From teemu.savolainen@nokia.com Tue Mar 1 07:47:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884C13A6992 for ; Tue, 1 Mar 2011 07:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 ODdCyw1rkzEv for ; Tue, 1 Mar 2011 07:47:46 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 94EEB3A6952 for ; Tue, 1 Mar 2011 07:47:46 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21Flei2029260; Tue, 1 Mar 2011 17:48:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 17:48:34 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Mar 2011 16:48:34 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 16:48:34 +0100 From: To: , Thread-Topic: Comments on draft-ietf-behave-v4v6-bih-02 Thread-Index: AcvXh1UbHpfb2lXBRvGZdRJSdxR9OQAnI4Iw Date: Tue, 1 Mar 2011 15:48:33 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C2170@008-AM1MPN1-015.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFA5E52@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AFA5E52@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 15:48:34.0960 (UTC) FILETIME=[1F89B100:01CBD828] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:47:47 -0000 Thank you Dave very much for your comments - we are already working on new = revision. Some replies and clarifying questions inline: > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of > ext Dave Thaler > Sent: 28. helmikuuta 2011 22:56 > To: behave@ietf.org > Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 >=20 > I have reviewed the latest version and have two main technical comments. > I also have lots of editorial nits that I will send directly to the autho= rs. > The main technical comments are summarized as follows. >=20 > 1) There are three ways to implement the ENR. > a) at the API layer (works fine with DNSSEC) > b) as a recursive resolver on the same host as discussed in Appendix = A > (I believe this has the same properties as DNS64 with respect to > DNSSEC impact) > c) in the network stack as shown in figure 2 (I think this breaks DNS= SEC) >=20 > Currently the document allows all three options, though seems to > treat (a) and (c) as equally recommended, and (b) is almost an > afterthought. Agree, the (a) comes from BIA and (c) from BIS, and this (b) is indeed newe= r thinking. Will look if this could be clarified. But I would not say (c) b= reaks DNSSEC more than network-based DNS64...:-) Works as long as host's re= solver does not do its own validation. > I would prefer a stronger recommendation towards things that work > with DNSSEC. For example, could we remove (c) all together from this > Standards Track document? I'd rather just make (a) a MUST, or at > least a strong SHOULD. The (a) is definitely the most powerful and works best with DNSSEC, but at = the same time I believe most difficult to implement. The (b) and (c) are po= ssible to have as plug-ins, which gives them some merit (especially for the= time being when host based DNSSEC validation is quite rare). What if docum= ent would say (a) is MUST if it is feasible to implement (i.e. acknowledgin= g sometimes the "MUST" may not hold)? =20 > Note that the choice of where the ENR is implemented is orthogonal > to where the protocol translation is implemented (which could be > either API layer, or in the network stack). Don't confuse this comm= ent > with BIS vs BIA for data translation. Agree, we will look ways to clarify this to the draft. > 2) Applications using name resolution APIs like gethostbyname() have no > idea whether DNS will be used or something else (hosts file, mDNS, > netbios, or whatever else). Indeed that was one of the main points > of RFC 6055. That's another reason why a type (a) ENR works much > better than a type (b) or (c) ENR, since (a) can be done in a name > resolution protocol agnostic way and the others cannot. Hopefully > folks now understand why I'd prefer to make (a) be a MUST or at least > a strong SHOULD. I'm not so sure about need for BIH for local communications (mDNS, netbios?= ) but this is true. Will add these considerations to the ENR section. > 3) Section 2.2 on the translator module in a BIS-like implementation clai= ms > that it needs to do fragmentation. Since as shown in figure 2, the > translator sits on top of the IPv6 stack, and the IPv6 stack can do > fragmentation, I can't imagine any reason the translator itself would > need to do fragmentation. It should just send it down to the IPv6 > module to fragment as needed. I thought SIIT procedure would directly construct an IPv6 packet that can b= e sent to the next hop link? I.e. the IPv6 packet would not be constructed = by the actual IPv6 layer, but just transported. While thinking about this, = it might be wiser for a host having BIS-model implementation to actually se= t local IPv4 interface's MTU small enough to avoid generation of IPv4 packe= ts that would be too large after translation:) From tom111.taylor@bell.net Tue Mar 1 07:59:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED553A6952 for ; Tue, 1 Mar 2011 07:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 hfb0JynvwnQO for ; Tue, 1 Mar 2011 07:59:08 -0800 (PST) Received: from blu0-omc3-s12.blu0.hotmail.com (blu0-omc3-s12.blu0.hotmail.com [65.55.116.87]) by core3.amsl.com (Postfix) with ESMTP id 295A93A6985 for ; Tue, 1 Mar 2011 07:59:08 -0800 (PST) Received: from BLU0-SMTP93 ([65.55.116.73]) by blu0-omc3-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 08:00:11 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.15] ([174.94.11.167]) by BLU0-SMTP93.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 08:00:11 -0800 Date: Tue, 1 Mar 2011 11:00:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2011 16:00:11.0248 (UTC) FILETIME=[BE8ECF00:01CBD829] Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:59:09 -0000 We have prepared this document to help sort out the multicast transition work in the BEHAVE and SOFTWIRES WGs. Please have a look at and comment on the conclusions. A new version of I-D, draft-tsou-multicast-transition-taxonomy-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-multicast-transition-taxonomy Revision: 00 Title: A Classification and Evaluation of Approaches to Transitional Multicast Creation_date: 2011-02-28 WG ID: Independent Submission Number_of_pages: 12 Abstract: A number of different contributions to the IETF make proposals in support of multicast during the transition from IPv4 to IPv6. This document provides a taxonomic framework to make it easier to see how the different proposals relate to each other. It analyzes the current work in progress in the light of this framework and draws a number of conclusions regarding how this work should move forward in the BEHAVE and SOFTWIRES Working Groups. From dthaler@microsoft.com Tue Mar 1 09:37:37 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5503C3A6A14 for ; Tue, 1 Mar 2011 09:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 zBGE+BhOInBw for ; Tue, 1 Mar 2011 09:37:36 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DAC0E3A6985 for ; Tue, 1 Mar 2011 09:37:35 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Mar 2011 09:38:40 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 1 Mar 2011 09:38:39 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.245]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 09:38:39 -0800 From: Dave Thaler To: "teemu.savolainen@nokia.com" , "behave@ietf.org" Thread-Topic: Comments on draft-ietf-behave-v4v6-bih-02 Thread-Index: AcvXh1UbHpfb2lXBRvGZdRJSdxR9OQAnI4IwAASWwYA= Date: Tue, 1 Mar 2011 17:38:36 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AFA8CCE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653AFA5E52@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <056B511A55F8AA42A3E492B7DD19A3193C2170@008-AM1MPN1-015.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193C2170@008-AM1MPN1-015.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 17:37:37 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Tuesday, March 01, 2011 7:49 AM > To: Dave Thaler; behave@ietf.org > Subject: RE: Comments on draft-ietf-behave-v4v6-bih-02 >=20 > Thank you Dave very much for your comments - we are already working on > new revision. Some replies and clarifying questions inline: >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of ext Dave Thaler > > Sent: 28. helmikuuta 2011 22:56 > > To: behave@ietf.org > > Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 > > > > I have reviewed the latest version and have two main technical comments= . > > I also have lots of editorial nits that I will send directly to the aut= hors. > > The main technical comments are summarized as follows. > > > > 1) There are three ways to implement the ENR. > > a) at the API layer (works fine with DNSSEC) > > b) as a recursive resolver on the same host as discussed in Appendi= x A > > (I believe this has the same properties as DNS64 with respect t= o > > DNSSEC impact) > > c) in the network stack as shown in figure 2 (I think this breaks > > DNSSEC) > > > > Currently the document allows all three options, though seems to > > treat (a) and (c) as equally recommended, and (b) is almost an > > afterthought. >=20 > Agree, the (a) comes from BIA and (c) from BIS, and this (b) is indeed ne= wer > thinking. Will look if this could be clarified. But I would not say (c) b= reaks > DNSSEC more than network-based DNS64...:-) Works as long as host's resolv= er > does not do its own validation. >=20 > > I would prefer a stronger recommendation towards things that work > > with DNSSEC. For example, could we remove (c) all together from th= is > > Standards Track document? I'd rather just make (a) a MUST, or at > > least a strong SHOULD. >=20 > The (a) is definitely the most powerful and works best with DNSSEC, but a= t the > same time I believe most difficult to implement. The (b) and (c) are poss= ible to > have as plug-ins, which gives them some merit (especially for the time be= ing > when host based DNSSEC validation is quite rare). What if document would = say > (a) is MUST if it is feasible to implement (i.e. acknowledging sometimes = the > "MUST" may not hold)? "MUST if it is feasible to implement" means the same as "SHOULD", and the=20 latter is more concise. =20 > > Note that the choice of where the ENR is implemented is orthogonal > > to where the protocol translation is implemented (which could be > > either API layer, or in the network stack). Don't confuse this co= mment > > with BIS vs BIA for data translation. >=20 > Agree, we will look ways to clarify this to the draft. >=20 > > 2) Applications using name resolution APIs like gethostbyname() have no > > idea whether DNS will be used or something else (hosts file, mDNS, > > netbios, or whatever else). Indeed that was one of the main point= s > > of RFC 6055. That's another reason why a type (a) ENR works much > > better than a type (b) or (c) ENR, since (a) can be done in a name > > resolution protocol agnostic way and the others cannot. Hopefully > > folks now understand why I'd prefer to make (a) be a MUST or at lea= st > > a strong SHOULD. >=20 > I'm not so sure about need for BIH for local communications (mDNS, netbio= s?) > but this is true. Will add these considerations to the ENR section. Aside: Neither mDNS nor netbios are restricted to communication on the link= . Netbios has name servers (like DNS does), which are what Windows folks some call WINS servers and RFCs 1001 and 1002 call name server ("NBNS") nod= es. mDNS uses multicast and, contains text saying that it could be used in the = future within wider scopes such as site-local. My main point is that DNS is not the only protocol for off-link name resolu= tion, and implementation option (a) is better than the others. > > 3) Section 2.2 on the translator module in a BIS-like implementation cl= aims > > that it needs to do fragmentation. Since as shown in figure 2, th= e > > translator sits on top of the IPv6 stack, and the IPv6 stack can do > > fragmentation, I can't imagine any reason the translator itself wou= ld > > need to do fragmentation. It should just send it down to the IPv6 > > module to fragment as needed. >=20 > I thought SIIT procedure would directly construct an IPv6 packet that can= be > sent to the next hop link? I.e. the IPv6 packet would not be constructed = by the > actual IPv6 layer, but just transported. While thinking about this, it mi= ght be > wiser for a host having BIS-model implementation to actually set local IP= v4 > interface's MTU small enough to avoid generation of IPv4 packets that wou= ld > be too large after translation:) Section 4 of draft-ietf-behave-v6v4-xlate already contains sufficient discussion. So I think the text on fragmentation can be removed, since the previous paragraph already references the entirety of that document. -Dave From teemu.savolainen@nokia.com Tue Mar 1 11:14:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0110B3A6A4A for ; Tue, 1 Mar 2011 11:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUJSRLASWeYh for ; Tue, 1 Mar 2011 11:14:27 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 299343A6A16 for ; Tue, 1 Mar 2011 11:14:26 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21JFFZU010474; Tue, 1 Mar 2011 21:15:28 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 21:15:14 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Mar 2011 20:15:13 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 20:15:08 +0100 From: To: , Thread-Topic: Comments on draft-ietf-behave-v4v6-bih-02 Thread-Index: AcvXh1UbHpfb2lXBRvGZdRJSdxR9OQAnI4IwAASWwYAAAnhfwA== Date: Tue, 1 Mar 2011 19:15:08 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C237F@008-AM1MPN1-015.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFA5E52@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <056B511A55F8AA42A3E492B7DD19A3193C2170@008-AM1MPN1-015.mgdnok.nokia.com> <9B57C850BB53634CACEC56EF4853FF653AFA8CCE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AFA8CCE@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.66.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 19:15:14.0533 (UTC) FILETIME=[FE426150:01CBD844] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 19:14:28 -0000 > > The (a) is definitely the most powerful and works best with DNSSEC, but= at > the > > same time I believe most difficult to implement. The (b) and (c) are > possible to > > have as plug-ins, which gives them some merit (especially for the time = being > > when host based DNSSEC validation is quite rare). What if document woul= d say > > (a) is MUST if it is feasible to implement (i.e. acknowledging sometime= s the > > "MUST" may not hold)? >=20 > "MUST if it is feasible to implement" means the same as "SHOULD", and the > latter is more concise. SHOULD then, for the next revision, perhaps: -- In order to properly support DNSSEC, the ENR SHOULD be implemented at the=20 socket API level. If the socket API level implementation is not possible,=20 DNSSEC support SHOULD be provided by other means. -- > My main point is that DNS is not the only protocol for off-link name > resolution, > and implementation option (a) is better than the others. Maybe: -- In the case of the socket API layer implementation option, when an IPv4 app= lication tries to do a forward lookup to resolve names via the resolver library (e.g., gethostbyname()), BIH intercepts the function call and instead calls the IPv6 equivalent functions (e.g., getnameinfo()) that will resolve both A and AAAA records. This implementation option is name re= solution protocol agnostic, and hence supports techniques such as "hosts-file", NetBIOS, mDNS, and essentially anything underlying operating system uses. -- > Section 4 of draft-ietf-behave-v6v4-xlate already contains sufficient > discussion. So I think the text on fragmentation can be removed, since > the previous paragraph already references the entirety of that document. Probably the same applies then for checksum as well, and hence the whole se= ction could be: -- 2.2. Protocol translator The protocol translator translates IPv4 into IPv6 and vice versa using the IP conversion mechanism defined in SIIT [I-D.ietf-behave-v6v4-xlate]. To avoid unnecessary fragmentation, host's IPv4 module should be configured with small enough MTU (IPv6 link MTU - 20 bytes). -- From stig@venaas.com Wed Mar 2 11:40:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACB63A6879 for ; Wed, 2 Mar 2011 11:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 holUF1b0TZVq for ; Wed, 2 Mar 2011 11:40:18 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 212573A686A for ; Wed, 2 Mar 2011 11:40:18 -0800 (PST) Received: from [10.33.12.88] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 75EE08042; Wed, 2 Mar 2011 20:41:23 +0100 (CET) Message-ID: <4D6E9D61.6030402@venaas.com> Date: Wed, 02 Mar 2011 11:41:21 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tom Taylor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 19:40:19 -0000 On 3/1/2011 8:00 AM, Tom Taylor wrote: > We have prepared this document to help sort out the multicast transition > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and comment > on the conclusions. A good well written document :) I would not use the term Multicast Topology for ASM vs SSM. Topology is more used for network topology... ASM and SSM are generally I think, referred to as different multicast service models. I would suggest using that term. That is the only change I would suggest in the draft. Some comments regarding ID.venaas-mcast46 though. It can be used together with ID.boucadair-64-multicast-address-format, and I plan to update it with a reference to that. This is maybe obvious though. It is correct that it is from 2008. Although not relevant, I feel like pointing out that the draft is very close to draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. Stig From dwing@cisco.com Wed Mar 2 12:19:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA43A6834 for ; Wed, 2 Mar 2011 12:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 7hdGUDntQL7H for ; Wed, 2 Mar 2011 12:19:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2D95E3A6823 for ; Wed, 2 Mar 2011 12:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1682; q=dns/txt; s=iport; t=1299097226; x=1300306826; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=y5nh6mH9DuonCgvtzNfvxkfPaQPf9bRAWom357djHmo=; b=krNXvWbSOhTg7fmEKJy4yx/koeVcn9Ei8BynVILxyLkXDredO6+H0SSy Q50bklOrgf4LPvRL3Pwn5dua+yx4qIF2AcEosNh3d+NREFTkvHxT1R4AG vPgRnSzdhfORFW+n7jB96ruGZbOk7+N7+vgKrPus6uVBfkzHJmOpbr7sK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAHo1bk2rR7Hu/2dsb2JhbACYFoFljHN0omObfoVhBIUX X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="272850274" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2011 20:20:25 +0000 Received: from dwingWS (dhcp-128-107-104-207.cisco.com [128.107.104.207]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p22KKQq0014880; Wed, 2 Mar 2011 20:20:26 GMT From: "Dan Wing" To: "'Stig Venaas'" , "'Tom Taylor'" References: <4D6E9D61.6030402@venaas.com> In-Reply-To: <4D6E9D61.6030402@venaas.com> Date: Wed, 2 Mar 2011 12:20:26 -0800 Message-ID: <0e6e01cbd917$445aaee0$cd100ca0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvZEdfl8p+7uZp2T6mMEc5Ev9jHMQABT2wA Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 20:19:21 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Stig Venaas > Sent: Wednesday, March 02, 2011 11:41 AM > To: Tom Taylor > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > multicast-transition-taxonomy-00 > > On 3/1/2011 8:00 AM, Tom Taylor wrote: > > We have prepared this document to help sort out the multicast > > transition > > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and > > comment > > on the conclusions. > > A good well written document :) Agreed. > I would not use the term Multicast Topology for ASM vs SSM. Topology is > more used for network topology... ASM and SSM are generally I think, > referred to as different multicast service models. I would suggest > using > that term. > > That is the only change I would suggest in the draft. > > Some comments regarding ID.venaas-mcast46 though. It can be used > together with ID.boucadair-64-multicast-address-format, and I plan > to update it with a reference to that. This is maybe obvious though. Tom, tt would be really valuable if you could email all of the authors of the various drafts and ask them to review draft-tsou-multicast-transition-taxonomy, to ensure their documents are all accurately summarized. -d > It is correct that it is from 2008. Although not relevant, I feel like > pointing out that the draft is very close to > draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. > > Stig > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tena@huawei.com Wed Mar 2 13:31:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8775B3A68BC for ; Wed, 2 Mar 2011 13:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 tTQCwjz9gKT1 for ; Wed, 2 Mar 2011 13:31:54 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 89F323A68C4 for ; Wed, 2 Mar 2011 13:31:54 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHG00M5T970Q6@usaga02-in.huawei.com> for behave@ietf.org; Wed, 02 Mar 2011 13:33:00 -0800 (PST) Received: from TingZousc1 ([10.193.34.192]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHG00ISE96ZIK@usaga02-in.huawei.com> for behave@ietf.org; Wed, 02 Mar 2011 13:33:00 -0800 (PST) Date: Wed, 02 Mar 2011 13:32:59 -0800 From: Tina Tsou In-reply-to: <0e6e01cbd917$445aaee0$cd100ca0$@com> To: 'Dan Wing' , 'Stig Venaas' , 'Tom Taylor' Message-id: <034c01cbd921$672f1c80$358d5580$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvZEdfl8p+7uZp2T6mMEc5Ev9jHMQABT2wAAAKJMrA= References: <4D6E9D61.6030402@venaas.com> <0e6e01cbd917$445aaee0$cd100ca0$@com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 21:31:55 -0000 Hi Dan, We have emailed all of the authors of the various drafts and ask them to review draft-tsou-multicast-transition-taxonomy. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing Sent: Wednesday, March 02, 2011 12:20 PM To: 'Stig Venaas'; 'Tom Taylor' Cc: behave@ietf.org Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Stig Venaas > Sent: Wednesday, March 02, 2011 11:41 AM > To: Tom Taylor > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > multicast-transition-taxonomy-00 > > On 3/1/2011 8:00 AM, Tom Taylor wrote: > > We have prepared this document to help sort out the multicast > > transition > > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and > > comment > > on the conclusions. > > A good well written document :) Agreed. > I would not use the term Multicast Topology for ASM vs SSM. Topology is > more used for network topology... ASM and SSM are generally I think, > referred to as different multicast service models. I would suggest > using > that term. > > That is the only change I would suggest in the draft. > > Some comments regarding ID.venaas-mcast46 though. It can be used > together with ID.boucadair-64-multicast-address-format, and I plan > to update it with a reference to that. This is maybe obvious though. Tom, tt would be really valuable if you could email all of the authors of the various drafts and ask them to review draft-tsou-multicast-transition-taxonomy, to ensure their documents are all accurately summarized. -d > It is correct that it is from 2008. Although not relevant, I feel like > pointing out that the draft is very close to > draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. > > Stig > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Mar 2 14:17:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956AE3A68C4 for ; Wed, 2 Mar 2011 14:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 yV+1lRLG3VXo for ; Wed, 2 Mar 2011 14:17:31 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B31E63A67B5 for ; Wed, 2 Mar 2011 14:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2871; q=dns/txt; s=iport; t=1299104318; x=1300313918; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=alN/x/SidL4Gv44WT94Kc3fa9FHT2lpej86NscEjxPU=; b=TDRoYaMEfTt8r0rXoJsNNaB4HDmAwuLXR06qlAQTfwuxT8hLvQhxFVxg 1z4ZUvxZZhH2Mahsj5Sa1LslSWiXjC+WzbQ5m0AKiEPI5DaEuOzr0r0qP BtzJ6MnsTFDp13Ok23F8BiI16tTJ8DlHxt5KDGFKcx+W9xab5ur9w7xsz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAG5Qbk2rRN+K/2dsb2JhbACYGYFljHN0omqcBIVhBIUX X-IronPort-AV: E=Sophos;i="4.62,255,1297036800"; d="scan'208";a="272895529" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2011 22:18:38 +0000 Received: from dwingWS (dhcp-128-107-104-207.cisco.com [128.107.104.207]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p22MIcug013883; Wed, 2 Mar 2011 22:18:38 GMT From: "Dan Wing" To: "'Tina Tsou'" , "'Stig Venaas'" , "'Tom Taylor'" References: <4D6E9D61.6030402@venaas.com> <0e6e01cbd917$445aaee0$cd100ca0$@com> <034c01cbd921$672f1c80$358d5580$@com> In-Reply-To: <034c01cbd921$672f1c80$358d5580$@com> Date: Wed, 2 Mar 2011 14:18:38 -0800 Message-ID: <0f8d01cbd927$c788e2e0$569aa8a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvZEdfl8p+7uZp2T6mMEc5Ev9jHMQABT2wAAAKJMrAAAaDb8A== Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 22:17:32 -0000 > -----Original Message----- > From: Tina Tsou [mailto:tena@huawei.com] > Sent: Wednesday, March 02, 2011 1:33 PM > To: 'Dan Wing'; 'Stig Venaas'; 'Tom Taylor' > Cc: behave@ietf.org > Subject: RE: [BEHAVE] Fwd: New Version Notification for draft-tsou- > multicast-transition-taxonomy-00 > > Hi Dan, > We have emailed all of the authors of the various drafts and ask them > to review draft-tsou-multicast-transition-taxonomy. Great. Thanks! -d > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of > Dan Wing > Sent: Wednesday, March 02, 2011 12:20 PM > To: 'Stig Venaas'; 'Tom Taylor' > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Fwd: New Version Notification for > draft-tsou-multicast-transition-taxonomy-00 > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Stig Venaas > > Sent: Wednesday, March 02, 2011 11:41 AM > > To: Tom Taylor > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > > multicast-transition-taxonomy-00 > > > > On 3/1/2011 8:00 AM, Tom Taylor wrote: > > > We have prepared this document to help sort out the multicast > > > transition > > > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and > > > comment > > > on the conclusions. > > > > A good well written document :) > > Agreed. > > > I would not use the term Multicast Topology for ASM vs SSM. Topology > is > > more used for network topology... ASM and SSM are generally I think, > > referred to as different multicast service models. I would suggest > > using > > that term. > > > > That is the only change I would suggest in the draft. > > > > Some comments regarding ID.venaas-mcast46 though. It can be used > > together with ID.boucadair-64-multicast-address-format, and I plan > > to update it with a reference to that. This is maybe obvious though. > > Tom, tt would be really valuable if you could email all of the > authors of the various drafts and ask them to review > draft-tsou-multicast-transition-taxonomy, to ensure their documents > are all accurately summarized. > > -d > > > It is correct that it is from 2008. Although not relevant, I feel > like > > pointing out that the draft is very close to > > draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. > > > > Stig > > > > _______________________________________________ > > 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 jacniq@gmail.com Thu Mar 3 00:58:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D08B3A6995 for ; Thu, 3 Mar 2011 00:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efR8eguKhIyB for ; Thu, 3 Mar 2011 00:58:00 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A08343A6882 for ; Thu, 3 Mar 2011 00:58:00 -0800 (PST) Received: by ywi6 with SMTP id 6so342016ywi.31 for ; Thu, 03 Mar 2011 00:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cVgNx9kh7d2pcogzpf8H6G8UQKxG0mVZuKrRFZGeCMg=; b=sxDEFkVInGOle0Mwoy03ZGJCphuOYyJMv+5h3qmHwckDIEdH/agEvnsKTS7qDCl0Ko exfUk8LXjSyr4SYVVvQn3zpiBmgLgrWU47ESoGQa3XBVZMOQ+5jKWgrdSNV/HjBzFYtX EAw2bDXHYV4Er4M9h2wDXrq3V+M+3/9gmhOw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f/u7nRkDl8gmLXjQAieZviHIRmE0x2NEwwd2eP1+3p6EN3MF9IIvguscuCrSgOU0m/ Xiu0iZ9W0DeSuAfhMh1JiK6yqWtRPGZJv8wIklMXM5fH09+aXSw2DbQOLznBDGDgc8h8 iHW33oxynNOmEANpLA7uXbDRy52IuoTWo5ykA= MIME-Version: 1.0 Received: by 10.151.83.4 with SMTP id k4mr1503357ybl.37.1299142747752; Thu, 03 Mar 2011 00:59:07 -0800 (PST) Received: by 10.147.41.16 with HTTP; Thu, 3 Mar 2011 00:59:07 -0800 (PST) In-Reply-To: <034c01cbd921$672f1c80$358d5580$@com> References: <4D6E9D61.6030402@venaas.com> <0e6e01cbd917$445aaee0$cd100ca0$@com> <034c01cbd921$672f1c80$358d5580$@com> Date: Thu, 3 Mar 2011 16:59:07 +0800 Message-ID: From: Jacni Qin To: Tina Tsou Content-Type: multipart/alternative; boundary=000e0cd4d2eefe0ed9049d903d26 Cc: Tom Taylor , Stig Venaas , behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 08:58:02 -0000 --000e0cd4d2eefe0ed9049d903d26 Content-Type: text/plain; charset=ISO-8859-1 Hi Tina, Thanks for writing the document, please see below my comments. For the discussions about draft-qin-softwire-dslite-multicast in Section 3, Acctually, both ASM and SSM are covered everytime when some points are discussed, for example, Address mapping, mB4, mAFTR. Particularly, the authors spent a lot of efforts on the ASM deployment issues encounterd in Section 7. So, please update the text related, also that in the Table 1, thanks. Cheers, Jacni On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou wrote: > Hi Dan, > We have emailed all of the authors of the various drafts and ask them to > review draft-tsou-multicast-transition-taxonomy. > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of > Dan Wing > Sent: Wednesday, March 02, 2011 12:20 PM > To: 'Stig Venaas'; 'Tom Taylor' > Cc: behave@ietf.org > Subject: Re: [BEHAVE] Fwd: New Version Notification for > draft-tsou-multicast-transition-taxonomy-00 > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Stig Venaas > > Sent: Wednesday, March 02, 2011 11:41 AM > > To: Tom Taylor > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > > multicast-transition-taxonomy-00 > > > > On 3/1/2011 8:00 AM, Tom Taylor wrote: > > > We have prepared this document to help sort out the multicast > > > transition > > > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and > > > comment > > > on the conclusions. > > > > A good well written document :) > > Agreed. > > > I would not use the term Multicast Topology for ASM vs SSM. Topology is > > more used for network topology... ASM and SSM are generally I think, > > referred to as different multicast service models. I would suggest > > using > > that term. > > > > That is the only change I would suggest in the draft. > > > > Some comments regarding ID.venaas-mcast46 though. It can be used > > together with ID.boucadair-64-multicast-address-format, and I plan > > to update it with a reference to that. This is maybe obvious though. > > Tom, tt would be really valuable if you could email all of the > authors of the various drafts and ask them to review > draft-tsou-multicast-transition-taxonomy, to ensure their documents > are all accurately summarized. > > -d > > > It is correct that it is from 2008. Although not relevant, I feel like > > pointing out that the draft is very close to > > draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. > > > > Stig > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --000e0cd4d2eefe0ed9049d903d26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tina,

Thanks for writing the do= cument, please see below my comments.

For the discussions about draf= t-qin-softwire-dslite-multicast in Section 3,
Acctually, both ASM and SS= M are covered everytime when some points are discussed, for example, Addres= s mapping, mB4, mAFTR.
Particularly, the authors spent a lot of efforts on the ASM deployment issu= es encounterd in Section 7.
So, please update the text related, also tha= t in the Table 1, thanks.


Cheers,
Jacni


On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou <tena@huawei.com><= /span> wrote:
Hi Dan,
We have emailed all of the authors of the various drafts and ask them to review draft-tsou-multicast-transition-taxonomy.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http:= //tinatsou.weebly.com/contact.html


-----Original Message-----
From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.or= g] On Behalf Of
Dan Wing
Sent: Wednesday, March 02, 2011 12:20 PM
To: 'Stig Venaas'; 'Tom Taylor'
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for
draft-tsou-multicast-transition-taxonomy-00

> -----Original Message-----
> From: behave-bounces@ietf.o= rg [mailto:behave-bounces@ie= tf.org] On
> Behalf Of Stig Venaas
> Sent: Wednesday, March 02, 2011 11:41 AM
> To: Tom Taylor
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- > multicast-transition-taxonomy-00
>
> On 3/1/2011 8:00 AM, Tom Taylor wrote:
> > We have prepared this document to help sort out the multicast
> > transition
> > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and > > comment
> > on the conclusions.
>
> A good well written document :)

Agreed.

> I would not use the term Multicast Topology for ASM vs SSM. Topology i= s
> more used for network topology... ASM and SSM are generally I think, > referred to as different multicast service models. I would suggest
> using
> that term.
>
> That is the only change I would suggest in the draft.
>
> Some comments regarding ID.venaas-mcast46 though. It can be used
> together with ID.boucadair-64-multicast-address-format, and I plan
> to update it with a reference to that. This is maybe obvious though.
Tom, tt would be really valuable if you could email all of the
authors of the various drafts and ask them to review
draft-tsou-multicast-transition-taxonomy, to ensure their documents
are all accurately summarized.

-d

> It is correct that it is from 2008. Although not relevant, I feel like=
> pointing out that the draft is very close to
> draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.
>
> Stig
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

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

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

--000e0cd4d2eefe0ed9049d903d26-- From behcetsarikaya@yahoo.com Thu Mar 3 12:52:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954613A69FD for ; Thu, 3 Mar 2011 12:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 eoGGA5LEDIxm for ; Thu, 3 Mar 2011 12:52:40 -0800 (PST) Received: from nm11.bullet.mail.sp2.yahoo.com (nm11.bullet.mail.sp2.yahoo.com [98.139.91.81]) by core3.amsl.com (Postfix) with SMTP id 4F1A33A6800 for ; Thu, 3 Mar 2011 12:52:39 -0800 (PST) Received: from [98.139.91.62] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 03 Mar 2011 20:53:44 -0000 Received: from [98.139.91.46] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 03 Mar 2011 20:53:44 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 03 Mar 2011 20:53:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 783245.93342.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 20015 invoked by uid 60001); 3 Mar 2011 20:53:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299185624; bh=BvHfdkUmqd4rCsqfbM/avp4xSSWGAro7yUY0kdaLNS8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1cCzpn7R762Su2WEaep577SEwV1Rar0NYmxTOzVRXKEYfPHa/cy6f7hyQlkrLqkmQHwk7oMU6UfxJKv7ZoF6tQSeBxj7uY7YhQe/ZmvpFNoiMTXaj/QofaviDPTINO2Gjdgydjm5BK/clUxPBKPm04POY/O5+xskH1o0CG2fVIo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LWkt8HnWzPZsxwUlKxAitf14Rhxq5kU2JRd7syx1k/4ZoCakLlEK73FpKfQSY1akHwMuulDZqyPslizdFl09ObcBKxnEjOA+KXIOjdxYdlK60j4qrDHu47I7tfqaoIheu7W5LhgnEUOMYHqUVTHu41/hj2prLG+k0qZvxOQfNPo=; Message-ID: <391898.19039.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: IKBNmT4VM1k5Q6u6_Id7K6wXDdj7XkHdIFXiVWr8AHxZDH3 gepLlEnDXXD3fIGJNgE_DdBDygDFKlU8cuxk78GgwQoCcvt4oNP7u7mJG4ZD oulFrNqfpdLv_XJvHd3WmtecSkMK2ZTKJXJzKLL4Sdafp1TpCwvD2uB5nJbm TY2OLlAvSEaQ8gH_z9STCpZBzO_h_s1R8SXjJmVnKmUaXcf9ede9RdqONn3N 5XnXnYd6M2K.ewPPp.oBII_8u8Mv6ND02Jy6rdOAQN3xfZS4QLr0lI4FjFE8 ALuojZL7VqUkyQfak2ybk6H9q20f7Jufa9jvR5LLaKuWcFGsrHigldXSdc53 XT3R8xp6Wl5IfozjYow7PERjk7JI8As8vUwM2m6azB_0JBcBjYAgOa_5MvxB waDqFOWKnM9C7 Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 03 Mar 2011 12:53:44 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: Date: Thu, 3 Mar 2011 12:53:44 -0800 (PST) From: Behcet Sarikaya To: Tom Taylor , "behave@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:52:43 -0000 Hi Tom, Here are my comments. First of all NAT64 multicast has been implemented in Teemu Kiviniemi's thesis, he announced it in Behave list more than once. [ID.sarikaya-mcast4nat64] is based on this implementation. The thesis gives credit to [ID.venaas-mcast46] especially in address translation. You mentioned that [ID.sarikaya-mcast4nat64] has a number of useful details, these details are on protocol translation part. It is important to note that SIIT algorithm requires modifications for multicast protocol translation. BTW, I have submitted a new version of this draft. Regarding DS-Lite and 6rd, I think that totally different approaches are needed. I am going to submit a draft before the deadline expires. Keep up the good work. Regards, Behcet From tom111.taylor@bell.net Thu Mar 3 20:05:52 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBB53A692B for ; Thu, 3 Mar 2011 20:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.506 X-Spam-Level: X-Spam-Status: No, score=-101.506 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 EX4ppfnteuIA for ; Thu, 3 Mar 2011 20:05:51 -0800 (PST) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by core3.amsl.com (Postfix) with ESMTP id 82E7B3A6926 for ; Thu, 3 Mar 2011 20:05:47 -0800 (PST) Received: from BLU0-SMTP19 ([65.55.116.74]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 20:06:55 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP19.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 20:06:55 -0800 Date: Thu, 3 Mar 2011 23:06:59 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Jacni Qin References: <4D6E9D61.6030402@venaas.com> <0e6e01cbd917$445aaee0$cd100ca0$@com> <034c01cbd921$672f1c80$358d5580$@com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2011 04:06:55.0490 (UTC) FILETIME=[99899E20:01CBDA21] Cc: Stig Venaas , behave@ietf.org, Dan Wing , Tina Tsou Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 04:05:52 -0000 This is a point to be discussed. Our criterion for whether ASM was addressed was whether sources were allowed in network A. You discussed ASM in network C, and the table records this fact, but your introduction has the following statement: "This document does not cover the case where an IPv4 host connected to a CPE served by a DS-Lite AFTR can be the source of multicast traffic." Should we classify by a different criterion than the one we used? On 03/03/2011 3:59 AM, Jacni Qin wrote: > Hi Tina, > > Thanks for writing the document, please see below my comments. > > For the discussions about draft-qin-softwire-dslite-multicast in Section 3, > Acctually, both ASM and SSM are covered everytime when some points are > discussed, for example, Address mapping, mB4, mAFTR. > Particularly, the authors spent a lot of efforts on the ASM deployment > issues encounterd in Section 7. > So, please update the text related, also that in the Table 1, thanks. > > > Cheers, > Jacni > > > On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou wrote: > >> Hi Dan, >> We have emailed all of the authors of the various drafts and ask them to >> review draft-tsou-multicast-transition-taxonomy. >> >> >> We keep our promises with one another - no matter what! >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >> Of >> Dan Wing >> Sent: Wednesday, March 02, 2011 12:20 PM >> To: 'Stig Venaas'; 'Tom Taylor' >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] Fwd: New Version Notification for >> draft-tsou-multicast-transition-taxonomy-00 >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of Stig Venaas >>> Sent: Wednesday, March 02, 2011 11:41 AM >>> To: Tom Taylor >>> Cc: behave@ietf.org >>> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >>> multicast-transition-taxonomy-00 >>> >>> On 3/1/2011 8:00 AM, Tom Taylor wrote: >>>> We have prepared this document to help sort out the multicast >>>> transition >>>> work in the BEHAVE and SOFTWIRES WGs. Please have a look at and >>>> comment >>>> on the conclusions. >>> >>> A good well written document :) >> >> Agreed. >> >>> I would not use the term Multicast Topology for ASM vs SSM. Topology is >>> more used for network topology... ASM and SSM are generally I think, >>> referred to as different multicast service models. I would suggest >>> using >>> that term. >>> >>> That is the only change I would suggest in the draft. >>> >>> Some comments regarding ID.venaas-mcast46 though. It can be used >>> together with ID.boucadair-64-multicast-address-format, and I plan >>> to update it with a reference to that. This is maybe obvious though. >> >> Tom, tt would be really valuable if you could email all of the >> authors of the various drafts and ask them to review >> draft-tsou-multicast-transition-taxonomy, to ensure their documents >> are all accurately summarized. >> >> -d >> >>> It is correct that it is from 2008. Although not relevant, I feel like >>> pointing out that the draft is very close to >>> draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. >>> >>> Stig >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From jean-philippe.dionne@viagenie.ca Fri Mar 4 10:40:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612503A69EC for ; Fri, 4 Mar 2011 10:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, 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 jqDCfDP2uhiA for ; Fri, 4 Mar 2011 10:40:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id EDBE83A69C7 for ; Fri, 4 Mar 2011 10:40:20 -0800 (PST) Received: from jpdionne.viagenie.ca (unknown [IPv6:2620:0:230:c000:226:55ff:fe3c:7eff]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1A88721EDE for ; Fri, 4 Mar 2011 13:41:29 -0500 (EST) Message-ID: <4D713258.3050105@viagenie.ca> Date: Fri, 04 Mar 2011 13:41:28 -0500 From: Jean-Philippe Dionne User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org Content-Type: multipart/mixed; boundary="------------070608080309050802060809" Subject: [BEHAVE] Fwd: I-D Action:draft-jpdionne-behave-nat64-mib-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: Fri, 04 Mar 2011 18:40:22 -0000 This is a multi-part message in MIME format. --------------070608080309050802060809 Content-Type: multipart/alternative; boundary="------------010304080509080009040202" --------------010304080509080009040202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, A modification of the NAT-MIB is proposed to take into consideration NAT64. Comments are welcomed. Thanks Jean-Philippe Dionne -------- Original Message -------- Subject: I-D Action:draft-jpdionne-behave-nat64-mib-00.txt Date: Fri, 04 Mar 2011 07:30:02 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64 Management Information Base (MIB) Author(s) : J. Dionne, M. Blanchet Filename : draft-jpdionne-behave-nat64-mib-00.txt Pages : 11 Date : 2011-03-04 This memo describes the NAT64 Management Information Base. It reuses the NAT-MIB and add specific NAT64 variables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jpdionne-behave-nat64-mib-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. --------------010304080509080009040202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

A modification of the NAT-MIB is proposed to take into consideration NAT64.   Comments are welcomed.

Thanks
Jean-Philippe Dionne

-------- Original Message --------
Subject: I-D Action:draft-jpdionne-behave-nat64-mib-00.txt
Date: Fri, 04 Mar 2011 07:30:02 -0800
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : NAT64 Management Information Base (MIB)
	Author(s)       : J. Dionne, M. Blanchet
	Filename        : draft-jpdionne-behave-nat64-mib-00.txt
	Pages           : 11
	Date            : 2011-03-04

This memo describes the NAT64 Management Information Base.  It reuses
the NAT-MIB and add specific NAT64 variables.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jpdionne-behave-nat64-mib-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.
--------------010304080509080009040202-- --------------070608080309050802060809 Content-Type: Message/External-body; name="draft-jpdionne-behave-nat64-mib-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-jpdionne-behave-nat64-mib-00.txt" Content-Type: text/plain Content-ID: <2011-03-04071631.I-D@ietf.org> --------------070608080309050802060809 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070608080309050802060809-- From stig@venaas.com Fri Mar 4 11:30:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1073A6A1D for ; Fri, 4 Mar 2011 11:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 oTbilzta-vPW for ; Fri, 4 Mar 2011 11:30:00 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 03C0E3A6A17 for ; Fri, 4 Mar 2011 11:30:00 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:892b:ee27:895e:969a] (unknown [IPv6:2001:420:4:ea0c:892b:ee27:895e:969a]) by ufisa.uninett.no (Postfix) with ESMTPSA id A021A8017; Fri, 4 Mar 2011 20:31:07 +0100 (CET) Message-ID: <4D713DF8.7090706@venaas.com> Date: Fri, 04 Mar 2011 11:31:04 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Behcet Sarikaya References: <391898.19039.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: <391898.19039.qm@web111414.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tom Taylor , Behcet Sarikaya , "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 19:30:01 -0000 On 3/3/2011 12:53 PM, Behcet Sarikaya wrote: > Hi Tom, > Here are my comments. > > > First of all NAT64 multicast has been implemented in Teemu Kiviniemi's thesis, > he announced it in Behave list more than once. > > [ID.sarikaya-mcast4nat64] is based on this implementation. The thesis gives > credit to [ID.venaas-mcast46] especially in address translation. Yes, the implementation was based on [ID.venaas-mcast46] Stig From behcetsarikaya@yahoo.com Fri Mar 4 13:59:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954C028C0E3 for ; Fri, 4 Mar 2011 13:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 Gg6sRkSsM2HQ for ; Fri, 4 Mar 2011 13:59:23 -0800 (PST) Received: from nm9-vm0.bullet.mail.sp2.yahoo.com (nm9-vm0.bullet.mail.sp2.yahoo.com [98.139.91.196]) by core3.amsl.com (Postfix) with SMTP id D6FE33A68AC for ; Fri, 4 Mar 2011 13:59:23 -0800 (PST) Received: from [98.139.91.63] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 04 Mar 2011 22:00:30 -0000 Received: from [98.139.91.9] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 04 Mar 2011 22:00:30 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 04 Mar 2011 22:00:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 845324.61183.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 47086 invoked by uid 60001); 4 Mar 2011 22:00:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299276030; bh=V3IrAxzRV9Plmln6Dchsz5MtWzMOxCVrB+V9NZy07ZY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SQ+/I1mtoNkDbjdCweH8HhPcui2fss+4SaNCXUWCxQk9mfNzzFh5K88VPj+Swy9kXkxqYtnWYovXFDUu3jmNP8rxbIwYGmJV69k62OdytVcfXN4Yy5BwPjgnt19+BwbJH7u6ybt6lRW8e7BqNEU64gMNHA5ZJJIonD3dsRzBPGY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=49o6J2qOo5pbIQCv2aC9VkL2/ftL7Hrdw8+zOJS4MO0f1DwTVbpU1ceLlh/uJ2thKDZfjrsAtmnoGLswRtZzHogAkUm7brDkuVM6gX4kiT4nTC48iB4qK1FgSn9Fl2GuKaILMSJbGwCIiRr2DN0Zo6YnzbKuvyYsOxjQfVwioio=; Message-ID: <348573.45529.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: TltCGpIVM1l.vWIQOIASBS8Gpktn.HbA8Oakk3WGTbtJPZU L.75Ow_9UGom6T6KqD4zJYg67X51ONym8JvNj2PVJ18IHAfdEv25VtsgrYhN RUZeks.z03mvkACxATPzLcaeiqogSM.t7AdrXgzgdvfwAJ2ptmX22BiG9Csm 6NvIc6wVmon4ZC94hB37DukJbAFyhKaKwMm_amykaB.IdjP_Yw8T5tblRl2E nCmPlDKKVVHNLxqVr6p367RxS7uDBpFPHVD.WJ37cbzGtEGf84JXsY.ZB8nz DI.1q9c_NfGEyi8bJ0FbnLg041yrXmeYPKV2UsGXezdFzCzlVFNLWXEmHvHo uggSmHe55XoKwj2v8ZuMBy7nkypttfi7eYzSMHrqjDwzjnDUR79X0_pldRqr YcqRT_c9_n3o1 Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Fri, 04 Mar 2011 14:00:30 PST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.292656 References: <391898.19039.qm@web111414.mail.gq1.yahoo.com> <4D713DF8.7090706@venaas.com> Date: Fri, 4 Mar 2011 14:00:30 -0800 (PST) From: Behcet Sarikaya To: Stig Venaas In-Reply-To: <4D713DF8.7090706@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:59:24 -0000 > > On 3/3/2011 12:53 PM, Behcet Sarikaya wrote: > > Hi Tom, > > Here are my comments. > > > > > > First of all NAT64 multicast has been implemented in Teemu Kiviniemi's >thesis, > > he announced it in Behave list more than once. > > > > [ID.sarikaya-mcast4nat64] is based on this implementation. The thesis gives > > credit to [ID.venaas-mcast46] especially in address translation. > > Yes, the implementation was based on [ID.venaas-mcast46] It is a little overstatement, I think. Yes, Stig has done pioneer work in this area, dating way back to 2003. Thanks Stig. If you take away NAT46 part and add multicast data protocol translation you get something like [ID.sarikaya-mcast4nat64] which is based on Kiviniemi's thesis :-). Regards, Behcet From stig@venaas.com Fri Mar 4 14:32:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF29E3A68AC for ; Fri, 4 Mar 2011 14:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 J-nmFCEZ3s-c for ; Fri, 4 Mar 2011 14:32:16 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id AF6E93A68AB for ; Fri, 4 Mar 2011 14:32:15 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:892b:ee27:895e:969a] (unknown [IPv6:2001:420:4:ea0c:892b:ee27:895e:969a]) by ufisa.uninett.no (Postfix) with ESMTPSA id 75B798000; Fri, 4 Mar 2011 23:33:23 +0100 (CET) Message-ID: <4D7168B0.8080401@venaas.com> Date: Fri, 04 Mar 2011 14:33:20 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Behcet Sarikaya References: <391898.19039.qm@web111414.mail.gq1.yahoo.com> <4D713DF8.7090706@venaas.com> <348573.45529.qm@web111401.mail.gq1.yahoo.com> In-Reply-To: <348573.45529.qm@web111401.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behcet Sarikaya , "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 22:32:17 -0000 On 3/4/2011 2:00 PM, Behcet Sarikaya wrote: >> > >> On 3/3/2011 12:53 PM, Behcet Sarikaya wrote: >>> Hi Tom, >>> Here are my comments. >>> >>> >>> First of all NAT64 multicast has been implemented in Teemu Kiviniemi's >> thesis, >>> he announced it in Behave list more than once. >>> >>> [ID.sarikaya-mcast4nat64] is based on this implementation. The thesis gives >>> credit to [ID.venaas-mcast46] especially in address translation. >> >> Yes, the implementation was based on [ID.venaas-mcast46] > > It is a little overstatement, I think. All I know is what he told me. When he announced it on the behave wg list last May he wrote: The implementation follows the architectural ideas and address translation presented in draft-venaas-behave-mcast46. IPv4 to IPv6 protocol translation is done using an adapted version of the SIIT algorithm. IPv6 to IPv4 translation or unicast translation is not supported. So maybe it is just the ideas. > Yes, Stig has done pioneer work in this area, dating way back to 2003. Thanks > Stig. > > If you take away NAT46 part and add multicast data protocol translation you get > something like [ID.sarikaya-mcast4nat64] which is based on Kiviniemi's thesis > :-). There are not that many ways to do this. So there are going to be some similarities either way. You can say that my draft is similar to NAT46 too I think... Stig > Regards, > > Behcet > > > From behcetsarikaya@yahoo.com Fri Mar 4 15:04:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A0F3A68AC for ; Fri, 4 Mar 2011 15:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 zuaLQcWkzcR2 for ; Fri, 4 Mar 2011 15:04:24 -0800 (PST) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by core3.amsl.com (Postfix) with SMTP id 0FB313A6812 for ; Fri, 4 Mar 2011 15:04:24 -0800 (PST) Received: from [98.139.91.61] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 04 Mar 2011 23:05:31 -0000 Received: from [98.139.91.8] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 04 Mar 2011 23:05:31 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 04 Mar 2011 23:05:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 605073.66000.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 7066 invoked by uid 60001); 4 Mar 2011 23:05:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299279931; bh=LMxd3ABeK7yi2Oe/CN0RhjxltiJYUFQPAuCUuqByYYA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bZ22KiaLym49tLSCHQcwnHD8HtN7doLOvLCBzdsa41rRi/nENtrzygoxn8e6HSITk+dd1YUrahG1s2X9J2iWCtHo4KleQt+3T+d2+ap97rk8tC9TejQcg+QhVp1CttRS/sl7ZyI2y5Af39GSLb1DK/LJCvUEemccvHsHfu3nxqY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=boUUahaPGpuhe5KkOiUaeFVrClKD7TmhD9vMPKUdxQytmpIuasqL2S4+xhB/Shqtj0QsbeeHFntkLUmNM9G33QihvVyLRmwcZRJgopIoaMEq+zHe6PvbaL79bPzUpIFiqDQgEz0913B6gS4SJpbaT+FQBn1f7Mq7yifzXFOksMs=; Message-ID: <207876.7053.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: K.cx5j0VM1ltXWuLSviamB6diCJm4P9ywN2GDyzPFAQFyEP p6pDcbDVmXY4YOrbWy.9VBlZ6D_jn5q0TqGFOmShARW.p_DR2vSPYbhO8Zsu .NAVm8NRA2sGqKQYX4JKsZ2nmGRxiXiteCs.BIFdDGFzydjtVyI2B4NY4J1N .tTmlh02.A7cPkI56Ic6vvS8CYTFkDjtZPslWEyx.nxAlEso5DjGOAH3tjVJ xVNX5EWgZ1PB0fKwYzICAMxJ4f.9Gr_wAQVzCHeSYw8MfYeyln7G3ax9Z8HA x0nybQOk6Y1YRxYx3YLi1mrpApQnex35nVUkntHM.zgM0fllb18DQDSVzx5_ eKELcXpdbI.cnQ8SMDiu4csfDJLngyD43u5KCbzRMqe2tSmnEWT0daN58jTw 9Y7W5zikJlmsB Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 04 Mar 2011 15:05:30 PST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.292656 References: <391898.19039.qm@web111414.mail.gq1.yahoo.com> <4D713DF8.7090706@venaas.com> <348573.45529.qm@web111401.mail.gq1.yahoo.com> <4D7168B0.8080401@venaas.com> Date: Fri, 4 Mar 2011 15:05:30 -0800 (PST) From: Behcet Sarikaya To: Stig Venaas In-Reply-To: <4D7168B0.8080401@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 23:04:24 -0000 > > On 3/4/2011 2:00 PM, Behcet Sarikaya wrote: > >> > > > >> On 3/3/2011 12:53 PM, Behcet Sarikaya wrote: > >>> Hi Tom, > >>> Here are my comments. > >>> > >>> > >>> First of all NAT64 multicast has been implemented in Teemu Kiviniemi's > >> thesis, > >>> he announced it in Behave list more than once. > >>> > >>> [ID.sarikaya-mcast4nat64] is based on this implementation. The thesis >gives > >>> credit to [ID.venaas-mcast46] especially in address translation. > >> > >> Yes, the implementation was based on [ID.venaas-mcast46] > > > > It is a little overstatement, I think. > > All I know is what he told me. When he announced it on the behave wg > list last May he wrote: > > The implementation follows the architectural ideas and address > translation presented in draft-venaas-behave-mcast46. IPv4 to IPv6 > protocol translation is done using an adapted version of the SIIT > algorithm. IPv6 to IPv4 translation or unicast translation is not > supported. > > So maybe it is just the ideas. > > > Yes, Stig has done pioneer work in this area, dating way back to 2003. >Thanks > > Stig. > > > > If you take away NAT46 part and add multicast data protocol translation you >get > > something like [ID.sarikaya-mcast4nat64] which is based on Kiviniemi's >thesis > > :-). > > There are not that many ways to do this. So there are going to be some > similarities either way. > You can say that my draft is similar to NAT46 > too I think... In "take away NAT46" above, NAT46 refers to what [ID.venaas-mcast46] have in Sections 5.2 - 5.4 and 6.3 - 6.4. i.e. IPv4 only host talking to IPv6 only servers. Regards, Behcet From jacniq@gmail.com Sun Mar 6 22:25:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A4A3A6914 for ; Sun, 6 Mar 2011 22:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmEqORcOhO6e for ; Sun, 6 Mar 2011 22:25:29 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id D99A53A67F5 for ; Sun, 6 Mar 2011 22:25:27 -0800 (PST) Received: by ywi6 with SMTP id 6so1909013ywi.31 for ; Sun, 06 Mar 2011 22:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1n4bun+6Bns29SavJuUwC9MT8Q5Ex8BC1Uh49wag7QE=; b=wkL3B6ZCxs9wUMOA3/3wtLF3/H1UjJyM1rlg1kxkuQUSYzFni9LFpnqOpQFaD0YRFj H8f5mA/LRFBrFBQkjj4XsBwV7jTGMerKDpgur0lT7UFN+ow62Z75ccjm4mLJHH8zhO2H T5Bdxlhc1mFDE5HAkbFnnHwkupjb7DPwd7fg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GG35P9OeS3X4qMNxGjhZC3J2VBe/ZMViOwfGAni6AieiHAitU9bmRRqeb4IPDSBxkV +9G5h9tFpJeJDF+lWDD3+xxFNRGHGukIjtUUu/kllUkdWm5Tl+IomIQfuTR1QNNPP7eB sDo/L9BAE1isS9wFErBiNYP5ui65WZxH8IQG4= MIME-Version: 1.0 Received: by 10.150.56.17 with SMTP id e17mr4076418yba.190.1299479200559; Sun, 06 Mar 2011 22:26:40 -0800 (PST) Received: by 10.146.82.4 with HTTP; Sun, 6 Mar 2011 22:26:40 -0800 (PST) In-Reply-To: References: <4D6E9D61.6030402@venaas.com> <0e6e01cbd917$445aaee0$cd100ca0$@com> <034c01cbd921$672f1c80$358d5580$@com> Date: Mon, 7 Mar 2011 14:26:40 +0800 Message-ID: From: Jacni Qin To: Tom Taylor Content-Type: multipart/alternative; boundary=000e0cd707782474db049dde9487 Cc: Stig Venaas , behave@ietf.org, Dan Wing , Tina Tsou Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 06:25:40 -0000 --000e0cd707782474db049dde9487 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Sorry, I don't follow you point. For ASM, we mean "Any-Source Multicast". The statement below is just to clarify that for example, in practical deployment of the scheme, the broadband subscribers are not allowed to source the multicast traffic. Other things like, RP, Source Registration, of ASM are all taken into account. Cheers, Jacni On Fri, Mar 4, 2011 at 12:06 PM, Tom Taylor wrote: > This is a point to be discussed. Our criterion for whether ASM was > addressed was whether sources were allowed in network A. You discussed ASM > in network C, and the table records this fact, but your introduction has the > following statement: > > "This document does not cover the case where an IPv4 host connected to > a CPE served by a DS-Lite AFTR can be the source of multicast > traffic." > > Should we classify by a different criterion than the one we used? > > > > On 03/03/2011 3:59 AM, Jacni Qin wrote: > >> Hi Tina, >> >> Thanks for writing the document, please see below my comments. >> >> For the discussions about draft-qin-softwire-dslite-multicast in Section >> 3, >> Acctually, both ASM and SSM are covered everytime when some points are >> discussed, for example, Address mapping, mB4, mAFTR. >> Particularly, the authors spent a lot of efforts on the ASM deployment >> issues encounterd in Section 7. >> So, please update the text related, also that in the Table 1, thanks. >> >> >> Cheers, >> Jacni >> >> >> On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou wrote: >> >> Hi Dan, >>> We have emailed all of the authors of the various drafts and ask them to >>> review draft-tsou-multicast-transition-taxonomy. >>> >>> >>> We keep our promises with one another - no matter what! >>> >>> Best Regards, >>> Tina TSOU >>> http://tinatsou.weebly.com/contact.html >>> >>> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >>> Of >>> Dan Wing >>> Sent: Wednesday, March 02, 2011 12:20 PM >>> To: 'Stig Venaas'; 'Tom Taylor' >>> Cc: behave@ietf.org >>> Subject: Re: [BEHAVE] Fwd: New Version Notification for >>> draft-tsou-multicast-transition-taxonomy-00 >>> >>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of Stig Venaas >>>> Sent: Wednesday, March 02, 2011 11:41 AM >>>> To: Tom Taylor >>>> Cc: behave@ietf.org >>>> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou- >>>> multicast-transition-taxonomy-00 >>>> >>>> On 3/1/2011 8:00 AM, Tom Taylor wrote: >>>> >>>>> We have prepared this document to help sort out the multicast >>>>> transition >>>>> work in the BEHAVE and SOFTWIRES WGs. Please have a look at and >>>>> comment >>>>> on the conclusions. >>>>> >>>> >>>> A good well written document :) >>>> >>> >>> Agreed. >>> >>> I would not use the term Multicast Topology for ASM vs SSM. Topology is >>>> more used for network topology... ASM and SSM are generally I think, >>>> referred to as different multicast service models. I would suggest >>>> using >>>> that term. >>>> >>>> That is the only change I would suggest in the draft. >>>> >>>> Some comments regarding ID.venaas-mcast46 though. It can be used >>>> together with ID.boucadair-64-multicast-address-format, and I plan >>>> to update it with a reference to that. This is maybe obvious though. >>>> >>> >>> Tom, tt would be really valuable if you could email all of the >>> authors of the various drafts and ask them to review >>> draft-tsou-multicast-transition-taxonomy, to ensure their documents >>> are all accurately summarized. >>> >>> -d >>> >>> It is correct that it is from 2008. Although not relevant, I feel like >>>> pointing out that the draft is very close to >>>> draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. >>>> >>>> Stig >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >> --000e0cd707782474db049dde9487 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom,

Sorry, I don't follow = you point.

For ASM, we mean "Any-Source Multicast". The st= atement below is just to clarify that for example, in practical depl= oyment of the scheme, the broadban= d subscribers are not allowed to s= ource the multicast traffic. Other things like, RP, Source Registration, of= ASM are all taken into account.


Cheers,
Jacni

On Fri, M= ar 4, 2011 at 12:06 PM, Tom Taylor <tom111.taylor@bell.net> wrote:
This is a point to be discussed. Our criterion for whether ASM was addresse= d was whether sources were allowed in network A. You discussed ASM in netwo= rk C, and the table records this fact, but your introduction has the follow= ing statement:

=A0"This document does not cover the case where an IPv4 host connecte= d to
=A0 a CPE served by a DS-Lite AFTR can be the source of multicast
=A0 traffic."

Should we classify by a different criterion than the one we used?
=



On 03/03/2011 3:59 AM, Jacni Qin wrote:
Hi Tina,

Thanks for writing the document, please see below my comments.

For the discussions about draft-qin-softwire-dslite-multicast in Section 3,=
Acctually, both ASM and SSM are covered everytime when some points are
discussed, for example, Address mapping, mB4, mAFTR.
Particularly, the authors spent a lot of efforts on the ASM deployment
issues encounterd in Section 7.
So, please update the text related, also that in the Table 1, thanks.


Cheers,
Jacni


On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou<tena@huawei.com> =A0wrote:

Hi Dan,
We have emailed all of the authors of the various drafts and ask them to review draft-tsou-multicast-transition-taxonomy.


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http:= //tinatsou.weebly.com/contact.html


-----Original Message-----
From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
Of
Dan Wing
Sent: Wednesday, March 02, 2011 12:20 PM
To: 'Stig Venaas'; 'Tom Taylor'
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for
draft-tsou-multicast-transition-taxonomy-00

-----Original Message-----
From: behave-b= ounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Stig Venaas
Sent: Wednesday, March 02, 2011 11:41 AM
To: Tom Taylor
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
multicast-transition-taxonomy-00

On 3/1/2011 8:00 AM, Tom Taylor wrote:
We have prepared this document to help sort out the multicast
transition
work in the BEHAVE and SOFTWIRES WGs. Please have a look at and
comment
on the conclusions.

A good well written document :)

Agreed.

I would not use the term Multicast Topology for ASM vs SSM. Topology is
more used for network topology... ASM and SSM are generally I think,
referred to as different multicast service models. I would suggest
using
that term.

That is the only change I would suggest in the draft.

Some comments regarding ID.venaas-mcast46 though. It can be used
together with ID.boucadair-64-multicast-address-format, and I plan
to update it with a reference to that. This is maybe obvious though.

Tom, tt would be really valuable if you could email all of the
authors of the various drafts and ask them to review
draft-tsou-multicast-transition-taxonomy, to ensure their documents
are all accurately summarized.

-d

It is correct that it is from 2008. Although not relevant, I feel like
pointing out that the draft is very close to
draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.

Stig

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

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

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



--000e0cd707782474db049dde9487-- From tom111.taylor@bell.net Mon Mar 7 05:12:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FAB03A67B4 for ; Mon, 7 Mar 2011 05:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.539 X-Spam-Level: X-Spam-Status: No, score=-101.539 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 o9Mm4UwzDVvt for ; Mon, 7 Mar 2011 05:12:12 -0800 (PST) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by core3.amsl.com (Postfix) with ESMTP id 80E393A67A8 for ; Mon, 7 Mar 2011 05:12:12 -0800 (PST) Received: from BLU0-SMTP98 ([65.55.116.74]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 05:13:25 -0800 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP98.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 05:13:25 -0800 Date: Mon, 7 Mar 2011 08:13:24 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jacni Qin References: <4D6E9D61.6030402@venaas.com> <0e6e01cbd917$445aaee0$cd100ca0$@com> <034c01cbd921$672f1c80$358d5580$@com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2011 13:13:25.0446 (UTC) FILETIME=[711D1660:01CBDCC9] Cc: Stig Venaas , behave@ietf.org, Dan Wing , Tina Tsou Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 13:12:13 -0000 Noting a restriction on practical deployment is fine, but it is a limit on the applicability of your document. I'm sure there are potential scenarios (e.g., campus environment) where ASM is a practical necessity. On 07/03/2011 1:26 AM, Jacni Qin wrote: > Hi Tom, > > Sorry, I don't follow you point. > > For ASM, we mean "Any-Source Multicast". The statement below is just to > clarify that for example, in practical deployment of the scheme, the broadband > subscribers are not allowed to source the multicast traffic. Other things > like, RP, Source Registration, of ASM are all taken into account. > > > Cheers, > Jacni > From victor.pascual.avila@gmail.com Mon Mar 7 06:30:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CD028C13D for ; Mon, 7 Mar 2011 06:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCreYOFS2p6T for ; Mon, 7 Mar 2011 06:30:12 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8A09D28C139 for ; Mon, 7 Mar 2011 06:30:09 -0800 (PST) Received: by vws6 with SMTP id 6so4370170vws.31 for ; Mon, 07 Mar 2011 06:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ptVM+1DsJgsImoAL8OPr5FaKwc6glxDPjYH3nJRSB8o=; b=VOreGaBB2up49XCwLqXRXwPe2F+8+SAueCQlwfPf90SazRX6P+zFftHMLLILD/2l+y N5+5KpYT9osmroo0pixOZcuCUTXZ9pTMDdu3eNMtBfoP9V1YnVnCnlpT8gUIuVdg2xW7 k7vvMAM9d6htQnfBmeHLU3KwMwuR1rA1LN4K4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=IBXunQqn2H6fl4utUQODJmCTlIoPP0OyOp6kX5/d1c/2ZCCv5jUemhGbTLkuZE3V6g Pjp7/XrxkgJMRhdZ4xTlfa0VO32IdJl7Lg2wEnGJVE8MDf+3N1/jXV1Ez+bgqoqN6paD EyURGnuIBRgM02+kgunHp5wrZ2wiB2P1aR5Es= MIME-Version: 1.0 Received: by 10.220.49.151 with SMTP id v23mr537600vcf.252.1299508281821; Mon, 07 Mar 2011 06:31:21 -0800 (PST) Received: by 10.220.4.195 with HTTP; Mon, 7 Mar 2011 06:31:21 -0800 (PST) Date: Mon, 7 Mar 2011 15:31:21 +0100 Message-ID: From: Victor Pascual Avila To: Behave@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [BEHAVE] Survey on deployed types of residential NAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 14:30:13 -0000 Hi, Please excuse me if this is not the right mailing list to post this message. I'm wondering whether there is any good survey/field test on the deployed types of residential NAT (full cone, restricted cone, etc.). Any suggestion? Many thanks in advance, --=20 Victor Pascual =C3=81vila From xiaohong.deng@orange-ftgroup.com Mon Mar 7 23:32:42 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DB23A690F; Mon, 7 Mar 2011 23:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.743, 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 jpj4tvhdsrRM; Mon, 7 Mar 2011 23:32:41 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 2D7C43A6849; Mon, 7 Mar 2011 23:32:41 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D5E52FC400D; Tue, 8 Mar 2011 08:34:00 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id CC4E9FC4001; Tue, 8 Mar 2011 08:34:00 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 08:33:54 +0100 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, 8 Mar 2011 15:33:50 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC015B62CF@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-deng-aplusp-experiment-results-00 Thread-Index: Acvc7WLnStoq5r2JRWanmqgET185ogAdJc+A From: To: , X-OriginalArrivalTime: 08 Mar 2011 07:33:54.0596 (UTC) FILETIME=[2D8DCE40:01CBDD63] Subject: [BEHAVE] FW: New Version Notification for draft-deng-aplusp-experiment-results-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 07:32:42 -0000 A new version of I-D, draft-deng-aplusp-experiment-results-00.txt has been successfully submitted by Xiaohong Deng and posted to the IETF repository. Filename: draft-deng-aplusp-experiment-results Revision: 00 Title: Implementing A+P in the provider's IPv6-only network Creation_date: 2011-03-08 WG ID: Independent Submission Number_of_pages: 15 Abstract: This memo describes an implementation of A+P in the provider's IPv6- only network. It provides an overview of the implementation=20 environment which consists of network elements and configurations,=20 and the results of the application compatibility test to verify the=20 feasibility of deploying A+P in the IPv6-only network and to assess=20 the impacts on services and also the viability of A+P proposed=20 approach. =20 This memo focuses on the IPv6 flavor of A+P. =20 A URL for this Internet-Draft is: http://tools.ietf.org/html/draft-deng-aplusp-experiment-results-00. The IETF Secretariat. From Internet-Drafts@ietf.org Fri Mar 11 02:30:06 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700EE3A6893; Fri, 11 Mar 2011 02:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 5UcF4TmueRuu; Fri, 11 Mar 2011 02:30:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FCAD3A68AA; Fri, 11 Mar 2011 02:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110311103002.23659.77481.idtracker@localhost> Date: Fri, 11 Mar 2011 02:30:02 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-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: Fri, 11 Mar 2011 10:30:06 -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 : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Author(s) : B. Huang, et al. Filename : draft-ietf-behave-v4v6-bih-03.txt Pages : 26 Date : 2011-03-11 Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-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-v4v6-bih-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-11022951.I-D@ietf.org> --NextPart-- From xing@cernet.edu.cn Sun Mar 13 06:52:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B8A3A68EF for ; Sun, 13 Mar 2011 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.403 X-Spam-Level: X-Spam-Status: No, score=-99.403 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 Rb6+i3m+PrJ0 for ; Sun, 13 Mar 2011 06:52:42 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id A879A3A681A for ; Sun, 13 Mar 2011 06:52:41 -0700 (PDT) Received: from [127.0.0.1]([125.34.44.154]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4d7d0dc0; Sun, 13 Mar 2011 21:54:02 +0800 Message-ID: <4D7CCC62.1050500@cernet.edu.cn> Date: Sun, 13 Mar 2011 21:53:38 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.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: 7TKklyZB Cc: behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 13:52:43 -0000 Hi, Rajiv, 于 2011/3/13 13:39, Rajiv Asati (rajiva) 写道: > draft-xli-behave-ivi-07 seems to have an error in section 3.3 > (Network-layer Header Translation), in which the default behavior of > IPv4 ToS = IPv6 TC (specified in SIIT (RFC2765)) is being ignored. > > Section 3.3 suggests the v4-v6 translation must follow SIIT (except src > & dest addresses conversion), but discards the TC and ToS values. > > Perhaps, this is an editorial error that can be easily fixed right away. Thanks. We will make modifications during AUTH48. ------------------------------------------------------------- IPv4 Field Translated to IPv6 ------------------------------------------------------------- Version (0x4) Version (0x6) IHL discarded Type of Service copied from IP Type Of Service and Precedence field Total Length Payload Length = Total Length - 20 Identification discarded Flags discarded Offset discarded Time to Live Hop Limit Protocol Next Header Header Checksum discarded Source Address IVI address mapping Destination Address IVI address mapping Options discarded ------------------------------------------------------------- Figure 6: IPv4 to IPv6 Header translation ------------------------------------------------------------- IPv6 Field Translated to IPv4 Header ------------------------------------------------------------- Version (0x6) Version (0x4) Traffic Class copied from the IPv6 Traffic Class Flow Label discarded Payload Length Total Length = Payload Length + 20 Next Header Protocol Hop Limit TTL Source Address IVI address mapping Destination Address IVI address mapping - IHL = 5 - Header Checksum recalculated ------------------------------------------------------------- Figure 7: IPv6 to IPv4 Header translation Regards, xing > > Cheers, > Rajiv > > > > From xing@cernet.edu.cn Sun Mar 13 06:56:41 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE2D3A68F0 for ; Sun, 13 Mar 2011 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.653 X-Spam-Level: X-Spam-Status: No, score=-99.653 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 O9ocJe0J23jK for ; Sun, 13 Mar 2011 06:56:41 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id 091FE3A6835 for ; Sun, 13 Mar 2011 06:56:39 -0700 (PDT) Received: from [127.0.0.1]([125.34.44.154]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4d7d0eaf; Sun, 13 Mar 2011 21:58:00 +0800 Message-ID: <4D7CCD65.7070504@cernet.edu.cn> Date: Sun, 13 Mar 2011 21:57:57 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 7bAolyZB Cc: behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 13:56:41 -0000 Another typing error in the previous mail. It should be ------------------------------------------------------------- IPv4 Field Translated to IPv6 ------------------------------------------------------------- Version (0x4) Version (0x6) IHL discarded Type of Service copied from the IPv6 Traffic Class Total Length Payload Length = Total Length - 20 Identification discarded Flags discarded Offset discarded Time to Live Hop Limit Protocol Next Header Header Checksum discarded Source Address IVI address mapping Destination Address IVI address mapping Options discarded ------------------------------------------------------------- Figure 6: IPv4 to IPv6 Header translation ------------------------------------------------------------- IPv6 Field Translated to IPv4 Header ------------------------------------------------------------- Version (0x6) Version (0x4) Traffic Class copied from IP Type Of Service and Precedence field Flow Label discarded Payload Length Total Length = Payload Length + 20 Next Header Protocol Hop Limit TTL Source Address IVI address mapping Destination Address IVI address mapping - IHL = 5 - Header Checksum recalculated ------------------------------------------------------------- Figure 7: IPv6 to IPv4 Header translation Regards, xing From brian.e.carpenter@gmail.com Sun Mar 13 13:44:05 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D883A6B08 for ; Sun, 13 Mar 2011 13:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 wKuf3cGGekM5 for ; Sun, 13 Mar 2011 13:44:02 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id F3B8C3A6A51 for ; Sun, 13 Mar 2011 13:44:01 -0700 (PDT) Received: by gwb20 with SMTP id 20so2072538gwb.31 for ; Sun, 13 Mar 2011 13:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FUh1dEeNIeCpL3upH0XJD1DMk7FJWivrI4WxoYBLNlw=; b=TdsVHnuwTJJ65OzSnFXJPCuu4NZ59UjulanGylHgGZsMV20Ht4JsWigkNqX6BPq6hK wuQC9peEZgsE/sBUho1iYk7+G9ds9OjPNK6pDxlU82mfSgP+iGDIw7xukHJ+BKrLI5ve Mcu8rJHTBmohCeG8jNJzofEYXEY/TV/FnmAQs= 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=gMJbh9EMDerTBW8vCeF1ZhB5H6PlWU4VLDVq/sULecHl0OXPCi9l6POzDkp2rpTaO5 yScN4JJO+s4ov6O8ikOcuyoEPSzBf+kdX9bJaf6vsRWFQxeCgZZF3LaGb0ISCr66gyYr yjw2K2rZXOc+us1DWHz+XbMYhU7KDbiigqjSE= Received: by 10.150.63.17 with SMTP id l17mr5264269yba.187.1300049123605; Sun, 13 Mar 2011 13:45:23 -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 t12sm1493531ybe.0.2011.03.13.13.45.20 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 13:45:22 -0700 (PDT) Message-ID: <4D7D2CDE.8070600@gmail.com> Date: Mon, 14 Mar 2011 09:45:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xing Li References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> <4D7CCD65.7070504@cernet.edu.cn> In-Reply-To: <4D7CCD65.7070504@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Xing Li , behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 20:44:05 -0000 Just to be clear - you are copying 8 bits, including ECN? Brian On 2011-03-14 02:57, Xing Li wrote: > Another typing error in the previous mail. It should be > > ------------------------------------------------------------- > IPv4 Field Translated to IPv6 > ------------------------------------------------------------- > Version (0x4) Version (0x6) > IHL discarded > Type of Service copied from the IPv6 Traffic Class > Total Length Payload Length = Total Length - 20 > Identification discarded > Flags discarded > Offset discarded > Time to Live Hop Limit > Protocol Next Header > Header Checksum discarded > Source Address IVI address mapping > Destination Address IVI address mapping > Options discarded > ------------------------------------------------------------- > > Figure 6: IPv4 to IPv6 Header translation > > > ------------------------------------------------------------- > IPv6 Field Translated to IPv4 Header > ------------------------------------------------------------- > Version (0x6) Version (0x4) > Traffic Class copied from IP Type Of Service and Precedence field > Flow Label discarded > Payload Length Total Length = Payload Length + 20 > Next Header Protocol > Hop Limit TTL > Source Address IVI address mapping > Destination Address IVI address mapping > - IHL = 5 > - Header Checksum recalculated > ------------------------------------------------------------- > > Figure 7: IPv6 to IPv4 Header translation > > Regards, > > xing > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xing@cernet.edu.cn Sun Mar 13 16:20:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D603A690A for ; Sun, 13 Mar 2011 16:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.736 X-Spam-Level: X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 878R7jM6c9+b for ; Sun, 13 Mar 2011 16:20:37 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id 51CAB3A68AB for ; Sun, 13 Mar 2011 16:20:37 -0700 (PDT) Received: from [127.0.0.1]([125.34.46.150]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104d7d92d0; Mon, 14 Mar 2011 07:21:45 +0800 Message-ID: <4D7D517D.20200@cernet.edu.cn> Date: Mon, 14 Mar 2011 07:21:33 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian E Carpenter References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> <4D7CCD65.7070504@cernet.edu.cn> <4D7D2CDE.8070600@gmail.com> In-Reply-To: <4D7D2CDE.8070600@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: 7p9buyZB Cc: "Rajiv Asati \(rajiva\)" , behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 23:20:38 -0000 于 2011/3/14 4:45, Brian E Carpenter 写道: > Just to be clear - you are copying 8 bits, including ECN? Yes, as in RFC2765 Traffic Class: By default, copied from IP Type Of Service and Precedence field (all 8 bits are copied). According to [DIFFSERV] the semantics of the bits are identical in IPv4 and IPv6. However, in some IPv4 environments these fields might be used with the old semantics of "Type Of Service and Precedence". An implementation of a translator SHOULD provide the ability to ignore the IPv4 "TOS" and always set the IPv6 traffic class to zero. Regards, xing > Brian > > On 2011-03-14 02:57, Xing Li wrote: >> Another typing error in the previous mail. It should be >> >> ------------------------------------------------------------- >> IPv4 Field Translated to IPv6 >> ------------------------------------------------------------- >> Version (0x4) Version (0x6) >> IHL discarded >> Type of Service copied from the IPv6 Traffic Class >> Total Length Payload Length = Total Length - 20 >> Identification discarded >> Flags discarded >> Offset discarded >> Time to Live Hop Limit >> Protocol Next Header >> Header Checksum discarded >> Source Address IVI address mapping >> Destination Address IVI address mapping >> Options discarded >> ------------------------------------------------------------- >> >> Figure 6: IPv4 to IPv6 Header translation >> >> >> ------------------------------------------------------------- >> IPv6 Field Translated to IPv4 Header >> ------------------------------------------------------------- >> Version (0x6) Version (0x4) >> Traffic Class copied from IP Type Of Service and Precedence field >> Flow Label discarded >> Payload Length Total Length = Payload Length + 20 >> Next Header Protocol >> Hop Limit TTL >> Source Address IVI address mapping >> Destination Address IVI address mapping >> - IHL = 5 >> - Header Checksum recalculated >> ------------------------------------------------------------- >> >> Figure 7: IPv6 to IPv4 Header translation >> >> Regards, >> >> xing >> >> _______________________________________________ >> 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 xing@cernet.edu.cn Sun Mar 13 16:20:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DD13A6A49 for ; Sun, 13 Mar 2011 16:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.778 X-Spam-Level: X-Spam-Status: No, score=-99.778 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, 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 OqBZP2pv17Jx for ; Sun, 13 Mar 2011 16:20:52 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by core3.amsl.com (Postfix) with SMTP id 1DF0C3A6A3C for ; Sun, 13 Mar 2011 16:20:51 -0700 (PDT) Received: from [127.0.0.1]([125.34.46.150]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm3e4d7d92ec; Mon, 14 Mar 2011 07:22:14 +0800 Message-ID: <4D7D51A5.2060807@cernet.edu.cn> Date: Mon, 14 Mar 2011 07:22:13 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> <4D7CCD65.7070504@cernet.edu.cn> <067E6CE33034954AAC05C9EC85E2577C046336E8@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C046336E8@XMB-RCD-111.cisco.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: 7qCcuyZB Cc: behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 23:20:54 -0000 于 2011/3/14 6:03, Rajiv Asati (rajiva) 写道: >> Traffic Class copied from IP Type Of Service and Precedence field > Why not just say - Traffic Class copied from IP Type Of Service field. > > Precedence is part of ToS field anyway. Noted. Regards, xing > Cheers, > Rajiv > > ~~~ > June 8, 2011 is the "World IPv6 Day" (http://isoc.org/wp/worldipv6day/) > > > >> -----Original Message----- >> From: Xing Li [mailto:xing@cernet.edu.cn] >> Sent: Sunday, March 13, 2011 9:58 AM >> To: Rajiv Asati (rajiva) >> Cc: draft-xli-behave-ivi@tools.ietf.org; behave@ietf.org; Xing Li >> Subject: Re: draft-xli-behave-ivi -- Error per SIIT ! >> >> Another typing error in the previous mail. It should be >> >> ------------------------------------------------------------- >> IPv4 Field Translated to IPv6 >> ------------------------------------------------------------- >> Version (0x4) Version (0x6) >> IHL discarded >> Type of Service copied from the IPv6 Traffic Class >> Total Length Payload Length = Total Length - 20 >> Identification discarded >> Flags discarded >> Offset discarded >> Time to Live Hop Limit >> Protocol Next Header >> Header Checksum discarded >> Source Address IVI address mapping >> Destination Address IVI address mapping >> Options discarded >> ------------------------------------------------------------- >> >> Figure 6: IPv4 to IPv6 Header translation >> >> >> ------------------------------------------------------------- >> IPv6 Field Translated to IPv4 Header >> ------------------------------------------------------------- >> Version (0x6) Version (0x4) >> Traffic Class copied from IP Type Of Service and Precedence field >> Flow Label discarded >> Payload Length Total Length = Payload Length + 20 >> Next Header Protocol >> Hop Limit TTL >> Source Address IVI address mapping >> Destination Address IVI address mapping >> - IHL = 5 >> - Header Checksum recalculated >> ------------------------------------------------------------- >> >> Figure 7: IPv6 to IPv4 Header translation >> >> Regards, >> >> xing > From melnikovkolya@gmail.com Mon Mar 14 05:20:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156253A69C1 for ; Mon, 14 Mar 2011 05:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKgNe386pCem for ; Mon, 14 Mar 2011 05:20:03 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 73B8C3A6994 for ; Mon, 14 Mar 2011 05:20:02 -0700 (PDT) Received: by qyk7 with SMTP id 7so3976735qyk.10 for ; Mon, 14 Mar 2011 05:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:from:date:message-id :subject:to:cc:content-type; bh=afn6yZdcRPDGNiSKdj9HMs9Nm2paed6RojeDpIcC4Fo=; b=I74w8LbU5eDIJup15NIu7EgdkQ8OIddk0hCE6hnXSt9KGS0Wgo4HlMMcZ1ETB4Q442 o0wbcxfQL4tF0/qWZtl/d9P4PZCVSAx0PA39Idb1hkTWHH8lomacsOgi3crO4kbMfjsQ bRO21lwaVWN4Rtl/sLWaGSRF+onwztElTWNBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:cc :content-type; b=D3M7vlypQRVomYY7JJTicVxPjo87dr9U8t92Z7QSk2CML0K7S+ZOmWJ8S40HXQ3CLa 6qdophZc14CMuPdqzJu5PQ0w3pyGPxvM4BgI+Skv07oydSyxpgSfWmLv2Pi2jy94HV5c 73RBzePEIbivZvU6TTj1imahaX4xDOPbAhyJ8= Received: by 10.229.29.129 with SMTP id q1mr9732698qcc.295.1300105284098; Mon, 14 Mar 2011 05:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.201 with HTTP; Mon, 14 Mar 2011 05:21:04 -0700 (PDT) From: Nikolay Melnikov Date: Mon, 14 Mar 2011 13:21:04 +0100 Message-ID: To: draft-ietf-behave-lsn-requirements@tools.ietf.org Content-Type: multipart/alternative; boundary=001636833ecca11cf4049e7059a6 Cc: behave@ietf.org Subject: [BEHAVE] draft-ietf-behave-lsn-requirements-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: melnikovkolya@gmail.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 12:20:04 -0000 --001636833ecca11cf4049e7059a6 Content-Type: text/plain; charset=ISO-8859-1 Hello everyone, I bumped into several statements and (what I consider to be) typos at my initial read of the document, so I decided not to postpone and report them. "Each LSN occupies combination of LSN external IP address, LSN external port and LSN external identifier exclusively." It is not clear what "occupies" means in this case. Along with "exclusively". Does it mean that each LSN forms a unique combination of an external IP address, port and identifier? REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE ports of UDP. "which are mapped to". Same in REQ-3 and REQ-4 REQ-5: A LSN MAY have implementations that some specific applications can work well even if each CPE's usable number of LSN external ports ha already consumed. In general, in requirements REQ-1 through REQ-5 "An LSN" combination should be used as LSN abbreviation starts with a vowel-sounding "L" possibility among CPEs which have LSN. a)It is RECOMMENDED that a NAT "Endpoint-Independent Filtering" behaviour. nik -- Nikolay Melnikov School of Engineering and Science Jacobs University Bremen --001636833ecca11cf4049e7059a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
He=
llo everyone,

I bumped into several statements and (what I consider =
to be) typos at my initial read of the document, so I decided not to postpo=
ne and report them. 





   "Each LSN occupies combination of L=
SN external IP address, LSN external port and LSN external identifier exclu=
sively."

It is not clear what "occupies" means in this case. Along with &q=
uot;exclusively". Does it mean that each LSN forms a unique combinatio=
n of an
 external IP address, port and identifier?




   REQ-2: A LSN MUST allocate LSN external ports which is mapped for CP=
E
   ports of UDP.

"which are mapped to". Same in REQ-3 and RE=
Q-4







   REQ-5: A LSN MAY have implementations that some specific app=
lications
   can work well <with,> even if each CPE's usable number of LSN external ports
   ha<s> already <been> consumed.






In general, in requirements REQ-1 through REQ-5 "An LSN" c=
ombination should be used as LSN abbreviation starts with a vowel-sounding =
"L"






   possibility among CPEs which <don's =
t> have LSN.




   a)It is RECOMMENDED that a NAT=
 <has an><have> "Endpoint-Independ=
ent


      Filtering" behaviour.


n= ik
--
Nikolay Melnikov
School of Engineering and Science
Jacobs University Bremen

<http= ://www.jacobs-university.de/>
--001636833ecca11cf4049e7059a6-- From melnikovkolya@gmail.com Mon Mar 14 05:21:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1C33A6906 for ; Mon, 14 Mar 2011 05:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zkujxl1M8DQ for ; Mon, 14 Mar 2011 05:21:12 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id A0D713A6928 for ; Mon, 14 Mar 2011 05:21:12 -0700 (PDT) Received: by qwg5 with SMTP id 5so1513983qwg.31 for ; Mon, 14 Mar 2011 05:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:from:date:message-id :subject:to:cc:content-type; bh=86N2DlZ9WGuzWLDrKB3ez7tTnXaaA/O8tzL/p+wysdA=; b=Weu14P//GHQUIpdP5i3PmG5bJbeHZ+9EzWDVA4KGjE0LXRjyD9smf0vlDIlnbbfUq7 9TmoaYuUNEP88CfhwDdT5k+SdA9DMvU5hbM8evwQkIhr02U39BP9Xk9Ft6Z2YIZhNwjh lQV0K5ddRPg5A1/8nhm5227fMX1MweyggVP14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:cc :content-type; b=IJ4A8R4IOMwI0g8E1dYFyL8vMn5aX9yxVzPb96vCFNwrp9TbWwNrLwQ5K85/grW8zi aQPFkxUxB2NHkCBs7cWIHcbx4f5R3RfPeB+vJFkgMQyUwJgAg77QZulW4p4Hn7VMYVQ1 4yIShM9Jisrq7zcAIYKo360fD4yCyjjJWaioM= Received: by 10.229.10.12 with SMTP id n12mr1086627qcn.219.1300105355115; Mon, 14 Mar 2011 05:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.201 with HTTP; Mon, 14 Mar 2011 05:22:15 -0700 (PDT) From: Nikolay Melnikov Date: Mon, 14 Mar 2011 13:22:15 +0100 Message-ID: To: draft-ietf-behave-sctpnat@tools.ietf.org Content-Type: multipart/alternative; boundary=0016360e3da0dcbd45049e705d5f Cc: behave@ietf.org Subject: [BEHAVE] draft-ietf-behave-sctpnat-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: melnikovkolya@gmail.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 12:21:14 -0000 --0016360e3da0dcbd45049e705d5f Content-Type: text/plain; charset=ISO-8859-1 Hello everyone, I bumped into several statements and (what I consider to be) typos at my initial read of the document, so I decided not to postpone and report them. 5. Limitations of classical NAPT for SCTP This would add considerable (?overhead?) to the NAT computational burden, however hardware support may mitigate this in some implementations. 6. The SCTP specific variant of NAT It is also possible that a connection to External-Address and External-Port exists without an Internal-VTag 7. Nat to SCTP This document at various places discusses the sending of specialized SCTP chunks (e.g. an ABORT with set). " 9. Simplification for small NATs Small NAT boxes, i.e. NAT boxes which only have to support a small number of concurrent SCTP associations, MAY not take the external address into account when processing packets. Therefore the External-Address could also be removed from the NAT table. This simplification may make implementing a NAT box easier, however, the collision probability is higher than using a mapping which takes the external address into account. " Is the risk of higher collision probability worth "implementation simplification"? Does it make sense to have this section at all? Shouldn't the multi-homed "server-side" of figures in 10.3 look as follows (to comply with figure in 10.2): +-------+ +--------+ /-| NAT 1 |-\ /--\/--\ /-|Router 1|-\ +------+ / +-------+ \ / \ / +--------+ \ +--------+ | Host |=== ===| Internet |== ==| Host B | | A | \ +-------+ / \ / \ +--------+ / +--------+ +------+ \-| NAT 2 |-/ \--/\--/ \-|Router 2|-/ +-------+ +--------+ 10.5 Host A send INIT-ACK, which can pass through NAT B: Question: From the example in 10.5, the INIT packet from host A creates an entry in NAT A, but is discarded at NAT B. What follows, is an INIT packet from host B, which creates an appropriate entry in NAT B. It is mentioned that the rendezvous points are involved in this case, could you please explain to me how? Does host B send an INIT packet a hint from that rendezvous point? nik -- Nikolay Melnikov School of Engineering and Science Jacobs University Bremen --0016360e3da0dcbd45049e705d5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
He=
llo everyone,

I bumped into several statements and (what I consider =
to be) typos at my initial read of the document, so I decided not to postpo=
ne and report them. 





5.  Limitations of classical NAPT for SCTP

    =
This would add considerable (?overhead?) to the NAT computational burden, h=
owever hardware support may mitigate this in some implementations.





6.  The SCTP specific variant of NAT

     It is also possible that a connection to External-Address a=
nd External-Port exists without an<space missing>
Internal-VTag





7.  Nat to SCTP
   
   This document at v=
arious places discusses the sending of specialized
   SCTP chunks (e.g. =
an ABORT with <inconsistent throughout the document, should be: M-Bit>=
;<M bit> set).

"
9. Simplification for small NATs
   Small NAT boxes, i.e.  NAT boxes which only have to support a small=

   number of concurrent SCTP associations, MAY not take the external   address into account when processing packets.  Therefore the
   Exte=
rnal-Address could also be removed from the NAT table.



   This simplification may make implementing a NAT box easier, however,=

   the collision probability is higher than using a mapping which takes=

   the external address into account.
"
Is the risk of= higher collision probability worth "implementation simplification&quo= t;? Does it make sense to have this section at all?



Shouldn't the multi-homed "server-side" of figure= s in 10.3 look as follows (to comply with figure in 10.2):


=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------+=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--------+
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 /-| NAT 1 |-\=A0=A0=A0=A0=A0 /--\/--\=A0=A0=A0= =A0=A0 /-|Router 1|-\
=A0+------+=A0=A0=A0 /=A0 +-------+=A0 \=A0=A0=A0 /=A0=A0=A0=A0=A0=A0=A0 \= =A0=A0=A0 /=A0 +--------+=A0 \ +--------+=A0
=A0| Host |=3D=3D=3D=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=3D=3D| Internet |=3D=3D=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=3D| Host B |
=A0|=A0=A0 A=A0= |=A0=A0=A0 \=A0 +-------+=A0 /=A0=A0=A0 \=A0=A0=A0=A0=A0=A0=A0 /=A0=A0=A0 = \=A0 +--------+=A0 / +--------+
=A0+------+=A0=A0=A0=A0 \-| NAT 2 |-/=A0=A0=A0=A0=A0 \--/\--/=A0=A0=A0=A0= =A0 \-|Router 2|-/=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--= -----+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= +--------+


10.5 
Host A send<s> INIT-ACK, which c=
an pass through NAT B:


Question: From the example in 10.5, the INIT packet from host A creates=20 an entry in NAT A, but is discarded at NAT B. What follows, is an INIT=20 packet from host B, which creates an appropriate entry in NAT B. It is=20 mentioned that the rendezvous points are involved in this case, could=20 you please explain to me how? Does host B send an INIT packet=A0 a hint=20 from that rendezvous point?


nik
--
Nikolay Melnikov
School of Engineering and Science=
Jacobs University Bremen

<http://www.jacobs-university.de/>
--0016360e3da0dcbd45049e705d5f-- From Internet-Drafts@ietf.org Mon Mar 14 08:30:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2364B3A6D8A; Mon, 14 Mar 2011 08:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 h7uDOGKsTT+1; Mon, 14 Mar 2011 08:30:10 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7939F3A6D48; Mon, 14 Mar 2011 08:30:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314153007.29808.57662.idtracker@localhost> Date: Mon, 14 Mar 2011 08:30:07 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-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: Mon, 14 Mar 2011 15:30:17 -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 : Common requirements for IP address sharing schemes Author(s) : S. Perreault, et al. Filename : draft-ietf-behave-lsn-requirements-01.txt Pages : 11 Date : 2011-03-14 This document defines common requirements for Carrier-Grade NAT (CGN) devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-lsn-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14082201.I-D@ietf.org> --NextPart-- From simon.perreault@viagenie.ca Mon Mar 14 08:33:59 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890D63A6B32 for ; Mon, 14 Mar 2011 08:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKxwNUAX+rTy for ; Mon, 14 Mar 2011 08:33:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 06CEF3A6D63 for ; Mon, 14 Mar 2011 08:33:53 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CCB8920D0B; Mon, 14 Mar 2011 11:35:15 -0400 (EDT) Message-ID: <4D7E35B3.5090907@viagenie.ca> Date: Mon, 14 Mar 2011 11:35:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: melnikovkolya@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-lsn-requirements-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 15:33:59 -0000 I think all these have been fixed in the -01 revision that was posted a few minutes ago... Thanks, Simon On 2011-03-14 08:21, Nikolay Melnikov wrote: > Hello everyone, > > I bumped into several statements and (what I consider to be) typos at my initial read of the document, so I decided not to postpone and report them. > > > > > > "Each LSN occupies combination of LSN external IP address, LSN external port and LSN external identifier exclusively." > > It is not clear what "occupies" means in this case. Along with "exclusively". Does it mean that each LSN forms a unique combination of an > external IP address, port and identifier? > > > > > REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE > ports of UDP. > > "which are mapped to". Same in REQ-3 and REQ-4 > > > > > > > > REQ-5: A LSN MAY have implementations that some specific applications > can work well even if each CPE's usable number of LSN external ports > ha already consumed. > > > > > > > In general, in requirements REQ-1 through REQ-5 "An LSN" combination should be used as LSN abbreviation starts with a vowel-sounding "L" > > > > > > > possibility among CPEs which have LSN. > > > > > a)It is RECOMMENDED that a NAT "Endpoint-Independent > > > Filtering" behaviour. > > > nik > -- > Nikolay Melnikov > School of Engineering and Science > Jacobs University Bremen > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rajiva@cisco.com Sat Mar 12 21:38:35 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354A93A6AE6 for ; Sat, 12 Mar 2011 21:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFI1CyZ6W582 for ; Sat, 12 Mar 2011 21:38:34 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4866E3A6A99 for ; Sat, 12 Mar 2011 21:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=448; q=dns/txt; s=iport; t=1299994796; x=1301204396; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=MZyUfco7d4X1y4SNNkozBSb05q0VGvP6J7Q2T3e5OvM=; b=Jm2nJXSCcGNNYorfeW55RbLwxWYL0PE4aY7jVejIyT7AB7QgqI+Bph2O Rt0zuh/tDlBDLrRk/4x6Q/J3+w6YZKkKPoqiELkD+rFSpS1wzEskn3utA Gsa3jzDkK5vgN7Ev7F+d5ZZ53neOEJnYRVOPE4Rce1tn3WgSnO8SluLQk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGALrne02tJV2Z/2dsb2JhbACZNo0Od6RYmm2FYgSFK4p7 X-IronPort-AV: E=Sophos;i="4.62,309,1297036800"; d="scan'208";a="275507247" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-4.cisco.com with ESMTP; 13 Mar 2011 05:39:55 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2D5dtZX003496; Sun, 13 Mar 2011 05:39:55 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Mar 2011 23:39:55 -0600 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: Sat, 12 Mar 2011 23:39:54 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-xli-behave-ivi -- Error per SIIT ! Thread-Index: AcvhQRS6z/+/Nv5/TTCV6sm5hivjgA== From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 13 Mar 2011 05:39:55.0994 (UTC) FILETIME=[157EB3A0:01CBE141] X-Mailman-Approved-At: Mon, 14 Mar 2011 09:09:17 -0700 Cc: behave@ietf.org, "Rajiv Asati \(rajiva\)" Subject: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 05:38:35 -0000 draft-xli-behave-ivi-07 seems to have an error in section 3.3 (Network-layer Header Translation), in which the default behavior of IPv4 ToS =3D IPv6 TC (specified in SIIT (RFC2765)) is being ignored. Section 3.3 suggests the v4-v6 translation must follow SIIT (except src & dest addresses conversion), but discards the TC and ToS values. Perhaps, this is an editorial error that can be easily fixed right away. Cheers, Rajiv =20 From rajiva@cisco.com Sun Mar 13 15:01:50 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494B93A6BDF for ; Sun, 13 Mar 2011 15:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaN2fIXB-ACE for ; Sun, 13 Mar 2011 15:01:49 -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 2F32E3A6BDB for ; Sun, 13 Mar 2011 15:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1992; q=dns/txt; s=iport; t=1300053792; x=1301263392; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=X+T9u5wPSHj15vScAm9ci+81u9t26dsb5yhnGc0rVRw=; b=KSVMv2OIWYVVNMXK0LH0Wrr3PGg9a8MOctJ/WERF0x8t9Os4KXFJDTOR /sessnny/+FDkQDkVutim5/dP+oxr1eTzcRFCXSCjst22UhUFKbWkkQqV OmNxocxDcmmMOjyDjGTgxrhHGyW/OpsbpgOV5yeg0zIr8QYnlv/1Wb5J1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAPTbfE2tJXG//2dsb2JhbACYRo1Qd6URmmqFYgSFK4p7iGs X-IronPort-AV: E=Sophos;i="4.62,312,1297036800"; d="scan'208";a="345543048" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2011 22:03:11 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2DM3BjW003692; Sun, 13 Mar 2011 22:03:11 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 17:03:11 -0500 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: Sun, 13 Mar 2011 17:03:10 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C046336E8@XMB-RCD-111.cisco.com> In-Reply-To: <4D7CCD65.7070504@cernet.edu.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-xli-behave-ivi -- Error per SIIT ! Thread-Index: AcvhhrNId0D47cebSNKepYv4gT3JBwAQ5uhQ References: <067E6CE33034954AAC05C9EC85E2577C0463368C@XMB-RCD-111.cisco.com> <4D7CCD65.7070504@cernet.edu.cn> From: "Rajiv Asati (rajiva)" To: "Xing Li" X-OriginalArrivalTime: 13 Mar 2011 22:03:11.0550 (UTC) FILETIME=[719625E0:01CBE1CA] X-Mailman-Approved-At: Mon, 14 Mar 2011 09:09:28 -0700 Cc: behave@ietf.org, draft-xli-behave-ivi@tools.ietf.org, Xing Li Subject: Re: [BEHAVE] draft-xli-behave-ivi -- Error per SIIT ! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 22:01:50 -0000 > Traffic Class copied from IP Type Of Service and Precedence field Why not just say - Traffic Class copied from IP Type Of Service field. Precedence is part of ToS field anyway. Cheers, Rajiv ~~~ June 8, 2011 is the "World IPv6 Day" (http://isoc.org/wp/worldipv6day/) > -----Original Message----- > From: Xing Li [mailto:xing@cernet.edu.cn] > Sent: Sunday, March 13, 2011 9:58 AM > To: Rajiv Asati (rajiva) > Cc: draft-xli-behave-ivi@tools.ietf.org; behave@ietf.org; Xing Li > Subject: Re: draft-xli-behave-ivi -- Error per SIIT ! >=20 > Another typing error in the previous mail. It should be >=20 > ------------------------------------------------------------- > IPv4 Field Translated to IPv6 > ------------------------------------------------------------- > Version (0x4) Version (0x6) > IHL discarded > Type of Service copied from the IPv6 Traffic Class > Total Length Payload Length =3D Total Length - 20 > Identification discarded > Flags discarded > Offset discarded > Time to Live Hop Limit > Protocol Next Header > Header Checksum discarded > Source Address IVI address mapping > Destination Address IVI address mapping > Options discarded > ------------------------------------------------------------- >=20 > Figure 6: IPv4 to IPv6 Header translation >=20 >=20 > ------------------------------------------------------------- > IPv6 Field Translated to IPv4 Header > ------------------------------------------------------------- > Version (0x6) Version (0x4) > Traffic Class copied from IP Type Of Service and Precedence field > Flow Label discarded > Payload Length Total Length =3D Payload Length + 20 > Next Header Protocol > Hop Limit TTL > Source Address IVI address mapping > Destination Address IVI address mapping > - IHL =3D 5 > - Header Checksum recalculated > ------------------------------------------------------------- >=20 > Figure 7: IPv6 to IPv4 Header translation >=20 > Regards, >=20 > xing From simon.perreault@viagenie.ca Mon Mar 14 09:17:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147603A6957 for ; Mon, 14 Mar 2011 09:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 aCOarhF+ihiU for ; Mon, 14 Mar 2011 09:17:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B75793A696C for ; Mon, 14 Mar 2011 09:17:56 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BF88220D0B for ; Mon, 14 Mar 2011 12:19:19 -0400 (EDT) Message-ID: <4D7E4007.1020004@viagenie.ca> Date: Mon, 14 Mar 2011 12:19:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <20110314153007.29808.57662.idtracker@localhost> In-Reply-To: <20110314153007.29808.57662.idtracker@localhost> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-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: Mon, 14 Mar 2011 16:17:58 -0000 This version has changed heavily. The primary goal was to make it clear which requirements are new and which ones are re-statements of existing ones. Here's the change log: o Terminology: LSN is now CGN. o Imported all requirements from RFCs 4787, 5382, and 5508. This allowed us to eliminate some duplication. o Added references to draft-ietf-intarea-server-logging-recommendations and draft-ford-shared-addressing-issues. o Incorporated a requirement from draft-xu-behave-stateful-nat-standby-06. Simon On 2011-03-14 11:30, 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 : Common requirements for IP address sharing schemes > Author(s) : S. Perreault, et al. > Filename : draft-ietf-behave-lsn-requirements-01.txt > Pages : 11 > Date : 2011-03-14 > > This document defines common requirements for Carrier-Grade NAT (CGN) > devices. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom111.taylor@bell.net Mon Mar 14 14:29:53 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBE83A6BAC; Mon, 14 Mar 2011 14:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.404 X-Spam-Level: X-Spam-Status: No, score=-101.404 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 tYENQVxvmRrZ; Mon, 14 Mar 2011 14:29:52 -0700 (PDT) Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by core3.amsl.com (Postfix) with ESMTP id 163423A6826; Mon, 14 Mar 2011 14:29:52 -0700 (PDT) Received: from BLU0-SMTP25 ([65.55.116.74]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 14:31:16 -0700 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP25.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 14:31:15 -0700 Date: Mon, 14 Mar 2011 17:31:16 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "behave@ietf.org" , Softwires Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2011 21:31:15.0815 (UTC) FILETIME=[2621EF70:01CBE28F] Subject: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:29:53 -0000 Added four more drafts to the summary. -------- Original Message -------- Subject: New Version Notification for draft-tsou-multicast-transition-taxonomy-01 Date: Mon, 14 Mar 2011 14:18:19 -0700 (PDT) From: IETF I-D Submission Tool To: tom111.taylor@bell.net CC: tena@huawei.com,cathyzhou@huawei.com A new version of I-D, draft-tsou-multicast-transition-taxonomy-01.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-multicast-transition-taxonomy Revision: 01 Title: A Classification and Evaluation of Approaches to Transitional Multicast Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 14 Abstract: A number of different contributions to the IETF make proposals in support of multicast during the transition from IPv4 to IPv6. This document provides a taxonomic framework to make it easier to see how the different proposals relate to each other. It analyzes the current work in progress in the light of this framework and draws a number of conclusions regarding how this work should move forward in the BEHAVE and SOFTWIRES Working Groups. The IETF Secretariat. From phdgang@gmail.com Mon Mar 14 19:48:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A073A6A80; Mon, 14 Mar 2011 19:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CucT2tHak6M0; Mon, 14 Mar 2011 19:48:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C59273A6973; Mon, 14 Mar 2011 19:48:36 -0700 (PDT) Received: by bwz13 with SMTP id 13so200476bwz.31 for ; Mon, 14 Mar 2011 19:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fZW872lejgl+oHw6TvJfZ9/pNTpZlPk2aNpFDaJ0gns=; b=V6wS9fMRiQPJup98mvbLfo3XfC1757scDdX6KEoNJ/aSPrIJBUvUWb8JAWrID008ZA tGaK0X+9UCrsF9cO4IQE75u+2r4mstDn/93AwUAExBIrjEvzZDa0Sw3bwsu6vfBTImlg JP9/qIeH08QLG5Puu/XaTkNymQ0mwCbk/CcSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fbY4XMzMxu02QJH3KxjCT2/8VJkq2ibXzC2ZESbBulVbV2ceRG2dw4km9uGmvaEr49 AQjws8WKzG7Ep0dMTkn7t6IZ6lfsNqc6WzYc9fV1dkR8wRQdQ3HWKNbVz6fFst4VBm+x Nu45ii8XpbFTrxx2S7TgertCsIQC4W4ajtnuA= MIME-Version: 1.0 Received: by 10.204.165.193 with SMTP id j1mr11470839bky.11.1300157400006; Mon, 14 Mar 2011 19:50:00 -0700 (PDT) Received: by 10.204.80.212 with HTTP; Mon, 14 Mar 2011 19:49:59 -0700 (PDT) In-Reply-To: <20110314154501.6000.91738.idtracker@localhost> References: <20110314154501.6000.91738.idtracker@localhost> Date: Tue, 15 Mar 2011 10:49:59 +0800 Message-ID: From: GangChen To: v6ops , Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] [v6ops] I-D Action:draft-chen-v6ops-nat64-cpe-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: Tue, 15 Mar 2011 02:48:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64-CPE Mode Operation for Opening Residential Service Author(s) : G. Chen, H. Deng Filename : draft-chen-v6ops-nat64-cpe-01.txt Pages : 10 Date : 2011-03-14 The document has proposed an approach of NAT64-CPE mode, which would give residential service opportunities to be accessed by remote subscribers going through IPv6 networks. The document captures the fundamental NAT64 Functionalities with special cares to fit into CPE scenarios and don't need cooperate with DNS64 any more. In addition, the CPE mode also allows IPv4 residential hosts to access IPv6 service. It will compatible with legacy residential hosts/servers and no further updates requirements to public DNS system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-01.txt Please kindly review. Comments are appreciated. Many thanks Gang From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 06:47:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4888D3A6D16 for ; Tue, 15 Mar 2011 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 tGZJbrLwvhAc for ; Tue, 15 Mar 2011 06:47:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 2DC9F3A6D4A for ; Tue, 15 Mar 2011 06:47:44 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 564C33243A2; Tue, 15 Mar 2011 14:49:08 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3ABF835C018; Tue, 15 Mar 2011 14:49:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 15 Mar 2011 14:49:08 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 14:49:06 +0100 Thread-Topic: CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DB02C6BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.130022 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 13:47:45 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DB02C6BPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, As you know, several issues are encountered when CGNs are used (see http://= tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for more= details). In order to mitigate some of the issues listed in the above I-D, the CGN ma= y inject an information which will be used by remote servers to disambiguat= e users. FWIW, http://tools.ietf.org/html/draft-boucadair-intarea-nat-revea= l-analysis-01 analyzes a set of candidates solutions and identifies some li= mitations. IMHO, it is valuable to add a requirement in the I-D among these lines. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DB02C6BPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 authors,
 
A= s you know,=20 several issues are encountered when CGNs are used (see http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-iss= ues-05 for=20 more details).
 
I= n order to=20 mitigate some of the issues listed in the above I-D, the CGN may inject an= =20 information which will be used by remote servers to disambiguate users. FWI= W, http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analy= sis-01 analyzes=20 a set of candidates solutions and identifies some=20 limitations.
 
I= MHO, it is=20 valuable to add a requirement in the I-D among these=20 lines.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DB02C6BPUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:02:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C6C3A6D5F for ; Tue, 15 Mar 2011 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 iCawRr3ZgK1O for ; Tue, 15 Mar 2011 07:02:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 08BFD3A6D27 for ; Tue, 15 Mar 2011 07:02:19 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 5A2C01901E0; Tue, 15 Mar 2011 15:03:43 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3704215803A; Tue, 15 Mar 2011 15:03:43 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 15 Mar 2011 15:03:43 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:03:41 +0100 Thread-Topic: CGN REQ-1 Thread-Index: AcvjGcpZNbLmjRthR1iyJ8ie10/sag== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.132418 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:02:20 -0000 Dear authors,=20 =20 The I-D states: REQ-1: A CGN MUST have an "IP address pooling" behaviour of "Paired". Justification: This is a stronger form of REQ-2 from [RFC4787 ]. Note that this requirement applies regardless of the transport protocol. In other words, a CGN must use the same external IP address mapping for all sessions associated with the same internal IP address, be they TCP, UDP, ICMP, something else, or a mix of different protocols. Some comments about this req: * The wording should be modified to mandate the address pooling per-subscri= ber and not per internal host basis. This should be the default behaviour. * This requirement may be relaxed for some protocols such as DNS but this s= hould be left to the taste of SPs (the use of the same external IP address = is not mandatory: the server does not initiate connection towards the clien= t, there is no referral to a third party, no need to correlate between seve= ral sessions (e.g., RTP/RTCP). Cheers, Med=20 =20 From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:06:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609E83A6DB7 for ; Tue, 15 Mar 2011 07:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 Yupe1Bvbfbj3 for ; Tue, 15 Mar 2011 07:06:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 7699C3A6DB2 for ; Tue, 15 Mar 2011 07:06:37 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 425442AC1C8; Tue, 15 Mar 2011 15:08:02 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 294D638403C; Tue, 15 Mar 2011 15:08:02 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 15 Mar 2011 15:08:02 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:08:00 +0100 Thread-Topic: CGN REQ: Transport Protocols Thread-Index: AcvjGmS5XpLj3ZSLRuGOqmdqA6NsvA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DB02C93@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DB02C93PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.132418 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Transport Protocols X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:06:38 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DB02C93PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, It is obvious, but IMO an explicit requirement about the mandatory supporte= d transport protocols (TCP and UDP) is missing. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DB02C93PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
I= t is=20 obvious, but IMO an explicit requirement about the manda= tory=20 supported transport protocols (TCP and UDP) is missing.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DB02C93PUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:12:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918463A6B5B for ; Tue, 15 Mar 2011 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 EjpFBk9p3ncz for ; Tue, 15 Mar 2011 07:12:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 650343A6D7B for ; Tue, 15 Mar 2011 07:12:57 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 31694190155; Tue, 15 Mar 2011 15:14:22 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 18903C803A; Tue, 15 Mar 2011 15:14:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 15 Mar 2011 15:14:22 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:14:20 +0100 Thread-Topic: CGN REQ: IP-ID Thread-Index: AcvjG0cPCkKBJk7TSraF0yZ4hDVV/g== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3AB7PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.134518 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:12:58 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3AB7PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, As for the re-writing of the IP-ID field, a requirement reflecting what is = discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-0= 2#section-9 should be added to the I-D. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3AB7PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
A= s for the=20 re-writing of the IP-ID field, a requirement reflecting what is discussed i= n http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02#sec= tion-9 should=20 be added to the I-D.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3AB7PUEXCB1Bnante_-- From simon.perreault@viagenie.ca Tue Mar 15 07:13:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E813A6D11 for ; Tue, 15 Mar 2011 07:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 XH4xADvTTECV for ; Tue, 15 Mar 2011 07:13:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 2B5CD3A6B5B for ; Tue, 15 Mar 2011 07:13:45 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 466FB20D1E; Tue, 15 Mar 2011 10:15:09 -0400 (EDT) Message-ID: <4D7F746C.4060908@viagenie.ca> Date: Tue, 15 Mar 2011 10:15:08 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:13:46 -0000 On 2011-03-15 10:03, mohamed.boucadair@orange-ftgroup.com wrote: > Dear authors, > > The I-D states: REQ-1: A CGN MUST have an "IP address pooling" > behaviour of "Paired". > > Justification: This is a stronger form of REQ-2 from [RFC4787 > ]. > > Note that this requirement applies regardless of the transport > protocol. In other words, a CGN must use the same external IP > address mapping for all sessions associated with the same internal IP > address, be they TCP, UDP, ICMP, something else, or a mix of > different protocols. > > Some comments about this req: > > * The wording should be modified to mandate the address pooling > per-subscriber and not per internal host basis. This should be the > default behaviour. I don't understand the difference. The requirement is written in terms of internal/external IP addresses, like it is in RFC 4787. What's different with a CGN? > * This requirement may be relaxed for some > protocols such as DNS but this should be left to the taste of SPs > (the use of the same external IP address is not mandatory: the server > does not initiate connection towards the client, there is no referral > to a third party, no need to correlate between several sessions > (e.g., RTP/RTCP). So are you suggesting s/MUST/SHOULD/ ? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Mar 15 07:14:33 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D70C3A6B5B for ; Tue, 15 Mar 2011 07:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 hrZlTBF+00C8 for ; Tue, 15 Mar 2011 07:14:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 493BB3A6D7B for ; Tue, 15 Mar 2011 07:14:32 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8176920D1E; Tue, 15 Mar 2011 10:15:56 -0400 (EDT) Message-ID: <4D7F749C.8070502@viagenie.ca> Date: Tue, 15 Mar 2011 10:15:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DB02C93@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02C93@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Transport Protocols X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:14:33 -0000 On 2011-03-15 10:08, mohamed.boucadair@orange-ftgroup.com wrote: > It is obvious, but IMO an explicit requirement about the mandatory > supported transport protocols (TCP and UDP) is missing. Agreed. I will also add ICMP to that list. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:19:39 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41363A6DCE for ; Tue, 15 Mar 2011 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 ma1OzCl7PFki for ; Tue, 15 Mar 2011 07:19:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 7DD7F3A6DD5 for ; Tue, 15 Mar 2011 07:19:38 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 31A87264260; Tue, 15 Mar 2011 15:21:03 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 17C8D27C054; Tue, 15 Mar 2011 15:21:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 15 Mar 2011 15:21:03 +0100 From: To: Simon Perreault Date: Tue, 15 Mar 2011 15:21:02 +0100 Thread-Topic: CGN REQ-1 Thread-Index: AcvjG2aAvwvgpy3FRrq8zjY7CegySQAADf1g Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3AC8@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> <4D7F746C.4060908@viagenie.ca> In-Reply-To: <4D7F746C.4060908@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.131535 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:19:40 -0000 Re-, Please see inline. Cheers, Med -----Message d'origine----- De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Envoy=E9 : mardi 15 mars 2011 15:15 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-ietf-behave-lsn-requirements@tools.ietf.org; 'behave' <(behave@i= etf.org)> Objet : Re: CGN REQ-1 On 2011-03-15 10:03, mohamed.boucadair@orange-ftgroup.com wrote: > Dear authors, >=20 > The I-D states: REQ-1: A CGN MUST have an "IP address pooling" > behaviour of "Paired". >=20 > Justification: This is a stronger form of REQ-2 from [RFC4787 > ]. >=20 > Note that this requirement applies regardless of the transport=20 > protocol. In other words, a CGN must use the same external IP=20 > address mapping for all sessions associated with the same internal IP > address, be they TCP, UDP, ICMP, something else, or a mix of=20 > different protocols. >=20 > Some comments about this req: >=20 > * The wording should be modified to mandate the address pooling > per-subscriber and not per internal host basis. This should be the > default behaviour. I don't understand the difference. The requirement is written in terms of internal/external IP addresses, like it is in RFC 4787. What's different with a CGN? Med: A subscriber can be seen with multiple IP internal addresses (e.g., DS= -Lite, L2-NAT).=20 > * This requirement may be relaxed for some > protocols such as DNS but this should be left to the taste of SPs > (the use of the same external IP address is not mandatory: the server > does not initiate connection towards the client, there is no referral > to a third party, no need to correlate between several sessions > (e.g., RTP/RTCP). So are you suggesting s/MUST/SHOULD/ ? Med: Yes. State also this is should be the default behaviour. Thanks, Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Mar 15 07:20:15 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F273A6B5B for ; Tue, 15 Mar 2011 07:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 6ycA91+VkWGu for ; Tue, 15 Mar 2011 07:20:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1B7693A6BD0 for ; Tue, 15 Mar 2011 07:20:14 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B068120D1E; Tue, 15 Mar 2011 10:21:37 -0400 (EDT) Message-ID: <4D7F75F1.5030601@viagenie.ca> Date: Tue, 15 Mar 2011 10:21:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:20:15 -0000 On 2011-03-15 10:14, mohamed.boucadair@orange-ftgroup.com wrote: > As for the re-writing of the IP-ID field, a requirement reflecting what > is discussed in > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02#section-9 should > be added to the I-D. Unless the WG disagrees, I'll add a new requirement referring to that draft. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Mar 15 07:25:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC603A6D85 for ; Tue, 15 Mar 2011 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, 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 gJI3zE7Jag3A for ; Tue, 15 Mar 2011 07:25:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5C4183A6D2F for ; Tue, 15 Mar 2011 07:25:06 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9AE7720D1E; Tue, 15 Mar 2011 10:26:30 -0400 (EDT) Message-ID: <4D7F7716.5060108@viagenie.ca> Date: Tue, 15 Mar 2011 10:26:30 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> <4D7F746C.4060908@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3AC8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3AC8@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:25:09 -0000 On 2011-03-15 10:21, mohamed.boucadair@orange-ftgroup.com wrote: >> * The wording should be modified to mandate the address pooling >> per-subscriber and not per internal host basis. This should be the >> default behaviour. > > I don't understand the difference. The requirement is written in terms > of internal/external IP addresses, like it is in RFC 4787. What's > different with a CGN? > > Med: A subscriber can be seen with multiple IP internal addresses (e.g., DS-Lite, L2-NAT). So a subscriber's CPE would be assigned multiple internal IPv4 addresses, and all these addresses would need to map to the same external address. Is that right? If so, how can the CGN recognize that those multiple addresses are related? >> * This requirement may be relaxed for some >> protocols such as DNS but this should be left to the taste of SPs >> (the use of the same external IP address is not mandatory: the server >> does not initiate connection towards the client, there is no referral >> to a third party, no need to correlate between several sessions >> (e.g., RTP/RTCP). > > So are you suggesting s/MUST/SHOULD/ ? > > Med: Yes. State also this is should be the default behaviour. Unless the WG disagrees, I'll make those changes in the next revision. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Mar 15 07:26:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2CD23A6D11 for ; Tue, 15 Mar 2011 07:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 fh+fz+bXs7kt for ; Tue, 15 Mar 2011 07:26:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F3D323A6D2F for ; Tue, 15 Mar 2011 07:26:17 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4102A20D1E; Tue, 15 Mar 2011 10:27:42 -0400 (EDT) Message-ID: <4D7F775D.6030303@viagenie.ca> Date: Tue, 15 Mar 2011 10:27:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:26:19 -0000 On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: > As you know, several issues are encountered when CGNs are used (see > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for > more details). > > In order to mitigate some of the issues listed in the above I-D, the CGN > may inject an information which will be used by remote servers to > disambiguate users. FWIW, > http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01 analyzes > a set of candidates solutions and identifies some limitations. > > IMHO, it is valuable to add a requirement in the I-D among these lines. I'll definitely need WG feedback on this. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:26:39 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDCC3A6DCF for ; Tue, 15 Mar 2011 07:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 wtH1q9bHOwDL for ; Tue, 15 Mar 2011 07:26:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 1EF503A6D11 for ; Tue, 15 Mar 2011 07:26:38 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3E2CA2AC466; Tue, 15 Mar 2011 15:28:02 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 258E5180067; Tue, 15 Mar 2011 15:28:02 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 15 Mar 2011 15:28:02 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:28:00 +0100 Thread-Topic: CGN REQ: Control NAT mappings for inbound communications Thread-Index: AcvjHS/xay+A6A2mRli6YQarXKnKrQ== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3ADC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3ADCPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.135418 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:26:39 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3ADCPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, Some applications will fail if port forwarding is not supported. Having a r= equirement to mandate the support of port forwarding feature would be valua= ble. PCP can be listed as a RECOMMENDED solution. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3ADCPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
S= ome=20 applications will fail if port forwarding is not supported. Having a requir= ement=20 to mandate the support of port forwarding feature would be=20 valuable.
 
P= CP can be=20 listed as a RECOMMENDED solution.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3ADCPUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:32:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32E83A6D93 for ; Tue, 15 Mar 2011 07:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, HELO_EQ_FR=0.35, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 LFyqbLKsKykm for ; Tue, 15 Mar 2011 07:32:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 6E4813A6DE4 for ; Tue, 15 Mar 2011 07:32:41 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 44201C0136; Tue, 15 Mar 2011 15:34:06 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2BD9218004F; Tue, 15 Mar 2011 15:34:06 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 15 Mar 2011 15:34:06 +0100 From: To: Simon Perreault Date: Tue, 15 Mar 2011 15:34:04 +0100 Thread-Topic: CGN REQ-1 Thread-Index: AcvjHPsa890l5U4MQiqhWruJb/1sMgAAEBZg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3AE4@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> <4D7F746C.4060908@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3AC8@PUEXCB1B.nanterre.francetelecom.fr> <4D7F7716.5060108@viagenie.ca> In-Reply-To: <4D7F7716.5060108@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.135418 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:32:47 -0000 Re, Please see inline. Cheers, Med =20 -----Message d'origine----- De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Envoy=E9 : mardi 15 mars 2011 15:27 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-ietf-behave-lsn-requirements@tools.ietf.org; 'behave' <(behave@i= etf.org)> Objet : Re: CGN REQ-1 On 2011-03-15 10:21, mohamed.boucadair@orange-ftgroup.com wrote: >> * The wording should be modified to mandate the address pooling >> per-subscriber and not per internal host basis. This should be the >> default behaviour. >=20 > I don't understand the difference. The requirement is written in terms > of internal/external IP addresses, like it is in RFC 4787. What's > different with a CGN? >=20 > Med: A subscriber can be seen with multiple IP internal addresses (e.g., = DS-Lite, L2-NAT).=20 So a subscriber's CPE would be assigned multiple internal IPv4 addresses, and all these addresses would need to map to the same external address. Is that right? Med: No IPv4 address is assigned to the WAN interface of the CPE. The CPE d= oes not "touch" to the IPv4 packets as issued by internal hosts. The NAT ta= ble must include in addition to the internal IPv4 address, the de-multiplex= er identifier (MAC address, IPv6 address, IPv6 prefix, etc.). If so, how can the CGN recognize that those multiple addresses are related? Med: For the DS-Lite case, the first bits of the IPv6 address (e.g., 56, 64= ) are used as a de-multiplexer. For the L2-NAT, this can rely on the PPP se= ssion, etc.=20 =20 >> * This requirement may be relaxed for some >> protocols such as DNS but this should be left to the taste of SPs >> (the use of the same external IP address is not mandatory: the server >> does not initiate connection towards the client, there is no referral >> to a third party, no need to correlate between several sessions >> (e.g., RTP/RTCP). >=20 > So are you suggesting s/MUST/SHOULD/ ? >=20 > Med: Yes. State also this is should be the default behaviour. Unless the WG disagrees, I'll make those changes in the next revision. Thanks, Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:42:05 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF913A6DEA for ; Tue, 15 Mar 2011 07:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 40Jufqxb6yuk for ; Tue, 15 Mar 2011 07:42:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 04F033A6DE4 for ; Tue, 15 Mar 2011 07:42:04 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D1D6918C144; Tue, 15 Mar 2011 15:43:28 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B2F7C4C013; Tue, 15 Mar 2011 15:43:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 15 Mar 2011 15:43:28 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:43:27 +0100 Thread-Topic: CGN REG: Diffserv and DSCP marking/re-marking policies Thread-Index: AcvjH1gc9ccHEPR4QdieWadTqpt+Xw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B17@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.140322 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:42:05 -0000 Re-, =20 Since the CGN nodes will be introduced into service providers networks, som= e QoS functions are required: =20 * Set the value of DSCP field (default behaviour) * Ability to configure DSCP re-marking policies * For the DS-Lite case, some extra functions are required to map between th= e contents of the Differentiated Services field of the IPv4 header and the = Differentiated Services field of the IPv6 header for downstream traffic (vi= ce versa). * Support of DiffServ capabilities (traffic classification and marking, tra= ffic conditioning and scheduling, traffic discarding) * Etc. Cheers, Med From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:44:30 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920753A6D8D for ; Tue, 15 Mar 2011 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 8Uks9IsQgLkV for ; Tue, 15 Mar 2011 07:44:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id B34993A6D85 for ; Tue, 15 Mar 2011 07:44:29 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 5E866C0321; Tue, 15 Mar 2011 15:45:54 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 45278C803A; Tue, 15 Mar 2011 15:45:54 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 15 Mar 2011 15:45:54 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:45:52 +0100 Thread-Topic: CGN REQ: Ability to blacklist misbehaving users Thread-Index: AcvjH654m3MFXnBXRqCZhEgLsWJ1oQ== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B21@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B21PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.140322 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Ability to blacklist misbehaving users X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:44:30 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B21PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, In some deployment contexts, the CGN should be able to blacklist (white lis= t) a misbehaving user. I suggest to add a requirement about this operational (but important) requi= rement. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B21PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
I= n some=20 deployment contexts, the CGN should be able to blacklist (white list) a=20 misbehaving user.
I= suggest to=20 add a requirement about this operational (but important)=20 requirement.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B21PUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:48:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9543A6DDC for ; Tue, 15 Mar 2011 07:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 uJcnKy0L68Ie for ; Tue, 15 Mar 2011 07:48:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 955D33A6D9F for ; Tue, 15 Mar 2011 07:48:37 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 74BF8C02C6; Tue, 15 Mar 2011 15:50:02 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D0DA158085; Tue, 15 Mar 2011 15:50:02 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 15 Mar 2011 15:50:02 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:50:01 +0100 Thread-Topic: CGN REQ: Bandwidth fair usage Thread-Index: AcvjIELb5smnjdewTJSMILNilwhjzw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B32@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B32PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.135418 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Bandwidth fair usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:48:38 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B32PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, In addition to the rate limit function mentioned in REQ 2, the CGN should b= e able to enforce a bandwidth fair usage between subscribers (traffic polic= ing and shaping) are required. The configuration SHOULD be system-wise and = MAY be per-subscriber (e.g., define service profiles). Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B32PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
I= n addition=20 to the rate limit function mentioned in REQ 2, the CGN should be able=20 to enforce a bandwidth fair usage between subscribers (traffic=20 policing and shaping) are required. The configuration SHOULD= be=20 system-wise and MAY be per-subscriber (e.g., define service=20 profiles). 
 
Cheers,
Med 
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B32PUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:54:26 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA3C3A6DA4 for ; Tue, 15 Mar 2011 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 nptfE+pkY0w5 for ; Tue, 15 Mar 2011 07:54:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id B2D663A6D31 for ; Tue, 15 Mar 2011 07:54:22 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 846D2190101; Tue, 15 Mar 2011 15:55:47 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6225E15805E; Tue, 15 Mar 2011 15:55:47 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 15 Mar 2011 15:55:47 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:55:46 +0100 Thread-Topic: CGN REQ: SPAM Protection Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25w== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B3CPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.143316 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:54:26 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B3CPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, An explicit requirement about the support of means to protect against SPAM = should be IMO added to the req list. For instance the default behaviour wou= ld be the CGN block port 25 for SMTP. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B3CPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
A= n explicit=20 requirement about the support of means to protect against SPAM should be IM= O=20 added to the req list. For instance the default behaviour would be the CGN = block=20 port 25 for SMTP.
 
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B3CPUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 07:59:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0A23A6D9C for ; Tue, 15 Mar 2011 07:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, HELO_EQ_FR=0.35, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 wVZU2JgD6sAK for ; Tue, 15 Mar 2011 07:59:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 6D6DB3A6D13 for ; Tue, 15 Mar 2011 07:59:28 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4AF9C2AC054; Tue, 15 Mar 2011 16:00:53 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 33B76C803A; Tue, 15 Mar 2011 16:00:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 15 Mar 2011 16:00:53 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 16:00:51 +0100 Thread-Topic: CGN REQ: NAT MIB Thread-Index: AcvjIcbO4NKW9aBHQ+ybE/15DgVsuw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.143316 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 14:59:29 -0000 Re-, =20 A requirement to mention that appropriate MIB modules are to be supported b= y the CGN is needed. =20 At least RFC 4008 is needed. Tunnel MIB (RFC 4087) is to be supported for D= S-Lite CGN. Cheers, Med= From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 08:05:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D699F3A6C5B for ; Tue, 15 Mar 2011 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 rDKxblVE6d1c for ; Tue, 15 Mar 2011 08:05:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id DD0543A6835 for ; Tue, 15 Mar 2011 08:05:53 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 44096C01A1; Tue, 15 Mar 2011 16:07:18 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2B52E384061; Tue, 15 Mar 2011 16:07:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 15 Mar 2011 16:07:18 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 16:07:16 +0100 Thread-Topic: CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B56PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.134518 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 15:05:54 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B56PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#= section-5 discusses various modes for the port assignment but there is no e= xplicit requirement. I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) support t= he ability to assign port sets. The selection of the dynamic mode vs. port = set is deployment-specific. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B56PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
S= ection 5=20 http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#s= ection-5 discusses=20 various modes for the port assignment but there is no explicit=20 requirement. 
 
I= suggest=20 in=20 addition to the dynamic mode, the CGN MUST (SHOULD?) support the= =20 ability to assign port sets. The selection of the dynamic mode vs. port set= is=20 deployment-specific.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3B56PUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 08:09:35 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384093A6DA4 for ; Tue, 15 Mar 2011 08:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 Qioq3Vuae-Dn for ; Tue, 15 Mar 2011 08:09:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 63D953A6D1F for ; Tue, 15 Mar 2011 08:09:34 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 43E2EC015E; Tue, 15 Mar 2011 16:10:59 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2DD0538403C; Tue, 15 Mar 2011 16:10:59 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 15 Mar 2011 16:10:59 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 16:10:58 +0100 Thread-Topic: CGN REQ: Hold-down pool Thread-Index: AcvjIzBUZe2XYRcbSNCzhU8+x/B+hA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.134518 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 15:09:35 -0000 Re-, =20 An important missing requirement is the behaviour for the timeouted ports; = I refer to this as hold down pool. These ports SHOULD NOT be assigned to ne= w requesting users before the expiration of the hold down timer. The purpos= e is to prevent users from receiving unwanted traffic. The hold-down timer and size of the pool should be configurable by the oper= ator. Cheers, Med=20 From dwing@cisco.com Tue Mar 15 08:18:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1923A6DBB; Tue, 15 Mar 2011 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.434 X-Spam-Level: X-Spam-Status: No, score=-110.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 MikfVslpU4Vk; Tue, 15 Mar 2011 08:18: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 D29FA3A6E0F; Tue, 15 Mar 2011 08:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3739; q=dns/txt; s=iport; t=1300202369; x=1301411969; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ko8eCLuyaLQuQMsftQgALst7eZ5T5b0bGg9BG2EK6tc=; b=A1efMkVOwA+AFuRaPci8fToxcPiFMbshHjCmn+5YyhG4JiAnCGm/UwTT cq465sSocVxy+dJoE3AcZ/I+iWfYUhmSebBSB27qvkHiGCAk7QxjAeO18 rMNN7gwUhys0F/BjrUe1KKGrgKLTtWMrAa/iFK0wbFtVpVkUIh6kdVV87 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAAYgf02tJXHB/2dsb2JhbACYSoFki1p3pT+dCYViBIUw X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208";a="347044199" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 15:19:28 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FFJRNi005104; Tue, 15 Mar 2011 15:19:27 GMT From: "Dan Wing" To: , "'Francis Dupont'" , References: <201103151019.p2FAJmhk073794@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4DB02BCB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02BCB@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 08:19:27 -0700 Message-ID: <10f301cbe324$60300a40$20901ec0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvi+oeJMbP5aOqLTRq6SOVByadhhAADuvHAAAZ7f0A= Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 15:18:21 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 5:14 AM > To: Francis Dupont; pcp@ietf.org > Subject: Re: [pcp] last CGN requirements >=20 > Hi all, >=20 > REQ-6 is an operational requirement which require more elaboration: > e.g., how an address pool is defined? Is there any hold-timer for the > re-use of the address pool? There really isn't a /need/ for two address pools. Rather, there is a need to not re-use an address within "some time period". I don't know the time period. It needs to be discussed. For EXAMPLE, let's say there is a CGN that crashes and takes 20 minutes to boot -- could it reasonably re-use the same IP address pool? 2 minutes to boot? 4 minutes? What is the amount of time needed. =20 Today when ISPs force subscribers to change IP addresses, do they wait a day or an hour or a minute before re-using the IP address for another subscriber? > For operational requirements, I would prefer having something as what > is documented in http://tools.ietf.org/html/draft-xu-behave-stateful- > nat-standby-06. >=20 > In draft-xu-behave-stateful-nat-standby-06, you may read this > requirement which I would like see integrated in the CGN requirement = I- > D: >=20 > "Port forwarding entries SHOULD be stored in permanent storage > whatever the deployed redundancy mode." If a different address pool is going to be one of the requirements, though, such permanent storage serves no purpose. Essentially, I think we need to up-level the requirement to what we want to see on the wire, rather than how it should be implemented in the CGN. -d >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > Francis Dupont > Envoy=E9 : mardi 15 mars 2011 11:20 > =C0 : pcp@ietf.org > Objet : [pcp] last CGN requirements >=20 > Printing the new base-07, I am reading the new CGN requirement draft > (named draft-ietf-behave-lsn-requirements-01.txt but LSN was replaced > by CGN everywhere at the exception of the title). > I can get: >=20 > REQ-6: When a CGN loses state (due to a crash, reboot, failover to > a > cold standby, etc.), it MUST start using a different external > address pool. >=20 > Justification: This is necessary in order to prevent collisions > between old and new mappings and sessions. It ensures that all > established sessions are broken instead of redirected to a > different peer. The previous address pool MAY of course be > reused > after a second loss of state. >=20 > Three comments: > - the MUST applies to all mappings: static, explicit dynamic (i.e., > instantiated by PCP) and implicit dynamic. >=20 > - it does not say something about the use of stable/persistent = storage > to remove the condition (i.e., the when). >=20 > - it is a pure operational requirement, for instance the MAY does not > make sense from a security point of view for long term mappings, > i.e., static or explicit dynamic. >=20 > There are other interesting points (REQ-1 for instance) but IMHO it is > unfinished: logging section does not use the fact EIM is required for > instance. >=20 > Regards >=20 > Francis.Dupont@fdupont.fr >=20 > PS: Simon, I believe you want more comments? > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Tue Mar 15 08:22:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C833A6D4D for ; Tue, 15 Mar 2011 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.44 X-Spam-Level: X-Spam-Status: No, score=-110.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 d-xk6SdgCX-5 for ; Tue, 15 Mar 2011 08:22:16 -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 7466F3A6D71 for ; Tue, 15 Mar 2011 08:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1171; q=dns/txt; s=iport; t=1300202621; x=1301412221; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=cYR3axEjeL9qJ9lcXnyd66hEWDhVSVAvUcKVNJwK/mE=; b=mokRO8llpVe1GEWw6vrGGR5ukVAzx5xBCp2Ie5R0F+sby+if6bX2khyI JD9vJqufpZkL5xUcLblDr32q81Aq3RmcJ2l+Rr4fWKRckV9X5tvhBmf1m eHPd2ZfTt9koviGuNKd96g6DcQLAxl6ivpg5D/xdrDA3HcYP529kYSNfH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAADMhf02tJXHB/2dsb2JhbACYSoFki1p3pTidCYViBIUwjSY X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208";a="347047320" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 15:23:40 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FFNdgj007141; Tue, 15 Mar 2011 15:23:39 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 08:23:39 -0700 Message-ID: <10fd01cbe324$f63e7fd0$e2bb7f70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgw Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 15:22:18 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 6:49 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > Dear authors, > > As you know, several issues are encountered when CGNs are used (see > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues- > 05 for more details). > > In order to mitigate some of the issues listed in the above I-D, the > CGN may inject an information which will be used by remote servers to > disambiguate users. FWIW, http://tools.ietf.org/html/draft-boucadair- > intarea-nat-reveal-analysis-01 analyzes a set of candidates solutions > and identifies some limitations. > > IMHO, it is valuable to add a requirement in the I-D among these lines. I agree it would be valuable. How about in CGN Requirements "bis", though? I would hate to delay publication of the CGN Requirements draft while we're working through which mechanism to standardize. -d From dwing@cisco.com Tue Mar 15 08:28:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A3A3A6D85 for ; Tue, 15 Mar 2011 08:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.407 X-Spam-Level: X-Spam-Status: No, score=-109.407 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, 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 02CKuPKFC0fC for ; Tue, 15 Mar 2011 08:28:27 -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 C34373A6D76 for ; Tue, 15 Mar 2011 08:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2068; q=dns/txt; s=iport; t=1300202993; x=1301412593; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=lo8NJKuNcgXkciCYzSCMGu7vuCt8QQxMmsXWV4CaNEM=; b=Y746h2rW+LCY3ZprxkJDmnmli+xcug2KPpSS7l6yct3Pig0OfMdC7TwR /yn8LDWb8lb3IHJxJr19XlfC668k+5XAwjov+IL7lAPycrJpMCGBiGP5b yrLf2ZXpzx54UcHbPhq+UlAFq68HzfwUkqatNUYHqyylJjSWrfHKnOAbU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsACAF8if02tJV2d/2dsb2JhbACYSoFki1poD6VEnQqFYgSFMA X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208";a="347052152" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 15:29:48 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FFTlBu024814; Tue, 15 Mar 2011 15:29:47 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 08:29:47 -0700 Message-ID: <10fe01cbe325$d16c4560$7444d020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjGcpZNbLmjRthR1iyJ8ie10/sagACzYqw Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 15:28:29 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 7:04 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ-1 > > Dear authors, > > The I-D states: > REQ-1: A CGN MUST have an "IP address pooling" behaviour of > "Paired". > > Justification: This is a stronger form of REQ-2 from [RFC4787 > ]. > > Note that this requirement applies regardless of the transport > protocol. In other words, a CGN must use the same external IP > address mapping for all sessions associated with the same > internal > IP address, be they TCP, UDP, ICMP, something else, or a mix of > different protocols. > > Some comments about this req: > > * The wording should be modified to mandate the address pooling per- > subscriber and not per internal host basis. This should be the default > behaviour. Perhaps I am mis-understanding what is meant by 'per subscriber'. Let's take the example of DS-Lite where a single subscriber has several IPv4 hosts in their home. You're saying all of the hosts belonging to that user need to share the same public IPv4 address? If that's what you're saying, why do we need that requirement? > * This requirement may be relaxed for some protocols such as DNS but > this should be left to the taste of SPs (the use of the same external > IP address is not mandatory: the server does not initiate connection > towards the client, there is no referral to a third party, no need to > correlate between several sessions (e.g., RTP/RTCP). DNS could become sensitive to this, depending on how ideas such as draft-vandergaast-edns-client-ip get deployed. -d > Cheers, > Med > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From rpenno@juniper.net Tue Mar 15 08:47:57 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6907B3A6DE2 for ; Tue, 15 Mar 2011 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.007, 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 U+uu8g33FOCj for ; Tue, 15 Mar 2011 08:47:56 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 0840C3A6D0F for ; Tue, 15 Mar 2011 08:47:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTX+Ke7dp1eOpqWHzwJB71rivVpCU4zrm@postini.com; Tue, 15 Mar 2011 08:49:21 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 08:44:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 11:46:01 -0400 From: Reinaldo Penno To: Simon Perreault , "mohamed.boucadair@orange-ftgroup.com" Date: Tue, 15 Mar 2011 11:46:00 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0i Message-ID: In-Reply-To: <4D7F775D.6030303@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 15:47:57 -0000 I believe we need much more discussion on this requirement before it makes to the I-D. There are security issues, subscriber privacy issues, performance issues, amongst others. Not to mention that there are some 6 different techniques. On 3/15/11 7:27 AM, "Simon Perreault" wrote: > On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: >> As you know, several issues are encountered when CGNs are used (see >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-0= 5 for >> more details). >> =20 >> In order to mitigate some of the issues listed in the above I-D, the CGN >> may inject an information which will be used by remote servers to >> disambiguate users. FWIW, >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-0= 1 >> analyzes >> a set of candidates solutions and identifies some limitations. >> =20 >> IMHO, it is valuable to add a requirement in the I-D among these lines. >=20 > I'll definitely need WG feedback on this. >=20 > Thanks, > Simon From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 08:53:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762AD3A6E27 for ; Tue, 15 Mar 2011 08:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 VhKuSrNStw9n for ; Tue, 15 Mar 2011 08:53:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 35E9B3A6C5B for ; Tue, 15 Mar 2011 08:53:22 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4B0F932448C; Tue, 15 Mar 2011 16:54:46 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3085C4C021; Tue, 15 Mar 2011 16:54:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 15 Mar 2011 16:54:46 +0100 From: To: Reinaldo Penno , Simon Perreault Date: Tue, 15 Mar 2011 16:54:44 +0100 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7A= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3BD6@PUEXCB1B.nanterre.francetelecom.fr> References: <4D7F775D.6030303@viagenie.ca> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.150320 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 15:53:23 -0000 Hi Reinaldo, Yes, this needs discussion.=20 As for the privacy, I don't see an issue there since the exposed informatio= n is the same as the source IP address (when there is no NAT).=20 Cheers, Med=20 -----Message d'origine----- De : Reinaldo Penno [mailto:rpenno@juniper.net]=20 Envoy=E9 : mardi 15 mars 2011 16:46 =C0 : Simon Perreault; BOUCADAIR Mohamed OLNC/NAD/TIP Cc : 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn-requirements@tools= .ietf.org Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT I believe we need much more discussion on this requirement before it makes to the I-D. There are security issues, subscriber privacy issues, performance issues, amongst others. Not to mention that there are some 6 different techniques. On 3/15/11 7:27 AM, "Simon Perreault" wrote: > On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: >> As you know, several issues are encountered when CGNs are used (see >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-0= 5 for >> more details). >> =20 >> In order to mitigate some of the issues listed in the above I-D, the CGN >> may inject an information which will be used by remote servers to >> disambiguate users. FWIW, >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-0= 1 >> analyzes >> a set of candidates solutions and identifies some limitations. >> =20 >> IMHO, it is valuable to add a requirement in the I-D among these lines. >=20 > I'll definitely need WG feedback on this. >=20 > Thanks, > Simon From rpenno@juniper.net Tue Mar 15 09:13:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BFE3A6D1F for ; Tue, 15 Mar 2011 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Bbt3MVoqEIex for ; Tue, 15 Mar 2011 09:13:21 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 6C8203A6C5B for ; Tue, 15 Mar 2011 09:13:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTX+QYiXmhucm4yMld7lZWnGe6XPAE7VB@postini.com; Tue, 15 Mar 2011 09:14:46 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 09:10:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 12:11:47 -0400 From: Reinaldo Penno To: "mohamed.boucadair@orange-ftgroup.com" , Simon Perreault Date: Tue, 15 Mar 2011 12:11:45 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWg== Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3BD6@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:13:22 -0000 On 3/15/11 8:54 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Hi Reinaldo, >=20 > Yes, this needs discussion. >=20 > As for the privacy, I don't see an issue there since the exposed informat= ion > is the same as the source IP address (when there is no NAT). If you take NAT as the new baseline, then there is a change in relation to that. Look at this another way. Will this requirement apply to CPEs as well so third parties can differentiate between several users at the home? Why not? BTW, Can you explain who this requirement will benefit? >=20 > Cheers, > Med=20 >=20 > -----Message d'origine----- > De : Reinaldo Penno [mailto:rpenno@juniper.net] > Envoy=E9 : mardi 15 mars 2011 16:46 > =C0 : Simon Perreault; BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : 'behave' <(behave@ietf.org)>; > draft-ietf-behave-lsn-requirements@tools.ietf.org > Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 > I believe we need much more discussion on this requirement before it make= s > to the I-D. There are security issues, subscriber privacy issues, > performance issues, amongst others. Not to mention that there are some 6 > different techniques. >=20 >=20 > On 3/15/11 7:27 AM, "Simon Perreault" wrote= : >=20 >> On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: >>> As you know, several issues are encountered when CGNs are used (see >>> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-= 05 >>> for >>> more details). >>> =20 >>> In order to mitigate some of the issues listed in the above I-D, the CG= N >>> may inject an information which will be used by remote servers to >>> disambiguate users. FWIW, >>> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-= 01 >>> analyzes >>> a set of candidates solutions and identifies some limitations. >>> =20 >>> IMHO, it is valuable to add a requirement in the I-D among these lines. >>=20 >> I'll definitely need WG feedback on this. >>=20 >> Thanks, >> Simon >=20 From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 09:46:08 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B223A6D48 for ; Tue, 15 Mar 2011 09:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 3koDooe+ZK+m for ; Tue, 15 Mar 2011 09:46:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id F31313A6E20 for ; Tue, 15 Mar 2011 09:46:06 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 6C110C015E; Tue, 15 Mar 2011 17:47:31 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 4070B158063; Tue, 15 Mar 2011 17:47:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 15 Mar 2011 17:47:31 +0100 From: To: Reinaldo Penno , Simon Perreault Date: Tue, 15 Mar 2011 17:47:29 +0100 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWgAA6etw Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3C30@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3BD6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.150320 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:46:08 -0000 Re-, Please see inline. Cheers, Med =20 -----Message d'origine----- De : Reinaldo Penno [mailto:rpenno@juniper.net]=20 Envoy=E9 : mardi 15 mars 2011 17:12 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault Cc : 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn-requirements@tools= .ietf.org Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT On 3/15/11 8:54 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Hi Reinaldo, >=20 > Yes, this needs discussion. >=20 > As for the privacy, I don't see an issue there since the exposed informat= ion > is the same as the source IP address (when there is no NAT). If you take NAT as the new baseline, then there is a change in relation to that. Look at this another way. Will this requirement apply to CPEs as well so third parties can differentiate between several users at the home? Why not? Med: I see your point and it is a valid question. The requirement is about = the CGN and not the NAT in the CPE. Some of the solutions are already deplo= yed (e.g., use of XFF by load-balancers). BTW, there are already reported i= ssues with current practices: see for instance the S. Bellovin's study abou= t counting NATed hosts. BTW, Can you explain who this requirement will benefit? Med: It benefits to the users, service providers and content providers:=20 * a user won't be impacted by a misbehaving action of another user sharing = the same IP address. See http://tools.ietf.org/html/draft-boucadair-intarea= -nat-reveal-analysis-01#section-1 for more details. * a service provider won't receive calls to hot-lines (OPEX reduction) * content providers: service experience. >=20 > Cheers, > Med=20 >=20 > -----Message d'origine----- > De : Reinaldo Penno [mailto:rpenno@juniper.net] > Envoy=E9 : mardi 15 mars 2011 16:46 > =C0 : Simon Perreault; BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : 'behave' <(behave@ietf.org)>; > draft-ietf-behave-lsn-requirements@tools.ietf.org > Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 > I believe we need much more discussion on this requirement before it make= s > to the I-D. There are security issues, subscriber privacy issues, > performance issues, amongst others. Not to mention that there are some 6 > different techniques. >=20 >=20 > On 3/15/11 7:27 AM, "Simon Perreault" wrote= : >=20 >> On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: >>> As you know, several issues are encountered when CGNs are used (see >>> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-= 05 >>> for >>> more details). >>> =20 >>> In order to mitigate some of the issues listed in the above I-D, the CG= N >>> may inject an information which will be used by remote servers to >>> disambiguate users. FWIW, >>> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-= 01 >>> analyzes >>> a set of candidates solutions and identifies some limitations. >>> =20 >>> IMHO, it is valuable to add a requirement in the I-D among these lines. >>=20 >> I'll definitely need WG feedback on this. >>=20 >> Thanks, >> Simon >=20 From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 09:52:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F1D3A6DF1 for ; Tue, 15 Mar 2011 09:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 cMq58y6UnfmP for ; Tue, 15 Mar 2011 09:52:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 892B63A6C5B for ; Tue, 15 Mar 2011 09:52:02 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 8AA30C0077; Tue, 15 Mar 2011 17:53:27 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7391138403C; Tue, 15 Mar 2011 17:53:27 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 15 Mar 2011 17:53:27 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 17:53:26 +0100 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3C3B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> <10fd01cbe324$f63e7fd0$e2bb7f70$@com> In-Reply-To: <10fd01cbe324$f63e7fd0$e2bb7f70$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.163320 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:52:04 -0000 Hi Dan, If there is a risk to delay the publication of the document, an option woul= d be to have a non-normative section to record the issue and to discuss it = without providing an explicit requirement. This works for me. BTW, does the work documented in nat-reveal-analysis I-D within the charter= of BEHAVE or not? Cheers, Med -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 16:24 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 6:49 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 > Dear authors, >=20 > As you know, several issues are encountered when CGNs are used (see > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues- > 05 for more details). >=20 > In order to mitigate some of the issues listed in the above I-D, the > CGN may inject an information which will be used by remote servers to > disambiguate users. FWIW, http://tools.ietf.org/html/draft-boucadair- > intarea-nat-reveal-analysis-01 analyzes a set of candidates solutions > and identifies some limitations. >=20 > IMHO, it is valuable to add a requirement in the I-D among these lines. I agree it would be valuable. How about in CGN Requirements "bis", though? I would hate to delay publication of the CGN Requirements draft while we're working through which mechanism to standardize. -d From dwing@cisco.com Tue Mar 15 10:17:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4083C3A69F9 for ; Tue, 15 Mar 2011 10:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.257 X-Spam-Level: X-Spam-Status: No, score=-110.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 CNdwnTylM1HR for ; Tue, 15 Mar 2011 10:17:54 -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 09AEF3A69DD for ; Tue, 15 Mar 2011 10:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2849; q=dns/txt; s=iport; t=1300209559; x=1301419159; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ISRn6Eziml7b5bi2kxuRrP1fbNqWbDptpo5M9BcIUqk=; b=IrAcuNHr9FFNnoYoXEk2r85mKmcoGwL+rWchdoCC9C0q6KDqrzqhOygb 93qSzIvLGIE0/cfFJX7IPtJOHEjlsZnOrM0kYklhjTRDiR22ZP0N0CO3M 6s6Pa6hOgvyVMtGKAiBRkdVnRwSzbAf+9wDUviQUyGlqiHSa6TYuJDGHF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAOo7f02tJXHA/2dsb2JhbACYSoFki1p3piSdBIJ7gmcEhTCNJg X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="667370184" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 17:19:18 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHJImw004888; Tue, 15 Mar 2011 17:19:18 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> <10fd01cbe324$f63e7fd0$e2bb7f70$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3C3B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3C3B@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 10:19:18 -0700 Message-ID: <123501cbe335$1e1537f0$5a3fa7d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEA== Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:17:55 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 9:53 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 > Hi Dan, >=20 > If there is a risk to delay the publication of the document, an option > would be to have a non-normative section to record the issue and to > discuss it without providing an explicit requirement. This works for > me. Ok. Works for me, too. Perhaps "There is ongoing work to allow servers to identify subscribers initiating connections, to facilitate tracability and blocking of=20 subscribers abusing a service (e.g., DoS attacks). A future=20 version of this specification is expected to recommend using one of these mechanisms." > BTW, does the work documented in nat-reveal-analysis I-D within the > charter of BEHAVE or not? I believe so, but it's probably somewhere between BEHAVE and INTAREA. =20 I'll add you to the BEHAVE agenda, because the audience in BEHAVE should certainly be(come) aware of this issue. http://www.ietf.org/proceedings/80/agenda/behave.html -d > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 16:24 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Tuesday, March 15, 2011 6:49 AM > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: 'behave' <(behave@ietf.org)> > > Subject: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > > > Dear authors, > > > > As you know, several issues are encountered when CGNs are used (see > > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing- > issues- > > 05 for more details). > > > > In order to mitigate some of the issues listed in the above I-D, the > > CGN may inject an information which will be used by remote servers = to > > disambiguate users. FWIW, = http://tools.ietf.org/html/draft-boucadair- > > intarea-nat-reveal-analysis-01 analyzes a set of candidates = solutions > > and identifies some limitations. > > > > IMHO, it is valuable to add a requirement in the I-D among these > lines. >=20 > I agree it would be valuable. >=20 > How about in CGN Requirements "bis", though? I would hate to delay > publication of the CGN Requirements draft while we're working through > which mechanism to standardize. >=20 > -d From dwing@cisco.com Tue Mar 15 10:38:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7847E3A6971 for ; Tue, 15 Mar 2011 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 BvlskGu0E9wo for ; Tue, 15 Mar 2011 10:38:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DCD953A6D21 for ; Tue, 15 Mar 2011 10:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1661; q=dns/txt; s=iport; t=1300210822; x=1301420422; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=oo77zo/95GCYcCh/Oq5sLDkswfRbC5NXPCGFJgTNNUQ=; b=iGia8x7a5r0Prf/mizF2T1Xr7r/dDEiEQ2rRlroYDEzZNKu+KPLeB5aX oPjWZO+lSFIUbeysuPDavAVffsSiEUs70B9H8O+mVfwyRDaUZCI+7pk5m fIBHcXRQ0hD/4wJAQ2FuLExTuw1eRfMPkSJ8dcCEHYqxYJyw0shjnmdcX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMBANZAf02Q/khNgWdsb2JhbACYSj+BJYtaFAEBFiYlpg+dBYViBIUw X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="79311166" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Mar 2011 17:40:21 +0000 Received: from dwingWS ([10.32.240.196]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHeKXs016323; Tue, 15 Mar 2011 17:40:20 GMT From: "Dan Wing" To: References: <4D713258.3050105@viagenie.ca> In-Reply-To: <4D713258.3050105@viagenie.ca> Date: Tue, 15 Mar 2011 10:40:19 -0700 Message-ID: <126301cbe338$0ea0e410$2be2ac30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvam8r0nwMrNNI1TP6ie3ENGAGIQwInC0JQ Content-language: en-us Cc: 'Jean-Philippe Dionne' Subject: Re: [BEHAVE] Fwd: I-D Action:draft-jpdionne-behave-nat64-mib-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: Tue, 15 Mar 2011 17:38:58 -0000 I would really like folks to review this. We lack both a NAT64 and a CGN-appropriate NAT44 MIB, and this gives us one of them. -d > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Jean-Philippe Dionne > Sent: Friday, March 04, 2011 10:41 AM > To: behave@ietf.org > Subject: [BEHAVE] Fwd: I-D Action:draft-jpdionne-behave-nat64-mib- > 00.txt > > Hi, > > A modification of the NAT-MIB is proposed to take into consideration > NAT64. Comments are welcomed. > > Thanks > Jean-Philippe Dionne > > -------- Original Message -------- > Subject: I-D Action:draft-jpdionne-behave-nat64-mib-00.txt > Date: Fri, 04 Mar 2011 07:30:02 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NAT64 Management Information Base (MIB) > Author(s) : J. Dionne, M. Blanchet > Filename : draft-jpdionne-behave-nat64-mib-00.txt > Pages : 11 > Date : 2011-03-04 > > This memo describes the NAT64 Management Information Base. It reuses > the NAT-MIB and add specific NAT64 variables. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jpdionne-behave-nat64-mib- > 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. From rpenno@juniper.net Tue Mar 15 10:41:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A9A3A6DBA for ; Tue, 15 Mar 2011 10:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 VU0jhCV2OLSi for ; Tue, 15 Mar 2011 10:41:00 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 093523A6DAF for ; Tue, 15 Mar 2011 10:40:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTX+k+2PnZIgNGxC59jt7LLIdXO24AMog@postini.com; Tue, 15 Mar 2011 10:42:25 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 10:40:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 13:41:43 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 13:41:41 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sT Message-ID: In-Reply-To: <123501cbe335$1e1537f0$5a3fa7d0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:41:01 -0000 This seems another incarnation of the 'log' problem. BTW, it is not clear to me that "A future version of this specification is expected to recommend using one of these mechanisms." On 3/15/11 10:19 AM, "Dan Wing" wrote: > Perhaps "There is ongoing work to allow servers to identify subscribers > initiating connections, to facilitate tracability and blocking of > subscribers abusing a service (e.g., DoS attacks). A future > version of this specification is expected to recommend using > one of these mechanisms." From rpenno@juniper.net Tue Mar 15 10:44:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886A73A6D39 for ; Tue, 15 Mar 2011 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 9MKOH0JNEWUe for ; Tue, 15 Mar 2011 10:44:44 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id EFEDC3A6971 for ; Tue, 15 Mar 2011 10:44:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTX+l3Zmcw10Vf5dF0qg2gvM92SzkjsZC@postini.com; Tue, 15 Mar 2011 10:46:10 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 10:40:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 13:41:56 -0400 From: Reinaldo Penno To: "mohamed.boucadair@orange-ftgroup.com" , Simon Perreault Date: Tue, 15 Mar 2011 13:41:51 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWgAA6etwAAI7pF8= Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3C30@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:44:45 -0000 On 3/15/11 9:47 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Med: It benefits to the users, service providers and content providers: > * a user won't be impacted by a misbehaving action of another user sharin= g the > same IP address. See > http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01= #sect > ion-1 for more details. I think the solution does not fit the problem. Can you elaborate on an actual use case from the top? > * a service provider won't receive calls to hot-lines (OPEX reduction) It will not receive calls or it will receive calls but will have more information to go with them? The identify of the user can be determined by the ISP through NAT logs base= d on public source IP, port alone. Any action by the ISP will need to be done on the private side anyway where there is a 'stable' IP address. This seems another incarnation of the 'log' problem. > * content providers: service experience. Service experience to the content provider or the subscriber? Can you elaborate in a little more detail how subscribers will benefit from this? BTW, I'm not really opposed to this at this point to this but it is not clear to me what exactly we are trying to solve and for which purpose. "1.1. Problem to Be Solved Observation: Today, servers use the source IPv4 address as an identifier to treat some incoming connections differently." From dwing@cisco.com Tue Mar 15 10:51:39 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3230B3A6D54 for ; Tue, 15 Mar 2011 10:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 731oZb77Gzfa for ; Tue, 15 Mar 2011 10:51:37 -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 3DED13A6971 for ; Tue, 15 Mar 2011 10:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=734; q=dns/txt; s=iport; t=1300211581; x=1301421181; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ojyVMZFXqlYnv8863sNssbCOxikj2AonION6T+taN9E=; b=Bs5tko54bDN3W0YO+k3pge+JObO0OiAvTbAZx4nm9W5KD0lqZn/Eni/W 1VYcQU2y2uc11/BS9kHdLMB6hsPjKC/vCV0STu0IZOvZsay6FhpB2cuRo cUf23L2Oe9z1tf5zWcq1/+9rO+RfVytkkuW4z1kVv5FyufXoUBlIwfZXj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAONDf02tJXG8/2dsb2JhbACYSoFki1p3pXudBoViBIUw X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="320566845" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 17:53:01 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHr0Ue025745; Tue, 15 Mar 2011 17:53:00 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 10:53:00 -0700 Message-ID: <127201cbe339$d357aa90$7a06ffb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25wAGI9Nw Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:51:39 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 7:56 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: SPAM Protection > > Re-, > > An explicit requirement about the support of means to protect against > SPAM should be IMO added to the req list. For instance the default > behaviour would be the CGN block port 25 for SMTP. That is an operational policy of an ISP, not a CGN. Does IETF have any existing recommendation to block outbound TCP/25? If not, I don't believe we could create one in BEHAVE. -d From dwing@cisco.com Tue Mar 15 10:53:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4583A6DBC for ; Tue, 15 Mar 2011 10:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.24 X-Spam-Level: X-Spam-Status: No, score=-109.24 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, 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 dgwkGHz4I7uS for ; Tue, 15 Mar 2011 10:53:53 -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 684CC3A6971 for ; Tue, 15 Mar 2011 10:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1039; q=dns/txt; s=iport; t=1300211718; x=1301421318; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=npAlzabMyn6wnqjdrydGawhj3dmsY68AtyKd/d8ac8Y=; b=YlwJRSxwoyGw0vIdJtVaf7FN+k0Z65OhFq262soeEMwAFlc0MuQ/MYQw wTwJj5OMEVtwnbEnqJ0a1a1yWee74nXisY2owAj40DA/j0ujmyghMKmMk 3g+fFVjaYqUgfvuuVq2ww6wcu8WNBov4+psPfqiu5w5TL8+o6RsoJLnK9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsACAFtEf02tJXG+/2dsb2JhbACYS4Fki1poD6V6nQaCf4JjBIUw X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="278271141" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2011 17:55:18 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHtHMd018560; Tue, 15 Mar 2011 17:55:17 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 10:55:17 -0700 Message-ID: <127301cbe33a$251a9ae0$6f4fd0a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIcbO4NKW9aBHQ+ybE/15DgVsuwAGBrdw Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:53:54 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 8:01 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: NAT MIB > > Re-, > > A requirement to mention that appropriate MIB modules are to be > supported by the CGN is needed. > > At least RFC 4008 is needed. FWIW, we have looked at RFC4008 for a CGN. It seems inadequate for a CGN -- it lacks ability to alarm if a user is reaching or has exceeded things like their port quota. Also, walking that MIB would take a considerable amount of time on a CGN, due to the table design. > Tunnel MIB (RFC 4087) is to be supported for DS-Lite CGN. Did SOFTWIRE require that MIB for Dual-Stack Lite? -d > Cheers, > Med > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Mar 15 10:54:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A863A6E2E for ; Tue, 15 Mar 2011 10:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.258 X-Spam-Level: X-Spam-Status: No, score=-110.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 mWY8t4xjDUZD for ; Tue, 15 Mar 2011 10:54:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 63EDC3A6971 for ; Tue, 15 Mar 2011 10:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=762; q=dns/txt; s=iport; t=1300211763; x=1301421363; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=wXGBXE/ww/4EcSkKphgu4U/GnE4a5JyvDCocMLQjx0c=; b=Vck1EpTZTLAoDQ5Pc0CGyOqZYhhL3Gdju7aId/LvwFmM/h2NxJDvga0d 3OKmpOyb9jTdpmSw4fZnqJBEXRydGYICk7MpRUbqpzovwbiyC5Hajn78g DGNoMGLhY5eeJP9dlQ/zfnoAxFXXttV5ypxNJSHgfCvZzJiNsOOk4RiIF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAEpFf02tJV2d/2dsb2JhbACYS4Fki1p3pXSdBoViBIUw X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="225475136" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2011 17:55:48 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHtdab025019; Tue, 15 Mar 2011 17:55:39 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 10:55:39 -0700 Message-ID: <127401cbe33a$322a1c60$967e5520$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQ Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:54:38 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 8:07 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: Port Set Assignment > > Re-, > > Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn- > requirements-01#section-5 discusses various modes for the port > assignment but there is no explicit requirement. > > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) > support the ability to assign port sets. Why? -d > The selection of the dynamic > mode vs. port set is deployment-specific. > > Cheers, > Med From dwing@cisco.com Tue Mar 15 10:55:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BD93A6DFB for ; Tue, 15 Mar 2011 10:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.268 X-Spam-Level: X-Spam-Status: No, score=-110.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 MdTGcQZ5SJlX for ; Tue, 15 Mar 2011 10:55:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7B01B3A6E21 for ; Tue, 15 Mar 2011 10:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1018; q=dns/txt; s=iport; t=1300211805; x=1301421405; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=pY+DisdMxQ7Pf85ki+75qTHX6dWzyM3Hg4y94H+NGIU=; b=i7ci5VLXfjxBnSi7KQmSeU1OD6dN/n6gHUrr3ngBtGtajubTl1udWZUF enJU6Jfca1SeXpnbODS5c62L2YJh77tTzUtg3rvBb5glO49mE610S0O1s +sHrfxpd4AJtG3h5IU135y4pUZ4IyQRYOmu/3KiByvuctUzitwRRpOp5q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAEpFf02tJV2Y/2dsb2JhbACYS4Fki1p3pXSdBoViBIUw X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="667386189" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 17:56:43 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHugBa005572; Tue, 15 Mar 2011 17:56:43 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 10:56:42 -0700 Message-ID: <127501cbe33a$57f0d380$07d27a80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIzBUZe2XYRcbSNCzhU8+x/B+hAAFwwTA Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:55:23 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 8:11 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: Hold-down pool > > Re-, > > An important missing requirement is the behaviour for the timeouted > ports; I refer to this as hold down pool. These ports SHOULD NOT be > assigned to new requesting users before the expiration of the hold down > timer. The purpose is to prevent users from receiving unwanted traffic. Agreed, that should be a requirement. > The hold-down timer and size of the pool should be configurable by the > operator. Can we make recommendations on the hold down timers for UDP, TCP, and ICMP? -d > Cheers, > Med > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Mar 15 10:58:14 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CD33A6DD7 for ; Tue, 15 Mar 2011 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.276 X-Spam-Level: X-Spam-Status: No, score=-110.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 O6+Oh8DCPEq7 for ; Tue, 15 Mar 2011 10:58:13 -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 186693A6971 for ; Tue, 15 Mar 2011 10:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2036; q=dns/txt; s=iport; t=1300211978; x=1301421578; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Aahhhb/uHDMjnISmHBvfcp7eBZpfCeQLuP2Czp+cR5c=; b=b/FzGJbfka4H6mgotY04xHHb0Lr7QmOMD600UCW3TuLQxbH9zEArOu2M ZufVDr28wL3pcMiWOE0SYTDqQTM11bvWUDT5GswwLCXVPjoPlnBnJif7C IURKxEbsS2hlNAUSp7eahv9RmaFqoy7PJm10UbaErnwXrgc7Ok8Ui//CH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAADpGf02tJXG+/2dsb2JhbACYTIFki1p3pXmdBYViBIUwjSY X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="320569593" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 17:59:38 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2FHxbpf021920; Tue, 15 Mar 2011 17:59:37 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Simon Perreault'" , References: <4D7F775D.6030303@viagenie.ca> In-Reply-To: Date: Tue, 15 Mar 2011 10:59:36 -0700 Message-ID: <127601cbe33a$bfeb0550$3fc10ff0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAScGWA= Content-language: en-us Cc: behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:58:14 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 8:46 AM > To: Simon Perreault; mohamed.boucadair@orange-ftgroup.com > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > I believe we need much more discussion on this requirement before it > makes > to the I-D. There are security issues, subscriber privacy issues, > performance issues, amongst others. Not to mention that there are some > 6 different techniques. I agree with all your points except 'subscriber privacy issues'. Subscribers, today, generally have publicly-routable IPv4 addresses. Those subscribers disclose their IP address every time they connect to a website -- it's in the source IP address field of the IP header. All of the techniques preserve that same information, in the face of a CGN. -d > > > On 3/15/11 7:27 AM, "Simon Perreault" > wrote: > > > On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: > >> As you know, several issues are encountered when CGNs are used (see > >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing- > issues-05 for > >> more details). > >> > >> In order to mitigate some of the issues listed in the above I-D, the > CGN > >> may inject an information which will be used by remote servers to > >> disambiguate users. FWIW, > >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal- > analysis-01 > >> analyzes > >> a set of candidates solutions and identifies some limitations. > >> > >> IMHO, it is valuable to add a requirement in the I-D among these > lines. > > > > I'll definitely need WG feedback on this. > > > > Thanks, > > Simon > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Mar 15 11:02:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51313A6DD4 for ; Tue, 15 Mar 2011 11:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.285 X-Spam-Level: X-Spam-Status: No, score=-110.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 9nJ21Iodp5lP for ; Tue, 15 Mar 2011 11:02:12 -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 BEC983A6971 for ; Tue, 15 Mar 2011 11:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3366; q=dns/txt; s=iport; t=1300212218; x=1301421818; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=PD8H7sXWJhy07VY4owI509srD9lSUTpYAKbriNZEs6Y=; b=OVqwwNjl3AAYasyD25V2Nw9imGOZ13NeA8kt6qFiC0xYjXAAyebJ8qMp v77o7XxeVUHIztWNSbRiPkQwIsIQzMN8Ti69KcojW5reHG/hwSHF2fRiG 8FAbzdIuY/wml6vsYYaKPoQeuQkwToltMGIWw/tDStlR6MynANwU3Me8k M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAHdGf02tJXHA/2dsb2JhbACYTIFki1p3pXmdBYViBIUwjSY X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="667389470" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 18:03:37 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FI3aRb028412; Tue, 15 Mar 2011 18:03:36 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , "'Simon Perreault'" References: <94C682931C08B048B7A8645303FDC9F33C4DBA3BD6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Tue, 15 Mar 2011 11:03:36 -0700 Message-ID: <127701cbe33b$4e8d9bb0$eba8d310$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWgADyYQg Content-language: en-us Cc: behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:02:13 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 9:12 AM > To: mohamed.boucadair@orange-ftgroup.com; Simon Perreault > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 >=20 >=20 >=20 > On 3/15/11 8:54 AM, "mohamed.boucadair@orange-ftgroup.com" > wrote: >=20 > > Hi Reinaldo, > > > > Yes, this needs discussion. > > > > As for the privacy, I don't see an issue there since the exposed > information > > is the same as the source IP address (when there is no NAT). >=20 > If you take NAT as the new baseline, then there is a change in = relation > to > that. Look at this another way. Will this requirement apply to CPEs as > well > so third parties can differentiate between several users at the home? > Why > not? >=20 > BTW, Can you explain who this requirement will benefit? It benefits anyone who is operating a server -- today -- that is=20 throttling connections from certain IP addresses due to abuse. If both users and abusers are sharing the same IPv4 address, the server cannot differentiate between the user and the abuser, and will have to degrade service to legitimate users. =20 If you run an ssh server on port 22 on the Internet, you are undoubtedly familiar with tools such as DenyHosts, Banshee, SSHblock, and other similar tools. Those are examples of these sorts of problems and deployed solutions, at a small scale. -d > > > > Cheers, > > Med > > > > -----Message d'origine----- > > De : Reinaldo Penno [mailto:rpenno@juniper.net] > > Envoy=E9 : mardi 15 mars 2011 16:46 > > =C0 : Simon Perreault; BOUCADAIR Mohamed OLNC/NAD/TIP > > Cc : 'behave' <(behave@ietf.org)>; > > draft-ietf-behave-lsn-requirements@tools.ietf.org > > Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > > > I believe we need much more discussion on this requirement before it > makes > > to the I-D. There are security issues, subscriber privacy issues, > > performance issues, amongst others. Not to mention that there are > some 6 > > different techniques. > > > > > > On 3/15/11 7:27 AM, "Simon Perreault" > wrote: > > > >> On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: > >>> As you know, several issues are encountered when CGNs are used = (see > >>> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing- > issues-05 > >>> for > >>> more details). > >>> > >>> In order to mitigate some of the issues listed in the above I-D, > the CGN > >>> may inject an information which will be used by remote servers to > >>> disambiguate users. FWIW, > >>> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal- > analysis-01 > >>> analyzes > >>> a set of candidates solutions and identifies some limitations. > >>> > >>> IMHO, it is valuable to add a requirement in the I-D among these > lines. > >> > >> I'll definitely need WG feedback on this. > >> > >> Thanks, > >> Simon > > >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 11:07:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17143A6B10 for ; Tue, 15 Mar 2011 11:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 wxWaewtzxu8q for ; Tue, 15 Mar 2011 11:07:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id B43A73A6971 for ; Tue, 15 Mar 2011 11:06:58 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C41E122C58E; Tue, 15 Mar 2011 19:08:22 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A967E23805E; Tue, 15 Mar 2011 19:08:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 15 Mar 2011 19:08:22 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 19:08:21 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25wAGI9NwAAAm27E= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> In-Reply-To: <127201cbe339$d357aa90$7a06ffb0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.153320 Cc: "behave@ietf.org" Subject: [BEHAVE] RE : CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:07:02 -0000 Re-, Port 25 is provided as an example. The functional requirement can be reworded to something like: "the CGN SHOU= LD be able to block some ports. The ports to be prohibited MUST be configur= able."=20 Please don"t forget the CGN we are talking about can be a DS-Lite CGN: the = CGN is the place to access the IPv4 packet. "Legacy" filters to prevent SP= AM as deployed in operational networks are not able to inspect IPv4-in IPv6= packets; equivalent function is needed in the CGN.=20 Cheers, Med ________________________________________ De : Dan Wing [dwing@cisco.com] Date d'envoi : mardi 15 mars 2011 18:53 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: SPAM Protection > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 7:56 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: SPAM Protection > > Re-, > > An explicit requirement about the support of means to protect against > SPAM should be IMO added to the req list. For instance the default > behaviour would be the CGN block port 25 for SMTP. That is an operational policy of an ISP, not a CGN. Does IETF have any existing recommendation to block outbound TCP/25? If not, I don't believe we could create one in BEHAVE. -d From dwing@cisco.com Tue Mar 15 11:07:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB8D3A6E42 for ; Tue, 15 Mar 2011 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.255 X-Spam-Level: X-Spam-Status: No, score=-109.255 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, 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 kHaODCDIoEA7 for ; Tue, 15 Mar 2011 11:07:16 -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 AF5753A6B10 for ; Tue, 15 Mar 2011 11:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=940; q=dns/txt; s=iport; t=1300212518; x=1301422118; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=/0/JvxQdw6PN5rs+LplRut/Hu9+vgvgO4mt+VEYryNs=; b=FxNvYaE+CAjMIIipWytHnxOAyk9y+maWolR74FpdlhWRZLcKPHI9++5E +BePUYYbjAsVVnKiIGKdZFl/tIryfmqnIyoAn2lCQ7R2Mlk3Ws4QBUVPk 5xtwhCF8b0rBtR2KF1Ytbsgzd+5ihGaAFPfBdHy5D3jedsQXRpgjW/YMe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgNAGZHf02tJXHA/2dsb2JhbACaMItaaA+IQZ0onQWFYgSFMA X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="320574395" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 18:08:28 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FI8RCc031281; Tue, 15 Mar 2011 18:08:28 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 11:08:27 -0700 Message-ID: <12a101cbe33b$fc20e160$f462a420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjG0cPCkKBJk7TSraF0yZ4hDVV/gAC5QxQ Content-language: en-us Cc: behave@ietf.org, 'Joe Touch' Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:07:17 -0000 > As for the re-writing of the IP-ID field, a requirement reflecting what > is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id- > update-02#section-9 should be added to the I-D. BEHAVE has documented how popular layer 4 protocols are translated on today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). Those documents provide minimal guidance, in an attempt to improve NAT operation. BEHAVE has not published a document on how IP is translated. That section describes how to translate IP, and requires a NAT reassemble fragments and re-write the IPID. The requirement is not solely on a NAT but, rather, on any sort of address-sharing device (to include 4rd, IVI, and others in the "A+P family"). Unfortunate to say, but I do not foresee NAT vendors implementing that requirement. Joe, I assume there is demonstrated harm occurring on the Internet where IPIDs collided? -d From dwing@cisco.com Tue Mar 15 11:10:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94CD3A6E44 for ; Tue, 15 Mar 2011 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.275 X-Spam-Level: X-Spam-Status: No, score=-110.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 3ogbnWnXdMTB for ; Tue, 15 Mar 2011 11:10:19 -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 68E273A6BE4 for ; Tue, 15 Mar 2011 11:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1289; q=dns/txt; s=iport; t=1300212704; x=1301422304; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Syr6kBd6JAwfCE1yHrBN3dPHJZVqhgZfFMonG8dhLqE=; b=dtxbG+B4LmYIArc2DDKxHlpUoUppHK6Z4axwL0yemUXwSBGhmf5FtUWd ux4iCJ7j5Z9MjRcvSe+HXRrCWBO+2ukQw0K7nUayF8fvhVi7J7UFRYDx6 1259pkeYdSaml/x3nzZZrSzzI0IenXIWPcJ7pvjVj0b5vKVm5IYUQgFaO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAAtJf02tJV2c/2dsb2JhbACYTIFki1p3pWSdAoJ7gmcEhTCNJg X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="347202402" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 18:11:43 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FIBgih014243; Tue, 15 Mar 2011 18:11:43 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <123501cbe335$1e1537f0$5a3fa7d0$@com> In-Reply-To: Date: Tue, 15 Mar 2011 11:11:42 -0700 Message-ID: <12a201cbe33c$70540ad0$50fc2070$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDA= Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:10:21 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 15, 2011 10:42 AM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > This seems another incarnation of the 'log' problem. No. It's quite different. Knowing your IP address is fe80::c126:c633:d2dc:8090 (according to your SMTP headers) doesn't tell me if someone else has acquired that IP address between when you last used it and a minute in the future. Only the entity that hands out your IP address could know that (e.g., your DHCPv6 server or something monitoring SLAAC). -d > BTW, it is not clear to me that "A future > version of this specification is expected to recommend using > one of these mechanisms." > > > On 3/15/11 10:19 AM, "Dan Wing" wrote: > > > Perhaps "There is ongoing work to allow servers to identify > subscribers > > initiating connections, to facilitate tracability and blocking of > > subscribers abusing a service (e.g., DoS attacks). A future > > version of this specification is expected to recommend using > > one of these mechanisms." From dwing@cisco.com Tue Mar 15 11:14:26 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7279E3A6BE4 for ; Tue, 15 Mar 2011 11:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.283 X-Spam-Level: X-Spam-Status: No, score=-110.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 UMYgAB4e7gyd for ; Tue, 15 Mar 2011 11:14:24 -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 BF7BD3A6B10 for ; Tue, 15 Mar 2011 11:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2445; q=dns/txt; s=iport; t=1300212950; x=1301422550; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=fP87Ke8PeOWPFxLwCiha8tJZ62LAaQJ1HPekuW+OluM=; b=VqJoHaxGiIfL16NagNgtDfGjtJkfZND8S8rYWKyjrXfc7+/nJklGJgk3 q2+ET+L5IxBKxxgN431CO+JfEyNfIwroRrDw2WcLyllbFsL0HGCUCTc5K +drMb4f5H8VmbSQawDVDBMgYt7ugPmAerCZ992PjdBitZGQjeiZJ1jSqj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAADhKf02tJV2c/2dsb2JhbACYTIFki1p3pV+dAoViBIUw X-IronPort-AV: E=Sophos;i="4.63,188,1299456000"; d="scan'208";a="347205981" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 18:15:49 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FIFmZh016699; Tue, 15 Mar 2011 18:15:49 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 11:15:48 -0700 Message-ID: <12b201cbe33d$03060ef0$09122cd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25wAGI9NwAAAm27EAAJS3UA== Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:14:26 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 11:08 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >=20 > Re-, >=20 > Port 25 is provided as an example. > The functional requirement can be reworded to something like: "the CGN > SHOULD be able to block some ports. The ports to be prohibited MUST be > configurable." >=20 > Please don"t forget the CGN we are talking about can be a DS-Lite CGN: > the CGN is the place to access the IPv4 packet. "Legacy" filters to > prevent SPAM as deployed in operational networks are not able to > inspect IPv4-in IPv6 packets; equivalent function is needed in the = CGN. I don't see this being a CGN requirement. I assume you want these ports blocked before they consume state in the CGN, which means they are blocked in *front* of the CGN function. In the AFTR architecture, it's somewhere between where the tunnel is unwrapped and the packets are NATted. Is that "in" the CGN? =20 Maybe Softwires should take on that requirment? Or are there non-DS-Lite scenarios where this is really something that only the CGN can do? -d > Cheers, > Med >=20 > ________________________________________ > De : Dan Wing [dwing@cisco.com] > Date d'envoi : mardi 15 mars 2011 18:53 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Tuesday, March 15, 2011 7:56 AM > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: 'behave' <(behave@ietf.org)> > > Subject: [BEHAVE] CGN REQ: SPAM Protection > > > > Re-, > > > > An explicit requirement about the support of means to protect = against > > SPAM should be IMO added to the req list. For instance the default > > behaviour would be the CGN block port 25 for SMTP. >=20 > That is an operational policy of an ISP, not a CGN. >=20 > Does IETF have any existing recommendation to block outbound TCP/25? > If > not, I don't believe we could create one in BEHAVE. >=20 > -d >=20 >=20 >=20 >=20 >=20 >=20 From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 11:17:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0A63A6C3C for ; Tue, 15 Mar 2011 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 VvBp11aVia1W for ; Tue, 15 Mar 2011 11:17:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 86B2D3A6B10 for ; Tue, 15 Mar 2011 11:17:28 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id EF0DE2AC4DE; Tue, 15 Mar 2011 19:18:52 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id D833DC805C; Tue, 15 Mar 2011 19:18:52 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 15 Mar 2011 19:18:53 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 19:18:51 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjE= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> In-Reply-To: <127401cbe33a$322a1c60$967e5520$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.165415 Cc: "behave@ietf.org" Subject: [BEHAVE] RE : CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:17:29 -0000 Re-, Please see inline. Cheers, Med ________________________________________ De : Dan Wing [dwing@cisco.com] Date d'envoi : mardi 15 mars 2011 18:55 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 8:07 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: Port Set Assignment > > Re-, > > Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn- > requirements-01#section-5 discusses various modes for the port > assignment but there is no explicit requirement. > > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) > support the ability to assign port sets. Why? Med: We can ask the other question around: why only the dynamic NAT should = be supported? More seriously, the use of port set has several advantages in term of log r= eduction and in some implementation(s) has important impact on performance= s (because of the per-entry write operations). Tests we have done for some = implementations showed severe degradation. FWIW, some CGN implementations s= upport only the port set allocation and the length of the port set is even = no configurable!=20 IMO, the decision to activate the port set or use the dynamic mode should l= eft to operators (enterprise, service providers, etc.). -d > The selection of the dynamic > mode vs. port set is deployment-specific. > > Cheers, > Med From tena@huawei.com Tue Mar 15 11:27:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8953A6E52; Tue, 15 Mar 2011 11:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.306 X-Spam-Level: X-Spam-Status: No, score=-106.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 PcZQMB00gneS; Tue, 15 Mar 2011 11:27:48 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id EB03D3A6E51; Tue, 15 Mar 2011 11:27:47 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI4004QD3CO2W@usaga02-in.huawei.com>; Tue, 15 Mar 2011 11:29:12 -0700 (PDT) Received: from TingZousc1 ([10.193.34.192]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI400JIE3CNV6@usaga02-in.huawei.com>; Tue, 15 Mar 2011 11:29:12 -0700 (PDT) Date: Tue, 15 Mar 2011 11:29:11 -0700 From: Tina Tsou In-reply-to: <127601cbe33a$bfeb0550$3fc10ff0$@com> To: 'Dan Wing' , 'Reinaldo Penno' , 'Simon Perreault' , mohamed.boucadair@orange-ftgroup.com Message-id: <003801cbe33e$e1f023c0$a5d06b40$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAScGWAAALt2UA== References: <4D7F775D.6030303@viagenie.ca> <127601cbe33a$bfeb0550$3fc10ff0$@com> Cc: int-area@ietf.org, behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:27:49 -0000 A related I-D: https://datatracker.ietf.org/doc/draft-chen-intarea-v4-uid-header-option/ IPv4 Header Option for User Identification in CGN Scenario My co-authors are currently doing tests on draft-chen-intarea-v4-uid-header-option. After the test, we may have more input. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing Sent: Tuesday, March 15, 2011 11:00 AM To: 'Reinaldo Penno'; 'Simon Perreault'; mohamed.boucadair@orange-ftgroup.com Cc: behave@ietf.org; draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 8:46 AM > To: Simon Perreault; mohamed.boucadair@orange-ftgroup.com > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > I believe we need much more discussion on this requirement before it > makes > to the I-D. There are security issues, subscriber privacy issues, > performance issues, amongst others. Not to mention that there are some > 6 different techniques. I agree with all your points except 'subscriber privacy issues'. Subscribers, today, generally have publicly-routable IPv4 addresses. Those subscribers disclose their IP address every time they connect to a website -- it's in the source IP address field of the IP header. All of the techniques preserve that same information, in the face of a CGN. -d > > > On 3/15/11 7:27 AM, "Simon Perreault" > wrote: > > > On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: > >> As you know, several issues are encountered when CGNs are used (see > >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing- > issues-05 for > >> more details). > >> > >> In order to mitigate some of the issues listed in the above I-D, the > CGN > >> may inject an information which will be used by remote servers to > >> disambiguate users. FWIW, > >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal- > analysis-01 > >> analyzes > >> a set of candidates solutions and identifies some limitations. > >> > >> IMHO, it is valuable to add a requirement in the I-D among these > lines. > > > > I'll definitely need WG feedback on this. > > > > Thanks, > > Simon > > _______________________________________________ > 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 rpenno@juniper.net Tue Mar 15 11:29:27 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18033A6E5E for ; Tue, 15 Mar 2011 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 378pMw2UN36X for ; Tue, 15 Mar 2011 11:29:24 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 2B4AF3A6D78 for ; Tue, 15 Mar 2011 11:29:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTX+wU1tatCj2uc4QMwYy5yfmoHdArYrq@postini.com; Tue, 15 Mar 2011 11:30:49 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 11:25:31 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 14:26:36 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 14:26:34 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQ== Message-ID: In-Reply-To: <12a201cbe33c$70540ad0$50fc2070$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:29:27 -0000 On 3/15/11 11:11 AM, "Dan Wing" wrote: >> -----Original Message----- >> From: Reinaldo Penno [mailto:rpenno@juniper.net] >> Sent: Tuesday, March 15, 2011 10:42 AM >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- >> lsn-requirements@tools.ietf.org >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >>=20 >> This seems another incarnation of the 'log' problem. >=20 > No. It's quite different. Knowing your IP address is > fe80::c126:c633:d2dc:8090 (according to your SMTP headers) > doesn't tell me if someone else has acquired that IP address > between when you last used it and a minute in the future. > Only the entity that hands out your IP address could know that > (e.g., your DHCPv6 server or something monitoring SLAAC). Isn't this the same problem you were actively discussing on the PCP list: renumbering. Renumbering already exists today and can not be solved by wha= t the document proposes (conveying the private IP address, because it might have changed). A public IP can also be reused and the 'server' will not know, only the ISP. >=20 > -d >=20 >> BTW, it is not clear to me that "A future >> version of this specification is expected to recommend using >> one of these mechanisms." >>=20 >>=20 >> On 3/15/11 10:19 AM, "Dan Wing" wrote: >>=20 >>> Perhaps "There is ongoing work to allow servers to identify >> subscribers >>> initiating connections, to facilitate tracability and blocking of >>> subscribers abusing a service (e.g., DoS attacks). A future >>> version of this specification is expected to recommend using >>> one of these mechanisms." >=20 From dwing@cisco.com Tue Mar 15 11:45:05 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5533A6B1D for ; Tue, 15 Mar 2011 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.29 X-Spam-Level: X-Spam-Status: No, score=-110.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 59JxVVhlpAWJ for ; Tue, 15 Mar 2011 11:45:04 -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 AD8173A6B10 for ; Tue, 15 Mar 2011 11:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3113; q=dns/txt; s=iport; t=1300214790; x=1301424390; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eVgDfCFbmgxAZwEl0e9YjIrlYfpHRSpjDzatvbYQYPA=; b=DZjxYwZfTvbwG21yG5s2WDHwGB9+DVqJl8cNlkJ1vgB9bvx4PmLQC8Q7 A+ycqve1Ypo+YNaGS3i5lCkYFjadjYGv8cCiOhDk2QNyu7/KucS+omz2z rXm/UQljr66KWCXGeFcvZfXYF1lttM3Kned5Toc6MwlFIQ4ufqWULWdeF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAD9Rf02tJV2c/2dsb2JhbACYS4Fki1p3pVudBYJ7gmcEhTCNJg X-IronPort-AV: E=Sophos;i="4.63,189,1299456000"; d="scan'208";a="347230964" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 18:46:29 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FIkSEC032110; Tue, 15 Mar 2011 18:46:29 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <12a201cbe33c$70540ad0$50fc2070$@com> In-Reply-To: Date: Tue, 15 Mar 2011 11:46:28 -0700 Message-ID: <12e801cbe341$4bb98560$e32c9020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqw Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:45:05 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 15, 2011 11:27 AM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > > > > On 3/15/11 11:11 AM, "Dan Wing" wrote: > > >> -----Original Message----- > >> From: Reinaldo Penno [mailto:rpenno@juniper.net] > >> Sent: Tuesday, March 15, 2011 10:42 AM > >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- > behave- > >> lsn-requirements@tools.ietf.org > >> Cc: behave@ietf.org > >> Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > >> > >> This seems another incarnation of the 'log' problem. > > > > No. It's quite different. Knowing your IP address is > > fe80::c126:c633:d2dc:8090 (according to your SMTP headers) > > doesn't tell me if someone else has acquired that IP address > > between when you last used it and a minute in the future. > > Only the entity that hands out your IP address could know that > > (e.g., your DHCPv6 server or something monitoring SLAAC). > > Isn't this the same problem you were actively discussing on the PCP > list: > renumbering. Renumbering already exists today and can not be solved by > what > the document proposes (conveying the private IP address, because it > might > have changed). A public IP can also be reused and the 'server' will not > know, only the ISP. Yes, the subscriber can be renumbered today -- and they are renumbered today. Subscribers will be renumbered tomorrow. Yes, renumbering will cause some IP addresses to continue to have a "poor reputation" for some-amount-of-time after the abuser was using the address. All of these existing systems time out those addresses. The same is true of credit scores in real life, scary parts of town (which are cleaned up with additional police presence), and a lot of other things. The alternative is that everyone sharing the same IPv4 address be put into the same low-quality of service, such as throttling all of their activity, challenging them all with captchas, or blocking them outright. People will argue that ruining the IPv4 Internet will create an incentive for people and content providers to move to IPv6. Which is true. However, ruining the IPv4 Internet harms the ISP's business and the content provider's business. -d > > > > > -d > > > >> BTW, it is not clear to me that "A future > >> version of this specification is expected to recommend using > >> one of these mechanisms." > >> > >> > >> On 3/15/11 10:19 AM, "Dan Wing" wrote: > >> > >>> Perhaps "There is ongoing work to allow servers to identify > >> subscribers > >>> initiating connections, to facilitate tracability and blocking of > >>> subscribers abusing a service (e.g., DoS attacks). A future > >>> version of this specification is expected to recommend using > >>> one of these mechanisms." > > From jmh@joelhalpern.com Tue Mar 15 11:49:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD5D3A6A7C for ; Tue, 15 Mar 2011 11:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.791 X-Spam-Level: X-Spam-Status: No, score=-101.791 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, 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 VXUxjoIyIPPt for ; Tue, 15 Mar 2011 11:49:43 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 05B213A6A26 for ; Tue, 15 Mar 2011 11:49:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8387F4300E5 for ; Tue, 15 Mar 2011 11:51:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 0013A4300E1 for ; Tue, 15 Mar 2011 11:51:07 -0700 (PDT) Message-ID: <4D7FB517.3030708@joelhalpern.com> Date: Tue, 15 Mar 2011 14:51:03 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 CC: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> In-Reply-To: <12b201cbe33d$03060ef0$09122cd0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:49:43 -0000 I would agree with dan. What you are describing is a firewalling or filtering function. While those are functions operators want, those are not the function of the CGN. Divide a problem a conquering the pieces serves us well. Yours, Joel On 3/15/2011 2:15 PM, Dan Wing wrote: >> -----Original Message----- >> From: mohamed.boucadair@orange-ftgroup.com >> [mailto:mohamed.boucadair@orange-ftgroup.com] >> Sent: Tuesday, March 15, 2011 11:08 AM >> To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org >> Cc: behave@ietf.org >> Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >> >> Re-, >> >> Port 25 is provided as an example. >> The functional requirement can be reworded to something like: "the CGN >> SHOULD be able to block some ports. The ports to be prohibited MUST be >> configurable." >> >> Please don"t forget the CGN we are talking about can be a DS-Lite CGN: >> the CGN is the place to access the IPv4 packet. "Legacy" filters to >> prevent SPAM as deployed in operational networks are not able to >> inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN. > > I don't see this being a CGN requirement. I assume you want these > ports blocked before they consume state in the CGN, which means they > are blocked in *front* of the CGN function. In the AFTR architecture, > it's somewhere between where the tunnel is unwrapped and the packets > are NATted. Is that "in" the CGN? > > Maybe Softwires should take on that requirment? Or are there > non-DS-Lite scenarios where this is really something that only > the CGN can do? > > -d > > >> Cheers, >> Med >> >> ________________________________________ >> De : Dan Wing [dwing@cisco.com] >> Date d'envoi : mardi 15 mars 2011 18:53 >> : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- >> requirements@tools.ietf.org >> Cc : behave@ietf.org >> Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of mohamed.boucadair@orange-ftgroup.com >>> Sent: Tuesday, March 15, 2011 7:56 AM >>> To: draft-ietf-behave-lsn-requirements@tools.ietf.org >>> Cc: 'behave'<(behave@ietf.org)> >>> Subject: [BEHAVE] CGN REQ: SPAM Protection >>> >>> Re-, >>> >>> An explicit requirement about the support of means to protect against >>> SPAM should be IMO added to the req list. For instance the default >>> behaviour would be the CGN block port 25 for SMTP. >> >> That is an operational policy of an ISP, not a CGN. >> >> Does IETF have any existing recommendation to block outbound TCP/25? >> If >> not, I don't believe we could create one in BEHAVE. >> >> -d >> >> >> >> >> >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Tue Mar 15 11:50:07 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0403A6B1D for ; Tue, 15 Mar 2011 11:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.297 X-Spam-Level: X-Spam-Status: No, score=-110.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 vhZprI7xIemH for ; Tue, 15 Mar 2011 11:50:04 -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 1F8A63A6A7C for ; Tue, 15 Mar 2011 11:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2784; q=dns/txt; s=iport; t=1300215089; x=1301424689; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=bkZ6KJsL4be0QAEFK+iT+3bUGXqtODLRoEQgGa6U6Ks=; b=WgvQrzLg065nL0HPyrvnZ8qfk9jAFGS/Jz8ylNS5cjzidbfMTtL3r/M8 WxZ6f7HPPFNuh0eHZnd0h67lQLN/+M4BHMYccypmzagtI5lZwY9rDoF5r IrY0bLDjaLCx17/rUU4oMLMopSqoyT/DX+PBW3Vrd3TL4LQcEwwhmzc8z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAGtSf02tJV2c/2dsb2JhbACYS4Fki1p3pT6dBYViBIUw X-IronPort-AV: E=Sophos;i="4.63,189,1299456000"; d="scan'208";a="347234570" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 18:51:29 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FIpSK0002461; Tue, 15 Mar 2011 18:51:28 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 11:51:28 -0700 Message-ID: <12f501cbe341$fe3310d0$fa993270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcA== Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:50:07 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 11:19 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med > ________________________________________ > De : Dan Wing [dwing@cisco.com] > Date d'envoi : mardi 15 mars 2011 18:55 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Tuesday, March 15, 2011 8:07 AM > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: 'behave' <(behave@ietf.org)> > > Subject: [BEHAVE] CGN REQ: Port Set Assignment > > > > Re-, > > > > Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn- > > requirements-01#section-5 discusses various modes for the port > > assignment but there is no explicit requirement. > > > > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) > > support the ability to assign port sets. >=20 > Why? >=20 > Med: We can ask the other question around: why only the dynamic NAT > should be supported? Because that's what NATs do today -- NATs in people's homes and deployed by enterprises do that today. > More seriously, the use of port set has several advantages in term of > log reduction and in some implementation(s) has important impact on > performances (because of the per-entry write operations). Tests we = have > done for some implementations showed severe degradation. FWIW, some = CGN > implementations support only the port set allocation and the length of > the port set is even no configurable! Yes, well aware. > IMO, the decision to activate the port set or use the dynamic mode > should left to operators (enterprise, service providers, etc.). Their incentive is to reduce costs. But "port sets" (or "bulk port allocations", or whatever term) increase the attack surface of the subscribers, with no cost or security risk to the ISP. The incentives are in the wrong place. It's obvious what an ISP will do -- they will prefer to increase the attack surface of their subscribers. Speaking personally (not as chair), I do not support the=20 IETF making a recommendation that users be restricted to a fixed set of port numbers. -d =20 > -d >=20 > > The selection of the dynamic > > mode vs. port set is deployment-specific. > > > > Cheers, > > Med From touch@isi.edu Tue Mar 15 11:52:30 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5E93A6A7C for ; Tue, 15 Mar 2011 11:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.816 X-Spam-Level: X-Spam-Status: No, score=-103.816 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, 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 QxWEtBW-OwEU for ; Tue, 15 Mar 2011 11:52:29 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id AA00A3A6A72 for ; Tue, 15 Mar 2011 11:52:29 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p2FIqtxq012150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 15 Mar 2011 11:53:05 -0700 (PDT) Message-ID: <4D7FB586.7090503@isi.edu> Date: Tue, 15 Mar 2011 11:52:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Wing References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> <12a101cbe33b$fc20e160$f462a420$@com> In-Reply-To: <12a101cbe33b$fc20e160$f462a420$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p2FIqtxq012150 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:52:31 -0000 Hi, Dan, On 3/15/2011 11:08 AM, Dan Wing wrote: >> As for the re-writing of the IP-ID field, a requirement reflecting what >> is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id- >> update-02#section-9 should be added to the I-D. > > BEHAVE has documented how popular layer 4 protocols are translated on > today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). Those > documents provide minimal guidance, in an attempt to improve NAT > operation. BEHAVE has not published a document on how IP is > translated. > > That section describes how to translate IP, and requires a NAT > reassemble fragments and re-write the IPID. The requirement is > not solely on a NAT but, rather, on any sort of address-sharing > device (to include 4rd, IVI, and others in the "A+P family"). > > Unfortunate to say, but I do not foresee NAT vendors implementing > that requirement. Joe, I assume there is demonstrated harm > occurring on the Internet where IPIDs collided? It's difficult to show such measurements, as we don't have access to traffic behind NATs. The result of not rewriting the ID appropriately can be increased packet reassembly errors, some of which may be caught by TCP checksums, some may result in interrupted TLS connections, etc. I do understand that NAT vendors can't be expected to implement *any* standard; that's frankly their entire focus. That doesn't mean we can't or shouldn't hold them to such, however. I.e., *when* there are problems, we can stand behind their incorrect behavior as the cause, rather than simply saying "kids will be kids" and expecting the rest of the Internet to accommodate them. Joe From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 12:01:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236983A6E61 for ; Tue, 15 Mar 2011 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 jGK61S89RwO0 for ; Tue, 15 Mar 2011 12:01:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id E4BA43A6E77 for ; Tue, 15 Mar 2011 12:00:58 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 017263243A5; Tue, 15 Mar 2011 20:02:24 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D4E7523804B; Tue, 15 Mar 2011 20:02:23 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 15 Mar 2011 20:02:24 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 20:02:23 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/ Message-ID: <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr>, <12f501cbe341$fe3310d0$fa993270$@com> In-Reply-To: <12f501cbe341$fe3310d0$fa993270$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.15.165415 Cc: DENG Xiaohong ESP/PEK , "behave@ietf.org" Subject: [BEHAVE] RE : CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:01:21 -0000 Re- A "Port Set" does not mean necessarily "contiguous port range"! Both pure randomized port set or Simple port randomization with port sets c= an be considered. We have an implementation to assess the behavior of simple port randomizati= on (only two lines of codes are needed to implement it: the algorithm uses = the port mask and port value). Another solution to generate random ports is available at: http://tools.iet= f.org/html/draft-bajko-pripaddrassign-03#section-5. Cheers, Med ________________________________________ De : Dan Wing [dwing@cisco.com] Date d'envoi : mardi 15 mars 2011 19:51 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 11:19 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment > > Re-, > > Please see inline. > > Cheers, > Med > ________________________________________ > De : Dan Wing [dwing@cisco.com] > Date d'envoi : mardi 15 mars 2011 18:55 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Tuesday, March 15, 2011 8:07 AM > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: 'behave' <(behave@ietf.org)> > > Subject: [BEHAVE] CGN REQ: Port Set Assignment > > > > Re-, > > > > Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn- > > requirements-01#section-5 discusses various modes for the port > > assignment but there is no explicit requirement. > > > > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) > > support the ability to assign port sets. > > Why? > > Med: We can ask the other question around: why only the dynamic NAT > should be supported? Because that's what NATs do today -- NATs in people's homes and deployed by enterprises do that today. > More seriously, the use of port set has several advantages in term of > log reduction and in some implementation(s) has important impact on > performances (because of the per-entry write operations). Tests we have > done for some implementations showed severe degradation. FWIW, some CGN > implementations support only the port set allocation and the length of > the port set is even no configurable! Yes, well aware. > IMO, the decision to activate the port set or use the dynamic mode > should left to operators (enterprise, service providers, etc.). Their incentive is to reduce costs. But "port sets" (or "bulk port allocations", or whatever term) increase the attack surface of the subscribers, with no cost or security risk to the ISP. The incentives are in the wrong place. It's obvious what an ISP will do -- they will prefer to increase the attack surface of their subscribers. Speaking personally (not as chair), I do not support the IETF making a recommendation that users be restricted to a fixed set of port numbers. -d > -d > > > The selection of the dynamic > > mode vs. port set is deployment-specific. > > > > Cheers, > > Med From rpenno@juniper.net Tue Mar 15 12:06:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24FD3A6A72 for ; Tue, 15 Mar 2011 12:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 c5PJJEIaiJBL for ; Tue, 15 Mar 2011 12:06:03 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id E279A3A6B0D for ; Tue, 15 Mar 2011 12:06:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTX+467jru2UleNLMIN/t2HhME+1TMpEk@postini.com; Tue, 15 Mar 2011 12:07:28 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 12:05:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 15 Mar 2011 15:06:42 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 15:06:40 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDA= Message-ID: In-Reply-To: <12e801cbe341$4bb98560$e32c9020$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:06:04 -0000 But there are operational solutions for this problem which do not need man-in-the-middle rewrite. The abusers can be put in special public pool of address that is there for such sole purpose. BTW, this already done today in many different forms. On 3/15/11 11:46 AM, "Dan Wing" wrote: > The alternative is that everyone sharing the same IPv4 address be > put into the same low-quality of service, such as throttling all > of their activity, challenging them all with captchas, or blocking > them outright. From bschlies@cisco.com Tue Mar 15 12:14:48 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B7D3A6ACD for ; Tue, 15 Mar 2011 12:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9fxII2-jZuU for ; Tue, 15 Mar 2011 12:14:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CB8713A6A40 for ; Tue, 15 Mar 2011 12:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=739; q=dns/txt; s=iport; t=1300216573; x=1301426173; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=rl6Z6gZUVV1aF8ttYj0aWLhCfn9tW19WwdMsBtxEe5w=; b=QfK78lN+1ad/qlO27cYHJU1FaMgHfBb//DPmkm1ZKeyvZy/YaciUP2E+ CoqpSfidW4x16Z4zDY4nxmw0wGAFD1hv0hs8I01fRMYJaO/+RyIH+pVeK /1RE92rc84VE4k9NDr3P/71pvBU3CAIcF0NYs5TauRTqWf/DzBGeL6Q4z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAApYf02tJV2d/2dsb2JhbACmCXelL50GhWIEhTCHLYNV X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="225504692" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2011 19:16:12 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJGCce003520; Tue, 15 Mar 2011 19:16:12 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:16:12 -0500 Received: from 10.21.84.106 ([10.21.84.106]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 19:16:12 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 14:16:08 -0500 From: Benson Schliesser To: Simon Perreault , Message-ID: Thread-Topic: [BEHAVE] CGN REQ: IP-ID Thread-Index: AcvjRW/pA20Sc0cfv02H1viscdKDVQ== In-Reply-To: <4D7F75F1.5030601@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Mar 2011 19:16:12.0554 (UTC) FILETIME=[72A02EA0:01CBE345] Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:14:49 -0000 On 3/15/11 8:21 AM, "Simon Perreault" wrote: > On 2011-03-15 10:14, mohamed.boucadair@orange-ftgroup.com wrote: >> As for the re-writing of the IP-ID field, a requirement reflecting what >> is discussed in >> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02#section-9 >> should >> be added to the I-D. > > Unless the WG disagrees, I'll add a new requirement referring to that draft. Capturing this as a "SHOULD" is a good idea. However, it needs to be clear that the goal is to avoid ID overlap for a given set of flows - the goal is not necessarily to translate the IP ID field. The mechanism for avoiding IP ID overlap is is an implementation issue. Cheers, -Benson From bschlies@cisco.com Tue Mar 15 12:24:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8670A3A6B43 for ; Tue, 15 Mar 2011 12:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqUz6XvrKPzL for ; Tue, 15 Mar 2011 12:24:15 -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 1F9993A6B25 for ; Tue, 15 Mar 2011 12:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1256; q=dns/txt; s=iport; t=1300217140; x=1301426740; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=yEsSBeFN8UzpsXZpmHmjm7ku8J163AukEKoQsdL+mbk=; b=fDB4BXWSxT5EAgjKy7WuIz2xfNrxc5W63du869rab04HfYbwHA0HilGZ K4TJZWnjqMmhxS/rWI+gfgRCCe1/Q8oSRcagh6Q8uAkDz1M+MzyR2lXPg +1nhEHiIRsRnSXfuS9RWOEl33YE3OBQ1ShSzzJzqdj/Pr1P18ca6zchS9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK5Zf02tJXHA/2dsb2JhbACmCXelLZ0DhWIEhTCHLYNVgiQ X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="414666768" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2011 19:25:40 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJPeYw001965; Tue, 15 Mar 2011 19:25:40 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:25:40 -0500 Received: from 10.21.84.106 ([10.21.84.106]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 19:25:39 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 14:25:35 -0500 From: Benson Schliesser To: Simon Perreault , Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjRsHeKVmC2QRxHkO1YyHS/uiVMw== In-Reply-To: <4D7F775D.6030303@viagenie.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Mar 2011 19:25:40.0315 (UTC) FILETIME=[C509A2B0:01CBE346] Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:24:17 -0000 On 3/15/11 8:27 AM, "Simon Perreault" wrote: > On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: >> As you know, several issues are encountered when CGNs are used (see >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for >> more details). >> >> In order to mitigate some of the issues listed in the above I-D, the CGN >> may inject an information which will be used by remote servers to >> disambiguate users. FWIW, >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01 >> analyzes >> a set of candidates solutions and identifies some limitations. >> >> IMHO, it is valuable to add a requirement in the I-D among these lines. > > I'll definitely need WG feedback on this. I agree that user-hint would be a valuable feature for a CGN. But it is not a requirement for the successful operation of a CGN, and should not be included in the requirements document. Further, while I respect the analysis done in draft-boucadair-..., I don't yet think there is consensus on the user-hint technology. It would be inappropriate to pick one approach at this time, pending more operational experience and feedback. Cheers, -Benson From bschlies@cisco.com Tue Mar 15 12:30:10 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061363A6E79 for ; Tue, 15 Mar 2011 12:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DwmnDVTOX17 for ; Tue, 15 Mar 2011 12:30:06 -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 C4F9E3A6B49 for ; Tue, 15 Mar 2011 12:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=825; q=dns/txt; s=iport; t=1300217491; x=1301427091; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=FUIkrRLt23dq8MA+rRogOVTCPNHXLRg8iY3lDqYr6g8=; b=Lx328VYFlQZDExaaR2GAwUledDeh8Dn3JTQ8O4Lez+vqDl0nE/HRN8PH r/WPVlA8U0Gvnc+NwMj+JRaHLjEM0KqiPGk6lUzrseAQPTMVZbZG14N6d BlogKTyGExzKeKfuw3UVrzecBwbsB9L1gRxtU22m43bZm6I0T3ByGt2mW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANtaf02tJXHA/2dsb2JhbACmCXelIZ0ChWIEhTCHLYNV X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="414669633" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2011 19:31:23 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJVNBL004834; Tue, 15 Mar 2011 19:31:23 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:31:23 -0500 Received: from 10.21.84.106 ([10.21.84.106]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 19:31:22 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 14:31:18 -0500 From: Benson Schliesser To: , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAJOJc3 In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Mar 2011 19:31:23.0426 (UTC) FILETIME=[918C3820:01CBE347] Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:30:10 -0000 On 3/15/11 9:07 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Section 5 > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#section-5 > discusses various modes for the port assignment but there is no explicit > requirement. > > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) support the > ability to assign port sets. The selection of the dynamic mode vs. port set is > deployment-specific. I don't support this as a MUST or SHOULD. A port-set feature isn't a requirement for successful deployment of a CGN. In fact, a port-set feature might be seen to have negative implications for security, scale, etc. It is an implementation choice, and the requirements document ought to capture it as a MAY. Cheers, -Benson From bschlies@cisco.com Tue Mar 15 12:31:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574BD3A6B49 for ; Tue, 15 Mar 2011 12:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4HRwQqcmuHG for ; Tue, 15 Mar 2011 12:31:18 -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 353C93A68AF for ; Tue, 15 Mar 2011 12:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=613; q=dns/txt; s=iport; t=1300217563; x=1301427163; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=vWjQb8XwJFw3YKzN6SBk5P89K4UsyAZNzsu9irLvPPQ=; b=SSuCjVqwQ6ZOIRVxwOszEt/MCe3ijlqb61wmhtkPJBxf4H3MJBuFvQGf wDqL4ejtnJm+dgg+2u2Vs4Tg9EFnhmk/TS/zoWd0BNqtFPxw3HbfBNcI/ i5E9gWn2fjKMFVIYReJA/6H7wBs4/782TaMxXOnSBMNKc5mLE2XtUzVUO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFJbf02tJV2Z/2dsb2JhbACmCXelJ50GhWIEhTCHLYNV X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="320609069" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 19:32:43 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJWhjj028357; Tue, 15 Mar 2011 19:32:43 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:32:43 -0500 Received: from 10.21.84.106 ([10.21.84.106]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 19:32:43 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 14:32:40 -0500 From: Benson Schliesser To: , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: AcvjIzBUZe2XYRcbSNCzhU8+x/B+hAAJI7dl In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Mar 2011 19:32:43.0507 (UTC) FILETIME=[C1479C30:01CBE347] Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:31:20 -0000 On 3/15/11 9:10 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > An important missing requirement is the behaviour for the timeouted ports; I > refer to this as hold down pool. These ports SHOULD NOT be assigned to new > requesting users before the expiration of the hold down timer. The purpose is > to prevent users from receiving unwanted traffic. > > The hold-down timer and size of the pool should be configurable by the > operator. I agree on this requirement. It ought to be included in the lsn-requirements draft as a SHOULD. Cheers, -Benson From bschlies@cisco.com Tue Mar 15 12:41:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F277B3A6E8D for ; Tue, 15 Mar 2011 12:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMs0CFd8c2aA for ; Tue, 15 Mar 2011 12:41:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EC49C3A6E31 for ; Tue, 15 Mar 2011 12:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=841; q=dns/txt; s=iport; t=1300218189; x=1301427789; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=figxIyV00PXKFzkBfNMKj4ZLYZNH27iDZvs+qkQ30+w=; b=hRfek1aWecEdMq8PQImrE1PtyYEaMSpNc+EHGr0VeWXyUGscCMhryLxI cIfoxILD07Y5rpJ4qWCMlUhJQ5OLCJw6rfsKXlzGjQ0udwFkm6VkGu5bp 9hRuipBgWRwzN0QQoz7/1ZaGXUN0SpHSJqAhv6y6kcrbkewD2y7eIX1Jj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOZdf02tJXG8/2dsb2JhbACmCXelH50IhWIEhTCHLYNV X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="667430412" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 19:43:09 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJh83P021844; Tue, 15 Mar 2011 19:43:08 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:43:09 -0500 Received: from 10.21.84.106 ([10.21.84.106]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 19:43:08 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 14:43:05 -0500 From: Benson Schliesser To: , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications Thread-Index: AcvjHS/xay+A6A2mRli6YQarXKnKrQALAPGr In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3ADC@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Mar 2011 19:43:09.0188 (UTC) FILETIME=[3636F440:01CBE349] Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:41:45 -0000 On 3/15/11 8:28 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Some applications will fail if port forwarding is not supported. Having a > requirement to mandate the support of port forwarding feature would be > valuable. > > PCP can be listed as a RECOMMENDED solution. I'm not convinced that a port-forwarding feature ought to be a CGN requirement. I'm not opposed to it as a requirement, and I do agree that it is a desired feature in many cases. But it is not always a desired feature for all deployments. Thus, at this time I believe the requirements draft ought to capture it as a MAY. That said, I do agree that PCP should be recommended as the control protocol for dynamically configured port-forwarding in the event that it is implemented. Cheers, -Benson From bschlies@cisco.com Tue Mar 15 12:59:26 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69A53A6B49; Tue, 15 Mar 2011 12:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu4s9A79CBgo; Tue, 15 Mar 2011 12:59:25 -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 AC5343A6A8B; Tue, 15 Mar 2011 12:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1888; q=dns/txt; s=iport; t=1300219251; x=1301428851; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=6z025GaeGACfG2ooYeC2RfUtifc2G+9tJ0MyRwqCzpo=; b=fYTyn/OcrLGNFoKmILM9SDDfyhmQpfYcnvro5FGJLYvKyWQ4N/6tF2cl LMYOtnRAjafA343kzaO0xC4nhsuJz4OdU4DPu/SDGH1NTccxVWSoJrUOC M8BFoc/j8kMH2dN4zldc1m/RJzTRxSCM97U+O3A+bzxHnzlik06x+Fymp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJZif02tJXG//2dsb2JhbACmCnelGp0EhWIEhTCHLYNV X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="347290783" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 20:00:40 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2FK0dKJ005220; Tue, 15 Mar 2011 20:00:39 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 15:00:40 -0500 Received: from 10.21.84.106 ([10.21.84.106]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 20:00:39 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 15 Mar 2011 15:00:38 -0500 From: Benson Schliesser To: Dan Wing , , "'Francis Dupont'" , Message-ID: Thread-Topic: [pcp] last CGN requirements Thread-Index: Acvi+oeJMbP5aOqLTRq6SOVByadhhAADuvHAAAZ7f0AAChGEWw== In-Reply-To: <10f301cbe324$60300a40$20901ec0$@com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Mar 2011 20:00:40.0259 (UTC) FILETIME=[A8B3A930:01CBE34B] Cc: behave@ietf.org Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:59:26 -0000 >> REQ-6 is an operational requirement which require more elaboration: >> e.g., how an address pool is defined? Is there any hold-timer for the >> re-use of the address pool? > > There really isn't a /need/ for two address pools. Rather, there is a > need to not re-use an address within "some time period". I don't know > the time period. It needs to be discussed. Hosts, firewalls, etc already have mechanisms for dealing with the arrival of packets that don't properly belong to an established connection. On a host, the hold-down timer reduces the probability of conflict with a properly-behaving remote host stack. But a host should be prepared for the worst case, including packets received after a reboot and/or attack packets that attempt to interfere with existing connections. My view is that the CGN is well advised to enforce this hold-down timer. But as a requirement, the hold-down timer is a SHOULD. There may be conditions in which the timer is ignored, without creating undue risk for "inside" hosts. Further, reuse of an address-pool following a loss of state (reboot etc) SHOULD wait pending the expiration of a hold-down timer. But this ought not be a MUST requirement, and the requirements draft ought not require the use of an alternative address-pool following a loss of state event. Cheers, -Benson >> REQ-6: When a CGN loses state (due to a crash, reboot, failover to >> a >> cold standby, etc.), it MUST start using a different external >> address pool. >> >> Justification: This is necessary in order to prevent collisions >> between old and new mappings and sessions. It ensures that all >> established sessions are broken instead of redirected to a >> different peer. The previous address pool MAY of course be >> reused >> after a second loss of state. From dwing@cisco.com Tue Mar 15 14:23:42 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EEE3A6B82 for ; Tue, 15 Mar 2011 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.266 X-Spam-Level: X-Spam-Status: No, score=-109.266 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, 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 HMGLoyBYz-Ca for ; Tue, 15 Mar 2011 14:23:40 -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 0C27D3A6A2D for ; Tue, 15 Mar 2011 14:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2403; q=dns/txt; s=iport; t=1300224305; x=1301433905; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=vaKicdaBWP2c/VwcLgC31xbwBe1krWgYaumYi8HFoYo=; b=miZ8OZtCaZt6lFaJsznq2ANMY8qXTBGFGH+YPN8puGUud22Vmaj8sPzP wD8mbU9pedYSrgBuqUKArQqn7fqUb289lj3weZon1aZuQP9lzdfs4pH12 v6udi84KNBlPhqvDVNIJ+wnAqrMebpn76XcLjD4uYYGiDGgdpNgy2SFPu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsDANl1f02tJV2Z/2dsb2JhbACYT4Fki1poD6RqnHSFYgSFMJNw X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="414723312" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2011 21:25:05 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2FLP4Lq002425; Tue, 15 Mar 2011 21:25:04 GMT From: "Dan Wing" To: "'Joe Touch'" References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> <12a101cbe33b$fc20e160$f462a420$@com> <4D7FB586.7090503@isi.edu> In-Reply-To: <4D7FB586.7090503@isi.edu> Date: Tue, 15 Mar 2011 14:25:04 -0700 Message-ID: <138501cbe357$73c325a0$5b4970e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjQmml9hTnHD3pTVOp5up97k8BcQAESQHw Content-language: en-us Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:23:42 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, March 15, 2011 11:53 AM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- > requirements@tools.ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: IP-ID > > Hi, Dan, > > On 3/15/2011 11:08 AM, Dan Wing wrote: > >> As for the re-writing of the IP-ID field, a requirement reflecting > what > >> is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4- > id- > >> update-02#section-9 should be added to the I-D. > > > > BEHAVE has documented how popular layer 4 protocols are translated on > > today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). > Those > > documents provide minimal guidance, in an attempt to improve NAT > > operation. BEHAVE has not published a document on how IP is > > translated. > > > > That section describes how to translate IP, and requires a NAT > > reassemble fragments and re-write the IPID. The requirement is > > not solely on a NAT but, rather, on any sort of address-sharing > > device (to include 4rd, IVI, and others in the "A+P family"). > > > > Unfortunate to say, but I do not foresee NAT vendors implementing > > that requirement. Joe, I assume there is demonstrated harm > > occurring on the Internet where IPIDs collided? > > It's difficult to show such measurements, as we don't have access to > traffic behind NATs. The result of not rewriting the ID appropriately > can be increased packet reassembly errors, some of which may be caught > by TCP checksums, some may result in interrupted TLS connections, etc. But a significant majority of TCP connections send their segments with DF=1 (FreeBSD, Linux, OSX, Windows, and iOS). So I doubt the problem occurs very frequently with TCP. I expect it could occur with UDP, especially with applications that rely on fragmentation (that is, send UDP packets bigger than the MTU). > I do understand that NAT vendors can't be expected to implement *any* > standard; that's frankly their entire focus. Hugs all around. > That doesn't mean we can't > or shouldn't hold them to such, however. I.e., *when* there are > problems, we can stand behind their incorrect behavior as the cause, > rather than simply saying "kids will be kids" and expecting the rest of > the Internet to accommodate them. -d From dwing@cisco.com Tue Mar 15 14:27:05 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A14F3A6B82 for ; Tue, 15 Mar 2011 14:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.294 X-Spam-Level: X-Spam-Status: No, score=-110.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 DE6O4Vq769ag for ; Tue, 15 Mar 2011 14:27: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 0B5473A6D54 for ; Tue, 15 Mar 2011 14:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4687; q=dns/txt; s=iport; t=1300224509; x=1301434109; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=12Dw5rOYrTCNoxfPIer2P4drJTCqMkVZnEIl4EcQQC8=; b=S9IUMWN/JPeU+twdJBUfpMk7MUv/FvsORq41aiaUjTaiNrGIYJpo/dGi 3o7/QJs75bBfH4p3iEtYJWTXTP4pVH7xIGEYTynOxjtjSPLpyFJypwScm hfZFzPnsmZ+Rx+sT4t3ZwCwWFkvkEZXW/698DDADLLCVI0CPXmBNEOCYk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAEZ2f02tJV2Y/2dsb2JhbACYT4Fki1p3pFycdIViBIUw X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="320664527" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 21:28:29 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FLSSWl027844; Tue, 15 Mar 2011 21:28:28 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr>, <12f501cbe341$fe3310d0$fa993270$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 15 Mar 2011 14:28:28 -0700 Message-ID: <138701cbe357$ed3e63e0$c7bb2ba0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjA= Content-language: en-us Cc: 'DENG Xiaohong ESP/PEK' , behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:27:05 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 12:02 PM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org; DENG Xiaohong ESP/PEK > Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment >=20 > Re- >=20 > A "Port Set" does not mean necessarily "contiguous port range"! It is not relevant if they are contiguous or not. This is a false sense = of security. If they are fixed, the ports can be determined by causing the victim to = view HTML which opens img1.example.com, img2.example.com, img3.example.com, = etc., to servers controlled by the attacker. The attacker can then have Javascript release one of those mappings, wait, and the attacker will = know the victim will re-use that port -- because it's the only port = available. Proof of concept code that does this has been circulating. -d > Both pure randomized port set or Simple port randomization with port > sets can be considered. >=20 > We have an implementation to assess the behavior of simple port > randomization (only two lines of codes are needed to implement it: the > algorithm uses the port mask and port value). >=20 > Another solution to generate random ports is available at: > http://tools.ietf.org/html/draft-bajko-pripaddrassign-03#section-5. >=20 > Cheers, > Med >=20 >=20 > ________________________________________ > De : Dan Wing [dwing@cisco.com] > Date d'envoi : mardi 15 mars 2011 19:51 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange-ftgroup.com > > [mailto:mohamed.boucadair@orange-ftgroup.com] > > Sent: Tuesday, March 15, 2011 11:19 AM > > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: behave@ietf.org > > Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > ________________________________________ > > De : Dan Wing [dwing@cisco.com] > > Date d'envoi : mardi 15 mars 2011 18:55 > > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > > requirements@tools.ietf.org > > Cc : behave@ietf.org > > Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > > > > > -----Original Message----- > > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > > Sent: Tuesday, March 15, 2011 8:07 AM > > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > > Cc: 'behave' <(behave@ietf.org)> > > > Subject: [BEHAVE] CGN REQ: Port Set Assignment > > > > > > Re-, > > > > > > Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn- > > > requirements-01#section-5 discusses various modes for the port > > > assignment but there is no explicit requirement. > > > > > > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) > > > support the ability to assign port sets. > > > > Why? > > > > Med: We can ask the other question around: why only the dynamic NAT > > should be supported? >=20 > Because that's what NATs do today -- NATs in people's homes and > deployed by enterprises do that today. >=20 > > More seriously, the use of port set has several advantages in term = of > > log reduction and in some implementation(s) has important impact on > > performances (because of the per-entry write operations). Tests we > have > > done for some implementations showed severe degradation. FWIW, some > CGN > > implementations support only the port set allocation and the length > of > > the port set is even no configurable! >=20 > Yes, well aware. >=20 > > IMO, the decision to activate the port set or use the dynamic mode > > should left to operators (enterprise, service providers, etc.). >=20 > Their incentive is to reduce costs. But "port sets" (or "bulk port > allocations", or whatever term) increase the attack surface of > the subscribers, with no cost or security risk to the ISP. The > incentives are in the wrong place. It's obvious what an ISP > will do -- they will prefer to increase the attack surface of > their subscribers. >=20 > Speaking personally (not as chair), I do not support the > IETF making a recommendation that users be restricted to > a fixed set of port numbers. >=20 > -d >=20 >=20 >=20 > > -d > > > > > The selection of the dynamic > > > mode vs. port set is deployment-specific. > > > > > > Cheers, > > > Med From dwing@cisco.com Tue Mar 15 14:28:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45623A6EBD for ; Tue, 15 Mar 2011 14:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 iQzGgFCFo1jr for ; Tue, 15 Mar 2011 14:28: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 EE7033A6EB5 for ; Tue, 15 Mar 2011 14:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=985; q=dns/txt; s=iport; t=1300224578; x=1301434178; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9AyrVDFkbXvMqQwaVnoPn37qZ3H18zGs2AuNBcismqc=; b=QLefjld2emUuheBwd2oetgLAEoEIRiy+xNPmSNig1RJlz5zEJNw2mtNZ ChjpLAEjn+hk/GhPRpUJWB2P6qFy0SOzkMhEbTXNvg4dvEn0HB64bsWFv +jvRx16Rz2G9R28n4907BdeLvZdF+jL1+wkXB2TS/FtYibtZZC9ZcKhFP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAPp2f02tJXG9/2dsb2JhbACYT4Fki1p3pGKcdIViBIUwjSY X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="414724591" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2011 21:29:38 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2FLTbom028256; Tue, 15 Mar 2011 21:29:37 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <12e801cbe341$4bb98560$e32c9020$@com> In-Reply-To: Date: Tue, 15 Mar 2011 14:29:37 -0700 Message-ID: <138801cbe358$1651fc10$42f5f430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDAABPhPAA== Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:28:13 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 15, 2011 12:07 PM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > But there are operational solutions for this problem which do not need > man-in-the-middle rewrite. > > The abusers can be put in special public pool of address that is there > for such sole purpose. For that, the ISP would decide which of their subscribers is abusive?? -d > BTW, this already done today in many different > forms. > > On 3/15/11 11:46 AM, "Dan Wing" wrote: > > > The alternative is that everyone sharing the same IPv4 address be > > put into the same low-quality of service, such as throttling all > > of their activity, challenging them all with captchas, or blocking > > them outright. From dwing@cisco.com Tue Mar 15 14:48:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C9F3A6E9A for ; Tue, 15 Mar 2011 14:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.307 X-Spam-Level: X-Spam-Status: No, score=-110.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 fdeeFHR3F-hQ for ; Tue, 15 Mar 2011 14:48:44 -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 54AAA3A6BAC for ; Tue, 15 Mar 2011 14:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=42391; q=dns/txt; s=iport; t=1300225810; x=1301435410; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version; bh=7ApoPyC6N95z8xY5kZHcWn98PpQVzufV/G6Yls6SzgY=; b=VdvmxHpvNC5eZRLAuLODAajUMMGkUi7J7ZMSLrxEAYztgPQY0rEiaKLF QlHd8whVwmajMmcuoV8CNqt6xhyss36taGXkhLGk5YrWNh3BgJ0JaygQI VU9llEb0KrFUT70KOSr+k6pgvE/xDzWccCH7q0bfBnBkf5HxljNH53CWD 4=; X-Files: captcha.jpg : 28324 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBALR7f02tJXG9/2dsb2JhbACYT4Fki1p3pGKcb4J7gmcEhTCNJg X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="jpg'145?scan'145,208,145";a="278377649" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2011 21:50:09 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2FLo8OQ003790; Tue, 15 Mar 2011 21:50:08 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , "'Simon Perreault'" References: <94C682931C08B048B7A8645303FDC9F33C4DBA3C30@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Tue, 15 Mar 2011 14:50:08 -0700 Message-ID: <13ab01cbe35a$f3e4efe0$dbaecfa0$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_13AC_01CBE320.478617E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWgAA6etwAAI7pF8ACHHr8A== Content-language: en-us Cc: behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:48:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_13AC_01CBE320.478617E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 10:42 AM > To: mohamed.boucadair@orange-ftgroup.com; Simon Perreault > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > > > > On 3/15/11 9:47 AM, "mohamed.boucadair@orange-ftgroup.com" > wrote: > > > Med: It benefits to the users, service providers and content > providers: > > * a user won't be impacted by a misbehaving action of another user > sharing the > > same IP address. See > > http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal- > analysis-01#sect > > ion-1 for more details. > > I think the solution does not fit the problem. Can you elaborate on an > actual use case from the top? Today, AT&T Mobility runs a NAPT44. Occasionally I have been challanged with a captcha (*) while on my iPhone. See attached. It's a real problem, today. "Tomorrow," there will be more IPv4 address sharing until both clients and servers are running IPv6. The intent of user-hint is to provide content providers with additional information so that they can reduce the need for such heavy-handed mechanisms (such as captchas, such as connection-per- minute throttling), and instead just throttle abusers while allowing users through -- much as they are doing, today, with IPv4 addresses. I hope that makes it clearer that this is not the "logging problem". No amount of logging would change or prevent the captcha challange. Including a "user-hint" _can_ be used by the content provider -- if they wish -- to differentiate between abusers and users. This is important for TLS services, as well, where the server burns CPU before it realizes it just finished a TLS connection to an abuser. (*) http://en.wikipedia.org/wiki/CAPTCHA -d > > * a service provider won't receive calls to hot-lines (OPEX > reduction) > > It will not receive calls or it will receive calls but will have more > information to go with them? > > The identify of the user can be determined by the ISP through NAT logs > based > on public source IP, port alone. Any action by the ISP will need to be > done > on the private side anyway where there is a 'stable' IP address. > > This seems another incarnation of the 'log' problem. > > > * content providers: service experience. > > Service experience to the content provider or the subscriber? Can you > elaborate in a little more detail how subscribers will benefit from > this? > > BTW, I'm not really opposed to this at this point to this but it is not > clear to me what exactly we are trying to solve and for which purpose. > > "1.1. Problem to Be Solved > > Observation: Today, servers use the source IPv4 address as an > identifier to treat some incoming connections differently." > > > > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave ------=_NextPart_000_13AC_01CBE320.478617E0 Content-Type: image/jpeg; name="captcha.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="captcha.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/4QBMRXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAA A6ABAAMAAAABAAEAAKACAAQAAAABAAABQKADAAQAAAABAAAB4AAAAAD/2wBDAAICAgICAQICAgIC AgIDAwYEAwMDAwcFBQQGCAcICAgHCAgJCg0LCQkMCggICw8LDA0ODg4OCQsQEQ8OEQ0ODg7/2wBD AQICAgMDAwYEBAYOCQgJDg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg7/wAARCAHgAUADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgEC BAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcY GRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOU lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3 +Pn6/9oADAMBAAIRAxEAPwD9ptOn07SdDtNM0y1tdP061iWG2treMJHEigBVVRwAB2q5/a6/3hXz j4i8YeNLDxP4ct/DPg608TaTdXWzW76XxBFYtpcO+IeasTqTcHa0rbFIP7rGcsK+ZB4V+NHiLX/h hqvxC0NPFGraB4p+2PfXt7pCyadbeZpkm9Bbuqt80N0QEDSfKARymfr8p4fhi4+0rYiFOOu8o8z0 l9m6trG3vNP3k0ndHyWa51UwrUaWHnUldbRdlrFO8rW2lfS/wtaWPvjwR8VfCfxF8K3OteEdRudQ 06C7NrLJcadcWbCQIkmNk6IxG2RDuAwc8Hg45T4xfH7wn8E/AWneIPFFnr+qxXt6baCz0S1S4ucL FJNLMUZ0/dRxxsztngdjXzn8Dx8QfAfwyfR/FHgTVI7291vzJGtNZ0yaOzh+zWkXnSH7WCy7kl+W ISPiM/L8ybqfxE8DfEH4kftNQarF4g0/wR4O0fwzPp+m31zpNtrLX816dl4BbG5jaIeSiRl3AyCw UEMSOTiHAYfB42pTw01Omn7rUoyuvNx0/BHRw/i8TisFSqYunyVGryVmrPtqe0+Pv2pNL+H/AIws dNu/hd8YfEOn6je2tlo2uaJo9tNp2rXFzEJIoraR7lDI5yVxtB3IwGcZqvrn7WXhjwzb6f8A8JD4 C+KWiXb6M2s6vY3ul20VxoViLw2a3F1GbjJVpBuCw+a+whioyBXzzZeB/ijN+zd8DfCGt6Va3Or+ BPH9hc3Nwur2mybSrJpliul/fHnymiHk5M2Qfkqh8W/hx8SvGP7Sc/i7TvD2m+K5LFrCbwNqF/4g tYNO8PPEwa6ju7KX57gTOqtujRmwI9rIUyPDbZ7SjHY+kvE37Vlr4W+L9v4Ju/gr8eL7WL28u7fR mstAtWj1gWuTLLa7rpWkj2YkB2g7WBIGa+hNH8TnVvCOlarLp2p6LJe2cVw+n6lEI7q0LoGMUyBm CyLnawBIDAjJ618QWuh/EzV/ij+zn4s8WWEsuq+FbPVV8W3NzqWnF4Z7m0WJGVbaTZIruDjyVbau N4U5r6R/t0/3v1qokSsin4y/aQ8HeCPiVc+HdR0rxhqNvpy2zeItb0zSjPp3h8XLbbf7ZLuBTzCe AiuQOTgc1V8V/tKeHfDHiTxHZWvg34meMrDw423xHrHhvQftVhpLCMSusspdcskZV3EYcoGGcc48 l+Kmh+O/iCF0NNN8PX+hxXUF1oWsNr0lq+gTIytJJcWjOUvclNyBYnABwQGG6s+98L+O7HSPGXhz w3YPcaXrmvXOt2HiGw8bnRZ9NuLg72W4SN0uHVJNxAh3h12A7SDj77BZZk0qNGU2uZr3k6kUvs+9 fSz1l7rs9Nmo3n8xXzDGxqVEoPlWz5G9fe0t1Wi1Wmu6vZfaOl+KtO1rwzp2s6XdR3mmX9rHc2lw n3ZYpFDowz2KkH8av/2uv94V8+eDtQ13TvhH4V0/xNc3Fz4ktdHtodWmuL0XUklysSrKzTBmErFw xLhm3HnJzmuj/t0/3v1r4rE0owrSjF3SbSe/4n0NKblBSas2j2D+11/vCj+11/vCvH/7dP8Ae/Wj +3T/AHv1rCxoewf2uv8AeFH9rr/eFeP/ANun+9+tH9un+9+tFgJPjr8bbf4J/steJviVLoz+JG0t 7WKHS0vFtmupbm6htY081lYJ88ynJB4BrjPAn7ScupfBPxZ8RPitoHhH4W+C9FeJRrNp45tNetJt zFJN0tsoERRjEuDkkyDpiuD/AGg9M1jx1+zDq3h/RfAfg74n3T3dtO/hfxNeNbWmoxxzI7IJQ6hJ Bt3IXOzcoDcGvlz4T/Dj4g+BI/2mfHlh+zz4W0vS/GtxpZ8L/BSXXNNjs3NrH5c80rrvs4DKzmUL 6x4I+4ahtpmkYpxPsv4j/tbaV4D/AGmvhN8NLXwH4y11/G+v22mxeI3s5LTR4I54TKJIrpkKXMoG 3MKYwNxLKVwZvHH7V1h4O/bm+GfwOX4f+Nby88WanLZnxJd2UlnpUIS0+0k28zIVu3GVRkQgIc5b I2nxX44eEPGnj34nfswaz4f8P25tfCHjuDWPEMK6hbxrp1sts6MV3uvm7WYKFiDE9QMVb+NHhDxh 4y/bK/Zg8Y6Bpcd/oPgzxBqV54guWvoIjaRTWXlRsEkdXky/GIwxHUgDmh3ElHQ+yPiR8Rf+EA/Z 38e+PEsV1Z/Dfhy+1dbEz+SLo21vJN5W/a2zds27tpxnOD0r428BftxeNtT1X4G3XxN+BcPgbwh8 WriC28Ja3pPjOLVmE08XmRLcW5gheNSCuWBbbnkV6x8YItW8XfslfFLwnoVut7reteEdS07T7czp EJp57SWKNN7sFXLMBuYhRnJIHNfNP7N37Kfw0+GXw4+FvivxT4Jnk+MmiaJbi5n1PxDPqUel3vkh Z/s8fnPbJ8xIDRggYG0im730CPLbU6j4cf8ABQ+Hxv8As8/tB+NdT+GZ8Pal8OLcTabpK699oPiA ST3NrBsk8hTFvubYxHCvtLA89D9N/s0/H6b9oH9jjwx8VbvwzH4NudVnvIZNIXUftotzbXc1t/rf Lj3bvK3fdGM45xk/lB4N/Za+Nmk+JvhJFe+HLKy0C68Q3afEmFtbspBHptt4hj1rTjhJiZvMYSrt j3sgc7guePt39j7wl4w+EX7AfhLwF460uPRPE1hfalLc2aX0NyEWfULmeM+ZC7ocpIh4Y4zg4IIq YNt6lTjFLQ++v7XX+8KP7XX+8K8f/t0/3v1o/t0/3v1rSxkewf2uv94Uf2uv94V4/wD26f7360f2 6f7360WA9g/tdf7wo/tdf7wrx/8At0/3v1o/t0/3v1osB7B/a6/3hR/a6/3hXj/9un+9+tH9un+9 +tFgPYP7XX+8KP7XX+8K8f8A7dP979aP7dP979aLAewf2uv94Uf2uv8AeFeP/wBun+9+tH9un+9+ tFgPYP7XX+8K+btH+Nnxm8QeD9H1/Svgp4Zk0vVLCG+s2n8eOkhimjWRN6jTyFbawyASAc8nrXY/ 26f73618SP8AD/8AaOso7ex0TWrG10i0tora0i/tq3ASOONUAA87p8voPoK+Q4wxmc4bD03llPnm 3rtorefmeLnWIxlKnF4aDk762t+p6J43/be8a+AfibqXhPXPgdYyapZLEZmtfGjPH+8iSVcE2IJ+ Vxnjrn617n8Fvjto/wC0B8IteGu+GdM0C7S6lsb3w5c6kl801v5cR80gxoTG3m7OUxlSMmvnSD4U a7qlhb3vjHRZtV8SvCi313HqdgyysqhFILXIP3VUc+lehfDH4fw+BvFuqa9JLq9pcSiWGy0tr6CS 1gilW182XZFuAmd7ZAT5hGyNPlBzn6PK6lephKcsRG03FN/4rK6++569BydCEpK0mlddnbUp+Z4y /wChu8Of+ElN/wDLGjzfGX/Q3eHP/CSm/wDljXAePvEN9o3wQ8Xavpdx9l1Ky0e4ntZtiv5ciRsy thgQcEDggivH7z40eL7T4c6jbT+FxYeJI/Bi69p93cahDKlxENqvJJGgxG4LbvK6kcfKa+hlhaa3 RgqsmfT/AJvjL/obvDn/AISU3/yxo83xl/0N3hz/AMJKb/5Y182w/FfxtafEMQ6toWmf2TB4BbXr mKHUEMjOufnDBeNxATy8cZ3ZIGK6fw58WtQ1bxT4d07V/B13oEfiHSG1HQ7g6lDcC6VUV3RlTmJt rqRu5wRkA8ULDUmHtJHtfm+Mv+hu8Of+ElN/8saPN8Zf9Dd4c/8ACSm/+WNeKa3461Y6t4VtbuC7 8IPDb3GueJYHljlktrK2BAjZlyp8yRo+hztV/SuLt/jPrfhbwdfjxPod7qviKSxt9Zs7VblUM0N3 O4ECgJ8nkKNpzuJKknGaX1akCqSPp/zfGX/Q3eHP/CSm/wDljR5vjL/obvDn/hJTf/LGvCT8brYe JVH9iOfC7ayulDWftgx5xtPtP+r29Odn3uvPtWLB8f57zwdDqNl4Mupb+PSb7U9SsJNQCPZw2zov J8s7i4cMOBj3o+r0Q9pI+kPN8Zf9Dd4c/wDCSm/+WNHm+Mv+hu8Of+ElN/8ALGvn6T482j61qtjp /h+4vZY7iwg0ljdhF1J7pkVtp2nb5ZcZ+9nHau98Y+O5vDUWiWunaQ2v67rGoCz0+xF2lurttZ2d 5GyERVUknB7U1haQe1keieb4y/6G7w5/4SU3/wAsaPN8Zf8AQ3eHP/CSm/8AljXz9bfG+/vroaPa eCrg+L5PENxo1vpE2qxIhe3hSWeV58FFRQ3Vd27AIzmp4fjZNeW2n6Xp/hO4n8cXOt3OkPocupRR xwzWyCSZmucFTGqFWDAHdngUfVqQe0ke9eb4y/6G7w5/4SU3/wAsaPN8Zf8AQ3eHP/CSm/8AljXg 0HxquL200/TdO8JTXHje41y50iXQ5dUiiSGa2j8yZjcHKNGqYIYD5s8Vkj4u6vrPiDwhJBa3Hha2 Pi690jWLKZop2kS3gdjuYKdpDL/Ae33iKPq1IPaSPo/zfGX/AEN3hz/wkpv/AJY0eb4y/wChu8Of +ElN/wDLGvnvwf8AH/SvFnj/AEfR1061tINYE50uWLWILif90C2LiBPmtyygldxOcYrqtd+JGrWn xFu/DXhfwfeeLr+w05L7UhFfx25iR2KokYfmWU7WOwY4HBJ4o+rUrXD2sr2PWvN8Zf8AQ3eHP/CS m/8AljR5vjL/AKG7w5/4SU3/AMsa8L1v4x6jYar4lGk+Cb/V9N8NWsNx4iuJtRitZbTzI/NKRxPk yuiZLAEYxjPTObrnx4bTJ/Et1p/hG51nQNCg0+6v9RTUoomEF4gaNlif5nYZ+6M8AkleMn1akHtJ H0N5vjL/AKG7w5/4SU3/AMsaPN8Zf9Dd4c/8JKb/AOWNfPuo/FvW5tF8aaAfDz+GvHNlLZ2Om273 0V2kk18Ctu++PK5XlnXkAKeTzVUfGjVtNf7DH4N1LXLKz8Tf8It/abavbpLd3oUCNjG20jeSCzHC Lu6noD6tSD2kj6M83xl/0N3hz/wkpv8A5Y0eb4y/6G7w5/4SU3/yxr5+n+KGr+JPAVzpGnWUvhbx nN4nPh1o1uY7r7LIm2SedHA2uqQb3BxjIHXjNvQfjZaav411PS30qKysrBrpZ5JtVi+3Qi33ZeW0 IEgVgpIK7+o3baPq1IPaSPdvN8Zf9Dd4c/8ACSm/+WNHm+Mv+hu8Of8AhJTf/LGvnHw9+0Pp+u6o Lb+xII2utMuL7TI7XXLa5mkEK7jFOgYfZpCvzAOcYzkjBqOP9oa3Xwj4vv7nQLR7vQbS3upItO1y K9gmSaUR7RPGu0OpPIAIyMZ70vq9IPaTPpLzfGX/AEN3hz/wkpv/AJY0eb4y/wChu8Of+ElN/wDL GvE5/il4o/4SO30Cy+HN7d+Jv7LfVL3TG1m3Rra280xxjfyrzvjPkg5HQnINczq3xW8YaP8AFDxd LD4cvdW0PTPDVpqlxplzcQWUmnAiRp9zMCzy4X/Vgn7jYI4yfV6Qe0kfSXm+Mv8AobvDn/hJTf8A yxo83xl/0N3hz/wkpv8A5Y14L488U+JR4JsfFmheLW0DS7nToxpGlWmkLeX2p6hPzBCwcFRG2VXC Hdncc4Ap918VfE2lyDSJPBp13X9J8ORap4qNrqUUEVmxQlo4t5PmtlXIVT0HBan9WproHtZHu/m+ Mv8AobvDn/hJTf8Ayxo83xl/0N3hz/wkpv8A5Y149Y/Fm4vfDWkajD8OfidqMV9p8F4s2k+HZr22 HmxLJtWZAA5XdtOB1BrgfGvi7x3B4xvtRvb3x74D8If2ZBPo97Y+F0vIIJmQtKupAq0kTK2FMYAO AT16p4ekgVSR9P8Am+Mv+hu8Of8AhJTf/LGjzfGX/Q3eHP8Awkpv/ljXgs3xivUUW2haFD46bT/D sera1qWn3yWluqMpIMKS/M7NsZhH94DjkgirunfGSPULe4kGhSRCPwVF4lwbsHIkViIPu9Rt+979 Kf1akHtZHtvm+Mv+hu8Of+ElN/8ALGjzfGX/AEN3hz/wkpv/AJY188a/8el0PwdoOuN4etHs7/Q4 NUkSfX4IJgJQD5UETfPO6jkkKq4754qe9+O9tY6vLZS+Hbozx65b2Uii6GUtJoVmW8b5eAFcZT1/ ipfV6Qe0kfQHm+Mv+hu8Of8AhJTf/LGjzfGX/Q3eHP8Awkpv/ljXg+ofHbRNL+EupeKL+C0tXF3d RaPp8uoKsuqR283kmRMrxkg8YOMDnmruqfGKF9d0HT/BOl2njubVbe7khktNYhhiRrdUZ0aRvl6P 65zgYOaf1akHtZHtfm+Mv+hu8Of+ElN/8saPN8Zf9Dd4c/8ACSm/+WNfOFv8c7vVfDtpO/hbUdBs 9Z8O32oaNqA1CCaVnto8ygxgNswfus4+bg7cEges+DPEEusfCHwtq1xLPPPe6RbXEkk+zzHZ4lYl tgVcknnaAPQCnHC03shOrJbnbeb4y/6G7w5/4SU3/wAsaPN8Zf8AQ3eHP/CSm/8AljWd9vHt+dH2 8e351X1KHYXt2eX6zFZ6/wCEtT0PUmuRp+oWsltcm2lCShHUq21mDANgnBKkexrmr3wX4W1CYvd/ 20+fDz6AVW8jVfsblST/AKvPnfKMPnb/ALBqo91qEjQ29lia9uJ47e3RuAZJHVFz7ZYV9l+Hv2P7 O98M2t34j8WeIptSmjDy+RfSQICR0CRkAD/Oa6sXWo0Lc/XsY4elUq35eh8Uaz4G02TQLq403UvE s+uw+GbjRbVrq+hKXcLo+xLgCEZKswIZCnQZzg5PBfgfS/D2neH9RvLvxDe6/Z6JHYpHeakstvp+ UXzhbqqArllxlmbA4HFfen/DGvhT/oZvFf8A4Obn/wCLo/4Y18Kf9DN4r/8ABzc//F1w/wBpYW97 P8P8zq+pV7br+vkfDy+CPDR0jUbK71Dxfq6ahDbwXtxqeqRz3E0MDtIkJk8kfu2Z33jGWDEArxjT 1bw74f1zx/onifU4r2TVtKjljthHOqwSrKu1hMhQlwOSuGXDHJz0r7O/4Y18Kf8AQzeK/wDwc3P/ AMXR/wAMa+FP+hm8V/8Ag5uf/i6f9pYX+V/h/mH1Kv3X9fI+Ev8AhW/gr/hTA8Af8VD/AMI+J/tA uPt8X2/zfM37/N8nZn+H/V/c46/NW1YeFvDGm+MPEOu2ttdte63BHBfwzTq1usaJs2xIEBQMMFss 2SARjpX2n/wxr4U/6GbxX/4Obn/4uj/hjXwp/wBDN4r/APBzc/8AxdCzLC/yv8P8w+pV+6/r5Hwj pXw38E6M/hNrJfEEr+G3nfTWur+JzK0xyxuMRL5m042bdm3AzupPFnh37Z4ab7C/iPWrxdaGqRmb xCLe6s5NpUrZy+SyxoASBFIpXDNls4r7v/4Y18Kf9DN4r/8ABzc//F0f8Ma+FP8AoZvFf/g5uf8A 4ul/aOFtZJ/h/mH1Kve91/XyPzt8LfDa2j8I3B8QXGraZrUviCfWbK70zVfMvdPaRFj2NPJGVlZl XL/Jht3GMV1A+HnhFPD9nY20/iWyu7XUZNSh1uHUE/tI3UgxLK8hjKNvGFZdgBCqOMZr7q/4Y18K f9DN4r/8HNz/APF0f8Ma+FP+hm8V/wDg5uf/AIuhZjhV0f4f5jeCxHdf18j8/dZ8Eadp/g3Trbw5 Yazf3drq76lJejXxa6rLPIrLJMJzC0bMwIVlZFUqBzkcngrwFbaV4Z0yTX3uf7VtdcutYt4Le/8A OjhecMnlyvJHumwh5I25bnJHX9Av+GNfCn/QzeK//Bzc/wDxdH/DGvhT/oZvFf8A4Obn/wCLpf2j hb3s/wAP8w+p17br8f8AI+JdK8J6Vomltp2meJPiFbaMsE0FppS6/ttbBZSSxhVYwSykkoZTJs6g EgGquo+BtA1O5tp5tb8cWtzHpqabc3Fpq8aTajbISVW5cxEs+SxMibCdzD0x9yf8Ma+FP+hm8V/+ Dm5/+Lo/4Y18Kf8AQzeK/wDwc3P/AMXT/tHC2tyv+vmL6liO6/r5Hwrq/wAPfCetarf3Ulz4o0lN Qt4rfVbPStTWK31GOIbY1lDxu2QuEJVlJXjrk1NqPgPwjqlp4qt7ga3b2/iKC1g1KK0vIkWNLYYh EAaJtmBw27fnttr7k/4Y18Kf9DN4r/8ABzc//F0f8Ma+FP8AoZvFf/g5uf8A4un/AGlhf5X+H+Yf UsR3X9fI+J/+ES8N/wDC2JPGzPrUmuu0bmJ7uM2YeOGSFHEflbtwSWQAmQjLZx0qufBPhdlkBk17 D+Jl8SN/psX/AB/KVIA/df6j5R8n3uv7yvuD/hjXwp/0M3iv/wAHNz/8XR/wxr4U/wChm8V/+Dm5 /wDi6P7Twv8AK/w/zF9Rr91/XyPifSvCXhvRvHF34js31ubU7i6ubpkuruN4IpbgRCV40WJWBxCi jLNhS453ZFZPBPh0+L7PWr3UPE+uS2TTNY2mq30dxBa+cpV1VvKEzJtYhUeQhQe+Aa+4f+GNfCn/ AEM3iv8A8HNz/wDF0f8ADGvhT/oZvFf/AIObn/4uj+0sL/K/w/zH9SxHdf18j4bh8DeH4vBt14bl 1zx9f+GprF7KLSLrXs2tnCxziJFjGWU/daXzNoAGDVS7+G/hTULHV4NS1bxvqR1TT4LC9muNTt9/ kwOHiEeLYLGQQBgKV2/w7stX3f8A8Ma+FP8AoZvFf/g5uf8A4uj/AIY18Kf9DN4r/wDBzc//ABdT /aGE/lf9fMf1PEd1/XyPifxD4V0XxLr0eqXWpeJ9G1EWTWMtxot+kDXFszbjFJvjfjOSCuCNx9eC bwj4ZmXXlxrEKaxo6aReJHeqQlsiui+WWRmEm2Rvmcvk4OOuftZv2NfC3lnZ4n8VBux/ti4/+Lr5 a+Jvw81r4T/E+DQrjVZtW0q8tmmsZ5gDKmxlDKx/iHzrgnng5rpw+Lw9epyxTu+//DmFbD1qUOZ2 sYh0+y/sHQ9Mh1DX7G10mSF7U2l6sckwhG1Y5zsIkjYffUBd3YrXMeL/AAbpXiNtV1WG98RaZrlz pT2Ug0zUVt4b5AGMaTgoxIDMRlWUlSVJx0SfUpLe2aV5HIGAFVcsxPAAHck8AV7/APD/APZy8feO tKh1XxDqc3hTS5QGjtLYL55X/bcg4OOy4x6munFSo0Y3mzGhGpUfuo+b9D+HXgyTwB4dj8U+E7LU NfttJtba8nOpXaZaKFI8YimVONuMgc4rVufAfhyTU5rvStV8ZeETPZx2d3DoOriOK5hjTy41cTJI dyp8gcHOOuSST9wx/sa+GfKHm+KfFTSY5P8Aa9wM/gGxT/8AhjXwr/0M/ir/AMHNz/8AF1539o4X +V/h/mdn1LEd1/XyPgjW/hz4auPD1wmhyeIdAuU0M6XFb6XqYhhvIVVvKjuNyMzYYnLBlYhmBPPF XT/hxo194F8Nx69d+JtM1i28MQaLqK6NqqQR3UKoN0UmY33AMWwVIyDg5FfoD/wxr4V/6GfxV/4O bn/4uj/hjXwr/wBDP4q/8HNz/wDF0f2jhez/AA/zD6liO6/r5HwhN8NfCE2lS2KX/jKxtJtEh0a7 js9ThjN5awjEXmsYCS477dqsQMoQCDcvPAPg+/1y91G6XXGu7vQv7FnKXkaqbfGBKB5XFyBgCT7o H/LOvuP/AIY18K/9DP4q/wDBzc//ABdH/DGvhX/oZ/FX/g5uf/i6P7Rwn8r/AK+YfUsR3X9fI+LZ /C3hq4+Do8BSxX3/AAjosxaB1li+1hBg7hK0ZUSEjLMEwSTwO1+70nR77xnpGvzLdQ6jpdvPBaJb PHHBsmCiTegTLNhBghlxzkHt9h/8Ma+Ff+hn8Vf+Dm5/+Lo/4Y18K/8AQz+Kv/Bzc/8AxdP+08L/ ACv8P8xfUa/dfj/kfDEXw98IQ6JoWnJJ4j+y6Pp11p9iWvoi5hulCzeYfJwz4+6QFAPVWrd07Q9N 0q202Cx1XxVFa2GjrpVtbHU18nyVACysgjGbgAAeYMDGfkr7IP7Gvhft4m8VD/uMXP8A8XWfqP7G +npYs2jeMfEtrdgfK0l+8wz/ALsm4fpTjmWF7P8Ar5g8DX7r+vkfJ1rpttaTaJImueMLg6VC8UK3 WrCRbwOAC10PLHnOMZUjZgk8Gt/+0j6/rWd468DeN/hh4iisvFCpdabM+y11WCParN2WReik9iDg n04rkvtk/wDz0P5V6lH2dSPNB3RwVeeErSWo7w9IG+JfhVeudesf/SmOv2am1Cx0nwbJqmp3dvYa bZ2ZnurmdwkcMaJuZ2J4AABJNfiz4XkLfFTwmM/8x2y/9KY6/Ynxdpcmt/AfxBo8WkWPiCW80aWF dMvJ2hhvC0RHlNIvKBvu7hyuc9q8jPlapD0PSyl+5IzdN+K/w+1TS9dvYPEcNtb6NbC61I6hbTWZ hgbO2bbMiFoztOHUFT2JqKz+Lnw9vvDmv6rHr7W1rolqLrVEvdPuLWe3gOdsxhljWQxnBw6qVODg mvnafwB8SfEHgzxFp2naR4xtdCgs9PuLDSfHOpWd1cz3drfxXLWsNzC7v9maOIpmZzl2UjADVtfE Dwh48+J8Hj/XrTwVqnhuSX4e3Ph7StL1W7tFutQuZ545mYmKZ40jTylVS7gkuxwByfAPWPZj8afh hnTAPFlq51J3TTQltMxvSkiRN5OE/ejc68pkEZYZUEjobfx/4Qu/CPhzXbbWoZdK16+Sy0mYRSZu Z3LgRhdu4NmN87gNuxs4wa5y48KXx/bA8L+JodMhHh3TfBt9p63AaMCC4kurNo0VM7hmOKXkDAAw SMgHyjwR4Vv/APhtbxJobCCTwR4M1C51vSQj5CXurRIxiK9F8rN8wA6LdIeOMgH0F4p8aeGfBenW dz4k1RdPW7n8i0iSGSea4fBYrHFGrO5ABJ2qcAZOBWAPi58OZPAK+J7fxRa3ujPf/wBnwy2kEs8k 9zt3GGKJEMkkgHJVFJAB9DjgPFNz4oX43/DPxqfCXnanaRaxpp8LHWrIX80UjwFbu2MkqRPhLdWZ N4ZUmGeQRXlngfSPFcmuWfxLsfCf9qDSviL4imvtB0y8geYJdosLSwu7pFJJFJGyt8wDbpNpPGQD 6a/4Wl4C/wCFbjxYPEUB0U3v2EMLeUzm6zj7N9n2+d5+f+WWzfjnGKSP4p+AZPhxd+LP+Ejt4tFt bsWdy00Esc8VwSAIGgZRKJjuXEZTedwwORXhK+BvHcPxFh+LT+FLmW5PjmXWZPB6Xdv9qSzbSxpy yBvM8g3Q2+aU8zGGIDbhVTWvDHi0ePm+Kl3odvpd7d+P9PvtO8I6lqdrDdXkMGnS2Srv80w/a2Mr SonmEbY1BbPQA9U1n4zaFc+HdNuvAup6Zrdx/wAJZpGj6pDPbyq1ol7dpCwZG2MkoUuQG6EDcp6H rJfip8P4PiKfCsviS1XWVu1s3XyZTAly33bdp9vlLMcgCMuGJOMZr5ytdI8U+NvjF8R9Rt/Cw0m7 j+IPhS7urFr63eWCKzMEszTOjmMyrEFcojMcFVBY1XtvhT4yt5NU8DX2heNdWsLzxbLqX9qp4jt4 NFktpL77WJpIgTP9oTIHlhMM6A7wvIAPr3xB4h0Xwr4Su9d8Q6jb6VpNsB51xLnALMFVQACWZmIU KASSQACTXIR/Fz4eS+C7rXh4iRLK2vUsZ4ZbKeO7W5cBkg+ysgnMjA5CBNxGSBgGua+JGleL/FOh 6fc6f4WkNx4V8a2WqWdjJfwZ122gALGM7gsTZkfaspX54RnAINclrelePdY+I/hz4lj4bQ2aaH4g 89dBWe1/tjULV7CW2M8riUwGaNpsxxmXhA3zBiBQB6kfi78OU8Br4mm8UWtpo/8AaP8AZ0ktzBLD JDdbS3kSxOgkikwM7XUHkeozlRfHj4TTTwxJ4vgWV7oW0qSWNwjWkhcIouA0YNvuZgAZtgOeCa8y k8AeMvEXxFl8b3fhmXSBqfxE0fVP7Hurm3M9nZWNqYftExSRkMrN82xGYhQg5IIFzxb8N/FWpeBP 2j7fTtDjl1DxVqdrLomLmFTeRx2VnGTksNmJI5hhypyCRwQSAepeIviDa+Hfi5HpWoXWnaf4dsdC bUdcvbhWLxPLcJb2UUe0/elZbnjaxJjUKMmrlt8U/AV14C1fxKviCK30nS5xb6i15azW01tK23bG 8EiLKHbeoVduWLAKDmvOvEvgnWdX8HfE7VNU8JSeItR1bxBatZ6VDqotbn7BZNEsLwTo4EcwZZ7m Pc6/NIFbbk44dfBvxL1Dwu+qNpfibU7PRfGOl61oukeKLmxOs30NujCeN5oW8s4L7ofNfdmP5mAI wAe7w/Fr4eS+CNW8RP4jisdL0q5gt9Ta/tZrSWykndEiE0MqLJGHZ1wzKBg5zgEiK1+MPw3vNd0L S7bxNFJqWsxxS6XafZJxLcxySywpIqlM7C8Mnzn5QFDEhWUnxfxX4F8Z/EK58eeJn8H3eipq3/CO afY6HqNza/abiCx1Vbu5uJ9krxL8kjhV3lisZ4yQp9jtfDOpJ+2jrnjKXT0GjzeCrHTLa+MiFjMl 5eSyxhc7wNskLE42nI5JBwAeoUVyP9ueJv8AhEvtv/CE3n9p/wBqfZv7N/tO33fZ/P8AL+1b92zb 5f73Znfj5cbuK14b7U5PG1/p8uiTQaRDaxS2+qm5jZLiRi4eIRg71KBVO4jB3jHQ0Aa9fNvin4he P/FXhTxq/wANNHsI/D2mW1zBLrl3NKs9xJGjb/saR8lxjCk8bsV9JV8xeDPGenfBjw7c+AvHttqW lw2V5O+larHZSTwX8MkjSL8yKTvyxBB9q6cPHdpXa6GFZ7JuyPR/hHL8Tp/hykvxLSwjvGCm0VY9 t2Ux1nC/IG6YAAP97mvlH9sRtvxO8FH/AKcbr/0KCvp7wHqfiLxl8Ydb8byR63pHgr+zk0/RtPvX eMXLCTe90YTwD/CGIzjjpXy5+2Y234j+Cj/053X/AKFBXbgF/t0f09GcuKf+yy/rqeYfs9+Drfxt +0harfxibT9Jg+1ujDIaRiVTP0w5+uK/VSKKOC2SKJFSNRhVA6CvzL/ZM8RWul/tKXul3UiRnV9O 2QFj96SJmbaPfa7n/gJr9OKWc831lp+Vv69Sstt7BWONPiDW7++vj4e0Ozv9PtJ3gee61AwNPIh2 usaiNuAwI3MQCQe3NX5/FGmWOk6fcap9q02e7iLrZvbvJOmAN2UjDHC5GW6DI55rkl0q/wBPstW0 C78MXfiPS5tRmvNPlguoo41EjmTZJudWXazNyA2R78VT8O6P4i8MSaZe3ejzatKunTWcsNlPGWhb 7VJKjAyOoKMrDvkbVyBzjyjvO9vPFGg2NhZXM2oLJDeR+bbfZ4nnaVAAS4WME7RkZbGBkZNNuvFf h2ygspbjVbZYruLzoHTLho+P3hKg7U5HzHA964vRtG1vwve6XfPpU2sFtJe2ngspY91tK07TYHmM oKfPtyD/AADjFUNKsNT8KXbCeytNVmuNCAuIEvIk+xkTTyHdvYfuf320soJ+Tp0oA7yDxXps+qXg EsKaVBpMGoi/aTCNHK0o6EDAAiznPO7pxzpaVrula3HM2m3XnmEgSo0bRum4ZUlXAYAjocYOOK8h s/C2s6l8LoBbwFPO8MaSsGZVUySQTPM8fP3SVKjJGMt7Gu68L6beJ4m1HVryz1q1MltHbxnVLyOW ZwrOx+WPKqoLcHJJyeBxkA7qiiigAooooA8++JvgzTPG/wAI9X0fUIElElu2xsfMpxwQexHWvx8I mtZ5rS5P+k20zwTf76MUb9Qa/arxHqdno3gTVtUv5o7eztbSSWaRzgKqqSSfwr8TLzUG1DXNQ1Jl MbXl5LclT/D5kjPj/wAer6LIOZua6aHjZta0e5Q03U20zxPpeqJH5z2V7DdLGTjeY5FfGffbiv1y 8M/H34R6z4NsLxvHnhvSZWhXzLXU75LWaNscqyOQcj1HHoTX4m/8Jv4N/wChs8M/+DSH/wCKo/4T fwb/ANDZ4Z/8GkP/AMVXq47A0sTZuVmjgwuKqUL2je5+6P8Awub4R/8ARTfAf/g8t/8A4uj/AIXN 8I/+im+A/wDweW//AMXX4Xf8Jv4N/wChs8M/+DSH/wCKo/4Tfwb/ANDZ4Z/8GkP/AMVXB/YVH/n5 +R1/2rV/kP3R/wCFzfCP/opvgP8A8Hlv/wDF1kaN8R/gN4d0+e00Dxr8MNFtprh7iaKx1O1hWSVz lpGCsMse7Hk1+Iv/AAm/g3/obPDP/g0h/wDiqP8AhN/Bv/Q2eGf/AAaQ/wDxVH9hUf8An5+Qf2rV /kP2y8RePf2ffF2jR6d4o8XfCvxDYxyiWOHUNStZljcAgOoZjtbBIyOeTWjpnxT+COi6Da6Vo/j3 4baVpltGI7a0s9WtYoYVHRVRWAUewFfh5/wm/g3/AKGzwz/4NIf/AIqj/hN/Bv8A0Nnhn/waQ/8A xVH9hUf+fn5B/atX+Q/dH/hc3wj/AOim+A//AAeW/wD8XWXrXxK+BPiPw5caP4g8b/DHW9Knx51n fapazRPg5GVZiCQQCPQgGvxC/wCE38G/9DZ4Z/8ABpD/APFUf8Jv4N/6Gzwz/wCDSH/4qj+wqP8A z8/IP7Vq/wAh+3OhfEX4C+F/D0ek+HPGnww0LTEYutrYanawx7m5ZtqsAWJ5J6nvWx/wub4R/wDR TfAf/g8t/wD4uvwu/wCE38G/9DZ4Z/8ABpD/APFUf8Jv4N/6Gzwz/wCDSH/4qj+wqP8Az8/IP7Vq /wAh+6P/AAub4R/9FN8B/wDg8t//AIuj/hc3wj/6Kb4D/wDB5b//ABdfhd/wm/g3/obPDP8A4NIf /iqP+E38G/8AQ2eGf/BpD/8AFUf2FR/5+fkH9q1f5D90f+FzfCP/AKKb4D/8Hlv/APF0f8Lm+Ef/ AEU3wH/4PLf/AOLr8Lv+E38G/wDQ2eGf/BpD/wDFUf8ACb+Df+hs8M/+DSH/AOKo/sKj/wA/PyD+ 1av8h+6P/C5vhH/0U3wH/wCDy3/+Lo/4XN8I/wDopvgP/wAHlv8A/F1+F3/Cb+Df+hs8M/8Ag0h/ +Ko/4Tfwb/0Nnhn/AMGkP/xVH9hUf+fn5B/atX+Q/dH/AIXN8I/+im+A/wDweW//AMXR/wALm+Ef /RTfAf8A4PLf/wCLr8Lv+E38G/8AQ2eGf/BpD/8AFUf8Jv4N/wChs8M/+DSH/wCKo/sKj/z8/IP7 Vq/yH7o/8Lm+Ef8A0U3wH/4PLf8A+Lo/4XN8I/8AopvgP/weW/8A8XX4Xf8ACb+Df+hs8M/+DSH/ AOKo/wCE38G/9DZ4Z/8ABpD/APFUf2FR/wCfn5B/atX+Q/dH/hc3wj/6Kb4D/wDB5b//ABdH/C5v hH/0U3wH/wCDy3/+Lr8Lv+E38G/9DZ4Z/wDBpD/8VR/wm/g3/obPDP8A4NIf/iqP7Co/8/PyD+1a v8h+6DfGj4RKpJ+JvgQ49NcgJ/8AQq/Pb9pv4m+HPiD8XdJTwvdDUdN0q1kje+RSI5pJCmQmeoAT 73Q7uOlfHH/Cb+Df+hs8M/8Ag0h/+Ko/4Tfwb/0Nnhn/AMGkP/xVdOEyqjQqKfPdowxGPq1YcvLY 72x1O90zWrPUtNu5rHULSZZra4iOGjdTkEf4dD0r9Gfhl+1v4R1fQbbT/iCzeGNdjUI92ImezuD0 3BgCY89SH4H941+VP/Cb+Df+hs8M/wDg0h/+Ko/4Tfwb/wBDZ4Z/8GkP/wAVXVi8HQxKtN6rqYYf E1qL91H7mx/Gv4QyQq4+JngdQRkB9agU/kWyKf8A8Lo+EX/RTvAf/g8t/wD4uvwv/wCE38G/9DZ4 Z/8ABpD/APFUf8Jv4N/6Gzwz/wCDSH/4qvM/sKj/AM/PyO7+1av8h+6H/C6PhF/0U7wH/wCDy3/+ LrPvvij8DNUaFtT8dfDPUTEcxG51S1k2H1G5jj8K/D//AITfwb/0Nnhn/wAGkP8A8VR/wm/g3/ob PDP/AINIf/iqP7Co/wDPz8g/tWr/ACH7of8AC5/hCBgfE3wGB/2HLf8A+Ko/4XR8Iv8Aop3gP/we W/8A8XX4X/8ACb+Df+hs8M/+DSH/AOKo/wCE38G/9DZ4Z/8ABpD/APFUf2FR/wCfn5B/atX+Q/dD /hdHwi/6Kd4D/wDB5b//ABdH/C6PhF/0U7wH/wCDy3/+Lr8L/wDhN/Bv/Q2eGf8AwaQ//FUf8Jv4 N/6Gzwz/AODSH/4qj+wqP/Pz8g/tWr/Ifuh/wuj4Rf8ARTvAf/g8t/8A4uszVPj78HNK097ib4h+ GbtVGdlhdi6c/RYtxP5V+IX/AAm/g3/obPDP/g0h/wDiqP8AhN/Bv/Q2eGf/AAaQ/wDxVCyKh1qf kDzWr/J+Z9q/Hb9o6f4k2LeF/C9vd6V4R3g3M0/yz3+DwpUfcjzzgnLcZxyD8veb7muL/wCE38G/ 9DZ4Z/8ABpD/APFUf8Jv4N/6Gzwz/wCDSH/4qvYw9GlQhyQtY82tUq1Zc0j+hyiisiSbXhcyCHTd IkhDHYz6lIrMueCQITg47ZP1Nfn59ea9FYvn+I/+gVon/g1k/wDjFHn+I/8AoFaJ/wCDWT/4xQBt UVi+f4j/AOgVon/g1k/+MUef4j/6BWif+DWT/wCMUAbVFYvn+I/+gVon/g1k/wDjFHn+I/8AoFaJ /wCDWT/4xQBtUVi+f4j/AOgVon/g1k/+MUef4j/6BWif+DWT/wCMUAbVFYvn+I/+gVon/g1k/wDj FHn+I/8AoFaJ/wCDWT/4xQBtUVi+f4j/AOgVon/g1k/+MUef4j/6BWif+DWT/wCMUAbVFYvn+I/+ gVon/g1k/wDjFHn+I/8AoFaJ/wCDWT/4xQBtUVi+f4j/AOgVon/g1k/+MVds5NRcSf2ha2VtjHl/ Z7ppt3XOcxpjt6/hQBdooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACqkN/Y3N7PbW97aXFzCcTRRzKzxnOPmAORz61brxTX/AIRXN9q3iXUfDXilvB+p61rqalc3dhZM ku1bAWnls0U0ZkIcC4BclN6gNG4ByAe100uqsqsyqWOFBPU4zgfgDXivin4XeLNd8Y61qemfE3WN Agvb2O4hgiN2fsqrZ/Z/LQLdpFtD/wCkL+7A8z74kHFcaf2e9fPiLQtRPxd8VyT2MJinmklu3nnD WUFu4WU3eYg0sctwcZw0uFI2lmAPp6msypGzuyoijLMxwAPU182t8EviF9is7SH46+Kbe1tLuGWD ZBO00kSJMGimke6YyAtKjBuD+6Tdv5NbnxR+GPjP4lLoNjF40/4RPThoGoWet/YDcslxPcPZ+WVh EyI6BIrlD5ochJmChSxYAHvFFfLknwG+I72tpE37QPi+QQNelpHgnDzC4tPs6hil0o/dt++UqBhy du04I6HSvgx4qh8MeNNI8RfFrxF4psdf8LHRFiuoHC2Tm0jt2uEHnHLEo8h6EtK3zUAfQVNZ1RQX ZVBIAJOOScAfma+Vovgt8Vr7Urh7v4va7oUMkGoRwvZ313PJZiUNDaCJWnCHy4hHIzSrK5cvtZW/ ensdV+Ct3r3hzwLZa3441bUbrQQUu74+fHPfodRsb776XCtGw+wpGGLPgOSOQKAPeqarK6koysMk ZBzyDgj868I8L/CXxrofwr8Q6BrHxh8S+K9S1G6gng1S8jlje2WOfzXiGy43+XIv7ptjo2zo2ea5 +P4C+LLKLTk0j4w+IdISLWItTvYoVu3juZFv7u7lQK9421JVuUicEtu8kMxYkigD6Zor5j0H4EeO NF1e3mn+N3irWrGL7Dusr2S/ZZDbwTROzOL4SEytKJSN2N8abg4AAr6P+z14t0rweuiN8bPF01jB YQW1jFCbq3W1MOmXFkpHl3YO0STRz7cjLQJuLNiRQD6i3L5mzcu/GduecetAZWZgrKxU4YA9DgHB /Aj86+e9W+CvirU7Dw0YPixr2l6zpnheXRrjWLWGZbq6kaORUuTi4CFgzhyJEkOVyrRsdwzLT4Ee M7KK7aH4z+IlvLqaWee6W3nWQyNZRWyNhboK5Uwox80ScKAnlNlyAfTNFeb/AA28Ea34H8NXdlrv jfWPHd3NICt9qRl8xEUssaYaV14i8oMwAZ3DuxO8KnpFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFVmW83sVntgueAYCSB/31VmmP92gCDbef8/Fp/4Dn/4ujbef 8/Fp/wCA5/8Ai6cWx1OK5LxP438P+FII01K7mm1KdS1ppllC1xeXOOuyJMsQO7HCjuRUVKkYR5pO yNqFCpWmoU4tt9EdXtvP+fi0/wDAc/8AxdG28/5+LT/wHP8A8XXgvhb4pG51/WNZ8Y+MPBejaDLq CafpGiWtxHPdWsrY2i8mjkdFmY/8s14UdWJ4Hp9n4+8EX95qVtZeMPDN1c6dGsmoRxanExtlbo0n zfKD2J61z0cdRqK6l9/+R3YvJsZh5uMoN26pNrp1tZ2bS0ur7NnV7bz/AJ+LT/wHP/xdG28/5+LT /wABz/8AF1n2Gt6Pquny3el6vpupWkZxJPa3SSxocBuWUkDgg/Q5rzmb4mWE3xp0nw9pWq+GJNF8 v/iaajc6kFxNJgW9rb4O2SZ87iATtXbxl1rWeIpwSbe5z0MvxFaUowg/dTb8rd/yS6vRanq229/5 +LX/AMBz/wDF0kMs32+a3mMTlI0cOilc7iwxgk/3eue/tzOnJNV4/wDkYbr/AK94v/QpK2OMuUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUx/u0+uZntPGD3kxt9d8NRW5kYwpJoUzuiZO0MwugGIGASAMnnA6UAYPjfV/EVsulaF4T0+SbXt XkeOPUZrZpLPSo1Xc9xMRgEgYCR5BdyBwAxHwLeeFvijD8SfiRaDw98RNeurnxXa2L6lqOki8KaS qHztRgzshmnkc4WMH9yn3VGK/RE2HjQ9fEHhU/8AcvTf/JdL9g8af9DB4V/8J6b/AOS68fMcp+uS i5VGrdvS33+Z9fw7xbLKITjToRlzJXb3upJp+miVtt73u0/hPxX4a1KLwf4Vi+Gnw+8VQeNPCPjC N7PwzreiiPT9UhZNr3DNFmFEIkLmZ5DJuTBJOKm0W/lHwT8UeIPHHh3W7344axdfY/E8dx4XmeDw /bSSiBpo444ykkUcDbhIC7ycc4BA+5f7P8Z4/wCQ/wCFf/Cem/8Akul+weNOP+Kg8K8dP+Kem/8A kuuX/V9KblGp0ta2m1k7X3S0v26X1PW/4iBKVBUqlC9mnzcz5mr8zg5NO8G/ecd72vJpcp+X/wAY PFOuWXh6z+FXw/8ACXivwP8ACK202P8Asx30S4jPiSeSdY5J5tqbzEitJMY2CtKUyRtIFe9/s1+B dMHw78JaF4h0XxWdQ0yZ9UuFu/D0lpYzXSyEwXMk8n/HwcEPEiYVOpQMM19iix8aDp4g8Kj/ALl6 b/5LpPsHjTOf+Eg8K5/7F6b/AOS6zw3Dns8X7edTm0slbRLstdlb7u71OnMvEiWIyhYCjh/Zu/M5 Kd5Sk005Sbjdt3bbvdu1rRSidPEu0HnNQx/8jDdf9e8X/oUlYAsvGoPHiHwt/wCE/N/8mVq6Xa6r A9zNrF/p9/cybVRrOxe2RUXOAVaWQk5ZucgYwMcZP0x+YmtRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWKl/qV15sljYWUtss0kQae8aN iUdkb5RGwxlTjnpjp0rarDgg1SwjlgtbbT7qFriWZZJbto2/eSNIRtEbdN2OvOM8dKAJfP13/oGa V/4MX/8AjNHn67/0DdK/8GL/APxmnedrn/QO0n/wYv8A/GaPO1z/AKB2k/8Agxf/AOM0AN8/Xf8A oG6V/wCDF/8A4zUU2o6lZiGW+06yS2e4ihZoL1pHBkkWNTtMagjcwzz0z16Gfztc/wCgdpP/AIMX /wDjNVbq31bUYYbe4t9OtYVuoZmkju3lb93KkmApjXrsx14znnGCAZup+JobLR7zVZtV0vRtKtYX knnv4tyxohJMrOJVATYM88jIJxgisi38bWd14Xt9at/F3haTSp5VhiuhZtsaRpRCEz5/DeYQm08h uCM8VznjL4b6nrvh/WtCtJLIaFqFo9t5fyF40cMrL5csbxsoGBhwytyGXHB8Eu/2Tbm9sYra48Q+ IJrdGikEM9xZTxmSO8iukYpLbMNqmGOJY8bFjGAoIDAA+qr/AMTHStJub/UvEvhuwsbcbri4nsmS OEZAJZjPhQMjJPArYt9VuftNqslxY3qSEJJ5MRiIyT84y7Aj7o28fxEE8Kfi3/hi/wAPr4a1HS4Y by2iv7doL2WK7gE1wjXf2tg7+Tl8vgEtnIAzyM19ReHfBuuWl5Yf2ndW8dpbKvywsC7lCuAV2bAp AOcYx2AzkAHqlFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV5hfeMPhpB4+1zQLzxpFb+INNuLJN UsBr86PZvfMwtFdBJhPNKtsHAwOwr0+vk7xV+x18NfFnxD1/xdd+IviFa+JNc1M6hq90NSguobt1 urW4tka0uoJbYJbizghj2xAmJSJDIx3UAfRz6ZoscrxyalqSOmN6trtyCuQSMjzeMgE/ga47U/F/ wt0bwTL4k1Px7Z2ehR3F5bNfP4pmMRms0nku4gRL80kS2tyzoMsohkyPlNeIT/sT/C95pZbLxL8Q tKuPscVrbz295ZvNAi2kFm37yW2dpi8Nui5nMvl7n8ryt5B3tW/ZH+G2r/s0Q/CufVPFUPh6HXNX 1eC4h+xfao5dUtr+2ukDNbFSuzUrkoWQureXhsIBQB7pCPDE+tzadDrOoPexCMtGNcuufM37AD5m GJ8qTgEn5TVqSx0GJphLq19GYSomDa/cDyyxwob97xk8DPWvnmD9j34YWfxR0fxXp+q+MdMu9M8S f27aWtnPaxQJL/aV1qPkALbhlt/Nu5FMasAUWMEllDVznjP9inwT8RvGfxQ1jxb4v8YWr+ML+aRo 9B+yWht7ea2tYHiZ2t3eZibVGDSMwTkIqBpN4B9W/wBmaL9peH+0dS85WVWT+3bncpboCPN6nHHr Vn+wLH/nvrf/AIObr/45Xx1Z/sUeHLr9oXxP448TeL9YuY7rxJba1o9rpUEVq8EkV9ql6wuHZH8/ e+qSLuOHQRjY6KVjj+36AMX+wLH/AJ763/4Obr/45R/YFj/z31v/AMHN1/8AHK2qKAMX+wLH/nvr f/g5uv8A45R/YFj/AM99b/8ABzdf/HK2qKAMX+wLH/nvrf8A4Obr/wCOUf2BY/8APfW//Bzdf/HK 2qKAMX+wLH/nvrf/AIObr/45R/YFj/z31v8A8HN1/wDHK2qKAMX+wLH/AJ763/4Obr/45V2zsILE SeTJevvxn7ReSz4xnpvY469utXaKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAK8ff4xaNbeOLOxv9Ou7PRL/XZdB03VPMWQ3GoRXC2zxtCuXjj81iqyHglGLBQY2k 9gr5c1rx58IF+OmraNrPwusbnxHdarBpWsajc6PZEzTG6tlhjeRzumk2vp12sQ3P5LxOBuj2gA9H X44fD5/hmPGP2/Uk8NG8gtVv5dNmSMvNCsynLKPl2MPmPG4hBlyFOPq37RHw40zTI5ornV9SuZop mtrWDT3V5nito7mSFTIFXzVjkG5M5RlZWwwxXE+Hvif8JPGXw58YWel/DSy1DwZ4R8OWuv3lsun2 MlsGmsRPFBFCG2+eIhJEcgKpQqWANcrN8R/gvZafe6MfhXbeLb2xN9MQ403UDM926T3ziZpWHlzN fudxwJf36gfIVIB7Kn7RHwtuNOsrvT9W1XWLa7neGGTT9HuZwSr2iAkqhwGe/tFU+suDjZJsvw/G 7wVqXw61XxL4efU/EFpp+u2WkXEFrZSCcy3V1DbRssbAMVJmVwcDco3D5SGPj2l/Gf4NR+Ljo5+G VjoEgv4/tTSWenKbV5b+OE3MyJIWSJXtIJXnI2AwwjcXVQMTw7+0F8JbES6TpHwpg04ajJbajY2m lWFmsd4TaR6hbSSEbUE4JDYyShMT5w+5QD2/SP2iPhPrutiw0zxDNcTO1ksJNjMole9Z1toxlch5 DFLhGAbEbNjbhiX/AO0B8O4v2eL34laPfX/iTQ4xOtrHp9jK8t5JFZvelEXbn/j3jaTJ4ABB+YFa 4vxH4t+E3ws8Y3cEnwi0/TpLJbSZtQ0rQ7PalzhzAo2fvB5QmnYybcIHcgnc1cPpnxo+Dut/ZPh/ e/B2y/sPXNTtv7N0waRZz2dx9ptoCks8f3EkBubWJhhsC5hIZlbIAPYp/wBo/wCFkGr3MI1m4msL ZLj7VqSWzfZopIruztBEWOCWkmvYlUgFeGJYDBK3P7Rfw1tVsrt7rWRoN1bSzRa1JpcsVm2y6gsw gaRVJZri4WLgfKyndtBUnxOT41fCDUNXjmsvg1ptzptxfRf2/qE2l2DrF9utZ71XdkZskGyR7iR/ lh8hy7ZiFeo/EbRvC+gyeFLjwx4H+Et7Y6rqFxY3xu/DkU5/0axu7sBGjZQCpsni2kHazA/wFSAd pp3xs8Fatrt9Dp8upz6VaaYt8+qtYSpBIrSRxhI9yguwaQBsD5SCDg0lr8c/hzd+JrrSYtU1AXUF zJbln0udYnkjWBpFRym1tourckg4/eDqQ2PE9K+LPwsj8RQaRqvwn0jQ73xD/ZOiarANLsiH+2ma KKKUox86EJBF8u0qqnBPAFR658YPgPo+q6p4Z1H4X6JJbWWv/wBmSwR6XYSxl/tT27u0akmM79Ni cLIqllS3b+EbQD2vTPj18MtXknS01q5Dw3JgkSWwlRlb7Ta2wJUrkAyXtuASBlX3jK/NVPSPj54L 8Q6Pq2peHo9U1rT7BtMjkktoRvaS/v5bJFCsR9x4t7HP3WGMkEV5J4W+JfwD8S/FTRfDdr8INJsd Wv8AVngtpZNAsGWKY29neEsyFtko+0QeZGf3iSRncPlVm0v+FkfDXQPHd34V0v4S6RD4cmnubTXB p1jYGTzLXVbWwtzJbRtvYGe7eRVZd2wh1GWK0AdFrP7U3w9s7Cw/sW117xBqd3Z/2hHpy2T28wsx a/bHnKyAFf3BjZVYDc0qLkYkKdjovxq0HV/ht4q1wabqxu/DVney61Z21rLJHDNZjM1qkzoiPKAU IHGQ4IzhsfPN38b/AIJJ4PTxfonwa028uRa2MW3+xbD7ZNa3NyunNBBGG8yXbBCUKqNigQo3y5K+ l2vxE+Gtxp3xC1Tw/wCAfDE2oaVf2mmazKIrVYr221G+EUshuEVlkiY+ZMwJIbA37X3qgB1tr+0F 4DOn2K6mNc0/VZ7yPTzZJpFzLm9eee2FvG/ljeTNa3SK2AGEDNwCufRPBXjnw78QPCR1vw1PeT2I aMH7VZS20g823huYyUkVWw0M8Tjjo+OoIHCfDu8+GXxS0GPxhpfgTQ4LnT75Vgnu9MtJJoZWEd+G SSPcA4e63thspP5oPzAk+s6Zo+kaLZNbaNpenaTbNs3RWVskKHZEkKcKAPljjjQeioqjhQKANGii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK+Z4/wBoH4e6F8cNS8Dw +HdYtdauvFAsrue2gjeOW4kmS2E0kgbBYkLhclvLQrgOhiX6Yr581H4qfETT/Fd/a/8ACpdTutPS /aKzuYBdObiNbu+twCFtyEd1tYZVZiIQlwheRAULgGPcftF2utfAfw74u8EaFeyXGt+K7fw9aW2s QiIxSzwecJJFDggIpBZcgllZAQCJK0vEXxyn8PfFj4iaO+g2s2jeDksptRunvBFPNHcwg4hjOd/l yS2+4jkrIwVGcIsluw+Jnj+B/hFp+qfDzWL698Q26/8ACTXlnplzFBo8vCtvDKdgD5PzHkDIOCGO H4n+K/xVsJNZstO+Fl/JKk14un3UNre3CtFDcXsccjhLYj50tIW2KSxF9EUDhCWALviT49eDPBtt /wAJLN4W1yax1LQdM1WbUrWGEmRLtLxreJ/nBDKlnN8zYQF413fMSvJT/tY6DL8ZLHQNJ8P3t1pc Fxqq61dOQJYobG288yxLnD5CyEqecKNuScV0Vl8XviVe/EXw5pt58LtX0bRHvm/tjUv7Lv7kLbLa h1kjUW6kGWWRVVTl4xC4kRWYBcr4yfEXXdK+IGseCrf/AIRnUtCn0tWure9jRtz3Y+xw2rgsBsWW SO6lY9IA+cLzXq5Pk9fMq7o0bXtfXT+tyKlRQV2eja38a9E0Hw54a1K+8P8AiR4dd0C41qwjihjL +Rb2zXMyyAuAjiPy+GIBaQLnhiK3gz48+E/GvifUdG021vItTsrfUJ5YXubdvMjsjaJJLGwk2tC7 3YWOXIR/Kc5AFedeFfjhaXnifwJ/wlWn+DbbxPfW/wBh/tX+1kj+zRtaWF5OWVlBjViZ4yBlRNbR xlssNvHeI/2nfFVnc+JG0nRtJdEsL4abgzSpbTwxhoRJthLTM7/ux5W6PLbgzqCR71DgHOa1b2Ua ava97qzV2tPufnp3tfJ4qmle56Bo37V3g7X5dKtNI8NeKLzU9QWD7PbhIo1Z5tRGnqN8jqCokO5n HAAwMt8tUB+1bo954/8AC+naX4V1a4stZnsraCN57YXhmvE3Qq0XnfuVyVO5+GU7k3KQw2vFXxvv NH+NM9hot54Q1rw1bW1vOzJeENKjLP5qrKu5GkBjQBBjG4bvvLnK8OftB33iD4Z3sstvoug+IrW8 0eONdQu9sdzHcXMcdyeUU/u497SMqAJnoVUO/PHgvNZUY1VD3Xy9duZ2V1v1100H9Zhe1zfsP2jt H1z4feMNX0bwzqYvtD8GyeJFs9Qu7eJpEWBZRE4R3eIndgMy7WUblLKQaz/D37QnhiwvPD+g6h4P 1XQtQ1zW2itxZJFLayNc3ez7RvV8AySys5U4dgJGAJwp8wX9pjT9I8dtqNt8OdIstb1qK2W6uzcS hriUWE9y1uHWEknzIhCCwRVLl26YPQXX7WVxFbSy6f4MtNdhEl4Iriz1JxHuhcIkR3RBizgl/MRW jIG1WY7ivY/DriC8f3G+3vR/O9ujJ+t0u51918b/AAB8Np7vT7fwLrulx3l/rEsQsLaHbftprG3m kB3gZJtzGqsQVSNMhV2ilg/as8Ay6DrV5/Z+rtNptxdQzW9vJBcs6wXthZGdTFI263aW/TEoyNsM p6rg9P4f+Jlzr/xJ8MxSeIPCdhbXE2oW1/pkV7HKrGC5kgheKQ7XaSfdbyRrtC+Ws33yyFfbrKws tOs3t7C0gtIHnlnaOJAqmSWRpZHIHdnd2J7lie9fMZhltfBTUKq1f6Np/iul1azTNoTUtj5ZT9rH wvca1dpZ+HdR+wWmnSXl1Jc3kEcqfPAsKqqsyyMwkkcrGzOqxEBWk3Rr6J4z+O/g3wX+z1oHxJul utQ0LVyggjtSjSrutpLkqwzjeEicbc/ewCVGWHtmBzwOajjhhhRlhiiiVnLsEUAFicljjuTyTXnl nzbpv7SOl634u8J6Lp/hbVdPu9a1C0iU6ndW0YEFxbW1yskarKWlby7pNyoCUP3woZSfpejvRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWQfEGgjxNDop1vSB rMys0NgbyP7RIFLBisedxAKsDgcbT6UAa9FRySxQxh5pI4kLqgZ2ABZiFUc9ySAB3JFEcsUpkEUk chR9j7WB2t6H0PI4oAkooqrdX9jZQyyXl5aWkccfmSNNMqBEzjcSTwM8Zpxi5OyQE5jjNwsxjQyq pVXK/MAcEgH0O0fkPSn1Sk1LTolvmlv7KNbJQ14WnUfZwV3Avz8o288445qrP4g0G1trma61vSLa G3EZuJJbyNViEn+rLEn5d38OevatFRqS2i3/AF/wfxFdGvRVS6v7Cxt5pb69tLOKKIyyvPMqKiDg sSTwvueKQajp5W9IvrMizGbsiZf3A27vn5+X5SG57c1KpzaukO5aKKzIWVWKnKkjocEZH4Ej8aFV UQKiqijoFGBWQfEfh4SlDrujBxHHIVN7HkJIQI269GLKFPfIx1rZpzpzh8SaEmgooorMYUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfOXh34beAG/aX 1/XrnxrpviXXDeJNDoVvfiM2NxFe6hdBpIkmJkdDeMoDqApiLYyRt+ja+X/Huh+ELzxOdWf4jS6E t/4xttRuLTS7KeS4v0sNmnXVgPs7iRg8s0aMQDtLAbW60AUdQ/Z08YaprF1PffGjWZ7WbxHFrEVt /Z8qratHeW10vlYugPNAtvLV3DqFlfKNkCsmb4CX2j6BrVofjrd+G9ZlhjvGnt2nhjt4lNwJpGjl vXcq7SwHzDIGRraPDgfKNDwh8M7jU49B1Pwz8etX8QaLpSR295a3BuJ4bqWTTbKP94xuRIGkZTOy lif9JKja2521viF4c8PeKPitZeJ774k+ANIsY7y2sdHsb7SA0n9p2moJI/mS/aozcEyW/k+UVGwb 9hBckgDbD4Ra/oPxHi1rUPjW1zZDU76f+zL63lEUkd/D5EFuxN3khZQXVhh5GyMggEaXxa+Heq+J vFmo6rYyeDtF3aXEjXt9q89tJNHbzLNvn8mNXMUbMQAJQFLK2RkqeY8SfAzwhD8N4lHjXRdHs4tB 03RLzUptNSQzm3sb/SjcOVlX980WpKqsciMwpncp2j0TxN8Px4jvLPxHpPjXSofE6+H73TrLW9a0 G2vpYo7m6sb1HEa+Sp8gWoMasDhnSRtxQh/RyvNK+Ar+2o/F/T/QicFNWZwOn/DT4paH4d8UJouu /D4y+IDAba+1W5nvhBIJ55xKkbRLEX3Tr5YRVjXy1JRySTwL/DC8tBbaPb+LfhFpV8bZYdGjg8S3 cVxG6xmB3yCJZ2R4yIgzERgMjeYeR9F2Pwz0tfCXgfSG162vx4XvbGbSkaziaOx+ywmBo7bJMybw kgLSyzOPnG4jIrznw/8As8aTp3wul8LN40tdUEulalp/n/YizhbmwtLIsN87t+7FuH27to8wIgjj VEHvw43zKEpSjypy1em9kkuvRK3pfu75PDQZ0GreFfFvifVrnW7S0+F82o6voS2a3S6rcOLq3S5S aOUPFCkhKKwCvG67HcSIVOFrjfC3wo+InhTwx4i0/Q9U+Gktxq2kx6VaG8lluIIDA107uYPKCyv5 9xJIynCrgoFC4C+gaP8AD7QPDHi7wxrU3iPw++vFL63kmj0/yjff2jq8Wpqke2besSPHOkSFnX97 klsMr3dN+E3h7R7bwu+lXmg2jabdaydKePTlRBDqM01wLWLZIpWOPevCMN/lA4XjHNR4sxlOg6MY x5HbRq6921t30svlpsU6EW7nh8/wm8SnwxrelReIPhVaQatp9xYXi/25fOssyW0UE9xtdjtnjSJ8 mPZ8sjiUODX2JoGtWGveGLbUNP1LSNVjKhZptNvluoBIAN6rIoAbB74U+w6V80aV8DL/AELVNKfR viL4LjW2X7RYR3fhYyvLIlja2FnM7reo0oQwJI68LNI4+7tTb698NLPS/CHwZhsJ/FHh/W/JaW7u tVtbY2n2pnLSS3MqvNIS7sJJGcMFI+6qqAK4s2z/ABWYxgq9vdva3nZfovuKp0ow2PUqKpWupWF7 bxS2t5bzJISF2uMkgZK46hh3B5Hemx6rpcwiMOpWEol2+VsuFO/cSBjB5zg49cV4poX6K5K08d+E L/UdBtLHX7C7m1qAT6Z5LF1uEKO64YDALLHKyqSCwikwDsbHW0AFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfLmt+DPgjrfxL1CPX/H0eqLZam7v4buL2ze1 s57q+jupVK+V5jCW509sh3ba0cyoUKkL9R18Pax45+DHhf48eNdQ1nwZc3pl17TtNuTrTLNptq32 zVjLqMPnho4UWdrkTSRny1eSMSNG/miMA7L4Z6h8KvDthqLaR8RfEOl+H49Vt7FLDXv7OW2luLaG GCJUbyPMWRYrRI2jd1mT7zorurGvqvgH4A6j45ttXPj63stXn1NdZEkF5ZHzpA97q0ZcvC2V2X7y rk5MUKclVkLUvEMn7NzeK7rw3eat4h0rxReXaWsVy19qTXBSC6ltVSN5GIa0W486LyhmHIJK7FDD H0rR/wBm3VdSGreHPCOpa6tiumWFvey67fFcak76AIx5kxOEgfY3H3CuPmCkAGh4X8LfAvw78LbH wze/GDR70/YZ7zUZY72wgiuEh0uG1uHASIbY0gKSZLF8kO7uUBXIvPhn+zJqJ8QzT/EW4ktNUuXv LmUa/bLFYmOcQzQoNgMatBPbae6EHEFnDGSskbO2z4Vu/Btm1p8P0+EGm6JpGtya/a6jPFq95dpb W8V2lhqDvcLbkxLI0fy73iXZGmHU4VeL+K/iX4LW+o+M207RNeXW7S1LWPiHQtUkJvUuZrbULtrW QsYyFW+853jJ8qJZTL5MBUyAHYfD7SP2fNI+NVhrHhj4kaxN4ieCbToYrm+haE/ZZ4rDzSPJCq7T tebHJHmSapfFcllEXJeGvhl8BdD0DXH8RfGTQ5XeVLC7NjdWNpDAjaI9rCmTGWU/Y2mmZgVDAHzf METE3vEL/s6DSX8PzadrOmW7O+inWYLmeSKexzcapJLFIWMUqtJuIZAWjeaNlx5a7fR/EfxR/Zx1 uLULDVJDqcjRyXt7Dp2nXRlYPo8nmO/kDJxp0zcnorDb8yfKAeTWXw4+CF38dvEC3HxSj/sqKxuf tKb7a3mln1XyJXcXSRqIwEspD5KbBGoLbIwheT0O48G/AgeBNC8LX3xYY2Fs+p2FqbzU7AvI0kv2 29G94PlYbEbzV2siqCrguzNiRWn7N/iP4ueNtF1HwZftrNr4tCSJBf3txLfXghvN10kMUm4IiQ3q +aoMfEsYbzllhjveHPHf7N8nh6fSZdJe31LxbImqXmkSx3eoXUs2qxfZc5+Yq0q+ZEfLO0bTyCy7 gDL/AOEV/Zz1Hw3/AGwfGN3e3yzXMUFx/oUV0rpf6tZyNDGIFVNtzqd0QiKMmKJgpIbfaPgz9nm2 8W+Drew1vUrjWvEr/wBn6eLJreS4cG2ubV43Ij38R/aFYAl1ELsQEhkZc6GX9lacweIr/QvEqztJ NPp9xqF7qc9zfL+71V5VQzNI+6S537WG4tldvQVmard/syW8djbGwv8AxZqNzqcfiK2jt7u6tks4 Z7zTA02YGGY4ClhL0ffIhZSzGQgA6OH4XfAO4vpPEH/C0dbtpbqae9aD+3LPy7c6lbRkIsSxFEAR FdAo+pZdoFHT/Bfwf8B2mgXmjt8RvE+o/wBu/aobhrewurlnl1Wa3Ebm4jVdjXdyyKy/vEDhg6gu x6vwNb/s06r4s0fT/CHg3T9WbXFjg/0+ymurRPsy6hbpjzt8XnA6VdpuUhmCFyzb1L+6Wvwq8C2e qaleQ6RdNPfX0F7KJtUupUjlhvTfx+UjyFYUFyTKUjCox4YEACgDy/4K6J8Ml1bUNO8FQauyeD75 7Bor6eyZLe7ht4dKdxFCd0coTTnXe6IW8+crlJMD6TrnrPwn4bsVtPI0WwZ7XUbrULSSePzpLe5u pZZbiWN3yyF3mkJ2kABiowuBXQ0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFcXqfw3+Hetm+Os+AvBmrG9mE14bzRLeb7RIA4DvuQ7mAkk5OT87f3jntKKA OQHw+8BLrH9or4J8IrqH2xbz7SNHg837Qrb1m3bc+YG+YN1B5zmtLUvC/hnWfEWlavrHh3Q9V1bT H36be3lhHNPZtlWzE7KWQ5VT8pHKg9hW7RQBmWui6NY3wurLSdMs7kediaC1RHHnS+dNyBn95L+8 b+83zHJ5rG1XwF4F13ULy71vwX4T1i6uwou5r7SIJnnCgKu9mUlsBVAz2AHausooA5ux8HeEdLn0 2XTfCvhzT5dOBGnvbaZFG1pmPyz5ZVRsynyfLj5eOlMvPBPgzUfEVzq+oeEfDF/q1xG0c97caXDJ PKjRGFlZ2UsQYiYyCeUJXpxXT0UAcTJ8NPhzNrd3qc3gHwVLqV1N59zdPoluZZpNzNvZymWbc7nJ Ocsx7mpovh54Ag1Cwu4fA/g+G6sTGbKZNGgV7fyiGj8shMrsIBXGNpHGK7CigDBtvCvhez8Nahot p4c0G10e/TZfWEOnxJBcr5KQbZIwu1x5UcceCD8iKvQAViD4YfDQTPIPh54H8x7c27t/YVtloiYy YydnKkxRcdP3af3RjuaKAOa0vwZ4P0R7ZtG8KeG9Ia3kMkBstMhhMTkzksu1Rgk3VycjnM8v99s9 LRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfIP/DQfxR/6Jr8J/8Aw4+o/wDyjo/4 aD+KP/RNfhP/AOHH1H/5R14T9vHt+dH28e351739mU/M8n69M92/4aD+KP8A0TX4T/8Ahx9R/wDl HR/w0H8Uf+ia/Cf/AMOPqP8A8o68J+3j2/Oj7ePb86P7Mp+YfXpnu3/DQfxR/wCia/Cf/wAOPqP/ AMo6P+Gg/ij/ANE1+E//AIcfUf8A5R14T9vHt+dH28e350f2ZT8w+vTPdv8AhoP4o/8ARNfhP/4c fUf/AJR0f8NB/FH/AKJr8J//AA4+o/8Ayjrwn7ePb86Pt49vzo/syn5h9eme7f8ADQfxR/6Jr8J/ /Dj6j/8AKOj/AIaD+KP/AETX4T/+HH1H/wCUdeE/bx7fnR9vHt+dH9mU/MPr0z3b/hoP4o/9E1+E /wD4cfUf/lHR/wANB/FH/omvwn/8OPqP/wAo68J+3j2/Oj7ePb86P7Mp+YfXpnu3/DQfxR/6Jr8J /wDw4+o//KOj/hoP4o/9E1+E/wD4cfUf/lHXhP28e350fbx7fnR/ZlPzD69M92/4aD+KP/RNfhP/ AOHH1H/5R0f8NB/FH/omvwn/APDj6j/8o68J+3j2/Oj7ePb86P7Mp+YfXpnu3/DQfxR/6Jr8J/8A w4+o/wDyjo/4aD+KP/RNfhP/AOHH1H/5R14T9vHt+dH28e350f2ZT8w+vTPdv+Gg/ij/ANE1+E// AIcfUf8A5R0f8NB/FH/omvwn/wDDj6j/APKOvCft49vzo+3j2/Oj+zKfmH16Z7t/w0H8Uf8Aomvw n/8ADj6j/wDKOj/hoP4o/wDRNfhP/wCHH1H/AOUdeE/bx7fnR9vHt+dH9mU/MPr0z3b/AIaD+KP/ AETX4T/+HH1H/wCUdH/DQfxR/wCia/Cf/wAOPqP/AMo68J+3j2/Oj7ePb86P7Mp+YfXpnu3/AA0H 8Uf+ia/Cf/w4+o//ACjo/wCGg/ij/wBE1+E//hx9R/8AlHXhP28e350fbx7fnR/ZlPzD69M92/4a D+KP/RNfhP8A+HH1H/5R0f8ADQfxR/6Jr8J//Dj6j/8AKOvCft49vzo+3j2/Oj+zKfmH16Z7t/w0 H8Uf+ia/Cf8A8OPqP/yjo/4aD+KP/RNfhP8A+HH1H/5R14T9vHt+dH28e350f2ZT8w+vTPdv+Gg/ ij/0TX4T/wDhx9R/+UdH/DQfxR/6Jr8J/wDw4+o//KOvCft49vzo+3j2/Oj+zKfmH16Z7t/w0H8U f+ia/Cf/AMOPqP8A8o6P+Gg/ij/0TX4T/wDhx9R/+UdeE/bx7fnR9vHt+dH9mU/MPr0z3b/hoP4o /wDRNfhP/wCHH1H/AOUdH/DQfxR/6Jr8J/8Aw4+o/wDyjrwn7ePb86Pt49vzo/syn5h9eme7f8NB /FH/AKJr8J//AA4+o/8Ayjo/4aD+KP8A0TX4T/8Ahx9R/wDlHXhP28e350fbx7fnR/ZlPzD69M92 /wCGg/ij/wBE1+E//hx9R/8AlHR/w0H8Uf8Aomvwn/8ADj6j/wDKOvCft49vzo+3j2/Oj+zKfmH1 6ZwP9pfT86P7S+n5157/AGhL/wA9D+VH9oS/89D+Ve97I8nnPQv7S+n51k6h4rtNP1PT9NEd5qWt 6g5j0zR9Ntnur6+cdVhgjBd8dWIG1RyxUAkcn/aEv/PQ/lX0z+zx8T/hX8PdQv7fVfB9h4e17VXA v/FsCvc3F4M5VJ3kLSrGp+6iHy1z8qIM1zYpVIQvTjdm2H5JztN2Ro+Cv2aPHvjSxGr/ABY1G6+H 3hsoXTwnoV8DqlyuM7by+jJW3HrFaMW6EXHVK8X/ALS+n51+r8Oo2GreFP7R0u9tdRsJ4C8NxbSi SOQYPIYcGvxe/tCX/nofyrz8qnOrKbm+36nZj4QpqCiu/wCh6F/aX0/Oj+0vp+dee/2hL/z0P5Uf 2hL/AM9D+Vez7I83nPQv7S+n50f2l9Pzrz3+0Jf+eh/Kj+0Jf+eh/Kj2Qc56F/aX0/OtmTSLw6XD f6Tc+a8sYkks7lyVJIydj9V+hyvptryT+0Jf+eh/KvXNLvmHhaxdpNqi3QknGB8orKrTatY0pyTM AasVvHtbiKWzvEGXt5xtcD1HOGHuCR71L/aX0/Os7xH4i0u9tPsnkRai6nKStwIm9VYYOfcEfWuO /tCX/nofyqoU21qiZSSeh6F/aX0/Oj+0vp+dee/2hL/z0P5Uf2hL/wA9D+VX7InnPQv7S+n50f2l 9Pzrz3+0Jf8Anofyo/tCX/nofyo9kHOd5c63b2WnXF5eXFvaWkEbSzzzSBEiRRlmZicAAAkk8AV0 XwY8QfCv4lftKeG/BWq6h8PvHVhqP2jzdDuri11CO68u2lmGYGLB9pjD8qcFAe2a878NeKJPD3xF 0DXzF9tGm6lBeG337PN8qRX2bsHbnbjODjPQ194/Df8AaaX4hfGjRvCA8F/2Sb/zv9L/ALY87y/L hkl+55K5zsx1GM59q4Meqsab5Y3Vnd32OvCezlNc0rO58pfGfxB8K/hr+0p4k8FaVqHw+8C2GnfZ /K0O1uLXT47XzLaKY4gUqE3GQvwoyXJ75rnbbW7e9063vLO4t7u0njWWCeGQOkqMMqysDgggggjg ivs/4kftNL8PfjRrPhA+C/7WNh5P+l/2x5PmeZDHL9zyWxjfjqc4z7V8HeJfFEniH4i6/r4i+xDU tSnvBb79/lebIz7N2BuxuxnAzjoKMAqsoLmjZWVnfcMX7OM3yu7udR/aX0/Oj+0vp+dee/2hL/z0 P5Uf2hL/AM9D+Vd/sjk5z0L+0vp+dH9pfT8689/tCX/nofyo/tCX/nofyo9kHOe0w+EzP4S0/wAT eMPF2r+C/DOoSSx6RF4fsbe71HUfKKiWTdOGihRWbYAyMzFWPA25kg8EXmpea/w58azeL7OKMyal F4tt4LG70mAfevHe3CxzwJ/GqIJOV2g5ONTxJo/jXxJ+yN8Cbbwb4O8R+Mb4jWjNHpkcQWEfbEAM kszxxR55xucZwcdDUPwv07xl4X1D4t2fjbwb4o8H3o+GOrTxRahbJIsyp5O4xywNJFIRkfKrk8ji vJnOPvP2lpXel/O23oehGL0XJpZa/Iyf+Ea8C58n/hdPxG/tf/n5/wCEasP7I3f9cdv2nb/22ziq Ouadr3hLxZfeHPE0NnDrdjJ5dx9ll3xSAgMkiHqFdCrgH5lDYPINch/whHxn/wCEe/tn/hTnxF/s bbu+0/Z7XzNvXP2bz/tPT/plmvRf2jLySL9srxjGr4A+ycf9ucFb0OR1eWE+bR9b9v8AMyq83s7y jbVfqcp/aX0/Oj+0vp+dee/2hL/z0P5Uf2hL/wA9D+Vd/sjk5z0L+0vp+dH9pfT8689/tCX/AJ6H 8qP7Ql/56H8qPZBznv1h4T8CXfwLufH/AI2sPFfiNV1tdHstK0vxXeaLDE3k+c0zSWjo7sQduGLK NowASTUth8MLLUI7S7t/2Pf2hJtKn2ulyPjrPBI0Z/iEFxrEUinHOyRUb1AqlpsOua9/wT01WDw5 p0muX2k+OP7S1aCC4hjktLEWBVrkiR13KpHKrlyA21WIwfr/APaQ8da94I/Z7ZPDI1m01nW7xdNT WdP0m4vzosTI7y3jRwRuxKojKnGPMdMkKCR89jZuM7Ldt9X5eZ7GGinG72suiPjTXfBXxB8L3F3P F8IPitpPgiCQeVqOvanpN/cWsbY4m+yX88rIhJXzCrYRQzt95q5f+0vp+dfZfw48WXnjH/gkTZ+I 9Q1HU9V1ab4f3A1C91CKVZp7hLV1kcmQAuCwOHGVbqCQc1+eX9oS/wDPQ/lXfltSdWDUumhyY2Ea ck49T0L+0vp+dH9pfT8689/tCX/nofyo/tCX/nofyr0vZHFznNfaD70faD71ztrqEF9psF5Z3EVz azIHiljbKup6EGrHnN6j867OU5rm19oPvR9oPvWL5zeo/Ojzm9R+dPlC56x4G+K3jL4d6m83hzVZ IrSU5udPnzJa3Hb5kzwcfxLhveuB+0H3rF85vUfnR5zeo/OoVKKbaWrKc20k3sbX2g+9H2g+9Yvn N6j86POb1H51fKTc2vtB96PtB96xfOb1H50ec3qPzo5QubX2g+9X7jW725sYbWSUi3iQKsa8A4GM n1Nct5zeo/Ojzm9R+dLkHc2vtB96PtB96xfOb1H50ec3qPzp8orm19oPvR9oPvWL5zeo/Ojzm9R+ dHKFza+0H3o+0H3rF85vUfnR5zeo/OjlC5tfaD711fgfxzqfgH4oaX4t0eCxudRsPM8mK9RmibzI niO4Kyno5IwRzj6V515zeo/Ojzm9R+dTKmpJprRjjNppo9F8ceOdT8ffFDVPFusQWNtqN/5fnRWS MsS+XEkQ2hmY9EBOSec/SuU+0H3rF85vUfnR5zeo/OiNNRSSWiCUnJ3ZtfaD70faD71i+c3qPzo8 5vUfnVcorm19oPvR9oPvWL5zeo/Ojzm9R+dHKFz0a98f+JL74daD4UbUJrbQdJhkjgtLd2RJTJNJ MzyDOGbMm3sNqrxnJPQ+CfjN458Aafq9poWqM9rf2T23k3TPIlqzdJ4gGAWVecE5Xk5U8Y8Y85vU fnR5zeo/OspYenKPK46GiqyTumdh/wAJRrv/AAkH9rf2zqn9qbt32v7U/m56/ezmrXinxfq3jHxr P4g1uSObVJ4IIp5UUjzTDDHCHOSfmYRhm7bicADAHC+c3qPzo85vUfnVKlG97E87tY2vtB96PtB9 6xfOb1H50ec3qPzq+Um5tfaD70faD71i+c3qPzo85vUfnRyhc2vtB96+34v21HfRo7bUfhtb3srQ hLll1vZHKcYb5DA2FPPBJ+pr4G85vUfnR5zeo/OubEYKlXt7SN7G9HE1KV+R2ufaGu/tVWd58DNT 8C+HPhlpnhTTbjS3022S21FTBZwuhjKxwpAigBSQACAOOO1fJP2g+9YvnN6j86POb1H506GEp0U1 BWuKriJ1WnJ3Nr7Qfej7QfesXzm9R+dV7rUILHTZ7y8uIra1hQvLLI2FRR1JNb8pjc//2Q== ------=_NextPart_000_13AC_01CBE320.478617E0-- From touch@isi.edu Tue Mar 15 14:48:50 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1213A6EEF for ; Tue, 15 Mar 2011 14:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.722 X-Spam-Level: X-Spam-Status: No, score=-103.722 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, 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 nXpcJM7cJguN for ; Tue, 15 Mar 2011 14:48:49 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 9D0E53A6E9A for ; Tue, 15 Mar 2011 14:48:49 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p2FLneXq018977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 15 Mar 2011 14:49:50 -0700 (PDT) Message-ID: <4D7FDEF4.9060200@isi.edu> Date: Tue, 15 Mar 2011 14:49:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Wing References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> <12a101cbe33b$fc20e160$f462a420$@com> <4D7FB586.7090503@isi.edu> <138501cbe357$73c325a0$5b4970e0$@com> In-Reply-To: <138501cbe357$73c325a0$5b4970e0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p2FLneXq018977 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:48:50 -0000 Hi, Dan, As a preface, I just want to point out that the statements in ipv4-id that refer to NATs don't add new requirements; IMO, they are just interpretations of *existing* requirements on NATs - granted, that they often ignore, and that may or may not have widespread impact (it's very hard to measure), but I continue to think they're worth stating. Some further notes below. On 3/15/2011 2:25 PM, Dan Wing wrote: >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, March 15, 2011 11:53 AM >> To: Dan Wing >> Cc: mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- >> requirements@tools.ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] CGN REQ: IP-ID >> >> Hi, Dan, >> >> On 3/15/2011 11:08 AM, Dan Wing wrote: >>>> As for the re-writing of the IP-ID field, a requirement reflecting >> what >>>> is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4- >> id- >>>> update-02#section-9 should be added to the I-D. >>> >>> BEHAVE has documented how popular layer 4 protocols are translated on >>> today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). >> Those >>> documents provide minimal guidance, in an attempt to improve NAT >>> operation. BEHAVE has not published a document on how IP is >>> translated. >>> >>> That section describes how to translate IP, and requires a NAT >>> reassemble fragments and re-write the IPID. The requirement is >>> not solely on a NAT but, rather, on any sort of address-sharing >>> device (to include 4rd, IVI, and others in the "A+P family"). >>> >>> Unfortunate to say, but I do not foresee NAT vendors implementing >>> that requirement. Joe, I assume there is demonstrated harm >>> occurring on the Internet where IPIDs collided? >> >> It's difficult to show such measurements, as we don't have access to >> traffic behind NATs. The result of not rewriting the ID appropriately >> can be increased packet reassembly errors, some of which may be caught >> by TCP checksums, some may result in interrupted TLS connections, etc. > > But a significant majority of TCP connections send their segments > with DF=1 (FreeBSD, Linux, OSX, Windows, and iOS). So I doubt the > problem occurs very frequently with TCP. There's already ample evidence that many devices ignore DF=1 as well, though. > I expect it could occur with UDP, especially with applications that > rely on fragmentation (that is, send UDP packets bigger than the MTU). Yes, that too - DNS may be one likely example of this. Joe From dwing@cisco.com Tue Mar 15 14:59:26 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5FF3A6B92 for ; Tue, 15 Mar 2011 14:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.275 X-Spam-Level: X-Spam-Status: No, score=-109.275 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, 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 STa3xHtuvsAm for ; Tue, 15 Mar 2011 14:59:25 -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 0CE153A6E9E for ; Tue, 15 Mar 2011 14:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3300; q=dns/txt; s=iport; t=1300226450; x=1301436050; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Y1JdKUTaFqEgSXWBzUQzyYbYQ0xUDfA2rQ2X1hikZmA=; b=ODNCUTEs8KwGBs2SkF/NvlSpka9yDZmgC49bXuP72hZPb9ZI2v/lH078 NE4OoPwPsgamIsI22i0wIfpwpR9cbydUMMyEXmfyK+keJMM+vA7jPOKbc yWjSGEQvKGSsMYU14Y7ezK0OP7n3xFzB1fDZbAfAXaZVSefyzHd8z8hfK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsDAAJ+f02tJV2Y/2dsb2JhbACYT4Fki1poD6RhnHCFYgSFMJNw X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="278380621" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 15 Mar 2011 22:00:50 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FM0nCf010631; Tue, 15 Mar 2011 22:00:49 GMT From: "Dan Wing" To: "'Joe Touch'" References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> <12a101cbe33b$fc20e160$f462a420$@com> <4D7FB586.7090503@isi.edu> <138501cbe357$73c325a0$5b4970e0$@com> <4D7FDEF4.9060200@isi.edu> In-Reply-To: <4D7FDEF4.9060200@isi.edu> Date: Tue, 15 Mar 2011 15:00:49 -0700 Message-ID: <13be01cbe35c$72022270$56066750$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjWvzqjiveF38QQJqWy7MFsveD/wAAG8hg Content-language: en-us Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:59:26 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, March 15, 2011 2:50 PM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- > requirements@tools.ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: IP-ID > > Hi, Dan, > > As a preface, I just want to point out that the statements in ipv4-id > that refer to NATs don't add new requirements; IMO, they are just > interpretations of *existing* requirements on NATs - granted, that they > often ignore, and that may or may not have widespread impact (it's very > hard to measure), but I continue to think they're worth stating. > > Some further notes below. > > On 3/15/2011 2:25 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Tuesday, March 15, 2011 11:53 AM > >> To: Dan Wing > >> Cc: mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- > >> requirements@tools.ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] CGN REQ: IP-ID > >> > >> Hi, Dan, > >> > >> On 3/15/2011 11:08 AM, Dan Wing wrote: > >>>> As for the re-writing of the IP-ID field, a requirement reflecting > >> what > >>>> is discussed in http://tools.ietf.org/html/draft-ietf-intarea- > ipv4- > >> id- > >>>> update-02#section-9 should be added to the I-D. > >>> > >>> BEHAVE has documented how popular layer 4 protocols are translated > on > >>> today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). > >> Those > >>> documents provide minimal guidance, in an attempt to improve NAT > >>> operation. BEHAVE has not published a document on how IP is > >>> translated. > >>> > >>> That section describes how to translate IP, and requires a NAT > >>> reassemble fragments and re-write the IPID. The requirement is > >>> not solely on a NAT but, rather, on any sort of address-sharing > >>> device (to include 4rd, IVI, and others in the "A+P family"). > >>> > >>> Unfortunate to say, but I do not foresee NAT vendors implementing > >>> that requirement. Joe, I assume there is demonstrated harm > >>> occurring on the Internet where IPIDs collided? > >> > >> It's difficult to show such measurements, as we don't have access to > >> traffic behind NATs. The result of not rewriting the ID > appropriately > >> can be increased packet reassembly errors, some of which may be > caught > >> by TCP checksums, some may result in interrupted TLS connections, > etc. > > > > But a significant majority of TCP connections send their segments > > with DF=1 (FreeBSD, Linux, OSX, Windows, and iOS). So I doubt the > > problem occurs very frequently with TCP. > > There's already ample evidence that many devices ignore DF=1 as well, > though. Neither a host nor a NAPT can fix that, though, especially with the restrictions of Section 6.1 of draft-ietf-intarea-ipv4-id-update which seem to prohibit the NAPT from diddling with the IPID of atomic packets. > > I expect it could occur with UDP, especially with applications that > > rely on fragmentation (that is, send UDP packets bigger than the > MTU). > > Yes, that too - DNS may be one likely example of this. Agreed, especially with EDNS0, DNSSEC, and AAAA making those packets larger. -d From rpenno@juniper.net Tue Mar 15 15:14:25 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601A23A6BC5 for ; Tue, 15 Mar 2011 15:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.093 X-Spam-Level: X-Spam-Status: No, score=-6.093 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, J_BACKHAIR_27=1, 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 1X1qLPrFI+Mt for ; Tue, 15 Mar 2011 15:14:24 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 6C6D43A6B30 for ; Tue, 15 Mar 2011 15:14:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTX/lDgy8paqulkbFfUMioZceubVwxhx2@postini.com; Tue, 15 Mar 2011 15:15:50 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 15:12:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 18:13:26 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 18:13:23 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDAABPhPAAABjRLN Message-ID: In-Reply-To: <138801cbe358$1651fc10$42f5f430$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:14:25 -0000 There is a premise of stopping spam, abuse, etc. I'm assuming other ISP and content providers will be contacting the ISP which hosts the attacker and reporting the public IP address and source port (as required by a recent draft). The ISP would then investigate and take appropriate action. Are saying the Content Providers will take sole action and have a long list of public IP<->private IP in their servers (or routers)? Can you elaborate Providers will operationalize using the private IP inside those connections to filter anything? A On 3/15/11 2:29 PM, "Dan Wing" wrote: >> -----Original Message----- >> From: Reinaldo Penno [mailto:rpenno@juniper.net] >> Sent: Tuesday, March 15, 2011 12:07 PM >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- >> lsn-requirements@tools.ietf.org >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >>=20 >> But there are operational solutions for this problem which do not need >> man-in-the-middle rewrite. >>=20 >> The abusers can be put in special public pool of address that is there >> for such sole purpose. >=20 > For that, the ISP would decide which of their subscribers is abusive?? >=20 > -d >=20 >=20 >> BTW, this already done today in many different >> forms. >>=20 >> On 3/15/11 11:46 AM, "Dan Wing" wrote: >>=20 >>> The alternative is that everyone sharing the same IPv4 address be >>> put into the same low-quality of service, such as throttling all >>> of their activity, challenging them all with captchas, or blocking >>> them outright. >=20 From rpenno@juniper.net Tue Mar 15 15:18:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14BA3A6BC6 for ; Tue, 15 Mar 2011 15:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 mg5M+NO0MnkB for ; Tue, 15 Mar 2011 15:18:22 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 73B053A6B44 for ; Tue, 15 Mar 2011 15:18:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTX/mAJOYpDo8eksd/5be8xm/IlU5OBnv@postini.com; Tue, 15 Mar 2011 15:19:48 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 15:17:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 18:18:49 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 18:18:47 -0400 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3Syg== Message-ID: In-Reply-To: <138701cbe357$ed3e63e0$c7bb2ba0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'DENG Xiaohong ESP/PEK' , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:18:23 -0000 That are security considerations that need to be understood in relation to port block. But many of those can be mitigated. Having said that, I would guess there are at least 3 CGN vendors that implement such a feature. Therefore, CGN vendors already do that today. As for your example, If the attacker has this access to your machine the victim should be worried about his credit card, not ports. (;-) On 3/15/11 2:28 PM, "Dan Wing" wrote: >> A "Port Set" does not mean necessarily "contiguous port range"! >=20 > It is not relevant if they are contiguous or not. This is a false sense = of > security. >=20 > If they are fixed, the ports can be determined by causing the victim to v= iew > HTML which opens img1.example.com, img2.example.com, img3.example.com, et= c., > to servers controlled by the attacker. The attacker can then have > Javascript release one of those mappings, wait, and the attacker will kn= ow > the victim will re-use that port -- because it's the only port available. > Proof of concept code that does this has been circulating. From touch@isi.edu Tue Mar 15 15:24:06 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750863A6A4B for ; Tue, 15 Mar 2011 15:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.642 X-Spam-Level: X-Spam-Status: No, score=-103.642 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, 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 PywMI1QH6ShU for ; Tue, 15 Mar 2011 15:24:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 460CB3A6930 for ; Tue, 15 Mar 2011 15:24:05 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p2FMP68p025841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 15 Mar 2011 15:25:16 -0700 (PDT) Message-ID: <4D7FE742.6040308@isi.edu> Date: Tue, 15 Mar 2011 15:25:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Wing References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> <12a101cbe33b$fc20e160$f462a420$@com> <4D7FB586.7090503@isi.edu> <138501cbe357$73c325a0$5b4970e0$@com> <4D7FDEF4.9060200@isi.edu> <13be01cbe35c$72022270$56066750$@com> In-Reply-To: <13be01cbe35c$72022270$56066750$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p2FMP68p025841 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: behave@ietf.org, mohamed.boucadair@orange-ftgroup.com, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:24:06 -0000 On 3/15/2011 3:00 PM, Dan Wing wrote: >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, March 15, 2011 2:50 PM >> To: Dan Wing >> Cc: mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- >> requirements@tools.ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] CGN REQ: IP-ID >> >> Hi, Dan, >> >> As a preface, I just want to point out that the statements in ipv4-id >> that refer to NATs don't add new requirements; IMO, they are just >> interpretations of *existing* requirements on NATs - granted, that they >> often ignore, and that may or may not have widespread impact (it's very >> hard to measure), but I continue to think they're worth stating. >> >> Some further notes below. >> >> On 3/15/2011 2:25 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Tuesday, March 15, 2011 11:53 AM >>>> To: Dan Wing >>>> Cc: mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- >>>> requirements@tools.ietf.org; behave@ietf.org >>>> Subject: Re: [BEHAVE] CGN REQ: IP-ID >>>> >>>> Hi, Dan, >>>> >>>> On 3/15/2011 11:08 AM, Dan Wing wrote: >>>>>> As for the re-writing of the IP-ID field, a requirement reflecting >>>> what >>>>>> is discussed in http://tools.ietf.org/html/draft-ietf-intarea- >> ipv4- >>>> id- >>>>>> update-02#section-9 should be added to the I-D. >>>>> >>>>> BEHAVE has documented how popular layer 4 protocols are translated >> on >>>>> today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). >>>> Those >>>>> documents provide minimal guidance, in an attempt to improve NAT >>>>> operation. BEHAVE has not published a document on how IP is >>>>> translated. >>>>> >>>>> That section describes how to translate IP, and requires a NAT >>>>> reassemble fragments and re-write the IPID. The requirement is >>>>> not solely on a NAT but, rather, on any sort of address-sharing >>>>> device (to include 4rd, IVI, and others in the "A+P family"). >>>>> >>>>> Unfortunate to say, but I do not foresee NAT vendors implementing >>>>> that requirement. Joe, I assume there is demonstrated harm >>>>> occurring on the Internet where IPIDs collided? >>>> >>>> It's difficult to show such measurements, as we don't have access to >>>> traffic behind NATs. The result of not rewriting the ID >> appropriately >>>> can be increased packet reassembly errors, some of which may be >> caught >>>> by TCP checksums, some may result in interrupted TLS connections, >> etc. >>> >>> But a significant majority of TCP connections send their segments >>> with DF=1 (FreeBSD, Linux, OSX, Windows, and iOS). So I doubt the >>> problem occurs very frequently with TCP. >> >> There's already ample evidence that many devices ignore DF=1 as well, >> though. > > Neither a host nor a NAPT can fix that, though, especially with the > restrictions of Section 6.1 of draft-ietf-intarea-ipv4-id-update > which seem to prohibit the NAPT from diddling with the IPID of > atomic packets. Right. We can't fix it; we're just trying to explain where the error is. Joe From dwing@cisco.com Tue Mar 15 15:26:08 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60323A6BC6 for ; Tue, 15 Mar 2011 15:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.798 X-Spam-Level: X-Spam-Status: No, score=-109.798 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_BACKHAIR_27=1, 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 h0NfhVABY+2o for ; Tue, 15 Mar 2011 15:26:07 -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 7C5CD3A6930 for ; Tue, 15 Mar 2011 15:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3140; q=dns/txt; s=iport; t=1300228053; x=1301437653; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=krEDdsgyUlNJIuTKJbmTdS0LVhgVBhOffjOBrzcqGnk=; b=lkq0RAg3Jyg8RUlaGAE6Xmi32JXUQnRrkjhdmra8NM54mPWt9ALnvk09 RnCy5trxgt2qDDle6UMOt1vINLe9J/DDL+kCKjh7DNNCzCv5pUinyd7GW P3VQLzmK7JlePykB/KwhBGa+D5YP1suirexhoG/tbrK4okz8Pc1y44Iqc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAFaEf02tJV2Y/2dsb2JhbACYT4Fki1p3pFScboViBIUwjSY X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="320681272" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 22:27:32 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FMRWMo027040; Tue, 15 Mar 2011 22:27:32 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <138801cbe358$1651fc10$42f5f430$@com> In-Reply-To: Date: Tue, 15 Mar 2011 15:27:31 -0700 Message-ID: <13df01cbe360$2d2e5d90$878b18b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDAABPhPAAABjRLNAABKecA= Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:26:08 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 15, 2011 3:13 PM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > There is a premise of stopping spam, abuse, etc. I'm assuming other ISP > and > content providers will be contacting the ISP which hosts the attacker > and > reporting the public IP address and source port (as required by a > recent draft). I am not familiar with that draft. But that would still be "the logging problem", which is not the purpose or value of user-hint. If the content provider is going to automatically (or manually) contact the ISP, they can do that via existing means -- such as by telling the ISP the source IP address, source port number, and time of the abusive user's connection to their server. That _is_ the "logging problem". > The ISP would then investigate and take appropriate action. > > Are saying the Content Providers will take sole action and have a long > list of public IP<->private IP in their servers (or routers)? They have long lists of this, today. One (of many) examples are the DNS blackhole lists operated by various organizations. Another example is the Cisco Ironport SenderBase, http://www.senderbase.org And on a server that I help operate, we have a couple thousand IP addresses in our /etc/hosts.denied file -- those are the IP addresses that have attempted dictionary attacks against SSH, IMAPS, and other services. > Can you elaborate > Providers will operationalize using the private IP inside those > connections to filter anything? A To provide service to users while throttling/captcha'ing/denying service to abusers. The alternative is to throttle/captcha/deny service to the entire source IP address -- which harms legitimate users. -d > > On 3/15/11 2:29 PM, "Dan Wing" wrote: > > >> -----Original Message----- > >> From: Reinaldo Penno [mailto:rpenno@juniper.net] > >> Sent: Tuesday, March 15, 2011 12:07 PM > >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- > behave- > >> lsn-requirements@tools.ietf.org > >> Cc: behave@ietf.org > >> Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > >> > >> But there are operational solutions for this problem which do not > need > >> man-in-the-middle rewrite. > >> > >> The abusers can be put in special public pool of address that is > there > >> for such sole purpose. > > > > For that, the ISP would decide which of their subscribers is > abusive?? > > > > -d > > > > > >> BTW, this already done today in many different > >> forms. > >> > >> On 3/15/11 11:46 AM, "Dan Wing" wrote: > >> > >>> The alternative is that everyone sharing the same IPv4 address be > >>> put into the same low-quality of service, such as throttling all > >>> of their activity, challenging them all with captchas, or blocking > >>> them outright. > > From dwing@cisco.com Tue Mar 15 15:32:14 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9586C3A6B44 for ; Tue, 15 Mar 2011 15:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.294 X-Spam-Level: X-Spam-Status: No, score=-110.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 4Xu444PsujHz for ; Tue, 15 Mar 2011 15:32:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5971E3A6A4B for ; Tue, 15 Mar 2011 15:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2599; q=dns/txt; s=iport; t=1300228419; x=1301438019; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=4I9UfEhRsZj2BlwgySRgwSnkhIbhhOtcusMx/PHvSlA=; b=fWAIdOLnF9jWzUd8t+T2CoOHKkqibST8Po/Gp/2YJqY5k1a3KPK7kKTa 6Y7fQTizUktRkzA50l5sPz8OHqI01VS3orOgyjvWhSLF4idJ5DKQMTJM9 5bHe1+hPuXq0dp5e15w1Y7s+VqhDZF9jtwylPH3P/TfdiW9u6ArqmXhXK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAL6Ff02tJV2a/2dsb2JhbACYT4Fki1p3pFaMbJAChWIEhTA X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="225567754" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2011 22:33:38 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2FMXbOP012883; Tue, 15 Mar 2011 22:33:37 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <138701cbe357$ed3e63e0$c7bb2ba0$@com> In-Reply-To: Date: Tue, 15 Mar 2011 15:33:37 -0700 Message-ID: <13e001cbe361$06f7b120$14e71360$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxA Content-language: en-us Cc: 'DENG Xiaohong ESP/PEK' , behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:32:14 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 3:19 PM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > > That are security considerations that need to be understood in relation > to > port block. But many of those can be mitigated. Having said that, I > would > guess there are at least 3 CGN vendors that implement such a feature. > Therefore, CGN vendors already do that today. > > As for your example, If the attacker has this access to your machine > the victim should be worried about his credit card, not ports. (;-) Yes, there are always more severe risks. Could get run over by a bus, too. But building a system which has predictable ports is risky for two reasons: * security, which everyone likes to discount as "not important". * the port limit will be wrong o It will be either too high (too many ports, costing money in the future ("why are we spending $30 for each IPv4 address, giving everyone 1000 ports, but the average user only consuming 10 ports? We are throwing money away"), o It will be too low (too few ports, harming an application, causing support calls). This will be expensive to correct, with some fixed-port schemes, because it requires re-IP'ing the access network for some users or for all users. Some other fixed-port schemes could be changed with a single CLI setting, and don't have this risk. -d > > On 3/15/11 2:28 PM, "Dan Wing" wrote: > > >> A "Port Set" does not mean necessarily "contiguous port range"! > > > > It is not relevant if they are contiguous or not. This is a false > sense of > > security. > > > > If they are fixed, the ports can be determined by causing the victim > to view > > HTML which opens img1.example.com, img2.example.com, > img3.example.com, etc., > > to servers controlled by the attacker. The attacker can then have > > Javascript release one of those mappings, wait, and the attacker > will know > > the victim will re-use that port -- because it's the only port > available. > > Proof of concept code that does this has been circulating. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tuexen@fh-muenster.de Mon Mar 14 12:08:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A273A6A2D for ; Mon, 14 Mar 2011 12:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=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 iDf8eSUaBXNw for ; Mon, 14 Mar 2011 12:08:15 -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 23A753A6979 for ; Mon, 14 Mar 2011 12:08:14 -0700 (PDT) Received: from [192.168.1.113] (p5481DBED.dip.t-dialin.net [84.129.219.237]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0D7391C0B4619; Mon, 14 Mar 2011 20:09:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Mon, 14 Mar 2011 20:09:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: melnikovkolya@gmail.com X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 15 Mar 2011 15:47:06 -0700 Cc: draft-ietf-behave-sctpnat@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-sctpnat-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:08:16 -0000 Hi Nik, thanks for comments. Best regards Michael On Mar 14, 2011, at 1:22 PM, Nikolay Melnikov wrote: > Hello everyone, >=20 > I bumped into several statements and (what I consider to be) typos at = my initial read of the document, so I decided not to postpone and report = them.=20 >=20 >=20 >=20 >=20 >=20 >=20 > 5. Limitations of classical NAPT for SCTP >=20 > This would add considerable (?overhead?) to the NAT computational = burden, however hardware support may mitigate this in some = implementations. It adds to the computational burden... We wanted to say that additional = work is needed. >=20 >=20 >=20 >=20 >=20 > 6. The SCTP specific variant of NAT >=20 > It is also possible that a connection to External-Address and = External-Port exists without an > Internal-VTag Fixed. >=20 >=20 >=20 >=20 >=20 >=20 > 7. Nat to SCTP > =20 > This document at various places discusses the sending of = specialized > SCTP chunks (e.g. an ABORT with set). Fixed. >=20 > " > 9. Simplification for small NATs > Small NAT boxes, i.e. NAT boxes which only have to support a small > number of concurrent SCTP associations, MAY not take the external > address into account when processing packets. Therefore the > External-Address could also be removed from the NAT table. >=20 >=20 >=20 >=20 > This simplification may make implementing a NAT box easier, = however, > the collision probability is higher than using a mapping which = takes > the external address into account. > " > Is the risk of higher collision probability worth "implementation = simplification"? Does it make sense to have this section at all?=20 This section has to change anyway... >=20 >=20 >=20 > Shouldn't the multi-homed "server-side" of figures in 10.3 look as = follows (to comply with figure in 10.2): >=20 >=20 > +-------+ +--------+ > /-| NAT 1 |-\ /--\/--\ /-|Router 1|-\ > +------+ / +-------+ \ / \ / +--------+ \ = +--------+ =20 > | Host |=3D=3D=3D =3D=3D=3D| Internet |=3D=3D = =3D=3D| Host B | > | A | \ +-------+ / \ / \ +--------+ / = +--------+ > +------+ \-| NAT 2 |-/ \--/\--/ \-|Router 2|-/ =20 > +-------+ +--------+ >=20 I agree, that the figures in 10.2 and 10.3 should show Host B in a = similar way. I'll fix it for the next rev. >=20 > 10.5=20 > Host A send INIT-ACK, which can pass through NAT B: >=20 >=20 > Question: =46rom the example in 10.5, the INIT packet from host A = creates an entry in NAT A, but is discarded at NAT B. What follows, is = an INIT packet from host B, which creates an appropriate entry in NAT B. = It is mentioned that the rendezvous points are involved in this case, = could you please explain to me how? Does host B send an INIT packet a = hint from that rendezvous point? Host A must know external address and port number of Host B and vice = versa. To get this information, both node connect to a rendezvous server and = exchange this information. This is described in more detail in Network Address Translation for the Stream Control Transmission Protocol T=FCxen, M.; R=FCngeler, I.; Rathgeb, E. IEEE Network, 22(5):26-32, 2008. Best regards Michael >=20 >=20 > nik > --=20 > Nikolay Melnikov > School of Engineering and Science > Jacobs University Bremen >=20 > From rpenno@juniper.net Tue Mar 15 15:52:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813673A6BD8 for ; Tue, 15 Mar 2011 15:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 BR2VI4Rayr8z for ; Tue, 15 Mar 2011 15:52:27 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 6CC4F3A6A4B for ; Tue, 15 Mar 2011 15:52:23 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTX/t+g9wdJsmgf/mDagcdxZBysAiQacM@postini.com; Tue, 15 Mar 2011 15:53:53 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 15:50:54 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 15 Mar 2011 18:52:00 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 18:51:57 -0400 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxAAADVbCQ= Message-ID: In-Reply-To: <13e001cbe361$06f7b120$14e71360$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'DENG Xiaohong ESP/PEK' , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:52:28 -0000 On 3/15/11 3:33 PM, "Dan Wing" wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Reinaldo Penno >> Sent: Tuesday, March 15, 2011 3:19 PM >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- >> lsn-requirements@tools.ietf.org >> Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment >>=20 >> That are security considerations that need to be understood in relation >> to >> port block. But many of those can be mitigated. Having said that, I >> would >> guess there are at least 3 CGN vendors that implement such a feature. >> Therefore, CGN vendors already do that today. >>=20 >> As for your example, If the attacker has this access to your machine >> the victim should be worried about his credit card, not ports. (;-) >=20 > Yes, there are always more severe risks. Could get run over by a bus, to= o. >=20 > But building a system which has predictable ports is risky for two reason= s: >=20 > * security, which everyone likes to discount as "not important". > * the port limit will be wrong There are many ways to overcome the issues you point below. I think you might have a specific implementation in mind. > o It will be either too high (too many ports, costing money > in the future ("why are we spending $30 for each IPv4 > address, giving everyone 1000 ports, but the average user > only consuming 10 ports? We are throwing money away"), > o It will be too low (too few ports, harming an application, > causing support calls). This will be expensive to correct, > with some fixed-port schemes, because it requires re-IP'ing > the access network for some users or for all users. Some > other fixed-port schemes could be changed with a single > CLI setting, and don't have this risk. >=20 > -d >=20 >=20 >>=20 >> On 3/15/11 2:28 PM, "Dan Wing" wrote: >>=20 >>>> A "Port Set" does not mean necessarily "contiguous port range"! >>>=20 >>> It is not relevant if they are contiguous or not. This is a false >> sense of >>> security. >>>=20 >>> If they are fixed, the ports can be determined by causing the victim >> to view >>> HTML which opens img1.example.com, img2.example.com, >> img3.example.com, etc., >>> to servers controlled by the attacker. The attacker can then have >>> Javascript release one of those mappings, wait, and the attacker >> will know >>> the victim will re-use that port -- because it's the only port >> available. >>> Proof of concept code that does this has been circulating. >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 From Francis.Dupont@fdupont.fr Tue Mar 15 15:56:53 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5A53A6EF8; Tue, 15 Mar 2011 15:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-dOUzyuTE0Y; Tue, 15 Mar 2011 15:56:53 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id AC5E63A6A4B; Tue, 15 Mar 2011 15:56:52 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2FMwG2b020546; Tue, 15 Mar 2011 23:58:16 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103152258.p2FMwG2b020546@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 15 Mar 2011 08:19:27 MST. <10f301cbe324$60300a40$20901ec0$@com> Date: Tue, 15 Mar 2011 23:58:16 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org, pcp@ietf.org, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:56:54 -0000 In your previous mail you wrote: There really isn't a /need/ for two address pools. Rather, there is a need to not re-use an address within "some time period". I don't know the time period. => I know: it is the longest term of any mappings. So it is infinite when there are some static mappings... This just shows the idea of no re-use within a time period works only with implicit dynamic mappings and something else (you have already guessed which one) should be used for explicit dynamic and static mappings. BTW PEER doesn't change this: it cannot extend the lifetime over the maximum. It needs to be discussed. For EXAMPLE, let's say there is a CGN that crashes and takes 20 minutes to boot -- could it reasonably re-use the same IP address pool? 2 minutes to boot? 4 minutes? What is the amount of time needed. => surely at least 2*MSL but IMHO simply the maximum lifetime of an implicit dynamic mapping (oops, RFC 5382 REQ-5 says it must be at least 2h04mn... forget, I am joking :-). Today when ISPs force subscribers to change IP addresses, do they wait a day or an hour or a minute before re-using the IP address for another subscriber? => I believe they don't care but technically it is wrong to wait less than 2*MSL. > "Port forwarding entries SHOULD be stored in permanent storage > whatever the deployed redundancy mode." If a different address pool is going to be one of the requirements, though, such permanent storage serves no purpose. => you already proposed the different address pool as a counter measure against the port forwarding entry theft threat. I agree but I don't like the operational consequence: they can't be stolen but they are no longer usable. Essentially, I think we need to up-level the requirement to what we want to see on the wire, rather than how it should be implemented in the CGN. => I can't see how you could solve the issue this way, I should have missed something. Regards Francis.Dupont@fdupont.fr From rpenno@juniper.net Tue Mar 15 15:57:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A23B3A6F00 for ; Tue, 15 Mar 2011 15:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, J_BACKHAIR_27=1, 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 3OtbFGfZ6Qjb for ; Tue, 15 Mar 2011 15:57:15 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 975543A6A4B for ; Tue, 15 Mar 2011 15:57:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTX/vGvDANemzJWEvXOCJGZz8rI2d8W8R@postini.com; Tue, 15 Mar 2011 15:58:40 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 15 Mar 2011 15:53:54 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 15 Mar 2011 18:55:00 -0400 From: Reinaldo Penno To: Dan Wing , "mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Tue, 15 Mar 2011 18:54:59 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDAABPhPAAABjRLNAABKecAAASl12w== Message-ID: In-Reply-To: <13df01cbe360$2d2e5d90$878b18b0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:57:16 -0000 On 3/15/11 3:27 PM, "Dan Wing" wrote: >> Are saying the Content Providers will take sole action and have a long >> list of public IP<->private IP in their servers (or routers)? >=20 > They have long lists of this, today. One (of many) examples are > the DNS blackhole lists operated by various organizations. So is one of the requirements that such blacklisted zone transfers have public IP<-> private IP mappings? > Another > example is the Cisco Ironport SenderBase, http://www.senderbase.org >=20 > And on a server that I help operate, we have a couple thousand > IP addresses in our /etc/hosts.denied file -- those are the > IP addresses that have attempted dictionary attacks against > SSH, IMAPS, and other services. Will the TCP stack be checking for the embedded private IP? From dwing@cisco.com Tue Mar 15 15:57:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3253A6A4B for ; Tue, 15 Mar 2011 15:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.3 X-Spam-Level: X-Spam-Status: No, score=-110.3 tagged_above=-999 required=5 tests=[AWL=0.299, 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 TIUoG3AJdPjn for ; Tue, 15 Mar 2011 15:57:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C97BF3A6EFA for ; Tue, 15 Mar 2011 15:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3776; q=dns/txt; s=iport; t=1300229958; x=1301439558; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=5eSewQApiKm8nKqK8q7Mnt8ge8NS+8g4+NIwfNHRIo4=; b=V1yQ5kpkrr2gdU4m/75zIYxV+0blaFF06RQnv2FmzIlgS3eWREJWmCel p7LMwKZJpDAmNujCwWqm+1uTpMWA+/SEbiUssp4M1wKELoyswVtD5ULy3 b8TiyC8kaQVws6vypvuarBrXq5BeKD6aYHGP0nHfUaJnDU7e0GfYMCfO9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBANaLf02tJV2a/2dsb2JhbACYT4Fki1p3pE+MbJAChWIEhTA X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="347437873" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 22:59:17 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2FMxH5M022664; Tue, 15 Mar 2011 22:59:17 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <13e001cbe361$06f7b120$14e71360$@com> In-Reply-To: Date: Tue, 15 Mar 2011 15:59:16 -0700 Message-ID: <140501cbe364$9ca93240$d5fb96c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxAAADVbCQAADD60A== Content-language: en-us Cc: 'DENG Xiaohong ESP/PEK' , behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 22:57:54 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 3:52 PM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > > > > > On 3/15/11 3:33 PM, "Dan Wing" wrote: > > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Reinaldo Penno > >> Sent: Tuesday, March 15, 2011 3:19 PM > >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- > behave- > >> lsn-requirements@tools.ietf.org > >> Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > >> > >> That are security considerations that need to be understood in > relation > >> to > >> port block. But many of those can be mitigated. Having said that, I > >> would > >> guess there are at least 3 CGN vendors that implement such a > feature. > >> Therefore, CGN vendors already do that today. > >> > >> As for your example, If the attacker has this access to your machine > >> the victim should be worried about his credit card, not ports. (;-) > > > > Yes, there are always more severe risks. Could get run over by a > bus, too. > > > > But building a system which has predictable ports is risky for two > reasons: > > > > * security, which everyone likes to discount as "not important". > > * the port limit will be wrong > > There are many ways to overcome the issues you point below. I think you > might have a specific implementation in mind. I am thinking of A+P-like schemes. No implementation magic can change the number of ports allocated by those schemes, because those schemes generally stick port information into the IPv6 address or into a tunnel header. -d > > o It will be either too high (too many ports, costing money > > in the future ("why are we spending $30 for each IPv4 > > address, giving everyone 1000 ports, but the average user > > only consuming 10 ports? We are throwing money away"), > > o It will be too low (too few ports, harming an application, > > causing support calls). This will be expensive to correct, > > with some fixed-port schemes, because it requires re-IP'ing > > the access network for some users or for all users. Some > > other fixed-port schemes could be changed with a single > > CLI setting, and don't have this risk. > > > > -d > > > > > >> > >> On 3/15/11 2:28 PM, "Dan Wing" wrote: > >> > >>>> A "Port Set" does not mean necessarily "contiguous port range"! > >>> > >>> It is not relevant if they are contiguous or not. This is a false > >> sense of > >>> security. > >>> > >>> If they are fixed, the ports can be determined by causing the > victim > >> to view > >>> HTML which opens img1.example.com, img2.example.com, > >> img3.example.com, etc., > >>> to servers controlled by the attacker. The attacker can then have > >>> Javascript release one of those mappings, wait, and the attacker > >> will know > >>> the victim will re-use that port -- because it's the only port > >> available. > >>> Proof of concept code that does this has been circulating. > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue Mar 15 16:01:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5732A3A6F0E for ; Tue, 15 Mar 2011 16:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.806 X-Spam-Level: X-Spam-Status: No, score=-109.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_BACKHAIR_27=1, 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 QpWsiPeoZGDy for ; Tue, 15 Mar 2011 16:01:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5710C3A6F0C for ; Tue, 15 Mar 2011 16:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1848; q=dns/txt; s=iport; t=1300230194; x=1301439794; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=BeSFMKTEwo6IOK284UYVA9makAb7aTqPpGyTFmkyDLE=; b=Qd29/A+kZcN4Fr5vOvK1kq8TxYm8WCbQq+yqdtvzKZReFzHuN9ys+67Z BRGOPafrI/XPQlm+K9YjrzW1ducH0bDfkKZun6IXmVtIJJ+ohfC2dDPy+ 62lK+0fgLoWWt/nJKQlNcV2TVRrwyx83NV7Hm1UVIeT70cQjQwuhmxiyu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAD6Nf02tJV2d/2dsb2JhbACYT4Fki1p3pE2caYViBIUwjSY X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="225963801" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2011 23:03:13 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FN3CMe014737; Tue, 15 Mar 2011 23:03:12 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , , References: <13df01cbe360$2d2e5d90$878b18b0$@com> In-Reply-To: Date: Tue, 15 Mar 2011 16:03:11 -0700 Message-ID: <140601cbe365$28e995b0$7abcc110$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDAABPhPAAABjRLNAABKecAAASl12wAAKN9Q Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 23:01:49 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 15, 2011 3:55 PM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT > > > On 3/15/11 3:27 PM, "Dan Wing" wrote: > > >> Are saying the Content Providers will take sole action and have a > long > >> list of public IP<->private IP in their servers (or routers)? > > > > They have long lists of this, today. One (of many) examples are > > the DNS blackhole lists operated by various organizations. > > So is one of the requirements that such blacklisted zone transfers have > public IP<-> private IP mappings? Not at all. It needs 'public IP + something_that_differentiates_user_from_abuser'. The public IP is the source IP address, which we are all familiar with using. The differentiator is the key part when doing address sharing. That differentiator does _not_ need to be the user's private IP address. It could be their social security number (kidding), a portion of their internal IP address (e.g., 24 bits of their IPv4 address), their VLAN number, the first 8/12/16 bits of a hash of their internal IP address, or a dozen other ideas that are easy to craft up on a napkin. > > Another > > example is the Cisco Ironport SenderBase, http://www.senderbase.org > > > > And on a server that I help operate, we have a couple thousand > > IP addresses in our /etc/hosts.denied file -- those are the > > IP addresses that have attempted dictionary attacks against > > SSH, IMAPS, and other services. > > Will the TCP stack be checking for the embedded private IP? If they want to use the additional information, yes. -d From Francis.Dupont@fdupont.fr Tue Mar 15 16:29:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C125F3A6F18; Tue, 15 Mar 2011 16:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcJleluXI+Eq; Tue, 15 Mar 2011 16:29:00 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 94FFC3A6DC6; Tue, 15 Mar 2011 16:28:59 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2FNUOq8022991; Wed, 16 Mar 2011 00:30:24 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103152330.p2FNUOq8022991@givry.fdupont.fr> From: Francis Dupont To: Benson Schliesser In-reply-to: Your message of Tue, 15 Mar 2011 15:00:38 EST. Date: Wed, 16 Mar 2011 00:30:24 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org, pcp@ietf.org, mohamed.boucadair@orange-ftgroup.com, Dan Wing Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:29:01 -0000 I disagree: for many reasons, including security expectations and possible clock skew in logging, the hold-down of explicit dynamic mappings (which is already a SHOULD in PCP base, cf 8.6) IMHO must be upgraded to a MUST for CGNs. You can argue for a MUST for a short hold-down and a SHOULD for the existing 120s one but I think it is better to get only one. Regards Francis.Dupont@fdupont.fr PS: I already discussed this point in the PCP mailing list. From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:11:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D063A67F0 for ; Tue, 15 Mar 2011 23:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 3PxCCilA3X+6 for ; Tue, 15 Mar 2011 23:11:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id F041A3A67DB for ; Tue, 15 Mar 2011 23:11:20 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id D53FBC0392; Wed, 16 Mar 2011 07:12:37 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 8C01D38403A; Wed, 16 Mar 2011 07:12:37 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 16 Mar 2011 07:12:37 +0100 From: To: Benson Schliesser , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 07:12:36 +0100 Thread-Topic: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications Thread-Index: AcvjHS/xay+A6A2mRli6YQarXKnKrQALAPGrABXrqMA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3ADC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.52416 Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:11:55 -0000 Dear Benson, I vote for SHOULD instead of MAY.=20 If we want to avoid applications brokenness, we need to have this function = supported. Cheers, Med =20 -----Message d'origine----- De : Benson Schliesser [mailto:bschlies@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 20:43 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : 'behave' <(behave@ietf.org)> Objet : Re: [BEHAVE] CGN REQ: Control NAT mappings for inbound communicatio= ns On 3/15/11 8:28 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Some applications will fail if port forwarding is not supported. Having a > requirement to mandate the support of port forwarding feature would be > valuable. > =20 > PCP can be listed as a RECOMMENDED solution. I'm not convinced that a port-forwarding feature ought to be a CGN requirement. I'm not opposed to it as a requirement, and I do agree that i= t is a desired feature in many cases. But it is not always a desired feature for all deployments. Thus, at this time I believe the requirements draft ought to capture it as a MAY. That said, I do agree that PCP should be recommended as the control protoco= l for dynamically configured port-forwarding in the event that it is implemented. Cheers, -Benson From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:15:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE12B3A67D2 for ; Tue, 15 Mar 2011 23:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 BwqPuoy3ipl8 for ; Tue, 15 Mar 2011 23:15:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 77EBC3A67C2 for ; Tue, 15 Mar 2011 23:15:18 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9F5FD3B4339; Wed, 16 Mar 2011 07:16:43 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8643335C018; Wed, 16 Mar 2011 07:16:43 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 16 Mar 2011 07:16:43 +0100 From: To: Benson Schliesser , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 07:16:42 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAJOJc3ABZsQNA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.41523 Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:15:21 -0000 Dear Benson, The port set does not means contiguous port range. Random port set can be h= andled by the CGN. This should be explicit in the requirements IMO. In deployments where a small address sharing ration is needed (e.g., 1:2, 1= :3), port randomization is still possible within the large port range. The I-D already discusses the trade-offs: Security: Mechanisms (1) and (2) provide very good security in that ports numbers are not easily guessed. Easily guessed port numbers put subscribers at risk of the attacks described in [RFC6056]. Mechanism (3) provides poor security to subscribers, especially if the "bin" size is small. Cheers, Med=20 -----Message d'origine----- De : Benson Schliesser [mailto:bschlies@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 20:31 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : 'behave' <(behave@ietf.org)> Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment On 3/15/11 9:07 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Section 5=20 > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#section-= 5 > discusses various modes for the port assignment but there is no explicit > requirement.=20 > =20 > I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) support= the > ability to assign port sets. The selection of the dynamic mode vs. port s= et is > deployment-specific. I don't support this as a MUST or SHOULD. A port-set feature isn't a requirement for successful deployment of a CGN. In fact, a port-set featur= e might be seen to have negative implications for security, scale, etc. It i= s an implementation choice, and the requirements document ought to capture it as a MAY. Cheers, -Benson From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:19:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E1F3A67D8 for ; Tue, 15 Mar 2011 23:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 36eHrvIDBygC for ; Tue, 15 Mar 2011 23:19:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 60DC33A6781 for ; Tue, 15 Mar 2011 23:19:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id AD3BD3241E0; Wed, 16 Mar 2011 07:21:11 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8C80D238062; Wed, 16 Mar 2011 07:21:11 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 16 Mar 2011 07:21:11 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 07:21:09 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAEpVuAA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC7@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr>, <12f501cbe341$fe3310d0$fa993270$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr> <138701cbe357$ed3e63e0$c7bb2ba0$@com> In-Reply-To: <138701cbe357$ed3e63e0$c7bb2ba0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.55415 Cc: DENG Xiaohong ESP/PEK , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:19:47 -0000 Hi Dan, Please see inline. Cheers, Med =20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 22:28 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org; DENG Xiaohong ESP/PEK Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 12:02 PM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org; DENG Xiaohong ESP/PEK > Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment >=20 > Re- >=20 > A "Port Set" does not mean necessarily "contiguous port range"! It is not relevant if they are contiguous or not. This is a false sense of security. If they are fixed, the ports can be determined by causing the victim to vie= w HTML which opens img1.example.com, img2.example.com, img3.example.com, etc.= , to servers controlled by the attacker. The attacker can then have Javascript release one of those mappings, wait, and the attacker will know the victim will re-use that port -- because it's the only port available. Proof of concept code that does this has been circulating. Med: Your point is valid. This is why there are other mode for the assignme= nt of the port sets: when a packet arrives and now binding is available, a = small random port set is generated. Once all the ports are used, a new rand= om port set is generated, etc. This processes is repeated until reaching th= e per-subscriber quota. A user is never assigned the same port sets. The si= ze of the port set per binding is configurable. From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:26:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3E53A67DA for ; Tue, 15 Mar 2011 23:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 3NUKHEMfli8s for ; Tue, 15 Mar 2011 23:26:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 012E43A67DB for ; Tue, 15 Mar 2011 23:26:28 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C4EC1324521; Wed, 16 Mar 2011 07:27:53 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9AE8A27C037; Wed, 16 Mar 2011 07:27:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 16 Mar 2011 07:27:53 +0100 From: To: Dan Wing , 'Reinaldo Penno' , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 07:27:52 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxAAADVbCQAADD60AAPk29w Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC8@PUEXCB1B.nanterre.francetelecom.fr> References: <13e001cbe361$06f7b120$14e71360$@com> <140501cbe364$9ca93240$d5fb96c0$@com> In-Reply-To: <140501cbe364$9ca93240$d5fb96c0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.12.28.90317 Cc: DENG Xiaohong ESP/PEK , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:26:29 -0000 Re-, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 23:59 =C0 : 'Reinaldo Penno'; BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-l= sn-requirements@tools.ietf.org Cc : DENG Xiaohong ESP/PEK; behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 15, 2011 3:52 PM > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave- > lsn-requirements@tools.ietf.org > Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 >=20 >=20 >=20 > On 3/15/11 3:33 PM, "Dan Wing" wrote: >=20 > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Reinaldo Penno > >> Sent: Tuesday, March 15, 2011 3:19 PM > >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- > behave- > >> lsn-requirements@tools.ietf.org > >> Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > >> > >> That are security considerations that need to be understood in > relation > >> to > >> port block. But many of those can be mitigated. Having said that, I > >> would > >> guess there are at least 3 CGN vendors that implement such a > feature. > >> Therefore, CGN vendors already do that today. > >> > >> As for your example, If the attacker has this access to your machine > >> the victim should be worried about his credit card, not ports. (;-) > > > > Yes, there are always more severe risks. Could get run over by a > bus, too. > > > > But building a system which has predictable ports is risky for two > reasons: > > > > * security, which everyone likes to discount as "not important". > > * the port limit will be wrong >=20 > There are many ways to overcome the issues you point below. I think you > might have a specific implementation in mind. I am thinking of A+P-like schemes.=20 Med: Which ones? Dynamic modes have been proposed in A+P; see http://tools.= ietf.org/html/draft-rqb-dynamic-port-ranges-02. Port randomization requirem= ent can be fairly honored. No implementation magic can change the number of ports allocated by those schemes, because those schemes generally stick port information into the IPv6 address or into a tunnel header. Med: This is true for the stateless A+P mode but not the binding mode (see:= http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 for more detai= ls). -d > > o It will be either too high (too many ports, costing money > > in the future ("why are we spending $30 for each IPv4 > > address, giving everyone 1000 ports, but the average user > > only consuming 10 ports? We are throwing money away"), > > o It will be too low (too few ports, harming an application, > > causing support calls). This will be expensive to correct, > > with some fixed-port schemes, because it requires re-IP'ing > > the access network for some users or for all users. Some > > other fixed-port schemes could be changed with a single > > CLI setting, and don't have this risk. > > > > -d > > > > > >> > >> On 3/15/11 2:28 PM, "Dan Wing" wrote: > >> > >>>> A "Port Set" does not mean necessarily "contiguous port range"! > >>> > >>> It is not relevant if they are contiguous or not. This is a false > >> sense of > >>> security. > >>> > >>> If they are fixed, the ports can be determined by causing the > victim > >> to view > >>> HTML which opens img1.example.com, img2.example.com, > >> img3.example.com, etc., > >>> to servers controlled by the attacker. The attacker can then have > >>> Javascript release one of those mappings, wait, and the attacker > >> will know > >>> the victim will re-use that port -- because it's the only port > >> available. > >>> Proof of concept code that does this has been circulating. > >> > >> _______________________________________________ > >> 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 mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:27:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF703A67E4 for ; Tue, 15 Mar 2011 23:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 VWavE0Rm9uUr for ; Tue, 15 Mar 2011 23:27:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id BC3A03A67ED for ; Tue, 15 Mar 2011 23:27:19 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 86C9B18C4BA; Wed, 16 Mar 2011 07:28:45 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6E0E827C037; Wed, 16 Mar 2011 07:28:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 16 Mar 2011 07:28:45 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 07:28:44 +0100 Thread-Topic: [BEHAVE] CGN REQ: IP-ID Thread-Index: AcvjG0cPCkKBJk7TSraF0yZ4hDVV/gAC5QxQAB8edaA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3AB7@PUEXCB1B.nanterre.francetelecom.fr> <12a101cbe33b$fc20e160$f462a420$@com> In-Reply-To: <12a101cbe33b$fc20e160$f462a420$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.55415 Cc: "behave@ietf.org" , 'Joe Touch' Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:27:21 -0000 Hi Dan, I don't think this an argument to not include it as a requirement in the CG= N I-D. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 19:08 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org; 'Joe Touch' Objet : RE: [BEHAVE] CGN REQ: IP-ID > As for the re-writing of the IP-ID field, a requirement reflecting what > is discussed in http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id- > update-02#section-9 should be added to the I-D. BEHAVE has documented how popular layer 4 protocols are translated on=20 today's NATs -- TCP (RFC5382), UDP (RFC4787), and ICMP (RFC5508). Those documents provide minimal guidance, in an attempt to improve NAT=20 operation. BEHAVE has not published a document on how IP is=20 translated. That section describes how to translate IP, and requires a NAT reassemble fragments and re-write the IPID. The requirement is not solely on a NAT but, rather, on any sort of address-sharing=20 device (to include 4rd, IVI, and others in the "A+P family"). =20 Unfortunate to say, but I do not foresee NAT vendors implementing=20 that requirement. Joe, I assume there is demonstrated harm=20 occurring on the Internet where IPIDs collided? -d From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:34:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F4F3A67F9 for ; Tue, 15 Mar 2011 23:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, HELO_EQ_FR=0.35, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 yKZwcYxwnVLy for ; Tue, 15 Mar 2011 23:34:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 52BE53A67F5 for ; Tue, 15 Mar 2011 23:34:27 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id A0D952AC523; Wed, 16 Mar 2011 07:35:52 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 88BAA180054; Wed, 16 Mar 2011 07:35:52 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 16 Mar 2011 07:35:52 +0100 From: To: Benson Schliesser , Simon Perreault Date: Wed, 16 Mar 2011 07:35:51 +0100 Thread-Topic: [BEHAVE] CGN REQ: IP-ID Thread-Index: AcvjRW/pA20Sc0cfv02H1viscdKDVQAXidDA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CCB@PUEXCB1B.nanterre.francetelecom.fr> References: <4D7F75F1.5030601@viagenie.ca> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.52416 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: IP-ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:34:28 -0000 Re-, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Benson Schliesser [mailto:bschlies@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 20:16 =C0 : Simon Perreault; BOUCADAIR Mohamed OLNC/NAD/TIP Cc : 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn-requirements@tools= .ietf.org Objet : Re: [BEHAVE] CGN REQ: IP-ID On 3/15/11 8:21 AM, "Simon Perreault" wrote: > On 2011-03-15 10:14, mohamed.boucadair@orange-ftgroup.com wrote: >> As for the re-writing of the IP-ID field, a requirement reflecting what >> is discussed in >> http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-02#section-= 9 >> should >> be added to the I-D. >=20 > Unless the WG disagrees, I'll add a new requirement referring to that dra= ft. Capturing this as a "SHOULD" is a good idea. However, it needs to be clear that the goal is to avoid ID overlap for a given set of flows - the goal is not necessarily to translate the IP ID field.=20 Med: We might be then vulnerable to what is discussed in http://www.cs.colu= mbia.edu/~smb/papers/fnat.pdf; in particular extrapolating to analyse so th= at it can be used to determine the address sharing ratio used by an SP? (I = have the DS-Lite case in mind). The mechanism for avoiding IP ID overlap is is an implementation issue. Cheers, -Benson From mohamed.boucadair@orange-ftgroup.com Tue Mar 15 23:49:31 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6523A67F9 for ; Tue, 15 Mar 2011 23:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 PmHww94XvVe9 for ; Tue, 15 Mar 2011 23:49:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 047833A67F6 for ; Tue, 15 Mar 2011 23:49:30 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9FB86264292; Wed, 16 Mar 2011 07:50:55 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 82BF1238055; Wed, 16 Mar 2011 07:50:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 16 Mar 2011 07:50:55 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , "draft-sivakumar-behave-nat-logging@tools.ietf.org" Date: Wed, 16 Mar 2011 07:50:54 +0100 Thread-Topic: [BEHAVE] CGN REQ: NAT MIB/YANG Thread-Index: AcvjIcbO4NKW9aBHQ+ybE/15DgVsuwAGBrdwABqpgjA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3CD5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> <127301cbe33a$251a9ae0$6f4fd0a0$@com> In-Reply-To: <127301cbe33a$251a9ae0$6f4fd0a0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.55415 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: NAT MIB/YANG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 06:49:31 -0000 Re-, Please see inline. Cheers, Med -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 18:55 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: NAT MIB > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 8:01 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: NAT MIB >=20 > Re-, >=20 > A requirement to mention that appropriate MIB modules are to be > supported by the CGN is needed. >=20 > At least RFC 4008 is needed.=20 FWIW, we have looked at RFC4008 for a CGN. It seems inadequate for a CGN -= - it lacks ability to alarm if a user is reaching or has exceeded things like their port quota. Also, walking that MIB would take a considerable amount of time on a CGN, due to the table design. Med: Yes, I'm aware if this but there is no better reference to quote (this= is why I said "at least"). For sure, the modules need be adapted to CGN co= ntext to cover a set of operational requirements. There are various proprie= tary CGN MIB modules in the nature but there is no standard one. BTW, YANG = CGN modules may be needed to for those using NETCONF.=20 BTW, a close topic is to log/notify important events. http://tools.ietf.org= /html/draft-sivakumar-behave-nat-logging-00 tried to captures a set of usef= ul information to log. The events are not complete and the structure should= be updated to cover the DS-Lite and L2-NAT. > Tunnel MIB (RFC 4087) is to be supported for DS-Lite CGN. Did SOFTWIRE require that MIB for Dual-Stack Lite? Med: No "management" or manageability considerations are discussed in SOFTW= IRE.= From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 00:46:15 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079973A6847 for ; Wed, 16 Mar 2011 00:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 XJxkHPXGw0lV for ; Wed, 16 Mar 2011 00:46:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 06B333A6830 for ; Wed, 16 Mar 2011 00:46:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C7CA22643E7; Wed, 16 Mar 2011 08:47:38 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AA7F035C048; Wed, 16 Mar 2011 08:47:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 16 Mar 2011 08:47:38 +0100 From: To: Reinaldo Penno , Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 08:47:37 +0100 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjF8BtgZj6qrHzQbeIu8Wx/+jJdAADNlgwAAMN6MAAAMuBEAABD6sTAADyfDAAAJ7NPQAAlwqwAADPfDAAGlzh4A== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3D0B@PUEXCB1B.nanterre.francetelecom.fr> References: <12e801cbe341$4bb98560$e32c9020$@com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.71222 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 07:46:15 -0000 Hi Reinaldo, Yes this may work but the operator needs to identify the abuser before...wh= ich is not easy. The issues are discussed in detail in http://tools.ietf.org/html/draft-ietf= -intarea-shared-addressing-issues-05. In Section 13.1 you can read for inst= ance: In addition, there are web tie-ins into different blacklists that web administrators subscribe to redirect users with infected machines (e.g., detect the presence of a worm) to a URL that says "Hey, your machine is infected!". With address sharing, someone else's worm can interfere with the ability to access the service for other subscribers sharing the same IP address. Cheers, Med -----Message d'origine----- De : Reinaldo Penno [mailto:rpenno@juniper.net]=20 Envoy=E9 : mardi 15 mars 2011 20:07 =C0 : Dan Wing; BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requi= rements@tools.ietf.org Cc : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT But there are operational solutions for this problem which do not need man-in-the-middle rewrite. The abusers can be put in special public pool of address that is there for such sole purpose. BTW, this already done today in many different forms. On 3/15/11 11:46 AM, "Dan Wing" wrote: > The alternative is that everyone sharing the same IPv4 address be > put into the same low-quality of service, such as throttling all > of their activity, challenging them all with captchas, or blocking > them outright. From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 00:56:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190003A6855 for ; Wed, 16 Mar 2011 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 Ri06wFvpiBV4 for ; Wed, 16 Mar 2011 00:56:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id D818C3A6844 for ; Wed, 16 Mar 2011 00:56:47 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 2028A1B82FC; Wed, 16 Mar 2011 08:58:13 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id E464B158060; Wed, 16 Mar 2011 08:58:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 16 Mar 2011 08:58:12 +0100 From: To: Reinaldo Penno , Simon Perreault Date: Wed, 16 Mar 2011 08:58:10 +0100 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWgAA6etwAAI7pF8AHaLVkA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3D19@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3C30@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.73319 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 07:56:49 -0000 Re-, The problem is that due to address sharing, users may experience service de= gradation and troubles to access to some services because: * Content Providers may rely on the source IP address as simple implicit au= thentication * Content providers rely on the source IP address to blacklist misbehaving = users * infected users are redirected to dedicated URL based on there IP address * See http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issue= s-05 for an exhaustive list of issues. To avoid all users sharing the same IP address be impacted, an ID in additi= on to the source IP address is needed to uniquely distinguish a user among = those sharing the same IP address. In nat-reveal-analysis I-D, we wrote: "The server must have extra information than the source IP address to differentiate the sending host. We call USER_HINT this information. o What is the USER_HINT? It must be unique to each user under the same address. It does not need to be globally unique. Of course, the combination of the (public) IPv4 source address and the identifier ends up being relatively unique. As unique as today's 32-bit IPv4 addresses which, today, can change when a user re- connects." Hope the problem is more clear. Cheers, Med -----Message d'origine----- De : Reinaldo Penno [mailto:rpenno@juniper.net]=20 Envoy=E9 : mardi 15 mars 2011 18:42 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault Cc : 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn-requirements@tools= .ietf.org Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT On 3/15/11 9:47 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Med: It benefits to the users, service providers and content providers: > * a user won't be impacted by a misbehaving action of another user sharin= g the > same IP address. See > http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01= #sect > ion-1 for more details. I think the solution does not fit the problem. Can you elaborate on an actual use case from the top? > * a service provider won't receive calls to hot-lines (OPEX reduction) It will not receive calls or it will receive calls but will have more information to go with them? The identify of the user can be determined by the ISP through NAT logs base= d on public source IP, port alone. Any action by the ISP will need to be done on the private side anyway where there is a 'stable' IP address. This seems another incarnation of the 'log' problem. > * content providers: service experience. Service experience to the content provider or the subscriber? Can you elaborate in a little more detail how subscribers will benefit from this? BTW, I'm not really opposed to this at this point to this but it is not clear to me what exactly we are trying to solve and for which purpose. "1.1. Problem to Be Solved Observation: Today, servers use the source IPv4 address as an identifier to treat some incoming connections differently." From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 01:13:53 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4923A6870 for ; Wed, 16 Mar 2011 01:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 dTYZrnMrYnJB for ; Wed, 16 Mar 2011 01:13:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id BCE413A684A for ; Wed, 16 Mar 2011 01:13:52 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 23D9A22C6AD; Wed, 16 Mar 2011 09:15:18 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0A45B27C037; Wed, 16 Mar 2011 09:15:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 16 Mar 2011 09:15:17 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 09:15:16 +0100 Thread-Topic: CGN REQ: Address space multiplicative factor Thread-Index: Acvjskgm9gr954uoR/2ktTBjlXZxlA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3D44@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3D44PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.73319 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Address space multiplicative factor X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 08:13:53 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3D44PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The current version of the draft does not elaborate on the address sharing = ratio which is one of the foundation of a CGN. To start, IMO, having something similar to http://tools.ietf.org/html/draft= -ietf-intarea-shared-addressing-issues-05#section-26.2 would be useful (BTW= , you can copy that text). We might consider including some requirements on the address sharing scheme= s to be supported by the CGN. This can be discussed if this is not seen as = implementation-specific (e.g., FIFO mode, Quota-based model, dynamic addres= s sharing mode, etc.). Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3D44PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
T= he current=20 version of the draft does not elaborate on the address sharing ratio which = is=20 one of the foundation of a CGN.
 
 
We=20 might consider including some requirements on the address sharing schemes t= o be=20 supported by the CGN. This can be discussed if this is not seen as=20 implementation-specific (e.g., FIFO mode, Quota-based model, dynamic addres= s=20 sharing mode, etc.). 
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3D44PUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 01:54:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C78C3A68A7 for ; Wed, 16 Mar 2011 01:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 NhrSZLxeS9Dc for ; Wed, 16 Mar 2011 01:54:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 19E923A6893 for ; Wed, 16 Mar 2011 01:54:56 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 360FF2AC565; Wed, 16 Mar 2011 09:56:22 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 19FA3C8061; Wed, 16 Mar 2011 09:56:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 16 Mar 2011 09:56:22 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 09:56:20 +0100 Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: AcvjIzBUZe2XYRcbSNCzhU8+x/B+hAAFwwTAAB1yIdA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3D9D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <127501cbe33a$57f0d380$07d27a80$@com> In-Reply-To: <127501cbe33a$57f0d380$07d27a80$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.73319 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 08:54:58 -0000 Re-, For the RECOMMENDED values, I must admit this is complex because it depends= on the address sharing ratio, the actual port usage ratio, etc. As an SP I would like to have these parameters configurable. We hope with t= he operational experience we tune these parameters to find a RECOMMENDED va= lue. Cheers, Med -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 18:57 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: Hold-down pool > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 8:11 AM > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: 'behave' <(behave@ietf.org)> > Subject: [BEHAVE] CGN REQ: Hold-down pool >=20 > Re-, >=20 > An important missing requirement is the behaviour for the timeouted > ports; I refer to this as hold down pool. These ports SHOULD NOT be > assigned to new requesting users before the expiration of the hold down > timer. The purpose is to prevent users from receiving unwanted traffic. Agreed, that should be a requirement. > The hold-down timer and size of the pool should be configurable by the > operator. Can we make recommendations on the hold down timers for UDP, TCP,=20 and ICMP? -d > Cheers, > Med > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 01:59:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26793A68B7 for ; Wed, 16 Mar 2011 01:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 V5PbeFXWcz51 for ; Wed, 16 Mar 2011 01:59:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id D2AA93A68B3 for ; Wed, 16 Mar 2011 01:59:43 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2D16E324492; Wed, 16 Mar 2011 10:01:09 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 128C927C037; Wed, 16 Mar 2011 10:01:09 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 16 Mar 2011 10:01:08 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 10:01:07 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25wAGI9NwAAAm27EAAJS3UAAe38vw Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3DAD@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> In-Reply-To: <12b201cbe33d$03060ef0$09122cd0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.83029 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 08:59:45 -0000 Re-, Please see inline. =20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 15 mars 2011 19:16 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: SPAM Protection > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 11:08 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >=20 > Re-, >=20 > Port 25 is provided as an example. > The functional requirement can be reworded to something like: "the CGN > SHOULD be able to block some ports. The ports to be prohibited MUST be > configurable." >=20 > Please don"t forget the CGN we are talking about can be a DS-Lite CGN: > the CGN is the place to access the IPv4 packet. "Legacy" filters to > prevent SPAM as deployed in operational networks are not able to > inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN. I don't see this being a CGN requirement. I assume you want these ports blocked before they consume state in the CGN, which means they are blocked in *front* of the CGN function. Med: Exactly. In the AFTR architecture, it's somewhere between where the tunnel is unwrapped and the packets are NATted. Is that "in" the CGN?=20 Med: It is an input to the NAT function of the CGN: "don't NAT when interna= l source port is equal to X"=20 Maybe Softwires should take on that requirment? Or are there non-DS-Lite scenarios where this is really something that only the CGN can do? Med: I prefer to have this discussed in the CGN requirement. The CGN I-D sh= ould not be specific to given model (e.g., NAT444, DS-Lite, L2-NAT). = From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 02:01:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E606C3A68B3 for ; Wed, 16 Mar 2011 02:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 WJ1DvVyg3OJX for ; Wed, 16 Mar 2011 02:01:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id B84AC3A6874 for ; Wed, 16 Mar 2011 02:01:22 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 308732DC282; Wed, 16 Mar 2011 10:02:48 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 16CCA35C058; Wed, 16 Mar 2011 10:02:48 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 16 Mar 2011 10:02:48 +0100 From: To: "Joel M. Halpern" Date: Wed, 16 Mar 2011 10:02:47 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: AcvjQfWdW89NmbIRTN+b4FBgGUP6RgAdsHJg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <4D7FB517.3030708@joelhalpern.com> In-Reply-To: <4D7FB517.3030708@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.81219 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 09:01:24 -0000 Dear Joel, This is a filtering function which can be seen in the same level as the "f= iltering behavior" defined by BEHAVE WG in the past. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Joel M. Halpern Envoy=E9 : mardi 15 mars 2011 19:51 Cc : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: SPAM Protection I would agree with dan. What you are describing is a firewalling or filtering function. While=20 those are functions operators want, those are not the function of the=20 CGN. Divide a problem a conquering the pieces serves us well. Yours, Joel On 3/15/2011 2:15 PM, Dan Wing wrote: >> -----Original Message----- >> From: mohamed.boucadair@orange-ftgroup.com >> [mailto:mohamed.boucadair@orange-ftgroup.com] >> Sent: Tuesday, March 15, 2011 11:08 AM >> To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org >> Cc: behave@ietf.org >> Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >> >> Re-, >> >> Port 25 is provided as an example. >> The functional requirement can be reworded to something like: "the CGN >> SHOULD be able to block some ports. The ports to be prohibited MUST be >> configurable." >> >> Please don"t forget the CGN we are talking about can be a DS-Lite CGN: >> the CGN is the place to access the IPv4 packet. "Legacy" filters to >> prevent SPAM as deployed in operational networks are not able to >> inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN. > > I don't see this being a CGN requirement. I assume you want these > ports blocked before they consume state in the CGN, which means they > are blocked in *front* of the CGN function. In the AFTR architecture, > it's somewhere between where the tunnel is unwrapped and the packets > are NATted. Is that "in" the CGN? > > Maybe Softwires should take on that requirment? Or are there > non-DS-Lite scenarios where this is really something that only > the CGN can do? > > -d > > >> Cheers, >> Med >> >> ________________________________________ >> De : Dan Wing [dwing@cisco.com] >> Date d'envoi : mardi 15 mars 2011 18:53 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- >> requirements@tools.ietf.org >> Cc : behave@ietf.org >> Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >> >>> -----Original Message----- >>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>> Behalf Of mohamed.boucadair@orange-ftgroup.com >>> Sent: Tuesday, March 15, 2011 7:56 AM >>> To: draft-ietf-behave-lsn-requirements@tools.ietf.org >>> Cc: 'behave'<(behave@ietf.org)> >>> Subject: [BEHAVE] CGN REQ: SPAM Protection >>> >>> Re-, >>> >>> An explicit requirement about the support of means to protect against >>> SPAM should be IMO added to the req list. For instance the default >>> behaviour would be the CGN block port 25 for SMTP. >> >> That is an operational policy of an ISP, not a CGN. >> >> Does IETF have any existing recommendation to block outbound TCP/25? >> If >> not, I don't believe we could create one in BEHAVE. >> >> -d >> >> >> >> >> >> > > > _______________________________________________ > 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 ssenthil@cisco.com Wed Mar 16 02:17:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7DF3A68C9 for ; Wed, 16 Mar 2011 02:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuN8oZ71-+-u for ; Wed, 16 Mar 2011 02:17:44 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 17F583A6822 for ; Wed, 16 Mar 2011 02:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=2454; q=dns/txt; s=iport; t=1300267150; x=1301476750; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=jA+a38apVF6RrvF66K/B5IwAVZZdy37EVyV88DL/Rj4=; b=Gc/kUk2WvySOsM6mW9hCYN3LldXJkQAUm4v2yIEKDDvAfVir2MXx/b/A fQPOQSDfhaCJUGRxP7SXOS553xpvHNW2cF1ZIH2j+WjzLPMFA6Xuezv0o P28vZZ4KOPGjJPIHpRhYrAxq4CBE8EEFx8V66usASa3WLa1+ru9QJOIho g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBACYdgE2tJV2d/2dsb2JhbACYUI03d6RRnFGFYgSMXoNT X-IronPort-AV: E=Sophos;i="4.63,193,1299456000"; d="scan'208";a="276465928" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2011 09:19:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2G9J9vG024584; Wed, 16 Mar 2011 09:19:09 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 02:19:09 -0700 Received: from 10.65.81.123 ([10.65.81.123]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Mar 2011 09:19:08 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 16 Mar 2011 05:20:14 -0400 From: ssenthil To: , Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: AcvjIzBUZe2XYRcbSNCzhU8+x/B+hAAFwwTAAB1yIdAAAtWXFw== In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3D9D@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Mar 2011 09:19:09.0731 (UTC) FILETIME=[34F8EF30:01CBE3BB] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 09:17:45 -0000 There should be default values for these hold-down timers in the absence of any configured values. We should not expect the operators to configure thes= e timeouts to make CGN operational. It may be as simple as no-holddown-timers= . One of the common performance metric that is used to measure a CGN is the connection setup rate and with the holddown logic that metric will now largely depend on the value of the hold-down timers. Senthil On 3/16/11 4:56 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: >=20 > Re-, >=20 > For the RECOMMENDED values, I must admit this is complex because it depen= ds on > the address sharing ratio, the actual port usage ratio, etc. >=20 > As an SP I would like to have these parameters configurable. We hope with= the > operational experience we tune these parameters to find a RECOMMENDED val= ue. >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 18:57 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; > draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Hold-down pool >=20 >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of mohamed.boucadair@orange-ftgroup.com >> Sent: Tuesday, March 15, 2011 8:11 AM >> To: draft-ietf-behave-lsn-requirements@tools.ietf.org >> Cc: 'behave' <(behave@ietf.org)> >> Subject: [BEHAVE] CGN REQ: Hold-down pool >>=20 >> Re-, >>=20 >> An important missing requirement is the behaviour for the timeouted >> ports; I refer to this as hold down pool. These ports SHOULD NOT be >> assigned to new requesting users before the expiration of the hold down >> timer. The purpose is to prevent users from receiving unwanted traffic. >=20 > Agreed, that should be a requirement. >=20 >> The hold-down timer and size of the pool should be configurable by the >> operator. >=20 > Can we make recommendations on the hold down timers for UDP, TCP, > and ICMP? >=20 > -d >=20 >=20 >=20 >> Cheers, >> Med >> _______________________________________________ >> 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 mohamed.boucadair@orange-ftgroup.com Wed Mar 16 02:27:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9176B3A68D2 for ; Wed, 16 Mar 2011 02:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 AZFMZwSvz6Zu for ; Wed, 16 Mar 2011 02:27:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 8F14D3A68C8 for ; Wed, 16 Mar 2011 02:27:00 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 213B33B44BD; Wed, 16 Mar 2011 10:28:25 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 09BA538406E; Wed, 16 Mar 2011 10:28:25 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 16 Mar 2011 10:28:25 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 10:28:23 +0100 Thread-Topic: CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) Thread-Index: AcvjvH8Qtmo72ApCSseCMeXE6+Fhfw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.90032 Cc: "behave@ietf.org" Subject: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 09:27:01 -0000 Dear authors, The requirement I-D needs to specify the behaviour of the CGN when there ar= e no available ports or when the per-subscriber quota is reached.=20 The requirement can elaborate on the behaviour of the CGN such as the follo= wing (only as example): If a (transport) protocol-specific state limit is configured or when there = is no available free port, no binding for in-excess traffic must be instant= iated in the CGN; in addition:=20 * appropriate log events should be recorded * ICMP message should be sent back to the requesting client (e.g., ICMP mes= sages type 3 code 13) * a notification (e.g., SNMP trap) towards a management system is be issued * etc. Cheers, Med= From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 02:35:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9FA3A68DE for ; Wed, 16 Mar 2011 02:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 oF0JTE14xNhb for ; Wed, 16 Mar 2011 02:35:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 63F093A68EC for ; Wed, 16 Mar 2011 02:35:23 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 38733190111; Wed, 16 Mar 2011 10:36:45 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 17084158074; Wed, 16 Mar 2011 10:36:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 16 Mar 2011 10:36:45 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 10:36:43 +0100 Thread-Topic: CGN REQ: Source address filtering Thread-Index: AcvjvakQVsZsUx+HSIyQJLK0/XYzMw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3DF6@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.90032 Cc: "behave@ietf.org" Subject: [BEHAVE] CGN REQ: Source address filtering X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 09:35:29 -0000 Re-, =20 This point is more specific to DS-Lite and L2-NAT. The NAT function of the = CGN must only processes IPv4 datagrams whose source address is a private ad= dress (RFC 1918). The behaviour of the CGN when receiving a packet with a b= roadcast address is also to be specified. For other CGN deployment models, address filtering can be enforced before r= eaching the CGN. Cheers, Med= From xiaohong.deng@orange-ftgroup.com Wed Mar 16 03:09:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BDC23A6912 for ; Wed, 16 Mar 2011 03:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGDZHmTv97Nd for ; Wed, 16 Mar 2011 03:09:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 91A953A68EE for ; Wed, 16 Mar 2011 03:09:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 68A1B8B800A; Wed, 16 Mar 2011 11:11:05 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5DC088B8002; Wed, 16 Mar 2011 11:11:05 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 11:10:36 +0100 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, 16 Mar 2011 18:10:31 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC015EC5A5@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC8@PUEXCB1B.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxAAADVbCQAADD60AAPk29wAAWmONA= References: <13e001cbe361$06f7b120$14e71360$@com> <140501cbe364$9ca93240$d5fb96c0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC8@PUEXCB1B.nanterre.francetelecom.fr> From: To: , , , X-OriginalArrivalTime: 16 Mar 2011 10:10:36.0068 (UTC) FILETIME=[64929640:01CBE3C2] Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 10:09:12 -0000 |> >> -----Original Message----- |> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 |> >> Behalf Of Reinaldo Penno |> >> Sent: Tuesday, March 15, 2011 3:19 PM |> >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- |> behave- |> >> lsn-requirements@tools.ietf.org |> >> Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org |> >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment |> >> |> >> That are security considerations that need to be understood in |> relation |> >> to |> >> port block. But many of those can be mitigated. Having=20 |said that, I=20 |> >> would guess there are at least 3 CGN vendors that implement such a |> feature. |> >> Therefore, CGN vendors already do that today. |> >> |> >> As for your example, If the attacker has this access to your=20 |> >> machine the victim should be worried about his credit card, not=20 |> >> ports. (;-) |> > |> > Yes, there are always more severe risks. Could get run over by a |> bus, too. |> > |> > But building a system which has predictable ports is risky for two |> reasons: |> > |> > * security, which everyone likes to discount as "not important". |> > * the port limit will be wrong |>=20 |> There are many ways to overcome the issues you point below. I think=20 |> you might have a specific implementation in mind. | |I am thinking of A+P-like schemes.=20 Xiaohong: When you refer to A+P-like schemes, I can imagine B4 element with port set restricted NAT and AFTR with by passing port set feature, and=20 Address + Port embedded IPv6 prefix is not necessary for Port Set Assignment. Does that make sense? | |Med: Which ones? Dynamic modes have been proposed in A+P; see=20 |http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02.=20 |Port randomization requirement can be fairly honored. | | No implementation magic can |change the number of ports allocated by those schemes, because=20 |those schemes generally stick port information into the IPv6=20 |address or into a tunnel header. | |Med: This is true for the stateless A+P mode but not the=20 |binding mode (see:=20 |http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4=20 |for more details). Xiaohong: Right, the binding mode doesn't require stick port information into the IPv6 address or into a tunnel header. Cheers, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ | | | |-d | | |> > o It will be either too high (too many ports, costing money |> > in the future ("why are we spending $30 for each IPv4 |> > address, giving everyone 1000 ports, but the average user |> > only consuming 10 ports? We are throwing money away"), |> > o It will be too low (too few ports, harming an application, |> > causing support calls). This will be expensive to correct, |> > with some fixed-port schemes, because it requires re-IP'ing |> > the access network for some users or for all users. Some |> > other fixed-port schemes could be changed with a single |> > CLI setting, and don't have this risk. |> > |> > -d |> > |> > |> >> |> >> On 3/15/11 2:28 PM, "Dan Wing" wrote: |> >> |> >>>> A "Port Set" does not mean necessarily "contiguous port range"! |> >>> |> >>> It is not relevant if they are contiguous or not. This=20 |is a false |> >> sense of |> >>> security. |> >>> |> >>> If they are fixed, the ports can be determined by causing the |> victim |> >> to view |> >>> HTML which opens img1.example.com, img2.example.com, |> >> img3.example.com, etc., |> >>> to servers controlled by the attacker. The attacker can=20 |then have=20 |> >>> Javascript release one of those mappings, wait, and the attacker |> >> will know |> >>> the victim will re-use that port -- because it's the only port |> >> available. |> >>> Proof of concept code that does this has been circulating. |> >> |> >> _______________________________________________ |> >> 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 simon.perreault@viagenie.ca Wed Mar 16 05:49:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0DE3A67E1 for ; Wed, 16 Mar 2011 05:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Kk7gvePIjYpC for ; Wed, 16 Mar 2011 05:49:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D97FE3A68AD for ; Wed, 16 Mar 2011 05:49:45 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 812D720E64 for ; Wed, 16 Mar 2011 08:51:11 -0400 (EDT) Message-ID: <4D80B23F.5000102@viagenie.ca> Date: Wed, 16 Mar 2011 08:51:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B17@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B17@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 12:49:47 -0000 On 2011-03-15 10:43, mohamed.boucadair@orange-ftgroup.com wrote: > Since the CGN nodes will be introduced into service providers > networks, some QoS functions are required: > > * Set the value of DSCP field (default behaviour) > * Ability to configure DSCP re-marking policies > * Support of DiffServ capabilities (traffic classification and > marking, traffic conditioning and scheduling, traffic discarding) Why should QoS capabilities be required of a CGN and not of a normal router? > * For the DS-Lite case, some extra functions are required to map > between the contents of the Differentiated Services field of the IPv4 > header and the Differentiated Services field of the IPv6 header for > downstream traffic (vice versa). This this is specific to DS-Lite, I think it should go in draft-ietf-softwire-dual-stack-lite instead. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 05:51:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE283A67FA for ; Wed, 16 Mar 2011 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.020, 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 UNauYFxL7bWY for ; Wed, 16 Mar 2011 05:51:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D49793A67E1 for ; Wed, 16 Mar 2011 05:51:21 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 99C3621F55 for ; Wed, 16 Mar 2011 08:52:47 -0400 (EDT) Message-ID: <4D80B29F.6090700@viagenie.ca> Date: Wed, 16 Mar 2011 08:52:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B21@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B21@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Ability to blacklist misbehaving users X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 12:51:22 -0000 On 2011-03-15 10:45, mohamed.boucadair@orange-ftgroup.com wrote: > In some deployment contexts, the CGN should be able to blacklist (white > list) a misbehaving user. > I suggest to add a requirement about this operational (but important) > requirement. Two questions: - This can be done elsewhere in the provider's network. Why does it need to be in the CGN itself? - Why should we require this of a CGN when we don't require it of normal routers? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 05:52:03 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D703A6911 for ; Wed, 16 Mar 2011 05:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.019, 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 hv5T7aL8Dgq7 for ; Wed, 16 Mar 2011 05:52: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 60E083A67FA for ; Wed, 16 Mar 2011 05:52:01 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 22E5D20E64 for ; Wed, 16 Mar 2011 08:53:27 -0400 (EDT) Message-ID: <4D80B2C6.5090303@viagenie.ca> Date: Wed, 16 Mar 2011 08:53:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B32@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B32@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Bandwidth fair usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 12:52:03 -0000 On 2011-03-15 10:50, mohamed.boucadair@orange-ftgroup.com wrote: > In addition to the rate limit function mentioned in REQ 2, the CGN > should be able to enforce a bandwidth fair usage between subscribers > (traffic policing and shaping) are required. The configuration SHOULD be > system-wise and MAY be per-subscriber (e.g., define service profiles). Same questions as for the other thread: - This can be done elsewhere in the provider's network. Why does it need to be in the CGN itself? - Why should we require this of a CGN when we don't require it of normal routers? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:05:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CCD3A6984 for ; Wed, 16 Mar 2011 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, 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 BdvsoCpb1yKp for ; Wed, 16 Mar 2011 06:05: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 5E5D13A657C for ; Wed, 16 Mar 2011 06:05:11 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2FC9120E64 for ; Wed, 16 Mar 2011 09:06:37 -0400 (EDT) Message-ID: <4D80B5DC.5040500@viagenie.ca> Date: Wed, 16 Mar 2011 09:06:36 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <201103152258.p2FMwG2b020546@givry.fdupont.fr> In-Reply-To: <201103152258.p2FMwG2b020546@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:05:12 -0000 On 2011-03-15 18:58, Francis Dupont wrote: > It needs to be discussed. For EXAMPLE, let's say > there is a CGN that crashes and takes 20 minutes to boot -- could it > reasonably re-use the same IP address pool? 2 minutes to boot? 4 > minutes? What is the amount of time needed. > > => surely at least 2*MSL but IMHO simply the maximum lifetime > of an implicit dynamic mapping (oops, RFC 5382 REQ-5 says it must > be at least 2h04mn... forget, I am joking :-). > > Today when ISPs force subscribers to change IP addresses, do they wait > a day or an hour or a minute before re-using the IP address for another > subscriber? > > => I believe they don't care but technically it is wrong to wait > less than 2*MSL. OK so we have a proposal: wait at least 2*MSL before reusing the same address pool. What does MSL stand for? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:09:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C7E3A68E4 for ; Wed, 16 Mar 2011 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.017, 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 2lLNCUwjTZmf for ; Wed, 16 Mar 2011 06:09:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9C3E63A6986 for ; Wed, 16 Mar 2011 06:09:14 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 59C7420E64 for ; Wed, 16 Mar 2011 09:10:40 -0400 (EDT) Message-ID: <4D80B6CF.7090003@viagenie.ca> Date: Wed, 16 Mar 2011 09:10:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3ADC@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC5@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:09:21 -0000 On 2011-03-16 02:12, mohamed.boucadair@orange-ftgroup.com wrote: > I vote for SHOULD instead of MAY. > > If we want to avoid applications brokenness, we need to have this function supported. I would tend to agree. As said in the introduction: This document describes behavioural requirements that are to be expected of those ISP-controlled NAT devices. Meeting this set of requirements will greatly increase the likelihood that subscribers' applications will function properly. Making PCP a SHOULD would "greatly increase the likelihood that subscribers' applications will function properly." Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:18:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130203A6990 for ; Wed, 16 Mar 2011 06:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.016, 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 aIx3oO7LbKRU for ; Wed, 16 Mar 2011 06:18:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id AE9373A693D for ; Wed, 16 Mar 2011 06:18:53 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 77A5A20E64 for ; Wed, 16 Mar 2011 09:20:19 -0400 (EDT) Message-ID: <4D80B912.5040702@viagenie.ca> Date: Wed, 16 Mar 2011 09:20:18 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> <127301cbe33a$251a9ae0$6f4fd0a0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CD5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CD5@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: NAT MIB/YANG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:18:55 -0000 On 2011-03-16 02:50, mohamed.boucadair@orange-ftgroup.com wrote: > FWIW, we have looked at RFC4008 for a CGN. It seems inadequate for a > CGN -- it lacks ability to alarm if a user is reaching or has > exceeded things like their port quota. Also, walking that MIB would > take a considerable amount of time on a CGN, due to the table > design. > > Med: Yes, I'm aware if this but there is no better reference to quote > (this is why I said "at least"). For sure, the modules need be > adapted to CGN context to cover a set of operational requirements. > There are various proprietary CGN MIB modules in the nature but there > is no standard one. BTW, YANG CGN modules may be needed to for those > using NETCONF. OK so I'm interpreting this as "yes for RFC4008, until we have something better to quote". >> Tunnel MIB (RFC 4087) is to be supported for DS-Lite CGN. > > Did SOFTWIRE require that MIB for Dual-Stack Lite? > > Med: No "management" or manageability considerations are discussed in > SOFTWIRE. I think that should go in a document that would be specific to DS-Lite. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:23:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497393A6994 for ; Wed, 16 Mar 2011 06:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 TFlfucacaHw8 for ; Wed, 16 Mar 2011 06:23:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 2C5203A698E for ; Wed, 16 Mar 2011 06:23:44 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E50B220E64 for ; Wed, 16 Mar 2011 09:25:09 -0400 (EDT) Message-ID: <4D80BA35.6070200@viagenie.ca> Date: Wed, 16 Mar 2011 09:25:09 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <201103152258.p2FMwG2b020546@givry.fdupont.fr> <4D80B5DC.5040500@viagenie.ca> In-Reply-To: <4D80B5DC.5040500@viagenie.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:23:45 -0000 On 2011-03-16 09:06, Simon Perreault wrote: > OK so we have a proposal: wait at least 2*MSL before reusing the same > address pool. > > What does MSL stand for? Sorry I was not in TCP mode. So would this be fine for UDP and ICMP also? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:37:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814C33A693D for ; Wed, 16 Mar 2011 06:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 MjtU+wm1Cqvj for ; Wed, 16 Mar 2011 06:37:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1EA153A68E5 for ; Wed, 16 Mar 2011 06:37:10 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9B62820DC3 for ; Wed, 16 Mar 2011 09:38:35 -0400 (EDT) Message-ID: <4D80BD5B.6020405@viagenie.ca> Date: Wed, 16 Mar 2011 09:38:35 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3D44@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3D44@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Address space multiplicative factor X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:37:11 -0000 On 2011-03-16 04:15, mohamed.boucadair@orange-ftgroup.com wrote: > To start, IMO, having something similar to > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#section-26.2 would > be useful (BTW, you can copy that text). I will include a reference to that section. > We might consider including some requirements on the address sharing > schemes to be supported by the CGN. This can be discussed if this is not > seen as implementation-specific (e.g., FIFO mode, Quota-based model, > dynamic address sharing mode, etc.). Do you have a reference or some text to contribute? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:40:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814403A68E5 for ; Wed, 16 Mar 2011 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 DGaDfq3EYHa2 for ; Wed, 16 Mar 2011 06:40:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 69AAA3A6995 for ; Wed, 16 Mar 2011 06:40:21 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 39CB120DC3 for ; Wed, 16 Mar 2011 09:41:47 -0400 (EDT) Message-ID: <4D80BE1A.3020205@viagenie.ca> Date: Wed, 16 Mar 2011 09:41:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <4D7FB517.3030708@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:40:22 -0000 On 2011-03-16 05:02, mohamed.boucadair@orange-ftgroup.com wrote: > This is a filtering function which can be seen in the same level as the "filtering behavior" defined by BEHAVE WG in the past. Why should we require this of a CGN when we don't require it of a plain router? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:47:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7BF3A699F for ; Wed, 16 Mar 2011 06:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 9AX3CUT4C95s for ; Wed, 16 Mar 2011 06:47:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B21023A698F for ; Wed, 16 Mar 2011 06:47:38 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7EEFF20DC3 for ; Wed, 16 Mar 2011 09:49:04 -0400 (EDT) Message-ID: <4D80BFD0.1060007@viagenie.ca> Date: Wed, 16 Mar 2011 09:49:04 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:47:40 -0000 On 2011-03-15 11:10, mohamed.boucadair@orange-ftgroup.com wrote: > An important missing requirement is the behaviour for the timeouted > ports; I refer to this as hold down pool. These ports SHOULD NOT be > assigned to new requesting users before the expiration of the hold > down timer. The purpose is to prevent users from receiving unwanted > traffic. > > The hold-down timer and size of the pool should be configurable by > the operator. Ok it seems we have consensus to add this. We need to figure out what the default values will be. Proposal: - TCP: 2*MSL - UDP: 0 seconds - ICMP: 0 seconds For UDP and ICMP, there is no point in adding to the normal mapping expiration lifetime. When the mapping expires it already means that there was no traffic on it for the last X seconds. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 06:56:50 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEFC3A698E for ; Wed, 16 Mar 2011 06:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 I4sFOwgOcUjX for ; Wed, 16 Mar 2011 06:56:50 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F34883A6966 for ; Wed, 16 Mar 2011 06:56:48 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB43820DC3 for ; Wed, 16 Mar 2011 09:58:11 -0400 (EDT) Message-ID: <4D80C1F3.9020104@viagenie.ca> Date: Wed, 16 Mar 2011 09:58:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:56:50 -0000 On 2011-03-16 05:28, mohamed.boucadair@orange-ftgroup.com wrote: > The requirement I-D needs to specify the behaviour of the CGN when there are no available ports or when the per-subscriber quota is reached. > > The requirement can elaborate on the behaviour of the CGN such as the following (only as example): > > If a (transport) protocol-specific state limit is configured or when there is no available free port, no binding for in-excess traffic must be instantiated in the CGN; in addition: > > * appropriate log events should be recorded > * ICMP message should be sent back to the requesting client (e.g., ICMP messages type 3 code 13) Not sure about code 13. How about 0 instead? > * a notification (e.g., SNMP trap) towards a management system is be issued > * etc. Unless the WG disagrees, I will add this. I would also specify that the CGN MUST NOT terminate existing mappings in order to "make room". Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:04:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F123A69A2 for ; Wed, 16 Mar 2011 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 qheVlk2-cCR3 for ; Wed, 16 Mar 2011 07:04:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id F15343A69A1 for ; Wed, 16 Mar 2011 07:04:42 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6FE1718C2A2; Wed, 16 Mar 2011 15:06:08 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 57D984C02B; Wed, 16 Mar 2011 15:06:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 16 Mar 2011 15:06:08 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 15:06:06 +0100 Thread-Topic: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies Thread-Index: Acvj2NgQy+4e+veOTpuVaI6RiPeCDgACfIIg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FAE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B17@PUEXCB1B.nanterre.francetelecom.fr> <4D80B23F.5000102@viagenie.ca> In-Reply-To: <4D80B23F.5000102@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.134228 Subject: Re: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:04:44 -0000 Dear Simon, Please see inline. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 13:51 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies On 2011-03-15 10:43, mohamed.boucadair@orange-ftgroup.com wrote: > Since the CGN nodes will be introduced into service providers > networks, some QoS functions are required: >=20 > * Set the value of DSCP field (default behaviour) > * Ability to configure DSCP re-marking policies > * Support of DiffServ capabilities (traffic classification and > marking, traffic conditioning and scheduling, traffic discarding) Why should QoS capabilities be required of a CGN and not of a normal router= ? Med: You point is valid when the CGN function is embedded in a CGN but a CG= N function may be embedded in a standalone device (not a router); hence the= need to support those functions. > * For the DS-Lite case, some extra functions are required to map > between the contents of the Differentiated Services field of the IPv4 > header and the Differentiated Services field of the IPv6 header for > downstream traffic (vice versa). This this is specific to DS-Lite, I think it should go in draft-ietf-softwire-dual-stack-lite instead. Med: The DS-Lite Spec does not elaborate on how NAT is done and in particul= ar for the DSCP marking of NATed packets. This IMO should be handled in the= CGN I-D. From remi.denis-courmont@nokia.com Wed Mar 16 07:09:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532B53A69AB for ; Wed, 16 Mar 2011 07:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.248, 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 EiWbFach65Jr for ; Wed, 16 Mar 2011 07:09:50 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id CA9B53A69A1 for ; Wed, 16 Mar 2011 07:09:49 -0700 (PDT) Received: from leon.remlab.net (helruo-dhcp021156.ntc.nokia.com [172.21.21.156]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2GEBFnY032311; Wed, 16 Mar 2011 16:11:15 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: MeeGo Devices - Nokia To: behave@ietf.org Date: Wed, 16 Mar 2011 16:11:21 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.35.9; KDE/4.5.1; i686; ; ) References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201103161611.21765.remi.denis-courmont@nokia.com> X-Nokia-AV: Clean Cc: "ext mohamed.boucadair@orange-ftgroup.com" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:09:51 -0000 On Wednesday 16 March 2011 11:28:23 ext mohamed.boucadair@orange-ftgroup.co= m,=20 you wrote: > Dear authors, >=20 > The requirement I-D needs to specify the behaviour of the CGN when there > are no available ports or when the per-subscriber quota is reached. >=20 > The requirement can elaborate on the behaviour of the CGN such as the > following (only as example): >=20 > If a (transport) protocol-specific state limit is configured or when there > is no available free port, no binding for in-excess traffic must be > instantiated in the CGN; in addition: >=20 > * appropriate log events should be recorded > * ICMP message should be sent back to the requesting client (e.g., ICMP > messages type 3 code 13) There's two situations where a user can run out of port. Either (s)he is ev= il=20 and trying to mount a denial of service, or it legitimately requires a lot = of=20 concurrent flows toward the same remote IP address. If the user is evil, I would rather not send an ICMP message at all. If the user is not evil, I would rather drop the packet and cross my finger= s=20 that one port will be freed soon enough that upper-layer (transport or app)= =20 retransmits will succeed in getting a port allocated. I believe application= s=20 will cope better with that, than with ICMP errors Think of the stereotypical case of a we browser establishing a LOT of HTTP= =20 connections to a server while viewing several pages with lots of images and= =20 AJAX and what not. Waiting for retransmit will slow down the browser. Sendi= ng=20 ICMP errors (or TCP resets) will cause user-visible failures on the other=20 hand. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From simon.perreault@viagenie.ca Wed Mar 16 07:10:48 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670F33A69A1 for ; Wed, 16 Mar 2011 07:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 DZaydJxB-yT4 for ; Wed, 16 Mar 2011 07:10:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 2E3853A69A2 for ; Wed, 16 Mar 2011 07:10:45 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF45220DC3 for ; Wed, 16 Mar 2011 10:12:10 -0400 (EDT) Message-ID: <4D80C53A.7010309@viagenie.ca> Date: Wed, 16 Mar 2011 10:12:10 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DF6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3DF6@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Source address filtering X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:10:48 -0000 On 2011-03-16 05:36, mohamed.boucadair@orange-ftgroup.com wrote: > This point is more specific to DS-Lite and L2-NAT. The NAT function > of the CGN must only processes IPv4 datagrams whose source address is > a private address (RFC 1918). Since this is specific to DS-Lite and L2-NAT then I suggest that it go in a document that would be specific to them. Why not add that to the document describing the AFTR? > The behaviour of the CGN when receiving > a packet with a broadcast address is also to be specified. What behaviour (on top of RFC1122) are you thinking of? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:11:07 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4F73A69A9 for ; Wed, 16 Mar 2011 07:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 GwfW4+M7p2PL for ; Wed, 16 Mar 2011 07:11:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id A728C3A69A2 for ; Wed, 16 Mar 2011 07:11:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6CEFA3B4384; Wed, 16 Mar 2011 15:12:32 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 47698238072; Wed, 16 Mar 2011 15:12:32 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 16 Mar 2011 15:12:32 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 15:12:31 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: Acvj3+kWTYZXUfTwTse6MIlWHuDibwABAsow Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FB9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <4D7FB517.3030708@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> <4D80BE1A.3020205@viagenie.ca> In-Reply-To: <4D80BE1A.3020205@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.12.28.91815 Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:11:07 -0000 Dear Simon, Please see inline. Cheers Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 14:42 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: SPAM Protection On 2011-03-16 05:02, mohamed.boucadair@orange-ftgroup.com wrote: > This is a filtering function which can be seen in the same level as the = "filtering behavior" defined by BEHAVE WG in the past. Why should we require this of a CGN when we don't require it of a plain router? Med: IP routers does not inspect the port information; the CGN does. From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:18:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040063A68EA for ; Wed, 16 Mar 2011 07:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 xq+N8fiXtYxT for ; Wed, 16 Mar 2011 07:18:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 2F80B3A682D for ; Wed, 16 Mar 2011 07:18:10 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id CB01919037B; Wed, 16 Mar 2011 15:19:35 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A885A15806C; Wed, 16 Mar 2011 15:19:32 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 16 Mar 2011 15:19:32 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 15:19:31 +0100 Thread-Topic: [BEHAVE] CGN REQ: Source address filtering Thread-Index: Acvj5CkvWDkwEKCNSz6/qo0z1NDehwAAEzQA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FBE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DF6@PUEXCB1B.nanterre.francetelecom.fr> <4D80C53A.7010309@viagenie.ca> In-Reply-To: <4D80C53A.7010309@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.135128 Subject: Re: [BEHAVE] CGN REQ: Source address filtering X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:18:11 -0000 Re-, I tend to disagree. I see the CGN requirement I-D as the place to cover the= requirements for all variants of CGN including the DS-Lite and L2-NAT. =20 More comments inline. Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 15:12 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Source address filtering On 2011-03-16 05:36, mohamed.boucadair@orange-ftgroup.com wrote: > This point is more specific to DS-Lite and L2-NAT. The NAT function > of the CGN must only processes IPv4 datagrams whose source address is > a private address (RFC 1918). Since this is specific to DS-Lite and L2-NAT then I suggest that it go in a document that would be specific to them. Why not add that to the document describing the AFTR? Med: DS-Lite I-D refers to the CGN Requirements I-D for the NAT behaviour. > The behaviour of the CGN when receiving > a packet with a broadcast address is also to be specified. What behaviour (on top of RFC1122) are you thinking of? Med: What I has in mind is for instance to add an explicit statement saying= : "drop packets with broadcast addresses".= From simon.perreault@viagenie.ca Wed Mar 16 07:18:15 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390103A69A8 for ; Wed, 16 Mar 2011 07:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 8Rzt-GJXvG03 for ; Wed, 16 Mar 2011 07:18:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F207A3A69A3 for ; Wed, 16 Mar 2011 07:18:13 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C09BE21F23 for ; Wed, 16 Mar 2011 10:19:39 -0400 (EDT) Message-ID: <4D80C6FB.3040101@viagenie.ca> Date: Wed, 16 Mar 2011 10:19:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr>, <12f501cbe341$fe3310d0$fa993270$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr> <138701cbe357$ed3e63e0$c7bb2ba0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC7@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:18:15 -0000 On 2011-03-16 02:21, mohamed.boucadair@orange-ftgroup.com wrote: > If they are fixed, the ports can be determined by causing the victim > to view HTML which opens img1.example.com, img2.example.com, > img3.example.com, etc., to servers controlled by the attacker. The > attacker can then have Javascript release one of those mappings, > wait, and the attacker will know the victim will re-use that port -- > because it's the only port available. Proof of concept code that does > this has been circulating. > > Med: Your point is valid. This is why there are other mode for the > assignment of the port sets: when a packet arrives and now binding is > available, a small random port set is generated. Once all the ports > are used, a new random port set is generated, etc. This processes is > repeated until reaching the per-subscriber quota. A user is never > assigned the same port sets. The size of the port set per binding is > configurable. I fail to see how this prevents the attack Dan described. Are the ports within a port set only used once? If so, it will come with heavy impacts on port utilization. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 07:20:35 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496703A682D for ; Wed, 16 Mar 2011 07:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 uT4LoVB1AqSQ for ; Wed, 16 Mar 2011 07:20:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 501443A68EA for ; Wed, 16 Mar 2011 07:20:34 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2D73320DC3 for ; Wed, 16 Mar 2011 10:22:00 -0400 (EDT) Message-ID: <4D80C787.7010806@viagenie.ca> Date: Wed, 16 Mar 2011 10:21:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:20:35 -0000 On 2011-03-16 02:16, mohamed.boucadair@orange-ftgroup.com wrote: > The port set does not means contiguous port range. Random port set can be handled by the CGN. This should be explicit in the requirements IMO. > > In deployments where a small address sharing ration is needed (e.g., 1:2, 1:3), port randomization is still possible within the large port range. > > The I-D already discusses the trade-offs: > > Security: Mechanisms (1) and (2) provide very good security in that > ports numbers are not easily guessed. Easily guessed port numbers > put subscribers at risk of the attacks described in [RFC6056]. > Mechanism (3) provides poor security to subscribers, especially if > the "bin" size is small. I think it will need to be changed in light of the attack described by Dan. To me, (2) does not appear to be as secure as (1) anymore. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:25:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EA93A6968 for ; Wed, 16 Mar 2011 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 OOiO9YTAId9g for ; Wed, 16 Mar 2011 07:25:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 574263A6911 for ; Wed, 16 Mar 2011 07:25:29 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9490E3B44B3; Wed, 16 Mar 2011 15:26:55 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7941F35C060; Wed, 16 Mar 2011 15:26:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 16 Mar 2011 15:26:55 +0100 From: To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "behave@ietf.org" Date: Wed, 16 Mar 2011 15:26:54 +0100 Thread-Topic: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) Thread-Index: Acvj5ATkisUbTuejS0qO+uASVmiLRQAAXCHA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FC5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> <201103161611.21765.remi.denis-courmont@nokia.com> In-Reply-To: <201103161611.21765.remi.denis-courmont@nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.123324 Cc: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:25:32 -0000 Dear R=E9mi, When port quota are configured, there is no much value to differentiate the= customers (evil or not); it is more simple to have a system-wise configura= tion.=20 Applications may evolve in the future to use the returned ICMP message and = to adapt their behaviours accordingly.=20 BTW, I'm fine with having the ability to enable/disable this ICMP function. Cheers, Med=20 -----Message d'origine----- De : R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 Envoy=E9 : mercredi 16 mars 2011 15:11 =C0 : behave@ietf.org Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@too= ls.ietf.org Objet : Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached = (ICMP notification) On Wednesday 16 March 2011 11:28:23 ext mohamed.boucadair@orange-ftgroup.co= m,=20 you wrote: > Dear authors, >=20 > The requirement I-D needs to specify the behaviour of the CGN when there > are no available ports or when the per-subscriber quota is reached. >=20 > The requirement can elaborate on the behaviour of the CGN such as the > following (only as example): >=20 > If a (transport) protocol-specific state limit is configured or when ther= e > is no available free port, no binding for in-excess traffic must be > instantiated in the CGN; in addition: >=20 > * appropriate log events should be recorded > * ICMP message should be sent back to the requesting client (e.g., ICMP > messages type 3 code 13) There's two situations where a user can run out of port. Either (s)he is ev= il=20 and trying to mount a denial of service, or it legitimately requires a lot = of=20 concurrent flows toward the same remote IP address. If the user is evil, I would rather not send an ICMP message at all. If the user is not evil, I would rather drop the packet and cross my finger= s=20 that one port will be freed soon enough that upper-layer (transport or app)= =20 retransmits will succeed in getting a port allocated. I believe application= s=20 will cope better with that, than with ICMP errors Think of the stereotypical case of a we browser establishing a LOT of HTTP= =20 connections to a server while viewing several pages with lots of images and= =20 AJAX and what not. Waiting for retransmit will slow down the browser. Sendi= ng=20 ICMP errors (or TCP resets) will cause user-visible failures on the other=20 hand. --=20 R=E9mi Denis-Courmont http://www.remlab.net/ From Francis.Dupont@fdupont.fr Wed Mar 16 07:26:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703983A6977 for ; Wed, 16 Mar 2011 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzXZ9xQZlKUb for ; Wed, 16 Mar 2011 07:26:42 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 67DFC3A699E for ; Wed, 16 Mar 2011 07:26:42 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GES8tI078780; Wed, 16 Mar 2011 15:28:08 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161428.p2GES8tI078780@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 07:12:36 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC5@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 15:28:08 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , Benson Schliesser Subject: Re: [BEHAVE] CGN REQ: Control NAT mappings for inbound communications X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:26:43 -0000 In your previous mail you wrote: I vote for SHOULD instead of MAY. +1 (but *NOT* for PCP as the *only* RECOMMENDED solution) Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:30:05 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DDC3A6968 for ; Wed, 16 Mar 2011 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.104 X-Spam-Level: X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 D3-VpQEgjp87 for ; Wed, 16 Mar 2011 07:30:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 77EC83A6920 for ; Wed, 16 Mar 2011 07:30:00 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 92253324419; Wed, 16 Mar 2011 15:31:26 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 781CC35C05A; Wed, 16 Mar 2011 15:31:26 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 16 Mar 2011 15:31:26 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 15:31:24 +0100 Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: Acvj4PVxjfP2WzhwRh2P81+sbGHHNAABWd7A Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FC7@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <4D80BFD0.1060007@viagenie.ca> In-Reply-To: <4D80BFD0.1060007@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.140321 Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:30:05 -0000 Re-, For the UDP don't forget the case of incoming connections (e.g., SIP INVITE= message is received just after a PCP-instructed mapping expired.). We need= a safety timer for UDP also. BTW, in addition to the timers, we need to consider also the pool size. Cheers Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 14:49 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Hold-down pool On 2011-03-15 11:10, mohamed.boucadair@orange-ftgroup.com wrote: > An important missing requirement is the behaviour for the timeouted > ports; I refer to this as hold down pool. These ports SHOULD NOT be > assigned to new requesting users before the expiration of the hold > down timer. The purpose is to prevent users from receiving unwanted > traffic. >=20 > The hold-down timer and size of the pool should be configurable by > the operator. Ok it seems we have consensus to add this. We need to figure out what the default values will be. Proposal: - TCP: 2*MSL - UDP: 0 seconds - ICMP: 0 seconds For UDP and ICMP, there is no point in adding to the normal mapping expiration lifetime. When the mapping expires it already means that there was no traffic on it for the last X seconds. Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From Francis.Dupont@fdupont.fr Wed Mar 16 07:30:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE48B3A699E for ; Wed, 16 Mar 2011 07:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkLcKZu44Xz9 for ; Wed, 16 Mar 2011 07:30:27 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 2D9403A6920 for ; Wed, 16 Mar 2011 07:30:26 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GEVqua078968; Wed, 16 Mar 2011 15:31:52 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161431.p2GEVqua078968@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 07:16:42 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 15:31:52 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , Benson Schliesser Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:30:29 -0000 In your previous mail you wrote: Random port set can be handled by the CGN. => I have a concern about the term 'random set' because I am not sure about its meaning (so if I missed the definition please send the pointer to me). Regards Francis.Dupont@fdupont.fr From simon.perreault@viagenie.ca Wed Mar 16 07:31:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D7E3A6920 for ; Wed, 16 Mar 2011 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.011, 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 oJFAQnGPEHYs for ; Wed, 16 Mar 2011 07:31:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F01063A6957 for ; Wed, 16 Mar 2011 07:31:26 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 764FB20DC3 for ; Wed, 16 Mar 2011 10:32:52 -0400 (EDT) Message-ID: <4D80CA14.9040808@viagenie.ca> Date: Wed, 16 Mar 2011 10:32:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> <201103161611.21765.remi.denis-courmont@nokia.com> In-Reply-To: <201103161611.21765.remi.denis-courmont@nokia.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:31:28 -0000 On 2011-03-16 10:11, Rmi Denis-Courmont wrote: > If the user is not evil, I would rather drop the packet and cross my fingers > that one port will be freed soon enough that upper-layer (transport or app) > retransmits will succeed in getting a port allocated. I believe applications > will cope better with that, than with ICMP errors Agreed. This is very similar to what happens when a normal router exceeds its capacity: it drops the packet. This is congestion. TCP is built on the assumption that packet loss equals congestion. We should not interfere with that. I think that argument would be strong enough to warrant the contrary: a CGN MUST NOT send an ICMP message when it has no ports left. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 07:33:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9443A6957 for ; Wed, 16 Mar 2011 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 oOHZfYb1MLYQ for ; Wed, 16 Mar 2011 07:33:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id AC91C3A6920 for ; Wed, 16 Mar 2011 07:33:31 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8673F20DC3 for ; Wed, 16 Mar 2011 10:34:57 -0400 (EDT) Message-ID: <4D80CA91.80607@viagenie.ca> Date: Wed, 16 Mar 2011 10:34:57 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <201103161431.p2GEVqua078968@givry.fdupont.fr> In-Reply-To: <201103161431.p2GEVqua078968@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:33:32 -0000 On 2011-03-16 10:31, Francis Dupont wrote: > In your previous mail you wrote: > > Random port set can be handled by the CGN. > > => I have a concern about the term 'random set' because I am not sure > about its meaning (so if I missed the definition please send the > pointer to me). Useful to all: it corresponds to mechanism (2) in section 5. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From lars.eggert@nokia.com Wed Mar 16 07:35:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8650C3A69A0 for ; Wed, 16 Mar 2011 07:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 w25GZ3+TmMOK for ; Wed, 16 Mar 2011 07:35:48 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 967CF3A699F for ; Wed, 16 Mar 2011 07:35:48 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2GEbBxg012303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 16:37:13 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-22--143523429; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D80BFD0.1060007@viagenie.ca> Date: Wed, 16 Mar 2011 16:37:03 +0200 Message-Id: <58912627-4280-46DB-9DBF-7F241FA99528@nokia.com> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <4D80BFD0.1060007@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 16 Mar 2011 16:37:08 +0200 (EET) X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:35:49 -0000 --Apple-Mail-22--143523429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-3-16, at 15:49, Simon Perreault wrote: > Proposal: > - TCP: 2*MSL > - UDP: 0 seconds > - ICMP: 0 seconds >=20 > For UDP and ICMP, there is no point in adding to the normal mapping > expiration lifetime. When the mapping expires it already means that > there was no traffic on it for the last X seconds. I don't get the need for hold-down. If you assume that the binding = timeout protects UDP and ICMP from late packets (i.e., it's > 2*MSL) why = is this not also effective for TCP? Or do you assume that the binding timeouts will be much shorter than = 2*MSL? In that case, introducing a hold-down timer that needs tuple = state doesn't seem to really save memory compared to simply using longer = binding timeouts. What am I missing? Thanks, Lars= --Apple-Mail-22--143523429 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMxNjE0MzcwNFowIwYJKoZIhvcNAQkE MRYEFOxK7o2O6/1LcxQfuFO5RX+FVvC6MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AJMUTcj/63dTvRlR9v7aOGC3KZJkx8ruRyq13G6NrV2UcAuy1zHaqUBbFpt+5FKPW5/OXNNjUPmg sqAUWQcg0N3uEY3+aE8Y6YPdJeYoRXmY+bzz2XMc5dB3zYaHiU8KvPkgTUXqOiIqdaopXmI/WWXz lYMjTAJhe8HYoxemAws3vg51D977HGdOu3N3MLY6e3XBfVg1Jws2RyzgWGT23EZ+tIYrOD63NtX6 Giqu0L7ZQ9LJ9sQsQ/IjuOP1DuVkUXITmK0/hvqN9rnff+scSsGHnZIt1vo/wBv1FzbTpesv3/MH 6nvl9ien67Tyu5N2LhZ2itj8vw1jd4w6PEDv0ekAAAAAAAA= --Apple-Mail-22--143523429-- From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:36:25 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53A23A6957 for ; Wed, 16 Mar 2011 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 nw5BlT7LHmk2 for ; Wed, 16 Mar 2011 07:36:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 58A713A6956 for ; Wed, 16 Mar 2011 07:36:24 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9591B3B4506; Wed, 16 Mar 2011 15:37:50 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 79ACD35C018; Wed, 16 Mar 2011 15:37:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 16 Mar 2011 15:37:50 +0100 From: To: "Francis.Dupont@fdupont.fr" Date: Wed, 16 Mar 2011 15:37:48 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: Acvj5ufE7eIX9/3+Se2nR9ztiTvhmAAABYcA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FCC@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 16 Mar 2011 07:16:42 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <201103161431.p2GEVqua078968@givry.fdupont.fr> In-Reply-To: <201103161431.p2GEVqua078968@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.140321 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , Benson Schliesser Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:36:25 -0000 Hi Francis, By "random port set", I meant: * a set of ports which are randomly generated when a new outbound packet is= received by the CGN * the port set is not contiguous * the port set is not fixe * for subsequent packet requiring a new port, a port from the pre-allocated= random port set is used * when all the ports in the port set are in-use, a new random port set is g= enerated by the CGN, etc until reaching a quota. We can find a better name for this. Cheers, Med =20 -----Message d'origine----- De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Envoy=E9 : mercredi 16 mars 2011 15:32 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Benson Schliesser; draft-ietf-behave-lsn-requirements@tools.ietf.org; = 'behave' <(behave@ietf.org)> Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment=20 In your previous mail you wrote: Random port set can be handled by the CGN. =20 =3D> I have a concern about the term 'random set' because I am not sure about its meaning (so if I missed the definition please send the pointer to me). Regards Francis.Dupont@fdupont.fr From simon.perreault@viagenie.ca Wed Mar 16 07:37:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E9F3A6966 for ; Wed, 16 Mar 2011 07:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 4RsbTtGhE00i for ; Wed, 16 Mar 2011 07:37:08 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 33F083A6911 for ; Wed, 16 Mar 2011 07:37:08 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0CE7320DC3 for ; Wed, 16 Mar 2011 10:38:34 -0400 (EDT) Message-ID: <4D80CB69.4000900@viagenie.ca> Date: Wed, 16 Mar 2011 10:38:33 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "'behave' <(behave@ietf.org)>" References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> <4D7F746C.4060908@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3AC8@PUEXCB1B.nanterre.francetelecom.fr> <4D7F7716.5060108@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3AE4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3AE4@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ-1 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:37:09 -0000 On 2011-03-15 10:34, mohamed.boucadair@orange-ftgroup.com wrote: > If so, how can the CGN recognize that those multiple addresses are > related? > > Med: For the DS-Lite case, the first bits of the IPv6 address (e.g., > 56, 64) are used as a de-multiplexer. For the L2-NAT, this can rely > on the PPP session, etc. If this is specific to DS-Lite and L2-NAT, then I think it should go in a document specific to them. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From remi.denis-courmont@nokia.com Wed Mar 16 07:37:52 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10C53A6920 for ; Wed, 16 Mar 2011 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.186, 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 MxTF99-kUHCb for ; Wed, 16 Mar 2011 07:37:50 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C4F063A6911 for ; Wed, 16 Mar 2011 07:37:49 -0700 (PDT) Received: from leon.remlab.net (helruo-dhcp021156.ntc.nokia.com [172.21.21.156]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2GEdFw7030538; Wed, 16 Mar 2011 16:39:15 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: MeeGo Devices - Nokia To: "ext mohamed.boucadair@orange-ftgroup.com" Date: Wed, 16 Mar 2011 16:39:21 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.35.9; KDE/4.5.1; i686; ; ) References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> <201103161611.21765.remi.denis-courmont@nokia.com> <94C682931C08B048B7A8645303FDC9F33C4DBA3FC5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3FC5@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201103161639.21792.remi.denis-courmont@nokia.com> X-Nokia-AV: Clean Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:37:52 -0000 On Wednesday 16 March 2011 16:26:54 ext mohamed.boucadair@orange-ftgroup.co= m,=20 you wrote: > Dear R=E9mi, >=20 > When port quota are configured, there is no much value to differentiate t= he > customers (evil or not); it is more simple to have a system-wise > configuration. Yeah? So what? I wrote that, regardless of the evilness or not of the user, it was best to= =20 not send ICMP errors (albeit for different reasons). > Applications may evolve in the future to use the returned ICMP message and > to adapt their behaviours accordingly. That's a silly assumption. Evolved applications will learn (if they have no= t=20 already done so) to not make excessive connections to the same peer, and th= ey=20 will learn to do IPv6. So this is all about existing contemporary applications. And I claim that n= ot=20 sending ICMP errors works better in that case. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:41:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449D03A6920 for ; Wed, 16 Mar 2011 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 jUm7d-3g7SEV for ; Wed, 16 Mar 2011 07:41:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 546CC3A6911 for ; Wed, 16 Mar 2011 07:41:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 969E418C0EE; Wed, 16 Mar 2011 15:43:19 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 76E8435C058; Wed, 16 Mar 2011 15:43:19 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 16 Mar 2011 15:43:19 +0100 From: To: Simon Perreault , 'Behave Chairs' Date: Wed, 16 Mar 2011 15:43:18 +0100 Thread-Topic: CGN REQ I-D Scope (was RE: [BEHAVE] CGN REQ-1) Thread-Index: Acvj59ibHeccOWfhSt2q2ly6Z/deBAAABujA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FD9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DB02C8D@PUEXCB1B.nanterre.francetelecom.fr> <4D7F746C.4060908@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3AC8@PUEXCB1B.nanterre.francetelecom.fr> <4D7F7716.5060108@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3AE4@PUEXCB1B.nanterre.francetelecom.fr> <4D80CB69.4000900@viagenie.ca> In-Reply-To: <4D80CB69.4000900@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.105416 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ I-D Scope (was RE: CGN REQ-1) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:41:55 -0000 Dear Simon, Chairs,=20 I thought the CGN requirement I-D is not specific to a given CGN flavour. I= MO, it should cover in particular the DS-Lite CGN. Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 15:39 =C0 : 'behave' <(behave@ietf.org)> Objet : Re: [BEHAVE] CGN REQ-1 On 2011-03-15 10:34, mohamed.boucadair@orange-ftgroup.com wrote: > If so, how can the CGN recognize that those multiple addresses are > related? >=20 > Med: For the DS-Lite case, the first bits of the IPv6 address (e.g., > 56, 64) are used as a de-multiplexer. For the L2-NAT, this can rely > on the PPP session, etc. If this is specific to DS-Lite and L2-NAT, then I think it should go in a document specific to them. Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From Francis.Dupont@fdupont.fr Wed Mar 16 07:45:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73223A699E for ; Wed, 16 Mar 2011 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OESLqIrSuqr2 for ; Wed, 16 Mar 2011 07:45:40 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id C53583A6911 for ; Wed, 16 Mar 2011 07:45:39 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GEl5A4080066; Wed, 16 Mar 2011 15:47:05 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161447.p2GEl5A4080066@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 10:01:07 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3DAD@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 15:47:05 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , Dan Wing Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:45:40 -0000 In your previous mail you wrote: I don't see this being a CGN requirement. I assume you want these ports blocked before they consume state in the CGN, which means they are blocked in *front* of the CGN function. Med: Exactly. => I am afraid there is some misunderstanding: IMHO Dan meant this function is not required to be implemented inside the CGN but can (and IMHO should) be implemented in a device placed before the CGN in the path between the client and the CGN, for instance in front of the CGN. Regards Francis.Dupont@fdupont.fr PS: IMHO it should be as close as possible to the client. Note my ISP puts it in the ISP-provided home gateway (there is a flag to enable port 25 and its default is disabled, i.e., exactly what I'd like :-). From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:47:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2D93A6957 for ; Wed, 16 Mar 2011 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 POeZMk2Q7V6c for ; Wed, 16 Mar 2011 07:47:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 929113A6920 for ; Wed, 16 Mar 2011 07:47:49 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 9D4922AC221; Wed, 16 Mar 2011 15:49:15 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 79D9E158060; Wed, 16 Mar 2011 15:49:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 16 Mar 2011 15:49:15 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Wed, 16 Mar 2011 15:49:14 +0100 Thread-Topic: CGN REQ: Shared address pool Thread-Index: Acvj6VFn15HvFIILSoW+I/8sqiEXPg== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FE1@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA3FE1PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.135128 Cc: "'behave' <\(behave@ietf.org\)>" Subject: [BEHAVE] CGN REQ: Shared address pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:47:51 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3FE1PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, I don't know how this should be covered in the I-D, but I see a value to ha= ve a section to elaborate on the configured address pool to be used in the = external interface of the CGN. In particular, the CGN should: * support contiguous address pool * support non-contiguous addresses As for the size of the address pool, this is deployment-specific. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA3FE1PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Re-,
 
I= don't know=20 how this should be covered in the I-D, but I see a value to have a section = to=20 elaborate on the configured address pool to be used in the external interfa= ce of=20 the CGN. In particular, the CGN should:
 
*= support=20 contiguous address pool
*= support=20 non-contiguous addresses
 
A= s for the=20 size of the address pool, this is deployment-specific.
 
Cheers,
Med
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA3FE1PUEXCB1Bnante_-- From Francis.Dupont@fdupont.fr Wed Mar 16 07:49:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62D73A695C for ; Wed, 16 Mar 2011 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40WxJTe-VvNy for ; Wed, 16 Mar 2011 07:49:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E7E833A6957 for ; Wed, 16 Mar 2011 07:49:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GEolNr080263; Wed, 16 Mar 2011 15:50:47 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161450.p2GEolNr080263@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 10:02:47 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 15:50:47 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "Joel M. Halpern" , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:49:22 -0000 In your previous mail you wrote: This is a filtering function which can be seen in the same level as the "filtering behavior" defined by BEHAVE WG in the past. => deeply disagree: Joel is right: this function is not a natural part of the NAT one. Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 07:52:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4292F3A6954 for ; Wed, 16 Mar 2011 07:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 0HgFoLiCbHQJ for ; Wed, 16 Mar 2011 07:52:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 5B86F3A695C for ; Wed, 16 Mar 2011 07:52:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A460518C4D9; Wed, 16 Mar 2011 15:53:57 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8B0EB4C013; Wed, 16 Mar 2011 15:53:57 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 16 Mar 2011 15:53:57 +0100 From: To: Francis Dupont Date: Wed, 16 Mar 2011 15:53:56 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: Acvj6Y3HEi08euXBQCummGJvttuhQQAABZJQ Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA3FEA@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 16 Mar 2011 10:02:47 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> <201103161450.p2GEolNr080263@givry.fdupont.fr> In-Reply-To: <201103161450.p2GEolNr080263@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.134228 Cc: "Joel M. Halpern" , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:52:32 -0000 Re-, We are not defining a "natural" NAT, we are dealing with a NAT to be deploy= ed in providers networks: i.e., new requirements are to be taken into accou= nt. Enforcing filtering on internal ports has a value for us as SPs. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Francis Dupont Envoy=E9 : mercredi 16 mars 2011 15:51 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Joel M. Halpern; behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: SPAM Protection In your previous mail you wrote: This is a filtering function which can be seen in the same level as the= =20 "filtering behavior" defined by BEHAVE WG in the past. =20 =3D> deeply disagree: Joel is right: this function is not a natural part of the NAT one. Regards Francis.Dupont@fdupont.fr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From Francis.Dupont@fdupont.fr Wed Mar 16 07:59:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5A93A6954 for ; Wed, 16 Mar 2011 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VmOCPNWQIoP for ; Wed, 16 Mar 2011 07:59:37 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 0A74D3A6911 for ; Wed, 16 Mar 2011 07:59:36 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GF13EV081008; Wed, 16 Mar 2011 16:01:03 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161501.p2GF13EV081008@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 10:28:23 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 16:01:03 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:59:38 -0000 In your previous mail you wrote: in addition: * ICMP message should be sent back to the requesting client (e.g., ICMP messages type 3 code 13) => not so clear: usually it is never a good idea to send an ICMP and in this case 3/13 was designed for a permanent condition. So IMHO a SHOULD is not the right thing, I prefer a MAY or alternatively I suggest to implement the MAY switch of RFC 1812 to disable 3/13 sending and to make it 'disable' by default... Regards Francis.Dupont@fdupont.fr From simon.perreault@viagenie.ca Wed Mar 16 08:02:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A753A699E for ; Wed, 16 Mar 2011 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 q6r7cy2FH6jd for ; Wed, 16 Mar 2011 08:02:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5A50C3A6954 for ; Wed, 16 Mar 2011 08:02:03 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D5A8321BBC for ; Wed, 16 Mar 2011 11:03:28 -0400 (EDT) Message-ID: <4D80D140.2060407@viagenie.ca> Date: Wed, 16 Mar 2011 11:03:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DB02C6B@PUEXCB1B.nanterre.francetelecom.fr> <4D7F775D.6030303@viagenie.ca> In-Reply-To: <4D7F775D.6030303@viagenie.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:02:04 -0000 On 2011-03-15 10:27, Simon Perreault wrote: > On 2011-03-15 09:49, mohamed.boucadair@orange-ftgroup.com wrote: >> As you know, several issues are encountered when CGNs are used (see >> http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05 for >> more details). >> >> In order to mitigate some of the issues listed in the above I-D, the CGN >> may inject an information which will be used by remote servers to >> disambiguate users. FWIW, >> http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01 analyzes >> a set of candidates solutions and identifies some limitations. >> >> IMHO, it is valuable to add a requirement in the I-D among these lines. > > I'll definitely need WG feedback on this. Ok there seems to be consensus that there is a problem but that the solution space is not clear enough to make a requirement. So I think what is appropriate at this point is to reference ongoing work. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 08:04:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB54F3A6920 for ; Wed, 16 Mar 2011 08:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 PfmaHW2OfaK3 for ; Wed, 16 Mar 2011 08:04:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DE5D53A6954 for ; Wed, 16 Mar 2011 08:04:08 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 96B3021BBC for ; Wed, 16 Mar 2011 11:05:34 -0400 (EDT) Message-ID: <4D80D1BE.6040408@viagenie.ca> Date: Wed, 16 Mar 2011 11:05:34 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3FE1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3FE1@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Shared address pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:04:09 -0000 On 2011-03-16 10:49, mohamed.boucadair@orange-ftgroup.com wrote: > I don't know how this should be covered in the I-D, but I see a value to > have a section to elaborate on the configured address pool to be used in > the external interface of the CGN. In particular, the CGN should: > > * support contiguous address pool > * support non-contiguous addresses Why? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Mar 16 08:04:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234753A69AB for ; Wed, 16 Mar 2011 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.312 X-Spam-Level: X-Spam-Status: No, score=-110.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 zx+9JDuUII0L for ; Wed, 16 Mar 2011 08:04:26 -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 B84CD3A699E for ; Wed, 16 Mar 2011 08:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5498; q=dns/txt; s=iport; t=1300287953; x=1301497553; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Wrz1pBhDjlwHfZov0iMggjzSFFlTL3Bvs9x1xpY/n4c=; b=buR7GUUJpCtOGbORzSex8Wk649OFu78kYOzcoWykpUXk8N/aNAhQEeVS Ap+YBGGSCj8F8GAb6kfTquCDw4zZift+t1otC/EY9AOj6QIilMyu5SXpO 2upyqi7OrDjEm3Kjo1gmFLHVwhDGrDnH1rjwjxp03QwYC4zJqduDQuOzC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAC5vgE2tJXG9/2dsb2JhbACYVYFki1R3pGKMbI9phWMEhS8 X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="667718263" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2011 15:05:52 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GF5p98001227; Wed, 16 Mar 2011 15:05:52 GMT From: "Dan Wing" To: , "'Reinaldo Penno'" , References: <13e001cbe361$06f7b120$14e71360$@com> <140501cbe364$9ca93240$d5fb96c0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC8@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC8@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 08:05:51 -0700 Message-ID: <164801cbe3eb$a43a3950$ecaeabf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxAAADVbCQAADD60AAPk29wABItJQA= Content-language: en-us Cc: 'DENG Xiaohong ESP/PEK' , behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:04:28 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Tuesday, March 15, 2011 11:28 PM > To: Dan Wing; 'Reinaldo Penno'; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc: DENG Xiaohong ESP/PEK; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 23:59 > =C0 : 'Reinaldo Penno'; BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf- > behave-lsn-requirements@tools.ietf.org > Cc : DENG Xiaohong ESP/PEK; behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Reinaldo Penno > > Sent: Tuesday, March 15, 2011 3:52 PM > > To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- > behave- > > lsn-requirements@tools.ietf.org > > Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > > > > > > > > > > On 3/15/11 3:33 PM, "Dan Wing" wrote: > > > > >> -----Original Message----- > > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > >> Behalf Of Reinaldo Penno > > >> Sent: Tuesday, March 15, 2011 3:19 PM > > >> To: Dan Wing; mohamed.boucadair@orange-ftgroup.com; draft-ietf- > > behave- > > >> lsn-requirements@tools.ietf.org > > >> Cc: 'DENG Xiaohong ESP/PEK'; behave@ietf.org > > >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > > >> > > >> That are security considerations that need to be understood in > > relation > > >> to > > >> port block. But many of those can be mitigated. Having said that, > I > > >> would > > >> guess there are at least 3 CGN vendors that implement such a > > feature. > > >> Therefore, CGN vendors already do that today. > > >> > > >> As for your example, If the attacker has this access to your > machine > > >> the victim should be worried about his credit card, not ports. = (;- > ) > > > > > > Yes, there are always more severe risks. Could get run over by a > > bus, too. > > > > > > But building a system which has predictable ports is risky for two > > reasons: > > > > > > * security, which everyone likes to discount as "not important". > > > * the port limit will be wrong > > > > There are many ways to overcome the issues you point below. I think > you > > might have a specific implementation in mind. >=20 > I am thinking of A+P-like schemes. >=20 > Med: Which ones? Dynamic modes have been proposed in A+P; see > http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02. Port > randomization requirement can be fairly honored. >=20 > No implementation magic can > change the number of ports allocated by those schemes, because > those schemes generally stick port information into the IPv6 > address or into a tunnel header. >=20 > Med: This is true for the stateless A+P mode but not the binding mode > (see: http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 for > more details). Most of the benefits attributed to A+P is that it's stateless in the SP's network. I haven't seen anyone excited about that, but I don't talk to everyone. -d >=20 >=20 > -d >=20 >=20 > > > o It will be either too high (too many ports, costing money > > > in the future ("why are we spending $30 for each IPv4 > > > address, giving everyone 1000 ports, but the average user > > > only consuming 10 ports? We are throwing money away"), > > > o It will be too low (too few ports, harming an application, > > > causing support calls). This will be expensive to = correct, > > > with some fixed-port schemes, because it requires = re-IP'ing > > > the access network for some users or for all users. Some > > > other fixed-port schemes could be changed with a single > > > CLI setting, and don't have this risk. > > > > > > -d > > > > > > > > >> > > >> On 3/15/11 2:28 PM, "Dan Wing" wrote: > > >> > > >>>> A "Port Set" does not mean necessarily "contiguous port range"! > > >>> > > >>> It is not relevant if they are contiguous or not. This is a > false > > >> sense of > > >>> security. > > >>> > > >>> If they are fixed, the ports can be determined by causing the > > victim > > >> to view > > >>> HTML which opens img1.example.com, img2.example.com, > > >> img3.example.com, etc., > > >>> to servers controlled by the attacker. The attacker can then > have > > >>> Javascript release one of those mappings, wait, and the = attacker > > >> will know > > >>> the victim will re-use that port -- because it's the only port > > >> available. > > >>> Proof of concept code that does this has been circulating. > > >> > > >> _______________________________________________ > > >> 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 Francis.Dupont@fdupont.fr Wed Mar 16 08:08:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9DA3A69B4 for ; Wed, 16 Mar 2011 08:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE3ALxjz-wmT for ; Wed, 16 Mar 2011 08:08:08 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 36BC93A69B8 for ; Wed, 16 Mar 2011 08:08:07 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GF9XGh081592; Wed, 16 Mar 2011 16:09:33 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161509.p2GF9XGh081592@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 10:36:43 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3DF6@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 16:09:33 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Source address filtering X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:08:09 -0000 In your previous mail you wrote: This point is more specific to DS-Lite and L2-NAT. The NAT function of the CGN must only processes IPv4 datagrams whose source address is a private address (RFC 1918). => to have implemented this for DS-Lite I can say the wording should be more accurate: there must be such a check but it should accept 192.0.0.0/29 too. IMHO the best is to accept only packets from prefixes in a list which is by default the 3 1918 prefixes and the 192 above. The behaviour of the CGN when receiving a packet with a broadcast address is also to be specified. => do you mean a broadcast address as the source address? (BTW how you can check this?) Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Wed Mar 16 08:12:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE17B3A6911 for ; Wed, 16 Mar 2011 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.279 X-Spam-Level: X-Spam-Status: No, score=-109.279 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, 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 ahAK4dRux3KG for ; Wed, 16 Mar 2011 08:12:20 -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 0C4A33A69B7 for ; Wed, 16 Mar 2011 08:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2714; q=dns/txt; s=iport; t=1300288426; x=1301498026; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=N867RwizFNL+ahe4FefJqnrhMN4WZZDFwH0SxoPwVps=; b=aWfkqXr19zizIhO0gIAp2/LHg7/J/H+BkY0URDFMayEbbA4ScptsMixx OC5w8rvRng8mnqi7TYuGNgs+0dOLkmecjE1h2HXI6vcyd7a8vB8yj3QNI xwK313jOMNUYQ9om+W0pSXwQxtHSuKq804mtM7nEciBLfKeWhNPbfP+/r w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYCAB5wgE2tJXG+/2dsb2JhbACYVYFki1RoD6RZnFWCf4JkBIUv X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="320947950" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2011 15:13:46 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2GFDjPb016168; Wed, 16 Mar 2011 15:13:45 GMT From: "Dan Wing" To: , , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> <127301cbe33a$251a9ae0$6f4fd0a0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CD5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CD5@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 08:13:44 -0700 Message-ID: <166e01cbe3ec$be69c1a0$3b3d44e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIcbO4NKW9aBHQ+ybE/15DgVsuwAGBrdwABqpgjAAEfrV0A== Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: NAT MIB/YANG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:12:21 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, March 15, 2011 11:51 PM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org; = draft- > sivakumar-behave-nat-logging@tools.ietf.org > Cc: behave@ietf.org > Subject: RE: [BEHAVE] CGN REQ: NAT MIB/YANG >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 18:55 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: NAT MIB >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Tuesday, March 15, 2011 8:01 AM > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: 'behave' <(behave@ietf.org)> > > Subject: [BEHAVE] CGN REQ: NAT MIB > > > > Re-, > > > > A requirement to mention that appropriate MIB modules are to be > > supported by the CGN is needed. > > > > At least RFC 4008 is needed. >=20 > FWIW, we have looked at RFC4008 for a CGN. It seems inadequate for a > CGN -- > it lacks ability to alarm if a user is reaching or has exceeded things > like > their port quota. Also, walking that MIB would take a considerable > amount > of time on a CGN, due to the table design. >=20 > Med: Yes, I'm aware if this but there is no better reference to quote > (this is why I said "at least"). If it's known to be inadequate, what is the purpose to include it in a Requirements document? > For sure, the modules need be adapted > to CGN context to cover a set of operational requirements. There are > various proprietary CGN MIB modules in the nature but there is no > standard one. BTW, YANG CGN modules may be needed to for those using > NETCONF. >=20 > BTW, a close topic is to log/notify important events. > http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-00 tried > to captures a set of useful information to log. The events are not > complete and the structure should be updated to cover the DS-Lite and > L2-NAT. >=20 > > Tunnel MIB (RFC 4087) is to be supported for DS-Lite CGN. >=20 > Did SOFTWIRE require that MIB for Dual-Stack Lite? >=20 > Med: No "management" or manageability considerations are discussed in > SOFTWIRE.=3D DS-Lite CGN requirements don't feel appropriate for BEHAVE. We do CGN. The fact that a tunnel is sticking out one side of the CGN (which is what a DS-Lite CGN is) doesn't seem in BEHAVE's scope. -d From simon.perreault@viagenie.ca Wed Mar 16 08:15:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102233A69BD for ; Wed, 16 Mar 2011 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 xe7QAP5NM3pS for ; Wed, 16 Mar 2011 08:15:23 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C7E453A6911 for ; Wed, 16 Mar 2011 08:15:22 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AF19721BBC; Wed, 16 Mar 2011 11:16:48 -0400 (EDT) Message-ID: <4D80D460.8010506@viagenie.ca> Date: Wed, 16 Mar 2011 11:16:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B17@PUEXCB1B.nanterre.francetelecom.fr> <4D80B23F.5000102@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3FAE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3FAE@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:15:24 -0000 On 2011-03-16 10:06, mohamed.boucadair@orange-ftgroup.com wrote: > Why should QoS capabilities be required of a CGN and not of a normal > router? > > Med: You point is valid when the CGN function is embedded in a CGN > but a CGN function may be embedded in a standalone device (not a > router); hence the need to support those functions. You missed my point. I'm not saying that QoS capabilities are in routers, and a CGN is a router, therefore it has QoS for free. That's not my point. What I'm saying is that if an ISP wants a router, and requires QoS from that router, it just buys a router with QoS. There is no document in the IETF saying that all routers need QoS. Change "router" with "CGN" and you have an identical situation. To me, it looks like QoS should be a bullet in an RFP... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Mar 16 08:26:27 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EAA3A6911 for ; Wed, 16 Mar 2011 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 zelN-1rNh3rY for ; Wed, 16 Mar 2011 08:26:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 965493A6977 for ; Wed, 16 Mar 2011 08:26:26 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8B7FE20D3A; Wed, 16 Mar 2011 11:27:51 -0400 (EDT) Message-ID: <4D80D6F7.40407@viagenie.ca> Date: Wed, 16 Mar 2011 11:27:51 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <4D80BFD0.1060007@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3FC7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3FC7@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:26:28 -0000 On 2011-03-16 10:31, mohamed.boucadair@orange-ftgroup.com wrote: > For the UDP don't forget the case of incoming connections (e.g., SIP > INVITE message is received just after a PCP-instructed mapping > expired.). We need a safety timer for UDP also. Hmmm... I was assuming that the CGN had inbound mapping refresh (REQ-6a in RFC4787). I guess the same reasoning equally applies to ICMP. What do you suggest instead of zero? > BTW, in addition to the timers, we need to consider also the pool > size. I don't quite understand the "pool" concept. What happens when the number of ports in hold-down is larger than the pool size? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Francis.Dupont@fdupont.fr Wed Mar 16 08:34:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C663A6991 for ; Wed, 16 Mar 2011 08:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6iWhpA10tAn for ; Wed, 16 Mar 2011 08:34:57 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id EE8833A6911 for ; Wed, 16 Mar 2011 08:34:56 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GFaNux083340; Wed, 16 Mar 2011 16:36:23 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161536.p2GFaNux083340@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Wed, 16 Mar 2011 09:06:36 -0400. <4D80B5DC.5040500@viagenie.ca> Date: Wed, 16 Mar 2011 16:36:23 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 15:34:58 -0000 In your previous mail you wrote: On 2011-03-15 18:58, Francis Dupont wrote: > It needs to be discussed. For EXAMPLE, let's say > there is a CGN that crashes and takes 20 minutes to boot -- could it > reasonably re-use the same IP address pool? 2 minutes to boot? 4 > minutes? What is the amount of time needed. > > => surely at least 2*MSL but IMHO simply the maximum lifetime > of an implicit dynamic mapping (oops, RFC 5382 REQ-5 says it must > be at least 2h04mn... forget, I am joking :-). > > Today when ISPs force subscribers to change IP addresses, do they wait > a day or an hour or a minute before re-using the IP address for another > subscriber? > > => I believe they don't care but technically it is wrong to wait > less than 2*MSL. OK so we have a proposal: wait at least 2*MSL before reusing the same address pool. What does MSL stand for? => "maximum segment life", it is bound to TCP TIME_WAIT state and was standardized to 120 seconds. BTW it is MSL and not 2*MSL in this case, I propose the common wording: "120 seconds (MSL)", this gives: "wait at least 120 seconds (MSL) before reusing the same address pool". Regards Francis.Dupont@fdupont.fr From jmh@joelhalpern.com Wed Mar 16 08:36:37 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F10A3A69B7 for ; Wed, 16 Mar 2011 08:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, 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 07NNn5NIziyL for ; Wed, 16 Mar 2011 08:36:36 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 63B1B3A69A3 for ; Wed, 16 Mar 2011 08:36:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4E5784300E1; Wed, 16 Mar 2011 08:38:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 7944E4300BE; Wed, 16 Mar 2011 08:37:59 -0700 (PDT) Message-ID: <4D80D95D.2020802@joelhalpern.com> Date: Wed, 16 Mar 2011 11:38:05 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <4D7FB517.3030708@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:36:37 -0000 The firweall function should not be conflated with the CGN function. For NAT44, there is some inherent conflating due to the constraint imposed by port rewriting / port acceptance issues. With NPT66, there is no such port rewriting. As such, there is no need to couple the two functions. The firewall may happen to be in the same device as the NPT. It can be upstream or downstream of that, depending upon where the operators wants to place it. Yours, Joel On 3/16/2011 5:02 AM, mohamed.boucadair@orange-ftgroup.com wrote: > Dear Joel, > > This is a filtering function which can be seen in the same level as the "filtering behavior" defined by BEHAVE WG in the past. > > Cheers, > Med > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Joel M. Halpern > Envoy : mardi 15 mars 2011 19:51 > Cc : behave@ietf.org > Objet : Re: [BEHAVE] CGN REQ: SPAM Protection > > I would agree with dan. > What you are describing is a firewalling or filtering function. While > those are functions operators want, those are not the function of the > CGN. Divide a problem a conquering the pieces serves us well. > > Yours, > Joel > > On 3/15/2011 2:15 PM, Dan Wing wrote: >>> -----Original Message----- >>> From: mohamed.boucadair@orange-ftgroup.com >>> [mailto:mohamed.boucadair@orange-ftgroup.com] >>> Sent: Tuesday, March 15, 2011 11:08 AM >>> To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org >>> Cc: behave@ietf.org >>> Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >>> >>> Re-, >>> >>> Port 25 is provided as an example. >>> The functional requirement can be reworded to something like: "the CGN >>> SHOULD be able to block some ports. The ports to be prohibited MUST be >>> configurable." >>> >>> Please don"t forget the CGN we are talking about can be a DS-Lite CGN: >>> the CGN is the place to access the IPv4 packet. "Legacy" filters to >>> prevent SPAM as deployed in operational networks are not able to >>> inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN. >> >> I don't see this being a CGN requirement. I assume you want these >> ports blocked before they consume state in the CGN, which means they >> are blocked in *front* of the CGN function. In the AFTR architecture, >> it's somewhere between where the tunnel is unwrapped and the packets >> are NATted. Is that "in" the CGN? >> >> Maybe Softwires should take on that requirment? Or are there >> non-DS-Lite scenarios where this is really something that only >> the CGN can do? >> >> -d >> >> >>> Cheers, >>> Med >>> >>> ________________________________________ >>> De : Dan Wing [dwing@cisco.com] >>> Date d'envoi : mardi 15 mars 2011 18:53 >>> : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- >>> requirements@tools.ietf.org >>> Cc : behave@ietf.org >>> Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >>> >>>> -----Original Message----- >>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>> Behalf Of mohamed.boucadair@orange-ftgroup.com >>>> Sent: Tuesday, March 15, 2011 7:56 AM >>>> To: draft-ietf-behave-lsn-requirements@tools.ietf.org >>>> Cc: 'behave'<(behave@ietf.org)> >>>> Subject: [BEHAVE] CGN REQ: SPAM Protection >>>> >>>> Re-, >>>> >>>> An explicit requirement about the support of means to protect against >>>> SPAM should be IMO added to the req list. For instance the default >>>> behaviour would be the CGN block port 25 for SMTP. >>> >>> That is an operational policy of an ISP, not a CGN. >>> >>> Does IETF have any existing recommendation to block outbound TCP/25? >>> If >>> not, I don't believe we could create one in BEHAVE. >>> >>> -d >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Wed Mar 16 08:37:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758A03A6991 for ; Wed, 16 Mar 2011 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.309 X-Spam-Level: X-Spam-Status: No, score=-110.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 bf45YCUwfANW for ; Wed, 16 Mar 2011 08:37:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8028A3A6966 for ; Wed, 16 Mar 2011 08:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2936; q=dns/txt; s=iport; t=1300289962; x=1301499562; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=tNttG8LxGe3RsXIS7SYM5PTEE1HCS/s1nIkl09IIMC8=; b=mTgKG35Jz13jjAu44Q22uSnwP5JB/RK4+trLov7Bz1G8Q4XzWDHAjyoy NniZEJEf91ePFJDkK/VaJGiUFxfwBs93Mzx0CpbRGjTwaqFYRawtLVwF7 6/pzaMkXRbGlGfZ/JVJB2yi46My/EwknqxKDgroCmQbapuy0PFN5xuD0z 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAHJ2gE2tJXG9/2dsb2JhbACYVoFki1R3pE6cVYVjBIUv X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="278679383" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2011 15:39:21 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GFdLCQ024416; Wed, 16 Mar 2011 15:39:21 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <127501cbe33a$57f0d380$07d27a80$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3D9D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3D9D@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 08:39:20 -0700 Message-ID: <167201cbe3f0$51b9d320$f52d7960$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIzBUZe2XYRcbSNCzhU8+x/B+hAAFwwTAAB1yIdAAD+sxUA== Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:37:56 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Wednesday, March 16, 2011 1:56 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE: [BEHAVE] CGN REQ: Hold-down pool >=20 >=20 > Re-, >=20 > For the RECOMMENDED values, I must admit this is complex because it > depends on the address sharing ratio, the actual port usage ratio, = etc. I don't think so. There is a safe minimum that we can recommend, and justify why. Otherwise, when IPv4 addresses get expensive and/or users need more ports, ISPs will "fix" the problem by cranking down the hold timer from NNN seconds to NN seconds to N seconds. > As an SP I would like to have these parameters configurable. We hope > with the operational experience we tune these parameters to find a > RECOMMENDED value. I don't think the SP is well-placed to actually gain that operational experience. I doubt anyone will call their ISP when their TCP session is corrupted due to aggressive timers. What is the ISP's=20 ability to receive operational feedback from the harm caused to users? Take an extreme -- set the value to 0. Even with such a short=20 value, many, many TCP sessions will be fine because the seq/ack numbers will not overlap (see Benson's post on that which=20 pointed out). A few will get corrupted. How is the ISP going to monitor/avoid that, or get told about it? -d > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 18:57 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: Hold-down pool >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Tuesday, March 15, 2011 8:11 AM > > To: draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: 'behave' <(behave@ietf.org)> > > Subject: [BEHAVE] CGN REQ: Hold-down pool > > > > Re-, > > > > An important missing requirement is the behaviour for the timeouted > > ports; I refer to this as hold down pool. These ports SHOULD NOT be > > assigned to new requesting users before the expiration of the hold > down > > timer. The purpose is to prevent users from receiving unwanted > traffic. >=20 > Agreed, that should be a requirement. >=20 > > The hold-down timer and size of the pool should be configurable by > the > > operator. >=20 > Can we make recommendations on the hold down timers for UDP, TCP, > and ICMP? >=20 > -d >=20 >=20 >=20 > > Cheers, > > Med > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Mar 16 08:39:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8263A69B2 for ; Wed, 16 Mar 2011 08:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.314 X-Spam-Level: X-Spam-Status: No, score=-110.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 jkRvs2Ym2bTS for ; Wed, 16 Mar 2011 08:39:20 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D93FC3A6991 for ; Wed, 16 Mar 2011 08:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2368; q=dns/txt; s=iport; t=1300290046; x=1301499646; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=cRixs3T8osSz5C97fvkxub63WNM1ZKXqkEoD9vsvZrQ=; b=gl3stPrHWsrz6Aw2N8Lng8SVnGRBJaL2dc9tK1hP6Xo8HvM2elndwh1C pawlDg6phJc0YsYfRdh0L0tFLXyxPh32cGUPGtyhjsWDV1AXgtUJ3eV2A huc+s39bhj+2qlfUkhVrLZPxtzM9pjeGM0MOMRJEmxqAsyq/jb2nCMvX5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAHJ2gE2tJV2c/2dsb2JhbACYVoFki1R3pE6cVYVjBIUv X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="226195800" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2011 15:40:46 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2GFejH4013029; Wed, 16 Mar 2011 15:40:45 GMT From: "Dan Wing" To: , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DAD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3DAD@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 08:40:44 -0700 Message-ID: <167301cbe3f0$83ef8600$8bce9200$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25wAGI9NwAAAm27EAAJS3UAAe38vwAA4UGsA= Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:39:21 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Wednesday, March 16, 2011 2:01 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE: [BEHAVE] CGN REQ: SPAM Protection >=20 > Re-, >=20 > Please see inline. >=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 19:16 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange-ftgroup.com > > [mailto:mohamed.boucadair@orange-ftgroup.com] > > Sent: Tuesday, March 15, 2011 11:08 AM > > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: behave@ietf.org > > Subject: RE : [BEHAVE] CGN REQ: SPAM Protection > > > > Re-, > > > > Port 25 is provided as an example. > > The functional requirement can be reworded to something like: "the > CGN > > SHOULD be able to block some ports. The ports to be prohibited MUST > be > > configurable." > > > > Please don"t forget the CGN we are talking about can be a DS-Lite > CGN: > > the CGN is the place to access the IPv4 packet. "Legacy" filters to > > prevent SPAM as deployed in operational networks are not able to > > inspect IPv4-in IPv6 packets; equivalent function is needed in the > CGN. >=20 > I don't see this being a CGN requirement. I assume you want these > ports blocked before they consume state in the CGN, which means they > are blocked in *front* of the CGN function. >=20 > Med: Exactly. >=20 > In the AFTR architecture, > it's somewhere between where the tunnel is unwrapped and the packets > are NATted. Is that "in" the CGN? >=20 > Med: It is an input to the NAT function of the CGN: "don't NAT when > internal source port is equal to X" ? When the *internal* (source port) is X? > Maybe Softwires should take on that requirment? Or are there > non-DS-Lite scenarios where this is really something that only > the CGN can do? >=20 > Med: I prefer to have this discussed in the CGN requirement. The CGN = I- > D should not be specific to given model (e.g., NAT444, DS-Lite, L2- > NAT). =3D -d From Francis.Dupont@fdupont.fr Wed Mar 16 08:40:08 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E7B3A6966 for ; Wed, 16 Mar 2011 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7rYyrWQAFCJ for ; Wed, 16 Mar 2011 08:40:08 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id D9C253A69BB for ; Wed, 16 Mar 2011 08:40:07 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GFfYm5083676; Wed, 16 Mar 2011 16:41:34 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161541.p2GFfYm5083676@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Wed, 16 Mar 2011 09:25:09 -0400. <4D80BA35.6070200@viagenie.ca> Date: Wed, 16 Mar 2011 16:41:34 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] [pcp] last CGN requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 15:40:09 -0000 In your previous mail you wrote: > What does MSL stand for? Sorry I was not in TCP mode. So would this be fine for UDP and ICMP also? => I see address pool so the value is for all mappings. Now if the question is whether UDP and ICMP could need longer I can't see how, so it is fine. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Mar 16 08:46:14 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E033A69BE for ; Wed, 16 Mar 2011 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxF17zloO0he for ; Wed, 16 Mar 2011 08:46:13 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 890603A6937 for ; Wed, 16 Mar 2011 08:46:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GFldwt084068; Wed, 16 Mar 2011 16:47:39 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161547.p2GFldwt084068@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Wed, 16 Mar 2011 09:49:04 -0400. <4D80BFD0.1060007@viagenie.ca> Date: Wed, 16 Mar 2011 16:47:39 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 15:46:14 -0000 In your previous mail you wrote: We need to figure out what the default values will be. Proposal: - TCP: 2*MSL - UDP: 0 seconds - ICMP: 0 seconds => this suggests to make a different between protocols, IMHO it is simpler to have one hold-down timing (of 120s). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Mar 16 09:02:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8DA3A6977 for ; Wed, 16 Mar 2011 09:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lija4rCIeppX for ; Wed, 16 Mar 2011 09:02:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 57D8F3A6937 for ; Wed, 16 Mar 2011 09:02:18 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GG3iI3085201; Wed, 16 Mar 2011 17:03:44 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161603.p2GG3iI3085201@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Wed, 16 Mar 2011 10:34:57 -0400. <4D80CA91.80607@viagenie.ca> Date: Wed, 16 Mar 2011 17:03:44 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:02:19 -0000 In your previous mail you wrote: On 2011-03-16 10:31, Francis Dupont wrote: > In your previous mail you wrote: > > Random port set can be handled by the CGN. > > => I have a concern about the term 'random set' because I am not sure > about its meaning (so if I missed the definition please send the > pointer to me). Useful to all: it corresponds to mechanism (2) in section 5. => fine, BTW the description should use 'When the "bin" is empty' as by convention a port is 'removed' from the "bin" before being used. Some extra comments: - it can be very good for the security (per flow port randomization) - it was I implemented in the ISC AFTR (following a customer request) - it is by design not really compatible with EIM (not a surprise: port randomization and EIM follow opposite goals). Of course the key point is the meaning of 'new outgoing connection'. Thanks Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Mar 16 09:05:00 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAE43A6977 for ; Wed, 16 Mar 2011 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYC99p4VKTmF for ; Wed, 16 Mar 2011 09:05:00 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 1404F3A6937 for ; Wed, 16 Mar 2011 09:04:59 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GG6PIF085449; Wed, 16 Mar 2011 17:06:26 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161606.p2GG6PIF085449@givry.fdupont.fr> From: Francis Dupont To: Lars Eggert In-reply-to: Your message of Wed, 16 Mar 2011 16:37:03 +0200. <58912627-4280-46DB-9DBF-7F241FA99528@nokia.com> Date: Wed, 16 Mar 2011 17:06:25 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:05:01 -0000 In your previous mail you wrote: What am I missing? => logging: the hold-down protects lookups in the log against clock skew. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Mar 16 09:15:57 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073E23A69E3 for ; Wed, 16 Mar 2011 09:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnEkDrhytUJq for ; Wed, 16 Mar 2011 09:15:56 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 07E2A3A69E0 for ; Wed, 16 Mar 2011 09:15:55 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GGHMaT086175; Wed, 16 Mar 2011 17:17:22 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161617.p2GGHMaT086175@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Wed, 16 Mar 2011 11:03:28 -0400. <4D80D140.2060407@viagenie.ca> Date: Wed, 16 Mar 2011 17:17:22 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:15:57 -0000 In your previous mail you wrote: Ok there seems to be consensus that there is a problem => I have a real question about who the problem is for. I don't believe users want extra mechanisms to track their activity, in particular I am afraid of the consequences of an IETF action decicated to reduce user privacy, or something which can give this feeling. So IMHO we should be very careful here. For instance active mechanisms should not be preferred without a good argument. Thanks Francis.Dupont@fdupont.fr From jmh@joelhalpern.com Wed Mar 16 09:23:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7F43A68FE for ; Wed, 16 Mar 2011 09:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, 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 VgxJY5ts2XoA for ; Wed, 16 Mar 2011 09:23:01 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 5E0153A68DE for ; Wed, 16 Mar 2011 09:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 534054300CC; Wed, 16 Mar 2011 09:24:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 7B6C84300EA; Wed, 16 Mar 2011 09:24:27 -0700 (PDT) Message-ID: <4D80E441.5020003@joelhalpern.com> Date: Wed, 16 Mar 2011 12:24:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <4D7FB517.3030708@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> <4D80D95D.2020802@joelhalpern.com> In-Reply-To: <4D80D95D.2020802@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:23:02 -0000 This note may have looked a little confused. The point is that as much as possible, we should treat firewall and NAT separately. The paradigmatic example is from another very similar thread, on NPT66. There it can be truly separate. It seems to me that even for a CGN NAT44, treating them as separate will work better. Yours, Joel On 3/16/2011 11:38 AM, Joel M. Halpern wrote: > The firweall function should not be conflated with the CGN function. > For NAT44, there is some inherent conflating due to the constraint > imposed by port rewriting / port acceptance issues. > With NPT66, there is no such port rewriting. As such, there is no need > to couple the two functions. The firewall may happen to be in the same > device as the NPT. It can be upstream or downstream of that, depending > upon where the operators wants to place it. > > Yours, > Joel > > On 3/16/2011 5:02 AM, mohamed.boucadair@orange-ftgroup.com wrote: >> Dear Joel, >> >> This is a filtering function which can be seen in the same level as >> the "filtering behavior" defined by BEHAVE WG in the past. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la >> part de Joel M. Halpern >> Envoy : mardi 15 mars 2011 19:51 >> Cc : behave@ietf.org >> Objet : Re: [BEHAVE] CGN REQ: SPAM Protection >> >> I would agree with dan. >> What you are describing is a firewalling or filtering function. While >> those are functions operators want, those are not the function of the >> CGN. Divide a problem a conquering the pieces serves us well. >> >> Yours, >> Joel >> >> On 3/15/2011 2:15 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: mohamed.boucadair@orange-ftgroup.com >>>> [mailto:mohamed.boucadair@orange-ftgroup.com] >>>> Sent: Tuesday, March 15, 2011 11:08 AM >>>> To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org >>>> Cc: behave@ietf.org >>>> Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >>>> >>>> Re-, >>>> >>>> Port 25 is provided as an example. >>>> The functional requirement can be reworded to something like: "the CGN >>>> SHOULD be able to block some ports. The ports to be prohibited MUST be >>>> configurable." >>>> >>>> Please don"t forget the CGN we are talking about can be a DS-Lite CGN: >>>> the CGN is the place to access the IPv4 packet. "Legacy" filters to >>>> prevent SPAM as deployed in operational networks are not able to >>>> inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN. >>> >>> I don't see this being a CGN requirement. I assume you want these >>> ports blocked before they consume state in the CGN, which means they >>> are blocked in *front* of the CGN function. In the AFTR architecture, >>> it's somewhere between where the tunnel is unwrapped and the packets >>> are NATted. Is that "in" the CGN? >>> >>> Maybe Softwires should take on that requirment? Or are there >>> non-DS-Lite scenarios where this is really something that only >>> the CGN can do? >>> >>> -d >>> >>> >>>> Cheers, >>>> Med >>>> >>>> ________________________________________ >>>> De : Dan Wing [dwing@cisco.com] >>>> Date d'envoi : mardi 15 mars 2011 18:53 >>>> : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- >>>> requirements@tools.ietf.org >>>> Cc : behave@ietf.org >>>> Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >>>> >>>>> -----Original Message----- >>>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>>> Behalf Of mohamed.boucadair@orange-ftgroup.com >>>>> Sent: Tuesday, March 15, 2011 7:56 AM >>>>> To: draft-ietf-behave-lsn-requirements@tools.ietf.org >>>>> Cc: 'behave'<(behave@ietf.org)> >>>>> Subject: [BEHAVE] CGN REQ: SPAM Protection >>>>> >>>>> Re-, >>>>> >>>>> An explicit requirement about the support of means to protect against >>>>> SPAM should be IMO added to the req list. For instance the default >>>>> behaviour would be the CGN block port 25 for SMTP. >>>> >>>> That is an operational policy of an ISP, not a CGN. >>>> >>>> Does IETF have any existing recommendation to block outbound TCP/25? >>>> If >>>> not, I don't believe we could create one in BEHAVE. >>>> >>>> -d >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 09:29:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8736D3A69AD for ; Wed, 16 Mar 2011 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 u0s39q5yCZAL for ; Wed, 16 Mar 2011 09:29:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 120AC3A69A6 for ; Wed, 16 Mar 2011 09:29:07 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C436C18C5E2; Wed, 16 Mar 2011 17:30:33 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AB85D4C068; Wed, 16 Mar 2011 17:30:33 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 16 Mar 2011 17:30:33 +0100 From: To: Francis Dupont , Simon Perreault Date: Wed, 16 Mar 2011 17:30:32 +0100 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: Acvj9aT8PbnuNXoiRKOmR/aPOG85+wAAXGMA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA408E@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 16 Mar 2011 11:03:28 -0400. <4D80D140.2060407@viagenie.ca> <201103161617.p2GGHMaT086175@givry.fdupont.fr> In-Reply-To: <201103161617.p2GGHMaT086175@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.160018 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:29:09 -0000 Francis, The user_hint we are talking about is similar to the source IPv4 address wh= en there is no NAT.=20 As described in http://tools.ietf.org/html/draft-boucadair-intarea-nat-reve= al-analysis-01#section-1: Observation: Today, servers use the source IPv4 address as an identifier to treat some incoming connections differently. Tomorrow, due to the introduction of CGNs (e.g., NAT44, NAT64), that address will be shared. In particular, when a server receives packets from the same source address. Because this address is shared, the server does not know which host is the sending host. Objective: The server should be able to sort out the packets by sending host. Requirement: The server must have extra information than the source IP address to differentiate the sending host. We call USER_HINT this information. o What is the USER_HINT? It must be unique to each user under the same address. It does not need to be globally unique. Of course, the combination of the (public) IPv4 source address and the identifier ends up being relatively unique. As unique as today's 32-bit IPv4 addresses which, today, can change when a user re- connects. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Francis Dupont Envoy=E9 : mercredi 16 mars 2011 17:17 =C0 : Simon Perreault Cc : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT In your previous mail you wrote: Ok there seems to be consensus that there is a problem =3D> I have a real question about who the problem is for. I don't believe users want extra mechanisms to track their activity, in particular I am afraid of the consequences of an IETF action decicated to reduce user privacy, or something which can give this feeling. So IMHO we should be very careful here. For instance active mechanisms should not be preferred without a good argument. Thanks Francis.Dupont@fdupont.fr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 09:37:39 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B993A69BF for ; Wed, 16 Mar 2011 09:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 77iiflrBWOX9 for ; Wed, 16 Mar 2011 09:37:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 618553A68EB for ; Wed, 16 Mar 2011 09:37:37 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9E5E122C6EF; Wed, 16 Mar 2011 17:39:03 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 85DA623805E; Wed, 16 Mar 2011 17:39:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 16 Mar 2011 17:39:03 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 17:39:01 +0100 Thread-Topic: [BEHAVE] CGN REQ: Shared address pool Thread-Index: Acvj657z44g3i9vkTGO0P3dO1+Qm0wADArHg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4099@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3FE1@PUEXCB1B.nanterre.francetelecom.fr> <4D80D1BE.6040408@viagenie.ca> In-Reply-To: <4D80D1BE.6040408@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.161524 Subject: Re: [BEHAVE] CGN REQ: Shared address pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:37:39 -0000 Re-, Because we want to avoid CGN implementations assuming that only contiguous = address pools can be configured as shared addresses. Address pools at our d= isposable may not be "aggregatable"... Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 16:06 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Shared address pool On 2011-03-16 10:49, mohamed.boucadair@orange-ftgroup.com wrote: > I don't know how this should be covered in the I-D, but I see a value to > have a section to elaborate on the configured address pool to be used in > the external interface of the CGN. In particular, the CGN should: > =20 > * support contiguous address pool > * support non-contiguous addresses Why? Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 09:40:27 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085A23A69DE for ; Wed, 16 Mar 2011 09:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, HELO_EQ_FR=0.35, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=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 t9eMpg6lu7H6 for ; Wed, 16 Mar 2011 09:40:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 1EF493A69D5 for ; Wed, 16 Mar 2011 09:40:26 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id A3F8C1B84E0; Wed, 16 Mar 2011 17:41:51 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 84109158077; Wed, 16 Mar 2011 17:41:51 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 16 Mar 2011 17:41:51 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 17:41:50 +0100 Thread-Topic: [BEHAVE] CGN REQ: NAT MIB/YANG Thread-Index: Acvj3Ow/LeguxQHSTvWROE1GnLaOEQAHBW/g Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA409B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B4A@PUEXCB1B.nanterre.francetelecom.fr> <127301cbe33a$251a9ae0$6f4fd0a0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CD5@PUEXCB1B.nanterre.francetelecom.fr> <4D80B912.5040702@viagenie.ca> In-Reply-To: <4D80B912.5040702@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.16.160018 Subject: Re: [BEHAVE] CGN REQ: NAT MIB/YANG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:40:27 -0000 =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 14:20 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: NAT MIB/YANG On 2011-03-16 02:50, mohamed.boucadair@orange-ftgroup.com wrote: > FWIW, we have looked at RFC4008 for a CGN. It seems inadequate for a > CGN -- it lacks ability to alarm if a user is reaching or has > exceeded things like their port quota. Also, walking that MIB would > take a considerable amount of time on a CGN, due to the table > design. >=20 > Med: Yes, I'm aware if this but there is no better reference to quote > (this is why I said "at least"). For sure, the modules need be > adapted to CGN context to cover a set of operational requirements. > There are various proprietary CGN MIB modules in the nature but there > is no standard one. BTW, YANG CGN modules may be needed to for those > using NETCONF. OK so I'm interpreting this as "yes for RFC4008, until we have something better to quote". Med: Yes.= From Francis.Dupont@fdupont.fr Wed Mar 16 09:58:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEFA3A69D8 for ; Wed, 16 Mar 2011 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KicsaSBXdKxK for ; Wed, 16 Mar 2011 09:58:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 818923A6941 for ; Wed, 16 Mar 2011 09:58:18 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2GGxiTU088857; Wed, 16 Mar 2011 17:59:44 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103161659.p2GGxiTU088857@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 16 Mar 2011 17:30:32 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA408E@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 17:59:44 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 16:58:19 -0000 In your previous mail you wrote: The user_hint we are talking about is similar to the source IPv4 address when there is no NAT. => I know but NATs are considered as security devices by some people and here you remove this capability. And the technical arguments are not enough, what matters is the feeling some people have. BTW we had already a similar issue with IPv6 addressing and technically the USER_HINT seems to be a HOST_HINT: this is bad because it would give an advantage to NAT444 over DS-Lite as NAT444 includes a first NAT44 level which "hides" the HOST and reveals only the USER. Another reason to be careful... Thanks Francis.Dupont@fdupont.fr PS: BTW is BEHAVE chartered to discuss about this, IMHO it is clearly in the INTAREA scope (and authors of the proposal share this opinion according to the name of the draft). Perhaps the best will be to wait for a resolution by INTAREA, i.e., jump far from this in place of into this. From rpenno@juniper.net Wed Mar 16 10:38:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3637D3A69FC for ; Wed, 16 Mar 2011 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 WOXRCcYoT3l2 for ; Wed, 16 Mar 2011 10:38:57 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0F0383A69F2 for ; Wed, 16 Mar 2011 10:38:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTYD2AJ8RRdSxZIOJvRKW2tChwrm8Xmpo@postini.com; Wed, 16 Mar 2011 10:40:23 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 10:37:08 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 16 Mar 2011 13:38:16 -0400 From: Reinaldo Penno To: "mohamed.boucadair@orange-ftgroup.com" , Simon Perreault Date: Wed, 16 Mar 2011 13:38:11 -0400 Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: AcvjHS5+0dmimUtYRfmRyjukLTEHFwACuZ0iAAA4U7AAAK3mWgAA6etwAAI7pF8AHaLVkAAUhv2M Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3D19@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'behave' <\(behave@ietf.org\)>" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 17:38:58 -0000 Thanks. This text is much better and clearer. Anybody without context will hit the ground running. On 3/16/11 12:58 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Re-, >=20 > The problem is that due to address sharing, users may experience service > degradation and troubles to access to some services because: >=20 > * Content Providers may rely on the source IP address as simple implicit > authentication > * Content providers rely on the source IP address to blacklist misbehavin= g > users > * infected users are redirected to dedicated URL based on there IP addres= s > * See=20 > http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05= for > an exhaustive list of issues. >=20 > To avoid all users sharing the same IP address be impacted, an ID in addi= tion > to the source IP address is needed to uniquely distinguish a user among t= hose > sharing the same IP address. In nat-reveal-analysis I-D, we wrote: >=20 > "The server must have extra information than the source > IP address to differentiate the sending host. We call USER_HINT this > information. >=20 > o What is the USER_HINT? It must be unique to each user under the > same address. It does not need to be globally unique. Of course, > the combination of the (public) IPv4 source address and the > identifier ends up being relatively unique. As unique as today's > 32-bit IPv4 addresses which, today, can change when a user re- > connects." >=20 >=20 > Hope the problem is more clear. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : Reinaldo Penno [mailto:rpenno@juniper.net] > Envoy=E9 : mardi 15 mars 2011 18:42 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault > Cc : 'behave' <(behave@ietf.org)>; > draft-ietf-behave-lsn-requirements@tools.ietf.org > Objet : Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT >=20 >=20 >=20 >=20 > On 3/15/11 9:47 AM, "mohamed.boucadair@orange-ftgroup.com" > wrote: >=20 >> Med: It benefits to the users, service providers and content providers: >> * a user won't be impacted by a misbehaving action of another user shari= ng >> the >> same IP address. See >>=20 http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-01#s= ec>> t >> ion-1 for more details. >=20 > I think the solution does not fit the problem. Can you elaborate on an > actual use case from the top? >=20 >> * a service provider won't receive calls to hot-lines (OPEX reduction) >=20 > It will not receive calls or it will receive calls but will have more > information to go with them? >=20 > The identify of the user can be determined by the ISP through NAT logs ba= sed > on public source IP, port alone. Any action by the ISP will need to be do= ne > on the private side anyway where there is a 'stable' IP address. >=20 > This seems another incarnation of the 'log' problem. >=20 >> * content providers: service experience. >=20 > Service experience to the content provider or the subscriber? Can you > elaborate in a little more detail how subscribers will benefit from this? >=20 > BTW, I'm not really opposed to this at this point to this but it is not > clear to me what exactly we are trying to solve and for which purpose. >=20 > "1.1. Problem to Be Solved >=20 > Observation: Today, servers use the source IPv4 address as an > identifier to treat some incoming connections differently." >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From rpenno@juniper.net Wed Mar 16 10:56:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5F33A6A36 for ; Wed, 16 Mar 2011 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 oHRgSqalWMIL for ; Wed, 16 Mar 2011 10:56:03 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 12A873A6A4A for ; Wed, 16 Mar 2011 10:56:01 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTYD6BwH2SGP0YXOlPiLhhQObN1pYTuWj@postini.com; Wed, 16 Mar 2011 10:57:30 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 10:54:12 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 16 Mar 2011 13:55:20 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 13:55:18 -0400 Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: Acvj4PM90m9iyf7jTl2qyUAgyeuB6gAIlxD4 Message-ID: In-Reply-To: <4D80BFD0.1060007@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 17:56:04 -0000 If the hold-down for TCP is 120 seconds at a rate of, say, 250k ports per second, you will have on average 250K*120 seconds =3D 30M ports unavailable until the next 120 seconds window. 30M ports is roughly equivalent to 500 public addresses. If the rate goes up to 1M ports per second...well you get the picture. For ISPs trying to save address and stay in business it becomes quite a burden. Then there is an added Req to not use a pool in certain situations - pool hold time. Now an ISP needs to have 3x the number of public addresses. On 3/16/11 6:49 AM, "Simon Perreault" wrote: > On 2011-03-15 11:10, mohamed.boucadair@orange-ftgroup.com wrote: >> An important missing requirement is the behaviour for the timeouted >> ports; I refer to this as hold down pool. These ports SHOULD NOT be >> assigned to new requesting users before the expiration of the hold >> down timer. The purpose is to prevent users from receiving unwanted >> traffic. >>=20 >> The hold-down timer and size of the pool should be configurable by >> the operator. >=20 > Ok it seems we have consensus to add this. >=20 > We need to figure out what the default values will be. >=20 > Proposal: > - TCP: 2*MSL > - UDP: 0 seconds > - ICMP: 0 seconds >=20 > For UDP and ICMP, there is no point in adding to the normal mapping > expiration lifetime. When the mapping expires it already means that > there was no traffic on it for the last X seconds. >=20 > Simon From dwing@cisco.com Wed Mar 16 12:32:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0021E3A6974 for ; Wed, 16 Mar 2011 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.336 X-Spam-Level: X-Spam-Status: No, score=-110.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 R0l4X1S4oJ+t for ; Wed, 16 Mar 2011 12:32:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B96C73A69FF for ; Wed, 16 Mar 2011 12:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3169; q=dns/txt; s=iport; t=1300304061; x=1301513661; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=M9jOet8LSF9fA7wolhSmpQKJsdIc80hWuk2ueySIKP4=; b=WHcd7Kzt2n7VqHxSXdOHjzfcwRtIDJvT+dA25EiJ6nl90FFhz1EUQ/wK 8ZNvJac+DQ0XHDch5JKnm5I/ZhfjsYVvESOcp8upHDzjMnken7K/E8q7D HB6zIFonqGoUMPTU86/N/L9uCrvnBYvDI7fnqSiut/eVIwtzWvV3zlt4Z U=; X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="226284071" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2011 19:34:19 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJYIZA030706; Wed, 16 Mar 2011 19:34:19 GMT From: "Dan Wing" To: , References: Your message of Wed, 16 Mar 2011 07:16:42 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <201103161431.p2GEVqua078968@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3FCC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3FCC@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 16 Mar 2011 12:34:19 -0700 Message-ID: <017a01cbe411$257172c0$70545840$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvj5ufE7eIX9/3+Se2nR9ztiTvhmAAABYcAAApyKoA= Content-language: en-us Cc: behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, 'Benson Schliesser' Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 19:32:56 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Wednesday, March 16, 2011 7:38 AM > To: Francis.Dupont@fdupont.fr > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > requirements@tools.ietf.org; Benson Schliesser > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 > Hi Francis, >=20 > By "random port set", I meant: >=20 > * a set of ports which are randomly generated when a new outbound > packet is received by the CGN > * the port set is not contiguous > * the port set is not fixe > * for subsequent packet requiring a new port, a port from the pre- > allocated random port set is used > * when all the ports in the port set are in-use, a new random port set > is generated by the CGN, etc until reaching a quota. >=20 > We can find a better name for this. I described a continuum from completely random to completely fixed at: http://www.ietf.org/mail-archive/web/behave/current/msg09182.html which said: 1. for every outgoing connection, create one mapping. 2. for an outgoing connection, create a "bin" of several mappings using random public ports. Subsequent outgoing connections will use ports from the "bin". When the "bin" is full, a new connection causes a new bin to be created. A bin is smaller or equal to the user's maximum port limit. 3. Same as (2), but the ports allocated to a "bin" are consecutive public ports. Perhaps that is a good starting point. Or perhaps this is better: 1. for a new outgoing flow, choose a random port and create a new mapping. There is a limit on the maximum number of ports. 2. for a new outgoing flow, choose several random ports and create a "bin" of those ports. This outgoing flow is assigned one of those ports. Subsequent outgoing flows will be assigned a port from the "bin". When the "bin" is full, a new flow causes this process to be repeated (i.e., a new bin is created). A bin is smaller or equal to the user's maximum port limit. 3. Same as (2), but the ports allocated to a "bin" are consecutive public ports. 4. Same as (3), but only one "bin" is allocated. -d > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Envoy=E9 : mercredi 16 mars 2011 15:32 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : Benson Schliesser; draft-ietf-behave-lsn- > requirements@tools.ietf.org; 'behave' <(behave@ietf.org)> > Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 > In your previous mail you wrote: >=20 > Random port set can be handled by the CGN. >=20 > =3D> I have a concern about the term 'random set' because I am not = sure > about its meaning (so if I missed the definition please send the > pointer to me). >=20 > Regards >=20 > Francis.Dupont@fdupont.fr > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Mar 16 12:48:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8604C3A6AA0 for ; Wed, 16 Mar 2011 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 UOrN3orj65yS for ; Wed, 16 Mar 2011 12:48:52 -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 640433A6A84 for ; Wed, 16 Mar 2011 12:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2428; q=dns/txt; s=iport; t=1300305019; x=1301514619; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=q25toCPRMEWwTPRxzkvF2BRYzkrcXnhCf8aCMAF3YII=; b=LUJ+v+LzlBz9hHGU9wmwQSFrTr0ye/ajVdMMcrVwc4gpY66gmnd+/gIF ymGrdU/bah/S9kskS1Dr+1fY8MeUqS/9pEnrt5dEeT/gDfjhnOG1vgv8e itjtj9yVzc1zjRSLb5pjadOELfxZ5cb2Sn4mv/0FVIMIkJT7t7D6yr9B7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAAuxgE2tJXG9/2dsb2JhbACYV4Fki1F3pXScWIJ/gmQEhS8 X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="278784215" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2011 19:50:18 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJoILm016922; Wed, 16 Mar 2011 19:50:18 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> <201103161611.21765.remi.denis-courmont@nokia.com> In-Reply-To: <201103161611.21765.remi.denis-courmont@nokia.com> Date: Wed, 16 Mar 2011 12:50:18 -0700 Message-ID: <019901cbe413$61302d90$239088b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvj5A7ECWvLNYxWTLeEIxWrdGgAVAALypAA Content-language: en-us Cc: mohamed.boucadair@orange-ftgroup.com, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 19:48:56 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of R=E9mi Denis-Courmont > Sent: Wednesday, March 16, 2011 7:11 AM > To: behave@ietf.org > Cc: ext mohamed.boucadair@orange-ftgroup.com; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is > reached (ICMP notification) >=20 > On Wednesday 16 March 2011 11:28:23 ext mohamed.boucadair@orange- > ftgroup.com, > you wrote: > > Dear authors, > > > > The requirement I-D needs to specify the behaviour of the CGN when > there > > are no available ports or when the per-subscriber quota is reached. > > > > The requirement can elaborate on the behaviour of the CGN such as = the > > following (only as example): > > > > If a (transport) protocol-specific state limit is configured or when > there > > is no available free port, no binding for in-excess traffic must be > > instantiated in the CGN; in addition: > > > > * appropriate log events should be recorded > > * ICMP message should be sent back to the requesting client (e.g., > ICMP > > messages type 3 code 13) >=20 > There's two situations where a user can run out of port. Either (s)he > is evil > and trying to mount a denial of service, or it legitimately requires a > lot of > concurrent flows toward the same remote IP address. >=20 > If the user is evil, I would rather not send an ICMP message at all. >=20 > If the user is not evil, I would rather drop the packet and cross my > fingers > that one port will be freed soon enough that upper-layer (transport or > app) > retransmits will succeed in getting a port allocated. I believe > applications > will cope better with that, than with ICMP errors >=20 > Think of the stereotypical case of a we browser establishing a LOT of > HTTP > connections to a server while viewing several pages with lots of = images > and > AJAX and what not. Waiting for retransmit will slow down the browser. > Sending > ICMP errors (or TCP resets) will cause user-visible failures on the > other hand. So you are saying you disagree with http://tools.ietf.org/html/rfc5508#section-6 -d > -- > R=E9mi Denis-Courmont > http://www.remlab.net/ > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Mar 16 12:58:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED3D3A6A39 for ; Wed, 16 Mar 2011 12:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 GvTgSbyCdcZk for ; Wed, 16 Mar 2011 12:58:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 68C4F3A6A5B for ; Wed, 16 Mar 2011 12:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2357; q=dns/txt; s=iport; t=1300305567; x=1301515167; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=0Tk1OMWj+GojxzLG9QhkMlIkT8bROPg7/ztjMWXrATo=; b=OK3aapr1ijOW08UJtdiJZKk8DLvFsOIpEfGnijTAT+B2hr38Zxlg74MH YARsTT1DrquIBwubXdhooH0qPWfq1Y6SODXDWMA6LlvOwbOQUunuRsKTp eEWU81GiIUITXj8zGV7siJV41MCG0f9b/cJwLC9Eo8FcarfH2V6PZxNC+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAAOqygE2Q/khMgWdsb2JhbACYV4Fki1EUAQEWJiWle5xWhWMEhS8 X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="22005292" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 16 Mar 2011 19:59:26 +0000 Received: from dwingWS ([10.32.240.196]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2GJxPYS015460; Wed, 16 Mar 2011 19:59:25 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Simon Perreault'" , References: <4D80BFD0.1060007@viagenie.ca> In-Reply-To: Date: Wed, 16 Mar 2011 12:59:25 -0700 Message-ID: <01e001cbe414$a790bab0$f6b23010$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvj4PM90m9iyf7jTl2qyUAgyeuB6gAIlxD4AAREr/A= Content-language: en-us Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 19:58:04 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Wednesday, March 16, 2011 10:55 AM > To: Simon Perreault; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: Hold-down pool > > If the hold-down for TCP is 120 seconds at a rate of, say, 250k ports > per > second, you will have on average 250K*120 seconds = 30M ports > unavailable > until the next 120 seconds window. > > 30M ports is roughly equivalent to 500 public addresses. > > If the rate goes up to 1M ports per second...well you get the picture. > For > ISPs trying to save address and stay in business it becomes quite a > burden. > > Then there is an added Req to not use a pool in certain situations - > pool > hold time. > > Now an ISP needs to have 3x the number of public addresses. And then double that to meet the current text for the cold-standby requirement. The incentives to do the wrong thing are in the wrong place; the ISP will choose smaller values (to conserve IPv4 addresses) and harm user sessions. We need ways to align these goals, as much as possible. Same problem occurs with stateful NAT64, of course. -d > > On 3/16/11 6:49 AM, "Simon Perreault" > wrote: > > > On 2011-03-15 11:10, mohamed.boucadair@orange-ftgroup.com wrote: > >> An important missing requirement is the behaviour for the timeouted > >> ports; I refer to this as hold down pool. These ports SHOULD NOT be > >> assigned to new requesting users before the expiration of the hold > >> down timer. The purpose is to prevent users from receiving unwanted > >> traffic. > >> > >> The hold-down timer and size of the pool should be configurable by > >> the operator. > > > > Ok it seems we have consensus to add this. > > > > We need to figure out what the default values will be. > > > > Proposal: > > - TCP: 2*MSL > > - UDP: 0 seconds > > - ICMP: 0 seconds > > > > For UDP and ICMP, there is no point in adding to the normal mapping > > expiration lifetime. When the mapping expires it already means that > > there was no traffic on it for the last X seconds. > > > > Simon > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Wed Mar 16 15:23:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C3B3A6A78 for ; Wed, 16 Mar 2011 15:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 sESHhW5D6p0l for ; Wed, 16 Mar 2011 15:23:22 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 119BE3A6974 for ; Wed, 16 Mar 2011 15:23:21 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Mar 2011 15:24:48 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 16 Mar 2011 15:24:48 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.245]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Wed, 16 Mar 2011 15:24:48 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AcvkKCP8/Ck7X6QaQK+yOCQk4jNnVQ== Date: Wed, 16 Mar 2011 22:24:47 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-v4v6-bih@tools.ietf.org" Subject: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 16 Mar 2011 22:23:23 -0000 Our charter milestone is: Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only applic= ations to access IPv6-only servers (std) This email begins a Working Group Last Call on draft-ietf-behave-v4v6-bih-0= 3.txt to close on March 30. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Friday, March 11, 2011 2:30 AM > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-03.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. >=20 >=20 > Title : Dual Stack Hosts Using "Bump-in-the-Host" (BIH) > Author(s) : B. Huang, et al. > Filename : draft-ietf-behave-v4v6-bih-03.txt > Pages : 26 > Date : 2011-03-11 >=20 > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation > mechanism that allows a class of IPv4-only applications that work through > NATs to communicate with IPv6-only peers. The host on which applications > are running may be connected to IPv6-only or dual-stack access networks. > BIH hides IPv6 and makes the IPv4-only applications think they are talkin= g > with IPv4 peers by local synthesis of IPv4 addresses. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. From rpenno@juniper.net Wed Mar 16 15:37:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E2D3A6A1F for ; Wed, 16 Mar 2011 15:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 KDr9khe0vRGk for ; Wed, 16 Mar 2011 15:37:28 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 785C83A6974 for ; Wed, 16 Mar 2011 15:37:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTYE7/KngAviQBrRHFDSWt7B0eUfGln3K@postini.com; Wed, 16 Mar 2011 15:38:55 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 15:34:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 16 Mar 2011 18:35:43 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Wed, 16 Mar 2011 18:35:38 -0400 Thread-Topic: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) Thread-Index: Acvj5xa0IzngK4JUSWilLEZnnr6kKQAQ2JMb Message-ID: In-Reply-To: <4D80CA14.9040808@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 22:37:29 -0000 Agreed. I understand per Dan's email that there is some history on this ( http://tools.ietf.org/html/rfc5508#section-6), but I always wondered in the original RFC people took into account 'evil' users, applications coping wit= h that, flooding users that have quotas with ICMP messages, etc. On 3/16/11 7:32 AM, "Simon Perreault" wrote: > On 2011-03-16 10:11, R=E9mi Denis-Courmont wrote: >> If the user is not evil, I would rather drop the packet and cross my fin= gers >> that one port will be freed soon enough that upper-layer (transport or a= pp) >> retransmits will succeed in getting a port allocated. I believe applicat= ions >> will cope better with that, than with ICMP errors >=20 > Agreed. >=20 > This is very similar to what happens when a normal router exceeds its > capacity: it drops the packet. This is congestion. TCP is built on the > assumption that packet loss equals congestion. We should not interfere > with that. >=20 > I think that argument would be strong enough to warrant the contrary: a > CGN MUST NOT send an ICMP message when it has no ports left. >=20 > Simon From dwing@cisco.com Wed Mar 16 18:36:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A709A3A69EC for ; Wed, 16 Mar 2011 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.346 X-Spam-Level: X-Spam-Status: No, score=-110.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 Hr48Kv5PbzKl for ; Wed, 16 Mar 2011 18:36:26 -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 A5E153A67EE for ; Wed, 16 Mar 2011 18:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1933; q=dns/txt; s=iport; t=1300325874; x=1301535474; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=s5S6SdkWWgUyEwYY6x4/gjeF5F73LrLzORKYIB/vVJ0=; b=PoXiiP1K6azcTxj4oOc0q8J+vjKFzcZhNERXtQv2jbX8hNit0dnYzm08 CPcDHNWP+u0up0RiBXlTlrzqZ2KtBi0+Ty+YYGdyExMoV67C0YO2j+irE MqhEVq93OnH/X1OkDvtJ+JhZ8EU0QtGuTn+PxzL0vXXSzYKc3YpsarfPk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAF4CgU2tJXG8/2dsb2JhbACYG4Fki1F3pg+cVIJ/D4JVBIUv X-IronPort-AV: E=Sophos;i="4.63,196,1299456000"; d="scan'208";a="415206309" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2011 01:37:53 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2H1bqis025533; Thu, 17 Mar 2011 01:37:53 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Simon Perreault'" , References: <4D80CA14.9040808@viagenie.ca> In-Reply-To: Date: Wed, 16 Mar 2011 18:37:52 -0700 Message-ID: <042301cbe443$eefd98d0$ccf8ca70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvj5xa0IzngK4JUSWilLEZnnr6kKQAQ2JMbAAXy13A= Content-language: en-us Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 01:36:28 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Wednesday, March 16, 2011 3:36 PM > To: Simon Perreault; behave@ietf.org > Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is > reached (ICMP notification) >=20 > Agreed. I understand per Dan's email that there is some history on = this > ( > http://tools.ietf.org/html/rfc5508#section-6), but I always wondered = in > the > original RFC people took into account 'evil' users, applications = coping > with that, flooding users that have quotas with ICMP messages, etc. ICMP code 13 is supposed to be a soft error, which has no effect on TCP, http://tools.ietf.org/html/rfc5461#section-2.2 However, at the moment I cannot find where code 13 was defined as a soft error. -d >=20 >=20 >=20 >=20 >=20 > On 3/16/11 7:32 AM, "Simon Perreault" > wrote: >=20 > > On 2011-03-16 10:11, R=E9mi Denis-Courmont wrote: > >> If the user is not evil, I would rather drop the packet and cross = my > fingers > >> that one port will be freed soon enough that upper-layer (transport > or app) > >> retransmits will succeed in getting a port allocated. I believe > applications > >> will cope better with that, than with ICMP errors > > > > Agreed. > > > > This is very similar to what happens when a normal router exceeds = its > > capacity: it drops the packet. This is congestion. TCP is built on > the > > assumption that packet loss equals congestion. We should not > interfere > > with that. > > > > I think that argument would be strong enough to warrant the = contrary: > a > > CGN MUST NOT send an ICMP message when it has no ports left. > > > > Simon >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Wed Mar 16 23:08:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E9E3A67AE for ; Wed, 16 Mar 2011 23:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk49nNzRjTuV for ; Wed, 16 Mar 2011 23:08:35 -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 DBB823A67AA for ; Wed, 16 Mar 2011 23:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1034; q=dns/txt; s=iport; t=1300342203; x=1301551803; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=tUq6t4iyq70q/x9Ofc3tfyxtj/S3Z0eNnKXDp8F1kX0=; b=LdvceS6r7I2F82Wl54uVMDiWK6932192J0gh/HZaQq92INLonofdgFvZ E6R0zvjnmIcc/bDxg9jb7T5NQHi+M3lPXHIdWQP7pphBAKKPcD8YD6CDI SHILugHm/I9HN4MCrJyM3UZE2adtIyactKz+3E5hnTLFvRN8NPUUnC51B Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANJCgU2tJV2Z/2dsb2JhbAClUXenB5w6gn+CZASMXoNT X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="415258533" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2011 06:10:02 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2H6A2Nb027446; Thu, 17 Mar 2011 06:10:02 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 23:10:02 -0700 Received: from 10.65.83.57 ([10.65.83.57]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Mar 2011 06:10:00 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Mar 2011 02:11:09 -0400 From: ssenthil To: Francis Dupont , Message-ID: Thread-Topic: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) Thread-Index: AcvkahuL/hZ0MbhBsESjMXl3ilrlpg== In-Reply-To: <201103161501.p2GF13EV081008@givry.fdupont.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Mar 2011 06:10:02.0287 (UTC) FILETIME=[F3C823F0:01CBE469] Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 06:08:36 -0000 On 3/16/11 11:01 AM, "Francis Dupont" wrote: > > In your previous mail you wrote: > > in addition: > > * ICMP message should be sent back to the requesting client (e.g., > ICMP messages type 3 code 13) > > => not so clear: usually it is never a good idea to send an ICMP and > in this case 3/13 was designed for a permanent condition. Can you point me to some documentation on code 13 being a permanent condition (hard error)? In the past there were a lot of discussions surrounding code 13 (related to rfc5508) and I don't believe that code 13 was spelled out as a hard error. > So IMHO a SHOULD is not the right thing, I prefer a MAY or > alternatively I suggest to implement the MAY switch of RFC 1812 > to disable 3/13 sending and to make it 'disable' by default... > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 23:19:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687EB3A67B0 for ; Wed, 16 Mar 2011 23:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 ZU55B9lfp-wj for ; Wed, 16 Mar 2011 23:19:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 3F0073A67AA for ; Wed, 16 Mar 2011 23:19:03 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7BBC82DC4AD; Thu, 17 Mar 2011 07:20:29 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5EE894C021; Thu, 17 Mar 2011 07:20:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 17 Mar 2011 07:20:29 +0100 From: To: Dan Wing , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Thu, 17 Mar 2011 07:20:28 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: AcvjIRCFoetwmRq4RTOPj/HqPpX25wAGI9NwAAAm27EAAJS3UAAe38vwAA4UGsAAHq0cwA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4128@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DAD@PUEXCB1B.nanterre.francetelecom.fr> <167301cbe3f0$83ef8600$8bce9200$@com> In-Reply-To: <167301cbe3f0$83ef8600$8bce9200$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 06:19:04 -0000 Hi Dan, Please see inline. =20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mercredi 16 mars 2011 16:41 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: SPAM Protection > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Wednesday, March 16, 2011 2:01 AM > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc: behave@ietf.org > Subject: RE: [BEHAVE] CGN REQ: SPAM Protection >=20 > Re-, >=20 > Please see inline. >=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 15 mars 2011 19:16 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange-ftgroup.com > > [mailto:mohamed.boucadair@orange-ftgroup.com] > > Sent: Tuesday, March 15, 2011 11:08 AM > > To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org > > Cc: behave@ietf.org > > Subject: RE : [BEHAVE] CGN REQ: SPAM Protection > > > > Re-, > > > > Port 25 is provided as an example. > > The functional requirement can be reworded to something like: "the > CGN > > SHOULD be able to block some ports. The ports to be prohibited MUST > be > > configurable." > > > > Please don"t forget the CGN we are talking about can be a DS-Lite > CGN: > > the CGN is the place to access the IPv4 packet. "Legacy" filters to > > prevent SPAM as deployed in operational networks are not able to > > inspect IPv4-in IPv6 packets; equivalent function is needed in the > CGN. >=20 > I don't see this being a CGN requirement. I assume you want these > ports blocked before they consume state in the CGN, which means they > are blocked in *front* of the CGN function. >=20 > Med: Exactly. >=20 > In the AFTR architecture, > it's somewhere between where the tunnel is unwrapped and the packets > are NATted. Is that "in" the CGN? >=20 > Med: It is an input to the NAT function of the CGN: "don't NAT when > internal source port is equal to X" ? When the *internal* (source port) is X? Med: I used "internal" to precise this rule is to be enforced on packets re= ceived on the customer-facing interface. > Maybe Softwires should take on that requirment? Or are there > non-DS-Lite scenarios where this is really something that only > the CGN can do? >=20 > Med: I prefer to have this discussed in the CGN requirement. The CGN I- > D should not be specific to given model (e.g., NAT444, DS-Lite, L2- > NAT). =3D -d From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 23:26:33 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1873A69D6 for ; Wed, 16 Mar 2011 23:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 DQEO2fjJ5Oft for ; Wed, 16 Mar 2011 23:26:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id CAEF93A69CD for ; Wed, 16 Mar 2011 23:26:31 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 708BA2AC6A9; Thu, 17 Mar 2011 07:27:57 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5A381C8068; Thu, 17 Mar 2011 07:27:57 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 17 Mar 2011 07:27:57 +0100 From: To: "Joel M. Halpern" Date: Thu, 17 Mar 2011 07:27:56 +0100 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: Acvj9qHLGN4bEGCPSNGoVKuCEKDHTgAdNQDg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4129@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B3C@PUEXCB1B.nanterre.francetelecom.fr>, <127201cbe339$d357aa90$7a06ffb0$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC1@PUEXCB1B.nanterre.francetelecom.fr> <12b201cbe33d$03060ef0$09122cd0$@com> <4D7FB517.3030708@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F33C4DBA3DB0@PUEXCB1B.nanterre.francetelecom.fr> <4D80D95D.2020802@joelhalpern.com> <4D80E441.5020003@joelhalpern.com> In-Reply-To: <4D80E441.5020003@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 06:26:33 -0000 Dear Joel, I see your point.=20 The issue I have is that firewalls are defined no where...and in the meanti= me I need a function which filters the internal ports before enforcing the = NAT operation. I package this as a CGN function. FWIW, we are not requesting for specific NAT mapping filtering behaviour si= nce we are recommending the EIM/EIF; which is advocating for "transparent" = NAT. Cheers, Med =20 -----Message d'origine----- De : Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Envoy=E9 : mercredi 16 mars 2011 17:25 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: SPAM Protection This note may have looked a little confused. The point is that as much as possible, we should treat firewall and NAT=20 separately. The paradigmatic example is from another very similar thread, on NPT66.=20 There it can be truly separate. It seems to me that even for a CGN NAT44, treating them as separate will=20 work better. Yours, Joel On 3/16/2011 11:38 AM, Joel M. Halpern wrote: > The firweall function should not be conflated with the CGN function. > For NAT44, there is some inherent conflating due to the constraint > imposed by port rewriting / port acceptance issues. > With NPT66, there is no such port rewriting. As such, there is no need > to couple the two functions. The firewall may happen to be in the same > device as the NPT. It can be upstream or downstream of that, depending > upon where the operators wants to place it. > > Yours, > Joel > > On 3/16/2011 5:02 AM, mohamed.boucadair@orange-ftgroup.com wrote: >> Dear Joel, >> >> This is a filtering function which can be seen in the same level as >> the "filtering behavior" defined by BEHAVE WG in the past. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la >> part de Joel M. Halpern >> Envoy=E9 : mardi 15 mars 2011 19:51 >> Cc : behave@ietf.org >> Objet : Re: [BEHAVE] CGN REQ: SPAM Protection >> >> I would agree with dan. >> What you are describing is a firewalling or filtering function. While >> those are functions operators want, those are not the function of the >> CGN. Divide a problem a conquering the pieces serves us well. >> >> Yours, >> Joel >> >> On 3/15/2011 2:15 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: mohamed.boucadair@orange-ftgroup.com >>>> [mailto:mohamed.boucadair@orange-ftgroup.com] >>>> Sent: Tuesday, March 15, 2011 11:08 AM >>>> To: Dan Wing; draft-ietf-behave-lsn-requirements@tools.ietf.org >>>> Cc: behave@ietf.org >>>> Subject: RE : [BEHAVE] CGN REQ: SPAM Protection >>>> >>>> Re-, >>>> >>>> Port 25 is provided as an example. >>>> The functional requirement can be reworded to something like: "the CGN >>>> SHOULD be able to block some ports. The ports to be prohibited MUST be >>>> configurable." >>>> >>>> Please don"t forget the CGN we are talking about can be a DS-Lite CGN: >>>> the CGN is the place to access the IPv4 packet. "Legacy" filters to >>>> prevent SPAM as deployed in operational networks are not able to >>>> inspect IPv4-in IPv6 packets; equivalent function is needed in the CGN= . >>> >>> I don't see this being a CGN requirement. I assume you want these >>> ports blocked before they consume state in the CGN, which means they >>> are blocked in *front* of the CGN function. In the AFTR architecture, >>> it's somewhere between where the tunnel is unwrapped and the packets >>> are NATted. Is that "in" the CGN? >>> >>> Maybe Softwires should take on that requirment? Or are there >>> non-DS-Lite scenarios where this is really something that only >>> the CGN can do? >>> >>> -d >>> >>> >>>> Cheers, >>>> Med >>>> >>>> ________________________________________ >>>> De : Dan Wing [dwing@cisco.com] >>>> Date d'envoi : mardi 15 mars 2011 18:53 >>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn- >>>> requirements@tools.ietf.org >>>> Cc : behave@ietf.org >>>> Objet : RE: [BEHAVE] CGN REQ: SPAM Protection >>>> >>>>> -----Original Message----- >>>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >>>>> Behalf Of mohamed.boucadair@orange-ftgroup.com >>>>> Sent: Tuesday, March 15, 2011 7:56 AM >>>>> To: draft-ietf-behave-lsn-requirements@tools.ietf.org >>>>> Cc: 'behave'<(behave@ietf.org)> >>>>> Subject: [BEHAVE] CGN REQ: SPAM Protection >>>>> >>>>> Re-, >>>>> >>>>> An explicit requirement about the support of means to protect against >>>>> SPAM should be IMO added to the req list. For instance the default >>>>> behaviour would be the CGN block port 25 for SMTP. >>>> >>>> That is an operational policy of an ISP, not a CGN. >>>> >>>> Does IETF have any existing recommendation to block outbound TCP/25? >>>> If >>>> not, I don't believe we could create one in BEHAVE. >>>> >>>> -d >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 23:34:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22D83A67CC for ; Wed, 16 Mar 2011 23:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 q31jEJNI6By0 for ; Wed, 16 Mar 2011 23:34:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id E64793A67AA for ; Wed, 16 Mar 2011 23:34:07 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 84B6F190617; Thu, 17 Mar 2011 07:35:34 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6CD01384061; Thu, 17 Mar 2011 07:35:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 17 Mar 2011 07:35:31 +0100 From: To: Simon Perreault Date: Thu, 17 Mar 2011 07:35:29 +0100 Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: Acvj7rkQtO5dIkZITBO5xpPu5AZROQAflBdQ Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA412A@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <4D80BFD0.1060007@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3FC7@PUEXCB1B.nanterre.francetelecom.fr> <4D80D6F7.40407@viagenie.ca> In-Reply-To: <4D80D6F7.40407@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 06:34:13 -0000 Dear Simon The rationale behind the pool is to prevent all/majority of your ports be u= nusable because tagged as hold-down port. We need a means to control the am= ount of port to be put in that pool; hence the need to configure a pool siz= e. As for the UDP timers, I agree with Francis to have one value for TCP/UDP. = I have no magic value so far. Cheers, Med=20 -----Message d'origine----- De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Envoy=E9 : mercredi 16 mars 2011 16:28 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Hold-down pool On 2011-03-16 10:31, mohamed.boucadair@orange-ftgroup.com wrote: > For the UDP don't forget the case of incoming connections (e.g., SIP > INVITE message is received just after a PCP-instructed mapping > expired.). We need a safety timer for UDP also. Hmmm... I was assuming that the CGN had inbound mapping refresh (REQ-6a in RFC4787). I guess the same reasoning equally applies to ICMP. What do you suggest instead of zero? > BTW, in addition to the timers, we need to consider also the pool > size. I don't quite understand the "pool" concept. What happens when the number of ports in hold-down is larger than the pool size? Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Wed Mar 16 23:49:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B053A69D6 for ; Wed, 16 Mar 2011 23:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.126 X-Spam-Level: X-Spam-Status: No, score=-3.126 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 EyvA11eNzE+4 for ; Wed, 16 Mar 2011 23:49:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 3C6203A67AE for ; Wed, 16 Mar 2011 23:49:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7642B2DC3F2; Thu, 17 Mar 2011 07:51:12 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5814135C058; Thu, 17 Mar 2011 07:51:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 17 Mar 2011 07:51:12 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Thu, 17 Mar 2011 07:51:11 +0100 Thread-Topic: CGN REQ: Planned maintenance operations Thread-Index: Acvkb7NnqI41qa1YT/+x8B4NneC3uw== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA412E@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Cc: "behave@ietf.org" Subject: [BEHAVE] CGN REQ: Planned maintenance operations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 06:49:46 -0000 Dear all, =20 CGN is a stateful function which (to be) deployed in providers networks. Th= e introduction of this function into operational networks induces constrain= ts on the service availability and its robustness. =20 Because of the stateful nature of this function and in order to meet some o= perational requirements such as the ability to execute planned maintenance = operations (e.g., "periodic" reboot, add a new interface, a new service car= d, etc.) without service interruption and ideally without the troubles must= not be perceived by customers. The CGN must be compliant with such requirement (i.e., support graceful shu= tdown, graceful restart). (Planned maintenance operation can be seen as predictable failure events) Cheers, Med From mohamed.boucadair@orange-ftgroup.com Thu Mar 17 00:04:31 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3CA3A67DB for ; Thu, 17 Mar 2011 00:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 zFXXGc8wPWAb for ; Thu, 17 Mar 2011 00:04:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 5D91C3A67AE for ; Thu, 17 Mar 2011 00:04:30 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7230E18C23C; Thu, 17 Mar 2011 08:05:57 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 571BA238041; Thu, 17 Mar 2011 08:05:57 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 17 Mar 2011 08:05:57 +0100 From: To: "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Thu, 17 Mar 2011 08:05:55 +0100 Thread-Topic: CGN REQ: Load-balancing Thread-Index: AcvkccKS/eT5bYrCTwGpI39tWT4Hng== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4137@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C4DBA4137PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Cc: "behave@ietf.org" Subject: [BEHAVE] CGN REQ: Load-balancing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 07:04:31 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C4DBA4137PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, The current I-D text does not elaborate on load-balancing when several CGNs= are deployed. It would be useful to have something documented in the requi= rement document. Examples of requirement to be included: * Avoid oscillation * Avoid traffic split between several CGNs * when (static) port forwarding is used, ensure the appropriate CGN is used * Etc. You can find more discussion on this in: * http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-05#sectio= n-5 * http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01#sec= tion-3 Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F33C4DBA4137PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 authors,
 
T= he current=20 I-D text does not elaborate on load-balancing when several CGNs are deploye= d. It=20 would be useful to have something documented in the requirement=20 document.
 
E= xamples of=20 requirement to be included:
*= Avoid=20 oscillation
*= Avoid=20 traffic split between several CGNs
* when (static) port forwarding i= s used,=20 ensure the appropriate CGN is used
*= =20 Etc.
 
Y= ou can find=20 more discussion on this in:
 
*= http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-= 05#section-5
*= http://tools.ietf.org/html/draft-zhang-behave-nat64-load-bala= ncing-01#section-3
 
Cheers,
Med
 
--_000_94C682931C08B048B7A8645303FDC9F33C4DBA4137PUEXCB1Bnante_-- From mohamed.boucadair@orange-ftgroup.com Thu Mar 17 00:08:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420623A6800 for ; Thu, 17 Mar 2011 00:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 TIcdWOvN69xi for ; Thu, 17 Mar 2011 00:08:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 2A1CF3A67DB for ; Thu, 17 Mar 2011 00:08:11 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 65C28190410; Thu, 17 Mar 2011 08:09:38 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 4C004180054; Thu, 17 Mar 2011 08:09:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 17 Mar 2011 08:09:38 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Thu, 17 Mar 2011 08:09:37 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: Acvj5TXUmELaFuIiSua+2crvmnidhgAjOuUg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4139@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr>, <127401cbe33a$322a1c60$967e5520$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC2@PUEXCB1B.nanterre.francetelecom.fr>, <12f501cbe341$fe3310d0$fa993270$@com> <94C682931C08B048B7A8645303FDC9F33C4D682FC3@PUEXCB1B.nanterre.francetelecom.fr> <138701cbe357$ed3e63e0$c7bb2ba0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC7@PUEXCB1B.nanterre.francetelecom.fr> <4D80C6FB.3040101@viagenie.ca> In-Reply-To: <4D80C6FB.3040101@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 07:08:12 -0000 Dear Simon, Port can be released when not used anymore.=20 Don't see an issue there. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 15:20 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment On 2011-03-16 02:21, mohamed.boucadair@orange-ftgroup.com wrote: > If they are fixed, the ports can be determined by causing the victim > to view HTML which opens img1.example.com, img2.example.com, > img3.example.com, etc., to servers controlled by the attacker. The > attacker can then have Javascript release one of those mappings, > wait, and the attacker will know the victim will re-use that port -- > because it's the only port available. Proof of concept code that does > this has been circulating. >=20 > Med: Your point is valid. This is why there are other mode for the > assignment of the port sets: when a packet arrives and now binding is > available, a small random port set is generated. Once all the ports > are used, a new random port set is generated, etc. This processes is > repeated until reaching the per-subscriber quota. A user is never > assigned the same port sets. The size of the port set per binding is > configurable. I fail to see how this prevents the attack Dan described. Are the ports within a port set only used once? If so, it will come with heavy impacts on port utilization. Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Thu Mar 17 00:12:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F4D3A67FC for ; Thu, 17 Mar 2011 00:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, UNPARSEABLE_RELAY=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 ycE+EruSOrMi for ; Thu, 17 Mar 2011 00:12:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 630613A67AA for ; Thu, 17 Mar 2011 00:12:45 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 857551B81D1; Thu, 17 Mar 2011 08:14:12 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6540138403C; Thu, 17 Mar 2011 08:14:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 17 Mar 2011 08:14:12 +0100 From: To: Dan Wing , 'Reinaldo Penno' , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Thu, 17 Mar 2011 08:14:10 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAF4EfQAACQgjEAATpYcAAATtl/AAU6NjAAAd3SygAAUxxAAADVbCQAADD60AAPk29wABItJQAAIccDMA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA413C@PUEXCB1B.nanterre.francetelecom.fr> References: <13e001cbe361$06f7b120$14e71360$@com> <140501cbe364$9ca93240$d5fb96c0$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC8@PUEXCB1B.nanterre.francetelecom.fr> <164801cbe3eb$a43a3950$ecaeabf0$@com> In-Reply-To: <164801cbe3eb$a43a3950$ecaeabf0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.51527 Cc: DENG Xiaohong ESP/PEK , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 07:12:47 -0000 =20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mercredi 16 mars 2011 16:06 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Reinaldo Penno'; draft-ietf-behave-l= sn-requirements@tools.ietf.org Cc : DENG Xiaohong ESP/PEK; behave@ietf.org Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment >=20 > I am thinking of A+P-like schemes. >=20 > Med: Which ones? Dynamic modes have been proposed in A+P; see > http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02. Port > randomization requirement can be fairly honored. >=20 > No implementation magic can > change the number of ports allocated by those schemes, because > those schemes generally stick port information into the IPv6 > address or into a tunnel header. >=20 > Med: This is true for the stateless A+P mode but not the binding mode > (see: http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 for > more details). Most of the benefits attributed to A+P is that it's stateless in the SP's network.=20 Med: The binding mode adds only one (few) per-subscriber state compared to = a per-session state for the NAT.=20 I haven't seen anyone excited about that, but I don't talk to everyone. Med: You should ;-). The binding mode is similar to the DS-Lite but with AF= TR=3DPRR (Port Range Router).= From mohamed.boucadair@orange-ftgroup.com Thu Mar 17 00:23:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E75C3A6A14 for ; Thu, 17 Mar 2011 00:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 aFTh7O6sBIhP for ; Thu, 17 Mar 2011 00:23:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id C8A8B3A67DB for ; Thu, 17 Mar 2011 00:23:27 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6E0D332471E; Thu, 17 Mar 2011 08:24:54 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4DD4B27C037; Thu, 17 Mar 2011 08:24:54 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 17 Mar 2011 08:24:53 +0100 From: To: Dan Wing , "Francis.Dupont@fdupont.fr" Date: Thu, 17 Mar 2011 08:24:51 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: Acvj5ufE7eIX9/3+Se2nR9ztiTvhmAAABYcAAApyKoAAGJ2wsA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4146@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 16 Mar 2011 07:16:42 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <201103161431.p2GEVqua078968@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3FCC@PUEXCB1B.nanterre.francetelecom.fr> <017a01cbe411$257172c0$70545840$@com> In-Reply-To: <017a01cbe411$257172c0$70545840$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.63317 Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , 'Benson Schliesser' Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 07:23:32 -0000 Re-, =20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mercredi 16 mars 2011 20:34 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Francis.Dupont@fdupont.fr Cc : behave@ietf.org; draft-ietf-behave-lsn-requirements@tools.ietf.org; 'B= enson Schliesser' Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange-ftgroup.com > Sent: Wednesday, March 16, 2011 7:38 AM > To: Francis.Dupont@fdupont.fr > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > requirements@tools.ietf.org; Benson Schliesser > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 > Hi Francis, >=20 > By "random port set", I meant: >=20 > * a set of ports which are randomly generated when a new outbound > packet is received by the CGN > * the port set is not contiguous > * the port set is not fixe > * for subsequent packet requiring a new port, a port from the pre- > allocated random port set is used > * when all the ports in the port set are in-use, a new random port set > is generated by the CGN, etc until reaching a quota. >=20 > We can find a better name for this. I described a continuum from completely random to completely fixed at: http://www.ietf.org/mail-archive/web/behave/current/msg09182.html which said: 1. for every outgoing connection, create one mapping. 2. for an outgoing connection, create a "bin" of several mappings using random public ports. Subsequent outgoing connections will use ports from the "bin". When the "bin" is full, a new connection causes a new bin to be created. A bin is smaller or equal to the user's maximum port limit. 3. Same as (2), but the ports allocated to a "bin" are consecutive public ports. Perhaps that is a good starting point. Or perhaps this is better: 1. for a new outgoing flow, choose a random port and create a new mapping. There is a limit on the maximum number of ports. 2. for a new outgoing flow, choose several random ports and create a "bin" of those ports. This outgoing flow is assigned one of those ports. Subsequent outgoing flows will be assigned a port from the "bin". When the "bin" is full, a new flow causes this process to be repeated (i.e., a new bin is created). A bin is smaller or equal to the user's maximum port limit. 3. Same as (2), but the ports allocated to a "bin" are consecutive public ports. Med: I don't know where to put the non-contiguous one single "bin" case (ex= cerpt from (see http://tools.ietf.org/html/draft-bajko-pripaddrassign-02#se= ction-4.1) "a non Continuous Port Range is assigned to a given customer's device. In this example, the Port Range Value defines 128 Continuous Port Ranges, each one with a length of 16 port values. Note that the two first Port Ranges are both in the well-known ports span (i.e. 0-1023) but these two ranges are not adjacent. The following Port Range Mask and Port Range Value are conveyed in DHCP messages: - Port Range Value : 0000000001010000 (80) - Port Range Mask : 0000000111110000 (496) This means that the 128 following Continuous Port Ranges are assigned to the same device: - from 80 to 95 - from 592 to 607 - ... - from 65104 to 65119" 4. Same as (3), but only one "bin" is allocated. From mohamed.boucadair@orange-ftgroup.com Thu Mar 17 07:11:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A195C3A6983 for ; Thu, 17 Mar 2011 07:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 iwYcqnI20fMZ for ; Thu, 17 Mar 2011 07:11:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 4AB383A695B for ; Thu, 17 Mar 2011 07:11:02 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 34E921B844B; Thu, 17 Mar 2011 15:12:29 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 15F7F384066; Thu, 17 Mar 2011 15:12:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 17 Mar 2011 15:12:29 +0100 From: To: Simon Perreault , "behave@ietf.org" , DENG Xiaohong ESP/PEK Date: Thu, 17 Mar 2011 15:12:27 +0100 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: Acvj5Yf5JBbxFkpRRCmeF11+4OKaIAAuyK7g Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA4444@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <4D80C787.7010806@viagenie.ca> In-Reply-To: <4D80C787.7010806@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.120026 Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 14:11:11 -0000 Dear Simon, Not sure I agree. FYI, based on the experiments done by Xiaohong (e.g., using the tool availa= ble at https://www.dns-oarc.net/oarc/services/dnsentropy) on three scenario= s which apply also for the CGN context: * Scenario A: DNS resolver behind a NAT implementing RFC6056 * Scenario B: DNS resolver behind a NAT implementing an algorithm called "A= +P simple port randomization algorithm" * Scenario C: DNS resolver behind an port-restricted NAT implementing "port= increment by 1" algorithm Both Scenario A and B have the same score: "GREAT". Scenario C has a score = of "POOR". More port samplings have been tested and Scenario A and B had almost the sa= me randomness performance. This is something that can be documented if the community is interested in. Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mercredi 16 mars 2011 15:22 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment On 2011-03-16 02:16, mohamed.boucadair@orange-ftgroup.com wrote: > The port set does not means contiguous port range. Random port set can be= handled by the CGN. This should be explicit in the requirements IMO. >=20 > In deployments where a small address sharing ration is needed (e.g., 1:2,= 1:3), port randomization is still possible within the large port range. >=20 > The I-D already discusses the trade-offs: >=20 > Security: Mechanisms (1) and (2) provide very good security in that > ports numbers are not easily guessed. Easily guessed port numbers > put subscribers at risk of the attacks described in [RFC6056]. > Mechanism (3) provides poor security to subscribers, especially if > the "bin" size is small. I think it will need to be changed in light of the attack described by Dan. To me, (2) does not appear to be as secure as (1) anymore. Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From Francis.Dupont@fdupont.fr Thu Mar 17 07:39:17 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0263A69B1 for ; Thu, 17 Mar 2011 07:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My6StUVd1W7V for ; Thu, 17 Mar 2011 07:39:16 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E11913A69A1 for ; Thu, 17 Mar 2011 07:39:15 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2HEehaB067611; Thu, 17 Mar 2011 15:40:43 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103171440.p2HEehaB067611@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Wed, 16 Mar 2011 13:55:18 -0400. Date: Thu, 17 Mar 2011 15:40:43 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 14:39:17 -0000 In your previous mail you wrote: If the hold-down for TCP is 120 seconds at a rate of, say, 250k ports per second, you will have on average 250K*120 seconds = 30M ports unavailable until the next 120 seconds window. 30M ports is roughly equivalent to 500 public addresses. If the rate goes up to 1M ports per second...well you get the picture. For ISPs trying to save address and stay in business it becomes quite a burden. Then there is an added Req to not use a pool in certain situations - pool hold time. Now an ISP needs to have 3x the number of public addresses. => I don't buy your argument because it proves 120 seconds are already too large for the lifetime of established TCP connections, BTW: - 120 is really too short and will break applications (I have the proof of this) - RFC 5382 REQ-r says 2 hours 4 minutes: this is obviously too large and I found firewalls which have shorter lifetimes. Nevertheless I propose to keep 120 seconds but as a default, the hold down timer could be any value between 0 (i.e., hold-down disabled) and a reasonable maximum (I've just looked at my code and I put 600). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Mar 17 08:05:59 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4016C3A6A6D for ; Thu, 17 Mar 2011 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vivrTtVqQ0yd for ; Thu, 17 Mar 2011 08:05:58 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 32D4B3A6A29 for ; Thu, 17 Mar 2011 08:05:58 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2HF7PND069428; Thu, 17 Mar 2011 16:07:25 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103171507.p2HF7PND069428@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 16 Mar 2011 12:50:18 MST. <019901cbe413$61302d90$239088b0$@com> Date: Thu, 17 Mar 2011 16:07:25 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 15:05:59 -0000 In your previous mail you wrote: So you are saying you disagree with http://tools.ietf.org/html/rfc5508#section-6 => +1 I disagree too: ICMP 3/13 should be sent only for administrative restrictions, and not for resource constraints. BTW as I said you MAY have a switch to disable ICMP 3/13 so you can use this to lower the SHOULD, and as we are talking about NATs this should do exactly what I want (:-). Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Thu Mar 17 08:14:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059453A6A76 for ; Thu, 17 Mar 2011 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 GTWbIUwZO4wf for ; Thu, 17 Mar 2011 08:14:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id D91B63A6A56 for ; Thu, 17 Mar 2011 08:14:27 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 9FCFE19061D; Thu, 17 Mar 2011 16:15:54 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 5365118004D; Thu, 17 Mar 2011 16:15:54 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 17 Mar 2011 16:15:54 +0100 From: To: Francis Dupont , Dan Wing Date: Thu, 17 Mar 2011 16:15:53 +0100 Thread-Topic: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) Thread-Index: AcvktQrn+V76Dv4wS5q+RzXIXHvPjAAAOn6g Message-ID: <94C682931C08B048B7A8645303FDC9F33C4DBA44BA@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 16 Mar 2011 12:50:18 MST. <019901cbe413$61302d90$239088b0$@com> <201103171507.p2HF7PND069428@givry.fdupont.fr> In-Reply-To: <201103171507.p2HF7PND069428@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.17.81221 Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 15:14:29 -0000 Francis, Please see inline. -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Francis Dupont Envoy=E9 : jeudi 17 mars 2011 16:07 =C0 : Dan Wing Cc : behave@ietf.org; draft-ietf-behave-lsn-requirements@tools.ietf.org; BO= UCADAIR Mohamed OLNC/NAD/TIP Objet : Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached = (ICMP notification) In your previous mail you wrote: So you are saying you disagree with =20 http://tools.ietf.org/html/rfc5508#section-6 =20 =3D> +1 I disagree too: ICMP 3/13 should be sent only for administrative restrictions, and not for resource constraints. Med: Which is the case when the port quota/limit is reached, no? From Francis.Dupont@fdupont.fr Thu Mar 17 08:24:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AFA3A6968 for ; Thu, 17 Mar 2011 08:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfFrAUivLj-4 for ; Thu, 17 Mar 2011 08:24:31 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id BBCBB3A6954 for ; Thu, 17 Mar 2011 08:24:30 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2HFPwBp070662; Thu, 17 Mar 2011 16:25:58 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103171525.p2HFPwBp070662@givry.fdupont.fr> From: Francis Dupont To: ssenthil In-reply-to: Your message of Thu, 17 Mar 2011 02:11:09 -0400. Date: Thu, 17 Mar 2011 16:25:58 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" , mohamed.boucadair@orange-ftgroup.com, "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 15:24:33 -0000 In your previous mail you wrote: > => not so clear: usually it is never a good idea to send an ICMP and > in this case 3/13 was designed for a permanent condition. Can you point me to some documentation on code 13 being a permanent condition (hard error)? => I don't say permanent condition == hard error (in fact 3/13 was designed before the texts about soft vs hard errors). IMHO it is just what the description means: "administratively" is not likely used for a something very transient. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Mar 17 08:28:27 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B5E3A68FC for ; Thu, 17 Mar 2011 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7qqTeOSLAfT for ; Thu, 17 Mar 2011 08:28:26 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 91D503A6954 for ; Thu, 17 Mar 2011 08:28:25 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2HFTqwi070912; Thu, 17 Mar 2011 16:29:52 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103171529.p2HFTqwi070912@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Thu, 17 Mar 2011 07:27:56 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA4129@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 17 Mar 2011 16:29:52 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "Joel M. Halpern" , "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 15:28:27 -0000 In your previous mail you wrote: The issue I have is that firewalls are defined no where...and in the meantime I need a function which filters the internal ports before enforcing the NAT operation. I package this as a CGN function. => I disagree: the only relationship between firewalls and CGNs should be that a firewall should be placed in front of a CGN (i.e., filtering before translation). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Mar 17 09:23:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A553A6A76 for ; Thu, 17 Mar 2011 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjdTUWYIAzRc for ; Thu, 17 Mar 2011 09:23:17 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 1F39C3A69DB for ; Thu, 17 Mar 2011 09:22:16 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2HGNg94074651; Thu, 17 Mar 2011 17:23:42 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103171623.p2HGNg94074651@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Thu, 17 Mar 2011 16:15:53 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA44BA@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 17 Mar 2011 17:23:42 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" , Dan Wing Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 16:23:20 -0000 In your previous mail you wrote: I disagree too: ICMP 3/13 should be sent only for administrative restrictions, and not for resource constraints. Med: Which is the case when the port quota/limit is reached, no? => no, administrative restrictions mean firewall-like rules (3/13 was clearly designed for firewalls BTW). Regards Francis.Dupont@fdupont.fr PS: what matters is what a user would believe when the connection fails because of 3/13. I don't think there is a doubt about the 'Communication Administratively Prohibited' message but in fact I haven't checked what usual OSs return (I am afraid it would be some kind of 'network unreachable'). From dwing@cisco.com Thu Mar 17 11:05:08 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840F93A6A04 for ; Thu, 17 Mar 2011 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 B1wrQGDKAwzM for ; Thu, 17 Mar 2011 11:05:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C34843A6AE8 for ; Thu, 17 Mar 2011 11:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4208; q=dns/txt; s=iport; t=1300385193; x=1301594793; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0NENKydCvSybA2UWaSRfFVtP0RgMMpWeFfx3T3EFC7g=; b=GzY+045OqwAhV90TcbbThNoMTZvzlR4CyGEo69Wx2LM3Io8K4KMYgNbF 7S91ypke33+wyjHmbbKHOo8hrp2eWgDnEOotCifqJz1NzzxdnwPZ/36O5 OMDv05uRoztYKg8UgDk8/ffNRrVi+NgpbmRBZFKlg0yWRu4FjFbN8Zfu9 4=; X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="226195787" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 17 Mar 2011 18:06:31 +0000 Received: from dwingWS ([10.32.240.196]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2HI6UXF010489; Thu, 17 Mar 2011 18:06:30 GMT From: "Dan Wing" To: , References: Your message of Wed, 16 Mar 2011 07:16:42 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <201103161431.p2GEVqua078968@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3FCC@PUEXCB1B.nanterre.francetelecom.fr> <017a01cbe411$257172c0$70545840$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA4146@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA4146@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 17 Mar 2011 11:06:29 -0700 Message-ID: <068901cbe4ce$0acbb7b0$20632710$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvj5ufE7eIX9/3+Se2nR9ztiTvhmAAABYcAAApyKoAAGJ2wsAAWq4uw Content-language: en-us Cc: behave@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, 'Benson Schliesser' Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 18:05:08 -0000 We need some common terminology. Invent something. =20 -d > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Thursday, March 17, 2011 12:25 AM > To: Dan Wing; Francis.Dupont@fdupont.fr > Cc: behave@ietf.org; = draft-ietf-behave-lsn-requirements@tools.ietf.org; > 'Benson Schliesser' > Subject: RE: [BEHAVE] CGN REQ: Port Set Assignment >=20 > Re-, >=20 >=20 >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mercredi 16 mars 2011 20:34 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Francis.Dupont@fdupont.fr > Cc : behave@ietf.org; draft-ietf-behave-lsn- > requirements@tools.ietf.org; 'Benson Schliesser' > Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of mohamed.boucadair@orange-ftgroup.com > > Sent: Wednesday, March 16, 2011 7:38 AM > > To: Francis.Dupont@fdupont.fr > > Cc: 'behave' <(behave@ietf.org)>; draft-ietf-behave-lsn- > > requirements@tools.ietf.org; Benson Schliesser > > Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment > > > > Hi Francis, > > > > By "random port set", I meant: > > > > * a set of ports which are randomly generated when a new outbound > > packet is received by the CGN > > * the port set is not contiguous > > * the port set is not fixe > > * for subsequent packet requiring a new port, a port from the pre- > > allocated random port set is used > > * when all the ports in the port set are in-use, a new random port > set > > is generated by the CGN, etc until reaching a quota. > > > > We can find a better name for this. >=20 > I described a continuum from completely random to completely fixed at: > http://www.ietf.org/mail-archive/web/behave/current/msg09182.html >=20 > which said: >=20 > 1. for every outgoing connection, create one mapping. > 2. for an outgoing connection, create a "bin" of several mappings > using random public ports. Subsequent outgoing connections will > use ports from the "bin". When the "bin" is full, a new > connection causes a new bin to be created. A bin is smaller or > equal to the user's maximum port limit. > 3. Same as (2), but the ports allocated to a "bin" are consecutive > public ports. >=20 > Perhaps that is a good starting point. Or perhaps this is better: >=20 > 1. for a new outgoing flow, choose a random port and create a new > mapping. There is a limit on the maximum number of ports. >=20 > 2. for a new outgoing flow, choose several random ports and create > a > "bin" of those ports. This outgoing flow is assigned one of > those ports. Subsequent outgoing flows will be assigned a port > from the "bin". When the "bin" is full, a new flow causes this > process to be repeated (i.e., a new bin is created). A bin is > smaller or equal to the user's maximum port limit. >=20 > 3. Same as (2), but the ports allocated to a "bin" are consecutive > public ports. >=20 > Med: I don't know where to put the non-contiguous one single "bin" = case > (excerpt from (see http://tools.ietf.org/html/draft-bajko- > pripaddrassign-02#section-4.1) >=20 > "a non Continuous Port Range is assigned to a given customer's > device. In this example, the Port Range Value defines 128 = Continuous > Port Ranges, each one with a length of 16 port values. Note that > the two first Port Ranges are both in the well-known ports span > (i.e. 0-1023) but these two ranges are not adjacent. >=20 > The following Port Range Mask and Port Range Value are conveyed in > DHCP messages: > - Port Range Value : 0000000001010000 (80) > - Port Range Mask : 0000000111110000 (496) >=20 > This means that the 128 following Continuous Port Ranges are > assigned to the same device: > - from 80 to 95 > - from 592 to 607 > - ... > - from 65104 to 65119" >=20 >=20 > 4. Same as (3), but only one "bin" is allocated. From rpenno@juniper.net Thu Mar 17 11:11:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8297A3A6A0F for ; Thu, 17 Mar 2011 11:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 qMV2EbD+u0W4 for ; Thu, 17 Mar 2011 11:11:10 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 181BB3A6ADD for ; Thu, 17 Mar 2011 11:11:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTYJPD9sFQUTmdxUildgLNY90NHatClPc@postini.com; Thu, 17 Mar 2011 11:12:37 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 17 Mar 2011 11:03:04 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 17 Mar 2011 14:04:14 -0400 From: Reinaldo Penno To: Francis Dupont Date: Thu, 17 Mar 2011 14:04:11 -0400 Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: AcvksRtkBkyMh7xYQ9GnWNC/jnuugQAHJw0r Message-ID: In-Reply-To: <201103171440.p2HEehaB067611@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 18:11:16 -0000 I think you are talking about idle timeout. The Hold-down is the time the port can not be re-used for another session after FINs have been received from both sides. It has nothing to do with idle or session timeout Thanks, Reinaldo On 3/17/11 7:40 AM, "Francis Dupont" wrote: > In your previous mail you wrote: >=20 > If the hold-down for TCP is 120 seconds at a rate of, say, 250k ports = per > second, you will have on average 250K*120 seconds =3D 30M ports unavai= lable > until the next 120 seconds window. > =20 > 30M ports is roughly equivalent to 500 public addresses. > =20 > If the rate goes up to 1M ports per second...well you get the picture.= For > ISPs trying to save address and stay in business it becomes quite a bu= rden. > =20 > Then there is an added Req to not use a pool in certain situations - p= ool > hold time. > =20 > Now an ISP needs to have 3x the number of public addresses. > =20 > =3D> I don't buy your argument because it proves 120 seconds are already > too large for the lifetime of established TCP connections, BTW: > - 120 is really too short and will break applications (I have the > proof of this) > - RFC 5382 REQ-r says 2 hours 4 minutes: this is obviously too large > and I found firewalls which have shorter lifetimes. >=20 > Nevertheless I propose to keep 120 seconds but as a default, the hold > down timer could be any value between 0 (i.e., hold-down disabled) and > a reasonable maximum (I've just looked at my code and I put 600). >=20 > Regards >=20 > Francis.Dupont@fdupont.fr From cb.list6@gmail.com Thu Mar 17 11:47:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823EA3A6A33 for ; Thu, 17 Mar 2011 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86gRItQouG4z for ; Thu, 17 Mar 2011 11:47:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B623C3A693F for ; Thu, 17 Mar 2011 11:47:12 -0700 (PDT) Received: by iwl42 with SMTP id 42so3701203iwl.31 for ; Thu, 17 Mar 2011 11:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YXDzfzWzSYnNmD8/MVJMBfmVa0cUWYqKdlgIuE4Be0E=; b=dzN8plFx0U4rYzVUYi+6rOoTk5zdbV1b05xgSG2QvqtseNH5F8+k3NAI42j8fnMa98 b14eJhHjwFg6gL2fotpwXDdp+yNG1VrqTaxMU71EZaWo0A9/t0FsbIxwKhriXMsspESy 9MMfXbl5GXPdWj3iStS6r0pSSxFc7qDdl2nY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dDpY1QMdAdKWSiQusWP949yXlMlhW0h7a6QFhxNzQExYPpRqUvJe/wbqbDOEQOVYAs j/nJQLjGlaUXyB+3CFfwkm7rStLQTJqasP4MdvtKhdPbQTcE9guzr5Cwhgo8bKp27Tlh G26n++0rQZiG/epmvWcZMOsFbUC+WQLjb1GqE= MIME-Version: 1.0 Received: by 10.42.19.134 with SMTP id c6mr178950icb.507.1300387720766; Thu, 17 Mar 2011 11:48:40 -0700 (PDT) Received: by 10.42.170.68 with HTTP; Thu, 17 Mar 2011 11:48:40 -0700 (PDT) In-Reply-To: <201103171529.p2HFTqwi070912@givry.fdupont.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA4129@PUEXCB1B.nanterre.francetelecom.fr> <201103171529.p2HFTqwi070912@givry.fdupont.fr> Date: Thu, 17 Mar 2011 11:48:40 -0700 Message-ID: From: Cameron Byrne To: Francis Dupont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.org" , "Joel M. Halpern" , mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 18:47:13 -0000 On Thu, Mar 17, 2011 at 8:29 AM, Francis Dupont wrote: > =A0In your previous mail you wrote: > > =A0 The issue I have is that firewalls are defined no where...and in > =A0 the meantime I need a function which filters the internal ports > =A0 before enforcing the NAT operation. I package this as a CGN > =A0 function. > > =3D> I disagree: the only relationship between firewalls and CGNs > should be that a firewall should be placed in front of a CGN > (i.e., filtering before translation). > Careful. I do not believe we should be using the word "should" and "firewall" . How about "may" and "security enforcement point". That said, i would highly discourage any design or standard that has stateful middle-boxes in series. Cameron From bschlies@cisco.com Thu Mar 17 14:13:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9711A3A69E5 for ; Thu, 17 Mar 2011 14:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO832X4SK-OY for ; Thu, 17 Mar 2011 14:13:37 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8C44F3A699A for ; Thu, 17 Mar 2011 14:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1054; q=dns/txt; s=iport; t=1300396506; x=1301606106; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=5h79lxQgHza90d3lKkmuWwh9FclLoUQnkKgBKlFX6BU=; b=Nmaehpow9obwewnC/Sy4A5CDn9OyHzVJ3QKzp1B8fQChjEEQS75XzdEG W4yAaGbe2l20y0rSCagPfgXrX6693h11Lm5GCEkY2tOqjhthgXNVShllf 2B1+fgNEkn+dipID21IyyTduIWaKxjRdAGjPlgnxujJFKzWr6NmeS8FJF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJMWgk2tJV2a/2dsb2JhbAClUXenFZwwhWMEhS+HL4NT X-IronPort-AV: E=Sophos;i="4.63,201,1299456000"; d="scan'208";a="226661302" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 17 Mar 2011 21:15:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2HLF5xg009184; Thu, 17 Mar 2011 21:15:05 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:15:05 -0500 Received: from 10.21.80.242 ([10.21.80.242]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Mar 2011 21:15:05 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Mar 2011 16:15:03 -0500 From: Benson Schliesser To: , Simon Perreault , "behave@ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Shared address pool Thread-Index: Acvj657z44g3i9vkTGO0P3dO1+Qm0wADArHgADwt9DU= In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA4099@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Mar 2011 21:15:05.0242 (UTC) FILETIME=[62DD7FA0:01CBE4E8] Subject: Re: [BEHAVE] CGN REQ: Shared address pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 21:13:38 -0000 On 3/16/11 11:39 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: >>> I don't know how this should be covered in the I-D, but I see a value to >>> have a section to elaborate on the configured address pool to be used in >>> the external interface of the CGN. In particular, the CGN should: >>> >>> * support contiguous address pool >>> * support non-contiguous addresses >> >> Why? > > Because we want to avoid CGN implementations assuming that only contiguous > address pools can be configured as shared addresses. Address pools at our > disposable may not be "aggregatable"... That may be true in some cases (marginal today, perhaps more of an issue in the future), and therefore it's not a bad feature. But I see no reason to make the pool size and/or composition a requirement for CGN. The only requirement is that pools can be routed. I believe that what you describe is an implementation topic, perhaps appropriate in a RFI but not the requirements draft. Cheers, -Benson From bschlies@cisco.com Thu Mar 17 14:17:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693C53A69E5 for ; Thu, 17 Mar 2011 14:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct2+nVK3S9RL for ; Thu, 17 Mar 2011 14:17:38 -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 E3BB03A6B31 for ; Thu, 17 Mar 2011 14:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=501; q=dns/txt; s=iport; t=1300396741; x=1301606341; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LoJ1fP13uWqDmBKECJhWH9MbzZrxqu2HPTDF+SgbGFY=; b=gdrNR6vKrOJnay1piC1NPnJJexcow0/SdQGif9BrvCGTneYN0CWUa+SV GQl7hw4kEP5oqzu02LIOFDw5i4Srk2G94FRixUUBGqUyvQqCfJEXjI6ro 9hOQhx+RCc0G7cE/wmKC5xbsOwKAKxX7FRNDRE1LYCuA1oB1bAu9HV9Yv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKMXgk2tJV2Y/2dsb2JhbAClUXenFJwwhWMEhS+HL4NTgiQ X-IronPort-AV: E=Sophos;i="4.63,201,1299456000"; d="scan'208";a="668282449" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2011 21:19:01 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2HLJ0xU029264; Thu, 17 Mar 2011 21:19:00 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:19:01 -0500 Received: from 10.21.80.242 ([10.21.80.242]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Mar 2011 21:19:00 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Mar 2011 16:18:58 -0500 From: Benson Schliesser To: Francis Dupont , Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT Thread-Index: Acvk6O2ZRPdchmYRaU+ShbWPXcMpbQ== In-Reply-To: <201103161659.p2GGxiTU088857@givry.fdupont.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Mar 2011 21:19:01.0531 (UTC) FILETIME=[EFB456B0:01CBE4E8] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Support a means to reveal a USER_HINT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 21:17:40 -0000 On 3/16/11 11:59 AM, "Francis Dupont" wrote: > => I know but NATs are considered as security devices by some people > and here you remove this capability. And the technical arguments > are not enough, what matters is the feeling some people have. I think the user-hint feature may sometimes be desired, but also may be undesired as Francis describes. The user-hint feature is not an appropriate requirement, unless it's specified as a MAY. Cheers, -Benson From bschlies@cisco.com Thu Mar 17 14:39:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3194D3A6A4A for ; Thu, 17 Mar 2011 14:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I0PWAGEBe+A for ; Thu, 17 Mar 2011 14:39:42 -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 DF8673A6935 for ; Thu, 17 Mar 2011 14:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2725; q=dns/txt; s=iport; t=1300398071; x=1301607671; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/n7NkQKamJAs/v+DITq5SlEdL0yz8P+KZrgt+16PMx4=; b=VR6Ztgusl5S3aXjXbfvYXOTXLfxZgOhD69CZy64XfkE4Ccz8CtayQaeN E8kdYiQi4h/pPKV696PdYXvUr4qkCBNQexNXlUeBfVKbpifDfrTvPjyYO 5iFhlmuyNHwfxb+AbzFTlRN+7cjikE6KVJTzMLt1NtznIAUXqg9SIrj5t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF0cgk2tJXG9/2dsb2JhbAClVHenFZwvhWMEhS+HL4NT X-IronPort-AV: E=Sophos;i="4.63,201,1299456000"; d="scan'208";a="279323225" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2011 21:41:11 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2HLfAC0027808; Thu, 17 Mar 2011 21:41:10 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:41:10 -0500 Received: from 10.21.80.242 ([10.21.80.242]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Mar 2011 21:41:10 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Mar 2011 16:41:08 -0500 From: Benson Schliesser To: , Simon Perreault Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Hold-down pool Thread-Index: Acvj7rkQtO5dIkZITBO5xpPu5AZROQAflBdQAB+/OgI= In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA412A@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Mar 2011 21:41:10.0826 (UTC) FILETIME=[0806A8A0:01CBE4EC] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 21:39:44 -0000 During normal operation, a flow reuse hold-down timer makes sense. However= , there are cases where the CGN might benefit from reducing or ignoring the timer. And the potential for negative effects isn't bad enough to forbid that behavior. Thus, a hold-down timer cannot be a MUST requirement - it ought to be a SHOULD requirement. Further, if I recall correctly in your original note on the topic, you applied this hold-down timer to "state loss" events such as reboots and failures. And I believe you conclude that a backup address pool is required. I disagree. By making the hold-down timer a requirement, the CG= N is faced with either (a) reserving an address pool for use following state-loss events, wasting those resources during normal operations, or (b) forcing downtime for the hold-down period of time following a state loss event. We can avoid this situation entirely by just not making it a requirement. My input is to make hold-down timers a SHOULD requirement during normal operations, with some text commenting about state loss events. Perhaps, include a MAY statement allowing for reserved address pools to cope with these state loss events. And leave the details up to each implementation. Cheers, -Benson On 3/17/11 1:35 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > The rationale behind the pool is to prevent all/majority of your ports be > unusable because tagged as hold-down port. We need a means to control the > amount of port to be put in that pool; hence the need to configure a pool > size. >=20 > As for the UDP timers, I agree with Francis to have one value for TCP/UDP= . I > have no magic value so far. >=20 > Cheers, > Med=20 >=20 > -----Message d'origine----- > De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > Envoy=E9 : mercredi 16 mars 2011 16:28 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : behave@ietf.org > Objet : Re: [BEHAVE] CGN REQ: Hold-down pool >=20 > On 2011-03-16 10:31, mohamed.boucadair@orange-ftgroup.com wrote: >> For the UDP don't forget the case of incoming connections (e.g., SIP >> INVITE message is received just after a PCP-instructed mapping >> expired.). We need a safety timer for UDP also. >=20 > Hmmm... I was assuming that the CGN had inbound mapping refresh (REQ-6a > in RFC4787). >=20 > I guess the same reasoning equally applies to ICMP. >=20 > What do you suggest instead of zero? >=20 >> BTW, in addition to the timers, we need to consider also the pool >> size. >=20 > I don't quite understand the "pool" concept. What happens when the > number of ports in hold-down is larger than the pool size? >=20 > Simon From bschlies@cisco.com Thu Mar 17 14:43:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FA43A6A63 for ; Thu, 17 Mar 2011 14:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vU1VUOxyxwJ for ; Thu, 17 Mar 2011 14:43:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 622913A6A4A for ; Thu, 17 Mar 2011 14:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2475; q=dns/txt; s=iport; t=1300398272; x=1301607872; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=XO7vbn5ZurSikCdMD8NWFpVTmOS8y8A4PseStpAXiVo=; b=ABHc85VZhbe9UeKzHSs1mbOfY/pYsDHAsb4SL3sxlLkcoPELOHAfwiej vzC3GRRHCBQkdJLcjdZNiRG9/mYWGICII/PBJNUUovnIHGSOsxXU9W47c AbPVqdxGVkoW2uvNjeU2KVW07capORKevwD/Hbca3Kul09UjKB+j87EKE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABIdgk2tJV2a/2dsb2JhbAClVXeIRZ45nC+FYwSFL4cvg1M X-IronPort-AV: E=Sophos;i="4.63,201,1299456000"; d="scan'208";a="226276039" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 17 Mar 2011 21:44:31 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2HLiVoB021158; Thu, 17 Mar 2011 21:44:31 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:44:31 -0500 Received: from 10.21.80.242 ([10.21.80.242]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Mar 2011 21:44:30 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Mar 2011 16:44:27 -0500 From: Benson Schliesser To: , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAJOJc3ABZsQNAAUs9pnQ== In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Mar 2011 21:44:31.0022 (UTC) FILETIME=[7F5A24E0:01CBE4EC] Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 21:43:04 -0000 It doesn't matter what kind of port-set you implement - there are no cases where the port-set feature is a requirement. There are cases where it is desirable, including logging reduction etc. Operators that desire this feature should include it in their RFI. But it doesn't belong as a MUST or SHOULD in the requirements draft - it ought to be listed as a MAY item. Cheers, -Benson On 3/16/11 1:16 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: > Dear Benson, >=20 > The port set does not means contiguous port range. Random port set can be > handled by the CGN. This should be explicit in the requirements IMO. >=20 > In deployments where a small address sharing ration is needed (e.g., 1:2, > 1:3), port randomization is still possible within the large port range. >=20 > The I-D already discusses the trade-offs: >=20 > Security: Mechanisms (1) and (2) provide very good security in that > ports numbers are not easily guessed. Easily guessed port numbers > put subscribers at risk of the attacks described in [RFC6056]. > Mechanism (3) provides poor security to subscribers, especially if > the "bin" size is small. >=20 > Cheers, > Med=20 >=20 > -----Message d'origine----- > De : Benson Schliesser [mailto:bschlies@cisco.com] > Envoy=E9 : mardi 15 mars 2011 20:31 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; > draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc : 'behave' <(behave@ietf.org)> > Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 >=20 > On 3/15/11 9:07 AM, "mohamed.boucadair@orange-ftgroup.com" > wrote: >=20 >> Section 5=20 >> http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#section= -5 >> discusses various modes for the port assignment but there is no explicit >> requirement.=20 >> =20 >> I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) suppor= t the >> ability to assign port sets. The selection of the dynamic mode vs. port = set >> is >> deployment-specific. >=20 > I don't support this as a MUST or SHOULD. A port-set feature isn't a > requirement for successful deployment of a CGN. In fact, a port-set feat= ure > might be seen to have negative implications for security, scale, etc. It= is > an implementation choice, and the requirements document ought to capture = it > as a MAY. >=20 > Cheers, > -Benson >=20 From bschlies@cisco.com Thu Mar 17 14:47:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA76C3A6A63 for ; Thu, 17 Mar 2011 14:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2Uf9T7kZB2L for ; Thu, 17 Mar 2011 14:47:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 874603A6A62 for ; Thu, 17 Mar 2011 14:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=3057; q=dns/txt; s=iport; t=1300398564; x=1301608164; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=4UhuaAb5ucEgx3NxTvgNuFMYxqCjzMfGAnU2zA74vi4=; b=Sq7OPWMrVEJRCBmxlDaxflptONZ+UR658xyn+4jLM1BJejFBqfy8sqGc hcI9MUbNWct+tVImWW2g/lPD2rV3i0NpctAiOJFJBDm9ZQ5XdL+pVdeZT iVxrberyeSj9THsHfDmjQ3t/+lTRGpMCObkTgmKj9RkZYinc3ciJQygTQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADIegk2tJV2a/2dsb2JhbAClVXeIRZ5CnC2FYwSFL4cvg1M X-IronPort-AV: E=Sophos;i="4.63,201,1299456000"; d="scan'208";a="226277216" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 17 Mar 2011 21:49:23 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2HLnNCY022814; Thu, 17 Mar 2011 21:49:23 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 16:49:23 -0500 Received: from 10.21.80.242 ([10.21.80.242]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Mar 2011 21:49:22 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 17 Mar 2011 16:49:19 -0500 From: Benson Schliesser To: , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAJOJc3ABZsQNAAUs9pnQAAK4MU In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 17 Mar 2011 21:49:23.0347 (UTC) FILETIME=[2D976630:01CBE4ED] Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 17 Mar 2011 21:47:56 -0000 On 3/17/11 4:44 PM, "Benson Schliesser" wrote: > It doesn't matter what kind of port-set you implement - there are no case= s > where the port-set feature is a requirement. Sorry, I should have said: the port-set feature is not a requirement for CGN. There are specific implementations of CGN where it might be inherent and/or desired, but that doesn't mean it applies to the general case. Cheers, -Benson >=20 > There are cases where it is desirable, including logging reduction etc. > Operators that desire this feature should include it in their RFI. But i= t > doesn't belong as a MUST or SHOULD in the requirements draft - it ought t= o > be listed as a MAY item. >=20 > Cheers, > -Benson >=20 >=20 > On 3/16/11 1:16 AM, "mohamed.boucadair@orange-ftgroup.com" > wrote: >=20 >> Dear Benson, >>=20 >> The port set does not means contiguous port range. Random port set can b= e >> handled by the CGN. This should be explicit in the requirements IMO. >>=20 >> In deployments where a small address sharing ration is needed (e.g., 1:2= , >> 1:3), port randomization is still possible within the large port range. >>=20 >> The I-D already discusses the trade-offs: >>=20 >> Security: Mechanisms (1) and (2) provide very good security in that >> ports numbers are not easily guessed. Easily guessed port numbers >> put subscribers at risk of the attacks described in [RFC6056]. >> Mechanism (3) provides poor security to subscribers, especially if >> the "bin" size is small. >>=20 >> Cheers, >> Med=20 >>=20 >> -----Message d'origine----- >> De : Benson Schliesser [mailto:bschlies@cisco.com] >> Envoy=E9 : mardi 15 mars 2011 20:31 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; >> draft-ietf-behave-lsn-requirements@tools.ietf.org >> Cc : 'behave' <(behave@ietf.org)> >> Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment >>=20 >>=20 >> On 3/15/11 9:07 AM, "mohamed.boucadair@orange-ftgroup.com" >> wrote: >>=20 >>> Section 5=20 >>> http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#sectio= n-5 >>> discusses various modes for the port assignment but there is no explici= t >>> requirement.=20 >>> =20 >>> I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) suppo= rt >>> the >>> ability to assign port sets. The selection of the dynamic mode vs. port= set >>> is >>> deployment-specific. >>=20 >> I don't support this as a MUST or SHOULD. A port-set feature isn't a >> requirement for successful deployment of a CGN. In fact, a port-set fea= ture >> might be seen to have negative implications for security, scale, etc. I= t is >> an implementation choice, and the requirements document ought to capture= it >> as a MAY. >>=20 >> Cheers, >> -Benson >>=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From miyakawa@nttv6.jp Fri Mar 18 00:40:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F8F3A680D; Fri, 18 Mar 2011 00:40:02 -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 wGfevL23pSvF; Fri, 18 Mar 2011 00:40:01 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by core3.amsl.com (Postfix) with ESMTP id 2BC333A67AE; Fri, 18 Mar 2011 00:40:01 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1B5F2BDC18; Fri, 18 Mar 2011 16:41:29 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id E621870496; Fri, 18 Mar 2011 16:41:28 +0900 (JST) Date: Fri, 18 Mar 2011 16:41:28 +0900 (JST) Message-Id: <20110318.164128.246590975.miyakawa@nttv6.jp> To: behave@ietf.org, pcp@ietf.org From: Shin Miyakawa Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: [BEHAVE] CGN REQ: CGN behaviour X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2011 07:40:02 -0000 Folks, This is Shin Miyakawa from NTT Communications in Tokyo. First of all, thank you very much for many warm messages from around the world for us. However still the situation has not been stabilized yet here in Japan, we're just fine and I believe that it would be improved soon. Then, I'd like to make a comment as one of authors of the CGN requirement draft... Talking about our CGN requirements draft, we think that CGN is not security device whereas it seems to me that some people believe CGN should has SECURITY function. Rather than that, CGN should implement FAIRNESS among the users behind. This is the original intention of the draft. Please note well also that because IPv4 address is going to be running out, to keep end-to-end principle as the Internet should have, we should move to IPv6 as quick as possible. CGN ans other similar techniques are just a quick relief, not a fundmental solution. So please do not expect "perfect" to the CGN and friends. Best regards, Shin Miyakawa From pacosaddress@googlemail.com Thu Mar 17 03:21:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDD53A68ED for ; Thu, 17 Mar 2011 03:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S37NpmQr7Ul for ; Thu, 17 Mar 2011 03:21:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8A5263A6839 for ; Thu, 17 Mar 2011 03:21:33 -0700 (PDT) Received: by iyi12 with SMTP id 12so3130420iyi.31 for ; Thu, 17 Mar 2011 03:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=EnMXkzc0Wa36mVnp6VHkFqMn4nv+eiICN4LBc/h/u8g=; b=IQeATwBu9H39ike1/QZL/U6JYJeKloVMquUOkCwweJq2+u0LqqSjjvCJIn+eFbjbXF +ELtya8GwfCbqDSOWLBZeGEe8ZgDkXmuwPk8LIoeRAYfdmGPdNavOaVN+QzFr0iixxcl +NHcvgbRnpR/g63UFkQW39Hkv4RYMtMIaTqCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=NfPYxkWYVdQYkIffusv8/gnbkj6AM/rYpafOlcMVn1AgRiN28jCiwZbu7vP0pTi39p lepYamSDG457coPFp7AVYfHrYfHNe+7lmPsGq8+BxkikM9OA9uHSbm1a0nEonCWEcya6 3wqNzvqH9uKjJ+UmBHlR7edoPKlpQYKBIXmKk= MIME-Version: 1.0 Received: by 10.231.119.216 with SMTP id a24mr1038281ibr.58.1300357380939; Thu, 17 Mar 2011 03:23:00 -0700 (PDT) Received: by 10.231.160.21 with HTTP; Thu, 17 Mar 2011 03:23:00 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 17 Mar 2011 11:23:00 +0100 Message-ID: From: Paco Cortes To: Dave Thaler , "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Mar 2011 08:57:11 -0700 Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 10:21:40 -0000 Hi, A few comments: 1) Section 4.3, quote "Source addresses: 172.21.112.0/30. Source addresses have to be allocated because applications use getsockname() calls and in the BIS=A0mode an IP address of the IPv4 interface has to be shown ...": Comment 1a: Should there be a description of the case of a applying getscockname() to a socket to which a local IPv4 address has already been bound via bind()? In that case, it should not be an address from 172.21.112.0/30 that should be returned, but the real local IPv4 @ previously bound to the socket, shouldn't it? Comment 1b: What is the advantage of using a BIH specific address in other cases? Why not just reusing a real IPv4 address of the host? 2) Section 4.3, quote "Secondary destination addresses: 10.170.160.0/20. The address mapper will select destination addresses out of this pool if the node has a dual-stack connection conflicting with primary destination addresses". Comment 2a: This does imply that IPv4 peer hosts might have addresses belonging to the primary destination @ range 172.21.80.0/20 (should be obvious, but the draft could assume that this might be prohibited in the RFC1918 network where the host is located). What shall be the behaviour of a host implementing BIH if the address mapper has allocated an address from 172.21.80.0/20 (lets take 172.21.80.1 as example) to an IPv6 socket, and later the host tries to establish an IPv4 socket to an IPv4 peer with exactly that address 172.21.80.1? Can the BIH implementation somehow distinguish if the local host is trying to connect to the real IPv4 host with address 172.21.80.1, or if it is trying to connect to the IPv6 peer to which 172.21.80.1 was assigned by the address mapper? Seeing a DNS responses with an A record with address 172.21.80.1 could be used as indication, but it doesn't really solve the ambiguity. Does this imply that BIH would fully prevent any communication to a real IPv4 peer with address 172.21.80.1? If there is a way to distinguish the intended peer, should the BIH implementation apply NAT44 to the destination to allow communication (and getting things quite complex...). The implied limitations and the preferred behavior of a BIH implementation should be clearly stated. 3) Section 4.3, first paragraph, quote "For example, entries with the longest inactivity time can be cleared and IPv4 addresses reused for creating new entries.". Comment 3a: this seems to imply that address mappings are kept fully independent from a possible detection of end of communication (like TCP RST, TCP FIN, ICMP 3, ...). Is this desirable/acceptable? Shouldn't this proposed standard mandate mechanisms to limit the liveness of address mappings? Please bear with me if similar comments were handled in past discussions. Kind regards, Paco 2011/3/16 Dave Thaler > > Our charter milestone is: > =A0 =A0 =A0 =A0Apr 2011 Submit to IESG: host-based NAT46 translation for = IPv4-only applications to access IPv6-only servers (std) > > This email begins a Working Group Last Call on draft-ietf-behave-v4v6-bih= -03.txt > to close on March 30. > > -Dave > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behal= f > > Of Internet-Drafts@ietf.org > > Sent: Friday, March 11, 2011 2:30 AM > > To: i-d-announce@ietf.org > > Cc: behave@ietf.org > > Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Behavior Engineering for Hindrance > > Avoidance Working Group of the IETF. > > > > > > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Dual Stack Hosts Using "Bump-in= -the-Host" (BIH) > > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : B. Huang, et al. > > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-behave-v4v6-bih-03.txt > > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 26 > > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-11 > > > > Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translatio= n > > mechanism that allows a class of IPv4-only applications that work throu= gh > > NATs to communicate with IPv6-only peers. =A0The host on which applicat= ions > > are running may be connected to IPv6-only or dual-stack access networks= . > > BIH hides IPv6 and makes the IPv4-only applications think they are talk= ing > > with IPv4 peers by local synthesis of IPv4 addresses. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-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 Inter= net- > > Draft. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Fri Mar 18 11:10:10 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F118E3A6A3E for ; Fri, 18 Mar 2011 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JDuvmwGRrHu for ; Fri, 18 Mar 2011 11:10:08 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 03F793A6A2D for ; Fri, 18 Mar 2011 11:10:07 -0700 (PDT) Received: by iwl42 with SMTP id 42so5005320iwl.31 for ; Fri, 18 Mar 2011 11:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=74hvwNr7JdQWg/y1R2TSnMh4BwXjJus2Ua/aX4v+EyM=; b=weZFvwZHXCAFxIrRgCs6FqNf+2bKDv/MS1e089i1HR+7lWUWMcu2UXp+64hqU6IKx5 8GFhHanMlK4RytwfRZQBSdm9BMEvzPSXfapRDDa2D36Rm0YWlNM5stXm+b0A+n7xu2hf Vb+6xNt+B8S7SohfHzLKF8or7KJyoyxembjjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Njx+pamPUPqmnQMIYjg/Hjm0Tce5SU0WyEHWTRd9GA2qMnIHV8jX/bBVPt/zXiqCte ShUrLH6zLZjut2jWTp18hACnP60GwvaNBCVKQaYfXd6IOQsZaPrAScH/4Wqhk0wpzSAu nN1zC8po/SxcDHDXkqW4oCU9as/4UYKZo7vl8= MIME-Version: 1.0 Received: by 10.43.59.142 with SMTP id wo14mr1961671icb.373.1300471897465; Fri, 18 Mar 2011 11:11:37 -0700 (PDT) Received: by 10.42.170.68 with HTTP; Fri, 18 Mar 2011 11:11:37 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 18 Mar 2011 11:11:37 -0700 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-behave-v4v6-bih@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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: Fri, 18 Mar 2011 18:10:10 -0000 the draft states: "The supported class of applications includes those that use DNS for IP address resolution and that do not embed IP address literals in protocol payloads." I believe this wording is too strong and makes it sound like BIH cannot support IPv4 literals, when later in the draft it is stated: "BIH MAY intercept inet_ntoa() and inet_addr() and use the address mapper for those. Doing that enables BIH to support literal IP addresses." I suggest this wording to make it clear that IPv4 literals may be supported but embedded addresses with application signalling will pose a challenge "The supported class of applications includes those that use DNS for IP address resolution. Direct references of outbound connections to IPv4 literals are also may be support (ex: http://192.0.2.1)." From cb.list6@gmail.com Fri Mar 18 11:18:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D7F3A69CD for ; Fri, 18 Mar 2011 11:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYYotkMXAqKj for ; Fri, 18 Mar 2011 11:18:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 769083A69B7 for ; Fri, 18 Mar 2011 11:18:42 -0700 (PDT) Received: by iyi12 with SMTP id 12so4960954iyi.31 for ; Fri, 18 Mar 2011 11:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1mP2PtmSoxXnx0Pyy1Yu7TPl3i4NLR2fIaOaZL7c6DY=; b=wPjwdk56hMQNYgHmjELgqlOPFHF4jH1wPDmg2aS/aKpbpBFNCRca3P7BTfNDXeMbF1 IxxrAv+lscfRNC4mzpMoKhs7A7/5OlE85WEWVH/0JINO9iGLiCJnFPxuWCfo0ax6sfWb 2NzRLjK6kLSNu64uABKMR28xGLrr2z80ZUb2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KbEnH3OsifAJrrGt2gP6+QYfOvVGaZgJ6xoNCg7flRexky16AXzbVsiPqiBxgX7CM4 GDgpVGn7dzenGJUD84oFfO3Pkji0HBtiYDl6yr9gX5Q0h6NN0548oHuF1Awq/IpMSQ2Q LvRV09ieTwA53FKE76TvvEdiO+tgfdlw+MJ4g= MIME-Version: 1.0 Received: by 10.42.199.210 with SMTP id et18mr2169577icb.38.1300472412011; Fri, 18 Mar 2011 11:20:12 -0700 (PDT) Received: by 10.42.170.68 with HTTP; Fri, 18 Mar 2011 11:20:11 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 18 Mar 2011 11:20:11 -0700 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-behave-v4v6-bih@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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: Fri, 18 Mar 2011 18:18:43 -0000 On Wed, Mar 16, 2011 at 3:24 PM, Dave Thaler wrote: > Our charter milestone is: > =A0 =A0 =A0 =A0Apr 2011 Submit to IESG: host-based NAT46 translation for = IPv4-only applications to access IPv6-only servers (std) > > This email begins a Working Group Last Call on draft-ietf-behave-v4v6-bih= -03.txt > to close on March 30. > > -Dave > Dave, Is BIH NAT46? Generically, host based NAT exist today in many platforms like Linux and they do not use the API interception structure as in BIH. IMHO, I believe this implementation on the N900 looks more like what NAT46 = is. http://code.google.com/p/n900ipv6/wiki/Nat64D And, it provides genuine utility to a user and overcomes real challenges of the post-IPv4 depletion world. Regards, Cameron From xiaohong.deng@orange-ftgroup.com Sun Mar 20 22:38:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44BD3A67B1 for ; Sun, 20 Mar 2011 22:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=0.665, 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 6alAnr7Lileo for ; Sun, 20 Mar 2011 22:38:13 -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 E9FDD3A67AF for ; Sun, 20 Mar 2011 22:38:10 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 05AA2FC4002; Mon, 21 Mar 2011 06:39:49 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id EF8BAFC4001; Mon, 21 Mar 2011 06:39:48 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 06:39:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 21 Mar 2011 13:39:38 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016216DF@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA4444@PUEXCB1B.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: Acvj5Yf5JBbxFkpRRCmeF11+4OKaIAAuyK7gALoYgyA= References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B56@PUEXCB1B.nanterre.francetelecom.fr><94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <4D80C787.7010806@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA4444@PUEXCB1B.nanterre.francetelecom.fr> From: To: , , X-OriginalArrivalTime: 21 Mar 2011 05:39:42.0098 (UTC) FILETIME=[60845720:01CBE78A] Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 Mar 2011 05:38:16 -0000 DQpGb3IgbW9yZSBpbmZvcm1hdGlvbiwgdGhlIGV4cGVyaW1lbnRzIE1lZCBtZW50aW9uZWQgaGVy ZSBpcyBjYXJyaWVkIG91dCB3aXRoIGFuIGFkZHJlc3Mgc2hhcmluZyByYXRpb24gKDE6NjQpDQpB bmQgb3ZlciAyMDAwIHBvcnRzIGhhdmUgYmVlbiBzYW1wbGVkLCB3aGljaCBzaG93cyBubyBzaWdu aWZpY2FudCBkaWZmZXJlbmNlIG9mIHBvcnQgcmFuZG9taXphdGlvbiAgYmV0d3dlbiANCiJhIE5B VCBpbXBsZW1lbnRpbmcgUkZDNjA1NjogQWxnb3JpdGhtIDEiIGFuZCAiYSBOQVQgaW1wbGVtZW50 aW5nIEErUCBzaW1wbGUgcG9ydCByYW5kb21pemF0aW9uIGFsZ29yaXRobSIuDQoNCkNoZWVycywN ClhpYW9ob25nDQpvcGVuc291cmNlIEErUDogaHR0cDovL29wZW5zb3VyY2VhcGx1c3Aud2VlYmx5 LmNvbS8NCiANCg0KfC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCnzlj5Hku7bkuro6IEJPVUNBREFJ UiBNb2hhbWVkIE9MTkMvTkFEL1RJUCANCnxbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS1mdGdyb3VwLmNvbV0gDQp85Y+R6YCB5pe26Ze0OiAyMDEx5bm0M+aciDE35pelIDIyOjEyDQp8 5pS25Lu25Lq6OiBTaW1vbiBQZXJyZWF1bHQ7IGJlaGF2ZUBpZXRmLm9yZzsgREVORyBYaWFvaG9u ZyBFU1AvUEVLDQp85Li76aKYOiBSRTogW0JFSEFWRV0gQ0dOIFJFUTogUG9ydCBTZXQgQXNzaWdu bWVudA0KfA0KfERlYXIgU2ltb24sDQp8DQp8Tm90IHN1cmUgSSBhZ3JlZS4NCnwNCnxGWUksIGJh c2VkIG9uIHRoZSBleHBlcmltZW50cyBkb25lIGJ5IFhpYW9ob25nIChlLmcuLCB1c2luZyANCnx0 aGUgdG9vbCBhdmFpbGFibGUgYXQgDQp8aHR0cHM6Ly93d3cuZG5zLW9hcmMubmV0L29hcmMvc2Vy dmljZXMvZG5zZW50cm9weSkgb24gdGhyZWUgDQp8c2NlbmFyaW9zIHdoaWNoIGFwcGx5IGFsc28g Zm9yIHRoZSBDR04gY29udGV4dDoNCnwNCnwqIFNjZW5hcmlvIEE6IEROUyByZXNvbHZlciBiZWhp bmQgYSBOQVQgaW1wbGVtZW50aW5nIFJGQzYwNTYNCnwqIFNjZW5hcmlvIEI6IEROUyByZXNvbHZl ciBiZWhpbmQgYSBOQVQgaW1wbGVtZW50aW5nIGFuIA0KfGFsZ29yaXRobSBjYWxsZWQgIkErUCBz aW1wbGUgcG9ydCByYW5kb21pemF0aW9uIGFsZ29yaXRobSINCnwqIFNjZW5hcmlvIEM6IEROUyBy ZXNvbHZlciBiZWhpbmQgYW4gcG9ydC1yZXN0cmljdGVkIE5BVCANCnxpbXBsZW1lbnRpbmcgInBv cnQgaW5jcmVtZW50IGJ5IDEiIGFsZ29yaXRobQ0KfA0KfEJvdGggU2NlbmFyaW8gQSBhbmQgQiBo YXZlIHRoZSBzYW1lIHNjb3JlOiAiR1JFQVQiLiBTY2VuYXJpbyBDIA0KfGhhcyBhIHNjb3JlIG9m ICJQT09SIi4NCnwNCnxNb3JlIHBvcnQgc2FtcGxpbmdzIGhhdmUgYmVlbiB0ZXN0ZWQgYW5kIFNj ZW5hcmlvIEEgYW5kIEIgaGFkIA0KfGFsbW9zdCB0aGUgc2FtZSByYW5kb21uZXNzIHBlcmZvcm1h bmNlLg0KfA0KfFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgY2FuIGJlIGRvY3VtZW50ZWQgaWYgdGhl IGNvbW11bml0eSBpcyANCnxpbnRlcmVzdGVkIGluLg0KfA0KfENoZWVycywNCnxNZWQNCnwNCnwt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCnxEZSA6IGJlaGF2ZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmddIA0KfERlIGxhIHBhcnQgZGUgU2ltb24g UGVycmVhdWx0IEVudm95w6kgOiBtZXJjcmVkaSAxNiBtYXJzIDIwMTEgDQp8MTU6MjIgw4AgOiBi ZWhhdmVAaWV0Zi5vcmcgT2JqZXQgOiBSZTogW0JFSEFWRV0gQ0dOIFJFUTogUG9ydCANCnxTZXQg QXNzaWdubWVudA0KfA0KfE9uIDIwMTEtMDMtMTYgMDI6MTYsIG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS1mdGdyb3VwLmNvbSB3cm90ZToNCnw+IFRoZSBwb3J0IHNldCBkb2VzIG5vdCBtZWFucyBj b250aWd1b3VzIHBvcnQgcmFuZ2UuIFJhbmRvbSANCnxwb3J0IHNldCBjYW4gYmUgaGFuZGxlZCBi eSB0aGUgQ0dOLiBUaGlzIHNob3VsZCBiZSBleHBsaWNpdCBpbiANCnx0aGUgcmVxdWlyZW1lbnRz IElNTy4NCnw+IA0KfD4gSW4gZGVwbG95bWVudHMgd2hlcmUgYSBzbWFsbCBhZGRyZXNzIHNoYXJp bmcgcmF0aW9uIGlzIA0KfG5lZWRlZCAoZS5nLiwgMToyLCAxOjMpLCBwb3J0IHJhbmRvbWl6YXRp b24gaXMgc3RpbGwgcG9zc2libGUgDQp8d2l0aGluIHRoZSBsYXJnZSBwb3J0IHJhbmdlLg0KfD4g DQp8PiBUaGUgSS1EIGFscmVhZHkgZGlzY3Vzc2VzIHRoZSB0cmFkZS1vZmZzOg0KfD4gDQp8PiAg ICBTZWN1cml0eTogIE1lY2hhbmlzbXMgKDEpIGFuZCAoMikgcHJvdmlkZSB2ZXJ5IGdvb2QgDQp8 c2VjdXJpdHkgaW4gdGhhdA0KfD4gICAgICAgcG9ydHMgbnVtYmVycyBhcmUgbm90IGVhc2lseSBn dWVzc2VkLiAgRWFzaWx5IGd1ZXNzZWQgDQp8cG9ydCBudW1iZXJzDQp8PiAgICAgICBwdXQgc3Vi c2NyaWJlcnMgYXQgcmlzayBvZiB0aGUgYXR0YWNrcyBkZXNjcmliZWQgaW4gW1JGQzYwNTZdLg0K fD4gICAgICAgTWVjaGFuaXNtICgzKSBwcm92aWRlcyBwb29yIHNlY3VyaXR5IHRvIHN1YnNjcmli ZXJzLCANCnxlc3BlY2lhbGx5IGlmDQp8PiAgICAgICB0aGUgImJpbiIgc2l6ZSBpcyBzbWFsbC4N CnwNCnxJIHRoaW5rIGl0IHdpbGwgbmVlZCB0byBiZSBjaGFuZ2VkIGluIGxpZ2h0IG9mIHRoZSBh dHRhY2sgDQp8ZGVzY3JpYmVkIGJ5IERhbi4gVG8gbWUsICgyKSBkb2VzIG5vdCBhcHBlYXIgdG8g YmUgYXMgc2VjdXJlIA0KfGFzICgxKSBhbnltb3JlLg0KfA0KfFNpbW9uDQp8LS0NCnxEVE4gbWFk ZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUu Y2ENCnxOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAgICAgICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZp YWdlbmllLmNhDQp8U1RVTi9UVVJOIHNlcnZlciAgICAgICAgICAgICAgIC0tPiBodHRwOi8vbnVt Yi52aWFnZW5pZS5jYQ0KfF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp8QmVoYXZlIG1haWxpbmcgbGlzdA0KfEJlaGF2ZUBpZXRmLm9yZw0KfGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQp8DQo= From teemu.savolainen@nokia.com Mon Mar 21 04:23:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E933A67D2 for ; Mon, 21 Mar 2011 04:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 StA455v44pP5 for ; Mon, 21 Mar 2011 04:23:21 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 18BD73A6825 for ; Mon, 21 Mar 2011 04:23:20 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2LBOoSP012971; Mon, 21 Mar 2011 13:24:51 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 13:24:48 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 21 Mar 2011 12:24:48 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Mon, 21 Mar 2011 12:24:47 +0100 From: To: , , Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5YVrjmBmY1QaUUiMt5414UxLG5Q3nZig Date: Mon, 21 Mar 2011 11:24:47 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.21.125] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2011 11:24:48.0205 (UTC) FILETIME=[965187D0:01CBE7BA] X-Nokia-AV: Clean Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 11:23:22 -0000 Hi Paco, > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Paco Cortes > Sent: 17. maaliskuuta 2011 12:23 > To: Dave Thaler; behave@ietf.org > Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt >=20 > Hi, >=20 > A few comments: >=20 > 1) Section 4.3, quote "Source addresses: 172.21.112.0/30. Source > addresses have to be allocated because applications use getsockname() > calls and in the BIS=A0mode an IP address of the IPv4 interface has to > be shown ...": > Comment 1a: Should there be a description of the case of a applying > getscockname() to a socket to which a local IPv4 address has already > been bound via bind()? In that case, it should not be an address from > 172.21.112.0/30 that should be returned, but the real local IPv4 @ > previously bound to the socket, shouldn't it? Do you mean a case where a socket has been explicitly bound to a "real" IPv= 4 address of a local access network. In such a case the getsockname would h= ave to return that.=20 Now a question would be is it ok to transmit packets through BIH if the soc= ket was explicitly bound to a real IPv4 address? Probably the BIH would not= perform "source address validation", but the application might mistakenly = think it is not traversing through NAT, if the real IPv4 address happened t= o be from public pool.. > Comment 1b: What is the advantage of using a BIH specific address in > other cases? Why not just reusing a real IPv4 address of the host? To ensure application understands it is traversing through NAT.=20 To ensure there is no conflict between IP addresses used by the BIH and by = the access network. > 2) Section 4.3, quote "Secondary destination addresses: > 10.170.160.0/20. The address mapper will select destination addresses > out of this pool if the node has a dual-stack connection conflicting > with primary destination addresses". > Comment 2a: This does imply that IPv4 peer hosts might have addresses > belonging to the primary destination @ range 172.21.80.0/20 (should be > obvious, but the draft could assume that this might be prohibited in > the RFC1918 network where the host is located). > What shall be the behaviour of a host implementing BIH if the address > mapper has allocated an address from 172.21.80.0/20 (lets take > 172.21.80.1 as example) to an IPv6 socket, and later the host tries to > establish an IPv4 socket to an IPv4 peer with exactly that address > 172.21.80.1? > Can the BIH implementation somehow distinguish if the local host is > trying to connect to the real IPv4 host with address 172.21.80.1, or > if it is trying to connect to the IPv6 peer to which 172.21.80.1 was > assigned by the address mapper? Seeing a DNS responses with an A > record with address 172.21.80.1 could be used as indication, but it > doesn't really solve the ambiguity. Does this imply that BIH would > fully prevent any communication to a real IPv4 peer with address > 172.21.80.1? > If there is a way to distinguish the intended peer, should the BIH > implementation apply NAT44 to the destination to allow communication > (and getting things quite complex...). > The implied limitations and the preferred behavior of a BIH > implementation should be clearly stated. The application might get the 172.21.80.1 by non-DNS means as well, hence e= ven looking at DNS records might not help.=20 I see the draft is missing "secondary source addresses", in case the attach= ed network interface is numbered using IPv4 addresses from the same space a= s currently described. In the case of BIA, if the Address Mapper happens to have no entry matching= the IPv4 address, then the packet should be sent out as IPv4 packet. But o= nce an entry for 172.21.80.1 is created - the packets get translated. In the case of BIS, if the translator has no entry, the packet gets dropped= (unless the system is so wise that it forwards packets to BIS virtual inte= rface only when the packet are sent to addresses there are mappings). In any case, yes, **it happens sometimes.. Let's look how to document that. =20 > 3) Section 4.3, first paragraph, quote "For example, entries with the > longest inactivity time can be cleared and IPv4 addresses reused for > creating new entries.". > Comment 3a: this seems to imply that address mappings are kept fully > independent from a possible detection of end of communication (like > TCP RST, TCP FIN, ICMP 3, ...). Is this desirable/acceptable? > Shouldn't this proposed standard mandate mechanisms to limit the > liveness of address mappings? An application might do series of TCP connections to same destination, i.e. -> ask IP for name -> create TCP, close TCP -> create TCP, close TCP -> create TCP, close TCP The lifetime is somewhat difficult to limit, as it should not be shorter th= an the transport session lifetime... and it is not possible to tell how man= y connections application makes to the same destination. You are thinking of tradeoff between the lifetime of mapping and some (same= or different) application trying to talk to IPv4 destination having the sa= me address? > Please bear with me if similar comments were handled in past > discussions. There has not been such discussion in the past, so thank you:) Teemu From teemu.savolainen@nokia.com Mon Mar 21 04:52:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A99228C11C for ; Mon, 21 Mar 2011 04:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 Ptgb+ZanG5Uo for ; Mon, 21 Mar 2011 04:52:27 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 0071028C116 for ; Mon, 21 Mar 2011 04:52:26 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2LBrjNb023398; Mon, 21 Mar 2011 13:53:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 13:53:51 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 21 Mar 2011 12:53:51 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Mon, 21 Mar 2011 12:53:38 +0100 From: To: , Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5Zf5jmBmY1QaUUiMt5414UxLG5Q3qvTA Date: Mon, 21 Mar 2011 11:53:38 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.21.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2011 11:53:51.0077 (UTC) FILETIME=[A526B150:01CBE7BE] X-Nokia-AV: Clean Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 11:52:28 -0000 IPv4 literals can be used only after a mapping has been created between IPv= 4->IPv6.=20 So maybe clarify instead (in the appendix section): -- BIH MAY intercept inet_ntoa() and inet_addr() and use the address mapper fo= r those. Doing that enables BIH to support literal IP addresses. However, = IPv4 address literals can only be used after a mapping entry between the IP= v4 address and corresponding IPv6 address has been created. -- Btw this inet_ntoa/inet_addr text comes from the original BIA, and I have t= o admit I'm not sure what was the intent of the original authors. For me it= seems those functions just do conversion between IPv4 ASCII and IPv4 binar= y formats (and hence would not necessarily have to be here)... but if the "= BIA" would allow IPv6 string formats, then the inet_addr could maybe conver= t IPv6 textual presentation into IPv4 binary format (and create a new mappi= ng/use existing), but I don't see how inet_ntoa could convert IPv4 address = into IPv6 textual presentation without Address Mapper already having an ent= ry for that mapping. Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Cameron Byrne > Sent: 18. maaliskuuta 2011 20:12 > To: Dave Thaler > Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt >=20 > the draft states: >=20 > "The supported class of applications includes those that use DNS for > IP address resolution and that do not embed IP address literals in > protocol payloads." >=20 > I believe this wording is too strong and makes it sound like BIH > cannot support IPv4 literals, when later in the draft it is stated: >=20 > "BIH MAY intercept inet_ntoa() and inet_addr() and use the address > mapper for those. Doing that enables BIH to support literal IP > addresses." >=20 > I suggest this wording to make it clear that IPv4 literals may be > supported but embedded addresses with application signalling will pose > a challenge >=20 > "The supported class of applications includes those that use DNS for > IP address resolution. Direct references of outbound connections > to IPv4 literals are also may be support (ex: http://192.0.2.1)." > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From teemu.savolainen@nokia.com Mon Mar 21 06:07:25 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230C53A684A for ; Mon, 21 Mar 2011 06:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVaY8juHPuyU for ; Mon, 21 Mar 2011 06:07:24 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id E5E673A6767 for ; Mon, 21 Mar 2011 06:07:23 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2LD8UIA005573; Mon, 21 Mar 2011 15:08:51 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 15:08:27 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 21 Mar 2011 14:08:20 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Mon, 21 Mar 2011 14:08:20 +0100 From: To: Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5YVrjmBmY1QaUUiMt5414UxLG5Q3nZiggAAKvICAABO3gA== Date: Mon, 21 Mar 2011 13:08:20 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962FE95@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.21.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2011 13:08:27.0745 (UTC) FILETIME=[11740510:01CBE7C9] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 13:07:25 -0000 > > Do you mean a case where a socket has been explicitly bound to a > "real" IPv4 address of a local access network. In such a case the > getsockname would have to return that. >=20 > [Paco] Then the draft should explicitly say so. Ok, will clarify. But that kind of binding does not happen without applicat= ion explicitly binding it's sockets to some address. The implicit binding h= as knowledge of the destination address, and if the destination is syntheti= c the socket would be implicitly bound to "BIH address".=20 > [Paco] although probably/hopefully very seldom, there might be > applications with awareness of physical interfaces with several IP > addresses allocated, and which want to steer which source address is > used for a specific socket. Something like BIND where it can be > configured which address to use for zone transfers, for responses, ... Ok, but in that case application explicitly binds sockets to addresses it w= ants. > Such applications would just break if they issue a getsockname() and > get an unknown address back. Right, so it is clear that BIH should not change the address a socket has b= een bound to... but for me that is kind of obvious - at least I don't recal= l any case where socket address can change after being bound to something. > It can be questioned if it is "OK" to return the real IPv4 address to > which the socket was bound despite of it not really being used, but at > least then the application would try to continue and possibly work. > On the "mistakenly think it is not traversing through NAT", please see > my next comment. If the application asks getsockname() without bind/connect issued, it gets = just zero back. If application uses bind() to bind socket to local address,= then that's the sockets address and will be returned in subsequent calls. = If the application issues connect() without bind() first, then the OS selec= ts source address and if the destination was synthetic IPv4 address, the OS= would bind the socket to "BIH address". > >> Comment 1b: What is the advantage of using a BIH specific address in > >> other cases? Why not just reusing a real IPv4 address of the host? > > > > To ensure application understands it is traversing through NAT. >=20 > [Paco] I understand that the motivation behind BIH is to support > legacy applications. For any "legacy" NAT today, the application would > get a local IP address when using a getsockname(), regardless of NAT > taking place somewhere else or not.=20 Some applications make assumptions that if they have RFC1918 address, they = are behind NAT. If they get non-RFC1918 address they usually are not behind= NAT (but could be). > So, that a different new @ is > returned would only be an indication of using BIH and it would > therefore only be useful for a new application developed to detect > BIH. This is fully missing the purpose of IPv6 migration, isn't it? I may be missing your point.. We are not talking about apps detecting BIH, = but apps realizing they may be behind NAT. Let me put it another way...=20 What I was saying is that if your application explicitly binds socket to lo= cal public IPv4 address (say 192.0.2.1) and makes a name query for IPv6-onl= y server, for which BIH returns private address (say 172.21.80.1) and then = creates connection, it could not realize from its own address (192.0.2.1) t= hat there is NAT between it and the server. However, if application left socket unbound, and just issued connect to 172= .21.80.1, the BIH could implicitly bind the applications's socket to "BIH a= ddress" e.g. 172.21.112.1, which application could determine with getsockna= me, and do realize it is behind NAT. > [Paco] I agree. Even if DNS is used, it can only be a best guess if a > later system call is trying to use the "new" 172.21.80.1 got by DNS, > or the "old" one got from a getsockname(). Ah this case I forgot to reply. This can happen already without BIH so no n= ew from that pow. On multihoming case host can have 192.168.1.2 as its addr= ess while on another interface it gets 192.168.1.2 as a pointer to another = local host. Also non-BIH implementing host can move so that first it has on one interfa= ce 172.21.80.1 and when joining new WLAN it gets from DNS 172.21.80.1... With IPv4 and RFC1918 the hosts are just screwed with conflicting addresses= - and afaik there is no other working solution than IPv6.=20 > [Paco] actually I was assuming that the system had to be so wise. > Seeing that you have another interpretation, I would say that the > draft should also be explicit on this. > I.e., if a BIS implementation MUST, SHOULD, MAY, MUST NOT or SHOULD > NOT forward packets with a destination address within the ranges > 172.21.80.0/20 and 10.170.160.0/20 for which there is no entry in the > Address Mapper. I had assumed a "MUST", but your answer indicates a > "MAY". I had not really thought about that case in such detail. The socket layer B= IH option is simpler as it can rather easily to "not bump", so there we cou= ld have MUST NOT forward if no mapping entry. But the stack layer option is= more difficult as the IPv4 packet has already been created and sent, and i= t has arrived to virtual IPv4 interface. I'm not quite sure if the virtual = IPv4 interface can decide not to accept the packet and redirect it to the p= hysical IPv4 interface. Maybe it can do that.. Maybe say the virtual interf= ace SHOULD try to forward the packet to another IPv4 interface in case of n= o mapping entry? > [Paco] No, I am thinking of 4096 potential destination addresses > (172.21.80.0/20) not being sufficient for all potential destinations a > host might require traffic too between shut downs. A few hours > intensive web browsing, or a browser configured for pre-fetching of > content might very quickly reach that limit. The same could apply to > some peer to peer applications or other applications we have not > thought of. > And there is also the issue of hosts not being shut down for weeks. > The currently described mechanism of just taking the oldest mapping > sounds very suboptimal to me. That would require quite a lot of IPv6-only destinations for an IPv4-only a= pp... But the /20 was just something drawn out of the hat and that would b= e smaller to avoid conflicts. But I'm definitely ok for increasing the sugg= est (not mandated!) pool size, just please suggest something. Teemu From cb.list6@gmail.com Mon Mar 21 09:39:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A1628C0F4 for ; Mon, 21 Mar 2011 09:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgYaHZidHLKR for ; Mon, 21 Mar 2011 09:39:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4328228C0EB for ; Mon, 21 Mar 2011 09:39:46 -0700 (PDT) Received: by iwl42 with SMTP id 42so7732223iwl.31 for ; Mon, 21 Mar 2011 09:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q+Rw2Tj31sTCKEVZPFgKyMFe3miDlqjgNxyoZc5LbHA=; b=d2HMRzP1McjI+5bSqdLCYG24+5KS6ZwJXDwCvqgWC90xB84BnH10lo+NHrJOAbnLOP mo+8Nv0qcVLksYTecBtOTpr+x1VK6M/UQJ/kPd2wkOc4kR5uDOv4j9foaxczUQQ5GzhU wb+dCyDCJxjemgO2ewWjSGntsV/+Q7v8RiSSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qZ0XTmOMaMTt/UBbVkx6oHQ+Ot9KZmCC+aJYW+GLVD/lZtgMrkeUn9yx0hB8a/R8kT OItfPEGtUnRUY9ND5D+6yKpXrHLbt0W+Ci/e0HhdidEEwpZimGs/e56n+Nir+z/bPz4s sgzJL8zU6P6h6n43PDHfxxpBIaS4T/JvRsupE= MIME-Version: 1.0 Received: by 10.42.152.71 with SMTP id h7mr3277250icw.440.1300725630192; Mon, 21 Mar 2011 09:40:30 -0700 (PDT) Received: by 10.42.170.68 with HTTP; Mon, 21 Mar 2011 09:40:30 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> Date: Mon, 21 Mar 2011 09:40:30 -0700 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 16:39:47 -0000 On Mon, Mar 21, 2011 at 4:53 AM, wrote: > IPv4 literals can be used only after a mapping has been created between I= Pv4->IPv6. > Is it possible to initiate the mapper without DNS first ? Why must DNS be the only trigger? Cameron > So maybe clarify instead (in the appendix section): > -- > BIH MAY intercept inet_ntoa() and inet_addr() and use the address mapper = for those. =A0Doing that enables BIH to support literal IP addresses. Howev= er, IPv4 address literals can only be used after a mapping entry between th= e IPv4 address and corresponding IPv6 address has been created. > -- > Btw this inet_ntoa/inet_addr text comes from the original BIA, and I have= to admit I'm not sure what was the intent of the original authors. For me = it seems those functions just do conversion between IPv4 ASCII and IPv4 bin= ary formats (and hence would not necessarily have to be here)... but if the= "BIA" would allow IPv6 string formats, then the inet_addr could maybe conv= ert IPv6 textual presentation into IPv4 binary format (and create a new map= ping/use existing), but I don't see how inet_ntoa could convert IPv4 addres= s into IPv6 textual presentation without Address Mapper already having an e= ntry for that mapping. > > Best regards, > > =A0 =A0 =A0 =A0Teemu > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of ext Cameron Byrne >> Sent: 18. maaliskuuta 2011 20:12 >> To: Dave Thaler >> Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt >> >> the draft states: >> >> "The supported class of applications includes those that use DNS for >> =A0 =A0IP address resolution and that do not embed IP address literals i= n >> =A0 =A0protocol payloads." >> >> I believe this wording is too strong and makes it sound like BIH >> cannot support IPv4 literals, when later in the draft it is stated: >> >> "BIH MAY intercept inet_ntoa() and inet_addr() and use the address >> =A0 =A0mapper for those. =A0Doing that enables BIH to support literal IP >> =A0 =A0addresses." >> >> I suggest this wording to make it clear that IPv4 literals may be >> supported but embedded addresses with application signalling will pose >> =A0a challenge >> >> "The supported class of applications includes those that use DNS for >> =A0 =A0IP address resolution. =A0Direct references of outbound connectio= ns >> to IPv4 literals are also may be =A0support (ex: http://192.0.2.1)." >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Mon Mar 21 11:35:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DBC3A67AA for ; Mon, 21 Mar 2011 11:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.44 X-Spam-Level: X-Spam-Status: No, score=-110.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 HhH8QHmCNxwb for ; Mon, 21 Mar 2011 11:35:21 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 071293A659C for ; Mon, 21 Mar 2011 11:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1712; q=dns/txt; s=iport; t=1300732614; x=1301942214; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=5Q5Z2SR8jy51gwOu1X1OM0dHhUg3KVix1icjS5WFOvg=; b=bBUdmXE4u9QMAAEpheqLZPB0hzAdByHXORm6HwXjOwgVsX824w4YCSBG kLoT/2d/SLZTwhLNVsDg/ZCSI4srELt3xoTCwHeKmBH1c5zfP1kQoj1Y8 vZUe4zbOttv+NiZIrWmyK8YFnHxa5t0nfPW2Xb5k1l0AWmnNzkhKsFXAh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPc2h02rRDoJ/2dsb2JhbACZYYted4hNnUqcJIJ9gmYEhTM X-IronPort-AV: E=Sophos;i="4.63,220,1299456000"; d="scan'208";a="278846612" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2011 18:36:38 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2LIabwM010011; Mon, 21 Mar 2011 18:36:37 GMT From: "Dan Wing" To: , , References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> Date: Mon, 21 Mar 2011 11:36:37 -0700 Message-ID: <10ca01cbe7f6$e9a77cf0$bcf676d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHL5YVrjmBmY1QaUUiMt5414UxLG5Q3nZiggACEHtA= Content-language: en-us Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 18:35:22 -0000 > > 3) Section 4.3, first paragraph, quote "For example, entries with the > > longest inactivity time can be cleared and IPv4 addresses reused for > > creating new entries.". > > Comment 3a: this seems to imply that address mappings are kept fully > > independent from a possible detection of end of communication (like > > TCP RST, TCP FIN, ICMP 3, ...). Is this desirable/acceptable? > > Shouldn't this proposed standard mandate mechanisms to limit the > > liveness of address mappings? > > An application might do series of TCP connections to same destination, > i.e. > -> ask IP for name > -> create TCP, close TCP > -> create TCP, close TCP > -> create TCP, close TCP > > The lifetime is somewhat difficult to limit, as it should not be > shorter than the transport session lifetime... and it is not possible > to tell how many connections application makes to the same destination. It would be useful to point out in the I-D that some applications purposefully do that, so that BIH implementations have the proper guidance for when to destroy NAT46 state. As an example, web browsers purposefully do not look up the DNS name again, to protect themselves against DNS rebinding attacks. -d > You are thinking of tradeoff between the lifetime of mapping and some > (same or different) application trying to talk to IPv4 destination > having the same address? > > > Please bear with me if similar comments were handled in past > > discussions. > > There has not been such discussion in the past, so thank you:) > > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Mar 21 11:36:48 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DA93A67B5 for ; Mon, 21 Mar 2011 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.446 X-Spam-Level: X-Spam-Status: No, score=-110.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, 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 oa+R8YuulhFm for ; Mon, 21 Mar 2011 11:36:47 -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 437B03A659C for ; Mon, 21 Mar 2011 11:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3308; q=dns/txt; s=iport; t=1300732700; x=1301942300; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Wx6sT4xiJ2RE1wTs9ZjcVenp222OPSPn6iiUCpiJsAU=; b=mj1Zzvw7+lOHD3fsT9E6Bhtq91U7b536fLBKZ8lOYQivFeXf716JqwBN opKj+uCXywA9Pc0dxgS+9gwx1BkC4qQQL5dQX+F4tgheTt1OZE1dVCiNZ DG+YwjZIf8txPFP0Dcl+dXCtDR3JCXuZoRj8yzXsEQn36gj9v1i8+wyPE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAACM4h02rRDoI/2dsb2JhbACXfYFkiyQ6d6YgjmwBjTiFYwSFM44q X-IronPort-AV: E=Sophos;i="4.63,220,1299456000"; d="scan'208";a="349994001" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2011 18:38:20 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2LIcJtv031506; Mon, 21 Mar 2011 18:38:19 GMT From: "Dan Wing" To: , , References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> Date: Mon, 21 Mar 2011 11:38:19 -0700 Message-ID: <10cb01cbe7f7$2680e170$7382a450$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHL5Zf5jmBmY1QaUUiMt5414UxLG5Q3qvTAgAB37MA= Content-language: en-us Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 18:36:48 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of teemu.savolainen@nokia.com > Sent: Monday, March 21, 2011 4:54 AM > To: cb.list6@gmail.com; dthaler@microsoft.com > Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt > > IPv4 literals can be used only after a mapping has been created between > IPv4->IPv6. > > So maybe clarify instead (in the appendix section): > -- > BIH MAY intercept inet_ntoa() and inet_addr() and use the address > mapper for those. Doing that enables BIH to support literal IP > addresses. However, IPv4 address literals can only be used after a > mapping entry between the IPv4 address and corresponding IPv6 address > has been created. That text can't be an accurate description of the BIH deployed by China Mobile, which works with Skype. Skype doesn't do DNS queries for its DHT or for its peers. So, I believe the "DNS must be used first" restriction doesn't exist. -d > -- > Btw this inet_ntoa/inet_addr text comes from the original BIA, and I > have to admit I'm not sure what was the intent of the original authors. > For me it seems those functions just do conversion between IPv4 ASCII > and IPv4 binary formats (and hence would not necessarily have to be > here)... but if the "BIA" would allow IPv6 string formats, then the > inet_addr could maybe convert IPv6 textual presentation into IPv4 > binary format (and create a new mapping/use existing), but I don't see > how inet_ntoa could convert IPv4 address into IPv6 textual presentation > without Address Mapper already having an entry for that mapping. > > Best regards, > > Teemu > > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of ext Cameron Byrne > > Sent: 18. maaliskuuta 2011 20:12 > > To: Dave Thaler > > Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org; behave@ietf.org > > Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt > > > > the draft states: > > > > "The supported class of applications includes those that use DNS for > > IP address resolution and that do not embed IP address literals in > > protocol payloads." > > > > I believe this wording is too strong and makes it sound like BIH > > cannot support IPv4 literals, when later in the draft it is stated: > > > > "BIH MAY intercept inet_ntoa() and inet_addr() and use the address > > mapper for those. Doing that enables BIH to support literal IP > > addresses." > > > > I suggest this wording to make it clear that IPv4 literals may be > > supported but embedded addresses with application signalling will > pose > > a challenge > > > > "The supported class of applications includes those that use DNS for > > IP address resolution. Direct references of outbound connections > > to IPv4 literals are also may be support (ex: http://192.0.2.1)." > > _______________________________________________ > > 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 pacosaddress@googlemail.com Mon Mar 21 05:16:50 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDB728C116 for ; Mon, 21 Mar 2011 05:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZcgXO4RvxXQ for ; Mon, 21 Mar 2011 05:16:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BB5A228C0CE for ; Mon, 21 Mar 2011 05:16:48 -0700 (PDT) Received: by iyi12 with SMTP id 12so7399396iyi.31 for ; Mon, 21 Mar 2011 05:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e03xcSOHb1CYSNpVbZBgDcyo4eBtmJ5S/3WLNJeDxl8=; b=Ihg/BxSNRheV5Nx3M+sN40hvmwcbGyuzOe77B94dcu9nrLquxLMbV5CMV40pV75agZ eLWgBNnt1A1ThILpDu6hYpb6OcmN3Jc/ON3Z3RLdX7wEsO168D18foKBDQfy653O2F+D 1TSxMErbgur1T89JR8FkPpXF02CLYF9R7Aulo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GFapoQfMu7C6ooJtYq9vZmbttiav5vvAFBHMCxIASPnkiL0gFuyXHo3UnhPkznc7eT 5ZvzecYqSq/sfHDZXOtYJLj2p6KOLRsoxTUgbrKRCux4u7wCcJRCkBbU6fkMrd3kEg7l DHO99hsaGTyM32v87rqNlj49cdeOIP4Yw9pGk= MIME-Version: 1.0 Received: by 10.231.185.76 with SMTP id cn12mr4155775ibb.33.1300709901095; Mon, 21 Mar 2011 05:18:21 -0700 (PDT) Received: by 10.231.160.21 with HTTP; Mon, 21 Mar 2011 05:18:21 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> Date: Mon, 21 Mar 2011 13:18:21 +0100 Message-ID: From: Paco Cortes To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Mar 2011 12:11:38 -0700 Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 21 Mar 2011 12:16:50 -0000 Hi Teemu, please, see my comments below. 2011/3/21 : > Hi Paco, > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of ext Paco Cortes >> Sent: 17. maaliskuuta 2011 12:23 >> To: Dave Thaler; behave@ietf.org >> Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt >> >> Hi, >> >> A few comments: >> >> 1) Section 4.3, quote "Source addresses: 172.21.112.0/30. Source >> addresses have to be allocated because applications use getsockname() >> calls and in the BIS=A0mode an IP address of the IPv4 interface has to >> be shown ...": >> Comment 1a: Should there be a description of the case of a applying >> getscockname() to a socket to which a local IPv4 address has already >> been bound via bind()? In that case, it should not be an address from >> 172.21.112.0/30 that should be returned, but the real local IPv4 @ >> previously bound to the socket, shouldn't it? > > Do you mean a case where a socket has been explicitly bound to a "real" I= Pv4 address of a local access network. In such a case the getsockname would= have to return that. [Paco] Then the draft should explicitly say so. > Now a question would be is it ok to transmit packets through BIH if the s= ocket was explicitly bound to a real IPv4 address? Probably the BIH would n= ot perform "source address validation", but the application might mistakenl= y think it is not traversing through NAT, if the real IPv4 address happened= to be from public pool.. [Paco] although probably/hopefully very seldom, there might be applications with awareness of physical interfaces with several IP addresses allocated, and which want to steer which source address is used for a specific socket. Something like BIND where it can be configured which address to use for zone transfers, for responses, ... Such applications would just break if they issue a getsockname() and get an unknown address back. It can be questioned if it is "OK" to return the real IPv4 address to which the socket was bound despite of it not really being used, but at least then the application would try to continue and possibly work. On the "mistakenly think it is not traversing through NAT", please see my next comment. > >> Comment 1b: What is the advantage of using a BIH specific address in >> other cases? Why not just reusing a real IPv4 address of the host? > > To ensure application understands it is traversing through NAT. [Paco] I understand that the motivation behind BIH is to support legacy applications. For any "legacy" NAT today, the application would get a local IP address when using a getsockname(), regardless of NAT taking place somewhere else or not. So, that a different new @ is returned would only be an indication of using BIH and it would therefore only be useful for a new application developed to detect BIH. This is fully missing the purpose of IPv6 migration, isn't it? > To ensure there is no conflict between IP addresses used by the BIH and b= y the access network. > >> 2) Section 4.3, quote "Secondary destination addresses: >> 10.170.160.0/20. =A0The address mapper will select destination addresses >> out of this pool if the node has a dual-stack connection conflicting >> with primary destination addresses". >> Comment 2a: This does imply that IPv4 peer hosts might have addresses >> belonging to the primary destination @ range 172.21.80.0/20 (should be >> obvious, but the draft could assume that this might be prohibited in >> the RFC1918 network where the host is located). >> What shall be the behaviour of a host implementing BIH if the address >> mapper has allocated an address from 172.21.80.0/20 (lets take >> 172.21.80.1 as example) to an IPv6 socket, and later the host tries to >> establish an IPv4 socket to an IPv4 peer with exactly that address >> 172.21.80.1? >> Can the BIH implementation somehow distinguish if the local host is >> trying to connect to the real IPv4 host with address 172.21.80.1, or >> if it is trying to connect to the IPv6 peer to which 172.21.80.1 was >> assigned by the address mapper? Seeing a DNS responses with an A >> record with address 172.21.80.1 could be used as indication, but it >> doesn't really solve the ambiguity. Does this imply that BIH would >> fully prevent any communication to a real IPv4 peer with address >> 172.21.80.1? >> If there is a way to distinguish the intended peer, should the BIH >> implementation apply NAT44 to the destination to allow communication >> (and getting things quite complex...). >> The implied limitations and the preferred behavior of a BIH >> implementation should be clearly stated. > > The application might get the 172.21.80.1 by non-DNS means as well, hence= even looking at DNS records might not help. [Paco] I agree. Even if DNS is used, it can only be a best guess if a later system call is trying to use the "new" 172.21.80.1 got by DNS, or the "old" one got from a getsockname(). > > I see the draft is missing "secondary source addresses", in case the atta= ched network interface is numbered using IPv4 addresses from the same space= as currently described. > > In the case of BIA, if the Address Mapper happens to have no entry matchi= ng the IPv4 address, then the packet should be sent out as IPv4 packet. But= once an entry for 172.21.80.1 is created - the packets get translated. > > In the case of BIS, if the translator has no entry, the packet gets dropp= ed (unless the system is so wise that it forwards packets to BIS virtual in= terface only when the packet are sent to addresses there are mappings). [Paco] actually I was assuming that the system had to be so wise. Seeing that you have another interpretation, I would say that the draft should also be explicit on this. I.e., if a BIS implementation MUST, SHOULD, MAY, MUST NOT or SHOULD NOT forward packets with a destination address within the ranges 172.21.80.0/20 and 10.170.160.0/20 for which there is no entry in the Address Mapper. I had assumed a "MUST", but your answer indicates a "MAY". > In any case, yes, **it happens sometimes.. Let's look how to document tha= t. [Paco] Yes, that was my point. I understand that this problem is unavoidable as long as RFC1918 @s are used, but I missing a clear description of the implications. >> 3) Section 4.3, first paragraph, quote "For example, entries with the >> longest inactivity time can be cleared and IPv4 addresses reused for >> creating new entries.". >> Comment 3a: this seems to imply that address mappings are kept fully >> independent from a possible detection of end of communication (like >> TCP RST, TCP FIN, ICMP 3, ...). Is this desirable/acceptable? >> Shouldn't this proposed standard mandate mechanisms to limit the >> liveness of address mappings? > > An application might do series of TCP connections to same destination, i.= e. > -> ask IP for name > -> create TCP, close TCP > -> create TCP, close TCP > -> create TCP, close TCP > > The lifetime is somewhat difficult to limit, as it should not be shorter = than the transport session lifetime... and it is not possible to tell how m= any connections application makes to the same destination. > > You are thinking of tradeoff between the lifetime of mapping and some (sa= me or different) application trying to talk to IPv4 destination having the = same address? [Paco] No, I am thinking of 4096 potential destination addresses (172.21.80.0/20) not being sufficient for all potential destinations a host might require traffic too between shut downs. A few hours intensive web browsing, or a browser configured for pre-fetching of content might very quickly reach that limit. The same could apply to some peer to peer applications or other applications we have not thought of. And there is also the issue of hosts not being shut down for weeks. The currently described mechanism of just taking the oldest mapping sounds very suboptimal to me. >> Please bear with me if similar comments were handled in past >> discussions. > > There has not been such discussion in the past, so thank you:) > > Teemu > From dwing@cisco.com Mon Mar 21 12:14:39 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2383A6840 for ; Mon, 21 Mar 2011 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 uLc8iXILjL05 for ; Mon, 21 Mar 2011 12:14:38 -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 A30E13A682E for ; Mon, 21 Mar 2011 12:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1947; q=dns/txt; s=iport; t=1300734971; x=1301944571; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=MuNh/EC0i3qzIXpQfwa2PlaF2jGDCB8/sCTw/KMGUVg=; b=JAdC5pA6pp+t4Ybg1HWWjXkxGqdPPDrbsDGAW2FB6R9pJzLkuAZEhUBj bxebi+5sGn5Sa9quew/YGnO4t8UNCniHi7upsOelL/1ycQ+tQnePbIr3i jqqI63/PaR9UN0FnSh4/8knE/lIqtozqEca0HAI3pfEdDnAUbV2UnKIyf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0HAFZAh02rRDoJ/2dsb2JhbACYPIEli153pk2cKYVjBIUz X-IronPort-AV: E=Sophos;i="4.63,220,1299456000"; d="scan'208";a="350035433" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2011 19:15:53 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2LJFrO6023971; Mon, 21 Mar 2011 19:15:53 GMT From: "Dan Wing" To: Date: Mon, 21 Mar 2011 12:15:53 -0700 Message-ID: <114b01cbe7fc$65e607a0$31b216e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvn/GWdDSpQBeoLRpStuoiFxUunpw== Content-language: en-us Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 Mar 2011 19:14:39 -0000 Requirements documents are notoriously difficult, across the industry and across life in general ("the new bicycle MUST have 24 gears"). There appears to be considerable scope creep with the CGN Requirements document, for which I am partially guilty. My desire is to get this document published, and I had thought we were close to finishing the document until Simon's update caused a flurry of new CGN requirements to be considered. The general theme for the document is that the CGN should be "fair". That was the reason for the initial CGN-specific requirement which is that a subscriber be limited to a certain number of IPv4 ports -- to prevent one user from denying service to other legitimate users. Dave and I have discussed the organization of the document in the past, and the following two tenets seem pretty valuable in scoping the document: * if a requirement is specific to a Carrier Grade NAT, it should be a new requirement in the document. For example, restricting a user to a certain number of ports. * if a requirement is not specific to a Carrier Grade NAT, it should not be a _new_ requirement in the document. Instead, the document should reference an existing requirement. For example, the TCP behavior of a CGN can be described by BEHAVE's existing TCP behavior document, RFC5382. For example, hold-down timers is not specific to a CGN (because existing NAPT would have similar or identical requirements), and TCP/25 filtering is not specific to a CGN (as evidenced by ISPs filtering TCP/25 without deploying a CGN). For example, new logging requirements caused by IPv4 address sharing is well-described by other IETF documents which can be cited. In addition to the follow-ups on the mailing list from this email, I added 10 minutes to BEHAVE's agenda in Prague to discuss scoping the CGN Requirements document. -d From teemu.savolainen@nokia.com Tue Mar 22 00:31:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45B43A6950 for ; Tue, 22 Mar 2011 00:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 tSrsi070Uict for ; Tue, 22 Mar 2011 00:31:49 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id B2F023A693C for ; Tue, 22 Mar 2011 00:31:48 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2M7XFvt028047; Tue, 22 Mar 2011 09:33:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 09:33:11 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 22 Mar 2011 08:33:10 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 08:33:08 +0100 From: To: , Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5Zf5jmBmY1QaUUiMt5414UxLG5Q3qvTAgABGeQCAAQc4YA== Date: Tue, 22 Mar 2011 07:33:07 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2011 07:33:11.0802 (UTC) FILETIME=[65D475A0:01CBE863] X-Nokia-AV: Clean Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 07:31:50 -0000 Hi Cameron, Dan, > -----Original Message----- > From: ext Cameron Byrne [mailto:cb.list6@gmail.com] >=20 > Is it possible to initiate the mapper without DNS first ? Why must > DNS be the only trigger? and > -----Original Message----- > From: ext Dan Wing [mailto:dwing@cisco.com] > > That text can't be an accurate description of the BIH deployed by China > Mobile, which works with Skype. Skype doesn't do DNS queries for > its DHT or for its peers. >=20 > So, I believe the "DNS must be used first" restriction doesn't exist. If I recall behave's earlier discussions correctly, it was agreed that the = specification developed in behave is to be scoped only for DNS using legacy= applications. Hence restriction comes from this WG and that is why BIH dra= ft says what is says. This is not technical restriction, as you can clearly= see from implementations (I know of two different). Would you then like to see some additional text in the section "2.4 Address= Mapper" such as: -- "(4) The Address Mapper MAY also allow creation of mapping table entries vi= a implementation specific means" -- ? Teemu From cb.list6@gmail.com Tue Mar 22 00:57:41 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48993A6767 for ; Tue, 22 Mar 2011 00:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr5HCAfj1rBj for ; Tue, 22 Mar 2011 00:57:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AE86B3A63CB for ; Tue, 22 Mar 2011 00:57:40 -0700 (PDT) Received: by iwl42 with SMTP id 42so8473191iwl.31 for ; Tue, 22 Mar 2011 00:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yfAC/JHfCXhSat8ikuEx1PrLVUoygb0yHe3dJjPMc3U=; b=dh3b3RAoxM3lOI8fvE5XBRbI6OfXdKpTAG8JmrqmnWqY0KH0hPsoQDsxlnaAEIWxpx ziz11P5SMHGKfz03XDUbPl2WsCKwfXRxezHWJwaJ2MMXseHsN/gOaO9NZCRnTOJ5HNFo XLeLlz31W4cCs4Nm/UZAHqPRAaRD1J8hp2mHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CHoX5AtboH6ozfd2Isy7gS/QPhXyJ8hRBhMTXHoPNxqgfq4LbCexkjVPvaIw6AHmh3 bZSsqDdN54TFnsNTjl4uOztHRrpaEqVyEOZ7WbNfUEi5oBL7bRJLvkIdYaE/teprLTiw gkg4KIX8j9BD8TOw7EJee9HQJaNy+5We4ERpM= MIME-Version: 1.0 Received: by 10.42.137.130 with SMTP id y2mr5833969ict.486.1300780753591; Tue, 22 Mar 2011 00:59:13 -0700 (PDT) Received: by 10.42.39.1 with HTTP; Tue, 22 Mar 2011 00:59:13 -0700 (PDT) Received: by 10.42.39.1 with HTTP; Tue, 22 Mar 2011 00:59:13 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> Date: Tue, 22 Mar 2011 00:59:13 -0700 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=90e6ba212471bf9c2d049f0d9e49 Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dwing@cisco.com, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 07:57:41 -0000 --90e6ba212471bf9c2d049f0d9e49 Content-Type: text/plain; charset=ISO-8859-1 On Mar 22, 2011 12:33 AM, wrote: > > Hi Cameron, Dan, > > > -----Original Message----- > > From: ext Cameron Byrne [mailto:cb.list6@gmail.com] > > > > Is it possible to initiate the mapper without DNS first ? Why must > > DNS be the only trigger? > > and > > > -----Original Message----- > > From: ext Dan Wing [mailto:dwing@cisco.com] > > > > That text can't be an accurate description of the BIH deployed by China > > Mobile, which works with Skype. Skype doesn't do DNS queries for > > its DHT or for its peers. > > > > So, I believe the "DNS must be used first" restriction doesn't exist. > > If I recall behave's earlier discussions correctly, it was agreed that the specification developed in behave is to be scoped only for DNS using legacy applications. Hence restriction comes from this WG and that is why BIH draft says what is says. This is not technical restriction, as you can clearly see from implementations (I know of two different). > > Would you then like to see some additional text in the section "2.4 Address Mapper" such as: > -- > "(4) The Address Mapper MAY also allow creation of mapping table entries via implementation specific means" > -- > Yes. Why not be more specific as well? This vague language to describe obvious functionality will be confusing. Cb > ? > > Teemu --90e6ba212471bf9c2d049f0d9e49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 22, 2011 12:33 AM, <teemu.savolainen@nokia.com> wrote:
>
> Hi Cameron, Dan,
>
> > -----Original Message-----
> > From: ext Cameron Byrne [mailto:cb.list6@gmail.com]
> >
> > Is it possible to initiate the mapper without DNS first ? =A0Why = must
> > DNS be the only trigger?
>
> and
>
> > -----Original Message-----
> > From: ext Dan Wing [mailto:dwi= ng@cisco.com]
> >
> > That text can't be an accurate description of the BIH deploye= d by China
> > Mobile, which works with Skype. =A0Skype doesn't do DNS queri= es for
> > its DHT or for its peers.
> >
> > So, I believe the "DNS must be used first" restriction = doesn't exist.
>
> If I recall behave's earlier discussions correctly, it was agreed = that the specification developed in behave is to be scoped only for DNS usi= ng legacy applications. Hence restriction comes from this WG and that is wh= y BIH draft says what is says. This is not technical restriction, as you ca= n clearly see from implementations (I know of two different).
>
> Would you then like to see some additional text in the section "2= .4 Address Mapper" such as:
> --
> "(4) The Address Mapper MAY also allow creation of mapping table = entries via implementation specific means"
> --
>

Yes. Why not be more specific as well? This vague language to describe o= bvious functionality will be confusing.

Cb

> ?
>
> Teemu

--90e6ba212471bf9c2d049f0d9e49-- From pacosaddress@googlemail.com Tue Mar 22 04:33:37 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8913A67B7 for ; Tue, 22 Mar 2011 04:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 669buXsz4VeL for ; Tue, 22 Mar 2011 04:33:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 63ED63A6826 for ; Tue, 22 Mar 2011 04:33:36 -0700 (PDT) Received: by iwl42 with SMTP id 42so8690105iwl.31 for ; Tue, 22 Mar 2011 04:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uYwG42v5MVIKO3PrNJhhcfvZtD/TBB6Kp2NX0ceQoeQ=; b=P5tARih1+wZyhTl8AQ/uZSRBvNgpLnGP7yRmYg7ROJXyjKMYFcBSq26uv7RwjWm0gK rnX3gkau7bKC4DA9opAIXY1JhFs3476IKMaq+JMEHHxT3ez5RqqnGgVLuy0EQuqeq48j Kelv/9G10OTmV8Ga29L3Y9tJ3lAAUP3W0savQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oYZ8ygObMuhO6zD+DaqTojdkKPABt/+MvVX9pXRDDiEHlzQ4wMwddYjiu3ZEWABHqo yC9jNxyApZ7DL1cvwCxAzftrPN9r2Ewt7G95hwZkH/6v1XJmTQS5ntMHFNOj/Q8TDYpx OFN6piubY78Wh/lpXhU38QLbOCMwf6yhRLMBk= MIME-Version: 1.0 Received: by 10.43.54.133 with SMTP id vu5mr2751200icb.36.1300793709418; Tue, 22 Mar 2011 04:35:09 -0700 (PDT) Received: by 10.231.160.21 with HTTP; Tue, 22 Mar 2011 04:35:09 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962FE95@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962FE95@008-AM1MPN1-036.mgdnok.nokia.com> Date: Tue, 22 Mar 2011 12:35:09 +0100 Message-ID: From: Paco Cortes To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 11:33:38 -0000 Hi Teemu, > Ok, will clarify. But that kind of binding does not happen without applic= ation explicitly binding it's sockets to some address. The implicit binding= has knowledge of the destination address, and if the destination is synthe= tic the socket would be implicitly bound to "BIH address". What do you mean with "if the destination is synthetic the socket would be implicitly bound to "BIH address"? Do you mean that if the destination is synthetic, an implementation shall return also a synthetic source IP address from 172.21.80.0/20 even if the socket was bound at creation to let's say 10.10.10.10? I believe that there should be no such exceptions for the reasons already explained. > >> >> Comment 1b: What is the advantage of using a BIH specific address in >> >> other cases? Why not just reusing a real IPv4 address of the host? >> > >> > To ensure application understands it is traversing through NAT. >> >> [Paco] I understand that the motivation behind BIH is to support >> legacy applications. For any "legacy" NAT today, the application would >> get a local IP address when using a getsockname(), regardless of NAT >> taking place somewhere else or not. > > Some applications make assumptions that if they have RFC1918 address, the= y are behind NAT. If they get non-RFC1918 address they usually are not behi= nd NAT (but could be). Ok, now I get what you meant with understanding it is traversing through NA= T. I was assuming that more often than not the host would already have RFC1928 addresses on their local interfaces. For such cases I see no added value on using 172.21.112.0/30 addresses, but just problems potential. But maybe this is an acceptable compromise if it eases implementations. > However, if application left socket unbound, and just issued connect to 1= 72.21.80.1, the BIH could implicitly bind the applications's socket to "BIH= address" e.g. 172.21.112.1, which application could determine with getsock= name, and do realize it is behind NAT. > >> [Paco] I agree. Even if DNS is used, it can only be a best guess if a >> later system call is trying to use the "new" 172.21.80.1 got by DNS, >> or the "old" one got from a getsockname(). > > Ah this case I forgot to reply. This can happen already without BIH so no= new from that pow. On multihoming case host can have 192.168.1.2 as its ad= dress while on another interface it gets 192.168.1.2 as a pointer to anothe= r local host. Here I disagree. Without BIH this should never happen unless the network is completely messed up. Host are not just multihomed to different RFC1918 networks under different administrations without NATing or address plan alignment, and single administrations do not design their networks with overlapping addresses. This problem could happen on a wrongly design network, or when interconnecting devices with hardcoded addresses, but this should not be a justification for a new I-D to also create this problem without highlighting it because it could also occur in other cases. >> [Paco] actually I was assuming that the system had to be so wise. >> Seeing that you have another interpretation, I would say that the >> draft should also be explicit on this. >> I.e., if a BIS implementation MUST, SHOULD, MAY, MUST NOT or SHOULD >> NOT forward packets with a destination address within the ranges >> 172.21.80.0/20 and 10.170.160.0/20 for which there is no entry in the >> Address Mapper. I had assumed a "MUST", but your answer indicates a >> "MAY". > > I had not really thought about that case in such detail. The socket layer= BIH option is simpler as it can rather easily to "not bump", so there we c= ould have MUST NOT forward if no mapping entry. But the stack layer option = is more difficult as the IPv4 packet has already been created and sent, and= it has arrived to virtual IPv4 interface. I'm not quite sure if the virtua= l IPv4 interface can decide not to accept the packet and redirect it to the= physical IPv4 interface. Maybe it can do that.. Maybe say the virtual inte= rface SHOULD try to forward the packet to another IPv4 interface in case of= no mapping entry? That's ok for me. My concern with the current version of the draft is that it is not stated at all. > That would require quite a lot of IPv6-only destinations for an IPv4-only= app... =A0But the /20 was just something drawn out of the hat and that wou= ld be smaller to avoid conflicts. But I'm definitely ok for increasing the = suggest (not mandated!) pool size, just please suggest something. My suggestion is not to increase the pool size, but to mandate or at least recommend the usage of mechanisms to remove unused sessions. You pointed out that it is not as easy as using TCP RST or TCP FIN due to recurrent connections to the same address, but this does not prevent using a timer in addition. And there are a number of well known and proven mechanism used by NAT devices today. I would add a SHOULD or even a MUST in the first paragraph of 4.3 where you write about "smart management techniques of the address pool". Sorry about being a bit picky on some requirements. I do understand that some of the issues I'm commenting are due to the wish to simplify possible implementations. But as this I-D is intended for the standards-track as opposed to becoming an informational RFC, I think that it should meet a high standard. Paco From teemu.savolainen@nokia.com Tue Mar 22 07:29:37 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6FC28C128 for ; Tue, 22 Mar 2011 07:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 G1XN6Aam06Te for ; Tue, 22 Mar 2011 07:29:36 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 329DE28C113 for ; Tue, 22 Mar 2011 07:29:36 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2MEV3ao011247; Tue, 22 Mar 2011 16:31:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 16:31:03 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 22 Mar 2011 15:31:03 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 15:31:02 +0100 From: To: Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5YVrjmBmY1QaUUiMt5414UxLG5Q3nZiggAAKvICAABO3gIABcoyAgAA+8aA= Date: Tue, 22 Mar 2011 14:31:02 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962011338@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962FE95@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.68.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2011 14:31:03.0914 (UTC) FILETIME=[C5F924A0:01CBE89D] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 14:29:37 -0000 > What do you mean with "if the destination is synthetic the socket > would be implicitly bound to "BIH address"? > Do you mean that if the destination is synthetic, an implementation > shall return also a synthetic source IP address from 172.21.80.0/20 > even if the socket was bound at creation to let's say 10.10.10.10? > I believe that there should be no such exceptions for the reasons > already explained. I tried to say unbound socket would be bound to BIH address. No touching to= already bound sockets addresses. > Ok, now I get what you meant with understanding it is traversing > through NAT. > I was assuming that more often than not the host would already have > RFC1928 addresses on their local interfaces. > For such cases I see no added value on using 172.21.112.0/30 > addresses, but just problems potential. But maybe this is an > acceptable compromise if it eases implementations. Well, in BIS mode the virtual interface has to have some address on it, rig= ht? Maybe you could avoid virtual interface on some implementations, and ju= st "catch" the packets that need to be translated.=20 On the other hand, if you would use the physical address of the link, what = if the IPv4 on the link dies or renumbers for some reason? That would impac= t to translated session. I would leave some room for implementations as well, that is why the draft = recommends but not mandates addresses. > > Ah this case I forgot to reply. This can happen already without BIH > so no new from that pow. On multihoming case host can have 192.168.1.2 > as its address while on another interface it gets 192.168.1.2 as a > pointer to another local host. >=20 > Here I disagree. Without BIH this should never happen unless the > network is completely messed up. > Host are not just multihomed to different RFC1918 networks under > different administrations without NATing or address plan alignment, > and single administrations do not design their networks with > overlapping addresses. Please join MIF WG for that discussion. E.g. your cellphone may perfectly c= onnect to WLAN and cellular networks that have different admins and both th= ink it is a good idea to number host as 192.168.1.2. > This problem could happen on a wrongly design network, or when > interconnecting devices with hardcoded addresses, but this should not > be a justification for a new I-D to also create this problem without > highlighting it because it could also occur in other cases. The big (but not the only) reason current smartphones don't do WLAN and cel= lular at the same time is overlapping RFC1918 addresses. And it is not beca= use of wrongly designed networks. > That's ok for me. My concern with the current version of the draft is > that it is not stated at all. I will do my best to collect these concerns into the BIH presentation at be= have. Then do update. > My suggestion is not to increase the pool size, but to mandate or at > least recommend the usage of mechanisms to remove unused sessions. > You pointed out that it is not as easy as using TCP RST or TCP FIN due > to recurrent connections to the same address, but this does not > prevent using a timer in addition. And there are a number of well > known and proven mechanism used by NAT devices today. > I would add a SHOULD or even a MUST in the first paragraph of 4.3 > where you write about "smart management techniques of the address > pool". That is fine for me as well. Are there some nice reference that describes s= uch techniques? > Sorry about being a bit picky on some requirements. I do understand > that some of the issues I'm commenting are due to the wish to simplify > possible implementations. But as this I-D is intended for the > standards-track as opposed to becoming an informational RFC, I think > that it should meet a high standard. No prob - the WG doc should reflect WG consensus:) Keep comments rolling in= :) Teemu From teemu.savolainen@nokia.com Tue Mar 22 07:50:20 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FD228C138 for ; Tue, 22 Mar 2011 07:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C26DUsTQcyO2 for ; Tue, 22 Mar 2011 07:50:15 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id BC42228C137 for ; Tue, 22 Mar 2011 07:50:13 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2MEpfZL001908; Tue, 22 Mar 2011 16:51:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 16:51:36 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 22 Mar 2011 15:51:35 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 15:51:35 +0100 From: To: Thread-Topic: RE: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5Zf5jmBmY1QaUUiMt5414UxLG5Q3qvTAgABGeQCAAQc4YP//+XiAgAB+RJA= Date: Tue, 22 Mar 2011 14:51:34 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962011385@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.68.126] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962011385008AM1MPN1036mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2011 14:51:36.0173 (UTC) FILETIME=[A474F1D0:01CBE8A0] X-Nokia-AV: Clean Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dwing@cisco.com, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 14:50:20 -0000 --_000_916CE6CF87173740BC8A2CE443096962011385008AM1MPN1036mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the current text in the draft is quite specific:"those that use DNS= for IP address resolution and that do not embed IP address literals in pro= tocol payloads ". This work is limited by the charter: -- Submit to IESG: host-based NAT46 translation for IPv4-only applications to = access IPv6-only servers (std) -- Hence I don't really see what the more specific text there could be? I mean we can't describe what the NAT64d actually implements, because it im= plements features outside of behave WG scope.. Teemu From: ext Cameron Byrne [mailto:cb.list6@gmail.com] Sent: 22. maaliskuuta 2011 09:59 To: Savolainen Teemu (Nokia-MS/Tampere) Cc: dthaler@microsoft.com; behave@ietf.org; draft-ietf-behave-v4v6-bih@tool= s.ietf.org; dwing@cisco.com Subject: Re: RE: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt On Mar 22, 2011 12:33 AM, > wrote: > > Hi Cameron, Dan, > > > -----Original Message----- > > From: ext Cameron Byrne [mailto:cb.list6@gmail.com] > > > > Is it possible to initiate the mapper without DNS first ? Why must > > DNS be the only trigger? > > and > > > -----Original Message----- > > From: ext Dan Wing [mailto:dwing@cisco.com] > > > > That text can't be an accurate description of the BIH deployed by China > > Mobile, which works with Skype. Skype doesn't do DNS queries for > > its DHT or for its peers. > > > > So, I believe the "DNS must be used first" restriction doesn't exist. > > If I recall behave's earlier discussions correctly, it was agreed that th= e specification developed in behave is to be scoped only for DNS using lega= cy applications. Hence restriction comes from this WG and that is why BIH d= raft says what is says. This is not technical restriction, as you can clear= ly see from implementations (I know of two different). > > Would you then like to see some additional text in the section "2.4 Addre= ss Mapper" such as: > -- > "(4) The Address Mapper MAY also allow creation of mapping table entries = via implementation specific means" > -- > Yes. Why not be more specific as well? This vague language to describe obvi= ous functionality will be confusing. Cb > ? > > Teemu --_000_916CE6CF87173740BC8A2CE443096962011385008AM1MPN1036mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the current text in the draft is quite specific:R= 21;those that use DNS for IP address resolution and that do not embed IP ad= dress literals in protocol payloads ”.

 

This work is limited by the charter:

--

Submit to IESG: host-based NAT46 translation for IPv4-only a= pplications to access IPv6-only servers (std)

--

 

Hence I don’t really see what the more specific text t= here could be?

 

I mean we can’t describe what the NAT64d actually impl= ements, because it implements features outside of behave WG scope..

 

Teemu=

 

 

From: ext Came= ron Byrne [mailto:cb.list6@gmail.com]
Sent: 22. maaliskuuta 2011 09:59
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: dthaler@microsoft.com; behave@ietf.org; draft-ietf-behave-v4v6-b= ih@tools.ietf.org; dwing@cisco.com
Subject: Re: RE: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt

 


On Mar 22, 2011 12:33 AM, <teemu.savolainen@nokia.com> wrote:
>
> Hi Cameron, Dan,
>
> > -----Original Message-----
> > From: ext Cameron Byrne [mailto:cb.list6@gmail.com]
> >
> > Is it possible to initiate the mapper without DNS first ?  W= hy must
> > DNS be the only trigger?
>
> and
>
> > -----Original Message-----
> > From: ext Dan Wing [mailto:dwi= ng@cisco.com]
> >
> > That text can't be an accurate description of the BIH deployed by= China
> > Mobile, which works with Skype.  Skype doesn't do DNS querie= s for
> > its DHT or for its peers.
> >
> > So, I believe the "DNS must be used first" restriction = doesn't exist.
>
> If I recall behave's earlier discussions correctly, it was agreed that= the specification developed in behave is to be scoped only for DNS using l= egacy applications. Hence restriction comes from this WG and that is why BI= H draft says what is says. This is not technical restriction, as you can clearly see from implementations (I = know of two different).
>
> Would you then like to see some additional text in the section "2= .4 Address Mapper" such as:
> --
> "(4) The Address Mapper MAY also allow creation of mapping table = entries via implementation specific means"
> --
>

Yes. Why not be more specific as well? This vague language to describe o= bvious functionality will be confusing.

Cb

> ?
>
> Teemu

--_000_916CE6CF87173740BC8A2CE443096962011385008AM1MPN1036mgdn_-- From pacosaddress@googlemail.com Tue Mar 22 08:56:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B803A6359 for ; Tue, 22 Mar 2011 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcVM2ZfSkwaQ for ; Tue, 22 Mar 2011 08:55:54 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id ABE1F3A63CA for ; Tue, 22 Mar 2011 08:55:54 -0700 (PDT) Received: by gxk19 with SMTP id 19so3521648gxk.31 for ; Tue, 22 Mar 2011 08:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n0q+7Yu5SZJ1oR3yn+jLWTcFKdk9DKmMzZ9Dk1rclXg=; b=enXjDlW2n6u86OUDtJH/7OWbsEdgN7r0P0bRpTyNSvc9HDzxRx4YlShzKLlfn9LhXy du7vXfTciNHIs1206gyYssgiL0KSVgvYvWjLlnIphKeHfStYfPWgU6V94FG6TIc81kLl JFXCrsgcgo2ieP7oI83rglZLIFO7cxJZ1VPfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=reU6ID4FZY2KveiRT0IN/K32Xp+JxNQN2+opUK+Fmw6MxaqOyXap6DDENhskW0tA1s 3bAWvdkf5mkbuQLMFd9N17/Uspwd7jhMWgITC+WNSLkPYHu719ZxfWgFQV8PJBXO6hOL 1FcSYQcaKtkxMRChfVLOtTfRZHBNt1KnwY+84= MIME-Version: 1.0 Received: by 10.43.54.210 with SMTP id vv18mr9436529icb.103.1300809447399; Tue, 22 Mar 2011 08:57:27 -0700 (PDT) Received: by 10.231.160.21 with HTTP; Tue, 22 Mar 2011 08:57:27 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962011338@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962FE95@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962011338@008-AM1MPN1-036.mgdnok.nokia.com> Date: Tue, 22 Mar 2011 16:57:27 +0100 Message-ID: From: Paco Cortes To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 15:56:01 -0000 Hi, >> I was assuming that more often than not the host would already have >> RFC1928 addresses on their local interfaces. >> For such cases I see no added value on using 172.21.112.0/30 >> addresses, but just problems potential. But maybe this is an >> acceptable compromise if it eases implementations. > > Well, in BIS mode the virtual interface has to have some address on it, r= ight? Maybe you could avoid virtual interface on some implementations, and = just "catch" the packets that need to be translated. > On the other hand, if you would use the physical address of the link, wha= t if the IPv4 on the link dies or renumbers for some reason? That would imp= act to translated session. uhmmm.... you have a point there. > I would leave some room for implementations as well, that is why the draf= t recommends but not mandates addresses. Sounds reasonable. We started this discussion on the issue of sockets explicitly bound by an application to a local source IPv4 address at creation time. On that one we have agreed that the BIH implementation shall respect that binding and return that IPv4 address instead of a synthetic one in case of getsockname(). That should then be explicitly documented in the I-D. For other cases, I see the validity of you argumentation above. I have then no strong opinion on if the possibility of re-using local IPv4 addresses or synthetic 172.21.112.0/30 ones should be prohibited, recommended, mentioned as possibility, ... Whatever you chose is fine to me ;-) > Please join MIF WG for that discussion. E.g. your cellphone may perfectly= connect to WLAN and cellular networks that have different admins and both = think it is a good idea to number host as 192.168.1.2. Point taken. I still would explicitly mention in the I-D the problem of potentially preventing communication to real peers using addresses from the 172.21.80.0/20 range, but I do understand now that for the devices for which this I-D is targeted, this is a known problem.. >> I would add a =A0SHOULD or even a MUST in the first paragraph of 4.3 >> where you write about "smart management techniques of the address >> pool". > > That is fine for me as well. Are there some nice reference that describes= such techniques? Maybe just a reference to RFC 2663 will do. References to RFCs 4787, 5382 and 5508 might also be useful. > No prob - the WG doc should reflect WG consensus:) Keep comments rolling = in:) running out of comments already ;) From cb.list6@gmail.com Tue Mar 22 09:00:34 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B833A63C9 for ; Tue, 22 Mar 2011 09:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfX3DmoIgogl for ; Tue, 22 Mar 2011 09:00:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 20D6C3A659A for ; Tue, 22 Mar 2011 09:00:33 -0700 (PDT) Received: by iyi12 with SMTP id 12so8891666iyi.31 for ; Tue, 22 Mar 2011 09:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hpOldxllotkiQnkt3nPJ2Ar+vnq+VAYGgkjt/Sr+CXs=; b=VJRQABbwqq/iDCo3l/+OT4bGuurwZHrBJzjf9Z2JNRcbe+i/ml5+fyfpeSV4SvRGEK w/OYQIdP3TXTU2RlYqh6XZJMCxEPcDFNTA95aRMnDokeLXZQMZGn7pvQ2A9C7I8LIQ4y tzCCkhkiWQdgiSS6fC7Cp/Hvbz8+63NwRbJWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uuuR8mGkDjoAs3KmHsPK7kHGpG5wyFlaqLvl6lr6gaeXUs983aXie+BWMB51ckp24P 4IgAzRsCsbosOiNduf1glisHXEKO01vTmk/4BM8jq2oO95D2/xP+WfiqL6wALIh2Azn3 0+M6U/Z6IweWeTW/tW7DhpycEhiqruK0bxHf4= MIME-Version: 1.0 Received: by 10.42.219.135 with SMTP id hu7mr9331393icb.285.1300809723500; Tue, 22 Mar 2011 09:02:03 -0700 (PDT) Received: by 10.42.39.1 with HTTP; Tue, 22 Mar 2011 09:02:03 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962011385@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962011385@008-AM1MPN1-036.mgdnok.nokia.com> Date: Tue, 22 Mar 2011 09:02:03 -0700 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dwing@cisco.com, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 16:00:34 -0000 On Tue, Mar 22, 2011 at 7:51 AM, wrote: > I think the current text in the draft is quite specific:=94those that use= DNS > for IP address resolution and that do not embed IP address literals in > protocol payloads =94. > > > > This work is limited by the charter: > > -- > > Submit to IESG: host-based NAT46 translation for IPv4-only applications t= o > access IPv6-only servers (std) > > -- > > > > Hence I don=92t really see what the more specific text there could be? > > > > I mean we can=92t describe what the NAT64d actually implements, because i= t > implements features outside of behave WG scope.. > I believe the WG scope and the real world solution scope are 2 different things. This is a problem. They should be bridged so that the IETF produces the most relevant standard possible and serves the reality of what NAT64D on N900 and the China Mobile prototype exhibit*. As it stands, this draft only captures a narrow and unlikely scenario of IPv6-only servers. I imagine that the implementations will conclude that session state in a NAT64 is an IPv6-only server .... otherwise how does Skype work on the China Mobile prototype of BIH? For whatever reason, some mobile phone applications fail to operate on ipv6-only networks. My sampling shows this can be up to 10% of the network applications. It is obvious that NAT46 and NAT64 will have to be used together to bridge the gap.... either that or "break some glass" and force the apps to update/fix. China Mobile and the N900 already have solved this problem with NAT464. This has already been demonstrated in 2 unique environments. I think the time has come for the IETF and BEHAVE to realize that NAT464 is a reality. We can plug our ears or see the reality and document it correctly. Cameron *I don't have any idea what China Mobile has done with BIH, but Dan mentioned on the list they have a prototype that works with Skype. Sorry if i have inferred too much and incorrectly. But, according to that implementation of BIH, it is NAT464. > > > Teemu > > > > > > From: ext Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: 22. maaliskuuta 2011 09:59 > To: Savolainen Teemu (Nokia-MS/Tampere) > Cc: dthaler@microsoft.com; behave@ietf.org; > draft-ietf-behave-v4v6-bih@tools.ietf.org; dwing@cisco.com > Subject: Re: RE: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt > > > > On Mar 22, 2011 12:33 AM, wrote: >> >> Hi Cameron, Dan, >> >> > -----Original Message----- >> > From: ext Cameron Byrne [mailto:cb.list6@gmail.com] >> > >> > Is it possible to initiate the mapper without DNS first ? =A0Why must >> > DNS be the only trigger? >> >> and >> >> > -----Original Message----- >> > From: ext Dan Wing [mailto:dwing@cisco.com] >> > >> > That text can't be an accurate description of the BIH deployed by Chin= a >> > Mobile, which works with Skype. =A0Skype doesn't do DNS queries for >> > its DHT or for its peers. >> > >> > So, I believe the "DNS must be used first" restriction doesn't exist. >> >> If I recall behave's earlier discussions correctly, it was agreed that t= he >> specification developed in behave is to be scoped only for DNS using leg= acy >> applications. Hence restriction comes from this WG and that is why BIH d= raft >> says what is says. This is not technical restriction, as you can clearly= see >> from implementations (I know of two different). >> >> Would you then like to see some additional text in the section "2.4 >> Address Mapper" such as: >> -- >> "(4) The Address Mapper MAY also allow creation of mapping table entries >> via implementation specific means" >> -- >> > > Yes. Why not be more specific as well? This vague language to describe > obvious functionality will be confusing. > > Cb > >> ? >> >> Teemu From dwing@cisco.com Tue Mar 22 11:17:57 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0317E3A68C3 for ; Tue, 22 Mar 2011 11:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 tiqMkh83VnJD for ; Tue, 22 Mar 2011 11:17:56 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 29C173A68B3 for ; Tue, 22 Mar 2011 11:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=363; q=dns/txt; s=iport; t=1300817969; x=1302027569; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ow/AkHNPsMtL6w/MUNsH4XcnGmbzuTuVVueEB3gaBos=; b=UwnJsEEZqJzuuIDAV45W79AJYw+3dGxO/39wwNKz+apKMF4Uw1Wh7y9u K3rQVWo+Vk9Q1+CJPoEC5d0bW6ffqHQaMWa3YE5CPDd/ldKyj/0yLt0nw zNfbyFqgtzBmQqeJp/32lPslQCCmgt1cLCam4l1JRDZ9WAbe1hzZviVR/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHWFiE2rRDoJ/2dsb2JhbACZaotTd6dDnDyFaASFNQ X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208";a="279517724" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2011 18:19:29 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2MIJTw3032648; Tue, 22 Mar 2011 18:19:29 GMT From: "Dan Wing" To: "'Cameron Byrne'" , References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962011385@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Date: Tue, 22 Mar 2011 11:19:29 -0700 Message-ID: <15a401cbe8bd$af3aa430$0dafec90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvoqoq+/whUN8TYQJeT/5RC4ehxZgAEtxig Content-language: en-us Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 18:17:57 -0000 > *I don't have any idea what China Mobile has done with BIH, but Dan > mentioned on the list they have a prototype that works with Skype. > Sorry if i have inferred too much and incorrectly. But, according to > that implementation of BIH, it is NAT464. http://code.google.com/p/n900ipv6/wiki/Nat64D says: "known success ... * Skype" -d From rpenno@juniper.net Tue Mar 22 11:22:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B533A68C3 for ; Tue, 22 Mar 2011 11:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGRsczGrHI0b for ; Tue, 22 Mar 2011 11:22:21 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 13B9E3A68B3 for ; Tue, 22 Mar 2011 11:22:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTYjpNLnoRoFiyejBDA4p0TaiakBpaCNU@postini.com; Tue, 22 Mar 2011 11:23:54 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Mar 2011 11:20:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 22 Mar 2011 14:21:50 -0400 From: Reinaldo Penno To: Dan Wing , "behave@ietf.org" Date: Tue, 22 Mar 2011 14:21:46 -0400 Thread-Topic: [BEHAVE] scoping CGN Requirements document Thread-Index: Acvn/GWdDSpQBeoLRpStuoiFxUunpwAwZrhy Message-ID: In-Reply-To: <114b01cbe7fc$65e607a0$31b216e0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave-chairs@tools.ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 18:22:22 -0000 I think there are certain nuances that are not clear. It would be good to discuss in the meeting. By the very nature of 'Carrier' Grade NAT it means it is not a regular NAT. Therefore should all previous behave RFCs apply blindly? Or as part of this process should some be updated to reflect this new type of NAT device? If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT becomes a CGN? On 3/21/11 12:15 PM, "Dan Wing" wrote: > * if a requirement is not specific to a Carrier Grade NAT, it > should not be a _new_ requirement in the document. Instead, the > document should reference an existing requirement. For example, > the TCP behavior of a CGN can be described by BEHAVE's existing > TCP behavior document, RFC5382. For example, hold-down timers > is not specific to a CGN (because existing NAPT would have > similar or identical requirements), and TCP/25 filtering is not > specific to a CGN (as evidenced by ISPs filtering TCP/25 without > deploying a CGN). For example, new logging requirements caused > by IPv4 address sharing is well-described by other IETF documents > which can be cited. From cb.list6@gmail.com Tue Mar 22 11:24:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5373A68BC for ; Tue, 22 Mar 2011 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx3J0pPNVmUv for ; Tue, 22 Mar 2011 11:24:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id D18B93A68B3 for ; Tue, 22 Mar 2011 11:24:48 -0700 (PDT) Received: by yxk30 with SMTP id 30so3552677yxk.31 for ; Tue, 22 Mar 2011 11:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7bqoU+SbRi9nDqoRKxPdH57svMTa42+NjdB7HhTnBqw=; b=gznmbqsOh8c1jHgVgreN2dLb5TwhcnTyyzlYlE6gTWxv4QdZ8q5LrJ6PNEndlgljzG 8cJC1bs8chR3YN60Ekn97OdexNUW7JshlQvqtnaRSWl8e6bedTHvqbvJVsacvYT4YO/E dMnumYn4NI8nGumI4W5U2Q6JLonDWRTlD74ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uXW4+wCG/JWrHBZn2bAEJuJTza8o7BVetnxawnjPBTqCFt4TILaiWH/itB4h0UbYWK slGRvSAQ7E3+7YGR2PZIF9n+6wlvzyZcV8mVlfjv/78OISzqrUdbJidgjmrUEfR5g5cR Z4Ym3RqKq+DHyUHK0cw2OmQLivjNWRvHMPjkE= MIME-Version: 1.0 Received: by 10.42.29.74 with SMTP id q10mr2248443icc.352.1300818381875; Tue, 22 Mar 2011 11:26:21 -0700 (PDT) Received: by 10.42.39.1 with HTTP; Tue, 22 Mar 2011 11:26:21 -0700 (PDT) In-Reply-To: <15a401cbe8bd$af3aa430$0dafec90$@com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FDBF@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE4430969620109F4@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962011385@008-AM1MPN1-036.mgdnok.nokia.com> <15a401cbe8bd$af3aa430$0dafec90$@com> Date: Tue, 22 Mar 2011 11:26:21 -0700 Message-ID: From: Cameron Byrne To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-behave-v4v6-bih@tools.ietf.org, behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-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, 22 Mar 2011 18:24:49 -0000 On Tue, Mar 22, 2011 at 11:19 AM, Dan Wing wrote: >> *I don't have any idea what China Mobile =A0has done with BIH, but Dan >> mentioned on the list they have a prototype that works with Skype. >> Sorry if i have inferred too much and incorrectly. =A0But, according to >> that implementation of BIH, it is NAT464. > > http://code.google.com/p/n900ipv6/wiki/Nat64D says: > > =A0"known success > > =A0... > > =A0* Skype" > Hmm... i thought you meant that China Mobile had something different from the N900 code. My bad. Cameron > -d > > > From simon.perreault@viagenie.ca Tue Mar 22 11:26:28 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B87E3A68BC for ; Tue, 22 Mar 2011 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 KApCfFm1FkwK for ; Tue, 22 Mar 2011 11:26:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 36EB13A68B3 for ; Tue, 22 Mar 2011 11:26:27 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A57B121B98 for ; Tue, 22 Mar 2011 14:27:59 -0400 (EDT) Message-ID: <4D88EA2F.50401@viagenie.ca> Date: Tue, 22 Mar 2011 14:27:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: "behave@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 18:26:28 -0000 On 2011-03-22 14:21, Reinaldo Penno wrote: > If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT becomes > a CGN? >From the Terminology section: Carrier-Grade NAT (CGN): NAT device placed between a subscriber and the Internet in an ISP's network. A CGN translates IP addresses and transport-protocol port numbers in the packets that it forwards across the border between the internal and external realms. This makes it clear that a CPE is not a CGN. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Tue Mar 22 11:40:03 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F50128C100 for ; Tue, 22 Mar 2011 11:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.478 X-Spam-Level: X-Spam-Status: No, score=-110.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 F6kZuAHMKcQ7 for ; Tue, 22 Mar 2011 11:40:02 -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 33E0D28C0FB for ; Tue, 22 Mar 2011 11:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2628; q=dns/txt; s=iport; t=1300819295; x=1302028895; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=CYchZE3avGTHdwEj5zvz904IzCYLwf5BoXSK9us1Hv4=; b=hT/NU0lSKlkphZh2MEiZWqLo+mPtQ2Qws4JhhL2im9rN3STZV6WD2eOJ VXLaLKs3igCOF5W5JAeWb7HiLrF8wxiNc2nletQItZH4ZJYoM7VxGoCX4 xkH/5u1NDLOSunOmSUUOUhWyPjxSG+jXTrlzuGCW5sL+1lJ33yREzt4XS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAK2JiE2rRDoJ/2dsb2JhbACYBoFki1J3iE2fKJw5hWgEhTU X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208";a="350675613" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2011 18:41:35 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2MIfZsJ025622; Tue, 22 Mar 2011 18:41:35 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , References: <114b01cbe7fc$65e607a0$31b216e0$@com> In-Reply-To: Date: Tue, 22 Mar 2011 11:41:35 -0700 Message-ID: <15c901cbe8c0$c58d7ca0$50a875e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvn/GWdDSpQBeoLRpStuoiFxUunpwAwZrhyAACBT9A= Content-language: en-us Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 18:40:03 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, March 22, 2011 11:22 AM > To: Dan Wing; behave@ietf.org > Cc: behave-chairs@tools.ietf.org; draft-ietf-behave-lsn- > requirements@tools.ietf.org > Subject: Re: [BEHAVE] scoping CGN Requirements document > > I think there are certain nuances that are not clear. It would be good > to > discuss in the meeting. > > By the very nature of 'Carrier' Grade NAT it means it is not a regular > NAT. Therefore should all previous behave RFCs apply blindly? No. We should carefully evaluate which of the requirements apply, and re-apply them. Right now, the document effectively says "the requirements of BEHAVE's UDP, TCP, and ICMP documents SHOULD be followed". If there is something more specific (or less specific) for a CGN, it should be in the CGN document. > Or as part of this > process should some be updated to reflect this new type of NAT device? Exactly. > If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT > becomes a CGN? A related question, which is why I suggested and really liked the name "Large Scale NAT", is "does a really large enterprise want or need the features ascribed to a Carrier-Grade NAT?". Afterall, an enterprise with 20,000-30,000 users actively hitting the NAT is larger than many ISPs. To your question, the threshold is crossed when there are users behind the NAT which are separately responsible for their own Internet activity. At home, anyone who calls the fire department from my phone will make me (as the owner of the phone line) responsible for the fine for the false phone call. Once that changes, it gets into CGN territory. At least, that's my definition for whatever that's worth. -d > > On 3/21/11 12:15 PM, "Dan Wing" wrote: > > > * if a requirement is not specific to a Carrier Grade NAT, it > > should not be a _new_ requirement in the document. Instead, the > > document should reference an existing requirement. For example, > > the TCP behavior of a CGN can be described by BEHAVE's existing > > TCP behavior document, RFC5382. For example, hold-down timers > > is not specific to a CGN (because existing NAPT would have > > similar or identical requirements), and TCP/25 filtering is not > > specific to a CGN (as evidenced by ISPs filtering TCP/25 without > > deploying a CGN). For example, new logging requirements caused > > by IPv4 address sharing is well-described by other IETF documents > > which can be cited. From rpenno@juniper.net Tue Mar 22 12:31:53 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8292E28C15C for ; Tue, 22 Mar 2011 12:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 kITgEPHubqtJ for ; Tue, 22 Mar 2011 12:31:52 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 77EC228C15F for ; Tue, 22 Mar 2011 12:31:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTYj5gB3mX9o85USHUhVt65VM0rc3QZ6D@postini.com; Tue, 22 Mar 2011 12:33:26 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Mar 2011 11:42:24 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 22 Mar 2011 14:43:41 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Tue, 22 Mar 2011 14:43:39 -0400 Thread-Topic: [BEHAVE] scoping CGN Requirements document Thread-Index: Acvovuqu0apDP05nQDS+sriKwEWRjQAAiRsQ Message-ID: In-Reply-To: <4D88EA2F.50401@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 19:31:53 -0000 Thanks Simon, Please clarify A Layer-3 CPE fits this descriptions since it is placed between devices in = a subscriber home and the ISP. Or do you mean a device place between the CPE and the Internet network? In the case of managed CPEs or Enterprise NAT, are these CGNs? If you have a NAT as a cloud service, does that make it a CGN? On 3/22/11 11:27 AM, "Simon Perreault" wrote: > On 2011-03-22 14:21, Reinaldo Penno wrote: >> If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT beco= mes >> a CGN? >=20 > From the Terminology section: >=20 > Carrier-Grade NAT (CGN): NAT device placed between a subscriber and > the Internet in an ISP's network. A CGN translates IP addresses > and transport-protocol port numbers in the packets that it > forwards across the border between the internal and external > realms. >=20 > This makes it clear that a CPE is not a CGN. >=20 > Thanks, > Simon From simon.perreault@viagenie.ca Tue Mar 22 12:44:07 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B35B28C16E for ; Tue, 22 Mar 2011 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 Urrs8EWGn0JW for ; Tue, 22 Mar 2011 12:44:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0FBB128C168 for ; Tue, 22 Mar 2011 12:44:06 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7DFF621B98; Tue, 22 Mar 2011 15:45:38 -0400 (EDT) Message-ID: <4D88FC62.80609@viagenie.ca> Date: Tue, 22 Mar 2011 15:45:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 19:44:07 -0000 On 2011-03-22 14:43, Reinaldo Penno wrote: > A Layer-3 CPE fits this descriptions since it is placed between devices in a > subscriber home and the ISP. ...but it's not "in an ISP's network". See also Figure 1: . : | Internet ............... | ................... | ISP network | | ++------++ External realm ........... | CGN |............... ++------++ Internal realm | | | | | | ISP network ............. | .. | ................ | | Customer premises ++------++ ++------++ | CPE1 | | CPE2 | etc. ++------++ ++------++ Figure 1: CGN network topology If there is a clarification to be made, please let me know so I can fix the draft. > In the case of managed CPEs or Enterprise NAT, are these CGNs? No, because they are not "in the ISP's network". > If you have a NAT as a cloud service, does that make it a CGN? Yes it is, according to the draft's definition. Again, this draft needs to get the definition right. Let me know if it needs to be changed. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rpenno@juniper.net Tue Mar 22 14:42:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6322A3A6783 for ; Tue, 22 Mar 2011 14:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 t+zCnAN7jgzH for ; Tue, 22 Mar 2011 14:42:48 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 68BDF3A67A1 for ; Tue, 22 Mar 2011 14:42:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTYkYNFSZJJdFxj8RndX7TDtfgbtfMV3N@postini.com; Tue, 22 Mar 2011 14:44:22 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Mar 2011 14:22:38 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 22 Mar 2011 17:23:56 -0400 From: Reinaldo Penno To: Simon Perreault Date: Tue, 22 Mar 2011 17:23:54 -0400 Thread-Topic: [BEHAVE] scoping CGN Requirements document Thread-Index: AcvoyclRSeRH4BFrSHOmP6DXlnejlAADajF9 Message-ID: In-Reply-To: <4D88FC62.80609@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 21:42:49 -0000 If the administrative authority extends to the CPE (whether small or large) it is questionable if it is in the ISP's network or not. Also, the 'CPE' ca= n be is some co-location connected through a metro Ethernet. It is in the ISP's network but customer has full control over it. I think we should avoid topology related definitions of CGN. One thing seems common across all 'regular' NATs; they have a single subscriber behind it. I think a NAT becomes a CGN when it aggregates more than one subscriber and therefore you have address sharing across subscribers. On 3/22/11 12:45 PM, "Simon Perreault" wrote: >> In the case of managed CPEs or Enterprise NAT, are these CGNs? >=20 > No, because they are not "in the ISP's network". From simon.perreault@viagenie.ca Tue Mar 22 15:15:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1E03A67D9 for ; Tue, 22 Mar 2011 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 BwkW0aP504Tt for ; Tue, 22 Mar 2011 15:15:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 127F23A67B6 for ; Tue, 22 Mar 2011 15:15:45 -0700 (PDT) Received: from balaise.nomis80.org (unknown [IPv6:2001:470:1f11:783:218:f3ff:fe3d:1af4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 63A7121B98; Tue, 22 Mar 2011 18:17:17 -0400 (EDT) Message-ID: <4D891FEC.5010106@viagenie.ca> Date: Tue, 22 Mar 2011 18:17:16 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 22:15:46 -0000 On 03/22/2011 05:23 PM, Reinaldo Penno wrote: > If the administrative authority extends to the CPE (whether small or large) > it is questionable if it is in the ISP's network or not. Also, the 'CPE' can > be is some co-location connected through a metro Ethernet. It is in the > ISP's network but customer has full control over it. > > I think we should avoid topology related definitions of CGN. Sure, as long as we have a better alternative. > One thing seems common across all 'regular' NATs; they have a single > subscriber behind it. I think a NAT becomes a CGN when it aggregates more > than one subscriber and therefore you have address sharing across > subscribers. I think I would agree with that, especially if we add some notion of "control" that subscribers do or do not have over the NAT. On terminology issues it is important to be precise. So I ask you to please send a concrete proposal (the actual text that would go in the draft) that we may discuss further. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Tue Mar 22 15:15:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183C628C0D9 for ; Tue, 22 Mar 2011 15:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 orq5LuUHA7ZE for ; Tue, 22 Mar 2011 15:15:48 -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 069293A67B6 for ; Tue, 22 Mar 2011 15:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1538; q=dns/txt; s=iport; t=1300832241; x=1302041841; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=02w6HucY5ag7/BwNz+xpXMqy3Cy49vm87IIq/D9pQmI=; b=VhgOlLjSLDcPxQra7ecFfgBg5+nAU0kqwWn2uJ+S4hAwZwaToQf4iriK COmrE/Vair/eZU4lQmdE7EL6SlezrmANkuqad5iexC6Mxy5l4W/57m5Np OJMbFhnU39sG2isZtOzT2uvVr7Y0ip3YpT2WCDG+o9us9ay2Qbs2E7Ixk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAH68iE2rRDoG/2dsb2JhbACYDIFki1J3qGWcFIVoBIU1 X-IronPort-AV: E=Sophos;i="4.63,227,1299456000"; d="scan'208";a="281116623" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2011 22:17:20 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2MMHKtE031793; Tue, 22 Mar 2011 22:17:20 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Simon Perreault'" References: <4D88FC62.80609@viagenie.ca> In-Reply-To: Date: Tue, 22 Mar 2011 15:17:20 -0700 Message-ID: <170a01cbe8de$e9930020$bcb90060$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvoyclRSeRH4BFrSHOmP6DXlnejlAADajF9AAGyfvA= Content-language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 22:15:49 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Reinaldo Penno > Sent: Tuesday, March 22, 2011 2:24 PM > To: Simon Perreault > Cc: behave@ietf.org > Subject: Re: [BEHAVE] scoping CGN Requirements document > > If the administrative authority extends to the CPE (whether small or > large) it is questionable if it is in the ISP's network or not. > Also, the 'CPE' can be is some co-location connected through a > metro Ethernet. It is in the ISP's network but customer has full > control over it. > > > I think we should avoid topology related definitions of CGN. > > One thing seems common across all 'regular' NATs; they have a single > subscriber behind it. I think a NAT becomes a CGN when it aggregates > more > than one subscriber and therefore you have address sharing across > subscribers. Exactly. Differentiating between who pays for the electricity or who has administrative privileges isn't what's important. Rather, it is if there is more than one entity, with their own bill, Terms of Service agreement, installation address, etc. -d > > > > > > > > On 3/22/11 12:45 PM, "Simon Perreault" > wrote: > > >> In the case of managed CPEs or Enterprise NAT, are these CGNs? > > > > No, because they are not "in the ISP's network". > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Francis.Dupont@fdupont.fr Tue Mar 22 15:21:10 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4423A67F4 for ; Tue, 22 Mar 2011 15:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9bpCbmxhlG8 for ; Tue, 22 Mar 2011 15:21:09 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 011E13A67F2 for ; Tue, 22 Mar 2011 15:21:08 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2MMMfjU034386; Tue, 22 Mar 2011 23:22:41 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103222222.p2MMMfjU034386@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Tue, 22 Mar 2011 17:23:54 -0400. Date: Tue, 22 Mar 2011 23:22:41 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 22:21:10 -0000 In your previous mail you wrote: One thing seems common across all 'regular' NATs; they have a single subscriber behind it. I think a NAT becomes a CGN when it aggregates more than one subscriber and therefore you have address sharing across subscribers. => +1 Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Wed Mar 23 00:03:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4D63A67C1 for ; Wed, 23 Mar 2011 00:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 MgXoVgCQoXoR for ; Wed, 23 Mar 2011 00:03:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id BED0E3A68E8 for ; Wed, 23 Mar 2011 00:03:49 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 73E143B430A; Wed, 23 Mar 2011 08:05:22 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 56CD1238041; Wed, 23 Mar 2011 08:05:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 23 Mar 2011 08:05:22 +0100 From: To: Dan Wing , "behave@ietf.org" Date: Wed, 23 Mar 2011 08:05:21 +0100 Thread-Topic: [BEHAVE] scoping CGN Requirements document Thread-Index: Acvn/GWdDSpQBeoLRpStuoiFxUunpwBJzssw Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0EAFC@PUEXCB1B.nanterre.francetelecom.fr> References: <114b01cbe7fc$65e607a0$31b216e0$@com> In-Reply-To: <114b01cbe7fc$65e607a0$31b216e0$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.23.60016 Cc: "behave-chairs@tools.ietf.org" , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 07:03:51 -0000 Hi Dan, all, (*) I fully agree a scoping is needed if we want this document to progress = but since this is a CARRIER GRADE NAT and not a "normal" NAT in a CPE, some= of the requirements as worded in existing behave RFCs should be re-examine= d: in particular the configuration of the timers is a "MAY" in existing RFC= s while in the CGN case this should be at least defined as "SHOULD", etc.=20 (*) The current version of I-D is talking about "Carrier-Grade NAT (CGN) de= vices" which IMO should be avoided. We are not defining the requirement for= a device but a "Function" or a "Functional Element". (*) Basically, a CGN can be defined as "a NAT-based Functional Element oper= ated by an administrative entity (e.g., operator) to share the same address= among several subscribers.".=20 (*) Because the CGN is operated by an operator, several dimensions may be t= aken into account as listed below (but the WG may decide to focus only on a= subset): * "Basic" NAT behaviour itself * Customized NAT: all the configuration specific to the operator: timers, a= ddress sharing, shared address pool, exclude some ports from the shared por= t pool, dedicate address pool for ICMP, port quotas (implicit/explicit), be= haviour when the port limit is reached, support of port set, etc. * "Basic" per-subscriber functions: blacklist a subscriber, differentiated = customer profiles, etc. * Data retention and Legal Intercept requirements: this set of requirements= can be elaborated in this I-D but instead a clear statement in the I-D to = say this is out of scope can be added. * Provider-oriented functions: QoS transparency (e.g., DSCP re-marking, pri= oritization), emergency, resource fair usage,=20 * Filtering functions: NAT filtering, inbound (from subscriber-facing) addr= ess filtering, inbound port filtering, etc.=20 * Requirements to avoid application brokenness: (dynamic) port forwarding, = insert host_id, etc.=20 * Ensure service availability and reliability during reboot or outage: a CG= N is a stateful function. This is provider-specific. * Operational considerations: graceful restart, graceful shutdown for plann= ed maintenance operations, stable storage, etc. * Resource optimisation: when several CGN are deployed, an operator need to= load balance the traffic among deployed CGNs * Management functions: behaviour when a subscriber quota is fired, behavio= ur when a port usage threshold is reached, MIB/YANG modules to be supported= =20 Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Dan Wing Envoy=E9 : lundi 21 mars 2011 20:16 =C0 : behave@ietf.org Cc : behave-chairs@tools.ietf.org; draft-ietf-behave-lsn-requirements@tools= .ietf.org Objet : [BEHAVE] scoping CGN Requirements document Requirements documents are notoriously difficult, across the industry and across life in general ("the new bicycle MUST have 24 gears"). There appears to be considerable scope creep with the CGN Requirements document, for which I am partially guilty. My desire is to get this document published, and I had thought we were close to finishing the document until Simon's update caused a flurry of new CGN requirements to be considered. The general theme for the document is that the CGN should be "fair". That was the reason for the initial CGN-specific requirement which is that a subscriber be limited to a certain number of IPv4 ports -- to prevent one user from denying service to other legitimate users. Dave and I have discussed the organization of the document in the past, and the following two tenets seem pretty valuable in scoping the document: * if a requirement is specific to a Carrier Grade NAT, it should be a=20 new requirement in the document. For example, restricting a user to a certain number of ports. * if a requirement is not specific to a Carrier Grade NAT, it should not be a _new_ requirement in the document. Instead, the document should reference an existing requirement. For example, the TCP behavior of a CGN can be described by BEHAVE's existing TCP behavior document, RFC5382. For example, hold-down timers is not specific to a CGN (because existing NAPT would have=20 similar or identical requirements), and TCP/25 filtering is not=20 specific to a CGN (as evidenced by ISPs filtering TCP/25 without=20 deploying a CGN). For example, new logging requirements caused=20 by IPv4 address sharing is well-described by other IETF documents=20 which can be cited. In addition to the follow-ups on the mailing list from this email, I added 10 minutes to BEHAVE's agenda in Prague to discuss scoping the CGN Requirements document. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Wed Mar 23 00:09:10 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FA83A67C2 for ; Wed, 23 Mar 2011 00:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 5oXzAcbrukgA for ; Wed, 23 Mar 2011 00:09:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 31BDD3A68E4 for ; Wed, 23 Mar 2011 00:09:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 795522DC106; Wed, 23 Mar 2011 08:10:38 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 58E8835C018; Wed, 23 Mar 2011 08:10:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 23 Mar 2011 08:10:38 +0100 From: To: Simon Perreault , "behave@ietf.org" Date: Wed, 23 Mar 2011 08:10:37 +0100 Thread-Topic: [BEHAVE] scoping CGN Requirements document Thread-Index: AcvovuL2dtrCBMFBRUqMdOG/YHsKYAAaeODg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0EB02@PUEXCB1B.nanterre.francetelecom.fr> References: <4D88EA2F.50401@viagenie.ca> In-Reply-To: <4D88EA2F.50401@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.23.60016 Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 07:09:10 -0000 Dear Simon, I would suggest to update this definition and avoid using the "device" term= . CGN is a function and not a device: it can be embedded in existing router= s or be deployed in standalone device.=20 What about the following proposal: "Carrier-Grade NAT (CGN): NAT-based [RFC2663] Functional Element operated b= y an administrative entity (e.g., operator) to share the same address among= several subscribers.". Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : mardi 22 mars 2011 19:28 =C0 : behave@ietf.org Objet : Re: [BEHAVE] scoping CGN Requirements document On 2011-03-22 14:21, Reinaldo Penno wrote: > If a NAT is a NAT should CGN requirements apply to CPEs? When a NAT becom= es > a CGN? >From the Terminology section: Carrier-Grade NAT (CGN): NAT device placed between a subscriber and the Internet in an ISP's network. A CGN translates IP addresses and transport-protocol port numbers in the packets that it forwards across the border between the internal and external realms. This makes it clear that a CPE is not a CGN. Thanks, Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From zhangdong_rh@huaweisymantec.com Wed Mar 23 01:05:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5660D3A6905 for ; Wed, 23 Mar 2011 01:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 XA9dbhtkxZgv for ; Wed, 23 Mar 2011 01:05:11 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 5D3793A68E4 for ; Wed, 23 Mar 2011 01:05:11 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_u0AknLyXhL/UBnhRGJWAzA)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LII0052M3VN5UC0@hstga01-in.huaweisymantec.com> for behave@ietf.org; Wed, 23 Mar 2011 16:06:59 +0800 (CST) Received: from Z90001956Z ([10.27.136.91]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LII00JSW3VPIO20@hstml01-in.huaweisymantec.com> for behave@ietf.org; Wed, 23 Mar 2011 16:07:04 +0800 (CST) Date: Wed, 23 Mar 2011 16:06:31 +0800 From: Dong Zhang To: Simon Perreault , Reinaldo Penno References: <4D891FEC.5010106@viagenie.ca> Message-id: <201103231606313267700@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: "behave@ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 08:05:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_u0AknLyXhL/UBnhRGJWAzA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT >> One thing seems common across all 'regular' NATs; they have a single >> subscriber behind it. I think a NAT becomes a CGN when it aggregates more >> than one subscriber and therefore you have address sharing across >> subscribers. > >I think I would agree with that, especially if we add some notion of >"control" that subscribers do or do not have over the NAT. +1. The subscriber cann't operate or configure the CGN easily like its HGW or CPE. What about this based on Med's proposal: "Carrier-Grade NAT (CGN): NAT-based [RFC2663] Functional Element operated by an administrative entity (e.g., operator) to share the same address among several subscribers. CGN is managed by the administrative entity, not the subscribers". Thanks. 2011-03-23 Dong Zhang --Boundary_(ID_u0AknLyXhL/UBnhRGJWAzA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzIyIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9OVC1TSVpFOiAxMHB0Ij4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPiZndDsmZ3Q7IE9uZSB0aGluZyBz ZWVtcyBjb21tb24gDQphY3Jvc3MgYWxsICdyZWd1bGFyJyBOQVRzOyB0aGV5Jm5ic3A7IGhhdmUg YSBzaW5nbGU8QlI+Jmd0OyZndDsgc3Vic2NyaWJlciANCmJlaGluZCBpdC4gSSB0aGluayBhIE5B VCBiZWNvbWVzIGEgQ0dOIHdoZW4gaXQgYWdncmVnYXRlcyBtb3JlPEJSPiZndDsmZ3Q7IHRoYW4g DQpvbmUgc3Vic2NyaWJlciBhbmQgdGhlcmVmb3JlIHlvdSBoYXZlIGFkZHJlc3Mgc2hhcmluZyBh Y3Jvc3M8QlI+Jmd0OyZndDsgDQpzdWJzY3JpYmVycy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZndDs8 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPiZndDtJ IHRoaW5rIEkgd291bGQgYWdyZWUgd2l0aCANCnRoYXQsIGVzcGVjaWFsbHkgaWYgd2UgYWRkIHNv bWUgbm90aW9uIG9mIDxCUj4mZ3Q7ImNvbnRyb2wiIHRoYXQgc3Vic2NyaWJlcnMgZG8gDQpvciBk byBub3QgaGF2ZSBvdmVyIHRoZSBOQVQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+KzEuIFRoZSBzdWJzY3JpYmVyIGNh bm4ndCBvcGVyYXRlIA0Kb3IgY29uZmlndXJlIHRoZSBDR04gZWFzaWx5IGxpa2UgaXRzJm5ic3A7 SEdXIG9yIENQRS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPldoYXQgYWJvdXQgdGhpcyBi YXNlZCBvbiBNZWQncyBwcm9wb3NhbDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMw MDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4iQ2Fycmllci1HcmFkZSBOQVQgKENHTik6 IE5BVC1iYXNlZCBbUkZDMjY2M10gRnVuY3Rpb25hbCBFbGVtZW50IG9wZXJhdGVkIA0KYnkgYW4g YWRtaW5pc3RyYXRpdmUgZW50aXR5IChlLmcuLCBvcGVyYXRvcikgdG8gc2hhcmUgdGhlIHNhbWUg YWRkcmVzcyBhbW9uZyANCnNldmVyYWwgc3Vic2NyaWJlcnMuIENHTiBpcyBtYW5hZ2VkIGJ5IHRo ZSBhZG1pbmlzdHJhdGl2ZSBlbnRpdHksIG5vdCB0aGUgDQpzdWJzY3JpYmVycyIuPC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4 MD5UaGFua3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBm YWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMw IHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxMS0wMy0yMyA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpjb2xv cj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsg SEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0KPC9GT05UPg0KPERJVj48Rk9OVCBjb2xv cj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+DQo8RElWPg0KPERJVj48Rk9OVCBz aXplPTIgZmFjZT1WZXJkYW5hPkRvbmcgDQpaaGFuZzxCUj48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9T UEFOPjwvRk9OVD48L0RJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiANCmZhY2U9VmVyZGFu YT4NCjxIUj4NCjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_u0AknLyXhL/UBnhRGJWAzA)-- From teemu.savolainen@nokia.com Thu Mar 24 05:53:41 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACFB28C0EF for ; Thu, 24 Mar 2011 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 iGiBQhHji5us for ; Thu, 24 Mar 2011 05:53:41 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 8C4313A684E for ; Thu, 24 Mar 2011 05:53:40 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2OCt6PU011572; Thu, 24 Mar 2011 14:55:12 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Mar 2011 14:50:48 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 24 Mar 2011 13:50:47 +0100 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Thu, 24 Mar 2011 13:50:46 +0100 From: To: Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt Thread-Index: AQHL5YVrjmBmY1QaUUiMt5414UxLG5Q3nZiggAAKvICAABO3gIABcoyAgAA+8aCAAApYgIADANQQ Date: Thu, 24 Mar 2011 12:50:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620129F1@008-AM1MPN1-036.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653AFCB207@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <916CE6CF87173740BC8A2CE443096962FD55@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962FE95@008-AM1MPN1-036.mgdnok.nokia.com> <916CE6CF87173740BC8A2CE443096962011338@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Mar 2011 12:50:48.0208 (UTC) FILETIME=[1928C100:01CBEA22] X-Nokia-AV: Clean Cc: behave@ietf.org, dthaler@microsoft.com Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 12:53:42 -0000 Hi, > We started this discussion on the issue of sockets explicitly bound by > an application to a local source IPv4 address at creation time. > On that one we have agreed that the BIH implementation shall respect > that binding and return that IPv4 address instead of a synthetic one > in case of getsockname(). > That should then be explicitly documented in the I-D. Will do, and also include in the BIH presentation at behave wg. > Point taken. > I still would explicitly mention in the I-D the problem of potentially > preventing communication to real peers using addresses from the > 172.21.80.0/20 range, but I do understand now that for the devices for > which this I-D is targeted, this is a known problem.. Will do that as well. >=20 > >> I would add a =A0SHOULD or even a MUST in the first paragraph of 4.3 > >> where you write about "smart management techniques of the address > >> pool". > > > > That is fine for me as well. Are there some nice reference that > describes such techniques? >=20 > Maybe just a reference to RFC 2663 will do. References to RFCs 4787, > 5382 and 5508 might also be useful. Thank you, will check out those. Teemu From dwing@cisco.com Thu Mar 24 17:55:43 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FE928C0D6 for ; Thu, 24 Mar 2011 17:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.963 X-Spam-Level: X-Spam-Status: No, score=-109.963 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083, 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 GZ0QAbr71esZ for ; Thu, 24 Mar 2011 17:55:41 -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 EF32E28C113 for ; Thu, 24 Mar 2011 17:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=179; q=dns/txt; s=iport; t=1301014636; x=1302224236; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=bf75hPaTcxskaxeATLW5QA7wUo/99PJP5wE6hxYR7Xs=; b=iB+QHVByKmJZUjMMVjPGYxZvExKrwghGJ8dsKXsdw3UzyILmU411ETiY 9IjyG25Emf1RYrcI3EeO5ShDj34X5paOTaH4l4S1LlpT61r/vQ3v6PYU4 9yPpU5YeKtjl7qaSjBhUa3XFtAPoaVY/crBqb0/LXs1OVOC7BqjSL1/Mg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioWAALoi02rRDoH/2dsb2JhbACYUIElhHIBhmR3qCucToVpBIU5 X-IronPort-AV: E=Sophos;i="4.63,240,1299456000"; d="scan'208";a="418065389" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2011 00:57:15 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2P0vFTm027342 for ; Fri, 25 Mar 2011 00:57:15 GMT From: "Dan Wing" To: Date: Thu, 24 Mar 2011 17:57:15 -0700 Message-ID: <214501cbea87$959c15b0$c0d44110$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvqh5VmTXwB0UczSnaavABJDcw6Cw== Content-language: en-us Subject: [BEHAVE] BEHAVE agenda posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 00:55:43 -0000 BEHAVE's agenda is now posted at http://www.ietf.org/proceedings/80/agenda/behave.html We will be canceling BEHAVE's Friday session that appears in the IETF agenda. -d From tena@huawei.com Thu Mar 24 18:07:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5848A3A677C for ; Thu, 24 Mar 2011 18:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.71 X-Spam-Level: X-Spam-Status: No, score=-105.71 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083, 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 K0acf7tgkO8F for ; Thu, 24 Mar 2011 18:07:54 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 65E893A63EC for ; Thu, 24 Mar 2011 18:07:54 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIL00ET69VS5S@usaga04-in.huawei.com> for behave@ietf.org; Thu, 24 Mar 2011 20:09:29 -0500 (CDT) Received: from TingZousc1 ([10.212.244.208]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIL0072H9VO1K@usaga04-in.huawei.com> for behave@ietf.org; Thu, 24 Mar 2011 20:09:28 -0500 (CDT) Date: Thu, 24 Mar 2011 18:09:24 -0700 From: Tina Tsou In-reply-to: <214501cbea87$959c15b0$c0d44110$@com> To: 'Dan Wing' , behave@ietf.org Message-id: <022001cbea89$485e2660$d91a7320$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acvqh5VmTXwB0UczSnaavABJDcw6CwAASyyA References: <214501cbea87$959c15b0$c0d44110$@com> Subject: Re: [BEHAVE] BEHAVE agenda posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 01:07:55 -0000 Hi Dan, If we want to cancel the Friday session, it would be better if it is done before Hilton's deadline of changing without penalty, i.e. Mar 17th. In this case, some people can leave on Friday afternoon. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing Sent: Thursday, March 24, 2011 5:57 PM To: behave@ietf.org Subject: [BEHAVE] BEHAVE agenda posted BEHAVE's agenda is now posted at http://www.ietf.org/proceedings/80/agenda/behave.html We will be canceling BEHAVE's Friday session that appears in the IETF agenda. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Sat Mar 26 03:05:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459F73A6907 for ; Sat, 26 Mar 2011 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6yZY0niVV7o for ; Sat, 26 Mar 2011 03:05:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id AEA6D3A684F for ; Sat, 26 Mar 2011 03:05:32 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C1E5321F4E for ; Sat, 26 Mar 2011 06:07:05 -0400 (EDT) Message-ID: <4D8D24F0.9060209@viagenie.ca> Date: Fri, 25 Mar 2011 19:27:44 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: <201103171529.p2HFTqwi070912@givry.fdupont.fr> In-Reply-To: <201103171529.p2HFTqwi070912@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:05:55 -0000 Francis Dupont wrote, on 03/17/2011 11:29 AM: > The issue I have is that firewalls are defined no where...and in > the meantime I need a function which filters the internal ports > before enforcing the NAT operation. I package this as a CGN > function. > > => I disagree: the only relationship between firewalls and CGNs > should be that a firewall should be placed in front of a CGN > (i.e., filtering before translation). Ok so what I understand from this thread, and with input from the chairs' guidelines about what should be the scope of this draft, is that we should only document filtering that is specific to CGN devices. If it can be done elsewhere in the network, then it's out of scope. Furthermore, NAT-specific filtering is already documented in the BEHAVE RFCs. If there's more to be said about NAT-specific filtering, then it means that an update of these RFCs would be required. It really needs to be specific to CGNs to be in scope for this draft. And so far, as editor, I haven't seen consensus on any CGN-specific filtering. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:05:59 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D1328C10A for ; Sat, 26 Mar 2011 03:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaHD3YkK8ko9 for ; Sat, 26 Mar 2011 03:05: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 D4B0428C108 for ; Sat, 26 Mar 2011 03:05:58 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C1C5421F50 for ; Sat, 26 Mar 2011 06:07:33 -0400 (EDT) Message-ID: <4D8D2D50.3080908@viagenie.ca> Date: Fri, 25 Mar 2011 20:03:28 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: Your message of Wed, 16 Mar 2011 07:16:42 +0100. <94C682931C08B048B7A8645303FDC9F33C4DBA3CC6@PUEXCB1B.nanterre.francetelecom.fr> <201103161431.p2GEVqua078968@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4DBA3FCC@PUEXCB1B.nanterre.francetelecom.fr> <017a01cbe411$257172c0$70545840$@com> <94C682931C08B048B7A8645303FDC9F33C4DBA4146@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA4146@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:06:00 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 03:24 AM: > 1. for a new outgoing flow, choose a random port and create a new > mapping. There is a limit on the maximum number of ports. > > 2. for a new outgoing flow, choose several random ports and create a > "bin" of those ports. This outgoing flow is assigned one of > those ports. Subsequent outgoing flows will be assigned a port > from the "bin". When the "bin" is full, a new flow causes this > process to be repeated (i.e., a new bin is created). A bin is > smaller or equal to the user's maximum port limit. > > 3. Same as (2), but the ports allocated to a "bin" are consecutive > public ports. > > Med: I don't know where to put the non-contiguous one single "bin" case (excerpt from (see http://tools.ietf.org/html/draft-bajko-pripaddrassign-02#section-4.1) > > "a non Continuous Port Range is assigned to a given customer's > device. In this example, the Port Range Value defines 128 Continuous > Port Ranges, each one with a length of 16 port values. Note that > the two first Port Ranges are both in the well-known ports span > (i.e. 0-1023) but these two ranges are not adjacent. It looks to me like it would be between 2 and 3: somewhat random, but not completely. Now, I don't think we need to list all possibilities in the draft. Anyone could invent a dozen new ones by blending what's already there in varying proportions, without even trying hard to be creative. What the text needs to make clear is that this is a continuum, and how the pros and cons vary as you move along it (as a first step). The next revision will contain terminology that will work better than numbers for discussion. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:06:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AE528C111 for ; Sat, 26 Mar 2011 03:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCaleohnkMWp for ; Sat, 26 Mar 2011 03:06:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 96FEE28C10F for ; Sat, 26 Mar 2011 03:06:03 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D115721EE0; Sat, 26 Mar 2011 06:07:37 -0400 (EDT) Message-ID: <4D8D2F50.1020301@viagenie.ca> Date: Fri, 25 Mar 2011 20:12:00 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <94C682931C08B048B7A8645303FDC9F33C4DBA3B5C@PUEXCB1B.nanterre.francetelecom.fr> <4D80BFD0.1060007@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA3FC7@PUEXCB1B.nanterre.francetelecom.fr> <4D80D6F7.40407@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4DBA412A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA412A@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Hold-down pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:06:04 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 02:35 AM: > The rationale behind the pool is to prevent all/majority of your ports be > unusable because tagged as hold-down port. We need a means to control the > amount of port to be put in that pool; hence the need to configure a pool > size. Understood. I have one further question: is this CGN-specific? The hold-down functionality seems to me like it would apply to any NAT. The hodl-down pool size limit seems to me like it would be CGN-specific, as a DoS-prevention mechanism. Am I right? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:06:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AE23A6900 for ; Sat, 26 Mar 2011 03:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hSD47V9TfTV for ; Sat, 26 Mar 2011 03:06:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id CB8883A684F for ; Sat, 26 Mar 2011 03:06:47 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 63E0821EE0 for ; Sat, 26 Mar 2011 06:08:20 -0400 (EDT) Message-ID: <4D8D336D.1050604@viagenie.ca> Date: Fri, 25 Mar 2011 20:29:33 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA3DE8@PUEXCB1B.nanterre.francetelecom.fr> <201103161611.21765.remi.denis-courmont@nokia.com> <019901cbe413$61302d90$239088b0$@com> In-Reply-To: <019901cbe413$61302d90$239088b0$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:06:49 -0000 Dan Wing wrote, on 03/16/2011 03:50 PM: > So you are saying you disagree with > > http://tools.ietf.org/html/rfc5508#section-6 Well, that settles it. RFC5508 specifies exactly what any NAT (including CGNs) should do when a port quota is reached: send an ICMP unreachable with code 13. Disagreement with this rule need to go into an RFC5508-bis. This is now out of scope for CGN requirements. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:06:59 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB453A6907 for ; Sat, 26 Mar 2011 03:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tpw8nOSdpJ8 for ; Sat, 26 Mar 2011 03:06: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 193593A684F for ; Sat, 26 Mar 2011 03:06:59 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B5C8921F6C for ; Sat, 26 Mar 2011 06:08:31 -0400 (EDT) Message-ID: <4D8D34CF.4030509@viagenie.ca> Date: Fri, 25 Mar 2011 20:35:27 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA412E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA412E@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:07:00 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 02:51 AM: > The CGN must be compliant with such requirement (i.e., support graceful > shutdown, graceful restart). Going by the chairs' guidelines for what the scope of this draft is, I think this is out of scope. The reason is this requirement is not specific to CGNs. Many other network functions have the same requirement. Therefore, it is out of scope. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:07:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0951628C113 for ; Sat, 26 Mar 2011 03:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBxIE7PKO2rH for ; Sat, 26 Mar 2011 03:07:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3328128C111 for ; Sat, 26 Mar 2011 03:07:03 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C6EF521EE0 for ; Sat, 26 Mar 2011 06:08:37 -0400 (EDT) Message-ID: <4D8D355D.8050604@viagenie.ca> Date: Fri, 25 Mar 2011 20:37:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: <94C682931C08B048B7A8645303FDC9F33C4DBA4137@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4DBA4137@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] CGN REQ: Load-balancing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:07:04 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 03:05 AM: > Examples of requirement to be included: > * Avoid oscillation > * Avoid traffic split between several CGNs The above two do not seem to be specific to CGNs. They could also apply to plain routers, could they not? > * when (static) port forwarding is used, ensure the appropriate CGN is used I don't understand this one. Since it is static, why does it matter which CGN is used? Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:07:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2363428C10E for ; Sat, 26 Mar 2011 03:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlMpXtSDgXVv for ; Sat, 26 Mar 2011 03:07: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 4C55528C111 for ; Sat, 26 Mar 2011 03:07:11 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 43BC020D0D for ; Sat, 26 Mar 2011 06:08:46 -0400 (EDT) Message-ID: <4D8D360A.3080809@viagenie.ca> Date: Fri, 25 Mar 2011 20:40:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: behave@ietf.org References: <114b01cbe7fc$65e607a0$31b216e0$@com> <94C682931C08B048B7A8645303FDC9F33C4EF0EAFC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4EF0EAFC@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:07:12 -0000 mohamed.boucadair@orange-ftgroup.com wrote, on 03/23/2011 03:05 AM: > (*) The current version of I-D is talking about "Carrier-Grade NAT (CGN) > devices" which IMO should be avoided. We are not defining the requirement for > a device but a "Function" or a "Functional Element". Agreed. The next revision will avoid this. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sat Mar 26 03:07:15 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A9C28C115 for ; Sat, 26 Mar 2011 03:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bJHa1DyXpYc for ; Sat, 26 Mar 2011 03:07:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id C8B3E28C11B for ; Sat, 26 Mar 2011 03:07:14 -0700 (PDT) Received: from banana.viagenie.ca (unknown [212.47.23.197]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 484A520D0D; Sat, 26 Mar 2011 06:08:49 -0400 (EDT) Message-ID: <4D8D3657.4030506@viagenie.ca> Date: Fri, 25 Mar 2011 20:41:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dong Zhang References: <4D891FEC.5010106@viagenie.ca> <201103231606313267700@huaweisymantec.com> In-Reply-To: <201103231606313267700@huaweisymantec.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] scoping CGN Requirements document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 10:07:15 -0000 Dong Zhang wrote, on 03/23/2011 04:06 AM: > "Carrier-Grade NAT (CGN): NAT-based [RFC2663] Functional Element operated by an > administrative entity (e.g., operator) to share the same address among several > subscribers. CGN is managed by the administrative entity, not the subscribers". Unless the WG disagrees, the next revision will include this definition. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From Francis.Dupont@fdupont.fr Sat Mar 26 09:10:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D8B3A6939 for ; Sat, 26 Mar 2011 09:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUyeB6hhWwKg for ; Sat, 26 Mar 2011 09:10:12 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id F3D5A3A68FC for ; Sat, 26 Mar 2011 09:10:11 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QGBl97064319; Sat, 26 Mar 2011 17:11:47 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103261611.p2QGBl97064319@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Fri, 25 Mar 2011 19:27:44 -0400. <4D8D24F0.9060209@viagenie.ca> Date: Sat, 26 Mar 2011 17:11:47 +0100 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 16:10:13 -0000 In fact there are two things: - filtering which is builtin in a NAT or an AFTR - extra filtering which is usually performed by a firewall the issue with the second is a firewall is not an IETF object, i.e., there is no good RFC to refer to... Regards Francis.Dupont@fdupont.fr PS: IMHO despite of this issue CGN REQs should not include firewall stuff (but as I said some days ago to deny a problem doesn't solve it :-). From Francis.Dupont@fdupont.fr Sat Mar 26 13:45:08 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6059B3A6962 for ; Sat, 26 Mar 2011 13:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z+NjejUC7Sb for ; Sat, 26 Mar 2011 13:45:07 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 0EAD53A6955 for ; Sat, 26 Mar 2011 13:45:06 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QKkg1L080998 for ; Sat, 26 Mar 2011 21:46:42 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103262046.p2QKkg1L080998@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Sat, 26 Mar 2011 21:46:42 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] about CGN requirements (1) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 20:45:08 -0000 This is the first of a serie of comments about CGN requirements (aka draft-ietf-behave-lsn-requirements-01.txt). 1 page 3: quoting "This document builds upon previous works describing requirements for generic NAT devices.[RFC4787][RFC5382][RFC5508]. These documents still apply in this context. What follows are additional requirements, to be satisfied on top of previous ones." => even if I understand what the CGN requirements should build on the previous NAT RFCs I am afraid this makes the document to inherit very questionable ("disconnected from the reality" to stay polite) requirements like RFC 5382 REQ-5: "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. or even RFC 4787 REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior. because: - ~70 % of deployed NATs don't implement EIM (i.e., this requirement is simply ignored in the real world) - this doesn't seem to have a negative impact on users (i.e., the reasons of this requirement doesn't match the real world) - as far as I know ISPs want strong port randomization (i.e., something which is opposed to efficient sharing scheme as EIM) Note I don't argue EIM is silly, it is a fine way to improve port sharing (the function of NATs) but the MUST is clearly not appropriate for CGNs. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 26 13:46:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9753A695C for ; Sat, 26 Mar 2011 13:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STZ3Q5X3lSST for ; Sat, 26 Mar 2011 13:46:48 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 7EC4F3A6955 for ; Sat, 26 Mar 2011 13:46:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QKmO5l081121 for ; Sat, 26 Mar 2011 21:48:24 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103262048.p2QKmO5l081121@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Sat, 26 Mar 2011 21:48:24 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] about CGN requirements (2) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 20:46:49 -0000 2 page 3: the term CPE should be defined and made clear it is the device associated to a subscriber. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 26 13:53:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A6E3A6962 for ; Sat, 26 Mar 2011 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2-yO4u6KVoa for ; Sat, 26 Mar 2011 13:53:55 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 46BE53A6801 for ; Sat, 26 Mar 2011 13:53:55 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QKtVqh081541 for ; Sat, 26 Mar 2011 21:55:31 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103262055.p2QKtVqh081541@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Sat, 26 Mar 2011 21:55:31 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] about CGN requirements (3) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 20:53:56 -0000 REQ-1: A CGN MUST have an "IP address pooling" behaviour of "Paired". Some comments: - the same external IP address should be per CPE to catch DS-Lite & co - the term "persistent" should be defined. I propose to use it when the CGN keeps the same external IP address when there is at least one mapping for the CPE. - some people want to see the MUST relaxed into a SHOULD. IMHO it makes sense, e.g., it allows the ISP to renumber. - REQ-1 and REQ-6 are trivially incompatible (the obvious solution is to add a SHOULD for hot standby in REQ-6 which currently is a MUST for cold standby) Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 26 14:00:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952793A6962 for ; Sat, 26 Mar 2011 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qXc94+r7pzC for ; Sat, 26 Mar 2011 14:00:11 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id C34DD3A6801 for ; Sat, 26 Mar 2011 14:00:10 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QL1k4G081954 for ; Sat, 26 Mar 2011 22:01:46 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103262101.p2QL1k4G081954@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Sat, 26 Mar 2011 22:01:46 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] about CGN requirements (4) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 21:00:12 -0000 REQ-3: A CGN SHOULD limit the number of TCP sessions per CPE. it should be removed as it doesn't match the way TCP sessions are tracked by current implementations (BTW with APDM REQ-2 is enough, with EIM only the first TCP session is tracked and to have more than one TCP session is a state similar to extablished... There are other ways but IMHO nobody tries to track all TCP sessions of one EIM mapping) Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 26 14:02:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2064E3A695C for ; Sat, 26 Mar 2011 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8teJIP5CM6Dg for ; Sat, 26 Mar 2011 14:02:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E75EC3A6801 for ; Sat, 26 Mar 2011 14:02:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QL3v5R082129 for ; Sat, 26 Mar 2011 22:03:57 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103262103.p2QL3v5R082129@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Sat, 26 Mar 2011 22:03:57 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] about CGN requirements (5) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 21:02:23 -0000 REQ-4: It SHOULD be possible to administratively turn off translation for specific destination addresses and/or ports. => it is a typical "firewall" requirement (IMHO it has nothing to do here, and we have to find a place for it and others). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 26 14:08:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A373A6965 for ; Sat, 26 Mar 2011 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iHeB8TMBfzW for ; Sat, 26 Mar 2011 14:08:13 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E6CD23A6840 for ; Sat, 26 Mar 2011 14:08:12 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2QL9mBO082523 for ; Sat, 26 Mar 2011 22:09:48 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103262109.p2QL9mBO082523@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Sat, 26 Mar 2011 22:09:48 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] about CGN requirements (6) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 21:08:13 -0000 7. Security Considerations (page 8) is far too weak: there are a lot of bad things you can do with a CGN, including mapping theft (cf PCP mailing list). Regards Francis.Dupont@fdupont.fr From rpenno@juniper.net Sat Mar 26 19:54:37 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5C428C0FF for ; Sat, 26 Mar 2011 19:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 KtW6CsSZZy4A for ; Sat, 26 Mar 2011 19:54:37 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id C1F0828C101 for ; Sat, 26 Mar 2011 19:54:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTY6nS8BN9gqpQ+P8s6i0ad2X0d3I6KNb@postini.com; Sat, 26 Mar 2011 19:56:13 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 26 Mar 2011 19:54:46 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 26 Mar 2011 22:56:10 -0400 From: Reinaldo Penno To: Simon Perreault , "behave@ietf.org" Date: Sat, 26 Mar 2011 22:56:07 -0400 Thread-Topic: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) Thread-Index: Acvrnclh0Tma3kAGScOWZJOh/6+BaQAjLtf2 Message-ID: In-Reply-To: <4D8D336D.1050604@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 02:54:38 -0000 On 3/25/11 5:29 PM, "Simon Perreault" wrote: > Dan Wing wrote, on 03/16/2011 03:50 PM: >> So you are saying you disagree with >>=20 >> http://tools.ietf.org/html/rfc5508#section-6 >=20 > Well, that settles it. RFC5508 specifies exactly what any NAT (including = CGNs) 'Any' NAT at that time did not include CGN (address sharing). Regular NATs do not need to deal with address sharing (which is the basis of CGN definition). It seems clear throughout all examples in previous BEHAVE RFCs that this was not in the radar. > should do when a port quota is reached: send an ICMP unreachable with cod= e 13. >=20 > Disagreement with this rule need to go into an RFC5508-bis. This is now o= ut of > scope for CGN requirements. I believe we should strive to reuse previous RFCs recommendations but because of the very nature of CGN we can not just get them all. >=20 > Thanks, > Simon From simon.perreault@viagenie.ca Sun Mar 27 02:25:42 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74AA3A6906 for ; Sun, 27 Mar 2011 02:25:42 -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 0Z4BnihrdgY9 for ; Sun, 27 Mar 2011 02:25:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 819FC3A68FA for ; Sun, 27 Mar 2011 02:25:41 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2001:df8:0:16:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF21420D3A; Sun, 27 Mar 2011 05:27:16 -0400 (EDT) Message-ID: <4D8F02F3.10304@viagenie.ca> Date: Sun, 27 Mar 2011 11:27:15 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6 MIME-Version: 1.0 To: Reinaldo Penno References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: CGN behaviour when the port quota is reached (ICMP notification) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 09:25:43 -0000 Reinaldo Penno wrote, on 03/27/2011 04:56 AM: >> Well, that settles it. RFC5508 specifies exactly what any NAT (including CGNs) > > 'Any' NAT at that time did not include CGN (address sharing). Regular NATs > do not need to deal with address sharing (which is the basis of CGN > definition). It seems clear throughout all examples in previous BEHAVE RFCs > that this was not in the radar. Of course, since those RFCs predate the draft we are now discussing. > I believe we should strive to reuse previous RFCs recommendations but > because of the very nature of CGN we can not just get them all. Are you suggesting that we should "pick and choose" requirements from RFC 5008? I suppose we could do that, but only if there is CGN-specific justification. So far all I've heard about this issue applied to all NATs. Thanks, Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 04:46:00 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5302F3A67C3 for ; Sun, 27 Mar 2011 04:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 EiiDlgjstYF6 for ; Sun, 27 Mar 2011 04:45:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id ECFFE3A67B4 for ; Sun, 27 Mar 2011 04:45:58 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9C2D618C1D2; Sun, 27 Mar 2011 13:47:34 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 50C9227C037; Sun, 27 Mar 2011 13:47:30 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Sun, 27 Mar 2011 13:47:30 +0200 From: To: Simon Perreault , "behave@ietf.org" Date: Sun, 27 Mar 2011 13:47:28 +0200 Thread-Topic: [BEHAVE] CGN REQ: Load-balancing Thread-Index: AcvrncuVteFRFwL/TReh9uYbeN0SDAA1c5Rw Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F908@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA4137@PUEXCB1B.nanterre.francetelecom.fr> <4D8D355D.8050604@viagenie.ca> In-Reply-To: <4D8D355D.8050604@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.23.130317 Subject: Re: [BEHAVE] CGN REQ: Load-balancing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 11:46:00 -0000 Dear Simon, Please see inline. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : samedi 26 mars 2011 01:38 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Load-balancing mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 03:05 AM: > Examples of requirement to be included: > * Avoid oscillation > * Avoid traffic split between several CGNs The above two do not seem to be specific to CGNs. They could also apply to = plain routers, could they not? Med: because=20 * The CGN is not necessarily embedded in a router * the stateful nature of the CGN=20 * if two CGNs are used, distinct external IP addresses will be used * imagine your RTP flows handled by CGN1 and RTCP by CGN2... > * when (static) port forwarding is used, ensure the appropriate CGN is us= ed I don't understand this one. Since it is static, why does it matter which C= GN is used? Med: Because the static mappings are not instantiated in all CGNs in the ne= twork! Per-subscriber static mappings are likely to be configured only in o= ne CGN. If you load balance your traffic between several CGN in a blind man= ner, the service will be broken for those customers. To avoid this, your lo= ad-balancing must redirect the customers to the CGN where their static mapp= ings are instantiated.=20 BTW, this less critical for PCP-instructed mappings because the PCP Client = or IWF will recreate the mapping when a new CGN is assigned.=20 Thanks, Simon --=20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 04:49:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D5D3A67E5 for ; Sun, 27 Mar 2011 04:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 IgmHia5gxRNL for ; Sun, 27 Mar 2011 04:49:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id D36203A67C3 for ; Sun, 27 Mar 2011 04:49:30 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 54E4C22C498; Sun, 27 Mar 2011 13:51:07 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3D0E3238055; Sun, 27 Mar 2011 13:51:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Sun, 27 Mar 2011 13:51:07 +0200 From: To: Simon Perreault , "behave@ietf.org" Date: Sun, 27 Mar 2011 13:51:04 +0200 Thread-Topic: [BEHAVE] CGN REQ: Planned maintenance operations Thread-Index: AcvrncgNwRaBldwKQ/+06WagoYe8wQA1vpKQ Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F909@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA412E@PUEXCB1B.nanterre.francetelecom.fr> <4D8D34CF.4030509@viagenie.ca> In-Reply-To: <4D8D34CF.4030509@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.101222 Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 11:49:32 -0000 Re-, I'm in a full disagreement here. Because of the stateful nature of the CGN, service availably is a MUST. CGN= MUST be able to gracefully handover/etc. If you take for instance BGP, there is a procedure how graceful restart is = defined. For CGN, we need a specific procedure. Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Simon Perreault Envoy=E9 : samedi 26 mars 2011 01:35 =C0 : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Planned maintenance operations mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 02:51 AM: > The CGN must be compliant with such requirement (i.e., support graceful > shutdown, graceful restart). Going by the chairs' guidelines for what the scope of this draft is, I thin= k this is out of scope. The reason is this requirement is not specific to CGN= s. Many other network functions have the same requirement. Therefore, it is ou= t of scope. Thanks, Simon --=20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 04:53:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CDA3A67EA for ; Sun, 27 Mar 2011 04:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 KfPZnYYZT1x3 for ; Sun, 27 Mar 2011 04:53:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id A2BF63A67DB for ; Sun, 27 Mar 2011 04:53:28 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 8315A1B8292; Sun, 27 Mar 2011 13:55:04 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6B9CC38406B; Sun, 27 Mar 2011 13:55:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Sun, 27 Mar 2011 13:55:04 +0200 From: To: Francis Dupont , Simon Perreault Date: Sun, 27 Mar 2011 13:55:02 +0200 Thread-Topic: [BEHAVE] CGN REQ: SPAM Protection Thread-Index: Acvr0IXkPTWsf+SvQ4GTEblniVLg6AApO9Jw Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F90A@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Fri, 25 Mar 2011 19:27:44 -0400. <4D8D24F0.9060209@viagenie.ca> <201103261611.p2QGBl97064319@givry.fdupont.fr> In-Reply-To: <201103261611.p2QGBl97064319@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.104221 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 11:53:29 -0000 Hi Francis, all, There is no I-D which defines what is a firewall... Ingress filtering is needed to meet some provider-specific needs: this incl= udes filtering internal port, internal IP address, NAT filtering, etc. Please don't focus on the "N" and forget "CG". Cheers, Med =20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Francis Dupont Envoy=E9 : samedi 26 mars 2011 17:12 =C0 : Simon Perreault Cc : behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: SPAM Protection In fact there are two things: - filtering which is builtin in a NAT or an AFTR - extra filtering which is usually performed by a firewall the issue with the second is a firewall is not an IETF object, i.e., there is no good RFC to refer to... Regards Francis.Dupont@fdupont.fr PS: IMHO despite of this issue CGN REQs should not include firewall stuff (but as I said some days ago to deny a problem doesn't solve it :-). _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 04:59:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4DA3A67D9 for ; Sun, 27 Mar 2011 04:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.146 X-Spam-Level: X-Spam-Status: No, score=-3.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 jv1SnU6a7exk for ; Sun, 27 Mar 2011 04:59:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 0C1193A67FF for ; Sun, 27 Mar 2011 04:59:39 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7899F324310; Sun, 27 Mar 2011 14:01:14 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5DA35238055; Sun, 27 Mar 2011 14:01:14 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Sun, 27 Mar 2011 14:01:14 +0200 From: To: Benson Schliesser , Simon Perreault , "behave@ietf.org" Date: Sun, 27 Mar 2011 14:01:12 +0200 Thread-Topic: [BEHAVE] CGN REQ: Shared address pool Thread-Index: Acvj657z44g3i9vkTGO0P3dO1+Qm0wADArHgADwt9DUB42DNcA== Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F90B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA4099@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.101222 Subject: [BEHAVE] pRE: CGN REQ: Shared address pool X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 11:59:40 -0000 Dear Benson, I don't think this is a marginal case. Imagine an SP who want to have an ef= ficient use of its available IP addresses, small pools will be provisioned = in the CGNs as external IP addresses; once the address usage reaches a give= n threshold (e.g., 90%), a new pool can be added, etc.=20 This is why CGNs must not have any assumption on the size of the address po= ol neither its structure. Cheers, Med -----Message d'origine----- De : Benson Schliesser [mailto:bschlies@cisco.com]=20 Envoy=E9 : jeudi 17 mars 2011 22:15 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Shared address pool On 3/16/11 11:39 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: >>> I don't know how this should be covered in the I-D, but I see a value t= o >>> have a section to elaborate on the configured address pool to be used i= n >>> the external interface of the CGN. In particular, the CGN should: >>> =20 >>> * support contiguous address pool >>> * support non-contiguous addresses >> >> Why? > > Because we want to avoid CGN implementations assuming that only contiguou= s > address pools can be configured as shared addresses. Address pools at our > disposable may not be "aggregatable"... That may be true in some cases (marginal today, perhaps more of an issue in the future), and therefore it's not a bad feature. But I see no reason to make the pool size and/or composition a requirement for CGN. The only requirement is that pools can be routed. I believe that what you describe is an implementation topic, perhaps appropriate in a RFI but not the requirements draft. Cheers, -Benson From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 05:04:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A6A3A67E5 for ; Sun, 27 Mar 2011 05:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 SPvSgEHudemT for ; Sun, 27 Mar 2011 05:04:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 564DA3A67DA for ; Sun, 27 Mar 2011 05:04:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 801B322C3A7; Sun, 27 Mar 2011 14:05:56 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 65E91238055; Sun, 27 Mar 2011 14:05:56 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Sun, 27 Mar 2011 14:05:56 +0200 From: To: Benson Schliesser , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Date: Sun, 27 Mar 2011 14:05:54 +0200 Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAJOJc3ABZsQNAAUs9pnQAAK4MUAeJmSWA= Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F90C@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.101222 Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:04:22 -0000 Dear Benson, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Benson Schliesser [mailto:bschlies@cisco.com]=20 Envoy=E9 : jeudi 17 mars 2011 22:49 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; draft-ietf-behave-lsn-requirements@to= ols.ietf.org Cc : 'behave' <(behave@ietf.org)> Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment On 3/17/11 4:44 PM, "Benson Schliesser" wrote: > It doesn't matter what kind of port-set you implement - there are no case= s > where the port-set feature is a requirement. Sorry, I should have said: the port-set feature is not a requirement for CGN. There are specific implementations of CGN where it might be inherent and/or desired, but that doesn't mean it applies to the general case. Med: If we adopt that perspective, we can also say:=20 "the one-by-one mapping feature is not a requirement for CGN. There are specific implementations of CGN where it might be inherent and/or desired, but that doesn't mean it applies to the general case. ", No= ? Unlike traditional NATs, the CGN comes with its own design choices and IMO = port set is one of them.=20 Cheers, -Benson >=20 > There are cases where it is desirable, including logging reduction etc. > Operators that desire this feature should include it in their RFI. But i= t > doesn't belong as a MUST or SHOULD in the requirements draft - it ought t= o > be listed as a MAY item. >=20 > Cheers, > -Benson >=20 >=20 > On 3/16/11 1:16 AM, "mohamed.boucadair@orange-ftgroup.com" > wrote: >=20 >> Dear Benson, >>=20 >> The port set does not means contiguous port range. Random port set can b= e >> handled by the CGN. This should be explicit in the requirements IMO. >>=20 >> In deployments where a small address sharing ration is needed (e.g., 1:2= , >> 1:3), port randomization is still possible within the large port range. >>=20 >> The I-D already discusses the trade-offs: >>=20 >> Security: Mechanisms (1) and (2) provide very good security in that >> ports numbers are not easily guessed. Easily guessed port numbers >> put subscribers at risk of the attacks described in [RFC6056]. >> Mechanism (3) provides poor security to subscribers, especially if >> the "bin" size is small. >>=20 >> Cheers, >> Med=20 >>=20 >> -----Message d'origine----- >> De : Benson Schliesser [mailto:bschlies@cisco.com] >> Envoy=E9 : mardi 15 mars 2011 20:31 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; >> draft-ietf-behave-lsn-requirements@tools.ietf.org >> Cc : 'behave' <(behave@ietf.org)> >> Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment >>=20 >>=20 >> On 3/15/11 9:07 AM, "mohamed.boucadair@orange-ftgroup.com" >> wrote: >>=20 >>> Section 5=20 >>> http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#sectio= n-5 >>> discusses various modes for the port assignment but there is no explici= t >>> requirement.=20 >>> =20 >>> I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) suppo= rt >>> the >>> ability to assign port sets. The selection of the dynamic mode vs. port= set >>> is >>> deployment-specific. >>=20 >> I don't support this as a MUST or SHOULD. A port-set feature isn't a >> requirement for successful deployment of a CGN. In fact, a port-set fea= ture >> might be seen to have negative implications for security, scale, etc. I= t is >> an implementation choice, and the requirements document ought to capture= it >> as a MAY. >>=20 >> Cheers, >> -Benson >>=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 05:10:54 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FA73A67EE for ; Sun, 27 Mar 2011 05:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 Xab5y17IThUH for ; Sun, 27 Mar 2011 05:10:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 60F733A67DA for ; Sun, 27 Mar 2011 05:10:51 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 5EDC22AC3E5; Sun, 27 Mar 2011 14:12:27 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4898E38405A; Sun, 27 Mar 2011 14:12:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Sun, 27 Mar 2011 14:12:27 +0200 From: To: Francis Dupont , "behave@ietf.org" Date: Sun, 27 Mar 2011 14:12:25 +0200 Thread-Topic: [BEHAVE] about CGN requirements (3) Thread-Index: Acvr+Cj+4Q1kvvTUSiGby7Mpb3VEJQAf42yg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F90D@PUEXCB1B.nanterre.francetelecom.fr> References: <201103262055.p2QKtVqh081541@givry.fdupont.fr> In-Reply-To: <201103262055.p2QKtVqh081541@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.104221 Subject: Re: [BEHAVE] about CGN requirements (3) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:10:54 -0000 Hi Francis, I fully agree with your three first bullets. FYI, this is similar to what h= as been discussed in: http://www.ietf.org/mail-archive/web/behave/current/m= sg09284.html Cheers, Med -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Francis Dupont Envoy=E9 : samedi 26 mars 2011 21:56 =C0 : behave@ietf.org Objet : [BEHAVE] about CGN requirements (3) REQ-1: A CGN MUST have an "IP address pooling" behaviour of "Paired". Some comments: - the same external IP address should be per CPE to catch DS-Lite & co - the term "persistent" should be defined. I propose to use it when the CGN keeps the same external IP address when there is at least one mapping for the CPE. - some people want to see the MUST relaxed into a SHOULD. IMHO it makes sense, e.g., it allows the ISP to renumber. - REQ-1 and REQ-6 are trivially incompatible (the obvious solution is to add a SHOULD for hot standby in REQ-6 which currently is a MUST for cold standby) Regards Francis.Dupont@fdupont.fr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From Francis.Dupont@fdupont.fr Sun Mar 27 05:11:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9A73A67F5 for ; Sun, 27 Mar 2011 05:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcWFnQMGFHst for ; Sun, 27 Mar 2011 05:11:45 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 8642F3A67DA for ; Sun, 27 Mar 2011 05:11:45 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2RCDLAR037953; Sun, 27 Mar 2011 14:13:21 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103271213.p2RCDLAR037953@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Sun, 27 Mar 2011 13:47:28 +0200. <94C682931C08B048B7A8645303FDC9F33C4EF0F908@PUEXCB1B.nanterre.francetelecom.fr> Date: Sun, 27 Mar 2011 14:13:21 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Load-balancing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:11:46 -0000 In your previous mail you wrote: * The CGN is not necessarily embedded in a router => I disagree about this argument: the NAT function is a super set of the router function (yes I know you can write a NAT code for a L2 device but such a thing should be at least strongly NOT RECOMMENDED). Regards Francis.Dupont@fdupont.fr From bschlies@cisco.com Sun Mar 27 05:17:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABAC3A6809 for ; Sun, 27 Mar 2011 05:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgmG0BCufgIv for ; Sun, 27 Mar 2011 05:17:01 -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 008973A6804 for ; Sun, 27 Mar 2011 05:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=4724; q=dns/txt; s=iport; t=1301228318; x=1302437918; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=cDHeyqlLssk9ZnxY1L1BUyDR7aJN0IudNwp5umPjZ0Y=; b=N0NhKXoyxRDx84VG9+7DXxYForD2m8pcekQ77oVetz1eDaDg3c7Wbhf0 heOA4EdvfX6Wt8FvmRzxpk5B8+CaBodFYNHEIGX7H2fRYeGxTRv+B7A9L BUFFu6RpLYV//SMVcxicp57/OiAqKgsp+0vZnWLIGp1aZH+wqHdjhaobJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFoqj02tJV2Y/2dsb2JhbAClYXeIZAecaZsBhWkEhTqHPYNa X-IronPort-AV: E=Sophos;i="4.63,251,1299456000"; d="scan'208";a="418968597" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 27 Mar 2011 12:18:37 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2RCIbu4016304; Sun, 27 Mar 2011 12:18:37 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 07:18:37 -0500 Received: from 10.61.102.16 ([10.61.102.16]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([144.254.231.93]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Mar 2011 12:18:37 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 27 Mar 2011 07:18:33 -0500 From: Benson Schliesser To: , "draft-ietf-behave-lsn-requirements@tools.ietf.org" Message-ID: Thread-Topic: [BEHAVE] CGN REQ: Port Set Assignment Thread-Index: AcvjIqvyHEN/PZAJQFafEA4YjAjBJAAJOJc3ABZsQNAAUs9pnQAAK4MUAeJmSWAAAJSyYA== In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4EF0F90C@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Mar 2011 12:18:37.0527 (UTC) FILETIME=[199F7670:01CBEC79] Cc: "'behave' <\(behave@ietf.org\)>" Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:17:02 -0000 Med - Parsing your inline comment is difficult. But from what I can tell, I agre= e with your straw-man statement: the method for allocating ports is an implementation issue, and we shouldn't require any one specific approach (one-by-one, port-set, etc). It's a good idea to discuss the trade-offs: port allocation method versus logging, scale, security, etc. But it goes too far to make a requirement based on your implementation preference. Cheers, -Benson On 3/27/11 7:05 AM, "mohamed.boucadair@orange-ftgroup.com" wrote: >=20 > Dear Benson, >=20 > Please see inline. >=20 > Cheers, > Med=20 >=20 > -----Message d'origine----- > De : Benson Schliesser [mailto:bschlies@cisco.com] > Envoy=E9 : jeudi 17 mars 2011 22:49 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; > draft-ietf-behave-lsn-requirements@tools.ietf.org > Cc : 'behave' <(behave@ietf.org)> > Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment >=20 >=20 > On 3/17/11 4:44 PM, "Benson Schliesser" wrote: >=20 >> It doesn't matter what kind of port-set you implement - there are no cas= es >> where the port-set feature is a requirement. >=20 > Sorry, I should have said: the port-set feature is not a requirement for > CGN. There are specific implementations of CGN where it might be inheren= t > and/or desired, but that doesn't mean it applies to the general case. >=20 >=20 > Med: If we adopt that perspective, we can also say: > "the one-by-one mapping feature is not a requirement for > CGN. There are specific implementations of CGN where it might be inheren= t > and/or desired, but that doesn't mean it applies to the general case. ", = No? >=20 > Unlike traditional NATs, the CGN comes with its own design choices and IM= O > port set is one of them. >=20 >=20 > Cheers, > -Benson >=20 >=20 >=20 >>=20 >> There are cases where it is desirable, including logging reduction etc. >> Operators that desire this feature should include it in their RFI. But = it >> doesn't belong as a MUST or SHOULD in the requirements draft - it ought = to >> be listed as a MAY item. >>=20 >> Cheers, >> -Benson >>=20 >>=20 >> On 3/16/11 1:16 AM, "mohamed.boucadair@orange-ftgroup.com" >> wrote: >>=20 >>> Dear Benson, >>>=20 >>> The port set does not means contiguous port range. Random port set can = be >>> handled by the CGN. This should be explicit in the requirements IMO. >>>=20 >>> In deployments where a small address sharing ration is needed (e.g., 1:= 2, >>> 1:3), port randomization is still possible within the large port range. >>>=20 >>> The I-D already discusses the trade-offs: >>>=20 >>> Security: Mechanisms (1) and (2) provide very good security in that >>> ports numbers are not easily guessed. Easily guessed port number= s >>> put subscribers at risk of the attacks described in [RFC6056]. >>> Mechanism (3) provides poor security to subscribers, especially i= f >>> the "bin" size is small. >>>=20 >>> Cheers, >>> Med=20 >>>=20 >>> -----Message d'origine----- >>> De : Benson Schliesser [mailto:bschlies@cisco.com] >>> Envoy=E9 : mardi 15 mars 2011 20:31 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; >>> draft-ietf-behave-lsn-requirements@tools.ietf.org >>> Cc : 'behave' <(behave@ietf.org)> >>> Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment >>>=20 >>>=20 >>> On 3/15/11 9:07 AM, "mohamed.boucadair@orange-ftgroup.com" >>> wrote: >>>=20 >>>> Section 5=20 >>>> http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#secti= on-5 >>>> discusses various modes for the port assignment but there is no explic= it >>>> requirement.=20 >>>> =20 >>>> I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) supp= ort >>>> the >>>> ability to assign port sets. The selection of the dynamic mode vs. por= t set >>>> is >>>> deployment-specific. >>>=20 >>> I don't support this as a MUST or SHOULD. A port-set feature isn't a >>> requirement for successful deployment of a CGN. In fact, a port-set fe= ature >>> might be seen to have negative implications for security, scale, etc. = It is >>> an implementation choice, and the requirements document ought to captur= e it >>> as a MAY. >>>=20 >>> Cheers, >>> -Benson >>>=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 Francis.Dupont@fdupont.fr Sun Mar 27 05:22:09 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3D93A6804 for ; Sun, 27 Mar 2011 05:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0xEHAOvRAFp for ; Sun, 27 Mar 2011 05:22:08 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 2FD923A67D0 for ; Sun, 27 Mar 2011 05:22:08 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2RCNiuI038568; Sun, 27 Mar 2011 14:23:44 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103271223.p2RCNiuI038568@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Sun, 27 Mar 2011 13:55:02 +0200. <94C682931C08B048B7A8645303FDC9F33C4EF0F90A@PUEXCB1B.nanterre.francetelecom.fr> Date: Sun, 27 Mar 2011 14:23:44 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: SPAM Protection X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:22:09 -0000 In your previous mail you wrote: There is no I-D which defines what is a firewall... => I know and this is the reason I don't say your problem should not be addressed. But this is not in the scope of BEHAVE too (and seeing what BEHAVE did for NATs I really prefer this will be never handled by BEHAVE :-). I have an idea: as it is something looking for a place to be done, you should ask during the technical plenary where should be the place (including the area). You could get an IAB/IESG bless decision... Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 05:23:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768593A67EE for ; Sun, 27 Mar 2011 05:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 jBSLopQV06tm for ; Sun, 27 Mar 2011 05:23:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 870913A67D0 for ; Sun, 27 Mar 2011 05:23:21 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 646A61902E4; Sun, 27 Mar 2011 14:24:57 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 450AC15805E; Sun, 27 Mar 2011 14:24:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Sun, 27 Mar 2011 14:24:57 +0200 From: To: "Francis.Dupont@fdupont.fr" Date: Sun, 27 Mar 2011 14:24:54 +0200 Thread-Topic: [BEHAVE] CGN REQ: Load-balancing Thread-Index: AcvseF7YOv1lMUHeRvGlJPd9eZKtHwAAIJCA Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F90E@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Sun, 27 Mar 2011 13:47:28 +0200. <94C682931C08B048B7A8645303FDC9F33C4EF0F908@PUEXCB1B.nanterre.francetelecom.fr> <201103271213.p2RCDLAR037953@givry.fdupont.fr> In-Reply-To: <201103271213.p2RCDLAR037953@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.103321 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Load-balancing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:23:22 -0000 Re-, An IP router is not supposed to NAT; it should forward IP datagrams. A CGN is an IP node but not necessarily an IP router. BTW, we have a simila= r issue in the VoIP case where we have SBCs (which are some kind of CGN); s= ome products in the market do not embed OSPF/ISIS/BGP/6PE/etc stacks... Cheers, Med -----Message d'origine----- De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Envoy=E9 : dimanche 27 mars 2011 14:13 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Simon Perreault; behave@ietf.org Objet : Re: [BEHAVE] CGN REQ: Load-balancing=20 In your previous mail you wrote: * The CGN is not necessarily embedded in a router =3D> I disagree about this argument: the NAT function is a super set of the router function (yes I know you can write a NAT code for a L2 device but such a thing should be at least strongly NOT RECOMMENDED). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sun Mar 27 05:38:16 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F8B3A67EE for ; Sun, 27 Mar 2011 05:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5R27BhcJEdr for ; Sun, 27 Mar 2011 05:38:15 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 17E713A67F5 for ; Sun, 27 Mar 2011 05:38:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2RCdoNc039569; Sun, 27 Mar 2011 14:39:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103271239.p2RCdoNc039569@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Sun, 27 Mar 2011 14:24:54 +0200. <94C682931C08B048B7A8645303FDC9F33C4EF0F90E@PUEXCB1B.nanterre.francetelecom.fr> Date: Sun, 27 Mar 2011 14:39:50 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Load-balancing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 12:38:16 -0000 In your previous mail you wrote: An IP router is not supposed to NAT; it should forward IP datagrams. => so you share my opinion the IP router function is to forward IP packets. A CGN is an IP node but not necessarily an IP router. => this is a point where I disagree: a CGN MUST be an IP router (it is so obvious BEHAVE never emits such a requirement, BTW RFC 2663 (the place where NATs are defined) explicitly stands NATs are router, cf 2.2. Transparent routing). BTW, we have a similar issue in the VoIP case where we have SBCs (which are some kind of CGN); some products in the market do not embed OSPF/ISIS/BGP/6PE/etc stacks... => to be an IP router doesn't mean to have to support routing protocols (even someone could argue this makes an IP router easier to use). Regards Francis.Dupont@fdupont.fr From teemu.savolainen@nokia.com Sun Mar 27 06:19:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CAD3A67E3; Sun, 27 Mar 2011 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSA049oXW9Gw; Sun, 27 Mar 2011 06:19:10 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 5070428C100; Sun, 27 Mar 2011 06:19:10 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2RDKjqP012355; Sun, 27 Mar 2011 16:20:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 16:20:35 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 27 Mar 2011 15:20:35 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Sun, 27 Mar 2011 15:20:34 +0200 From: To: , Thread-Topic: RFC3484-revise and NAT64 Well-Known Prefix Thread-Index: AcvsgcCRXbnjiKSUSuKTwnQkrPt+Hw== Date: Sun, 27 Mar 2011 13:20:34 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE443096962014C5D008AM1MPN1036mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Mar 2011 13:20:35.0901 (UTC) FILETIME=[C1F24ED0:01CBEC81] X-Nokia-AV: Clean Subject: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 13:19:11 -0000 --_000_916CE6CF87173740BC8A2CE443096962014C5D008AM1MPN1036mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I discussed shortly with Arifumi about RFC3484 default policy table updates= and NAT64 WKP, i.e. whether the default policy table should take a stand o= n 64:ff9b::/96 preference. It seemed to us that default policy table does not necessarily have to, as = it could be ok to handle addresses with WKP similarly to global IPv6 addres= ses. Furthermore, the default policy table anyway cannot cover Network-Spec= ific Prefixes. Hence prefixes used for protocol translation would be handled like global I= Pv6 addresses unless something different is configured via policy distribut= ion mechanism? And this should perhaps be documented into the RFC3484-revis= ed. Best regards, Teemu --_000_916CE6CF87173740BC8A2CE443096962014C5D008AM1MPN1036mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I discussed shortly with Arifumi about RFC3484 defau= lt policy table updates and NAT64 WKP, i.e. whether the default policy tabl= e should take a stand on 64:ff9b::/96 preference.

 

It seemed to us that default policy table does not n= ecessarily have to, as it could be ok to handle addresses with WKP similarl= y to global IPv6 addresses. Furthermore, the default policy table anyway ca= nnot cover Network-Specific Prefixes.

 

Hence prefixes used for protocol translation would b= e handled like global IPv6 addresses unless something different is configur= ed via policy distribution mechanism? And this should perhaps be documented= into the RFC3484-revised.

 

Best regards,

 

        &nbs= p;       Teemu

--_000_916CE6CF87173740BC8A2CE443096962014C5D008AM1MPN1036mgdn_-- From miyakawa@nttv6.jp Sun Mar 27 06:43:18 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525823A6849 for ; Sun, 27 Mar 2011 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rKh2Hmqqz8q for ; Sun, 27 Mar 2011 06:43:17 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by core3.amsl.com (Postfix) with ESMTP id AD7653A6845 for ; Sun, 27 Mar 2011 06:43:16 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 796F7BDC52; Sun, 27 Mar 2011 22:44:51 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 993747049B; Sun, 27 Mar 2011 22:44:50 +0900 (JST) Date: Sun, 27 Mar 2011 22:44:50 +0900 (JST) Message-Id: <20110327.224450.71161718.miyakawa@nttv6.jp> To: mohamed.boucadair@orange-ftgroup.com From: Shin Miyakawa In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4EF0F909@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA412E@PUEXCB1B.nanterre.francetelecom.fr> <4D8D34CF.4030509@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4EF0F909@PUEXCB1B.nanterre.francetelecom.fr> Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: miyakawa@nttv6.jp, behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 13:43:18 -0000 Mohamed, Thank you for your comment of our draft, as one of th eoriginal author of this draft, I'd like to respond to thi= s... Then.... From: Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations Date: Sun, 27 Mar 2011 13:51:04 +0200 > Because of the stateful nature of the CGN, service availably is a MUS= T. CGN MUST be able to gracefully handover/etc. This depends on operators' choise. = I have talked many operators on the earth who consider about CGN deploy= ment. There are certain amount of operators who do not think they need = high-availability of CGN. So we can not use MUST. It is too strong as a standard document. Of course, I agree with SHOULD. > If you take for instance BGP, there is a procedure how graceful resta= rt is defined. For CGN, we need a specific procedure. Also the graceful restart mechanism of CGN is quite implentation depend= ed. I do not think that we can define a general procedure between two CGNs which comes from different vendors. Best wishes, Shin Miyakawa = > = > Cheers, > Med > = > = > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la p= art de Simon Perreault > Envoy=E9 : samedi 26 mars 2011 01:35 > =C0 : behave@ietf.org > Objet : Re: [BEHAVE] CGN REQ: Planned maintenance operations > = > mohamed.boucadair@orange-ftgroup.com wrote, on 03/17/2011 02:51 AM: >> The CGN must be compliant with such requirement (i.e., support grace= ful >> shutdown, graceful restart). > = > Going by the chairs' guidelines for what the scope of this draft is, = I think > this is out of scope. The reason is this requirement is not specific = to CGNs. > Many other network functions have the same requirement. Therefore, it= is out of > scope. > = > Thanks, > Simon > -- = > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > = From cb.list6@gmail.com Sun Mar 27 08:13:51 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C3D3A686C; Sun, 27 Mar 2011 08:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WMYH7Fj+GOJ; Sun, 27 Mar 2011 08:13:50 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5797C3A6868; Sun, 27 Mar 2011 08:13:50 -0700 (PDT) Received: by eye13 with SMTP id 13so1044326eye.31 for ; Sun, 27 Mar 2011 08:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9z/wuR7qkmkwfrggqaywkG9U9hd1Ioj7/2K9urTRSHA=; b=wv5cG4YtB3PemGAgauDX3Ts5MuNGKfyPwKK5oqCWlAQgN/8G/fMM00aZyECjQGIzLR r/4sGD2GhB+gjn0rJmXYJtHj2qab55q5IWlUdN1XjkHspLygZECn45AlVtZ36Cab/8q/ GWC+CSEjc4UQDfDmZiGA2SD4l+lnYTjDhFDsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IZ5ulS/QALZouewNDH6Sj3ijWYFTIQW+4vdBnJEayH2KsaEl+k0ILsLvUEp7Q9j5af NWzYxNSukS+GoHMIE2yxw4TyaL+t5d2shTROtu5pCBRVrqHTw4QT7i4FFo+9qmL4qchP QqFs3k0F1BFDqe9JIqT2emiavKZAx9NXsJy7o= MIME-Version: 1.0 Received: by 10.213.104.103 with SMTP id n39mr1298333ebo.144.1301238924068; Sun, 27 Mar 2011 08:15:24 -0700 (PDT) Received: by 10.213.104.141 with HTTP; Sun, 27 Mar 2011 08:15:24 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> Date: Sun, 27 Mar 2011 08:15:24 -0700 Message-ID: From: Cameron Byrne To: teemu.savolainen@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org, ipv6@ietf.org Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 15:13:51 -0000 On Sun, Mar 27, 2011 at 6:20 AM, wrote: > Hi, > > > > I discussed shortly with Arifumi about RFC3484 default policy table updat= es > and NAT64 WKP, i.e. whether the default policy table should take a stand = on > 64:ff9b::/96 preference. > > > > It seemed to us that default policy table does not necessarily have to, a= s > it could be ok to handle addresses with WKP similarly to global IPv6 > addresses. Furthermore, the default policy table anyway cannot cover > Network-Specific Prefixes. > > > > Hence prefixes used for protocol translation would be handled like global > IPv6 addresses unless something different is configured via policy > distribution mechanism? And this should perhaps be documented into the > RFC3484-revised. > I agree that prefixes used for protocol translation should be treated as normal IPv6. I do not believe the policy table needs to be updated .... seems like the policy table has been the target of trying to fix various things (or the table was implemented wrong ...), but relying on that static host level logic is very difficult in the real world to solve dynamic problems. Cameron > > > Best regards, > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Teemu > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From mohamed.boucadair@orange-ftgroup.com Sun Mar 27 09:17:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D273A683B for ; Sun, 27 Mar 2011 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 BtO+dJi7QvYD for ; Sun, 27 Mar 2011 09:17:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 467853A67D8 for ; Sun, 27 Mar 2011 09:17:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1C51418C18C; Sun, 27 Mar 2011 18:19:07 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 024774C024; Sun, 27 Mar 2011 18:19:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Sun, 27 Mar 2011 18:19:06 +0200 From: To: Shin Miyakawa Date: Sun, 27 Mar 2011 18:19:05 +0200 Thread-Topic: [BEHAVE] CGN REQ: Planned maintenance operations Thread-Index: AcvshShN54VvSXICQBaRU9m4f3vt0wAFMvrg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4EF0F912@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4DBA412E@PUEXCB1B.nanterre.francetelecom.fr> <4D8D34CF.4030509@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C4EF0F909@PUEXCB1B.nanterre.francetelecom.fr> <20110327.224450.71161718.miyakawa@nttv6.jp> In-Reply-To: <20110327.224450.71161718.miyakawa@nttv6.jp> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.27.150316 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 16:17:32 -0000 Dear Shin, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Shin Miyakawa [mailto:miyakawa@nttv6.jp]=20 Envoy=E9 : dimanche 27 mars 2011 15:45 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : simon.perreault@viagenie.ca; behave@ietf.org; miyakawa@nttv6.jp Objet : Re: [BEHAVE] CGN REQ: Planned maintenance operations Mohamed, Thank you for your comment of our draft, as one of th eoriginal author of this draft, I'd like to respond to this... Then.... From: Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations Date: Sun, 27 Mar 2011 13:51:04 +0200 > Because of the stateful nature of the CGN, service availably is a MUST. C= GN MUST be able to gracefully handover/etc. This depends on operators' choise.=20 I have talked many operators on the earth who consider about CGN deployment= . There are certain amount of operators who do not think they need=20 high-availability of CGN.=20 So we can not use MUST. It is too strong as a standard document. Of course, I agree with SHOULD. > If you take for instance BGP, there is a procedure how graceful restart i= s defined. For CGN, we need a specific procedure. Also the graceful restart mechanism of CGN is quite implentation depended. I do not think that we can define a general procedure between two CGNs which comes from different vendors. Med: Putting aside the solution discussion and multi-vendor scenario, do yo= u agree/disagree this is a valid requirement?=20 From Teemu.Kiviniemi@csc.fi Sun Mar 27 12:51:40 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3582B3A6926; Sun, 27 Mar 2011 12:51:40 -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 48h+f4fo80dI; Sun, 27 Mar 2011 12:51:38 -0700 (PDT) Received: from smtp3.csc.fi (smtp3.csc.fi [193.166.7.53]) by core3.amsl.com (Postfix) with ESMTP id 249DA3A691B; Sun, 27 Mar 2011 12:51:37 -0700 (PDT) Received: from kusti.csc.fi (kusti.csc.fi [193.166.0.100]) by smtp3.csc.fi (8.14.3/8.14.3/CSC) with ESMTP id p2RJrDvI030512; Sun, 27 Mar 2011 22:53:13 +0300 Received: from sampo3.csc.fi (193.166.1.170) by kusti.csc.fi (192.168.120.3) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 27 Mar 2011 22:54:00 +0300 Date: Sun, 27 Mar 2011 22:53:13 +0300 From: Teemu Kiviniemi To: "teemu.savolainen@nokia.com" In-Reply-To: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> Message-ID: References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-CanIt-Geo: ip=193.166.0.100; country=FI; latitude=64.0000; longitude=26.0000; http://maps.google.com/maps?q=64.0000,26.0000&z=6 X-CanItPRO-Stream: 00_Opt_Out (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 193.166.7.53 Cc: "behave@ietf.org" , "ipv6@ietf.org" Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 19:51:40 -0000 On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: > I discussed shortly with Arifumi about RFC3484 default policy table > updates and NAT64 WKP, i.e. whether the default policy table should take > a stand on 64:ff9b::/96 preference. > > It seemed to us that default policy table does not necessarily have to, > as it could be ok to handle addresses with WKP similarly to global IPv6 > addresses. Furthermore, the default policy table anyway cannot cover > Network-Specific Prefixes. > > Hence prefixes used for protocol translation would be handled like > global IPv6 addresses unless something different is configured via > policy distribution mechanism? And this should perhaps be documented > into the RFC3484-revised. I believe native IPv4 should always be preferred over NAT64. Even if native IPv4 was using NAT, it is likely to work better with current applications than NAT64. Preferring IPv4 over the NAT64 well-known prefix does not fix the problem for network-specific NAT64 prefixes. However, I see no reasons why the NAT64 WKP should not be given a lower preference than IPv4 by default. -- Teemu From miyakawa@nttv6.jp Sun Mar 27 12:52:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6173A691B for ; Sun, 27 Mar 2011 12:52:45 -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 B98uo5HPEIsb for ; Sun, 27 Mar 2011 12:52:44 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by core3.amsl.com (Postfix) with ESMTP id 61B8A3A691A for ; Sun, 27 Mar 2011 12:52:44 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 064A8BDC5B; Mon, 28 Mar 2011 04:54:20 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id DDCE7704F3; Mon, 28 Mar 2011 04:54:19 +0900 (JST) Date: Mon, 28 Mar 2011 04:54:19 +0900 (JST) Message-Id: <20110328.045419.193764124.miyakawa@nttv6.jp> To: mohamed.boucadair@orange-ftgroup.com From: Shin Miyakawa In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4EF0F912@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33C4EF0F909@PUEXCB1B.nanterre.francetelecom.fr> <20110327.224450.71161718.miyakawa@nttv6.jp> <94C682931C08B048B7A8645303FDC9F33C4EF0F912@PUEXCB1B.nanterre.francetelecom.fr> Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 19:52:45 -0000 From: Subject: Re: [BEHAVE] CGN REQ: Planned maintenance operations Date: Sun, 27 Mar 2011 18:19:05 +0200 > Med: Putting aside the solution discussion and multi-vendor scenario, do you agree/disagree this is a valid requirement? OK. To make it clear, I disagree with that, at least as you proposed. Cheers, Shin From cb.list6@gmail.com Sun Mar 27 14:15:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE3E3A6950; Sun, 27 Mar 2011 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxi1tgTRkTY5; Sun, 27 Mar 2011 14:15:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id CEEA43A6955; Sun, 27 Mar 2011 14:15:34 -0700 (PDT) Received: by eye13 with SMTP id 13so1106434eye.31 for ; Sun, 27 Mar 2011 14:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+g7/FZNB3bMFTbhfiT09vzmK6bSQuMKo5GaRF8/kuYI=; b=uir+9+pZPfw/k+ODENgAWife4Opqi4V2u3wvJ8EqqFxgSTMcd17qHLwc6N74J9yuYH bNTwSJN0vqEhURQM+5NBxHN4oyhTc92WgKltWcspFYwHtVcslE7t7Va7g4Ueu55H1iIr UnPx4yesQqNJigandQIYrJUJi/dfB+8+65InI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xeZxERPDKif76xfmSb7NrfeM+D28CBalXyH+WT/hXpX6rqLqFPerLUEad0o9Y0dQEC IJh9uJqBwkSP8JZ0VB6SpfL1lgzAXqI2dmjK0ZvAHQZcABcdn251RJWqFSOqo/vOgatc jF4aZlYVBhatBCQHFTc/0YWebQO8fjRA0usNE= MIME-Version: 1.0 Received: by 10.213.25.212 with SMTP id a20mr1365590ebc.106.1301260630983; Sun, 27 Mar 2011 14:17:10 -0700 (PDT) Received: by 10.213.104.141 with HTTP; Sun, 27 Mar 2011 14:17:10 -0700 (PDT) In-Reply-To: References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> Date: Sun, 27 Mar 2011 14:17:10 -0700 Message-ID: From: Cameron Byrne To: Teemu Kiviniemi Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 21:15:36 -0000 On Sun, Mar 27, 2011 at 12:53 PM, Teemu Kiviniemi wrote: > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: > >> I discussed shortly with Arifumi about RFC3484 default policy table >> updates and NAT64 WKP, i.e. whether the default policy table should take a >> stand on 64:ff9b::/96 preference. >> >> It seemed to us that default policy table does not necessarily have to, as >> it could be ok to handle addresses with WKP similarly to global IPv6 >> addresses. Furthermore, the default policy table anyway cannot cover >> Network-Specific Prefixes. >> >> Hence prefixes used for protocol translation would be handled like global >> IPv6 addresses unless something different is configured via policy >> distribution mechanism? And this should perhaps be documented into the >> RFC3484-revised. > > I believe native IPv4 should always be preferred over NAT64. Even if native > IPv4 was using NAT, it is likely to work better with current applications > than NAT64. > I strongly disagree. Let's not keep changing things, and please leave well enough alone. We can't keep changing the rules of the game, we just end up with inconsistent implementations that cannot be changed easily once deployed. What data do you have to show that NAT44 experience is better than NAT64? As someone who has deployed and operated NAT44 at very large scale and NAT64 (small scale, for over a year, but the largest i know of) there is not a service difference that i am aware of between NAT64 and NAT44. I see this, like happy eyeballs, as a threat to growing IPv6 traffic volumes. If we cannot grow traffic volumes on IPv6, the relevant planning people (google's now famous graph ... and others) will not put resources to growing IPv6. IPv6 remains a second class half-way implemented / RFP checkbox protocol that is not fit for production.... and over time looses the ground it has gained like ... Symbian^3 now not working with IPv6. T-Mobile USA just launched the Nokia C7, and it less IPv6 functionality than last year's Nokia phones ... Network planners see the CGN NAT44 growing, so they put time and money on that ... Yet CGN NAT44 is a dead end. CGN NAT64 is not a dead end, it gets the protocol right and ENABLES one end of the connection to have the opportunity to have native IPv6 and that pressures the other end to support IPv6 to avoid CGN issues.... What you are suggesting just ensures the status quo while injecting additional entropy across the install base. With IPv6 preferred and going via NAT64, network planners and application folks can see the latent IPv6 opportunity that would be available if both ends of the connection were IPv6. > Preferring IPv4 over the NAT64 well-known prefix does not fix the problem Please make your cogent case for that there is a problem first. > for network-specific NAT64 prefixes. However, I see no reasons why the NAT64 > WKP should not be given a lower preference than IPv4 by default. > No reason to not do it != reason to do it. Let's not keep changing the rules of the game. Cameron > -- > Teemu > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From marc.blanchet@viagenie.ca Sun Mar 27 14:33:12 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566753A6957 for ; Sun, 27 Mar 2011 14:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 T3hXtQxui6Ee for ; Sun, 27 Mar 2011 14:32:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4051A3A6969 for ; Sun, 27 Mar 2011 14:32:43 -0700 (PDT) Received: from dhcp-43d4.meeting.ietf.org (dhcp-43d4.meeting.ietf.org [130.129.67.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0FA1E21F49 for ; Sun, 27 Mar 2011 17:34:18 -0400 (EDT) Message-ID: <4D8FAD59.5080307@viagenie.ca> Date: Sun, 27 Mar 2011 23:34:17 +0200 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: behave@ietf.org References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 21:33:12 -0000 Le 11-03-27 21:53, Teemu Kiviniemi a crit : > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: > >> I discussed shortly with Arifumi about RFC3484 default policy table >> updates and NAT64 WKP, i.e. whether the default policy table should >> take a stand on 64:ff9b::/96 preference. >> >> It seemed to us that default policy table does not necessarily have >> to, as it could be ok to handle addresses with WKP similarly to global >> IPv6 addresses. Furthermore, the default policy table anyway cannot >> cover Network-Specific Prefixes. >> >> Hence prefixes used for protocol translation would be handled like >> global IPv6 addresses unless something different is configured via >> policy distribution mechanism? And this should perhaps be documented >> into the RFC3484-revised. > > I believe native IPv4 should always be preferred over NAT64. I disagree. The reason why people are deploying NAT64 is to move to IPv6 networks, which is the end goal. The pain of NAT64 is only in compensation of having an IPv6 network. Therefore, pref Ipv4 over NAT64 will not help. > Even if > native IPv4 was using NAT, it is likely to work better with current > applications than NAT64. our experience is that dual-stack applications work pretty well in NAT64 networks. Marc. > > Preferring IPv4 over the NAT64 well-known prefix does not fix the > problem for network-specific NAT64 prefixes. However, I see no reasons > why the NAT64 WKP should not be given a lower preference than IPv4 by > default. > -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From ajs@shinkuro.com Sun Mar 27 16:00:42 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA2528C184 for ; Sun, 27 Mar 2011 16:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 QaHGh1qCBwN5 for ; Sun, 27 Mar 2011 16:00:41 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BA38028C180 for ; Sun, 27 Mar 2011 16:00:41 -0700 (PDT) Received: from shinkuro.com (dhcp-6383.meeting.ietf.org [130.129.99.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 05CC71ECB41D for ; Sun, 27 Mar 2011 23:02:17 +0000 (UTC) Date: Sun, 27 Mar 2011 19:02:16 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110327230215.GB95614@crankycanuck.ca> References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 23:00:42 -0000 On Sun, Mar 27, 2011 at 02:17:10PM -0700, Cameron Byrne wrote: > Let's not keep changing things, and please leave well enough alone. > We can't keep changing the rules of the game, we just end up with > inconsistent implementations that cannot be changed easily once > deployed. + ten billion, four hundred and one. I have made this argument before, but now I will make it in a cranky way. If you have native v4, _don't do_ NAT64. I see no reason why that's supposed to be hard. (Please don't give me some contrived example where someone has a bad network experience. Yes, of course. NAT sucks. That's why we mostly think you should avoid it where possible.) Anyway, I'll bet a pretty good lunch you don't have "native v4", or that if you do you are no way no how going to put a NAT64 on it unless you're some ancient IBM OS/360 that needs to keep hobbling along for some reason (in which case, of course, you're already way down in the noise of people for whom we don't need to provide any defaults of any kind, because you're on your own.) If you have real, true native v4, you can do dual stack and you don't have any pain at all. (Well, except for the mif ones. But that's Someone Else's bad dream.) We have to get past the idea that NAT64 can be tweaked until it's good. It needs to be good enough _and no more_. It's not spinach. Your mom doesn't want you to eat it. It isn't going to be tasty and good for you too. It's a nasty hack that will mostly work most of the time for most people. That's all we wanted. I'd be ashamed of my tiny contribution to this stuff if it weren't a necessary evil that will get some people past a hump -- but that's all it's for. It's not a lily, and it wouldn't need gilding even if it were. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From brian.e.carpenter@gmail.com Sun Mar 27 22:53:33 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1CE3A6814; Sun, 27 Mar 2011 22:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kOv2ki7Im5Et; Sun, 27 Mar 2011 22:53:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 6E32C3A6813; Sun, 27 Mar 2011 22:53:32 -0700 (PDT) Received: by gxk19 with SMTP id 19so1205979gxk.31 for ; Sun, 27 Mar 2011 22:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jYtL6IVUJZaQX84Xta0ttpY+UzIWhH5JFrShYjyCMn0=; b=LRiRp1raVwbc4WZapVk5218YN+V2lF/1a68VfgeVUHVAneO7iDaeLhcZae5KW09Llv 6e/vQa2Wa7zIXKZFOC9wi/XdynZGmrcqIcvGWszlYC9qeFE91iGyVqJxOtXquISTvNIN mjsUnn9njjxnjs/zO/qx7fPefBDpvdAmolGH0= 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=wt/PMvcFbAxhaQFLMu40rroouwQdLfQBfnlTCRht+yf95dXUPpzxrqh34YiDCJ0a6j tMKzb8h4gVwNkbugxOSOQY6ZRqhcDBegtCkwICG3jKudxZc6MLv2F2dytiXGE2ZKoW7f 5pWg3g3biJ7D6fJ4z0iV3NstYX6/5rY9+P7qI= Received: by 10.150.31.16 with SMTP id e16mr3683633ybe.227.1301291709299; Sun, 27 Mar 2011 22:55:09 -0700 (PDT) Received: from [130.129.71.154] (dhcp-479a.meeting.ietf.org [130.129.71.154]) by mx.google.com with ESMTPS id b4sm48878ybn.8.2011.03.27.22.55.06 (version=SSLv3 cipher=OTHER); Sun, 27 Mar 2011 22:55:08 -0700 (PDT) Message-ID: <4D9022B6.8020105@gmail.com> Date: Mon, 28 Mar 2011 18:55:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teemu Kiviniemi References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 05:53:33 -0000 On 2011-03-28 08:53, Teemu Kiviniemi wrote: > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: ... > I believe native IPv4 should always be preferred over NAT64. That is just irrelevant and of no importance, since the only hosts that use DNS64 and NAT64 in normal life are IPv6-only hosts. There is a side issue of what happens if a synthetic IPv6 address is referred to a non-IPv6-only host, but that is a whole other problem that cannot be solved at the RFC3484bis level. See draft-carpenter-referral-ps-02.txt... Brian From teemu.savolainen@nokia.com Mon Mar 28 00:18:03 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1167A3A6876; Mon, 28 Mar 2011 00:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 Wd60IUNReIvK; Mon, 28 Mar 2011 00:18:02 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 866BD3A68B0; Mon, 28 Mar 2011 00:17:46 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2S7JJkR008207; Mon, 28 Mar 2011 10:19:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 10:19:08 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 28 Mar 2011 09:19:00 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 09:19:00 +0200 From: To: , Thread-Topic: RFC3484-revise and NAT64 Well-Known Prefix Thread-Index: AcvsgcCRXbnjiKSUSuKTwnQkrPt+HwAivlGZAALORlA= Date: Mon, 28 Mar 2011 07:19:00 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962015109@008-AM1MPN1-036.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <4D9022B6.8020105@gmail.com> In-Reply-To: <4D9022B6.8020105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.99.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2011 07:19:08.0803 (UTC) FILETIME=[6DD78530:01CBED18] X-Nokia-AV: Clean Cc: ipv6@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 07:18:03 -0000 TXVsdGktaW50ZXJmYWNlZCBob3N0IG1pZ2h0IGhhdmUgb25lIG5ldHdvcmsgaW50ZXJmYWNlIElQ djYtb25seSB3aXRoIE5BVDY0IChlLmcuIGNlbGx1bGFyKSBhbmQgYW5vdGhlciBuZXR3b3JrIGlu dGVyZmFjZSBJUHY0LW9ubHkgKGUuZy4gV0xBTikuDQoNClRlZW11DQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZXh0IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiAyOC4gbWFhbGlza3V1dGEgMjAxMSAw Nzo1NQ0KPiBUbzogVGVlbXUgS2l2aW5pZW1pDQo+IENjOiBTYXZvbGFpbmVuIFRlZW11IChOb2tp YS1NUy9UYW1wZXJlKTsgYmVoYXZlQGlldGYub3JnOyBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBSRkMzNDg0LXJldmlzZSBhbmQgTkFUNjQgV2VsbC1Lbm93biBQcmVmaXgNCj4gDQo+IE9u IDIwMTEtMDMtMjggMDg6NTMsIFRlZW11IEtpdmluaWVtaSB3cm90ZToNCj4gPiBPbiBTdW4sIDI3 IE1hciAyMDExLCB0ZWVtdS5zYXZvbGFpbmVuQG5va2lhLmNvbSB3cm90ZToNCj4gLi4uDQo+ID4g SSBiZWxpZXZlIG5hdGl2ZSBJUHY0IHNob3VsZCBhbHdheXMgYmUgcHJlZmVycmVkIG92ZXIgTkFU NjQuDQo+IA0KPiBUaGF0IGlzIGp1c3QgaXJyZWxldmFudCBhbmQgb2Ygbm8gaW1wb3J0YW5jZSwg c2luY2UgdGhlIG9ubHkgaG9zdHMNCj4gdGhhdCB1c2UgRE5TNjQgYW5kIE5BVDY0IGluIG5vcm1h bCBsaWZlIGFyZSBJUHY2LW9ubHkgaG9zdHMuDQo+IA0KPiBUaGVyZSBpcyBhIHNpZGUgaXNzdWUg b2Ygd2hhdCBoYXBwZW5zIGlmIGEgc3ludGhldGljIElQdjYgYWRkcmVzcw0KPiBpcyByZWZlcnJl ZCB0byBhIG5vbi1JUHY2LW9ubHkgaG9zdCwgYnV0IHRoYXQgaXMgYSB3aG9sZSBvdGhlcg0KPiBw cm9ibGVtIHRoYXQgY2Fubm90IGJlIHNvbHZlZCBhdCB0aGUgUkZDMzQ4NGJpcyBsZXZlbC4NCj4g DQo+IFNlZSBkcmFmdC1jYXJwZW50ZXItcmVmZXJyYWwtcHMtMDIudHh0Li4uDQo+IA0KPiAgICAg QnJpYW4NCg== From brian.e.carpenter@gmail.com Mon Mar 28 00:52:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16783A68EB; Mon, 28 Mar 2011 00:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 gFCd46-MXQIo; Mon, 28 Mar 2011 00:52:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id F1FBF3A68EE; Mon, 28 Mar 2011 00:51:59 -0700 (PDT) Received: by yxk30 with SMTP id 30so1248319yxk.31 for ; Mon, 28 Mar 2011 00:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UEPuUjYgd1+SCkGJ6XcHyOZRAwpBsukauLzK65mbflM=; b=lsVedPprAEsTEzAml1v/nZhw2Ze/s3zAMSHParILLwOPZdQtLLxS90hcx63DF76dA9 HaX08NRQkOT3t2vGJ1oNKlv76mRCia37Mu42fuqG9nmNBHP6cJQrhcn8HxH2zJtloWdO XTMFTAZIZC3JyFsg3jwyo2GeSxQwopEJpph1E= 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=q2dEXeRfqV8lHv/4mskDLoKqlL6BjNEpiVFNErEw2ED9ZbKPd6bf98OrxhsMtXF/3k sgqCKyWx20C2oE1xhJfVUVoKZ3RfWTAx/eiX6uudYEayUPQp1Diqwk2GLmRPhyX/RLlW ZwoDy+asOqJEAVceaIYIpDcm89l3GS51YVzN4= Received: by 10.236.197.7 with SMTP id s7mr1099535yhn.188.1301298817069; Mon, 28 Mar 2011 00:53:37 -0700 (PDT) Received: from [130.129.22.150] (dhcp-1696.meeting.ietf.org [130.129.22.150]) by mx.google.com with ESMTPS id x76sm1823631yhn.94.2011.03.28.00.53.00 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 00:53:06 -0700 (PDT) Message-ID: <4D903E55.1010807@gmail.com> Date: Mon, 28 Mar 2011 20:52:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <4D9022B6.8020105@gmail.com> <916CE6CF87173740BC8A2CE443096962015109@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962015109@008-AM1MPN1-036.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, tekivini@csc.fi, behave@ietf.org Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 07:52:01 -0000 Yes. The MIF model seems to me to be fairly broken from an architectural point of view. Maybe you have to forbid exporting certain information from one stack to another on a MIF host. Brian On 2011-03-28 20:19, teemu.savolainen@nokia.com wrote: > Multi-interfaced host might have one network interface IPv6-only with NAT64 (e.g. cellular) and another network interface IPv4-only (e.g. WLAN). > > Teemu > >> -----Original Message----- >> From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 28. maaliskuuta 2011 07:55 >> To: Teemu Kiviniemi >> Cc: Savolainen Teemu (Nokia-MS/Tampere); behave@ietf.org; ipv6@ietf.org >> Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix >> >> On 2011-03-28 08:53, Teemu Kiviniemi wrote: >>> On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: >> ... >>> I believe native IPv4 should always be preferred over NAT64. >> That is just irrelevant and of no importance, since the only hosts >> that use DNS64 and NAT64 in normal life are IPv6-only hosts. >> >> There is a side issue of what happens if a synthetic IPv6 address >> is referred to a non-IPv6-only host, but that is a whole other >> problem that cannot be solved at the RFC3484bis level. >> >> See draft-carpenter-referral-ps-02.txt... >> >> Brian From dwing@cisco.com Mon Mar 28 05:46:58 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475203A6A61; Mon, 28 Mar 2011 05:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.488 X-Spam-Level: X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 uPJyJEybA4YE; Mon, 28 Mar 2011 05:46:57 -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 0D72A3A6A56; Mon, 28 Mar 2011 05:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2635; q=dns/txt; s=iport; t=1301316514; x=1302526114; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=v7nyfG2aYOT9HpbHi7Bs9lhzL88CRzBZZnCo8LoxTi4=; b=GJGoFuWI8INcP3sk/GbalAcqsq6zlG39ZGD0ezfI5ZjErdBi+n7R33ex 9zK01ektzPn+C/kA4Bvb730Fzuz+esjBSmtHMtWHlczAH7RLi//PM841X P1el7mPwaMDFprkCA+zRQQvv/XGxihHT3WX1oHYcAUzPHXQmTGe1xTcTk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAKCCkE2rRDoJ/2dsb2JhbACYAYFki1t3pw+bZIVpBA X-IronPort-AV: E=Sophos;i="4.63,255,1299456000"; d="scan'208";a="284021027" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2011 12:48:21 +0000 Received: from dwingWS (sjc-vpn6-310.cisco.com [10.21.121.54]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2SCmJ44023036; Mon, 28 Mar 2011 12:48:20 GMT From: "Dan Wing" To: "'Teemu Kiviniemi'" , References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> In-Reply-To: Date: Mon, 28 Mar 2011 14:48:18 +0200 Message-ID: <040201cbed46$6b4c5790$41e506b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvsuKZl117vMpmdSv2qMkR5SwORbAAjTprw Content-Language: en-us Cc: ipv6@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 12:46:58 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Teemu Kiviniemi > Sent: Sunday, March 27, 2011 9:53 PM > To: teemu.savolainen@nokia.com > Cc: behave@ietf.org; ipv6@ietf.org > Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix > > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: > > > I discussed shortly with Arifumi about RFC3484 default policy table > > updates and NAT64 WKP, i.e. whether the default policy table should > take > > a stand on 64:ff9b::/96 preference. > > > > It seemed to us that default policy table does not necessarily have > to, > > as it could be ok to handle addresses with WKP similarly to global > IPv6 > > addresses. Furthermore, the default policy table anyway cannot cover > > Network-Specific Prefixes. > > > > Hence prefixes used for protocol translation would be handled like > > global IPv6 addresses unless something different is configured via > > policy distribution mechanism? And this should perhaps be documented > > into the RFC3484-revised. > > I believe native IPv4 should always be preferred over NAT64. Even if > native IPv4 was using NAT, it is likely to work better with current > applications than NAT64. > > Preferring IPv4 over the NAT64 well-known prefix does not fix the > problem > for network-specific NAT64 prefixes. However, I see no reasons why the > NAT64 WKP should not be given a lower preference than IPv4 by default. One reason is that it changes behavior for a network using the well-known NAT64 prefix versus using their own network's NAT64 prefix. Not to mention they won't know if/when their IPv6 devices are using the new RFC3484 default table, and will thus start shifting their preference away from IPv6 (and a NAT64) and towards IPv4 (and a NAPT44, because let's be real, everyone will have a NAPT44 if we're talking about an RFC3484 change). Personally, I don't see any benefit to changing RFC3484 table to accomodate NAT64, assuming there is a way for the host to learn its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis). Assuming there is no standard way to learn the prefix by the time we would want to standardize rfc3484bis, I see harm in adding the NAT64 well known prefix 64:ff9b::/96 to the default policy table. -d > -- > Teemu > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dthaler@microsoft.com Tue Mar 29 01:57:41 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D8A3A68EC for ; Tue, 29 Mar 2011 01:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 Wnzp-o5w4Vqe for ; Tue, 29 Mar 2011 01:57:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5C17D3A687E for ; Tue, 29 Mar 2011 01:57:40 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Mar 2011 01:59:18 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 29 Mar 2011 01:59:18 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.127]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Tue, 29 Mar 2011 01:59:17 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Volunteers for note taker / jabber scribe? Thread-Index: Acvt725mFEUpU3OBRtW3CpO7zUsUQw== Date: Tue, 29 Mar 2011 08:59:16 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B007C38@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Volunteers for note taker / jabber scribe? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 08:57:41 -0000 We are in need of a note taker or (preferably) two, and a jabber scribe. Please volunteer! Thanks, -Dave From dwing@cisco.com Tue Mar 29 02:09:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDB03A692D; Tue, 29 Mar 2011 02:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 LBX5PrRfWBJP; Tue, 29 Mar 2011 02:09:23 -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 685C73A67B7; Tue, 29 Mar 2011 02:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2971; q=dns/txt; s=iport; t=1301389850; x=1302599450; h=reply-to:from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=zCdA3Epcc9uj+3IxYlK3N4aeoNNUG/dA+4FBpjMkhgw=; b=Qg8dQDpOVj8F29sX1d4eUtY5wgU0tgLgOFFKdFZQrKsL2zaImxfiK5n4 g3JJNOr3qPMLzp7WQfjULz7ZOTu3JMw2f/21Jt4UPNLioYXeqWfJCzOsV 6OOZ/7YNc8ZCxjBIJwALO/pMnGOSDpTRSFLVvN6VFfFELl8OcdY5TY4yy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHWhkU2rRDoJ/2dsb2JhbACZcotTd6dPnEWFagQ X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="672318685" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 29 Mar 2011 09:10:50 +0000 Received: from dwingWS (sjc-vpn6-1034.cisco.com [10.21.124.10]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2T9AmCu016470; Tue, 29 Mar 2011 09:10:49 GMT From: "Dan Wing" To: , Date: Tue, 29 Mar 2011 11:10:47 +0200 Message-ID: <041d01cbedf1$329be590$97d3b0b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvt8TD+IT7X5LVtQb+G1iyxHGHDLA== Content-Language: en-us Cc: 'David Harrington' , draft-ietf-behave-dns64@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] auth48 changes to draft-ietf-behave-dns64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:09:24 -0000 During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that two sections were not consistent. The text in Section 5.1.1 is clear: If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not complying with this recommendation). By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist That is, SHOULD NOT in the general case, and MUST NOT as a default case. This represents WG consensus. But then 5.1.4 says something slightly different: If it receives an answer with at least one AAAA record containing an address outside any of the excluded range(s), then it MAY build an answer section for a response including only the AAAA record(s) that do not contain any of the addresses inside the excluded ranges. That answer section is used in the assembly of a response as detailed in Section 5.4. Alternatively, it MAY treat the answer as though it were an empty answer, and proceed accordingly. It MUST NOT return the offending AAAA records as part of a response. It seems rather self-defeating to have excluded ranges and then ignore those. Then the only issue is: if there are both an excluded AAAA record and a non-excluded one, the above says you can either return the good one, or not return any AAAA records. The proposal is to change the "MAY build an answer section" in 5.1.4 to "by default MUST build an answer section", so it would read as follows. The critical changes are highlighted with "^": When the DNS64 performs its initial AAAA query, if it receives an answer with only AAAA records containing addresses in the excluded range(s), then it MUST treat the answer as though it were an empty .....................^^^^ answer, and proceed accordingly. If it receives an answer with at least one AAAA record containing an address outside any of the excluded range(s), then it by default SHOULD build an answer section .................................^^^^^^^^^^^^^^ for a response including only the AAAA record(s) that do not contain any of the addresses inside the excluded ranges. That answer section is used in the assembly of a response as detailed in Section 5.4. Alternatively, it MAY treat the answer as though it were an empty answer, and proceed accordingly. It MUST NOT return the offending AAAA records as part of a response. We believe this is in line with the WG consensus in section 5.1.1. The updated files are here: http://www.rfc-editor.org/authors/rfc6147.txt http://www.rfc-editor.org/authors/rfc6147.xml http://www.rfc-editor.org/authors/rfc6147-diff.html We are soliciting feedback for this change until noon (Prague time) on Friday, April 1. Please send feedback to behave@ietf.org. -d From suresh.krishnan@ericsson.com Tue Mar 29 03:45:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63813A6952; Tue, 29 Mar 2011 03:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.906 X-Spam-Level: X-Spam-Status: No, score=-104.906 tagged_above=-999 required=5 tests=[AWL=1.693, 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 pE9wlVwmrE9S; Tue, 29 Mar 2011 03:45:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id CDC343A68D4; Tue, 29 Mar 2011 03:45:48 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2TAlMES029914; Tue, 29 Mar 2011 05:47:23 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 29 Mar 2011 06:47:16 -0400 From: Suresh Krishnan To: Dan Wing , "'Teemu Kiviniemi'" , "teemu.savolainen@nokia.com" Date: Tue, 29 Mar 2011 06:47:15 -0400 Thread-Topic: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix Thread-Index: AcvsuKZl117vMpmdSv2qMkR5SwORbAAjTprwAC3irhA= Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se> References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <040201cbed46$6b4c5790$41e506b0$@com> In-Reply-To: <040201cbed46$6b4c5790$41e506b0$@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 Cc: "behave@ietf.org" , "ipv6@ietf.org" Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 10:45:49 -0000 Hi Dan/Teemu(s)/Cameron, I am afraid there is no single right answer here. There will be networks = that will prefer NAT44 over NAT64 and those that prefer NAT64 over NAT44. F= or this reason, I think this is better left as a site-specific policy decis= ion for distribution using a mechanism such as draft-ietf-6man-addr-select-= opt. So, I agree with Dan and Cameron that we should not add an entry to th= e default table for the NAT64 prefix. Cheers Suresh=20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > Sent: Monday, March 28, 2011 2:48 PM > To: 'Teemu Kiviniemi'; teemu.savolainen@nokia.com > Cc: ipv6@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]=20 > On Behalf=20 > > Of Teemu Kiviniemi > > Sent: Sunday, March 27, 2011 9:53 PM > > To: teemu.savolainen@nokia.com > > Cc: behave@ietf.org; ipv6@ietf.org > > Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix > >=20 > > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: > >=20 > > > I discussed shortly with Arifumi about RFC3484 default=20 > policy table=20 > > > updates and NAT64 WKP, i.e. whether the default policy=20 > table should > > take > > > a stand on 64:ff9b::/96 preference. > > > > > > It seemed to us that default policy table does not=20 > necessarily have > > to, > > > as it could be ok to handle addresses with WKP similarly to global > > IPv6 > > > addresses. Furthermore, the default policy table anyway=20 > cannot cover=20 > > > Network-Specific Prefixes. > > > > > > Hence prefixes used for protocol translation would be=20 > handled like=20 > > > global IPv6 addresses unless something different is=20 > configured via=20 > > > policy distribution mechanism? And this should perhaps be=20 > documented=20 > > > into the RFC3484-revised. > >=20 > > I believe native IPv4 should always be preferred over=20 > NAT64. Even if=20 > > native IPv4 was using NAT, it is likely to work better with current=20 > > applications than NAT64. > >=20 > > Preferring IPv4 over the NAT64 well-known prefix does not fix the=20 > > problem for network-specific NAT64 prefixes. However, I see=20 > no reasons=20 > > why the > > NAT64 WKP should not be given a lower preference than IPv4=20 > by default. >=20 > One reason is that it changes behavior for a network using=20 > the well-known > NAT64 prefix versus using their own network's NAT64 prefix. =20 > Not to mention they won't know if/when their IPv6 devices are=20 > using the new > RFC3484 default table, and will thus start shifting their=20 > preference away from IPv6 (and a NAT64) and towards IPv4 (and=20 > a NAPT44, because let's be real, everyone will have a NAPT44=20 > if we're talking about an > RFC3484 change). >=20 > Personally, I don't see any benefit to changing RFC3484 table=20 > to accomodate NAT64, assuming there is a way for the host to=20 > learn its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis). =20 > Assuming there is no standard way to learn the prefix by the=20 > time we would want to standardize rfc3484bis, I see harm in=20 > adding the NAT64 well known prefix 64:ff9b::/96 to the=20 > default policy table. >=20 > -d >=20 >=20 > > -- > > Teemu > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > = From denghui02@gmail.com Tue Mar 29 04:37:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2017E28C156; Tue, 29 Mar 2011 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 EWy5xDbsmWaE; Tue, 29 Mar 2011 04:37:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 399513A67CC; Tue, 29 Mar 2011 04:37:34 -0700 (PDT) Received: by iye19 with SMTP id 19so94243iye.31 for ; Tue, 29 Mar 2011 04:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qLRnAU/oRQeRQzLpnQWtqg91lgRR81Ua4+bXSXadW6g=; b=OEDyEvzIs40MQDvNpI2F+9B1fjPxn61owGBbmQZtX7StzDlALP7aOj8gENuJbkLe45 Q84UpDx7j3ywWTdJd5RjNRMbGtKzIWVc0aYxr9QM3X+M0DHl3n1tvIW9ZHmqvCvXYAKJ Be5zyuFfSWR+jZWfSrUEx0o8JfEOaZ/28Bs2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NFunJczumTEgZwCc/TD+PWwUXSseaCjcyFfKmUcpN8L9sBNDWWrF7Jg9m9i3sruBDz nknmJc8y+2wlzp/XKMCGSG7F9Rbg+6bUDWdxll4oRLzKXzejq8aU5SjdLr1aRKVPRhKi /qJvMe+1/xXsCc/nEiMfbunNQMmkjtncubDAY= MIME-Version: 1.0 Received: by 10.42.66.147 with SMTP id p19mr9120535ici.7.1301398752304; Tue, 29 Mar 2011 04:39:12 -0700 (PDT) Received: by 10.42.224.71 with HTTP; Tue, 29 Mar 2011 04:39:12 -0700 (PDT) In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se> References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <040201cbed46$6b4c5790$41e506b0$@com> <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 29 Mar 2011 13:39:12 +0200 Message-ID: From: Hui Deng To: Suresh Krishnan Content-Type: multipart/alternative; boundary=90e6ba614eec579df1049f9d8243 Cc: "ipv6@ietf.org" , Teemu Kiviniemi , "behave@ietf.org" , Dan Wing Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 11:37:36 -0000 --90e6ba614eec579df1049f9d8243 Content-Type: text/plain; charset=ISO-8859-1 make sense -Hui 2011/3/29 Suresh Krishnan > Hi Dan/Teemu(s)/Cameron, > I am afraid there is no single right answer here. There will be networks > that will prefer NAT44 over NAT64 and those that prefer NAT64 over NAT44. > For this reason, I think this is better left as a site-specific policy > decision for distribution using a mechanism such as > draft-ietf-6man-addr-select-opt. So, I agree with Dan and Cameron that we > should not add an entry to the default table for the NAT64 prefix. > > Cheers > Suresh > > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing > > Sent: Monday, March 28, 2011 2:48 PM > > To: 'Teemu Kiviniemi'; teemu.savolainen@nokia.com > > Cc: ipv6@ietf.org; behave@ietf.org > > Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix > > > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > > On Behalf > > > Of Teemu Kiviniemi > > > Sent: Sunday, March 27, 2011 9:53 PM > > > To: teemu.savolainen@nokia.com > > > Cc: behave@ietf.org; ipv6@ietf.org > > > Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix > > > > > > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: > > > > > > > I discussed shortly with Arifumi about RFC3484 default > > policy table > > > > updates and NAT64 WKP, i.e. whether the default policy > > table should > > > take > > > > a stand on 64:ff9b::/96 preference. > > > > > > > > It seemed to us that default policy table does not > > necessarily have > > > to, > > > > as it could be ok to handle addresses with WKP similarly to global > > > IPv6 > > > > addresses. Furthermore, the default policy table anyway > > cannot cover > > > > Network-Specific Prefixes. > > > > > > > > Hence prefixes used for protocol translation would be > > handled like > > > > global IPv6 addresses unless something different is > > configured via > > > > policy distribution mechanism? And this should perhaps be > > documented > > > > into the RFC3484-revised. > > > > > > I believe native IPv4 should always be preferred over > > NAT64. Even if > > > native IPv4 was using NAT, it is likely to work better with current > > > applications than NAT64. > > > > > > Preferring IPv4 over the NAT64 well-known prefix does not fix the > > > problem for network-specific NAT64 prefixes. However, I see > > no reasons > > > why the > > > NAT64 WKP should not be given a lower preference than IPv4 > > by default. > > > > One reason is that it changes behavior for a network using > > the well-known > > NAT64 prefix versus using their own network's NAT64 prefix. > > Not to mention they won't know if/when their IPv6 devices are > > using the new > > RFC3484 default table, and will thus start shifting their > > preference away from IPv6 (and a NAT64) and towards IPv4 (and > > a NAPT44, because let's be real, everyone will have a NAPT44 > > if we're talking about an > > RFC3484 change). > > > > Personally, I don't see any benefit to changing RFC3484 table > > to accomodate NAT64, assuming there is a way for the host to > > learn its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis). > > Assuming there is no standard way to learn the prefix by the > > time we would want to standardize rfc3484bis, I see harm in > > adding the NAT64 well known prefix 64:ff9b::/96 to the > > default policy table. > > > > -d > > > > > > > -- > > > Teemu > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > _______________________________________________ > > 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 > --90e6ba614eec579df1049f9d8243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
make sense
=A0
-Hui

2011/3/29 Suresh Krishnan <= suresh.krishnan@ericsson.co= m>
Hi Dan/Teemu(s)/Cameron,
=A0I= am afraid there is no single right answer here. There will be networks tha= t will prefer NAT44 over NAT64 and those that prefer NAT64 over NAT44. For = this reason, I think this is better left as a site-specific policy decision= for distribution using a mechanism such as draft-ietf-6man-addr-select-opt= . So, I agree with Dan and Cameron that we should not add an entry to the d= efault table for the NAT64 prefix.

Cheers
Suresh

> -----Original Message-----
> From: behave-bounces@ietf.org
> [ma= ilto:behave-bounces@ietf.org= ] On Behalf Of Dan Wing
> Sent: Monday, March 28, 2011 2:48 PM
> To: 'Teemu Kiviniemi&= #39;; teemu.savolainen@nokia.= com
> Cc: ipv6@ietf.org; behave@ietf.org
> Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix
&g= t;
> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]
> On Behalf
> > Of Teemu Kiviniemi
> > Sent: Sunday, M= arch 27, 2011 9:53 PM
> > To: teemu.savolainen@nokia.com
> > Cc: behave@ietf.org; ipv= 6@ietf.org
> > Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix
> &= gt;
> > On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote:
> >
> > &g= t; I discussed shortly with Arifumi about RFC3484 default
> policy table
> > > updates and NAT64 WKP, i.e. whether the= default policy
> table should
> > take
> > > a = stand on 64:ff9b::/96 preference.
> > >
> > > It se= emed to us that default policy table does not
> necessarily have
> > to,
> > > as it could be ok = to handle addresses with WKP similarly to global
> > IPv6
> = > > addresses. Furthermore, the default policy table anyway
> c= annot cover
> > > Network-Specific Prefixes.
> > >
> > &g= t; Hence prefixes used for protocol translation would be
> handled li= ke
> > > global IPv6 addresses unless something different is > configured via
> > > policy distribution mechanism? And th= is should perhaps be
> documented
> > > into the RFC3484-= revised.
> >
> > I believe native IPv4 should always be p= referred over
> NAT64. Even if
> > native IPv4 was using NAT, it is likely to= work better with current
> > applications than NAT64.
> >= ;
> > Preferring IPv4 over the NAT64 well-known prefix does not fi= x the
> > problem for network-specific NAT64 prefixes. However, I see
&g= t; no reasons
> > why the
> > NAT64 WKP should not be giv= en a lower preference than IPv4
> by default.
>
> One rea= son is that it changes behavior for a network using
> the well-known
> NAT64 prefix versus using their own network'= ;s NAT64 prefix.
> Not to mention they won't know if/when their I= Pv6 devices are
> using the new
> RFC3484 default table, and wi= ll thus start shifting their
> preference away from IPv6 (and a NAT64) and towards IPv4 (and
> = a NAPT44, because let's be real, everyone will have a NAPT44
> if= we're talking about an
> RFC3484 change).
>
> Person= ally, I don't see any benefit to changing RFC3484 table
> to accomodate NAT64, assuming there is a way for the host to
> l= earn its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis).
>= Assuming there is no standard way to learn the prefix by the
> time = we would want to standardize rfc3484bis, I see harm in
> adding the NAT64 well known prefix 64:ff9b::/96 to the
> default= policy table.
>
> -d
>
>
> > --
> &= gt; Teemu
> > ----------------------------------------------------= ----------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: <= a href=3D"https://www.ietf.org/mailman/listinfo/ipv6" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/ipv6
> > -----------------------------------------------------------------= ---
>
> _______________________________________________
>= 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

--90e6ba614eec579df1049f9d8243-- From jari.arkko@piuha.net Tue Mar 29 06:27:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8713A683A; Tue, 29 Mar 2011 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 MBrCiW-NtCUt; Tue, 29 Mar 2011 06:27:27 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4DA1D3A6824; Tue, 29 Mar 2011 06:27:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0B7462CC39; Tue, 29 Mar 2011 16:28:59 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxX7+Lgv6rTP; Tue, 29 Mar 2011 16:28:58 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D70A72CC2F; Tue, 29 Mar 2011 16:28:57 +0300 (EEST) Message-ID: <4D91DE99.20206@piuha.net> Date: Tue, 29 Mar 2011 15:28:57 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: behave@ietf.org References: <041d01cbedf1$329be590$97d3b0b0$@com> In-Reply-To: <041d01cbedf1$329be590$97d3b0b0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave-chairs@tools.ietf.org, 'David Harrington' , ietf@ietf.org, draft-ietf-behave-dns64@tools.ietf.org Subject: Re: [BEHAVE] auth48 changes to draft-ietf-behave-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, 29 Mar 2011 13:27:32 -0000 I'm OK with these changes. Jari Dan Wing kirjoitti: > During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that > two sections were not consistent. > > The text in Section 5.1.1 is clear: > > If there is (non-excluded) AAAA data available, DNS64 > SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A > for an analysis of the motivations for and the implications of not > complying with this recommendation). By default, DNS64 > implementations MUST NOT synthesize AAAA RRs when real AAAA RRs > exist > > That is, SHOULD NOT in the general case, and MUST NOT as a default case. > This represents WG consensus. > > > But then 5.1.4 says something slightly different: > > If it receives an answer with at > least one AAAA record containing an address outside any of the > excluded range(s), then it MAY build an answer section for a response > including only the AAAA record(s) that do not contain any of the > addresses inside the excluded ranges. That answer section is used in > the assembly of a response as detailed in Section 5.4. > Alternatively, it MAY treat the answer as though it were an empty > answer, and proceed accordingly. It MUST NOT return the offending > AAAA records as part of a response. > > It seems rather self-defeating to have excluded ranges and then > ignore those. Then the only issue is: if there are both an > excluded AAAA record and a non-excluded one, the above says you > can either return the good one, or not return any AAAA records. > > The proposal is to change the "MAY build an answer section" in 5.1.4 > to "by default MUST build an answer section", so it would read as > follows. The critical changes are highlighted with "^": > > When the DNS64 performs its initial AAAA query, if it receives an > answer with only AAAA records containing addresses in the excluded > range(s), then it MUST treat the answer as though it were an empty > .....................^^^^ > answer, and proceed accordingly. If it receives an answer with at > least one AAAA record containing an address outside any of the > excluded range(s), then it by default SHOULD build an answer section > .................................^^^^^^^^^^^^^^ > for a response including only the AAAA record(s) that do not contain > any of the addresses inside the excluded ranges. That answer section > is used in the assembly of a response as detailed in Section 5.4. > Alternatively, it MAY treat the answer as though it were an empty > answer, and proceed accordingly. It MUST NOT return the offending > AAAA records as part of a response. > > We believe this is in line with the WG consensus in section 5.1.1. > > > The updated files are here: > http://www.rfc-editor.org/authors/rfc6147.txt > http://www.rfc-editor.org/authors/rfc6147.xml > http://www.rfc-editor.org/authors/rfc6147-diff.html > > > We are soliciting feedback for this change until noon (Prague time) > on Friday, April 1. Please send feedback to behave@ietf.org. > > -d > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > From jari.arkko@piuha.net Tue Mar 29 06:47:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AD43A6936 for ; Tue, 29 Mar 2011 06:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 A7W3gs9XOHxS for ; Tue, 29 Mar 2011 06:47:22 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DCEE13A690F for ; Tue, 29 Mar 2011 06:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2AC842CC39; Tue, 29 Mar 2011 16:48:58 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0Y8PCIkch2l; Tue, 29 Mar 2011 16:48:57 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9B58D2CC2F; Tue, 29 Mar 2011 16:48:57 +0300 (EEST) Message-ID: <4D91E349.40005@piuha.net> Date: Tue, 29 Mar 2011 15:48:57 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Savolainen Teemu (Nokia-TP/Tampere)" , Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] comment on draft-ietf-behave-v4v6-bih X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 13:47:23 -0000 I think the scoping and recommendations in this document is fine. However, I would reformulate this: > Use of BIH together with a > NAT64 is NOT RECOMMENDED as a competing technology for tunneling > based transition solutions. > as follows: "Use of BIH together with a NAT64 is NOT RECOMMENDED. Tunneling based transition solutions are recommended instead." Jari From vicmank@rogers.com Tue Mar 29 06:54:24 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C661B3A690F for ; Tue, 29 Mar 2011 06:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FLHlf5qL97q for ; Tue, 29 Mar 2011 06:54:20 -0700 (PDT) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by core3.amsl.com (Postfix) with SMTP id 524C53A68FC for ; Tue, 29 Mar 2011 06:54:20 -0700 (PDT) Received: (qmail 20586 invoked from network); 29 Mar 2011 13:55:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version:Content-type; b=jcdoXYii5sMDu6EvULlCXjBv9Epb5gEKyGllhPZUoZp+Y2IVkIkvD9W0ChuDI+YwOXs4NU5lxWvDfSK9r0npVb8lyTLZVCoeX22YcGkVldZN7KWGateBFmFK/6WRAfeDtsIOdFqSXKeMkNCMrJa4JHSRc+r9Tyetzjyb4/jBGd0= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1301406951; bh=E4HBtGKKqusrl9LiOXKLYBk4yy1YetTLggNiVw2yWMo=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version:Content-type; b=A3Hnm5Y20KVXkrma9LRNPKwQGivonjNiKkoPp7Zql0vOwrxI/L7Pnm/9tjFHRyO/HWlqyqe0Ok0keA3vwu4nK/nE8V1QShXh3zTbfcWcF9k6V0BEJv6tFb1O9LBKzaVBdsRaUqu6wbKpgp+ExRh9fKyWmkGG0WnL1BQdVB3Zzb4= Received: from [130.129.19.75] (vicmank@130.129.19.75 with login) by smtp108.rog.mail.re2.yahoo.com with SMTP; 29 Mar 2011 06:55:51 -0700 PDT X-Yahoo-SMTP: f9g07a.swBDGzI9q2Xty6cZwEaZpJ.WouSaMcQ-- X-YMail-OSG: oay0Jx8VM1lmA207.kpkoJ7axsmBzzuxW3kVI2DpXWzuT41 LmL4L.PJKxaHGLvvcWRxYxVwxGXaF5Cmmt8r08fP7aq9xhbEFl0cRRSIENhh RB8nkeraCI241_XFyIlS5kf3O6yhO6NuvT9dbVFYYfuVkNBkXBB7nSSyoiZ5 jZDN5XZxjTkTIjsXePn5Mq8WGazTGo6SuIdfOt.kfc0LwcPJ76ahysXltn1p SXp0qlBXAwZFRtpJZr1bJrdUd8pWUv0KnHJoZ.RJ8qOAds.unSItkezu6Oz8 4uTspgRiaZ.PNX3ci_VeD.GoEEEmSCdzCkFMYyPkVbIK8z..Bne73N.kB9ai QmbvlFUA2FF5LZKM6 X-Yahoo-Newman-Property: ymail-3 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Tue, 29 Mar 2011 15:59:34 +0200 From: Victor Kuarsingh To: Dave Thaler , Dan Wing Message-ID: Thread-Topic: Regarding 6to4-PMT Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384259179_4293033" Cc: "behave@ietf.org" Subject: [BEHAVE] Regarding 6to4-PMT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 13:54:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384259179_4293033 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Chairs, There is a 6to4-PMT Draft under discussion in the v6ops working group [draft-kuarsingh-v6ops-6to4-provider-managed-tunnel]. Originally, this draft was not intending to introduce any changes to NAT (in theory) but doe= s differ with the current draft-mrw-nat66 I-D which covers NAT66. The main difference include: * The use of PMT is not included in the "NPTv6 Applicability Statement" in section 1.2 * It does not align with the "multi-homing" and "redundancy/load-sharing" sections since the 6to4 continues to use RFC3068 (WKP) to get to the 6to4/PMT relay * The PMT implementation does not include provisions for "Checksum Nutural Mappings" but uses RF3022 "checksum adjustment" as used in many NATs today. * PMT is targeted as "stateless" but does not prevent "statefull implementations" * PMT does not promote any given algorithm for the Prefix Translation (Flexible), but the most basic mapping is provided in that draft (Maps a 2002::/16 to a Provider:/32 and drops the Sub-ID bits =AD keeping the Host generated (65-128) bits Due to this, do we need to discuss this draft and/or concept within the Behave WG? As a side note, 6to4-PMT is already in code and working/being tested in a couple labs/network. By the way, the concept as a whole will be debated once again in v6ops alon= g with two other drafts associated with 6to4 (so I do not know the future status of the draft just yet) Regards, Victor K --B_3384259179_4293033 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Chairs,

=
There is a 6to4-PMT Draft under discussion in the v6ops working group [= draft-kuarsingh-v6ops-6to4-provider-managed-tunnel].  Originally, this = draft was not intending to introduce any changes to NAT (in theory) but does= differ with the current draft-mrw-nat66 I-D which covers NAT66.
<= div>
The main difference include:
  • The use of PMT = is not included in the "NPTv6 Applicability Statement" in section 1.2
    • It does not align with the "multi-homing" and "redundancy/load-sharing" se= ctions since the 6to4 continues to use RFC3068 (WKP) to get to the 6to4/PMT = relay
  • The PMT implementation does not include provisions for "Checks= um Nutural Mappings" but uses RF3022 "checksum adjustment" as used in many N= ATs today.
  • PMT is targeted as "stateless" but does not prevent "stat= efull implementations"
  • PMT does not promote any given algorithm for = the Prefix Translation (Flexible), but the most basic mapping is provided in= that draft (Maps a 2002::/16 to a Provider:/32 and drops the Sub-ID bits &#= 8211; keeping the Host generated (65-128) bits

= Due to this, do we need to discuss this draft and/or concept within the Beha= ve WG?

As a side note, 6to4-PMT is already in code = and working/being tested in a couple labs/network.

= By the way, the concept as a whole will be debated once again in v6ops along= with two other drafts associated with 6to4 (so I do not know the future sta= tus of the draft just yet)

Regards,

<= /div>
Victor K
--B_3384259179_4293033-- From Internet-Drafts@ietf.org Tue Mar 29 07:15:03 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CE23A68DA; Tue, 29 Mar 2011 07:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 A2cKgaJzEzUI; Tue, 29 Mar 2011 07:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200FB3A6A38; Tue, 29 Mar 2011 07:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329141502.9128.50793.idtracker@localhost> Date: Tue, 29 Mar 2011 07:15:02 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-ftp64-08.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, 29 Mar 2011 14:15:03 -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 : An FTP ALG for IPv6-to-IPv4 translation Author(s) : I. van Beijnum Filename : draft-ietf-behave-ftp64-08.txt Pages : 16 Date : 2011-03-29 The File Transfer Protocol (FTP) has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as 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 do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-ftp64-08.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-ftp64-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29071137.I-D@ietf.org> --NextPart-- From iljitsch@muada.com Tue Mar 29 07:28:39 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC713A682B for ; Tue, 29 Mar 2011 07:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hXyvQ+eFgkU0 for ; Tue, 29 Mar 2011 07:28:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id 1B9543A68AA for ; Tue, 29 Mar 2011 07:28:37 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.51]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p2TEVoo1089889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Mar 2011 16:31:50 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <20110329141502.9128.50793.idtracker@localhost> Date: Tue, 29 Mar 2011 16:29:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C45D474-F9CC-43A4-B83F-097246845960@muada.com> References: <20110329141502.9128.50793.idtracker@localhost> To: Behave WG X-Mailer: Apple Mail (2.1084) Cc: David Harrington Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-ftp64-08.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, 29 Mar 2011 14:28:39 -0000 On 29 mrt 2011, at 16:15, 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 : An FTP ALG for IPv6-to-IPv4 translation > Author(s) : I. van Beijnum > Filename : draft-ietf-behave-ftp64-08.txt > Pages : 16 > Date : 2011-03-29 This is in response to the AD review. See the diff with the previous = version here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-ftp64-08 The biggest change is that the ALGS command is now a MUST and not a = SHOULD. Also, applications MUST support enabling/disabling EPSV translation = through the ALGS command. I consider the latter a minor change as it's = already mandatory to have EPSV translation (the whole point of this = effort) and disable it after an AUTH command. Iljitsch From Francis.Dupont@fdupont.fr Tue Mar 29 08:09:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2C63A6940 for ; Tue, 29 Mar 2011 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl5HH-URxEfm for ; Tue, 29 Mar 2011 08:09:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 2921D3A6A39 for ; Tue, 29 Mar 2011 08:09:18 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2TFAugP027159 for ; Tue, 29 Mar 2011 17:10:56 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103291510.p2TFAugP027159@givry.fdupont.fr> From: Francis Dupont To: behave@ietf.org Date: Tue, 29 Mar 2011 17:10:56 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:09:19 -0000 As I said it is too late in Europe to convince lawyers they are wrong (if you know a way to convince a lawyer or a journalist about a technical point :-), for instance: http://bits.blogs.nytimes.com/2008/01/22/europe-your-ip-address-is-personal/ Worst, I am really afraid this could give as feelings for end-users, we already had a lot of bad feedlings for IPv6 interface ID, and this has clearly more solid basis. Regards Francis.Dupont@fdupont.fr From ajs@shinkuro.com Tue Mar 29 08:14:19 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF82B3A6855 for ; Tue, 29 Mar 2011 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 Ej9k62DvNwOK for ; Tue, 29 Mar 2011 08:14:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7C11E3A6835 for ; Tue, 29 Mar 2011 08:14:18 -0700 (PDT) Received: from shinkuro.com (unknown [130.129.34.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D60681ECB41D for ; Tue, 29 Mar 2011 15:15:55 +0000 (UTC) Date: Tue, 29 Mar 2011 11:15:50 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110329151548.GB88272@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:14:19 -0000 This is a note to amplify my remarks today. Using a well-known name in the DNS to detect the existence of a DNS64 is, frankly, an idea that makes me cringe. Among the deep problems in the DNS is its somewhat careless commingling of the data plane and control plane. What this sort of proposal does is make that commingling worse, by using the exact same form of query and answer sometimes for control, and sometimes for data. Reaching back to my database theory days, I want to call this "minus first normal form" or something like that. So, in the first place, there is a serious architectural issue here. The point of having data types in the DNS is that the data that you get from it is supposed to be one kind of data and one kind only. But this proposal makes a positive answer to AAAA mean not one, but two things: (1) you can contact host $name on address $ipv6_address and (2) there's a NAT64 here. In the second place, there's a serious operational side effect to all this. What this proposal means is that the root name servers for the DNS will have to take a pile more garbage traffic. A AAAA query for $well-known-name will be quite common. Any application that cares about this will issue these queries forever, and when the desired end goal (native v6 [almost] everywhere) happens, applications on all those networks will continue to make this AAAA query. It's going to leak from local networks (it's practically _designed_ to leak), and we'll never get rid of it. So, a well-known name is a terrible idea. It is a filthy hack and it has bad side effects for the global DNS. It ought to be a straightforward loser. But, of course, that was true of most NAT proposals, and we got all of them no matter how stupid they were, partly by ignoring the work instead of working on the one that would be least bad. What I heard at the mic today is, "We who put IPv4 literals in our higher-level protocols and who are now depending on them are going to use a well-known name, because we have practical limitations on doing other things. We don't have a choice, and this is the way we are going to do it, period, so get used to it." Since I have no desire to pretend to be King Canute, then, I have to concede that we need to document something. But while I am willing to bow to reality and make an architecturally hideous concession, we simply cannot increase the garbage queries that will be directed for the rest of eternity at the root servers. So we need to come up with something to solve the operational consequences. The question I have, then, for the people who are absolutely determined to go this direction is how many restrictions you really have. Does this have to be a bog-standard AAAA query? In particular, I'm wondering whether you could do something with a PTR query (inside ip6.arpa) instead of a AAAA. I'm imagining a case where you get an answer for a particular address inside the reverse tree only if there is a DNS64 in the way. Only if you get the required answer, you may do the forward AAAA query for the well-known name. The reason I am thinking that might be better is that there is infrastructure (the AS112 project) set up to sink garbage queries of the sort the well-known name proposal is guaranteed to generate. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From arifumi@nttv6.net Tue Mar 29 08:24:26 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CA73A682B; Tue, 29 Mar 2011 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, 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 d9L972GluD7b; Tue, 29 Mar 2011 08:24:25 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by core3.amsl.com (Postfix) with ESMTP id DB7403A6824; Tue, 29 Mar 2011 08:24:24 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p2TFOXgm014360; Wed, 30 Mar 2011 00:24:34 +0900 (JST) (envelope-from arifumi@nttv6.net) References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <040201cbed46$6b4c5790$41e506b0$@com> <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <8B54EB8B-F0A6-4FAD-A364-1524EA08600E@nttv6.net> Content-Transfer-Encoding: quoted-printable From: Arifumi Matsumoto Date: Wed, 30 Mar 2011 00:24:33 +0900 To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , 'Teemu Kiviniemi' , "behave@ietf.org" , Dan Wing Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:24:26 -0000 Hi, thank you for insightful comments on this issue, all. I'll put some texts in the next version to note discussions about it. Best regards, On 2011/03/29, at 19:47, Suresh Krishnan wrote: > Hi Dan/Teemu(s)/Cameron, > I am afraid there is no single right answer here. There will be = networks that will prefer NAT44 over NAT64 and those that prefer NAT64 = over NAT44. For this reason, I think this is better left as a = site-specific policy decision for distribution using a mechanism such as = draft-ietf-6man-addr-select-opt. So, I agree with Dan and Cameron that = we should not add an entry to the default table for the NAT64 prefix. >=20 > Cheers > Suresh=20 >=20 >> -----Original Message----- >> From: behave-bounces@ietf.org=20 >> [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing >> Sent: Monday, March 28, 2011 2:48 PM >> To: 'Teemu Kiviniemi'; teemu.savolainen@nokia.com >> Cc: ipv6@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix >>=20 >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]=20 >> On Behalf=20 >>> Of Teemu Kiviniemi >>> Sent: Sunday, March 27, 2011 9:53 PM >>> To: teemu.savolainen@nokia.com >>> Cc: behave@ietf.org; ipv6@ietf.org >>> Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix >>>=20 >>> On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote: >>>=20 >>>> I discussed shortly with Arifumi about RFC3484 default=20 >> policy table=20 >>>> updates and NAT64 WKP, i.e. whether the default policy=20 >> table should >>> take >>>> a stand on 64:ff9b::/96 preference. >>>>=20 >>>> It seemed to us that default policy table does not=20 >> necessarily have >>> to, >>>> as it could be ok to handle addresses with WKP similarly to global >>> IPv6 >>>> addresses. Furthermore, the default policy table anyway=20 >> cannot cover=20 >>>> Network-Specific Prefixes. >>>>=20 >>>> Hence prefixes used for protocol translation would be=20 >> handled like=20 >>>> global IPv6 addresses unless something different is=20 >> configured via=20 >>>> policy distribution mechanism? And this should perhaps be=20 >> documented=20 >>>> into the RFC3484-revised. >>>=20 >>> I believe native IPv4 should always be preferred over=20 >> NAT64. Even if=20 >>> native IPv4 was using NAT, it is likely to work better with current=20= >>> applications than NAT64. >>>=20 >>> Preferring IPv4 over the NAT64 well-known prefix does not fix the=20 >>> problem for network-specific NAT64 prefixes. However, I see=20 >> no reasons=20 >>> why the >>> NAT64 WKP should not be given a lower preference than IPv4=20 >> by default. >>=20 >> One reason is that it changes behavior for a network using=20 >> the well-known >> NAT64 prefix versus using their own network's NAT64 prefix. =20 >> Not to mention they won't know if/when their IPv6 devices are=20 >> using the new >> RFC3484 default table, and will thus start shifting their=20 >> preference away from IPv6 (and a NAT64) and towards IPv4 (and=20 >> a NAPT44, because let's be real, everyone will have a NAPT44=20 >> if we're talking about an >> RFC3484 change). >>=20 >> Personally, I don't see any benefit to changing RFC3484 table=20 >> to accomodate NAT64, assuming there is a way for the host to=20 >> learn its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis). =20= >> Assuming there is no standard way to learn the prefix by the=20 >> time we would want to standardize rfc3484bis, I see harm in=20 >> adding the NAT64 well known prefix 64:ff9b::/96 to the=20 >> default policy table. >>=20 >> -d >>=20 >>=20 >>> -- >>> Teemu >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ajs@shinkuro.com Tue Mar 29 08:38:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402ED3A6981 for ; Tue, 29 Mar 2011 08:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 CsOPLZ4d2Q1X for ; Tue, 29 Mar 2011 08:38:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 77B0D3A6801 for ; Tue, 29 Mar 2011 08:38:48 -0700 (PDT) Received: from shinkuro.com (unknown [130.129.34.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0D2051ECB41D for ; Tue, 29 Mar 2011 15:40:25 +0000 (UTC) Date: Tue, 29 Mar 2011 11:40:18 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110329154017.GD88272@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [BEHAVE] draft-jpdionne-behave-nat64-mib-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:38:49 -0000 There was some suggestion today that draft-jpdionne-behave-nat64-mib-00 would need a DNS64 MIB, which would need a DNS MIB, I guess. What is it that would be useful about a DNS64 MIB? The only mention of DNS64 in the document is that it needs to have the same configuration as something that would be in the NAT64 MIB anyway. Is there some use case for the DNS64 side I'm not seeing? (That's not a rhetirical question. I actually don't know.) Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marc.blanchet@viagenie.ca Tue Mar 29 08:49:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEEC3A693E for ; Tue, 29 Mar 2011 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UqefHDuFxIXR for ; Tue, 29 Mar 2011 08:49:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DB4143A6812 for ; Tue, 29 Mar 2011 08:49:42 -0700 (PDT) Received: from dhcp-57b6.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:5ab0:35ff:fe6a:294a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4D67520F5B for ; Tue, 29 Mar 2011 11:51:20 -0400 (EDT) Message-ID: <4D91FFF7.1040807@viagenie.ca> Date: Tue, 29 Mar 2011 17:51:19 +0200 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: behave@ietf.org References: <20110329154017.GD88272@crankycanuck.ca> In-Reply-To: <20110329154017.GD88272@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] draft-jpdionne-behave-nat64-mib-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:49:45 -0000 Andrew, let rephrase the other way: if a DNS MIB existed and was in used, then we would have look at it to see to add the DNS64 specifics. Since no DNS MIB exist, then we don't know if there is any value. While we have seen support for the NAT64 mib from 2 operators and 3 vendors today, I haven't heard any specific support for DNS64. So I guess we will put the DNS64 MIB to sleep, unless someone requests it. Marc. Le 11-03-29 17:40, Andrew Sullivan a crit : > There was some suggestion today that > draft-jpdionne-behave-nat64-mib-00 would need a DNS64 MIB, which would > need a DNS MIB, I guess. > > What is it that would be useful about a DNS64 MIB? The only mention > of DNS64 in the document is that it needs to have the same > configuration as something that would be in the NAT64 MIB anyway. Is > there some use case for the DNS64 side I'm not seeing? (That's not a > rhetirical question. I actually don't know.) > > Thanks, > > A > -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From kaeo@merike.com Tue Mar 29 08:58:02 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46A73A690E for ; Tue, 29 Mar 2011 08:58:02 -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 AfgwM8+RHAa0 for ; Tue, 29 Mar 2011 08:58:01 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by core3.amsl.com (Postfix) with ESMTP id A30C33A6A32 for ; Tue, 29 Mar 2011 08:58:01 -0700 (PDT) Received: from dhcp-15a4.meeting.ietf.org ([130.129.21.164]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p2TFxbup028383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Mar 2011 08:59:39 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Merike Kaeo In-Reply-To: <20110329154017.GD88272@crankycanuck.ca> Date: Tue, 29 Mar 2011 08:59:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <627B188A-551E-40EA-9BC1-875E54C97031@merike.com> References: <20110329154017.GD88272@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1082) Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-jpdionne-behave-nat64-mib-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:58:03 -0000 That comment came from me and I really meant the NAT64 (apologies for = mis-speaking). While the environment I am in is doing DNS64/NAT64 I do = need to specifically take a look at what MIB variables exist and what = would be useful operationally. I'll start with the existing NAT64 one. And while I'm commenting, I would personally hate to see private = extensions and then see where they all meet. I still remember the FDDI = MIB nightmares with a private one and the later standardized one and = trying to figure out which version of the MIB different vendors = supported. Thankfully I met the authors of snmpwalk back then which = saved me. =20 I doubt I'll get to this in the current week but will try and get some = comments on list next week. - merike On Mar 29, 2011, at 8:40 AM, Andrew Sullivan wrote: > There was some suggestion today that > draft-jpdionne-behave-nat64-mib-00 would need a DNS64 MIB, which would > need a DNS MIB, I guess. >=20 > What is it that would be useful about a DNS64 MIB? The only mention > of DNS64 in the document is that it needs to have the same > configuration as something that would be in the NAT64 MIB anyway. Is > there some use case for the DNS64 side I'm not seeing? (That's not a > rhetirical question. I actually don't know.) >=20 > Thanks, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From alh-ietf@tndh.net Tue Mar 29 09:20:11 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2956C3A691E for ; Tue, 29 Mar 2011 09:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF0rhKu3CKDm for ; Tue, 29 Mar 2011 09:20:08 -0700 (PDT) Received: from tndh.net (unknown [50.46.43.186]) by core3.amsl.com (Postfix) with ESMTP id AD9A03A6863 for ; Tue, 29 Mar 2011 09:20:06 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from ahainW7 ([192.168.123.15]:61214) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Tue, 29 Mar 2011 09:21:37 -0700 From: "Tony Hain" To: "'Dan Wing'" , "'Dave Thaler'" , "'Lars Eggert'" Date: Tue, 29 Mar 2011 09:21:34 -0700 Message-ID: <04da01cbee2d$618b76e0$24a264a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvuLVls+IWTV3RoRfiEctDRpBcY9A== Content-Language: en-us x-cr-hashedpuzzle: 1Ro= ASNO Brcv Cy87 F4IN IG8r KQVE XMoI dD0q iFRv jpHQ kN0h lkFl n74Z uWWK u/D7; 4; YgBlAGgAYQB2AGUAQABpAGUAdABmAC4AbwByAGcAOwBkAHQAaABhAGwAZQByAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA7AGQAdwBpAG4AZwBAAGMAaQBzAGMAbwAuAGMAbwBtADsAbABhAHIAcwAuAGUAZwBnAGUAcgB0AEAAbgBvAGsAaQBhAC4AYwBvAG0A; Sosha1_v1; 7; {B10E4D6A-2803-4B57-8A76-B7C22FB71241}; YQBsAGgALQBpAGUAdABmAEAAdABuAGQAaAAuAG4AZQB0AA==; Tue, 29 Mar 2011 16:21:25 GMT; SQBHAE0AUAAvAE0ATABEACAAaQBzACAAYQAgAGIAcgBvAGsAZQBuACAAaQBkAGUAYQAgAGEAbgBkACAAYQAgAHcAYQBzAHQAZQAgAG8AZgAgAHQAaQBtAGUA x-cr-puzzleid: {B10E4D6A-2803-4B57-8A76-B7C22FB71241} Cc: behave@ietf.org Subject: [BEHAVE] IGMP/MLD is a broken idea and a waste of time X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 16:20:11 -0000 This is not a new concept, and it didn't gain enough deployment traction the last time people thought it was a good idea. https://datatracker.ietf.org/doc/draft-ietf-ngtrans-mtp/ Once you get into the operational reality of the differences you figure out that bandwidth is way cheaper than the overhead of trying to manage translation. Do not waste IETF resources on yet another BoF for hacks to avoid getting on with IPv6 deployment. Tony From tena@huawei.com Tue Mar 29 09:36:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9577D3A697F; Tue, 29 Mar 2011 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.455 X-Spam-Level: X-Spam-Status: No, score=-105.455 tagged_above=-999 required=5 tests=[AWL=1.145, 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 Ei+pMFRPN9dt; Tue, 29 Mar 2011 09:36:55 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id D4B743A6A3C; Tue, 29 Mar 2011 09:36:55 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT004HTVKAC8@usaga03-in.huawei.com>; Tue, 29 Mar 2011 11:38:34 -0500 (CDT) Received: from TingZousc1 ([130.129.19.214]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIT00IJIVK7VB@usaga03-in.huawei.com>; Tue, 29 Mar 2011 11:38:34 -0500 (CDT) Date: Tue, 29 Mar 2011 18:37:55 +0200 From: Tina Tsou To: softwires@ietf.org, behave@ietf.org, mboned@ietf.org, 'IPv6 Ops WG' Message-id: <007501cbee2f$be1a4f60$3a4eee20$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvuL6fFhcBvvwkUTCOg/Wh+n096dw== Subject: [BEHAVE] IPv4-IPv6 Multicast meeting on Wed 3:10 PM-4:10 PM X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 16:36:57 -0000 Hi all, Per suggestion from the chairs and audience of today's behave meeting, I'm forwarding the following meeting info to the related WGs. You are welcome to join. Subject: IPv4-IPv6 Multicast meeting: summary of this week and next steps When: Wednesday, March 30, 2011 3:10 PM-4:10 PM Prague. Where: Room Tyrolka, Level M We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From mcr@sandelman.ca Mon Mar 28 08:59:59 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9B228C0E8 for ; Mon, 28 Mar 2011 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOTfHSK4oGLY for ; Mon, 28 Mar 2011 08:59:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4A31D28C0E6 for ; Mon, 28 Mar 2011 08:59:57 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-164d.meeting.ietf.org [130.129.22.77]) by relay.sandelman.ca (Postfix) with ESMTPS id C461734139 for ; Mon, 28 Mar 2011 12:01:34 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C88FF98B18 for ; Mon, 28 Mar 2011 18:02:19 +0200 (CEST) From: Michael Richardson To: behave@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Mon, 28 Mar 2011 18:02:19 +0200 Message-ID: <8764.1301328139@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Tue, 29 Mar 2011 09:39:02 -0700 Subject: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 15:59:59 -0000 I'm sorry if this a repeat. {Although I've been on the mailing list a long time, I have been ignoring it, and actually made a decision to unsubscribe a few hours ago... I don't think I've succeeded yet.} Today I tried the ietf-nat64 network. I found that I got the wrong DNS server via RA, and I'm told that it might work. I expected to have to put the correct one into my local recursive resolvers' "forwarder" list, but in fact to my surprise my /etc/resolv.conf was updated by NetworkManager. It wasn't until I started filling out they survey that I realized I should flush my DNS cache, that I'd have to. So, this needs to be addressed somewhere --- we really need some signal in the RA that there is a NAT64 available, and therefore if you have a local recursive resolver, you should either do DNS64, or you should pay more serious attention to the DNS value you get from the RA (or the DHCPv6). I discovered some things that did not work (mostly in my IM client), which I reported.... aha... do I have to flush my DNS cache? yes, I do. marajade-[~] mcr 10005 %dig @2001:df8:0:7::1 www.credil.org aaaa ;; ANSWER SECTION: www.credil.org. 6118 IN AAAA 64:ff9b::adec:8254 The TTL in the reply is way too high. I can easily imagine wandering in and out of IPv6 only networks (with suspends in between). I shouldn't have to flush my DNS cache each time. I'd like to suggest that the TTL be 1. Section 5.1.7 of draft-ietf-behave-dns64-11 says: o The TTL field is set to the minimum of the TTL of the original A RR and the SOA RR for the queried domain. (Note that in order to obtain the TTL of the SOA RR, the DNS64 does not need to perform a new query, but it can remember the TTL from the SOA RR in the negative response to the AAAA query. If the SOA RR was not delivered with the negative response to the AAAA query, then the DNS64 SHOULD use a the minimum of the TTL of the original A RR and 600 seconds. It is possible instead to query explicitly for the SOA RR and use the result of that query, but this will increase query load and time to resolution for little additional benefit.) This is in keeping with the approach used in negative caching ([RFC2308]. I can see that this is trying to find a heuristic that tries to find a reasonable upper bound so that if a AAAA does appear then it won't take too long to discover this. Unfortunately, it fails, I think, for mobile nodes that can be on different networks in series without restarting. I.e. laptops and smartphones. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From dthaler@microsoft.com Mon Mar 28 04:04:57 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40083A6403 for ; Mon, 28 Mar 2011 04:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7pg6UdjT-4N for ; Mon, 28 Mar 2011 04:04:57 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1D30C3A63EB for ; Mon, 28 Mar 2011 04:04:56 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Mar 2011 04:06:33 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 28 Mar 2011 04:06:33 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.127]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 04:05:28 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Comments on draft-ietf-behave-lsn-requirements-01.txt Thread-Index: AcvtN5fiWakLxxynSxOMZR7cifm9lw== Date: Mon, 28 Mar 2011 11:05:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B0052A6@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/mixed; boundary="_002_9B57C850BB53634CACEC56EF4853FF653B0052A6TK5EX14MBXW604w_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 29 Mar 2011 09:39:02 -0700 Subject: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-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: Mon, 28 Mar 2011 11:04:57 -0000 --_002_9B57C850BB53634CACEC56EF4853FF653B0052A6TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't have time right now to transcribe into text, but attached is a marked up PDF with my comments. -Dave --_002_9B57C850BB53634CACEC56EF4853FF653B0052A6TK5EX14MBXW604w_ Content-Type: application/pdf; name="draft-ietf-behave-lsn-requirements-01.pdf" Content-Description: draft-ietf-behave-lsn-requirements-01.pdf Content-Disposition: attachment; filename="draft-ietf-behave-lsn-requirements-01.pdf"; size=224758; creation-date="Mon, 28 Mar 2011 11:02:54 GMT"; modification-date="Mon, 28 Mar 2011 11:02:55 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDM5IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEyL0tpZHNbIDMgMCBSIDE2 IDAgUiAxOCAwIFIgMjAgMCBSIDIyIDAgUiAyNCAwIFIgMjYgMCBSIDI4IDAgUiAzMCAwIFIgMzIg MCBSIDM0IDAgUiAzNiAwIFJdID4+DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl bnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDcgMCBSL0YzIDkgMCBSL0Y0 IDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRp YUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyA0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMD4+DQplbmRv YmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzUxNj4+DQpzdHJlYW0N Cnic7Rxrbxs38rsA/4dFP1mHar187OsQGIidx7lAeunZuAfcflAk23Fj2a7lxPG/Pw6XM+JotbMr J8Fd74ogMpfikMN5z5CrZO9t8uzZ3pvDoxdJtr+fHLw4TLK0tnVysTOy1qZZmZQmLTObqKJKrUoK 16mL5O5sZ3T+p51R8vLNYZJEs6gwy8HJzmjvlUqqNK91cnK+M1JJ5v65GVSaZVVS5DpVeXKy2Bll sFqWvN4Zne4ejSd69xo+7sfV7hk07lzD95y5xj00Etd42Qysdi+gcRmPIahLNiaBjxP3NIXG0jU+ 4GSvoHHjGnfQmOEc8FXS2xg8UGwcQyPFnre4lzvci0do6hofoXGFpPgeIV66xryZ45fk5Ied0UvH AeAC0t2aLNU6pvupg1yNbbFSR6xcZ57VKc7Rz7HN+KjMIaLZVJPOoWWq+KovcB3PzPNYMr4xo/7D s/4dxd1v/AJJfo3iftbD/oiGIveNwH2j08p0s/8aRfEMG4D4EsdMsfER9fDPOOYAGoeu8fb3zbEj 10ix51+ouQtsXGDjvmnIHIupLbLMCizTJlVFmMSbzs/wcYtSQxaGseMYmXjL+LtwjXfMQMFgBQ3D bJJ2jQwaCr9POvaqM5sWmqP5X8jazcgb5yJrjvtxLABvUGUfke8fsPEwRAA4UQQByAUBUCbNFafs 71W7ntDoYJwp07rktPnRjT8BwBOc4RA+blB/F2i4yOLOYpt2iYOvG22SOcuZInC2EDibuQDN/t9y 9otUNibd81hlf2xpKtnsQSrLeSIwtuxmbF77+Pv3z9gOk18WqS34Ln9AVbrFxnXsUgfnBZ9RL98j 1/zAJlrqkAiHh6nXid41tm6h/vMurAAbeIvo/hMaP49lUelcsCUqlSAqlU2t/h8QlW88awc7HfWU 5UT8S2wNnje2PIgTePL5ACOwxhSBs7XA2dKmZf4HZ7ebVVbbmKTeX4Or97EupB5/hcabHtZyrgis VZnA2yJP3Z8/eNujnnnl2RZT6w3adSrYvMdpfJ4Bmcf32KOhkeFXqoe1nCkSa5XA2jxP7aCkTQll ltzmaTko8leGqneVycOnSu4udkbaZmlukty4WLN0A02qy6R24YkVqnhCKpmbIs3qVeFue9GV9rEp hVGqBGJGC59uCMpvoEHhAiW0v8HHx/F6nrtYCwXamGwKuZWzILnlmFxj9LHEtc8Rm7s1qW4vsin8 I4ZFixyNqSYSAqN58xE0AEKgJUOC3BVpCdVIL+IxM2i8X5GFJpPQ3hSKQEhdcazjvWfgYh/gb5aZ Wif4VyV/e+2W0MkPiWv/mnh5rby4FsmiEd9S+ecyudoZHe+MGpGufV+FY+DZagjh1ga5TlvFM7mO osJRgHVRrpaDZ6dybDm/s2K1HD7Hy7VphE49Hm4JHtaMEdmkaLpIjQ2K9vor+4iOQqutUh0vfNrI WVRonejuim7YaAzeWdIt6zSzfOwlSiGE+OddgEEFhywSqkpsLBWuSDk+NT0dU5g8NeXA5YLixmOv UDGvu4CcpxhKNA2SkfOxpP6ioQumMdipDj+r9WDKGl2mJaNsMnEaXbi+k9npbtblZKHiUjFyum6A kE8ipCBKFaBMQ84zJH9NKZiP9d+hdbxn0j8by8cZmY4mknERvL6ty9QMO6ERivS2KsG6NCR2mFVV Q+ekS/chHbcczEOcoIO4ZP5ljk4OiPJxs6Ql4+gg4LzxQeH7MzbZDCdboEenEloSu7hOGQ/fU4Fg iaDnOBnVqQ+ZU6RjwqaW3SG1YBZ1TBtBM3IXYFV87OtmpbAuUcRvHeqNzzEJ8T0/7yKWr8ehEtVX RGCrySIjRHa2rNJMbS8yMZiHoB1+wrhjxoKUriPKEOhFE/btRqh426JKzaDgWQvVVeuSjwLjmeNG vCbR4c3HWNhuMPpLUA6pYEBj3iAlgph3UAJynpyvLu9BKCRaJ771oEKEFmpM1tSQOWwtHTGYZFB6 C3xdIYtJlYqXEYIOH96woevnyGH9pMW3JXL7HdqpSxx8jzjSWec9Wp2ws0lzPu93/mo1fYeXr1Va 1hxNMoXniMYVNK5aBvS6ZfPo1PEaB9Ldhgfc5T2yhAtuz1kyw1CWK6HCZXWdFtuLVQTlAW6RkZ4M n2LxWj+TCdu8QVIBKTacPJfuqcLvqRg974KoHIBr1OOq075BgAj2jXDvO4MX4h6r6rQeVGEwQtxj VQbeamvqx2Ae4og5fjoYJlffqb7B5K8mFNTXBagunGdjX+BKU+Qmc/9T8rzkcB/GUXb+ATWAJ8ZD gps+q08LbnVyQXjwSIkIGuHaoZtZnZZrBJXFQwpFsywtnhARxGArmz9FznxA0ryKeTFjVPNRUNty ukhoolelPbLB6xyPLkwtG4gwL1nCeWzmOUcfmAH9MG7fJAsNsjdgkW/RutC5QQjwwmT3bH8kJ1PB uVmXwOaMnn3MFDICU8PVvq2ZycA8xE1Lzu8GUCVBNfIcelzxI/ixJfOZ89iAUxbme96hTpI+beLZ F+i1UIpuLgxEJDldiViCAvuEKCacPrKJOzOM5hiDjZWFQoj5TaVSXW8vFDGYh+i4kLcU3KFSGuKH aK6+jQjhvilVmg8Kco0Q7hv3t8q3J0cM9jX8YTRhrz9kY7f3h/ONEFuqy0Q3uR7McYW6R6FSOwmf YoOi088ItUDLsWjGTNYitSUO/MzmoPiODFPP5RtGNllghNzK5E6Gt5eXCMoDtMNLIswj9rxjbCPb Oh9H14/Omp7Y4ZEvvEXeTGNnywczJt2gtQ2mORjqs7XFAui7GFfBRcxxnVmzDVmqKNFmQfhjF2t1 DlXlFXn7OCvkuwZuyprtWRuDeYh7JtlnrQDhKN4iz4nJg02R2zzNuR1HYSEXgnYaSqWKTZHpVkYq ZKjRVoWadV2kdcXHDjFSRAOS33OGJJX7moxWcKt8bVkehDzVwD3c7RNVBuYhSLM51YmFlNQzZeS8 nHlR6XALhYFoMVr4tCv2pDpUj85SfYDfyeKM+m5DFLYuxwnKMYnwxbh9hDlp3oT4Tri8V/H9yfei hTTaaJPqQaG1FdJoAxc5nxBax2C8NkY6TN6U7s+3XeIM1Zu/LXLNIJ5YX9PabcjEqAq67syv0nys EBcGSZ5ESVnbz5GzosrVMrZj5C+nksEKRXmGmMxsISk2mXmSIYjBPMR75MY92nJ/837PNfag8YAK 9YA+Y+2ENOhJyKCDMu1tHgizKvxq3sPsFar9zI7HTlnEcB+b+Rn5GUqR4fvP2OismTn/4eZny8is E1Jg7fyBHhQZWCFn0nCxb/skgYF9gbZ3phY9mhyO3CM0hNQCrkTyocIbV8fMPVDW8IDovxjTiV3A cYbbo+oPHcJRGLCFZeDuYz0yHVBhYTuVBUPIQTVcC9y+msrAvrVlYPeCKBZ/QAhaeYGhSE8xO0K+ j3JC3q0LZ0yGveQkJGNwl8Jussxd5FepSxU4WOs2wgZ+rcZ/o9MstoJ8msWGSqdZD4jjFdqZBFH7 jFHZZRyMkeUh/QvvgwWRJPOzQKtP+/Sg8NJX3/tgXcIVHDbbnCwWQian4RrlMBEV4n9tCrjCxq4f Bko8MiN2EasRnfFTdE3vDHUlLSADmebrya99CfGt1sVACuZCfKtVAQnf1oYtBvMQdG3Ti9vjOMp9 LlCRyK00r1QAqZqq/6a7vLFPbB+xnuAClPsST9rnAFHqM4kyFXKwy3F0xkpe6hLn4AWMyzHdeImr Mu30tvewNZR7I1r2MVKIXXVWwg2yrRkZg62ueERVnGrDJRyi80e20ZuYoKEUEkjzvGWfOsSjXR0g tw89n4iNc8mDuc2ZIt5cH2WF0FLBra1BRiYXQktVlemgE/VcCEMU3J8ZpvOCS4YffBi4IcElw0WW EvPrt8SWu9jRTFGErlBO6HzvrCVLVxipSG8jgCUQXnD2Y47H1QBfNoleKjBj4aWCr/PmxCk03nqa dMerheVkpR8BIEx/kUvfDFpmreBWla03ixlPOir4uYnOsb913gjP4Eb4qb827j9+cT3JPBnZQjdv A1RgmRbwOyUuEC3xBYfmOvVPT5qZTYSXwVsTt1+xyJyiSJfbYUHCW9XwOyqAN3ZUkJbZwr8LDNdZ 68I92bSq8Gm2Myoyf2M2dFxBB1iK8Fxklb+13kxFT34lD9x0wM36ugEOHTrVJglTubDDOOaGhZqn GaDZoNJ0XEFHg2nTgbtopqInv9JsZ23XDvq9kw985eS3ZnZVe8xdJK7cLJULfXRa5/7tlH/8Kbl2 g2OJxBANgasNwOHdlgYaxHHvlU6KNM/5T9HYogCpzA0lH/FP0YRYJd9dLMYK/fv9WHkFNk5Vy90X J2qsMqdupUvQLBPsRgK3wdBswDCHI76yC8OjsXbIONtVOM9Yg6EzzvvWux/c/yT4W+u6ldpdJsv3 TfxinamtnRl1nXN4Sn71HrreXd5DX7KcQu8jTPFF27ECwXWJ1xqj7TzLsgOTZbrYn+Su7bQxy3P4 v2/h8XBfKfhbNd2Z2VfaPevn+5PimR9mPFTT7dLEiQ3D3dDaNY1qRmq7X8Fjua9gRObWzA78ujhh FY3ODv28uFw8rxPFIsasgO4G+dy1DwIqBGqbfvfsp3Bus4E78OgFTMPeA0gehhar4bRRWDGsFr5y 4F9bAIljGUyzLoBegG6cqJwtv7ro27IE09ax8pps/hQsyr8BinOnOw0KZW5kc3RyZWFtDQplbmRv YmoNCjUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZv bnQvQUJDREVFK0NvdXJpZXIjMjBOZXcvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNj cmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjQvV2lkdGhzIDY4OSAwIFI+Pg0K ZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStD b3VyaWVyIzIwTmV3L0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDgzMy9EZXNjZW50IC0x ODgvQ2FwSGVpZ2h0IDYxMy9BdmdXaWR0aCA2MDAvTWF4V2lkdGggNzQ0L0ZvbnRXZWlnaHQgNDAw L1hIZWlnaHQgMjUwL1N0ZW1WIDYwL0ZvbnRCQm94WyAtMTIyIC0xODggNjIzIDYxM10gL0ZvbnRG aWxlMiA2OTAgMCBSPj4NCmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1 ZVR5cGUvTmFtZS9GMi9CYXNlRm9udC9BQkNERUUrVGFob21hLEJvbGQvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDggMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMTYv V2lkdGhzIDY5MSAwIFI+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9y L0ZvbnROYW1lL0FCQ0RFRStUYWhvbWEsQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2Vu dCAxMDAwL0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2Z1dpZHRoIDUwNi9NYXhXaWR0aCAy MzIzL0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUwL0ZvbnRCQm94WyAtNjk4IC0y MDcgMTYyNSA3NjVdIC9Gb250RmlsZTIgNjkyIDAgUj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8L1R5 cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvVGltZXMjMjBOZXcjMjBS b21hbi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMTAgMCBSL0ZpcnN0 Q2hhciAzMi9MYXN0Q2hhciAxMjEvV2lkdGhzIDY5NiAwIFI+Pg0KZW5kb2JqDQoxMCAwIG9iag0K PDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9UaW1lcyMyME5ldyMyMFJvbWFuL0ZsYWdz IDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY5My9B dmdXaWR0aCA0MDEvTWF4V2lkdGggMjU2OC9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFk aW5nIDQyL1N0ZW1WIDQwL0ZvbnRCQm94WyAtNTY4IC0yMTYgMjAwMCA2OTNdID4+DQplbmRvYmoN CjExIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9UaW1lcyMyME5l dyMyMFJvbWFuL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDEyIDAgUi9Ub1Vu aWNvZGUgNjkzIDAgUj4+DQplbmRvYmoNCjEyIDAgb2JqDQpbIDEzIDAgUl0gDQplbmRvYmoNCjEz IDAgb2JqDQo8PC9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFuL1N1YnR5cGUvQ0lERm9udFR5 cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g MTQgMCBSL0ZvbnREZXNjcmlwdG9yIDE1IDAgUi9XIDY5NSAwIFI+Pg0KZW5kb2JqDQoxNCAwIG9i ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+ DQplbmRvYmoNCjE1IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVz IzIwTmV3IzIwUm9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODkxL0Rlc2NlbnQg LTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhXaWR0aCAyNTY4L0ZvbnRXZWlnaHQg NDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAvRm9udEJCb3hbIC01NjggLTIxNiAy MDAwIDY5M10gL0ZvbnRGaWxlMiA2OTQgMCBSPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8L1R5cGUv UGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vUHJvY1NldFsv UERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0g L0NvbnRlbnRzIDE3IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMT4+DQplbmRvYmoNCjE3IDAgb2JqDQo8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIyNjI+Pg0Kc3RyZWFtDQp4nO1bWW/bOBB+N+D/wLfG i5oRD12LokCuLrJoi6DxW9oH11eydeJs7LTJv1+S9oxJyRpJ2Tw03UWBdCBxRuR8w7lIs/0z9ubN /oej02MWvX3LDo+PWMRznbNZt6O15lHKUsXTSDORZFwLlpiHMmF3k25n+lu3w04+HDHmSREbKYeD bmf/nWAZj3PJBtNuR7DI/DMSBI+ijCWx5CJmg+tuJ7Jfi9gf3c7F3mmvL/du7J9VL9ubWOLOEO7J xBCr3hc2+LPbOTHy7TdAqoiMOOlLvdjrV45NucjCscfwpaElpu5LhmCGYFVE3fts78gSfxjiIzz5 BAv52xL3hriCL7vFXsN71MGywXfqieLjD5YYGuLOEiNDXMIraYnIEMISokKJWkVcFhTOvLEly5Ce ZRRtQUveSIYiZCjJM9VEiCaESMVF4oSYfRDJLGODkRHHWIUW0oRrHbI5joFV3SWguwTNjw2xAIXf r/HeAH/jm1zItQRT+WqJv4Bj5HM4YgEch2B7Z/AkNUQGg4e4ycbwfgUWMIEnp4Y4scTAEO+AdQDW eg9TdF9+tTVU8+c9THEGH5tX6E9lOZfCV2ANeDEBnlA8Fu3B89kcxxms0UH13cfjCtR8EyD0CRY8 hwWvYPAN6AHVvABdOl93Akp9B2OOGxjJsmJJMkm4EP6aavSZEPqMjOfX7fXpszmOz3uwG1agg1tL /G6IfUvsw6uyYU1g6RwUOgEZU3i8ANYZCJtb4soQo8CdLp2wCs3piMfKn311AJE65okMx14BPtO1 iZg/n3sA6RXMgMFypjByArNcweCFP3gFqpvg7hr7NjaBgYu11IptludcJ+GESbNIq80izl1a0NYs AjbHcRu4tTngOyptoUAhC9Be6Lba+1nuh8MzmMIE4uISbY1BlLRQfQc43asfO93nMvCju+bSL8X4 KvdolBb7uqvBLSNwM7K0bI+bz+Y4RkHqMAFDvod9Z9X4aInXoALUZ9miH+HxONDeCMRfgX2gPh9B n/cwhvmDZ2vx/ULyNATsxyVIlzAYZeB+LLr7DesPGIhrYeCCJmCHt4XNTWZRnpJrAM4JgFPN07g9 wD6b4whzCW+Lefocw5gRQFG2ao4uC3PhhY+0e3UEcF6D0lDfu9Ngp+GHALOhj9kENh0DT3EHUq9L Nlh0G/WLYjBXL05VYCtjHgX6rcFWRAS4iRGWtQfXZ3McGKdGsFfvQWFVoVEIyVXqywoXEo5NuVbh 2HOwHqfNWz8+TwN3invz0BLnhjiGJ++DvVmI6D6q9tVDANawFBpwk45g2zqtfC1ZTxC3zws7evN+ AQp1HBrsHg184ZZZYSLC2EZerdmyiQjCROLYqr61ifhs2/1/6Wu2IutHYCbgeIcALgZV3HwYOZcl zRFeehg4VgY+oiwVvQqylr00ho1VMAZjGToT3O2PwTwqw/Q6vfI0WQcjUQzHJrlM29egAZvjaBJR UVnoFiqqwfY7klclz8YtCunPt05ZRNUfq4RHeSMpRNkfy4SrRnmxIOrPWCQ8gSxtgJ7nK2yJgkco hsWw6VVb6QmdcRl+k545UenFzZJLQVQFOk+5ap98BGyOQ6xtx8vNTwN9YF0+BneEfZCyN+Yg45kJ f4rPRzxlQo5V0dmlp+Q6hIn6QWcpT3ZlIFUAC/NRGbKtOWiL2I6/WLciA2MYwE5yvuza91wO+jkQ M997/28MW2Pw9UsbA1Fr6DTjUfteW8DmOFQJ4foOedlFYrK/8aVYFpYb8BgVMXPA+LWs0uxPhrCu QXir5LqWPFFw6CTjqn0aErA5Dl1C+D3ANIONint4Vtixz6O1F7eHkxqEt0quQ5ioF3Sc8SRvj7DP 5jjiEsKHsHVd4vMNXp31vGYt5uAH4Lfna7vo1/YAW2q2qlUubG/NW051aLJtdSnCsT+TvaQ19lK1 xrK9EIWJNhln3r6BGLA5jqRkLy7FOwA3fQCvsDeERWJQ6W3KtZ1msvTF/wIeIatBeKvkOoSJakqr nMv2rf2AzXGkJYTD5gm2brE8f6Qw73ttGzyj/9eYvzCEt0quQ5iodLXM+ROCusflGLISvgfgtr8B dg7EHz2v+HUbd9Yr53H9Qov3l4zpdfiijuvgJVoQWuQ8b98CDNgcR14CGNNyPLXEA5QbwB77qv/J pC2vAXir5DqEiVaNFkbYtnwDPbAtVLsnkSWm6iuwI8jlnstHcKxYZoc+93vPP5HG6w9T30tjkVZf YL18bANUKGypHloU8UQ8HVufHbEtt1CwnxaWy7tA7ntdy6Yg10fgF4ZtiAqFLdE9U7m9V9naMwds jsMF2tued8Ds3O8YQHuAZR2UFmpTK9fVxyOOWQCavbaFvTP35PNer3i1DA/JmB8CrmHMxmbIMspb 1MX2rM0Kxoadizb2RtQRPDkJVon3qO6A/baHKWW/0ATaLIC8gRbMiUaZaIupTHCZUzu4NVHV/Vf2 nlfwPauBe9DkHFVB1NLbC0ovNvK60BXRO7iACnW/lGiIqVTwWD7ZOwfsB7DycuR1Bn/Z885CcZMW D+uIj4pU8SwJP1p5HTrN7T2FYGwEc/uFkrRGphKCTJkK0VlT5v+s/WFYwLZ19nhgjUfY1um5XOqV 7+zH4CHDm014IPvM5dVLRXir5DqEiV6YiiVvZiZEu0XZa++NKgJFlPTKXnxvVDkqonJUUtkw2EQK UZ0oe++4URRVRB6sItV0RUTGJXNt8W4ihYjo0t7Ma2Qumogd0t4Ba1QfaMKtyCTmotlPHAjTlfaW SiPtasJ27RXohisibFeqhItG9qIJ25UyaboiwnalSOxdrCZSCNuVUWpPFZpIIWxX2BP7ZtolbFdk KW/UMYwJ0xX2NLHZTzMI07W/Hmu2oJgwXRFnPG3kpGLCdIXOm66IMF2hcq7AXM7WEXcTmjH+DiF8 zyH/fg2hCn/F4MIdXpsLUsEdSab9tcgDlDvhuTj23c7hyW3PuxN5DZXBZpp+yFT+zIo//2pVsVS+ v7DEGegEm8D4wS901A60XcLsHwvOAHENCmVuZHN0cmVhbQ0KZW5kb2JqDQoxOCAwIG9iag0KPDwv VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgNyAw IFIvRjMgOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4v TWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMTkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91 cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAyPj4N CmVuZG9iag0KMTkgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDc5MT4+DQpz dHJlYW0NCnictRxrb9w28rsB/wchX7oquqokUq9ecUCatL0c+o6L4uDmw2a9dnzx2q7Xjq///jgU Z3ZGIimtm6KoQ3HJITkznBeHTD7/Kfnyy8+/f/HqZZL/85/JVy9fJHnW6S65OD7SWmd5kzQqa3Kd FHWb6SKpTWVZJ3eb46PzT4+Pkq+/f5EkDErhoHx1cnz0+TdF0mZVVyYn58dHRZKb/wyEIsvzNqmr Miuq5GR7fJTDaHny7fHR6eJVuiwX1/DnPm0XGyjcmYKt2ZjCffomOfn38dHXBj6MgVCL3IArOdTT xTLYtsmKVrZ9iSOtoHBuRzKFxBSSUGHq93bxAgrfmsIPWPMLLuQPKDyYwiWObBe7xd8JB7sZ40wX htXfQ2FlCndQWJvCO/yphEJuCgUUigAStcqzcoDwhLUdcUbJOGPIC7rMZsFQERiqzFo1B4iOAClV VtQOiF1+JjD3ihPGYu7GFM6QlGv86RJ/ug6xoFZZXsrxopOuIpMuVFYVc4DUESC52ebaAjESIC/b NjlZG3BJElhBU2day262x2+w9EvcP+8Qc/fIYRus2WHNDeLyHrffBe6GBH8/RzJY+fCTKXyAgkZg KyTDGQLb4NbZITAofEZQaYoJ0muHwKDr/6Bwi13X2HiD4yR8hat+9q56KxZF6wXeeY2z34V2VaGz puNonSBpEyZp1Vn5fShJRTfbY4sY/hOX+Ig1Qf4uykw1HNapJS/xwg2CukXxZ2s+IDHOBO5WnGlI KXxAOq5F40fOancDOHxU2LJvoXCFo645sX7CCWnstUIOOxMym9iMhr9B8FfYw/701vaIUl5gLEr5 lvR1qyr3t0jujCotS0NulVRtkXWt1YxV0mV1U4bVdhdho1Znutwr6jAvjY2B3APWcdkequOyndhN hFyBPGJAYkkrjf/k7PHQN3ZfawR2uSeAqyHF+vsiuojCswhCMa3i1E7nCscl/n7fGzSu5hG/iK1p FtZEeG4KJyjZdF+Izc2nVFVpCK7l3DiZ8qzQySP8m+fKGGf4b5H8YkywpEz+nZjyfxPLR2Xb81GZ bHvGKgyPtmWWF8nV8dHr46Oe2/rKosBWUNHlWTNsZOpabAOgzXfXYSOYuGbD2YUMRoO6mg3mvtlY YySh1cAat9hXyzn4+L8xGxMN1W8PlKX7vqeL01eBtm2d1a0YyG2JkAHbFVlrdrOA/tIwTCb06iWK P2KzFfLjZdAsabMB3KARXalM1bLttdCFXhYWIAyHFjNHa7us7GTbS1zWbaBTmeusnrmcMu+yppVt CZNkJ/fqPwBB51mlZo6mq9HMhsrF/HkDwintzVBmu3+Nc1oLE4sJP4eYNc77EjUdCT+ygUj+rBDG Dn+6QGHlBHHUERBriWuFiAFe1VVm/jnYZuHdbA+p6UkBfNhzKJmYEb3ukPGZaHjNbUAaR4rvBNts wnYK4fkerQU5szNOpuuR0Umztybxa2uw+HGkKuO61xxJY9EPdoNfIZwuPgnBrVVWVwIu8+TJICIO ukfLkYzj9yGegt2oOOShCvPNn9ZppLz5x/j42rRQ5i/aPXZ+RnBZcds3y41GMMaRbiMxjYjzVVVV ptUc68jDtfu+jmvvkf+I0XZon0reIOS+HSF3gzXEMrO3gODsoIk8c9OQA5aF2MfZKXssTAmOiP9a GYnazPKki5jLpGowUw4WP7yb7XGCu1R6lkLgXuNWIM/xHmskaROU5TeCKy65jGHqaSiZdgj1Cil6 33dfYozCO/zf5bEHmKHr7N7dY3KKjG2EjGWdqcODGaLbXovM43Gmn18haoY0Xx7oyRIJVpxL1lhz 7WcOgiG3+1vkAPKWGIO57udIuI1YL2kicnGIby483Bi3E/ZInqJwzCktjM38hNgG72Z73IxY/Q6p Q1p/h/tG2lvCe3Nc7hBei64ElaIb65Ecpy2V8M180Y/MVcAdn9lDT/PAljKOfy7WHDZIVd5Y4vC2 P5gBnsMAJyM+8IVHJE8HhmnarKvlMGPeDykMbez5arCgeMjZF39ADnpKaEzGxV4j4Sho7wv0cU64 51QcBhS54Dzn0uESd/bFDI4cEsLLdol3H0uhcI5C4Y73cubnUOtQ5Iu8CDehuH03L9JV+iIwjoy6 azJVHUxJ0U2Gn24EfVaIdlrlvHD0TL3xmVe3PuKWkKQZxpt9inoY7xzWUHz8cq92htx1LgQSk1VR YjKUTtEzchSk28ZY54fTk3eLCfZx3P7ai8chUT4GT4yPKLw8ERJ/ZVdAhJgtdQrPkeMybSRxPuvQ qNTBQHNhjDYjkLVx0zoLuSrKqUhzGXGmdN1CTOkpoebS5xs43thDjVvnZ7j716hatyn5UswAOxPk CkSYe6ixGfv8EMIoTfl0D5JYlgT6TXQAn4VcqgoOZjimD4oFPERH9FlsLi42pK2LEpCzezWFL+VT 5iVwTiXxRQIveMQ+JCpxgN/gXpEm3UxO0qeqVKOyTs5RHIG5yFwMrDfO37tMAu50kAQZoDHWeAFB knoYI/FS3u51kD5mr7cVRM+hou4rugrD87bS1NVgeWIjM5jOaj1oA/FChW0Asqkww+GBQZ3D1344 S+liMBxUFgUbDyvEgKyyHxGB8xF5aMgJNBcaikkzFROxVQsIkhx/kFLbA3CCy7Lt/1IXnNmkLOVA GuhCIZG+uxG24dBYjQXp2VQmg/SirfBMKbx1gzv+amADj+OoblUbvyG7S9tBisb3+NMmpUBH0JCS 8p8wcy/RGD2wFauNy4ZI3FvrFljxYLOHd7M9/oLwe8TGRJgEsUZQyfKUkQRC8XrUmLHb0HtIcDA7 6ntsSDXEspRk48u64NF0ClfOOfoNhbV10cG5OcPtFGFjJo0ye+JwT1N024eibnHri4wFQoQM6U0R 9jylAII/dWnpy9C45XgkLgjarE4/75czhctIjFeXoDjmAImEeC111eEE4d1sD8rkI2dvnFkgncpQ QggSBIwOyqyRbpuQ57dYQxGEa0G9lSAzxR/pfHDDpxjYTlusoT1OkyKhSdv6EWE4yRIN8TJMTpEx EuLVhU0gGEMRbeusAD2/bytJPkFx1iuQoTL0nUPJUA2ccDCAh9jcfMqr4BCldQr5EMzksH2nUp6m YhbMUnVc88hVLYmLYWrOchCymi2fRUz9NY4TCi+7w78gX/hRjqTJG0gehb66jZwZunZzDMNI8Frn BkDxtDND1nc6o4Q1TmZllAjolFEiIoGhNIACcmsGEIKGouNW3jaY/hVKPzHkrmYOB+fUhWw7xe3M aAxoNmP+tc28CbhsMdE2IpbfIOPLQJwIPVAgihT7nLNWMYN4knQkdK4gY2rWEY6ORG5VW4C3cKgi Ft0+RjTnLQomh0nXlWTeA1o95MYkWEM6ms4wSM9Td5fw4Jjs/WiKxHZjcTiOzA6t+yXL8tqkbez2 AOOlgNlbVuBEM/xOETcSxlVNkVWH+zOim+1xIVZEYVw6Lzow9WYZDmMXjcramk/hsMhYUDU3ncXr Hu5pcJv2zjafAguVncLsfzFr+QYKL1J38taYQouFN1A4Td09k29SdwWlMgUFBduwjDesoJAj1Dfp 0MOG40Dy4XaEV8L7DaL7IcCRUX9a4GmGAndUqztIm/bl/BD+lc1Iz/K6b6G6xqvjHagZOl5Hgj/K /NtWT9PxrC+3PMm+Z25c6/ELyeQi+SFjm1JMjgM0dP3hfkT631JffPScRBzNjE6x2FGg73CKDkQu xQrJ/3Sh4VD+WZs1BUfXlMSKRGBUVWZPEFis11+Iv9CB/jADiONrlw5d/R0i/zL1BQDHiT23fc3S 51DSFD9wKjwIIhLU6eQus5tKjtUp0kRiKAquh8272hWJHii4IDYrfKAj4QNVKoib91DKHgND4Uhu zBZpQ6letDmsXvszpAZUAy6yGCs+44inrOB62DxrLeKzqFwh9g7aH7ybtNZIabxHhpLXi8juFdbY MyhAjPdXKLxGlNtqOkx/lroLjr+m7b6N/QmSWn4M97La0OZX/4xjvNpXt/010Wd8xz7r59Eu/oVW yHdQ+M4DPtgwOLNogJLhduryYMSYLzsNmT+HElZ0sz3k+n5E9H03A2vjxgfQylkuPyLNgTm+xu4v B4TzcgnQ4j+jKY4zYp/hOD/hpF71NW6w54LwUQ0cMYN6M5zhd4q4ER+rhDtAh2fHiG62xxzDLqDm fUedQ/SQ3WG7CtdqfO1SphgxH2rpv/HAukp6jM1fsIzdred20UHhTVTJ9QYIQ9cUrSIuUwnHk7Py OqqI3VnWxgY+PLwtus0Ob8tQTYIF3wHlkBLBVGdnlqy4+rzCAg3ozjWWvqvGY7JCDk4DhRYLFGKh QCVZTuMLFpI7t7HN22coMmxOkTJikZaQGH+4yhXd9pt3kzJb8dpPD1o10VTEYJ3q5pubQoNjy39w 7BqIjCkbrmVzPszpjvoQbq9700vEJNo6a8QcmNctnqHYCkFCMughwhIKbDkB/dQrk4Z0YCNMp3Q4 JCrIkKgMF5RxF9e1HLu4Pi6EixXsSIF0wTIaWfsiZNr2b28wqFM7JOIYlKqGu6xzoEQcg7Ksn7TP eDfb44VQgBTK6yVH6GjI3pNnsCJh7P6sQrT9FkeSUjqQSPH7Ih2+SfJ7akpfYJ/gDulvR7KhDzrB WppvYDNA0vPgGH2QnI8xPMISGenB1BAun25RLNF1SbH35pxnrQh98y5Ysmg9MyFDdyIqCLYKks7Y 70gNDW+I0KGVztu89O/3vuWMkFYVcX3LooYAHZMECaGG/N8YF7lDJgbn1JN0K95Y8T0A5JWbMpVX pOB/ImR19DYixbsc1OdYGD/kc/hVPcoLDqYDj18siTqAApFx8ReJD5RGIud76/VJFOUgfBYVu4hO qSm3AvfBd536cz4xwsQ5n2grk1fIF6Go5xWXFDLNm+7okbvDzqg5Ydn93GjmNpvYYVbO0CQNWBpG l5RyFGbH3AopSMlW4oxon54l4ruXMQIpSPorhlw0KcIQI20GfzPd1XGLBa7yzxJgkRhWATcU2r8u wBicU3k4LrN3ziJmYdFHIwWo4AlSHw4UbVdC/dzsRcfQjiR74K3Yb8Khkz5Y5CbxGGrAhR/Y3Uuf o0W+YrBrNI8oiLrxs1eR8FfRNlnzl4Qfh0B+E6VgbdOJQLnLhZDziC0mEu4p4FLHrIhgHQlEwEt/ DLEBnMhC1NgXAH9ANiSqRzLvPfmifn/sGW4HihCQWRa9kOge4hAzDGZxVPBujGhKubHS/H6Gk6V8 FmF+yKtJvvRkipgtWR4DRcajr6tFLYYBaWMMEokxgU5uio/JIBwgHZyR/CC/ng4I6LJyIGJz0GMc /xhJN/mem/T1r3Ac8UakDGed8V6U17EhqJQpQgZrLNFcdTpTQ6THSBeJKRW6myshIn53obpM+QzP P8JJjPCq1Kl9esr+eWNqkrPkSNclOLUVhGDsPQ+tjTXQ4ONl/d2Mn58EWQDauuee9Ajy+Fpbnz8Q fiELRqSJ10Zu29eqqKKGa5C6to8ywgsmJVy30lnb4tf6+KjO7S14V3EFFSD/3XdtzKKmRlD0ZUey nfsKsLz6vv13l2cVdLaQjHaqoW8/Tv+1hln2M+krrqCin2hfgYvoQRFxYKD18WDNpvM7w6lohf3R A4f3wcy8AVvamDjGOTB/jQUPFttvnybXpjXnMozLYO+2761E75b1Bnb8/JsyqbOqkg/L2ltAgBYF ZB7avy/6bVYtttu0QLvmPi2s8FKL07RZvDwp0yJfvDHFL1ItGLvnwENmqDwzrCBHsgnN8IdeKmgj I4pikRg52Bg52BlpYT5t3cZ4pxXkLS9hdgWcOi1rJ+cKvdCmsYbfoJDYQ6bk3hTfmf83H381iO+m huDCOG4KE74zGhpQ/GgQb6dxndaLZAXLuE5LzdZrf71LzIpaz4rcah4MaXYbWPkZ4eAtlP6EFcPX xsJev4Nh/rYVGy3K83fxwaMH4B47nd367pLmtrn7LOU4sPTsZ7hdAe/Zyd8Aue9S1S9ju7J594At xhJ7kAms8j4tKyQuLPrj82sDdaH1rnYW4dnHH7aFEHZo2AFZf/bprmYvVfC1w4jygbuQdceUj7v/ J5VPBIzohfcLqxEYGq+yGWZ7naErENlOEuuq7iWxFdTua68yXAWpDPftdEAPiT7sOHuNoRsF875i FTqrnMbQTZVVLWoM97XXGK5irzFcBeEQINGHHWd9PFhxUGPAJTpVIKsUVabzoMZoRxrD9hadD1IY upZhgUMUhpqlMOZMMKIvAhPszzhf7JILM74RrCXI21V/EGekhZUqD0aA7DZWYYBQ3W56ubR2Erj7 +HNGpBqKd77r3mqx6r0VK+6xuLJ64SuYFTRxKm/pSrt3gOZkdwsyckMrvIQGsIgL8//uoyNftX13 70ICUuj/u1UbBQ0KZW5kc3RyZWFtDQplbmRvYmoNCjIwIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFy ZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAgUi9GMyA5IDAgUi9G NCAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVk aWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMjEgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAzPj4NCmVu ZG9iag0KMjEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDgxND4+DQpzdHJl YW0NCnic1Rzbbty28t2A/4E4L8dqsop40a0oDORapEAKp3HRByMPm/Xaceu1U6+dNAf9+DNDcihS Erlax7mhaExxyZnhzHAu1FDswQH76acHLx4/f8KK/X326MljVuStatnp7o5SKi9qVsu8LhTjVZMr ziroFBW7Wu7unPywu8OevnjMmAeFWyiPDnd3HjzjrMnLVrDDk90dzgr4DyDwvCgaVpUi5yU7XO3u FIitYD/v7hztHWQzsbfEf66yBv7XT83eHBs30DjHxjU07mODQWNJPQwbcxqTUw/rGv7TU2j8g413 0DgjhBrYmsa8oh4cc020rLDxhn66IqgcG9KnTGCjoJ949pod/rK78xQ4g9whfkguctH6/DgaEJ5o RLojuJo2FzzEdYQTDojHp7QuhCWx8ToCS8kiF6JPdzd2oBrCU42+MiiRE4zniPSChOpU4YLYfx2h hxdAiAhAzaJD65yHWJ8QHs2FE5L3bVjvNR5j42do/Eo9v9Ey/iaNDnVvRb87Dqyn68IWtL6gzaL1 dwGNt9upLYnf42FS+jIhfSnyRk4BohJAhMx5NQVImQDCZV7ycBNu4mxaxXyAZ0bADZgTaJx3IreN i5R2lzKXlQ+vAIol2Fb6y9nV6Vjvb9quLqNwwayXIZ2XsbGVzCse0OBZ7isynXnAoN9oT12Tji1J 6+7TmDN/u50FJlh3X9KTs7o48IZ4dhxAXRMwnHWJjWPfOaydVOcdDjvwHTXOqXFKBC1oGecb9kOo Qd3YcXE5sYL+VazMi6aBEbJRzsM6AZU4sEQdDwdoGQCYqkF1A+9dw4CKtXldNXE/XSU2QQEeX3Xy vaOd0EE96ozfnLh9Rmb3LBDmj4EevPXFr03qQ2gcUo/Tg/ekVAvqcWrmrKndg1YP3MDjQA0vfM25 oJ+eU2ygg5X/+lCtl7JK9YHUUK/lrwGw45guFSA9GbIsadLquDTLVkdxd2fSAoDXgdu8IFbENgmX dd7KEIQzDmHsNRR4iAt15SSQM6NNe0Iw3H524J1XPSNBnJMGfiQYq0BGHwnYmkzOG1rlgiR7Ftim K/o938RRElGjciVuYdQPDY+skq2N7o2jaiptIDxUR6DCdhe+ofUtiP6xFUVEqmReiGANnlPYbAEd YTxv4U+VS9E3gY5NVS5qJkqYoEfIth21ghaWsYJVLeJWsEnsm1rldXnXVtCDemQkNyd75cyUM4cr ajj1ddbpksTCaN9d0k8L0gen61fUcx5Mf5/1U5jhngsDWOewPwx8uUvSIhv4Y+Y524+0Ofuu1ZL4 Me1jAyYm7WKbkG+F3vYu7aIPMCLaE7Ih5740rMRmFAFa0bpIhJH83gcsZ8S3cW+4ycE5hE4sTqIu JXFW1Ml45ezd2jfZeTThBEtf9pmdkBgvEiIry1xNyhM4d4cZjSztvzbiAoo4K8FqSc4ExEu83WQl eCJzLVUJgVZnJtC6CbBBhwsgkaWJHEuJ6ipXyocKvQjrGbm6UzLaV4Fm8YGbWvmuzLqpFDVjuZUN Pv1FbuWg/pfEOJaI2RzDw3gUuJ4hlLFIFg+r6nYgHOuUll3ElgI8FlSR9njUDY2md1RhbaUz138F pvaStukw6XDRiBeHpogd82QSDBOaS59aZ7ld2PSWNOcxNH7Gxq/Ukwio0zIZs7sSgj4ZEjMlP7IK qLfrSPbj9KXWf8AQq35+lHPFPsR0lAn2C4P2n0xbBtloXKJkK2MqRGWQl+x8d+fV7o6xH6YTNqod hR2lyAvVH4WHY9KHBR1S2FFBzGJWOCFmEUXUtpFNkpCD1qzkmDFCJqFUAhpP2DZZ5UXb2z5bGDgx ZjetgetAWwPnEnAXcXqJQQrJmBXlHNhc+1iOAhc1hDJq/XiN/iaAklZZ1KgdRC6UlkKlRY/ESP1c O/2APmX6GhqDzwqGtnbQkEgymP5w5eYjTuiA4NjMH5OogPiaUvtBgD5EmDglKDkE7lvmlXdzdLlF YzwoEbLU2uGvIBbACFVoToerTfEslYtvm4h/Ywxz5P+4gVvFNFYl0i/V1mh0v2NuBSv4dwr2537S Nv3FhwQzJQccS/E9kRappkYL8ln4njzZDhDnmT1Gtv80t2ggTsf2/phbQ/UaEWngeYjs8zH1YiSR 8ai6yYst30d8Y7vAX8HEXRAB2PC8VCFAfYJ1QDMvsiZ+9hqRlhR5PeBzSlqJeElB1iGr71pa/gr+ TRv53mpTPEvkzwoC/Kr9rnnmr2ATz8LVpniWeF+qVJO34pviWWTVXOVN7dPrZw/37sWmiRLf5AfT 9IwZIpsB1n4jAqcs86YK2XUPJ9wLqHeVIEO3614QsKx/zonZ+irqA5reAjZJO/FiW8kWj72/gkf2 EW/vOwP/q3EODxjcT/9+AY8c8jEljUSFgBKQnn9HW8+Ru9XO82Z9ysbzeDWy7xLh7ifuu0BGKUEn 8lvFW3xV2WddeOQxPNgIppkZX9uNpUXd0RuNz6JOzYrZB5HmdyI3VrzIxWdKPD4zBz3Cb8vBYO0p DqZS5qLAM9DvkIM+4VEORpKF5u6SgJB/KSkkEmjZYgHtV3DXAeJPSHUDv+1+CoXwBRLoHh9TRYGJ BFpC0ii+0fQiuScCwiftCYyu9Iu/oADO1ZO6V8bvyNO64sP+69yIXEDNxICjKbkkUmVZQzL/FVKY yA7Sb/U8miYFS7zV74uCabeKlqzEfZbYcMlbju1J+pEAhMU5JCV2vFLldbCYGTAB30SlI8a26mF2 YU9KNRInAhL+Nl/h5DepGj5Nw6TmABuYRvLY/hymQtZnPcWGiA90r5EXWaLKQtR5JfqcS/E/cbog S5F/azvTkbTVxvRmfcq+9Phxy23pQbjdruxWstWm7DMgrROJMwiJVf7TKvQTuTPGWc2XS54jylFL zRuflinFNT8SiuGdjn69x2ys6HdDkXms5I22dsi6lAASOa0UEq//TIGSyNQklrhPi8wS2YosZLci fdFoeG9AxyN/U1xzlvXr0MbvyZwEAnBGul/aYsG/z7wyxGQARPbAJzy9/ESaIMBGiUlng2UivBVY dVtufUgRTNMz/sCFYyWQK7rQXDrxdfWc+PqB4kVGYnG8nzuWuypWF46yrF+ffbWdjH2sjjJXpril jF22Yyk7JA6E5arzrG8MzjRBkQJVUJEi4O8m4cYLFe0JnqgFvtbleL0JS4NU4lJHmQirBBbNNrcq VCzjhYoeVKtJc+L8MTHrmhrDilNXtOyK6C5JOksnHSfqm8zdmwhk0bP2Q/rHPJtjb8eWrUob3b2C sA6a0cpxoywM1bPBHS9fk13BZnAJz6ulTq1szNtKvGRRDwRuC36OMnsJ8Rn5MoX/1PDUUOM1Nu4n EY95GXu71EM8pcTPCaLKK9JzU91fezV8o5VWgmuLjFsEUtLVru4opNkzVEalEbSm0xRLUQdkskXT HwWdvCZYCLzRZXR2FPK2UR5GaW60hBilbIgMg5E6Aoxep8FIwH2Mfo2gNQW2RjBpCBLuW1Ql1iRO reob2fMdALvnj8hhPyNDXGJDkk6JTqc8sxpuZU8vfRglNApsNAQjWqlVKIyUPOo22d5EdIKRu5p2 mzTl5LHYtdnePfvT9AzNGEwwX0YmtpD5QVbgzYzffobkoAX9CsbqxNVdtkMD9DAe7+q7w79n9uTV XTiI3HkIrs79Bxt4aHsQGDrnL7w7+L6NdDGzu8XiLP8pQUVgbwhzSItxPrFjrQYl7XFjOz9wE4OL hcllADe4LGtXdqkD1uTliUBQm+2pWxAkDpVXER3YU9+qKH18PMGqVKlIVFZYZz3lulRagzs4RyBX qyjzrH9P/pjEHjMH9qphAC+5kavEcaUQ1URzUIloQGdr2dHRiJpxrkuONpRnV4mDGsErvORwm4iu GouIrPHpoB7t/XKThDIWfdj7fB4Ya8PWFDCFV33d7S/3k7u75tmjFBWjF0CI195iutuSQcoS3jd3 l8Jd2uKuYmHodjoI9my2aQeukpSOeWWMe3C7+pSm1zvmtmxxXAAlzLXQPevDxpdJ4KM3N8wXSgLg sxSUesxQYJmqqkMo7uDzJPOuKa6ItzauCIPVBkJUGw/oxussPBgdUjO2sRVEC32GTantB72q9RaW XNfdY0GXfu6ufkBXafKLkobgMwS2RdsfhNFuS6Nq/Sy7kLTG27AeNq0rIkSHfaXo0NGzj27IErJS /nBDCCH1KRkzPkWNvmnqTYI6Ycd4q+uXNxwLJr1GAOLXrH/rO8gwwxMOl8F5NmG29cmEZzzeUbzi wpQunmE+jFOacUX+7Jx+CoOfS7IywTK6/Nhd8XWR1jpz98rsT7HacfulgZ4IUoJMnBLzps43Fqql 5ehBeOebBPc+091uHn7k6TkZaeZM8nh+Hp7QHhPDg+QkcqSkBX9DM5zgXY+LegPMzqHMDQxPLXVj SvWhXt3BBjEGAkhJMXFKz7EWeuMpfVqMPog5xfbHvvaHKr4i3rwjzfXi+9DR9i8/Bzep1wPwYUTh uXn7tA4U6ywLrp3NvPz0Q/SAXqAjCZbsLu2745yRbTuuD+66p/vc2BX1TPn8TE94KRVIvCfA67Of apF9ENMSvv42fJP1rZzbUO527CFt04NgKianT8yG8b7H9pwGvzA/+TPW5DScNALP4FJN91L2nGYt AzjhmbSzJK7M4p/QqkeECc4copKeGFLCTJz36MhiY1lYWpg+iOPMC+FPAi0desQxIz4zQb97r2C/ lZJ8l9tbRIoViVMdrtqpuyNxqsNli2d9Qyh/Ry8ZF3jJ+EjfRNb/vIYedsx2VGWvgTb2MrHCewI1 3eA10dfLW0EOAGGASVdiQ8jDNNXcno5fmEaMjnCIoqW+5Oo6RN62TFX6K1hlwbGGS1UqxyvO5mmx u1MV+hqq7TjHDnRc9rkqGrwibkG5J41JTzYdsMCmNZNtB2Qp+NEkDcpcpyZE5mmBZBpSTMc5dhhK TQetwoByTxrTYre3apj9FpSV0va/DXSIossCYML2BSgN1vXAHip1iv/HD+wCRvsfoKFMiWY3Y7OF NxsV8sEzwSBsL8MPa6qq0h8RkyPnu0cme7rMyr3VKuP0MuI649ocSEi16r0nhyrjBSRUNaTeKlBt o4PbUChHKCzBV1Z1jMKH2nq0aBgU2ArOwfy2e8srZt8UKYwMlGmd48+6dQpjPsL/TAfwLOPS9COk JYN/TjLbcwWNu18TcR3f0/fvyh/pFXTrWXcLMM/3GbbNNxlwqRnXRM9Kf/1LPehMT2AXIBwNgKHo FjdZtbe+NsxoMTqFTuAY/vaO1rzEJ/OTAQIAQcxfgicFghnVxIOnsHYg5g1ScQO060WwD6Cg/qrn WkEfQ489ga722BplvLx6j4tYrr1hAKvWsFD2C+xCUOwSu1EL2AI5iwM8li2v1p/GAJVgANjcavD9 kZ+Kony438Af9Wi/xSexP1Pwt5DQVe9XXlfJ9YhH1b7Ep3qfczsQ2giiLM0vjYFUhYNUsz8rEZGC /yvbNkg1DMBSe3DtT6pBuBaCCggB8mgyDK5oMDfNqsNYyH0usK/dn/GCSHgc0Mw7bJX5H2bN8CcY qAkyfQMqYNjnUtmixI9/9FXW7Jv1Df5Z5ne/X5pCu79R3D3tfDn2GTPeeRH63Eki3BB1bb9KYqME +2IxDDcSYIJZ9OJyCMbhg+CNe0GCKCvMVq3rxVdtVUlBgn3qggTb4YIE+2ydvgXlnhBRFyOIus3L xosRBDAaIhkLqREUIGCziw7wqQsN8IkIN9MdGzX0xW64zmhYIMoaYwyrHuAKWxkNC8QgLNCz/cn2 tcHEqEDUMm+HH22dFBWUk6KCKQQmgoIIga/eIjGX5CW03z++cxIUz3mMgrtfsNLXTSLotEPULpvN 0XstdARBvv2dC36W5ogCx5lSK7RQ2q3l2iWyhyBVdITHJlq440WQWsEfOXTx67cuwvCkhnS8gYBF h2WrS1QwHZ/g4/If+KFbnV7OwlQPYVxwbUOkuc4stUe3AR549BeI7HeMDV5lgu8d2tSbC4PTjyec 3/9sDAEb0A4/OdaFc6s7RwxmqBAxxFO8h9zOe/AWez3vYV5obus9zCx641ANwDh8YKxL6bsPsNm8 cu6j0J8WJNNtnjz3YTo692GeyR8YUO5JY/L8h+Do0D3/gXKpyH8IhYwnRObJ8yKmw3MkpoNWYUC5 J43J8yWGlrgzKbTjs+rC8cOIUWeihs4EZ6tg9lY5JtZGNbfMMatp3mQKhWOhN7mTUQohdpS1Dl2b sSjzcRdE830dtULgbcLXIKpWFOPCAGmj6icW1jAQJzRdKEwdVQerP7ifAED0zHmHNh4BT2JcyoCB psthIqtTL+1ulsdgqbucXOeac+w77h4XLoVF8z/XHzH9M2u83Esb+BPwaYW19XM35czl9mjiNSbw DmDxjSt4i02w59Ew/NYcKMEjCxXjQMSS/h+XL5D+DQplbmRzdHJlYW0NCmVuZG9iag0KMjIgMCBv YmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBS L0YyIDcgMCBSL0YzIDkgMCBSL0Y0IDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9J bWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyAyMyAwIFIv R3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9T dHJ1Y3RQYXJlbnRzIDQ+Pg0KZW5kb2JqDQoyMyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCA1MzkyPj4NCnN0cmVhbQ0KeJztPWtvHDeS3wXoPzT2y2oWnnaT7Oci0MKWH3GwSZzY i+Cg5MNYr+isV2bkOPn3xyJZ1VXdTc6MRg7ugENgDZtNFousYj3JTvb0bfbVV0+/PXrzIisOD7Pn L46yIu/KLrvY3yvLMi+arDF5U5SZqtu8VFltK3WdLc/2987/sb+Xvfz2KMsYFBWgPH+/v/f0lcra vOp09v58f09lhf3PQlB5UbRZXelcVdn76/29AkYrstf7e8cHb2dzfXAGf5az1v5zT+3BAgqfbOEK Cve28AQKmS2cYU0GhQW2ybEm6wv86aUt/AGFO1u4xAEdsBW2eYc10OYecbmGwgd8tUSoCgqGY6ah UOArNYFQohB9fwyFt7gmF4gHvCqh8Mvsl+z9N/t7Ly0FgAq47qUpcq35uh/bTn3bESk1I+WQeKXO EcYbGPQGiUCku8Hluo/gowqLiBag5tGmTa7kqC9wHLcK50ifhy0pFY6g8NoWvsOaH3EavyEHSl65 xve0AqvNabwxrtPLYpo272qxLN/iHnBseWILv8a4Mc0lDGaSSUyCSYzOW7MJkDIBRJtc1ZsAqRJA lMkr5YBY8Vbots3en1hwWWxlmzovS9nN9fgRJccPkY6dyttG855xru7qvDO1bOuI9E/OD8/ivPkO Cl/bwvdQ+A/8+bd9eoHvnRy8RIl1yfeIK/zKZccN8ndEvN3iPsuQ4/+Y3vMkgaHXHRRukR/Z9rB/ fj5AsEsnNSNM3lotVMlVSvJBneCDwuqykoBEhEKashzEWC78jhLpCtflBlcbav6EwhMc7m9IltOR ELnE1b7EV0vUTH9DTM/F2kKNE8WOT761T06V/jzD0e5RGCw4IyyENKOaFVIK0LsgCX+GyBJtz/rx p9ctLH3VOWPCqXtbYaxRgL8qW15M1f74Wm7Xo7cvk9uVDRG26wpp8wHndILTvRxweUTx6CavJfLM VsljvazgaxreS7Ls9ALgJFReV1mlcl3aBpb7ydailaxy6FTlpQEYpa3DJg67ylicW4RU5HXW5XXZ xm22Jr5jKrv7St3PfM3eaxOQmjJvqp32ngDxzLbPBYR/I1mvsSDU8Tpp+QHZOUPVeYv791zshE/I 8gvsddXvn8BVf8YF7ViOux13yuX0DRZWfhpzZuvcc6kZY0Fjec8M1zxBuC5BuLrK7c8GQFSRgFIB v+5Gfg7i+bbkd5YRMM1/CUIRWU5Qmt4I0Qv29SchI09xwAU2ZjVz7yvcIVeQ+CapeYlMRUKf5CgB GyoO++dPHONuncwybZdrNVzwFNlUgmxllTf1OrJtSkildG4aCfSe76YblNNjuyFMPlDiVuwE2qxX iS2hCysGu+GMUuuScIAqU+dFtxGUhIVc6To3u9kjAsTRaFM8Q0Y75ZviUvA6GWzEaOTBXorVB3f4 ayh8bwvrBOgd0mSFNCWVeyUaEhW3NFmHMlEaMIT0ZzR7LnGT/5p2fQZESZE24bdUqs7r5rE3Dge6 pQke3t8jNUiELQU1GDOwzSUX+TS1y2D+1XD6qUVM+G3VpPk0BpEw+cuuyU21tesnurke36DqX4ld RIpCLJPcYFP+3Fy73foaCt9xo2OBsn+diqItdTrjvppQNgss3MTIBU6oWKXjELQJW4cY5yOColFW iM4nGvyEo0sbVm5Ib9ZEtqCyBksn0UmTPmG7lq0z3neRrgLEasYcqPFafxBqmlTSda/hOXMAhS+w 6xZ+SmjMopvzmOkzHueLe/0RqmprQZZDeqSomvAjyqbNC7UbVTkI0lPT0lFqr4tZO3KEhyrsDLue 4GrTbnce+UusGRProt8sfI9Nk+4Fbr93I8V3L1D42GvayQ25SBuSgwVPka2jFEJrqvDXO7fabuy2 yUrrS3Qqa3WuLENYe8xSI+qW6oQ7UdZtbmrpl65lhfEIU5YvMkk/gt/6n3CHrHB/L1GckeVD+4ZE 9SevS+fMS7iasXzGDQILcdoUtlP2KC0sw3YheIn8ydVsbE1x1T/QRylMpmxaVCUcExqbZMlyxjyf pcDmFhG5wPcySkX2IclfSn4sk9hOmWml6kbYyhiNKrPP0bCUzr7JbPm/M8vZFaQxgLPbKrvedxWF 8axeZVf7e+/29xz/d1BZgyS83qcK66HX5bAVuO0GYQFwW2HHxlZ2oVsxIqy8Ho5odSgI3X7EUMFH HK8VWmO8ecAljMJxmdqZVQtult+Zr3cQ0j2cmOrNkGvO41IyNI6Y1Zb6YG4Mh7rF3SmNGpFSfCNk 6BnfZDJeQCL8HCdAGSRSJaRlSO9c49xukNEzAX4LSyGilK07bAkr5p7e9Ckru2yBKXZSyhzEww2a EEqYD3xCacescXKk9U5+8Eo8UXhmHLkhSS/sgnPBVBSNJ2plYi6A2V0yuDdY8xTlmqhexsU3TqRA SrZaq5ZTxpmxJkOzs1qeikYSpjTCcdqC2sRUCg0XyAIfPZ1T+c4po0QBQVqJW56EMmV4qK5zrieH kk4bgCra6yCNXjoSNjUIalth/VxP0xrVgV2+znhCd75VqCirvKqGrWxlXQZYDritaElNwXS1ZiO6 +evBiFBZlmxErOAjjlcGjRze3OOCo3BcpnhQWwaW+idFCRO3WVs7P2soNHZP6CKv9Lo8iknEg5y9 YfqdEQ9GjMFORUhCmKKHmspQj0FOyXLcYT1MmbseQ5lyvkNWW0AxgNT/9qx2aqJTIg/Zg83zPU7o 7VqIUyLOFI3bVxzkqjcjWEaWMlOkk/oQw3IwdkRsAPpgAFv2Lr192Lrd6/i9t0hbt8ehsqZWUKHr XJthK4icag7LVlRkt8L0ioaNCBWqG4zoFqFlI2IFH3F8ggTFMm/uccFROC6TG7SAfo+XoB7jOCX0 cR/T4LukrsdDTrmMIanNJxxJao/hTTl+Id3N4G2e7i4tcVqTSneXyqog06e7eROe7g6QQro7ZcCU KTFdWABq43x3mQhemw5OUu5kEwsQf13COxIq9pEGgdP/1cT4gDYpCie8HtNatt3IdyoTYWrTKBBM O/EJBzHOjP9/EnDrJOCAKCnSJtwhY3/btWdeNiV2SAIKoAOLIyxy1GCYJ3N/40ihz8lH5IFx8p6h s43ePI6eC9amGk3zJNa2tHa5ETgwVXY54gy3C6KpS0tzM6TZOjWGq1B1cE4KTsq0TkmZriENRDMy 1mCs4DirO7VV6ElFFkBtcG6rTJzaMZXONz+3VSVC7QaOAqOPsXkGVXT7QhnU7/DpPb6/QUpTgob4 XYiYj9iGjvf3GRISKBQRGEeQdtx3JA4p+HSJr+577JPZNLa+64ibON9j4Iz22vM9aeXDQSQzYckz lgNM4icrbSPR9hrJRQevSI5d+O3O5vIe9celoIkQeESB8UHAYJXPvcklL4uI6yORCDI1Pue2SlBR HDPKCNFhYZFKYWowzSSxRR0zSeKwk9EGEoE7MQkHQRud9sx0iHaclXpCg2+VkaNlJ16ZytPP2eE6 0hiJmD+ZoRRoOENeZzF9rmlp1PE2Ydy1JmmBFookSoq0iRNoBo7V7+ikcBDTh8wjKfEpGs5jyQwK jxPnZAKq2GMybU4rTWnEYSom4isU2m2ifoLbWTgxCoY4D4fLrJbobR9r/llvQyz3SiyKOMYvt9M6 b+vvs8ShnKKEEQesss4wosWrIDRurZ526OALo0cpOE+5gfdeJbx3UxgUd5unH6ZYuodzvLFcj/rm c+bDMNX0MEuCX6BhR4Gjh0zGh5QHvSLMVraORflC3IspkYKkUwzCUZP6NeVHoKriQ6XlWSLoon1q Yhd5JkCcobA4x1U74aT8XazEVDqKi0JBRloXanMpKCzUzPB6ZezsZQ0qQUwgdvnMOzui6Van0Bxq L3BC7/iE7kngiCNIyWx0OGs0IF+KCRJxGQ2XVna7aiJAfOFs9NYSILDFkFvCydHYQU8FRx3YvB7J W/enfsR6xbz1oBI4DsJbT+8VYW6F2fOFFXcqTgVNbtNnIAb8stblx6XUk2qNVqSGGzh5Uaf0HgDZ ROnFM/iqagF53Wg4MgsZ/LVxgyoRstJw3qfdUoWOR0hk8NkIx24T0HEZuX9iZyLma47J1ZMZelwl NvY1baOHHh+YOmmZPD1QT7ni4ci8wC2ZhaknDwJa4a+UhLJBGhAWpnHcY23La89OteemjjL5tq5S rtKyVWgEFa2Cm2GDVrZSNdiqcc+GDgXouoBDK/14bvJqMCBUKj4gVvABx8uCfg5v7lHBYTkuU8xf V5Br2vTsQJ0wRTVcv6q3jpqJbltdOWc91145F23dRyNEgE26ucmA/3xwReEOt8pWAf9hnidIc7Ih x3keumxNgkEmlshEJ/VBOvc8pp0aa4DKpUlTP2WGwiWz3a4eCBDTl+ToMGxEY7IgUxjTUYUcAIo7 ihBshsQ4E8tPZigbcD44Jkd0PEWCSStGnGiniy6u8dMRrsRK8tMB8cReB4QbrHyKfikL0tRw/ncT KInMntb1g2QA7/aokfM3ZJmPXTRxYeV6RNrxxwYomBIiCXN2kWmBZCWLec1+lrFQJhwCvy5x+N+R F4Opl2aGfiXXkTFlEqka7L2dNjMHsSZkNV7poWM23yzYKUTsSrQhybmc8YDCdAKQTsrKw62xgDTn NWcwgVvzd4EZZWkAxc9ivmBCxT4FEiIFA3qkqJpIkGk4jbSjk8hBrFkOV/hjxrILpJ7C90LmzGU8 66vDZhRx6J8EeJL3FE9l90nmLJRObuVyxkIX8eini1IO1ikZmxwsyHwQARoeCRmGZ+XUxceL1ic8 /M3BKLbjj14kUp4K7h/upr4FiKkQztRV3QjtM9yyl4KcN1xuXk8DoytIUxGLefgGTyT1NNYR40/U kI5nJth8kDQjaU9X9MkUHF6eTGY8BlRJ0TaR8VRtk6+9l50mLYPAjvEHAG9mbS/2fp5BiXJ4U2bc nF0IS14+GIZbx6luKshQ9JtJySQPyIxTcgLp/qbC9EEt4r4oCX0OQS5+ioKJdKSCC4m75awFCJGL /YwzWQpldzcbngmg+2mkuD+jVqQ1pmzBvVioW6QTNKYjdCc48oRxPSYGWYMZxyySY6AvkRDmUjHc zZgzEaREMmI2IEGKkInkI1y/2lXMchDL0ZKTnt3kEABj4rmODqzaMlfDcefsSy7C7ZFfchFuDxlR IfM8H3g7i1FXB+x8xDOXfJwTL0gD+HFuIR6Ad59ZG5AkRdhE8MNFfjbKTTcJJ1qV3aZMlnDllOkg sjSG8lv8SDdc7jx2N0Ddn19sTXaa7ZW1hk/qlE0BV+au4QupRV7SrWYfVvrhQZAFoGsfRIYD9API 4/CvDy3HL6rCiIR4pfLaXcWhigLMtrJ239YrS3/fuy5zOE/tn0729+rCfRAlVFxBBUjx8FwXrTv7 70HRkxvJdfYVjYH5XrEKqxCyAKmp8gq+zufH8U8ngKXHxFdcQYVH1FcQOQASPbhxTvYHc7adf7UM j9Hw3zxwuBZg8W6B1zRcgNPui5UQOP/pH9mNbcyZDD197Nz6zh3vrEvWG7jx6Sud1XlVyW/gulu5 QF6yaHgm5MjLgurg+nqmcG/fz5STj+bgeNYcvHjfzFRx8Ist/nNWCr72DLgNhmYCw8q2rZsYhl97 SVu6g7WZy8zYv50VVUodZFZyVVb0dAcLr4q6g5V/YSVZbQVvd3CWQZMjqHwNdRA4+FdmX2QZQH0z 03rHOZWJVa86uJE2mNNXRVE1h0rZ3/L5YQc/R4dzA9XKP750P4Xxb2rW4Xl96BrW4XV5OC+hR+2a tPCq9TBK+++Vq7E/HvpRD9b2q+DVs77xke/uUajqfkzoUOnDeTOBeGurqtCkdoO7ESuPFlQ51CoH X2n2Dru6qbwCEGINYMDyqwESfoZsbNvpsdmRSKenUofMIA3s6PhtdXbllaXdKfmj75DSiuhCxVAa cO8PU1qr7QUKfm4gpXZKK8m41vF3dqXWSUARvfA6ZTsCQ8PZpagariy0yjXpCl34rx54Ce2fmK7w Fb2u8M8o+x0kenDjMFVROkuEqYqyggPRqHVqpzeCSoIHpincM1MU7pnWz4GhJzcKUxQej7iisEhz PdHpmJ7oxnoi1Xe9ljDtg7VEu5mWWI9fSkdM4/fTo4/Wgi0UGQ20ysK5s6uZMl45LWcmaKTbWR3k QAYLBOdWvge98y5b3KO0WJyATvoI2upfbhV7VYRdHz6hlDoyBdyrmlBHR1Lmtr2ieH5YBwVRdb7o xa5XH6WT1zXK5/ZQg6yuTIBjRkrCSv9mPBLqvcbXWvBOVVArRfhMqgCHC+qNALHwmsbw8V95sA7O s8OKwSkJ8kDB2tpuY5XzMG5D4miDGQR5VgXUy+oT/HhbxrFQz4QDSwc40b04AyPHOnxKexiumytd YN8zy36PvHOsC9RE57KBpmqL7TSVcv+PCKaq3B36bTWV64QXeM0QCA5mugruBfd6ynTGu05OBVhX KG/JqQlPvaIKFaSownPQPAEUPbmRmKaCRITimkq1ufvMeBNuhquaVJV/YrrKVzBl5StoDR0oenIj newPZh3VVnDN0a4hs2pUFdFXrRrpK9e73sGvUQV8iehBGqvbSGNthGFKZ01j+NNs3rht+yf4It6v ubdFqPJ73qoS2wR8mit4du2cv/MBtIVTO5/IEXKBJuflvH3y+FPBxS4mj5GTyHFSaJlhcXFjdWEc 5erxVxy+YVXG0Jx/gfEa+DrO9HBukjDbO5j2VS+/vYfay+jzGTMi/HLdIF8Ax97hO9fIdb61704c ezi42c+Ww23L/MIueP4Emn0xHjDWF1F6NNvFqR36FDE9W60ef/y2gvBKZPzHJy58Q7LV0fnezLQS F+ceadSu8f3/qll2nVdOk+PdWT5j9u2j7x8I8f+Fk62UAkMmMp7j3jPacWc3jqM7X/AiC6xz48Xz FdlUZ8uVe6FxqSCi9B+re8D2f2tfKEjOmXhc4OHzaU0enc4mxpbeytjSjbOOemMrnATe0toKvfCs ZDUC049nYGK9vQU3CZoK7S0NwfEG7a3w1NtboYLsrfAc7KcAip4MRRVCRRcCwVjRumOdAVSr0diC Ym9paR/eQARbigGE7jSPjuLOfKZRG8sdYjXIIe4jqRELy4wsrHHfehsDC1Dr1MMMLAUGVgF7xFtZ Sdd2EzynzawanNoInmRmeWdprUv+2Mg1Lsw/iVw2hwRK2Rj/FZ6oK/bwsVt30WV6YSLi4X8AA5Au yw0KZW5kc3RyZWFtDQplbmRvYmoNCjI0IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBS L1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAgUi9GNCAxMSAwIFIvRjMgOSAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA2MTIgNzkyXSAvQ29udGVudHMgMjUgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KMjUg MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDQzMj4+DQpzdHJlYW0NCnicvRxr b9w28rsB/wehX2r1sopEUq8gMJA4D6S49PJw0R58+eB3fPUj2bXj5tAffxyKMzsjiVyt3QRBvBSX HA5nhvOkNnn4Jnn8+OHrnVfPknx7O3n6bCfJs9a0yenmhjEmy+uk1lmdm6SomswUSWU7VZXMjzc3 Tn7a3Eiev95JEgal8FCe7m5uPHxRJE1WtirZPdncKJLc/rMQiizPm6QqVVaUye7F5kYOq+XJy82N va036UxtHcOfedrY/+6p2dqHxo1tnEPj2jYeQCOxjWPsSaCxj2My7EmWDf703Db+hMYn2zjDBR2w BY55jz0w5hpxuYDGAX41R6gFNDTHTEEjx6+KEYQijeD3e9B4gzQ5RTzgqxIaH9IPye7PmxvPLQeA C0h3o/NMKU73PTtpOXbASsVY2WeeURnCeAWLXiITiHWXSK7rAD5FbhFRAtQsOLTOCrnqM1zHUeEE +XM3klJjBxovbeMX7HmH2/iMEihl5QK/JwospvN4DVxfo3A7eTu0jY8hMYuzn9Ewyn0d4b5WWaOn ADERIEpnRTUFSBkBUuisLAhIgMvjBGmLrKmVBPEC+QvH6kYwmiid4JhzVDU3yPVrIZR0HEifXCPb zric3OCY4wCmyuRZqSWmoaOiTJlVvV0douwsSLlmoel1kek+WSO8qSK8ya3hMFOA1GEgZets0AQg TQRIYzKjVknJ+o2AsjJNpuSav6P+fwSNP0MTrYWtWzlzTaPBGrTmj9B4hNbO6Ygf7wdVLXcCZ2J8 N7q0/kLVp32EgW2EgbXJ6vI7M5Cv+Y/Q0FJnupJjZxb+DOAHrZnns1ygsUbMa4+rzrB4NH9Hzc54 yLYSQs0rjfVQU2WZNVUfNWdg74LbSiS1rrO2XhNJbYmummkMQimUAhSRwiKPiGFVZvbj+4ohX/Ov oZPwF4fn7M8VZ44SzFF8cB8Y9dwF2BDq+2VPnDWSqDHWFBHWWME1+juzhq9J+94RrNmGxva6jT4w 33M3YEOox1NZI4kaY00kViitR1JXAdaMr98U1ocx/ZnfgIN8ASLPm/HDtVaDgL0cP1z3hDqfykFJ wRgHI/5+qassb7/z4eJr0r6fC9Y8hsbjdRsE7BdB1rsBG0L9MpU1kqgx1kSiqFJVmTbfmTV8zYBJ ivgL65ukuwEbQp2s9yRRY6yJxKZlUWVV/Z1Zw9dc31uIuHLrewtT/ML1FZokaow1kdC0zL83X2jB VZEEDZwcRjDQq3CxsVgx3PzdN6d0mel6wu4wGJm+O4xEGOj7c2pVGDIdPYxBVu4c5XZaEqOIpEJM W2d6WgwTyYWYps6qbxDDDBuTToeTSIHTCxgP+bFTaNykrAiQoI5/hMCH+dpP0HDpN8ioLYJprgq4 IhYOSqL1Rksjxzpt9xFxA7XnkniQNfwYEoTCsm9A/xgXIwkRUzdZPilBpyLxrLEaRHfeYZJnuWos XocWXhJiF1DNyGluhkuSQ0HlbTzXymaG6d1WWWsHibEl2hISK1d1oKqPyKcSNk46/gV/Xqc+g/4c ZeUZepPPEAYlZ/dTVkzYD4maFwD3/RfuXLieS4T6A64DPUfQ+ISODCDtqwZRJTOJal7PiLGvxLrH eDqoWnGEaF+m4TKNKQyYGQE4LnGRMN1YLKuVkURchjgIytefp6xANxfUhUP5AwI/wDEfSU98QRhX cSW1XNeelVy3KsHPIpmfjvW+cxXNmyDYNlOtgEt10GRmoVR2t3C65qFkfdG27jwuIfjzyEk4jqzf U5WDaisz+2gH6EZbK4ilXYeNlcCqAb5VWQFDqqS1AWUTrv+qSCbAWF+oVcutrhKkSEhqtCVevb7q 4tPcjJ/RyixQBzhZOMHGYcqqOWeo7S8H+mi3Uwh9XXSGlihBzZJgDxWLrvAIngoBhukn3YJ+4AV2 XyGKDtg7VDEh7asL5SRtufmIHrFmytRybIMrnXCLR9jsdUjYPy9QTxrbqKHRYOODbWSrjjjomkYg Kg7Ck8vQPFVm+Rh34/IViauNarNQzmqinmIQwAg8QY17hOyk2mDISymgzloJSMFgADxYLYY+Cyn9 Wa9gnSDrvrkmRVeKsPx7NKlqqqzmUNl9kvmoi/BL5xn4YzvmNHh/IeI0ZEIidlNR2o3LqRCuVaoa iaaLzJSgqyunqs24olY13O7oFDWcm7CijqQuTNGCNAlFfaczsISzJxlwgOpwgWJ0JJQb+U/klR2L 7w/41DkKX0BRU37iIx/jFTHXZhRknOLAi7Rfw9/n3lOCDt3xEpe4f8YpEtTBlWVmyccKNXgdOl66 1lkrpnVaMLiOjSLaHk6kLPxFnsBM8Dx6M+O6NpKNMUUObu69lC0HsY86DxhzjmeSLkFcYw8JGknl nATtc+pDurO0H4CCNniFKpPMIhnpvtT6Hqc/nnCNIy+LfEnZ3akF4nouBlN67Xa5oP3zx0AZvRqV /ND1EvTwJRtizIxlKXKre+53I0eAOOSMIrv0pzjEV+gpjQVsjvbMBlBkJ12zM9QBnzgzr8WJpwUl Ny4csKhp4ju6xLVj83Rew20tNnE9U/m/Fa4gRyhkrdAVZDgww0qSHT1uQX18ILwggPEHNsgNDsU9 RpeDTay2o56kum3AhFpDXJmeISXiKJeyo6ho3NR6QFNMbSQfp1u4bzs9JookhbR1FFS7dkwkpq2V zmEzV6ZzxNgKFhDh029LJcWtPwVMO2mDZ9nPOEeRIjeA1DiFcvIaHnz1ny003TdCPcsTTcseovYn VwVwpAu+ZBgOcPoVrviAVN8JInLGsf4inJehit+PX+MU5Izf41ze62506f96zxLCrdq6Gy3csbO+ aVWulGUdye7o2nqqak23cbjCWAYBJW65AjMN59x9lMyn7Bc4jF+h8QARoXvjTlXBdfH/pGIAsxYx dMeyFEhZjq4LJX5N/c2Y3ZVkGItOfR1FwKVcAt0OJhNHN0vPkBanAzN5hFs9QWElN4TlBpGNwvjK u96dvxLb0VjEYXID0Y3YkdTlhUluQ4YuUcnPiW3/N7HCXMJ1cifMRXKx6Tpy7TqKIjnf3Hi/ueFE vu06VTeoe67rrOmPgb4WIQFoSLovR1lWGL4cPLf95YBfLVvOP7PlhmRCV1mMbmkNicfYMbSfDb5Z 8fLufhiD0znVR6g7Se8thA9FrtNVSi9hhKqdDQSzYoX4aYi4nLq0ZnsSkJgdhnvxen3jyad9/4Ti JZ7Cw1Tkk7g2+Mr12SVJwhV+f8RPMkUvV7jgJ6ENKExhasFrUK+KQyFtk9UFJ9fe0ldcYINFZAHr 57UFBxNnecxf6tJr9wlVBAh6JQjod4tHRDo0dDIoe8DyCX5NenPmFnsucCD52VKhR5IT0jsiW0Ay t0jHgkfi7PGSIzNRjZ2NvdYwrJyd94zCSNzZY0PsbZJILVMrnan7xZ0CBJGMXImDtOmJLPmrjNp0 DIPUJkbJtMJBynLrf+BXFC95hs9Y7YDei6PlRSBM4MnCU8+hsOAkeNM8UA11q6JP8BjbYi4jvGmy 8v5anG0cxBHXtye437kgJ4XxvcSds1d8ccrpHvMZBOyLUFuk8hPOFp/sn2guYapzEyFR9G/skdWe w+WCM5YtEnJE4Q6tzN4xcpjFgwvJlBhrI9U+net7q1cOYh85KlzPYV3tWFCJAoAE1dEVDlyME1j4 03TQgi9MgUum+5uNkSxS1VStAfpPgRKpXSl45WaSV2UiNQAFr0w0A4fIhAgBL45ZD55P40nroB/l 73qL5dyMfyJnTtHMsUJUwK2EjJXmsFYRIJKWVpX1+qe95RhxTuEem1n/jo2Y5mbICy8XqGS+jp57 ciEOB6pnnzQSTR3mr1m6hR2xI1yZvI8zcWDm4tSQgyn8BPIrqX5I4A/whNI2PBxuAnt3VmYsdv2a rrBcrlwhWLKKsZGAAV60HDkfKxnLp7kZ5FkdILEOkRdngrHEnQNkI1Po5AHMmLe5MlqfsctUb9Ck mQHPx0rWM5YpGebMH3AY0iOluIdKbtLPAgH7JHgeLPvnbVZrTtJV/IxEA0q7Ky5r85NPczOIEFRp D6T4SJQFL25Rpn3dhnsUBwNLLi6ckSN3jlBv8Xjf4NnykeCsV1Cht8rlzx0IH4LegCcpuMZGJsx7 P5kb9SMZAVe9Bx5x/5Wq7qRm+TQ34wI3ST80cYYUORcaa4FUpVI0JYvPluptxlw0yk5SGXo+YCON EZcu5MrB18SryhF0uac994auZPJlykKz/jEfS+1QtnspkIII5P0yGYpG7wLBOMcjkYMqKoge1+Y4 n+Zm9H31vpYbP2KfhImTlcHhNYNhuEd3ZShIPBgwmoXTs7Ga8lHaP4skNeOF7gSx8z4wR3H8MitZ 6ehRRsO6pO0qxkbiBpXXWV6uz1g+rbsngfwk7i1Q7mVhiEzT+P22EbmngF7UnUjz009IkKINLOjI S35Lj8OBUw4FNUGl9SrD4Nq9gUWex0vEbIG1fJTolRaONaslh2IKnzUUqEwo9OIGTAYvDMG1ZVfF zTWVtYiITdYmRZnZKdH7rx2sCaXeMhLdFa17A2Bqqbc04cJddyWsaMrufnhW1A4zE7mYW0ZivaKp s3qJWPjYDaGOBVDdgVwC5RGMyIROyT8H4wTeLWYcIXh5qCht9yBw3mZqcMk/tvOxoI8Yg1vfW6oJ OvmkL5g7GFtoLAjRyq6gxEKU2zgd2d9M3Cf2hoZm3KYioxxDZsyD9olcjkz8lIImckLcdDLc1cbs c+2etaL6GWQHXJ8pcIx9bk1vQAu32f33jXu0CsAPAVKVLVsIOqqmt5IjaMOWwg5aa/jbN+iPsrEZ zYUlOR5jxw4KeXhl9eV65o7N9ceLGEhMdseLMgW9elP0yjGDvhe0RP7OsRgr16YKwj66hhTPrCpp UFlJ3BEiV9ad8UcRR7gowpsYcjLiZ8JrlnpSdFlFnBooeNbTflEpZkFMO3VHkfxgodtMj7lpn4Nl 9hzK7Ht59w6I/fPB9iRHyYaplMt+1hrquBfwm4E53BnzV0o6yX97J8gCENa+9QDy0Dh2N7bCVwZg RULcfugOcezIwTEwlfsBLF22cKG2Mhnc93IPh5sbVe5eD++ez+EZ9F73WFmPwtpiD4ae3Cpuatdh z7Dupvpnq5GqxAOyYlubBFfpng4Bww6NruMcOjokuw5ihQNFT7DQ4WZvv3byR3tk0E343AEvWleQ L+3xN1YLKHCMjB0NLsVvPyWXdjSXMPQncHYzNlux2SCKD1+opMrKUv4kpLEHNgcyWA9LD7zDnU6n lFsXF2mBkch1Wri4SG/tpfXWs90iLfIt+6fY+mCfH6Uz+8hluxPCdRA1I4jCLwO4ez1jiD7Oc7Wz rZT9zHWem3p7Vtu2jXVmBj6L7dZ+PK22NTzV20WBI9vtWaHZUPOi+xI/CcST7cbPsc0SRjx1QMsd 9+G+qN0Y/4XZ8RAqv1Q3kB5NBzjX2/chlY7w1AqpUgOevgZ2/ZrOqq33uw8SYNvxAjhqrYHZOraK v7T2wPbudwVk2/qatlvJaVp1/V/s0/GlfUo6J8c+JTDpNcz31TP7JYA8cCDPU+Wyo8Y5O9m9JGNs u/ALU20b2m5PEt+OaexqeZ7w0lNE5RYtFFeYyvXBgFS5ETBiFnpFagCG1rNaxnq2S01ZWEVT1Kgp bQACv2bidZR/WupK30HK0j979edB0ZNbaaktixZ+svKcPTtr4yG17rIWrtM9LbWl71hqS99BVHSg 6AkWOtzs7TmoLQHvumTConVIWdYDZekmGzG5WkdZFnCz3NxDWaqJynISoqNHolOWAUR3Pzqfz+Kw SBY+J2W2buxJdsf9CJ4Se3ZruwfAfn58a3c1T3U36Zr+dGqgy3y132AbSO/aek2DXTgMlurnxJHS 7WQOCuci8VcyHIHtNvYTO/YdTHr+9u8nuI3DTAjTgAr6P3tiqAENCmVuZHN0cmVhbQ0KZW5kb2Jq DQoyNiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwv RjEgNSAwIFIvRjIgNyAwIFIvRjMgOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1h Z2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMjcgMCBSL0dy b3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3Ry dWN0UGFyZW50cyA2Pj4NCmVuZG9iag0KMjcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMzMyNj4+DQpzdHJlYW0NCnictRxdb9w28n2B/Q9EXm63iBnxQ19FUaBN0sAFUqSND31w 8+Cs147vvLbj3cRJf31JSjM7I4mUNudDkTVFcYbkzHC+OKp49kb88MOz18+PX4jsxx/Fzy+ei0zW thaX85m1VmalKI0sMytUUUmrROE6dSHu1/PZxXfzmXj5+rkQBItqsfx8Mp89+0WJSua1FicX85kS mfvPYVAyyypR5FqqXJxs5rPMz5aJV/PZ6eLN8kgv1v7nflm5f+GpWpz5xifXuPaNnWs89Q3hGmvo Eb5xBmMk9Ih9gz69dI0vvnHnGlcwYUC2hTFvoceP2cFaNr7xHl7dA1blG4auTPtGBq/UwIISjej7 U994AzS5hHX4V4VvvFu+Eye/zmcvHQc8F4Du1mRSa0r3Uwe0H9tjpSas7DLPagk4jv2kN8AEZN0N kGsXWY/K3EI0Q3UUHVpKxWd9AfMEKlwAf76NpNh47huvXOM36PkDtvERJJDLygbeIwW203l8wFpf g3AHeVu5xoeYmKXZT2iY5L5JcN9oWZkpSGwCiTZSFVOQ5AkkyshcBSROb2W6qsTJyqETIkKFspDW crAAccsIfkX5ySUa9YsAVt+6xicYs0L1JUA2z13jvKdftpEF6qyWRU1XOEKdIkGdzKluOwVJGUeS 18EKHEpiBvZ/JPEdvL9vkEUUiFuNYXsZIUiVIEhlpdVTkNQJJKWVZX44VSnYAFXXYNSmUzVCsNxI U9D5Th9VvhniJBFVlqBikUv3ZwoWlcCS59Kaw3lBwR6HF48g4ftFjVEkYd5zm8tykm5WCTORm0Jm 9eF0pWADdD2nYrZjuuSM9tw2fgnxC88b8L6otuj/WoBn9wn4JmDQGlgqmPd3DRM9+J+/ljGpL5U0 dGdjZE0YzlwX0kzS6iphOXNVyOIb1DoFezTm3EHPPaO740flSN36XejfbYEVeETeQ881nJURdrhT UhV0M2OUTFjZfJpFUQkba+tSmsOtAQMbYMYOvNVNjyueGZuG9BF9YkpZGzrF2P4SJtNWpSym6emE zbRlJbPDnT0GFiB+AiqdgzhumYr4DKbthpLrkmkAL2QX6KrvwB9HZAJov6Xc+MAOQj/iwMGfYPpz mBXjzA/QcwZr/QqvPgGOfmi4aWZ2P1/pqbuHvZzDMWuNTySIcNa7NJSkYzFkwnrbovI+xsH8pGAB 4hqoer/fdjLmJCj4+geCTjb2DE7TLZCrH/aFVxdAZNRIl8AbTA8EHfUB5ISFdBvYEbIWMyEfUTyu aLcAa3QG9o3LK5589CT6Mv0Z3l/D7jC6lREiGe92xOnZl4eEH2bzyruGU7AkfBdrK1nrw6WKggUI jPzRy0UnDnm9BRaiPFzDYO4noA/ywGR1SJ1UHZm5BAm5gR4iD63g3IJc8nTEOaweLcEtvEJNc7G3 vW3PMVN9qHtulphri8lCLW1BKRnP6NjMytzysWmWJxxNa2qpD/dlGFiAuADmrJjnctlzBD2tPjPq ID1PXeM4plIKIwtFJ07kvNyZKms+9kU4ie3SMO95EQ0J6kDjKbNpx49C87FXTA6YzJ7F0NhM5mbi lC7I6E65ZTQlFI651UWQuEnTVapHjeRBiwi5KqUtp01ptO5NiSRcwdwb5qFNObfvfCOmkcFE00nT JysRa1jtovXDDxaBCgB/gszuQF+Knua6AwN2BdKGprV79lq3h6vjpz0/C5XrtKCEUnk0uUHHoJs2 FK2H7oh4+BOuCLVOGzS3sO4boM+O9mAkeh6TAJ3LzDK8aQFIhIlW1T4MOFgCKFiA2LGdEbs4ZO7W PSOKflArQZS9z13jlW/8BuoRI6CT5ZBfvmISRnzqVgLvOka27x1HRQ3jKkzocCk+yM5Hj3iTyidE HuNwIny1yiGbFJvpVASbZd6yTcFS4T1j5SLL5leJ+8v5zGnoQlthqsrnvr2vbivhhNj9Ru8bdSJg NLW/y9xfMZ4u8oasKCKp+4+hyAVWuEd8uvgZOO1F57+A+01HD7T8/wnYjomj1V7XH7HcSGptQ160 qqxUfGl0g5lUVjz4v1lmnM8Ff5X445WbQotfhWv/R3guVGURuGBzsQlsKauGK7m4ns/ezmeBVVXD qsK2g0JHXUpHoM4on0Qw7aiA23XkGkapysi6JBP6nWRlZ8awvYLMCB10xj6lIFKgw5u1wLR0LUNC 5Nas61aIXo1fmyX8VFMqP9WhypSBBYi3TJleLEnUF3oeqHrFnMPnnqbaNgbtqBPsoTFDc33GhPhs UPPy63fUbahsMZrgkfINXWtofBkMPc4Q65CZ7QczSe+IkHSMnwnvyLi/1eFpOwYWINY9l+YroxGm Py+hpx+brPYEpVRdLYeyrtxKHlNTiDzn2Sv0zFdAcO4xJdyvqyXmGls24qK6SZOIo1S6KLGgdBtj WsKjMbmW33AGCVQAOAMlTgQ9mXPaYzjlqXDOxg21JjjmDoUfqTr1eql/Urj3umNPgs66YRP2kxbn VEpWIKh7pYK6JJo9ahlLSJPma8KPMb6wYZI3ZBJ+jPGlDYdHPAwsQJzAMULWoJLjBwuVKRazoP9H skNHJKXIks0oPdseH/vFLF3Ht+VhQP99Om4mOxwjb+IiwGgj9SQ30aT8Ol8cYQ9nEgULEKoRTlJm 8ws7LWiSpunmFrSfrMNYf4pufsoYGXUWiUA9qh1NZ3oJDcdKfxKZf5OZicJkE/li7VakD1flDCxA 6AligCcTwzi8I+4yPmKVSUncmA1dLbulj8hHrjOeLNvLT1QFT5ZDkSaqY560RCPWV0CYidikM7iE mmOsTCTtta+p2Zt2UE5DhXHDq6kLFwoXHM/4IUhefXbWFBlrjVSKjyW32dTNYQL2FlTHezAGYbUf Qa5YRWFU5Lo24HCRQzP0AK9Q4Qhm0FH2hnYXkRCfn+jxNiUhidhJ+4Kh6hEkhOK5gH1gFjLiwg6d sy5LQ5ITLf7NYcjQVT7qXM2gL3jNNARqAFT7Dyn+R40NQmCBNXI7ytYmvdhhSIqtiRBKF7lU5hHY SvGgB4TS/wA9nO7o7ZLEJOXUkB4m2UkeRf20x0F8gAG2bpfkghePG7oXeNq5C4KqgXj37YJu2V5Q BFlFAKL/V/LINpnFDldSvE1EWr7KxhaPwFuKBwn3BTi5AcndANJIcuCaQeB1RMzhaSvqOrtI0SIR nfjLromnJRGdaFP4LN7BHg8FCxBm2CBh9rqfJdrXx2nfWjJt1K/RIpKYvJwkS4sb2fZyko0dC2s7 ofmRHji//QOEmuNJ7yA/YWNIQNdVuTxTglTx8tZ6X2lzGaNIX1ISgZbWxeOcPYrnim0RSYl1U/3q F+JSHpFYc7OMxxmqqqWquxtIkSERKWpV+Ev0KR8ZJMIVnZUyOzzPx8ACxDFs/g7ohm7ZNiZebU+/ XoNHhg+AY0yd7Rc1RpFE6KV8Fn2SOssTXr+qSnl42QaFCgCRq5Z/05OHuv9voHzfF/qeHROewMGi LDzYH5YkWkIDv2G8IpV+R0OeIOqeO2r3MWrrm3PcRnsCozLD47yv6Wz4nqJjzEw46MrXBI5qnIiy 8ddCmqNYAyUulqRC7gr2xYOjvkeHhMbPtSLRC3pJGBxhEcLfy34ZxtH0BDq/NEEnjNmIp8PSgSmm 7uVNmo+cBSlGJlxyX3hkRiOtNCMpCryzaMpMI9pJaWnK7tyxsaX/xoGN3YKAnDEOsizcXcP3diV3 7IQgh9kFVePwsDKMfuJ1wMN/oFobsw/BRjrPKVqkgHoBq4EO1DQxx8J6IxilbV86Ek69ykPRyv8k HRRFXym+p+TG6Ayd+24ufExF9vMb5HIEqzG5RxNNdIyz7gbUiechRpP3iJUp+Mj00cKe9phzFqQY mYhIlK2nKotERKJMLc2Qg/UxWmmQ+UqD01COEH7euR5xLma20P5Ym9r4+/aN//4886V2bTlIc0H/ +zdhZoigdKCHuF+QkrkDkyqa8BPiun2xQxnWDR1ZKI0OH3Kasg4lO4WVVQVPq/msyMLHPG3Hte/w trh9LrJKhlIMjwkfwjwBtumoc/+V5zXpKGX4+jNgqitf9gDzNE8rv8hmJU3Hte9oFtp0IDMCKnwK M63mnT076A9OUqE852OD3TnxfuGVFzUtK3/uHUweSnn+/E7cuNFUyCCYAehqCFoTaC+Nz35xRJJ5 zv8PA7YovGibKgRUWP7Tlm88b45hvthslgps8m6pwgE1i9NluXhxopYqc1GyUot37tl5hu6Rincj h4cs1Aws1H/KVZWxhZ40t/BuDVuxXfu1rXbQ4xSTdbqmXghnGXKn0Pyo0CluloXblNvO2hmc0qkW lS9E62m61/7Ne99aN1t+7D0h8TVcFNE93S/NYv3giO8bYSc7v7Gdb639ykVjW2u/5KPCKdd6sRZ+ ixcOIOzAQ25Eo0dNu/+wqz88kpe/Pz6XbOE1UmRHHQr+3h6CfwDLNI6pDQplbmRzdHJlYW0NCmVu ZG9iag0KMjggMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9u dDw8L0YxIDUgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+ L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDI5IDAgUi9Hcm91cDw8L1R5cGUvR3Jv dXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgNz4+ DQplbmRvYmoNCjI5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMwNDY+Pg0K c3RyZWFtDQp4nKVbbW/bOBL+HiD/QeiXqw41K5HU22KxQLdpu7ltekWbw+KQ7QfHcVJfEztrO9vt /vojJc1kRhLHco2iLSORI3Keeeckev4++vHH52cvT0+i5Kefop9PXkaJqmwV3RwfWWtVUkSFUUVi ozQvlU2j3D3UebSeHx9d//P4KHp19jKKCJW0pfLz+fHR89dpVKqs0tH59fFRGiXuj6OQqiQpozzT Ks2i87vjo8R/LYneHB9dPH0fT/TTuf9nHZfub/1T+XTqBw9ucOsHWzd45geRG8zhSeQHU5ij4En0 OKA/vXKDv/zg3g0W8MGa2AbmfIQnfs4W9nLnB5fwag1UUz8wdGfaDxJ4lQ5sSBgE31/4wXvgyQ3s w78q/OBT/Ck6/9fx0SuHgEcB+G5NorSmfL9wix7n9qDUBMoueFYroHHqP7oEEBC6JbBrG9hPmriN aEZqEpxaqJR/9QS+U3PhGvD5Ppbi4KUfvHGDd/DkAxzjD5BALit38B45sBmF8fBBjS5UwXmyx4kC NItSVTmjeQaaUgvvzA0+h2RWliW2T0GUjCBKRqvSjCFiBSLaqDQfQyQTiKRGZSkSCYjMMEOqVJUe OErCG40VCMuWGZYFlZN7mLMCU7NCw7IFgVuBiKGBi4DqCqhuYPLf1CisQEGihqD75zN9/wTM2aJR 5PaJColTqpWuuswSOJ4LHE+cb7FjiBRhIllVuylPxPmuRJdldD5z5KIQVkWurOXL6hVvgZk3YFiR I/WTH6ggnIHez4ChU5i8aLCojUO74venoFG/x/Bs1vNvaD9RTqYwuAUgt8Ow4vsbeMJs0hqEDskr Jtq7T9O6vQ07kW5PJBoJwugdIJcCyKVVVh+km4zEFLhzxQ5kRkMUwU+f4T2q4BSgRxVbgu/ohg7t Ki9010h1bywx4LiE76CUuFNNNDnWPxiI5EsBZa8qZfMu9wUIKwHCwqoiOwxCSmIHU1B/1j2A7ppX LQNu4f2asRG1wdN4gKUI6RQGa5izbBiJHxs+ifbWJ+cnmVF9i5iIYID7F3UUeMgNfO4K+fknla5v IVwdoEnWhUTANU0EYPNMuf8OApaSmIFU3sGZp4DFFvD6Rjn1Db7S2utWrRegwqi53J6LMBL+Nzo0 b5xiuxaziydg2LUbJH6Q1IOQ8yyULfhxQ0Gv0S64snxu/0sVbMKpd70vyvnf4MxoqCJgIGpGc9SA Bdfu27YLsCQmqSAmWaasOUxMKIknoKkLQO1JHAyEmJlsYyBqFpjNvWFU0QpfxySei5iRxxB6L7dJ jNQYX0Snouzex90AEpXlcwjVtFJVDw8JVSETzGymivwwVCmJvksdC80atfQPsNjoImbUSvDI6cQN fvGDl27wHuagYV03NpX+1IRPAfNe5ipPu1yReCukRpnJVVKNoiLkRpnOlbESQsNH8Scpe8tlJOnc swHlaOHA9GdHgNyV+NpyYYQegd+bAzlm47nVx/wJ066vjY6072+pxcekfp9wuLXMjR2O6Jor7klM MyuknM4lV2Gu96EXMtosdRgWhyknJcEClSWwdcscoqd5zliLTEK2Ig0EY8sYzap5ESjnGz94B08W gME9gw9N8hKo9q0FysKcPrne4R5wZ1gIXLMVX2vTIjtSjoeEqpA1Z8mBkOL6r1T6saiAATOPtJBr AR6tKQQrYBbq1D1M5qnPFiZHAMGKbWgFmsqkZN7b6wwm3/Wk4KqRpIA1IOK0DKGX2DoSG5fFpkKt wlaFMoflQIRENElUkrtnvnpxcSrXWem6pt6xo9rK9noCOr4Ahm8bLxogYQpVGU4i+DlrVJryuaiz W1A8koYHyBSVV7Fxn3TpT+eLXYePchrw885Ml8W4r2ntYOowQwxqAmRcvFbmIz/p5S3jc/dQFbSc YmbCqK+YSf8UdytMp424EK3/zCIBTN9QI5ePZkSsL3V0StJMocBky8KFO4dpJiWBUfgM+It3SP7V JXNazx49JMZM4wOPfROK9jQ8vCLcHqpB8ALIVRyOgI0ta3PD+SmhItSMbFGqZFSVWQsFCpuXyuR7 V4jZsnrFR6ZCDzGpO23BV/7AxEYMgsOApqMA7cB+D/tZgQlbwBrEkWcy6NtvAP1VTMLVTee4rd/G ikK37tJV7saQiBER4fEugIXSgs1KlVeHKS8lIdzcLEEZ7mJSKFyzOVMWDmEBGGNlLOpNgcmLXrR1 E5McdtOQn5BaH4u3X30HMVTlCYnPVnCW7ajzynaZgyJBK9QXrDMn1WGFf0biHs6DJ9zAk0tgDpb9 FwNnnpDkDmmgWnhiX2BOKBuAgIDuq+8aMbBGf4zeo9bHL9R18jx4+AAINVfXup/gg/vptR/4RCv3 A19czPwgd4NPjciFwuNKFaaLlIS3UPOwplL6sPyGkdi/CtGpu/HiWt+qbmJiftGGYmrYtaEITNeG 9q9y9xBKLG5SKbinR1/A0WvLcNuz3qFIHpSZwyKBK5SirK7UYbVCSqGvKXuVhDHt2zCs7kC5MQUN 1vraHIAdSuKMUKmpa7KjirFaqAzY1IE1KujSUpKaJL6G2VDJGw5QmE7d4IUfvIMBts6wvJrrCfbq kCR8AilDKKVzFsXy/cinEgJ8U/nGtlFUhIDUlKnvftg3lGTL6hVYIkPm8KvF4fAhyP9Wy3kWtqCO AS+4sCjGJwel3GYq1/QEu3p9hEjcFKnKRvkII4R7xv1fjus7EiILk2kFWyn6Uo69fzMwxcOx7265 F/gekHt/627ZBuVTCv7U+BatUYbFCIbb+Cat/TMotqxewcsAWN5lRhfvbbFUh9lna8oDbHMBp83o Ry/Ah7bLZwzGfh9G/yLer8LIeNXZ/KSTNqMz4t7/AbzSji20vRlUrt7HbXCPFQLMNfGeYhqH7/nb LIuxRBYCwUcZbZRO9xcCuqxeMaat4gSY/nE4QCJJ5uR7g3ns9cBEiTT8dLWWXyGgwOL9K5uDKD7A nHbTg0dgkT7GZ7VYfY0xTxPjM8LkXQgL8YPxTX12f4TpsnrFLXDkjsns8CUR94Dslr2tjlEJYOX/ fr/uFIzvHQMF4zxsFkK54Vf63uzX18H/doP/+MFbkEZM29FnYjg/Zwj377GGzQhpR5HV95G/u8AV wjqTmO+y4XRZvYKXack9XHs0bExCjcNC55AATDpReP/a95KxmFVWeZ8Qeo8NkxSsmuF9F+uH4V1B /f6q5mYqUO30PienTLp4vFHjF4XMQKBMT5tPiZ0ajLqMvxAA68p6S7Ev/mxZveKgWkPbUf8alLeu YZZxW8ws4h21htTtxrCz7OKIEMxr39Y4Ko60QkyrfRPdqKTLCjGtzjOVQpxWNiyYkHD0RUzKPpgP fGXadQUyjL+l0vnFhABPc+PzK7YD+RxCVO1vqewoWbVC1OqTjpane8kqXcbTLIzWvjDr1e/p6ntl VNx7sPkYgPVbPNAd/AlL52B58FYFc4fzBscJuTPHrgksOUXg3tBK4pxt3L0gwjjxv2Aq0VGhpW3v CMSOX8LJXTAKaYM2uUr3jyfYsseLF8aaKcA4BaXg5z+nr9Cetzzg7G91ZRWTfp8FLJ0yqr8CKA+U s18azFuqfK8byvkvLGiYUj9wAk9wd782k1vhmYLwTBkHnu2A8ZGTu2AUAn+tc9DpMIx9ikOBZgsw JfiopwyKb8CQVpxJcIH8vOqx8bx5QsHDFG1NuXsGNP4GTG5gwIUAsX/BaHjDgfcinCqmDRs6B7PE 1SNViXtDkVwbbRD2DXEurOj9rwzFCyA79CvyXqvnb6fLm+jpfDN59TEWBCnNfXPbnoKUDTnfVpAo wZrWa0Dxf8xkTkH7FoNKh6Hmb8zg3zAB6N/CnoCMYb8IS2ywooEZTuvTR3+epKVYNdoyObyM8T5r 0gm97noCTXrdJH4PhSltXyJh+K5ftJOChKTw7Sl7+wW6rF7Bb1f67V2eDfUlVjCe1HWbAqG861hC 1JL6TpRRTjMTnGZaFmrUTUsmmGxfOk9AeauGAxMSTn6ISbrNE/AlsHMuxYxGq6Lgn5E3K5Qd/K+W j+SbkN/68l8xqgSSCVlSaquxJxIyi9RUygTV5P/45tS7DQplbmRzdHJlYW0NCmVuZG9iag0KMzAg MCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUg MCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94 WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDMxIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFu c3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgOD4+DQplbmRvYmoN CjMxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMxNzk+Pg0Kc3RyZWFtDQp4 nL1cbW/bOBL+HiD/Qein+lCzEkW9HRYLNEnTS3fTM9rch0XaD2ncJEbbJBsnzfV+/ZGUZjwjmSO6 hYvFbrk2NUPNy8NnhnST57Pkt9+eH+8fHSTp778newf7Saoa0ySXuzvGGJVWSZWrKjVJVtbKZElp P9Rlcvdpd+fiH7s7ycvj/SQhUrJOyt7J7s7zwyypVdHo5ORidydLUvuPlZCpNK2TstAqK5KTr7s7 qdOWJq92d06fziZT/fST+8/dpLb/+v+rn565wYMdfHGDezt45gaJHXyCTxI3OIM5Cj5JVgP6fy/t 4L9ucGsHC1DohS1hzjv4xM25h7V8dYOP8NUdSM3cIKcr026QwlfZmgUJg+D3p24wA5tcwjrcV7Ub fJh8SE5e7+68tB5wXgC7mzxVWlO7n9qHVnMHrtTElX3nGa1AxpFTeg1OQNddg7nuA+vJUrsQzURN g1MrlXGtB6DHW+EC/DNu0oAGG+V1yTQExayXoFOjSv46+27+K/vgG5DwFozyN8Qzj7yv8D3acxkf MRsE0zGkio/eczu4CgWtHEzMXkIs5UIs5VrVeYwQIwjRucrKGCGFICTLVZF1QpoWRLrEVcyEb+zg Bhz3FWzpA3BhB9/Ai37yW3DuBYMM9PL5CnYCsdkYlfdWJ75iKbxiatHcxAipwkKKxm8MTojdLVJd 18nJuRWXhHKjKpUx/DH/xCnY59AN9iH6Moi+xg4+MMvvQcw6g89b5KFWfUahW7FPntjBH2D57yD1 0Q1uQOqcZtxF+1Xn5gQydsm8uwA3Ynof2sE+20buIVzcnBVcziH9zwHGWgBdb8PcRQG14Yj/asF/ tVFGc5j7MXAJBKzL6JKrwSz42w4ewHJdJnjk676/plD+J9gaU+oLWPYJc+4eGH0Gn/gAMnQ75t5B rGPRhpODCNk90cATVYsTAafVjdJZ3+CC1xrBa5VRVRTYZqkgpSyU/WPj3KWPSblbw6Aa5O4hpQeX LJ1uwPNo/1lrVsLqMGf8JwcUlN8xQF2AHhT2pAXtwMZdZ6pgb3i64pQcHj6D9iPQdTkhJHXJsv4Q 1oKUFV9+Aa/rrfDP0B6bNqrK+cJkv2eC34tCmXz7OU/VHAx2PrJNUgs4wQcDH3pI/ALKbwCRmcO9 7b+tgJRC8wtQdg/CXBp/Zk56hMR2Cv3jV/AVUv1bWIeP0u80BmZsQTcAbXcgLATmHX3qOUVyrUDG C1Ooqty+a6maF7D9ztckALXJLdgN/Yc75mUEirt6qma5HEBxhjtDFP/OJjt6m7YDCbxtxVtlffNK ThJYbpGXKm2ipAg0t9Clys3m6E0fC6C3AePV69H7BQT3fEJq7mcYbocUkM8gvefwyT7D89d0t8eE x6hYrkPvehSVxaDs5pxAfuISl5DeSMEWIP46lL6Z3YobatYxnwpVR5GVqqy2n75Uzfunk64qdTbz Nnk/WWVhZ7kryJ5vIdGO3jRc9GJCaiMO4SIHrKH4nRIOiG67oFL9J/+hkXMOK12CD3HOQYsn07YA wKDag7hHCPccUE86Rvcs6PpGNQOnSa4XqrEi/QV+Rx0s3f3jBt4Wcx7t8xos6m38AL68C2Np5QEg wLGKVJX8fSWTCbWnaSqVx7FgoQIydeXWsymOsscCOFqwbUsPcPQVxP4V2JTUrB1G8ihdQFw/whNL OuePwVOHDB7ngy1W9bR2iPcNxH+GJX6lbkfx3TKpjCE/nwnRYFLjGDex5pgrhbLIVLVKs62nEVPz DmyLrnmY0GJ2CeDJmg8cb9G9PaTtpPYhdBrbQOyX0QKEnjAMjIFHA1kfhMeW2PacIjWZhVrVWAKW /wyxDXhUa9epJdKTqQWBstIdCIxEAnmuBYEhsBZ2kCOwamrZf7vBOXjHZelH8CkeJXBgrceBtWcp yd5CjWiKWpVRHFUL5YgxtWr05thKH5OwtaB24di6eV7OBnB4SNNkHDunpOXrEvgzaMW28Fhfcoid uA+MbRg9VAmkpC5Uyuw75lyhjDG5ZXzbJy1MzR5gGhoAC/6fIprrTlnW9Hxdne+rl+NNkbJmzhoW rsNwDsJqt2Ny60s+FIpIoxu1/XYB1eLC8xaMumCu4lDXCFDnio2s6a1eMoFQc3kWH9V40QJ9N5nd 7H6ARdLHAkhXgll8jJQDpPtzQpgZnkhctwE3Jc0PoYXKKvZXsBthTvD6G4nHOUz0WcT4xhz04EkY 9nX7CYab3dTREDzTCTRiLJtoSmq303aZS4grFBg6bO56qUxE6LS5q+7ZXDlGpHoltRv0L6CnVM0M rHFDacY5Qhsm34zudXjo8nYQLjfgap+7/5sMeyWdm8cPZUhECy29Lvw7eCxbqXJwcDtL3hLqwrxx t1+27i2m5vWENKMewPbef8NKG2+SBFGyaRzG9F5EModQW+V15vo7Mef7Ao3Pq0wVwDxWx+p60j9W x1MVVqpscL4+JTy6d74uW4uuUH5PgT7n9s867jaEQJ/zQqvN2fPqKbubHAWm1qWtFbgGLzwEhI19 H1sUUdl47IZUGpkVtt+QBi9CVrdUlIsNXvwpclfX0KnXK/TpaJZpByHWYFQWp6ttZtKpWEbcypd+ YsRrtwPVbCra8IwG7TwkwKSqyON0maK/rDPA8nmbV9PwRTFts4HrkYNZKBdydz9o+6eOTM07KTKn bXdrwfapvyb9muwY5nyfkJ6YH2ATTmjbvWFp4AaXMHiEAU5+MXj8L1wrNuAuYW84p2/Hu7WtDLEI 7PlD8qpQQOSt1X/Sq6HmjG8K9lTI3qdzhzT3X6t9ZtpWyj4WrsDF84FDh806AjOETndnTdPe1dEl uAfPsxLw5Q0o/AQ8bAkKg/zGgmWmwwYZek6oe3Kdu/soW89HqgYP45zJLlrkDqF9rUzBnw6idZk7 vsfmcr9iW2BJczi0JwE8x+jWtkCoKz73mrGU0W0JEDpKXZGq3srGN6aydLPj5Ld4v9aSZyy6Q1tT nmqPLjHa8rRyHWI2lySTi5XAgxYZqkiTuWzpexPLCR/F/gS0O0fuXvEzRHd3OUW80tXLJCkfhQ5C 7u50/oJ6g6q5nZDq8LKHXl26vJ8wQBRLFGzkdD0cvE8X7lkXg0XJFhTq6zzNY3FRqPt0Y1xQbsq6 yWPjtJvpiOHdTDoSb1YbhRKyO+JgEoJI2u64bO6G+d8Bd5y6FrjZ3D45FTZTEZGjFqC19XDO5yKe LiHA8eZIkCW3UczEyPEnFNraXRAtto4DTI1w0IGdQ97lxvtteGEZuRNybUahOan2NzHwQIYRNYEM 8yvA6ChygtN/Ynj5aCbBUdca7LlA+hmC0OvQ7pJuvX1HUjVvwZHkN0l4+NvntUcssR5oqvk5j7D/ 3U/Ij0KOWkvXwKHldMVLAgxB+JXPCMrbs6XkEaEro8tCZdsvQZmajSkve3oMOelc3k4P4rNvgsQp absgbO6GfYoOX2O0aVuWOk/TueObAcZRiM/azbmMXEB7+ZvNXYRSJBCtmR5YLMhLs0qZis91bV0N UWZpaZeEfVo67f3WBM/TbtqNcd2NR6Bx4l2NXoJIaSa0Ld12aLZ/qsjUHFN44Ze3ecM8nYweK/bW L1lB6He5si4SsoT+is5LlW1+y5c8FsFGqY4oNkqlIxvF31rce6ST2SiVMMZG6VzM+PsBCIWODAEr o1S6e94Nn7ukWymeN4RKU3eMUJg4bV3LmM39Aih+Cbk8DnJtNzhOZdtsYHPRgqtjQdeg4lcjkN71 bkV38BKixq5S7+uTk0FoWWld/hJgoWoOJuSHHJxOCkz1FUQn70Ph8bdrP31nhOxoxZH7bPeThNza 5qSLWG6a0NzSXVgevN/4JaT+D6yuYG1+67ml4DuXVpu7Q7YyvNphOAgdE52V7tW3Hg5UzRNwzLoU nZIWL5KV80n9gznl5fQvSeCvRsnfQnAHn/C//+ACxJ8PKHcCOtYB25T9qlKulLgLJEcKjRudVir9 BSUvVbM5L6dPj/FyOncBlr1vnSLy8iglHS/nSsh1Hd6pCe2LQLhjVOrcX4BhczfbF7XzdaQVu441 m4s/uruEGB7tBHWt6CiVXSuazd0whaeDe06hrrFxe2HcstoOM5vrO6s5xD1tXuOPoGSSz7NNylmh TZq5H19sv7vB1IhFz3Rdgeh/ycR/DOFc9xFmjzewp/IdG1dg5mXfGpJNhdZfVlcq6kpnIbSdMnff Pu6vvxBaJY4Ix71QIVSCDjqrqJORQqikMtPEvpFQSWV5o/LgVvV/31I5wQ0KZW5kc3RyZWFtDQpl bmRvYmoNCjMyIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0Zv bnQ8PC9GMSA1IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+ Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyAzMyAwIFIvR3JvdXA8PC9UeXBlL0dy b3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDk+ Pg0KZW5kb2JqDQozMyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyNDA5Pj4N CnN0cmVhbQ0KeJylWm1v3DYM/h4g/8HfltsaxXq1XRTFsjQtWrRF1mQFhrQfrnm9NbmkuaQv/36i bMrS3YmWWwxLdbZISSRFPiRd7BwUT57svNl7+awonz4t/nq2V5SsUU1xsbmhlGJlVVSSVaUquKmZ 4oWxD4Up7s42N85/39wo9t/sFUXAhXdc/jra3Nh5zoua6UYUR+ebG7wo7X+WA2dlWRdGC8Z1cXS9 uVHCamXxYnPjeOtgsi22zuDP3aS2/7tf9dYUBg92cAWDezt4BIPCDs7wSQGDKc5h+KToB+GvfTv4 DoNbO5jhgo7ZAucc4hOYc497uYbBJ3x1h1w5DOTkY3H0anNj3x4fRICHFjVnWoWHPu5PIGBQIgu+ ZuPEIPn+GAYHKLsL3C+8amDwMbFVJUsmRLzVIpi7onIRqHxZyUow5PESFp2jsryK5yjW+8R+eGk3 IiJW28mpFePxqs9wHSeFc9Tjz4nUD/Zg8MIO3uKTd3iML2ipsU1d43svgUW+jkfs9Q1eAmeXJ3Zw mTIzWv2BDEntS0L7UrBa5jBRBBMhGTc5TDTBhEumecdkt73R3bU+a82y3jqFwQy9Aghsd8WPOL1f ojUB1QXq1c15DX9u8DFQfNhCfd/go08RSWAh3Zyv+OQU5ziKH/jrnR08h8Fe6Mv89u9xD94z3eI6 s6VXfmfrTUFa178kO1IBhlBAaaOI8kwyr9nyIHHrRcXM0hK3eAud6K7w7CeounuU1g0q8sMkxb5u GG+WT0CIoUqLQTcupGYwqQkmtWJKhMbMMG6wSGB7ePun6HcuVkxrhq+S0lU1E/GaSferJZMmnFts l6w0lf1xcrxVplwON5IZHtGVjoKUUENIqFKsyvJevCS4GM3sP+1+WCnqut1UkRJVZZhSMZmjuIm0 chRGv+tIBzcIXrwLgUv/GMlft5jE/nkbqs8HEs/j2/o4xVLgRGomq3DjQ1LjhNS0ZirL6XMCOGil WWXGyz4k62S/fr7FY0bEBKGtJtdpOKvtnNWFXqI2b9Gr3IWg8RRVMkWHdIVPOpBr/3yxvx5QrR77 EtDhHNe5wQiyHCG2Azir7KCCQY2DR/hK24HEVyJ65Z3HaT+5oyiRIvY7R+h3WutM4Axu72gTCnLI XAikoaVhZTMUXmiNhix8FnGFsv224jkfQkX4oFt4Zfqgc42DeR99AjC+QFKv5wLXeUB7umqlGUew IJ7PqestLYC2CdySjChJE3BMC8NkVhjkBB7T3DBTjb/eIdka17qLF+10RVseZp2H7teDvxOvNn9b KGTUYYJgP0PCILCRDhDBT1mupz9FtzFF35BMqngFXronTcZ0IayjDCbOJkHKfZ4EDRa08xz2LboI uHcKuW+PEeppmlSGYllrWaWJJpi4CE3hK96+u1SUFNZSc0QmhIaEtZ8Yh/SL0B1cpHiAbeicxYxh Ijy9F9dJGBbiGHKadiLe/AO3n3ArFrVpHVkvdQEIVKyaikn9S3cgYjH6GkTUAzchmnsexvqUoLrL kLeIuw/RVBcffM7pUUFytaoBb5+3mrs50dQp2sdpdPcWGKg8Vk1abgsms9YXqmR6Sfwe0S4wAPoN JPGrjQ4271gyI8oYiexK1S6bzOFCZCCqqlnJRwe4iGw5wNEXoKdsseg88gGgyFu86P5uJNBpHDBz QWmB0fWuBzQJfekSRBxtma4wElmaMjUo/5ecR8hivPMIqYecRz83Sje+P6TooIRmIrrWLpILyYo1 S5vyBSdfDOiCXSodrwGZ550LSkQmnrtAi4ix7jna0VXKLGxGUFd563bBOJobwGvaNWUt0Lmm+GAe l/jYuN22An4QrkmZzCXbHkE012VYhvJ9jVlRAH2XiNxd6ZqZrBRBELm7sjGsEVlciJROSYvWEFrs tglXZ06XkSMDrfyGN313IHydERkplK+EiRemt0/kSUo0LE8fRJqkeAOXeXQUCckcxSH67+sI7IHE DnrcG4Ntf1uDlklbzfaZ1azPkzradBW1aZa2NiQXImNSvGRifGUuInMU71EucY9sjmdLusjO9fcM h05Dwd+yhPLn6NOEZI7C1W18bUdjBPyECvL9U9/TeD0JWqt3KIy+r+mLQB6M+Q6DL1Q8m0DFiHbT /VYH06ZoroEF5AQqTWk3rZYWoBVBQD/ZQO97QBGrHNfBwFZFEUPH628U9hlqxudqvh3s5vjeDjx5 AQOo77/HJ07VrtcnqL3JdcCpi9nB5oZafHzn9XR+UWydLbb3DyeEAG0EE81oS47IHMVeFGWn6M+T FYC27xvwGTqRyD1RZWNyViyTMpel/bfWY61Mros1nfhCho7XAaaMvrvlrOwx2tQfk64JDKak0Lhq fGLQfRgPpxu0Oe0oqI2ui2ddvSzY6ZA0Ce8vtWBivJEFVI5gH2sjU/RrV5GQFpOgfusF6Srdvm8c fKOyNmb+iVibjDEd17a0S6ZM/SGG5EfEGwmt/fGoIiJzFP/ArqHX8DISnE+9LlEM95h9wpwdGOxM ui7VNxw4EXxFoYAofWt9HgUmCF4nlDfoAkmw3yFhUTGhTcByuBDlACkkVOlyvoQgUl0Jnfih+LRG cSFZ16uy4vuM1nqJkp2h4v5Fa70Ozdanc0k33ALoYL2hwxK5iCwlCn7UYUMyR+Fan9CSOkLj3OsL FN0ZH6IbSfRYFis87tAheAy8jjSVkJYubvV7HhIYkXaJRsGHO2MFFpE5ihfRQeZoFP5TMnj1GeVw hGf8FuUR/oM4B0Wfh/Am9YlcV54P9kOUHewkWcdzVXJuA+aYxVeUCso00VwfKA/xsswQu8XQedqf 0oGzdV2/VEMJ0vimzttk189L6PtzqpQkuViSb5HxlYUiUnQBH2wMIZk1FheSOQpvRM6sfkzqpb4e n/heM/kJUMCZqpA5jx7NrSfBx5fJRVr3FhHSsiPqAwI+URmfwkZkjuIVmt5tj5lTKNnajQhZDO2f KE0IY4Ns3rd9BJQT8LHIeCcfkWUj3hoV7L94KHuf1GXOvE2pQmhc4cS0g2mdUb+pIYkQ4EzA9xA/ YRchWRa8neF1A/91ic57hqjVl/XvW1y2jWVIO/iPbCcFW4Hv8MgGejSXlhmB0YQ0jOcBDgKjCWEy 9acJjCa4geJ5DhcC/Aib0JZZPkYTiIBDQyxLuprw8ryuWFY5VBPujkOvJ0+4hNOBzkTmgQinw3XN qiwwromLylWTeyLCdLlsmEyay/8x48vvDQplbmRzdHJlYW0NCmVuZG9iag0KMzQgMCBvYmoNCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vUHJv Y1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEy IDc5Ml0gL0NvbnRlbnRzIDM1IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kv Q1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTA+Pg0KZW5kb2JqDQozNSAwIG9i ag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNzgxPj4NCnN0cmVhbQ0KeJylWt9zEzcQ fveM/wc9xi1R9PukDsMUQqBhCM0UP7RDeTBJCKmbmBoo8N9Xkm9lyb7b06XDYNZn7Wq1+rT7rQ5y dE4ePjw6Oz59StijR+TJ02PCqFOOXE8nSinKGtJI2jBFuLFUcWL8Q2HI+mo6ef/DdEJOzo4Jyazw 1sqT+XRy9IwTS7UTZP5+OuGE+T/eAqeMWWK0oFyT+e10wsJsjDyfTt4cnM8OxcFV+FjPrP8bv9mD RRC+eOHvIHz2woMgEC9cwRMShAWMofCEbIX824kXvgXhoxduYMJo7BOMeQ1PwpjP4MttEN7BT2uw yoMgc89EEBj8xDscQoTOx2+8cA7LvAaHCJhnQXg7e0vmL6aTE78DYRcg7koyKkQe9zdeczt2bytF tpW7m6cEBRunYdI72IS0dXfg3ecefzjzjojC1GHv0IbyctanME9ExnvYn/EhLYTjIDz3wit48hss 4x9AYImVW/g9ReBT/R6P8PUMdj3i7cILH/pghm9/FkN09yWy+1JQK2uMKMSIkJSbGiMaMcIl1Twa 8XmLCWvJ/MKbI6QnCo2hSpVqUeN1CN0H2N07iPwZPPkOSFuC8DUKPXhV0juTTzOwRIMskfn8q8Yv MVeLGhHSc+/1vED7CjLarRe+wOpvAGULgPUNDL7bpMhdG2vIk6viZO6odrssPDZ5sdSBeDX98dIu Vq2x8SrUosbzYh0JEufwJPy0hDDMYYlfIR+UdaEJH8/y4iD7sGMdFS73B8mLfpC05VjVO9ZRrers CqaoEeVYDo6XR+VdXpzXkKQepCSWTtBdjohV38TOUGfrnJS+fjDVt9/LL31qXOzEt91vFHAWAZxV VInxgMvVokbC0BIyzqooA6nC274tFg01hUMIdEION+VYm1OV3km0DASwUERD55DQNYo2enzocrWo 8QKA9xGEvlQTWIdPzZmJAfc5Q/w3mvp/aqxwxIrWVMnxUcjVosY5nMwVHLhIUX4CAP0YtzWnohog tclIEVstBgQ8VkEwXnAbDTwVbZ0aighCL7XStDHjI5KrRY0TKGwx89xAb5AicjtU373w85bctdnr X4gIDcJfEXb9Sbd0bCgqCO3S0lDmqqwgvEsLQ2VVkeUI8dLcUHOPKpurRY3HEPREqxcAvFdwlpdF x7OAKtvPviwV+VRD60TYl74PlSjrSlduald4Cuc09Zbr4uSmrjY1qxdwxBMpKbvAYzj9NOcaL8HY JfwUB/954KUXG1LjP079t9/j81lfebY8cghWF1eEpSnXUDk+8xdqUeNXWNpVcdRTg3QDi30C9DZl gcucmlwnxiIgAxZ0ra+tamlV5tggrSrG9pVZwRxtbKVdrqhtyrGJrg0HyH88yPGT4vYdCMkldtxa QlXlqeQNVYWn5NBvv2nEAGkLzEZ0bD8OQIS1KRu50mgAbtU8YeujsdanHrszx2aBA8yO4cyumH2A 2RVj2XYC298hbJhdoYjHF6F2qrGUje/MC7X7UbvMxNAFF0LtlLFUVpVsgVA7pS01bnwUcrV7UjuX UzsHiU0V1E5sWtPUo6LULnNqKCIItVO+OLvx3VKhVkXtetlBSEEyN4gcJSFi2snHpj42McXrDsqY eGHr2zcovAuoPIPcUXBHnSonx8OOcEclHRVVVVsg3FEJR+vOBEIdVVjX+HanUIsav0Bw11CnvsNF xLIo/Y9n7a1surW4nCGXd20a3M43tFiEPyrOqLhHmcnVosYNlPF083YBq/4ft3eJgF5s8IkngK1T QxHBmB9j1AwVhn2LXaW8jVVuMNrSYTFqh7Ttm+yqXo57JiVym2V22L8m76oh4RbLF4/CCi9iXvDT 1Nas0Jm66ky4aeZ8jL9duXnTMRVGUqOxSsT4MXx7t3N69ifpykTtxeYIV7syEWCxG0UFgdw32JWV gJTvoQh/O2KOXi7ursnB1afDk9ezfrhLF96njk4AhVrU+ANO8BKEDwCbWxDS2yIB9b73umaDm2wa pApGdBRDE5cUm6PWo+g5VFMq4kFtaoPq+1AxnlYVavcjl5mJocXY2sU0vqmuKvDS1Zr0/9qh7nr/ ZV1XKmsjlxuspF/dNfdwc6FWlrOylA3TpH3Xu3JjaKE9Yc18H3pbifBWqX2XW2UEYWEyvHyte3GK sDC5afBqrCA0TApPc6raJIXwGxlecVYdboVwAslk7YqQll740iDq9ghpXEV4sVEFF420jyK8X6ji ShppH4XRlFfhRSPQFeFOvu5NO4JdEe6w61aEYFdIQ3kVXjSCXSFM7YoQ7ApuaFOVyzWCXcEayurw gmCXh5utuugi2OW2oVVNnkGgy8P9SVVwDQLdUPvrFmQQ6HLtGUTd/6BAoMuVq10RAl3uW2jZC5f/ AMr8vnYNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAy IDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMzcg MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz L1MvU3RydWN0UGFyZW50cyAxMT4+DQplbmRvYmoNCjM3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDI2Nj4+DQpzdHJlYW0NCnicfZHRS8MwEMbfA/kfvsdWNM2laZvC2MO6KQqD wvpW9jBhG4IDqRP8881Vj1WYEhJ+uVy+73JB1mI2y9bN4xJ2Psdi2cCa2tc4auW9N7ZClZvKelAZ jCeUMehKDHutDjdaYbVugIkK/agsOq2ye0IwRe3QHbQi2DiiAhlrA8rCGSrQnbSy7GbxoFWftOmd S/a8DGmIc9yFZMfwEeGV4RzhlgHpFt2TVqvoxo7iQVQZn089+m9RvgmGnWgZieAC090qwifDW4QX KWwUe5ecjUQ45yw1nxie5WgQVWLILy8IiWOwckRXCvoHrob7CK088ygFQeRHn+0fvfO5Nc797t20 z+OXfwG0CW4yDQplbmRzdHJlYW0NCmVuZG9iag0KMzggMCBvYmoNCjw8L0F1dGhvcihEYXZlIFRo YWxlcikgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFcAbwByAGQAIAAyADAAMQAw KSAvQ3JlYXRpb25EYXRlKEQ6MjAxMTAzMjgxMzAyNTUrMDInMDAnKSAvTW9kRGF0ZShEOjIwMTEw MzI4MTMwMjU1KzAyJzAwJykgL1Byb2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8A cgBkACAAMgAwADEAMCkgPj4NCmVuZG9iag0KNDUgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNTAw L0ZpcnN0IDQ3NDQvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MjUwPj4NCnN0cmVhbQ0KeJyd nc2ubLdxhecB/A77DS7JKv4BhoEMMtJEiDIzMjACwzAQy0agDPL2WR/73CNLt08f7TWwm+qzi+Su +lZVsf9uxlWuHFevV86rlnblvmrPq5erlX71drU+rx5XlHX1fsUoVx9X1nr1Jcu4eKL2a+iJMS6e qOsaeY2x9b9rtnqNec3ZLj2xWl6zXmvyh2s3/SGvPfc1u1aPouv0uNo111Vr6GJtp65xrXLVFksT XDW0sVX1qJ2tuGq2dq3Uo+Zamqc3XT/0qEmW5huad2m+IeOl+abm3Zpv6qKteZbm3Zp36cmt+XZq a5pv6/92lx/koD30uHXdvFqVczRsTe7aW4/yVy1yWBStWqoG8g3ObFkL96XB0AIl5c3KxZoVb1UZ NPxVi+Ydk4s18WxcrJmn7qhqirZ0S1U+b+s4RjNv3ZQ8pAEu0aRRgos7keLicUUNLp4acLtaJlpy 8daAG2zlitDNVcUoQrdUtXBkP76+ousOqgIWnRtsJ/hcrJkHN6joxeQGm2ae3GDTzIsb1OZicYOh mTc3GJp5c4MRVxZNT3SzTK7p4kmmNQDrRHheKSde3EA2Yhf7ykgFK8VrsHn9RybQ6pa0Zc2cmrl3 gNDMZ6upmUfXzLrJnHKbGNFgaObUzIuNCfhcYpKo5tbtVsSwAVH0d6CsmrQXUEMZbLNKCr0Ck8TQ j1eRSdvgJ6GEpq9auKdwqEgk8SEi6QUkNXPX02JTslEYqxQjIjSzNtenQlT1Hx3ZVMmnL7lfAGsA AFJS33JtlUP7hn3dwChyW0Vn5dCNEuWSKoZGFb9VGhsNfU90SnB1k0PRRQqSLBuT3kbiMQlu9Io6 NHPXNgnMGOJLetFAm6paeJytCrgxCZzkNhb+kWsGeqoK3tgKSJUyZynISyo/iEp7k8BWiW/yf1Xq m01BkwQ1AEg5dIYCwg3MLKiSnCFnV/15dvDbpA/tsAmCOSpK1czkHxQqDfGMZp6IVVPMRVqTBudG iAJlbgWt6f5XQWTS4CoKiBSvRFORvDIIzm7682qitwmm1eTIpuAtyUkDZZ+QE5QflI5Eb9NWVsoB TVOsLmCbgFtdN9fktTUEo5KIchTJo5EWBVojmy0Sg5ZZuloDzbwRvSBYW4A0aXCXSg6aGij4TRrc iLVpK5vAKhspqwVpqWqgoDVpcIei06TBHQpRIxOm6EVsO0l2+vPubEww7Y7HyI5CQQPNPE8y08xT 2Ci9KRGSusiYZ6sCbm98qJDvTVAIZylEhUxTyuY5Mh5COTgWnNkIcmmCvnWyX8gxDTGLatImqVGp QBZUiM42TtrtCwvWGNqfsiqj/ShbyqpJpj35lYwN2GVxL2hPMknSL6NO/iU3FtItuDOhRuRUkmkj aVSUxx6VghWmhgiUBrXGOPWK/Q0qlrKgsjdJV1lLo8pI4mjoWVlEa0zW6HjjJPkBpVRBLUHmZ40J pyQiqVFrnNS/8NqpisfN1EVpQ2tQEYV5o1gwkt4IunK7AtjIEQ3FNSpkIzwNDQqXSVUh4wMNuVZB pORsRmCDjBUK7Y9qKXdqf6hVzjmFiBHonJIyFduTBrU1rUbe0ZLMwhpHcKfQHI9vkr6QUM2iMhTF IkiYQWU7GSrIh0HaCFQUZIDAxzQBqiUULDJ9xOS6SVmhHBVqhhK8RqyhhKwqyBpKoBqxhhKeRqwx dA9BEg5yRdRTeCiplZmXYhunhG1WI9+pkum6Rs2hPmhrjORj9qPKFFhQmshqQUFMYhGUvYyBLc/l qcQUoxQX0U7Fku6iYds3M1OhxsSWMjYpvlSkVDbTiHUXpTVYV9lCI9bY7IB+IKVGjShLRTGPU7uK YhEUi07RC7qEToYMknFHQ5Gn6hEZiq6CT2NAlYONyFMKuSMye4eNQOcdNk5H0WEj0GqHjUc9hI04 DSZsBJruyovXSfC6Xe0K7fctdQbaHwUOTuUseA2dj9O/oPNBsaMJVDk9bQqVEeUEOh/4Lh41VioJ dD4SX6HzkUQLnY+ze3SupgYL1jhsnGp82EDn47CBzgeFJND5oJIEOh+QHeh8UEsCnU+KSaDzSTUh j6lOQzE6n9STQOeTTI/6NGL36HwS75inW5WeuQMVcsWRzKIRO0Xnk7IS6HxSV+L0AhSWQOeTyhKo e04oRt2q07Rip/9ltdMR70fDxogInq644N3TF5/eD50vGoXTfa12Oju6AXJLoPMFU4HOF/OfhnKl WAl0vlLXJDpXyNVzofM1OHGg8zUU20TnqoZqzdC5tqdODJ0v1JjofC3F4nQqa0t/ic7XnvSUNBIq INfpuXfRLjmlKOfR86HzTYOQ6HxTWRJdbrJHovgNNYniN3aJfjcHnKynD6l0qazR2QHa32qrNDrN iSLPMUTdiWKZ6FwdpCzQuTp0LFhDhV0j1tj0weh8b/n9VDZ1R8xHk1Lk95OFy+lhg6aEhgd+1dTQ oQYND/nwVJiCDk7TUbj/JFuXs3vFRL2O7iupA0VypIGm7dF+k0pUBjulPVHItQZZvcx1+muaIfrq ZDU5WiPWoOIkFUv1kudOiySek+xfOT1k0hLRanKeaBQajWiBqE9JZavkpaQ2VMikQ24kRbp4RkSw swb9CC2fGioiSAVEtheNakNctPuMiOA4bZbizZGrAdY5plL8OLCe3otonTaqNI4K9FpF+lOipQ8L jsT0VnS6ScVvtEVJ/9eoi3kaLvIheVsjdjpp3fIcNOjCkmjRGag5KZw5aNqgnSqrZgKL07+x+8ka kwP1Yo1FBNdp6oggPaVKr66jGqukcmJJGjwiSJ1X4dNd0gkFh7HTaQSd++k+gzYvT7tHpc9NT0iG T/qBQNlJxxRn93QkStJagz5VKZfXBE5jKCWi4XZOf7lPj4hS6KyUyLTGo10UEf0chxfHk3MeViN6 cZxsp3L2RxMpIjodWHLg7+X0kyKi0/smB4f+aC1FROdYnHQYvZwuU0TQ+8vhhdcfTsPJKY1OMpmh 19N7cgarrDH0FzSsESes048q3WrEGrwU0Omn5WIsWEMJRic61tjJKyGsIbFqRHcpSWlEF8qxvrdz tD9nQDpODgy8DKERRz2to4xTuY4ulMrS0Xknt3R03qGro/PO/B2ddxVMjVhjaC56GI0mFqwxdfXp yvpcXMcaK3ixhjU4fPXTEW9p93Sc6uY1S57uNzmb0sHyMkVH3eOcaVH84ADU0fmgO+7ofJzdo/NB NezofJAFyeUaiX44F9js9HTYXVRDj/rl4LjLGiqYF68mqHMOXk9ijSkKf//7L98r9V3l+vcvP3z5 4R9/+vHLf/zfP/785Yef/ud//+unf/vvP//ty/d/ueL8/bur/OEPv/uXX5p8/8313/3xqv95vZt9 a/LRKkLj3jLNW2bdXCasZRSie8ukt0z7eJkPbfLm1rq3tbvxHN4yd+M5rWXiRTw/tHkRnKdbW97W 7sZze8vcjWctL9d5bvM6dzy3eZ0InttwWrvoP2m+lRSeTaFC/koVr934rz/++Pef/vTTX//+rTOJ 9LnM2PfrRZ/nSSMOzYhDM+LQXmfX5zavU+Vzm9c57LnN64T03OZ1dnlu81r2z20MDsLgIAwOwuAg DA7C4CAMDsLgIAwOwuAgDA7S4CANDtLgIA0O0uAgDQ7S4CANDtLgIA0OusFBNzjoBgfd4KAbHHSD g25w0A0OusHBW3geZ6l756hbNmHYpGHTDZth2EzDZhk227D52kffM3JIqA4K1WGhOjBUh4bq4FAd HqoDRHWIaA4RzcoNDhHNIaI5RDSHiOYQ0RwimkNEc4gIh4hwiAirXDhEhENEOESEQ0Q4RIRDRDhE pENEOkSkQ0RaHYRDRDpEpENEOkSkQ0Q6RHSHiO4Q0R0iukNEt/qIN5tlNMl3bMKwScOmGzbDsJmG zbr47NfFJwKeu5APKJaXLzy/v2Mz5hOr53f3/PZ4c/OV1fpkhx+0fZs/v/bN61eD+SCnrjuf43w8 rs+nfN2M3zJyoKsOddXBrjrc1eex/I3N+K3MUBwjKwc5Sag5RJy31XkHj3fQ+WAh73/xySMrDTo7 CIfJcJgMh8lwmAyHyXCYTIfJdJhMh4i0KqNDRDpEpENEOkSkQ0Q6RHSHiO4Q0R0iukNEt5olh4ju ENEdIrpDRHeIGA4RwyFiOEQMh4jhEDGsTuZh8/iYz70zxC2bMGzSsOmGzTBspmGzDJtt2Hx9of2e ESebbz9P8t5L3iOEj9PyoS4+4fg8jHwR5/V56f2jZ6s+sXru4ed3ztd/futa8cTq+VrPZfCZ1Wfe +OD14fMRnvPdpsfjeTPtdWRen9X4EtWZKvfblOXzKV++eH3PyBFdc1TXHNk1h/pwdBdOBg4rBTs5 OJwkHA4R4RARDhHhEBEOEekQkQ4R6RCRVlV2iEiHiHSISIeIdIhIh4juEHG+K8CvKPD98f7exd+b w/FLd/zSHb8Mxy/DUcpo51cmUv0yPzAx+Mo5vy0xyzWd+aajvOkobzrKm47yptUSO4RNh7BpdcVv Ns046dyxCcMmDZtu2AzDZho2y7DZhs37SeeWkUNCdVCoDgvVgaE6NFQHh+rwUB0g+Bbds3PkL+fg i2Xl9dnuscp3yjVPrF6nsl+v9emZ9etaq1hW7YnV6xT40Q6f6/I5+p9ZPcf4Ex/G43Wo84sH5/GR rc+vHTwez3SvwXh9huWnFh5LjLfH+fmUr8+wt4wc/fzynSinvlhFid9auPj+Pz8QcPHzDnyH/uLb 0u3nc8CtmuXkqXT8nI6f08lT6eSpdCpXdypXd3jpDi/dIaJbbYxDRHeI4NvVS6cTfnJu1PdX8+81 UI5fhuOXYfV3jl+Go5ThKGU4SpmOUqajlOkQMR0ipkPEdIiYVo/3ZpN36pphE4ZNGjbdsBmGzTRs lmGzDZv3o9ItI4eE6qBQHRaqA0N1aKgODtXhoTpAVIeI5hDRrNzgENEcIppDRHOIaA4RzSGiOUQ0 h4ivH457Py48nSMen/J8dZ79+ksOYzyxet3u/Hqt/Ztal492+MFbOf/8VucHDvrk5Pn2CddYb4fc f/7w7D2fOxyFw1E4HIXDUTqZJZ3Mkk5mSavvcDJLOpklHSLSISIdItIhojtEdIeI7hDRHSK+vhn3 frB0ukzHL8Pxy3D8Mhy/DKsre7MxvvB9yyYMmzRsumEzDJtp2CzDZhs270cO5wvf94wcFKrDQnVg qA4N1cGhOjxUB4jqENEcIpqVGxwimkNEc4hoDhHNIaI5RHz7DsWvrDNeJr9PgHrdW/OzsT/30s53 uu8ZOUEPJ+jhBD2coIcT9HDSQDhpIJ00kE4aSIeItJoEh4h0iEiHiHSISIeIdIjoDhHdIaI7RHSH iG71jQ4R3SGiW63Cm43xlfNbNmHYpGHTDZth2EzDZhk227B5b9NvGTkkVAeF6rBQHRiqQ0N1cKgO D9UBojpENIeIZuUGh4jmENEcIppDRHOIaA4RzSGiOUSEQ0Q4RIRVLhwiwiEiHCLCISIcIsIhIhwi 0iEiHSLSISKtDsIh4vwjgfzzl+n4nn9IofzcyTpfUL9n5PilW62Vo5TuKKU7SulOtLrVXz1swviK 9S2bMGzSsOmGzTBspmGzDJtt2Lz/mwD3vmLtGDkoVIeF6sBQHRqqg0N1eKgOENUhojlENCs3OEQ0 h4jmENEcIppDRHOIaA4RzSEiHCLiGyL+H1SU570NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NTcgMCBv YmoNCjw8L1R5cGUvT2JqU3RtL04gMTQ4L0ZpcnN0IDEzMDkvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAzMDQ3Pj4NCnN0cmVhbQ0KeJztm12PHcURhu8j5T/MP9jp+poZCSFFAZQIgRBGygXiYjEn xsL2omUtwb9P9emnbePEYbcMCBtfrGvO2a53erqet89MHa97LOvivi+uGY6lrbF4rEvLY4+2SJOM skh4Rl205dCwRbeW0RcTyxiLbVvG/NGUixyzp14cS2jqbesSe+plzmapt8myHam36bJbjt1sOdbU 23w5PPW2yHmsKZaiOaFU3PaltZaSW06x5fl8zzlKS9G95UGfzS5LU9HzqZumlu+2NJPU2T0Ptj44 lV374FQ+z3FP5dA+OJUj3/YjlTfLkx6pvB055kjl3fKk+aLtR+ocqXx4Xkpehqxrph+RB30djy0X reUpjj0Pcqk8E0TatsS65kFfjLxY6VONNVdW83Jj1UVMcr1Wy4O8lEhR8ZxYZEWkTzNyRSSs5UEq b2vXSeUtKxctlfccGHli2bMukXWTI4sVuWpy5PpEy6qtWa5onge5tNEi65kFi5xcFrbr7EvOq+sc eZBLErIuqlm0kJYHebkhsqhl2SIvQD0vJVJUPQsXksp9miGpHFm4yNVPVFJZUnnLwkVepO6tk5HK e6IQWQ89MjU0lY8sdagutubboZYHWcZeIWt9Yvljra+Gbh2+PIXueXB0nWOxnNkS+a5pFqQvlp2n mhdg3lfMUtmzcJHjrK9xWCqH9zGd4ly/sFTeouuk8t4LZ6m898J5Kh+9cJ7KRy9ch2DthesGWnvh OsGtF84Ti/NU02QuvXCeeEmyE2fD5Xmi28z6xDrl1kuZpvPuokjXeUc0olupX3uHqRspuhm3fl3D CakcZ8pTuXvv6CWIjmkvwQAudToEay9BX/TWS7D1kvdXWy9eL8HWC9xL0K9Newk6KNpL0N+1XPVI I+WKdE/3FckVjb1fW1/wfv19taLPe0u645yZKxF7/0lyY+/j8iq72eJIKqOv0RG9nsu2dvK6yfe9 Q5AHx9ZrnyZPW2U580A7DXu3fXdw67bvLrdu+/5Oetusr0jqeOsTTAPnbtRnmSZv+avotu9V3Lrb 1+Q616Jt5y0q94i9v/Peexef9Tmty+cX9y4+u/jip+9PF/durp/ev/nw0enxxcdfpke+Wi4+e5B+ 6qPef/+vf7lNklaSrJLklaSoJG2VpL2SdBSSbK0ktUpShQirEGEVIqxChFWIsAoRViHCKkR4hQiv EOEVIrxChFeImJckd8iRQo4WcqyQ44WcKORshZy9kHMUctpaSaqQ0CootAoLrQJDq9DQKji0Cg+t AkSrECEVIqS0N1SIkAoRUiFCKkRIhQipEJGPSf0BqVItrVRLS1t5PvjZ85vLO6VWVlIrK6kVb2nF W1apllWqZZVqWemTt+ItqxBhFSKsQoRViLAKEV4hwitEeIUIrxDhpZuxChFeIcIrRHjp85ccK9ww 3yVHCzlWyPFCThRytkLOXsg5CjnPbpjvlFQhoVVQaBUWWgWGVqGhVXBoFR5aBYhWIUIqREhpb6gQ IRUipEKEVIiQChGyPbv9Xfp3AvLyjeadds/KDLTCpFaY7N9VrM9vAu+0x1d4sdKnSYUXq1TLKtWy SrWsUi2r7CBe2UG8QoRXiPAKEV66wagQ4RUivEKEV4jwChFRISIqRESFiKgQEaW7DHLiZzm5J5Jz eX3zvzexPiA3ixG2Ec5Z6bYRZIQx0n2EkeD7OcQYGW2EMTJshDEyhnQM6W2M3Ib0NkZuQ3obI7ch vY2EfZxhH3n7OMM+8vaRt48T7SN9H+n7SD9G+jHSj3HaY6gcQ+UYKsdQOYbKMVSOodLWldiIQlSi EZ0YxI24E9Fr6DX0GnoNvYZeQ6+h19Br6DX0BD1BT9AT9AQ9QU/QE/QEPUFP0VP0FD1FT9FT9BQ9 RU/RU/QMPUPP0IPCZugZemDZ4LIZegDaILQ5eqDaYLU5ekDboLY5euDb/2fOOcJxA+QW6EF0A+kW 6MF2A+4W6EF529AD9wbvbUMP8Bvktw09LNDwQMMEDRc0bNB29PBDwxANRzSwb3DfAL9BfgP9dszx nB/6G/g3+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4 F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bf4F/gX+Bd4FngWeBafv+d8 8CzwLPAs8CzwLPAs8CzwLPAs8CzwLPAs8CzwLPAs8CzwLPAs8CzwLPAs8CzwLPAs8CzwLPAsbPHC Hi9s8sIuL/Au8C7wLvAu8C7wLvAu8C7wLvCu8K7wrvCu8K7wrvCu8K7wrvCu8K7wrvCu8K7wrvCu 8KoyX6MPrwqvCq8KrwqvCq8KrwqvCq8KrwqvCq8KrwqvCq8KrwqvCq8KrwqvCq8Kr8p+rezXyn6t 7NfKfq3s1wrfCt8K3wrfCt8K3wrfCt8K3wrfCt8K3wrfCt8K3wrfCt8K3wrfCt8K3wrfCt8K3wrf Ct8K3wrfCt8K3wrfCt8K3wq/Cr8Kvwq/Cr96zPGcH34Vfg1+DX4Nfg1+DX4Nfg1+DX4Nfg1+DX4N fg1+DX4Nfo392tivjf3a2K+N/drYr4392tivDf4N/g3+Df4N/g3+Df4N/g3+Df4N/g3+Df4N/g3+ Df4N/g3+Df4N/m3eNcO9zdvnef8M9wb3BvcG9wb3BvcG9wb3BvcG9wb3BvcG9wb3BvcW824ePbg3 uDe4N7g3uDe4N7g3uDe4N7g3uLdtPi6gB/cG9wb3BvcG9wb3BvcG9wb3xr5u7OvGvm7s64YvDF8Y vjB8YfjC8IUd83kGvWM+2PBkgy8cXzi+cHzh+MLxheMLxxeOLxxfOL5wfOH4wvGF4wvHF44vHF84 vnCZT17o4QvHF44vHF84vnB84fjC8YXjC8cXrvORDj184fjC8YXjC8cXji8cXzi+cHzh+ML5XHD8 4fjD8YfjD58PmvNJE3/4fOR89syJ3nz4nE+f+MLxheMLxxeOLxxfOL7wmA+x6OALxxeOLxxfOL5w fOH4wvGF4wvHF44vHF84vnB84fjC8YXjC8cXji98n0/Z6OELxxeOLxxfOL5wfOH4wvGF4wvHF44v HF8Evgh8Efgi8EXgi8AXgS8CX8Q62wHotdkXQA9fBL4IfBH4IvBF4IvAF4EvAl8Evgh8Efgi8EXg i8AXgS8CXwS+CHwROhsX6OGLwBeBLwJfBL4IfBH4IvBF4IvAF2GzI4Ievgh8Efgi8EXgi8AXgS8C XwS+CHwR+CLwRfC5EbM9gz9i9mlmowZ/xOzYPGvZoDd7N7N5gz8CfwT+CPwR+CPwR+CPwB+xzV4Q evgj8Efgj8AfgT8CfwT+CPwR+CPwRwx/fLXQ/3qh3/XF9en0+dXVzcXnV49On1x+v4xS9b7Y6cn5 t8so2vg6YMi88NtPTz/efHz6aWmC9kcp9uTq5nTxaf/nwyffPH/xRY79+urHi3un+zcX/zhdfnO6 Hsc9Zx7/88mjh09O97697FPsb/ztSSpc3jy8esLr65uH/77Mg/Orf11df/f11dV3Fx9c3X/6OCd1 fueHb0+nm9Hb++Ty/vXVC6///m3++8LrDx5ePrp68MIb9x49/Ob0wthxnhz24Pry8cVHDx88vT5x rZ8+ffzDl7kksz2zwKks80Z+mXcwC+j1P98ZNVmArP9lxvmg/73C+eBYZn9kXWZH5Py3As9q+F/9 yfn5OMLchTAhbI6z0WCks/j/Woq3CO/ajSPert24Y59z/WZn8V0HcsQ3ogM5ajev7bW7kb8Qf/Mu 5evGd13OUS/Wm52vjc0OVubY36oT+roxbhff2g7rbeNdO7G/VnzNjq5NrmZ9GMe+LINPWJ1d3z9q F/iW8ZVd4l+KL3eRf+34e3elbxt/5+41+7i2ue6z7nN9Zv3Rlxfum551uv9sHfBbxj9qh/y28Zad dGU/1H3Of33OyOz+vvXd9lfFt6z7PvYjajs77u868iP+1h35V8V4RXytzj01nt36d138Ed+ILj61 +7N09F+Or+rwvxzfyI7/qO3sYr+13f/Xjb/07cHL8Y38NgEW5u/2+d5/AFckcusNCmVuZHN0cmVh bQ0KZW5kb2JqDQo2ODkgMCBvYmoNClsgNjAwIDAgNjAwIDAgMCAwIDAgNjAwIDYwMCA2MDAgMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgMCA2MDAgMCA2MDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMF0gDQplbmRvYmoNCjY5MCAwIG9iag0KPDwvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCA0NTA4My9MZW5ndGgxIDg2NzIwPj4NCnN0cmVhbQ0KeJzsfAl4 lEXW7jn1fZ10OlsnhKyEdNNkgU7Y19CQDknYIhAgQIIsWQhEEUEDqCgk6uASUMAVhV8Yd41gJ6Ak gBBG3FDEBXGdQRTEEXHHmRGS73+rujsE1NF77zzP/Z97/U7OW/XVXqdOnTrVdENMRB0AOvXKnTR6 ZEjdgEbigZ2IEh4emZs3IsoSOpno84eJxEUjC8ZPir9n+xmiL74hGjRx5KTJwwNMe34gduSikcPj J/XsE+6c2YGIG9FqyZTcsUV9Gsamoq0aooi7yueXLjz+YpflRBlRaC+yfMki25NhFYhnbSMKXDVn 4dz59ZED+hD1TCMyvTe3tGohOSkI/d+F9qxzL7tmTlLDAhvRSDfRslsqK0pnv/1ZwKXoz4X8AZVI sGwRiPMivHetnL/o6m6nOjyIvmKJ4uZctqC8tPSnnLFE+17Ge9n80qsXWn8K7o7y61Dednnp/Ipb 37solOhv6USWvIULqha1ppCcv2zPtvDKioW7Nq1OIuqPV0s9SdmZOnXLz7xz36xw12lzkJnk81Dy hFIZvvDAhFQj8Kc1+hmzE69Bqrx8EAY80XIfhH7ACDTe0s+05fgfTaaEeGgUYvIRZKWeciTaUfSr UvQDvIZMZDbdb+qLJhO9oVZKc0SkySQCtSAhTELXP6buRjNdnaNGgKdwbI6N3GTTlusnWpfLkYi5 bmLDMFC7TL9DzpR0/QDNlaURygGfZAvtpGPgVj4qZnAGfUJr2Ek7+AB9RseRU0fP02Hax5H0Np3g DnyAB1EZVdBd3IHepQiaStX0ABXRRqqheahRR8WIxVIPqqSt4CJqotU0CfNMpgIqp3fEUPoU63oM ve+iNZSBGstR411aBjk8R9toD0bTkS6jtcirQe5BuoMupiE0CL3eTaf4buHiu1AmAlSN9mVPk9DS OapDPS/t8JFszU8X++gsT8AorqPVvECNWomFd3IW+onEWOejpTK6CzyNPNDXAfQYHeU0TqGhmM1C +oxPYp63Uj3GMgkzq0Y9OaZKcCStNb7F/D/kFk5GO+sx8nJIPpDmiUIKow50BpJ00sdoKwJzkFwE 6XmpUtEkRTvYhT5dnCmI63kHD+FDkN4U9NkEybxDp4TLaKHr0frd6C8DqxfGS3gyl/s0Tq7LMrQp S1djnpKXG8fFPvS5RvEDeG9B7zWKa9Cyn3tAbpIrIbUi1JMs21mNFZE8CVKUjFEorsYMp0Fez3AC raM36FrjOEciHkaCl/lZIj0BWd1Ha0Si3CAiUSRK9LL/4WXIlaW92+JX4r/+iLn+CCjcx1uw3inY expGkk2NmKXA/DZyOMYdhFVBMtZrJ/IEX8KX0BbohpSRX3J+KXkltayN50F359EwyHlnO34ONbZB s/ZAVn551vjk6ZepV55L22Tp52Tou1zTd1X/kdC4AlqIXSnT/Yx86JeLbsHoQ1AumBKEGfqxk83k Ns5iPtnGjzATh+g7tVMr0OM7apcWQxpyj96JccyG3uzDGMrRQyK5kFtOZVi1lbyTprJOI3gKraSt Ihyakk2FNIbzMPb9GPdUrGEeLeY0xNaCFytNrgY1KT2uIwfkH0FXUTp6kSOQ1mIMFRln6EpKA12F ErEYkXcU1RhFuhpHMXXDyaWrtZsK7Y7GeNdAdtdCr6YhjMJbJuhq6ktJqL8WLC3Joxj/VZjnWBpB dlA+Wn+UbqCudCNq3Y7a0p48B4uwjfoaX2HFrkaNeeh5HXZ4b6oUyTyGR/No0ZW3g9bxOsTyRVcx AFq9Tri0ldTEr0G3H+CO9BBt4qt4NFa3kquwVtuoGVZjBfZfJxqP+Hf0E/2NHqQX6Cl6jTZhlVcg dw/9A+v7OcrfrfSzGXlNit9Q5G+5Apb2XLsrVJuyxbb2+CqsyDakPCVyeBWXcFd+iV+iMwKbij/i e8Ef8UPg/fwhv8+zYdl+4Gou5IFs5kBOpXtQ+jMxht/k7zmUUzkCK3tu/+0XmmCh8YP8MNfxfJ6I tA1cxiXQvWRVJJgCVEkrxiGfNZC85jvZLCD5PAlL+Q3dC/4GpR7AXgBhJNJOe9Pv5Rv5HYz8cd6P 8olYB2db6I//Bx6MfYM64YiisMst9CokdC80v5l38T/VOJWxQNw3P36Z/9Q2V3+ab64/Cx/gCZKV DCQHeGXTFl74hPjk4ws5HuvbLvTLFtp7WIXbsN9lvpmuUGEDN6j0Vmi1fP8eY5UP5qPm8iQtUe9z sUdvoD/TBlgSsIjDakMvqJQugkQ+hG6EQgMegiRmwD8wYR32g97BatyIXNnLBtrAX/BpPo39PY+f 4R/4U04R5ZCaB/smm1L4Y6R8yl/xXrT4EqTwAPp6F37D63SAL4XPdjsdoF3Km7ubboUGRtBX0PZd oJfoftiPm3gGaDdoF9/PR85Ju00KUlOknBOVPhCPBBXR9/QB/xPr9TqSpD2F3cQY7sOu3cevcjPs 4AvQ3CZ2YmfE8kzO1ZbRy6r+Rn6OH+Hn1R53KkpTZLTRPkig/fs5Go7S4Lbz8/dy+7Pjl/g4rJI8 M/ynw+/lC0+O9lyu/A4vyzHIPn6lDvfkKDoNhi2EfY6CHb1a8TxQGepLLoBmd4NtlefdcIwZbUEf VvHFPIr3gEYpukrtIqmJfm28YBf93vBXd9tv7MJf5HvB69vt0F/jC3fub+zgn+3Y3wrljvazCSQf v9X07fKfhX5r+hthm3X4ldBvLX4rbJMnrAq8zu9VHCH45bZ1/TUOxy71WVPf+nstkQyneUmeOLhN FOFUaeZNwoJTLoosIkF04nlIqeLXeBFoM/WWVkEkcPOFq+CXOix5g5KehpN+A23327n2jPYy4cut EJEiAWO4nf7FocoXuVf5Kh3hB0VC3ybA+9DB0ouORm6GYlmiDv6xTKmhZ7BTr0S3NbiPdMRu+lR5 dzthBTsiVXp2LuyuaNTbqjy7ffCd7oBllf6yC7tsKEpJT/nPij6EN7IPOncHZeBOc4IqcKMwgywY jxn7NRBkQV/YudyzzQ/0+5yyZ78N+DOtgq5468o8C0Ygvc0LbY/Xxuw4zwOV7LcDfu++DuT1aW+i E2rE/lbkjk87z/5I21KJO1x35YFdipi8z41TJ3wl3QxaBqqjh1F2Ms6jufQcfEnpIe/ErTICkuvo k14mSozDKbOWqhTVQUIfAW8HHcQ9S9KbGJ28DzZiPeSdMBtvp3AzW0WboWHbwHXo9Vr0KmfQRJfD s6tRORYflbXFnsBtMhI0nzO4OyiDPsdpyPCNcGvjFhEmwnDfcqtb4FJaKgbgRNkFdOGc2iXPAlVi nSIXb8LNqy+P5WLuz268u3D7A+IOJO9uWdg7Q9iF2u8gzATJPpK1ONWWt4UT51qTc5V14M/v4EOq T7tsTdVMk5+LeO+FkNtj8OHC8PYkd+bnBaG/XRhnGlo3y3rQqnfQovd8u5S3+zZQKt56cQGncAwP Zg0r8SakMAQnQH/vLKHBI+HNEngt9cFZLdd6FdZhI8iNG8EqnMpy5by6shiybsJN5Hl1Z78eWrNL xbahXh39C7qThvdM7PN74JcPVvYzQt64YAG74VyR4TXYkYm4Ucie4rG6kjvDv3fTLNSLwkxl7Wq0 uQ1SdolQEUoMSkO7U2mO2rnJ1A87dI06uWLg98sbuQX7aCr2t7zBrYbdDQHJU8wEWyX5eNt558B9 Yp6PZIlYSuLMtl0kd5/cAzj5VA3Zz/OQg+xfsn9HXA+PKx27ws+yJYG2FmFnWDEjuasnwA5a1H6N UnLCuOCr5PNHuIE0wjd5j4cCj4Ef0UbTJxTFU3g51hEpdBTe1iN4r8PbOrwTf4NbSk+QXOO/8rU+ a+G3YV47Vidv+j/jX/JENsJunrvVns/SQ5EWRFofP7f/zEByLLTCz/7PENp/ltCetypbmdFmidp/ znAh+z93uPDzh/Zshc5I9t+RpcciWVop/+cUkiej/iCkrcFcyy6gdo+RYCRwO2qfhz1wPl1QT4Ty cViFexRbLvgoUOrt2nYk62wA7TP2qbOpPZGxCJSAPXY+kfGlMQW0HJRgBMqxqzFiLFzDdardqepe vvi35vhbc/k9fbcjuevk3T0Ce3QA5AC9bNe28NE85fOnwQJHKenKD0fl5wbI8+a0SWA/SIblIFkT Hg2sW1q78fjbdIk0WIX7oKv+R36mmAL7lkmfyc8EcJ99EPvmGOzxLljiIej/AP/dR9LCjuZjsKeZ uCHIUrEizNeO1NIhuH8kQxPlpwiS1tB2Zuyjg7BS8vS6AVwHbXNwVyX9R+lG0KM0BSOKxSkkT6xT qOVB3jq8zUNeImzOUTqM23cER8Max6jb+Rx44mc4hg7Rt/CUImEZLuIB7OBg+qva5Rq9Ra2w271g r3uDNNjyNNjwIbDoLnAKcoegrYug36dRs5ha4JnbcMoVwM7HIE2m9JYp51Zas8Gvuonv4GtQdwbu hbtFPHx7/73W/2RSKOxWZ5z4ifB1OiPvCDVgRE7IKKutlPRIq6UFhec7EhShbFANdu5ByOBqbSXW IYE3oZRDeVmS1kFrm2DLruJ19BHugp+oW8UB6MIHGOd/6hbR/q7u8ysvvH//qlfv99QvCP338Qvv 5T/zrP2e+IW3DcK5txsoT/T1OO+Koe2naBzHweck+JnHoH1TaABwOVY0vO1T8gyli/XQpQqUn4Y1 WY41GIS2A9Xnj/JfFVZBOwZzOG7BvXk2SIOnUCB68WJQGbxjF9ZvHzyrd5AeBd2J4kIep7RnFHfA bf00X6GoH+dIzeIvoWEHlP+QAu3rjzWV52I1ToULrAxa8lKIly60bGwCtU+XHvtz2B3dYcvD1Vkk PYhChOGISRtep2in+sTOb9vlOYyTm6d6ifbSXqwv9i7mLvfqIpRfCN+kSPna8hSTp5Y8Bby322v5 Rf4YNw+X8tpqcE7VcLX3U3S+mithS68G1XAyTqwadaosxolcCZmbKB6SyOCjoGWgk4pcfs1g+Zg0 jeFUUqzpy+Bm+qfZwKkfYLRSEAXhXmFRGEzBQPglwFDgWQqjUGC4QiuFASMoHF5HpMIOZFUeSASw I/An7MNIYAx1AMZSlPEviqNoYLzCBIoBdgL+E3s2FtiZ4oBJCm2UYPwDtlFiF+oEdFCi8SO8J4nJ ClOoMzCVkozT8HUkdiM7sDvwB+z8LsB0cgAzFPagrsb31JOSgb0U9qYUYB9KNb6DxesO7EdOYH/g t9DsdOBAygAOUjiYehjfwNZIHEI9gS7qDRwK/JqGUR9gFvUFutVnudnUDzic+gNzFObSAOMU9tVA 4AgaBBxJg4GjgF/SaMoEjqEhwHzgSbqIXMCxCsfRMOB4yjK+gI5JnEBu4ETKBk4C/h16ORw4WeEU yjM+hwaPBBYpLKZRwGk02jgBv0TidBoDnKFwJuUbn2GfXwQsobHAUhpnHMeuGW/IT+AlzqYCYAVN MI7Bu5U4lyYCKxVeQoXGp7hvTQbOU3gZTTE+gb8+FXi5wgVUBFwIPAq7Uwy8ki4GVgE/xr6YDlxM M4BLFF5FM40j2BUlwGuoFLiUyoDXUrnxN7qOZgOXUQVwOfCv2IVzgDU0F3i9whuo0vgIZ57EP9Gl wBU0D3gT8EPcyi4D3kLzgbcCP6Bauhy4UuEqWgC8jRYa78NaXgFcTVcC11AVELdC4z3s30XAOxXe RYuNd2ETlgDvUXgvXQ1cR9cYh3HiSryfrgOuV7iBlhnv0H/RcuADCjdStXGINtH1wD8rfJBuAD5E Nxpv48Yq8RH6E/BRhY/RCuMtepxuAj5BNwOfpFuMN2FjbgU+pXAz1QK3AN+gp2kl0EOrgPUKG+h2 4yDOydXAbQqfoTXG6/Sswu20FthIdwCbgAdgU+8E7qS7DfkZ6r3Ga7CP64C76T7gHoXNdL/xKqye xL/QeuDztAG4j/7L2E8v0APAF2kj8CXgK/QybQK+onA//Rn4Kj1ovEyvKTxADwNfp0eAB4Ev0Rv0 KPBNhW/RY8aL9DY9Djyk8B16AniY6owXYL0lvkdPAd9X+AFthkf7IW0BfqTwr/S08Tz9jRqAR2gr 8GPaBjxKzxh/gV2V+Ck9Czym8DhtN/bCd2sEnlD4OTUZzfR32gn8QuFJ2gX8ErgHVv054Fe0G/i1 wm9oj7EbflQz8DvaC/ye/mI8Rz8oPE3PA3+kfcB/AHfRP+kF4L/oZeBPCs/QK8ZOOquwhfYDW+lV YwcZCtvbdIuy6Zb/L2162h82/Q+b/odN/z+w6ev+sOl/2PT/UTb9/yU/Pfd/0abn/2HT/61Nv+IP m/6Hn/5vbfqO/1E2ndRndZI7+b6Ze5f3G7l8P+nYTQQrbEWKBda1G6zYMNiGi2EHlmJHbaLN2nL5 XVpY4VTY0WGwZjKv9Fye8enPqNwoP7vpZ98CPu/hADr3BWIh5FeQLiiAIevqawKW4BAKC7dGRHaI 6hgdExsXn9ApsXMSDgRH1+SU1LRu3Z3pGT169urdp2+//gMGDhqcOcSlxkmUmzdi5KjRY/IvGjtu fMGEiZMKJ0+ZWlQ87eLpM2Da/pOP9r9X7f+a9N3Zhe6sYUNdQzIHDxrYv1/fPr179eyRke7s3i0t NSW5q6OL3ZbUObFTQnxcbEx0x6gOkRHW8LDQkGBLkDkwwKRrgik9zzGixOZJKfHoKY5RozLku6MU CaXtEko8NiSNOL+Mx1aiitnOL+lGyTkXlHR7S7rbSrLV5iJXRrotz2HzHMh12Bp52oQixG/LdRTb PKdUfKyKr1HxUMTtdlSw5cVW5to8XGLL84xYUlmbV5KL5uqDLTmOnApLRjrVW4IRDUbME+NYWM8x w1hFRExeZr0gcygG5Yl35OZ54hy5cgQeLTmvdLanYEJRXm6C3V6cke7hnHJHmYccwz3hTlWEclQ3 noAcT6DqxnaJnA2ttNWnN9euarRSWYkzZLZjdun0Io9WWiz7iHCi31xPzNJjsede0XhkTtHN7XMT tNq82Ets8rW29mabZ9OEova5donFxWgDdUXyiJLaEeh6FYSYP8mG3sSK4iIPr0CXNjkTOSvv/Coc eTKl5FKbJ8gx3FFZe2kJlia+1kMTr7E3xMe7m3AUx+fZaguLHHZPVoKjuDS3U30U1U68Zmuc2xZ3 fk5Ger01wivY+rBwXyQktH2koi1PxVRxGcuf2CZZliNyjIZCeGzlNoykyIE5DZJQMYhqywehGJ5i Ri3PbKzIJZ6gnJJaa6ZMl/U9pmSrw1Z7mqABjlNfnp9S6ksJSLaeJhmVetKmasj3xz1Op6d7d6ki gTlYU4xxmHrvn5G+pFFc4lhotSGA+KgAsi0tzuwJ8dvtcoFXNrqpDC+emglF3ncblSU0kLuns9gj SmROsz+n42SZU+PPaate4oAmb1Nbu6PHnNL2F26N7pBXmenh6H+TXeHNz5/kyJ8wrciWV1vik21+ 4Xlv3vxBbXm+mKdDTpGWIHwxkaCpXCjl9LbC8qUoxKMn4y9AKfXsxkAztFKlsG2Ex1oyyovFFrv9 d1ZqNL6RtVRwrppvmJ5M5/nvQ857P294IbUaBqyniPzCabW1lvPyRsAC1daOcNhG1JbUljYaNWUO m9VR26SlaCm1C/NK/CvaaOxYmeAZsaoYk6jkTGiroOH1Dr5lQr2bb5k0rajJCmN9S2FRg2CRUzK8 uL4r8oqabLC5KlW0pco3m3yjfIamNwizykpochPVqFxdJaj38kYmlWb2pzGVNwpvmlWl4cnYAae7 WWtumNzX3YggUwVbw7r2qZFhcKgKG4L6ZmX31JppIfhp8EGwTrOA1b4UjZKAWWCZulrlb9J2kgfc DH4DLFN2IGUHUnYgZQdSsrRGYm279mxD1yR0vW1rXNc+X2fHa1vJAAttrbYS53aSNtMXzvKFqxF2 R7jGF96mrWwYkhSeHYR3pq+BBlhgbhsaRo7v06QiA10qst6fsn4rUpKy47QNGNUGjGoDRrUBo/oa yGh1PdLXI3090ter9PXEqil7N19TvsiGhvBoXwoi2RatWJuCu2GSVuQLp2pTGvok7cku0Saj6acV btIKgasVzlI4XmG1yq1W8QUqvkDFs1Q8yxeX2LMdJikMl6hN1CbBN0jSJmhjVFig5eHem6SNx7sM x2mjVThWG6nCi5AeizAf5SIRjtHUd3q00XjPRTgK7zIcqY1oyE3qlb0Q77OQJ9CfTM/FGHIxplwI SaasBm8CH1Eps4DV4INgTZVkLReUA8rWslHDjTbcyHGTprlBWaBh2jDkDEXZoUC35lJzdKGUCz25 ICsXWnZheVxYHhcFai6gTetPvcBucAG4BGxCO+mol45xpaOHdC2DuqItu1hFUQhtvjBJrJTfo9I6 i5UNnZPc2UFiGxWAS8ALwTViW4MpMjw7CuVk2Z7g8eBZ4GrwRvDTYDNleXPcwSJLZGnjxXhNh3Z3 2+py9VFh3wHesFOiNwyJ7xOefaXWDWLqRhvBGobcDUPuhqn635LAAqqTSnvAB8FHwFLgqRBGKoSR igmmon6qKhWgyn0NNsAalCgV7Z9fxqRqJ4F7tmtFpqYhJQ1vaaiThrJpSD0CZFVD5heAV4P3+PK6 KGXuopSzC9rqgtH2BGapWDgwSevSIILCGyFfzgzPHgi5jwcjU9wGad4Gud0mNUTITdwTOVm+EqvB T4NNWhOoGygVlAbqArKDbCCsoNYZq7cGtBp0O+g20CrQSqxG1NPOPU4xq/+C/tX9V/ff2P/p/nv6 B+4UpaASUeK2UHQ0TsLICHN8tlXoNJ1C+SeFmxVeqdCtMMYdPz302PTQl6eH3jc99O7poUXTQ8dN Dx0xPbTn9NBGLnPHOEM/dIaucYZOcYYOcIb2d4b2dYZ2c4ZmR3AxT6VQ2q1wuMI+CrsoTOSpDaEU tIsvJrsZGs+p2+zXJx23N+rckHSjvdGM4Abv28XeYIhMfDapl31uUro3JcUbdLU/p6MFmsxPUSA7 3emBrwTOCnQHDg7sEZgRmBaYGugITAqMMkeareYwc4jZYjabA8y6WZjJHNVofOx2yltVVIBVBgG6 RF3FrfKbReoCxvKrxWZBY8jTQcsX+ZOGc76nuZzyy2yeHyc5GtmCM9XkGM6eyHzKLxwe6xnozG8M NCZ6BjnzPUEFFxfVM99ejDePuAVHVmFRIxsyaUWCdF+biDl9xW0JvrC4WNYpqtf5ttuKKXpJVmxW 5LCIwSNyfwFKfOg898Q6279gJImee/InFXmeTCz29JERI7E4H5KT3m6TGCQG5OU2iYEyKC5qstSI QXkTZbqlJrf4XDmyIT23iewyUOXIJsuR7YJyncVAWS5ZBt5ynVW5zueVqx9qz8utt9v9ZYaqMkPP LzP3/DJzVZm5vjKat4y9XZnAj8muytgDP/5Zmc6/o0zyL5ZpJ82K4c5/83ATjeHD9TlL5VWhxJFX AS7xrFxSGeupKbPZmiiHD/tuESklZeWVMiytaOTDjopcT44j11Y/ZunP8z1LZfYYR249Lc0rLKpf 6q7IbRjjHpPnKM0t3jqytPvm87q71d9dfffSX2isVDbWXfY1cvMvZG+W2SNlX5tlX5tlXyPdI1Vf SuuhlmYaXgzfVIVbRbAFClySYC8eHm1dOExp8xB77PKEHTrx4xQMVz0E175QsMzKyM7IllnYZTIr TN4IfVmxy4fYE3bw474sK5IjHMMpNu+SXPxVVfkiv/Ovqqpq0cyqmVUyVH9VixaD5TLJL5MvIswg O0Sdb0mwxtI2rwSvUjZaq6oqXkRqTasWk2xtkYRzjbfFFqNlrmqvBFR14SM1w0leRnNVixmlZMHF PrWpkj85QjMkB+lrhUg/Ab6DEhB21spwYpNxxMefyF90y/zWFsMQ76JwoY+9TyHoboWFPNYb0mw6 pL67fS/S+vLr9AS5KRzph0hj4iJy0Z10Fb1Dk41vkWqnh+hrSqfBVGm0qu/qtfIyeoi9v54dRG/L 76sJl+bUT8I4dudeWh3fQBlopZDuoRg6iBa7Gxa8bxWJwoVahfSqNsucbvQyvuNm/RWjjB5klzis b6HX6BR30an1RmOlsd7YQGH0g5bY8rzR25iPWpOphBbTdRhBDT1AB7hYDBV7jFvVb6QrkLqdXmUn FKoEHt1ElP4TraMm2k0H6T06zszhnMY1/DYfMlHLvtZ9xmijzFhAeTSOCqgGuYmczNlimjZN26y9 2/Jp68dGZ7RdSEvoarqWVqvfj79L79OHrAmLKBSTtc2UQEPVL5vXQmYPQJKv0BE2cz/OZDffxE+J JbrWsg8nvE4dIcFRSvpraT1k+gg9TfvoDXoTbX6rvrEZh8WfzNN5Ga/g2/kufoSf4i18UpjEe5qm Xa+/qJ9sPWxYjPuNJ9BvAnUiG3zddKzBRVjPA/QF5ted0zmL3xJOka6xHtLS2trXGGlUGy8Y75KD UlF2KPzaPBpLUzHqa+hG2kkvou4Bep0+o39AShpbOBKysLGDJ/IkXoxRbOavuUVEY/0GictEgzik ObUD+lR9S8u21o6tDa1ftxpGneExnjdeU+s7AP3kYAVm0EJsMbliz6CfF+gY/Z1Oo48ATsJYR3E+ 5rsO7R/hs1Ans1gunhIGvN812it6nL6udVzr/NZ1rVuNfsZY6JYGpyuO+oEyoU3yu3pV6nu1D6nf dmyF9hymrziWO3MvHs1TuIhLuJIX8EK+gq/l6yDVJ3gb7+TD/CF/hatjgOgIOTlFubhB3Cm2iX3i sDimkTYJd5grtGu1O7Vt2hva57pVT9d76WP1Ev0afakJLllAtPm1szFn57eUtdzf8nxrj9bc1nmt K1v3th5u/cQINvYYx+GK9sIYi2kuxrgM87+JbqeN0I8nMcajdIJOYs2/gyw0DuJ4jDhJrVsOxj0W I58Kl2kOqJIvhfxruI4beBc3815+hV/lt/gj/hqX546iB2gIdsFkMQdzuF/UCY94H3Ra/AvX8nSt j9YXt4oSzOZm7RbM517tI+24LvSOem99kl6tv2TSTLNN95jWm/aZXjZ9EWANuNhnI85ZEPnZ7Wti rz5Mu4w24XagaV+It4SLl4kz/JhI5L3oLRH3rQKRI4bAN9oJLZ9PUYHrA+wBdhFF1sAS2Ya4T2Ro U/UULYQWyV91iGniJlFCj/IuOiNGQdOWaAfEJjFLW6/foQ/jd3G/2KuTCOUfKZuyeRjW7m26AiuU oT2ty991ksmsnTXNF6HGzfoJk9Degh0cykLbz9P4FBeIaEhriLidHHi38imEo7ED34fmN8HtHKR/ rK0SY8SHSLuM7uS9mONOukzs5AexLoOwH6/kAt6g9ablfAWkMZguFXdRF7FQdIE+T6bv+QbuiJ17 BmvTVcwhXQsV5XRIFGPV3+BI0YOXQ0/n00qupXRu4WZ6TaylAVyh7T4b15Im+OwprtdGUT2f0V/R X4HzfQaSTITmmuFwH4VOr0cvL5JdS4HWDCKTwD0O+6kEez1CnObrxGV0Ca/T/s6PiGwaTxValRjB 97Se1rO1vpDYDliTnIDBZjK5TIl6P6z4CRqmfmNFAZX6EdMNMq69rf1gFBv21lmmsNaPaCmkMwrW bSX20ij6gKN5Jk/QDZGvG8YUqhNP6x8ZMRzCdnrTwA5rfYZd3NWw8RVGME+Ahs+U/8eJvlJfoS/W r8PZdAZW8ya6g+6nv+A0eRjnVirkeBGkOR225xKcEb2oD/XH7IbRcFil0cgroCmwpyWwknPocroC lve/6CmqxwmVD3nMRL05dCnSq3BCXUvLsf9vplWwAffQo/SmeFJsxB33FvGCWCIuoQ/oA+0lzc1T 6JB+q15Nk3AHnsAd0PNArFIS6q0y3kZv3SgB1r8fdin03jhpHDYebzmI9h6VvygLGE4nA3Iojcbz j3o8m2DfIEN9rkn+k0YgjagPCGzkkG2CyaTLiEaWABMiz2qaiA8KlGnPMsWZx18b6xxn/cE1tsU1 zvqja6y1BZd6V4tLcu9efSPsEcn2CPtcnc7atOazbhOdIZvejP100vhEfGIy4SRKovHu8MPBx4OF OdBCVu6wKB7Nb3d3CKX44Ogt1mFsGZa4BdeoQA7cJUbjdGjlcRTrtP4449SxY9Zjxygr65T1FEdE DsZf714wi1pAgKNLSqqW0r/fgL59ojtGaQoDHEhFktieImIiImNEsujpcPSoSHUOHdZdgn5HyzRb fLxNPBob3KVHD4flrHmoM901tHuGS96PLOIxba/+lvqtYkl9mKlR3OS2sCVI/o84lneDdoiHKVjs dofYIvZEHIw4EvF1hCliB0eTELu3mrH3G8XDz/QyL8C9bJe4D6f5t1zgnccPp6wtmM0PpyA7l9UF eWIadt8szkXQ14gAW1ycLYDnqmhsvM2kv9Uan5KUlMKfeUPcsI7iznwSO8NM3dxW07O43W0Rd9CW 1WZDdT2Wgs6J8FgL5HeqfXdHZdP2WPSin2j5vrvdLv9jITGj9Sws1AmczwXu1G4h3a3CFBPWwRIZ HRBgssZEd+g4rINpbFBQh01hXYmsUKe4Tvt3QK9iOW6F1JAZY1t+cFlPWdEblAMLNVgumFyuGdwv MnKgd50CcXhFRcaoteqSmiJSxAzXk6khYZFxgZfPnHl5YFxkWEjy427+rooFT3QEx0ZYQva3Nj78 SGvjKyGWiLjgLjymFRLIaD0rqn2j7RYkguLjRFy8LkccFBkQE201BWC0FgsG/d+cfQucE9XZ/jkz k2RynVsymUkyk/tkk8llb8nuwi6ZZUUUBVaLoK7LolYtisIW6t0CtYogivVWFRW03q1auS4LCm21 Wq0Vb9VaW7F/xEtdi5ZSbd3sd84kuwuo/X3fP7/dM2dOkmXmvO/7vM/znpOArpdBLkiAgHLfIOKS tes9iK93L7pg83IPu1ovQdispiO1lPhiM5Gqeplf5EVi6Tde7WeLKyOVx2IuGV3tb+Ex990Pj3kB XS3yscoWdLWIgXVRHdR0dBk9RoPcEw4DpNsfZHuoB2mmx26nQ++AHtrfw3FSD8vSsMdmo9+pd0GX HKG7l0s6KEBzgs35Rb/4gKzKmtM9vJfFHoUtzHnNy+aiZhA0RblqcHDRamwQP5EEXqqsVgMBFS7B fbgE94lw5TRz7D6/IPjhvbhfmYv7yC+gXnmdeAXmkUs1GdKvwKtgD9iPaOEWCv6D+CV4lbGFbYRt B7wNOMD5UBn3ucKQOZlRWJtKRAO4yptBTY6TMD/8VmNcdrhwWWKQsFECsRShUsBwgV3IThZCps58 FMPOXnYfKEzHf8gXLVLCVw8SSy++GF3TSyN/RZT/M+AGIRSfG2gn9ZZT9py/DarARKvpQ6bLJw8H hZMSrd0ntODms5mtE2bgX/Tv7xuZQ35sOR+59PnGBLtdhLKdbAVt9qPhsfYe+3n2C+HF9pX0Svut 8Hb7/fBh+xawBT4Hf2v/A9wHP7IfhF/Y/U47dA7A5zeTzkmgxz4AN6CL6qGfKpCQfJMbgNuf3IFm 5UDvMIr/2rz09/bCsYkp1SBsz/BpXJCTHcTPnF4PJ1sS/z45KTMun+Uhv0dmnMiF30f3/aEFs8kC fGwjTzjigyOfA3LkwIYcne60o37dyAGQGvkXENGvb+RfW0Ieu4f2EIMjXwB25PMNiieH35EZ+dyI py0hT9gT48+n1RAP8jBlccfinmgHn+2w8BaLO9CB8Ox3WxoSHR65/p5BaEWhk72qOr3sQTTDZeR+ QyhoMC63VaOn6xLjVCLPapLsl0XZJ3tlizUUVIJqMBykrCmtTktrGY2yOl0Ol91Fu2wui5XUYlzC ABEhYEDdmjRAjioYMM5EDRiUUaO5sgbIE6gxpaYpLjPooS8HrbUHbD30gXSx4eNUQS57Vc5f5nAj qipfjg2M/McwUCflDXGoCbKokRnU+D3lOG5SXtGNeqghveh1pMo7yzkHakTcU7xyFP+RTww/6jBe fxi/K1wmHCw3yY8b+A01FXzZp0Afa2JKSkM/xSJrwqFfRD+2ZjSS0uIxwufzonO/2NTIF8kPl591 x7Qr88oUxo96x/0orx7FirO6MnJd29Tr1nfpUl3bMavXE3/aXfns7ssnFqM3dsxevBuyuB+7sX32 0ote6ojL8cqeXdsu+n1HTE7A6C4cbXtR+v+Q+gLh5pMbeDo4MPKFwXBWQNuDRrCb7w5SdmaQeBi4 4FrDzrpcDPu0nSbwiAWN8NBiIeDTdG3rgI0PegeRdueIc7YCi512yYR3O7Ec5U4/8XvDAc7hOHgO yvfsU8QiJPruQZLd9CCc19vZ4SHWTIflIZzZ/W2AHe7g2woSZP954JnDThrqQa9p5VEgG8M3yyhM txA3wAjGreEFJpJFKp967YzsoGXqi/+c5kdQJ/GCn6qfbZU5xk3jfP4omok3USzpMPKkleiadfLW oFO3UF4ABmDPZofL2xGzIBQpD+OLa6gPbkMx9RcjG0w0H8Nc6rk6dXXd1ekH6h5Ib3dtytjdvEMs ulozVDqeUXVvSq2Lu7xO7Cnuj/kh8d/8sEjV0aMz+c7W2kRanoJ7EbA6oRuBWs8mu93hCgzALzeZ //Z2xIhQ0KNx+j2uI9npJhYi6ulHoyp6vZM4HxH0n4xGJXvwAA5K1GDoGyqj+d2LKFNtGkF1GlF0 hsIJXhKTEc0XlQwgxDkD+sNeA/IJ1NSia/ny6nyjB+iH/fopLdEazUIonGiZRBSbkbtabdZalqzh l9VqA7Zh4iqcWL56HYLP+2eFH7/sgkdkq93Fcv75206/669az4WVtwZnRbGRfnD5vk8Xfm9m3YIH ftgr2Rx+tv6+uW+vmnD64iWVd+7Bvvrrkb9SaKIAMvzGBa0QDCDUampsLHITEscmpiW7Wr8PrEuj V7feQt1UvLX1/uIDrduEQf+Lwovel/x/Ev7s/0T4t3+kwOH3bfbGkOG4AWTBEOqkacap13FkAV2I BCzxEJDVSJ2WlZHpN0YifHYAXrdR62jyoONmvsMa7ygNQLfh8HWQoVAbGZhQGEQmCBHLtzrltiaL 1f3JIFxWNQSCRZysp+/dO4Pdh+Z+OotZH7bG8F50OoRwEsOl6fLoh6uCZqi5mEgKXsqSbI4bULD4 DJgoagb0UrwBgGmX5eiBDq29/a2gtR+KVQqljZGTpsYSsotWtUiT3zwzrTQaI1UjkcKSS/85sODD PONnWe/ax2589vQtvWpAlo/pv+mOy+fcmGU5JyfNueSOdb87g3i0efMZP/3gtHqWZyVm8dZFx93w HRxLcFXP3Bvam712P1vXcdLOH8+6FeWmP+B4QoxMAUhnGW6UzyOEGrUo4ZCIpnXfFkV5WmR8/ACc Z/Aez9O+SDR6DkEirkUS0XAETfxWkqQsUdWtov4G4EHJB+UrJYTDQAQMGhN95ABxpcFAi+ccRQkD RoUoFNRB4gIQhT2GE8UQlGMU5XOhbPUqMkdizBz90xH97m9H3Hu4ncXMaQh3PjW5lEnIh9u5NsuK vH4F+wyKFhQ4/3y9ffTINNT3w2gRNnGjfGK0UwOiJo6LQ5Icfg2+9sTR4UAgfLTZVp7H7V3ZyhzY dzqZ+up3eO4q/xxFI9hHvDscRX7+DPZzNHNZ8Bcj5gzaQzF7Wp4gWXLp49N96QvSt6V/K/9J+ptE y9iJRezEAuoEI3Hay0YSYjgAw0oUPAXxl+xBvBwF9xp2pYOiHEBLCgPw/xl2f4cj0MEigTVIXAXS xILN6JXnJBMD8M9bWTmXpByjLjw+Z4huojkaGu6tui+m9IUhhNrYhU2yzI96rySFLPaQBeVvyY6a oFUxoEz7xz0XhbCu9/ZDbhQqMPc/wnPjMVuNvVZfAZdOu6bj7jf2b7roghmGJrGc8NMNN+16YNmV V0bciIhPwxBC3Vg5Kxz+y+bnvygmW6IiL/PX/fbB6x+bwkoikcM4hOCTR7MbQCgSB/XwEcOVj3kT zTFVV6OqNjhyEJeiDU+Rmkh3UcfRJ1Gn0tYkmuCNaH4jtWPMPMabEwMjrxsOjB7o3QnaPYDeuZSi KNpLeWmN0uiMMEE4TugRzhUuEa4RrkpsFzYn3na+zf/NLTihhbZFrJrMJCLJ6FmRM6OXRC+pW1xY VL8xtj3zB9dfHftc/Kk0Ij0sx0cEb9iniopfZiV3DCTcrqRTc8D6ApHPoiyStukZi9/qcScaUIzc vznXQZL24AD8iyGGO7yWVIfdLb1n7QAZNhPJ1GeozFPES6ARJGACuIgHtsY66j3QIzdsh61w+Ril 652Oc8dwrykWUQLBtt5bVdz+tmoGxDCVzEailMAyHMMzpNXldroJa5bKGDAixAbgzw0f0ByIyyUT dTQa1C05A0aZMH7GCZPulAHStpTpFtgx2HaTyWFc6zcTjsmWqqlHh+OuYnoKSjvYV2q+E48BnxfR p3HXgQtm3H/W1buffvD8p0pd5fr1b1w+q1USOTef7vh1Zaes/WzhonXrzzr91HZCWHzBu/fd+uXV 1z726t3XzF93VoyReb/DW3nyg+grW+58YvWVP/9OC4rK10Yq5B9QVPrAsiftJE7cVgRdGcJqJYmn 7S63+xwf8Pp8wIfIhMvv9LkAyULiHKeDY1gHxbqcgygSIfHQJr9dFj85hD7vnW4Sn7IJPAh3/GY0 4WBa4cnrHoxAR+RtWIxWJ6KIOnAU0Mnlww9gLCHJyuO06OElK7VAM8Ni3dX/eT7ASayDRyj8AdIM H5iaIQka4ArjKP7B2AvgU/CpiwpQik/PzdHPIixODyUFPV5plXQzvIO+w3lTap1+Z+5h+LPUZmKn Y9A1qL/keEEXLoH3R4kGbw4xmw2huDow8ucN9fH84Mifkdj4YhNH19Ul8FimLjY48glIjny8IRWL YhrE63UGHe9Ip61Kh2ApdFjd8QH4R4NNp0VW6yDfC3SUxZkiIQ7AIcPZFOlg38t22OXGI2QHctED uIqCoWif6ajYT03XrM81BMOcj6JVPmKAkBfhUN6GNEO9BaXRMIcQKehDTY4uGKABCYxxMYET69eV BOiFvf2gvwsvCOsjH25EagDdyIcbkUjAR6MeaQSLhM4sEupB3IOSOeZ1lX0SerkPj/nwmA+PHSYN ThnL3wgDW0ah0KyPtJhpG0kB5NvCIX1SmH/envXr95x37mmZCW/c+tPXJ6Td9/xgyT3rLrxonf/n y5b9/LGlSx8jrm16cN4tb799S9+DzcW2E85Y9fLLq87onvDRgrV3nnvGTTdVbAvvu++C7z/0EMJF AeGiH/lFEjTBbiNno6mMTQf5RxKDCauGQTKeRY1HQo3bozY2u2KoaRSbsqmsDzMxpqfhff7L+D8y B/KWnQA2YJTE7xrARheR/T8GjWiecuhdVu/mhmcaXmug5tLuBNA8rpSzzp5B6g/13BoacFNMIt3h sGA8MxwFBGiOaIfo1gYRZrmJBwxHooMJFAPv2TqyTxEPgeZx6GIPDCOidRC5xvug6g17y1U9wZnK tAZcqVQ+Fqd8bo/LQ1g5RGcE1stSVksyY0c+UudEPpLSYr4ERioB5iksNuk0GvSgJs5G0fhmkLMW xrDrEPACvToGrH44hmGobwZpzap+064mWz4k54Fic0obN29LidzZuXHunJ/N27n++zuau9q0m077 4TWntgUkzuVPNb0BG73Fu+afd++9Z09c3BQlfrN4yXd/ee4dw9eveOz9DRd231oox1iJ8zsF2PRB 5q0Xb9p03cqNhqEjO5u1EvIM4Eaar8GwMxtEJ70BWPntUESYQEFxs9Mpy6Hx4kn7dLaqIsyq4WEl FOHbCirjDXlGd8vEGfh3eM1YlYWArSMZEphXIYGTDW6XZ7fnLXaP5yN2v+dL1uZHJOWRjfUMZAZg wLCj62P+wf5SpAagaLidzZ5XGRGKb8vAWrtKUIYICA4cqJbBhlC3Wrk77PLI6BhUErOSrTO7W1Bz wmmQrrzvkzkpYj3kUn9XqY/xqs+FvxIenAE6qTZqOtKxVxrqk1ZI2+0JAL3A7gC4FpwAHOrTgKN7 IL5s4OjhOu3wEeCAO1CGvRXp4UcBDXdssG6DA8SjyJ/R35R5MHO5NADjiF7JBSiZKXfv0BD6AfIB aUhmUbOCruI/OkpmB9+UAGvIAGEt+51BrhadnBz76iBpj8mcUySmwn+7ZE4WKt2VbgF1XOhfvBnd xXnmXVxtxHZaX3F97iIPu/pD76qHM+8E3VGnE90Jvgt8N7U7QWnsUcMFthWs0IpupPsydCPRQ29k eO//4kbGC16wFgXUeV8tMe+EdHz1r9qdVKzmncBfwF9U74QAb478ECl1DnSAqbB3G2BHdm0Mqc38 wMguw86rzW4DNWV0thEdhdpRMo9Scxd+lR91BukdBsGzBXecJb9HRxTYUWobgB7DUSo1dkBq6qSj lAHSYtjlhqznnUk9jo4BkjQ4KnvUUbLDmsjKzsjjbZNKSKccbbhFx6RiKTFpagKUIBKG6zZ0Zm0D sGA4RV8iJyZy3VmY3QE/AMeA53CBHBc8kOBA+nz4QO8wJtVIg7AHTKaFEAtLQ+TJe00SYEoOth30 mrB1Yrkr2WyRMnpar9NTuqZbrIKX93Je1ktZC1pTsmzvrANSUuwDTL2vD7gbnXWwy4LGDHpSHfTr ch/w5j190NXsqYOTrUfVVfFLH01Go+xrdPtPsRYxpaYarUK45eO8fFPjWP1+rIjFVYtYoo8zc5k1 TlpHsYzskTP8ZXf9+pFrzp5a1kP1UzbedutxHMtJ7fPWdl+VC81g/dcsuPvEVed6vW5BOurHt5x/ Bpf0wryTom5bcNmTp1+wOiEnyk9eWdn8q8q/prISG9E6JjaHb51wwiLYDcG9P5pyz/zhXQSidz47 3AN/NOv4sy34u7U5AKid1I0gA/Jwi6GXODSjwUnZltxU/tjA8dmjc918t9gX6Mt2577IMDrIZLJ5 SBA5BztA3GeI7jXudW7iXTd0pzm3m+UUB8fH0/gpj6Y1ZTQtnVHimaydNIes1iaTDCp2IicL5pAo zuZFUeAVmediITx0TBiEl4VvCJO7wzCcDobDoaASCwYC2UxGDQa8wWCA5ziVyCEdnEvE4w4UmVDV mXw4T+TzdjmX1QKCFpCJwCA8GWThJMOb0YIGYy8DDjLBcHBPcH+QQuQ/u6We0Licxg/CSYBDvs85 yhz2fRa9luEg4GZyf+dGOAoFenZjYcoCFMLVUlw/8oUDpnfi7rBZk8PqGHOsXnOhD/nrCospjVeg cF5xBVLI9Fh97rPe/sKBZw4d+D+dmu+2ISqMf6sLBuQR4hrWPDIKj3iCJOMkednwW/33mCsWv8Ft J1z8hVkBfBDe0WkOP4dF+PqbPgy/B1dUXhoV3+THeH3jP78aE+MriDOH78Jro3OQD52CfCgEUqAR nm089UTmUf03jmedbzosazKr9Lsia5Pr9MeT1ssSS5OL9R/k1jjWeK9NrEnSJ7FnsUsdi9hF3CJ+ kWCbFpkePTZxnH61x9LITIxMiE5IljMT9SnMVJa2F+RIKBpMBjPBQpzJ6PQl7I7EcwXy6MixyQsj V0dW1d8SuT+yOUJn6ZAo6wAoIkFbdAgVuj7iIeN1nsZISklrYkqjVUVtaGwUaUKk40nGFXYVXGXX TFefa6HL5hqAVxrpXBKg4CMY7gZuF7eb28Pt56xcoDlVp0JzKW8/TlBN0y6p+gRG9P7aem+vWTjB agXZyywHsNUKVq1ke3ihxMQsNZHlvQ6noOnJjDeXg0lHPAezfDoHEk4tB8E46wb9vbC/v78XPZLc qJFNkKkBSs3QQhShj6nzoly0sVQtc0Uh6DcXr9i7nr3/yku77z992FzYeham+2Z2HHXzRZWN8OET Lp50yt3XVl6dVTX35kvv6CvcOXfWtWdgkxOleOjclplXfSUec26bcfEkvJN/5F3qeOox0AreNS7O eWEBlMFMQFpEnzjbf5b3u+L8/CLvYnGRtMnvaAmV6qeJ00o9/p7iuf7vFa8K3V5wNDUwkWAMApL2 iP6WxkhcZdyA5J3xTTqfbHFeS6lJvYWkCN3u0eh5UU0LTAhqTEO4odBQbqAa5LYVhxhh+hBmtsPD ePrNtZbq7JvUtra+6m/DLBeRH3DcL5zfOe4XiRNORXolhNQZyvJYgikjn2wWRX9IEmu65hQsa1Ck j1Z0awI7VUN7mxUNAZOP1vAeM448WSw282iEfAvPo1/g/IRl9pKbT59taJNTIchuWvBoN+fjRf3E l+b3zD1m7srGqz5YsZsKT8Qm+SgckIKzOk/Rw7kZfUeffNOOyt/m9vlEzl84rTcePObRn8x59HKI PwSCv82OuhDFnoKgzmVEr3esdF7DrxRWelf71oTXRFZFr0utSq/JuFCWS0XSoSje+my/PbU5SnTR fgXjrTOQBoGAAhQ/TeDzoiVt1toVmsszYVUUFdVP66rdTqg0kdAYRDmZCEMwgXxWVWEEWZsAcm47 bIP0eG1kPBgwLUZBYDZYtf+3RQsUC82RjMPnYdyMi3EylFVLppJ1yXSSsgq8lyes0WTGkcjDiC+e h0lGz8MYH87XimZ4iatWiEf5+dD4wEtE2G62cSQ0owLriZQZGcpUEwKfOfeJ/My08v2rzvxRpR2P rIUN527rlROTE6tPqLxcC4qTW/vOnT5/yfLPT52Mo2LVL+feNqPjlO7ssSgeTkb2KCB7FCFvBPrC C61LrSTn9Og8rzhjoXAxHldCpN2KuRajlvHRyDJy2TqbQFnRG/DrgqAEmvPYwYkGvVhU8qkcrksR GV3TlFx4AC4w2gME1JzxhBYoAi2pAuAMEE46pjEh+PfQSIgIdZIasMNu+3r7bvse+367xV7UtDzI sTkiN4AyophMIiKr2k8UCvzf+f08yculaQulmuWGhnHV9wDOZGxvP5IK/TU0G66WffEPQq8hwP6z 9/X2sU4N0cxTXR99YmwcL0lBbnRZhBurA49aiRst14y/pjYCTyKuxtP+1enYIv0mhpGL8cjwA9Cs WSIrSESxEjbzWGXTeLaqvItHXqoc12c+8ylu+5CV1iErLUFWagafGXPnWSBjd+ksq9ijQbUYiynB phxTH64n6vXmZiWH0kgJpxFe9ukcp8haFqTZNJHWk0klG4trcjNIJjQAZGQVu0zY6eZkLqmBLJvt zpJZPN/ZRCIOoMbGNBCMBInu4PrgbpOHWIInchEWAnYZewO7n6VYuXhwG46jsZSCJp+t2QMX3nER bLh93BZHzj441Aq932AE2HvkmmDNBC3/3QZ3VhcLK8FRGzBOlbwLT/zwFYcb4TC+4HZ8swmQDZah zHEVyhztUDNaV0fuiBAFtszOZMljXUcnZjt7XbMTDzgfSOywDrrsVNwf11ypuJYoJawl0HYDaGsD SqlYwIDVxDTCxlK+sbGQV4oOOpxicwJU/RJKT7lSJqywZDTYrpUKWunsYpESokkPiejffCPi9QpE JknZ1bPz+ZwKIQhMSmkMHaYJWu5YsfCItGJu5GJNCWLiGWZ7e8fTS7XAXytLHgZzvVWcq55gYXdI 5ul0IHH2CbDgb2QZ+Rik0W/dyMebE2JMjI/mH5SA+ntxAuJwZskTtcTir60ijuaj6tIVOqVwLhoN MEt1nZEqzNvZt+Kl62eu/HT1i6ttuPYp8ZwfWl+5bMn2E0oQvHf8j+ZUTQVvVgOsF26o3FYsdd+w YeUdq6Bl1cIGLxNQnw7LfuWkBWdd33vh7a8cjNTBFmRiCfoFt2hDFj0PRdVCFFVd8FeGi79HfLyw UdxZoKpSwenWawohEDGZP6tARY8qSiSqBLKN5hAowEK6qVBobFKy7ZPxEMuUw2WirHeVy5O7lPaq jnBa9ZqMqIoIp5iuaQg9af4dpg7W6Ym6umRC0ScW8VAXaIWtenNra7FZmRiPqQBCu9yoZbN6RAsk NV2vaob2iRMdSFA0qYlmNdFlhMLN67qe6CLWdL3bRXQNENuN4BRejUY5tZ4wiBsIciaxmyAYoo9Y SJDEDmI7OAp/GASYe1dQ5GLyh8JYbzerQzhi27FSMDkhbrkaRTzSVb7x7NtP/tu7jvwbJgKYJdoC LgYw3rJooKaAEtFWj4BOUFMtt0a/tmRXg+qxJb3o10aOlBtXDr9mwnXlHTPsm7Gw+NJEECK3SA3I 4S/xSHPf6Gvk8CKiVFEPlxwmkB8PN432vxJHn0c+9z4SIB8hnwuDN41cgcpb4q6IO+KN+AqhgjrJ 0uSq99b7yqGyOsPS5TK8hu+40ExlpurDn9RDnuMqmVs2kCeFzfNQCYRCYaDIVS7kRMhf5UISj89T vhLn8/GcIoU1mddkiSA0mtHsdhqLUG4mC1k5svpdaYwDYasjY5fNYsb/wpTfZK2v7eGIHkL88R61 I/Zx7DFJ/s3mat+k8ckan0yMvo8i9H0CzZsGPjcu/yG5VLjUu5JYTa4RVnm/EGk74fQ6feQdxF22 R2wfsO973xetFHs2u4Xd4qUaaS0SLyKBFZHDoT9JkhK2MbzTSUXCBI/QVPJjKDXcXBkYLra8B8Bl 6N8L1DFne1SatuEnbPiJZTZok1N3bYNv1NIdonAYY/fOqEns2s7ZIbzXsICw9ZukU4wVCatP9KKW szAIdRmrTSD9OchaEQaLBJ+rkkMcenqmJqB6a9v+UrXdfiReFcN66YiZJZ/Ye3ff1gU4scHpP512 4rEtPZWt2GGJs6uTOxy4fc+cM2HJdN/Pp06tU68/gdg3Ns0Q/4+C1O1olicT3zV6pZxUCnQmmopN LaWp0Z7Oc6ILOi+KXt65yljVebuxtvOJzu2dLzYJDCg1TWma00wxMb10dHNncXbDM+VfG7s66WAs 2DA/Nr/h5uYncg+XPox9mfuy5GicDEDDqDfrh3mzB4RgqCmCHDqiyJl6s2ATyd2QI+pzMJe7oSGX q29QMg2g6useYIGWpsPc3YkIT9Xd03F83q0xWlir10hNj+F8o6Rj0c5mo0SVJ8caAA/UaMwbjcZA tCFGRWC9lolrmXRabojFIiheUMBIRGuLNqlcpmlWM+w0GCAu3RSNSvbGAXjy1sjkyQ1gstY4CB8C MeJSw290N8xrWNRAggajobuB3NOwH3Hizpbt8GQQAWVYMrijohEcd4CF+3HodU0bhLPGRYgpydvb ZfZAYFhCp/0BvLEEg25ANrF3SCoHhkxYHm43BYq5L7Qd73Uw0/qKvI53xsnAUNuRN4daUCM3osaf Q423rlwtDZ6ywnLFMwC/QTq0TlP474h9aIWnt/+/grbNw7a3V7dcbQOxkT0b5UQzVnIb0BFdwikY JkyJ+m2QHR0FaHgEYkO8n84/ekZoKTh7rbkRY/0414bz8Mha4qjT8PFfeChWaTznmnJi3nw8cu+P N62AL1RWfR1ohv9DWMYQ/MzMD5d07jc3w8x/OWMyQBQdJ6PoiIIFRisSSUUskjAFR9gSRCLpTzVN VMSaiNCcQSxzGDu0BxCbVgVejt1/ySFb7ff1InZcXYoZ58BfY8Z40+/4Nt9vnif4BpE392TNwzf7 /PPmLLw/CqhwBk5UlblHgCoEErqfXeh+WomUMeGvyj6VOBpMa90FdoPX4FuhV5SD4CA8qDiSIKWk VK11amhO6CF1m/o6eB2+rnwMP1TcJ6vQZUaesA7L7DCS2WmBYXhBcYVNasOCWHeMiKW1WCypKeGC SW6cjU2lxsZiSSk4LeY53UTRtIVSnEFf9Y9JkJHCEiGlvZLk8yrBfF014vVundDTKV2vSyn5gZFr jZACQSSkKCokvBC3aisAqqJ60RCKVsVwqkktHFbVkKJBfD4tFAq2thCkTwsS+UKqpBUKTqeLEjQX raVaWxVVVVpKasoAL8Nwqi+1MPVEamfKkjJS6eaUwReZ1JrU7tSe1H40NkC8Z/iUMOyDxBr4Mv6+ dCoUogiCUgaISwxRiJCUl1JnCi8L7wp/FyhBbvtVTbNOx0EckNkhiWsrVH96+9Fpr673S+y+gLlX CY9iATVcjXF8KGN4ME+qkY88B5dtV1xRXYaxXME+o0vfTq36///4Wb+Z17+POH0/jMOv74waDVEI v3XzVJy4e17lKXatmXhewO3UIm5/DyfBtt+bnKq6n+pFNYhCl8cbp45kAsNZ4vXD6RT5MY7KPPLi 5ciLs3ChIdIEtIfkEPEcAZ3QGgxCMUg5OdPJPGne4+FQxCb1qjMh0p3O1tXpWSXpoMyX2JpIm40i EeX3mud+HcWKFwVzQsXnsWiTEo2qipIIEpCHaijoRd4Eg0DQtWRS1RIJlJgu3RL0aijyQ6hrOKDT 4YC0ElIhEmdGEICskSwy2ZnZvuzC7Jrsu1lrNpAnSJUP4pcLfJ+wUFgj7BcoRoCCnJtw3pio68eV DrZapcJUY1+VrLXXyFr1MwOmpqtlAQbSCPGhlwuhhg2auxNOMUv7/2di93VSbsJ3NP6tAN4Ej4Ry ilgwfEsVq180N9CZWP0OsWAtRqcqJ5lK+b/qOKJ+/wH57DgPJMD3EA/8HlLhbiDDr4yR3zLPygS/ T9wnfcl+yR8QD8jW58Q/sn/k/yC+KX3EfsTbAmyA94miRD3H/5s5KJB32W9x3Uc8bHnYfp/rBesL NH0lsdpyHb3MtVJY6buZWGuhW6wtdJO93TWBbeKbxAkSnSF0V4FN8kmxIE0kbDuYnewGfoOwwfcL cac0KNOPMY+z9/P3Cj/z3Sc+IT0i03OEE8ReaR17i3CTeKd0u0xPEab4pojTpOPlU5lT2RN5Oi1N YEpCi69NmsFMY6fwtNPqoIPWIJ1mUkLKh3SxDClaYNwUsPkRSeWSDtKTxKX8CKgH64EFXORN2uSN ga5Lax+HwJv48IK+WTL2m5+hMh+49o4it7cX+cRm8X84+xIAJ6ps7bpV2ddKpbJUtqrKUtm6k3Qn 6S1Np6ChUVEbFYQGIsimoE6Dy+A20o4rbqCIyrj1jOKGInazNKDi+FBhmBnwF1zQGdCHyzii6I+O I3T6v7cq6U434j/vibm1pJJ06p5z7nfO+c6JzmPJU30DP/TCLdk38GMv5czbEUXcRLvzdqfdm3ei QQsX614zg576Em2VfQPvDh7rKXT8OtpqS1sr2kKgbEOvk7fHRBMEzTbOSLVYfXAAiFpjZfLG0hZH W9KWN5S2TsQ4MVqsLcAEB4Mf7f080x7JMYZqeCAmxiwkBkWQUmdwRK9HcW1KcfHt3yzbXdwNsruX fb1s8tevvHQcqNe88jXe9kzx427QAUzADKZ2Fz959i+grbjroy+L76EfkcWxXmhJpkNLEsCqsaOi U+FSuNU+jLW6KTbkzrrHubfEdTEq3DfwtUhe5brZhYc1Mc1K1yoWH4lnf94bqxmEp1WSLxbAfCHK HMwH8WDQCV2yaMgMAbArWQ0hIskkfhhKFJTD0yg6jbyLAiZpeFCE9z4IvWI46M3ID+4o1e395+4a YoCjAPQpwmxlBZao4KFSbibAg/Uj42sQcXzxwofjaydMbDq/+G9gKDwx4bnfFveDQ8Urh2v0n5ed 89tQg8s66byrW+Y8Juu0RdLpBNYEdokzb4vfmroj82B8deaZyFOxJxMaamHNgjSuCxNxd5iO09UC dkaqNdNad3rjhKZCcFro/HAhdV56cmZK/fTGGU1z43NrLsrMql+XeiLTXf9KalO6J7O+fkvTm/E3 U/6UoR5K+6YmXUoTRLvHemo0aSSsHXFDWBOtjjZmI/lYU3VT4+nB8fG7g3eGb4rfnLg5tazu4eDD 4ZXxFYlVqdV1a7Cn4u/E/9H4U+qHzA91PzV56uobmxSZdIqoEvwAApCAnw5Ad2M+1FFo+M/v0c9X 94FlopUIORoETFsbijqiREBrml+F9YFCDzjCoeXBmU2GUBiWq0pVdVcpq5ZkQwKTgxreN0iPg1pO /tB/GIX18kkU1YP+Zxloqwde69GSmXjHYeZTJzwvQQPTb3YMWYQy51/KOEjMN7Et0MyY84m5Piof j8AhgSxEnQ8OGTTUoQqaDBrqfPC6OlRBk0FDHaqgyaAhTkOFByO0tAMUlOoSDWowzyQxC+QklBzC rRfwLNJfpMXWCg3GL190Xt3Uyc1803iPgXLobGc01MXuH1dz2rxRtNbidGx7+huo3FDBi3s/HFRv fpKFcyQph9Wsd3JMncFiUTppmrwtCs74Ail88Znit8Xvi0/jcyvVHpcyIK9Cra/G6sHvt2D8wA7x bI5vidMOZ8v07Pyaq2oIdbyp5oyaaa6pNVdyV1Zdnb07uyb2XM0eYT/7DndQ2F/9jWAxC9qacWwb f3XVLewdVfeyf2DXVu3kdvGfxY2+bQM/YlrM/LMWYrgDmxuyECwXi/Mqf3VVgE1gdSVvtBrzJRNI 6RNI3xMJDXR0hVgMxXPYrfi1WDXeLRox+EV8ZDrkwQQgQPHauNSz3APxCIiIqLHRRH+3f6//qF/h R3jYbBFJkCSPkjjJNJxx6fD8cGHx4cLhAilF9KV6MAlvSLwBaIjLTmhltvg/NTsN2IT1VCmm3MMa uK0Dx1Cz7w1xQ9bOwvWpJ8PVwLWmzNQshZRR+covu4xq+zDvMJQeNFiTT/YTTzz63i2PTOu6W0RH ix5Z21n8/tNf9Z7z7DXF3biueMZws/XWb6Y9nm155DvJIXS8mp008dKGSQ9B/LkFIhIaWq+x2Idi bFT6THd7upBeYr/VfptrmfuuxtVjdKdzbaNxJBLPjn5mzH7HZ47vHWo3+pJWZx2i+nfExeionMtp VtIYqDfVpgJEIoOyyhY9IzQ3ZyyhVv2disSd4UyIbyUUcNnhpeRyfWimr9OH+1xtdEisEQKCOLoz ujS6PPp49MWoMsqMe3QrYCv434ePQKAo18XKGedyyrnfIpWtyDRwmfjvkAuxEWsWIPgwMpss0xp9 OEpVlkhrZQJziRFZYm6HhcE6AGKljOQoB1A+cfOdTybOnDV/7egpHZ/914c3odsqP7Ptscc2t41L PfT2jBnvvLBe0eJBs/OuDyWYb11+Ye25adbi8YbvuGDF7mUp9NQXKPc848HHLh1zkc/mCpx22i03 v4r8guVQr5ul1fweMWbWGrIoYeb3sHUopYlrlFmUI7My9jroxTMBCjoeOFQjpg90biJJiw++BdwV OdKT9Mzy7PEozJ68p90z07MIatOLnoMejecfIeTQoejfsVLVSV5afEcksU5KaZ0kwvxgWW95B19x QIqRStGLA8VnJBb4C+j2DQ+RFv+GpBosKS6TtgH4vc+D8ng9/N4p4N+GeVAj/oEfe1jSgwpE3RDp +Ze4D6s+83zJ/hv/XvW9+0f2OKfV4woVcOvZW9wPq1SUU/bcbaQNt6UZm83JeCk5HGfCqkF1FKuu TmHemEUn50miWqNRp/Va5JjbeCFdirWloGUKCNGoU6B0AmXBvRDH+nkfAJ1wbnAz1o7NRCXBtYzL p9G0a2dqO7VLtcu1Si1TU+H3FKSwKpLawlCAddDh+V+lG6TqXMmsNJQiq/CODyYVyz6sxHOry47w Y4j+r55etO7a8T6XyeCTvZaHX/3tecsuknxb+YSipX/MS0dnv3U1/qqUUpS81zF3vn7mY3OkM+X4 C1laeeKgQ/SoMbUzhZ3pPCM+y3sfudf7b+e/47pnsGe8uIGW809k2kaStM1rsNn9MXQKGvhFAo4J pDBL2CsoBCEaF4RY3OuPY3op8eTsVANUvd2phn5tFFerCdyrxwHPoCdP93rTTq+XcXp5p8OGA+CD XxDqsjMOAYzDSTscToc9JvgZgacFAyHo/TxvMOhx9HuAcRAXUs6JzvXOo06FE6WM9Q5cSNpm2rbb CBs87h1wAMdWcBNmx/f2VklctLmIyv1Z4VhBYvgXJF0pRzHQv2SyHMv4GQraSIqZFMv4xROlaYY+ aommLU2hzDoKgPTPncXXXFXsGO2gjUbaARqdVqPJ6vg9uFUFbux20vDACRrkraho0doMBptWHk/Y iS8rj5H1gb6a4kk4txH8WxmfiU6bE7c7lCoFdOwiLlolcAZcG8RtUXnpRIajWWqrINWiiud1ujrd nZ5O7+32Wx2vKV+jv7BrZ5GzLLOoWVbFHhyQdtIh2kWHwom7HT6G9foiUUcdXmevcbThbfbRjg4w 3T7VcbvjGccufKf9APxaUvLRQk4kAZmlSdJKe420jQ+js74gF1wUxLEgGZwYfC24N6gMrogEg+GI l49gBpV0idasZbW4Wbtde1D7jXYAKuoKpVarUnoNSgXnQpfQ3ple4M0yXq+L8XKME4NfmOsr/iRm bAqCo5UKhc9G03ANiUARczK008ngACeAz+mA+w6cwAHhs9nhFXZccPThvxZ9TtQMg7AJhEITFngX +p/jrIJRJRgN6BdXqzAMrnAFjIE3vSDW7mEAywBGjGUZMVOXYbqScCcQzDCiEM4wgmiOsJGZkaWR 5ZHHI3si30Q0kW34NRAEOiD8dtjhy+xiEj7gS+2iK2u2fyMVrEzdgItCFiK2a3qUnO0V+HE0RsCP VoBq0cbS4DUa0AKpBJiyXblcuUepUL4Cn41i46To/lyZhHkEiujXDHnYRfbH+xcjmOz8jCH7F7uc R+SKgsJh+KyT/BobtG+lTBwK8PdLkT4NYmgqoX4M7gxRNuH7YSPD+b9E4jz5hKwzE9YLEJjFIDDb jHfhLofL7ipBsAnrXYMENHzgqx5c4+gbOPqSnSxDNBTSLxQ6+ADibY6I/1itaat1xDnivZu//sfN 17OS6WxAK9iOzv++8R+XvSHbUnSCJfIn/qhoGcyl+onkibeJv1dY0YlQ07pQFh9Pi6uoLGjiGwLZ VtHQbm9PjG44xzDTXkic03Ch4Vf2XyUubHgssaLhaX8f1cf3Zfpad1I7+Z2Zna3vY19lvskfaf0X 9i34lvQ74dvWAqrVQrUGSH+A5DPpWsBnMq0URfn4DM3zmdoASZE+UEsDUItDnE0KZkFnFSiBFzjB NUZoFTJCVsjVCLUC14dfLXogTtdpXJocHsO/yYCM0Nqab2jIBwKJRLgVQXMqP1pJCgAoDQal12uw 270AnbaYlUllHsrVTKVS6RpXKwTg2Y3h+V74Seh5XTvUuU4v4WXGbgOCRGmzyesmc9YxJzS1iLGP Vk/mrMNOqhxtZtCUoyelcww8GDxZKAFDCSweqRyQACKX0UeipBKJkkokSiqRfsqXJ01GOxwMdNkV 7ChZcil3Tw3s64WvofrgFr5M2sJXUij2A18sHcPXo23P8Lcww/8kQy69T3rgW9FqcuQtZosnb1Ha 0EDa8ii2JFrhKd4Jn2xFA+k00/L7w20t3G6GW4sJ+nRg0EmVaAMjKccjTtTBEyNzUCNP4KvBcjka 8h0aby2uKT57q3R8DFFT0uCO4u2SjH+KJPoCMBaMuQDtfYbOcfiU/v5BjvKrxTHyvsmugobx88Fs VAE8USHzc6DMXwxlvhY8ghJsn/c6WNS14nMxa2Xym/xAG9DWMgGmdkFgQa1qGnWBfaZ3Gq/Q8HP9 9/vX+BX/4n8M4CpeG7DxTEBRDl5lS66pzHcxDpJdeH+8Bp7pJRMg0Ye/LuprE4maWm+8Fis7sdmS E8tYUf8kO7pmkCQfC0qcp3A8EA4HA95YwO8HpN+CEYy2NmCtEeJBIR7jhJiLpyiJ0wJBeECYWAtq +/DtG6FVFywk3BPNvIBR7dRyRP5LV+LDs45IVczHCkdK8FtOiEoMhubmskdTYei+H2b2TgKOmuHI 8dRXSmKJLYaeLAPNYgiaxV7MaXGWCLiLsZ9zVv//srRyEPgz7IHi8lp09DkazgNNIH3uoNzU4mRx 7KDcvIwnBkUlDD6oYE7go4r9xCrF55gFaxMFi970HYbV6qH/8x20XBq9jtRQGAhqSV1KN1FH6Bhq 3rOVdJD8z+Ujy99qqO3QnyVxPyQHBRX3/bQdfbryS6lAGy7gzcV+/H7pb2gRuZF/A6mntLogyEs1 VPKnnyh/+sjPVg7xL0v3FM/vruSRvKgcjfgPP0k+ElzYV0Bv6HyiC4tgdWC2eM5z6ifZ5xKEoA6x OcWV1iWuX7u76Ftc99GrXGvV3fSTrnXJjeqXTS/RG1xbfLtNx2psOsCAGCB+Z7nfhV+XuCPxcOI5 09rEGzX7az6t0UT8ffg60RVK8qGQn/dHKK/VEa3jsbooINIGbVVdHzgkTgO3RzBdmif0Wh6F9xZV EVXRnMEQoR8hea8aPWHEOI4XoQU08yDJ5/l2fib/OP8iv50/yGt4V4NjeYpXoec7VY+rtqsOqhQq pj62bUgJQPys/s9KRBT51pVLvJOFI8hjkipqB737RkvjCFEuSTFa3LdjaugqZgaOYln4YAaO9VKa hKZE7YNLfIkOSMNLt2E+eIl14DX0zOICKPDZcnVRrd1RUfKPGrjIKeyS7BCC9Fy5mmjq5r0PPnfo vabb27u6Zr/EaUmHzjTnkYmP9yxCAv9G7ubTN1909pLLL9s255rfre68dpOZvH3c/Eadk7LozK7Y o3P690lxmT9YyPbcuWdePGUmiitXw7mfAqXOg0VA8CUEf9eJejIpQV+/0WNHx1YmaWMYu83v8akJ oOcEQ0HfB+ZsFHgtx8MVeI4YIzwYRqi1ei9vhnceV7ligUmYgbPRqEjHTHfSB2mCZqIX3FM5HWgS DpdD9lCLELSDFgkuuIdLvMtfaoYzYb2hNBnipIVakNKnguMj50fmRp71rwluBlv0L/s2hXcod2v2 KT7SHFZ+qbHYFTWgVjlK3wra9af7zgeTlQV1QT8XzFdeqr8Kv053ne8adplvK/uKf2PIDtfLoz16 MtI38OVLPrvcBaYAFncAC5wjzEZjKJoTGBFgAxWVyiD20Ht9QFX818aPVr5RwXJ+7MB99x1AD8Xn /e+8Wfz+9R3Fo2+ukRrztEgEhZ2P/+1vj8NHidE1AWpmDDu6kdfpzShp9INYBXfesn0U+iB8iD3E /zP0ZVgdtIXtY7mzQmeFJ3OF0LTwQvNCZkFoGWOwo5TRFVa6w3q+7ZLQ/PAPLqXKxZA2V5SMUiHX HeTD5APOVa41tjXw2oBAWcwM7ZYqNxiPQ46vYbdb+Kha36tQef7g4AN6U07T0c2CFexrLM66qmhe QJPcLQBEJFohEAIT31Exz1DbJK5tYfFZx+SuPPDf4RLDdqh4Qw6loZgDInOhIrxSME1VGUyzV9Zk BPxYNoOla4k3JDqXVI+hevH+ba+/+9zs3efaSItj3hM7dxePA/3uPxJGD9KSV1mXwz2+68sHn9h3 2kTaYYmPuQQQb+0GBqQLN8C7vRZ1aYb3++NNp8cujuFo9V4n06iS0gLu1/ic6BTpTjrcbqfD79PZ /RFtQQfVoDfCw/sN1YHz87QPM+hpNWo572C1XBfqXwyAqyrEd0HXsg/c1RuPdZWrzxaX7g8KITdL ZS5wRTkM/z+G9ODUIZua1IT19pIS9Jo0lAaZmCG92ILFoAfC0WEU1hIgAgpogsygjRpcogJZ1aCj X+soi3Jl0b0Cl03MfR9f/vY117x9xUcPSMeL3l/1wPvvP7DqfcXnxy9DtuXpndccWnL1wWt3ggOy JHd/9FE3kmRcYoYnoSQzGIftFRfo7KtteC0+Bj8Xn4O/ib9p/RNzgDrAfOT+b+en7E92I+OJeTJ4 g+8M95nsDPc0ttN9KXuD+y73as9q32al+Sr7Vs8OYge1y7PLp9K8YXFxHFxBLV7eoVbwFr1hkivX jYFFUIP6wKeiw8/lQK6bBp30dnoPNEUKmuFjz1eI6FlHpMK/I4fL3RSkIq9hRqbHTqugSdjgplkf 3jfw1aCph0AG8Hb7iGIhWTIxtUzhVlSfeMb+6bMX/HW01UQ6ydT3N75fPAjMO/8KdFOY/StX7nOB R594qyVtZiwWsnYKcO/aDC3H/73xznXP340iJe9BLDsNSmYG2y2GRMNEZZfyJsONNd2GHsOG+Ovx fXGdQ2PWGnaSpF+bSWA1AIJRxSYM8ycggOgDougCUHKDET8WKkR5L4ZRHJOodqq0Gp0fyqKoq8Oq AOfaI4nmKtGYtIm2Rba9NoWNyV61Bfy5xOY8SyogaSY/k1BkM0pu9EvtUUbUwBVGMDpNsbgbTmgV i8XdURag0NiNN56yagHulNoDDPU5UdlsZRyVBJId7e9E4+5NaNz0/D1LbkvbnLTG+uDFv1oClkmG 1tg/voz98C1IHpcufMSusVOUg3BcOm6pjLtw7DfFGxQ3QMkMY2ngE2vG0Yto/CP+ndBX/OHQcf5Y UHVJ9LLqOck56WuN10cXp++KdqUfjd6bXhvtTm/1mXANsgazJQOhVSo1Wj+O+eI1To50cHAuTb6V NTyni/PYSkENHVsVUIGIlwOcTkdqu7XrtYRZi8K6L2r3aJVaVzbBdwVWBLoD6wOK7YE9gUOBowFF gMnELhwmrJK1QKw4OBkIAOYPI5OaL9clNo4wEhVSvA1zDxzDXAPHemIa6PH92OPTYCjDW6VJoU3U kEYnq+3JocRSSdARcgHZQfYSrTbhgaEuW/V1WWRF8GyGStcO69dxo7z2BZ2LZpwlFYp8e8aSsP22 /S8cP/7C/tt23333n/5099278Z2/kyzGlkljqi6ISBUIZ54eG31iCwAbNwKsOOH+P/9l5f1/+QvU hclQFy6DutAALherV7uOc7gC2MBc1VWqFeB+vBs8ia8Hvbhujeop9QblRvWb6vfVB11ql8bikOy2 mWZpnJ7hpGmH02+JJiXAUzUjVVWVTPmjpE6290ZgnCGF7P2kjF/1oRkl/NpQi44D2WRNNltb428A qARPEY1E4HQ3YAo1qdNoOeagE8B14glR34TxXM321J4UnuoD/+xtHH/hYM2x7JI195dNvhTotZzS 4P+ndQTwqXK6Gwy8hno3AcQrtbhKvFKokKTLrVSrQm4lwwKX2iOrJOpQNZRx3IKpBo5t5AwsLaOf DjnFJfeuGsKog6pbKpQ/VeoRnDtx5fTZy2ZcwDIMW/xGcvJvumrG6OSllTVEkmZDXHR8yvhxy9v7 /zWov8T0a6u5Jf1fDfYwbJH7WmGvQGmwK6GrDBHsUjHmZ2oZkTmXmcNcydzMqK1GcioNcazKoJ2q VPoNdg+zygZxLPEG3gfu3+RRGQ06DGwDKMmCQzfEpFAoOVs7DWjGe87SIR+P7JdmqTn/w5ERrh5W WYVlC2StJzH7SzcAX3H9UnAG+t79TskZO+N7xONTWj74oHjOie8qLBXEMsgubSjeQDRI38yLPS7G SdRCEieJ6eYOD0R3nivNXVgX6MK7iFVm09ma5ZrHNWs9Wz1Kj8aNEsUeqM1KvaYPvLBJofDr5S8s mvQq1ySGo6wm+0ofSt7NFC04ThA+1mDkvN52BVAwvq1gI3gbcw4llqSSlnLyrv9w/of+ofo/1CsI LoDomw9+48qiTGVtXRY/eP2NRSNy1vHxU6eOmlT8XroB2ktuRt++/4Sk+XMuWVHNSop/10VQy7fD eV0JtTyL923BolCM7cZ8FFVY0gZpK7ZT+vxF1qes+I4MiNGxUCIay0SyjcF8aFQ0n1lILwzo51tB wFpnxeN0e/SD0AeZr0JfZY6Hjmc0TaGmzMLgwuxaem1AFcwGAphsxvWDNtyDlH4DxgKWRR9qIPOs 1EYAIm92RoBl/QG/J4BVpyVrkUq1ZVKpdMZfncla9NIbmZI6k0mv81sQWxd6UDJV17la4ur63bS1 SkDnx0ejM0LRqBDyV4WCoWCQy2bobDYToK2UlcMCNIYFMGs2SCsDwJ/zeGw5t0rIVaVz1dVVVbg+ R1kwTQ7gOhq50NrOAAj8LhScnN0KurEQPGNclOnK4FwmlZmVITLIGnnrrXDth6vPIm2XFie1nDYF d9A6pNIyddvAo1iXHIwfotqjNt2oYvRIKXpUjrZLJTAlPqWj8TZFQo5iWgf29fqaEdltX6+nXt4y tfLWUS1te4ZI9gCx7G8zlXi5v5zNOnUMauS10JSddPkwur114FCvK5ihJQafBXVLOdQDt1KLWim6 P4SgAxBB05oQahecGfihsnIPXgGvmli66sfeEJPhBivLUQB1kN45hGsGY1v8YGzrpNDqyxXO4htg XlzSFSMyHBcW+8DjF0oUjaPobK74IPh18Y4K1/EnUIXMh9Tg+utix2Do6wqoUdugRtFQo5xYQczM tl1hu8kGwYdhKsKMECVORQiRctpWWSx+JwaBIQY4C0m2k9tJgmSYSmsotas9tRU8pQW8d7j9+w7Z v7LrUGHU4d9qQx1MICZrw2Nis7ne3GBqNDeZm82jzKK51TxOSwmGOsMGd0+VIgzqAD7ZM1s923Ol +kqPsk5d6xmnHueZrFamNPWjJP082ASa2lqamka1+OttZnTKx1FgIrWXOkQdpRQYRVIiRVBtJooy m/y2ECsBBcxP+nF/m8/vZ33+UF1KPpkm03i6LZlOp5L+ujYRnZx3sBW0tuVbW8W8vzqp8gmJ6ojX owLqWL2Yw9pUMZ5w8Votoa6vqwuFbDqjiXPYRTabsnfZcfsJwevjwgI6FroEXDjRgiW5fAsKZGEt 21v2tBAtzPjYC86KmAnciTcPbgaLEEtFaeVoLtWI/S+qCQsnl62UtUaFrLAEJkaCihKq4CJRJ6Mz KJT6UFQRZoFSxegcLIgoYyxwGlwswMr9DqVmc4UChBvuoaJZ3cDXmAI+1AMH4GcdgODlnTL2BHIH OjX6C1wtUqU93KK/pAdu5dbSBatNiqhJXuwQQAlY5Aaww48rkMpIJf3ikktHz+YbrmiaXjde6iDw 8NnpxPzRbdJue0111ahW6fQnEhtb2iVmT75iXFvbuNyZ0/o3ImnGHxQnjZvX/460f2/rFG90rnww 5IxAKb8USvkUKOUN4Daxfr9qvwbfodqhwZ/Q9Kh6NMRidZcan6Oeq5nrJh52r1Hh17G9YANOeNiF LI4BBY77NJQcizDbWBtua5NoKH5qJKaVlyQTZgKmttKqJGNaEguRIXwEsDVm22RgW5trUIGt4BDG gTmi1csr1BDjUpRFp9VxroMMYNCCQkrwdkWqG8JbBmHbIchUQraycPYfg4vF/7zS9X+Ka2m3R6lR a1QaXOVRQoFza7wyto1J2NY9yKaj4Uv//pKblsVrsdSCpVCACK6u5HieJB3DpegkeDtl6j0ds9ob pkvy8LFE3v/tZeddu7gS3ZZkZWnH2KjvztP7vxlCtx3Xtd7S/+0IAYEY8N6Bg4pmKCF6zAFOExso u8JOO+zELrBLvx//UPk39X696hL1Ags+D5+nWKBZoFtovNQyzzrfobHxhJnXEnqt2sBjUmcKJi9t TQ5pKxpt2fUYILEUNgtCzD78NtFJ8SoR9a0Q4TWdqu2qPapDqqMqpaoPfNLrhCao7LfAxe1If2Ex chnK/e+HFcBvw+wQgdIDxzaQtIl2bB34BK64n/QafRbfkD9ZkBJDKFeqt6PSCxoNFhTetJp9eT0N B40ODmo0WFDzTC9EfGpaT8En4WCnLY4WGg1WGqUt+wZ2iBTc0ekgWNOgASfMbDMo0+Ermk6i2G05 PlMZ5WouHnl9R/FrQO14HVgnf9zd/TF6gBdfKx4Flu3ohxuO/vGxvx989JFDB1HkvHiDpL2on2i1 mK/RmRvD8JGtPgdMxgvGuQDOieoS45XgutjlCf1/qV7TfaD+QHsg/EHNZ6pPdRqGqCKuU99FrCae J1R2j6SyTNLLMB6v3y6vUnpq57AlabQ/WVqNgDGaNOdsnhyUVFOS1+uiPFipUGNsLqQSeLMGaFzp KszE+cxeOfet8DK1lcF3CdqVQ+9HmqUAws/FD36ZoloZHosYUsjvqJYIqkYOoFmvGfjbS+HAsJYH qAhY1jIU3UFB9FOq1LBY+oTnr7r+/1xR7H/l47vkPFpnRUj90XceWr1v3+oH9xGzV0+fceWeyzcW BzYXVTJfEuKKnASIFty7Z++Ke/fuQdFIOHfPwbkLYElwJups+kOPuTGKhK/B3LgOe9q9LkSci810 zcV+5VrIX4Fd7/p14ibsbtetidXCI1UPJp4Vnq96KmF5MgAejq7l1kYJ2X8wVYaBZNust+0smWXZ DJ+LzHDZOcBc4WpnjkJA3lTNe3RaFCEK89hKvzoIGC3DdemAWXdId1RH6Fw1MR61UOtm17OKPewh 9ihLsEyqHESujAxJpXPQ9MJJRfTjfPPPhYV+wcoOn1iX3EIpCYFwiK5CLW8jdLwPzmx0xMzKUftT 1rfJQdHgiPDQ829IkWQpnlxcJIX07vzk5WI/IF49dOe+hx7ahx74rtVoBo+/UZ5R8NNmADZuGihO uHfPnnvv3btX/iUDxTRiCbT2NpG+3gSqtO26hdQ11DLqAdWjVrVHDuOwO0vem9u2FV8HnR1R1Jac MtRoYp3YHjlb6jLhj+tNtEEP50SpNgIrRptIXTCUw+IqXZ6EiyH0xZBL5taZ1UfVuNpVjdFc0ByY GJADeEcDqgBT1X/P0IIoF7PKtazSbxNIjnW5PyuwNP6n1PBfXAThzFlKM7fRSpvslKeMoEpaN6y1 yKkCsDj+5BPjJtzIWHUmayDD1D+8HVwpQffLkBe/WypHI2bvu3/yPJeVUVsDrqlrixlpciiLA3+5 hG/2DBwkilDLxoJvxdvpvGc0Tp2JdWALxj7PPV//+4Y/W3eN+bv1Xfu7LR+O+af1cOaLMSesxzI/ jqH0VpVd2aIdw1ptdluLe8yd/lWZbWb9FOu0hgUNC3PXNtyQW9awLLeG7qF19+Q2svg5mng0INSI o5ozLqfZpLYZGrFMbSqgSNSZTQZChxEWJjdqFG/hW3V9ILuB4BBNAzwgeoQ6nsdy6smNfLsPEcUJ n6utZlIgF7XxIlol7XA9FDs6oyDKjGtVEypBx+svKKmcRAIq/SQRiB8pdTmQeONojgtDpPHGCtp4 qbMMJXfkbagfQ3GekDXkaLGxWM7dyIJ6Dg7UGHhozztZzOFsGdXkbYZYxpVrbmDrWIwebZGgtNT/ QBpKdB0J45Rnf0OOzug8Lw98jjmg9o6FattC10Pt7fXbmz1DcV2JhiEThxrgGquFbkeOhkMDWnGd pA0ewWEsWmLH0nBRHUvrzXkPeh94Z9BFmxGwoNFQscTC1f3nGquhZuUVZHhaVUGGH2pkHhaCpZ7B xPWyN4vyeg3n3nb32bm21K0vjr1w5l/femupxmaU6PCMI7C688nuc84tvnX7mftWriPiXiipK3wu O9McbmiMZ5sjHrPVGbj+tEuenuenTS7fC1B8bQk2lb927NnJJJe5uPnSpcjrvA+irRyqksV2icHj bmB0u9z4k7qNutd17+gO65S/Nt1qWmV6yvSm/l29yqFBvyKwDlOAy0WbRqFQa/yApLU2i5m0ULSS MUT7wBOixZcLBtU5ADCVgWf09O2KPvCsSFdVabScwL+JeUgP51nk2e5RQgTwaW81cvTQL0dJaZZj 5cZEqJhZTpSe1G1Nzq+43Dq93qVlMZ3bwGJyfqXUFqOs4RZ6ZIpKyA7Pt9htEO5LdfHFhqsWT36z njaSTiP3r8Ur10nE7YfRZBCzkXL3v3367DRnRL8iw591x1V4Ep2UOnWh+zgd3scOYjYWhpbYoFNs tOMRO3BpzFrJAhuSGoNBq/Gb5USq3n12KZEa5tFxNWrR38YFgzznDwO7meb4HBbWOZw51ucza7Q5 0qyieULPcRjmsCMfRBslLZxmjxqoUYA9MjLA3twst3EusZ7k2r//eDksm1tR9//Y+/r4qIrr75k7 995sdrN52U02byTcbDabAMluSMKLBCEKWgQCikijAiWQQIIhiSEgIj/ElypFRFREoNZSi4iIgaJS RKAVKaWWUqRIKaU8SClFP9Rai5RSSZ7vnHt3swlg1b7YP8h8zpkz554583bO3JmbuXd5mZxsjQ6P 0V1u+fVst5rQlbn0RLPnTTd0W264jSXB/TxYDLnajlv/MaQDILkR3U9j06c9GTr/8dC63feU3Ww+ CaoZ8YuXaBj+TNuIe54ZVDFDyaTBeHTU1K0maT5HlmNQKn9zGGOQzb9R1vMl/pJrnVsYdsNhyE/p xBpxBnZupbyvq597sjIloTaxNns9hNa6XWVdufy4U0tZkpM5451Bp3COoI88ee0JLvMmitZ25RGP QeUXnFrkl2DH0iecvNEKNx97Dkwxn3uOCD/2TFA4N1wJidhHJmYzZrgTE93uRLeLM7v1gDM9vtQu Su3RenZp4mY+tczhVkqDCQMT1ieIhC18KnPz6DJnmYsXuhpcK137XKprG18Pm8nhWdY5YiyETtIJ +j+xiLcgBvb/zMPznY8CX+Lc7yXOAcsngebp+Q4P9Yo7c5QNi1pfGEOPvehbkI/wkhweMH+Crr/8 j8gtwknfW5PD+TVz/xd6Fta3rU1dgpHME/llz+d5cpMfEms9zydvVl73vJpsY0q8cq/nMc96z3bP //O0emwrlQ3KLxVhU21JKWpKUp7STc1Lyk3uq/ZNGqIOSfq6+vXEiqSK1Iq8yfwOtSZpSvKU1Cl5 96izkpZ5liavVl5S1yStTH5NeUPdnLQh+YepP8z7meenyb/1HEh+33MiuYfDk+7pofTw9Eh+OPXh vHWeNzy7tF2JRzyn+Knkc8o/POeSE8wzRLHx4UNE5vn5lrL8Rh9nPsNX5hMfSWqlb59PNPrm+RR5 oF7x+ZbTaXqvdZq+pazbN+hlFyHP1I+MFn+O5uvpYL2Q3wuJXk4H673WwXpYZUZGkE7Ve43UlKfo VH3b0LKi0Kl6I3yq3og4VW9EnKo3rFP1P+LHsN1uhjUdk48i+bGybJWN5lyMVu25pVlppYa71KmX xmQZhtMZozek8JS3Urn8N7qfPZlaVtgrtSyvR0lqWU4uUEYmUGoaUFxCSWpp2YQ8nvcGf4GO0z9S luy5RSnreVWJIuUUKaeUxSeUKJv5C2VOzZiQxJPeSlSfTCzV5KOuwl4yeqXvVSWU7GEmUQzF0EAx 8lMMZTIuc3mSS7SypF73ao9pijx9r2jb+HHWLcJjzo4bF753/0mesB8nD+Dj7wIdvx8XOn7f48xJ eZGldHwrZeAZ+SVvEF/4AP5FD/nHjbvzordWLsW0TuGHnji8lmdLtanx7Qsa3pQVJUSu6HRyNPKA fYgn5te8vrmmpVv4EOkdT71StfmxqfLp9Em56M3jSpcLJ3iEh05WEi+cVlZEemk15tup8NJByhNl T3VN6OpSXH0Tvp6gpMtnLF29E/g0V0NWQ/aEQW/xt+L3uvZm7cneU7SjZMegOBtLYcu84lKH6ekA vWEeoKeD9YZ5sF4p5aVxpZgo3aWu0qxSozStZ2lRqa80u7T7taWDSnuVlpSWloUOz+cGArkDb9VK NvPAq8agFQPj5T+L0uUh+qwsT0yMxjxcHqRfEac1wDTSrivC9VeyV+S6SC5rRe6tcRlB6zGClpE6 2G5Ps3fXS/WTW3hU+Me+QgvhE+GP30ecpx8nD87LQ/V0eF6+3vGnlPgTodP0VpzGUjqdpSekPRwI HY9/u9Px+HXW8fizr7iyZXxcPttCfHRjev8BFx2wL8uO7y2P5OeHj+TbkS0+U56Dz5Tn8r3hXOFD 9eat/7WEFGdcSfHmtlMbEVvfZqL/AVnn7Y+XRbscAxMyHa6BxfLnkIaCSLB7kgck4JY5YNA1ma6B XKJBfbokDOQSDeqTHg8KaJD85UUuUZY9wxhQEgdUlJiaPiBerruL5EIbscuKB21u2/lKfKJ88r2z zAkiuz9QlkSX/RCEXIxz8/2tzzrAb/1Ox2UOXevZykp+nz8xDrv0j6VTPNL6eusbdANr/XNmWpzb z+9rXetz4/of5P2siqfzjCrpQn+QV338J62PRXmc1r+jrmr9qfms0+mJwsZ0iI2uyGc0f+YJplfF eGzwqqda56rL4FVFfCsWEyzFleLt4cxK7sV7JYx0liX/w/13ryPaPcw91FvDaxJmuWd557vne19P 2Obe4t3l/bU3Fq7pKnIlFLnNNU2m0xkML2bSvZnzMnnmcm9mpteb7s2WJ/hbXg0U0t4w2TrC7+1R 5I42DwFq2nLzCGA0Z/LjN7jlJBcm8+QgfQDHm+Yukuf4W8qm5eYG6SC/t3u2111UZJhfOkiA+8pf mnC5GS/CBVcCZ7ZMzRUtlz7p6YmlaWnwaEUufXyl3XuW9ujRPZZl3pipNGYey/xI7kxLbpSvT8Vr htaoHdM+0nQttbj7FprFzZ9UGndn/ElMf6GHDBGLH+ukpfxFCs2ajf/JP1w/74IolIzvLB1li+9v 62++YMhDv5B4WfPq9H/QLKWudXZqZpozyUMn+e/kX+ej7rTeD4lPDFw4/QDZHr34zKMwN7ucSdE0 OY9UfmCaEIyr/YmRnKP/xJj4ENaUzN4vs8fKR8TcFmtXtrWdZc62c8zOVLkfiQrSB468dg+ZzGB3 MM7tjo/zemK54lIMZ2yi0xnrjFFiucepxPDYOIMlY9VrOGLsfJxaGmcfaG+Qz+tSPeMa5I8Xp8yI eERXbp13PhH+9fCr2n9HDlOd+RlPxfynuSJv45iuKMaMhfjQRsxXoSmq4w9kdf61LPqCRQ+exEPf /Y3K6sXDv6AlDl54ROlL5y0uMKXpwllzczfswtX0Y8i7hyk7miTxU8YV+WbC4+ofmZNlvY4+Ki5z OhgvYb4oW2qs9SZE//LQ72sL6+1sKlN5nFv/1EhRW84/LBVqd2P6YPjrY4XH2R9CgcfxyXwb36ak K8OUauUR5T1VUR/WKvSgvifqHtvTtn/Yo+z/cAxwLHH8zfG3mLExY513xj4Z93j8TQmpCaddLe6n E99JmuYxktenJKfOTrsz/btdbs9Ykbml60OGYvw66yfZs31n/HaE4QjfMkPuw3ljujm7vdH9th62 Hsfy/1gwuuBXwTnB/T2vKxpT7CtRSk73eq2Ps88P+k6/qqK0R/+DV18YsBxh55VwJVwJV8KVcCVc CVfClXAlXAlXwpVwJVwJV8KVcCVcCVfClXAlXAlXwn87yH+xsH7KdiZ/zVn+TSUsac48lJK0wmJ5 oUULdhsfYNFqhIzGUvgyi9ZZF77BoqPYrrCMjRWy1RYdDZk9Fu1UVvBTKNH866Xeb9GcOdQfWrTC orQ0ixasQMuyaDVCRmMx2giL1lmsdptFR7FJYRkbS1HftehoyNRYtJOXazOhmasCZcXobxGtgY7X f0W0TvzfEx1F/D8TbSO6jehoqw9N2uxDkzb70KTNPjRpNULG7EOTNvvQpM0+NGmzD03a7EOTNvtQ 0vaI+jtk3aLiiI6J4MdKOqor0fGyblFBot2gXVFXE50YIZ9EbTRpTwQ/lfKOJDqdyjJ1ZkTIdI2g fSQ/jujuRN9BdAHRd0vaFlF/W0RZMRH8mFBbXmQGK0KPFLK+oEazGlaNuJw1sHpAM7ubNRJnEFJN oCWuBL+WJAK4cg2rQzDYKPCmIH8zm06pasTVkJ4JXAVJqWEG0rXENdgIxHchriX5SkAz6a4Cfxri JnYHeA1s8peol9RaTxrNfLcgVYuUrInBbgZVSSmz5Hpwg6TBIN01Vg0nUY3rqV61JB2gdk0Bt45q 2Lk+/S7Tyn7UC03QEKpfL+jqiWCwPGipRVlNuDKd2tvMurExl5HvqN/UfiNaVI4+GoJrd1G9ZCuH 4VozQh1J3kr5DOrZuxHPoNExe8gcgclUUjP1iEw3Ur5p1G+hnptIeUO9eh36dTjG38zbFHGlkVpT hVImkUZzNO6isiYBX7pcMy1lJ6HWM8gSqki2AbiKrjdSz98dHjezrFpLwyRLVzVhaZ3GRS2XEnVE 5SFfN8TS3iaGy7pUveov0v35e6ldexVpmgJeE1mTaVeTwlZ76da3W3LHepVG9IFsidmWZiov5A9S v9nWKrIN2fIG8rFLt9Ts6coOvVpt+UVn75C92gy5GZRT1nYmtaY6rEdK1kHiM8foRaOosLCvMbqm 2ihvqG9ovrux2hjU0NTY0FTZXNtQHzCuqaszRtVOqWmeboyqnl7dNLO6KjCoYUZTbXWTMaL6LqN2 ulFpNDdVVlVPq2y6w2iYfFldRm290Yxrt9TXNldXGTc3VzZXI3N9VbChyWjAlSZjUsOM+maonh4Y VT1lRl1lU0hPv4gi+82sbpou9fUK9Oxp5JXXTmpqmN4wubnbmAi+JQ/xG28uHz2k4a7KpipjWHVz c111060NM4xplXcbM6ZXo0JowOSG+majcrrRWN00rbZZVm7i3VTV624Zfg2uNlGisamhasakZtmM u2pqJ9VE5EVcWz+pbkYVsjY3GFW10xvrUADahly1EJgEqer65oBhhApvqK+728ir7WZUT5soc7Xr qg9JX7JKJF5VWz/FaKqejr6aJLs2onjqZEtXKdUgrxalNFdPk+PQVItSqxruqq9rqIwsFJWuNKuK Pg4PR8OM5sYZzUZV9czaSdVSpqa6rrFTizAJNpALVsLY6mHsDdIBuRMGNhXp92mCDl03p37pNDRN ihXiB2Kb+BHgdbFFrIvQJaVrw+n3SHd1h7KqO2gjfWqm2lMdpn5NvRr4KkhXwimku5k3iRq+gX8P 6zU5CVwD+Sbr9lIZWjPirzUbMzkLr+Ui/wSTKyUf4220VgJHflBvMK3txgMfpG+Y/RrXDikLGVce VZYzoaxQVoD+tvJt0M8oz4D+jvIs6O8qH4H+i3IO9N+FxrjQRRQTwiZsoKMFVlnCLmJAO0UCU4RL eMBJFsngpIg00OkiHXQX0QV0hugNuo+4HpJfE8PAGS7uAT1H/B/4c8W9oOeJM6A/EZ+CvqCiPSpX 5Tv2Qq7oVLtcX6lOrJSE6lGTQaeoKEVNV7uAzlCzQftUP+hcFWsttVDtCbpILQHdS+0Nuo+KdZc6 QC0DfY16A+ih6jDQw9URoEeqI0HfqH4dJVaok0FPUetAT1PvwdU56r2g56nfA/2clsu4lqf1YELL 169hXL9WH8KEfoM+FPQw/WbQo/XRoG/RK0DfqmMNrNfqU5mi36FjPabX6XWgp+nTQNfrM0Hfpd8F mVn6LHDu1ueBvk+/H/wH9MdAL9afBn+Z7W2s2H5ue58J2wcOJ+OOWAf63JHsQH0ceY7uoHs4eoIu chQzxVHi+BroIQ7UzXGDYzjocgdWko4bHTeCvslxE+hRjptBj3bcCvq2mGFY+Q2PKWdKzIiY9bAW 1bI0CXa4ywEmKpsqJ7LEmuqJTayorrK5ng3AFX7LqMEGS2QMlqeYtkqU1CB1yBSXq1emDB89xGCe USPLDdaF+KwD1uQkzQzC3QmXTLtj2h3sNsITw3snpQOVgJW9jlW8DSt2O3PA7p0slsWhvATmYm7U LIm8QFBtzDgTNb8eLjgGvjEZbjaTzWUPsUVsKXuWrWPb2R52lJ1kH7KzPIbn8xLenw/mw/loPpZX 8TqzV3hv6OGIz6F8xDEGaoE4tr8Zx5v7KR6/xpRLKGPyPC13JSIdhbjM5LsmWPF+M07cQnJqcl3y vOQlyWsopaccTfk4VU9NSw2kXmteT9uRdjDtg7RW83r6hvSd6YfST3dhXRJNPRlLzDhznhl3vY0k bUaJMcQYbzQbC4yVxiZjD3Gdvq2+fb4TvnM5MTlGTknOkJyxOY05D+Ysy1ln1tpfJTHiBaY2/xNm nFtnxt1mm3H3DaZc/nYr3kWWwPNbEUvZon8U/+cDyoqj2YvRvGWjGcuOWcrNHDQDOVUdO04X/DiP ucmDE+G7I1m6PgoebMB3xzCvXgEP9sHPklgOvGQMK3BUwFcKGY8eHP2c3CNhVi1iLP96ADwssBfx KEAF6AOIMe/mVwFmAuYDtjNWiJkwcBh0o3W9n/yxTQuwty2+FvEcwCLAEsD9gBWAlYDVVrwOsBGw GbqOId4JwOwQOIl4H+LT0LMGMAQwAoB7RjF268UTEE8G1AFaAK8CtgB+DNilpOfHBPIKng1OzvcF AgTdA2X53YNN+dcGqoKzgnMLbIHz+UcD5wvSAuMl5NcF7s+fQLAkf0LwwfxXA9slFBQFPiSIDYwP LjBlC/yAk4HjBQeC1+ZnQreEFAtakE+CK9APUFJwDHKHIXcb8i9GOS7IuEL1CQxHfcYHZwWqCtZC 51ZcLwxcTzAE/KVI9wYtYQTSz3So53zU87mI9CKCJtCTCRbl7wfMDawjeDCwrmAT4jWo2xqrjj8G 7ArstOBtgj2gJewHvZ94RwiOgj4akT4BWsJH/wSOBk5Z8DbKfTt/FmgJn4JuIR3mOKB/CxLRvhOo 01H0uzUuBfmd+n9M0FUwFtAczCyYjfSzwUKCVYG3g9BfsDbYO78l2JI/2uy/gg2REIwJtb/gZHCI HD/EI2gcTbt4FWNyPcFRq14G8gHC42uOa7/wOEb2Z0u73vz+geuDWyLGrfM4yrE3x38qyv0xxnwU wehAY3AX0p3lL85fAXveg/wzkX8/+vR+CxZZ0DHdbicrCGS6idIrAasj5WGzkfKrSX4BbEfC4sBG CzYTLLBgKa4tpesm/5nAuuAhpJ9D/IwVH0W8Bf20xbK9H1t991kQkrP8MWyfhwL7AAcj7PcgQbv9 HiTYFThOcBTyEkL2+wFs74MIOz1LNnmqQAH9Kdltx/E/QTZxPdkkbPGi6x+AxpxCc4OfrpMdh+3Z ZtKw5zMEneeVkJ0PQPoE0qCDHyA9GOmP5PUgKygKni2IDcYEFwQ/Jdm+gNB8BLpQQXpoYHyhTaaD eqES1AvSgjEFfkDfICtUCmNNeZm25G+EPPyuYGLQVZgGv5oHv3oC6RqkDaQfQnoZ0vVI+5FeGMws 7Et+mAI/TIEf+gpmB7ubfleYD/udE9xVWARf652/JthSsCnYu2Av4rXB/u3XMf8SH+n2+WoF7G6F nAMJdqCsdr91SbjINlouDQW7O8FeC0I+fxrxxzQnVwUXoy4huZOBMlwfDbnbEE8oOIf+k9BqQoRt 7etgWyeQlhCa2zBusNkzNC/1Ncep6FDRUukP5BOhe8tetG0TxsKK87sX+wmuDc4NLsXc3hvzg4QR xfnwoSpzziguorlqaXAu5ovh+YVIj0YafVrcNzC8uG84/epF8nJOWgw7Dt2LJlt9f8k5AvfABcUD AIOLhxbfiHhMuN873yM+NX0n5FPFEwOnCMaCHtt+3aIv9q1O6Uv5AkHIF6QfkC8U1wQXFNcXzwsW EjSjvNm4B3S8J5wv2FT8UMHe4odC/VK8MNi7+IlC2afji1cBliH9bHu68z0mPPd0noOs9v+HV2gK S1b+jD0sw94TKVGMHahH3Ic9Zhp2eTexRepo7PUWa/na99kSbbX2Io/RWrSdPF7bpe3iudpunfM8 VEDjE3Wb7uRVerzu4VP1FD2N36l30bvwZj1T78Nn6P30gfwx7PKq+FP6ZL2Gf89+p/1Ovgr7skz+ vON2x27+MvYIG5TY9vWi1wPowrjvWcReQB7oVfJT4YASANaT3goA1oB+7CV8a0GXWdftgHgLsHbs 5kI8HIC1pBdrTS/Wn16sI71YX3pnWjHWk16sI73zoWsDYqwrvdj3++TnyVci3go9swApgEyAD9Ad a/pCxL0B/QFzAQ8CFgAWA5Zib+VHT/djg7GPqsDurA67qHlsAVuCPdQatpFtZbvYPqb4P8215Sq5 aH+u3d+aG5+rgorxn8l1+c+DUvwf5Mb6P4LcuVw7rnpAfeg/mOvKTQF1wr/H/6l/P6jD/h3IbUcO 3b/Zf8q/nfK2+D/wn8XVVv8q/wH/WlDn/Sv8B/3HQZ31L/b/2L8U1Mf+h5B7L6gl0L3Oj721fwFy tvi3gJrnr/Ev89eDmukfj9yr/+O2Keg5B9MbsPu30Z47Hjbi4nOwU4phW1gPxrp+DEANurYyZmDf amDcDYy5AXsxYCMGxjj7OOIu5rWuWPt3PW2CAfvyf4hYvmkPGzFgOwZsx4BdGbAVY5QVw8YM2I0B uzFgJwbsxYCt5GK/4D8DOA8aW9hcHQA7w4iw3NsA2EfkYh+BvR/LbWI9clblrM3ZkLMpZ2vOjpzd OXtzDuQczjmWczLnNPCmnI/9MyFxLqc1Z5VflRjQmrPBb/fH+z2At/1z/Pf75/sXYXRW+Pdh9I74 j/tPoZ8SMAroB+WM8glTlL9hRFQaEZ1GxIYRcbFoGhE7jUgcjUg8jUgCRmQES6ER6aKPwYhkYixc rKsjESPioxHx04h0+y+WxOEvNTTK3VkUehueaGB3Z2BXZ2B3Z2BnZ2Bnl+NnUb5dvj2+/b5DvqO+ Ezlp8j+0yl+Vv6KOZ5WzjAs3rFHRR8LqBOztFqaSvWkOt8PN9C8sPQQ7c+PfsOuOVR5VnkKpTyvL WTQ9V4yh51pO2x7bL1ms7R3bfuayHbQdZIm2Q7bfsCTbb22/Zcm292zvsRTbCdsfWKrtlO0US6cn Wl3oOVVX9FcLe5V6zSWfqWDOLPd6vXnegLfE28+7xFvmvd47HHiUtyJrlXe8t8o71dvonemdk7U3 a6/3/qwN3vlZGxBavSu8Fd5F3pWQHJW1CmGDCV7zL1Jju74qqUtqitCzBNcrQD0BzhMdg3zaoWDW YbqyUtmGvnhT+QnLVH6qnGTZ+mx9Nhsk7xBssKOrw8+uo2e18ktdLutJmyecX0V+3BWU1coWpilb oSuN8uDOwdKYl/pD/geX+WIAkxk35sonYvQEFzpQhrS2svZ+MyYwt3Ebwn7jEOCoDL55CEN9N/rG +Mb6JvpqfPW+Zt9sqsMy6I5WXlBeQB1eVnAXU9Yr66F/o7KRCeU15TXU8A3USkPbdjMbtcpONXRg NpvPd9MdbxRLsGanLw88+21W3nUlwmrAOqLMEElfKi3Dxk78jZeQkWHzZfhfNHxWHTvX73J1uVR9 Vn/xumAE7OSFjLyQkxcq5IU6eaGNvDCavNBBXhhDXuiEF77P4j63FXPleuUJ2HIM1gBpjGVgzokA dgm4HP9yspG6lKxjFJdnLLworEUI0RsQLpZYmPEEwsKMTRnHLnnVDFszTgIvQ+jI35GxN0zvzjgd ceVj4pz7DJ2Rtdqb0Qp8gPC/Hj671WZ7zRIPd6jJwk5tjGzdF23XvxzkfBG+fzyNuWc57iJ2289t P4dt7rPtg22+a3sXtnnEdgz3kt/bfs/cdJ9IdJQ7ylmyY6RjJEuhe0bqF5p/K5j8fVbO6mkGTpa/ RMFWsUVI9bdm5WSS2wnAWp0dbpfj8ew8UolhOTkDfxu+hlWeWT6VlkmlybM6NvJBRj6okg/q5INR 5IPR5IN28kEH3Qmd/2ZNsjcY9YZGvZHzFWuS/Sr/V4DZiR2gPkwhnjyxJv/n0NrO47o5TrxLBC+T Ronzkgheb3Oc+PAI3mgaJc6nWjyFOf4lW5NWlnLZsdFJEyNNnDQppEmQJhvpiL5sbhU1exQ1exz1 41QzncqLumwOoSxSFlttEVRP9bJj9EVkP7sml8rx+VouPWwFe5DG0/ScVBp10+c4vC/EU7D2W0bj GSn3nDmabLPF+/f51Wf7b+TVi1v/+a7KNh2wbN5sUxrxPmZHyOYjeNzOzkT0kckrsWw+kjfcsvlI 3lTL5kO8/6zF//ts9l/zp/9Vi+dsE9tDa3E5OiwFe+0U7LWTtrPyxF3/q0G22fYr26/QuuO242jd H21/BO9zrwrZRralfZ/ixqoteQ4rdx9EOCJx8miiw7F15UhEqlNol0y81oSIfOHrEfou1hXBSdzS MUgftf3advjLttDVSlDumYvwIMJct8vtkin3IcITCBeasUUjeBaE0jKHKdkuEw4PuveENLbrC8mR nggNnrmuM64z7rkdA7XwgO3kF1gfKdxHu+911kySDp7gz/FneD7SyyK5ik1RuNwB39+BW6/U8HOM fm0jgntA2auMR3pMJFf0EyWKXGeVdeCuFCtEd6S7R3AVlYnFETNcekTbXMpzyvfRtueV1Zh1X1Re hF+vU9Zhr7pB2YCWb1Y2syi0/E1mU3ai/dHKL5V9mB/3K79iTuVd5V0WpxxSDrF45bBymCUox5Rj 0Pl7Rc6JhsPAnJjtyGZJjhxHDo38Z80a/926yJ37o4Qf/wrLXv6VlP34V1j2E19h2Uu+wrKf+grL Xk6zU5Gch3jotFoX4nXHnMXZRx14Xto3HOnAS+NyFbm7A8/FY5B6tQPPzuXpppUdeAr7FKmFkTzs Bc9ErOu6WOu60xHrOpP3ATsRsa4zecdp/de/A+8w7YnyOvD20zoiMcyTM7mccRitQzitQxRahwis Q45iNXwMq5GoDh4StljbkQ7WK/GTEXyTPtBuZXKNEx71RyPox9vpSBkr71MROk36dx2sR7Yrj3mB PfJkILUso10OrZByG5n5bJQzO9Ow6reH0x3uwrEnGIvry8od9f+rIWKn8DnXGXwN/5Cepzah3Vie Mx4bGwaZ7gwmX4mAsZ3SE8M0j60B1FNs8mys3F74FYajX2npXzr82/ZYn3f1eZx7yO6vZxjtmACg hLHoxktDjN2iK9ohxsPKbdd/+RDD/pXc/yx8yX39l/KpqBbGo+aGQaY7Q0f+hItlbGntsqBDEOKV 60f+h8NxC/7Hwn/dp+R55/MRewn53zlba+OFE5HhC9x15QqDk5fK+9jutr6h+5pSqSURzgSuIjxd KySaEz8PeCrxK+QbuYpXLSd+LnCtNgm4TK0E3qQOJ36czKveBDxWHUVXpcw0unq7uoSuSrqPejvR JyRN+keR5O2WvLy6Q6wFLpRv+SqF+g6iPyJ6vMTigMRqX8I76SpqK2IkX8Soz0isLSTMCMvnsTvE MonVCUSXEP6UOFLDVtJWIXPxM9puSVucWcB+yQH/iKSpdD/l8mtVhBcSlufyx8urfLysA/BOwmaJ B6isvhKT5A71LNGzCFMNqfQdMq8ymPQPlnmVwTQWgynvMZJcTHS+hZ8hvtS5mDSs0lYCz5FYeVB9 ANggPFs7DnxO+z7wBu0CeqZRg30oC2Q/iwN6vsSyn0EvlnzJwVXZ8zZq9VbCC6huC0ya6raAemCB soZ6ZgL1BtVTcvhi0Uh13kn0AaI3EB0j608y+aTtG209CUsba2q7Cnhm283ANW1y3Ee1vQj8Ydu3 5YhLS1aWXDgsaYnZ+Vb5XPY8Wfhuone3yvXfUokVl+TzFslXXK2bCJ+SY2pxZK2aLsBKeay8yptI Pra1kfAAySF+PuWtoNIrKG+FLJ3vsOpgSJryjqfSz1PpW0n/YtKzg0rJJ5nFpiTV+XzrOsmnFrlM LOVBS985TCW6SCZFYsVPesa3Uh9KzM4TZ7GsFV8saeiEBnaSemMtabORniotlXpGSp6hERlq9Zis 4TEaqTM0gmfIus6QXcWa7TUtnFqdTxr2kORQ6p8z0g7ZQmpviqmfPKhC+g5Poau7pd2yI1InSlxH tT1M/GeIv1I+w5F89ipZ8l5NfoX6Ae014G7SbtHSw9RSskBpq0z+8bZnCG+gNXwR0TuJNvdYtJNp m6pAQ1s80Yckxg5O0vMJN5u52v4GrEvJVnryxFeRBnMfdZ5khkuMGrDQvgl9J2eDCuJ8QvhHlLeJ 6JcJ/4Y4c4g2d4Pmvu4FwhsJ/5LwfpJcTPgYcZYSpn0lTyH6A8KvSKyYz7e2WTR2J+I66uFd5N0l bWOQa7PE4N9I/ERJq7slrXuJs13OCVKG7VKxK1O6XNhF9HCZV9LQgL2t8p5eQbhMYjmywiNnSGHI 982AK6QeKS+WSaxU6SMJv0K2t5voVbKvaIYZoc+RnKhkmuHlzDNYj5VXoyqIv48w0foemg9nEb2Y tJF1kYbBFucIXSWdF+Rdpqr1DuAVF+S8OvPCD+Vd5sLP6Kqkb1BvpntQK92DXqZ7k/TxxzXcP5V7 274DHFA/Ic1XU94nSf9keVV/XmrQpbaZhF/T75P3PuJXET1K9rAySvPS3e0d0n+Y8G4q8RPCP5JX 5SkJZaYma367PozwtcBu/bdSg55EPktzAnnrSvLHQvLQ+1oTgMsI76G7lVvOXezXNIPtkPcpYLn3 +4jmhIWkZ6uch3Gnk9gmMdtNnjVeejQ7T349XvYwaHmfckuLQqnS/nWy+SGmT1m75gLp72Sf4wnv IBmDbNJPeDDx6fmq+dQE85GUWUR4tsSogcQnCG8lzUOkZsbaPFTKdsJYLbSNb31fYtLzNuE3CX/I sA5BHkmvJw0DCa815wkm3yl8iNezyHcKh9A7hWPC7xRm0nuBUUx+b8TG4liC/IEA4sk1WhSLxpoq nrmYg2nhNw0VepbQ8V3DzIi3DDl2CGYcy9yTJk1rZM2EZxOeV1VXO4XNn1xbX8kWEV5SW1/bzFYQ Xlk7vaGOrSa8DoKVbCPhzXUNk+rYdsI7Cb89rbqqlu0jfLBJ6jxC+Di1XQljhd5ZZLQ6lFiLwFER WI3AjggsrL5ktMKUWI/ANgvHogf8LMB6X/KtRzNfoxXPNN/jYwvNVSsfCxyNeKYVLzZjfb8Z2/Mh j9i5y8wXe9p6+7HF5CdYbyMmWO8JJsyRezrGY0aQ/mZ5ZpCpUTFRzqjYqDj639Lf5ezOu3KD3hzc AS0pzMvyUfsyNpSNRo2ll6jCJU9qEvW1MDUkTN0QpoaGqWFE6SgxkaUxA32ST1r+Qho+ptx/pZxn KNcnlOOs/PINrCwFvegT2Eko50Qy5UqjXB6ST5XyclfAYkQS6UmkvPK/hn9BqUxEiSgWRScxbbTr FPo8/V6FLFaYH/+xCzutoWOoHyAh3tcTxZNSQvfoHrhBmo4dpTx/LiX4GLZGZApD+ESeyBcBUSR6 i/vFg+IhMV8sEIvEYrFELBUrxLPiObFarBXrRIvYIDaKTWKL2C52iF3ibbFX7BcHxWFxVBwXJ8UH 4rT4UHwkPlZvUm/RCrSg1lMr1nppfbSrtKu1a7TrtBu0m7Ry7RbtVm2cVqlVa7XaNK1Bu1Obrs3Q 7tLu1u7R/k+7V7tPe0D7pvaw9i3tEe1R7THtSe1p7dvad7Xvay9o67VXtB9qb2g/0t7U3tJ+ou3W fqG9o72r/Ub7nfae9gftfe1P2l+0T7S/axd0rmt6tO7UE/QkvauepWfrOXqu3k3voRfoQb2n3kvv o5fqV+sD9dv08fpEvcaR4khzdHGMdUxwVDlqHHWORkezY5ZjjmOe40HHQ44FjkWOJxxLHSsczzqe c6x2rHW0ODY6Njm2OLY7djh2OuR/PNeIDJGB0egqumI0skU2U0SuyMVo9BA9YEUFooBpoqfoyXTR S/TCmN4n7mM28YB4gEWLb4pvMrt4WDzMHOJb4luwhkfFo8wpHhOPsVjxJEYzTjwlnmLxYrlYzhLE d8R3mEt8T3yPucXz4nmWKF4UL7Ik8ZJ4iXnEy+JllizWi/UsRfxA/IClitfEayxNvC5eZ+lim9jG uog3xZssQ/xEYFcrfiZ+xrqKX4hfMEO8I95hWeJd8S7zit+I37Bs8TvxO1jwe/+/ujMBp2rrG/g6 Z5+1DRsJiQyZHSL7HDJHiCQzUYYyzzMRyZSpIilUMqVbkaYboSQaVaR5zlCaJ0WTlL59VuXWfbvf /Z7n+773Pi+P7b/2sPY+Z6/fb62199nrYHeBIvYAewCUsCfYE6CMPcOeASb2AnsBVLBBbBCoYq+x 12Aaw55hD9QYzgxnoA7VoBqYDqlfoAFJqpdKQjZkAxbUglqADbWhNtCEulAXaEFDaAhmwFlwFtCG s+FsoAMtoSXQhdbQGuhBe6rlow+doTMwgAvgAmAIPaAHmAm9oBcwgn5ULWkMg2AQmAXDYBgwgRFU jWkKo2AUMIMxMAbMhnEwDpjDeBgPLOBSqk6cA5NgErCEyVStPRemwBRgBdNgGpgHM2AGsIaZMBPY wGyYDWxhLswFdnAVXAXsYR5VkzrANXANcITr4DrgBEtgCXCGpbAUzIcVsAK4wGpYDVzhdrgdLIB7 4B6wEO6H+4EbbISNwB0egoeABzxCtdk8YTtsB4vgMXgMLIYn4AngRZXr08AbdsEu4AMvwAvAF16B V4AfvAFvAH94h2ojBcB+2A8C4X14HwTBx/AxCIbP4XMQAl9RPb5Q+Aa+AWHwA/wAwuEn+AlE4Byx R+IMnAGicG6cG0TjfDgfiMEFcUEQi4vgIoDzXIo0WILL4DIgHpejWpUJuAKuAJbiSrgSSMSZOBMk 4aq4KliGq1Ftv2R8Oj4dLMdJnAQpuBauBVJxbVwbpOH6uD5Ixw1xQ5CBG+FGYAW+EF8IMnFP3BNk 4d64N8jGA/FAkENMJiaDXEKcEAcrCSlCCqwi3Al3sJpYTCwGeYQv4QvyiUAiEKwhQolQUEBEEpFg LRFLxIJCIoFIAOuIZcQysJ5IJVJBEbGCWAGKiSwiC5QQK4mVYAORT+SDjUQhUQg2EcVEMSglNhGb wGainCgHZcQWYgsoJ7YR20AFUUvUgkpiN7EbVBG/E7+DLcQB4gCoJg4SB8FWopVoBb8RR4mjYBtx nDgOthMniZOA802Ad0AoJocpYaoYiWlhb7A8bB22ESvDqrDfsBqsAWvGDmPt2AnsNNaFXcCuYDew O1g/dh97TPnyOfaG4cRwhQbQGJrBOXAedIJ20BW6w8XQFwbCUFgIi+EmWA63wFr4OzwAD8JWKg8l 2AE74Xl4GV6Ht2EfHICP4DM4CIfhezgKv2CPcQKTw4VxcZyNe+BeuB8hTSwifIgAIoSIIGKIeCKJ SCFyiTxiLVFEbCTKiCriN6KG2EXsIxqIZuIw0U5wPoMdikwGkMloyGR05DAMOYyBHAaRq3BkKS7k J27kJx7kJ17kJwL5iQ95iB95SAB5aALykCDy0ETkISHkIWHkIRHkoUnIQ6LIQ5ORh8SQh8SRh6Yg D0kgD0ki90gh90gj90xFXpFBXpFFXpFDXpFHXlFAXlFEXlFCXlFGXmEir6ggr6gir0xDXlFDxKsj 4qcj4jUQ8SQinoVYZyPWNRHrWoj1GYh1bUS5DqJcF1GuhyjXR5QbIMoNEeUzEeVGiHJjRPksRLkJ otwUUW6GKJ+NKDdHlFsgyucgyi0R33MR31aI73moDWCNSLVBLNoiFu0Qi/aIPAdEniMizwmR54zI m4/Ic0HkuSLyFiDyFiLy3BBt7og2D0SbJ6JtEaJtMaLNC9HmjWjzQbT5Itr8EG3+iLYARFsgoi0I 0RaMCAuhSuFzEIvJYoqYCqaBaWLD2GqsENuAbcYqsa3YDqwea8JasDbsONaBdWLnscvYdew21ocN YI84pYLhiA0zHBku2GqoD42gKbSAVtAR2kIX6AYXQR8YAEPgWlgEN8IyWEVZuwbugw2wGR6mtrmM KcJT8CzshpfgNXgL9sJ78CF8Cl/CIfgOfoRj2COoj/NisrgQLoazoSkVueOLcV94iZAgPAlvwp8I JsKJaGIJkUgsJ3KI1UQBsZ7YQGwmKomtxA6ijthL1BNNRAvRRnRQrzX2P4w4Tp0vhbiTRtxNRdzJ oFpdFtEnh+iTR/QpIPoUEX1KiD5lRB8T0aeC6FNF9E1D9Kkh+tQRfdMRfRqIPhLRx0L0sRF9mqi+ 1UIMzkAMaiMGdRCDuohBPVTf6iMSDRCJhojEmYhEI0SiMSJxFiLRBJFoikg0QyTORiSaIxItEIlz EImWiMS5iEQrROI8RKI1qm9tEI+2iEc7xKM94tEB8eiI6kwnVGc6IzbnIzZdEJuuqJ5cgAhdiAh1 Q4S6I0I9EKGeiNBFiNDFiFAvRKg3ItQHEeqLCPVDhPojQgMQoYGI0CBEaDAiNAQRGooIDUOEhiNC IxChkYjQKERoNCI0Bn26mo/q4XiBarALNIJ2cBZcAb3gMRgCn6gey7f+D1AFJNUTM8Sovg7V13hP TTOxEWqai41S0zV4OjWVxoMBHarjodRUAw+npqxf5PAO5fAB5fAR5fAJ5ZCBcghBOYShHCJQDlQP Do/krIGiqPEoejyKGY9ix6O48WjJeBT/PeKzHo9sUET13yjr9ANA2WGQ2usQHAYMyhJUr5EyxSjg pghv51yfoJUBcaALTIE11Zv2ogwXR/Wlc8ffu1vgPucRLJoITZrGpLFphjQLmj36ZByDYFL9wk0o UhmPVL9H9HNUtBFF3ePR+fHownh0EUUY6t2L0C9xUvSjgE7Y0geouAStc3l87Svj0dWftruGtjtG TfPpx6lpMVrn+g/riNJPcPKjn6T6sRup/zfGc7o5Ht0aj26PR3fGo57xqHc86huP+lHEBQSp0iHz 7SqFIf0Mtbdyan9n0F7L6R3oubazVKqCSp9FcyvoVOuGmt4dz+seijjPPn79vG8VfTu1Zg19F+Cl 76HvARPo++i/A0F6Pb0BCNEb6YeAyLcReEU4o/qgZ+UAuoPMefZuC7Wgjl5H5dlArY/RW+mt6HPD dHoRuhvJea6K00/novKA6HqW/LcR1aTQWGrSVB5tYCq6u2iM7i5y8rdCT0kpAS10rUCQYFP1AVXi sKffI1wUlQhNKjVM9eF70HoCWCpVe1DLvv7HnqKrBpyeJUB9RBq1ZR+6XiIEvt7BZNAfUUfKuYJP o1eh/ULqPf5+HQVdp6B3otfSNX7e73M+lYKiB+PRw+8RnsRZ+799b75fh/o2apgE54qiCJoLJLLJ DIkMnEc12zL7PT+Ni16VIRFLzYqk02gsguTB4TQBjD4FAtIb552G0xi0DB06jVHlRDqQaj/MkayW TpMEhujXDvigQVHD0GCm/sCI80vK/pAZQ8Q6pSZV/FmgXPSBe/N39Ow826UzL6QqQ3QOmcEQIjPo H6swOo1OnwCOgtWGhrkTLxq9833eN4vkHz9SzijFZBRrGqmCY/MZhLCcWWRUYgxnyEkZpq+KDEtP T0dmfJBHNKDkdJY0Kfl15Uk/L/k21CRLlpzKWY4Ji/2x3DEyMk7GZElcUGRMcFwiKT2ZX0+HZLFI Uoekftwm87NJFluT9S35DxxRBk3ux7eFBgGWQZsAqPm89AwaDdTSW49GPTQYspVgVm5Yuoh8Wl2b r7j4w1ix9damsfJqGaNkh+rN1QVe7NCLpn6JL3fFn3G+NfSsLFuyoDIzoP5kaJKP/DUpw94JtHWP S060qQeUlgYpbbqgr9bGd2CB0lGLR7xGuiVqtUy9mudzV5gOZE5oKQ2b770rI3mLl3qC9ZNNDX4G pfaSLG4FkcraR4XTxB7O3Ogr4rUA+ldK6TjmvN8xWEQ/JXG5bb55/cq0Nv3nzkW2ez7vSAqPs90r 1lXCw5QFrmu9gnVa5glxGbp8cR/9LYCXe/uldBfXwUaDRaLpCYxb747sSSse23cu9dqOKTEehmcP v+LeKkfW41ln6mUShLP66BhV8Lem15Dp28j0aurdlKIx0kvJ9A1pgu4XogaDYyrkHVJE9tus+dK5 Jebff/4y/qaMY5xzWPyYaM8f3iA240UzTeFGwsRhDy92ZQXRaQQLcwvO6D+UHXrlul7tQNWc0z6D n653GRi41Wo7B48phBuf6drZC5N7WPkzKwWjQlrGhOzEgts/XTAbmOgmY/fUZ9neneKnp+koqh/x 3yK0SnGC79b3zpIjsmeuTRp23BVhxub6nDH5w4PAMH6Hd62vHTtaH50gP8mweHKlilWm2FyVom97 ndaPNbi/+b3ntOtL/7kdjs6NDRhT6Mvaa6+4C1KaN5ys01G7n3S/JmEgvgpcCDE+ekl7Vb+JUM2M EImQ2zPuXpFk3K8xZ5x209SNsJHk92nirc67fNXZ2OKc5PztUbeF9HPWL6nccamKsoIXmYFZf7UC 7/S6iXfsv3iUd7Z/d4rUPyUDintdNvVDGYBNyYDFppIzvssgERmUygQXps93YgmTEzkJbmFeV+/Y oOCIwDhqN4KkAGcmlzCXo79feGSE3/cD4/2rA5MnZb8e2JQfl/v5yzgFB0Zwhni1NzP5Wys0JS6/ 5llvrlejtYt1a0RxxtyE9tGpFR3m0YMXLR5fyTseau3o82YT/bjNjblhGgpG/m3d8k2EZVPqkh7z 1p0FAvYnFacNVT3il5960UTho8+m8+Lm29ZbTd10rl5D7riVenLkzUnSBnl6gno9rSpvAgzUaewv Y8qW2w+E0XLKRg/t903NGPGoSs/MWrNvqLlo63nd7fZZk5VzbHvId2Dmm1MjM9OPZL8I09sxXetd w/S9vMt9CpcGlG2M5c/eO3RiWOagnVC+b6faTba5+MsWqxIDeyex7gCHxJ27c067GFVm2OdGwN9n HF2m0OoYMHOTbde0FM2IzDn4xYoLVtn0iGzwW3tOn9M3K3wk09+TwhwpKDL4SF6cm6rQIOTCsP8M VUzgHKMwjfaFAUmM+kdKcWYIMEQZIl1S3fEgyn3v61snbEsdZk/fOtv3FUlwFk9gMCiMsn9ABzlm Wd2eFCuloe7DtnHVC5TjVJfUZ3+usy5aCmyenH0mdif4pEB18jDd7NTZnK4PTl3HKltdIl/5zq6d DV6WnC69KtlMVIrzF12/Jb1bZfngi+2xuwp69dbM3BhyWDf8Uu5e+c99T64F8xTmto7dBS1aw++T RwSFpsNnKiXrTUOZ0U26Bf1c/Gc8g861ppmEBtS0NLWs0To7hAkmJ7291G/at2zs7t1dY+/6rvLX R11bN2DXqFudrH5l5m0twkeHXpkeIr/ynYdvwT63Fr3rXnnzM6dovjXYWJXBV714db1a05ZtnXW3 ZBrbSPEsGRF+1cOOb0z6F5ED65jBOUej7g3vqOtOM42JF6Ack0Q5xuebY7xx5XTUQuL+kSNIeeYf pJojHF3KNGw2i601YwZHOCTV/KCSmpwkmb7i/+XY+FHBoYouw8bO3vH76thfrP637mmNaVj5SLIy qyOu2csD055Z9nlTUqmKhdy+HTlOL15a6He4Q8K1puks7LpsnTAnKqv+QWdf4KOtn+OU1wdWXl+F zSZPvT9z6Iy+FLfLbLvJ3PwjDeJBOxUkR6Fr1pOTtlyyOjuedatpNJqek4U7rj28zHTtkEjqVtHm Olcxv6vltdyzGvnf+FWOjV447mbkO7NDbS6xLDHrVe5gdKuZ28DWev7h+aOK/fdkLj8qXVS0TVOd meoqMT+Ejz17MCAs8pVu2SB9d+mWno1cggKGYsH3Em0tRPoP5l1YEl62C5Spm751aHZ7s9R8xZPp ydNaPM+JezN3F5nxngwx/XKAvec3Fble0ceXv7nnA5n+9tfu+YNi+Yuxqtatow9kP0ZLb5p0cfLI ie2r0OmTmsChngKZKw15Q0qeIUaKpv0a+9mcFaYyZpIGpF6VTtWMbM2guLgofQ0N35iw6eHfz+F0 38hwjajQYM5cjW/DlsdqmDlRBW86NYu0/H6EVLvEkNQndb+nSXq22rcMExISfpWhf8wPOcX9CShk HzOV876tYQOx4cc3XQ/nyzU4ZRmbpNitdk9nWblWZat895G+Gx6JE0OFHWRovgdj3nMPnFruoCrK vHLx0WbV82L8l4SjC1Weu7SOXDvJr7HXXz3cxlzFJSbTzvhSiJSJT22ix5pXHQmrOunM6eUdZdMe HFTl6Xm+4d6DpPxFgrlOW3q87BI2RnvVuOsVXq4TmgqfHDevvXzM4eDe5juf8EzwJm7r7S9dUlXy kOu+8oxjG9aK78zwUn48mjlN+iKjc835DP7rNTZms5Zc6u1JGFzlETohx6+g4VDTobpAZ1nznVZB j5wXrRbxCFz6fK0HJljIXa4gs+FxH5gYVTuyPyaqac+9Y5WidMo+5ZR9sr7aRzCE2GTXDhTrJt42 n7ogKbD6zw76Z9o62qQeS5tkkVpaOhz16FHJf6Ct4xwc7h8b5x0e9T9t69zRiRjde9rUKlrsdLel kVP7xzqRQ2rsFiE7x9MrXhhp3pzLWsdsLPTrn2qfeejYvIup8MPgkiOrO2qu7gmOCliqHPC4sWkw 6+C5lzs/C/1GLJRT0Tg/66YLQyL+QLhfuJXz7Z7XvW2VKzrS+lKt6TpFb9sruF2kg+acu9ke76Gx vFGR0eDiHiLp+yUt2fDlVYaijV5CHJfnMY8b2TpqS84IPJXW40mOHysPi0jqf25UsKEiWmCxqp2Y jxe74tIK22lyHkHmq3s1MgXt948cmJIf9lJxs/CHTsHrWQJvMuJjtU8VJ1V3eeHP4b5szaYPRe6Z JpkLsooi9k1Vs+yKLDPrD3mcqrQm9KtvMmhM6h1R+JVxuP8zWjuCOM+36w2TaJwmDPhBlJGPbY03 HNSqm5ddcLjs6S4DE7NTF0jx8Q1E6Aw+aV7gBJYAH2AGTH5uCf1LM+oXgiqymcg6lmzfMnHNFm8u mkBelHn+YKxzqzEPVP/S7OCUJflCr7BpqwvRm9doIHFxdNeOM02/O8hKRHIHp4Ri1XIWL8IawpPl mi0uZw7nTzjCtUr76LOUJ1Ge5pXrLnV196xpv9umei75+Zk97Ks5Bzt9T2hfFJNti+81KK2XiK2Q zb3R0CDknPem7Ji/VSlTqcxr1QSDDmH/pZYt53ev0Lfb57Ogl3zyRE9qYOXQLb30EWHZPL80X5xR MlRKN9NYZpF76Av9pv+IVe8tLG59PYzg6yq/w/ROtnw9uWyirC5dMmcXfrKE3fxg1imnma21K3sf B+jkv5ErKeval+DsoH8tZvZ++XeUoHZSglo33jwqUkfNI55/rnn0LyJAzSNShz2DUhObhRyl+TXJ 4iTJ9Pp/R/NImVT8mpSOMAuO4nwjxmwncxlzJ1t9HRNdtrq2rq6Jup6FHpulSMp/fU2SP78mdSfO i5Jx8o/hfIPG3+qtOJ1XxlTMIelm8YvNn+/kXBwVKBB+ulOHKRQ/ZmNfF79Bdf2c/lqXYPqDohSb rNup0YNLwO0Ws7DRyF3Rr6ZdTF7XXTS5fMvJQyPvU3q876qT0mVK6vHGDy1K1uy5sVLnRtfg8Hn3 45+C+of8CjY/Pi40svVI5qdrq7vhzFZavL0y9iGzSTQ73+uIp4qa4fltnze6zZCyE23XvSHtbTxT u95FZFJCsYHgR7Bv/T1PnTrlFl81S5H0+QNhT2unFefnCqRsBdsSFLg2qkZhzaoKa0t7T1bLzWuz XognOMeY7TPy61mfyb2gcexJzlwe7fr6D5q1KdbVianshSoCFQfe9htWGD+3MPixOfWHEJjFuW10 g2e3ig4tt5jwsfNNSvmXiz+1lH5pjP9NSykuNsrX+/+kpfQ9p7hfy/qn9h/e/itbgZe7Pt27lBtw VmXA7eA5kJEy2eOkwkKhlpr3oddzxvI7D8RPlZB79/7u2YaDJrQpOrstdUqiPnZp7mDmNRONccLM pvold1V57q2269tovKFJSyj9qWCP1J1Dfudt7Q2sV30W71Hcc7Uk5+m8Ew9ejZhM9qQ9c81dHp/0 IHIsR2bX+rK80rbFU6omkQr91SnehVIqKsfnrtU3W7HyZe/VFT12ajMMHpmY0HYCPmLo2lyJbtP8 ZfuG1fM9Ve4eyU8tnBTf4DUqorwzUsjXlLlAf5XB6ln3m052rXOVtHAJLehcZ+MCwdkP5Cxz2z7x 3Na3gq96pvQxpRschhL6lQZaeNKF7kjrXzBnZTB2U8aqpdNoZHrOP9hl+6kj+ccF8Kr0G6TIeO3E pLG4MIhueXDqrG8nkwdj8f14zZ06mj9SBEuA/HHpJMol4xsyWBQAQdHOQ3a9nqW4pIiR2FpmbrnQ 7iLS54dN+FjOpGMVM03pL7/l7afvTduilKbwl2U3LjEqMjDGOyooUeZPrmJk0IDRENfpVGOMvX/A QfH98afOH8+ud1rrPKLXXE7j/dimu7BSXCU1YXjdDaNKqySBgw9VTj1xWKKc/cJcPm5VIo+8XNql jJaTRUIFpYcV5gTt6RD8EPhu/X7tY80paUse7HXgFWU8vGzRXPElyWLN7Mc17c4fRV2LQ1sU49fY FE8vAmVKi64ph8/VnLOtKJbX6sajjWNL7Pgkkt4zb2b5XzN7x1ru4Xb57XuGnALv2Kyo7SfYT8/i ljk1z4XrDKM+LN96PdwreuqoovGx8B0OIqvDjfeqLlNqbHAo1jcfVLF8X3LvmAM487kyIzPKrj5/ WHnBnPa8g2JvTIxNqj9fsxENsro7+wu/++7hLRn0qWQGXeKPM4SzMuh81Czuf3sB/XOl+VNVzvWt gFZ5kmI/lkPijxtENGqf40sgawJV5epx7oBQf9paM9z+pRgu2OQU2By9IX/+nTDl5gSdHdZzn5/4 k7E4RSRgC1dW0uaO398UsDRs4lZWPPOzO7R/s1TIuk+RZ7uDuy/23fIes3QNHJX1ae+TmyLEWOyw 2ipOT/QU44SLgq6tcYCecJHJgfZLajkldxSLL1tGlFaORG7bd8py1bQyhRE6+zj/e3ELt2fWb9f6 7613F17P9M8fWP6cy/RQjnbc8duNYFBvZezwfYWE0UZmvPmDfPrNV5r8iV1RS0XPjzU4vhjg8ZwS r3ioNlFc4LpNE1s8sZjuadP32W5ZREZkHk85l9TU5AHBozeF4iPTp7qR+Q62Jzpzl01q+7KbVnjk E6/7g0QTMz7MorszdvDh3AUdy32KFYPE5Y8Gz0kNsngbHB79uu7EdgD+CxDIWtENCmVuZHN0cmVh bQ0KZW5kb2JqDQo2OTEgMCBvYmoNClsgMjkzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDYzNyA2MzcgNjM3IDYzNyA2MzcgNjM3IDYzNyA2MzcgNjM3IDYzNyAzNjMgMCAwIDAgMCAwIDAg MCAwIDY2NyA3NTcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjEyIDAgMCAwIDAgMCAw IDQ1NCAwIDQ1NCAwIDAgMCAwIDAgMCAwIDU5NCAwIDAgMCAwIDAgMCAwIDk1NCA2NDAgNjE3IDAg MCAwIDAgNDE2XSANCmVuZG9iag0KNjkyIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDQxOTU0L0xlbmd0aDEgMTk2OTYwPj4NCnN0cmVhbQ0KeJzsnQl8VNX5959z7519X7LNZHJn Mtm3CVlJCGQgCwlhJ2ACRBJIIIBIIKC4UKgLaMClarXVqmhb21oLQ1IxuGLRWvy7YavW3Yq7ILhR FTPzPvfOnYFYl/fTz/t+Pu+Lz3dyfue559zl3HPOPfc83JkLMABIQBFgZv2c5sm7NobOAO7tJwDc 102ub2j8cip8AFzKQgB+6uSZM+ZwsyzvA5f6e4C7hifPmTtpQs57fuAOdAKkrpjaOqepa9zKFwE8 1wGY2mbMCZS8vOpMBwD7Jx6lc179tLYN/950NkDeYQDVG0tWdfUJfn4xsKcuxPxLlpyzznvfub/O A/ZKHxZIu7Rv2aq/PPluM7CnMVt90bKu/j5IAh2WZyomWJeddd7ShZd1XwPsjQ0Azr7e7lUb1hpa EgGKnwB2c6i3p6v75YLpv8PjY/mhohcTLKvVeHyG5YOM3lXrNgzkGg4CcGPxfOeftXpJV9OhuveA ffYegOvOVV0b+uxZmn5cfxjX957dtarn7tbP5gFnwe111/et7l8X6YcDWJ4CKb9vbU/fnqPJrcCe uwTL+wFIdauyLNx6cYJxkaXmc3BrQWLns1J5AR6916H7amW40QTaLbgunhdEwe20LNyOddj71cqv 5pjklFG0SymmVpgMvLzMgRWCMBdrbTkeV4IXjNz9oAKt6kZVKe4gMxrzO+AAt1sLnEEr8CpB4IR/ QVFkH3QuwG1ypQ2nzfF6QfrsUKdhGcZpGfudl7GINwf3vkR1UDpTbBylSFybEh6EX/AfwCb4L1Al w3QM+zHcgGEZhkIMGzAsxrAeQy2Geu492P+D+zoD6tQWuPGH1tNkfvc6wjvfvR1/O9yhxFu/sww6 qBD2Qdn3Hv822KISYYtw7OR6/AbYIsdzIOH7tiUIgiAIgiAIgiAIgiAIgiAIgiD+f8PUylhamtk4 KtEQJ55uNsetaJQbjfT4kWFKDBZmxz1AfH2CIAiCIAiCIIjTHCZ9GAMjfKGNgBZ0kTDoZEWXCdUA BlQjGCMjYAITqhksqBawolrBhmoDO6odHJGvwQEJqE5IRE2QNRGSUZMgJXICkmVNAReqC9yobkhD TUX9CjwgoqaBF1UEH6oX0lF94I98CemQgeqHTNQMyELNhBzULMiNfAHZsuZAHmouFKDmQRFqPuq/ oQACqIVQjFoEY1ADUIJaDKWR4zAGylBLoBy1FCpRy2AsajlURT6HClkroRp1LNSgVslaDRMin8E4 qEWtgSDqeJiIOgEmodZCXeRTCEI96kRoQJ0Ek1HroAm1HvUTaIBm1EZoQZ0MU1GbZG2G6ZGPYQrM QG2BWahTZZ0Gs1Gnw5zIMZgh60yYizoLzkCdDW2RozBH1lZoR50LC1DnwULUM1A/gjY4E7UdFqHO h07UBdCFuhAWRw5DByxBPRO6URdBD2onLEPtgt7Ih7BY1iWwArUbVqL2yLoUzop8AMtgFWov9KEu l3UFrEFdCWsj78NZ0I+6Ctahng3rUVfDuah9qO/BGtiAuhbOR+2HC1DXyboeLoy8C+fARtRzYTPq BlnPg5+ing8XRd6BC+Bi1AvhEtSNcCnqT2Ar6ibUt2EzXI76UxhAvQi2oV4s6yWwPfIWXApXom6B q1C3wtWol8HPUC+HayKHYACuRd0G16Fuh5+jXgHXo14JN0TehKvgl6hXw42oP5P1GrgJ9Vq4OfIv uA5uQf053Ip6PexAvQFuQ/0F/DryBvxS1hvhN6g3wW9RfyXrzfD7yOtwC/wB9Va4E3WHrLfBH1Fv hz9FXoNfw07U38j6Wwih3gG7UX8Hg5FX4fcwhPoH+DPqnXA36h9lvQuGI6/An2Av6k64F3WXrCG4 H3U3PBB5GQZlHYIHUf8M+1Dvhr+g7kF9Ce6B/ajD8AjqXngU9V74K+p98FjkRbgfDqA+IOuD8Djq Q/AE6j54MvJPeFjWv8BTqPvhGdRH4FnUR1FfgL/C31Efg3+g/g2eQz0Az6M+Di9Enof/gRdRn5D1 SXgZ9Sl4BfVpeDXyHDwj60F4DfVZeAP17/Av1H/Am5F/wHNwCPV5eAv1BXgb9Z/wDuqL8G7k7/AS vI/6sqyvwIeor8Jh1NdQn4XX4QjqG/AR6r/gGOqb8DHqIfgkchDegk9R34bPUd+R9V04jvoe/Dvy DLwPX6B+AF+hfggnUA/D16hHUJ+Gj2AE9ShEUI8xQP2YMdRPGBd5Cj5lPOpnTED9nKlQjzM16r+Z JvIkfCHrl0yP+hUzoJ5AfQK+ZkbUEWZGDTMLakRWwHEUTG06nQ54nhdGjfyaOPzJpJilUxKikQo/ Mmp1LF+yVDB6jwRBEARBEARBEKcter3+f8+v0sYs8qsIgiAIgiAIgiBOxWAwSH6VelTi9/pVyre6 v+lXxR9oGSQrnkwQBEEQBEEQBHG6YzQaQRBUo/0qbZz4UyetLmYZotE3/Spt3K/SaqXk0XskCIIg CIIgCII4bTGZTN/nV8WfOn2XX6WOOVDa2AMt2a9Sk19FEARBEARBEMSPBbPZLPlVmlGJujhxv0of e6krKC+CVfysuAOli/lVJp2O/CqCIAiCIAiCIH5EWCyW//Sr9HFO+lWGmGWKRvHXVyib6mIPtGS/ SkN+FUEQBEEQBEEQPxasViuoVN/pV8W9o1P+v0IlIRrF/ar4Ay2LZMWTCYIgCIIgCIIgTndsNhv6 VWrtqMST//v7Sb/KFLMs0Uhxo7SgbGqI+VVWg4H8KoIgCIIgCIIgfkTY7XbJr9KNSjzpV8W9I6M5 ZlmVdaLRSb8q9kVBm9EgJZNfRRAEQRAEQRDEjwSHwwFqtWa0X2WME/eOTHG/yqasE410sR9aGWN+ ld1oPMXdIgiCIAiCIAiCON1xOp2SX6UflWiKc9KvssQsezT6pl9liv0AyyFZOvKrCIIgCIIgCIL4 sZCQkPB9flXcOzJbY5ZDWSca6WM/tIr7VU6T6RR3iyAIgiAIgiAI4nQnMTER/SqtYVSiOU7cr7LY YpYzGn3TrzLHXmyRYDZLyeRXEQRBEARBEATxIyEpKQk0mm/4VZY43+JXJUQj5fdWJ/2q2A+wEi3m U5IJgiAIgiAIgiBOd5KTkyW/yjgq8aRfFX/qZLXHLMWvUn5vZYi9GNAS86uSLBbyqwiCIAiCIAiC +BHhdrtBq9WZRiXa4sS9I7szZiUr60QjY+wFFjarku+y2aTk0U/ACIIgCIIgCIIgTls8Hg/odHrz qER7nLh35EiMWS5lnWhkiv3Qyh77omCqwy4lj34CRhAEQRAEQRAEcdri9XrRrzJYRyU648S9o4Tk mOVR1olGltgXAp3KewJBdDqlX1+NfgJGEARBEARBEARx2uLz+UCv/4ZflRAn7lclpsSs7/CrEmJf FBQTZL9q9BMwgiAIgiAIgiCI05bMzEwwGEz2UYnJceJPnVJSY5YvGiVFI1vsh1ZJsS8K+pMxywrx /0eYIAiCIAiCIAji9CYvLw+MRnPCqER3nLh3lOqNWVnRSPmZlSP2/wS7Yg+0ctwu6ddX8feyEwRB EARBEARBnN4UFRWByWRNGpXoiRP3jkR/zMqNRsrzq4TYe9c9biW/wJMqfUsw9nMrgiAIgiAIgiCI 05ySkhKwWGzJoxK9ceLfD/RlxazCaCRGo6TYFwLFNCW/2ItZiTD6CRhBEARBEARBEMRpS0VFBVit DteoxPQ48f+1KiM3ZhVHI+VnVimgfP8v3avkl/l9krsVfy87QRAEQRAEQRDE6U11dTXYbM7UUYmZ ceJPnbILYlZZNMqIRq7YD60y05X8yswMyd0a/QSMIAiCIAiCIAjitKWurg6cziTfqMT8OHHvqLA0 ZtVEI+X5VRoo3//Ly1Hyg/m50svYR3tqBEEQBEEQBEEQpy0tLS2QmOjKHJVYHCf2MgooqYpZddGo KBqlg/KcKqD87gqaioukbwmK//fKTBAEQRAEQRAE8f8Sc+bMgeTk1NxRieVxYi+jgMramDUlGinP r7Ji710vG6Pkzygvlb4lGPtaIEEQBEEQBEEQxGnOwoULwe32Fo5KHBcn/v3A8Y0xa3Y0GhuN8vAj U12p5LeNqwLIgfj7AwmCIAiCIAiCIE5vuru7weNJHzMqMRgnI5ZUNzVmtUej8dGoMPbe9dpxSv6i 4ASA/Ji7RRAEQRAEQRAE8SOAAY8BwAgCbADpFX9WTNFDOlRDPUyDVlgAHdADq2EtrIMdkQiu44Vi qIvndcOqWF7k0Ld+lshH+A6Cwdam6ppx1VVjKyvKy0pLxhQHigoL8vNyc7KzMjP86T6vmOZJdbtS kpMSE5wOu81qMZuMBr1Oq1GrBJ5jUMBCyXVtu1M0+W6fz9deqCy7Ri+H+EzrJ74Q2Eet5P7GRqnf WPZ8Yzktvjw9BM5Qo7+uXtrxbmh8JwSOEHOGQDoKc0zDIykbNXSv8DcsD6XUdXd24hb1fqs31Hgs oBRF3vdug77OX9ejLyyA3XoDmga0cN2+3axxApMNrrGhejcHWlNhQcieH+IyG6SwIhTc1omGvx73 hDmOkznDkX3bT80C3CxmOaIWC6nrQhr5uN7loWBXCLZ5dxfsG9g+bIXFnfnGbn9310KsuS4s427g Mxt6W6V6bJBCZ683JODOZXFjireh1zvgl6qjobcT1V+PW31rOibr6tq2+va5Q3aMG0K2/NBkXGPy +W+5+YGG5OVeaXFgYKs3tGNW26m5Pknb29uTscADDX7cIe6sYcUkPJXkQGFB9JyUCujuXCEdc0WX VM6GFd6BbT1yWbfLZZBXbejFhun6obUGBhq6/Q3dXd2TonuvCwVb5Qha57fJJ4hVV9+uJCkrYI4g 53TWt/uild0yu61OKpi/q94dbfZ4SqeSggkNsUyvVIJm3EHIu8Qbgtltflx1rCQ9Y2FgyVi58/ja GW418+RWIVWm1e8d+BxCrNN/5PDolC4lRZ1p/Rwks9Hf2Dkw0Oj3Ng50DnQNRzYv9nut/oHdLS0D fQ2deNSZbbjVcOTebe5Q4/b2kLWzl1Vj3Us9oHF2W63bZ2uPLc6MLQJ2KexYBvl0sBbwr1mJsJah tc3nxYqa29buxnpqk+xWtKOx1JGw447FNlaqTaqjnrHx6qlTTJ9P6p3bhoOwGBdCm2e1RZe9sNg9 CMFAPrZHp5SzL5aTMFfK2RzLiW/e6cej/FkeohJC2qz4n8Wa6GjorQ6xxO/J7onmhxx1bbyba49a nJuXLH0+Xuk1oaR8tHPyB7ARnvGHrPkhVds+d02712rDEUBqvTn+llnz27wNA/FeEE1RzlTqB9jV /V29A8qlJHX6b09tmROrcKnH4iW9DWt88+IV2Gnwr2u7NPz4BqyhxuM+t2/A5rd7qwLt0V5tfcZ/ gOHAhcOaNcRq5NNi8piGR2oO8UljMfO/PsLoU8JxbNJuP7ts1u4gu2zO/La9VrypXNbaNsgxrq5z UvvuDMxr2+vFu4OcysVTpSWvtAQt0tUzyGnlLPfeIMBmOVeQE+TlJcMM5DRtLI3BkmEummaV05BC gN2tiyYm4Z0EG5mNoFpRgxiuxsBDLfscFsnhODyDQYjsY/mDRlPFXjQKBjNzFcPpixpDOmtFcJjl DLpcckLOkMkkJWQONTbK8aDolTMyB92pipGQqBgWm2LojbKRPpidrRhpaVFjSK+XdpM+ZDRKsW8o KUWK+cGkJHkFfjBFOvBfWMJgmqgYeqdsOAZx272Rh1ni4Jy5ijF9hmI0NChGXZ1i5OZGjaGMLOkI iYMpKfIREgcTExXDZlMMXbQ+UgbHjIkaQwUF0kYpg6JPyfGkKYZSUPsQ7gZXsQ8mR/drH5w+XTEa JitGZpZiKEeyx2peHDQYFMMUS1HWEQcdDsVQCirK1ciyGRssEfGQ6kG7Xc7gBnOi7ceGsnOlwnBD WDqMWayUGYPJyYphsVY8wMxMBTYQsV5UQya5pYUhPK4UD+r08ppCrKKEwZrxijFlStQYOqNdWjcw qDPIlasd1LlkQzcYrFMMeSPJKCpWjOw8xUjPUAxXbCtngmw4BzMyFCMrO2oMGR0VlolmVopduBS7 byl2ZpHZgDErs0AZ2pZBYaYoFQuCoiG5IvK+KH7woUss/pC973SJRw9bxY8wwPHgcQ5vDsHk4wZj xXHmEo8cNojWY1cd44KH+w4/dJjHIXvoK6uzAuNg9Zd2Z8W777jEd8pdYvAlLHDtP9nBF2rF519w iZufY89h1PlC3wvc4wfyxMcPVI19nBn+Vv83LvQKw833vIJXT9+zkhm89Fm9oyJje+v2ddsv2f6b 7aHtj2zXBPezyr02cTmGhzE8hOFBDA9guB/DffNs4r173eLdaO/Z6xLvwTCMYS+WpabWJo7HMAFD PYY6DJNqE8SJGIJo15bbxJJSp1ha7hTLy5xiGcY7yuWS+MoN2NJrqqsrXl/Dgmt0joqr+kJ93Our WXA1nu0zZ8trJZ4tlX3p1UtDS/ngMp2l4tYeFuqWs8Z1S4PCDub9eejnXO01bNFVm67ivFfsu4Lz rgyu5KCXyX8zezt7+U1drHhBcMGmBZsXCGN/ZROl7T/9lRG3f5QFh9hubJmQM0Hc5bSJOzH8CcNd ToP4R6dZvBNDfp5N7MtjBYVmsdBpEm/x1omiM03Em67oddaIf3ZliLe6ekS3q0Tc5LrKxbmc6eJj jiYxwRkQHU6vWGwP2mfar7YLffbN9mfsvN2ZLNowgJPNdHY6+5x8sZmBmlkY/gVYLVvNNrFd7CH2 NDvKIkxvAexcAahFl2ET7IKH4Gk4ChHQ63WVooWz8NzT3NN8hIvwgpSi0+aJgipP5Pgs0WiqUglV PFfFoGqmig3j3kL2FmhpnRRyMIznTNqtK8lvCXXPnnTpFVd4QtdL84vNnvZhLa6DE5UQu7I9pJXu ULIZfwNf/zr8618X4htC6oberpDaX98vLZilBbO0YG4IWaQFi7+ehZwNvSEnpq7Lz1+3Xtp+ffxN fv0nrX4p9ON+ZaTlflxxvSRwynr/SX8/w/x+kPeQLwuT0uWE/FjAY3/fTv4LpLLmA6jT1E7VMdVB YYuwhL8HvT2IvBl5Nbwh3B1u52+S3uTO5rFOtoKdwy6KO4lnsmWy8RvWxVayc0c5cFPhbmzkl+AQ fBxPizABxxjpP+F6mzlgo7z13+E1eB0+gxNMxWzMxfw/6JveCDsV63k2zGlkSw/buVvhMRbG3BvR C63D0nzAXchfykv5W2AjjmtlP7jnb4E3cVexhdy5sIPdxtVxbdyr3J2n5jMtTMVzX8uu+c9tWSIT 8VKoZo1sNlvMBthRrpRNhPfhUxjBmnAwEe6FV+AtOMw4pmVONoVdzk3jTrAwW6EeUNmET0btbTlr wjNZyPpZL+uF42jPkWvjOtSz0VN3xd5fgsfNh4exrcYwI7+YG+Sn8ufzn6j0/CCA6iC41FbuM24p XoSb4Fr8tAN6C9AJF8NP4Ums/2Psa8iV6/FmXGMlfl4Xlgjn8Y+xQVgK82Apxn+H+exqWAKX4/lN Yync/4AThri34TZ4kS3kJ8K1/HkM5xU4FKzG8lyHW70CQ3CVcPC/aQPi/yTCS5pUzWH4E1yG4U52 j7BH9Rx8CHfAi7AKHgVOcmk0oMauj5EnaFFzAmAohiDMxLRAx5OvPgkBlDHFPpvPlomC4z58tVkF J6QY0AAOfoGShb1N2ksg6OE4nlfvU2m9ulrdDB2PycJuHlRWlVfFqwIdpSMlgUAH1B6prQqMKWa8 j2e4Xy4rN/xILtsePocNqA6eeEXI+CqAFxzufRP/GL9C7ZT3XhfM4dRq0DCrLqDrw33jOVrBKgiw M8DX8ov41fwmXsXzwk6NNCHR2So1gfwjpYGOIx14xNLSQKl0RL/84VfUPFWzCIPaOTLETZMCHm16 5F/C46qjkAR+aAqmuPdW26fYz8N7IOfbW65uUJ+j5tV6vw+kW7JZZ6oEyLRkiplcms8oHdFkrzTi ETtspahQ23EE//CQTk6jVvvTs7KzuPIye2VFRWlJYlKiXWXN8qerbdbE0pIK4fEJ9fUv3XLzSw31 E8ZPbnzlF7e90FA/Pnz5grNWLly4cuVC7v2Hw691dS1ZsmQxE/f9lSX3LOnq6V4cfuM+5nz99fAH 4WOHDqHjsh9r5CZsZQs0BvNVe9RqI2/mh5n2KOapcIzyQoDxYDR7mZefyXMWm2jD5rJZbfaqQEdH 6ZGqko5AqdQ8IyW1pQEsu09qeV95SQWWuhIt4aavc1h1+K8Nl+UWlws43pUygXd8inOEWTUnAniU G7AEr6o+Ai9cGUz0m6rdzeYp7pmaVvO85AWe5cL5br1zOPI+ukiVluHI7cEss7US7Ga31e5xB9zL 3Oe6NXa74d5ELoCuoLiXaTvFPpGTp0BJBmulvQ9L7tX6RDuXkpJuSRfTOU5uamslF8iX6t1eVSW1 OC5gH6vqqJUWxhTn53f4fOUV0lmUl0m1jg2i8dsqMkq9QoJTXvIJr564d9urrasWX7i6qqestMnu qWXGC5mO2S68ev6dWdy5n579SFv/zoW9q1MTk4qNrCGt9vDzl4z8rH2bB897GfacYdUxvCPtCroL TBn5WeNLaupq2sbNntgzdsmk/rH6gjI8V+wmzw9hXIKVEJyBPUibhGWfMN493JnKUlPL1DOKWXFx 7r1lXFDP9HrLvWp9IIjrGxpR/L651azaHSh2+ord46sFHeDtmwNosDSIDZxBJ9WE3lqpC+SXSlXR YU+qOoLNif0fZxdyTcgiN/ZIVZVULVgxTD5/qXvaShOlvhitpOysLL/fNmrxlGqTOnCiVHMJiZIl DM+aPuO5X+78cnrG7FcXVGzKT8+tLi7eUhocV782J6cwT8zoTK9cW5G3MFGcxlSXXbq/YerUazeU 9xQXjmP7V/25trauOoPVlU11eFOa6yZNttoEpjbaHfXVhVVWu9HltJaaWK1vfFFB4GcLNj2UatZm 5WdfgKdeGPla+AjHHj2Y4JxghdFkqlRrnFhIo1qjM+1ltcIMYZGwSUB4Dc8HNLWaBZqVmgs0KtAY Tbxa8IJOnp/bdcZKnM9aLDhFNamDtsRKtVKL+aWlR2xJWGMQqJUqDgcwW1XVVlVRvrDR+ghe3X7p CrHhKFaKKnx0IHzDyBruYrb+wMhT4a1sQfg2togl8p1fX89OhFXYUzZgT7kPy1wE5wWn6bUFlhKh xFkv1Ds7zHMLtaZWbGhtCnYKn8+zNzdXnbk3nZf7gg37gj9TTA8azJXpST5/utz8XhwZodhSLBZz OuVK0EWvhA7pUsBxKBBreiw9Dr7yxaC0eVa0zZO+0ezpUiPjSSUoI1WicN+MGdNfuPmOo9PTUxur ylfVVW/JTUvP95deXTb7piov/9LI1rQ5SSv3NM49k32x7q9Nk6ezynTWYM1JTHB7stKmTChrSUp3 uCx8ffjdLzg+v7ByrzS2L8aa+IfqiPys4YJgjdFoTvEYxZQ8Q8BYkDLfsFaztkzv4guGwWP1cB4P b3E4kva2W5iFG3tPBd/Ic7x+HjC7PSs6IFt0FhyQayw1Yg3nKvHJ1WGwS9UxUhIdkuWhTRqVsR7k qwDrZEwx1gb4To7Ocue2+aP1EKsBdmrlONUJTqXShH+Enw9/fdETk+fOb120gGUdaL7W7XZtmLbr wcTmGxbNvKJy2oLwdI+Y4fO1BrLnZHCF6a66zLRGduLD8MGW5nnM+sAjrHj96o0Odfhlk2/4rsDY /Nxx+8KXZ8yd13RmamqC06Iv8m/+VY43NU16VrMeR9f7se+ooTuYzqMjfwvHO/GOCxy/V8VzWp5B NzCuTRoP8W4+HDk2JN2lpNox6gxYO1qLVtRygtJThGhPyc/HusiX+gvU1o7YsEqk7r114yOM+aS7 s3D/yJZwJ/fLkWphsvCHE2cIw9LUnofayGvCi6pPIRNn3I2wI9ijCiQEcsyBsWO84ysneadVtgqL zO2Vi2ousK33mIuLykqCRfUl7SmtRYsq503sLFpRua5oU+X540zjKk3pJUVqde49y1JwjjnxHrV+ fvpSWG5c7lgqqrK8YoHXYXGI6YKx3Kvce/G2AU2WJrGJm+CV773WU++9OPIFjgSOyPOMDmmpQ27m 2ECXlVVeVlFZHo1iTayMZky+P0QbOKmiwiG3erZaSoleJMKLM6ZOffmK699smlx/xZaLe5ua6g9e NPDkpPqmCzZdtz3c1z1vds/4YOq0YHaGOGGpZ1Ve9vhLzvK0eLzZ7NbO39bU1DeMG7ejffOdVerg nr7ZV1dVTBxXPGbbrBV/rFbX7Odypi6YXVPTLJrTkksXjWxsnj7GnGfP7m/ovdDhTJogXTX1kUM4 kzsKOThPWxNstPJWnD95ea9tHtfPaZz+ccOWJDGJS0pSB+6p8jf7OT+n15v3zlUztb7dw3TOXJ/O o9w5JlkmiZO4cp9HqkGLvdKj1CD2BbxEpIsFI6kGT7lWcDIjjL5bVJ5aq/HZzSn3jPjlUllWIexp 6+gMH3q68RcpntRlC5ovG1Nab5x5+dJpV1RPmz+juenZn170eFPrGeErczNdE7N8tR5XRqbXO7sk r93N8zUPhh9Z03+BXcMyzd7svIJLlpSU5+bXPHD9ukebm2Y3t8wNf7blvJsLvKlun6evrqkj1Z2Y ZDTk4qnizIjLFJbI88icYArbz6nU+1Vaq86rQ88ypAb0V72MZ/IAL/cbaeYmz36wejPDt7DFUuBe YpefuJldjtdiXeSQKgFnOoVwe9An6PV5Tr07b3zymNRpycHUtsQz0s4T1hkuzDX5e3FEtw1HLpHu +zhb2RPU4TUpTEGRqj1YgEZSECVg8mZzsqw2MZPJWX4+NhnXmc2ys73l6/GIelNO9F5lqczJCVgC wcCiAO9K4JcWWT+LdvwaaXiTBntZOzqit3gc8FVesFnBJ3d0eXD7lrbBhiy1qaU0PjW8G6fi29iM 9isnlm7IzHLPLivbWD9r6/ixk6fUVF81ecqWopKpqem5Z1U1nu9hP2er0ev9rdNuKXOEb06u83oL S2ur/nLJtgeqx5aMSRODKeHbHWNsCYnYDjeiZ/oEjmBm8EBtML/dPs+9lFtuEtS8ycgllmv5pHKN VotjfMK50qxKDIozRS7JqelOsx4/0mH9rCN6UR/pONkXsYFKhJM9LjZpUT2xZ9u68NEbw0XsqZuZ fcO1d4Y39yyf+rt1Gs1P/jR9YSf37jPhe9pa8lUHc6adGX74uWsPjsvTfr1QN6b6CTwyllO9Dctp hC/3gj6yM1iDrafaIDWhJCo9x+v0gksICLVCUOgU+gSNIGgMOp5ptDq9gVdxTugxW8xB80wzr8Jm uweHLJVd023C88jvQMFJBdTW1NZI1xaOUNhKu9VcXWvb3fpgtKPskzqMSon1UsubsJdwUldRSaL8 +9aYYnewxcJZVKDnZ3AzVJwka/W7uF2qHXr1bH6hsMjQya8WVuhXG/r4TcL5+k0Gg0GvM7j1KYYC QzE/XqjSjzcE+RnCDF2z3oTdHt2ljo417Tj5Z34mXQB4I1BvC28PfxwJfxzewXaxKayZ7eJfHrmY 2/h1purgiI97HaJP+YV3sNY0MCaYpmblPI93HJ2o41QLNE5uwWZpFZ02qNuk46LT0LdG3uqQbjol UR9TnkkNh5uEdzDczVLDb51okfZ7R3gD70IvUNpvsupBjqkfZAaLjvEWECEgTYHUdzH5pobTuOiN vvTUizgBA+8a2c6tC9/HGsIbNL86/FUN7ndreAN3IrZf4UEN45X93hXfseqU/ZbKvmR8v+WSa+Tj Toxsx33eh/vecFj1yGFpjK7Amc3FuN9E9CPrgoV4h/NMNU319DlU/jyjtZKXJAHcE3Geq/VN0uqd ScwFqzPT3Ia+DOwa1pGRkhLpMPgXc17U0ZsXZ4uPsdgstizlZiVNRS4O355+hi9vdtW+N6bWjd/Z 1bamhZ0Zvt3VmvaTTT1ris5cnxq0Op1sAtNf+8+ZzXMzs9lrJ9K5bJMtdMsd12VgqcsibwrXCFsg De/oy4L+TFOZaSI3Q5hompPRz52foHVJxc6sMRggfYJa2JHMkpXOKcXBFJxgJCfbgqBLSRFd+jXZ lmyWaXDxfVnW4zik4hBVGp2K4vnIk1Gsw/jAhJrgS/zPkcgRHaa4R/8Xe98fF+V15nved975wTAa RCQECUElhqAiMZQSSw1rLSHGgI5AjTWEH8PIEGZ4gZGgaylxdZjfDDPvDJRSw1LXWtdaY6zXuF5r LNdrrddar3Gtta5rqWtda1xDCXUN2e857/Azpp+9+/nc+8f94Pk853zPec8573Oe5znPec4w4PDJ 4R9x2VwCx3PCp5wyK21R00tfbXxuwcuPP73gpWUvbH5SUWYwNqgSuXTuCW4ml4cr8afN+aannpo9 O3bmwhnD/zTjyccem8Ffr7VuMVGLshGiTha2kQWkPGexKkn1zKykWc8I6pkrZs9JJjplXKLwhDJO syCelM15PDJeN/vx+LiyFt0B3XmdgoYbOVHYgDrdooVRixYvyllUukhg9rzg9YFPl0T9ccYLA7j+ v/gitjW17NfnzBg9DGdMxCMx9mgQMkPZp3rssRdfSMlPG+5RA2Ut0D8z3MuVFHe+sbH72cr3NuRv XbB4Mf/c2vrk5Dnzkh7288/pGwBTZj/sFyq2vqwvLyupXLIkM9j06dPyOoVerDOWvJCTzMfMjMnQ fl0rzlJGTdOsmClMV3LTNNT04krjuKjI+GmWx2VlDf6R+qYX5TN/ziN5niX0DvdEPha94oUF65Yw Dr9fse8wv2hFa9L8OUnzwtz8+hxhlvVb4RgsKxL74emcWdE5EUJijkKrm03qnn7xaS5utorZPTWS kd0lGwXLuUeGEojEjg3/avhfh/84/EvuOeg8hksf/s6cJ5/KX7J4VVJi8tzZCYXPp34j/qkk/jn0 +oB7kZvFxXFfHf5g+JZhR0rqnCeffca+ceO35z+TnJy8YLMsK0WTsJHMIhU/0UVEQ3Jy4IxAeUW0 UquM0LDgc0bEDASfj7MoS6eOj7DEMpnR85cq/dMF7HIhO/P3ie6zEwcjZsJZw0+/T6Z/dv0g9gks /zVu3gSJhje1ounJmFVpX978ApVoXNG8+ZWLZqTOUMSp1Umxn0YJFX8b+7WYx+fwPLXhWZ/dVqxU 7iKzybqcWZF0b2g004QXtWplXFzMiyQiLpKymwT+IyOffPHJgid5lXZavPox1VOqJIVCRRRRih8r cCuGr6Qfy8m3XfrZz+IXUX8eV8XXlXPnf2nGvC89P0N2oqPCf36WSsVnXPqZzcaVcGuGf8w/Nv2l FQnfjE58oSX2wGl+2gD3V8M/HRiu/8q6efOejdN+8tgMHA3zwklPHH8h/YFL5XbzZfw/KHIUvxaS hN8oG5XvTE6qpSrv5KR+dkIqmpDeRvrR+KTRaJonpfsRX4qws3Q94ro2aypNpak0labSVJpKU2kq TaWpNJWm0lSaSlNpKk2lqTSVptJUmkpTaSr9/5HYl+eX8XfpX0YQFIQn05FkLJAEQhhWol1LUsNY IHF4QrEK7SqyPIwFEkMyGFajXUOKw1ggsSSPYQ3adaQmjAUST0oYjsB7DKQpjDn0uRrGmIcbDGMF SeUuhjHm5G6FsZLEccNhrCKxfGwYq8nQ6DwajF0dxhEkgV8YxpEkl88L42l8J+9lWEvloMwIY8hB OZ/hSLRHK1eHsUCSlPLadZRPpRjG4E1ZzvB0tEcpfWEskETlNoaj2DxiGNN55P4zqTyV+8MY8lT2 MBzD+DkZxpSfQwzPQnuM8loYC2Su8jzD9LtH01UkjGn/+ww/QfurEsIY/VWyrmdT/aqWhTH0q0pn +Emm3+IwpvqVZfUU618cxrS/3E6/V6FTWcIY+lWVMpxK5aOyhzHko9rC8CI2z84wpvMwWWnGyV8z Tv6acevSjFuXblx/3bj+unF60Y3opZCUkSpSS8wok0g+qSQbST1yK+oTn1nJJm4asZA/TGo3ordh Ulsum8E6sVVhV/x3RZ/ip8jfJT9EryUkHSkL6FViIhV4by1pABkxMol8jf3dEZHlZWgxAVlIGp78 FfZMDcp6tG3E/FaMSmJcN4DqSSPjKG0STybWqxKlFa20XxJrr2drpk+trJWOpaulbzWgRkfXkzfR Vjs65tFPjf9HK6EcWdhclJskUoSaifFA37+WacDK1kTfaUHr4jAHteNWUIHaJjy1MmnQ3mmP5GGi LJYD1WDGYjZLwyhHX8LodJI5ofei0d6vMo7kd7/F1lXG/voLnaOKPRHJUnC5GE9pSsP4yZykMY7N 6GMlm5lMNjKpiJhhM3mNrSaJvXczyk1Mo7KMZP0ZGadWJhNaF9nbzUxyI7IrZ2NH5Pp1SHYVbEYe Wz/uicg4M+AtFWxGWR9vsXdVIH/0e+U67VsBqWxiViBbTC1yA3su4om8Allz8rtM4RkqwnNVspxa 9OR10+c1DKVg1LPMbs1Y18ibHsWV5XMz/+dlNDa7gc20cXQ/yXZVMWq1j177mCVP5Osr4yRAVyKv xcreN7If6PzyWg1oeYutvJbtrkevVJZz2QSZVob3xeTdQaVKrXITG0m5bWSrqRydh/asQY+/rKFH e0nTI7zkKrRWATWihT7fNOn5S2zNDcyurYyHyZ7zD+DnTTKIGf6AvhOfFrNRE9vykNegt/ERz1aH 99cmaFfW3+a/sJZJvAhPCcuErwhfEzKFLCFH+KrwivDCpNGFX3AmvEJ54p7Dk8nt1KpErG/Su7gZ 5IZiHvBkadYyiyxjkRf795lIfv4Fv/SoIDSiiiLcZ5+N/mUrwhfzJWjFDPzLhONX8huIgn+ddwN7 +O8Ad/FdwN/lvwvczXcDf4/HGcy/w98D/jd+CPjPCh3hFNMUUUShmKF4AjheEQ88W5EL/JLiFeBV ii3Af634a+Ctimbgbyu+TXhFi2IA+E+Kh8CfCktwtj8vPE8UQoZQAWwQDMCVghF4o2AGtgibgBuF bwE3Cy5gtwA+hS4BfArfFf4OeLewG/gHwg+A9whngH8h/AL4rHAd+J+F3wH3C3eBPxI+Bh4QwIPw J+ET4CHl7win7FciXlT+QXkb+F+VA8B/Uv4JeFCJ9Sr/rMa71N9V/54o1DfVHxNePRCxnHARX4tA ZBPxcsQh4J9E/AT4cMT7wEcjTgH/z4h/Ar4e8RHwvYjPCKclWsS+Wo1WAxyhnQEcrY0GnqldCfyK 9hXgVdrXgNdr1xOF9ptaEbhOW4f2eq0L2K3di/a/1/49WvZpfwx8QIv1an+h/RD4UiR0GrkyUk8U kWsjIc9IQ6QReGOkBbg2ErNF1kU6gJ2RHrR7IwPAUmQIuCPyO8Bdke8A9+jKEBOV6yqJQmfUfQ94 p+4dwut6dEeB/0HXh/b/MW0tbEog8nedefIMbGklLOQV/hUi8Kv4V8Pal3WqhDarkb8JnfLQ5lvA W6BTpRCENpXCO0IPUULCWJf6R+oDRFC/q34X+D31fwM+qj6G/KfqnyP/pfoC8v+tvoynv1b/GviK +grwb9S/Bb6mhsbV/6y+QQRoJzesixFZ/UL7v4DPaX9FBO0F7QUmBxcRIt2RbrZeSExn0BmIoKvE 2jndMd0HyE/qTqLlZ7qfAfdh7QJbsZa4OSNRltWXlZOkis31NSS7qrK8nqysKbNaSLG1qoz6EC3h ivQrkhAbE+xCHuNUDHFEzWQnt3JEM1rj2G2K0xe8OjZKgVuJjASiHTdOiRuKzlxW/yZZyXI9y9ex fCvLfSzfZX7T/CbZy/KDLD/K8pMsP8PyC0yLsjY5zEx/LWYmOJiF+9njuNM9gfvYbNzsniSJ5Cn4 ojnsf7ilfCuxJg041IKbaV/QxtG/roD5eea3xsrp5LFHljNINFlA1pFSeD8Rd78WYic+0kl6yB5y gBwhJ8hpcp5cJtfJLXKPDHEI+bkoLo5L4tK4bG4lt44r5ao4kbNxe7mD3FHuJHeGu8Bd4W5wt5n+ OK6L0N9A5CKPgVOU02Pk8rFh2aajdsrl08nhclAunymUy5Qlcpm5XC6/nCqXWdPl8kWJ4JJMuJxE oqJ/Syk/lqjwgFtdLz/XL8RdDuU3komKfoN13RmZr3XDkBvK9fVyff3OcHlcLr+5UC5fj2f9hDfm v7H0jfw3ysO182/0vzFUqpNrpadLr5beKxPkGizVVtZVtl8eX14tlxXFcmlIZ700ldrKxMqMypWV pZWNle7KXtb6mNFu7DYeMPYZLxvvbCQbYzambMzeuHqjYWPTRvfGHpnjqhqao/TLM1Z1yaXJKpfV N+SyJk7uZ7aFSy/bAZwZ+zRiRUSIfQpwhf7/yrW7QfsIJ55FeRB0hHD1WkK+dRL4OKgPdIYQM56b Yb/my6ifB10CXQXdAN0C3QXB44vpKB8QGBQI+1DEeSjWg5rC1Azajn6ZKJ0gHyhEuFoJJU7CumGU vaA9oP2gQyB4xHpoVDwBOkVIy03QHdB9wr1djXIINMzHm/W1ltot5tjaFnOJOcGcYp5rTjOvAtYD N5q9rN5ormZYMneZe8y763Rom2vJZO14XrvT4qRk3of6PlFrqbckU0I9jdFBtFM6HqYMc5pluTnH 0msptfSaqy37LaWigPKouY+SeZ3ZYD5jPm++hLEZ5hzUSyzbMW6dpRS4eowfCzH3iFrwnWsJmXNH 2i3N6H9iXL/w+HF8poDPuRPr5pTx9Vq3OcVSb84V0zDvcXl+ywmsaxzV+s3nGXWajzD6gjp4SaE0 Wq9nc6eAr79ItW7wQ8lmThFvYUzI4qQk3kXdYE6R9WBOq4s2l4gi2qqhE+hlpA4dpjEakb+sDyZP Jsd94hHQcfTJpVRrZbrOGZGfeAbt28Ky3SpeQlsfpRH9oay2LMc7x+nBvBSEuiUaz6Jl2VOdW+Iw TyKVJewCZEnFHOmYw26+Yb6KOURLtkVnvsFouSXPfNeSb86w5FkKUWJNlvWwFSPmqUFZQ20BNrIO NhK2Ccizj9GIDY3wOGIDt8DHwfG2I9vymM2IUZYTYqylCXM1hW3mKMOszmSyfYLtOc09Ft+ITizd 0E/3mA1R+2E0ZlO55n2WzLG6SG2u2tJNx35+vLyX6LpEvZgGygAtFfWjtjjSngMbzQVNKkf24GSb /UIK9//P2rRY8jkbf0Bpss2P2LLYGLbdAeAHYT9DfUeLuM2sF+11RNxqniturYsWvaIoSuOed+G5 VKeCncPe6+JkP1WnC9t6uIT9Vov7xN2TfU7dcoyhlAhMKQ+YUjIwCHP3MDoIW6IU3jMj/UfqtSvg P1aM1esS8e5E9t6R/ucpjdZTMT51bM/V5ZtLQGP1QtQLH/k8R96jWDeo1ir2YK9gT2JPnRC1Yh94 sZpzaq1169mzEbuNhr2j30T7Q3t4z47u3eNjRPcJ7IXRSBvOAUaj/cL7SLwq+2LGx3YxYbQffIB4 g/l0Rl/oA+thH5TGfNgD+LAH2AcHR2x5RHaWC7UbqJ2Lq8R1o3YcsmSL56mPt6gYjfgcuhfpnjxj IS3N4+pj+5vVW5pRl8bqbLw0uX/L9nH9S9A2embU7qR78/P7s6W3ZU/L/pZD4DFbTGs5OvlsoPuE 0iTfnUv3Q0smKBt7IUHeH+Pr5rktJ0CnYP9as77l7Fid2ljLhZZr5jRG/eCB0ki9l/I0Vh+x69qd 4hHQ8ZZ75lxGgy0Pzfve5jHXHkq11rc11Pe3NMtyeXs69NCEutNc0uJjPpCdDS0hyOXM588Sy3as exxNXj+ip2nslk7YnVzDbuMR7D48nd2EH8Md+CMSLQzi9juT3Xtn4cZ7j8QrP8a9N4ndeOfiDrmG PM1ug/RT+Dj+I9z+iUKlUOHWHqOIwZ0+VvE4ItwncPtXKRIUCUStSFQghlQ8r8gksxVv45b/lOJT xackoPhM8RmRcC/fQ4K4kV8jIXb//iFu3i1kr3Kbchv3vHK78ndchvLPKoGTVCqVhuuJOBjxHvd9 etPl/g532WJud+S6yNe4vbibTuMQE3J3+GVjkWIdbhd1sYjEELnVJYDmEq4S0VfDTuAUUBoog5AK RG91S0E5oFxCqhFJ1q0C6UHrQCUggzy2jhJCxbpGQkxxKLeGy20gO8gb7ofo0GhE2RWurwIf2Sh7 QIhg6/aBEL0au8PPj4AQvTYiUmzE+xvvEO4t8NN4HzSE+9ZC9vfG83H7KWefZLUQJ5HITtx8DpJj 5BTuPVfIHTLMaYiijtTV1Knq6ut0dU2EF4/VLRVPYm28eLAuXTxSlwm0p26+eKhuIdDOugTxACTD w8tHi/vqEoGcdRqxty4eqEUcFjvrBKBGcQBnwwP6VLwtbhfvsafXxS3iTSDEJzg3rgLVi2dFo3gB yCKeFDeIp4GqxSPwMceB0sVTYh4iZF6cj6fLxL1EEA3iefRg4/EW3AfG1yoOiLcIXzsEHCVuJfym I2KNqEJ8/n/DopXs0yjCPofi1HfUH5MI9vnIDPZJx0zYVzS3jf2s8SjuoUTMA+WDCkHrob8VKEtB 0LtYI98iLFfkW0QF7Kpqy+htgljAueXc2I3CgttBxVZ2s6C3ikfdKEhtLAh2aogeu1nQWxCkTUTc csRroH5CrDZQOcgNgq1brWSBmC0uh+SXi91ivliIciStF0tZMiKVQrb1YhPyJqR6lKUom1lZCp1v Z3lpw2DDQytv1VjpzyqjoQXYKD/A/4nw/CfQiMA0omIaUTON6JhGpjGNREEjg2QG00g0NHKXPK68 B73MZnpJUH6i/IQkQi/55KnI1dBOMrTTTeZH7oSOnv1//j6O5BAr03ga7rOkDBqpwK6twG4ti5Op 4rhc1t8lmrKWit6yLRV7WNrfQD9p1fAf8x+D30F+kHDCJ7BGXvmR8iOigAUOEkE5BDtURhZEFhBV 5Pciv0fU/6UxXPStmUuJgui44/AOpCGb8EFYW8NyEKy0AVbaACttgJU2wEIbjOE6Jdq/nv4wHWVT mJrDfUAlR0eJ80Zj3pYw2RiRhu3YzadG6wxDFnzQPbGdUqk4sR8l2jZCdN6R9nB/0uAM8+mTeaO8 NITCz9ZPeIf8rJv1G5mHNGAnNUBvDfvDdOi/QHTeE0weY+uXiTSMrYHU3RklmT8qw7NhujyB+KAf 5TWUnfzVHZfcxsCd8mZ3TeD+jqvu+sBQudPdFBjeccPdbCU7brm3S0J5v9spadHuQ/tdd0iK2jGA PHbHA3d34L6NoE+CTeXuleZihu5NMcibAkMYWyMJFEspwHswTzPyNJvOvV/KsEVjzqV4uy9wxxbn PiTl4OnRhmqaS7m2RPeehn22ZPcJaZUt1X1KWmpLd5+V9LZM9wVpnS3bfVkqsS13X7Pm2fLc/ZLB lu++LVXbCt33JNG23j0oNaLl4WhLqYdv6LMZPRq0ZHumY2wN8q22PE8MxtZ74tGnyZMkbbM1e+ZL dvRcKHlt25FLNqdnyaYsm6/sAdbYVK6TumyhsoEthbZuTxY4ZznWWCP12Ho9y6zEtsezYlOMbb9n ZWDIdsizGpzf8+zCKu559rKc4kHPAZZT/NBtRE5Xd7CV9xyWSpDvYjnFGs8x5NM9J6UjyE8jjwEW W+M955AneS5K1eh5hfUfy+VRGobne65L3gl5kucm8oUYe9x21FMs7aZak/ZBSnekPsjnvnTGLrYV BrfbTng2YI2nPOXI93iqAkOtK71R0qXW1d5Y6WrpkGdI6mot9iY0VKOnBX3OeqzQrDzqgmcLpN3r wRFgu+xpkaLC+TWPbRT3e9yQ0vj8tscPiY3LWzd450I7xJsiJbSWe9OkG61VnmWbxVaLN0O61Wr1 LGvY17rFs2tLYbnT0xkYbl2CtevLmzw7G6pbszzD4HCZVwBe4dVK51tbvEulu602yMFgu+bNkaKY TQ4w7XfZ+r25WKMb8te3+r250oPWTs+uIGnd6W4Kqlp3eVcF7rTuRYuO7ppgNLXPYFzrAW+u1WjL 9OqldeVO7zp57wQTqZUGk1sPQybVrcc8h4OprSe9JVjFaa+BrojtmkJv9cjqgEXgfm/jphho6gpG nfM2GvnWi54rkCGTD/R7ETq94lkmCa3XvVslEStdhtXd9G6TsZTWmuW1w5Kxy4Lp1J6Dma13vF7o pdkrwbZve7sg1fvUEsISZni8JFuHvD3AwwYxmG0XvLsbRFuid59ksGu9B4PLbd3eI4E79igqmfES s+33Hgde4u2T9PZY7xkrgQVSGz7sPY+1uIHR7tliJfYE7yW0t+DtWvtcqgt7ivcqcJr3hmSg3iaY F27P8N6CTg9770rVO656B7Cz8r0PpGr70jYiRbXGt6kgsWttOthSYVs08OW2OLTHUEw9VTAT7YnB fHtOW3Kw0J7blhpcT71WsBT+YU/QaF/Vlg4rhfyDNXJPthd6qK8IGsdj2/62TKwOeypYb+v/ViEw 1ZEXnu1hsIn6kGD+qGXapVthL8dkbtfD6pZi31GZH8JKR/DttmxgtiupPww2U89jLbWva1su5dhL 2vI2ZdkNnp1SrmzJ9uq2fEmc8HQcdjxsF6UcJ9/euClrvP3vuNq2PjBkb2wrlbz2u223sbOMbfck LyzfCMuHDYf8dkP7VinXqYGP2lbeC+s1MutNl/evczr1SM6Y9m1Mp/AqkHOyFOWMt++mcm63j8iZ efse6mMxtr/dGxjCWNp/dHWYmVmdk0mAefsB2a/KPIMH8Oyc3y41VMPDAI9Ysj86mCmfLLYm+P9t dJeFDst80v0Y6pTX4lzoPQKPxE4Neq5hfuBgM8XWZAewtca5pL0rMIzTpJnuWXdTaCfFoV3OLOC9 FAevjW+3473Bh85lwAfC8kkHDwfH8+Bc0d4jCc6V7butec7V3quh6c5iz3W0L2nfFxh2bmg/KFXT MxRz5rcfCRpH2r1Hwu3HaLu1dHyf8TYMj9QYuA9/sgx7YZwNU2ztpRhjt8OTnHeWtyWGTjqrwM95 p6X9eDCftodO03lC58p7Ye1GeU6ntb1Pmuvc0n6moc/Z0n4e2NZ+CWclTvPQRVtp+9WQxeluv7Ep xumHX62evDtCVyi2lo5vh3eyQA6d0PtW5wqsTnDuxFjg9lvAu9rvBrNpPBC6TndN6CbFJX22+vaB 0B3nQvRJc+5tf8A82B5I74AnKbRa9mzOw34C+xyHaX/0Qf9gpvOYXyVlOE/6dfBy42yG4WSKQ/cn tI+3yc/jdJz+B22n/HGBO87TsFUJNuaEjSEqCN4O77Vz/kTEBoheQkM0TggNw/ZwGjov+pOlhEfg vezElD2tBf4zm8Y5OIkQUYSWUWytYXiJbAlYS6pkd17xp2/Kcl73Z2Jf3PRnS6ucd/zL4Qe2Ip7R 27e1GYNOu92935hk97bVBOvtUls9YqflbU3SNntXW3OQ2HvatsMD7G5zov++Np9RYz/o7Qr67Efc TfASF9tC0vHys23dwXT072043rqsDXEajd+CTfbjbfvhmfug362ICg4FQ/YzNKbacbftKLxuqrvb OF+Otexn2k6Aq/Ntp+DyLrWdDXZTqwj2jloIdq79atsFcHWj7bIUi9mMmO1W2zXpPNr7g3vomRhM dd7353UI2Fk18DblbYPB/bbmtofBQ9Bdk5RR4m07FTxKMXb9VR+POQd8muAJ+wPf9OApu9cXEzwb jh7lOE2WMMvtXf78IHEe8Bd2aB2Fvp2hw84h//qOKOewv7Qj1iX4jR0JLq2/pmOuK8pf35HiinXv 6UhzJfibOjJcc/3NHUtdKW1nO3JsJ/zbA3dcaZ5dHbm2y36nFOXK8PukI7LHcy3FGZEqezlXDjxA vaPeH5JuuXL93R2rYDO98M8sopZjV9cqj79Dj7jiesc6nHeNOO+YhYz3pdiDXVKPS4+Z0+lTydBq 8e8J3XSt8+/vKHGV+A91RLkM/qMdBle1/0RHgny20rfjPHX6TwVVO274lsBTsegCvhfRhRynuUQW l57wnx2Jbcb7fFuv/wJwErDX1diWbMxyZeBsPeLa6r+8aaFrm+dkR/UEP9/vvzaCw1GKxbs1mO2y +/s7RJfXu3XTwvH+Xz4BXRKw3nHbf7uj0dXlv2ctBJ+3cNb3+gcR+UT7NB1b7X3gf769z/8wNJ9q s2Mb1W+H3dUT4LGK3QEN9gWkBPnrafTrXBiYznYcPUF8vvhgqoP4koKk/KhvvnTcfgR90hwq38Lg BYcOUdxlW6ZvSfAacl5a54iGPy90xPmypG2ORN+y4GWHzrcCeaJvJXqmI2bQO5J9q4P9jlRfMayL 6RHzb0BEtN1XHrxtM/qqsDpjWzr8Sb7PAmkjp17XZ5VER7p3bvCeI9O3JTjoyPa1IF/us8FWqU8+ 5MjzuYMPHfk+f4i3lfo6QxrwvDOYKOew212QiXyLKfXtbehzrPcdCE13lPoOB/Nsyb5j1jyH0XcS eY3vWEOPg0Umcm6r953G25t854xZjmbfReyRPN+VTfFy9OtIpTGeY7vveigGM9wMxWN1GrQ4fXdC SQ6f7z5uVfLNqMY3BC3Qm0IJ1jssSY5QuxBa6OhGRCE5ajz3Q/FhP0bzrLB/Y7mjt10bWuHobo8y Jjn2tMdafbam9gQapbCTPb09IbQS0psveR372+cGiaOwPcVKMCottBrtO62lOCkyEJd625daUyfM dqg9J1TsONqeG9rAcLnjhG9vqMpxqn1VyOI4264PWR0X2teFtjgut90LtTiulasQNfW3l4Rsjtvt hoZt7vWBk5319MbRudyd6FstNdqPBGKkAfsZ3/1gvmsf1jvgOtim6vA67rVXh9yOQZq7jgTiOyTX 8UBSR5erLzC/o8d1JrCwY7frfGBJxz45znddCmR1HKRytnYzuz3iuhpY1nE8fLfNDKzArVa+z46/ q8q3VHY/dd0IrJx0S2X+zXUrsLqjz3U3UNxxxjUQ2NBx3vUgUN5xyU0CVR1X3aqABaPYPG5dwBqs d0cHtnTcoO/tuIX3tnTcpe/tGBi9Rz/seEBvzZ2EctKpopygZZQTtIOHTp1sLfQ07Iymt+POOMpP ZyKNwTqT5Zs11VHTMRoddabSfdSZTvdRZ3r4/i6/pd59tjMzPBusq+OBOy5g68yWP5GQPyWgkWpD NY21OvPcqQE/PD/7/EG+6bvTA52d+e7MwM7OQvlzBlli4U8SWGzpLgwc66wZuXOxzwQYDn9GgVHB Jnd2YFfI714e2Nu53p0XONBZ6s4PHO40upMDbquKfeq7kn+VEPYtMkH9XfW7RMm+D5bAvg82h30f LFn9S/UNsph91+tr7LteL2l/ob1ACiOdkW6ygX2H7Q3dMV0fqcCMWSSZfJUQsoK8TuJJOXmbZLC/ s1ZIfKSdFJEe8rfkG2Q30mtkHzlA1pP3yVHyBjlFPiRl5Dr5Pakj/0LukLfIIPmMfIvjuVTSymVx S8kBbgX3N+Q9zsX5ycd8Lv8y+Xf+db6UfMZv4rdwCn4Hb+ciFKsUBdw0hUGxkZuhsCo2c7OERUIa N1v4QDjJPal6QhXPPaVKUM3j5qjmqxZzz6oyVF/mnlctVb3MfVm1SrWRe0klqt7iKlRbVAHuTVWn 6l1uh3pQk8K9o1moWcRd0CzWLOYuajI0K7gPNa9qXuVuavQaN/cvmnaNn5+rCWpCfLKmW3OUn685 phniv05/usJv0x7Qvsv/jfaQ9n1+R+S3I+28Szddl80HdT26fXyf7pTuFP8r3WndOf6C7kPdh/yv dZd1l/krun5dP/8bwkF21exT00T6vaaC7SAnyAcKkfiC9QXOAl9BqKC7oLdgD9D+gkMFR1E7UXCq 4GzBhYLLBdcK+gtuF9xDi7GgpmCw4CH9bhj7/iBRd6u7Ca/+vvr7hP7uUTR3hbtCCHeTu0k47hZ3 i/DcH7k/EgV3j/s3InCD3CBRcf/O/TtR8wpeQTS8kteQCH4aPw22FMXPINN5+vs/UfxsfjaZwc/j 55Fo/mk+hczkM/gM8jj08AGJo5IjT2BNl8k1trJo+p24wpOkvKinOLE4uTi1OL04szi7eHlxHlJ+ cWHxeuDSYmNxTXF9cVNxc/H2YmexrzhU3F3cW3i4aHfRvqKDhSeLjhQdL+orPF10puh80aWiq0U3 0Har6G7RQNGDYlJ4rlhVrCuOLrxYHFe0rqikqAQjS4oMRdVFYuFJ9Gws2gbainp1kb3IC5LkVHil 8HrhzaKuwjtFXUUJhfcLhwqHi4QibVFUUWzR3CJ9UUpRWlFG0dKinKLcolX0m1YRH0GasRP2Av2m dwYRYdlLyWbsi+VsL7yCPXCAvIpd8D7Jxx74kBSQ20irmYzWwJZ2Er2mR9NDijS7NLtIsWa35gfk G5ofan5IXtP8WPNjsl7znuY98k3NTzQ/IRs0JzQfkNc1FzUfkjc0/6j5R+wpjnRjt1Epz6XfOVxz iRB9IigZlApKJ9lrjur36g/oD+uP6U/qT+vP6S/qr+iv63fpb+rv6O/rh/TDa4W12rVRa2PXJqyd uzZlbdraDP0SfZI+a80F/TL9Cv1K/Wp9sX6DvnzNZX2V3qK36rfoW9ZcW9O/5rbepnfr/fpO/c41 9/QL9fP1/JpTa86uXbpmcA21Q059Rn2OfR9RO0Fam5EyyC+RvkR+h5QJz/B78mVyCylL83PNz8kL mnOac2Sp5rea35KvEE53b5qK/bQylagJMVSDRMJVXUDZCNoKfJlweccUzxkMVScM1VWnDGLVWUNj 1QXD1qrLhm1V1wz2qn6Dt+q2Qaq6Z+iqGjT0VD007Dbxhn0mjeGgabrhiCnGcNwUz8o+U5LhjGm+ 4bxpoeGSaYnhqinLcMO0jM19y7TCcNe00jBgWm14YCquJKYNlSpTeaXOVFUZbbIwHGeyViaatlQm m1oqU002htNNbtaeafKzPpSyTZ2Vy007K/NMu9izfNPeykLTgcr1psOVpaZjlUbTycqaqhOU2Hqw lsp60/TKJlNMZTP4ojw8ghhPlJ/xRHkYTyO8TCbaPp56TRcrt5tOU7lU7jFdoX2MxdW5I3wxXo7+ B3vfHxdVcuVb9/ZPGgYRFZFBAooIHWAMAwYVmMYQwxq66W6aH3EImThM03bzXNf4Ia4xxnUJ67KO yxgkxhjjI8ZxXGOM6xqfIcYQ15B5LOsYMyE+Y1xDjI9HjGGJz4/R5p3zvfc2TYNxMsnLX0t9zqnq c0+dOnXqVNWpAm6vG3nlwrpR1pntA3o76arlDB2+e5OA62lAfQkB63Zp3YNX+tcFX7myLgP2GVy3 GrboWjfwyol1N185QG2wfU6vuw073vANcc5j+8pQ/X2uw/aCHYbV/J5fj/FjG6n5K/d9V1555Lew XNiW7dSu5F55ncy6sI94zf445LH+BNif7aLlrD/bZPa6VB5PLdd0Zx/i8fUmrcv2pvqT0Ueup+Va 39Tcm+Ff4M32Z3rz/LkhPYcn9yVS11Cu2iFkj51K7i30DXtL1m3ylvnzvav9y2En7puaYzzCPvP8 YN/lOQL/JeD+49kppd+h/KzS/1B+cfr+a/3l+RTef+0zzy/4vjq2Xqff1nRcoUXmIZ56f4V3rd/t Pezv9B7z7w/Zq/npedOpd/Z8El+kvd9B3nQ27HOknVWbaT70+/Km8xOfmy4q/X5Srtkl0tZNbyp2 elqOOczz68DkXBtL6E390fxQs3vTZVp3aU3E+huWh/yX5xv7ZcvvzyPtGGonwu+b3vbdaLpOa+6N CT+HL+1Wcs3vtc+hPMzvm26t29J0x/eo6S75uOrvoVz1eV4LmC80B9S8aWydmdd1Lee9BOv8xog5 EpE/aVxD4/twXRL3R8u1NUWbW5GfQ3PtTXW9pM8+MTlnOq9BGL/LT8jfjpiTEf7DOdvTZ1xXyHsV 74uca/MyNId53ec9TMs1P1LXON4/w3PI5jWC67KfkS/5Yvw29h2vz1+n+ZF3vb8BfsV7oba+09rt 3eRvZB74Dq9B5CfeLX5/aN8nPb3b/Ru0uRda19gHeB1p87fw2Hh3+beyb3v3+Hd49/l3eg/6d8Mv 1XgANjzpP4T9L8J+3jP+I2wvb4//uLfXf0rrG/OG4Jr/TW+f/yzL9MUHDvgSA92+lMBRX3rghM8a OM128C0JnPMtDVzwFQUuhdYddd0I+Yk2HjQHfCvX9fG+rK312lwI+XTEGuMrJ93Z5rS++xwTOmj1 fJ5Av29N4Epof4tcGyPXuI7Je0ikL0/ZFyP2P99LgUHYSZ2rPm/ghq85MMQQ8g+tbU22th4xTY2l QrGYFo+pMZl3wH/ee9V/Eba/6b/sve1/OxSn8dwa8V9H3MVxTnjco8ZJ3lH/Le8D/x1v0H8X/sN+ x3Nci+d4XdX7xzBvLf6HTXEB0ZQQMKKvEdCUHIhh4D2YAf7EvkT6NC0IxDdlBhIxD9R4sCk3kNKU H0jX4sKm5QFrky2whG3StCqwFLZh0PqtAo95U0WgiPvK/WP9mtyBlezzTXWBcvRd5W1qCDiaGgOe Jn9gTdOGwEtNLQFv09ZAc9OOwMamnYHNTbsD25o6A61N+wPtvhPNGVpc69sYGPZtDtzzbQvc97UG HjUdCnQ0HQl0+dqbZQbsCeocRZzNc4XXJtLX19FsxnixHjwWmi3VmJhtFIobuH/sl13NsfDfA82z eUygB/s52YftNEke55Fxd1i8DZuzTXlt4nUozI/gM6q/hOJm6gPqsBzm5/VIOxdoe5MaM7HNtDUD a7S6l/qONqeG7x84a/C6wm1TP33dzUm85nBbfII3/dz0CyEsP+T/S4x+NfpVweefnD/z/ctOMa6r 0P2V9F7ctrhw21KL25aP4LblRWOy8RvSR3GH8p/mbPNzcgbfnshWPt/KK/j2RC7C7ckncXvy17g9 +RRuT/bj9uTHuD0ZxO3JNdye3MTtyTDfnujm8e2JLoNvT3SL+fZEl8u3J7rn+PZEt4TOvYfFsYk7 BtthUW4bsF2z3bTdto3YRm0PbMFSPSVLaVxpQmmybV/pgtLM0tzS/NLltsOlttJVtr7SilK37Wpp XWlDaWOpv3RDaUvp1tIdpTtLd5d2lu4vrbMdo2eHSo+UHi89ZTtZerb0fOnF0jdLL9uOIZ2kdAap B6mXSscAXCbg+wLTKRq76IgT8BYau0+Lz9DZ9wSlZTgNLxdviSt03r1KqVj6pLRZlPCdl7DxnRfV lESdaAjr76hYQD0dLdpoe1DSwn21BW2j3NviJO4v9TqOekz9LY4tuVO6vCS5NLOkpdRWHFscS72n /hcNFg0Wx0LHb5OOc0nHdNIxg5IkMinJdOLmN9NkC/6/uVzxnDCI94k8OoUXiEIRRTqViWfEKkqx opzSDLGaUpyooDRTOEQlaeoSbjGbvLNOJOB/1JNEC6VnxTZKyWI7pfmin1IK9f2H4j1SrBQr0oRk bDFuneirPU/3PnveihFbjL2w+L69hPIyW5d9NeFhu9NeY6+3r7X7CNYX5do3rRixb3nhYXnjijb7 dvt6W7q9zb7Lvse+z36weMh+mHBridN+zH7SfsbeU9xq7y3ZYu8rb7QP2K/ar9lv2vMo3aZWSKqt nyRMpFGSg1Q8pCRI0dIDJRX320dIn6BD77gFWfWOBEey/Rq1kEdSCYrv27qURHz13Aqn4iHbMElc b+8lvW/aC+0nqcY1h8URZ4txLLB1OTIdubYYWzoD9SiPqPmO5eUt9rbyFofNsYpk7yIJrSwFkmpI O4Z60m2to8K+trh1RVtRrsPtqCvKpT5vsvcxcGsMjgZHY5HNnleUqbVSfN/h14Ba28B6OFocG+xl 9oP2MsdW0mmHrYtaI3DsdOx2dNoPO/Y7DtkPOo44jjtOOc46zjsuon0Cx5uOy9w70uBtrW0Gx3XH dfsW+wD3lkaDShowBbWZk/T6Q2BFT2U5W2Q6oGcO1rnSU7mm8iXHAk3DcJiOzjS+Zw3XnqFy44qT lZsrt9lOV7byjW15Y2WX+0LxoC3G+WDFgPsS9BlZ0abe4+IWt7wl7Bb3inKPW3y/8h7f4Tplp5kg FvlsZ9KHtjtT2ebODGc28jxnYZGtKNlZ4izjfhQP2xKdq51OghpnvXOt00ew3rnJucW5qSjTud3Z RrDLuce5r/yI86DzMOCY82Tx/fJG5xlnj/MM5+WNxf3OXoI+ggHnVec1503nbecIwajzgTPo0jtH i3K57LJUDhfluuJcCZUdlcOVHa5k1wJXpivXle9a7rK5VrE9bP2uihUjle0ut6tuxUFXg6vR5V/R ZnMwEHUDe5zL4moh2OrMJlkNrh3ONvb/D69a0UaJ7OW4w15Y3lLeQtxtjru2RFu6Y4y88GGlYK9j W9AoGitj7DWV8fb6ysTKFFoP1jv8yiyqTK+02nsrl1QupTl4p7LIUcetVq50ZLr7WQ/3Ffeg+4Z7 yD3svue+735UJVeZab5uZ5vyeNOsdFTFFq2qmk3rzT4GbrEqqSoVkFGVbT+sSOBnVXlVhZhvJIFh xQB5GoE2Q0KeRPOQgaWjhZL334PcMls/zT1P1WpIqFfmP1mekmuna7erk4BxZ6i033XIdcTZ4zru OlW8zXXWdZ7XJFuX66LrTddl19uu665brjvEedfZs+Kka8z10C24ttvojnHHuxOplFKU6053W91L 3EtdcZWtJGunq9PZ4y5ynSW80l3udlS2uj3uNe6X3N7i++5m1N/o3uzeRrnypN3d4e5yH3B3u48q q6L7hPuEx89rbZWzqqaq3t7rPu0+V7W2ymfPq1pftYnGqLdqS9X2qjYapzb7HqzGZ4pbeS12xNlv FvdX7araU7XP1lV10H6m6nDVsaqTVWeqeojeW9VXNVB1lajXqm5W3a4aqRqtelAV9OgpWTxxngT7 Lk+yZ4En05Pryad9YBOvt55VtFMc9lR43Gx3tuqKUWWltK/1LLdv99R5GjyNHht2wvP/FWlNE2nx ewT4Bp7fEiYKbwhpWaqYXTiwLK7w2rLk/O58T8FAwbXCm8sWPH93WWbh7WW5+cbn7xb0FdwuHFmW T7TlhaPLbIUPlq0CLbisIv/A0jfzu/K7l+mXufPJvMssy+r47Q2ms6b/gXczfFB8iEbgL8SHKf6w UxRhFFVk52gakY/yf5iQZnehEX5z5lkqpNrTlBdRfk73Ps+S6k2epQRFBCsJygkcBB6CNQQvEXgJ mgk2Emwm2EbQStCu5h0EXQQHCLoJjhKcIGDZpwnOEVwguETQT3CFYJDghloeIhgmuEdwXy0/UujV sspDUG0miCWYrT5LIkglyCDIJshT21yi9qc8TNduVYfpoF/VJxyGI0DVJRKgexhUlxEUKm1Wr1b5 esL0Yno9wVpFZ9hniaqrlperdg+H1jDoDgPSrdpHsF4ZA7YP25ttUV1C4FTagH1qVFt61JzkIsWq 9uqfyKu3qPpcCMvJP6q3K3Kh42BYvlG1E+XVbWq+S7X/UFjeqtqtQxnPUK7pfkAdX873qH0cCsvV voX6uI/gIMHhMD0j+jJFVy3X7BCZr1HH8hjBSdX+w78n5/nBvstz5L4Kmj2e1P9IO0T2P7LfkfkJ xfdDY3smjBaZazy9BH3Vm2osBHHTjO+fOn+S3d9pHmnnSNu9w1zr99PySBtrdnpartl3Sq6NZWtE vzT78Lp7aZpc81tej6+8g/yd2pPXdV5zPdWT/PypeeQ4aH4emYetAdPmvHc8miaPnCNPmzORebva Hy2PXFuetNY8LQ9fi6bLnzZHtfyosleF8sj5uUTZw0L5adV/Ita6UD6ktI+9j/kuqPOffKd6oDrk R9VXqyf8SVvXeU+4pvJcUe1H/lF9s3pi32c9b4eNuTa+w+o6MqKMTfWoOgYPCII0F/QT9tdsWJOg 7H+R9qtJVuxTs4Agc6Jv4FWhxkaQq8isjSdIJEghSCewKnaoJZvVUl9qi6on5lXkeqGNA80B3pt5 X56y5mt9jPAt6MI2vzdZB61eLc3BWi3OGKp++hr4tDUt0lcjfKnWoeqjzs1a0qN2jQIh/9Da1mRq /nShOhRLhWKx/jAa6VeTT7Bctf0qgorqiTiNoMat+DDHOZNiHzVOqqkjaCBoVGk8Lo+qQ/Ec1lW/ olfNBoIWgq1KXyOhZocCvAcDYpXxYH1qdhLsVufBbFVuJ8H+6lBcWHOI4Ihik5rjqn/lhfVbA7JT zSmlr9w/1q/mrOIPNefVvqu8NRcJ3iS4TPA2wXWCWwR3CO4SjBE8pPEQBAeqQ3FtLY13LcUJteRn tbQe1hoJYgg2KxCKWbkdXi8PqP0lfWu3qeN1RR0LzZZXJuykzS30j/1SHfvadmVMoMcVxT5sp0ny rlRPibsnxds9qk0zVPnhfjQ44S+huLlfHachlX9p9cS5QJsHaszENpu0Zqu+WttVPXn/aFd4sNZR P2s7lDWH2+K/oMKb98R/nUinnkilDukh3w9LscImRMEmgi0E2wnaCHYR7CHYR3BQ/cxwmOCYEBmF lJ9U4YzKQ5A6OgEFPQS9ar0+hRf0AUU2yldVGdcIbhLcVmHkXQDLe6DqEhQiP30CmLZUr4JFhTgV EoStIKkgtSCjILsgr6CwoAS4kLCWytI6Ca9GcqZ10qeagjzkZUQvKagvWFvgQ1pPaRPwloLtlLjU BryLaxD3noJ9lA4WHKZ0rOBkwRlKPfzOQbzBUoS9u1KHN1Iq76Kcg3dOJuBtk8l4z+R8/NVxKv7q OB3vlnwf3iqZj/dJFuB9kkvxJslCvElyGd4h+cKfsSV+i4V/4i0W+S/RmJf9fsj3EjRPQ9/4BFoG 5ZsJtk19lt86lf7U9tsJOsR7n7/z/N0/cRp7/iG/YRJvKBV4y6jyflED/p7cgr8nfwbvF03Em0WT 8U7R+XibaCreGroA7wvNwDtCM/Fe0Cy8EdT6/02upD+pvyIsNIIOfpNvzi0hctwEdaHcnLsSEJVL Fs9pEKYcmlk5jULOjRE6eq7PTREGAiPxF6blT5MapqaczKkpbdU0aRp5OblTU1rC1JSTPzUt7Jua cpbnHAFomCXaco4DVJxrzDXmrJomVUxOuTG5MTnuySk3Pjd+Olra/skpNzE3MS1zasqpmyY1TE3T 2u+PsaltmhQ3TZpG3kJf2vI0fc7bObdy7qZZ0vRPbOMIjYlv0ZW0HTljCx8s9DEtPX9qSkvO2ZAa JIl3MlaTzIdMi7Qpp2n165wmnZomRfQhNyU3JadxmjTNWGasnppy/DmnACpm2+dsmCa15JwFaJja WLh9asrZmnM+5zLBeSpRGZaxTE05O3IuAlTMtIU1U9N0Oi9cPzWluaemnN2TU5o/zZ/TOTnlpuem 5+yfnHKtudacndOkimnSNHx87433PQu8vZvf290izPqt+k+LKLzpmb8jxaTP13+cOF7Wvyxy9a/o XxHP6f9S/wmxRP8P+n8QBXiz91K84/r9tIM1Sm3CTOvfSvGMMGZ1CzEFjgpp3g6hJzAQmEA7IWQq 6wjis1ozc+dVLL6adSOrdV6FtXBexUSyzlbyrG5K/Vn9T/x89D2Wic/zL2WdmN+fdSXr/vxh6+ys djUNWWVrqrUka1vWAYJtWfessdZsa1lWB6ULBESz5llXz6tISV08kJI6/8L8K/P7Sfa2rK6s01mX sgazHlmTsralpFprrDUpD6z11rWLe6i14cV9KWbiHVzck+XlGkS7oOi1uI+lEb+P+NdbNzF/eL/m 37NugW7nCIatZmtGVrvVSbCdoM26y7rHum/SmPkxZtrbuU14LzePmfGJHBhV8MXhby7y8DuNJH7j fEY9QCy+KHSLeyYSnwvwJnARVpKkCskz8Rua+duFlFwu7NZ0a/rc3RPJSj/J9VaPVrYusS7Rni0a WTRiXUqJfkL8RdaiUHklpXJrebis8JxKHu1Zcn1yfYjPo6bIn/SJ9EQdp9EvXK9wnSL10WSgnsbj oKS2x3zT9Zl/CyV3xXyLx00+JH+bzPxd+V9Fivx9+bZYGPXNqG+KD2B+lUW/GL1WfBDfDsBvZY5X 3/+9kH+PKPObmPVUn04c8hH5nDDIPSQrCXWSiSNJLEBsifFKzxWisltIc26gdf7OAJLB76kXS0XR xN/BzBsVM59tf7Y9KT/p1rxRTunGdOO8B/OCSfokS1JcUkJSctICtM+eGSW/Lr9O7X9N/hpRvi5/ nWSfkk8Jnfwt0kVPPeoTJvQlivT6mLBEf5y0m0HetFMagDe5xUxqdauQFtMpaeFRIeasfldgX1y3 uC5xQ+KG5K7kLs4XNyxumHd63un0/en7k9SfeZfmXVrcOJGSYpNimS8plVJPUs/C3oW9SdmUStR0 kNI+SsTH5bm9c3uTriZdZflamndg3oFwmZyYLzyxblriOtxWSEeqvyhlUQr02zhv4yRJ9Dz5QPIB 6KXpNI0+Czct3AR53CfiCWnnT/TP7Zvbl1SYVMiykPyUKJ87OneU/24M3yUh8C0PyrckyJbdlteE zvI5SyeN3T7LPhFl2W/5orBYvmT5koixfMXyFfGM5YjldRFrOWY5JuLesR9L0nFpBKPeQt4p5hUJ kURn2UWXCPqV8tw2BRIvK3SNtvDkBMyLVyD8M+ezPBOgfpYWDQl74rlFJYnbEmoSapK2Jo0l1Cw4 uKhs7tm5++ceWbA9MT5RMCSsnnt87sNFqxO3EXRTip87lhi/qCzNm2hM2pHYvWh92tHEc4nxCTWJ 6YnbEtPnDCW2Ur4t8dzcsTmPqBw/52hiCn9KqAnB2bk7knYsWs1AEhRgvjAgXUo0UHRM7A7Tccfc swv1qn51kLNNk7OoLImlk16aTtPqczZtDctFPeJhvRLTCeITnAklc04k1BMXyVowsKhsztFFzkWb KL80Z5D/p05+Vd5LY/p5+fM0z78gf4E84FXLqyLasseyh/zg85bPkx8ctHSTH3zV8lUxC99mMRvf VzH3D1rb+PfyToL1WN3S8d+ka/D3iEXqipcOvi3YwSSxKowvT3jp0+wQH69uX2QvpjUI7aO1FLTG 33xmhncLeLce3m2Ed5vg3VHwbgu8Oxre/QwkcR8E+mBAHxZBnw5V7yNoW6FthdYSnegnaH2q3uF8 p6G1hP/OZdofY++9sPf0/TVChoAMCTJkyNBBhplqdwr+pj7D1NYhPzp6L8mPfaIVZNEqdsEOygjg u9vEZtUKG0I0WdSr4xfO51WtUK7S3s34PG3En6R3hzgVpvdi0E6Lg2Fep9B86viF03ap46fR/vjR eyf2/2PGdzorSOKM6Mfez/GgSF5AQP1MzhX2eEdyxsyE5Oz4cgJrfDnyouS8Z85Q2UFlek6lZkpF yYVUKqLUnJyNlMefkkuSS0Dl5OAUJvGlMHl4wpJYDoEiJ4OkNDM3WitXWyZJ3BfLXgvZynLYcpj6 /IblDXxjyTvcg2jUz03ERfFuIWIuc3/jPTPaCW7Ex8SviXcg93CacSOuLP6lGfcIe2fcmHFj5l1w eWYcZS5OGme859nEGUcZlP5OlqhxxZWxLNQLyXk2RWmJ0v14I6VmxjOOUpv8rR2y5QuWA++2hzOP E5wS9pknYu/NPD0zJvbejLKZ52Lv0adzscMzL8y8gPKlmf2EL8xMJ7jC1BmrYwdnrI29wWlGWeyw yjuopJknOE1IjNsde49AlQdZLCkkhyTcw7MbM6/MkKlGPdHWMp45iB52WY7+AXsGz9S3qd5xdQZm Ek0n5UmFgv8ift8kaqaUS3yS2DGJmiKliy763DyJOltKEnSyETWTqBYpDuu0bRJVSEZBEYawhlFl cV+UhK0MmWF9e/oMj5e75a8Qx1flI7SmvSG/QRH0cfk41TwpnyTbnJXPChPZ5rvCLF8kC0XJ/y5f pgjuivxD8Yz8I/lHYoY8KA+KOPmafE3MlG/KN0nmz+Wf02pTH11Pq83HKAafQzH4x8k3OIZ/DfhV 4C9MKb8WVt4TVu4MK+9Vy9R3ySOtoRgvW+17FmgVkptoiZNoZdJqoukn0YqklfTp3iRavrScPl2f RMuW8rCjhtPSJSt21HBassSnlEOTaDy6Eq3d4bQYKR77VThNL1noU2M4TTyS5LDdQqGNiYdhu4VC GxGjYbuFQhsSw2E+kQU/5/EXWLslrN0y1m4drd2HaN/rphXcFDkSloNTRmJPGP1zKHeFlfeEjdZr YeVXp5T3hvHsDau7N0zm3rC2lPKXJ3mAUub+LsB/diTgG4i5x9YJbuqdcnZlzPuvRRjEPP5GLZU6 ae2KaaWz3SNhj6mPGonpjd0WUxI9HFMTU8J51AjR6mOc9Gw0+h6V6pli6SRqXkxv1O0YfrsMpRBn fdRtJXE5UuIEF8vi8oQc5Rkoay0Jc25bdsc454wQLrEsD4s+3ukZKFZyoIcbqd8i+gBBN8FRFU4Q kCdHnyO4oJbpeRSdZxIqCNwq1KnQQNColul59KUJ4M+JB4XdMmY+YXkY5YwW0cboGMLxljrz6aia 6MRoYRkzDBM1JTrefDo6PcoXnW6+YH5En1PMJzhFG82n6UkipRQlWcY4TZIYkmcZY1ksaUIOSTgR VcM1iCPefM58NFpQ2RltNQ/9CeKmd7on3pISYHX+TyJhyaPToY9gPcEmpWyhdWvWFjXfThbfSDmd PGfRejFrD33uEPaoq6ZGy/Lo+1FnotZGDRCm3NRoaoy6GtVHz/xRPipdZYo5hqjHLMtNDUS5hqRx XjU1KInLUySGuFgWl8PkrFU+E+WaafesBrMxqm9WI+Ez+A+wd3OyeVc+a3xJCPNlxTrxa9TPFxWI alaAn5tbCLYS0M5r3kmwm6BTLe8nOKQ8N3pJ1hklB/8qYTfbDA/Nq4wHzBVmt7mOcIPpsFEYu82N VLbplhLVb24wCvMG42mCGGM5ffYbHnIyu4389XaNlPxqsnGaJHFCno1lsaQJOWY38W7gGsTRYDQa xswVVD5gbjEu+TP6LH9v28OwCILvAM3BDY8fhFJPsOQP2E34pCVhHHkd7hsv1NZlKdnQQjjPSGc2 qdjwAq/a/J2d4jbzSB1GirPlMkMjlc+CotDHQOk1jjHl8TXmBD3P1Mxlfioecl1JoK1R8KSAp9dA 2sgZigTDZuDrjPUnOYYATyKeimAMl/UHCHtQ7gW9wWjjMjgb0Eq2wolyCtoaA0825HcEr0Ifpozp OCoZYwrV6kYrfFbtU3RjHjkDchpMl5kCnE3WZp3pPCi3Q88UpkgdSlt62ITLch1jXSr0jDNz5DAK yQYuEyWVJUNOhuEea8WYKPegSQl6WgJNDgNznPnQ1M7josrBidm0BH1vQ91G7LWC2w3uJsk+tD7f 8AnCK4wdhNONvAbeM/JO/JaR65qN9YRfMHBbLxhdhGeN/5blGP5CSONX9XxX/X4ui8fGjeBfAt/4 W3r6M9CjuUz8z7N9MO4pwTTgKoz1OdYEOs8aZ/tHs3zpDaaQhblft9XR9GC8stHfbLYw0+W7qoew lRL0h9HWfNYNGg7rOVqINs2l8m/1X2AKtBIGD1O4R7RF4b7I8G/oC58P7NyX8WEjn4AF+pUy/gPC C9mqpPkGjEI3yt0Yiw0os7ckqt7bxzpjNHuBG0zL4SeMv4lR60Ddn44rvfgI5hH7VRk8sAP97YXF dkDm+9HKTzDuacBngQW86zZ8rw52q1NsAvpNbkU2A2eo8w7zyFRH+IuKZ8KvxjCDOmDhMWg4ZhwG ZRhabcSIxKIcixHhp4shM1uZX+hdNvxZiL+GN/4M1vsS5GxErV746mXgZmgOS47vgQ/8gMeFb/rI nt9kCewnIvrxN8hvcZqTe/Dbpg7G+ovw5wsoxzE2IFI34oyhuwr6IMp3UE4CHgGuAP0Ryrmoq8yO 3WjlMspepRbJoFqM5bvgPA3KOQWDxw+tlHZbIaEOZZw1DTgr0IpA2FSGp+2wgCBdJHk7/6exXGd8 S0iPf2eg80Yw2WDC00fwTBP32vwsY3AeZayLUTDL0aWifAFPO1G+g3KLIZP5gQ8qmFuhucPlZsa6 fMbSTVC+C4oVdV8A5VnE6DivyB8F/k6QZoFcNH6AR4Sx3DPOlukEbmeKPp2xeqrrAj4GfB5YOWHh vK2e8nCuk2JRvg38EBTlRI0TntQA7AG+CXwCT/Og1X+AYsat4reAH6uYz9i/5LK0C5RRxvIQai3B GMWg7mFgn7JConwW5XJwbsc44owmvQ0cAJ6ltsv4JeB84NXALzCmecsS8Ns58m32hD2Q/CboncDw Cv02tKKcaIsU38PeNCZC9wVkWdJfvwm1HoB+H9JOgTIMjJOVzgFpOAvrP2IIUN3fGOgMZygy7OLW dTeIvlOfTvi+wQL8Gih0CtbfAk8r8LeZU3eVYwB9D8vRzzHUsQ78VF8B/Ijphkzwl4NykrH0C8ZG D2NDI57+o+Fv6GkUeGZAZhnwAHhmMzZdQlmA51Xg90BbCfhFXsF034NW+YYfM0WfRXgWU6Tv6xeS BVbQnJb0CXrexd7gtd24V8ffLF7LFN0HmF93UK+np/28WuqLudfGvZBTDLySKbo7XCYPH4Anz2Df GP8Nt8tYfsB0+ajiRUpZpROWHnFUJbdj3Q6Cshij0wKMmyU5A37SDwlu3IuvY0weuI5wevBX9HRB 8Bek21LwrOY3MOj2YT1/VVTx2g76TGArJKwRf0flBJYg3w32U7mby1LBeDLJWQDObuB8tLIb0pr5 ll0Kgo5vkpZXybyPn+SbAOmK9D/ZSyVameVUiW+8H8gUOYgb0mfp6e/4qRjjb0KWTkv8u95MmVv/ R8Exw3ekX7PvybySzwIWMtlEZMulxOOSLhL+iUzRi5wu/Qt7O80qSZ4jfZ/wcvm9RNFJNOLyQukO UyTSVvxC4t22Sqrh1UP3OdL5RelFeloqfQxyuK4dmiyUfsIzXeIoNEirsqSjZZbKD1ln6ddSL8vn 33fLn5Vpt5J/xLcm8o+h/4vyvxP+pMx9r+X3pco/k79L/C3y96j8Mfk7vObriEcXy7cT8n+Xyf7y dflThNfoPosy7XFyg+6LPNPlr3B/ZdJZPkyxvST/vW4Z1d0mU1/kj8MCH5Yq2Hvlz/CqJfFcM+g+ D4uRNP0y3cu8/uj+L5X/lr+PWp/OZeNN2nPIt3VU1/RBLksD4EnTUY/0n0DZq9tJbX2ENdE91m0h /G+6/yC8Vfc2KDwHX9ax/b/H/HIQtTJ1tCYY56O8mbFBx1iXBMr/1n0fGvKMjtPtQplxGetJ2vI+ /h3mlE7rfgvJhPWVeNqgo0hM/98gJw8y9xlo7PQf1X2Z5x3t6rzCfJ3KxYbDXAbnR3Tsq3W6X6Hv 5A/SW4ZjpGEQFqhArY9zH/V/yTy6AFaJrzFdum5YyWsFLPZlSMsFzwWUmwxRWH/o3GGYof8iWv8Y VhvChlX633F0wWXdBtCDBh9pouOycSt4ntVTNKXfwbu2oUi/j8r/xGX9Ho5I9b9U5ADPZkyrHMsZ AcWA8knGUr5hO+Jt8mopy8h3kqNGGjtxCRHpqLEJPLxrFxszCOcZspiCaFZwrD7+M0TdKznKlWYh 7pplXEGUNNDT1Mico/dsjpApNn6E2NgDym1Exf+H6eBcyS2K9zMmSi9aGURsrETInyabtPFJQbxl imG/NR1FGZijWV2bqRPYDMwRy2uMjY+MdGbV/y8TeZHUra8VkvkrxtNE/5GRZpb+som8VBrSr6VT aKyOIgpzDWtruMtPKWI8zzG/oHHX9Y3/M9tqfCvv8sFk4MVEv8HRo24smEcy68dpfdCnIs4M8Bte zPuY39g07iX60vG/QoRAJ6AoI9c1zQ3SfNT/JvhjSP47btHA/vySciJA3x9z32lcVoCinJUyMSLV PDqGFL7B5BGhWG43RnMJzils+WjmpBHhtzAnKCMCzgT2AeLh+DDbxLfUCbBtAo8vjVEvzlaDoGxk Hpxf0lStRhmbnYxNcUQ/ZxpB+Qhjip35VKhQRjB2F0BJR7keZfY0AQkt3DspAD8MoFxtClI8Y6So indijrTbsFMsRxwSjQjnB8CIQ9R7eOX2XLl/P4SniJTEJeD9wG8BI0KW34fyY+BR4F+quxXjLYip FHwBGHE+xUWMIYHszliJoGrUMo0djR9hI6IpE/ZNPWInE/ZiI/Y+/U7gEebU31IpXLePdwqKuzha gP7yZd5T5EuMdVbGQbfa1g60tQNydkDCDki4CQkkbTxdic0ohqWzGDQvhMx2NRIQuP8W2McZnwEP ziwkGfpzXKG/D+wHHmQsX1IjAebfqVg7SCMbvMNx43gccCEiyXQuUx2OjbcqESbfkIg+FfN5XNBJ SxrfpjyVcL6WcI5jurAAC9wcCcjJpnicn/Iq0Qf+VcwvzqucTngCn08TmWccozN+n2JqafwWagng zeDJRjmPnxLuhTTGjUqMDZldaOUh8CFQ+rjFcZzpxs8xffwiejEA+qCilXp2SMFJJAWUTETdq3BC WcW1wLMKEs5B2wGldVBuKdbQ/yufUHBbko/Z/Rjz6DrPSjplmzmeYUyc57CqM88vsaK+hZk7qsw7 A592r5u+wXJ4PRSj5mZQeOYm4oSeotxfmQ4C89k50ciWEbwSSg2gdyDa/Cbuo36K8k9xxt+AO4Sr wGdBP8t0GnEjl5U7FqzPu7COdaDFm6DfhF/B3+i0vgH3ANRuUIlaPwRf/TnwZ0DBeUfKwU1XHMq/ VvwHZ8Z6+LD2GzD+nc4HUK4FrsKo4czOf3NAeC5wGuT8DZ4OKJEzzU4pmMr48TXgTqMyIrdgT/gk Rc1MGQCuYE9WntK8p3FXOS3AmeC34Sl2Nz3Hgc8xj/wcbiOf4zs9op/kmQUJs/UUUYyPMKazM3m+ /Dr/ha38OpelKn0cbksoAn88xDi4BeWD5la01Q/sw6rbifIYysnAzViHY1A+yq0bTwBjjvBNCz1N QNmBMm5dTEOsmyoZ1uC7GurdQ9aQx1d+3ejGHQLj/4R/VvEuICeP42+NxrEXjNcAo7/j2BHGYROa E+SfdC7nEzHfTyY/HmI6YymfsbwdlKJx/kbUA+oKxtY7zucjOj0N8FkbZ6hWUPKBy3FuGlKe8nyk MxfzdDPWx4GnFTxLFE7mkVYoa2awFScvruvB3eYlnMXaVZkYBeA6yLwK/BnwNKPWGCS8rOwyXDba UPdocB/ukTgmRC35IM5xW4HdwU9x7Kes5HjaTvsSaQ4d6hjrX6FdkW+EyMd0JVymM3s06wn+Ouan 1ndzxAtKJ+oOqdJ2Q58N6Avr6YMEByQkAt9EX1JxgitjrJO5FtlhC+rCGpDjhW6dwTdZfvA4eI7j bmEG+sjSfOwD8mW0/jJ0WwEJl7lsKFV0Zk3Is7t4xcC4JIC+VjkXqz3axxj0y2h9nypzN+7rUrAO pGBVYX4ftC0HtkLPUyh3822wLiF4C5RfQfIm7JLRKJ8BprOS/E/g+RnwZabTKPT/P/a+O6yqa2l/ nb32nHM4GxARFRUVayyoB2LFEluMGkGDjRg12FAMliAxxlgQO7bErjGIxCiWGDvGEkusBGsMGgsa Y9cYo1iwfmvevXOu92v3d//4fff5nufLfe6758yaPWvWrJlZuyy2/LxC8N/oXWNUkWNqO8U0Syo6 G7TJ2Q1OCuYlDTFWBM9/DNBl8MyQZ/Me70hUyDpXw5L6kEnhs9Rc/I7IWcXXSOixLaLUCfv7vZSQ uQSZbODvmLVV8MMl0KeAkMf9u8ZWySwrloCQyUJrTfRSE9r2YxQ1Yf9+2NOSW1X8PMC8jwby04AO 5rj4LBUJ2aBXgV4Fejdy8CZm/AH8uRmeWQV6Feb3ATi7ge0xF93Rewp6Z5vT0ZoBq9K5X0V3Rw4+ wEztht/YV1g7dD94YDSsynvxGDGzCmjOdRqs4nNLAEfjfcEBrlpKTwqQx9gdiPqjfQrJqcyx3cU6 cgdnZcOeUxxRyrd8jReAMeZDfha82pz5shtrtk3Dc+nGLG+7wpbY3oYPq0LebdJsv+0AYmAXx49t Gverahf3OA84GZLR0GM+C5oN/hVzRC/moC4xvRxYEpI1EWkjMPvXGfU68OpNcHwhGY6+goW6v9Yi wFkJ/NWaqZaoElxP8AzWFvhigLoPwnN1pw+uKkviSjjHrGksKYdyzjrw3NLhwzRdgQZc1dNL1MyW qD8pwDtojWa04+m6LQRXDkv5elKfxNVVXYcJXLXyk/+djPoiRjueAMsc9Fvz5TVUdcZv+FyVBfzM B89LZTXNizOLJR3V0MtP4PcAjgVOxlXxl7CnPDADlqzFWbXQugGc7ehxvekZ2INWLR787sBx3Lvy Hlty48U+fpbCqOHaxvYCdAPUvU0v3sW5LIOn1nqiuTbx1a/KX1Vv7dmsk1aiF3/UxpGQfBuWm09x U6gOI94RTOa7cm0yqYpNwx3+CkcCOzPaCzDqt4HLwH8IfklGmQu+DfyZoGczOipApgqwMlqbAo8C C0LyKugbwFhGZz3Q3dD6FJgFji/ouqC9QO9C77CNSjNq/YHX0HoCNiwBfReSw0CXAt0eNFod4Og5 wC+AtaBzuLMm2w+szEg3GB03TG8wLXPRGmraDBmM1zEaMg/Ab4FxvQ3+JfA3w841ph/4LP0pzn3I qK6y4HlwhOl/9JJi+hb93sIoTO8dhYarwDz0Mh78GsC75kxBW2noaQJ+YdiAmaJAyGwDrYNuBBr+ tB8DXQSazwLhW8LsO+dAZh1QAiPQugnWXganEhCxROfAHwLOYtBuYBhaTY/5gTMWY0wFzgNGoRWS dsSnHbFqj0QrIkfHLFN3YDQwAHyzrw/BmQX6PM46APwTY+kHRHR57YXmFZA/jVGjF0c6+G3Ax7l6 K2Ay+HUg429GMmYkC7gLeBf+3waMwIyMBH8Z5hSzrPUHfyb4JxBvFcBpCk4p0LGQRCS4TgGRTc4r wH2wIROjuA/OcXAwXgdimALNc9G6HWNpjFHA24S8o14Y0Qbw4UM75l1HLju+Ab0F3suHngRwngCR j/puRtuMlwOw4hTmnOKrdxoJ7MxoL8Co3wYuA/8h+CUZZS74NvBngp7N6KgAmSrAymhtCjwKLAjJ q6BvAGMZnfVAd0PrU2AWOL6g64L2Ar0LvcM2Ko37jv7Aa2g9ARuWgL4LyWGgS4FuDxqtDnD0HOAX wFrgwyp7KPRjFI7RaH0ATgtY+zb4l8DfjN7XoBV3Q/YU9HULiJHqeZAfD5kaQNhmbwK6MDTAexQI /jbQOuhGoDFG+zHQRaDtLBDjJcyIcw5k1gElMAKtm2DDZXAqATG/dA78IeAsBu0GhqHVHK8fOGMx llTgPGAUWiFpR8zYET/2SLRiNnV4nroDo4EB4Jt9fQjOLNDncdYB4J8YSz8gZtxrLzSvgPxpjBq9 ONLBbwM+ztVbAZPBrwMZf0bXKSBiz3kFuA+tmdB/H5zj4MAS53bobAxtGDUhJqkXNG8AH2Oxw/86 4tzxDegtGEU+9CSA8wSIWNV3Y6778TNkLZr3iqi1LBfVJhcrSy7WlFysYrmoP7lYfXKxUuRiXcP7 UPBngp7NqGpRLtbEXKyJuahLuViDcrGW5WIlysVamYtKlYtKmIv1MRcrXS6qInN8QdcF7QV6F3qH bWq1ykU9ZLyG1hOwYQnou5AcBroU6Pag0eoAR88BfgGsBT6ssodCP0bhGI3WB+C0gLVvg38J/M3o fQ2jEJAB2lPQ4y0gxqvn4azxkKkBhIX2JqALQw98qGpvLlYBpnXQjUBjpPZjoItA21kgRk2YF+cc yKwDSmAEWjfBhsvgVAJilukc+EPAWQzaDQxDqzlqP3DGYiypwHnAKLRC0o7IsSOK7JFoxZzq8D91 B0YDA8A3+/oQnFmgz+OsA8A/MZZ+QMy7115oXgH50xg1enGkg98GfJyrtwImg18HMv6Mah1kRAQ6 rwD3oTUT+u+DcxwcWOLcDp2NoQ2jJkQm9YLmDeBjLHb4X0e0O74BvQWjyIeeBHCeABGx+m7Gl+9x 9r2MwS67TOyZKYJ9L6nA/Yy2m6CdaNXMHTWgp4OOBz5m1IuDTgGGUxPwpyhMAt0NdDzo5qBTQM9m 2lYbuIZRnjT5wPXAIPMsRltrnBvJtJwP/lCgPzATzwlTeaeQLIK3bEXAecyox8C2TOwjwvNhLR70 bG613WTadpNpWQT8x8Bw+xZgAjAbo94CTOB7YaaV/SYmYEQmboEn4QFwmoOzHXQGo74WfrPD8u2w oTbenXU39zih9yBztxJof9Ygq4BOwY7TJHA0cKJBe6PHreD0xLmXzTECh8KGoRhpbXgpGPxU8Pdb PW7BvDMnyTwXo05xZKI1gZ9jIAairF1bbVkD/BzPz3KVbbATnBTIe1u+ZZ/7g+4O22ZTO8zOMY4f 2DMf/a6HzEX0Mtjc08U7XtR4eXSXrT1gU9A7Ygn7BqOtGIbl/NRX1gQnC/LbEV1VTP2I7drgR0Lm Hug75ogwIxmQfAw8BpnVVivP0R7sDasI9Ac2tzhN8DahCaxSPYpbkM8GPxvW+gPvwJ4sSKYinhtZ e8+mINKA0BkEDR1A9zT1I1/2YBRrYNtk6IkE/yJwgukf+oGfKjBN5xj1RcyRJ8FpxzQFgF8c9szH WRUxUjfwDDSf4d714hwDSsaM5+OY8eOY/WPwJ+YUuB1zvR3y3oicM9DWF/r3g9McrY1Ax5s+YdoW Ys4v6NqQmY7YOMma5XRwTtoHILsz0eMAzOlx4ABE6QBYOABvcFA9EMnx0NkaZ0UiMudDcii0zec3 DsoqxnBIXgTmsQZnLGtwavzex54D3MJ22kfA/7mMDkSmA/XTvtTy4XFUiePoBbnMqO/FKFqaVsHO hcx3xpp6uEd7DiwPh4YXyIg8YAj0nDE5oJMgk4cIycTowjGu7YiW2pyhMgfza+rMtF9DplzDuYGw gemu9sn8rgoy47Aj9xnveNeGUThfL9kfKs5RplWlCuexAFcDi4O/BrGahwiJt5dVvVS0H4A2cyxl UcP5yeRIxHw0dVF0AaqvMIZ4R0EpftOkojEEFTKE13dgADiLgDPBSQbOZVTzyPRKRvsayBwBx8Xo bAR6KiSvQ38bHrXcDHoR9mAU5/dcchzovfy+TK0XgYilQFTIQOgMxLzwWaNM5LdgSn4v1wc+S61f ARipqee0ms1w7JJtwzGjH+H3VnSO3zpRC+bQRkbHdtjchlv1tWYro6KZs8hElpRZTKualgMZ1pYM DOAeaSoki6P6XWfUi3PlVL37wuZzyBFfxD/jerSuNVuBe01kvsPJPtHXYqRbIbmVW0nwnkxVSeYq 3xZhyx3RPEbl4RzUK5afib5SMC47zkrG29X5/P6OwmBnG4xxEUeLmmX22Ezma0n8Rk/l7x54HjOL Ua/GuHKBJ6HTBflo0Oesed/DPsdZAtiCVxk1xhz0sgcxsBKcPfBtELy0EhGVg7EzPRcWxvAucToB zTHodxd63A56PsY71KTxtCrIjEbIpMKTR7CfKgCjTnZU5GjkVmWhL+LNjHBf9rZlLfc+DHqyzCyg Fuwr+HwUInwpJIex/6kdZPaa2cE72PVJVr4onfabmJ3ZbIOyNhC+CsEKznzMjgMetidwDKu+uJeH jHbsgbf74tzN+IuDoeA3Nu3EWSOsvPOFhTzvRxDtaxnlZtCXTHsQS8XNHEF+XWJUa18A7+2E/YnQ cBoeawE6BlEUif2uUcgsZIpal0OwfgVw7AGdZi4DH3K/9gRoDuF+aSNbrlZYHguqgYw1e4clkyAT hnP90BqMfo8BzVjqgnPHQWdj0LvMnDVnHBEVA8u/R6Y8tORXMvKbd3tZ1KJYts3pDQs7wP/hsL+i mTV2HZGmczwzR9WuHMisxPobjhriRC7Aq8j9qagYAYjemagS4xDtc8GJsTAEVzK8cq3hs9Qq5otq iRWNbbavgf0rzUoFPavh+dUYy0nQJ9GjC5EfbqEv8sUJO3nstyEZbFqOa92tWG2vc0TJWGhORzxs hfdyWb9rI2v2us3anLuAsWZtYfRCzXcOh89HoRpcR5adMWOP59GxHmPJgw11kV9RLO9Kgwb8/YLz JDDWrN6cj6oCVERdrQh/VoSHmfPMtA0xHGN63qyosP8696IqHteQ08iF61gdrvOKoPqdp/i3MAtN qDU8pjjyV3spVDy+8vdjm8lLT+Y7NeKrgrsYxQKsTYhMVUu53wxIRiNW16JO1kIeZdNJRe+iCI46 O+/u+1LnfaGViFfYa/axfN+HynwGVm3jdVbvqHN1dWNHt+DdSgpLYW/DEext4LU7if+uTsvEG20N WITfQ0lvvKnZD04V5thuguPEW6qh4E/H3oDPwNkOjLf2hF9j74FeDwxHaxKwmyXJmML7tbTZ0FMb uAac9cDmVr/XIMMYCW3NuVUWYdRjLJvZh0nMsTW2di/wKE5afa3l60zIr4VtdmjuDskgSFZ5eZtH Ac0azoq2/MB0T2AmdgiEA1OB8cChZi/o/SYsD4JVUab3wK8Nvr/Zr9mLOXbgUGAK9OwH/RhnXeS3 vTIWerKAg4H3sFdkrdVLJ77ChHwecI+5GwH2r7Z2X5h81l/RnAVr7wT3FckobsH/2ZC/AwuzTB9i J0MjWL4F8uFWJJjzyzKTQfvDG/5sj6K5xwngJ0HzRebYfZmmcxbdiXPE3KnCHGrH2igAM1XcspY1 nDH7BWbCNm/Q3YBn0G9f0KlW63S8je2KeZ8O//MopluRw3SwOVMWTsfcTed+ITPf9CdGfZHRiVlw IkfsOcAtzLePgHwuo+Mycxywwb4Umt2It70YY0szlqB5oSXPngkxx2ju+cFYHgNTXtyDJ+8hO9jP OSaafng5AZE/Ah4egTifAPl0ziNoG8fvwW3PQA9jmm6gx6PgrIY9j/GuvBskO4CeDbo2o5oX8016 S8RJS8RqS/TSEjPSEpGfzjMFDAKnuKkBOZWK98gVYfM4K0dYciR8gizTCsCeGKZftuM9t6pSuUSq baWgHgk9eorgXp8kxIsO/fr0TBDd43skDhTxif16xIlJvNuoY1TzYFXXxMuXwqHO8xKGKCgKCR/+ pXi8I5G/S1xA+IsA4at+819icYvwUBr+1VelK6ptRDB/XVDxsCsPbbrw80jaBInCvXoNGCySgBOA U4GzganAjN7xcX3F+ti4gT3EFuD3cQPjEsVeYFbckEHx4hgwRwn2EOeAl+IH9YoX14F3BvTpHSfy gE8SVLNNAO3YJejwoKZG5KWO5h5C7d9RurLXPAN/NyO8X0GfV9B4Bf1eQdcr+xN9X8ECFhYR1UVt 0Ui0EJGik+guYsVAMVSMEhPEdDFXpIplYo3YLL4X+8URkSPsvOlVrIU3eZ8HjvY0zLfN2VjY+e9q nJ1gu82ZYFruHKXkbOq41Tx6+Sq+OrqOMQqbwTsfvdSxnXXsbR79VprHgLrqPHUsut88P/C2eSzW XNmg9BfroGKPj/1MO4olWO3jrHGr6318QVIoir+v1EZECOHc4NyAX/9j30in/mou/WxltZqyhR4t gkS4aCpaiyjRRfQU/UWCGC6SVUZ8JuaLNJGhvPw3v+eKy+K2yBPPbLrNW02p9Hro9chlw/GxS8Mx 3yVxfOLS1fGR10MX4fjIZcfxscuBY77LieMTl5fQVKtL/XqspA0cH7m8cXzs8sEx3+WL4xNXASX9 2OWnfuUr6YI4PnL54/jYVQjHfFcAjk9chZV0vquI+vVESRfF8ZErEMfHrmI45ruK4/jEVUJJP/l3 HuF/R2+YSPp/8kgQRv7QVdLyTCnLM6UtzwRbnimj+nnoKmv5p5zll/KWXypYfqloeeQ1yyOVLI9U tjxSxfJIVXgkxPJINcsj1S2P1LA84rY8EgqPhFkeed3ySE3LI7Usj9S2PFLnH3jkP+bm33ukruWR epZHwi2P1Lc80sDySEN4pJHlkTesiGlseaaJ5ZmmlmeaIWKaW/550/JPC8svb1l+aWl5pJXlkdaW R962PNLG8kgEPBJpeaSt5ZF2lkfesTwSZXmk/T/hkb0iW5wU5/C9onviiU2zuVwdLI90tDzSyfJI Z8sj0ZZH3oVHulgeec/ySFfLI90sj3S3PPI+PBJjeaSH5ZGeVsT0sjzT2/JMH0RMrOWfvpZ/+ln+ ibP8MohH6upv+eUDyy/xll8GWH4ZaPrln/bIbY9HBlse+dDySILlkSGWRxItj3wEjwy1PPKx5ZFh lkc+sTwy3PLIp/DICMsjIy2PjLI8MtrySJLlkTHwSLLlkbGWR8ZZHhlvRcwEyzMTETGTLM9MtjyT YnlmiukZ/tYz2401aqZaA7zFQH7lqqp/kKgo3MpfzdVqF+2t1iXHIsdKrY33aIuK8E4CtUrxxlhU hHeyolIhN9aiIrzHgWK58RYVga8PllfraV01H23UahqjqnqiWksneU/w9DTR09MkT0+TPT2leHqa 4ulpqqenaX/15D1XUWmORYo3z6IivOeDSlW8BRb131k03WPRDI9Fn3ks+txj0UyPRbM8Fs32WDTH Y9FCj0VfeCxa5LHoS49Faq2yVbdVV1NzkP8213bcdhyrsK/Q9ap6CP/rOfidz39XbyttC+YzPKt4 cazihfjqSG+sN3v1q95KA39nRtNH6H149ddj8V3OIPG3r00HQJ6/Iy7+iS+Nt1BXE74iUF1BhKhf unxLaNojUK08VGtQUvXvKwIgcQ+teWh5gK9W3tPuqW7zNN7f+gjSNtsiUew/zo1IF6tVzu4SZ8Rl vkyyBdhK2SrZwmwNbC1s7VREqx7VNZKGL5XpRh8PFfsXpR1W1HxQRzzUUQ91zEMdB2XZrZ3gX9pv /E1vbbfQvLdB5ieP9EkP9fPfnZeD8/YonKb9oHAOZE69IlNE2wut+5Qf5qvjaY+mXzzUGQ911kOd 81DnPVSuh7rgoS6Ccqj5ChTBKsf5mraBdkj19qXq7xB6/VI7gO+FZ6lfqep3Frip2kHFTdV+9ei6 BEoTDm269pmasTRtmZLM0FYLl7ZGWyMKaGu1dcJP26BtFP7aZm2riiuJiApQtYW/rcixVtj6pvkS 1bBKW6V0blTyUtvBXxPnCNdm48tL/M1qjnd1bSYId03qqkRbqC0UJbVF2iJRSunYKUrje0pv4HtK jfHdael44MjT+O5GSnQvXZL/csNbekOfkpA35HM5i3/pOXqOivRf+K9+hWbrIlbKOjJYFpFBspSs JENkdRkma8tkOU5OkJNkipwuP5Oz5Vy5UKbKdLlMrpSr5Rq5Vq6Xm+VW+b3cI/fLLHlEnpA58ozM lZfkVXlT3pZ35F15T77UD+vH9Z/0n/Vzeq4sr+frT/Xn+kuykSQiBxlUgApRUSpBpakcvUZVqQa9 TnWoHtWnhvQGNaFm9Ca9Ra3obYqgtvQOtafO9B69T72oL8XRAPqQPqJPaCSNpjE0jibTNPqc5tAC +pKW0Ne0gr6hdbSJvqMdtJN+oH10iH6kw3SUjtNP9DOdol/oLF2gX+k3ekIv7Jrd6bXB6GB0MqKN JcbXxgrjG2Odscn4zthh7Db2GQeMQ8aPxlHjJ+OUcda4YPxmXDNuGX8Y941HxlPjpXK5w9vLm//1 ggzplE41F6VlaTUX5WQ5ockKUl1HyqqyqrDLarKacMhQGSqcspasJbzkGDlGuORYOVYYcrwcL7zl RDlR+MjJcrLwldPkNFFAzpAzhJ+cpeayoJwj5wh/uUAuEIXkl/JLVW2WyCWisPxafi2KyBVyhSgq V8lVIlB+I78RxeS38ltRXK6T60QJuUluEkHyO/mdKCl3yB2ilNwtd4vScp/cJ4LlIXlIlJGH5WFR Vh6Xx0U5+bP8WZSXv8hfRAV5Xp4XFeWv8lfxmrwir4hKKrpuiMrylrwlqsjf5e+iqvxD/iFC5J/y T1FNRd5zUV3P1rNFDf2Yfky49RP6CRGqn9RPijD9rH5WvK6f18+Lmnqenidq6Y/1x6K2/kR/Iuro z/Rnoq7+Qn8h6hEnRThppIn6pJMuGpCd7KIhucglGpEv+Yo3yJ/8RWMqQkVEEypOxUVTKkWlRDMq S2VFc6pIFcWbVIWqiBZUnaqLtyiMwkRLqk21RSuqS3VFawqncPE2NaAGog01okYighpTYxFJTamp aEvNqbloRy2ohXiHWlJLEUWtqbVoT22ojehAkRQpOlI7aic6URRFic7UiTqJaOpCXcS71J26iy7U k3qK9yiWYkVX6kf9RDeKp3jRnQbTYPE+JVKiiKFhNEz0oBE0QvSkUTRK9KIkShK9VXyPE31oEk0S sTSVpoq+9Bl9JvrRbJot4mg+zRf9aREtEh9QGqWJeFpKS8UAyqAMMZBW02oxiNbSWjGYNtJG8SFt oS0igbbTdjGEvqfvRSLtoT3iI9pLe8VQOkgHxceURVliGGVTtviEjtARMZyO0THxKZ2gE2IEnaST YiTlUI4YRafptBhNZ+iMSKJcyhVj6CJdFMl0iS6JsZRP+WIcPafnYrzdZreJCXaH3SEmeq33Wi8m Ge2N9mKy0dHoKFKMd413xRQjzUgTU42lxlIxzcgwMsR0Y7WxWsww1hprxWfGRmOj+NzYYmwRM43t xnYxy9hl7BKzjb3GXjHH2G/sF3ONg8ZBMc/IMrLEfOOIcUQsME4YJ8RCI8fIEV8YZ4wzYpGRa+SK L41LxiWRalw1rorFxk3jpkgz7hh3xBLjnnFPpBsPjYfiK+OJ8UQsNV4YL8TX3pq3JpZ5273tYrm3 09spMrxd6kZ8Bb6TOkSWkUVlQWmXlWUN+bqeIafIz+U8+YVcLL+Sy+UGmSm3yZ0q2/bJH+VR+ZM8 Jc/KC/I3eY3zR515Xz8ir+mnlIYp5CRv8qMACqQgCqbyVIlCyE01qQNFU1eKod4qjvrTQEqgoTRc 6SpKyTSBUmg6zaS5tJBSKZ2W0UpaQ+tpM23Vj9AuWYb20znyVsen9NIuabrR2Ug3lhkrjTXGemOz sdX43thjZBvHjJPGaeOccdG4bFw3bht3jTzjsfHMW3jr3ryufIjKJlDZbKhsGmoaoabZUdMcqF1O VC0v1CsX6pWBeuWNeuWDeuWLulQAdckPdakg6pI/6lIh1KUA1KXCqEtFUJeKoi4Foi4VQ10qjrpU AnUpCHWpJOpSKVSk0qhIwahFZVB/ymI9LIfKUx5VpQKqSkVUlddQVSqhqlRGVamCqlIVVSUEVaUa qkp1VJUaqCpuVJVQVIAwVIDXUQFqogLUQgWojQpQBxWgLipAPVSAcFSA+qgADVABGqICNEIFeAMV oDEqQBNUgKaoAM1QAZqjAryJCtACFeAtVICWqACtUAFaowK8jQrQBhUgAhUgEhWgLSpAO1SAd5DL Ucji9sjiDsjijsjiTsjizsjfaOTsu8jZLsjZ95CzXZGz3ZCz3ZGz7yNnY5CzPZCzPZGhvZChvZGh fZChscjQvsjQfsjQOGRof2ToB8jQeGToAGToQGToIGToYGToh8jKBCsry8oA6ZDFZBXpljVlnpwq Z8r5cpFMk0tlhtwot8jtcpfcKw/KbHlMnpSn5Tl5UV6W19WVzG11Zp5+VF7XTysNU8iLfKggFaZi VJLKUAWqTNUolGpRR3qXulEP6qPm9gMaREPoY/pU6QqgsTSRptAMmkXz6AtaTF/RclpF39IGyqRt +lHaLcvSAZWVPiorn9nV7QjNMLoYXxnLjVXGt8YGI9PYZuw0fjAOG8eNn41fjPPGr8YV44bxu/Gn 8cDIN55727zJ2+f/svL/svJ/SVbabHZ1X1JK3en+dYebJU6KXHFd3BPP8HwmULWWF1XUfZS6f5Pq vlndkzxSOE7mK5wknyqc7rVF3dHkO64qfOq4rvC546bCl/+JhofQ8BgankDDM2j4DhquQcMNaLgF Der+z3GbJUD97qHueKg/PNRdD/Wnh7rnoe7/RXmneqjFoDSVkRfkRSHUGq3uC9U6/a3Q1Vq9QdjV ep0pnGqtJXxHvDWeXVUUNfF+y88YJHQ+U978i9JzcN8/WP26r+7ZzkPOV45W9xuqzTzKm7hH5DsJ gXsCmzrzAj8JwRMVJ+55lSfU/a1N2LQ0895R/Oxa51r7n7wtcSk/LdSnvPIExk+Q/jE/LdGH65++ 8oSF7SfVys9NauOuVc2+9iPufLM9Twku81fHQV3xUFf/orwyWfq/vZMW6MlmvvkRosQoPOfBfyWG upNLJNi9qkxoOeGRj82hpSWX6KVY72s2W6jh9rJTVV+pFSfh7mF3VbXbdFtyHc2mp7V3v+MOeYUT lF4qKUg0wP/aip5iiBgk4kUfkaj+34j/5y7zijI94Icu41fdeEdfHpo1vvqI3z+84nPmM2dacpG3 3Mm6vztZe5ImNZumFRC7xZQGDSYVPN7oYa/bFxq7fTyW2nRl0+DQqu7KdtlRNwqVbTZo8CcJcX37 JQZX6lU5OLRevTrBEXG9EgYNGRSbGNxsUMLg6qGl3EGmcOG/bxmU0CMxbtDA0DLu0twuCwX+rT1q 0KDE4CYfJfYblBCX+Im7VFGfenXcoaFudx23+q9LUZ8wd2jY66HWz3+BRcm2sq+6xUZCJtsKCMV3 ack2m1ih7dg9+Gr9e5ElKi2eN6y7+2b6imkV3n/8Yk6brzJffJke3GjEO+lfpM+ICfvgeNPen9xZ PfRQhzP3bi2aEDRj8bjYDfs+GN6zXE7JBrkFbDOvz927s1rswoX9Ki44Fh6y03tTdMXdLa65GtWd G7KiUr2M263GNv1tXIFtC+M79lidPGJJTLWP29xYsLF3/YXtgkKd5QMWr7j2edXAqw3n9wqIiaY+ i0vWiZr4aPkfs7X9JX7a2fHNDZOTdobf7jA7cs3z5cMHJEZ+G5g916tSGdH5s5i4Otve9nc06PTy vadLY13OZSfGdOr8x+b63YuM+Vg/8/D7NUlzXqw9PDpnefGErg2ytt91flXWvcE+/tCG4I8Ljb+g 8b/d8dWYDPeYr91j0pU3S9r0MQvdY+Yl+b13bPAfcQmp5d4ZFbA+YvrLH5ck/M/PX/I/iHHJczjn urFr2v15gbV+32Irf/rjgve7xoQtTjV+bESfT5pxKPxqmXt3O88K2ZT21sGefzw7lV2/fpcVtTvE vSg/4I1D2StzacT50GkNF/sN7r/thX/bwLhdz441+61gl+C2N3t++u3KYger1qlQ7fs+S/xTKhTo 9dWjDkH5ZQ7lFL4ftXpgszDH8+Sij6/0jfd55+GOP6MO7Li21/0sONRrUsk5lYtH/FxS+/rPpIty 43t5684f7HynT6sDUR02b5SV/F9+lnPXOWPUlnn7VtUJuTz8csbHvw1NE8f6v7H7RO2Ui038M2r1 L9H/bK1fTwbplzPe1A92eb3uwIggn56ZrvSpP/3c4Y0Wh4M6Lht81j984qyPFi8/kaaqQow7WbYx q4Kr+qqC59q97Prlj7v+qikl/1XFQOV93TD1n6oAYaoYhIapn7X+KgafoIIqJfZCWsf2oYXcBfmH s5Crc48h/eIG9k1U3fi5fZnpKOSI6tN7wKCBvf8yzPVfGVbOXcY0rPir7b37BLeP6ztQaQ1u16zJ P6wKmZ+MzOm24c16GTVXh57Jr1Cr1ce7npZOPfDmh38cb3H95NQfPmgT1TNvgfZDxOlW8TXKN+qz 80i5TKNl5uiPzr+5Y+UM33b7KlS9l3bNp1zp403KP+m54GixN7+e1br0gsMbapT9oXW1EYN+KVyq /tR6fvXO76icF1u/mi3s5YvXWi7bFG+buOjp1vW9Rifnd00bM2789LX3tsz+6mjdZe3GF31tYuR5 90PRMG9/fsMx30/4Pb7e8uo1H26s/q1rZM/Ph8Uumj/EZ8K39/beD/6urf+0Xj+G/BL2ZrE721rP rd+ufeCR2Hc+WfnNxIOdGi1ObjdpIK2rtfvT8juiYhsuiMyuOur1gePesh9PPdZ6gjZwgli6a+KF 9lZVeOIe88hdiItCBd3b7bI71YJG5JDyf0epKMA2FrLZXurklurgLskMX72IHpBd8shQMfi9b/88 szdy4TvNq3/VvNddt8HNBXRdpdGEV1IHNebTVWtGta5478j2yMT06NcSq3y0YcLzVW1mDxMRN7Ju BZ6L2+ebPuK+1mx/1sTsx+2z9yze0WnQ3V7NVzQXd+YeXPhz0BZjcTGf2afOlPqm8sg/fl82ZPWM 3HrTG87vv73ugBOTvi33/MKNnDivzyftePGr2Fbz/qMR+X7+1elW5bmzmn5Q6cPMujMuOnwOdet3 eEdSkw9iM7ZlbpteM+ue9Bsx/MGJi00vfPri119Xv3h44WefDYNzZv7WdnPd9BHVTjY8W9PoWUdb PKZ/uckPu/aasbbLtnqnYqZ2HFf89Qf156cle6e/P2VDSOaSr39cdSZ48053sfHBAT5VtkflNbnY 3f3bzEpxE3cPvnR/+aojSU0ThvqqGjNc1ZieVo3pYX9tDK6QnK/mEak68y/Mai44dVWlCQsLDatZ qxYXHLe6/FA/X+ef7jFj/7/Y5oPAUaGrR7RtF/WXuPwvxP9h7dmRsHHytaDF4w8kbonpKms3XPR8 wfCFlVuUXbt8Yvvf77QIP/AeGZ0zMrMo+6c2H781ePyGKz9e6Hvtq+eJr83qu/hUimzu3v/o0NZD 4SWdnZq3Ler0yd9YrN/K8kFPqfP4G/siHWXqLL91JKTG5qaHy9DynKs/Vep8oMTwI5VrOw6ndsze 9mfZWxnllvpU3vP02A9d/q1aM4+H6t3j+MzYI/tW9i1jyxlijAmNQZQ1a0U/Gso2GQyD7Pu+ZCuN tZ+yJWXnR66yFNGQoowsPz9LQqhI5Q5tKvd17+t17+vX6/5xXuf1fc55nvM85/l+39/P85yjjlHr kNVjPO8bsRi94N6EPjFxpXL3svm6xOi4cP9U1qm0QkU5aJAln7kzk4LWwhlXt0UV4gLkelY++SId K/NBXqdxX0MdztH6+IdeWGIZiCin+dqk7sSKj3bYzH5/mUabB3vsoNfT0LvanDU3qhXKf5cSHeGe 7v/MnlUg5PXO7PkWxWIkT2n9pvVJkXfugpe4SDxrd6/Gbk2fAMtm1FMCmS54ixsCYtS8AHfwzmGv tXmDELUagAQQefA8pUhFRzwepyovj/Fw3Y/9Mof7MW5YeZyL02apPM7Dzd4Lg/eUR5tSHG8/pQjQ /dJDii45CKgCKl9sABIp+7lBAoGwU4MOHttawv8QUFv0QUv1YppcJzyxdy49wTJFI9t1Pf0kemTH 4eezD+Q2ifU0Px+09mVz4TARBmPqPd7ST7QHmEhzQx+Rpi5L9/Lu7uNwT5Gas2hae9y2W/6GgxzW QFvKwiPcSKPPWQB1utjXOnGxgxDbBYHuz+4gykzWSzOQ5zLHJ/0STrFGm+aTbY0IF91ti04iUvpL 2YVoZu5oF/e3mtTfqBt+TxsOWsFfebbRLZAnRkP3p6RSa2bynpJQW8np9XAZQRJ1V2Jv6O4nRQbo Q159I2TCQqy1C0uUfVJVQ21D6VkzEe2SI45TZqfiOK3P+swlW1OxptBniwtnTj8HseGK12554GrL x1tzuSEU+mRT6BPxiT6szoyXjFpAEqVsz7SFrPzOFvzIoF+jdZQBBEwZgAEHDsA30YOgmL9A65g5 YR088XZY3H+qdYbh59ZvdGoeceft7NFVN215V8rZIKvQyG50rDPspbrikB7sArQmxX5UyDi8ofUo KYhmdcGrOa6jaKDcCXfGR/LMdE3tQkT9g/mSD+y/Mx4XlZLvPTRkQc3nXY21xx4xe0Z+NXI7N6wj +HmQPgSe9rolh95C0PHwg6EWb2v5gBoJ6iqLk878mI1g/4PzA9QSBggCns6m1XowEi7rdY95VhDB 4O/9Mdv1nN/onHpSZo4782/SRrynbRVy+sIMZUStHbXjRuTDWY1vrVXvTXCdl7jMsdrF+iSCeSXU 21O5Pd2voNuWdo6mIlKxdjXtZDgq3Coi7VyFkKxutxsRPeo8HbQv0eUTb0LBUMobEd+JOPT/H2qH lZbh834DF3hTwoC2gdJt2lAjs/5A6dHIpD+Is2VIFLr9IbDnawVOCDWT4C6QKcgLdBqEBqG+V0I/ yagdAJVmwAZr9TduZEvMt6MDM8fjtBMWPM2aNBho5DbqTEwj+F8iUmqvWDCOxNcg+UjrZdfu1d40 EeFzo3cKdKEqENV56VqF9Ret0+kPX05gaaaLVf7Hi8AZnI127oW+7h5yYsvYbekH/nP3yhUGouq7 MHeVSbwit71HkFmVfJ45ItGDVVXsZvErxFaHI1nQfUTbWBZkB4eDj25j7/UwVaOK01YjwMwMQmAi ZukpImSNQyTePhhDS52xlAVBy5/XiW7YgAw5rB0ZeUqFT62kOcfUnT0MtfPXfcVDZBNRgfBHldG2 ZSjUTR5qN1VrKo4ZmT4DT1gRzSB2VxDMTFQfe2jdEntDAVQJBVAXvsqjNLktecTw6+TRTyDYkkcA XEGJgiYF2BajFD+ZsE0TCKn8O+SRJCDxyRQ8h3bCOTp4CGuZagtrmxqqwlEqCnLKKiooOYQOQgEm AYh9GhP/92OSM90clLCpg4e3E8bh3+ItPWSXsCavid9Q+svLH4ajSOvMSRyzJXAou/dHA+NS70zp 1MOjxRZOkMm0QIOIZ0HuC16gZ41o13W3MvdFGZL/hZ40nuz8toa1t4FkuzE5QJC4T85b4y+djMTy wRj4YPfCcu/JO+8dR5fsky5P32Ffu9Ic/v5xXA+NWhPY21iSajW8ljsywbbZRkr2YG/hh4snlASM uFtUBgXtNNSUKy04uQjpSNZ3oIrUcRt4qWQjRlaXM8R8wnW2WCY9IZo58AqokCBOd1EaR1UnLZ6c NdJWIHr0tv5xWoKZB7pC3Z6cGk5vVfNxJkqPQbmyclWxOFC/wDdI4bgUc07169GDORpzOsjtcuob EKDp0bchyBdP0xoCdFjeda0EZm+QvlNKOxLjv1FKeE8cxu5/opS+tITfGdbf6T/alp1oBZovez/e F33mvtTEifoHoNBAHus28ePsjUVvXZ5EfUzoqvYW4hN983bsflU9CrwXfl0XnoF71614DRpfx1iD 54DWVnqNSTOMxxk9v6iRWXuAPWSWlSww3GDfa2iM1I/9sIcsUT6QETV79O7k4hqKxwb8wjI6wNtv 0u1jlHBZKjE+6/Zve/O4APHRgkC7FAEpqTt6yarosJj5kYEwspGsEnIKhQKXgJgYlx7r8fVoJpyv WJZLsJEaa04ISuHyrrJd55QscWPHaEKtVGORcYf+rG3rvmDJr2PhktR1wcCCBnR/FTikbfh8T3TT a9ZF8t7nUMEqkyXC6L6JRoYQ9mFB1YfasC05RX0JAgYDIVG/cMn23ULy2wZ4XkgnwPk1O0HBMDoq mq0/1DZz1ufJZKCCMW3fc6f05pvFCGMGtl/lorDka0VqGCUApmau+ccYH/N96TXJxGYl5hNQYHIY OLatChNMC9DM4w3mBpmB7ECOIDcQlnIWBmlubd3b5+8LFv+Xvor3xbmd9bDDOfoK/8Am6lAwiDGn 1lw1YSGpu6rh6fg1rzZisSjudN77UcuXRGr65jYTbpuswmQSdrAnMhEi22JtjU3+6+aL+lG9YoPc hkFx6RuydbeUBML1p5js130YkAEFzjfqCvXZuNFXi7DH1Fu8rv4ho8V5ZzmZaVLqDWGhFHlMlJWn trHnXtRNzZn5UwqRWpBUpIjVeaO2fKshZRnHGUt0C+xaThNzrL6WNdrDhNEKJe1W3yewPPyovXxF CTvczKeCG3jW3zkUxIEvwWiQGGfyanrulx3OZgan8Hbubu0tnKIqReSJY6FroDE/mYJUyIMpeXvd QbZQLh2w8EZRNUPBQ3MNkbRhNY3+OnH+Dfv8UIgQEArh+zYjtLBQCBOliP5vd8gfk+R3qZvus0Pm 2QC82/2O8dsHITDlmV+v0MBYKCl2M7kqUg4YTPnET273SEpzf8DBVi1UDiMiQdaPGZENV/+BUJsu YnWPmDOhnsFEozVAj0ifrO3JN99LnUobT15is10Ukuftyj26+iHN5kXhQPVfNE7XlZLFeqNxJqtQ 4rW5Rp7rEQqkW4Wl4uX0j3nnbNWYjEhGCzV2LVq1PD71hm9ky1x3DaGGhTkbnM1f7Xvnw7IoJBb/ ujRw1gOVpnVO/g1RcUYl/pBiwt3USUtULtAex1m00CbZkW4euzYwzhHBg3mlim24x7qEGtCw+OjP SFAz62UQDwe9tbE9HMROXc9fDjTwdy4fTYaVFatVa4iSb7AY3RQ6OTO/op7l9uo8MS9cP2ZyDYpQ OoOffvJ+RpGsd3LSihBz5KJ2hwGfsuWjLBWeq0tjINA/Ad83XyMNCmVuZHN0cmVhbQ0KZW5kb2Jq DQo2OTMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzM0Pj4NCnN0cmVhbQ0K eJx9kstqwzAQRff6Ci3TRfDbTsAYYrcBL/qgTj/AkcapoJaF7Cz895U0JmkaiMCGo7lzZySNV9XP tRQT9T70wBqYaCck1zAOZ82AHuEkJAlSygWbFnJ/1reKeCa5mccJ+lp2A8lz6n2a4Djpma52fDjC E/HeNQct5ImuvqrGcHNW6gd6kBP1SVFQDp0xem3VW9sD9VzauuYmLqZ5bXKuisOsgIaOA2yGDRxG 1TLQrTwByX2zCprvzSoISP4vvmQdO/bdaqeOjNr3Q9+pl/2L6mpaOplfoXqzqDG+uTPdo6wqLAUB 0oujMHYUB0gpUoS0Q8qQsFi8dRShS4wuUeYoif+2Hd61HWOxBA+ZYs0kwU0sloU3Z7m7oAS7yLaP L6jEEqUtGPpB9di0TFF2Y2pfyw7VZRTYWWszBW7y3PPbhxcSLsOpBmWz7PcL6hDQIw0KZW5kc3Ry ZWFtDQplbmRvYmoNCjY5NCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2Njkz Mi9MZW5ndGgxIDIxNTc1Mj4+DQpzdHJlYW0NCnic7J0JfFTV2f+fe+/seybLTDJJZiaTSchGQpA9 mMlKIChLIiSUShYQXJDUgFWrgq24xAWq1GqtQlXQipbJRG1Q34rWDVEWV7SWRUBFbaVabevCfX/n TBI28wds8s/Hl/O9Ob+zPfeeM3fOPLnPzJ2EJCJyQzS0pLxm/LhFm3VESv5IIs/yceUVlbPtc88k uclAJN89bvKkmkrjX+aTPPsBoj98Na7mrNIHq6f+k5TY+2B/0YSa2sr52efqsL8bR02dWFtT9dTK UVcTDcXxrDMm1eQXxtZeci2OheNRw+SyibX1r121h+TGragPn1Z+Rt2ZgXk/JwqtIIpZ0Ty/saX1 jlczSbqlBftc2HzxQt/Bgh0HSHpwJpH+nXNa5s7/85oUiaQVu4h0Q+Y2traQm4w43gYczzH3gkvP WVFzv4akCMa/9p15s+df8nfnlBuIpg4iKVQ1b07j7L+MOv+PRNKNbPx5aHB+Gjcc9WdRT583f+El /oh5HsZGKth8/pyLLlQ3qMtJrkW/9O8LFjQ3fvnc9kaSR8cRJf1hfuMlLbEfOnAypQ+xv+/Cxvlz qnKqnCRPe5LItLdlQetCNZ1mY36rWH/LRXNaRr3/opWkO7G/vYLYc6G1vPKKbkr5LHvRF4ZEdpqI 7tmT8gzLn2v/cvnXC7+90UEGG6pGbs9ArvcfrKDpDvp64Vc7HdTT04U5hrVYp9EMUqiAZGwOyqdp OGtBPq5EijJMWk5aMmh/ox2KAwSjubKKzpGdklaWdYpWo5UVzS7KVjfQJSV8BqD2jDIfhcjnS9Xe eLBSGqr3S0+ESFJVFXuv0E5kj5Q0ulFSMrOWu9ODtFcpp6X0HaCvFmlwT53oQtRrkP/yu+w1GAGp 6bv6jka5iWayXPsCObTTKA1pAsoBzR7K1rSSH+UqVsd4Qw/fT58C2xfUfawfdmncbhr2a6Ul2Pd0 1M3c7ibydB0/9jjzGK8h9WvklZh7OfKJGHMSymORrPIoKpJHqc0ox6A8VjeKYlC2IFVgv/+wfWBv VVJoNvrjUJeZLca1Ivcw2xM5H4KTB89VGUusjOfg6e97jP92HmyN/LfHEAgEAoFAIOgN6QH18YGe w4mi9fxw5ioQCAQDiUTq4wYkBwm/KRAIBAKBQCAQCAQCgUAgEAgEAoFAIOh/2H2wAz0HgUAgOIR1 ml6SpLnzeEWnI3L9OPp1jdTUHpuXqaLKFnI3jTt9DmruUKg+lDNqaohep1CXReHZxVXVe2fXjok0 jfu89uyzz85PG1rbOLP5hf6Z9KdO2n5Ew1dHW4zpn4EFP3yk45t8D1PBcYCXGegpCAQCgUDQK+K3 lKCvUEiRGFpFkWRc/7i1n5g30L8NKhnIoB4kI5mgJq5mMqvfkoUsUCtXG1mhdug35CA7NIarkxzQ WOjXFEcx0HhyQhMoDuqCfkVuiocmkguaxNVDbvU/lExJ0BSuqeSBeikZ6oP+m/yUAk0jLzRAPmg6 9F8UJD80g9KgmVwHUbr6JWVREJpNGdAcyoTm0iD1C8qjLOhgyobmcy2gHPWfNIRyoYWUBx3K9TTK Vz+nYVQAHc51BA2BjqRC9TMaRUOho2kYdAzXIhoOHQv9B51OI6DFNBIaotHQEugBKqUx0DIqgpbT WGgF9FOqpGLoOApBq7iOpxL17zSBSqHVVAadSOXQM6hC/RudSZXQSTQOOpnrFKpSP6GpNAFaw7WW qqFn0UT1Y5pGZ0Cnc62jSdB6mgydQVPUj+hHXGfSVOiPqQZ6NtWq+2kWnQVtoGnQRpoObYJ+SM1U B51NM6Bz6EfQc6Af0FyaCZ1HP4aey/U8mqW+T+dTA/QCaoTO53ohNan7aAE1Q1toNvQnNAd6EZ2j 7qVWmgtdyHURzYNeTOdCf0rnq3voEq6X0gXQy2g+9Gd0ofoeXc71CmqBXkk/gS6G7qYldBH0KmqF /pwWQn9Bi9RddDVdDF1KP4VeQ5dAr4XupOvoUuj19DNoG9cb6HJ1B91IV0BvoiuhN3NdRkvUv9Jy ugr6S/o59Baut9IvoCvoavVd+hUthd5G10B/Tddir9vpOvTewfU3dD30TroB+lu6ETZ3cb2bboKu pJuhq6B/od/Rcug99EvovXQL9D7oO7SaboWuoRXQ++k26APQt+n39Gvog3Q7dC3dgfaHuD5Md6Ll D/Rb6DquYboL2k53q9spQiuhHbQK+gj9Dvoo3aO+RY/RvdA/cu2k+6DraY36Jj3O9Qm6H/okPQD9 H/q9+gb9ietTtBa6gR6CPk0Pq6/TM1z/TH+APkth6HPQ1+h5aoe+QB3QF+kR6EauL9Gj6qu0iR6D vkx/hL5CndDNtF7dRlvocehWrtvoCeir9KS6lV6jP0Ff54pZQN+kDeoWeouehm7n+jb9GfoOPatu pr9wfZeeg/6VnofuoBfUV2gnvQjdRRuhu+kl6Hu0SX2Z9nDdSy9D99Fm6PtcP6At6ib6kLZC99M2 6EdcP6bX1JfoE3od+jd6A/p3rp/Sm9AD9Bb0H7Qd+hm9Df2c3lE30j/pL9AvuH5J70L/RTvUF+nf tBP6H65f0S7o17RbfYG+4fot7YEepL1Qlfapzwuffor79I+5T/+Y+/SPuE//iPv0j7hP/4j79P3c p+/nPn0/9+n7uU/fz336fu7T93Ofvp/79A+5T/+Q+/QPuU//kPv0D7hP/4D79A+4T/+A+/T3uU9/ n/v097lPf5/79Pe5T9/Hffo+7tP3cZ++j/v0vdyn7+U+fS/36Xu5T9/Dffoe7tP3cJ++h/v097hP f4/79Pe4T3+P+/Td3Kfv5j59N/fpu7lP38V9+i7u03dxn76L+/Sd3Kfv5D59J/fpO7lP38l9+g7u 03dwn75jAH367V0+/e3v5dO3c5++nfv07dynb+c+fTv36du5T9/Offpb3Ke/xX36W9ynv8V9+lvc p7/Jffqb3Ke/yX36m9ynv8F9+uvcp7/Offrr3Ke/zn36a9ynv8Z9+mvcp7/Gffqr3Ke/yn36q9yn v8p9+jbu07dxn76N+/RXuU/fxn36Nu7Tt3Gfvo379K3cp2/lPn0r9+lbuU/fwn36Fu7Tt3CfvoX7 9M3cp2/mPn0z9+mbuU/fzH36K9ynv8J9+ivcp7/Mffom7tM3cZ++ifv0Tdynb+I+fRP36Zu4T3+Z +/RN3Kdv4j59E/fpm7hPf4n79Je4T3+J+/SXuE/fyH36Ru7TN3KfvpH79BdPIZ+eI3y68OmnjE+/ 47/y6W/1k09fJ3z6/wefTvC4ZK0zJxhJUTRa/i6NRkOkaBReZp+Ad6Elg15v0Ov0BvSTyWBARWsw 4BeAoduCodHqFEWnGHU6nVajQU1/2DH6FJ2W/Y3Aw9AebaH0z8CCHz7yiZvq+28WpxySOWGgpyAQ CAQCQa+IK0dBH2Bxn0hcZTQYjHq90ciiGYvRqDcadAbj4XGVDtuhuEqv02g1Op1R208XpiKuEnxv TiKuMhzfRHCCyBb3QE9BIBAIBIJeEVeOgj7AmmRicVU0iOolrtKxz6gQVxkOi6tQIWvPhSciKcRS ej2Pq/RAw2r9F1fpRFwl+J6cxNIQcVXfIVuTBnoKAoFAIBD0iub4JgLB8bCnWhBOaaOBCcsUbXRl 6Q/FRHoym0xmo8FkZmZWs9loNhmMZrJF/1UuNwZaFlfpFTMvs7jKrO+vuEp/VCR1zP2GIq4S9MJJ LA1T/83ilEO2px7fSCAQCASCAULEVYI+wOE7Kq7S6KIry3DozXoWVyGYMpp5XGWzWIwWE2pkPxRX sa9csc+rNAbEVQaDoZ/jKp2IqwTfExFXDQiywzfQUxAIBAKBoFdEXCXoA2LSrIfiKnbvX3dcZTT2 2CCuMpsRSlkszMxusZgsiLIs5DgsrgI6hFNag9ZqMKKs1xr0ZkM/3Uh1/M+rjrkxUCCIchKO03x8 E8EJIsekDfQUBAKBQCDoFXHlKOgDYjPspNXqogEQi6u0uujKOiyuMpDVYrWazTYri18cVhtKZouV nGTttjAZTQad0ajRGDU2o8lk0hm0RqP1sGP0KUbDUX+q7Zj4rZ/+EKHgh89JxFWW/pvFKYccmzHQ UxAIBAKBoFdEXCXoA+KzHYfiKnbfnlYfXVnmQ2/Wm8hms9mtFrudhStOu91it5ktdoole5eFEXGV UY9wSmfSOUxmk0lv0JlNdlN/xVXGo+KqY8YRcZWgF04irrIe30Rwgijx2QM9BYFAIBAIekVcOQr6 AHdBLOl0hug3Sdh9ezpDdGVZDr1Zb6IYhyPGbo2JYeFXfEyMLcZhsTnIRTFdFmYLNoPZotNZdE4L MBj1FkuMpZ/e8LeYj/qE6phxxKtD0Asn8YaU/fgmghNEcRcM9BQEAoFAIOgV8T8rBX2AZ3g86fVd cRW7b09vjK4sm63HxkKxTmdsjD02lkUz7thYe6zT7oilRIrttrBhM1hser3VEGcDRpPBZom19tMb /ojXjvyE6pi4Srw6BL1wEiF3zPFNBCeI4hk+0FMQCAQCgaBXxP9WEfQBKaNdh+Iqk6mXuCouNjbe 6YiLY2ZJ8XGOuFiHM548FN9tgbjKarTaDAabIYHHVWaDzRZn66+4ynq8uEq8OgS9cBJxVezxTQQn iCZl9EBPQSAQCASCXhFXjoI+wBdKJIPBHA2A2HeqDKboynI4emxslBAf74pzulzsO1fJLpfTFe+M TaAUcnVbOLCZ7Haj0WF02R0Oh9lstNtd9n66kcpuO+pPtR0zTj99sUvww+ckPsqM679ZnHJofKGB noJAIBAIBL0irhwFfYC/NOm746qYQzdB2cmVkOCOc7rdLJpJcbud7gRnvIu85O624HGVw2E0xhgT HSyushhjHK7DYrM+xW4XcZXge3IScVX88U0EJ4jGXzrQUxAIBAKBoFfElaOgDwhOSCGj0RwNTNjf mTCaoysr9tBNUA5KTEz0uGKTPCya8Xs88Z7EOJeH0sjTbeHEZnHGGo1OYwr7MpbFZop1epz99AWV GMdRf6rtmHHEq0PQCyfxQb/7+CaCE0QbnDDQUxAIBAKBoFdMAz0Bwf8Fsmv9ZDbbooEJ+06V2Rb9 KCj+0Jv1Tkr1JKcmuVJT2HeugqmprlSPKymFMim1yyI2zhnvtMYnWMzxFn9CXHy83WGJj0uJ76cv qDhjyXZkw9EW4j8PCXrhJEJuz/FNBCeINrt2oKcgEAgEAkGviCtHQR8weGY6WSy2aGDCvg9lsUdX lsvVYxNHvlSvPznJ72cfa2X5/Ul+b1KKj3LI12UR74pLiLUnJFgsCZa0hARXgsNpdSX4XAn9M+n4 uKPu/Dvmhi3x6hD0wkm8IZXSf7M45dANnjnQUxAIBAKBoFfE/6wU9AGFszPJanVEv6HPvlNljYmu rMTEHpt4Cvj96V5Pejr7WCs3PT053Z/sTafBlN5lkeBOSEywJ7otlkRL0J2UmBgTi1q620X9QnwC OY5sONpCxFWCXjiJuMrXb5M49dAVzh7oKQgEAoFA0Cu245sIBMdj+AXZZLPFRD9YcjqxrpzRleU5 dBOUmzLS0zP9qZmZLK4qyMxMzUxP8WfSUMrstvBgcyZ57PYke5YHOOPtnqRMTz/dSOVyH3Xn3zHx m/iProJeMB/fpJu0/pvFKYd++AUDPQWBQCAQCHpFXDkK+oDRC/PIbo+JBibsb1XYY6MrK+XQTVCJ lJWRmR3wZmex70udlp3ty870BbJpBGV3WSSlYHMmJ9sdKfac5JSUlFiXIzk5Ozm5fybtSTrqT2Af E7+JV4egF07io8xg/83ilEM/euFAT0EgEAgEgl5xDPQEBP8XKLvmNIqJiYsGJgkJRDEJ0b9hkXbo zfoUys/LK8hKzy9g0UxRQUGwIC84qIBOp4Iui9S01LSUBH9abGya87Q0f1paQlJsmj/f7+ufSaek 0pHf3DrmizDiP7oKeuEkPujP6b9ZnHIYyq4Z6CkIBAKBQNAr4spR0AdU3zaaYmPd0T/sx75TFZsY XVkZGT02fhpWWDh8cPaw4ew7V2XDh+cML8zOG06VNLzbIgObO5gRHx+MH5UBElPiM4LDgunUL/j9 lHhkw9EW4j8PCXrBceKmBf01h1MQY/VtAz0FgUAgEAh6RVw5CvqAmjUlFB/vCfAKu28v3hNdWdnZ PTYZNGbkiKKhg4uK2H19E4qK8otGDD6tiCZRUZdFMBubJyvL5c5yFWdlZ2cn+1xZWaOzBvXPpNOD R935d0z81k9/MEPww+ck/qfasP6bxSmHqWbNQE9BIBAIBIJeEVeOgj5gZmcVuVyp0Q+nvF6sq5To yho8uMcmi0rHji0dObS0lN1vN7W0dGjp2KGjSmk6lXZbDMbmzRuc5MlLqhwMvOlJg/NKB+f1z6Sz ssh7ZMPRFkn9M7Dgh89JfNA/pv9mccphmdk50FMQCAQCgaBXxJWjoA+Y/eKZlJjoj36w5PcTJfqj t9gVFvbYDKaq0rKqsSOqqlg0U19VNbKqbOTYKppFVV0WuYXY/EMKk5MLk88sBP7M5MLCqqH5/TPp 3Nyj7vw7Jn7rpz+YIfjhcxIf9If6bRKnHtbZLw70FAQCgUAg6BVx5SjoG5SulEwSrz+DGkrSi6Qh du9OOvlQ0lAaZSHEGkbFNJ7OoulUT5fSKnpYGiKP0IV8ib5UVSX2P38GUS6dBqsSOoNbNR5hlayq 6p7v2Jqx3WfY/k141104inTcWWuQOugRehbGukM7SLJMJB9li05Fo+VFs4XI7ojeC+Zy91ikUXow I3NQVnZOLmoFQwqHnjZs+IiRNLrnVsfyispxVeMnVE8848xJk6dMrak9a9r0uvoZP+rz/3aqdOUd j9BjR3Q8e4zpG4eVfyDPVaj0rNpQ8elji8aMHjVyxPBhpw0tHFKQPzgvNyc7a1BmRjA9kOb3eVNT kj1JiW5XQlysM8Zht1ktZpPRoNdpNYosUW5FoLLBF85oCGsyAlVVeaweaERD42ENDWEfmiqPtAn7 GriZ70jLECzPOcoyFLUM9VhKDl8RFeXl+ioCvvAr5QFfpzRjSh3KN5UH6n3hv/HyGby8nJetKPv9 2MFX4Z5X7gtLDb6KcOXF89oqGspxuHazqSxQNseUl0vtJjOKZpTCrkBLu+Q6XeIF2VUxul0mgxWT CicFyivCiYFyNoOwEqxonB2ePKWuotzj99fn5YalsuZAU5gCpWF7DjehMj5MWFcW1vNhfOeyR0M3 +NpzN7Td2OmgpoYcy+zA7MaZdWGlsZ6NEZODccvDrsv2ug9VcXBnWd21h/d6lLYK97k+Vm1ru9YX XjWl7vBeP9P6ehwjLAcrG9oqMfCNOIXVNT6MJS+trwtLSzGgjz0O9piij25OoIK1NJznCxsDpYF5 bec14IlJagvT1Ev9kaSk0Hp1FyVV+Npq6wL+cLEnUN9YntweR21TL+1IxHo9sicvt90REz2t7TZ7 V8FiPbwwp6ePl7g5K1VP7TmvEptRYDyWQ9jX7MNM6gJ4TCOZzBlJbc0jYQbqJewVno3n49ywsayh zTEa7Q62f1gbdAR8bV8Qnv/A3z45sqWxq0UXdHxBrMhWSc9CQ393OZyTE87OZgtEX4ZnFHM8ndeH 5eVe3CmHAy0OHzKcPpqMc9tYPzofJ9/vZ0/vDZ0hakIlvGRKXbTuoyZPhEL5OfVhuYH1bOjuiT+L 9Szp7unZvSGAdfwIf6XHhw0ZPT92R0JsxbzRYSnh/9E9J9pfXROonjKjzlfR1tB1bqtrj6hF+0f2 9HWVpGgHTnhYE8SZGh/A0ps6o4414EcbrAxUnNtQhZca5hiOLatTPHJ9tCR7FH4orN+ZPUdmlToL O5YmqOPrf3an3oAFzFskX2XY0VAV1XqT33+CO3WqB9hePDu0W9djCo/OObI+5oj6EdOztCmYsCZD rq6d0dZmOqKvEs6qra0y4Ktsa2hr7FSXNAV8jkDbeqVOqWtrqWjofvo71cdv8IQrb6zHg5gnjcbS lqm0PSBdN6U9JF1XM6NuvQPO/7rauogsyWUNpfXt6eirW++Df+atMmtljaziYxWqlvCqiMgGbu9Z HyJawns1vIHXmzsl4m2G7jaJmjvlaJuju01GmybaFuJtDOYpymrrDl8D/IVVz94xXU+1yicdSra3 uCRe2UsNyn5aqeyjnUgacqDFgVIxUgvKKpJW3aDs7qioKAx1Is8ZzPPIoKzC9awjkpRc+D/Kbvkh yiQvGnZGEjy8Z0ektLSrMHxktNCRnVe4s8Sk7KBPkWRlh7ITvzP5Xh2DBhceKLGiQVKuJLskkZdW KX+lMJJMIeWdjvSMwpVPKS+j/yVlI83mu22MWGMKccAXlD+Sk7zKY8qjXT2PdthiCqmkVbkJp20D dCvSLqQDSBpaoNxPi5GWIa1D0pAd6kXKR5rEWpS1ylrMczX2t0PzkRYgLUPS4BQ+iPbzmSoPKOfh CsGr3KisoHjkNyi38vw+5EnI70F7KvLfoc7ylV31O5Gz/t90td+BegLy27vyX6Pdg/w21Fn+q676 xcoivt/CrnyV0hpJ9TpKUtHvQypAUlBagdIKnLoV7CIIKim/UC7gI7UjL0Q+P5rjdF0R8Qf4c3RF hyuxcBVO6RU49VfgzF2BM3cFadB1ebfN5VGbPOVy2FwOm8thcznOSoHSivFa2RUj1IHkQ1Jw3ltx 3ll7GLoBaStvvxq6HGkVqyk/xXnMwqyuV86LDPJikc3tGBUqLH5COQenOqSc05GYUrjsUM1oYgsR ua0rtzPbObx3TofRwlrndCSlRHNYnV9iU5rpZ0gyxUHTkU5DKkfSKM2R9Hzv48qZNN9AIZt3sbxY WaxZrNUUlEvOp5RCmmwgLEmnkkdFMMjyziqSRjQYW4xLjIrD6DMWGEPGyUbtAmWxskxRvEq+UqxM UmYp2k51Q0Q/eiiy0Djd6KHLzavMYfMG81azNqzboNuq26U7oNP6dAW6kG6yrkHXoluiW65bpTMu 1y3Xyw3mFvMSs+Iw+8wF5pB5slnr1UurSpYqTfwqvAnnuAmv0yacxSac/wPKLLT7lLORZuHZmIVT cTa7XoQSag6krSjvQq5FzQ47O+zsaLWj1Y5WgrKeyUgNSC1dvbqenu59mP0B1oOUiV4bWm04t7ug B1gJaQJqVtSsqFlhtVX+BjN0QH1Ik5EU3rYLiYUa3/T0FXT1NyDpeP8BbtPdF2L7yt+EGjM3ZEnh LGlVlrQ8SwoVFZcUhtIgTqdzVmBWcNagWas1CwILggsGLVitmRSYFJw0aNJqTXGgOFg8qHi1Jj+Q H8wflL9a4w14g95B3tWaZRPXTXxq4paJmlkTF0xcPFEZgaeuI5JTUMjztCDLH40kJhWOsJeMkdfh 4cyCrkTaiaSQF5qPVIy0AEkjr4N65YfR+jBaH6ZJSLOQtNjjYeZeoN6uPta+kvexEuuXj+hX8MAf ioweOqlkAlzuLKSVSAqO/RD6H+LW0dI63h6G7uLtk7rsV/F2L7R7HwUObgZ3czPw8psB5z+DZiG1 IGlpizIdvxymsyNDvUgtSOuQNMoMbNOV6fLD2B6SH1JyQ9Yh8V7+FxvJGWNwlDhkC9aAVXqA6+1c r+dazDU9ZJtg/XKC9U8TrNdMsGaiIA9C+GSVVnD1h8wl1kdKrJNKrFklVhzNRX6yyvFcdUylj7me yTU3FOe3/sdv/dxv/Yffepff+hO/dayf7ZeM165VjuNqZirdxnUC14yQ2Wt93mud7rWO8FpLrNLd EkanUq6pXD1Mpc8esZfbyfiE9BmV40hSpCjLi1/JPJPUSFEJsoORonHIvo0U3Y3sq0jRrd4npf9I /Fea9GUkfa+3JF76pzRew+qfd+X/kMbTWuQHkM9FvoaKpCDy+yJFVzH7e7H/b1C/h9IMzP53NJnv t1Iaz9vv6trvt5HcJox6ZyT3Uoz6G8rlo/46krsXrbdGcq9Hdksk9wJkyyJBNsHzIkXZ3pIYaS6l y8y2mYIym8nErhGrcOQLkI+L7lwRyWV7lbMBOqWySGAIskw2yyelAE3mw3kjAf4gUyjAD5FMAT5p DwV5bpPsfPJWSuO5IRK4CkfRPRLc6/1X0RPsgdMXkj1yt3fPk3h801B9TxofWevdtp6droh3S26n FHzMuznwhPe59E5pWsS7IbfTgI6ncjtl6VFvO05yGLay9Jh3Xe5c78MB3rs6gF481SuL8rx3BmZ4 7wiiHvFelfskmwbNxyOehu763NO9E4vWeiuDnRK6Q0UYLGTyjg5c5B2F5pGd0viOtd4h6Z1sKgU4 xtrHvNkYMSPAp3LWiMflYaSXFoVy9Qv1Tfpp+in6Mfqh+jy9T5+iT9bHGZwGh8FmsBhMBoNBZ9AY ZAMZ4jrVXaEcFv7H6Rws02mYanjZITOVo+8OyJJBxmsnHKtUy9U1pVLYWU3VtaXhETnVnXp1anhk TnXYMPlHde2SdHM9amH5OlxJ1tZhgbKmpR4Wf64nScpfepOH5Zcvvam+XqoOb2im6iZf+MsaPA4T rqO1gVI3JVxc7C52nh4zqrL8O6ShS3MO4c45HHdK+Lbqmrrwgyn14UJWUFPqq8PjWOS6Xv6JvKCi fL3cwrL6uvXSZfJPKqaydumy8voeM0qTW2BGRSxjZh2UxswoTergZhO5GZZpWkV5e1pa1OgZaTwz wvJ5hhvNjR4rHUPgWJNZBjM5ldL5sdLlVGaG9RA9mP3wg1lIsvOD2S3ED5bMjNqDQZjkBplJ+4gg DNqDI3j32kPdgWB0OvUU5OMEpXo+jiQdshkUtcEq6LKRDbDJ6UvmlJ6EsdTR+O7sZvb+QUOgYg5S Q/iGi+e5w0uafL722e92vbGQ0dDUPI/ljXPC7wbmlIdnB8p97Y3N39HdzLobA+Xt1FxRW9feHJpT HmkMNVYEGsvrO9YsLqs+Yqzre8YqW/wdB1vMDlbGxlpT/R3d1ax7DRurmo1VzcZaE1rDx6qeWipV T65rN1BpPQJQnnfIZhNeDw0ef31pgqPldP7iGON3X+l5XEP4tWVG8G4JlIatSKwrrySvhHXh1cm6 bOwdoq4u95Vj/J7HpQe6uhxojgmUUg65K84t7/lpbW1dyNKiRTnQhYvcvG0hXrT+mupwJYtni8JF FeFQQ3m9xJ6ORV2U1YUcTxVtKZIXFC0uWla0smhdkXbRono0O59K25Imz0pbkLY4bVnayrR1aTrW MbPusVDRyrRP05RFWE3SQlBRzsdchBw/rLpwUSuDMEArUnS4nEU5ZXUladSMq10JV+Z5FIsUQBqK VIOkpT9DX0Pag/Q5koZ+Ab0V6V6kDtai5Cl5Fe5zy9mI9TnM6biVwo6CYYUjO5E3nhPNa2ZE84oz o3lRSaEbeaR4qKnEjgtviR6HvoT0DtJHSF8haZVCpZAffFF01da3UmuOhOkTKguZtOYslHJQkNjp Xtiak0MssQWOZwCmOdKR656k1kWEU4EnBBmMeGsr220Ry7thHXDF2puRJpIXKZlHaKTuRtqL9OHB Ceo32vMpcPA8dZfCbul/uCux/4pyG62kdDogDaFnaAM8+Rpc6kymFTSOttA6stGl0iaczQCuMB6A v/DC71eSS9LSHfQ2zaSLaB/tQtRcTTskJ45TQS2IFkep+6HVdJ26HlYmKqM/0OPSBVIN5aNcJefi TARpmbqBXDRIfUXdjtpdtE9KV9upCqX3KQZX54vplwijz6OX1G/4u99NdL90ubQf11YNdIPmNE2b ej6NoUfpDakapTPoUu1246O4Ovgl3Su5pA3qTvUD+hN+l87BkX5O12HGEdogD1bKtKvIRxk0ls6k RvT+jN6WYqUhSkjNVEvVO9B6P30m58jPK3rMI4fG0yy6iX6Hs/Em7cWlgFkahiuctdi2SX/Xbsfc qmkRXUZLMPM12PchWi8NkYbILlwfyniEWXQW+pbRaozfQVulaqle2iA9razWFhwsVuPUePUDVaVs qsMMV9LTGOOfUgFsMIKSpizUpGoWagu/vQqPcDb9lrbSNsxjB877F/RvKRvbbvlKebE6XX1A3Ye5 GHDtMJKm0AxaQBfTT+kePKvP0LP0D+lr2QjLLZrntJdpD6i34NxmUCnmPgnWNTj2DXiWItSJ7U08 yhjJh0cxUjpTmirNlZZJt0md0tvS27JO9uNX5UdKWNmkvKsZrtWqo3GkBBbJY5VMp3l4Bq7E2b4F j/cBeo42SvFShpSHR/Qm9v9SHiOXY7tX3iLvUJYqyzTfaK85uOvgxwe/VttIj1U2DudhET2Is/Cp lIA5ZEnnSa3SHsx8ufyIYlMcSkAZppQotUq9cp2yQnlR2ay5SLNW8452vLZRu1bfePDCg9vUavVq fn2iw7wy+ecgI7B+zsFqOh/za8F2EV1OV1Eb3Yz1cgutwvVuJz1FG+kN+it9gmeAJD/mfC5Gn49V t1S6Gdsd0kPS09Jz0kZpt/Ql2+Q0bIPk4XKxXCZXynPlpdhWyFvlN+UPlWSlGfH3Emx3K48pb8NL azSqthBblfYG7f26TfpB+ip9k+Hlb/72bfa39d/uOEgHkw7+6OBtB58++IE6Tb0U8w9SHg3GTK/F LO/AGlyN7UGsxMfoeXqZ3uJz/UySJS1WvFsKYDXk4lkrlsbhUmO8dIY0BdtZ2KZLM7A1Sk3SPGyL pSXSz6VfSFdLN0m/4tvteGyrpd9Lj2H74//y7S2AUVRn2+c9M7s7m+xldjd7nb3N3pNNdifZ3cCG QAaRu5iogMDHFlAEFJUkIALKR7wG0ApqBUSLWEWx0oogEAEVrfpVrRXrDbX9of2U4iWtbflQC9n8 75kExfb/foY558yZ7ObMe3ne533PBPbj8R4chePwOfydohFTDq05TpM0S4v4pKPoWNpKL8ZjPl2E RzvtpEtRQ4/T3fRZ+j7n4OKItnO4Du5+7pfcS9y73Lc85Wv5LN/MT+Xn87fwb/Fv80f407qQbrRu gW6L7iW9pM/rp+iv0m/SP6U/oT9j0BvakK7eaHjX0C/EEa3+C597zw92nrL6t2CxropfRo+iX3i4 dl03TEGJ6elk7mruLu53unnwFReGj2AtdyW3sP8Rbgz9hlsEU+kLEOFCuiZuHrmT9MOT9I/0JP0z 74TJ9DNI8XfDPrqIG4UZHcPVd3gnf4vuBDLdD0gTXQmH6CvcLdwt/c+RJt0WOKrbQt8mYf4YdZCj 6NXddCN+6Lf0SnoHmcbndafJlSj3J3TLUN4j6Gqo4d7lt5BPuSj9B2ZXGxA13oQJfIz+iBbhSUTc PgiSXugg7XAfUeEA/AF6kBNv5x6HC6gJtbWTmmEI0u43ORne5SrIdLZGSFAntNGv6BTuoP4wV8C0 5zD5HVkBHChoO2f/lcm16AE/oUnEtNGIJu9AA/GQjYj3J8sHGWLrjujuQDt7mKslFxOFlOgbpAl9 41M8ppHbSQPZjza4mih0E7mxvwvmIu5PQvykBPM2koVKREs3rm0VxgsXjSAWzsLf+g3i/+uI+hPh L+R6CKNnHSIpnt25kx+NyDQb8fcOPOaSEl49SO7R79G9Q1rBTQgfLm9BK/89+RHGnP/G3+8jzbi+ GeRhvhZXHUZk7sBPPFgeR1Q8bidvACUrcc0j0M/b+HGIvBv6r8InvBJj1AUYE18jV/ZvJKNQdxf3 39J/B5nV/3D/TMxUL+nfjvi7tH8XaSTduul0qi7N5xFjX4OXMR59DHcgbo8jHyEexcFDPsfjl7j+ EboDZC3/AWJnS/+d/e8RJ8ojghK6DKPoJ+Qa8heU2zjuEMmVL6RP94/h2jFCHSUX9T/eH4IKsqD/ akTeg2SbQYfY00WCum1ou3fw86iC660mLsji7EzdQ4QlWX60RD8rhyFGTnqawgH6PGKbgb6wi+j4 Hvr8MxypMLDBHiBeQa97Ae9TwkE1McJC+BHxpMVTzX3NF4onmyf1NZMWHItnsKlXZJtsi2MDfp6c CXOHzqg6chot+hB+/pP+T+BVZA4mtJMFB+jPiZcY+w+pxsaheaKqI/MCqyNWBeV8he8by/xGotYU 8o+TfbjeHm78PrOBM6uOShwXVDMhFbyouvIVKv+NVzzVe7LXZi9me0lLb4t4vF6BDo3zpGHM+RDl EoV8Y67B5awycKzVRyNsBhYkpulHZbMj+WszI0dm8IT5XE3B13LBBRM96TPKyDo2XTeSvSNwG3rY QVy5GW3mwX093l97vzZxpp7+b3ZH43mtr1Py0NN/YjcumfT0/1oN4MDrwcY3FJuvTWAwuU20wn8b PpgZLXzybgPns2C/q4oj+EjPmM0VvIU9m8vnc9sqruF/5b6G2MB2m+T/iXzVCsw8T5X6Tg085uCz 9jW3MJGnoaM0mNx0Apc852nlcx+dqo0uOjSTLjqK5cuGuAp1tU2+Ri4KseVeb0tTU/2Uy8sfQ2pF rdo0rD55V/lDFu8mlyfQG5ELOkiTGt1ge9xGbzetsdGKTUYb2YQsB9Vg3G6JtOlB31U1+UfMLEq9 fc3NYjPTRG89ej2UwJlIJmhBJEOcej11VrmDlN648Yr1D0LDqRu2XCj7JqwsL4pfMO9uWPsuNEL/ tTXnf1ne8Mr7T619fDOuIYNrmKqtoajGqvkaYZyOw19uw0U4EMyMFbiAgRIzp+9yTnv03xcBJUfB 5XbZnSIxFBob7YV8MkMzm65Y92D5ra9veGiS7J14o25uzcR595Svf6/8ehmujY/+Aha+8t7OtY+x FVxbfhI2kV8j97pETU6n090vuzije7b3sJczAjHwvFWwk7121VTJN1mdIWeXk3P2QI1aGbLOslKr 1/MgLgp9pTSpr8RM9BN7EWx2d5GtDDocuCRcUSIaMQxapqYw/bXzO4wGQ2XcXlXfNLHxvPnryk/W Rta1OczGKmNTrn7M4lnzn2Y6ugS66DTkhhxpUcNU1xWY27hKB6DtR3CEitAGs2E9bIXDoEfSld9D uvjJM5iU+kpMRtlebNlS0g7ZKV9CdX2nqXsj++a70V8XIYpWkrTqJ6q+klONalPBqLYUZhnhIeNT Rmq8zcRsUzzV0ZlOs2erV+Ln+hjJqpprvaS1mazKvCmMwPOsbgEiuZl8oKZcZrCS0WbVyqlWqDGB 0wBUD5xRpwfeVGkmvMnM601mcw/4VbtBqDIYBIHjDXoTclMzmA/Ag4hdlfCQataB3ijo9YKON5n4 AzAeZSLAPLXSaLRy8BD3FEe5Hvha9UALPp2PWGG2dav1mJWz6lUDGLyW/UjKgGi66mgWSx2nSs2T TpZweFxkKNdSzIooK7FX7OtsthVtTIvF7kyaXym+zIZWqxUtvhNNvqMTnFFb1CYXIIcdcM/u3db3 Er3u2m3lGJy8q7wZ5nVxN5+5kz7cN4tJ+rL+E9xyzLVkCKqjHuXBPj14ZXCVbpV+VeBO/scBQ4EW 5CnclPCl8kL/Ut1yfzdd61vrf4TbbtwaPRa1kihYRZvd4XS5hSoz5TgmKltYrgpzfFj2SX7O4OF1 OPvQ7nBYduyHb5HfOFSUKfyJ0D/JMobY/TCCSDB2T5dhq4EaeuB/1Ao1Cmp0dpRGXT3w7V6RbpVB Zl+iGsOquFWkojeyH8neZ5rEPilNQsGUmHSY4Ho/waiAY3TAXoZWgPJCk+8WMmkdiouwi6f1bCNX NXdCJ+0M3ww305vDelKazvC7REqY46uVC/lF9rnBdl17QFeaju5ikA28mxmY/hxvcbtyDehDCDNJ 4JZfWF4wHYwP3HbprRctXr5iUSbqS2YnTrru6S13XHMQeN0FP9+b3LK6Z+HeruSQSxr8aVHOP73q hvea6gzUyqxzZv+n3DDE+ggy5RN7jIJVoZTVL4cqhXxWaVFalVnKjcY7jNtM23yPSMaEYDJjGuHi dHKIB6vFUcFePRINlKFv7SoHOHpg756KMV6OYOi6WJWianUlLCAkUWt4+mgArAEIdCfEa1zHa5Ue uGZfQg3XKrW09gA1Y3qrwJDd8oMzBtD/uHiyFy2z4zv8P9WM0i1pWMJOFGqxaHOfBZdRy1Wf2y+Y pHilxxwgRp8hACZ3RQAEPzZkoERw003o+NAB0cbGIQyHEIb0zqrvPTjXoEnbgPI+169frTbUT2qO dV926dzmjFwz+qXHfjtn3Mj/uHukMzvyPC2Wqv+57d6O5SNWbbhYiV/tj9VfMqHjl8umLRy/ecGj a06OzGpooMVWEbnITpS3n4So52mqmYQdQkEaDBB/0E8CIQj6adXz3J+IG08DnhXcn1S3QP1Bzir4 XQESascMhAIIViqQbAtKp/Tm4TezWSYHsbf3L19CduCfuLL75ZdFPOsVSZUEi9VqFiuCxlCbrHda HaLP5pMkvyegl9nGZrzAut3KtLzWpzNav6t6YDqcGJj2BQem3dr0LqfWqRtFR95srcQvL1onWMeI 44Ot8nTrpeKUqmnBq6zzxQXBpWIX321Za+0Wu+1rgqtDD1gfEO+3PRB81vqs+Jzv2eAb1tfFXwde D35sPSJ+YT0hngh+a/1G/DbwbbDWaJ0o0VAQmJBIIBj0Gy0VktHld0sugRokwWmrkpzLglYxLAb9 /ohNrLK1I5MQrRZLD31NtdFgFaXBUGAbIQOC64E9qkkQrZzT5RIEo+DvgX+qRit+hm6zqLYequxu DUKwh36pWsKqpc3ylYWzPB5euFaLtV4fhjWPjzl+L3N6PLA9iVDQ19xtGfD37pIl40l361a+nPYQ sRfEQ//edosrX242NON/DQC+L9l2oufLBmaWbqdcQDsdAjlwDVyw0FlJuSf6/jEzMuyy8pQp3twI +EMUjhRLl/R9dlExde3xL+HV91uToawhHrd6lHv5mac3rb5IF4/zGbl2FphprO/3jAlHMEM4jhgc xHxmKF2pKjPIjOAasjq4Jne/76fJHb4dyc98nyf/nDUNJSuSy3ObG+7PbYv9PHfEdyR5JFXBN/XQ P++2zm9sYlbhj+RZr/63053PqXItNt5gvkGNprCRAvnzY+fH1/g+hPdjH+U+jRv4GMTNDSLn1Eu+ qqAr5ko5lUzD6NiE/KUwzTsjuYHaRCI2TYEZsdlN7U1dTVubBJ/ia2gjiDS+WDDlzfJ6ygXdwdbc 6tjm2Ic5Q7hJbWprupxezs3WzdbPNsxWluoX+xZL7cElscXJFalb9bdLtwfX5bqaXs9+lP0i9s+Y d7pgDUlGOSKGJJcczcUIh4lRIR2KcZHqobU5LhNJFQpGV3XK7XbRTIpZyvoEJJjZNxW07jzWde1u GZlnl7tHjdF6tQrnL5jlh4qg4qf+KXw6NLS2nt0QRxfsKr+VpwSbYzzHs8kKsy1PeAjzwPfA22q8 Vu9w0Cm1JquVtWYzthG0ZatIp1jD7NK6pdh0EN4mMpmD+RRi5YUn0+nmSb1oO32ljnSpg1Vn67m6 zySt652eFpubmYV29moG1qmFKnZqwDqIprYBHE2nNSQdmc1HU54gGHySV6J6fSIWp/FcIuVJ5CBr qM9BNJjIcXmoz3FJqToHii6TI/FAJEeCDVwhh7RCbE43p8+py9bcdBMD3w7o7OwknR0kPXgTE9cS uAZiXFQu5BqGNBZsjB9GCzKCMZuPu1jAG0Brg20w+DHkNnC7fjxmTtfRT/u6clPi7kByUo5OePTy DVtu7LshPqt4z70XvrR/btuSjj3PT31p3YhpEn0meN7M2654dkq8MdrJXf2fcm3cE9t3/byHrQZD y82Trt/uOr1IemRZ6z2T2TvRQCb0/1FnRayOAVXPMwazkKVZLhvaYL0/+Ij1Efte6z57pRDE1cNK 7gbnMtePubWun3IbfDu4A5zRxFl4GhjHTed0WUG0xSRMg3R7qASwHzOgiXvDm3UpPwc99OgeW3qn CGIPN3LPOvNDZmru4bJqtspIdyDhhwZxx1M2CNlabNTmU9EAjc1hD1g9IQ/1aObhGR+fe7nG4tKl zkm9F4qlU50dk3pPdrCY2XGydPJ4S++XJxFyMG0UX9PUG3ZKepMh7ktUJlxxvWSsIyYnNoJXVwcV bnMdId9pDpWG7KSzowSOqCZ0TGnsTAdD3Ho+Gmb5lz3GwibT3BD+7VBoxPGHuz9aubR3062vLw/N K391oPzUs2v3Qstz966rsUtVvkrdwnLurb1ryu8e7Sn/fX3H9qo92/+5/8wbMPnAOJdDUliUjGKU ZAzRhRyRU6dXSpWB28X7xPdE3VJxaVW3uMlxv/M16bXAu6LgsdmrAkHO4IRu3+ogTQn6kETkiCEk meWoW/aGUhaLmXpTLhcR/M2tdiB20R62K3bVrrP39P+fvUyG9vFR5osjWgrIAsNRaI8ypslFZbfm jW7NG92auN2YuJhE9Ea9Nqn3sUn9lsicQR0wX+zTWmSGnelTmlK+d7niWRfz+4JWpxivSgSt/qng c2ITsIWmguTwTj0r/ptuIsxjSh25HzpGmMfszqCXkyh1gliJfhHNTY25/MwDUqDA8Bd3vFi+7uNV U09AQ/m3X81YHB8iL+auXhWuja8tP/9O+dPn373MD2PADV44P8BsvQbjwTMo8Rw0qi1qYb7/ev8D yhOeHcoB5VhBmOpt17cbVgmrjF36LsM6YZ3RGAtJATkSD0lpOSqoTCCCbLGEjJJgYKKU2YxBpjSk lwx+UaIQRf4RyJFt6QypE+toXQ99B0NFbRoNaltAOuH3BwTjDkHQ72gxrDJQYhANrQYOv+u42qZ9 19LMjtp0qC6LH73atyOMjOaoxEmXtBXaC1sLXIGImqpETSuipioxEo9pqoppkzFNVbEt+WPPQrdW 1GFq0nSFPlPqPVn6pA/VVcIMUVPYlxjRsStroR2hsrmvmeU9Yu+XRPyfNAz2TJ1a3m+TmQdgAoTE PBGVbVUIW8xPcI4bALbvFch8CUewA2qWJPP6eNxisV88pfy+mBp6fPECZcTI1HWnv1CUdNjti01W eKc16cw1pK7Q0b4T0cyScupyfzRVHjkj6Q5nR6ws74i7RfVyruOmYCpe/mBhm9PKNCqjRtmOVh3U PJ3K9mCuNSQ+t9HIGyt2ZrlN6f3pV9Mfcu+kP+M/qzjNn64wYtahX4U67tJ16dehjgVDhbGGGmST qQcSqlmQDIGQ5JYjelQqm6nWSXqLFjuDISkhR9O1qQrBxOsoqhrF764j0QRJiSmaYpqOJ5MJiglb Mp3aQaqBVCvVanV7NV+9Xq8PGaDVAC9gUsqoWYZYNE1aNKVZNE1aIsGApsmANhnQNBnYkvk3p8P8 tbMZWVpHH8vIUHt/KX2nPNSdTatFoAsOaK/vbI8q7GCJbBpsTGWoxAyNRm1VbpZs5ZznxKWz+sP7 8MjXU1rN8TgkR5//tbkCE5n6vv3K5ITHXBFCo+D+Zo76Rl9xFSrti4mLyoXWCfHy1Pmy1+6Jx+vD K7irB8bl92dNTzF9jcNo83OMNnkoqZMr+DEZ6k36UlT0iF4ablQbZzcuE9o97d5lNes96707PTu9 lXXZpZXdlZynMeNra2xvvJP/BX+skTdxt1ceauTGCagXzz8idqa1aF6LP7u1+AO7kQFOVEfVb651 ezwRfaqWs6QiRkiHgiYm+aAm5KCeCTkYsdna7Ovt1GpvtVOGnavs/XbezjNt2BFAP3lGA9Ae+o1a WdHclgBrIpSgSIS+UkX2NQmR3U+ML8xdO6grBET0s2xaU5WmtU+00hXTkng2Ug2iZD6cNohCPJWs TtYkOb0JiYhVtg2DcEi0GdIVdcQcxUYMW4YRY1JfB5VxSx0ZoBaMmTPiMRDC0pqPMurBAhlqMcwo 9kAkszE6UZCdrCbltCEP0cIaOu532fYQ/jNU++Tlz5f7ujs2/KNr4p0jQyMvpmbvhYGqxcfWlK// zf1T5+26740JyxcNdTgkDkPc5K0XXffmL/76UvnQfYk4rJ7XIicS+fg15Tkjms489/XuR3915aWe amc0h5pn0e6n6Kmj4fqBjHDfWJUJjcR7+k/tYRqJ53v6z6h2Nsxrtp/XVJR34A+oDjbtgIimu4jm L5Ge/hOq5jAR7QcjvpEiZpIBPGvxzOKZISZsjXi24NmMOWblcBKLZYbTjL+Ckpasllm+iQnll19q DWRZSDr0Zpr1f0gfqlfSktrRPnbr2MNjj43lHWO3+NXGNhxStLhKORIJSX45kg9JGTkyOiSNkCM0 JFXIUUdIkuQoBo46OVoIScPlKEogGotJI4YPr6ysoJm6Or9fEuyOCFUjcDQC4YgSaY9sjRyOHIvo Iz00rPrEsbPHHhrLhcfC2NHxSKEtPztP81vGzPm9Jz1JPNnJyvRiR6cGBlrBfjBLw2MACs6yUq0Q CCzh+t63NTNAO/hX55f/dzgY/Ahso0sRB9KKQs/XwBuBoFZR+g4qlyS8fWu1W/V9BwYhAu/Q0ShE JHIfwK0LBoDBLY6ce+a+71ECflq+/BzMWHjOjzHMyCFZWsbeXCAvqotkLQrLmunIaqrglefY5jYK IYnKEU9IsssRb0gCOWoMSTY5archUAseL2VW4xWYlXh59lFvxNgudAnHBK5fAEVoE2YL3CzhkHBY 4ASe/ZigWaDQ0//NM+yzOCirAY0AzAm3y13yMZlT5DZ5tswdkg/LlCnlQtSEBtPo9B2dg1itAfSA Flgb/1/kelYTdNm/iA6Fqok0/gM8ZeMzP9HGTEKY5+r/jhJS4DX1hNUDFiK4LV5zylptreEVg304 DM9O9yyCBZ5rsss9G2Fz9g3PR54T8IXHbPYgGdYrYxSu0dOojPVwLiXpSSic3qNT3G4uTarxahhp chc9BW9BaWlobVhAVpClnuXeJcpassZzm3I/2ag8QR5TtjbsbPiN+zXPoYbfuz/0HG7odX/u+dx7 rOEU+af7ayU+Dsa7x2RnwHT31OxV7mXeVz2vKO973lc+9XyqWAay1HBI8smRTEhKaX4kyNGBvFUO SUnkuQjjBKqIx0vA6/GwuscIJVuleNxK1oN5C67d7fN63dQoCIQoSjIlKP+BtuPNZiLhsLxV3ikz XR2T9fIWtQEagLKvMIvWsNXGMs56TYmoQeZZkxhbYoNmWzFbRi1qjnXWwVhB7rvCJ/YebeD53t/Q Ajo6MNyygqeUFatMLTDQiEWPx1b0iPYiETxFd0//4T3uolupKmp54sA5HTBflIGZxA8dkQE4wDkW c85t4Mb0nZTibUo5pSBLrrJMvAS64Ev4BLqylyJrjrdl+w4pl0Zdff/DX3dm6cpQTTyeD3dyS2ek Asn46Y957fLM2u9urD19B9pW/6f9n2PEvoAk4UV14lo72NcBZoqthXUU7AEKSVrnGOpY5thEj9J+ anBEInaRIWBEZggY4Zheo1VMr1G73QaURuyRKrs9EumBn6nW5A6oMBqBSj7BbuQ0fZjsl9hsYVER VZETe/qPPWND5eDg5DMa58WBlsyIW6q1agMmM9UQZq/TH6um1Y4q9hVOWVYicCiC0UKLDlqIjrBg XaHFDW9qzs/OUqpSB6q677s8BidwfFzbGhjQdW9v92B9G2lVUVOxgW2ukFLnqGlqymj32quhhRTt rWSCfRaZYV9ErrKvsD8AT8AB2GN/A/4J9r9SYJF5OkHu1TGKvddJ+7fvDtpbKCupuMwtSDFO7EWj Uv1FNtw12Elat9dbRAxjwyOq1V60u+xFKjrx9BYxNB7ZVVnErzk80H2zp6pIVVuRnC20nX1XDK2K lDg0qvwPUCf6r1amUXYJ2rnhzGLgCLOl2JmbpUQrGhYzpGHDhwWG6S44Y+AsZ03l9Br+/DPPfWc4 T42udRgxv2Vcb5m2NyyRp9X6jfbthicqnhD562G5oRtWG/hRgjlFOGdKb/Q0s79AoYQTuTCncCqn 48YHmH59LYVwQA3QgK2Z/dUKtRpDRmoc7x8sBrC0c5LYkT41kH9qW4NIqBpAssYrE76EI2Ex2eqI BJ46qDLgyKXDkVhhrgMvxcYuOOuIm3fWkXOFlb4JHRjCLOmUWTukkeXDNpGxJLtNRI7fCwLcUl5R /qJ8onzL71/4eu+1a+66ZvcL3665FknRovK75TfKC+AuaIZRv3l6fPf28sHyM7tXQw2MhJlPrma5 P6tMprWYVgvLniUZfNR7mwrZzHWeJdIS/42p9sx9fsNyz77Y/tTH0sf+j2J6b1LMpBLFeDE5LKVk ZiSvTLZnujKVrxLw+av9E/0feD+WdNtT8HrsQ/dHsQ+TR1JfxPR+NRpICRYGpREISQY5ikDrlKMk EK6tCaRaoq1RTAEMzpqUy+WkgkGwE5/oU3yqr92n843PDNYLSAbUzM4MfShzKHM4w2VqQUteQKNd oJExiFgtmrcNZjRa+LRsqcv0wPW7ZZbCaCW8f6kblCaxOl5ioI6XYHW8gYRGq9qVkCwXWR4zWEuI Vbv9nngqUe1O5CDmxybprclBXEJ++X0tYfzk5aoYRPiJDuMjwfAwVGGIgMaTSVqr83R0IkUuMU70 7wirVeRcg7siSdf3dTgDPOpPTMr3HchNjVdJyUk5+Nve363/+Nf1nSMLFwcWbBx36+RcG72hfF1X qDYeHxpawl3NRhN3rXjssGVsRcXDXdM2TnQwrygv0i1Hr3CSBOlTq0fDNMN9wOktcCmO5sFSuB3W kw3Cf1k/JUbeqpLzgJsqcBv5HnpYzQqulMiR4A5BCBOFtJMuwpOLBcHMpSPNIUfWQYlDdIQdikN1 6BzjU2c9KKViguprFs1hM7WaQ2ZqHp/8f3nQJ6xWWkI/am7pFU8O+JJqTITj/kSlqcJE9Z54LBqP Un3IGamDgNGHzmPFJmHDS7kqWIdPJZmwMwpei6sOonZsWJLC/msKqsFjUAslHav3J2Kx5OC7BMzX qgh852pDGrWYx90+r3fj2vKr5T/PWz95RTesBaQscBv63oq9i+6869o9Bxd3Tyg+Z935mCmsu2L3 FU0j54D0IihwT/ma8pvfllfzn9/8SHlned+uNWt+Bs3/eKxr+dnq2wL0wBTJU6ruinmY2cY14+2O gP22xCvRV+q48bHH66gn5M7Mi3FGMMYT8bFkGiyii2I3wA10cWhxeGlkWXwtdIc31T0JT8b3JQ7W 9cec+vCtcGfs1uTm2DZ4lD4We6ruhbojyl/r+uvMduICH7Wn0MvqmzJNyrzYldmKGoH6/eAMSVY5 QuIpiSChtchRF8suoiqtjcdiEQpVSGZjO2iYGmqqt2kFKDdbrkE0tBlmG7j12jYvkXb48z1wt2pt SAUCfmq1WACIYNe2sqYNbGWNbi0Q+SmZtiIpovIesRFUzKwPN3KNeUHzbEGTg6B5thBxOTXPdmqT Ts2znVsKc54FL/mXyoRYYvlIWnt3Ojvg1dlBrx4kT729Irp1qTObxuyl2esTe7vZNhLbbrcXfYgS 2r5RulvUrXy5XvEwv6+rD0ZD8bpoNgf1QWwykdocicaUcEMOyFnLwvy3c6CGq8XXeP+xXaYiYMzf VVVEPzi2t0oLmDj8ao9YVEQrhkgYiIxIt9JpWQbN5f9/kGBgO1TQMAgKiAm6BeUN5UIubA6K/sQF BQ0cnKw+CX858ua6R54Ez+y1i84Md/iNL73y0C1Nl9MVFKC89IcQ0fLEdSt7EuUbbp9moj+B7Tev esjBOH1X/x95HeLEUHqp6rXfVwtWsNJKjlj5FKnWpVuhlRptTT0wRj3cOLTRx0n8LM8s7yzfLEmv M+sspOZQE7+kcol5iWWptT3YHmrPtitrhNsru83dllut3ent/PacaDfnzHlzIZAL5AMFVvqv48PB cKi6ui43AkbQFl7xKkElpMjD88ML48zjaiZXTjVfKk6tnpoOhCBEpVyoIDVO9kz2TvZNb5iZm5mf WZjZOGOIhausrHZUStXRynDTsGqlqdPe6VgT22TYlL1f2Z49lHqx5tX0oaavmqouFIZKZBGVnoK3 gMIqGNw5UM2FzfV+KbAoJAWD+wNsJu/dXIXg0WyyVJlMlrSpxsInjFqnj0IfZkCpei6aYjsKoAYj eYAQ28iCqCpmbS/Y6FEbhG1P2Y7aOFsP7d4X2hFMi+jR7AdCD2XghcxfM/0Y2tSxBTXzFl5wJBPO KBjw+MxBGEOKMEbbiGKQWUp3IFh2nuztwyDW11nMpge4hxa3Bvfq2S6pheUE5LtqjzYqgdjROwit jTHF4EglKmuNOVJtZUHNgY1BwcuKOlOOVJpq00kRQ5zVUl0Tt2OYE7J6ZvMDZR+tgbMbGGj7JSSk xssr55nni5en+dL0EmCMJR0Dr12YKj3WIq9YiznFqtHD6aAVANm7AZh6BqkW85IDe05RWy5Iz76A EUucfWuAFYm4J+P20o6ZC1anR3z2/B0T/3pwWD70K583YIjHfdP2XL3y7iFNyfKj915w7BdXLx/q 9skVyIjS3Vt/tOqiEbmJK+dd85OLNh816lqCWXj7nrtn3zqjYV5t8FdL7px8zzsFbyjLLH8EcqOd Gjf6m9o0A2bQGYEZwYX/l65vgY+bOvPVkWYkjaSZ0bw1b43nbXle8YzHYzuMHDtxcGxiiJ3YpCYu pEALbWxTcnmUxi2kaaBL3LKUQh9JX5TS/V1CcIKh28VlU+gDt2m3y9LepaS9uZQWvJt2A5cWbN/z HY2T0N/ecUbn6OjojI70Pf7f4yjoBvqG8A0RvhCrx7bGvmB+IPiI+eEgR6NwBItJOdZkAekZ55Q4 FaVlOx+bpxd0lwVplO6z1Z12PNwQ9RjWl/N0Rg/wFiLnLESkWYicszT5vFEtAvLRBmdQETmyK3Ik Yoo8TWco7+obughS0EvknxeP/oS6e9xwsJ8bB4EXwQJWrMAAx0R7Gd9g7Yzc1XDYwpOhdLGCv2uH XiVQB9w0SP4RxKzA6jP8dinDLXuRHCK+Fy7uMn3VnhJd0euGn8GIvLD8fYDnX9+VKfdzKdk8sPLs cKKj+s65NShukmyuG9+HLoG7Kq6eNj+O72oe3fkUVcRmR3OhXCRZDwlS6sPeUDnDdrAD7K12UzKe TK+Lr0tvjG9MfzPNZdO1ND1U/Kh4u/2h9DPpt1Nsl83wuUSjQX+sqZn4XFzRoBKLY9Mc6yk6mbFa mrGN9qc5uGu48iox4EgF7mAWLDXZYuF1qcbrGKTwRZ7msXmnO9xu0D1ED7HE5QJGn+GUIVfaW6/I RTRZPFI8WjxdNBWjKnmYKnmYKnmYapPTuc+F9riQi+gulw2OuSJwzOUvnLtg/4G9Rx7SZRiSEgtQ GycAteG+WTJUl2HYb7n81serPGbdVCwjOJpi8RjN2pPpZMKm5ijZkZKyOSQKMTmZozJiEqwKZIAf EhtG45gXqSlgWXTB78MSvZPCuuY97iDCfw0NxPwcnW4d0jyXL73wm1eL6kYIAZeHE/7wwKHr9/9i EGscczqZ7IlOLf/6hd9+9aFPjr1JO++4LJmsJKaXH9/6wnT/R4+/RCf3qS2YDoKrv+XuwHRQYyKG H/aEBbVnU27HPPM7MC/pNB2yFIMm0UmLPAUOUl+tXpeXT+HPAipAlo3fwlo5iRcsnCAU2RrntCmu moS/QaAn3lIOQsYALkO41F/DlTZLpdBvGTONWr5lYVOsxreIGSnjygSyweZMutTG1gLlYh/by20R NweH2VFulB8TRqXRwGhxuPRBdjd3o3h94PrgDa17TXvZvdxe4Rbxdun2wC3BO0K3qDcX9ps+w98d +nTh08WDpc9xD4r3ue5THgx8Ifj3mfsLf198hH/U8qj4aOCR4LdDj4a/VXiCe4J/UpgPzBWfL/6F /4v4bvgvav/1hQ8Ury8dtJjagzdG9kQ/kjN9gPsAf72F2WIZiG7ObCmYxoI7CpcXmSFuiL9SZEwc JWAlF/IWmkPZaImriZZG7luYcnZ2BIuWkEl0GHc26OQ5EYl8Le2kwZNUh2DbD+DTUBe1WlBvsYRC vMUihLDWi0R4ikVByhVwB12ZQjaYcUp4lHQkFUzXSu3B2vzq5BNBUVDnV/fo7iLPqZIoNgVx72Ag FIpYBIG4QYIh3BAqhHm+CfxkxUKJ5Tg4EiqW8G7J5UxnMtjEomhREHies3R+hf1mCT+zY3qlZKSA kJSOVK5YLpZmSrMlZmtpV2miNEl2TpfOlvjSa/zvLVeIweMB8WlapQLor7qoS0PSKYmRvtXROU9/ 6IkYJBVpkD/ol88o8vI5AhG15VfPo8KGb+2AOa8dsN1xEpfKRRW+UQF1qv3/c40u3nKyrYvHf5zc NUbcccYHcx8YipgBQSO6MxmvtR6BjVrEm6jiFOuGJTkG7nIPVoQY88UR/pdKr0VPQF0iVxqMFuLB vdCIDHUZr3B3VDZE3NrKpzIrP1lZTKx8OCe5N3ait5RKewsSf5tRMYZ2+f2uLC0n2ss5ZEJ0S9ib Wm8eSKbK8bve+S5zzbtfNl37cV8qmUwWm+IfX+boA9M716VcVifP4qZs677lKP36x4o+bNwnQbpj yGj+NpHu/zpnppCTyMlH6hW9eJVylX+oaGrx3e67NXVr+h7fwTTrN/tZmip6OE9GLQ4VzWYznmnG Q5tilIoSXCadyCTzxeImpBcvx1bplZHRzFDxJvYm7qbMTc2TxRk0w97F3ZWZaZ4pHm7+Ovo6faR4 Mvyv4dNFdT97gDuQYRBHB5GhlqMpNRilMvkgZSjoiBIORhIpxefDYMON7yPH80CTTekM3ssoKV8h wxX5DJdOKeaojOD/0YqAQvd551f/Spzx3jVvIFR0O9HHTTpvoYkyx21PEn3+D2oa7oLTWlHTxbSe HkpPpmfSs2kuPU9/4YkCUKUfozktgCV9V0C54K4HWjzPmfA9YDLAHC4NMsS2SoMOtYuozqgbYmCu I9WRpo3MV/AGAwxD00gj1ol59bRuwxSHMkBxsFHA3SfVOKPA1/3a41KtEeMDaiROX4wA/tZlgVL/ DQ1ihXEK/SoQ2H1F18pTodQVLcsLgBNWPrOh0O9O0b2Rwtb1KIiErnBbG6a5/Pb3Ly+v/MMaaEDd dPvudXEhmWxpSVy1sgV97ap8qMUPNvOlq0vMQeYxah21nrm0kdep1kkspq7Dk/EEuXySF0WwpKE1 SUmt4HcVnU56pNULXfD+bwgkaIWH54FH1kr6ttY4UnI54nZSLfiUfCsVMWVbimVJt+BBJT0chq0D H5LmV3+pR6CTJJn2KUghrQrpocjJCNfVYqIKGJVjmTHurJG43mJhGR7nL7VFVMA7BDovLLysaSfl Xy5CgCao7xFDd7fSzm1tyKlGazP1RywnBMapOe+g7mj9FHWPeE+FDTu9HXJ9pm6yhAbMA+xGdWPT QIdePxjmBRunUk2Xoi3CpeKllS3Vno5L1+8QrxP3W+4S7hLtw947vXS0vqtOT/CtVLkrn82Vv4vF vERJqwsnLDUpI9Yk4rPpqMhYhtIgSCckRiXFXskkdSngBM6Kta3KLmWPwhSUfQqtfByzCcy42KV3 0Xjak7mZHJ2r4Ps2z2zSHSYxv5BDuYkk1WqVpHIZ3/h38RNgR1q/C2/RwLYy/kVbjUpGkzPJ2aRJ T55N0jNJlJShU/K7dA/FUR6sDqI1zzy6To8EC7USp9tqKjfEzXCMzKGzHBriENdzSc9HDBNpanpa G4QIN4ZR4OnDOLgh5OW3xjGXnVs+My4vTdWXpiGdz1GDPppWMHjnGCMhzDlLRi6DkfbcV+kMxc2u antbO81aeIGn2ViT2kSzFbGmUo6wK0Q5XfaoNYSa4p3mWohq58sqqpRFZ0gOIVsT3nSwXSGKeCnA bGrgsuZmSNrDnIk5FJtL2FYaPVZ3gvgf16hpzK1zJTxTTJGnj8mkOGGrVVU8d4NTVUgjF8Waooo1 H/6GgNoDYk3Aj7KagVLApYBLCy4t5/3ya58xPM/kWt57ta2tajgWWI/v4mxtn9dDMm0g98ZjuCkg fdvjxk10398l2tbvuj2S/ckbO7bVkym6kEoWjh6+7bLOkFPw2WXJ0zV5bakDPdCytXd7+8BdH3b4 P/mhnlLvLdsTB69tamrpyK8r57bPZqMbtP0rP7qz081Zu9o/33sfGu/yt0zUNu/CnL/6zuoZ5inz vZSXSqBfGJz/eMQMHCwDL5vdEqWQ4IoiAcAHRpeAzKCJVIDPJehvhf6SpPgoE21xAeh0uHUL7ub2 UMGkRYyN0Ryxpusva4Y5Tfj0ZW1Bfg4zLcafDZyFVQjF4CHweXAOnBsxm1NJCjIG2RGFBuqFy3l7 DvZx5T+ehCZJSiUdRCBgxl+A2mLj9xaNJPugfqucQt9gT7DHuT9GTeZUj3W8TU3dzOw1fYo5YHqY +Q7P9XGog3enrd2uiLtX8UmUKeil5Bg6fyWlqHnWTE+YZ8yPmRnz65KXopSEJMnWIeukddZqmsGb o1aGsoJTtoirC9ZTVs6Kuf/Jrop1Ivnslka2I0SSZfCVycvj04afYbru8NXeXHoXvUlYI+NXGZFL qUxERQFBCVF+RZRCPN6LmmIq8ovBEBVmgypl6JOGNfOJT2CCJxkj02NjqLGizKAtw+GdTrY6HN4L zi4Wde5/6O9+8bV7vjP0ze12VQk125Ar1/rh2s4vf3l3pZKh33rqTz8/d/9MRwdz/EubA3J8cjmz /O/rWn/4zNHvBd0Yo2zCNNSPtUcMvXmMN6E1/UEH3pNqSHQA603aLdxEbDJGg8OSpIfEwljiz7mw bYgrPz4BGiVcYrCIx+JbG6+fXCKEsgjrAB53kkzHm5pzZSoOT89n3WGmQ65h0zbzNnaYGw2Ohrjr zHvNM9RMbC74A/WUepr6P2ZLFfWh7cpIaFd8QpkI7VWmQ3c773XNOmaVh9E36MfiT6Dvo+e55/1/ 4M+E/qieQwpL9zt3OO+J3qPOxM/GOYeK/nH1NKXibxQLDCpMgQAuYrqYiM3EaComx1SSNDAZm70o Hn02Zo1dG37FjuzPe5MWLgxBPXcNCr3dWcOTFGMvRCW0VTok0VJBpoqUTk1Qk9QsdZRaoE5TFmig qUdvCtwZoIcC6HAABeaRpDvPsohiZdZYSmdme5p6nqI/azixIHt2fHpqeWr8zBQhK02rLy1NEdF9 xtlgMWFb+JrwTWHmvjCWx1NjmDfa29tRO1nKA2lGBEfPUbIClt/ZE66aWZbB6bqAZSWWjAuPy7VG YA2T2BQCS5eulKnWxrKTNAEvTZwhyLBsY/qTL935pdcQmjvwP0stnRGHGI9fsnv95V89ePVl1TJ6 3/F/RuwrLyHbocFUIeXZG430X/3Vb7zTk78Vz7539YzJjCVUlMrRWxq0lSqQbJEsqxCi4g0CI8RG qWEvEVheUSVOB6AnlTgdVNIbt76tGx4FBc5QQ09DchEoakjRizpBdMku3WKjR1xuKokfXEsLQxAH SK4C/qIGwngZ44sFQpyQTtS4t1c48VmUKjIMnBqaDCM9PBGmw1ERDyN6iQzzmkBg4St0Q6ma7Ha8 peGIqhbyWdKHTI4dYdlCnki1Rc0QbpDEpIG4eHl8fLEOGfBYwGHeeIoqYCO9r69cABbZoOXLE4WP mT5mvts0U3issFDg9MJMgaYK3maPNmIe4Ye1z3PcZg6pharQJ2wXvmD6VvORArdQOKvRqkqpsacx tYtYC27sUreqV6nXCjeqt6mHqcPqo9xT3HPNYop3paVuZ8TV6wmnvd2hSLg3ik8TTS0ecteiLail JcqIUUqMSSoADKdnwjvjfczLRL2zXtr7enaIBcdCJl+G8sm+CtuT79nX8OAMLi1Pj3ctd8EHo3cs HJdAPMpEPlLyBTEZSGkmPp1M8VmV0kx4k+GSKmo2t6jU+YVT1Hg7UDiEpyCcgPUz1s6GInZiRVy5 IBkNdewzxysOcKI2aJh+vmem//On3/7nW7diCRnQrMiRs8e8wZy4cjbPdl1TGN248+iNO6/btP6d H/wA9Q1++8tEUL7z8lf7Qo741I/QS72Tta3X//DH/4YpegDLy23MUcpNhZk7GhSd4b1Y30mwUIKy kaKRO+op6hSCoCBNUTIsuF9dILISKroDcigoSgwmHRzkHNMQPJqDszkiXXE/zjS/+iI5A1d+/CRw g6kkikQwAIImmYvgLhsnZI3VcWFx4YIyDntmqCNYHDEqkU6McRHGLxq50gkgYZlTuaMcQ3ETHCxK NHGfM33NdMzEwE9xeGrAiSkgZ7c7GsHzhCqeLSZ7mC0usNWEm2y2aOS9KlxbPAVafPzk+Li2jlwr vtJF4qxy7lLG/RPUhPtFxuxXQximhWpePVSLkoUpPf1lPgoqIkpILFMmzdua8+Ug67eMuq7y7vJd qewMcIixsJyFl8yeS9mD9GfYA9Ld8v7w1+nvKMddv6R/Zf+1fI7+L8blnOAm+Ek8u4OW73M/tJ/l sKbjrHfRjAX4hMV80t9m2UT3WbZGh+lhy9X0NH3QddD/oOsblm8I8/xxy1Hhefr39GnpnODmT3GI 4k5x9BSUcO8gxHeUY7k7TG6q6PXApbqcNecuzz7PYc8rHpPHE/wXWGOzegorEBNAVBcUL+mbnTW4 x+8LIngi3Au8NxOs2b1oj3ef95CX8Z5zu2cgEW6Wp4v8If4VnpF5nccz4Y/yp3mWf9TmMVEHga6Y Ft1ZtMGKMYayyTbVxpy1IRtciQXfS1tPpKeBXLAJMLg8BbBlCtbbLmGcDynnwKCY16Yd+BFhrL3H g7G2Bi8bOIfN5GmygJpqb4dM5Z7RORbe6D81RowDEqybJvYzh39NjNckPVez4i+8ZOBYBoxnKEBG HAsae0HjWGNPMPYEY89C9nSbpeaR/TW/6qhZVZI4Q17CdBFEHxtzsb7GahBDgzlBgyVjKSNa8mu0 e/eBK/fnop4ff+Gbr//pxEPPLR9Aj5hl/zVt2+6kO1/46EevucV98LcI/ep1xP3k0Y7RRLv+CYyH tlIUc5v5M5RG8w3uTuaIvsrpoHZyxK4Oaki2sYi3ZRFP8iyc+F7/UXcCg9qchPWNhAv2aSPTVRf4 RDLioyh71j6PgsecLKyfXFqQF+qLS/KSoZQWAE6flJ+Dv5MkM7HByE9RdnIOhU/Vw1k2gUfis4gw ImKBAxHB1eQyXtJFwo2kHe//muBrmy3XsqaCXoYN/vnFRSM3J6hfco/6oOfBFNPL9Eqb/fuZ/ZL5 IRMq5PbF4AWyh/nDlq/IX3EczVlkFsupXc27NDrE2+Yi/Oea0FyEm2d4PRqPHI48E6EjjkTSh7Qh bPwWm7NOB8tzgowJfB5d8cQhbPDO028dQ83aPJJ1ayaLnHaH/Dm7HSWAWJ+YmCiTsqPDKOt1o0yU SKl7Q7HyrA0Bie+yTdoWbKdsrM3f8jTDMlwjDGgQ5eASJl1i2Xbh4tXxM9PEh9TVtTzdVV/Glm2h kb/iTKbd3lTSk0p6MyEq7U6E0N9ErjFIusi9A87/eKUVm4BrK3axHiKACVt+nlYPejiUvGTb8svZ zAb/sWOjx6c+ONpRjvha+6PRVF4PvcEMLD8809SSSGR6r6av3Nx18J9u7s21RyqxD7tcpete3LAZ VkiuX9nE/C+MyTupS6kx5gH9k07v0AOpB9sYKifvpPc2791GU81snr3iHtVUr27duad6c2py5yHT IfOdvruUQ5W7L7lz46Etn9p6v+9+5cGt86anzHO+OeVH5R9tWdh5aufpnWd3BgOqp1WuuNuiO83f 4vvb6kHKy7TF+oOUv+fC/+5gcbncFn4miZxJ8A85sR5KwuNwS3UoddEp1g8nH0s+k2SS8+grx0e1 GWxs4a66Ffo6D8ceiz0TY2KNc0iJT4nhvroy24/6ddzar+Om/hZgnf4hN3LPI1537eHRPh5XHBB0 qrAP9qCeeaakS/5+oeBHQ/4ZP+3/Hv0LisXMNUh14UMCy/kvR5e3tNgH/4kpYn0XwdsaNcgU9ahc RHuKh4qHi0xRAf1alIAlipVanpkZRsMwNyvmVlz58ZzsJpXfEF/MsJGeiBlpOBnNIJK64/UFyocy aGtmMrOQOZUxZWzQM7Pm/cSV/9CdIDAyN6s7izv1nUfwPTfvhFNDolTeaTv0+U1oE/HibCqpXmT3 Tnp/hoX9/OqfdQeJZUoADLzkGr3z9Pd014N1VC8VmSGGHmIQpOPRDNxKf7hMSjwqAz8PMBkqT8Ic mQ9eufNpdAu264THD4Kn30iBnl6aXiaVJW36jKxNkeTKKc1YoDklnyGLJJbgfQJEKSy/CiqiLi9B DjVGGdMy9MedsZaY+1nslRiN9cT0uSVYRAwtyVeSuGV6zVfbcNUSl+2az+i2LTs6NiYqobBPQeZU cl2ptVQuMWx3amsqn2xObU8Oh1CoMxKitlQGVWoDqqvUenM9RA3lBkPUFdqwinqVTSE0kt4RQtt3 hDuCuHuwkxoo9atoS3+lTad7VIhXm7pC6LLC5SFqW/Zyldro6wkRU1tbi9E3Nu99fx8s2SDLRach FwpNEdWmC3kZ02hFdoKv6ezjzkakfi0CT5ZqgJ3OxuMNG4q4gXzkr2HBr63rqJKzkBHgJ2Z8OoXY i/fwfmX4ysUjd048q9kY1szYtf/RfvKbvX0t0VgxNPnT9eN7PvSld76/f4voqHC7yloNefp395aH Bq7e2LrydqHYsft7c99pLT/0W3RZ9r6xT5/UzazFFxDM7ObJmRPuVM3tUDkTY7ZYJ6+YuuZzO9a1 KUpyg+WaaCkav4o+sPe2r+zYMH3b4Ss3vPuJ1tFkMXHJvs1lr9eElT5lxcLpv7A110YfaujGcLsO jCsLDoEoQkFJwL5CwvEKeHmAJxTwxxELT7EBkSop0JZRaEjFypV0DsVMkkSPxMgYsZwCY+QgsACt uPIWcVnl1ngMV97Q7UQpk/FyCFth3QJWtU78TeJvBn/TVBmCpxXix6q0UWlHuMUEXqxCAWxBsrIE E2XDHiSgVT753Dr5pGa0LGID8eRFtuFo2QksWSFb/IvpMh4UhnSkBaJ+BaJyBaKWhYanizQ1fF9K exXFSHOMNMdIcwzP5iyRNrjy5zk4gCvvPgnHcrn2akNrE6XdqC8C6MKzMLxjwFcIvOSFdr25IrRP YNxsT9pTM+2z7aaj7Qvtp9oZjUVD7RPtk9CktyOVV7IRxzxj1x1NuWwk3d8kZCNyfzyWjaTmGZue j1fS+e5ypNKL1HQbRWaJYZXDIQt+JWGZFdBRAdmFSeGw8DPBJICQSuaoWCIfzQ3lJnKTOdNMbjZH H80hWHC5kDuVM+Umqg/vI68xMJbGAAK9eInMUr3LUTP8Z9pacqk7EDLzbDKYCpn9IcTxAS4M6rnh KSOOYVg5B34MR5uxYook4Hsbuprkihm5M8Q0xK2NtZANixEN7vlk92WTQZdNKOorl3j0dQIT7S2W PtTvqW1a6Vgfdyv2aMBTsCGn+d7lq2/buP19+qMr/7hDVUKQISlfhno/f1WhvHUldFU+mki4hPbt zHrDeoTITBfecJhfRKqJbkRmnqISWBGEycI1KyF3a4x4MmIk1THmUhgL1iBEllsg0Z4EzcAKbITR fnoCelusyprEx5XfzTXY7fQau714nHCbCu4Q39bYntg+rIab9mAenmARS5AssdphALaJdWE0+CIW 6ovj8svjDQ+JEYlZxCyBZaZ2EmhsjROsKuGBGNnCOHNbtjQq3d1GRfdXq+yIDq6uIywNP0pRaqyJ c8H03tJDcKbFkohbCT9YaSB7K+EHmJnBDwowPuEf3PKkwUKJ+EU8YNiY+NpfXqwvGsGKBiv4ZxNo IjGZmE0cSZxNmNXEUILWYZMAhbluXZmU7R1GmSsaZTxJSj3vD5Qxg7j6m6zZiBOzRdrfrUZivZJf cs3iqdQoqkniXE5h1oIsNdDBx3oqUOj2eoW5QZKsfmtC0bWaQuJGbR3lWQUNKWhCmVRmlSPKWcWs HIsf+zphB/JCJ+ABrHqXDJiKNS+s9m0wA5kS+OuwyUbcwhe9H8Z1nq7b1hajELrONnd2Njd3dX7c X+pe6enJBy1cJBDK2JDbfC8c6Gpu7lyJLavba5iQA10j6P33t6h+e2KSolevWdmEDpkPYarNopMN OS9mXMQIckXh+Z2bAwFNKg3yPL1Gni/pLoM+DdoWoNmKrfcVcgquvEFOwZV/J6dE4RQLnBKl2Gwa 6FXK6ODMy2S9wZ/KVGFpEbx28ouLDbLUtDXC1J7DtsuJLwUQ60ca3Ol6tWLVjmHxp2tD2qz2iO2R 8BGNVfHOjMbIuOWUxgT4TFrtTkcyvX6YEjviClia/UE1K3HeeWTTrTJFSRz+Zfth8kqh6/SuZuMx 630VJq/5fAH8fA2qJa4/mCneJqLRWRXZVTShHlHPqoyqEu/g/Oqb2GIE3+CxZu3nMXjmJOW+EUEw Upw2fqD31cFz+OnLJM+7Xjf47Ci7GJwj9LY0PQaL+BtvwnJqNeqCB00ORWz2cDJkj4ZQxBYElIPW 7BesJrAB8zcEc1EIy9v6N3ST0bq6NEweMz88snO0FAsEHe+PKXnvBeo5RA43a10r6rvXvn5mQzy+ zsrtSO74LP2ZB7QYoSBEOSjKJGG5V2WeadCPFiDq30+2RjKYw1ihYCSGSVagAC9sMTZ4jdAIVHTN AAlt6XwUNeABWQkYYwlgyBP9n/cCceXXcEJ+DSfkQZLCAHlYKEgWHOVl5IiaUoIvkMyQHwLI/l2M FlJUBdOes42ghbYqlfJLkhEnY353wiJZCXkzv3tcYMH7tqQ1QMSytrCwcCEg1tDTz2GpCWkxpaLh tCAy6Sl7LVqjnayM8L/7LPcLs+Ks9EX7Q44vOh+KHq49IQg1fy2wS97l2BW9Ud7j2BP9Im15PbIU pWcsn7A9xzxn/wP9B/uS4z+dfN1RV+rRdrVe22SfFm628wW6WVaTaqpQa0ftMueRR9AV8rBqiss7 0A77q/KbsvlSx+bos5Znhf8tmH0WrxwNR6Mb6Q12VnTYXdaAFLZHbFF2GzNi2mYek4cdwy7Wbw+H I9FttKkh9gttCqFpJDNCuoLv0cckJN2OeUNg/WlJwj/dQDfEKRjLQ8wR9gE0EzmOK38lcjyfr7Vf wDUE1gCeWcQK6HzAD6sbfUS2I9rhdLlkfzQQ8ecxVEk3CbQlIgBSScfb0oXuSqStlypQIpY7CTXq VhGtRjE2LCLajRCNVEqNupApTdsFWVaEKkX55tEb+oAivSCKAosp3+9XBLEozUj0WQmdkk5L9KS0 ADEdn++wgpRAtIZqGNpQiUKBysv5o2S5jXkoj2bys3k6P9Fem0e3PBF7+COEtaemIXcRo8vL5GlY qwgetPGpi1YCw6vauvwwZTCKMOHIXV0k2962tmrRZry3raY0NMBFaSwH4NhJjoMElunpKQj5TDcS qagpyljFJmO2cWN7JZrBlhf+hnVMeBk7LERbOCbWRCgcNbtRWIwCEhwed9QaufeN6BDE2x1gs0AG VSXmYVmOcxGbpnXtjVAI9I/PwFXVi4HV1j/0S3wshe694sPdr79+dVMx4b9kpScVzKz83p8fXMlv intEu00NeJodSDbf++7UL3udkuQO06pK5zt/tfJvt8cKNiGRQB6XrxVdt3JqrF1BiYRD9MUuZzYc 7gs64iBp1mOEZceSxoM+u4avfBheEHzllljENfxzRGYgIjOQBDC7EQv/I7EwpDUIJQHQIqHw+dXf HCfRcfP3sHDg4X1olAtWqrvOx8U5AB7auvPuOwOTnAQP3kVWQ9pFUJKbBIsgLE5RXMNzZ/jsiBKB izJAj2QIL1IxQI8k+bzvAf51EjMCmfLkrG/Bd9bH+IizbFMZSr2j1llGvmPW3W1DPqT7hnwTvknf rO8I7shJ2QjX34SyETYdXwuU40viWIFCCavUGMZId6l0lmclNCShCWlSmpWOSGcls3TMexFsMeB7 vesCUMEmM/GfEZzyXmyyRhm3+8t9K/V6PmCLKoGMAznM977Tvb09THAIo3+xz0DPRIuwReYxagfz Lw0t4hsj1uYY8cH6HOTROkYGimvyvggPFB5fkaSgwTMuaqSXVqpuWuu1aa0XtOgx6LWpu6+b9Osm hNJNCKV7wA2/NrB23sCafhlYGwBX/qr7oe+AAMMMaOR0jZyuVUmOFTRUyYsoqpAbRbLVqyEYuEqM YOhapclxsh6+6iBjOMgYDkhoMcZQi43457PGGGoziY3Or/5aF6GrSjeOv4tpFOKlXn9h3cbNAKjU vuERHfoURtDWkT0j+0aYke1sX0lJtohcV4vZyOwogEYbH8fAankBPmsK7Tziek+1QergTzkpa6R8 jlgJ553WehceHo8ucmZueGQ7p5T6HITiHSoJoKoaMYI10qZVu8leN9nrHsDz+OOTRkh1tApuBGiu Gv4EUvkzOVqtjg6AjofGgTUOwpW3ydGBgbHRBuM4zm9lfOXki6dAkTkv1usglDH1HrVuGR59htq0 +hq1EX8L+Ftcfe14QPEr2Hg3PmNBPVTmTo39p5eZwSQ+Bta2ZkWzY9ioVrMRZZ5+d66pmo2UcEUX mwaykb7+Jkc24sN29Vxcy0aK84x1Lt6djWzCFf2S+Eh6sHs4MtLLZ6uDei2b4Sku2bd9BzyYZIsk iBxrMnN9m0pFxSeMYfQpOxKxooom1aMqrc6jim6vZvNaor1YRZPVo1W6Cm3ewR3diYGB6ODQID0z ODtIU4PyID2I+fqE21senBgdm6evxDprnzKPdu8nkPR8Tss5sMvPGEXXZYBNIT0af+rk3yBRYGuZ mNR5i33NZm9KSHZrMp5KSLEQstmbbMmLbXZsssNrlCG5pWqY7P+N4d7QJcSrznG+C3LkfDN3kUX/ HgTbioZ2O3PXt27/mOe6e7dcOhXzWoW29Stdrs6YTzAF09srNwzQtKdj00ppoCaaYy1b2yrbcv7S lpXO+roAwblpO3Jr9Bu77anm3btu2bJlpONjK3u3q15s4PvkuGMI3T2Z1yubRW1lC7H6sVa6AreV 9HBLdcVzZVswkQh2jqCrHmhZw8MSRTH/F0uyVvq8JKsQSVYkeLhkLNHl7d44iIQ87MXDiSxPRFLj zRdEHvBe4l5rrHaR/jbt1kjh9IIHOgXdvVSYnBwmA4XJEOEs8a5lCXDOrgHkrAHRSOWtxkoQLNsE OCNLhehEEQSJpUQss9I6K7wkFF7r0mT423RLwp5Yx/0/9r40PI7iWrSqe5ae7ll69u5ZezT7Lmk0 ske20Rjvi7DAC5axsIUkbIEtyVowBox1c6+3hMS+CUnYgknuJUDygs1mDIRgEiWXfMHgl0vIJfdx k/c+hxt/sYjDM4QEJL1T1TOyzPJCfrzvu+/7pNJUna6urvXUqVNVp055MqqUWD6v6m6hsmKlS1nj afRDJAREVBfZLpKNa/MuujpP17/rKEwzUKfGb4lwdPTkKKXgKNXgXFT8wkW9XBzxcrmKDchPQ/qp h5++9NOCUgmNKrlIEmJCQiSTxYbPutgGvGlTsZwqckXS/2uLrcXNxf7i4aI2q8FlCo/A07Gi7ljx dJE5VsSbweNkkfVzrmTAoi68JZOByPIaLhkwLw/7k4GwuvBWF0/Nrw3ULfShcH2BljgSDlssZt7t iugPc/gYhy1cP3eEe5XTcGThzZss+COpYLI1uZlotRpJHk4eS7IoKSYZqozBAB0+ublBXXxLf/bF N5skszpNVGbdPqzVSVpPtRuryhTbqeg0XXv71JU3ojRxmudFJqCAV3zzyyu2KS6zUHf5xBx7ucBr 5rfsvEkwk47oWFxnCVb74dgPV6ybe9vErquDMl1zs6zCO3fv+NyEv93lh562pAuveXCph65cANE+ wz4D/cyC/Iyx0tN8wAaqwo2UnVPndCIRhjZ6NKTvkJcEKNuJp4YG07ijnCBGkToyqiJs6qrDReEK A3lPwnnIx16CUx6Ng2KcwyhSDk6k7JuG8gEE1GgCRqMqJEGHIoJcMBah6jbsItuIEz/kOu76Mf6p YdT/hkFn+08eLzUscl3t3IvvMBy0vOHVB8v1RQ0VjjgSxD9x/tTDlIN4GVfNjY2q9kwD/78KUFGD TxO7VbNZ0685rDmm0WnOGcmGW9l4BKY4U3IBRC6YLMymVxxLrF5xrPXKDY8ZA8seC2qWXbVh/fNE Eppc3koueSVD4IL130ceth5pkIOtPyue9U57hNGh7aLOh0bst0XNMSbqi/FRXcxqcSjIjz0KdhkA kvQA2U2igr0sWE7BrSBZC1Zlzlz9o5LAgGuAdXjB+rJ1mBnW3cLfYr7FdrNrWBr2ce1tFTXWBp9o LXnh5yQbNYK6UUOWzCpqPuk2TGOjm+zWOmyVDRcGnb79xpte3fPqLVt2v7y6eOPlRz7XcXvPEvbo /fuP3vrhyINf+N7tf945v/n+216a+I8HfnThjs1E9vbPE8vZZwHX4qjE1FRwLTmHytvX8ynikO0A siNil5HCJu2UBtsVKm6vkL2NKr9G6a4yJYWrsIm0TWPWeZ5VFTGXBWA/clFzY5tOT9fHDIhSYYQB O4HCAuc2RgnuJWK5J8WfAGHNXyLd9gyqn/zwKYKI9TzBSSqixvNzmiB3FG/tlEbaFXUMoKtXb5e9 lFlTIFRCZ44jLJshMwLJDckAldEVVcqIp6R/TlfEf9IEq2/n5xBsLYnLxGvEg1bNvgyek2mesyJz TeYG6w2ZQW6XdVfmH7gH9We5PxtMtXPWF9oatjVoynNwnmMTSZsd2Cp5X40dmKt4GMVDq+IBtJCx pROsJic2YpITRk/yJEvm+rogf5hnNvMj/FGe5X+vMHQJz6sorURsdSSEibinKuKpDW1uIgK9dDJD FC1WZHkJOSQrsO6pFVjWTPTYzlUVmOaLehMXbYgZY7XRor5ewXkTWAVDo4LrhJzyEQWmdB8RUJCN FpxVkQF1OzBeZWAKrml7ElqVYJJjJBVGh8Ge2JJDqz6/cceB/u8sb0zUu0srJhR5VtzuFMMBKYob DObtq7suu3JjeX1tPsKWBl7f1bHtH14bu3eP05KdOHttIRCNYpdQ18Ve11YrmfdMfKcv3LT+iuuf +fmOKyQb2adYOLFcgwCX/SiNX6vgsidGSWXM6aKaBWAqHajMpc1kTkIlMyv6RCgfYiaLwJSPIfpu qPCL9ll16lwW9X6dJWALRyVdss0m6M0q3gDKNE+fPJ+kGKsizUlvipBQb4rgoTdFcNBj8QTWiSzO UpZbkeKtWaacHcn+c+KBrKbWUxtqTs1OrxLLnnJoVWpper2l1dMWaA1tSG1K94nXea4L9aVuE3d4 9gR2hPak93q+mL7P8jXPfYGvhe5K3Z9+2PVtz3d930s/4/oB5OBX6XPpD9IpJTsYHUwcsn/d/nXH yax+tR3XcGaYQccrM2ivZAkE2bAniUmxwlG/pNfrzF4vCgbNBO3yKIgPY2YzHsFHMYs5Ot//faxO dLY6mRecrzr/4GSdVBLAuSBTlZ0kp9jH0+0DqtrIPJ1gjzWPE3y0VTW4SpGE3R1xxxSUsIMVdYUV HHcQEcrq2i+RBd4xMDtNxIHTF6fiFV2gFelJRPnvWWxlk4wKSzayN0qF5RP19tl+h3TNgWV7/zt2 /Ki0OdZU/Pt4V3P/A/80OGcje/SD69fX+6JRUSgB67tt1Ts/O4ujiuKLjOfxozBe/+DFZ04WkLpj zDwNmJXAT1VlJVOURuqCbmucMqdxKYgrU/npM99gla8NVjnSIKFGVEIiSCfmQcrCBumMlwbEIiu5 ZLKYK6EYoJ15VbwvvifOxhN6ycgCsTpFZrhjML/9GFdKdrnES7d7wyS6GHzbZ9hjYAwQgaSDnFJC aaUzWJLHv1BCGSQrAgRfCUDlrYLBVHLaCqc4SuWt2qd4SG+5D6Zvlnqm3lJmypbPafTlFN6UwkFC 5eh8cV84HlfmxwLxhYgXUlaHImKNNEJ2IkQjNraxLNLDjHCTDpd1WJcLpnAKWSPBYFDBI8phhUGK CDPEk8ppRatsTn576gSQOscbOLNjoKLUZ2Cs3Vo5VYembTkNAH8HA6ezsSoXXp11uac2Ui9Z8Fs5 uGvW0oZI+GqnzZmttZsuv2wivbhG5rWmsCcY57GTPfrKKwsy8cZFjuS1E8tWxoF5i7jofKrzgXk+ wsABvnRNnmF+AfhSp2mo4Eu8QPGlUCbcGYPpXimme6XY4vVwcSPxj4csVfJjIQNpPXlvqdNzcUtI Y0tr8S4t3qbF2mgeY5zSyzsDuDOAA1HFgzd7+j2Mxyag5tH2duCB8uCC005EswmKAN936rVT4mvq SDqFHfUhS5zTpFwBW07LpOr0ajSybYUW36i9Vctooyn9wgDuCgwFmEDUJmCSw3fKHoItFkuh3sOZ 6SwmbiNOPF6or4yYo6o7SuRm28lPHB1tbxZH6amrykmYpCEjZxibLVcWSpmEUJIcbcYNsXvFOyNa Xs8n+OTmQn9hpKCzFE5gpbwfyOXPTD8zj0ZGo78Mvx55I/OW5q3wW5GzGcHWnGnP9GZ3Zw7hQ8wh dsQ54hnxjvgOZg/lTESzCc8ajDofn3mp5qdhzse6HDafyy8nvZm7DXfz9ypfCX8lItjSpkRmeWZV YVPh5uTNmX3mh8NHC79j3/IZk1xdAD3PBHAQ5+nlB+nH0fO5E9hTtqakgPy8N+AJerDoUaDmyEv5 eRd5WWOzRcImQWOJU0cbwP+CcvlUHUKkUj23y7JEDnA4XHlSsczLNoxtRBTpD0TSjHWUhX5y30y/ 5bCFtZzAjWU57pFzQQ5zmSNxvJkeN2XJ2VMm/ixWUD1WHltR7RxEfwidHI0TKdjJEG5vK+WBr3x8 EgNIrxS6QNRp0/3aM9MUiwBXysM8LWISHCaTUFUz0qbqGWkfuETTCICV06g5xWBqQOk2VZNWIhlU RKtOH7SGfFiX5HyIXCuB9AmtD1cJO5l7Ea0VH+jfE9+zfpDQtLfhAapMZH1ZPoKPMEfYI8I9psPO w57D3sO+u2u+Hj6SNQJ7nCayTERGqyzkw/nIFzL3Ru7NaNvJ/a5la0KRS4aEXMJlvsTAz6sK5Hro Pj5fyoFXhv4MJaMYsDWbFWIRNT7eEnXkUkQVaw6rjpEoyLOXMhXtA4/b1LgsNkjCBknYShnFRr45 X7ZYIJilxIomSMdEIjhftpkgHROEgZ9kpb+PHtG79A+rZ/aI8pTKSOZ2ud3V8yxER7m1UD00FYlP V5zCHA7Fdm5cvE4Jbvryz54fXrMt5HSbQiHf/dcturpj4j+y2XtvbWwpWEWbkT068dJXblienZ1I 5pZ0fmv33QHeg5fc8aUrS4uuPdxUunrHXW6LWSJXb0/+kZmreRF58XhVgthftgEN89MtdMFIF2CM TjvW2ilopwOZvSotZa/uq9tJXaiKMgQuY3E5NER0GGEdjGTjp0/lx0YrY9ib1VN4F+mT7FblB6nt nAZ7ya4nZaeqgEz4Obo90S9gweLFzh4HXubANLkyoCKkLXixlk4OtHQxRUtHQa1dXT7S0ZzS8c9e 3eGz2/2+aYsp9BxA8/jp9vaT4ilxtL0q0wDN6n0GmSAD842lTXgTwzT777beLb/gfMF1Qv6drD/i xwc9eJVxlWmTcZPpXUmrk5xSXGJdTkn2sJhYDu8DmHXWVnLL1jIM1hmLJNOuV52/pjxWt8P7MhLI vl9GgcEzl/cf8zN+hLFGo404Wu14xI6JkrZj9pP20/bf2HX2zb7vHqxODcbVI7LtF9qJYOQFclJ2 /Iy6kwevzmAruRGIcGeqLm/C8w9QmaSCM2ylPNWsAuW4YkR2uJHeq7L89dcLidBl1nh4ZGFufeof Zw1m3UnNixP/unj80bbLkonrOgubOpmtIVfP0lg3vbd98gw7zt6JokxtBatccbqGyFXYckFJVHYE KvyQEqjMMM+oMhmKhwb02Ojug62KbrbqXBSAC1RsyBapTj3NUlQnKGZJ58+YBT2RzH+KTD05HuXf TBPpcZWFP1cVzVD1NL+Zns5HXa1XjyywHC8ogmSORN0QqxqlUOGJeXUPjO6KKR66I+ahLJaHp+sq No6LKRTzFJ26KxCzkV08EsRWlRIiAMU9my0em77uD5ZI1xuJdZIKWAASUkYM+EF6HqWI42RWocTJ +HAsrmkQZgWblKXBpYrWw9lXkZlnaFUgGg9zcTxfH+AWKkLUz53Ai8p2HkWjMCSR8ph5gReEED0u ZUbHMLbgfnwEv4o1mIrI2WRPxGZrtR+2MyNgHbOzqmZAFe0A6WI/3HMpnwZD0dzKDXvqNQ5U+SnJ +RSnRkRAvD6L1Wfx+JBo9Yp+H6ILdeTgFG5PVzfi1HNRVTwEvk1fDFWw00r2d9lOS8gVjJsn3s7e dNuilh0Z36yleH5bc3r7itIG9s7xXxyhp6F+OHJ52x0j+O759V4cHb93pLVxJaO/YhYTJTt2gKNj gKMK82JVi40BeWw6eqeUFX4K/Bj2fz2GiBDF2LlzzXkYEfIX19TqJN7g5QyGmhB8Jzjo4q/DrrPS +Z/VpmOoD/RvhQIKiedU+uK/Kmqcf/OUSE/VlQ221fx66RqZlalK1mINGYU6nEWH7PCEDTV8yKrY IpIiK54mQ4lvshF1yk2e5dwyw0J+kbRIXubp4e7j7jZ8w3OP90jNI+hh7kHDt+RveR72/oB7ynCc Py49LT/rec57suYX0nv8e9IHnuwRA66hMmabG6ibrlPdQFJ1lyxR3XhcdcNh1bVaqVsuy74GS81t iNzV1q+9Tfk77V7roRpDE9fAN0gl7090J0P/5tEf4A9K+2V2lm2pxNglR8COvEoA2XhrAHrBvnLG 4JEVSZZrDbzDYOC9Hk/EwAHE6XVajYYDlsxuA7YJ6TyyIJ3AMDxt4rHIR/gj/HH+NV7L7zZ4CRKL ZV3+Ae4Z7hXovbsN8rCHKEZQyGWiT1hsDYaKEDqVIagvEudpYxEZTsJ06QR+4bhYg0dq1NqAUMQ9 brE3hAhhlcV0mmhJJ/TCMy69RVR+SBc8Y8QdkMamFH6IY4S67q8o+pjSN/MJ6mZUhTI7qhwBRf00 JuLbT/GKy9QMxOt3T4NriAhELO83wKXwRCyZt5c4BdgU+FWkH7B6uqiqvcNup0sxVJ9HRfUMOfAR t+KjvnjS+YvX3ZxQ04DTDY6wb+K55MQzrkTQWs/eGY0p4doJHWOa7TcbLEI0qrEGFn/4NqttzIsG jsyNJ89on4TekmFPVXpLLBSwmpkMWeQzI0NM4jSJaFBn0RE0b27O592l6Rqfqot6MRg9F1LpSB+d UlBbossKnGpLMYMGJWjkuzI4g4ajOCoMJ3BCUGPPZLKhUC5bWZcmaTW3NxNRUJqYKo5Da9X7mI2q AfE1F11xmGBao3EltynXY+jPnY2eTbwffT9hJAEetxdpuJe8wYZQLpfsavTLctAbFnMaPuaPZWKl 2Fr3Q+6HpIdinBCdFZkVX4VW4hb9Mm5JZHG8JdGSPKAfEUesX4weSBxIjuTuEe8kgaPPic9En0m8 kHsp+lLijegbidO5INJq9Dqnxm2I6uOGhC5ZdC8QF1hbtVfp10lXJQ8Kh8QD0kH5YPhA9EBsJOfe b9jn3h9jTYY2vFPcadVAn4DWjEZ5rIdeIbqtAVEJhwIKSmYCyMKbA5agHAjAtH7fE0Rw8MTk7nJZ ikYUTs8Z9JFkwpFMJgAbovFazuDgOANwJ7IzwkcdPB8NRyK1kuyQJDkZC8swWYf+x0M7PIfPQScK 4HNPBLHFSp5EZAbeBEZBUYQJvIIY4olRBoJAJ5WewzegKOLwt8uWRBkyG4kkBOVDSzcPc6rHnjyJ upNhcmrGWfbmW2X8gIyfl1+Vfw1U78uRPHRv79OKJYpFaPTKaZHoc1hEMeSEHm4s8/lNMVyOjZCb M/C5Jw2743nuWejmHLBTvIISeCRxntykAmM/fJp4QE8XVFuTeITcpSImlWQ5eSx5Mnk6qU9uzk5x TWNkR1n2jI2fgUnPjkrfBi8PeMBr6YwHWCnyq15l51ElowiLVVVKosJj6jyL6KGiVIDISnFVcsBN 9/nMeqiIFipVBRBV70fWyIBcEFoRIwrhycSEHFiyEzrhJ/rgpxwHcc4/7i5FieOkT485S1ObFSrl 0KmEgyqjUslGlZBUnnGYVemICY/AMDz64wYp7pqLn1wacHCnX3TESzh0dXLileRvJ96NTvzKP3su 0BNNwBfMjP8Rf2//XLeZjUZZtxh2OMffwR80KvYAE42aej78PbNs/GmWWVYwEZ7RixD7n0BhZrPv VHhGY4yXGmKaLIKo8kBnnszaRWY2EXFE2YBVJTT5PKEyJ6ml7imQoXS/bRGPD5kOmQ9Z98f2N7wu vO7+VfxXBYMlF+OjQsQ4wA8Lb9XrfU05y4ZGTa5Z2yw2W2fHmhOlhtqmZcIqcZV1cWBZbGViRUO5 aZ28LtraNKzfI+wR91j3uPa4v6o/Ih6xPiQ9FwuYtRbRYrVkgmLQGswk+aQ738SLTWsNGxpbm6qy iBHI967ZeDYpyE15nM/FGiReg3KkDIGc31/K5ZpKVYKWzzc30ysqCUU7qdqkTN+KQd90u1zxhoYi LxiNBWA/9Ho51lBsKBSjtkOuvBVbi8CWuoz+3XJrAAfy0b7wnjATPhTGYTmay5UK2XeSyXihFWp7 dxEXtVp9VNbrI8Woo1iMGl3xeG3B6CgUjNDyksHoLsSjsjA7H5N41tigL1p82BeElsjnSDPAAG61 klE5p8nibDYQ8PNGYDGf6nNhVy56ApufUGQsE7pqFItl+Zj8G/m8rCEeZDSWn2MaUQHp8ZbHi7k4 0IMnUAEXnmNeRCXUxLQ8ETp1UFX4doFIrband4xdqF4j2V4dbcmBfZHym+Sy0xKd2FTUplLNb+aK Cjgs2Uq789I58Uw7qeMztKJtpfZ8O/iI9FG87RxAek6ca5673yzO3T06SpxRblQPDge+VIaxnSo7 qYouCtCneCKh+P7ThpKbrDII5K5vcJ1kkmrwWZtNZa9IFXM9AQ/ELdvd5mYt2dPUE1VxjQQiV0I+ DW4yYSGxnT9uKUUVCxnw/+1xCzlo/Btw6oneIBO8MFEfsjoRU8jPCn5W8h3R4k+YhMdtqmNVWQav qSRCBVjh5y7bSqJoKVnhlyk7iep/QhVcqmMjQ6GTrH2cL9udpUbOWUrUOkpJ+Fk5F5G9hMhcpWTZ Cj9nqZ78IGU3SR1+tmlCmR//++iKCL7kBSVD1YUQKsFZ5V/09imJTeBr4pdc9zmL8DlefDQZCguu +SuW1sRwY12kbu3uM2uWliZas7K9vO8rC7PZiV9EvLENJx9dfuU8IEw+t1Qv1mzd2ulx+oEsSTUD D02c2FXHRiIOs9vdPjp6jVWKM5GI1uHfOfnhtllEImZiMXsBKFP91N4pcKfpFItujuO4H2YMdJ3X QQiTlYJEEeZxhoIMAespWH+iOplIj6XPgWnOn2qvkqwKpQgY0sjvsDK31ON6ZAPyEL6FpGFxOAoI NRSmmJ4320dhXkhpg7pEf0xcsWb988g7+T6SJ88jDxB6XqyIgH3XQE4EmtNfTTL2hpyrq/HvtXt1 jMGgtXEy5zGkHZ6YIWKLeGLp2bjRVvQusW01bOV75Os9nd6tmZu5XfwueadnyHtz5iB/UL4L3WX4 uudr6efQ6Ybf6sLAk6TTmVSKx5RTlwl7n6mvsPcxTpE9ntoU74AAmXSaMvbpFHyS8hg0PJcBVwZO gwtXWHyqbs8MuY3nwyW/pcHt9siEW/Ae4vGv+fNks7Sf/wPP8rubDasMmwysYTdHDkL4069byIGG IwqjHNqUwflMc4bJyIWGR4jYGBEZax9oOdO+48z4hXaiJWC8IirWMn4mXbnwqKp1mZs2cleu8P7U gfri4Ix3ENKQ/jRWnPLiummHGchMdhZWNUAa8Xed2Wzo16eseq4mjVPRhGSQJ77QePTKOStn1YZK CT6wJDJ/4mlLSBbdBcDhuD++aKIe/yWZsBkEEzDrUsjc/GHv3gMLM6mCy3JZ2xHmiWAubBSNiEEL 2C3sau2NyIWy6HPlBEZmjeSOeoOJGs4qJMo1x93WsnAcuVnE5qG6LVSHGzkinSpbvE0PQFf9kcUc NI+YWTPxM2iajjqwQ87lT+ChJ0LkznhSuy1j4+RuwPH2SsU2t9BrqccuXiZXUcSGnVPnRwvTjnpE P9kbL16/kjeYTBlbct7yWQu27WWu6S4LglHIuJLzWmZffsM+7Y3JXNecsMlsmZepXTS0tut7sVjT xst8ZrM4J123dGBtz/fQ5GS1FjCLRhHS/BOCMhMVpAzCTIpNwjyqnfAgL7Ld+B2oKw9aVfYbZMBI rWhwoOOmsoP1QeVomyzuoHuEyDDj1BOi7PV9H6dQCP0cz1NvmG0Zbx+7iFqVghP8sBcbL+6SV1S1 VRRmvb0l6hGMZsHmsSYuC6aaFtzYNoftzs8rxopBi0VvmJut98V2rLmpg2hoWjAxyq5GLyE3yqMv lOfd570v90j+RP6l/Nm87hbzsPvz5r1ujST74ghrLCEuZZSOp8oRAR23lY1CXbOvqTWLLdlgdiTL ZmkTPwD05UeaJosz6Bxxsk5SLotcWze9cUmh3msn8gbkAroz8F8VoKi26Q5SvkuLV2lG7af4D3Y3 84KJd7lcqbktsy6/cT/uvLqF540ml9sKTd24cNveidFUqX0eNCTHzU3XLh24uufRSCrbPSdsNnHc ZenaxcPQ2KTV6MlF9ihyYaW6NOOgcuxOarscTpdey3ES54fppV5yV2TZmWnreNMl2t/7qES75L7k GB/KF9LWQvObp0RVrv2JwxKmZ+fk+vqGfumodF5iFalVYspgbZYOSxqpcn5Pqpzfkyrn9+hXUdnT cFHSfXnYGTfNdwScC016F9JTWXcTjlAhd5mczaNC7oeN540MkXRnjI+7KzLuRCBqTF18a55rK116 Ho8cxyNy7vhTjuDd6vno0Tv26CcduEN48lkcxQ/jf0Uskp5HDPs0wiy5J/HEY1qcFwmCQJKhYgg/ PGHDb+Poo5VvtN6//o3W+5cj2o6L32D0ad/89mI6aOJZvPjiN9xn+IZDf3qWm/aN+Bm+EdEfnhWr 35BTh7cDxgXRFWWTL1D2LwzokYD9LOHDykHe2iBYNRZ/HEWczpASJFKQeBW3ievjJjkNl4emondK A5V4czSNNl3bLjW3vOuBlKJTx+8rWhsv3iGhiiLefsW1359Xv7C2RvI7s3XKPIdgMBZog6Wd/7Lr kNNbrCmYDMnMlZnD5JBbE200+JtTMXdhxzSzDn+dmrcYO9M8zbzEfunjRrNYs1j7eb1P/wb3ZcOt /Gqh1bjdOKEac8ayzPJL8TXrXbbfObqdosvhcrgn3ZNy/aXGm/dd6R8JnFXeqPFGtkQn4xsSt6aO pe/Psfmna8fqVxdGGu5q/MvsaGnnHPO85uY7yr///8nM753/d2B+/unm8o1/zSywz5gZM2NmzN9k sv9PzJIZM2P+C5qOBbcu+OqMmTEzZsbMmBkzY2bMjJkxM2bGzJi/2YzNmBkzY2bMfwVD96sw/F8A +0o8gnToesSiyOQhsGdN/jvYTdSeO/kkiiAW/CPg7we7aXIj2HMnF4LdNrkV7A0U3kjt4xAmiSwQ Joms1I5AmALE8CTYFnhbAH9iRyB8EeLcC3YTxF+EOIm9cfJRNAvC/zvYFvh2FhIh5Cz4isARiHMW qqdvF07uAHsxtZdSe+XkCbCvovBaCq+j8HoKb6DwRrCbaPxNEP9CsEVItwniJ3AE8tYEMW8Eeym1 V0J+miBOAq+l8Hpqb4Scz6XlmossE++DLcK3c5GVwhEKL5wsgL2U2ishlbkQD4FXQ1pz0RoaZj21 28B/GVoGuVqGjqMdaC3k7VGwxclfgm2Fb9ei5fB2Lbxdidrg7a1gW8HeQOENFN5I4Y0UPg552wr2 Ovj2OLoavj0OrbMV2r2J+QEitwqQvxuozVJsCNAnAjPIjKswiwbw7AqsmRZGiyR8SwXWoRr8nQqs R69MheFQLXq0AhvQPvxyBTYx9zBXEfyjf0XNuQqMkUUbqsAM0mu/WYFZVNIeqMCaaWG0yKh9pALr kFX7YgXWoy1TYTgkaRdUYANaoP15BTbhFp0TYsYaFtIy6q+jsBZgUT9AYR31/xyF9dT/SxTmKHw/ hQ2VOlRhtQ5VWK1DFVbrUIU108KodajCah2qsFqHKqzWoQqrdajCah0SmJ+Wf4HmTQ1vnOZvpvAP KEzu/DHrX6GwHWCb/n9Q2DEtvJPGo8Kuaf4y/fZtCntpGDVO/7QwwWlwhIb/kMIpAnM8hbMUlgjM Tcs/Ny0t4zR/Y7UsjyAF1SNyncNsgNagragb3BbUh3rhN4R2oX7qswCeBgAmdgf499AQOXgzH20D o6CrwG8LfD+EBulTN7jdEPomsLsg5Bp4v536KugKcHfSUH3g1wExKfCWvOmA3xBNowvCkHcD6Ebw 6wN6+rfnj8TaS2NUv1sLTz3wRHKkoNUAddAnNeVe8M3TGBQa91aafwV1wtMwvCX56qGhcx/LQdNf LR+pkS0QzzZapia0jsY+OJXTIsRaC7aCEhB7D6Q6AG8GacmHgO5fjF+N/WLcrVCSFnj/8VpZMwUt pPWyk9bHFnheBbFeT1Mhb7NTtdEL+euGr9Q6HqCtQmLNgM86Gn6oUkMraTlIK5GaUVAdKsEoVA9U lNSWQvNG4hmmeKC2gdrG19MYh2idk+d+WhPbactU2+Y6+m213RZBy60ETFO/HZj2pp/WUhek0klj VNt7J02rE+xPTld9JmE7obzDtBRdNGwf2F30fT9tqV1TmKGm1VOJobMSl1p60g+Uj5W8j9bmLtqi PdCCCsXo66bS+qR89X4s7s9eSxdj75pq5wGKMSrmdk71i08u/cW+cmm+5kyrA1IStSxDNL1qjyPx q2XtAp+dtOR9tBd/cknVmu64pFa7Kz3vo/2P1OoQhBumX5Lc3jSFuWo8JOQ2CPF/baNHlPra2tnK mq3dSktfb9/Qrv5uZUHfQH/fQMdQT19vTpm/bZtyVc+WrUODylXdg90DN3V35db0bO8eVK7o3qlc 1be9o1fpGVQ6lKGBjq7u7R0DNyp9139qfEpPrzIE79b29gx1dymrhzqGIKaO3q5834DSB28GlM6+ 4d6hgZ7uwVw1gqaPpndV95bhbR0DTeu6BwZJpMVcbVFJtPR0DvQN9l0/lKThITgN3bq6Zc1UVtYQ a+FAx86e3i3Kquuv7+nsVrIkG73bundBjgd6Bvt6M8q6ns4hyNDKjoGu7t4hpa5UqG/rG1a2d+xS hge7oQRQ4uv74E3HoNLfPbC9Z4iU5rpdtGyL1q6cD28H6EP/QF/XcOcQKffOrT2dW6d9C25Pb+e2 4S74dKhP6eoZ7N8GCUBlwFc9EKATQkHyOUWpJt7Xu22XkuhJKt3bryNfXYyrtxr6E7NEg3eRMg90 D0LldpK2mJY8bZVKXHNoDhI9kMpQ93bScAM9kGpX387ebX0d0xOFTHeoWYVmm2q/vuGh/uEhpav7 JlK5EGZr97b+j5QIqHUf7bcdgKG90EP6SK/FJsDKG+D5LKXY1fdVGtyl0lb2HvYx9nn2Bfg9wz7L /rdpcZHQPVPP/5PG3X1JWt2XxEbj0wQ0dZoVmiWaeWCXIHQH9CTSR9VRYys+hr8J7CShHPMh/EBl 1Ouo8LZoMgRhP/mPRYSLsyI8OUn4C4RamLfqGcTeidDlWu1KeFZU1K7+TcIfap6cWNNyxVW1tQjt q8ygiC5P/DJ+DWJbDkzrHQgzX2TuRixwZ/cAfC9zL8D3MfcB/A0GeEbmCHMe4D8y7wP8ZxZywNpY G2JZO7sY4CXsCoBXsrcDvIfdgxh2hIU5Gvsu+yHA45pB4J2GNEOI1QxrdgF8iwb4R82tmn8E+Mua rwB8p+ZOgL+q+SrAX9NmENZmtfWI1Ra0BYAbtHMAnqtbiLBukQ7S0q3UtQB8he5qgNfr1gPcprsG 4I26IYCHdcMA36TbCfDNur2I0e3T7Qf4gO4gwJ/X/zPC+gf1DyJW/239UwAf5+Yjhrucuw+x3De4 t4Gj+wN3AeB3DRCzoc2wE7GGmwXglAVeMCFWMAsJgJMCzBCFBuEhgB8WjgH8mAC8vPBDYRTgHws/ A/hl4RRihFeE3wF8VjgH/mPCOwD/b+FdgN8T3gP4T8KfAH5f+DPAfxGgZY3I+EPgHv8Pb98DFWVy 7VnfB3Q3f3Ucgso4SozDOA5jHDSEMTyOMQxxoW2cDjbdPQwiNARb6HGAgabpfzT9jw4xxueyHo7x uK7rMx6fy7I81ufxeHyOwxrjuEadCXEcjjHqc42HNcbHM8YH+7v1fV/TMmNm9p133unzq7pVX9Wt W/feulVfNa0fpIyA/l8pfwD9IOWPTEx5mDqLCamzU3ECTZ2fuhGWjJftKbKvcw1LupW0KusT88Jb i6ZcA11pjBrMSGPWVIHerKlFWq/ZhrRN04HUoXHiqUfThdSnwTuEplvTDdqvCYIOaXpARzQ/Ar0D uiItPZB1IkIbr4LOSf4m5rIieQWf713Qv0/+PZ/LGaQfpnyIGY1gXjSLryHNSM3AXOamzgU9j+Yl zyeJ9QknWMLm5s01LKu2o7mRFf6wuW4r0zXU1TSzqsbNrTas7CQmbNQXZbF0Rn/JL0IbyTKFdyyu G8ZXCr1npcaUBbyrpEXLAlYVOGnL12WxDLmFiLeWWTIdh6ez2XNb65ptrIGnNp628tRBWxTz8jTM 0x087ePpYZ5e4OmNpq1NW9kETycpFVQ8TeNpBk8XyvP/olSkfz8jJhcwK3pTTECuhrxJmH0K5kX/ P+pzbA57Hnr5GmY0l81j81kme4EtYC/iPW4Rdu0v7vdFdQgvXFPT+Szwf1ZOJ+hKxK9GRDQn87Ne tovtYQfYETbETrAz7Dy7wq6xm+wee8ieCPFCipApLBXyhCJBK5QLlUKz0CfsFQ4KR4Vh4aQwIlwQ PgFnDROECEYXmPCcDjIifyGf0f/lJbwYlvJFjdJayJLsLqwKSvm3jFKeNyzl394l5W+6pby4Xsq/ XyLlukMsHsoVynKZiq6a3olnKjiQsKlRGn9zNkmD/LFUrsmW8zVyPizllr28XXz9cP25+rH6B1Kp YWlDQcOGBotU2pKxZdmWwi16qWSNWPdaB60jUv+tk1LeeFfKm87wVhrbXtug7axtzPbw3aR3s97N 47WzWnJa1rSUtzS0OFt2tBxoOdZyvuV6y8NWTeuC1hWtRZLE78+mFHmexPH9Qilvmyfl7Topt5+W 2jny5LyQe5zgaGNC2nGupWp2DtYTueXKhXrBKYyITFwt2kWfuJt/9ouHxOP4XBTH4+Lj5iAtiNsZ tztuJO5afIY4Hr8ivjheG38hYU1CSUJrgjthNGFMtUSlR7TerzqvuoHPHfVy9Tb1Yc0CTa6mQGPV 9GpGNNc0DxKzEh2JQ0nLks4k3U3WJM9Jnpe8OLkyOZg8lHwu+WFKbkp5SlWKP2V/ytmUx6nxqXmp xlR36lDqg7SUtMK0ojRdWmPa9rQ98G26NaQ7wzfoTg0omBoS/jD1E+FPwJ+nfiIKQOLUp2LS1JA4 a2qI/4tIQ1gZcbzfi+yNyUf8VpHuFOlGke4T6TaR7hLj+F0i3STSPaKa37d9G8/eoNs61BRMrUTb n6BtEfRJT+mOkW4Y6X4xgd8vvkF3d3T7BtDt4hx++0d3i3SzSPeKL071s4V0x4mWdLdIN4t0r0i3 inSnSDeKdJ9It4l0l0g3iXSPmCZxgvycE/IXwW0h3YqCLoIU6wAtZNCjvBG5EahEndwTvej2ke4e X4TsC+m2FU/p/pFuH+nukW4e6d6Rbh3pznGWNEs+5ovymEXoWST3XMnvG+m2ke4a6aaR7hnplpHu GEV+x0g3jAn8hpHuF+l2sYTXain2THXy+0OB/R3mEc9vEekOkd8ggk4QX5taKeYBWuCtSY9YDr5q 9EtCvyThEdMKf5r8AJZPE4XJD8RM6CsBvrAXNR/BF/bCD/rhB/0sjmpRqkepHnES/iDkTB0RXps6 IiYAiVOLxKTJX4izgIypFhF6FZdMtbCvoVUJWs0Vlk+tFL45ZRBen3pBWAn6T5MDGIVh3AFwKBFT gdmQcg488HlgHpAJvDBVJb4IZOHZyyi/ghkIJBdidRz3pkVfSZIEao0Wn6JFC/qvxUzWsjT0bUHf Fsg3BPmGIN8Q5BtCyxa0PAiZhsS5wHxgEZANvAqrqsDvlzTyzFG5tRZBv4ugs2LMsRqaxHlRIG/N ivHnYtmf98Aj9oDTp5DjU8jRAjlahBXA68BKgNtpqhK8ysHrG3wWqcBsyPgckAErzYNcsB90NYQ5 H4O+WjDvY+JLKC8FXkF5GeReIPvkY0hAUoqQoBgSFP+rLZUx9fpftJYInZ2Ezk6yJPB2gbcLvF3g 7QIfFzT7Kdq70MqF9i60dKGP4nkZJK8sW8m/rRdBx5+x58BzGDyHwXMYNrKC7zB4DIPHAOY2DB4D kHEYfELg8yG0Oww+5AnD4DMMeYdZMriMg8tlcLkMDuPgMA5/uYyWl8XFQDbKryB/dWqcJYL3uJiO ec9Dnjn1j+A7Dr6/Eb+BuqXAMnhJ0ud8UvFF8kOSYDG36xBveTlm9MtoGTvyZXnky+Sbk7cQiW6x n0952OGpj9ggIGAV9eP0NDylFb+Llb8Oui8FtCivB3RTHkSPX4gVeGaeuiW+PbVb3AS6AflW5I1o 2wTYpgbZbHE1WhRODYpr8ORNzu0BuD0At1vgdgzcfiuWof4t9ChHO9PUCbEK5To8b4I0aeDgieEw KPc0x/T6a/Tq572a8Oxd4D30XICVNR8+PT92duD2dXDDzNhKcKsXi9F6HepLkZtQNoOuxChVoDdN WcQa0HWg65H/EGhAXyskagL9PvI2wI7ROxAJEzjX9Wy+WIF8E/LNjDz+u6DenLrFkmV90mgfYR6f YR6/g/z3+Khvg8sm6JD02IQ4oIGc3Zj1LfQ9iJY0W9LPoKIf6EbhtX7q19DkQbS4hbHnc7tsQsvN yBvAV7LLIPjWi+3omYDWZDlq9QAtPuK6lmo38T68BnochNSrwaEQkCwAb8AI66d+LOqQlyGivYV6 01QT5LqFFTprikHrDOdsLU7aWnYYulg9+Rgc6sHhmKyNenEdcuKk5dw+wtifgdu74OQBp8GoHO3o 3wE50qJyvMlnfAutf8nHLqe5gAtpfCvQKPkOpL+F3vMhyawp+vZyJTyhH57wS5mTh89G8oBbGP8y 167kAf1cfzWgLVzb/fAA8vF6cQvqrcBWrs9++Fu/2MK9oT/GGwZZNlbXIFbXIGLqIGLqIEaHNuCL 3A8nOyDB6/AIsu98vsp02J0quB/Oh208kGK++A78rWryt5AmSawGvRmoAWrR3oK8Dm3qkf8QaAC9 hfunFtIlQbKV4jbQzUALYAc6sB4S5TWljdpByzVqgTY9GJ249jO17K274WGDkE3LZWvgvo/zBtdZ AywuiE2Mvl0a5n0DOCERtXrqEEawwuIe8BnESEeh6aMx3l8P+zVhxBfkOf81S0KPcu5lko94uGw6 1JdBCtPUT6OeTz45KHvUe9yKyizKpor5OqGW1air495ex+ZAM7fgGb+E9LvhGUfBldqQl1Vzrh9B j/f4un4XgOeLrajrwLqYJce5W3KPh+jxIY9Q9fDZBqygrahr5GvmOOLerZjet/DmIcch9O7n49VB gnrZu4m/iDgxn/wcZ2uah5lR21u8diu8n3zZBlqJbGp55UotiMtW7BJ4gjFvwbpVKFUD9LQeEaYB 0jVNfQzJHqDVr9HqM5z+fw5dmBF93+Zz+kiOFUoMpxX0O/SgVTTAY4aI1g/4ekrBCB/y1VYtR+p6 7FYkqdSPNEj9fkmtMcPfIJYp85Fa/1ZuyecjzZzPWlnFm/msb8XM+td85FRGJ87nKE7LOqrmredz +8EbRascA5r42l/JLTAruv5fRGkhQDFp2qYe2QvIMgejlrHJ1lHJXidFRBt0+d7ULzjfFJnHYIz+ KC58KPvCIO2BaN0PjQ9yHQokKzTZyOstsGTVVB9GHgL/TzHyOOf/LjTOPQdPd8d45y2uNaUFxea4 6MwOgy+d5b+F0rcwz48wz4/kiDPI93WRvcZvchhLx0dgSxh9x/sKPnHsm/jEwworcSb4Fj4q9m18 1PQPDsF/C/BJor9ywCl7Iz4pzMTMsEUl/d0C+zu8f8xmH7AzbI7wqvAaSxf+IPyBzRX+SfhnNk/4 k/An9oLwZ+HPbAHejwX2opggJrBFolpMZVniLHEWe1nMEOeypeIL4gK2TFwkLmI54hJxCXtNXC4u Z8vFVeK32DfxZv1d9rpYJBazN8R1WO0FYom4gf2V+AOxnBWJBtHIikUztPsfRItoYW+J2LGZXmwQ G9gPRKu4jZWLbaKdvS0GxSCrEsNimG1iQmJBoo++n2ZjbBVj77oBPxO2ZSGPADtAZzPW1gC6jz9j 7+4B9gOHgKPAEHAcOAWMoH0O8vPAJRmjcj4m4yZwVwbR99EnF/mEXL7JhK0WKd+Wj/yJhG0ioAHS UF+IPB3IlPpwWoLQNqDQ4tzG+02Pmu7Z4psyrbkcubYMjkKrQYJtKUeNNZ+j0LacYG215hKaDDIK bb6m27Zw40TTZOMT8BObJps0yE/YnBxptqSmdNts3q7QFm7KbxzjSEO79NjxG0c58kEfBrJkKO2z QQPWysYxwrScVo0MRW4uZ1MRaA6igQ22NRwGGYU0J6BIRqZNy2FDW4JSbgXdGi3ro/yJjilvefKX 0bQBstiA4JabTb2AF7QD2AmacGDLXY7DmBshaDNyKOUT4HEiRv/yvKP6uGDbJmHLBMcVazaHor+r pGNggNva0nQdtiHI9kO+Hfn2qB0kn1jQNIC+A7I8im2VXLGtYkuFp2J7hXcOeAHWBsja8AW2nOmD X2b7Z/dfzDHT9iWgOYgme0V9J1uG4jurOJ7Z3raaoxL+Uyn7E8eW+xyVMhQf22Ar5lDaz0QD/K4h xgcLvwRKuxJ5TSo+6sDcCVEfBm2LKZO/EDLhX5nWwmkffroc9dVKzNUA7EafvYDim4QBaxZH1F9B H44pD8MehGh7WxXHzOeKfysokvz7c3GmBmXCWdCE06BPcxlzOU7AlwFrq20fITq36fgklZX2hQT4 q8FaxMGfU1v0NcT0n24vxRdF7i8t26wEa6WtioA12MuRT7GNr6tsjhwZV2wHOWRft/VbswkxPryU g+IiQVnHBGW9zVx3CopkzKyvkTG99pXYLMk4vX6lmKDktzHP29ZMPl/KP+df1p0csg5tu5QYh/kT LtjasD6NTVen9dx4t+lBkxdrgaD4dz5smi+v6di9QV73799sHCVMP3//Lkc0boDOjy1Hda+0v88x M87MjBvKui+B/oG2nLZcQtOGtnwOZV3O2Cui88aafH8CeAIa8b5NtOa2aT5fnl4rkJEwc+3IumqD n7YVTvt0WxHKRdPl6BroxT5ACGIfIFxoK5FgTeO4AtsRZL20bbBmc6Q1jhEU32xLRzl92sej8VY5 E8zcO+X549SUzL8LZ/xbcA3//jsxYVXCKpaWkJ/wHTaLf0v9vEqn+gHLVBlUFSyLfz+9mH9P/BL/ lpe4zBH/r3gfXBbFLWZi3MtxK5gqbmVcHpsd1xX3kKUnLE3IYeGEgoTL7McJHyd8LLyU8GvVd4Rs VaHqe8KPVJWqHwo/VW1RbRF+ptqqahT2qppVLcK+5MTkRGF/8n9PHhL+S/Jw8v8U/iZFSLEJP2eC cF/Mmz7x1fUCO5lQvxz5bmAvaNQ3toE+wJ+xusMATlV1w8AJ4DRwFrgAXEH71civAtdl3JbzezIe AI9kED2JPmsYq4+Xyw+YsLlZyuuLUZ8kYzaQASxAvRb5YmCp1IfTEoTGk1H6ayyH/gaa6ZiR1bBG 1sa8LMJ2sb3sEBtkJ9gIu8iusntsUtCwuLoddf66vrpI3Z6aU0ysK67TVhdYcESvK6hbW51rSQKV W5df21Y7Dmpp3fLaxtoJUAvrltQt23QJVHpdZl1W7R1QSXWz6zJqR0CxOlVdSu0FUBrLkzqxdpCJ lknLA8uj2uOgHlruWMZr94K6axmz3Kw9COq65Yrlam0E1CeWc5aLtTtBHbdcsozUhkENWM5aTtS6 WXwdQ+8b1afB4bFlvGYOi0d5EPQxPDlZU71pLVr7LGHL9tpCUHaL2+KvLf4389IE/jcdjP81h6By qwIskf9dw3P8rxKeh1/NE3z8/4c9CRuwWvhQLfyiFnaGFMy6ELlWrtMDRqAKwEm/1gpsA+BztU7A B4RlbJfzXTL6gX0yiD4IHJFpBYMyjgHwjdozwDngovz83OeQU+3mH/+W5mr3Fnt1pHpHtV+GG+ir 3oPPfuR9SA8B+3mJaEr3yB96jpoqw5b7+ExUVdJf6kD/8FjxofhPeO/9Z9ginttCxW2h5rZIgS3e YKkJ34laZDYs8habq/oB7PICt8sClVllZgthlyNsUfJRWGcJrPOEvZw8CRst+3ccSWBrWCu39XK8 G7PNeJPbjAi2GW9wm/Gm9g5iSQ3e1mrwrMHBNJv0m4yV/UirNlVVPmzYR9/li38U/whJJ8QJJiSs TljNRJVepWdx8D0Ti1e9DQ9MSP7b5L9lquR/Sf4Xpv5X9RHmjD9Pf2eeIpxELGB22N4Ov2m4zSFa 56EM/7HDf+zwFzv8xQ5/scNftsBH7fANO3xmi1aC/RO5ntpdi0LwZjOxMigBfi5al6D+BvJl0/XP gnUFkPcV2hUAWOHWdbzM5eK4I8tGsiBONSAuv33pqb5Su4ewTQr66+S6x///2DyP845C4dsBo4Ti gaTonEmv0fE7VJBxDQcvb1n1TPDnGAe5+Fm72e0IVLVXu70BS3u9Oxiwtje6ewPb2pvdOwNt7Xb3 7oAT9XtRX+8+EPCZbe7DgXC72z0Q2N7udw8HdrVH3CcC/e073KcD+9r73GcDB9GyF+3t7gu8b2/g CPhfQcs97quBQdDXMdZ+9220OeS+FzjWftT9IHASLR8FfEhvIx1yTwbOtB/3xAfOtZ/yJAUumg94 Zgc+aR/xZASutZ/3LAjcaL+EccPto57FgTvtY56lgfH2m57lgYftdz2rAo/b73tWB5lcM+FZg1Ge eIpRM+opBp9Rjxa9Rj36wB276DEGVXaNpyqYYk/zWIJzwF8P/qMea2Dcnu7ZFjhoz/S0BefZszzO 4EJ7tscXXGLP8YQDVVJKemu+bs8ljdnzPdvRvtCzK2C1F3n6kTo8FwPnnkq9nk+iqYNSml1whT3o uRa48VTay9OdnhuBh0jv8PRGMM++m9fs9YwHmf2AZzzwyVPpYc9Dnj5GGvQy4haT9vJ0wKsKFthL PPuCy9rrubTD3pTgWswaHBzLvE+C5+0bPAcxRwOfqTSjC94lQV37hHdZsNx+wjsH2ijEHH1oSW1y PUegAYmu9AyClmpqPMcCYTltkOmTSG2eM+AZm7Z6zs1Ir3hXwIKSj3Fr2q968wKD9uveAtjrtndt wGk2eNcFl0h+K8/Lhr4++2ku4VnvPAvVLwyus9/z6oJm6KEcdn/gNcN/4JPBarL+exG7zVuNER+R p9knie6I99YHLkpe15FE8+qYTRakVdN8gfyz2daRAcm3tY94G+GZ0bUTrCcvNe+UNNCxgOzYsZhm 0bHU20wz8tppRl739OzeycHs7pH/dCwny3as4vRqbmUb1z+3b8carz+wq2O2NxJUdRRzWstpPWmm w0iaoVUWbOT+3Awt7QhYOqq8fcE5HRbSaoeV+0Ar90/uFR3boMkz9kekyY420mqHk9M+756gvSPs 3R90d2z3Hgr6O3ZxPfSTHjr2kZag/3pIdZBr7AinB7n1vd6jGCWX0w7uyZV8jXg5PenV8dHJFoWc 7iWaok3z9Y5j3iHU27zHA76Ok95TgfG6au+IparjjHehZZfkRfAHrIKOc9yjpBXB/Qr1WCkUqVrO kM9UWTsues8Htnd84r2EyICoFYxQfGhZ3HHNO2rhESy4Q2pJESzYR7GiZbEczShu7Om44dkV3N9x h68vbouOcaIpsgUjPIYc6njI9f+Y9O9g3rHgUYfKezM4xNeIVVp3jpQYes60/ikeNl+nyBM87pjn vRs46VjovY9IMu3JpxxLvBPBEedseurMoKfOBZxezOmlnF4e26s7ElzYXt8lItKOdmkg7f6u06DP d53FiPDh8Hby4fAueaXz6CR5r3OVZ0G437nacyS8T45F0oru5TblenauUfTcPMC1t91Z7O4NH6QY Gz4ir2jusTQ71PPZYaxz0Vkj2ocH5bgaI7McVaQIw2XDCqLIWTNtd9fCaf6uJcTTtYx41pV3pQUv Oca6JkMO+0BXerDAsaIrMzjqyKtZGBxzFHRloSavKzs4Jj9d25UTXOtY15UbvOnQdeUH79ZVdxUG tjnKu4qC99GyhPfagJbmLkNwos7MLVvdVRl8Yj/bVRMSHfVdDSGNo7HLFkpzNHe1htLbb3Y5Ag8d 9i5vKBPyBC1VDndXr2WXw9+1M5TliHTtDmU7dnTtDeVgLFso19HXdSC4TpZ8T9fhUL5jf9dAqNBx qGs4VIS+JxC7EMdCJa4V7qs9h6TdynG060Jog2Oo60rI4DjuvRmqrDND2qOOU11Xg0NEh2ocI13X A1Zwvg3O57vuhRocl7oehGzSDivtZY7RrkehVjkt8OcECzqz/LkhB0nVc9SV58/vGXIV+At7jrvW +ot6TrnW+Ut6Rlw6/4ae865yv6Hnksvsr+wZdVWjfsxV76/puSnt0a5Gf0PPXVez34adRTpF8P3a Zffqeu7DXrT2c7uPBna53N1D2J1xWggPSv6DlbILvnHYMx4+4vK7J0NnzQaPLzzbFaFV7Nrhb+2Z cPX5HZBqj9/b84R4kj8QT9d+94PgqOuQPxgR4cPRiCrtTa6j3JekfUrakXmMcg2Rn6P9YNTnY+JJ rM+7jk9HgNjI7DpF0dg1wqMxj9Ku80TLkdbBI+2qmFUfE6Vdl/y9EY1r1L8zkhYb91xj/t2RdNdN /95IpsPtPxAsINtFssh2kWycQGh1HPFcjOTQyu1h8r5TyFdHL6S6EbuaHDd98bDsXV9SyIt0NlLy rgK5nqf2AV9GcJ3jvm8B6vk6ckz4FgefOJ74loaCUtop+paHejs1vlWhnZ1pvtVYBWjPz1Swb2e6 b01od2emrzi0tzPLpw05Oq759ODppnMapcF1ndk+YyirM8dXFQh35vosWBd+n/WptLIz37ctdKCz 0NcWOszTATrLIeUxWUo7i3zO0LCjz+eD35b4wqETnRt820OnOw2+XaGznZWQ7UJnja8faaVvX+hK Z4PvYOhqND0Sut5p8w2Gbne2+o6F7iE9GbpH6yv0oNPhOxN6JKde37nQpEwHfRdDWZLVMK9PMG6m 71o4vrPXdyOc1LnTd8eyq3O3b9xS1bnX9xD0Ad9jnB6zyXt5mhFDz+483M0sTqQqnqaQFbrnhBdI p+jOge554cWynoe7F4aX1u3pXhJe3nmie1l4FUYvhiZPd68Ir3Zc6s4DrfCh9Gx3QXhN54XuteFi 0OvC2s4r3bqwvvNqd3nY2Hm92xyu6rzdXR22dN7rrg9bOx90N4a3dT7qbg63dU5228NO2iOCbr5H HHNqu3GKwL6ZFLjm1Lu94ZN0Mg/307tD+AynzzmNdBZyVvFTut/d23LQafFkhC/SuSjMT+/ha04r 6BtEB/c4t4G+g74Z4XHy3vBDZxv2ncexntzR1t0XcDqd3XsCYUdK93549WH5zIA14vTRGqF3E8QN vAX0qOT6cPchqR67KtWnEN0zh78p3Ik9Gzi3U/xx7uLxB2cDyNyPd4fjnB4kumcenRB6Fsp73L7u 4z0LnQe7T1Vt5/VLqL5nGadXcDrPeaR7JLDPOdh9PnDMeYzTJ4mmt6SeAucZz5qetc5z/E2Bn+Hp pNFiJH/uWUd0j47o8DVOl0t+br/dfSngtB/oHg3cgU6IPky0U0txxnmR4gydRloO0mmkx8zpQU5X Oz/pHqOTSfdNnAxx4u2pJw/vaXRe674bGHTe6L4fTOnQc/oO0dS+p57ao42W3tec490TeDNCvOpp Js9voXfG6+EzRPfYY+MY3+sHpb1++lRj3kl0D3+36nE7H3Y/CRyzH/aLsBHeAZtv09tWj8r5ePoM Q2+FPX56/2ox2gv9moDPxfxpWEcSrfKn90QQ2ejMcILODK6U6RMsRcieHbS+evo4vYdocwP3hP2u Of7M4BznYn8W9H+AnzH4LuCa588OjkQuRK5GrrhzO9MjeykNPLYP+A8jdvn9A6FKR59/OLjOddd/ IpLrjO92h33OpG5/OOy67z8dyXdN+M9GCtvN/guRItcT/5VIibnIfzV8RD7hV/uvRzaQ5iMGkqfK 6Rb9tyOV0huu/G4rvdU+/caqVd5S3Rr/vaffVeUdnJ8f3Gn+B5Ead7r/UXDCnemfjDRIcdV+JRCP twzOpzMzkBSOd2cFZkdsfM2OSyuRxo20ym/T9O68R/JkkiTikONtVBK8vMRESP6mfIfekSNBKaZR xIj0Su/XUlyitdzjpr0jslNKpRppFHe2Z3Z4gTsnkBHZLXkI7RqoyQ8siByQbyf4jYG70O2IHJZu J9xFgcXwMekugr/1u0sCSyMD7g2B5RiR3zlIepNuFaRzptsW0EZOx75RyrR0X4FekWG3IbCq2eau DKx+b8JdE1gTXuxuCBRHTtC/aMB//cVifv0l8l9/xWvWaowsgf/iawH/xdfX+S++lmjaNE72TY1H 8yOWx3/N9T3+a64Nya8kr2Dlyf8n+feskv8CbRP/vVktxshlS9hfMcaK2Dssk9WwLraK9eBTznaw n7KNbB/7z6yCHcTHxI6wAWZmf8+Os01shH3MNrPr7BZ7j/0ju8fa2QSbYi5BFJaxkBARetmA0Cd8 zP6H8Jlwk/0x3hrfxP4cfyD+b9hU/In4fxDi4s/HXxYS4+/E/154Ln4iIU74WsKShJeEb6giqhPC S6pTqn8QjKoPVB8IZtVZ1a+Et1W/VquEOnWieq7wH9UvqhcKB9RfV3uEg4mexKCYkNiTuFNMTfxP if3i3MSfJR4RX0j8b4nnxFcTLydeFb+f+FnihFiW+OekdHELfZMidienJc8S/clzkueKweSx5H8U e1PeTfmZ2JfyMFUQP0zNTM0UL6cuSF0sXkl9JfUV8dPUnNQc8RoToBcrvyldSL+Z0TfKaGZM28cy 9fX6Rn2z3q536/36iH6Hvk+/R79ff0h/VD+kP64/pR/Rn9df0o/qx/Q39Xf199FmiH6DxW3LNN/T fI+JmhJNCf+t2hwxR8xhTMwX85kgrhZXM5H+twYWJ64Vv8fi+d8MqcT14nqmFjeKG5lGrBDNLFHc JG5iqWKNWMvS+F8LzRabxCb2nPi++D54tosO9jz/m6G50PcSNk/1K9Wv2HzMaZSN8ZnN4b9BvcRq dKJOo0vTpesydVm6bF2OLleXryvUFelKdBtQa9BV6mp0DTqbrlXn0Hl1QV2vbuf6S7rdur26A+tH dYd1A7rh9WO6E7rTurO6C7or62/qruqu627r7ukerL+re6SbLItff78saf2lmM+o/BmTPzejn7vS p2z2+omyjPVPyhYAa8oWly0tW162qmx1WXGZtkxf1lZmLKtaf7PMgpbWsm30Gyf1f4U2M57yc/qd +yq2DV67mnXA59dyPy+Ffw+w9fDwv2c6+PfHrIzdxWcD19Fb6m+oX2J69cvql9lG9avqV5lB/Zp6 OatQr1CvYCZ1njqPmdWr1avZ2+oCdQGrVH9fvY69o35bXck2qavUVVgvAtuDlURaXswSGCvNABbI WAwsZQWl80oXli4pXVa6ojSvtKB0bem6Ul1peam5tLq0HvWNpc2l9lI3nvpLI6U70K4P9J7S/aWH So+WDpUeLz1VOlJ6vvRS6WjpWOnN0rul90snSp9oRa1Gm6ZN12Zqs7TZ2hxtrnaDtgR1uaX7tfna Qm0R/R5M857mff6rv6SntNWBzyr2v/H5FvsdPnlY9bfYt9kdfPLVG9Qb2BvqjeqNbLXaoraw7zAB q4j/iylsGVMztlEPGJlgXI68CrAw4U1EtDdb43I3ao0ZG/XGBRxEG42LN1YZl3KaYDEu32g1roo+ 22ZcHX2mtKO+RNNz5VmbcU2UpnqnsXijz6h9KifeRBPCRj2HQm83GqPPFCiyKO0IxF+hieculHfJ MtG4SplAz78qFHli5fqqUHREMih1sXIozxX5qa5flpVywj7MNRax/WNBstE8KT8IG5B++mV9K2Ps knOyUWyZ9Fkl9yFZqc8ROVdkU/gouh00Vj1l0/6YXJHlmNHC85NGa3SsmTmNQ+MruSK7Mhfid8a4 7XP9+meMe87YtvGi0bnxE6MvKueRGXP5IlmV+cTyjtXXtZgyyUcyKfm+GWXFJ2N9UZmHUnfDGN54 x7j9KbtTrn/G/L9Iptiysr6UevSpyJXqZuZP9R037jIUGG8Y1hrvPGXXL8kr8r/a86fazdT3V8h5 f6U8U88zdfGX8mszypj3M3NtTB7Dp6JQ0tOX5X9Rrth5fJG/KWvtobF/42PjPk4ruRKX5TVoYMaD yjODyniEfMWQYhyMjdeGOcZjhnnGk1xnilwY27DQeMawxHgu1v8My4wXDSuMnxjyjNei8UGOB4Z1 xnG+fmPjC42nMz7kfcuNj6N+DvkMZhMjcL0ZTKOGapOK05WmsYoa003y14oG090Km+l+RatposJh ekJlHufRv6IEMVHZg77IljNt48VYcpyuCE6PEX3eaxYrdpo1n7PFs3xz34y1/WXxauZzWUcVu81p FXvN6YrcpNuKA+bMWF1FZTA+Iw6RPutNKYTovqb4ifK80TTH0Gyax2E3LTS4TUti91OD37Tsqf02 Zp81REwrZu5vhh2mPG4LBQqfPlMBz/eY1hr2m9YZDpl0fJxnwHDUVE7gsUypGzKZo2tY3ksNx03V hlOm+tiYZhgxNfK5nTc1P3NfJt+7ZLLTfGmOhlGTO8pzzOSP1ZfhpiliuGvaYbhv6jNMmPYYnpj2 V4imQxUa09GKNNNQRbrpeEWm6VRFlmnkqb1DWXuxubKXzIzDz8pn+pdxRq7UU9zf9wX+9Ky9aOae hL4VRbK/flG7mP2Ut4tZy9xfad3B3krOzyaUf9k8/1KspfygfNZQcmXd6Geso5n7n3IeQbliw9N5 9GwT/vw8PrffflV55efRvXLmvvqs88dMe8prKzoexTTou/V866XPnW1pvMPmrIps0/mKHNOligFz dsWwOeepMyPxJdCcidcJc250DZO+Ys/HyvpTziGyPBWnzfm0T1ScNRdG1z3VXzAX0fqL7V9xxVwS lW8mb/CtuGrewPtej1lfMfFJiUXRszPJfNtsiOrinrlSie8VD8w1Ub3JMlc8Mjc8dR6S9WhMMjue sjH5h7InUr9Js80Yb26lt3jNjzU/YSz5df4vCN1LvsfoX+3M/ve9X0mIY1P8HmUTv0fZrDql+kDY xW9QdvMblP38BuUSv0H5Lb9B+V2iJyldXMvvRUb5vchv+L3Ip/xe5Lf8XuT3dC8Sl0n3InFL6V4k 7hW6F4lbQfcica//P/LOPb6q6sz7+3pyIYaQ0pCkMWKICCSDgpCGmFtpRHruIvJSRaQUEZFSQItI I0VfqohI8VIEihQpVYwUKSJDLVWkiJRSyiiiUsYiMMgwlA8iIoOYzPN89z7JSRSll6l/DOuzfvs5 v/WsZz3rutde+5AjT7TLjIaW04OaOmNgzbCakTVjasbX3FYztWZ61dGae2pm1zxUM79mcc2ymrqa BomratbWrK+J12ys2VJ1VDS21+ys2V2zt+ZgzZGa4zWnahprndr02qzanNqC2qKaYG232p61fWor amtrhtQOqA3XDqodWr2tJkgYIqGOECfopyBRZYl6EpD6Tf3+ZJtn26nSI3caP5Cn2pUS+vGcW2H8 m/GqPMnulFBl/s7calQ7O5zXjFo9r5KcpjHUGN5S375njKJETaWe4+U6XiStrzJaZ611g9S4wa+1 1Fnq2yA13i7hHtGaXtOAj6PEx078XzZDRk9X4bpJsORZuodhG6USHKOncYnhGr2M3vJ83dcoN9LE pzrjPGOAhExjoIT2RlBClhGW0MGIGjHx9CpjkNFRxtxQI4e/hJhvTJbwFWOahAJjuoTzjW0SCqXu rxkXmJlmpnEhf21rWktdywrt3sGtwR3BXcE9wX19a4OHgkf7Luy7MHgieDpkBLeGAn1rQxmh7LKB odxQQM8yhGs+zSgbWNa/bERoYHBH9YpQNLhDTzaCO8pGc7rhnW0U9j0dmlZm6PmGlLM1NDe4T61K KGsJfbaIHUL1iuoVZZWhRWolEaTURJgn+ZaWjQ6XYisQMkJrxHIP+bSPuE9910AJfqheETxdVik1 mCR+zwruCS2XGsyQeq0MHgoNFN3nQxuCu0L9NZYNFLtleuYS3CPyHj15Ce4r6y+tMTh4Wi1J1PaS GAqIb9lST4lY1xOaXKmztpNGKU1jWSA0MHRY7SZKwWIiig8aQ8fkelQsS+y7sHqF+DVYr3reI3I0 eEJPfcqifQ4Gt4YzQ4fDHSkfH8L5lJ/bd2Zz2RL1bChUHJpGbSuQElEYL3eoUKxtx7dPxE/jw9vD O8O7W/mfFDVNfQ7vDR8MHwkfb/YwKX4ar1z4VLgx2fvmWggfPqW97EX1Q9sm4X+4d7QyVBncFy4P VRKrw3XSwnvCwXA8VBYeEh4WHhkeEzwUHh++LTyVkS3jNDw9fI9YEgvh2eGHqk+ERoTnaxuKncXh ZdqS4YbwqvDacG8pVfowvD68MTY/tji8JbYs1hBbFVsbWx/bGNsS2x7bGdsd2xs7GDuS6EktIdw5 dlxj7FSsMRT1cmha3Imne+PHb1G/5bwel95u7lNvXDW3hIyteFY8R0dHvCBeFFpeZsS7qYXwzshQ cmj75Ab3RfuHKqMDo9Ho4LKB0WtD/aMjoqMljAuXRidJmBIeEq2MTgvuiM6QEsdKiYOrV0RnRedG 50UXRZcKvzy6smx0dE30+eiG6GYJ26KvRt8MjYu+HT0QPRw9Fi4VSyejZ6pfiFmhwlhqLDPWMZYf 6xiaFOsc6xorjZVG345Jn0Q3hAKx8lh1rC4WjMWj02JDvjFSU2LDYiNjY2LjY7eVBWJTY9Nj9/Q9 KmuPjrYdocqIE94dSY9kRXL6bNEZGCmIFEW6RXpG+kSKwusjFYn2itRGBkTCkUFa+761ZSNod2ZP ZHhiFkVGRcZGJkQma7tqnwRPROojd0dmRuZEHiEujCyJPBHOl1Xk2kT0+iZ8PLIisjqyLvJC25Eq q8YIjV7/hA9qjGyKbNWxE9kR2aXXhKxrQWRPZF/kUORo5ETktPofNaIBvTb3q6yP0Yxots7KaG74 SHBrmaGR3pRxFy2MFkd7RC+NzOSceEaoLFp2YzddbeM9433iFfHa2OzYQ/EB8bB4vuurHWWdyo0P ig+NDw/Jilc2Ij5KWnWE+OqtxrNkBI6NT4hPFgtTQiPi9bHU+N3xmfE5ws+MPxJfGF8i7BPxFfHV 8XXxF2R8d45vim+N74jviu8p6x/fFz8UPxo/0Wdj/LSuf7rm6tgNRa8yrgrQJuL3VbneaintlC1r 6ZSrMq7K5l544/+hHdQYYwJn5vp3x42vzjFMiR2/OkvCXAnzJCySsFTCcgkrJayR8LyEDRI2S9hW bn31VQlvSnhbwgEJhyUck3BSwpmvntG/Mph6Q+oI/priFcaV0q7fMEKyr4jI7iBgXC2t107a+Xr9 HyAZhzKO4xHvui53DLPqNrmmy3Wq3buisWr85Y4XkdMlZnkyn3MkFiSlFSWl+Xrkz/LSm9O6Jcma r6fEPm2uOb6sscKPCbk2KS0RfV+a9fr49vu02Gwu02ntD1zPvyJWtIltffmsWJTkQ5KfzX4Utfid 3EbNbZXu1zUpJudvZavC16/w+6Cgpb2Ty8CPrDafc5LyOH69E9c+LW3W6jqgTZ8mXxO+hP3roE/6 0Fy245fvtPEj2c7QT8nXttzhEkdJHJvUx23r8mm+fkr7nNXXHN+ns139MdlqLKa34SZInPwZ7dCm /p/rU/L8SsyZbq3nXlsdrvUSt0rccZb+/Qdez9bu53xt087n2l+feq0/x2tyG/vt9HnXzyy35+f4 78+1y++WONOXE1enZQyjOycp7RG/nRZWtV6vl0h8oqp5zWgeGyskrm5T9jqJL0jcVNWyPiTG4a4q 5m+r9UWve/y8+6paz8dDfhSucoNcj/ryZonbvLFY+arENyW+LfGA95l1XvMXVbXcg85lTh6qal6n k8tIpFcelnjsk2191rH5OWOt7Xr1qeuS+nJS4pkkXtq2ymrdVm19+IQtTTvhx8TnxDhJfD4t5Rh+ DEjMqGp1P63MTtJNvjepj7lVn7i/VRb6fZGICTvF/rWHxEslllV94t6UHCsrvcgYSnD9k9rXv5dW DpQYbV3vysGev5XXJtW5TVTdyhFefbWOlaOTbI5r3V6VkyROkThN4gyJsyTOlThP4iKJSyUul7iy zb2jz1mun9JXZx2f57rGZX36ePpr70mf6UfbOZx8LfL7u83171prE2tJ8rXt/f5s9//Pu35Off5m fz/rnnku/dqndfmJten6wqpP7m3lWpUq426NxOdFzpTY0c/rJJWT7tdZbFXlV7XM4Zyq1vvjxPxL 7I19f6o6V3GfqOpa1TLvlS/15l9y/qreSf61tS12q8qTuMR8TFqfEmtR895Zfa5uSa+qq2pe36uC Se3m+1wVbz1OEu1YdVubPs6qatnXab4hEodVjdfvPfHX7o3/O8+a5lz9a+hGhplp1BpGyWKJywyj +xNeLGmQ6wq5rpK4VuJ6iRslbpG43TC67JDrTj/u9nnR67KpJRbO8vTQ3evpKl9yUOIRnz8u8ZTE xr8+ljqenURM2CtN9/wvzfJtSyzNaa3bJl9tSX5J55KuJaUlvUvKS6pL6kqCEuIlQ+TzMAlDSkYK N4YwvuS2kqkl00vuEXlIyeySh0rmlyzucbjH4ZJlinr1pJIGcFXnyYWXFl5aslbsjSyJd64vWS9h Y8mWpLBWv+v5yW/68gsPDr/t8GV+wyGH33DI49cbCvjdhvP5jm9nvuP7L/xWQy9+paEPv8/Ql99n KOOXGcr5ZYZ+/CZDzT+9PNPMNr1vzT5vlBhGjxGGUbDdiz1GSxwncVILd7bYY4rEaeegN0OijL8e c73P3bPapM/7fBt+LOl+tPuJNuF04aSE3MNI5nsEEnKLxqcH/cU5vslt8Ase3m93uHyTO51vcp/H b3fk8nsdBfxSx/n8RkdnfoujiF/h6Movb3Tj1za68zsbPf7X7JrGSmNNyzug4kVG5OLKrwS8cPG1 Evs3fxp4cdSX0PBSLh6cSE/kEBxx8YhmplJD6/SEvYQttZSw41tQ2/0T+RIl68mhNU/aImAtsX4j y/pL1stGofWKddDoErg9cLvxdV09jbp2v2q3wbiCXw7JlZjt/ybHhc35Hckv66L1hPW84VrrxVY+ eQpEIwf02yPvjGHmnSTfY4r6qzJGuVGdpLHbyM7flV+Rtze/4qL8vL15B/MO5qfnp+ftzjuSdzzv VF6jhnx+q8Gar9/AtZ60npSyf2H9QphnrGcMy1ptrTZs6znrOfHs1+KNK3XaYqRSm3Tx7DdGu3Yv in9ZMuNmmls4uxtkdJDShxnGRaUSe39GLD9rmplXZ0Tyi72Ql5OXk5Dz5+bP5XNufm5en7w++tnX OqFYfKr4VF59Xn1xY3Gj6unn5rzJQfKTqyKvIn9W3tDkoHnb6qtecmibflH6RenJPl6UdVFWQva8 8/zLq9f6XCR+eeWfzZ+Wevnli18XORc5eYPyBuXPEo1BqueFvAHCTcufJtcB9KP+7pLBrxeZadem XW9YaTekjTACaaPSRhmpaaPTbjLS0m5Ou9lol/bdtO8aGWmT0m41zkubnHa70f6cx7BprjBP0d+T Zd9idBp37rGLrKpdZFXtcumnxClezJV7RZdJ/nWKYXZZZBhXjjAincbkZmnoZBWdzJ3syV3yu+QX HS46k+t0quvUWZj63PpOe0VnWKe9EocVHSg6oPk6ZYrWSQny2bPh2yr1r2PEwm167dQ1d7LYGtMS tYQuXaWsrtiV4Om1jrlZapmyJL1Lqe+joz7m1quPCf9yR7X4R76TXSzJ6yR8+jR/1Ab8sES6+Na1 6Fin6k7VXTqLRrXqyXW3xN6dqnOLcsfK9R7tJesBS9Zo61HrUSPNWmAtMNLTvpn2TRkBw9OGywj4 dtq3ZQSMTRtvZKZNTJtofIlfn+rY7v127xud2n3Q7gMjl9+Xyvur1rihEuMSx7PKFfF/TJYZc+RT pb/yFaG3iW8cmMbuFj0zyzitv5XSrGfKavQTGdGWrEeUT2mFlKa/uZrKSDcY6Q4jPcBIT2GkpzHS 0xnp7WSkTzbO+wdb0tYwaA2X1rjoC7akbb3QmEEPeG3Yhbb2Wl+/PZPgLLnTzqcHkvWW0vqmsc7n /nEt/Nk9mZz6yZY4t1T1f54/9lbgfzHcBr/uu5K4A/7YO93Cmale3c1Cn9O/gPb3zB+dOblnHW8B LBlYMrFkYcnGUio20s6a2/2kZ5TdjlIzzzqi/tZ85+atjqoVfh94o+oiuB2yH2+Z/R532u+DJM4s 9Psgwf3v9sC5tMXf13P//B4wjbXGNnaD+fr3yjv0NIz224iR9oeyijt0zdqmsf2eDl31Kp9K27/Q oaukbfPSO/Tu0DtrQ4dSSd0g196qI1rlYHWHamU1tD+kobXFhD0/RSy1slPcoTSrWLW1NCmJktWS 1jntW2nfktpNSJsgtftems71c96TGKsZX/4b7cw3iZGswVnXZo3IGi04LmtS1hQJ0yTOEG5w1qys ucLOktR5WYuylkpcnrVS+MFZawjj0B+BbnJobTFhb5Z8HizyIuxMQR4nWjPk8xqx+7wwz0s7KG7O 0v6x0kam3fa31vC8k8RI+0D7QObd7TPkmt0+VzCjfaHEYpgemUWZ4fY9JGRISFwvlZQyQjafNRwT 9hgpGoqTLLbY64Etz1LCTv/MHe0Htj8ptgLyuZKoKIEa3pg25q/YN1hmMU9+K/zZ31X/4r653Fxq ynOB3KmSWCvTSjX13nV3K/Y2a7zZKJ/HtWJ3WzutUfJ5SDJr19oV1lb+HmEy+4S9xFbfeySxlhOw 5yWtSl2Tei/bWmr9TOr2c+sJuQc9ZT0lz0srrBUyx1dZq6Tm66x1RorU/CUj1dok9U+z/mjtkDXt Ves14zzrdet1o731pvWmkSVe7jY6WHutvWJzv7Vf1rHn2z0v69hv5Fnry/Ks9SI9//lrxz/XI32G fAB88Asse8EXUvaDX2DZD32BZT/yBZb94y+w7AWsUdeag2WHWOqvBRfDDTLD+ldsW3FBs044pxXX 39Rd6LFWXIXZRz7tacX1FvumsaUV10NWR1PWx2SuyNSToSWtuHxTd++zW3HZZoZ8mtKKSzf1BGhU K84yziTt3C72d2knknZuHnfcOJK0c/O4w+zmOjZzuu7r+mSwazHZtVjsWmzZtYyTJ4nxsndJaTWT mkd22thWo1zx4STek0e2jEbdETWPzAeT5AeSRk2y/GCL7Of9cZLNHyeV5cm3tBp9Wt9u8mxqcTbn 1bhbi57UTvVWG97pnmmkG648Qac3f251Lw/MMIyU3kYk8JCE+WBdYFhguoSgyEMCi0VSblmgQeSG wCqJDcI0BNZKynpCHfkWS1jrh4f8kGwxYe8hsTXdt6Spa9HQtFVia21gIxamB7aItD2wMenp61x3 K/vMHGqo/0fAcKWG7iyJcyXO8+VFEpf61+W+vNKPa7hG3OkS7gF7u0F3vIRykevc2SIp95A7X+T5 7mKJ84WZ7y6TlAZCb/LNlrDMD9MJG8VSi8VyX2s6tjxLnp3pWKgTpkE+rcLCeHetSOvdVX/jU/G5 nrBl6hojrTdJRo3hyrripLdEPh9qE32+fWlS7O3HconVEuskBkWvsCW2307eiJMjocBxBOudLEf/ pdu7JeyEu9vp5hQ5RfZup48z0+kpcY7ziOP/s7d4mqJb4YccPxQo2luwmLCXI7ZyxEYfiapToRZE S2078mmAs1A5uQ5wljgD/mFPgH9T29uyDzxvWUu0p0ksbh2Vt46KPNCPUYmD/ajytRJHePJ5DS0x cyh8xFooYYk101ooy8oj+utK1hxruIShcAG5qz0hYbi1zs6wVtsZdradi5aGsK851HrBDwv9sETR tzhHZNVaKLZmWqvl3rjaKZfrC1jQtHUivWBttQvhtopULLvjf3Lb8zvTp5N21/quJLVxQmNGYzWR 8FfcWfROaNKbuiZvaSpvXqMNZ5H09bomxYPgcE0156psnA4sE3mjq2dBG32+HKZBsVHfthz0mMad mtfdo6dG2CltnKA2GzvDBDQvzAnQaNQ78cHAXM3rTEOW+6sZJHV4IFN9w77h6q+JGoFJakdLMfSf jE893ZKyDXCUMo16vjWPVG8Pwg5DxrHiXNDbr3i7h4Xgq/BfQmYXYJ5A9nYdB2G2gTwhmXvBInAd uEzRGgqmgtNBnr6sOt9CJTa74UM3fCvEK+/sTfl6SmSHYR1QtDOQuyIPVHSor7erkdoaid2MtJrq jAb5TXvzHnAXOAk7i0ntjJ0w8lbwEDq0htyrjcSOxt+zebsq9mVNq8ARnp2mneqnonkCeSjyMrBU 0baQJ5G6GFwPs47UgTDTweXgI/BRcAJ4CJwBUpaTBc7E291+2xYyVueCuks7nTIdHMrIUcbwZPcY jGoeZCwx5mWkTVD/3SnaIzojjD0pOgfXgHvIuwbcQ941ilZXl95Rm1bXwGBQT4sPuowc5WWmGCAy o324O4oRjqw2hR8MniDVIDUN+RiyptaTq57Uevh69OvxpE5TZQYNplxkzzK5NiIP9/SdcnxGx2Hm sgJsVNlYI2PBtG5qek+Yp5oWa31pnzXgnkbdFa8BD2qLSeutQh6mM46Zu5G5v9GT4Yd7qwrrQ27j UmYxa4LKkrea9aEcRnPtRd6LXIo+PSXoyapf6rf2XHLpKnGM3mxydR5lOh9p77NGZeraZfzW2Sf4 AfwxVrMvOSdpAWU+0FzGq4GLFV39BY53XF19C50bdT7SMt3AjqDhobaVYaBjOAHGVS5jLATzEfKD yNuR05n1XcAb1Cs9H27aZ6DPiY+hjD0hUMr4X0SfImsP2hO0TVI7azsE5iq6A3RddRappp2h6JTr 2LAzvBGuPevOVl7ml8pbtN1SDykfmKtjydnHmDGsxeDPFE3eDsgzosxNc7/g0/JkaVo75J4llpEn gv3A9crL86LI5hhwr/Wcrrq24u3K2HPQ3G/9UnMpL9Z+r5aR+2npdo61VlcMzWufkTXPtE6Z83Q+ mjJaLMN8VuTN5n8gf6SydSUl6mg5YX1XW9XpoSuzqf1ea35PGVv8NwusV8RmgfkGeT307CwG96um 8uYcrbvpmEfg39T13MrWWpsrVTa36iphXaB1VFk0Ndc1ls6aWXoPknr9ibxPic08a7OuUbJym3Yf W8f8JFvuUPZUle3R9nxdge37BJeqpr0C5gJX7svODL4l9LBbI70Wc8SgE3Hl2drJA9+A76Wy1RGc 58oscD25k9tb+ve3KrvD3QGi39m5Q+RuTkTkfo6W8rgbFXk+Over7Na74mdK1BUd9zuutK270B0i OlNVx37U+lfBL9lXC17n3ilY77qCm2TnZtpV9vVSu5/Zsluwx9o/Efkm9wdiYaI9AEZxJrUea2ub /MT+quC9trb/V+w5wj9n6/h8yn5cy7IfE7zKlidX55Dmcr9N691kPyN8sT1G8Hr7N4LLbZmz1ofg UUXZramfHexOwmy2ZRTZlyiak+0n8VBtPq7t7LS37xed9vaLojPM1tWso66Kzj7nd/SXjB/3Vvdm kb9Hr13gao+MdmS0OBvkyc10DjpraR95Pna6udfRL9fTI9dp7VxZ/VxHU2W9vY4eGUuPyLO1/aKb JfgRuApra0ldqL2fchVjYD5537XvoYV1nBTZEwXDurLZrn2X4Hfcr9ELDyhvix1zhn1A8BF7L/wL Wnf312J5sn0rOrfSC5dqP/p9cTd9IfPRHOq8S1+8qJ7Yq+gLeXq337J/pfO3abvOWb07WBO5/+7n TnEN8tOk9oMZzn15M5oGdwFOBywDHUN54wg6c9C/CXklcgX7jTizKUquel0h7Tt0B2X1wuY2Xf3s x9Hv1SS7R/sJ5J8pur9QtJ8E++q6aj/RKGPbvNvzh7J+pnsGeyY202UPJfsKRfvLnn3lGw+5W2R9 fs9ZpfUNfCj4ekovrXVAzy8muvtU9jAlG15Xqtc11b4TfpkyTgH808qYm52hoIwBq1jXK6uYXjac b4GSaq1iHftXmI8VzTe8XG6t6rij9U7n6MlTE/esD1LG6TpMvTayQyvW/aTcR6WOTVkqN671GcV8 9pyzZW8rtZO7kN5l2LdoK8k9XffqueyUTqcUqKypguwutCzBAu53F4P/rdh0HfuZ6dzrvft+AKYA OxXc2QM6F1RH9hDd2KWrbzvZwfK2o5FdrtFALTb5+3yV3wS3g4ycxq1+Ls+C1mgAo8X7Tlkh2NHX 2cKzjzIuFp5A7gDmUMr58E+jf8iVMdPYT1F6P6CoM07u48Uwsh4a7X1UZrv+npek9tTdgierftMR b1eg40c0kb1Ui9Zz8uGzkEeAz2vLaAs39kuRFazxcZWbrkz5PjbZIbiP0ObXIC8AZ4B/An8FvoFO f+TDyK+BXcCb2Q+nkTofZjYyz1YB7ASmwOwBB4BbwP3gC+g4YI5hnuGZqOld2jMPbG943x2QO1HT SVLfYzSe9PmOMMKfYV8nO/CB4FrQY/SJIKo7N2uk85DM61dS5H7hDlF09oO3KloNivb5iikePgAD OgY6/RQDoFtKai38BuRb4J9GH9l5HeYxUj+AuRwLHZHnI/+Q1JdhLJju2EyBfwdmJv6Mxhqyexl8 X3J5dVkOfxy+BiaOhRHIl5DqwAyDWYN8P7iEEi+G/ynMafTTwTr478C/C94JMwp5I/ge+CFICzsD kSfgD60RQDPwGqlerVdivxd8BP5ecCpIL9hvITeBf4GZrZhOf6UNVkyld1IK0JkEcwBmAcz3wbvI S9s6O6nvfZTrld4T/gr4eTAXwoTBzeS9EZwBou/+AVwMg46D3LRPx1vTJh1vBr7Z12B5pJ5RWEPl uVNRZrpVofPafUVPSNwhis5+8FZFq0HRPl8xxcMHYEDHQKefYgCUsT2OUT2O8TyOsT2O0a5YSt5a cm1AvoVcT2MN2Xnds4z+Y+h8AHM5pXREno/8Q1JfhrFgumM5Bf4dmJn4PJpSkN3L4PuSy6vvcvjj 8DUwcSyMQL6EVAdmGMwa5PvBJZR4MfxPYThrctPBOvjvwL8L3gkzCnkj+B74IUgvOAORJ+APbRJA M/AaqV6tV2K/F3wE/l5wKkhP2W8hN4F/8fpOW9UGZeaOYz0Zx2ozjpVHcbZqptN3aYNVTqWXUwqw MwnmgNdKqpPOCElZAPN98C5Kpy+cnbTPffjpedsT/gr4eTAXwoTBzeS9Efn9tDd0tMOQy/0DuBgG TceTr+F8L6brsPuK3rXdIYrOfvBWRatB0T5fMcXDB2BAh92d1U8xALqlpNbCb0C+Bf5p9JGd12Ee I/UDmMux0BF5PvIPSX0ZxoLpjs0U+HdgZuLPaKwhu5fB9yWXV5fl8Mfha2DiWBiBfAmpDswwmDXI 94NLKPFi+J/CnEY/HayD/w78u+CdMKOQOf2w3wM/BGlhZyDyBPyhNQJoBl4j1av1Suz3go/A3wtO BekF+y3kJvAvMLMV0+mvtMGKqfROSgE6k2AOwCyA+T54F3lpW2cn9b2Pcr3Se8JfAT8P5kKYMLiZ vDeCM0D03T+Ai2HQcTz5GuR9nB8OAt9mlz4H+Qwnk1nKOOz9HHYOju4XzAAnt/ZS9Gc0ye7LeZb9 3mZ4dnEuew+b76w43ZH7oLMcfMQ7U+Xk6hjnS2PIxXdnzF66A7EH8aRQhj5PIuZhrAWQ7+Kc8Cip H6sc8M6Ev4kO56KWd1Zcqnacf4cZSVnrFJ19jVPVK/CMorUY3MGeeSLt0xOvXN07mcs0VXbUqv82 /nvtwJOXRduaZWrZXopODvpBno+WUrrX2l+j3d6gbbvAPOidoOLbn2D+Bc9T6amtePsf3nMcqezP 3fvoi5uo3Tbw2aY6SWXum7u0XKccC7sp8Q783I+HjEmLcu2php5L9MeHSznZWwYOx/M+ilYUuQe4 lSe1U8iD2BkuB49iOQN+Lc90N8O/rih36Hk8gU5AfwIeqv6cxq3kVUyFWdu0T5Fyd4MTSa1TtHmq cjldt36tlm0LbydR7i2cT46h3PVY24T8DprYtwpoz0bZ/2p/aeojWHiLsjYjr/NltbYanene2xBs nsGTHPBqNMfR2vmg96TcAX9SyDsMO0H4YeApcDL4JCP2TXrkLpibwR+BvwdfwvOH6a8L0HwHZoff hoIubz3cocz3jtRxO6mUqP/fTfDbWGOdMV/G2o3Uq8y/v6j8X/BXoXmf5yd2ejMCWW+tp2B4U2Pd jj7vVtxelPIrUvv5ZdHmyHeA14G/JNcM77kSnQ1Y4D2O+ywz+lJ0XkS/iDr2xjLtZv+Zsgqp7xa8 CqG5xJ/1P5a1l3c3qauYKcfA+7H/OnYYCSm8wQkwGp3TeHI1DG9/ZK+pNlczo9NILdO5FrjBX6mk FOt+xsyf6f0RrF28o7HOw89bSH2A8XA78mA9RXF4tyV3uoHay/jD6LKuxEPenVkF/PrFY9SdtrJT QOaRvQH9rvTaK+h4c/A5mCWk3uv3r5Z+Bakr0LyO+r4JTgP7o7kSnT7Im8Hb0e+GzPupADsKGV06 ivbjz+V4+6L/zH43z+xL9LnSPs5z+iKe3OfxZJ0FU84TdznP7Jzeq6Y8s3syz7+6w+fbGfL8Tmp7 0LBSkc+gE9bZpE/H1mTwKLgenAWO5E3oYeTN4GpFezRowWQj54AZ4E74xeTdpU8cYuG0npyAJ3gG mayylY2cDZ8LlsKnKtoZpKZiYSVYDwb1DZdtITeiU4G8F/mUvu2yZqX01TUQ+aiinQPOwbdTpG72 NVM54ekLevp90VdmF+9fdrk3qOfIJ5Bz3WfAUXh7A7VoAFU2AsWCT3u+wVSQ2k9Pz+y3aZlc5wph bEq5n9SRlNvD80S/pyMtpvwOmD8hb0Zeifwj5Ffw6t+Qc1Pq8EdPVi2Yw2hOpr4VMIM9P5GfIm9Q 31PbGTAn9FTEWkw7jKRl9qr/zkw87xO4SPBbeq5rnQr8Rld7avcS9negvxFmlqZa2YELKUvfgxju W1o6uQ5TVil9YXB+eAC+kbZtxMNL0alHnug+qqevbob2DpYP0FZPUu5R7z0+I2cbIyedc8swaIBP c555mf49UutCR9rW/hEnmfvoBZPU2zXVrqKmHbUHzWs8C4EiLR3mmNbIrvN4zWs/yznqJuwsgB+M 5Twvl/v/yFuEn2p5GDqj3dmCJYyEzc4AUC10Ull81lQTfqXy5s/Bl8FrOFk9in5X5M1gAS3soFOg jG24c3StJvVj2vnPjuzHrKXkraNG3jntKq++5M0D34dfQC26+3UJCr5DXgM/9/veHmAm4gma+ymr VNvZLNcxY65TxvmdK/d9N6Bod3c+1vuynvLZS90USb3ZfVXkElKLFK1MWvIILfYDyn2ONp/qzV/G +U5GguXLqcg6ig4z+5Z784KRdsBb6xjby721jhH7Y1YeRo61G/4/6ZdXvJVKzxKt68Fs8H1K76uj WuaL5lrN6M3V95X2w/gzEH9G408Gco5ak1mZyvxlxcCTcd6843S6HgzydPxn8s5Hv1HfVUlZdzI3 mTuBe/Qex8z6mBJT8MpmvgxV/1PHKpOyWhn33xUDO7UlA5nM4gGKKetg9qvsnqfoXM38elo9tL+C zVRKqaPcTK1v6kz9HotY7ii5jijKjNN2q9K5YC5kPq7Dk91YGEreb8NPgq9F8xFv1jCDxgZ0V1Cn 88XmXmB3ov2P6vm8VaTjxFzAOh9ynmLm6ogKBtRCb38WqP63GIGljOFHsf8SvXnCvUPkP1KWgZ1d ysjd5A5GrOaNkatBrTVt0rNu+2G91zhh8CS4HVwEDlF0C8F5inLHnMJMV6Y3OvmKgUaYBu5ch+Cz kHci7yN1Nni3YkoUeTypmzybetJup9Da1So7ASx0hj8EDtRUuQepfldSZ9BHU0gdBM4Alypa68Ed irLOd1RvVXZPo3OGUsqRVyDfpncKtwGsBs8oBtbgZ3eVnXfhM7infF1R7hTK5IFvwPfTU0fxRPEW 3kwtdx7VWaZoPwb/S/DX4F8UHVYzdwie/H+YW3l3aTinxIe9tNgr1CjblvHjXEBZX+GEsz3yh8g3 4+dllPtBoJMwXyP1PmxuZ3xej85+2rCW2l2HTgo6+6jX+8ws3og5l7i79USItpqLTki/O+G+Q66H 0azXu5jNt8KsiXpC63Dvc3sqb/VzXuIkLZP211rfqGNean0LJ7Tqz+X0Tr3bWXeqWmv3d66Jjp4k RLQ13HaaGrhV72VOg3se+qITqEBzv5Yl+urJVHuUnkrxlvZWZQLXa65Atsru22rfXK/3FKsBpt6l tZlfR5W3Q84Heubj2dT32oEdquNW0f6HeOf+nH5HJfB7/H+cvrue+n5P3/laZ7SO7nHs99K8gVnI e/UO6BTT/v3tG0Hx1j5gfwRq+zyn48HhPZHTBZ0O6LwG1ipaDfKsY9rXqG/iocoPKDohRanF1wX3 qLdWP2Vkh/Z1PSVTPwMw9mnwObXmptvvSup/025F2j7SMto+N5C3ATsfgA285V9kf0PwXS9V/bQW Uet+zs3YVE+ewf7tmsseq7VzeylKvWxh3vN85v14fw+1PaUWql+v9p0yvc86A/0a6TnGBHi+Jxa4 hbpsBKto/x8ySlfSbgedEuEttencS+pUcAwjqphvVgS1LLecPi1nbIe93gTzGbFzGOcvM87vRP6j ys4qRvt6VolGNKdg4TJPh3G+E50d8BdwovsVmBKsHaeUG5m5vyLXGTSvZP7Gua9dgZ0rA8MZFbrL +prOrHRWqrTBmprygGKqwepawIyepJh6gPW5H/gqHrZTzXTWasmbT15tk+8zU+5i9nVnDByCuU/f fUu5s5kduo96RdFewN1ks+5a3YdYh39Eyz/s/pZ5+lty9WT9V/kZdn0NrGDzHK3Ly9qn7gxvVVdr jsmYGcWomMSI2s9Ie0C/weVerTNIxtVpdn03Mh70Pr4Z/1Mpnd1j00njWt5gFur6zOnWZPBo07va X8izwJE+zzciwLneqR24mvOx0aDlaTbKk6ZVoXbsDPid8EPJu0t58zDYSFmpyCeQs3miz0Yzl+9X TIFJRf4vv3TVD/oW1HIFp50bvTNYdBq9J3fvmxJYfhrk/az9tu+bYg/4KM/7sziPmoy1IJo7SV2M Dwf9s0rVXM2TvoWcSuoB1TT+C2YiPhR49cJmBf5kwl+G/n5KT8dmGPkyyroQ+Udo7kPTxM41+HM7 qVXIHT3eL0vxGC1Qh87tyM9iYRO4gLL66TccrMHoe98nKSB1IjaHoTMaZiipm/GqE2WtBH8Ovgx6 o6Ureb22pdY2Ns2PsfZndJaCdfDXkHcw78qPgafxZxn4vtfLaGaBz3ilkOsdcCP8R3xbYzOyd5Jc imYxo2U3/DrOin/HN2oCnPT+TnPZ3dF/GJ/xzbkZuQT/i0j1+usI8g9ok+fAX3AStRA8TP8uR+cA TCPMUV9H9Zf742on+op888dazwlnKoi31n/i82HkWciv+PIEZsfS/2nvO6CiWLp1a6aongGajAqS k2QYECSjEhQRQQHDUVRykiRgxgAC5qyoHFTEY1bAjAEVcwAVFTPmLIqKR8XErd7TzvGE/573r/fu f9Zd68ly1+7q6urqr/b3dVX3TA3YDKg/AKLrMkQjl7+Y/2yqNCcAfO6K4uH5VXsoIwZfyD/75coo w6cUXsBR7tDm+Xxry4AFl+EswAXIeSflMvhHoOQgOFYd7CDoHXjKJ07mSopAH0gjZ5kR3F5yFK6o ibOiblwOsx76pR5sGMStDpcvng7HAv6CPDiqG7R5sTSewSZDj4+E9kifPx+BNkhZoAW2A5T82LYO dKwEtG4dXCn35BP6WtAb4iQQrs4RahgGV81CfL6A834DewVsOdhrYG2ghqVwbA3Y83BGiExhCNS2 icun7bOgOZFyDzkLUTdaLpjaGnibWQPPBmvgPb41QvAJFIQU0ErBJkSiMqOikWHMuMwUFJ6QGTcC DUuMi85EySlR2WloLPdttP6hfobcJ4ba2rjfTkXySBGpIQ2kxG3RPDqPpKVYpILUkSZSptvcJ+O5 PUjmCbi1q3hfiBiEuXqDwgMMuTWuYL8cv48gVdQuJiY1A00BWwh2NtgisCvBbohNSUpA2+OT0qJQ FdiDSWlJ2egY2DNJWekp6ALYK7RgFLoF9n5KekwKegr2VWpcbBJ6B/ZTJt0tQGDhXRZcqdRi8LgP xnHXQH6X85snQNLjFH6wij9Y+R+s8g8WvhHB18P+YJV4q4ZMkQ1yQp7IDwWhcBSBYlEKykY5KB/N RotRCfoFMdzHktF0QFggUJem8As53JN2bq18OkIXmyJYh0z+jHRbQcKn3RB8+0WhEtonUDjDp9ek qaquNNWopOVp2sFGmmqF0nPR+rU2SevROshfhTr9bwznVoG1GYJQH4TgV4iF//l1/ugIikaUwFjo hHvIDUK6yB35oEAUSkcp0SgZZaLxKI8iNx8tQ6VoA6pEu9FBdAKdQ1fQbfQQNaF36AsdHLGi3QiL toi2ivZAWi6qgrRCtBfSStE+mm6l3n5It4oOQFouqoa0QnQQ0krRISSk6WG6VU5L10C6VXQE0nLR UUgrRMcgrRQdp6XLRSfoVgUtfRLSraJTkJaLTkNaIToDaaXoLC1dIaqlW5W0dB2kW0XnIC0XnYe0 QnQB0kpRPS1d+QdEuF98GIum/B8hchGufIvoEo/MZR6ZBh6ZKzwyV+l5toiu8fhc53G5weNyk8fl Fo9II4/IbR6ROzwid3lE7gEi93lEHvCIPOQRecQj8phH5Akg8pRH5BmPyHMekRc8Ik08Ii//BpEi tBKtQ+X/EpFXPCLNPCKveUTe8Ii85RFpAUTe8Yj8ykfMex6ZDzwyH3lkWiFiPvH4fObx+cLj8pXH 5RuPSJsUESorgIhYIEVELJQiIsYcImI5KSJiIkVEzEgREYukiIjFUkTE8v8GIsdQLbqMblFEnqO3 6BMdYCqIFaSIiBWliIhZKSJiJSkiYmUpImIVDhGxqhQRsZoUEbG6FBGxhhQRsaYUEXE7DhFxeyki 4g5SRMRa0ogRa0uREXeUIiPW4SJGrCvFR6zH46PP42PA42LGXanYkMfFiMfFmMfFhMfFVIrLv41I kwyRTjwi5jwiFjwiljwiVjwi1oCIDY+ILY+IHY+IPY+IhEfEARBx5BHpzCPixCPizCPShUfEBRBx 5RFx4xFx5xHx4CPGk0fGCyLGm0emK49MNx6Z7lJkuDWLuXbDHWghvROwKI3eAsT0bqCLOiEJxcsP BaNB7EWq9L7ifnIL2Uu8t4i9DF4ozWvgvUXsFer5Q7mrvLeIvQYeV+467y2C9YtMkR1ypf0RhAag SKrq2WgSms7ekJ3ppuxMt2RnapSd6bbsTHdkZ7orO9O972din1Ovp9iX5r3gvUVsE3j+NO8l7/13 Lbova9EDWYseylr0SNaix7IWPZG16KmsRc9kLXola1GzrEWvZS16I2sR5b7ATmBHBzAdhdwzABOh CdyL6chNqTPc/bNpr01B2n9uMyqm44tyVIUu0jj+SCOYFbQXGAqsBE4Cb0GAYDQ3clM8goSw+oKc 4lGZd+y7J6yj3jLwzsm88zLvgsyrB48bHbLCi5wvfEBtEey7JCt1WeY1gIfpVSgjTeEVOIJryRwh 14olUObqD2XaC7k2FQmPI0xLFgmvyWq6LvNuyLybMu+WzGuUebdl3h2Zdxc8Qvtfk8a8MbIQ0vuz cAU9F70/C1fS9CQtsUJ4itqVwnuy4+7z1y0SzhXOp31UKlxHy28QbkEKwnJhOVIRVgq3IVXhDuFO pC7cLdxH68cwGtWkvOJWJuLGWqr86rCr6Y7Nws20zp20PBZWC6vp+Iz2tnAxfEObW/uT63uq9DCW VeDW8+O+A470hCXCEqRP6ziEDOAb113hG9fd+DGdGFpL76i0Zdy7jlLErdzI/I7htATuSUt8AC9A 5vWSeYEyrzd4BNaj1aLzC1M48i0c1QJHvIPSv0LJ95zCCN/SIxCsKoqZaUyhkJsxYAxwYAWswM2r MAvXR0vgZ4we5qJfwBgwRtxxgkFoI36ODbEFtsF22BF3wXk4Hxfi6Xgmnovn48W4CBfjlbgMr8Ob 8BZcjivxdrwb78MH8RF8Ap/B5/BFfAXfwLfxffyY1tWEX+HX+C2xIDbEi3Ql3Ykv8Sc9SS/Sm4SQ MDKQDCHDSQxJICNIOskiY8gEMpnkkqmkgEwjM8gsMofMIwvIIrKELCXLyc9kBVlFVpO1ZCPZSraR XWQP2UcOkMPkGDlFaskFcpFcJlfJLXKXPCRPSRN5Td6Rj+QLgxg5RsywjCqjzmgyWkxHRp8xYcwY c8aSsWZsGXvGgenMODNujAfTlenO+DJDmSgmjslS3K64U3E3K2QZVoFVZtXZ9mxHVp81ZjuxFqwN K2GdWFfWk+3G+rEBbBDblw1nB7ERbCQbyyayyWwKRXgDFmNuyGGADWgfmGNzJMTW2Jr2gS22pX3t gB0Qwc7YGTE4F+ciEZ6KpyIxLsAFSB5Pw9OQAp6BZyBFPAfPQSyeh+chJbyI9p4yXoKXIBW8HC9H qngFXoHU8Gq8GqnjtXgt0sAb8UakiTfjzagd3oq3ova4AlegDngb3oa08C68C2njvXgv6oircTXS wTW4Buni4/g40sOn8Wmkj+twHTLA9bgeGeIG3ICM8HV8HRnjRtyITPA9fI9G5iP8CJnhZ/gZ6oRf 4BfIHL/EL5EFbsbNyBK/wW+QFY0AC2RNo8AG2RBP4olsiTfxRnakG+mG7IkP8UES4kf8kAPpQXog RxJAAlBnEkgCkRMJJsHImYSSUNSFDCADkAsZTAYjVzKMDENuJJpEI3cST+KRB0mmMxpPbo0T5EUy SSbyJqPJaNSVjCfjUTcyiUxC3bm1SpAPySN5yJfkk3zkRwpJIfIn08l01IPMJDNRT27FExRA5pK5 qBeZT+ajQLKQLES9yWKyGAWRIlKE+nArnaBgUkyKUQgpISWoL1lJVqJ+pJSUolBupRMURjaQDSic bCFbUH9SSSrRALKT7EQDyW6yGw2ikbsf/UQOkUNoCDlKjqIIcpKcREPJWXIWDSPnyXk0nNSTehRJ LpFLKIrG9VUUTW6SmyiG3CF3UCx5QB6gOPKEPEHx5AV5gRJIM2lGiaSFtKAk8oF8QMnkM/mMRpA2 0oZSGMxglMqIGBFKYxQZRZTOLVWHMhg1Rg2NZDQYDZTJdGA6oCxGm9FG2Yweo4dGMcaMMRrNmDKm aAzTiemExjIWjAUax1gxVmg8Y8PYoAmMHWOHchgJI0ETGUfGEU1inBgnNJlxZVzRFMadcUe5jDfj jfKYbkw3NJXxYXxQPhPBRKACJpKJRIVMLBOLpjGZTCaarrhNcRuaobhDcQeaqbhHcQ+axdJbK5rN EpagOaw8K4/mskqsEprHqrFqaD7bjm2HFrDarDZayOqxemgRa8QaocWsGWuGlrDmrDkqYq1Za7SU tWft0TK2M9sZLWddWBdUzHqwHuhntivbFZWwvqwvWsH2ZHuilWxvtjdaxYawIaiUDWPD0Gp2IDsQ lbFD2CFoDTucHY5+YWPYGLSWTWAT0Do2iU1C69kR7Ag6LxTSMW0WNsKW2B53xi14Fl6Al+Kf8Sq8 Bq/HO/AevB8fomw7js/i8/gSvopv4jv4AX7C8YdY4hZiSazwLBJE+pJwMohEkEgSSxJJCskg2WQs ySFlZB3ZRMrJdhpRVcSKVJMacpycJnX4Ek0byHXSSO6RR+QZeUnekF9JK/nKCBjCyDNK+AkJYtph I0aHGcF0IeHUG8ZEM/HknuIueoMQsYqsCqvBdmB1WAPWhLVlHVhn1o31Yruz/mwvtg/bj+3P/sQO ZaPYODaVXmsmKBsCZROApglB0zBomhxoFwHVYkCvRKBXYtAredArBdArRdAlFnRJCXRJGXRJBXRJ FXRJDXRJHXRJA3RJE3SpHehSe9ClDqBLWqBL2qBLHUGXdECRdEGR9ECR9EGRDEBtDEFtjEBtjEFt TEBtTEFtzEBtOoHamIPaWIDaWILaWIHaWIPa2IDa2IIO2IEO2IMOSEAHHEAHHEEHOoMOOIEOOIMO uIAOuIIOuIEOuIMOeIAOeIIOeIEOeIMOdAUd6AY60B10wAd0wBd0wA90wB90oAfoQE/QgQDQgV6g A4GgA71BB4JAB/qADgSDDoSADvSlIwQD1A8YHQpcDgMuhwN/+wN/BwB/BwJ/BwFnfwLODgbODgHO RgBnhwJnhwFnhwNnI4GzUcDZaOBpDPA0FngaBzyNB54mAE8TgadJwNNk4OkI4GkK8DQVeJoGPE0H nmYAT0cCNzNpvD5GGdgYW2EJdsLv8Gy8EC/DJbgU/4I34J24Ch/Ah/ExfArX4gv4Mr6Gb+G7+CF+ SkczTZSb7yg3rSk3+5B+pD/5iQwlUSSOJJFUMpKMIuPIRLKGrCebSQXZQfYSa3KQHCEnyBlyDl+m 6RVyg9wm98lj8py8Im/Je/KJfGOEDMMoMMr4KenDtMfGjC6TwnShvBzOxDAJilWsHCtmWVaV1WS1 WF3WkDVl7VhHtgvrznqzPmwPNpANZkPZAexgdhgbzcaz3K/kpP9/Vv7brOT42Bn46AR87AJ8dAE+ ugIf3YCP7sBHD+CjJ/DRC/joDXzsCnzsBnzsDnz0AT76Ah/9gI/+wMcewMeewMcA4GMv4GMg8LE3 8DEI+NgH+BgMfAwBPvYFPvYDJoYCE8OAieHAxP7AwQHAwYHAwUHAwZ+Ag4OBg0OAgxHAwaHAwWHA weHAwUjgYBRwMBo4GAMcjAUOxgEH44GDCcDBROBgEnAwGTg4AjiYAhxMBQ6mAQfT6Xyagd+pjURl aAvajQ6jM+gyuo2eorfoCzwXgTkPsqIzpy7IE/9KYzcPf6A2H7dSOx1/pnYuMx0JiRczltquzHhq uzM51Pr+RQ3voYaPUMMnqOEL1DADahgHNUyAGiZCDXQOxkziSoA3WeZNkXm5Mi9P5k2Vefkyr+C7 x/06L++1gEdn8/Sufxch8pV8Q0J6f6azVHqPppMVep9WQGJ6f42HFQ8D4ZlRJ+QETwBUFWspf+mR +Pl3jzGA5wp1dKuFztUaoZwynkzZTvdJU/wc5oPcHALBbEBAj7zzfT6IGhRVFJX/9E6COzf31skY 2VAcu/FPIM7CjLlW9iThIbe2IXiPZN7j7x4zhiv9387Ape/cBPC2jYV3RRQU4WusI5cglyiXxL+V E0hLIaTDfS9DE3KRzkhJnk4qI29VGFD4QUkgEpbm6QyjWYOFAoGDokSeIdbKWNiRIEkUo2DNCOQE eS5CgVxpmKSfxOaHHN0y/Sm6yBP+QlA0yqJhmoLiUDb97839SYx+qExO01dx56vG2TWauZtdvnnK DSxqzX19sjSvvbskT05dkif8VIqFAqFQBdWgWZ6e09Xqvd/HNN3pJlGStVQgR9uU4WAtsWRwfzlF DWPf9IxxmUkJidmGFjGWhg5ubi6GfZJiMtOz0uOzDX3TMzPsHPQlutLC7X6/Jz0zKjspPc3BSGLA 7ccaWr/tD01PzzbsPio7MT0zKXucRL+DkpuLxMFBInGR0H+DOyg5ShwcOzvwm/9Ai/IExj/CIiAI 5wlUEM1XEOYJBGijsLom47HH22Adi1VLxw6TPC/bOMds+MdvS4LW7Pm2oszQO6df2c9l8yIdR9T7 xI57tWX06fAbb1+UFOrOW5Ufv+P4iPHRJlf0PG+rCBY+LTp2yDa+uDix0/IL7jaH2F2DOtX0eKLg 7Vpks9HCbUNTr6k+D/JV9hen9I/akpezOtJ2TNCz5TtjPYr76jqITTVXbXyywFrrsdeyGM3IQSRu lZ5L6LQP65sXC0/oXDrU33/HjCmH3JvCFweXf10/PjU7uEKrtkjewggNnB+Z5LK/t7rIc0DbkM+/ xCuI113MHTCwebfHsPa5Y+RuvD9YPmXJt8q6yVfWd8yM8Dxz4LV4jbFkB1NweofhGI2CO0JMA39N 7gZJ7lpJbhlFU08gl1ssyV06RXXIhYzmpMyVJv0maW7vM7ft7OrM/3z/5f1NjGOuD5c8VTw8p2Wp lvPLKoHptTFqLRGRjqtWKp71Jgumzzvt/tjo7euBi2x2lfY8Fd385Wqth8fgjV3Ck76ZpnY9Xbvp NslpdJjjtUo1I3n/N/UQraTDXy74PlAbbBjyPHpCxSbtU9YuZrYH41arzzRTiVnzIVy31ej0lXYt oVvSfB1FX/M6fHyUkKLU7331m9CT1U+OSb4YOshP11ti2bFPg55w7Zspd/HOIe+2NZ4a+Cqu18nQ 8N07sYV62/wrr8XzJlUtPb7Zxebh+IcbxjwYXYouJHetudhl5t3u6huck3WSbzrfu6wr93CDv9yp wZ1d0/roKkXvUSibfakhvGuPOt3+6zJuqrtPWzRq1fqLpVQVIiV5OEiqCgp2m9Vu9W2LWHH28HdN 0funxIDy3tWR/qMK4EjFwMGRbjp/F4NxoKC0EkZD2D/MQUOixm2INRQGRmUlJqUlZNPTqEqUuUyR hig0LjY1PS32e8MU/lXDTCRG0oZ1/HF/bJxhWFJCGq3VsK9v979VhT3jJl4ZusPfbYPTFocbrWbO vcYc/myw8qT/yOb6Hk8vzz46Iig0+t1y4dE+13ql2Jt6xx06Z7JHMWDP5FGN/tWb5in3PW5m/bb0 iZKJQX1300/Ry89r+69dFGiwvG6HvfHRQNuc9Ovt9D1mu6m6NVZbvov3sBU4tn0zD1i3K0UwreTz vu0xk/NaI0pz8wvmVr6tWrzmvOu6vgUdzKcFN0reI693J1q9cg8WvkxxW2/n9H6nXYXCxOgFY+NL lmUpFVa8PdZiuDdEfU7MWZvrjv7ar/YHFnn0DdM6F99v3Kat004N8F6V13d6GtnmXDPBtDo03mt5 cK31pM5p+T2Z+pUXAguFaYXol8PT7oTxqvBJkvtBosGJgpkcK1FgxPSGRogI4/8dUqHCtVFDIGiT IxJME4kel6Es115Os1bv3GiUMaTizY1jwcX9/OzW+MW8lihyu1Xk5CiNCn+gDmjMhM3lkwI7vT13 IDi7bJB5ttWoHYVfNwctHov6PDvzQutW0nHlspwWoe+JM9NqP4bVHllVPSD9dYzfRj/0quhUcYNu leIqbaXFV2/ob7Wc2PxyXdaWebfd5notSz7gmnpxeoXJ1zvPriTJL5he/e0e2u/U8iGnVVXdjryw LFrkM8Ji5B7XeXdFSqeHJtZVT+k+In7D/j375zqdeYtVc8b/evGuz50J3+7d2/Lt/Z0GpR0ZVxY+ CNntWpZje9nrppNitItwVW6yyYz3ETHzKgfvd7saObt/fsfOv3osK81jy4bP2mGzZ/Xas5tvGO4+ JNEuMNRUsjoQ+q773WGSBwstkqbVZNxvWb/53BSfzNHKVGPGU42J5jUmijHPhRGS+EceEaoz/yCr OcFxpUrj6Ojg6OTszAmOhA4/6GZnblOSO/V/pG1KEDg0dOX6hPQN/V4c/4vif6s91Zk7ZzzRXVVw MrsqMgJ38Sr5unx8sWUP48r108JevurhfnIIURy4Yc8ZUnspaEzPjIIdj87eSXiy5mu2+aKEVVdn Yj/JiQ+n95121xMP8AvpIFZq3amduMlU9zMZWPDseLDIyGX9i3M29rt96ozI+iuPL1kMPKkz/pxl F1Hdyv61+98Yv9hg8ouS5ZHPF44O9o7xOmnTS3HCuILX05tHVvsOfrBmh1JL/89md+8bXnpSPGzx 2s62FpMH6vRPZh39muNT0l+7ljQLtxavblwmUlX21Eq6Py64h+bdvbMvjEot2YJKbH1+7Vc1+N1Y /6nP7HKs9w+t046y2LrYV+F4sk/bLsfyXyyNb7d/eonXno+S3F//Wnt+Y7FJfZZVUPXnR0afRuov b1ffofXYupnQfXoqHOspkUVTQDf0TOS0JO2n/DXt/bgCBnJeEg+JW6lLqXNh58Ts7Ax3e/uYzBS7 1O99aBeTnmqfMSKJy7XPyEyPHRWTnWXvG0YDz45mSQK+t5COSzwl7hLX79sSYaENX+GYMWP+qsK4 zB9qyv4DoUB9fC3Px1SnPMhKPbr8aio73eNEQNZ4s3M2910mrHBaVW1y7uCdaxHj1EZo9DMUxOzN /CB+cGJiP6v2Fpfrn/xsdV5L6aLGyAWWTQOqW68cV7KviLNN7eNvOSAzP6TrxWS97tEbx0XMfX1y zMyzQgu7FSdLrB/ttZJvbFp6/9H4OcNUp4etbowMGbNsZOSGIW4LLm1WNyDPjvpvvHSk396Kqltf 6FT0Xfaam221eqUmRPTQ3PnI0vnam/IizZ9+zrfWr5c7O/d8ntLVDX18u426eLtxTPPMiBEq02Ln 7dy3Z9/mhHAj/02BiU/Ch83SjEgY2zQ/AqsuEK8wNVz69A5Sy9jYuj0zY0/5/SOr2gup+qyg6lPw XX165byUTuP+OfUJT0qNy8qOSs34UX26SNwcukgcnJ0dYbjjAJuOEm5Tkrvuf6Rt5hIzqfrop/km ZSTGZRr6hfkb+ocFuztI/FxtnV2dXGx9fXq4fi+INfT/xUWExWWOToqJ+1uBer6PxJy6Pq483897 7Y5jL4NWmt5xG60vf8UxcNDYi9bX14rmNz/x+lzdKWfN50cTJzmev+41y83l7cdrHk7tLy/M++zU lFiQ2XHe3aqgu1UFLZ0VhDVlo7Ocg4a+2XMvcKJe1eKxN9v0C9r59Bh5brL5QPX6qSEe5z/dfj/r ZVf0oOF2VGuHOb1/yfX8Nanb83szDolC9mVPeMY+6vl8c8qbhoRc8cf2ZyZq7M+6Lx/0Kfrzy1K3 YvdvL9RORelHD7qmED61waN37/v9q+0jO85dSHxvDH2Rp2CyVL6UOMTNWhSs392obOH8r/5+/unO 2/xdtiZtjGt18t3W4YiH2z3V2W87TnsQ3tfAY4XD1h8F6jctmpT52q7rAMu7Zh8SqwRfet+bdP6B 9++0J/1pcNele5029y6cd6Dk+RaP7r4nLvxfaU92VkZM1P8T7fleU/ZfCa7494rKHP4rgUoanyfP tq+/fb7HDLtD9U7jcyebW3S3arlktFB56dbhYcMsW1/WhAdumPhB44KiZmuft4XtUNqDqXoW/utt 3Bwb04tdBr8yCZ0Xjud0XV8S6/q+yylN393u3stOKx0dmWvREr/e4X7E0HmtoaH3Il4smr8iST5o Rn396CAnpeR7OX7rrYdMDZ/sb6ptdmxmj+NmD7SnJFlqvu9w4rWxTW6PYdbvWtedGONtkt66LrZg blm00kZb/Q2P5ntPbquc+2Vp05uvchV1vc4Nzt7yqUXDQMft3JqdVw682/nq1Na3A/Q/e745dcXK 78Chkq4T47XqthvGKJzp5hXnqJ2zvcqrplNAsLH28rTZkpo3C34vUKrJistDDiOzzWo3/Q0GjU8o +6NM/TOTMV6dJE5OLpw6udHNf2Ay9ifh/Du9ueWS9rnilE/gSK1T5wK8ww5/2qy5z8Zxv3pI6Kmp L707X+/lsNBi94LYuwZ98/cd6V0/mXxsHnVw1skNDeVJGfFjzeOf7t7TXLC37tWmr+q/KP5kbGl/ vtv1AXI6o3elxqYGht9sfHP70KqpJ6fcmRwkdFn86+GV4gH6iT3rrh8eHWE/cbeZ3M4BQ5J1Y9qm 5Hi+apAz6+M2Jls09EjEtUIXm1GnlZ/ru8nnjP62IiVt/N0m73lLV45UHm4VohUd6bjy4tRga+OI RP9Zt+3zVftub93VcU7KK7OfNT6eVb1aoPwub3RWlxNLxpfVRjJNpLKw856Pi4fkd88fVLA4rdLA JqA2vcT3bvLTyZ3mjpDqTZ7AgiJi+tcM/V8xHVNl5PkHou0E3BwL/aCefymO2rIDNIVyrL4CCkOj UDTyRd1/P1X70zzvLwRqcR81hyM5fferzV0dJRIoz87wn9OcFV7dVZ7YtlX1CyvQfem2YM+aAYq3 Z+/20Kn/vGX96T3b+hnppIuTJo3AZcY9XqbsTM0xrupxKb9ljspB0cwuNS8mPcsY6r9q4cXac41z D987ZFWX03S63LFh2t6zMce61GsZHRp926N4h07WSqPp13buVA+f/a7kSFxgsUWnksiZKh4nNeLG Buw/v3Wqe0hl9KDbkmfP3PQezHh7wy23VcNoduyUGEau6G2x0Nd+Qo/p+9qE1+NaA2/fwNmLdpA0 tnbFLYuonIA3HUrUjFyFutO2MMeLHKsedTsR5lW9ccbtp/Euc94ZF5XUVo4J7+d+JdNvu8l7hzy5 tVSkVgsFAknutH9wlva7ueNvz7xLcy9INGX9bSFwEGECHy7jooDvTHnswP74mJ225rctRQdlyY97 20lMfjtQzoHGmGbsseWFj8+az7Q0v/589zjxfRfVJ5LBPxzCOgRJAksNp+ijcJSEUlEcykKGKJim Y2gaitJpXhRKW91pium/vKlmj8tIT8iMykgcZ/gHUZPLE6B463Fs8PXzXwO7DVx0vHHq9auKpxR2 u61bmtc+zrX2UkKN3po+2/dMbxqrt7rfqaZHJaOWFxgp7u1V13D06hvTw6/MiJVyToFKpGOnx4kR NddbdvU+7/R03SLDlS3CbbtOfjamY626cDWfFm/S2cUcD1f2aLKRiyttXmjuouCxa7GKzaQkGkdD ej1+WK5z923ww/nTFB7Wx+wPUvX7/PG1bs2rT751w3fOb/RwH5d50Wl4hyjt6Fdh2zsN2bze/fyC QR5RQzavYOSfNaV3nH9ZUnosPfSWb+TgzOLm6OsirQzx9oM+V5UbNEMvWqD9cw5ZblmXVzBtg8FB 78NplpfPe/m+TmUicxOR2+o8oYEkT6jzW88wDnlClmaJ/+OB+cf70O+mFSI+MEuHSrR+jD/F394F Ceg5ZXuIgwq9wbrRsX4XR0cneocd/KfwC/XyclObV3oxxTB2/krhkP6qjtmP/6BUXIjcCrS65h5t HfZTz4/TDneqc/sUGLtE5+bA1btevjv5em+A5vMzl10aLvrsOzK5FBVfKB/saCoxbMFFWu0rPqg4 motjJQtuLg2Y0+Fg5vKnnzXTP6pcTVhtVV5UsCNmZE+7jdZHnPySE40m30gc42J5ecnku2s8jeVN traFPbE1dXTM0zLADRauaz5kCueO3TLllOehY1czX5YySa8XjG3TDrVg3fsf6zJr74TGpqNVH4Zf ttoZdqjVzKAs8NPH/O7b256pPTdIHGFge2Dx5rnb5uodVCm/VNCYX2x/SbF42M/o/qiIFQuDem3e XvFzg0/M8KuaH4N2B05MXqvzZGKRX3PbQtUOFZ866l9dxC3w9l/dYG1lDQplbmRzdHJlYW0NCmVu ZG9iag0KNjk1IDAgb2JqDQpbIDBbIDc3OF0gIDNbIDI1MF0gIDExWyAzMzMgMzMzXSAgMTVbIDI1 MCAzMzMgMjUwXSAgMjNbIDUwMCA1MDBdICAzNFsgNDQ0XSAgMzZbIDcyMiA2NjcgNjY3IDcyMiA2 MTEgNTU2IDcyMiA3MjIgMzMzXSAgNDhbIDg4OSA3MjIgNzIyIDU1NiA3MjIgNjY3IDU1NiA2MTEg NzIyXSAgNThbIDk0NF0gIDYwWyA3MjJdICA2OFsgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAw IDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAg NTAwIDcyMiA1MDAgNTAwXSAgMTc5WyA0NDQgNDQ0XSAgMTgyWyAzMzNdIF0gDQplbmRvYmoNCjY5 NiAwIG9iag0KWyAyNTAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1MCAwIDAg MCAwIDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgMCA3MjIgNjY3IDY2NyA3MjIgNjEx IDU1NiA3MjIgNzIyIDMzMyAwIDAgMCA4ODkgNzIyIDcyMiA1NTYgNzIyIDY2NyA1NTYgNjExIDcy MiAwIDk0NCAwIDcyMiAwIDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1 MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUw MCA3MjIgNTAwIDUwMF0gDQplbmRvYmoNCjY5NyAwIG9iag0KPDwvVHlwZS9YUmVmL1NpemUgNjk3 L1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZvIDM4IDAgUi9JRFs8MThEMUI0OUEyRDBDNDM0OUE3 MkQwQzk2RjFBOTNERDM+PDE4RDFCNDlBMkQwQzQzNDlBNzJEMEM5NkYxQTkzREQzPl0gL0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggMTM3OD4+DQpzdHJlYW0NCnicNdd1kJZlFIfh77eIBSgNtqAI xiIGmIhNmCgWooLYSVioKFhgI9idYCN2d3d3d3cXfvtcrzs7e815FmZ3/zhzz6nV6h+zZ6f+tU2t 1sT4QpoVGpoXWrfEXYU2MwtthxXaDS60r+G7QodxOKvQsS8mFTpNLnQeVegytdD1pELvUwt9phUG XlcYNKswvFVhhN9zjO+NnVGY8ENh4huFU1rgp8J5VxfO94Om9y/M6FW4fnRh5tDCDfU/rKH+2Vg7 FsdhEo6pU2v8/59Mrv+HWVPKVH8MGnzveFMzzOHxBFNzzOnxRNNcmNvjSaZ5TCeb5kULj6eYWqKV x1NN82F+j1NMrU2nmdqgrceppnZo73GaqQM6ohM6Y0EsgIWwMBbBolgMi6MLumIJLIluWArd0QNL Yxksi+XQiJ5YHr2wAlbESlgZvdEHq2BVrIbVsQbWRF+shX5YG+tgXayH9bEBNkR/DMBADMJG2Bib YFNshs0xGFtgSwzBVtga22BbbIeh2B7DsAN2xE4YjhHYGSOxC3bFbtgde2BP7IW9sQ/2xX7YH6Mw GmMwFgfgQByEg3EIxuFQHIbDMR5H4EhMwLGYiKNQbf/ROA6TMBnV2leLXq12tczVFld7W21qtZvV UlZrWC3e6TgDZ+IsnI1zcC7Ow/m4ABfiIlyMS3ApLsPluALTMQNX4ipcjWtwLa7D9ZiJGzALN+Im 3IxbcCtuw+24A3fiLtyNe3AvHsF9uB8P4wE8iIfwKB7D43gCT+IpPI1n8Cyew/N4AS/iJbyMV/Aq XsPreANv4i28jXfwLt7D+/gAH+IjfIxP8Ck+w+f4Al/iK3yNb/AtvsP3+AE/4if8jF/wK37D7/gD f+Iv/I1/8C9mFyKmEdMoXhogppkHc0BMMydUNHOjBSQyraCNmR+toYZpCxlMe+hf9C/6F/2L8EUG o3/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L /kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kXjIoORwehf1DD6F/2L/kX/on/Rv+hf9C/6 F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf 9C/6F/2L/kX/on/Rv+hf9C/6F/2L8EX4InwRvmhj9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/R v+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/ on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/CF+GL4kXxonhRwyhl9C/6F/2L/kX/on/Rv+hf9C/6F/2L /kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6 F/2L/kX/0tS/+n3UdDA+OO3/azCo7r9mqA6/5qguvrlQnXrVjTcvquOuJaqrbj5U51x1x7VBdcC1 Q3W5dUBHdEJnLIAFsRAWxiJYFIthcXRBVyyBJdENS6E7emBpLINlsRwa0RPLoxdWwIpYCSujN/pg FayK1bA61sCa6Iu10A9rYx2si/WwPjbAhuiPARiIQdgIG2MTbIrNsDkGYwtsiSHYCltjG2yL7TAU 22MYdsCO2AnDMQI7YyR2wa7YDbtjD+yJvbA39sG+2A/7YxRGYwzG4gAciINwMA7BOByKw3A4xuMI HIkJmIijcHR9N5/9uKzo80OayISnChPvaKKh2++F7lObaNY4stBzVq32H7zJwHQNCmVuZHN0cmVh bQ0KZW5kb2JqDQp4cmVmDQowIDY5OA0KMDAwMDAwMDAzOSA2NTUzNSBmDQowMDAwMDAwMDE3IDAw MDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDI1OSAwMDAwMCBuDQowMDAwMDAwNTE3 IDAwMDAwIG4NCjAwMDAwMDQxMDggMDAwMDAgbg0KMDAwMDAwNDI4MyAwMDAwMCBuDQowMDAwMDA0 NTI3IDAwMDAwIG4NCjAwMDAwMDQ3MDAgMDAwMDAgbg0KMDAwMDAwNDk0NSAwMDAwMCBuDQowMDAw MDA1MTIwIDAwMDAwIG4NCjAwMDAwMDUzNTkgMDAwMDAgbg0KMDAwMDAwNTQ5NyAwMDAwMCBuDQow MDAwMDA1NTI3IDAwMDAwIG4NCjAwMDAwMDU2OTMgMDAwMDAgbg0KMDAwMDAwNTc2NyAwMDAwMCBu DQowMDAwMDA2MDI0IDAwMDAwIG4NCjAwMDAwMDYyNTYgMDAwMDAgbg0KMDAwMDAwODU5NCAwMDAw MCBuDQowMDAwMDA4ODQ0IDAwMDAwIG4NCjAwMDAwMTM3MTEgMDAwMDAgbg0KMDAwMDAxMzk3MSAw MDAwMCBuDQowMDAwMDE4ODYxIDAwMDAwIG4NCjAwMDAwMTkxMjEgMDAwMDAgbg0KMDAwMDAyNDU4 OSAwMDAwMCBuDQowMDAwMDI0ODQ5IDAwMDAwIG4NCjAwMDAwMjkzNTcgMDAwMDAgbg0KMDAwMDAy OTYwNyAwMDAwMCBuDQowMDAwMDMzMDA5IDAwMDAwIG4NCjAwMDAwMzMyNDEgMDAwMDAgbg0KMDAw MDAzNjM2MyAwMDAwMCBuDQowMDAwMDM2NTk1IDAwMDAwIG4NCjAwMDAwMzk4NTAgMDAwMDAgbg0K MDAwMDA0MDA4MiAwMDAwMCBuDQowMDAwMDQyNTY3IDAwMDAwIG4NCjAwMDAwNDI4MDAgMDAwMDAg bg0KMDAwMDA0NDY1NyAwMDAwMCBuDQowMDAwMDQ0ODkwIDAwMDAwIG4NCjAwMDAwNDUyMzEgMDAw MDAgbg0KMDAwMDAwMDA0MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1NTM1IGYNCjAwMDAwMDAwNDIg NjU1MzUgZg0KMDAwMDAwMDA0MyA2NTUzNSBmDQowMDAwMDAwMDQ0IDY1NTM1IGYNCjAwMDAwMDAw NDUgNjU1MzUgZg0KMDAwMDAwMDA0NiA2NTUzNSBmDQowMDAwMDAwMDQ3IDY1NTM1IGYNCjAwMDAw MDAwNDggNjU1MzUgZg0KMDAwMDAwMDA0OSA2NTUzNSBmDQowMDAwMDAwMDUwIDY1NTM1IGYNCjAw MDAwMDAwNTEgNjU1MzUgZg0KMDAwMDAwMDA1MiA2NTUzNSBmDQowMDAwMDAwMDUzIDY1NTM1IGYN CjAwMDAwMDAwNTQgNjU1MzUgZg0KMDAwMDAwMDA1NSA2NTUzNSBmDQowMDAwMDAwMDU2IDY1NTM1 IGYNCjAwMDAwMDAwNTcgNjU1MzUgZg0KMDAwMDAwMDA1OCA2NTUzNSBmDQowMDAwMDAwMDU5IDY1 NTM1IGYNCjAwMDAwMDAwNjAgNjU1MzUgZg0KMDAwMDAwMDA2MSA2NTUzNSBmDQowMDAwMDAwMDYy IDY1NTM1IGYNCjAwMDAwMDAwNjMgNjU1MzUgZg0KMDAwMDAwMDA2NCA2NTUzNSBmDQowMDAwMDAw MDY1IDY1NTM1IGYNCjAwMDAwMDAwNjYgNjU1MzUgZg0KMDAwMDAwMDA2NyA2NTUzNSBmDQowMDAw MDAwMDY4IDY1NTM1IGYNCjAwMDAwMDAwNjkgNjU1MzUgZg0KMDAwMDAwMDA3MCA2NTUzNSBmDQow MDAwMDAwMDcxIDY1NTM1IGYNCjAwMDAwMDAwNzIgNjU1MzUgZg0KMDAwMDAwMDA3MyA2NTUzNSBm DQowMDAwMDAwMDc0IDY1NTM1IGYNCjAwMDAwMDAwNzUgNjU1MzUgZg0KMDAwMDAwMDA3NiA2NTUz NSBmDQowMDAwMDAwMDc3IDY1NTM1IGYNCjAwMDAwMDAwNzggNjU1MzUgZg0KMDAwMDAwMDA3OSA2 NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4 MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAw MDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAw MDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0K MDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUg Zg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1 MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkg NjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAx MDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAw MDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAw MDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYN CjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1 IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1 NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5 IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAw MTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAw MDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQow MDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBm DQowMDAwMDAwMTMxIDY1NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUz NSBmDQowMDAwMDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2 NTUzNSBmDQowMDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEz OSA2NTUzNSBmDQowMDAwMDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAw MDE0MiA2NTUzNSBmDQowMDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAw MDAwMDE0NSA2NTUzNSBmDQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0K MDAwMDAwMDE0OCA2NTUzNSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUg Zg0KMDAwMDAwMDE1MSA2NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1 MzUgZg0KMDAwMDAwMDE1NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYg NjU1MzUgZg0KMDAwMDAwMDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAx NTkgNjU1MzUgZg0KMDAwMDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAw MDAxNjIgNjU1MzUgZg0KMDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAw MDAwMDAxNjUgNjU1MzUgZg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYN CjAwMDAwMDAxNjggNjU1MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1 IGYNCjAwMDAwMDAxNzEgNjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1 NTM1IGYNCjAwMDAwMDAxNzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2 IDY1NTM1IGYNCjAwMDAwMDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAw MTc5IDY1NTM1IGYNCjAwMDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAw MDAwMTgyIDY1NTM1IGYNCjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQow MDAwMDAwMTg1IDY1NTM1IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBm DQowMDAwMDAwMTg4IDY1NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUz NSBmDQowMDAwMDAwMTkxIDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2 NTUzNSBmDQowMDAwMDAwMTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5 NiA2NTUzNSBmDQowMDAwMDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAw MDE5OSA2NTUzNSBmDQowMDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAw MDAwMDIwMiA2NTUzNSBmDQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0K MDAwMDAwMDIwNSA2NTUzNSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUg Zg0KMDAwMDAwMDIwOCA2NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1 MzUgZg0KMDAwMDAwMDIxMSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMg NjU1MzUgZg0KMDAwMDAwMDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAy MTYgNjU1MzUgZg0KMDAwMDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAw MDAyMTkgNjU1MzUgZg0KMDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAw MDAwMDAyMjIgNjU1MzUgZg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYN CjAwMDAwMDAyMjUgNjU1MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1 IGYNCjAwMDAwMDAyMjggNjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1 NTM1IGYNCjAwMDAwMDAyMzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMz IDY1NTM1IGYNCjAwMDAwMDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAw MjM2IDY1NTM1IGYNCjAwMDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAw MDAwMjM5IDY1NTM1IGYNCjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQow MDAwMDAwMjQyIDY1NTM1IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBm DQowMDAwMDAwMjQ1IDY1NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUz NSBmDQowMDAwMDAwMjQ4IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2 NTUzNSBmDQowMDAwMDAwMjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1 MyA2NTUzNSBmDQowMDAwMDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAw MDI1NiA2NTUzNSBmDQowMDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAw MDAwMDI1OSA2NTUzNSBmDQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0K MDAwMDAwMDI2MiA2NTUzNSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUg Zg0KMDAwMDAwMDI2NSA2NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1 MzUgZg0KMDAwMDAwMDI2OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAg NjU1MzUgZg0KMDAwMDAwMDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAy NzMgNjU1MzUgZg0KMDAwMDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAw MDAyNzYgNjU1MzUgZg0KMDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAw MDAwMDAyNzkgNjU1MzUgZg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYN CjAwMDAwMDAyODIgNjU1MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1 IGYNCjAwMDAwMDAyODUgNjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1 NTM1IGYNCjAwMDAwMDAyODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkw IDY1NTM1IGYNCjAwMDAwMDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAw MjkzIDY1NTM1IGYNCjAwMDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAw MDAwMjk2IDY1NTM1IGYNCjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQow MDAwMDAwMjk5IDY1NTM1IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBm DQowMDAwMDAwMzAyIDY1NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUz NSBmDQowMDAwMDAwMzA1IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2 NTUzNSBmDQowMDAwMDAwMzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMx MCA2NTUzNSBmDQowMDAwMDAwMzExIDY1NTM1IGYNCjAwMDAwMDAzMTIgNjU1MzUgZg0KMDAwMDAw MDMxMyA2NTUzNSBmDQowMDAwMDAwMzE0IDY1NTM1IGYNCjAwMDAwMDAzMTUgNjU1MzUgZg0KMDAw MDAwMDMxNiA2NTUzNSBmDQowMDAwMDAwMzE3IDY1NTM1IGYNCjAwMDAwMDAzMTggNjU1MzUgZg0K MDAwMDAwMDMxOSA2NTUzNSBmDQowMDAwMDAwMzIwIDY1NTM1IGYNCjAwMDAwMDAzMjEgNjU1MzUg Zg0KMDAwMDAwMDMyMiA2NTUzNSBmDQowMDAwMDAwMzIzIDY1NTM1IGYNCjAwMDAwMDAzMjQgNjU1 MzUgZg0KMDAwMDAwMDMyNSA2NTUzNSBmDQowMDAwMDAwMzI2IDY1NTM1IGYNCjAwMDAwMDAzMjcg NjU1MzUgZg0KMDAwMDAwMDMyOCA2NTUzNSBmDQowMDAwMDAwMzI5IDY1NTM1IGYNCjAwMDAwMDAz MzAgNjU1MzUgZg0KMDAwMDAwMDMzMSA2NTUzNSBmDQowMDAwMDAwMzMyIDY1NTM1IGYNCjAwMDAw MDAzMzMgNjU1MzUgZg0KMDAwMDAwMDMzNCA2NTUzNSBmDQowMDAwMDAwMzM1IDY1NTM1IGYNCjAw MDAwMDAzMzYgNjU1MzUgZg0KMDAwMDAwMDMzNyA2NTUzNSBmDQowMDAwMDAwMzM4IDY1NTM1IGYN CjAwMDAwMDAzMzkgNjU1MzUgZg0KMDAwMDAwMDM0MCA2NTUzNSBmDQowMDAwMDAwMzQxIDY1NTM1 IGYNCjAwMDAwMDAzNDIgNjU1MzUgZg0KMDAwMDAwMDM0MyA2NTUzNSBmDQowMDAwMDAwMzQ0IDY1 NTM1IGYNCjAwMDAwMDAzNDUgNjU1MzUgZg0KMDAwMDAwMDM0NiA2NTUzNSBmDQowMDAwMDAwMzQ3 IDY1NTM1IGYNCjAwMDAwMDAzNDggNjU1MzUgZg0KMDAwMDAwMDM0OSA2NTUzNSBmDQowMDAwMDAw MzUwIDY1NTM1IGYNCjAwMDAwMDAzNTEgNjU1MzUgZg0KMDAwMDAwMDM1MiA2NTUzNSBmDQowMDAw MDAwMzUzIDY1NTM1IGYNCjAwMDAwMDAzNTQgNjU1MzUgZg0KMDAwMDAwMDM1NSA2NTUzNSBmDQow MDAwMDAwMzU2IDY1NTM1IGYNCjAwMDAwMDAzNTcgNjU1MzUgZg0KMDAwMDAwMDM1OCA2NTUzNSBm DQowMDAwMDAwMzU5IDY1NTM1IGYNCjAwMDAwMDAzNjAgNjU1MzUgZg0KMDAwMDAwMDM2MSA2NTUz NSBmDQowMDAwMDAwMzYyIDY1NTM1IGYNCjAwMDAwMDAzNjMgNjU1MzUgZg0KMDAwMDAwMDM2NCA2 NTUzNSBmDQowMDAwMDAwMzY1IDY1NTM1IGYNCjAwMDAwMDAzNjYgNjU1MzUgZg0KMDAwMDAwMDM2 NyA2NTUzNSBmDQowMDAwMDAwMzY4IDY1NTM1IGYNCjAwMDAwMDAzNjkgNjU1MzUgZg0KMDAwMDAw MDM3MCA2NTUzNSBmDQowMDAwMDAwMzcxIDY1NTM1IGYNCjAwMDAwMDAzNzIgNjU1MzUgZg0KMDAw MDAwMDM3MyA2NTUzNSBmDQowMDAwMDAwMzc0IDY1NTM1IGYNCjAwMDAwMDAzNzUgNjU1MzUgZg0K MDAwMDAwMDM3NiA2NTUzNSBmDQowMDAwMDAwMzc3IDY1NTM1IGYNCjAwMDAwMDAzNzggNjU1MzUg Zg0KMDAwMDAwMDM3OSA2NTUzNSBmDQowMDAwMDAwMzgwIDY1NTM1IGYNCjAwMDAwMDAzODEgNjU1 MzUgZg0KMDAwMDAwMDM4MiA2NTUzNSBmDQowMDAwMDAwMzgzIDY1NTM1IGYNCjAwMDAwMDAzODQg NjU1MzUgZg0KMDAwMDAwMDM4NSA2NTUzNSBmDQowMDAwMDAwMzg2IDY1NTM1IGYNCjAwMDAwMDAz ODcgNjU1MzUgZg0KMDAwMDAwMDM4OCA2NTUzNSBmDQowMDAwMDAwMzg5IDY1NTM1IGYNCjAwMDAw MDAzOTAgNjU1MzUgZg0KMDAwMDAwMDM5MSA2NTUzNSBmDQowMDAwMDAwMzkyIDY1NTM1IGYNCjAw MDAwMDAzOTMgNjU1MzUgZg0KMDAwMDAwMDM5NCA2NTUzNSBmDQowMDAwMDAwMzk1IDY1NTM1IGYN CjAwMDAwMDAzOTYgNjU1MzUgZg0KMDAwMDAwMDM5NyA2NTUzNSBmDQowMDAwMDAwMzk4IDY1NTM1 IGYNCjAwMDAwMDAzOTkgNjU1MzUgZg0KMDAwMDAwMDQwMCA2NTUzNSBmDQowMDAwMDAwNDAxIDY1 NTM1IGYNCjAwMDAwMDA0MDIgNjU1MzUgZg0KMDAwMDAwMDQwMyA2NTUzNSBmDQowMDAwMDAwNDA0 IDY1NTM1IGYNCjAwMDAwMDA0MDUgNjU1MzUgZg0KMDAwMDAwMDQwNiA2NTUzNSBmDQowMDAwMDAw NDA3IDY1NTM1IGYNCjAwMDAwMDA0MDggNjU1MzUgZg0KMDAwMDAwMDQwOSA2NTUzNSBmDQowMDAw MDAwNDEwIDY1NTM1IGYNCjAwMDAwMDA0MTEgNjU1MzUgZg0KMDAwMDAwMDQxMiA2NTUzNSBmDQow MDAwMDAwNDEzIDY1NTM1IGYNCjAwMDAwMDA0MTQgNjU1MzUgZg0KMDAwMDAwMDQxNSA2NTUzNSBm DQowMDAwMDAwNDE2IDY1NTM1IGYNCjAwMDAwMDA0MTcgNjU1MzUgZg0KMDAwMDAwMDQxOCA2NTUz NSBmDQowMDAwMDAwNDE5IDY1NTM1IGYNCjAwMDAwMDA0MjAgNjU1MzUgZg0KMDAwMDAwMDQyMSA2 NTUzNSBmDQowMDAwMDAwNDIyIDY1NTM1IGYNCjAwMDAwMDA0MjMgNjU1MzUgZg0KMDAwMDAwMDQy NCA2NTUzNSBmDQowMDAwMDAwNDI1IDY1NTM1IGYNCjAwMDAwMDA0MjYgNjU1MzUgZg0KMDAwMDAw MDQyNyA2NTUzNSBmDQowMDAwMDAwNDI4IDY1NTM1IGYNCjAwMDAwMDA0MjkgNjU1MzUgZg0KMDAw MDAwMDQzMCA2NTUzNSBmDQowMDAwMDAwNDMxIDY1NTM1IGYNCjAwMDAwMDA0MzIgNjU1MzUgZg0K MDAwMDAwMDQzMyA2NTUzNSBmDQowMDAwMDAwNDM0IDY1NTM1IGYNCjAwMDAwMDA0MzUgNjU1MzUg Zg0KMDAwMDAwMDQzNiA2NTUzNSBmDQowMDAwMDAwNDM3IDY1NTM1IGYNCjAwMDAwMDA0MzggNjU1 MzUgZg0KMDAwMDAwMDQzOSA2NTUzNSBmDQowMDAwMDAwNDQwIDY1NTM1IGYNCjAwMDAwMDA0NDEg NjU1MzUgZg0KMDAwMDAwMDQ0MiA2NTUzNSBmDQowMDAwMDAwNDQzIDY1NTM1IGYNCjAwMDAwMDA0 NDQgNjU1MzUgZg0KMDAwMDAwMDQ0NSA2NTUzNSBmDQowMDAwMDAwNDQ2IDY1NTM1IGYNCjAwMDAw MDA0NDcgNjU1MzUgZg0KMDAwMDAwMDQ0OCA2NTUzNSBmDQowMDAwMDAwNDQ5IDY1NTM1IGYNCjAw MDAwMDA0NTAgNjU1MzUgZg0KMDAwMDAwMDQ1MSA2NTUzNSBmDQowMDAwMDAwNDUyIDY1NTM1IGYN CjAwMDAwMDA0NTMgNjU1MzUgZg0KMDAwMDAwMDQ1NCA2NTUzNSBmDQowMDAwMDAwNDU1IDY1NTM1 IGYNCjAwMDAwMDA0NTYgNjU1MzUgZg0KMDAwMDAwMDQ1NyA2NTUzNSBmDQowMDAwMDAwNDU4IDY1 NTM1IGYNCjAwMDAwMDA0NTkgNjU1MzUgZg0KMDAwMDAwMDQ2MCA2NTUzNSBmDQowMDAwMDAwNDYx IDY1NTM1IGYNCjAwMDAwMDA0NjIgNjU1MzUgZg0KMDAwMDAwMDQ2MyA2NTUzNSBmDQowMDAwMDAw NDY0IDY1NTM1IGYNCjAwMDAwMDA0NjUgNjU1MzUgZg0KMDAwMDAwMDQ2NiA2NTUzNSBmDQowMDAw MDAwNDY3IDY1NTM1IGYNCjAwMDAwMDA0NjggNjU1MzUgZg0KMDAwMDAwMDQ2OSA2NTUzNSBmDQow MDAwMDAwNDcwIDY1NTM1IGYNCjAwMDAwMDA0NzEgNjU1MzUgZg0KMDAwMDAwMDQ3MiA2NTUzNSBm DQowMDAwMDAwNDczIDY1NTM1IGYNCjAwMDAwMDA0NzQgNjU1MzUgZg0KMDAwMDAwMDQ3NSA2NTUz NSBmDQowMDAwMDAwNDc2IDY1NTM1IGYNCjAwMDAwMDA0NzcgNjU1MzUgZg0KMDAwMDAwMDQ3OCA2 NTUzNSBmDQowMDAwMDAwNDc5IDY1NTM1IGYNCjAwMDAwMDA0ODAgNjU1MzUgZg0KMDAwMDAwMDQ4 MSA2NTUzNSBmDQowMDAwMDAwNDgyIDY1NTM1IGYNCjAwMDAwMDA0ODMgNjU1MzUgZg0KMDAwMDAw MDQ4NCA2NTUzNSBmDQowMDAwMDAwNDg1IDY1NTM1IGYNCjAwMDAwMDA0ODYgNjU1MzUgZg0KMDAw MDAwMDQ4NyA2NTUzNSBmDQowMDAwMDAwNDg4IDY1NTM1IGYNCjAwMDAwMDA0ODkgNjU1MzUgZg0K MDAwMDAwMDQ5MCA2NTUzNSBmDQowMDAwMDAwNDkxIDY1NTM1IGYNCjAwMDAwMDA0OTIgNjU1MzUg Zg0KMDAwMDAwMDQ5MyA2NTUzNSBmDQowMDAwMDAwNDk0IDY1NTM1IGYNCjAwMDAwMDA0OTUgNjU1 MzUgZg0KMDAwMDAwMDQ5NiA2NTUzNSBmDQowMDAwMDAwNDk3IDY1NTM1IGYNCjAwMDAwMDA0OTgg NjU1MzUgZg0KMDAwMDAwMDQ5OSA2NTUzNSBmDQowMDAwMDAwNTAwIDY1NTM1IGYNCjAwMDAwMDA1 MDEgNjU1MzUgZg0KMDAwMDAwMDUwMiA2NTUzNSBmDQowMDAwMDAwNTAzIDY1NTM1IGYNCjAwMDAw MDA1MDQgNjU1MzUgZg0KMDAwMDAwMDUwNSA2NTUzNSBmDQowMDAwMDAwNTA2IDY1NTM1IGYNCjAw MDAwMDA1MDcgNjU1MzUgZg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTA5IDY1NTM1IGYN CjAwMDAwMDA1MTAgNjU1MzUgZg0KMDAwMDAwMDUxMSA2NTUzNSBmDQowMDAwMDAwNTEyIDY1NTM1 IGYNCjAwMDAwMDA1MTMgNjU1MzUgZg0KMDAwMDAwMDUxNCA2NTUzNSBmDQowMDAwMDAwNTE1IDY1 NTM1IGYNCjAwMDAwMDA1MTYgNjU1MzUgZg0KMDAwMDAwMDUxNyA2NTUzNSBmDQowMDAwMDAwNTE4 IDY1NTM1IGYNCjAwMDAwMDA1MTkgNjU1MzUgZg0KMDAwMDAwMDUyMCA2NTUzNSBmDQowMDAwMDAw NTIxIDY1NTM1IGYNCjAwMDAwMDA1MjIgNjU1MzUgZg0KMDAwMDAwMDUyMyA2NTUzNSBmDQowMDAw MDAwNTI0IDY1NTM1IGYNCjAwMDAwMDA1MjUgNjU1MzUgZg0KMDAwMDAwMDUyNiA2NTUzNSBmDQow MDAwMDAwNTI3IDY1NTM1IGYNCjAwMDAwMDA1MjggNjU1MzUgZg0KMDAwMDAwMDUyOSA2NTUzNSBm DQowMDAwMDAwNTMwIDY1NTM1IGYNCjAwMDAwMDA1MzEgNjU1MzUgZg0KMDAwMDAwMDUzMiA2NTUz NSBmDQowMDAwMDAwNTMzIDY1NTM1IGYNCjAwMDAwMDA1MzQgNjU1MzUgZg0KMDAwMDAwMDUzNSA2 NTUzNSBmDQowMDAwMDAwNTM2IDY1NTM1IGYNCjAwMDAwMDA1MzcgNjU1MzUgZg0KMDAwMDAwMDUz OCA2NTUzNSBmDQowMDAwMDAwNTM5IDY1NTM1IGYNCjAwMDAwMDA1NDAgNjU1MzUgZg0KMDAwMDAw MDU0MSA2NTUzNSBmDQowMDAwMDAwNTQyIDY1NTM1IGYNCjAwMDAwMDA1NDMgNjU1MzUgZg0KMDAw MDAwMDU0NCA2NTUzNSBmDQowMDAwMDAwNTQ1IDY1NTM1IGYNCjAwMDAwMDA1NDYgNjU1MzUgZg0K MDAwMDAwMDU0NyA2NTUzNSBmDQowMDAwMDAwNTQ4IDY1NTM1IGYNCjAwMDAwMDA1NDkgNjU1MzUg Zg0KMDAwMDAwMDU1MCA2NTUzNSBmDQowMDAwMDAwNTUxIDY1NTM1IGYNCjAwMDAwMDA1NTIgNjU1 MzUgZg0KMDAwMDAwMDU1MyA2NTUzNSBmDQowMDAwMDAwNTU0IDY1NTM1IGYNCjAwMDAwMDA1NTUg NjU1MzUgZg0KMDAwMDAwMDU1NiA2NTUzNSBmDQowMDAwMDAwNTU3IDY1NTM1IGYNCjAwMDAwMDA1 NTggNjU1MzUgZg0KMDAwMDAwMDU1OSA2NTUzNSBmDQowMDAwMDAwNTYwIDY1NTM1IGYNCjAwMDAw MDA1NjEgNjU1MzUgZg0KMDAwMDAwMDU2MiA2NTUzNSBmDQowMDAwMDAwNTYzIDY1NTM1IGYNCjAw MDAwMDA1NjQgNjU1MzUgZg0KMDAwMDAwMDU2NSA2NTUzNSBmDQowMDAwMDAwNTY2IDY1NTM1IGYN CjAwMDAwMDA1NjcgNjU1MzUgZg0KMDAwMDAwMDU2OCA2NTUzNSBmDQowMDAwMDAwNTY5IDY1NTM1 IGYNCjAwMDAwMDA1NzAgNjU1MzUgZg0KMDAwMDAwMDU3MSA2NTUzNSBmDQowMDAwMDAwNTcyIDY1 NTM1IGYNCjAwMDAwMDA1NzMgNjU1MzUgZg0KMDAwMDAwMDU3NCA2NTUzNSBmDQowMDAwMDAwNTc1 IDY1NTM1IGYNCjAwMDAwMDA1NzYgNjU1MzUgZg0KMDAwMDAwMDU3NyA2NTUzNSBmDQowMDAwMDAw NTc4IDY1NTM1IGYNCjAwMDAwMDA1NzkgNjU1MzUgZg0KMDAwMDAwMDU4MCA2NTUzNSBmDQowMDAw MDAwNTgxIDY1NTM1IGYNCjAwMDAwMDA1ODIgNjU1MzUgZg0KMDAwMDAwMDU4MyA2NTUzNSBmDQow MDAwMDAwNTg0IDY1NTM1IGYNCjAwMDAwMDA1ODUgNjU1MzUgZg0KMDAwMDAwMDU4NiA2NTUzNSBm DQowMDAwMDAwNTg3IDY1NTM1IGYNCjAwMDAwMDA1ODggNjU1MzUgZg0KMDAwMDAwMDU4OSA2NTUz NSBmDQowMDAwMDAwNTkwIDY1NTM1IGYNCjAwMDAwMDA1OTEgNjU1MzUgZg0KMDAwMDAwMDU5MiA2 NTUzNSBmDQowMDAwMDAwNTkzIDY1NTM1IGYNCjAwMDAwMDA1OTQgNjU1MzUgZg0KMDAwMDAwMDU5 NSA2NTUzNSBmDQowMDAwMDAwNTk2IDY1NTM1IGYNCjAwMDAwMDA1OTcgNjU1MzUgZg0KMDAwMDAw MDU5OCA2NTUzNSBmDQowMDAwMDAwNTk5IDY1NTM1IGYNCjAwMDAwMDA2MDAgNjU1MzUgZg0KMDAw MDAwMDYwMSA2NTUzNSBmDQowMDAwMDAwNjAyIDY1NTM1IGYNCjAwMDAwMDA2MDMgNjU1MzUgZg0K MDAwMDAwMDYwNCA2NTUzNSBmDQowMDAwMDAwNjA1IDY1NTM1IGYNCjAwMDAwMDA2MDYgNjU1MzUg Zg0KMDAwMDAwMDYwNyA2NTUzNSBmDQowMDAwMDAwNjA4IDY1NTM1IGYNCjAwMDAwMDA2MDkgNjU1 MzUgZg0KMDAwMDAwMDYxMCA2NTUzNSBmDQowMDAwMDAwNjExIDY1NTM1IGYNCjAwMDAwMDA2MTIg NjU1MzUgZg0KMDAwMDAwMDYxMyA2NTUzNSBmDQowMDAwMDAwNjE0IDY1NTM1IGYNCjAwMDAwMDA2 MTUgNjU1MzUgZg0KMDAwMDAwMDYxNiA2NTUzNSBmDQowMDAwMDAwNjE3IDY1NTM1IGYNCjAwMDAw MDA2MTggNjU1MzUgZg0KMDAwMDAwMDYxOSA2NTUzNSBmDQowMDAwMDAwNjIwIDY1NTM1IGYNCjAw MDAwMDA2MjEgNjU1MzUgZg0KMDAwMDAwMDYyMiA2NTUzNSBmDQowMDAwMDAwNjIzIDY1NTM1IGYN CjAwMDAwMDA2MjQgNjU1MzUgZg0KMDAwMDAwMDYyNSA2NTUzNSBmDQowMDAwMDAwNjI2IDY1NTM1 IGYNCjAwMDAwMDA2MjcgNjU1MzUgZg0KMDAwMDAwMDYyOCA2NTUzNSBmDQowMDAwMDAwNjI5IDY1 NTM1IGYNCjAwMDAwMDA2MzAgNjU1MzUgZg0KMDAwMDAwMDYzMSA2NTUzNSBmDQowMDAwMDAwNjMy IDY1NTM1IGYNCjAwMDAwMDA2MzMgNjU1MzUgZg0KMDAwMDAwMDYzNCA2NTUzNSBmDQowMDAwMDAw NjM1IDY1NTM1IGYNCjAwMDAwMDA2MzYgNjU1MzUgZg0KMDAwMDAwMDYzNyA2NTUzNSBmDQowMDAw MDAwNjM4IDY1NTM1IGYNCjAwMDAwMDA2MzkgNjU1MzUgZg0KMDAwMDAwMDY0MCA2NTUzNSBmDQow MDAwMDAwNjQxIDY1NTM1IGYNCjAwMDAwMDA2NDIgNjU1MzUgZg0KMDAwMDAwMDY0MyA2NTUzNSBm DQowMDAwMDAwNjQ0IDY1NTM1IGYNCjAwMDAwMDA2NDUgNjU1MzUgZg0KMDAwMDAwMDY0NiA2NTUz NSBmDQowMDAwMDAwNjQ3IDY1NTM1IGYNCjAwMDAwMDA2NDggNjU1MzUgZg0KMDAwMDAwMDY0OSA2 NTUzNSBmDQowMDAwMDAwNjUwIDY1NTM1IGYNCjAwMDAwMDA2NTEgNjU1MzUgZg0KMDAwMDAwMDY1 MiA2NTUzNSBmDQowMDAwMDAwNjUzIDY1NTM1IGYNCjAwMDAwMDA2NTQgNjU1MzUgZg0KMDAwMDAw MDY1NSA2NTUzNSBmDQowMDAwMDAwNjU2IDY1NTM1IGYNCjAwMDAwMDA2NTcgNjU1MzUgZg0KMDAw MDAwMDY1OCA2NTUzNSBmDQowMDAwMDAwNjU5IDY1NTM1IGYNCjAwMDAwMDA2NjAgNjU1MzUgZg0K MDAwMDAwMDY2MSA2NTUzNSBmDQowMDAwMDAwNjYyIDY1NTM1IGYNCjAwMDAwMDA2NjMgNjU1MzUg Zg0KMDAwMDAwMDY2NCA2NTUzNSBmDQowMDAwMDAwNjY1IDY1NTM1IGYNCjAwMDAwMDA2NjYgNjU1 MzUgZg0KMDAwMDAwMDY2NyA2NTUzNSBmDQowMDAwMDAwNjY4IDY1NTM1IGYNCjAwMDAwMDA2Njkg NjU1MzUgZg0KMDAwMDAwMDY3MCA2NTUzNSBmDQowMDAwMDAwNjcxIDY1NTM1IGYNCjAwMDAwMDA2 NzIgNjU1MzUgZg0KMDAwMDAwMDY3MyA2NTUzNSBmDQowMDAwMDAwNjc0IDY1NTM1IGYNCjAwMDAw MDA2NzUgNjU1MzUgZg0KMDAwMDAwMDY3NiA2NTUzNSBmDQowMDAwMDAwNjc3IDY1NTM1IGYNCjAw MDAwMDA2NzggNjU1MzUgZg0KMDAwMDAwMDY3OSA2NTUzNSBmDQowMDAwMDAwNjgwIDY1NTM1IGYN CjAwMDAwMDA2ODEgNjU1MzUgZg0KMDAwMDAwMDY4MiA2NTUzNSBmDQowMDAwMDAwNjgzIDY1NTM1 IGYNCjAwMDAwMDA2ODQgNjU1MzUgZg0KMDAwMDAwMDY4NSA2NTUzNSBmDQowMDAwMDAwNjg2IDY1 NTM1IGYNCjAwMDAwMDA2ODcgNjU1MzUgZg0KMDAwMDAwMDY4OCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwNTI5NjQgMDAwMDAgbg0KMDAwMDA1MzMzMiAwMDAwMCBuDQowMDAwMDk4 NTA3IDAwMDAwIG4NCjAwMDAwOTg3NDUgMDAwMDAgbg0KMDAwMDE0MDc5MiAwMDAwMCBuDQowMDAw MTQxMjAyIDAwMDAwIG4NCjAwMDAyMDgyMjcgMDAwMDAgbg0KMDAwMDIwODU2MSAwMDAwMCBuDQow MDAwMjA4ODczIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNjk4L1Jvb3QgMSAwIFIvSW5mbyAz OCAwIFIvSURbPDE4RDFCNDlBMkQwQzQzNDlBNzJEMEM5NkYxQTkzREQzPjwxOEQxQjQ5QTJEMEM0 MzQ5QTcyRDBDOTZGMUE5M0REMz5dID4+DQpzdGFydHhyZWYNCjIxMDQ1NQ0KJSVFT0YNCnhyZWYN CjAgMA0KdHJhaWxlcg0KPDwvU2l6ZSA2OTgvUm9vdCAxIDAgUi9JbmZvIDM4IDAgUi9JRFs8MThE MUI0OUEyRDBDNDM0OUE3MkQwQzk2RjFBOTNERDM+PDE4RDFCNDlBMkQwQzQzNDlBNzJEMEM5NkYx QTkzREQzPl0gL1ByZXYgMjEwNDU1L1hSZWZTdG0gMjA4ODczPj4NCnN0YXJ0eHJlZg0KMjI0NTc1 DQolJUVPRg== --_002_9B57C850BB53634CACEC56EF4853FF653B0052A6TK5EX14MBXW604w_-- From mohamed.boucadair@orange-ftgroup.com Tue Mar 29 22:59:57 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB4B3A680E for ; Tue, 29 Mar 2011 22:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 mp4T4DkWIV1N for ; Tue, 29 Mar 2011 22:59:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id D6CA13A6A8C for ; Tue, 29 Mar 2011 22:59:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id AEC3A2640DB; Wed, 30 Mar 2011 08:01:33 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 949B735C05A; Wed, 30 Mar 2011 08:01:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 30 Mar 2011 08:01:33 +0200 From: To: Francis Dupont , "behave@ietf.org" Date: Wed, 30 Mar 2011 08:01:31 +0200 Thread-Topic: [BEHAVE] IP address status in Europe Thread-Index: AcvuI4QZEVkC6bGLRZSLwca6nYpDjAAe8XZg Message-ID: <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> In-Reply-To: <201103291510.p2TFAugP027159@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.30.52118 Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 05:59:57 -0000 Hi Francis, I think that we are focusing too much on the IP layer while personal inform= ation is leaked somewhere else. I invite you to do the test available at: h= ttps://panopticlick.eff.org/. Cheers, Med=20 -----Message d'origine----- De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de= Francis Dupont Envoy=E9 : mardi 29 mars 2011 17:11 =C0 : behave@ietf.org Objet : [BEHAVE] IP address status in Europe As I said it is too late in Europe to convince lawyers they are wrong (if you know a way to convince a lawyer or a journalist about a technical point :-), for instance: http://bits.blogs.nytimes.com/2008/01/22/europe-your-ip-address-is-personal= / Worst, I am really afraid this could give as feelings for end-users, we already had a lot of bad feedlings for IPv6 interface ID, and this has clearly more solid basis. Regards Francis.Dupont@fdupont.fr _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From scott.brim@gmail.com Tue Mar 29 23:17:45 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5B03A6AD5 for ; Tue, 29 Mar 2011 23:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 VUMo6qUPgFA6 for ; Tue, 29 Mar 2011 23:17:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B106E3A6B01 for ; Tue, 29 Mar 2011 23:17:41 -0700 (PDT) Received: by iwn39 with SMTP id 39so1035631iwn.31 for ; Tue, 29 Mar 2011 23:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=iAr+tVwqTwPEJ63F0yhuuev7NiHaC/OjhhWEnwUbnQw=; b=T8qCR/1ccwzl9PaG+HDYiuZnyq0HCDGHVnNGtO5K6S+EYXnjmEY+trRjQX72pR3Jmz zItsfkKH+uWKjkzVuWOMq1I/8neBdV8KqQr5RDdFci7xdBDOBeFnsUzZRls/M/j+Dj+w j7VWRM4JsbPQF7ECNcei+lFrjEJQpUalehWzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=goFR2MC9xCnpgiC/uJA8p/282jJIgtbIgt4p9Tk+Kwk2B1aeViVnV1u4b42kPBglGv c/kVL/Au0ISbtAyvCGSWx8+g3MWvuBHP8QVrENX/EMhXwkdWopn7SuSoobRVNJJRYF3s oykF9aIfrYE8yqcaRI5OjhHR8PvzO2Mz+9p8I= Received: by 10.42.170.8 with SMTP id d8mr700172icz.281.1301465960141; Tue, 29 Mar 2011 23:19:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.133 with HTTP; Tue, 29 Mar 2011 23:19:00 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> From: Scott Brim Date: Wed, 30 Mar 2011 08:19:00 +0200 Message-ID: To: mohamed.boucadair@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Francis Dupont , "behave@ietf.org" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:17:45 -0000 Mohamed: Are you saying confidentiality is already lost so don't bother? Since the barbarians are sneaking in a side door we might as well open all of the castle gates and invite them in for dinner? Pardon my rhetoric, but it is still possible to fix the higher layer leaks, and in the meantime we can avoid degrading the IP layer. As a general principle: we must not design the Internet such that privacy is impossible. Privacy can be voluntary, but it must be an option. For example, we must not require a user to use the same persistent identifiers in every packet, or register a mapping between IP address and any persistent identifier in DNS in order to be reachable. Thanks ... Scott On Wed, Mar 30, 2011 at 08:01, wrot= e: > Hi Francis, > > I think that we are focusing too much on the IP layer while personal info= rmation is leaked somewhere else. I invite you to do the test available at:= https://panopticlick.eff.org/. > > Cheers, > Med > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Francis Dupont > Envoy=E9 : mardi 29 mars 2011 17:11 > =C0 : behave@ietf.org > Objet : [BEHAVE] IP address status in Europe > > As I said it is too late in Europe to convince lawyers they are wrong > (if you know a way to convince a lawyer or a journalist about a > technical point :-), for instance: > > http://bits.blogs.nytimes.com/2008/01/22/europe-your-ip-address-is-person= al/ > > Worst, I am really afraid this could give as feelings for end-users, > we already had a lot of bad feedlings for IPv6 interface ID, and > this has clearly more solid basis. > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > 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 brian.e.carpenter@gmail.com Tue Mar 29 23:30:55 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264DC3A6B01 for ; Tue, 29 Mar 2011 23:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 idpybPwQgw7B for ; Tue, 29 Mar 2011 23:30:53 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8CEFB3A6B02 for ; Tue, 29 Mar 2011 23:30:53 -0700 (PDT) Received: by bwz13 with SMTP id 13so787914bwz.31 for ; Tue, 29 Mar 2011 23:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+5ypJqDUxzXcd1u3HtwO8tpos1NSkofq6/ySqCHZp1E=; b=HrAnxYtLwnAEOlorP4PraFobjvdC1Ym4oVPOCyWVKkTGQvssFr8y0wTq9vjNpqYXhy QoHPKyE4eNRC8YGf9PHOKvzlf9q0+2Ijc1lKTIgWjxGub5jYi/LURokro+l+Re4soZbK ncvfuq0mS3o+IrpPwqJUUyQP/VS4YzPGP6fxM= 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=ok6lu6tz5PBbwbBcwBIOjZMiB5xncZx6l9271/Um4Yg0d5VEH8AlXV2AARPNK1j/xG VNdhQOTmmVTC16jhq+9o+XJOUzF1y4BBo1Khm1OhVyWIRrVjGZ1+ieYAeRb/eNUMHGE1 SKA+WIei6Xn1dkLJk2DLQPPXjUTul0VBgepPI= Received: by 10.204.22.194 with SMTP id o2mr682884bkb.67.1301466751036; Tue, 29 Mar 2011 23:32:31 -0700 (PDT) Received: from [130.129.68.91] (dhcp-445b.meeting.ietf.org [130.129.68.91]) by mx.google.com with ESMTPS id x6sm3855335bkv.0.2011.03.29.23.32.29 (version=SSLv3 cipher=OTHER); Tue, 29 Mar 2011 23:32:29 -0700 (PDT) Message-ID: <4D92CE79.3020100@gmail.com> Date: Wed, 30 Mar 2011 19:32:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.org" , Francis Dupont , mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:30:55 -0000 In any case, the point Francis was making, I think, is that it doesn't matter what we think. If the EU legislators believe that IP addresses are private information, then they *are* private information, by law. Of course, the same applies even more strongly to any kind of Host ID - it inevitably will become protected by privacy legislation as soon as the legislators are aware of it. Regards Brian Carpenter On 2011-03-30 19:19, Scott Brim wrote: > Mohamed: Are you saying confidentiality is already lost so don't > bother? Since the barbarians are sneaking in a side door we might as > well open all of the castle gates and invite them in for dinner? > Pardon my rhetoric, but it is still possible to fix the higher layer > leaks, and in the meantime we can avoid degrading the IP layer. >=20 > As a general principle: we must not design the Internet such that > privacy is impossible. Privacy can be voluntary, but it must be an > option. >=20 > For example, we must not require a user to use the same persistent > identifiers in every packet, or register a mapping between IP address > and any persistent identifier in DNS in order to be reachable. >=20 > Thanks ... Scott >=20 > On Wed, Mar 30, 2011 at 08:01, = wrote: >> Hi Francis, >> >> I think that we are focusing too much on the IP layer while personal i= nformation is leaked somewhere else. I invite you to do the test availabl= e at: https://panopticlick.eff.org/. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la pa= rt de Francis Dupont >> Envoy=C3=A9 : mardi 29 mars 2011 17:11 >> =C3=80 : behave@ietf.org >> Objet : [BEHAVE] IP address status in Europe >> >> As I said it is too late in Europe to convince lawyers they are wrong >> (if you know a way to convince a lawyer or a journalist about a >> technical point :-), for instance: >> >> http://bits.blogs.nytimes.com/2008/01/22/europe-your-ip-address-is-per= sonal/ >> >> Worst, I am really afraid this could give as feelings for end-users, >> we already had a lot of bad feedlings for IPv6 interface ID, and >> this has clearly more solid basis. >> >> Regards >> >> Francis.Dupont@fdupont.fr >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From mohamed.boucadair@orange-ftgroup.com Tue Mar 29 23:47:18 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB713A6B12 for ; Tue, 29 Mar 2011 23:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 gB3jyRjzEI3q for ; Tue, 29 Mar 2011 23:47:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 96BEC3A67F8 for ; Tue, 29 Mar 2011 23:47:15 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 17840C0129; Wed, 30 Mar 2011 08:48:53 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id F414338403A; Wed, 30 Mar 2011 08:48:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 30 Mar 2011 08:48:52 +0200 From: To: Scott Brim Date: Wed, 30 Mar 2011 08:48:51 +0200 Thread-Topic: [BEHAVE] IP address status in Europe Thread-Index: AcvuomiLzmO52B6nQJGztGpT5f/ciwAAvUvQ Message-ID: <94C682931C08B048B7A8645303FDC9F33C4F2B3E47@PUEXCB1B.nanterre.francetelecom.fr> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.30.61230 Cc: Francis Dupont , "behave@ietf.org" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:47:18 -0000 Dear Scott, The point I wanted to make is that as a user I have more concern about the = leak of my informational information (e.g., name, login, profiles, personal= url, etc) at the application layer than revealing my source IP address (wh= ich is not IMO a privacy concern; since in today's internet my IP address i= s seen by the servers!). I'm more concerned about the usage of some http headers such as referrer, e= tc. You can find more reading at: I know what you will do next summer Balachander Krishnamurthy ACM SIGCOMM Computer Communication Review, Volume 40, Number 5, October 201= 0 Privacy Leakage in Mobile Online Social Networks Balachander Krishnamurthy and Craig Wills Proceedings of Workshop on Online Social Networks, June 2010 Prediction Promotes Privacy In Dynamic Social Networks Smriti Bhagat, Graham Cormode, Balachander Krishnamurthy, Divesh Srivastava Proceedings of Workshop on Online Social Networks, June 2010 How much is too much? Privacy issues on Twitter Lee Humphreys, Phillipa Gill, Balachander Krishnamurthy Conference of International Communication Association, June 2010 On the Leakage of Personally Identifiable Information Via Online Social Net= works Balachander Krishnamurthy and Craig Wills Proceedings of ACM SIGCOMM Workshop on Online Social Networks, August 2009 Privacy Diffusion on the Web: A Longitudinal Perspective Balachander Krishnamurthy and Craig E. Wills Proceedings of the World Wide Web Conference, April 2009 Characterizing Privacy in Online Social Networks Balachander Krishnamurthy and Craig Wills Proceedings of ACM SIGCOMM Workshop on Online Social Networks, August 2008 Measuring privacy loss and the impact of privacy protection in Web browsing Balachander Krishnamurthy and Delfina Malandrino and Craig E. Wills Proceedings of the Symposium on Usable Privacy and Security, July 2007 Generating a Privacy Footprint on the Internet Balachander Krishnamurthy and Craig Wills Proceedings of IMC 2006, October 2006=20 BTW, I agree with you general principal but if applied at all levels and if= there is a "coordination" between layers. This big-picture view of privacy= is missing. Cheers, Med -----Message d'origine----- De : Scott Brim [mailto:scott.brim@gmail.com]=20 Envoy=E9 : mercredi 30 mars 2011 08:19 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Francis Dupont; behave@ietf.org Objet : Re: [BEHAVE] IP address status in Europe Mohamed: Are you saying confidentiality is already lost so don't bother? Since the barbarians are sneaking in a side door we might as well open all of the castle gates and invite them in for dinner? Pardon my rhetoric, but it is still possible to fix the higher layer leaks, and in the meantime we can avoid degrading the IP layer. As a general principle: we must not design the Internet such that privacy is impossible. Privacy can be voluntary, but it must be an option. For example, we must not require a user to use the same persistent identifiers in every packet, or register a mapping between IP address and any persistent identifier in DNS in order to be reachable. Thanks ... Scott On Wed, Mar 30, 2011 at 08:01, wrot= e: > Hi Francis, > > I think that we are focusing too much on the IP layer while personal info= rmation is leaked somewhere else. I invite you to do the test available at:= https://panopticlick.eff.org/. > > Cheers, > Med > > -----Message d'origine----- > De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part = de Francis Dupont > Envoy=E9 : mardi 29 mars 2011 17:11 > =C0 : behave@ietf.org > Objet : [BEHAVE] IP address status in Europe > > As I said it is too late in Europe to convince lawyers they are wrong > (if you know a way to convince a lawyer or a journalist about a > technical point :-), for instance: > > http://bits.blogs.nytimes.com/2008/01/22/europe-your-ip-address-is-person= al/ > > Worst, I am really afraid this could give as feelings for end-users, > we already had a lot of bad feedlings for IPv6 interface ID, and > this has clearly more solid basis. > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > 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 scott.brim@gmail.com Tue Mar 29 23:48:26 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FAD03A6982 for ; Tue, 29 Mar 2011 23:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 9PnjoZ5kL5xp for ; Tue, 29 Mar 2011 23:48:25 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7D45F3A6B0D for ; Tue, 29 Mar 2011 23:48:25 -0700 (PDT) Received: by iwn39 with SMTP id 39so1061526iwn.31 for ; Tue, 29 Mar 2011 23:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ku4sKmeTPoYFZPm3AUhak69sMZTLjSazQvIs/QKjiNc=; b=ng11ADNXtuRvOj9LzhYxSQKQbxSXvt8uuJHpqigyuhQock3tH04Lr4OmA650XWjxTD 04NPKo38jd+f4vYjVUIj9asYfvl2l+RTacm9r+mAPKqZ+pSaJSZZAdSg0ko/WkQI2wAw nW+5eHb1bE6X+oymnFoSG8ijjCyae0bAzc3uU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=q3F7VtWy11xlmlKyTISzF1+rHq3DGpVSLy72IxtSWbSsvugOUHb5KP5COhtb+WRKDH 5dAvO3/jpy1h/crAHiGzctCEDZmvHJDy3rsnM5WO0t9vRGMYMGPJnOf1fYGuu1Qmi2XM q7fygZxqIOPu1dsqeiMuGLp2oAMbt2QXblfm0= Received: by 10.43.61.148 with SMTP id ww20mr753208icb.482.1301467804160; Tue, 29 Mar 2011 23:50:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.133 with HTTP; Tue, 29 Mar 2011 23:49:44 -0700 (PDT) In-Reply-To: <4D92CE79.3020100@gmail.com> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> <4D92CE79.3020100@gmail.com> From: Scott Brim Date: Wed, 30 Mar 2011 08:49:44 +0200 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.org" , Francis Dupont , mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:48:26 -0000 On Wed, Mar 30, 2011 at 08:32, Brian E Carpenter wrote: > In any case, the point Francis was making, I think, is that > it doesn't matter what we think. If the EU legislators believe > that IP addresses are private information, then they *are* > private information, by law. Well, yes :-). > Of course, the same applies even more > strongly to any kind of =A0Host ID - it inevitably will become protected > by privacy legislation as soon as the legislators are aware of it. It doesn't have to be that way. Use of a "host ID', or any other identifier at any level, doesn't have to clash with privacy. The trick is to design the Internet and its protocols such that identifiers don't have to be leaked outside of their scopes of confidentiality (note that concept, scope of confidentiality, it's pivotal), and then to discipline Internet services to use identifiers only within their scope of confidentiality. Pardon me, as you can see this is something I easily get riled up about. See privacy work going on elsewhere e.g. IAB. Scott From scott.brim@gmail.com Tue Mar 29 23:53:46 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2FF3A6A46 for ; Tue, 29 Mar 2011 23:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 FB5N1dqaH-Kn for ; Tue, 29 Mar 2011 23:53:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7E89E3A6826 for ; Tue, 29 Mar 2011 23:53:45 -0700 (PDT) Received: by iye19 with SMTP id 19so1064539iye.31 for ; Tue, 29 Mar 2011 23:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qmlbdy6vhFPJWZhuDJX18QO4LEmGzGr2HXDi6LTfzug=; b=O5q2q0rKO5yXeYzKyDvdJ3+8x/Hc5MBdDrftRS6K551T6SJ4sWtvL4/j8v1PtVL/ff ySaFXYwJ3ifa1XO3BAR02YmLn6wbtGQl6TSmH3iv0O+PyR2Nu2763hUJsWy4NTXS2pm/ Z+mpzbFMvHjbms3l7OrX8MUzFXRobLZ65BVNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=pjtWVXFDHvZSgvQIPtUGUziTzygIyjJSqGJCi6NlQvmiWgQRnW5ekU0gRF6pla5lMn tl4zQNTeceNBn9xCMZU6fs6lOExoTkFY6ML0YAqrxYjE7seIlu5ROX3Ae0WO/CUQ949b K6eAA0ThZO4EpNe8+pPsz6M9+mnVWNqplV5vE= Received: by 10.42.117.68 with SMTP id s4mr785080icq.348.1301468124165; Tue, 29 Mar 2011 23:55:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.133 with HTTP; Tue, 29 Mar 2011 23:55:03 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4F2B3E47@PUEXCB1B.nanterre.francetelecom.fr> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E47@PUEXCB1B.nanterre.francetelecom.fr> From: Scott Brim Date: Wed, 30 Mar 2011 08:55:03 +0200 Message-ID: To: mohamed.boucadair@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Francis Dupont , "behave@ietf.org" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:53:46 -0000 On Wed, Mar 30, 2011 at 08:48, wrot= e: > Dear Scott, > > The point I wanted to make is that as a user I have more concern about th= e leak of my informational information (e.g., name, login, profiles, person= al url, etc) at the application layer than revealing my source IP address (= which is not IMO a privacy concern; since in today's internet my IP address= is seen by the servers!). Yes, me too. Sorry. I just want to be sure that while we are fighting those battles, we do not design away even the possibility of privacy in the lower layers. Thanks ... Scott From huitema@microsoft.com Tue Mar 29 23:56:22 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0253A67F8 for ; Tue, 29 Mar 2011 23:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFXiKFPaWoQd for ; Tue, 29 Mar 2011 23:56:22 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 127F13A6B02 for ; Tue, 29 Mar 2011 23:56:22 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Mar 2011 23:58:00 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 29 Mar 2011 23:58:00 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.185]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Tue, 29 Mar 2011 23:58:00 -0700 From: Christian Huitema To: "mohamed.boucadair@orange-ftgroup.com" , Scott Brim Thread-Topic: [BEHAVE] IP address status in Europe Thread-Index: AQHL7iOFzllfr7SD8Eyqfmr4cutFOpRF2OaAgAAE4wCAAAhXgP//iwiQ Date: Wed, 30 Mar 2011 06:57:59 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F0EC744@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E47@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C4F2B3E47@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Francis Dupont , "behave@ietf.org" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 06:56:23 -0000 > The point I wanted to make is that as a user I have more concern about th= e leak of my informational information (e.g., name, login, profiles, person= al url, etc) at the application layer than revealing my source IP address (= which is not IMO a privacy concern; since in today's internet my IP address= is seen by the servers!). That's indeed an issue. But application level information should be dealt w= ith by application level developers. And at least some are indeed doing tha= t, if we see the work on deployment of encryption or on privacy filters in = various web browsers. On the other hand, nobody but us deals with the IP ad= dresses, so it is indeed our job to get that one right. By the way, it is not just the network layer. You can see information leaka= ge at lower layers as well. Some EAP variants can leak identities. (The bet= ter EAP variants are protected.) The Wi-Fi clients that attempt to connect = to "hidden networks" broadcast their home network SSID. Many host will tell= a lot of information inside their DHCP requests. Many hosts emit a pattern= of DNS requests when they start up or when they connect to a new network.= =20 It may be a game of whack-a-mole, but it is time for every IETF group to st= art whacking their respective moles... -- Christian Huitema From scott.brim@gmail.com Wed Mar 30 00:14:36 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80193A67FD for ; Wed, 30 Mar 2011 00:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 fKayql2XluEL for ; Wed, 30 Mar 2011 00:14:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6265B28C0FA for ; Wed, 30 Mar 2011 00:14:35 -0700 (PDT) Received: by iwn39 with SMTP id 39so1085571iwn.31 for ; Wed, 30 Mar 2011 00:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=wHvtj/3HCqX2oKv3Zx2C1yAXO3r2ofewve5IAWUzydU=; b=PII9GArBYXpHAlWD2kf5Xl28MvVeygqzyRozs5tSJL+szLyitAAOXQsAGGD9iWTocI TEJpksrCaVJie/quSYeFlC5cvWDo5X5VHgpBArOQX9bn7Kz3oZCNShpq+OuGMYOzL5gi lbafCHYHPjPWLcpMyjEGpD4KloAq6fGYybgyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SJUzBdKT7QksIQHK4F/XQ3HSwmTiXADmPVdV3jNMeCsyEAWoCzUGeNRRr9yFmQCwVu P1vb+W+sC0n+Y6bdm/sP1xHGPWuIjH+URXpj2a9gJQelyg25vrRs1tU0JIb/+LRuHwQV VT9b+98uhk4Bw4V6GcLcuFv784oL7FZ+r7pP0= Received: by 10.42.117.68 with SMTP id s4mr812676icq.348.1301469373950; Wed, 30 Mar 2011 00:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.133 with HTTP; Wed, 30 Mar 2011 00:15:53 -0700 (PDT) In-Reply-To: <22F6318E46E26B498ABC828879B08D4F0EC744@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E47@PUEXCB1B.nanterre.francetelecom.fr> <22F6318E46E26B498ABC828879B08D4F0EC744@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> From: Scott Brim Date: Wed, 30 Mar 2011 09:15:53 +0200 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "behave@ietf.org" , Francis Dupont , "mohamed.boucadair@orange-ftgroup.com" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 07:14:37 -0000 On Wed, Mar 30, 2011 at 08:57, Christian Huitema wr= ote: > By the way, it is not just the network layer. You can see information lea= kage at lower layers as well. Some EAP variants can leak identities. (The b= etter EAP variants are protected.) The Wi-Fi clients that attempt to connec= t to "hidden networks" broadcast their home network SSID. Many host will te= ll a lot of information inside their DHCP requests. Many hosts emit a patte= rn of DNS requests when they start up or when they connect to a new network= . and I'm told that GSM sends IMSIs in the clear, for anyone to read. > It may be a game of whack-a-mole, but it is time for every IETF group to = start whacking their respective moles... Yes! (Also we need to whack the occasional regulatory moles. They have assumptions about technology that are sometimes just wrong. One of the foundations of a successful Internet is creating a good cultural and policy environment for it.) OK I'll shut up now. Thanks ... Scott From brian.e.carpenter@gmail.com Wed Mar 30 00:51:04 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44D628C0EF for ; Wed, 30 Mar 2011 00:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 843hLbN1sVvR for ; Wed, 30 Mar 2011 00:51:01 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6B4AA28C105 for ; Wed, 30 Mar 2011 00:50:56 -0700 (PDT) Received: by bwz13 with SMTP id 13so828171bwz.31 for ; Wed, 30 Mar 2011 00:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/iGkJqFMIyonXYGg+O3DHun8QgEaaDm3QNoE6G9taQ8=; b=J/Cn/LafqVyfYACQmy9/BhMhSpSfHvGF8anLERGAl2ImWdbFP8EA1gDnVIBBbPQxP6 G9bPdwNLrvvbTMRm6draVUfA2XcUaKPPp4ZmjmCQqmjCpidTt34S35xu9t5Y/HjFFEhE OJjoAFNdvgKMakPR9h/2xICMdecnqNBZHvVj0= 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=OFEei1iP3crkLs7u7hLIbm01gUR+0U6corf6xwZhvcBjB4ucUCzIDPYPGMlg6fmBpN 6r9OBPA4kR2rN/DzQv3VaVF4nwUBSwXBzcQqKVe+kp5+VEvCpcH/WSLt2fy3FljkZ/iq 4JA0sKjoJxqfE9FNzmztQS+myH81yI5klM41U= Received: by 10.204.14.137 with SMTP id g9mr343953bka.134.1301471553285; Wed, 30 Mar 2011 00:52:33 -0700 (PDT) Received: from [130.129.22.150] (dhcp-1696.meeting.ietf.org [130.129.22.150]) by mx.google.com with ESMTPS id l1sm3889137bkl.13.2011.03.30.00.52.31 (version=SSLv3 cipher=OTHER); Wed, 30 Mar 2011 00:52:32 -0700 (PDT) Message-ID: <4D92E13B.3070903@gmail.com> Date: Wed, 30 Mar 2011 20:52:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> <4D92CE79.3020100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , Francis Dupont , mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 07:51:04 -0000 Scott, On 2011-03-30 19:49, Scott Brim wrote: > On Wed, Mar 30, 2011 at 08:32, Brian E Carpenter > wrote: >> In any case, the point Francis was making, I think, is that >> it doesn't matter what we think. If the EU legislators believe >> that IP addresses are private information, then they *are* >> private information, by law. > > Well, yes :-). > >> Of course, the same applies even more >> strongly to any kind of Host ID - it inevitably will become protected >> by privacy legislation as soon as the legislators are aware of it. > > It doesn't have to be that way. Use of a "host ID', or any other > identifier at any level, doesn't have to clash with privacy. The > trick is to design the Internet and its protocols such that > identifiers don't have to be leaked outside of their scopes of > confidentiality (note that concept, scope of confidentiality, it's > pivotal), and then to discipline Internet services to use identifiers > only within their scope of confidentiality. I suspect that is exactly what the legislator is likely to require, for any 'magic number' that is specific to an individual customer. Brian Pardon me, as you can see > this is something I easily get riled up about. See privacy work going > on elsewhere e.g. IAB. > > Scott > From denghui02@gmail.com Wed Mar 30 01:46:52 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573B428C0DD for ; Wed, 30 Mar 2011 01:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 JiMmacAg8huu for ; Wed, 30 Mar 2011 01:46:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4662128C0CF for ; Wed, 30 Mar 2011 01:46:51 -0700 (PDT) Received: by iwn39 with SMTP id 39so1175530iwn.31 for ; Wed, 30 Mar 2011 01:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yu4OcNJtvEKr5zwFfxqL9fevi0Zwo7AxxG1awfS9350=; b=bw84c3/Sy1DCUNXoeEWLUUH2ERTXYWmQJTeY2gF9uItiasOFt+KBGS0fDbXV8CY6EQ CbgNrcwpBRDSdHnUokaxXV0JbQGZrf71/Dq4DDKGADp+Ttz6gi7txXp5tPXE/Rk85XwS M/kfhADUu7DB6wcDY2p1zTZRQC87wy0N/BHV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OPAl0p4vxP3YqaRhhRrHgHcyXvzDvCPPsFdk9jvPxY4qSpxLkzfwxtH1MGd8flUgnK Fe8jRX/iCWKqYKi2hZT657uyjYXr+e3bSJLlXIljIfJ/xy/+EObv5LQU68/DS2PVrSO0 Eady6zSsx6I+WJdTCiDWO/slkTdiL1/qF12xU= MIME-Version: 1.0 Received: by 10.42.141.195 with SMTP id p3mr791079icu.409.1301474909856; Wed, 30 Mar 2011 01:48:29 -0700 (PDT) Received: by 10.42.219.10 with HTTP; Wed, 30 Mar 2011 01:48:29 -0700 (PDT) In-Reply-To: <4D91E349.40005@piuha.net> References: <4D91E349.40005@piuha.net> Date: Wed, 30 Mar 2011 10:48:29 +0200 Message-ID: From: Hui Deng To: Jari Arkko Content-Type: multipart/alternative; boundary=90e6ba6134deafa1c6049faf3d36 Cc: Behave WG Subject: Re: [BEHAVE] comment on draft-ietf-behave-v4v6-bih X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 08:46:52 -0000 --90e6ba6134deafa1c6049faf3d36 Content-Type: text/plain; charset=ISO-8859-1 Jari, Maybe the text should explain the reason other than recommending other solution, then proposed text below: "Use of BIH together with a NAT64 is NOT RECOMMENDED as a replacement for tunneling based transition solutions." Regards, -Hui 2011/3/29 Jari Arkko > I think the scoping and recommendations in this document is fine. However, > I would reformulate this: > > Use of BIH together with a >> NAT64 is NOT RECOMMENDED as a competing technology for tunneling >> based transition solutions. >> >> > > as follows: "Use of BIH together with a NAT64 is NOT RECOMMENDED. Tunneling > based transition solutions are recommended instead." > > Jari > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --90e6ba6134deafa1c6049faf3d36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jari,
=A0
Maybe the text should explain the reason other than recommending other= solution, then proposed text below:
"Use of BIH together with a=A0 NAT64 is NOT RECOMMENDED as a repl= acement for tunneling
=A0 based transition solutions."

Regar= ds,
=A0
-Hui
=A0
2011/3/29 Jari Arkko <jari.arkko@piuha.net>
I think the scoping and recommen= dations in this document is fine. However, I would reformulate this:
Use of BIH together with a
= =A0 NAT64 is NOT RECOMMENDED as a competing technology for tunneling
=A0= based transition solutions.
=A0

as follows: "Use of BIH together with a NAT64 = is NOT RECOMMENDED. Tunneling based transition solutions are recommended in= stead."

Jari

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

--90e6ba6134deafa1c6049faf3d36-- From iljitsch@muada.com Wed Mar 30 02:25:48 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B743028C106 for ; Wed, 30 Mar 2011 02:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3cxsnAVXU1fS for ; Wed, 30 Mar 2011 02:25:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id DED7728C111 for ; Wed, 30 Mar 2011 02:25:46 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.51]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p2U9T0hf019102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Mar 2011 11:29:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4D92CE79.3020100@gmail.com> Date: Wed, 30 Mar 2011 11:27:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <210B345F-1544-4607-AFD7-4F3A7AC3CFF4@muada.com> References: <201103291510.p2TFAugP027159@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> <4D92CE79.3020100@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "behave@ietf.org" , Francis Dupont , Scott Brim , mohamed.boucadair@orange-ftgroup.com Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 09:25:48 -0000 On 30 mrt 2011, at 8:32, Brian E Carpenter wrote: > In any case, the point Francis was making, I think, is that > it doesn't matter what we think. If the EU legislators believe > that IP addresses are private information, then they *are* > private information, by law. Believe me, things aren't that simple. Also I don't know if "private information" is a good term here. In Dutch = we say "persoonsgegeven", which translates as "personally identifiable = information". In other words, any piece of information that identifies a = person. There have been huge discussions on whether an IP address is that. There = have been a few court decisions in Europe but those tend to ignore = relevant information such as the lease time and whether NAT is involved. = But even if IP addresses are personally identifiable information, that = doesn't mean you never get to see or use it under any circumstances. An = address or phone number certainly fall in this category yet these are = widely used and stored. Or even sold. About a host identifier: one way to avoid many issues here would be to = have a different one for each site. So when I talk to Google and Bing = they don't see a request coming from "iljitsch' computer" but from = sha256("Google", "iljitsch' computer", "Google") and sha256("Bing", = "iljitsch' computer", "Bing"). (I put the service in there twice to = thwart precomputation attacks.) Cookies also have this limitation. Of course the use of ad networks = largely invalidates that layer of protection, which is a source of = concern both for existing stuff and future stuff.= From Francis.Dupont@fdupont.fr Wed Mar 30 02:34:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138A028C122 for ; Wed, 30 Mar 2011 02:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0D9o3ISJoRB for ; Wed, 30 Mar 2011 02:34:43 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id AC11228C0E0 for ; Wed, 30 Mar 2011 02:34:42 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p2U9aKtD094914; Wed, 30 Mar 2011 11:36:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201103300936.p2U9aKtD094914@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Wed, 30 Mar 2011 08:01:31 +0200. <94C682931C08B048B7A8645303FDC9F33C4F2B3E35@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 30 Mar 2011 11:36:20 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "behave@ietf.org" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 09:34:44 -0000 In your previous mail you wrote: I think that we are focusing too much on the IP layer while personal information is leaked somewhere else. => CGNs are L3/4 beasts so I can't see why to focus on IP and transport layers are bad. And if a CGN does something perceived as wrong for privacy the ISP will be sued, so as an ISP employee this should be important. And it is clearly in the scope of BEHAVE. I invite you to do the test available at: https://panopticlick.eff.org/. => I don't want to imagine what the EFF could think about HOST_ID and other anti-privacy proposals... More seriously the fact some act badly is never an excuse to act badly yourself. Regards Francis.Dupont@fdupont.fr From iljitsch@muada.com Wed Mar 30 03:04:13 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3522828C0E2 for ; Wed, 30 Mar 2011 03:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 J7rw9Pme1IuW for ; Wed, 30 Mar 2011 03:04:12 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by core3.amsl.com (Postfix) with ESMTP id D5B6B28C0D6 for ; Wed, 30 Mar 2011 03:04:11 -0700 (PDT) Received: from claw.it.uc3m.es ([163.117.139.51]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p2UA7TDS019331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Mar 2011 12:07:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <201103300936.p2U9aKtD094914@givry.fdupont.fr> Date: Wed, 30 Mar 2011 12:05:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201103300936.p2U9aKtD094914@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1084) Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] IP address status in Europe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 10:04:13 -0000 On 30 mrt 2011, at 11:36, Francis Dupont wrote: > I invite you to do the test available at: = https://panopticlick.eff.org/. Hm, I find this suspicous: it tells me my iPhone is unique among 1.5 = million systems tested so far. Yet the iPhone doesn't allow the user to = install any fonts or plugins. So apparently it's mostly the combination = of the user agent string (new version of the iPhone firmware came out a = few days ago) and my timezone that makes me unique. I'm not impressed. Of course on the desktop the fonts and plugins do make it possible to = really fingerprint your system. From tena@huawei.com Wed Mar 30 06:17:44 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11FE28C169; Wed, 30 Mar 2011 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_00=-2.599, 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 TupfPNTwNwTp; Wed, 30 Mar 2011 06:17:43 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 8B74328C164; Wed, 30 Mar 2011 06:17:43 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00M7YH0AH7@usaga01-in.huawei.com>; Wed, 30 Mar 2011 08:19:22 -0500 (CDT) Received: from TingZousc1 (dhcp-13d6.meeting.ietf.org [130.129.19.214]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIV00J4TH06XP@usaga01-in.huawei.com>; Wed, 30 Mar 2011 08:19:22 -0500 (CDT) Date: Wed, 30 Mar 2011 15:19:19 +0200 From: Tina Tsou In-reply-to: To: softwires@ietf.org, behave@ietf.org, mboned@ietf.org, 'IPv6 Ops WG' Message-id: <026801cbeedd$14ba2e00$3e2e8a00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_V9muBR498hK4gFFKugcayw)" Content-language: en-us Thread-index: AcvuL6fFhcBvvwkUTCOg/Wh+n096dwArU6oA References: Subject: Re: [BEHAVE] IPv4-IPv6 Multicast meeting on Wed 3:10 PM-4:10 PM X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 13:17:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_V9muBR498hK4gFFKugcayw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Attached please find the proposal from multiple authors. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Tuesday, March 29, 2011 6:38 PM To: 'softwires@ietf.org'; 'behave@ietf.org'; 'mboned@ietf.org'; 'IPv6 Ops WG' Subject: IPv4-IPv6 Multicast meeting on Wed 3:10 PM-4:10 PM Hi all, Per suggestion from the chairs and audience of today's behave meeting, I'm forwarding the following meeting info to the related WGs. You are welcome to join. Subject: IPv4-IPv6 Multicast meeting: summary of this week and next steps When: Wednesday, March 30, 2011 3:10 PM-4:10 PM Prague. Where: Room Tyrolka, Level M We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html --Boundary_(ID_V9muBR498hK4gFFKugcayw) Content-type: application/pdf; name="Proposed Organization of Problem Statement.pdf" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Proposed Organization of Problem Statement.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nJ1QTUsDQQy9z6/IudA1mczXwjLQ1u7BW2HBg3izVaQK9uLf92W2VfSg IIFJJsl7eQl3Qu/ujZiW3HnKvXaJYh8Rn/budkGvTsjs9OjYCvTirCm3+Ehz3LDHC4kFc/XJHRZG 3pXkc4AXzT6iDLb15BRzIgXDTA90NWJOoOkwsNTp2W0nt/sFHGKnhi3/wIpnW9P3oGhoT5qAvgOc PWtdysCBlSOnFmcu3Fc/oLhqiTVvmr/mLeIRfgZt0KjCXKz5k0tEfF0ik0RRup9u/lKoErBZKP0P fRIwzAYaUzqPHL8xNjvvqQEH9qFcLgweP/PEKsIDtKopLVXKnFPsJsnEiolXW7lIxkT7iEqpGa14 I15pRxkNYu3sZQXaZJ0e1qobTjzK+kvjjj4AYcGE6QplbmRzdHJlYW0KZW5kb2JqCgozIDAgb2Jq CjMwMgplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nJ1VS2/TQBC++1fsGSlmZ/bhtWRZSuL4wK1SJA6IGxSEChK98PeZxz5MS0KCqrar ndc38307tj2YX91PY83O9miG0fXRhDHQ+flz9/6N+dGB4Z/nL51lg/nesdMg5yejZ4l9Kkn4oNav 3eMbTt6niIOn/+AGDGSmbIdz56hOMJ5jzp/M25XqeHN+nCzM52/d6dw9XAn2oXccm/4jFj1wB3ak 7iUajYsU/YHCLVpn/byDif4HG+0g5zTjBMd5R38Xe5Arb1cyow3zx/O7WlJ+MsREnXkXe69VnAHs 42uUm5CBx+mdZTcFhkmAwYkAULkjl2QY9gA4CzDFopcOQK8juGYNdp13nkI4xypX2c4J16v43Qhl Srfid4m5uQc/ECjHAz8S1oWvh+aXEcs1eUgnF2eekDEH2MxcNHIFM9iBQftIYiygvaohMuvjvAuT 3ecjTGizIvgMhAoW7s2xg86+2UlJ2aT4j42BJGmXOTA/6rzKlXgX4pgyxG1KALYLlZJtyDhCLjHU EoTr6pTAFZpun5JNZbL3TmkDWfusPUPrOUzgNpPiU7k4SZ2c0Ik05H7dpNExYR6UbePMV4SvVnM6 vJpSmAqiw7gNkZwY5jTltZCty1zODBVoF1x9RxhHmt9d7wij68cX7wjjLLqI5eHwMvJ6c/1RII4l 2810I4a2IjPdtDiooIxL5V6eZ5hwYBOs+iAy37tCZqwRCt3P5OsxKe843qCjvRiBAwMrAA90xOOl vgF4w8PoyxeGGpdXTo3jpcbl2wC09doKRtX5IKJTArRRK+0sLAyWNZ2cavc6oAj3AwrpNSBBQcVV pSLCBSxRoeAS/epDOVbMBHGo/gr/kEkUY8bPRtpKOLbcI5ECQgqN3NpED/IgflJf/khhLbYXU7J5 IRJ3ixCmfnm1R3necyxwJHJVoJdZFTUDKTPdqWbAl1ouXxvR536zwOs2+lPL+BcpB+rqJGLGJP2n tmOwXRCNL31ukrxvD4ihyrdA9k/YrD+ItepmAZbttN2PEuqz15J3ibZ7SbMyu/aG2iKosyKdrW2H atN8j2veUa4CAbsBUh3/uUKF8wh3Eh7i6+2Vv56Cy1neJND4quTiquyTvc60qaL55b7l+9YYp7y1 jwfzG8TVcL0KZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iago4NTUKZW5kb2JqCgo4IDAgb2JqCjw8 L0xlbmd0aCA5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydU8uK3EAMvPdX9HnB jh79sME0ZDzrw94GDDmE3LIPwiSwc9nfX0lte4YNMUkweDRqlVRVakOL/s29evANtORzz23ysY8S Xx7dlzv/y6HX5/LsQA/8T6dF2eKzr7Fhz2sTDerpi3u60+ZtlygH+UXOFOVYuh1mxzIn+qCY+bv/ NMmc4OenAbDMP9z97E474BBbVmz3H1jMWcARelFvaPKcBP1V4EDAEIBLgwNESJAt6goNOJZG3kc4 QLDkJElIFpLUag31OC3gESbGIoF1oLF8mx82ZvYsSjoxIHBqQyXDHqlNv4u5gWR1PTBoWeVP3cJf KZHyBEZE0vkJuZgEZXWAmpMg/olRR8KI+yRDVkZm9A4jhCzV3OO6EKEUjBKqmWJMMGY4lYbVNNoI aTjqKy/JOMBnK65GVmT4gKhrybXO2kVbgaIte1SZsYRhGWkkllLCtK89dqu1f6898urXVfuoJHhT ONW7UppQs7KfXRoE8oH8Iw2MN7dij0a9uDeJ7mppNU/zUf3Vv4jbFmv58abppuLk3wHyrOw4CmVu ZHN0cmVhbQplbmRvYmoKCjkgMCBvYmoKNDExCmVuZG9iagoKMTEgMCBvYmoKPDwvTGVuZ3RoIDEy IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVE1r20AQvetX7DlgdT72SyAElmwd egsIeii9NWkJSaG59O93Znblqo4VaDFIs7P73sy8fTK06H41Px24A7TkUsdtdKELEr8+NJ/u3I8G nf5evzWgG+6l0UPJ4mdXYsM+ryQalN3vzeOdkrc5UvLyRk4UZFvYxqVhqROcV8zy1X2YpY53y2MP OCxPzXlp7t8B+9CyYvN/YJmCTgCdTG9ochwF/VngQMDDAXvw9R1gRBq+LB8vrParXWRp3nNsfSFi h9TGt41sIEkV8wx6rNSmbLXpPJCWy8PB9zDqItdOaDjIKkofsjzpArmE8phgLAcwVkCA2d4RPIFF JV9pgGt0FORUSM6wglPdHLFAjYqS5siKjigp7kszEUThPXW4k1E56039PWotdeu5Q5XyTaqeuh2Z c746TkXko6rLiIQEmWgIvd6ziEfkbe5Jx5oh2nSWsUGz5OygREkT62LGU5HVThGCiaQYhl1hfCe+ uTXOtDOOGY3F9N2/GY3lE8Er9TEMcn0nubtpNYxeqN5lWRNK9zKWuqBayUwpeXXm6tHqgK1PKh8T CVfxUcmo0dKF3Sv7xeVbZNEylNXG5KXDUPcnOO5Jm0mFgrhOLULZn8Q7QiEkVQpw/SMSpXzxaRrs ZrWXWWqHbeaNVlEftN2so/Gfb/l4lajikamhaWTdCBV6RXyZ+d79BqZcOCoKZW5kc3RyZWFtCmVu ZG9iagoKMTIgMCBvYmoKNTI0CmVuZG9iagoKMTQgMCBvYmoKPDwvTGVuZ3RoIDE1IDAgUi9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAyMDA4Pj4Kc3RyZWFtCnic5VTLbxNHHP7NPuwEErBDoKFO y2wXqoDXdgj0qSBcNw0NqUTkKHSXRqIbZ/OSnVgmIKiKgvpQ6VZ9qFw4tQQuRRXV2Fw4cuDQA1FR hdKqD9EDEpdyQapUVU3Sb9bLQyj/Qdf2zPd983vMbzz7m60c9aiJTpFK2ULJLbcyphDRdSLWUjg2 y/XGN9YC/wHt5bHyeOlmR+0OkdKOnzdePDHWceNskUj7AOu3Jzx39Kd771lE+gT48xMQ3l96Mwp+ DnzrRGn2uMlebwK/Bt5UnCm4X9EhQP0GhoaSe7w8qT7FwH8G59NuyZt9oeFd8L+xh8/LM0dmW2lq hSh6Wq6XK165LXnvEvg34Gn8GD7yQQ4WkVyh//ezPLpyR13U9+oX6Uv6mC7RPrpAX9AMTVGeDlOG dlOKdtJbtI2epB7KEac5ytJFPU4kyBK0oV/sGLDF/mOOIHNvm4gk7T1OoJ10+E3BNqTbUoJZ/BfR lEwJxerP26+ZjpESqjXZxkV2wDZE1kkJzZKuhmm8Y/+eWHASsLOXEnedhGkIPWmL3mNOsOA4iKdb zcOHUiJiVZ9hp5Gdnx4eTghCmKhV3RpI2QdSg9US5y9lUqLR4idlkmsIw4W6rc/kQnt2v6AB2/d8 l0vwYsIwnIQfsHydyYRr6ruLJWIGIq61+I9BOU0Wz4hoctjmfJ/Z605xm4+O1ENIu2aZGam5z/f5 va7pc98M0pkyuMjCEvVJQWQ9SeCzLsi0Z7HNMBJ80ccxwKkPuxkK92YEZustky+GyU1u9w8mDMEc 20dBfaZvcr/PN13pUHeRU0rE5N/Qgn3HZQEStDxWgC8n0516+9FKpOsGC0X4H8lj2z9q+lHBB+zu xFWstFqXKcuyuRzrvxKjAgWjNB6y5Zi3zRHs3swlMDEzh5PP5u0a7tGrhVyNcYZJ8ILY7LXfz7XR ElBxLhhS8pIquHmkjOpD6EJRSlcZZbprUW3T3a5qRP+tu6YqgFRVpaxLuRaNtP/bXWNS3xU34tuM uNGj8OWt7OzyhD70z7c92gLJbnALvWNOO0drcb9r4EmhL9yfmWjKCHVRNC7gW21mSercaXCKkcGf 2BSLRtTU8r3lqyzL1rHmC+fPX2A5pZ3l5ueXbs/Py9jErmukHMaeN+JVyQi2gC8TWqaqB7Hizxkb NRidOUPBXlDi2Nivy9bg4fXdf9GWhuD9/P6H3JZH31d9DqeAXkj3Gxf8ogeX5h4xYY+94qryJ/VE humWVucWWmolsFLRB+txFHCFNkln1Qn91tF3D2KtfxCX0RowFnpFaXOIVeg8xBrwjhDr1IweUscR 6K/AkmmNYE9Tf4gZtdJkiBXkPRliFfonIdaAvw6xjl50OcQR6Asdhe28q3NnJz9QcQtF70DZmx48 URqZKea98aNFt/JQeIgOepUjkzPTvCu9O73roUwduMPbUUoXdaLxdQIdwHG5UIvkAZcxTtMgnaAS jaBRFtEoPRqno0AuLFezWE07CKVCR1D4DFZkvjQOKk27VrVGtcGzMo56V3musJUPBfuU+kXDgF1l 7DOn2is7loihGbfmAU45T6GzDNuOaE0S/Qcv4Ia+CmVuZHN0cmVhbQplbmRvYmoKCjE1IDAgb2Jq CjExOTAKZW5kb2JqCgoxNiAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0RB QUFBQStPcGVuU3ltYm9sCi9GbGFncyA0Ci9Gb250QkJveFstMTc5IC0zMTIgMTA4MyA5MTddL0l0 YWxpY0FuZ2xlIDAKL0FzY2VudCA3OTkKL0Rlc2NlbnQgMjAwCi9DYXBIZWlnaHQgOTE2Ci9TdGVt ViA4MAovRm9udEZpbGUyIDE0IDAgUgo+PgplbmRvYmoKCjE3IDAgb2JqCjw8L0xlbmd0aCAyMzAv RmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZBBa8QgEIXv/gqPu4dFY+lNAiXLQg7blqb9 AUYnqdCoTMwh/76ju22hB8XHe9/wHNH15z74LF4x2gEyn3xwCGvc0AIfYfaBNYo7b/Nd1dsuJjFB 7LCvGZY+TFFrJt7IWzPu/PDk4ghHJl7QAfow88NHN5AetpS+YIGQuWRtyx1MNOdq0rNZQFTq1Duy fd5PhPwF3vcEXFXd3KrY6GBNxgKaMAPTUrZcXy4tg+D+eepGjJP9NEjJhpLqsaOslqq8ZfNQuXui TChf/GnG7YZIreoeap1SxAf4XVWKqVD1fAMs5m/qCmVuZHN0cmVhbQplbmRvYmoKCjE4IDAgb2Jq Cjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0RBQUFBQStPcGVuU3ltYm9s Ci9GaXJzdENoYXIgMAovTGFzdENoYXIgMgovV2lkdGhzWzM2NSA3OTQgNTAwIF0KL0ZvbnREZXNj cmlwdG9yIDE2IDAgUgovVG9Vbmljb2RlIDE3IDAgUgo+PgplbmRvYmoKCjE5IDAgb2JqCjw8L0xl bmd0aCAyMCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMTI4Mjg+PgpzdHJlYW0KeJzt ent8VNW1/9p7n3nkMcnwDgSYk0wGAklICCIQRjJ5DK/wCBAgw/WaTJJJMpBkYjKBYlHwWpQGFa5F fLQC1ouPguVkIjagLam39v6oteCttepPBa94W+2L+rrtFTP3u/dMArHYe/v53M/n98fP2VmPvdba e6299jr7nDOZcEdXgJJpBwny1Lf620czRvj8lIiNrN8c1se+Pisd/Hkiy+uN7U2tYf2hdUQJzxKZ Zza1bG2c3PPVQ0SpFzFmc3PA33BXZ34Kkb0Z/WubIVg8sNWCPmwoq7k1/JWJbJ4V/R+hb20J1fvn 03ywdvgjc6v/K+1TtHvN6L+Mvt7mbw28OfBhIfofEY041R7qDDdQVpQo8ympb+8ItL9/+rf56MM+ 1QsZIxU+VkTMrPr/n39MdwOWkQMwUewj7GX0bcAFwK8HlkYvmTaRc2Bj9LwYBeMn40Dkov10kLLo IptJz1E/LaVHqYQqaR8tojN0jFJoK3uBNHJSOT1OLuYgTgtpHDPRA/QaXU8d9C6dp2yqoLfYSMzj pXYaS/Oi7wFX0K7oCVglUhl9l06yFraG8sEv5rksB573RPtpHGVHX4y+it5D9C7LivbQYnD/TiNo Km2nf6SRtJF+Er2ESLOojh5j29h7lEG1tFu7RuuObkJRHadfsApwy2mr6dWE49SCUY+wcaw/ei76 K/qBxiiAmf6BdiHiCPXzGaLMdIh0mkLX0QryQ/tVeo2NYjOFJzo1Whp9ANLH6AOew38sLIgjh5ZQ Dd1FDyMbr9AF+pglsdnsIXYE7SX2e9OriK2CuugmXFsPIXuP0VE6wWaymXwcH4dsjaNptBa6PXQY /nvpLKtgPtbPfigOmwoGiqOjo2Oiv4pGaTpVI8KD9EP4+IgVwAYeRKYIa5O1sKnws1uxwgb6Fp2l lxDHW8j7x/QnNh3tbX4L3x5dH308+i5isZKD5tIq2kAh2kxb6NvY1efoR/RH9ilPgOUZ7XnTTaaL 0XuQ2ylUithXwnoN5t6NXYpQH9orWOUIpmMVc9kKtpo1sT1sP+tjr7HXuJln8Bv5+8IQL4g3tGtN pmgRZhpLk+HXSeupGTtwC7J9D9b7OD1Pp9kYNoXlYUWvYPwnfD4vR3uEn+FviZ1ij3bJdPvA+YHf DHwa7SYLqmwR8tBF30EW/sDGIoZpbCPrZO8g8r38KZEi7MIpZosSUSV8YpfYJ/6P+JnWoR3RXjct MflNRyz+gbaBl6IV0a+RPBXMiGsq5dI1NAf104hq2oT42tE6aBvdSt10N+rlHjpER7DuU3SafkFv 0m+xA8QyEHMQ3ltRdTvZ3WgPsKPsh+x5dpq9zT6RjWeiZfNreTEv4wt5E9+Jto+f5a/wX4uJol5s FzvQDoinxWsaaZoWNRWiLTbtNj1mfsGSbVlsqbP+9NLvPpv+me+ztwZoYMLA3w3sH/jhwK+i66Jb Eb+L8mgGIr0DUT6AGjyM9h1U4tP0Y5zdv1SxfsA4M6Hi05gT1ZCLXStmi9gStOVsFdpatPVsA5qf 1bFmtO1sB/sHdhv7GruL3ava/VjbYfYEexrte+wk2i/YOfbv7H32AUcRc4FqdvGpPJ/Pw0rL+CK+ kq9Ga+IhtHbewTdjhx7jvfwEf0WMEi6RJ/ziRvGA+K54Trws/qxxLVfL19zaOq1Ju007o72kvap9 anKYvKZm0wHTc+Z08zXmteaN5vvNx8y/Nl+ymC2VljrLNsvLlqjVhdPqX7Du48OOvHzzGdZpGq19 hZ/DdZEm2k13sLXImJlXiRZxt/hXUyO7KHT2OusWQbEp+ohYyP8kQmwdP8UyhcNUJBrpToqyI/xt /hH/lTaGVfH3WLb2j+x7PCTKuFmdqz/Xxmi3mX5NxH9JRfxm1s+fF7eJ26LfpyLTAXbOdIC/RLp2 no+ic7iq7+D3YdDPeJDvpmrtGtOnFETenzB9BflewHex6eJl7QC9K5z8Q3aR7cep8SJbqmXxG/g8 dgQn7mdsMv2O3Ujt7F7ysGfYm6yPGHtcPMaW8WTslsFtbA5udi+KDPaySCSfjJFN4WNYJb/I14pn zWfFbNzaz9K/0k1MsALUzuBngNpwBezjU3GmeXGa/JwVUhrdh/P+o4Fn5YltetW0G3X2sMil1VRA f89foCJcG++iVdPtVEgnUYO7qIDfT9uiO1gDzv3lOD859bGNlM+ScFqOQ2zbcb8YyzNxFtbA659w /v8Ep34F+z1tYTqurH7K1qTmTs2Lk6kW5+9utAb6e/S+RfeYj5t+TivZOCJNHziAKn+DbsA95x34 n0BuxLeBHtZyEbWOk/lGjPjWwGLyoN1OLzBONyPmBbjOK7XFOHn3RzdihUHco5bhnniagtH7qAx7 tzp6W3Q31UQfjl5PTbQm+jjO383RCF1Ld5h8fJ0pR7sGZ+xp9iPcj/4v241zezG9jvPIxdLofbTv Iv4FpmeoW/slzs7i6J3RX9AY5CMTGarDXfQCtdLvkbfFop9mDazgPdGFoh13qHO0KvpY1MESqTna gpP3WTpsMeHs2UGTTYdRu7u1Rl6AeKfRWJYP6fWmg0Se0rVVnuIF17nnF82bO+fa2dfMKpxZkD8j Lzdn+rTsqVNcWc7MDN0xedLE9Anj08aNHT1q5Ah7aootOSkxwWoxmzTBGeV6nQtrdWNKraFNcS5e nCf7Tj8E/isEtYYO0cLhNoZeq8z04ZYeWDZ+ztITs/QMWTK77iZ3Xq7uderGi+VOvY9tWFUN/q5y p083fqf45Yrfq3gb+IwMDNC9ac3lusFqda+xcHNzt7e2HNP1JCWWOcsCiXm51JOYBDYJnDHO2d7D xi1giuHjvEU9nKw2BGVMcJZ7jfHOchmBIVxef4NRuaraW56ekeHLyzVYWb2zziBnqZGao0yoTLkx zGWGRbnRg3I1tFvvye3vvrPPTnW1OckNzgb/9dWG8PukjxE58FtujLvpQtrlLiYfWVZ9x5XadNHt TQvqstvdfYduHFpVfaU2Q2KfD3MY3LWwtnshHN+JFFas0eGL7/RVG2wnHOpyHXJNsdUFnF4pqd2o GwnOUmdz98ZabMyEboNWb82ITJjgORE9TxO8endVtTPDKE53+vzlE3tGU/fqrb3jPfr44Zq83B77 iFhae1JS40yy7UomMKRTnDKXXMXqobwyGZFzCcrB0Ot1RFLtxJrmShSYS931c2GGj49hlNGA/Qga CWW13fYiyO1yvGFy2Z1698eE/Xf+7rfDJf64xOyyf0ySlVUyVGjQD/JGTo4xfbosEEsZdhQxLlD9 2Xm5m/u44Wy36yBIH1Uit35fUT6Sn5Eht3d3n4fq0DF2rKqO9XWqS4+QJz/HZ/Baqekf1IxZKzU7 BjVDw2udqOOn1JvJGMM6Zegv1T52lLe5yGBj/4o6ENNXrHFWrNpQrXu7a+O5raga1ovp5w7p4hyL KZBwQ3MhU0ucKL3VG6qlAH8m10KnN1i7GJcaYjRGlVWLdO6LcTxdqKlQv9cPzSw71clyLs1lVvXf 0GexooCVhOkLDXvt4hj2JWZk/A8H9UUvylGKXB4WX5NRlDO8P39Yf1h4yd0CAWtTeEXVhu7uxGG6 hTisursXOvWF3bXd/r7ojjqnbnd2nxDVorq73Vs7uP190ZO7042Fd/qwiGZWhNLmVNrjZLtW9XjY rjUbqk/Y8Sq6q6o6whkvqy319WRBV31Cx/mspFxKpVB2dNnBPQ9XRYRblX36CQ/RDqXVlED16/sY KZl1UMaovo/HZPZBGYdMi8k8SiY/8qQoq6q+sgbUheXLk3d7zibi6WWiifDGb6HlPZw9w3+A52EL PxUhk9bHf/CUoESLZI4zGm81m05Bz0mwaZTANrEbKC3H/on7M/cK+0fu5Z+5qRi8/RLQzIKMERkj XEBsokaXdNF/yWOiT/EU1E+xN3FT8oubl8y4oybV/bF1vFU9fHz7nUnPDXtflZERJQy9uYNaMga8 eIOgy5JhH26exybyGB/7OkFa4KinmJCTHe+X64jMLu03ZFLSIqxJZkB+Nios1LjJqifUqBQ808R4 gbeC/XFeo8nMGudNlMamxHkzZbIFcd5CP2O1cd6K56IZcT6Bbuc3xHkbf5BfGFrLbNMtcZ5Rqqk3 znOymJ6L84LmmU7HeY1SzTzOmyjZPCLOm2mEeVKct1CTeUact1Ka+d44n0Bl5ifjvI0tN1/EzEwT 8JVsvU7xMkN26xLFm5Xcp3iLkgcUb1V8l+ITZA6tO+M8cmj9Q5xHDhNscR45TEiP88hhwl1xHjlM OBLnkcOEf47zyGHCu3EeOUzsjfPIYeI7cR45TAoqPlHGmSIUnyRjS0lVfLKSOxSfovgcxdtlbClz FD8K/MgUr+JHK5v1ih+j5qlX/Fgl71T8eDV2u+LTlU1sLZOUzUOKdyj+CcVnKfvjip+u+Nga82Ql prwkeWss/hgf8/Wm5JNj8vcUH1vLx/QEnnAL8RxegPd5narwZh0AXY73+jZAmLbiLVZKytDrAC+x H/KgspgBTQnedVtAV0PWhPFh6lS9AGgA1puBG2BZBX2rkuq0AnSLsgpB5sdM0r4J7+Qt6HX8hf+i /2a0/rnxRbhCpe/OeJw6zUYEBcC6ep8IUj20IehDeFsJ40n4r8//RbNdHhUbc3lEJZ7Yl0P/38Ud VBo/IKwy2wCbVrWGTZDJ6P72XZGztqkZY+PWohdET+6DjrjCyjYQ99wGab6aQVdzN6u16shQCPls U3EFlfWMvzmSv7SrGuLKleUWFWsT+iux1ka1M1KbNxRpG/Y0gFExrx0qY3LWXEjWKftwPPplKm8y gzJqnWbSPJqF6vaplegqr3KeLlWZsfzE8t+oZgyrfMh+u8pBq8raYN7q1NjBnHqR1WXq/bAx7n1Q 064qqwFe6tWMsb3YonzVA1/db6wvbeux3i61igZlGwJuUPp2Vd1bh3Yt5isYn6E+Plds9fLK1P9i 5SGVza3qKpDvf7qqtrohX1eLq+0v5v6fZ+ny7A1D+9yhailWVfVDlXL11V+u4+Fxzb8iB3IlsbWE lb/BGpTzx9baAMkWtfKQusKuvtJYpv3DshqIXxWfvzZkVsOw61IjZbSbhyo3No+0lN8B/tU9ekIv LCiYq1c1B/TlobZQeGt7QC8LdbSHOvzhYKhthl7S0qKvDjY1hzv11YHOQMfmQMOMqmBroFNfEdii rw61+ttWB5q6Wvwdg+OLPqfW4/qidYGOTsypz55RMFvPXh6s7wh1hhrD0z5nf6WZUkGjFJVrlld9 fu5gJ17lwx3+hkCrv2OTHmr8wqXowTY9DN3atmA40KCvCfvDmMnf1pAf6tBD0HTo9aGutnBHMNA5 44smGZJVSVTe4d8SbGvSVzY2BusDep6ctK0lsBVDO4KdobZcfV2wPozpl/k7GgJtYX3mvFmFvlCX 3urfqnd1BhAP4m8MQePv1NsDHa3BsIytbquK1Lt2WQm0HarT3hFq6KoPy1VsaQ7WN18xFjTYVt/S 1YCh4ZDeEOxsb4EDLA2jgjCohxXcz9D1QeehtpatenZwmh5orZOjLs/VNmh91ZCUeYNcc0egE6mq l0m5wr3KcXyu+SqC7CC8hAOtMoMdQXhtCG1pawn5r3SKoP2xULEJQ7sR6gq3d4X1hsBmmVzYNAda 2j+3ItzQQuoA8KtLC5c+s6G0N6K431PH/qBu8CBviB3Q4kHRI74vTgFOiJPi6JcPIV8+hHz5EPLl Q8iXDyH/Lx5Chp3il3nZC15V9/YwO3ldXHm+x6r/6nO2wGbrlX1tsjZTq9AWadcBzxvmoQ3zftEs 8l/qm1UWY9d1MzPYw4LU3n7xmKvz8e9tKJqB6a7yOUFV4re9YrqjuGSMuEC14j06KN6lcwCN7JDY wRUD2sFHAaZov3i71+st9PSB5sxQNJI9rfCEVEQmTCz8vnibH6Wp5IDgXGRsutK8FSktjTPXzo0x vdPzCs+VJIq36A8ALt4S51BoalRv9ozCiyU2CJi4hVIZIwcdEm+SAeDkEa/3Zk0pPHhK/BT6n4jT WJocdjpiG1GICf9FfI9GkkM8LY7HNcd7U0YUUkmnuIsY9QOfBZwHXARoFBKP0XbAHsAxgEapwA5A PmCllIgj4gjiPCy/cwLOB4QAewAaUvgdyDdJLB4XGykTY+8U+2gM6G7xDUX/CXQC6Lchnwz6MPqS Hoz3vwkq9Q/G5Q+gPxb0/ji9D/J00P3qlykOcW+8v1l0qXHhOD0kOiOTHfaSydDrgAKAALcP3D6k bp+sCGAmbhMtylMPaCFoa4wiXTdHMpxqj27uHTe+8BBSejNSfzMydzMydzNpUG0btNkWs8kT22Cz DTbbYLMNWSkQnfDXKb+5AbYDdCG/FToPfFHJDeB+wFkl/xrwXsAh2RNbkMdpiOrrYmMk24Eia+qd 5yksfkY0ItUe0dg7flLhnsu9hERZiKApcZoqbQNKG+hNSJbSQO+ESTEKq00lKaKevgrgNBo4C3AN oBygifpIVr7jpFhBrVbypDi28+1iu7bdpBWUs5GnRCFVWgklOVLkkRsG0xw1bjanNqE9YUeCsCfo CQUJnoTKBFNIbBd7hHCIfFEsVooaYeqL9kcsRbNAPIvMRbP2Jh1KMpL6k84mmQxzv/ms+bz5otmk mwvMHnOludbcbt5h3ms+ZE7Ya95r4bVJ7Uk7koQ9SU8qSPIkVSaZHBZ2qGSnqJPfUQLbAe2AvQAN Oa6BXBc3AGqwGzVIxQ2QEzChZwecBX8e1IReKuxSYZcKaSqkqSS/+E5VmkpALaA9rjUPaQbHSPuL UgOYCm0KpPJbxPPAFyUHWIqeDT0bejZYneWXEKEdWAdUAoSSnQegaoAHdQVxfS3ArPQXlc2gziPH 8kse/9T+acyYxg5NY3unMY+7uKTQkwk0cuTIGmeNqya75rAWcoZcoezQYW2lc6VrZfbKw1qxs9hV nF18WMt35rvys/MPaw6nw+XIdhzW9iw7tuzUsjPLtJploWXbl4k52LreSE5BoaKZLkmPR8ZPKJyT WjKfH8NyaoAPAs4BBDmA8wHFgBBA48eAHfxJSJ+E9ElaCagBmDBCftmcCuyI66T8oNJJTur5ML3A wo9GimatLFmKI7cGcBAgMPdR6I8q6xh3TMkN4PNKvjJuf0jJHcCDYwQOuA3qmNuAy28DDv8NVANo B5jojFiPm8N6OTOwA9AOOAbQxAa09WI9fxLtKD8qcj22mWMcNHYs7jMjR1jtJXaejBqwsccVvl/h rytcrHCWJ2Wp7ZOlth8std2+1DYVDM/G85+N7VM4w5NUYnuqxLayxDatxIbZxlEG2fgYhc0Ss98o vELhXM/oDNufM2wfZtj+mGF7KMN2Y4btugw5biKuXRsfrXCSxGy/wksVnuJJcth+7LCtd9jmOGwl NnaAwTuVKjxZ4XSJ2QdPpZanUsIz7AM8aNs4i7inOfo4KcKiEXcJyEDEvQjks4j7AMh/RtzfcDzL /szULY19Esm64CgZwz5iSzTZ/zBO/8iW0BHQi6BNoI+Sm7lA/ynivlXaP4LxD6L/bcq0SvuHqVKN O8iWKPlD8XHfiuTWwes3I7lb4fVBylVe74vkXoD0G5Hcr4PcE8ltAdkTcckAN0bc0x0lI1gTZXFp W08uLiNZFve4GDO3gC6KDfZGcuWocumgj5VFnDNBpsoon2VOqlTuHBGnWuQkcqopJpJTBZ1OLkVT WKoK3kaZilojzlsxi/kp1wXHf7ifkQunj1lq5IDjnWexvnXo/htbEjnieOmETFfEcSa3j7medvzM +Yzj+aw+ti7i6M/ts0JxKrePs+OOHiTZgC1nTzuO5TY5nnQq7WEntNjqg+48xzedGxwPuNCPOG7N fVaGQa1Y8TqofbkLHMvcRxwLXX0Mao8bzjyJjiJnh2MexHP72JLeI46ZWX0ylALMceRpx3R4nOJU oaydc5LPJgvr8uRawpY6yzrLKst8yyxLnkW3TLJMtIy2jrTarSnWZGui1Wo1WzUrt5J1dF/0vCdH /oNrtNmufoOnSawp3s4l5rH/3XFm5bh2jFGiglesKWXGyAqqqCo15uRU9Fmiq425ORWGtfLvqnsY u9uHnsF39TGqqkaBStHOdPkbixPEWP7Ou9Il3bbzLp+PVRj99VRRpxufrME6EldtMEzO0jQau7k4 rXjkghHzFpZfBdXGcc7lT1rOlZ+0Scb+ijXVxncm+YxCyUQn+SqMRfLXGSf4jTzkLT/B2yXxVZ9g N/EbvaulnN1U7hsyo0zeDjNySyLNeilTmlEm61Vmy5QZyjTTW96TmRkzeo4tkUYon+eUUVNsriy4 wFyVksCMT6YsNVcWnyzNUA+xyVKvnCyZWKqaLDWZ1GQTpVGPywWTXJc06ZnjgkGPa45SH7msdrpi 4fjIpfy4mE/5YeyyTXbMBlUQt+FW2OT8b34CpX+DMev1v9FQL38jU+v0BgC1xu7NzWnGjjpd72l4 I/7jmSm1dfXNkvoDxhvOQLnR4CzXe/z1V1HXS7XfWd5D9d6q6p56T6A84vf4vU5/ua/30e1lFcN8 fX3IV9n2q0y2XU5WJn09WnEVdYVUPyp9VUhfFdLXo55Hla+K1aWsorK6x0qlvrLrY7SXJyXieqhN z/CVjrW3L1AXx/yMtFvST2qE21ZSjs9IdpYaNoBU5ZXklUgVrk6pSpG/goqr0m6Zn5F+kj0eV9kh HuEspRxK8wbLh/46OzvDErq6coDDXWlKFsZFm7Gmwlgof7PhNtxew1Nb7mNyO7rin7Jqj/2U+4yb h9zb3XvcB93H3KauLh/EI09lnsnkNZmhzO2ZezIPZh7LNEvF9dVPe9wHM/+QKbpQTSyMj7dc+ewC xZ/shrs65YfgoBMQc5fTlVNWXZJJ9XjaZXgyz6NRACdgFmANwET/DPxzwDuADwEa3Qb8DcAjgF4p EXkiz5sWLJcefTny0EkThb0Fswvn9oH6G2N0zYYY9a6IUXdJYRpopHhWYkkqHrwZnQT+CeB1wPuA /wSYRKEoVJN3xarW10mdOQzhEzphiTpzwiwHDJPpDnfm5JAEWeDYAZjmsOF1T6yzi5AKbAgIjJS0 Uw7rknTwIxU4iv8LknBoTQplbmRzdHJlYW0KZW5kb2JqCgoyMCAwIG9iago2ODAyCmVuZG9iagoK MjEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CQUFBQUErVGltZXNOZXdS b21hblBTTVQKL0ZsYWdzIDYKL0ZvbnRCQm94Wy01NjggLTMwNiAyMDAwIDEwMDddL0l0YWxpY0Fu Z2xlIDAKL0FzY2VudCA4OTEKL0Rlc2NlbnQgMjE2Ci9DYXBIZWlnaHQgMTAwNgovU3RlbVYgODAK L0ZvbnRGaWxlMiAxOSAwIFIKPj4KZW5kb2JqCgoyMiAwIG9iago8PC9MZW5ndGggMjIxL0ZpbHRl ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2QQU/EIBCF7/yKOe4eNtCemyZmzSY96BqrP4DCtJLY gUzpof/eKVZNPEDyeO+DN+hr99hRyPqFo+sxwxjIMy5xZYcw4BRIVTX44PKhyu5mm5QWtt+WjHNH Y2wapV/FWzJvcHrwccCz0nf2yIEmOL1fe9H9mtInzkgZjGpb8DjKPU82PdsZdaEunRc75O0iyF/g bUsIddHVdxUXPS7JOmRLE6rGmBaa261VSP6fdxDD6D4sS7KSpDG1KdnjdKf2sX7agFuZpUmZvVTY Hw+Ev9+TYtqpsr4AfVltdQplbmRzdHJlYW0KZW5kb2JqCgoyMyAwIG9iago8PC9UeXBlL0ZvbnQv U3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9CQUFBQUErVGltZXNOZXdSb21hblBTTVQKL0ZpcnN0 Q2hhciAwCi9MYXN0Q2hhciAxCi9XaWR0aHNbNzc3IDI1MCBdCi9Gb250RGVzY3JpcHRvciAyMSAw IFIKL1RvVW5pY29kZSAyMiAwIFIKPj4KZW5kb2JqCgoyNCAwIG9iago8PC9MZW5ndGggMjUgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDMwMzQwPj4Kc3RyZWFtCnic7L15eBVF1jBeVb3c 7r5b3yV3T27fJPdmuYGELIRAJI3sIvtigkQSIEDYshA2RQnjAuICOjOuM4LLKG5DCAED6AujjuOG MDMuMzgKKq4zUV4HccHc+52qvoHgzLzP9z2//37PS6eqTlVXV1edOufUOaeqL22tqxqQBbUjDunz l9c31wwdqCGEXkcIO+evbtMsH2acBBiCOGNh86LllnlrpyEklUJ+xaJl6xaKV7yRQMj2CELj5yxu qF/w5Ibb7AhVQxNo8GIo2Jj4mQnyQyCfvXh529oJrlEHIT8H8i8va5pf3/unk+8iVJMN+YXL69c2 7xQu5yF/K+S1FfXLG9zcJ09D/imE1G+bm1a23YXykwgteYTeb25taL569vsTIP8iQub/gjIMF/1n AVCkecLxgmiSZMVssdrsqsPpcqd5vD5/IBhKzwhrkcys7GgsJzcvP14wYGBh0SD0/7N/wgHkhxAQ HkN+PoZ8CCU/hfAZTRONyc/ofZqSL6BydyogtBM9jRvR0+gQeh6fhqd2of2oC72MvGgU+hVaj36B NiERzYaSm9E0uAQo/wX2J7tQIXoQaOlBdATqXoGuQweQB/uSn6MN6Ebuz/DUjciKMtEINAU1odvw 5clVaA46wV+PytHlaAVqxu3J6uTtyTuTj6DfoP3cy8leZEYBNB+uI8kvhb8k/4YGwBO/RPeiE/hO eS/S4S3tUPPXqBXdx9XyOLko+QP0IILWQB94NBEdwYdJHFpvQJ9iH17PjYRWHk52JF+EWiFUixaj +9ABXIbHkogwJzkxeQR54B1rodV7USfaB1c3eg4dxxbhdPKR5GnkRwVoPIynC72BD3OJ3o2JKopo wFIeqoA7Tei/0B/QMZyFf0eaBItQLOjC1ck3kRsNQjOht4/Bk5/gb8l1cG3gXuLHJC9FNsDLHRTb 6PfoAxzAhXgynkXySBN5gGtFErxxEFwLUCPg+x5o/X0cx/uIhRzlHuaf5M+J6YmTSRvMSAzdj36N foetMFINr8Q/w2/jj8hIMpfcTz7kfsE/zv/JVA+jvgotR7ehJ9G32ImH4Kn4SrwYr8eb8B34XnwE H8OfkRFkBllKvuIWcy3cc/ylcE3nV/LXCzcJt4ifJaoTLyb+mPg2WZy8CU0FetgIvf8legBGth8d RX+F6wT6EAvYjG1waTiCZ+Jr4LoO34Yfwjvx47gL3nIMf4g/x1/jb/A5guASSZBESCZcWaSVrCG/ IL8iR+E6Rv5Bvue8XCYX58q4Sq6Ga4JebeK2wbWX+4AP8Ef5JOC5WLhL2C7sFJ4UnhdOixbTzyQk vf7jw735ve8nUGJz4q5EZ6Ir+QFKgzkMABbCqBJ6Xw/XEpjvu4DidqE/YwvgLoDz8XB8OWBmLl6C W/BawOQN+D78G9b33+JnAUvv4K+gz1YSYn0eSMrIpWQyXFeRBtJCtpE7SRd5m/zAmTgzZ+fSuHxu LFfLNXBt3DruLq6De517j/uQO8v9CFeSV/gwn8nH+Dg/lp/Lr+If4D/lPxXmCK8JH4uKuFy8SewW /9s02DTcNMU01VRr2mraZ3pTqgPqfAHtRc/053l8ktvIjeb2ottJCe8nb5A3gJ7nogXcRAKUSnbi zeRa3EWyhbXiMDIMT0Kn+Rjg+iWynZwlw7iJeAKejpaQlCwU3fwTkFTyL6Ae/lkY2xvQ8lrRgq8j X4kW1IkRqYB3/p4r4uPca+g4dwKb+AfRu7yCvbiHPMZNASp4jh8uVKMI9yv0W64FX4v2ktEIKeek W4GOJ+EnQC7MwMX4Oy6JODIJqKic+whdj5aSv6Ae4OPN6G68gF+EbkcleD36FD0KXJEnrBDzxTT8 CmnktxAX7kKEfxxGV4GzMSe40Q24lrtP/Ir8Fa1CR3kFvc89Bb0/Sn7LTeRPC9PwYuCAa9FNqCW5 Ea0Tqvk/4UWIw7NQlD8J0m09V8xHIN0AUmUOyLR9wN0HQA6M4CZCiQ8o53Kgi5kgIe6D6x6QEzxQ UCPw+BUgxd5AXeIM0o0WCTYMUgch/rXENDQ7+Si6N7kIrUjeiQaAPNiUXA8t7kQfo61oJ74xcQ1q RhnAOe/jy4Ux5KgwJjmAbCF/JdPJXRfPL2A7in3oC7h+C5nhwkG0hX8HTUdVyVuTbwF154KEvRfN Q5ehUzDKL+EN47jDqCQxiexOjuGaYbwn0NTkY8kwVtDi5DI0GT2LfmMSUL0pDnPcgf8E470GNZBp yTauIdEIeNgKWNABW6tA/tysj5w5Y4ReNfySymFDK4aUl5WWFA8qKhw4oCCen5ebE4tmZ2VGtHBG eigY8Pu8njS3y+lQ7TarxazIkkkUeI5gVDA6a0yd1hGr6+BjWePGDaD5rHooqO9XUNehQdGYi+t0 aHWsmnZxTR1qLvxJTd2oqZ+viVWtElUOKNBGZ2kdR0Zlad149tRqgG8blVWjdfQweCKDtzHYCnAk Ag9oo32LR2kduE4b3TFm9eIto+tGQXO7zcrIrJENyoACtFsxA2gGqMOb1bwbe4djBhDv6KG7CZKs 0KmOQNao0R3+rFG0Bx1cdHT9go4pU6tHjwpGIjUDCjrwyPlZ8zpQ1qUd9jirgkay13SIIztM7DVa Ix0NukXbXXB4y63dKppXF7csyFpQP6e6g6uvoe9wxOG9ozq8V5/yXchC486R1Zv63w1yW0b7GjWa 3bJlk9axY2p1/7sRGtfUQBvwLImOqdsyBl59KyBxwnQN3kZurKnuwDfCKzU6EjoqY3wNWaNpSd0S rUPOujRr8ZYldTA1gS0daNq6SGcgoO9PnkSB0dqWGdVZkY6qYFZN/ajQbjfaMm3dHr+u+S++M6Bg t+owELvbZk8BFmt/oOH8PQax6hSaMO08ZjHtUdZ4IIgObb4GPanOgjENoVHDELRl/hCoBv9qMDzV sQBmpLFDHlm3RR1Ky+nzHUJUzdK2fIOAArJ6/nFxSX2qRIyq3yAKUjo5T2pwvw/uiMc78vMpiZhG wpxCH4ezfNmAgtXdJCurWdUgAfShKYDb+pqhhYD+SIRO8C3dOpoHmY72qdVGXkPzgp1IL4zXdJA6 eudw3520mfROe9+d84/XZQEldzEVOa1Dip3/s6se1+jFQzuw53+43WDcnzA9a8LU2dXa6C11KdxO mHFRzrg/5Py9FNThGlnNBUkKIkGO3QWinHO+Ms1UWzr4KPyJjKgXdJskoEpWgrUxHWrdOCOuUSKR /8uHupOn6VMsufBYqpsdQ+MX54ddlL+oe5YtHHQYlsoJM2Zv2aJcdA9IzXjh+FQCFI9mVEe0kR1o JnBmFP66k4eH0FAT7NABZSNpBaA/oyiVvahiMAXXwD9KnQMKxoCg27JlTJY2ZkvdlvruZPu8LE3N 2rKfPE+e39I8uq6PcLqTB24Jdoy5tQZwtRgPBaYg6NLdWXjz1N063jx9dvV+FeynzTOqOwkmI+su rdmdDfeq92sI6ayU0FJaSDMazaAJGAbZSSRWP7hfR6id3eVZAcvP78aIlUl9ZRjN7yZGmdpXRqCM N8p0Vkb/URkzckZ1f+phLFkzAKiRYKZgCwg0drAmI46IIwoRhkX3R407/KMuoHNI4w9DTdBBEd8L Vo0VVulOvaDBsdRNJqgT3FeqV7p5syXDbrMhry8Dxo0kZ0xSrFYyU1LNZnGm1J08owctFoACWgDD X8Bn1bAGg9BUlcxE3cmzXXZ7CqDPAfCDbrZYALLQFmi+izYAwGkdmgao1j9sji+uno0b/2oreysn qS21ND+xB1VVQd5ZUQjxoCJci2pLHJFibwZJc5NIxAHw4LLSWE4sK/IAybtz4rI7a75MvJLYjK95 9oHaywfdkLhZOGBzNuxbfjDR2/sUh2/dMOf6NCu1gm8EVLzED0cO9Io+rNCFVR5n8aX8SFDiF/Jt vCg7JFmSrS6HbEWchM0h0QT2siLnbpOwlKm5sItkOqIYxnFYV0sGl56mUkFDx9BJwHl38ruuFEK+ 0x02G0A8Q4JoNrPSH+E2Q8IZ3WO3AyQypEgMIZOcY1/sh5B4bUu8sveUWnum9RSgo6rHUVEBf9jh rKhA6iubbNe+OKgI1bZiQE1J2uDBJcVeUywrUzSJaY4bHxreWHXlVcMvvXTYVe4MPvZgy7ihj+WM rapr7X2T0sKo5Gd8DmDBivx46b40H32/qzv5WRcF7ADoKynkZzecJsVvGSuOk2aJNdIisVGSStWh zqGeMt9odYJzgme0b44wR56m1jprPdN8y4Xl8gJ1uXO5Z4FvDU6TRcF6JTdDmKFcaVnGNQgNyjKL 4g3xJkfIbHZnB3VKLkGd4sfUnfxCd1A6MvloqUlNlZ7uojTEANofBlDsMYAi0ERnw5UdLS0yYWRS TZqJMw06EcRBWj4+I6u0CGBbNrLYKJE6GYVa2MSE2MTYGI3a2CxY2Ax52Lzo0GQYVQHCBgVKy+nc 1PZNTrxHbYnXnq29UBAHou2p6gFqbalFLSB7dXm6MF2eJ8yTeVxbg2gVl1oO84TS3KKYlYlcbk8J o2OYtVGP3Pz7d7Hnmr/fciLRs79z002de27c1Anqe87tqxMf9B75+89wBra+/trrf/z9a69ChzYl GvkIzKATZeB5+u0WdYB6iTpB5au0Do2EtTxLVnpxWnH6penN2jZNGuodGrzMe1mwRrrSMsc7J7hE WmppVJd7lwYPa392v+d7L/DnjFPuUxkntaTmyeLjajytjB+qjuEvU2erH5v/np5QzQ4b5wkxdvCE bGZk82cfU7Cq6Eqd0q7wGptCjU2n0p38RDfTiVR8qTzlfgZ8yeYSgDNsChVKa1kU2UobdpWQEmcU ocMYb8M7cAc+jfkwrgKLn8PAO3o65Sis0iaxStvDjEIwEzGYyh46d6wq4y5soQ1jJ51X7A+PLffh +CT1TPwCg7VWTlR7z5xSey8UUdHTw7jNWUH5C0Mt1OJKsZgHlHYCcxfLcXD9Zm/TI0PvXLz52JJV J66ZvXWg49HVa598rG3l7kSj8NyWqVNvTd7zcOLcLZcP7T3HPXLkxdfeeu3Vd6gsqkp+xu2GOSzi vPo1fKY7c6h8mTwqe1ZmQ+Z6+Xb5huxHXU8WPM9ZZW/A5y2aUPC2VwiSmYSoxVjxzZHmyHOUOeY5 ljnWJdISeYmyxLzEssTaFevKsefEsnOy8wZnz1ZqzAtiC3Lbstqy27N/rvzKcmfu3QW/LHpEedzy cM4juXtiv495culkUBxl9gFZfUB2H8DqUGxm9gFZfUB2H5DenXxfd2ZUzJZyohaFD2ixNN48MD3Q TZ7QM/0FdKrC/ir/ZP9c/y7/Ub9o94f9Tf4Tfj7s3+on/ueAEdNAOD2BMHCtm1ZXsY6Jio/BkoRV TGBmD+9xe0oxE742RynGA+ekL0sn6aE0E0+7QR8C4BNGCBTQXZQQ+NBAcxhWrWy/7vKVFtPHCyl5 +n1GTCnK76EU5dfok36NPuVX6aj8HiYJu8mVnabsfHh0b6jiWD7Op2+hT+RTsUmbYQB9AoAv9tGH 8gPsVZGc/NK64sPFpKq4vZgUqxjjbMTeiVQmcjQDy8A+FKAdoIDup53Qsu2MyO2se3aNVrPT1VWj 77Tb6AvtFia2M08gXAUmK0H+QVRaAanXtkxMkXsPBBWS1kkqrCtsjWmBdfYCM/S0gviCtKqnBZZd xhxxYAyWwJIDf7DyeIElRq7T9ZwBGVmCuyDmUJ2qS+XETKsWRHKuKYiFARBluCEbsWUFUWaW1SLl KUGcmyMrYpwPorCaHsQgDNVKtdKIMH19fnzjxo2oH2vi2taWWle5x2CynFjOQFJWOrjcYEJY6Sjb pbm9HrioVkAFaqyq037zNevXlkV//tK9k0cMyb9j+rXPzXZ0WFY2rl/i8RQGbzh096zGl649+ld8 SWhpa8OoS7J80eLxGyeNXZcbjo+7ZpFv2pxp5VmhdJeSXTJi/ZzZ2694iq6WE2C1zAA+TUPpeLru DaNQGpnJ1Qq18kxzA7dUaJIbzFJad/IUYxUHAPo0CqWHaJzj/Kvwg/tsgB/kHOofFBrhnBgYEZrq nOOfFqp3Lg/Uh9aKa9POkrM+FXmw3er1TvHUeZo9IGzt29QdKlFVPhhSTOiAwRlMwTA4gFIKpaZf ukK82atbu5N/Y2RkpWKWvhqALxhJWml9Geiww4qtgTDlo2islKb6CLo8hnHYU6Jmm/Ts/NKwqco0 GRZQja2+Pkp2phBbj9kyaQqxFZdxhcmfkSK01KzFJ/aeAiUuHj/bEk/pcT29sESequoBogIVr6WS 6S9UtFKlDurgllbsZcuhQ0WwNjrcpgibdByh+l2myF11oODL/Z8nvsLuv72FbfjHz5TOG+ff2nuc TLUMmXXz+sfxLO/DXTgMi4QF5ybeT3yvarsOLMa/vGnk4kdh9saAlD0Beq8DZm+m/ohCeGvUWmod ZRXK3GWhK8gMZZp7emgRWSA0yPPddaHD4TeFt1zv+T92fez+yvt3/8fpJ8PJsCccjgcqPZWBCYHm 8LawaSDJtg70DCVl1glktHWMe3zoCmWWdZH1Y/FTzw/4jE3FaZzNrNpRMGQ2OZCSFuLMvhKMog57 VFWPObDq0B11jnYHH2YrZ5itnA4nnV0H5X6mCDlEuuQ5mLCA0q+hKkyBw0Zn3kFnmc6Fg2qblzLS a3NmHzIdNZ0wJU183zxm9JvHDDaPbL00MaFhCrDZhHmc0n8eWyb2nF8SabZS7VF7K09RBaeSBgeV B2x1pLpOpIwyX6ys1EmZ0+soceB+ayM3pOHFDW+tWvLm9XV3Fe7p1Z5atfo3O69Z++BND9x67uHt mNsydQSx/TCGOF9/9XcvHX/9Rcpx85OfCu8JbyIbCqJX9SkBO3arbnfQGwzyvMq7zV5zkH/cu8/2 ko3zen1BoqXrjsmuyV49UC1Uy1eoMx1zXbO9c32zAlcEb/HeS1R/Bsc5M8xyWkwzYROV1BTRJoNR SJ8maeigfdrmmT5t8wc9wrAUaE/H6fYYtXtEpjEa2rs/NH9OCnm1E3tAvqY0+NqJ5zXC2hZUW1vb 4lJRpJh3ggrBZ2Vmk3KD4EsJoAnNx5vx4NfwmCe7EvsOHU0c2PkyTn/nXRxc9/kdbyTeIa/i5fjX zyd+87cTiR17X8az/yvxbeIoLsXBPdj888THgLNLE1O5L0BKZaB83KTXmc0goM1R9+Xm0W5RTven F5hj7oKsCvNg92XmMe5ZpmrzYvMPyjdptoFZBTnDs4bnXJ6zrWBHgWlwZHBeVcEY85jI6LwZkRl5 jab5kfl5dQXtBcdzPot8mfVVjsPrEdO6ye6u3JDLhOnyrmqoCNWhZtSODoMtZELd5Fq9WAiF7Mro zJBF8aSVREuUqM93zItVr+6t87Z7+QKwEMnMAkb4Xkb43vOE72WE7/Wwe9QuYIRPa4k0bxC+l2p6 l9FJ8rbZcRRlhrMP2Y/aT9iTdj5sr7JPtnN2JsXsAbZ4ZrLFM0RbSi2ZjPrt/nhBW4QyQHxSPwY4 06P+hAd6T52thBk9RWXaKZpWpqa2xUvXIaD48sE5wArE4ARvWYnDWJf6K/oLd5mLR7Zdu9lnw6s7 3j294o+3PXv1ow3v7vivL+599Nr1O5++eu3O6sDUaPGC2eUdt+DK9+7B+NZ72n9c8t3RtU9y+X88 fOj1F156gfLIZbAqhWC+c1E5GaAXyFY5328N5OdZ8/MrrIPTyoND88fn11pr85dYG/PrirZYb8q7 z3N/4HFrWi6lf4qFHKp9+yn0qP+J3H3+g7kv+o/m/intvVxplAdnsNmgGHI6aSwwdbqsO3lSn0mh sDfsixfkl1bwFQXj+XEFs6Sa+EKpMb7assnyiuV76/dxR3mpDfNqYXaptzji9s3Na8ojeaFCW5Vt q227LWkTttt22b6ycTYLnXMb5T1KBjb64jQ61TY2TTaRakI2W4jzArHt8/3SHQqZmBHN5g+NzlGK Qbzm1av1SGR6VTQCWuk/WGMU0M20NJvZ4tl0naZEkW0ojEyB/Ztupq/LZi/Kpna6odmSK3Vbjo5i akyLFcV2xYQKWDK7KGnGupNv72PAIFqmW+kyWnG4guyowBWMjkcwWo36MguzD4lHRRIWq0Qi2uhI RQvtj8hksmihnRGZTBaZCSoyvVMcNOSCb6QFqDGeUtxqLyhtlb3xjz+mMuYUqG29VE0r7KvfYuhs fUobW2phrYUEtUQZUYI2BfRKL6peUcdBznDClCtPWprb482KcaLJBqqVQdhlXOWC/Ut2PTt25biy pccX4ZLRmzesS+/wrTh28+YnpqiyN/PZkHfei01zipc3Ln4oln79zDFP3jhp4yS3zRrIjiorBlxS 0+JruWWCXn/ZwLWnz914yRD8Xm5IzZ1YOK7uysmXrAGhugkh7hOgaA++VncJnOgiO9Vu9SPuU9dp 7qxL5KnvqNJsLV2n4nvUY76TvqSP1yS3ze1xhgRql1oVq81iy/bpdOJ9bF0151LY7KZTZaak4KCo NzNSMGeyGnSymHgxu+mUQf57SjAAKZQcIH9WZwxg1ksGlybNGP7Mk3x01gOlg0s7fKd9pNm3w9fh O+zjfRwpSfMwB9HZLofDcIX1OYV+0L39nEIK8z3wff4xKvgAIoykeWYY0Fc4f+pkmuRVz9a2XJBM lb2VZyoZbfQvpRo9KNcI1mtqy2Knobl7RIesSIpJ4UQ1BtpFENsVJ9XHQQnP30iFGRAP8yelKMGR 5Sg1dG3HpodWvVf34BRV6cpfOm7lY3zs7l2jmycWX9u7kty0YvmIO1/vfZbKpc1g2laCvkU9kkf0 q+TBdJiT5W3yDrlDPiyfkE/LJiSH5Wa5Xd6eKjopJ2UlLGOETTzhZJG7DpZYQeQV0RQVEL+d38F3 8If5k7x4mD/NE8Rr/DHI8Xyfx40/j1yeIZdnyAVNwczswC/6DMIEW9N5unAoFNH8JGnslIudbq2A UOp+rOphqioNVMy3tsRdZSVpHGg3m7u6uvi/Hz16Lo2PnTtOLflcoNw3+Riy4V261dlNXpGIExc7 vaVSd/INXQYAD8+I0Nzz+mUA5JFcuVAFSaGMx2PIGGm8PFmdg2eQGdJseYq6DM8n88Gkvwa3SdfI t+AbpZvl7/EZEvRLMZwnxeUK6TfSO9ikAn08o6aVkgJnhdydfFPPAiONDJUVIilKFBM3BpvZapNE Ui/ETaKo1FuRlVK7TNFijdsU0o3tXZJkEsSD5EqEkIk6Jpn6k2ndYcPIptvqbO220zaByeRsesvW hpTrMN6F8GTUhJIwzz5Gwn672hZZ/6KxisJyOZHqjBQ4FVeBQGH5pAZmpfpxVWXvx0yB3CQMjG+6 9kXV9mIcMEwt0lpmAY6cU703D8ckavAb2JMoLiH3/DMUixSVyJBnNbgWau9HUvL9TjtFQir57Jlg hSx5gpcAfLrTS4u+0xVPBXFDCHgq+qa7pqQMi1mRskgaNg0uiaTlkkdWVicmcwt6f9e0bgn++52c JN65pveqa+T76TxnJ78m+cK9yIv+sh8pYEVlxUplZkUB0O4H+rVYFcwhjyrH7YrogVXJrmaiTGx1 Ri04aZJGy6PrTM2mdtM2E49MmmmHqcN02HTMJDJVNKWTnmH+BAC+ZkuNiRJ5Skv9rk9L/YFRNNVb qacNIDHlCDV8uKYDZAny4cG7F/YnbpiNM6fUHiBw9dSZSqbN91ZSR5ejpER9hVJ5PB71Gsq8IwvU l3KQBFkON7XHiBq4vHLesoIbbtizd68rnpvx4HZ1eMNDZP6t2LQscdutvT+fWBCgOHKBEGgX/oy8 2KpnuGVs9xf6i/y6v9l/v+VX1setUsCaa+3wH/bzfoq53EC4NF2ychZ7SMFpJO528ZyIlO1u7E66 dN4b5RFH7sTM475n0JBSJhTjoXDpNoT9OvPf6FYqVN1MyOayfYhMJmYLUlsRX6e2ItwpUftFnxf+ E+aDpML3GSZ1H/b5n8UHUASdxQoCQr6AOGrbAu1SOu5Re3pqqYCoBORV9VQ4DMnqVh2ibBKB2URV dgaRQ7QHMYjV/I0bMSXs1hKK0bLS8gue+rQ0it3O7dtdgetXXz4nOKR42qijR7n7bm1ZWjrmCuev lTF18279cSHI1JtA1wuDTFXBhm3X78eCxZ4tlAmjBaEq3BEm4XBmqCR0aYhapuJQFzVTL/dcHqiV aq3V9lrPVYEl0jLrYvsKz4rA4fBfLce9x/0fuv7h/Yf/I2bb+jWh0F7oLhKq7LpwuX2KsFA4nv4N /4NqUdNsvEjAhhVNGExYm9mXfcyMVbNurjO3m3nDaDUz7c3MjFS6WDISNfe57c19rl4ATjK1ii24 hWyBbcOOktRqaKx4JVyUkH/v/030eT76HMGWfo5g50WO4O9+6gj2MUew23AEZ4zt77PoE/rUERyP /9QVTD3BVResXeYLjmTBGgCTmEHSVJSVmcO5vRfUezzgsa7W3fN2teiJr597dikpnXnH6qd+s2r1 U8KB3m+2Tt766srEV4m3f43vOjTzliOvHXvpCHDM9cA25WzF/GifwJZLgRJ7+ZBSlpaWGWnRICPN jLJUj6Z5S+1CWNgunBD4yRCdFriw0Cy0C0mBB4VBIZyxUUVbYmyTBvS3HeHD6DTQ1L/btfrBQO1F CorBNVKKZYwFFIBk335eaiVFk/iLV1LmQYwbiymzk1qNYtAuHNd3CQd+GIMMnU+Mgc6Xhf+wH1lT NrfUZ3yDbP2LPhFUvih/ij8lf+D9WBPeEs5qxCtpWbIvqMkcl5UREtOoUQcaYFbAryrHonhbdEeU RL3egC26zYEdPPOqMGevg5kDzKvipoN0UBPISwfqIMy3wvZ/HMwQcPTtWjoMCUwBXKtbfNFtQRxk zQXPNxdkzUH+S91BmwsyxS6o0OagNGGolEELbTjYZ2EEaXseREqyovgYwtvQDkTohtNkoAX6jDEb quEr7ttOhdiTkmT99hPdTJQZU2HsZPmzo9147Z7I2P6WbR+1957qvxHS058ZeieNbhj1CVA6FXEg 5+hC3uPwsp3HlBpps7hdMbfFEcROa1pKfdyYcuj17UZ6vDTqr0BSCACqSj5Y/OiS1XeHr3v1gSf2 ZM0Z3vyLruoFl28cysd+OWnuvOoDu/b15pBfL5s79JeP9N5NOteunXLfHb1/pfQyJ/kp/3dYXYpI mp4zn5vPr+TaeD6aU8ZVhEZy402Xp48Oj8oekzOdqzHNSb8i92aXLYsupClT0ACifUCsD8jpA7LY FrZR2QCifUCsD8ihFsEYCuVaY9kkm8uJDraXZo2Kji6crc3KmhldZl5iXWpb6G7wrTNfbb3afq26 Kntl9CZui/lm6xb7beqN2ddH77TeZb8rLWO3SHf39QGRmDMYC8gx0HsQygs4+eJBMdQAbGodsC54 c5AEox7rgIycKI4KHoHONzPGhYwBckaGh2N+pjjMT61h9tGklpl+hT3GFdQHRLNtVrMQCaVnBCWT yHNExNHsTCgThYzggIBO6WtrAAd6PGgAczA7aYmKNTwF1+FmkMki7sYdumsAfSV9NfT4MjmG8nAe XVQprebRrlnpc3mBYhgTjjmpIU5vOfsOBzipLmandZwzqC/NP2j+lcZuxcRT1GxReyZRKVJLXTBs YGpvLduKiJ+hIwJKZIYtgDVUKPczekDIuMozwIgdbJwOyM6JMTP3J1sGvJdu41EjODs25xnr3Jev bXpi+pQ5wxLLpjYuuu7rXzz8/U3CAfvTj3c8WDEE/7W6/eqbzv36D4l/3ovfUVfcdsWlK0eNXpTl rY+XP9zQ9LsFja9vtN1y+8YrJ5eULM0dtnf1qqMr2z6nlFqEEH8ApLoJ3axbBZIBCEfskJ/cTVbu 0XjMd2P8jKhhUshhDuC9mB2poALJzOSxlDpT8TVbUQH4sO9wxY99wrdPHEOL0r57L4jfWtBVaqnH qvYTlZmBVewgRcRBVd2Ig7gS6fyWRFCwPv30D/+kvY0kpnJfggUTwN/uJowk0xW3nTNzIb/dKZpF l+60a2bdotmZ3AOlLh54L+A7AgKXJuyAAvM0BPfYQ9hOtwKXhypy3bPsuxROt+p2Ytdyi0pVGpks stNj9TlzzDmWHOtgy2Brme1ehznXmesa56lx1rhq0hqdja7GtHXiaus6x9Xuq9NutG5x3Oq81XWz +x5lp/lZ9aDjgPsL5VP3N9Ze9Xt3MpThTDGSx2UOBXn7KPsNds7uP9994wCFwRQVFUG93G63qA6n U0Gc3+1yRZ2KGzJ2i91hiZoVWPIUF3V6mUXaAAqpIVIYOhQioW5StdcOuNDd3WSGbq5y6k4y13nI SZzd+NJ9dpyJRgcVeothS9csRZbJFm6KJWkhFqixp9AOuCFVXUFtPWjmgLzeljO1LQFfD4A9PvXM Kb96ChSPgE/tYRDyUSWdTiE1lqRr1Rch9cVtACBqQdnUykrpxQkdtukTOnxTZ1cfRJbkZ8ic/AwP GVID7IGZdeROvr+vvELJLK8AM+6zvWkVjsw0ZgLVUO5BLbXAOTWuHMPRAxcucYH0LneVYNFE2WSD e1hB5TivIyaYE8uffy+eGY5/1JVYNiK7aP2s0sSix9Xc7OBSezqf23vvqo3rV5Ol517edWnNdEpX zehDfhj/Av0mQrds5doFwgkiJxHhIJkNhRyZ3Ul08QCeggieoqehJ/GTGk8CEl/JmGGV6YrZ7NxF JRUKyF8YmNgD/3wBuiad9225ynAaxmnN3Gs/JjhCNu7E9+1JvJj43R7agxNgj5wTDiMF7dI1IEVH 6VJ+A9lK7pX4p3gsIxG6JAvYQvCrCtOSlEhWaRFK8eLJPtUodTQFhRgv2lKMeNrYpUXMZZfazg1Y BN1qN3Q0G21LwJqgC0Twmw/gSnwjosLuFMV8PwdfHJZkyqZ0me3bHANFUxRNZYMHl5eQc10j/jzj 7g8L2/hrhq8P/3bsq3Pp2A5AtAkdAW0hqvtIJah8lXPBKN+AdiF+B9zfwT94D0NfLZWkg4pKykrS Dhw5coT6aZoSU01vCW+hsegK9K1+BR9RNU8kEi2zlthG28b7RkXGZI8ZP3bWDNvVeTZPFNYlOT89 llcWGFwxMjrLV5N+ZWRW3qzxNbMafA3RhXmrA1ent2bf6LshcGv6LZFNMb9NnWJD3PRuclBX7DlF 5ilmYjZ5DpJxaCSaQA52jRzKKWG4+8xQrMWb4yR+AE9EOeTgvsJx2Xa6R0Ou1+3qlOEo27nDnl2k NqtEPYAfR0HyQFfVkPxsqC+jLPKALmtluMxffcWtqTWkpxfWjTOg0vTSNaMHFYK5Rl2kQDBVtad6 DJ9oSp03PKHnd67KSziR+TvLBzvLSkl2ViZP0txOvkTLLi8RRbppA0sK2HBOuo/j9aSpJnYWJMb2 u4YTZgLYCH/ziAen1uxsfPjr1iseqMjcsy0jL71sVuuNTyaePvJF4tq33sI//wbW0nnVe0u+Szzx 3+8nbk58N3LGgqvx77D+Hb6ltf71fX8ZPdNtTXh+NmPI+pZxm+r1liX6wxOuXPyXjdtx1Y4ra+/v rb/VHsy5ZAq2bn0MZ/723cSiL75JPPB4x3WNxze0fvzL59498x62Y+21V55+LfH+B6/m5/jx5Tff M/KG1xZuvmvEtjf+hTPbyVae8ARzJoFQzsSIB84UdEw5UzA4U3xS47hKEQUkTcBCijM/qQW+rJzY Q1nz33AmxmX0jx/2YxmHf0xyr5GNifo9YNNV7kkspL1YmPxUWA36XDr68975ZEk69fkYmxNsIZxL IQ0VW+dDf9vS29EN6dvQfcKT3G+s+7ku6x+sx9Cp9H+mO2zOdEd6Opcv5jryQ1p4rHWW+4q0Wf7F wtL0a5y3OO/j7rXdF9qJHyE7HW/ZXMiNAqpbDfCEOoxyK5i2MyC3QrUjzAddGRYumMHLasx+GYpp GONA2BvTJCwx+1LyZ/Tt97HtvrMXFBUHHTSowrV0UwjUEbqzzXb6gMCyS4BiDB2E0hSVtXzX85ck Xvi4J/HO/bvwyOf/hguGHSp5/uePfzRn+Sc3PfwhIYO+Ovc7vOJPH+OZu0++NmDHnQ8lvrrjYOLz Lc+mLCeOfqXmxvX7kQesPDAHObo5w7T/KF/GjeYOWHlWNNTrL/VKDovDzQkY2UOCyW1WLFGZObRl fFjGHuYt9zDPucx85jLzmcvnfeYyMwrlAK0nUw2Y+cxl5jNn7jVm4MjMZ07v76MiUZ7kobj1Uj+5 57SHNHt2eDo8SQ/vIe7/fIryPzjMpZ84zD39HObEOEKZ9lNvLjVAqXO8n4HDinsQ28kG0/68b9wm 2kxRm2gJYqtk7zNqUBwWR2azGqe/+hsxXdcdXv3bCV2rlk65rRLM+6/vrH3kV71zyYObrpl++7W9 B2FMy4G69wN1R7FLDwTdwTRSl4OvklzYyWVno4jTS6Iog51rAlWBuiiw6M2wcZEMUcY4lhPNBo7T iJZTRzhC963oCkSoQkgnBIDjTDMk58/nktb2HJyTHtMUrLAlSfHHUso1JdaJqb3pWurtqKTbRYxs 6bZRJcsbp3z6rLxRfFYwFAj5Q5xoianRtFg4JkX5WFbUZ02PII/dFYHKbpdmglymEI3gkNkbwW4H RBlyJIKyOYgMR23qvE/fv3xmLOKyqOMi/gAlfSChyDWJTOyCOuLgLifLtyaO7fhLYnvXHjzl3e0Y 3xnbFZm3r+nG59dEhmzC5I7rTg8nVU/h3pOtK/fjq/7yNl7Ztaj7F0XN7ROn3jB58/YXE9+115dj B8zHlORnXA8/HLTc2Sktt9S2AVQyM9bRFJAwHOKdIbPJF+LN2JZmkpj71WIcmmCOV+NIKttlO/Lm S4Z18mJtMQ2g+upjZQsOh0a6Rnqnu6Z761x13vvJ/dx91kfURwIWyepXlpBGbomwytJsbbc+atkr 71P2Wiwey02Wjwhny5xrb7JvAL2V7amvK0K0U3RXnfoFTqLTSEZ2uxld6GMIup5tY6eHbZlB6p82 x8MYIxBZOnOF6cwPNo6RVoB5v8aH0rKPmjA9HEJSB3qYi8LEdrhMg4KlfWeQQQ01GKm2NXX4fD89 fzSkpqf1jHFajFGOo6JQrT0Ff8wWAwuspu84T2pR7bO7qMTjKnenf/Xb44lvWz+/+em/hXf5N8ze /MQjNyy5Hd/ofeYoTsfKU5hs3PVgcOmyF/789vM/o3LuicT7+HrQcRQ0aa/CIdOTYjesRzHMVRKC FUyVHrCfKpE4xDR0MjLUnx1IQDvMTPc5U8tc3tQGojHdlOgxFACqDLlFUw7oV/uOTLmiuGIwd+RI yy2xif76K+kRD4SEZ8AicvLpBq3sR066Ic6owdhmFlOnW9/ssljZHhRYbhRyaBbjxuEum7E5dVgv pJBDZ3nFwWFkASrHol1BitUiUuKyODDhFd6hpPxShtPfAcR25Ij69hH1zTgzs6qqUotryuaFEARR 6Mb5fJ5CLnNc6bjdwTk0OtsK1V9TG14n+w6nndblcKRUDaXn0K2L0/oz4exSXrTILjEo+50Cj3jR LJttklNFLs5tCklBc7otG0VN+VLcVorKTEOlYbZR3FhRN02UJphH2sc6LnNeaZ/mXGpaIC1yrhOv NrVJ+8UD9n3Ob8Rzcq7ZkYtyrTm2XHuOs9A9BJU710g3Sfdwd1sewzvJTjOwAdonHrC9zL8t/lX+ jP/M/qnzjPiDHDKLtMcWFquicRCAndpgcZ/BF1Rsdt6JHJJJiprsURs9QGwzcVZsiVq7k2/r5Wyv i0RxPuMIK3a7RMXsiClxxwx+mjLHscyx3rHFoTgUnkOYTocxMRdQbdiMhfEzhYYDQj1FL0Nawl9Q h0VVIKLJJMiKIpktFkV1OMACnrBHQE6tOzleX6jYbdoLDpOkmcDmjMPqKwgmG8xz1GpzW602CUyL uCK54XEkEOgrLOqYft1hcvISmKQ2K+ue02qxSJLJBHQvOu30ew3FfVa14jorFSectRs/pivaZAU3 KRsUAmboTF2e7MBNjg0O4qA5syrgOuYh5gSovBefdZ1dyFYH/8QztbW+3toW+Av4ewH+BBl2pxHT y2m4ACuc7DsEiDdNZPt3m8Ag/ZcEqBKM0xdNYKDSQGEaJnSEp1d3WTWLRp5NngR5chLZkse6UJFd cwKNgtVq/KuZ0FE6ne3rHdttKsKsIAI2bgkTQ1Ly5G6TZpQ6oTSDlUJD++wabVvqTh7rNBXRFjvR EHLAeNP5xs8/52XPOZIn9ygar6Eh/W1mW/LNfc4KVAABGHy3i9rLNRf82nHKfi1gQtREwFpmxrLL Sy3mLC6HwxMSBw88XsWXPL5/e9kl+3Ylug4+nvcOH+u9/5TjVbKi957XjpCF546T9Xt/PAqSJkA1 OZA0Cv4itSp5BQkpElChggRZEjARsunSLxTG3zuivnfEUVJCyZMKseAzZaDRZToqFOpysToqZI8z VCrRCNSCL/ZAilOpQp3pMt07zYWInbyXM6OlyAMR5I7r1+UOLEUaRHZLHsqVY0oFKlPGobHKLDyL 1EjV8kK8kDRKjfJatAavIeuktfIaZRPeRG7ibjZtlrbIv0b3yHcoT6GHlOfQM6bdyivo98px9Jby D/SRcg6dUQpgOIoPeZRcFFPKlclIV2RBd3pKBVAeS1MMDbY4okNH9CMB3c7kGGLngCguaBk70E+x wkqJIFjMVJd5Lw64gXAkfiSOCinvUvzo5YpJkqKy4pZlBXHnuUtQgNVlSaLMZFJk4H2h0IItmZKu 63K7TORuHNyrA6sQYJUgWJlEx5nmL/5EV8ceyiK9tQFfz6naFEec5xZH37Z2ihFqmKRmJ28u/EMG 2aScLPi3iWX/dSoa9sX/sT+xAsjkhkVNM1aTzfRsAUk+lJiKh7LdISd6Sx/NC1FhGF8i3CQIXgnE CA92m+BC2GomnNvCOwSziZ6eMIumkMO+zY3dXm/AYrFGFWWbGYfNVebJZs5MtedydiSG7S2Y2d6C me0tmDPYrh3bBjFLbL+Oodnsd7mf/uleAtvmp99tsR0DVDWxx3CzGWok89MCrW5SpUpDw5ZUe0xS lSCWbaYg6ts2oOcqcDnbQwM9201t6pu6EoszB4fLB3eVjLh7PP/5H//4/TX32sbfyc85t+PFiQuo XnA96HIn6S934Mn7UYCebwYDiGguT6mdLmslTndp3IWzJZfHgl0eM9CTI8SZUYkn6vNSuyfAbB0v s3W8Tnbc8PxRMS8zOLznTwZ53amDhykrx8u2cbzUCrJSFCW9+LAXeycF2C4bNXYCpwOkObAj0BFI BvgAmFrnTR0ZI1mTj8knZV7u23qTz38wlrKyFGZb0faZkSMzI0dmRo48yX+RkUONmX89/lPZy07r VlX2uTsA/QFetVntVliqJFESJE5UeUsQWSWHMRX5+RtBJ4dnU+d5c2JsOrzsNDabGq5q/VtXPTxZ NXeZHSumTr19WNevusYtn1y2ktzZu+e2QWOnTt+6mVQA2YKNCTLtv2F2VPy3lExLs2OzyBNZJKIV WC/lRy6Ms4WWWc7BZ+xObM/0V4hUlk3xV8y238XfJYHpbj8sHBYPm16zy3bdUxHgXHKaNaCW4aHm jfh2s1TovIKvMdWYq21343uUe8zPkG7Ly+ZXba+rx7m35D9a31U/Vpx9CoPZgpwOu88KEypSGWij kF0ECxIpChGpXUhNIZD3KV/xQlHkTJIsY1GUBZ7jzHY74NGK7XaraobJJFYzZ1EV0U7sivoSekkm ahTJboRkjlhfsmJr1AKcaeEUWeY4IgLHWSxImezEzvHW6yyZir1elK/TFZAyz+jiFLFd5MRuMlK3 adx1JHMy4HK8Yz1TymvPGIIH5I76sXqm55Pai9ZoKndqU4KnNuUgrrDbN0ls5TViSEzMZ1yZWui6 bL70CjPFtzm9wpLpreAg0HxnpEJl3tC0CpwZqZD10IVDM+yYGN1uqQHhVeKlYqwcIFj6sB3fkLj3 g4cHhgqie95J3IFvee/40MTnJBcnvh9bdGnJuYSl9w18WU2iFsb1IFjHmdSDgf6qKzF7NV8tvSLx zGHgcaWVlvLDpDH8ZdJq+6PCZ3aTBVEl5mCXKLtjhG4q9RnDBssSNWUKn9TZCV9Sq3mw5pniIfRr inYP57Eys5iNCVpX2KerSt+nq0rf7pRy/tNVhU99qvYt221R2BEithzVpg2ruegIQS01rWtbGEsa p77Z0WCQ8xg4yDjtzZiJ8ZKDr3t+QeLcm28kfmh+fuzT1769Tzjw4+73Ej8+fDu2fs5N/rHz0N55 z2M3lXIjwBZcQpaD9C/Q/c2kmSMT8URYs7IQCQjNdPeMb77NcCirn6DCiT2w3LRQkRpJG0HycPfe vbSVexAS7fT8CDnVZ8tI1INDhynZrA6GuC+7KCDQHexcClnY/p9gt3AywkQCmwBJMlHMIjtRqaaO e/ywj60dKjI+uzI+fu37GvhHY8OK2stHWATMfviweuzYYapIx1PHvlAwxZph+tEJsCWLORbzLBa0 1HfIX+tZbHKZJ45jZ54I+wZKZvuhiiV1Cuq7vnME3+lhCsUEbNEUZ6mdRYIFlnubGUkSJv2/STSO lSsHySxYa1UyS7emPl8WU9ttRrMI07GcKYTpZ9Ki0hhMrTEaY4FncVDfgIhdcpOgxK8GI/9lQKVl vGW8ncvjo9YCWzV3Jb/auta2ySqZiSBVWAfbJpMJ3CiTLk20XmpT7iH3cneZ7pJ2co+ZRCcBjb9I IGA7EAmW5CJBAlCyTLNPo5/JEYn+lhewgs2m0nmqc7Y7ifMA2YmseFCnADoxHqQrFlnRdMsGMzYf gEHasBnukG5s1mU7Rpq9WcVqN5n1jCbUGUYC2bnHQWndT+3o2kpfLxjQdKsK4MD5zKla5KPnodR+ V0Dt6blYEQLCnNBhTmnrzyFL8hzQ4Nug4LxN9W48ocMC93KZRm5NfrfbptBSpopbQRWPVNgKIhVg 0b25r7zCVlzOwL0DoHRASi7VtNJvUahGXlPiiGAqlHDEkeXAWdhxD87GVxZ5/GV4LhYOJmbtSlQL B859fce4KfdzP/4whn/tXBl/8hzd8VmfmErqhD8jFV2iKzmAFNVpklS1G5fsQdttgMQS3WHabrsK cSqncRz3lOPXtzLZ3Hu2BxRDRg+U9XGMOErLB5eXgDFpEtNUjE/88o2Js5/duC7nkixYbBNTn8Xf YduXx3vPHavZctfB5xLhBH3/IWDXjUzbe30v/RKfsCM/Qy4xjv6UlBrpgCIjzc0z0izjSNCe9Awj 9QWM7ad8q1qqCduEXQLHaWBRbkU7UAfiC5ln6QQ6jQSnBoXbEMeqM0GKfCku/kcfF3/Zt+18VjcO oTBuRA/xb9f023GGqepsRxjwT4/Qnld3jeM/1IF66Hl26AdWTISEMTBGBQ9P6QZOqvOzXx44b/AU 9rd0Uqp8dqGA81EuF1UKLUWWOsvN0s3yNsthy2mLWbNMsRCemCViyJJnZGwBBocmq6pS63g2LMCa JLglSYBuakRwEyLI8KrPNQU4pkHCDURiaMitmCLhdmmbBHmMdSvRcyvmEryVbCeE0BKHJkwRSBFw yTbhsHBaEIBTNu8x1+00OKWF7u7R4KObIUATAX+Pr4ot0HQHF/gBEmxwgxsovhPZQfr8d6fsxDQB gQFIT1mqUC0Xqg1mjIHYj16w01S1hg1h0HkJJiN6X/4TvnZgOHMAvvWlXkD1uXfam9eu5fOMc1YX 6LpBt+SSXJXIioqRU6aUrWznMKRdaDt3lY0e3Et9hWHIcZvxZSMD/qHbQUmaabeFbcT2lDNF+3Se f0L/rizkoF9txnJK6DFylfRuBOGYeUnO1RufnT3xKNg0J/EHz+6/a8vsP53rPf5l4uuEhAgal2gE nX449DKEB+u3m0mc5PuGkQlknUWsSqvyT/Bvy9iRIZS6SoNVGaNco4LTXdOD813zg3UZ7Rlvim85 PxE/t3zhU/NIpiWeVkHKLOPJGMts0kj+annX95Hnc/8nwR+JHfNWdyBkNtlEd4g3I5vXVoLoV3l2 rNp1e5293c5nsI+TMtgBRzv7OMl+/uMkO/s4ye5JfYubMNZRu4faCPa+r4BZ9Srmr2pz/OtXednM kcy+SzKx75JMHuMbM+O7yvSMi79I+jdf5PXSE7w//VQd1n5Hyvs6OPUJ0kXf4hXk3z3zucRXTX++ 7vctD/VGnlq78tFdq1c9nGgk0rBJeCA27Uhc/+jtP4zknj5y5IU/vPn2H6gF2gv8WsNOstjwon3Y ZldTuxApwFgV2S5EzYW12PhcqFAtUhdJi+U6dTO3TX1FeEk8rJ5WzZJQg2eRKepic4f6T8s/rf+0 geHDW3kbZ1ZAyeYt9Ni6yWQBWBItJhBd5w8NIc1kccMtwnG0LI2WcRpvccNTcgasiBlMgW7WZSRZ PtdBqpAD2Awcb9adFg01mLhpU/ij/Ame22acwdHNUyyHTScs3Daw/2letcNskQ2mdhMx/dz+9jvM i9zihwB/oHuzRa8H1rzKQE/VqUrqXWZrXR9zM+52GG6yTaBz2158cZNgpMAaFxbBLt7OSaYDydPA 198ZzN7a5yfIwtSVFOFcES6WI5o4UvJHUv3ek733P/hX/N/3jskMlVBhip9NjCKz8V3719x2C+Vy lPyUVACXc2j6fsSBEu+uoFucuuauuJvDhNvO7eIItxox3ZJgqKdwnyHyGXD/46Ao8nuu9tGNmjOG 1DIkFjUljKPhadAn/Pi2RLVf+McPTDvdDFbed0AZZlKvB0Xji1Jxljhb5uzWfwpnRVB3KOuIxk8E EON3H5iB2wdw1ARj5yZmcmsU4hQ1F/tO4vQep+Gf7oLUKbCCiOGwvgFKRJ4XeLFcHssLUXGAUq2s 4VYpx7mPRNOjIs4SY6aoVCEOkausk601fI1YbaqRr+XXCffKL4l/4t8WT4mfm74Vv5fSnIoCSyNP RNEkyxJkZEmKmkSgL5Hj+aiggIqlKDJk6FLCfjFVMpuRAnRj14E4GaFnSjQX0dieimqw8Taw+8xR RKIYb+v7LJ+KikH/cqLTOGXrZEuqs9/Pwfgt1g8iYxf297ekvqromaSCqUG3ndk2pmEBgtHqZa4n vv8hIZMqga3HsTilZFsnyDgs38AR2Wd1lNLvfVKmoK7IBekVspSeXkkN8M50aoe/2amxZHekImX7 UR0L7L84U83E5GEwFGESD3d6aPJ+p8qsd0hYzsKS3eY+HY0qyPRVzvd4LLk98Da3u5JF8NTZTh99 +B+7g0Z1+qsptSmohe3BUgLMwibH5i78xOeJJfjQ+4kHN4Dx9CzuSKzuXUDCVyeupHQ5m9uDc4Au BRTT05DAYeFLgriNGt4GVL9EbHmMLVvUUMPG9z0ujn7bs3ngkSJ40vnNN4kv2a99CfY5m9OueXSu vfIbKSixXxh86KOc/L5fG6S+OXaGBmz91O/rMi40DU9MQiMv/CjhT356tliEImEWeoA8gW7kV6JR EDbxCFVBOgHCGPq7kWIFmg/wpRAuo/fxH9BmqJML97IhuKDsJii7XnwCbYK25vAfoSK4H+GfQs1w 7wTUOSCFURPNC39AC2kb0OZyqDMF7j0BZSLAAfyH5ENw73qA7VD2IPRpBLR5D6Trod4haFumMNQZ J8xK9tK+Qd3NeBOaTX8PDd2Dg/hH8j7fKdwhLhWXmgRTr7xQGa+8YH4GbJ1/Wj+01dnXqkcc2c4p zjucSVe6O91d5+5NO+q529vifdr/YeC/g9eGLk+/Kv10hiu8M/yZNjvijizKLM4yZVVl35L92xQG i1E1PbVOf/UK9INCNAv68RSfDnNMS4cS+ivHHLu/hMUce05hOY49ZUNtKZhDV6GfpWAe6pxMwfS3 ar9IwSKsdiQFm9ABrKZgCRXhV1OwjLbgH1KwlTxBbjg/12XCwBQMUy3MT8EEmYTFKZhDhUJTCuah zgMpWEAW4eEULEL9XSnYhGqFfSlYQj7RlYJlNFqMp2ArninSXWzMc/Aui+n3DKYYUk1/ZLDIyj9g sImV9zBYYnAvg2WKQ8maggGH0poUDDiUNqZgwKG0NQUDDqWeFAw4lL5NwYBD2Z6CAYdyegoGHMrv pGDAoWJKwYBD5Q4GK7Sf1mEMNtO+Wccy2MLKr2CwjcHzGazSvlmbGOwC2Gm9lsFuVsfoZxpr534G e1j5kwz2s2efYXCQ1THwls7qvMXgMIMNvGWz+sZ48xl8jsEDKCXaKGawxPqfgtm7bGkUthjlEQaz sdgGoMeRBtRdBNcQgGagxagB0omoCa2A0IbWoWZWMhJyrQDTuB7KG1mNgXBnBFoGl4amQdkieL4N rWS5BkgboPZqiBdAzREAN8Kzy9i9RWgVQPVQ9tN3De1XU/tJ3aHAebTNlan3a6gMWi5CgwHKhZYa 0Xy42wT3m9BCaDGvX1v/6ckLNSbC+Pu/u5GNpB5CGxv1AmhhOevHUiijb/h/xxhtdQVr0XhuJuQa IUdxpKHpANWznPHmFVBayFrQWNuL2Rg0GGUT4GQF61cjqz3w/7kn/1pvxnloFKu5hvV1EeQnw1gX MuzSuwPYvDSheamxTGJ3FkMJnaWVqADKprA3tbI7jQyH0yFexUZkzIOGBqEKoLpiVMNGozHcroN0 FaMcA0fGHCxkfW1jZU0QL2Dlzex9685jSoOSVtanthSOVjBcGvl61lIze/tyhvM+rM9jbfTNyLLU OFec74XxRF8/WvvVbWbUtgB6PJ+9w8DHGtZvipF/PwYjT+vOh7etYhhZwHjpp5igTyxjUC7Uz4OU UuC8VL//fdsr/j+M/ULrC87PfSujr7657KOefzeC/rR9cb+G9ZsjOhJjLG3sfX10Sds3xroAStaw kTcxrvufKKH+ollvSHHKT/mFYrUN6q1iT9Lerj5PzUY7tOYyqPE/0dDAx7XioqIh2ozFDdrEphVN beuaG7SRTa3NTa31bY1NKwZqI5Yt06Y1LlrctlKb1rCyoXV1w4KBI1ob65dNa1i0all9a99TQ1mh liodOquhdSU8r5UNLBqs5U5snN/atLJpYVseq9X/JiuYOMN4unGlVq+1tdYvaFhe37pUa1r4Hzum Na7Q2uDezBWNbQ0LtOlt9W0N8PCKBYVNrVoT3GnV5jetWtHW2tiwcuB/auR82QwajWqtX9O4YpE2 eeHCxvkN2gBtWtM8eMukxvmLm5bVryzQptRDc/Mb67Xp9atWLIAxaIMqhhTXNK3Sltev01atbIAe wQgWNq1o09qatAWNK5uXwQ3olNbc2giF8+FOA6T1K7XmhtbljW206/PWsYEsg3euoE3ADdpGKytt bm1asGp+Gx3tmsXQkX5vgLRxxfxlqxbAhGh9nWhasWydltuYpzUsnwdt96u94n98O6u+gI6+tWEl HSVFz4UXGNhOtTWMjSi3Ed7S1rCc4rK1Ed66oGnNimVN9QsuRkK9MXSYjvPz0rSqrXlVm7agYTVF M9RZ3LCs+WIMDQQB3MQYu56xDLA0tgLJLgGi/ZyJ+L57xvJC2ZCy2wLuPm439xx3CMJ+7gD31P8q A/+rDPyvMvC/ysD/KgP/N8rARVL3AlzPaObf3fvgonrLoJ3+8phJ5P/Q5jKos65/ns/gB/ET+LH8 JRBXXPSGFdDuf2plEsSrGRYNXl+MO/CDHGJz+5+f+fdwyt+BkjnoLvRv/u1HM7jcPTFf+NizXB46 CYFweZ3x9PB+LodL7xwW1ru5rD3OtGL7iAEc3X0sZLEGcROEXRAOQeDRXC4DylWIN0Boh7ALwiEI xyCI0JEMdleD0ARhO4ST9A6XzoU6tbA6Iofzw7PU0rZzXvQVhCQEDoUhLoQwGcJcCFshbIcgsnq0 pAnCBgiHIJxmd3TO23lnCfTd23kLS/YsWVbMsvVGdk4ty+65osZIJ0410lHjjWpDjWqDSo3igZca aU6BkTqjxe00VazFh0d4OA8MkprwzRBj8iKyY4zCaAeXhjogEE5Mleicc092rHj7IY5HmCMchjkO Jw9zuNPqKB6hkCT5CjlRmHxJeow7pGePzVG8fcRl5EO0C8IhCBz5EK4PyAdoAzlJcQ5xFYTtEA5B OArhKwgiOQnXCbjeJ+8jO3kPFUKogjAXwnYIhyB8BcFE3oNYJX+jPiIWU7gKAiF/g1gl78Kw3oXY To4DdJwch679ubO8ong/A+KFKSAcTQHeYApweoq7yZ86v88DiorBTANFHeQy0XBUwmV2RgeFuzlf Z2VjuJt8tEeLh3eMKCJvog4IBHryJrz5TaRBmAKhDkIzBBGgtwF6G7VD2AZhB4QOCEBlEKsQNPIq hNchvI2KIOgQpkCQyLFOeE03OdoZuzQ8wkPeIH9AXsD4EfIyS18nL7H0NfJ7lr4CaQakr5KXOjPC aIQZ7iN4RoVUhbQQ7gvkd3uyneHkCAc5BLgLQ1wIoQrCZAhzIWyFIJJDJLNzQdgJjRxEr0oIanai z1n6KHpIQvqSsB4bCQSo0Sg29BKAINqubY8RPXbXvZClUez2OwGiUeyGWwGiUezqjQDRKLZsNUA0 ii1YAhCNYrPnAkSj2OQZAEHUTR54JjsnXD55KdZG2MkawNIawNIawNIaxJM19ELf87Rv93fm5wPG 7tPjefnh9gO4/VncPg23P4TbG3D7dbh9I26vxO1X4fY4bg/h9gzcruP2g3gIoKId610XZSt0H25/ Fbc/jdtX4vYYbo/i9mzcruFyvZtEOseXsGQ0S/aMoEwH6SXDQfrYSQQwGgGap56xQxAfhZBkOR0q aZlGZX8GTTP35FcZ+YFDi5tGjCMvwIMvwDS8gE5A4GGCXgAyegEaeQEasENcBWEuhMMQvoKQJPTD xxMkEzq+lcV2iAshVEGYC2EDhK8giKw7X0EgqCnVxV2sY4WpTk+mOfICXPQ/6IqQiJ6uhtS4Oo7b GsL2DDw5I5lBypHHAxLZ6ZAc3di671vrd99akTxCJreTrSgdJmJbKt3a+X16uBvf0xk7GB6Rhu9G GTxQHa5AMfx/GjuD1zaOKA7PrNzsyI4d2TWOiMaaNWuZNus0xTiVGwVZUVdV6R6q2KrRuiLIFgKX Xgor5VbjHgw1Jb0UcshfEBoKszKIldJDrvW5JdccemhvdQ6Fntz3ZldKQl3ooJ03+r1v3tsdjbSL dmEyYNeIp97fIJyhXSVcewx2pcu3oNul7tKyGNAp7NUTf/PfxB880KD5O38inhnBGO2KX0F53BO/ 8CPx8/WAgfLTUkDBDAyF9vma+PFEoV+D42FX7KPpia94WXzBlaMVOu568K5wSWwsbYuPIJ7Nd0XB g5g9sc7vilshdQP79MS7sAtW2LwKO/s2V0nNtAr4aTage4Vl/YFe0z/R39NX9GV9QRf6vJ7SZ9kM S7ApdpGNM8YusDGmMcJm8VE/C/9fn72QQIO3MygZU+2EhrUW3jrQKNPIx0S+GXM0Z7NIHfm0SZxd Q/61aQZ0/M62fMMsUjnjEKdalGuWE+hnGzJrOVKvfFbzKf3OBVVq3wSUVGsBPUPpMIXrBvUJpdOH 91No3zq877okOXdvPbk+k59+/0P7nKoR1a88qpt8rT0vHzibNfnDvCtXsHE27zrye1xYqE9f0D9L dp+eonFr/VievihtoB7L267rBHRLccSgp8DBjDlVHIMTM3LEYOmQexhyGegP3CIa4OJxklFcJh5X 3BhFzvcWS7a/uKiYywbxFONdNl5lTjLAZDKKmTsgJ4o5mTtARuYVwjkgaa4QeoVwhXB6RSFbL5Hr EXI0Qo5Uphh9yfCQmXw+ZCafA2P939IqWhY9zrnNOi7K1DBLLdga8tt7e0l5sGsYftONVmtaauw2 99DutKRrtmzZNG3Dz9XPcdfRnTNtn9RL1ZpfL7Tsbq6QK5k7tntcrqxmX8t1NMq1WjknWAWDrWKu cvYcdxbdZcyVxVxZzFUulFUuouZ4peYzUnQ/qIf2WJsYh/naSC24xbnEl3k1eXMLyf3UAK5WHpEJ y5UXzaKchA1d125fu40u+E6hawpX3opcyf3cQmpAH0WuBMjTZpFY7Y7XIcnS53b48qCA1O7ggIe1 5f1XAV9JFnZsr02II69uOnL9znbN13VQG3hI8uZQm5goBWdPQ/EdEG+iGIuNQNRuoRaPR+C/P/9O ZNU97APtyTEtpGmbeG5Mpp2qBj8F1WiJowFcS+HpwXPhAD1qUW8YI9rt4bOeFsFjHm7tTtSKxqId 2bAndPGGQzIqOFjWaMTaEJD8Awg1gLMKZW5kc3RyZWFtCmVuZG9iagoKMjUgMCBvYmoKMTk1ODgK ZW5kb2JqCgoyNiAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStB cmlhbE1UCi9GbGFncyA0Ci9Gb250QkJveFstNjY0IC0zMjQgMjAwMCAxMDA2XS9JdGFsaWNBbmds ZSAwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50IDIxMQovQ2FwSGVpZ2h0IDEwMDUKL1N0ZW1WIDgwCi9G b250RmlsZTIgMjQgMCBSCj4+CmVuZG9iagoKMjcgMCBvYmoKPDwvTGVuZ3RoIDQ0MC9GaWx0ZXIv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdk8tu2zAQRff6Ci7TRSBx9IoBQ4Bjx4AXfaBOP0CWaEdA LAm0vPDfl3cu2wJdWDgkh8Mz9DDdHnaHcVjSH37qjm4x52HsvbtNd985c3KXYUysmH7oljjSb3dt 5yQNe4+P2+Kuh/E8rddJ+jOs3Rb/ME+bfjq5L0n63ffOD+PFPP3aHsP4eJ/nT3d142KypGlM784h z9d2/tZeXaq7ng99WB6Wx3PY8i/g/TE7Izq2VOmm3t3mtnO+HS8uWWdZY9b7fZO4sf9vrVhxy+nc fbQ+hNoQmmVl1gQW5VrAuXK1Bxec15iSnIMrxpTgmlyAX5RF41fKhebZMKYGv5IteEt+A+/IK/Ab z9qA92TktxljKjD9Kzhb+ldbcPTfgelfwtnSv9Q89K9xlqV/rnvpn8PN0l/gZulfoC5L/1zn6V9o /uj/AqZ/gXot/SvECP0FZwn9a8RIvH/UJdEftUu8f9yzxPtHfqF/qfP0F9Qr9C+Uo7/GR3/UK/Qv 9Sz6i87Tv0btEv2V6S/4H/N4/69g+ofj0Wyxq9B2eBd/2tl0d+9DK+vj0R5G9w6j+/u+5mnGLv39 BvYn3iMKZW5kc3RyZWFtCmVuZG9iagoKMjggMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1 ZVR5cGUvQmFzZUZvbnQvQ0FBQUFBK0FyaWFsTVQKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA0OQov V2lkdGhzWzc1MCA2NjYgMzMzIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc3IDc3NyA1NTYgNTU2IDU1 NiAyMjIgNTAwIDI3NwoyNzcgNTU2IDIyMiA4MzMgNjY2IDYxMCA1MDAgNTgzIDU1NiAyNzcgMTAx NSA1ODMgNzIyIDU1NiA3NzcgNTAwCjI3NyA3MjIgNTAwIDIyMiA1NTYgNTAwIDcyMiAzMzMgODMz IDMzMyAyNzcgNjY2IDMzMyA1NTYgNjY2IDI3Nwo1MDAgMTkwIF0KL0ZvbnREZXNjcmlwdG9yIDI2 IDAgUgovVG9Vbmljb2RlIDI3IDAgUgo+PgplbmRvYmoKCjI5IDAgb2JqCjw8L0YxIDIzIDAgUi9G MiAyOCAwIFIvRjMgMTggMCBSCj4+CmVuZG9iagoKMzAgMCBvYmoKPDwvRm9udCAyOSAwIFIKL1By b2NTZXRbL1BERi9UZXh0XQo+PgplbmRvYmoKCjEgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAx MyAwIFIvUmVzb3VyY2VzIDMwIDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1Ry YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMiAwIFI+PgplbmRvYmoK CjQgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxMyAwIFIvUmVzb3VyY2VzIDMwIDAgUi9NZWRp YUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0 cnVlPj4vQ29udGVudHMgNSAwIFI+PgplbmRvYmoKCjcgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVu dCAxMyAwIFIvUmVzb3VyY2VzIDMwIDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgOCAwIFI+PgplbmRv YmoKCjEwIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTMgMCBSL1Jlc291cmNlcyAzMCAwIFIv TWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC L0kgdHJ1ZT4+L0NvbnRlbnRzIDExIDAgUj4+CmVuZG9iagoKMzEgMCBvYmoKPDwvQ291bnQgNC9G aXJzdCAzMiAwIFIvTGFzdCAzNSAwIFIKPj4KZW5kb2JqCgozMiAwIG9iago8PC9Db3VudCAwL1Rp dGxlPEZFRkYwMDUzMDA2QzAwNjkwMDY0MDA2NTAwMjAwMDMxPgovRGVzdFsxIDAgUi9YWVogMCA1 OTUgMF0vUGFyZW50IDMxIDAgUi9OZXh0IDMzIDAgUj4+CmVuZG9iagoKMzMgMCBvYmoKPDwvQ291 bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMj4KL0Rlc3RbNCAwIFIv WFlaIDAgNTk1IDBdL1BhcmVudCAzMSAwIFIvUHJldiAzMiAwIFIvTmV4dCAzNCAwIFI+PgplbmRv YmoKCjM0IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAy MDAwMzM+Ci9EZXN0WzcgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMzEgMCBSL1ByZXYgMzMgMCBS L05leHQgMzUgMCBSPj4KZW5kb2JqCgozNSAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUz MDA2QzAwNjkwMDY0MDA2NTAwMjAwMDM0PgovRGVzdFsxMCAwIFIvWFlaIDAgNTk1IDBdL1BhcmVu dCAzMSAwIFIvUHJldiAzNCAwIFI+PgplbmRvYmoKCjEzIDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jl c291cmNlcyAzMCAwIFIKL01lZGlhQm94WyAwIDAgNzk0IDU5NSBdCi9LaWRzWyAxIDAgUiA0IDAg UiA3IDAgUiAxMCAwIFIgXQovQ291bnQgND4+CmVuZG9iagoKMzYgMCBvYmoKPDwvVHlwZS9DYXRh bG9nL1BhZ2VzIDEzIDAgUgovT3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovVmll d2VyUHJlZmVyZW5jZXM8PC9EaXNwbGF5RG9jVGl0bGUgdHJ1ZQo+PgovT3V0bGluZXMgMzEgMCBS Cj4+CmVuZG9iagoKMzcgMCBvYmoKPDwvVGl0bGU8RkVGRjAwNDIwMDYxMDA3MzAwNjkwMDYzMDAy MDAwNzAwMDcyMDA2NTAwNzMwMDY1MDA2RTAwNzQwMDYxMDA3NDAwNjkwMDZGMDA2RT4KL0NyZWF0 b3I8RkVGRjAwNDkwMDZEMDA3MDAwNzIwMDY1MDA3MzAwNzM+Ci9Qcm9kdWNlcjxGRUZGMDA0RjAw NzAwMDY1MDA2RTAwNEYwMDY2MDA2NjAwNjkwMDYzMDA2NTAwMkUwMDZGMDA3MjAwNjcwMDIwMDAz MzAwMkUwMDMzPgovQ3JlYXRpb25EYXRlKEQ6MjAxMTAzMzAxMDU2MDQrMDInMDAnKT4+CmVuZG9i agoKeHJlZgowIDM4CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAzMjg2MCAwMDAwMCBuIAowMDAw MDAwMDE5IDAwMDAwIG4gCjAwMDAwMDAzOTIgMDAwMDAgbiAKMDAwMDAzMzAwNCAwMDAwMCBuIAow MDAwMDAwNDEyIDAwMDAwIG4gCjAwMDAwMDEzMzggMDAwMDAgbiAKMDAwMDAzMzE0OCAwMDAwMCBu IAowMDAwMDAxMzU4IDAwMDAwIG4gCjAwMDAwMDE4NDAgMDAwMDAgbiAKMDAwMDAzMzI5MiAwMDAw MCBuIAowMDAwMDAxODYwIDAwMDAwIG4gCjAwMDAwMDI0NTcgMDAwMDAgbiAKMDAwMDAzNDAwMyAw MDAwMCBuIAowMDAwMDAyNDc4IDAwMDAwIG4gCjAwMDAwMDM3NTQgMDAwMDAgbiAKMDAwMDAwMzc3 NiAwMDAwMCBuIAowMDAwMDAzOTY3IDAwMDAwIG4gCjAwMDAwMDQyNjcgMDAwMDAgbiAKMDAwMDAw NDQzMiAwMDAwMCBuIAowMDAwMDExMzIxIDAwMDAwIG4gCjAwMDAwMTEzNDMgMDAwMDAgbiAKMDAw MDAxMTU0MyAwMDAwMCBuIAowMDAwMDExODM0IDAwMDAwIG4gCjAwMDAwMTIwMDIgMDAwMDAgbiAK MDAwMDAzMTY3NyAwMDAwMCBuIAowMDAwMDMxNzAwIDAwMDAwIG4gCjAwMDAwMzE4OTAgMDAwMDAg biAKMDAwMDAzMjQwMCAwMDAwMCBuIAowMDAwMDMyNzUyIDAwMDAwIG4gCjAwMDAwMzI4MDUgMDAw MDAgbiAKMDAwMDAzMzQzOCAwMDAwMCBuIAowMDAwMDMzNDk0IDAwMDAwIG4gCjAwMDAwMzM2MTUg MDAwMDAgbiAKMDAwMDAzMzc0OCAwMDAwMCBuIAowMDAwMDMzODgxIDAwMDAwIG4gCjAwMDAwMzQx MjIgMDAwMDAgbiAKMDAwMDAzNDI2OSAwMDAwMCBuIAp0cmFpbGVyCjw8L1NpemUgMzgvUm9vdCAz NiAwIFIKL0luZm8gMzcgMCBSCi9JRCBbIDxEMjVDMzIyNkIyMTdFNThGMTBBNjdGNTVGQUI2QjVF RD4KPEQyNUMzMjI2QjIxN0U1OEYxMEE2N0Y1NUZBQjZCNUVEPiBdCi9Eb2NDaGVja3N1bSAvQTEz NDYxQUY4RjY2MjY1QTQxOUU0MTA1MUEwQTRENjEKPj4Kc3RhcnR4cmVmCjM0NTQ1CiUlRU9GCg== --Boundary_(ID_V9muBR498hK4gFFKugcayw)-- From teemu.savolainen@nokia.com Wed Mar 30 07:23:29 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0825D3A67FC for ; Wed, 30 Mar 2011 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 KeXiJ1Ek3SQR for ; Wed, 30 Mar 2011 07:23:27 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id C90B53A67F8 for ; Wed, 30 Mar 2011 07:23:26 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2UEOwIq010573; Wed, 30 Mar 2011 17:25:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 17:24:55 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 30 Mar 2011 16:24:54 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Wed, 30 Mar 2011 16:24:49 +0200 From: To: , Thread-Topic: [BEHAVE] On the well-known host heuristic Thread-Index: AQHL7iQ7X8m/EWs7lE+5meLpXFu2mJRF2FQQ Date: Wed, 30 Mar 2011 14:24:48 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110329151548.GB88272@crankycanuck.ca> In-Reply-To: <20110329151548.GB88272@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.26.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2011 14:24:55.0300 (UTC) FILETIME=[3D911C40:01CBEEE6] X-Nokia-AV: Clean Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 14:23:29 -0000 Hi, Would it help (even if not fully solve) if AAAA query would be sent only wh= en: - application actually has IPv4 literal at hand and host has IPv6-only conn= ection (i.e. not just in case) - application is running on host having dual-stack connection and the appli= cation actually needs to determine presence of NAT64 (i.e. not just in case= ) Then as IPv6 transition progresses, the IPv4 literals should become fever, = and hence applications would issue AAAA queries less often.=20 Also if this well-known name were application/os vendor specific, would tha= t still cause similar problem? I don't see how PTR could be used when network uses NSP instead of WKP? Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of ext Andrew Sullivan > Sent: 29. maaliskuuta 2011 17:16 > To: behave@ietf.org > Subject: [BEHAVE] On the well-known host heuristic >=20 > This is a note to amplify my remarks today. >=20 > Using a well-known name in the DNS to detect the existence of a DNS64 > is, frankly, an idea that makes me cringe. Among the deep problems in > the DNS is its somewhat careless commingling of the data plane and > control plane. What this sort of proposal does is make that > commingling worse, by using the exact same form of query and answer > sometimes for control, and sometimes for data. Reaching back to my > database theory days, I want to call this "minus first normal form" or > something like that. >=20 > So, in the first place, there is a serious architectural issue here. > The point of having data types in the DNS is that the data that you > get from it is supposed to be one kind of data and one kind only. But > this proposal makes a positive answer to AAAA mean not one, but two > things: (1) you can contact host $name on address $ipv6_address and > (2) there's a NAT64 here. >=20 > In the second place, there's a serious operational side effect to all > this. What this proposal means is that the root name servers for the > DNS will have to take a pile more garbage traffic. A AAAA query for > $well-known-name will be quite common. Any application that cares > about this will issue these queries forever, and when the desired end > goal (native v6 [almost] everywhere) happens, applications on all > those networks will continue to make this AAAA query. It's going to > leak from local networks (it's practically _designed_ to leak), and > we'll never get rid of it. >=20 > So, a well-known name is a terrible idea. It is a filthy hack and it > has bad side effects for the global DNS. It ought to be a > straightforward loser. But, of course, that was true of most NAT > proposals, and we got all of them no matter how stupid they were, > partly by ignoring the work instead of working on the one that would > be least bad. >=20 > What I heard at the mic today is, "We who put IPv4 literals in our > higher-level protocols and who are now depending on them are going to > use a well-known name, because we have practical limitations on doing > other things. We don't have a choice, and this is the way we are > going to do it, period, so get used to it." Since I have no desire to > pretend to be King Canute, then, I have to concede that we need to > document something. But while I am willing to bow to reality and make > an architecturally hideous concession, we simply cannot increase the > garbage queries that will be directed for the rest of eternity at the > root servers. So we need to come up with something to solve the > operational consequences. >=20 > The question I have, then, for the people who are absolutely > determined to go this direction is how many restrictions you really > have. Does this have to be a bog-standard AAAA query? In particular, > I'm wondering whether you could do something with a PTR query (inside > ip6.arpa) instead of a AAAA. I'm imagining a case where you get an > answer for a particular address inside the reverse tree only if there > is a DNS64 in the way. Only if you get the required answer, you may > do the forward AAAA query for the well-known name. >=20 > The reason I am thinking that might be better is that there is > infrastructure (the AS112 project) set up to sink garbage queries of > the sort the well-known name proposal is guaranteed to generate. >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Dmitry.Anipko@microsoft.com Tue Mar 29 11:06:32 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522AF3A6A82; Tue, 29 Mar 2011 11:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqUecnM3tkGt; Tue, 29 Mar 2011 11:06:31 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E884B3A6A76; Tue, 29 Mar 2011 11:06:30 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Mar 2011 11:08:06 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 29 Mar 2011 11:08:07 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Tue, 29 Mar 2011 11:06:43 -0700 From: Dmitry Anipko To: Jari Arkko , "behave@ietf.org" Date: Tue, 29 Mar 2011 11:06:42 -0700 Thread-Topic: [BEHAVE] auth48 changes to draft-ietf-behave-dns64 Thread-Index: AcvuFVJ7m6zL2unxS86JVDByZkBUEgAJdQ+A Message-ID: References: <041d01cbedf1$329be590$97d3b0b0$@com> <4D91DE99.20206@piuha.net> In-Reply-To: <4D91DE99.20206@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 30 Mar 2011 08:10:49 -0700 Cc: 'David Harrington' , "behave-chairs@tools.ietf.org" , "draft-ietf-behave-dns64@tools.ietf.org" , "ietf@ietf.org" Subject: Re: [BEHAVE] auth48 changes to draft-ietf-behave-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, 29 Mar 2011 18:06:32 -0000 Hi, I have a question about the particular part of the suggested diff. The diff= says: >>Alternatively, *if configured to do so*, it MAY treat the answer as... Does the part marked with stars imply that an implementation must support s= uch configuration setting, or the support of such configuration setting is = also covered by the following MAY? Thank you, Dmitry -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Jari Arkko Sent: Tuesday, March 29, 2011 6:29 AM To: behave@ietf.org Cc: behave-chairs@tools.ietf.org; 'David Harrington'; ietf@ietf.org; draft-= ietf-behave-dns64@tools.ietf.org Subject: Re: [BEHAVE] auth48 changes to draft-ietf-behave-dns64 I'm OK with these changes. Jari Dan Wing kirjoitti: > During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that=20 > two sections were not consistent. > > The text in Section 5.1.1 is clear: > > If there is (non-excluded) AAAA data available, DNS64 > SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A > for an analysis of the motivations for and the implications of not > complying with this recommendation). By default, DNS64 > implementations MUST NOT synthesize AAAA RRs when real AAAA RRs > exist > > That is, SHOULD NOT in the general case, and MUST NOT as a default case. > This represents WG consensus. > > > But then 5.1.4 says something slightly different: > > If it receives an answer with at > least one AAAA record containing an address outside any of the > excluded range(s), then it MAY build an answer section for a response > including only the AAAA record(s) that do not contain any of the > addresses inside the excluded ranges. That answer section is used in > the assembly of a response as detailed in Section 5.4. > Alternatively, it MAY treat the answer as though it were an empty > answer, and proceed accordingly. It MUST NOT return the offending > AAAA records as part of a response. > > It seems rather self-defeating to have excluded ranges and then=20 > ignore those. Then the only issue is: if there are both an=20 > excluded AAAA record and a non-excluded one, the above says you=20 > can either return the good one, or not return any AAAA records.=20 > > The proposal is to change the "MAY build an answer section" in 5.1.4 > to "by default MUST build an answer section", so it would read as > follows. The critical changes are highlighted with "^": > > When the DNS64 performs its initial AAAA query, if it receives an > answer with only AAAA records containing addresses in the excluded > range(s), then it MUST treat the answer as though it were an empty > .....................^^^^ > answer, and proceed accordingly. If it receives an answer with at > least one AAAA record containing an address outside any of the > excluded range(s), then it by default SHOULD build an answer section > .................................^^^^^^^^^^^^^^ > for a response including only the AAAA record(s) that do not contain > any of the addresses inside the excluded ranges. That answer section > is used in the assembly of a response as detailed in Section 5.4. > Alternatively, it MAY treat the answer as though it were an empty > answer, and proceed accordingly. It MUST NOT return the offending > AAAA records as part of a response. > =20 > We believe this is in line with the WG consensus in section 5.1.1. > > > The updated files are here: > http://www.rfc-editor.org/authors/rfc6147.txt > http://www.rfc-editor.org/authors/rfc6147.xml > http://www.rfc-editor.org/authors/rfc6147-diff.html > > > We are soliciting feedback for this change until noon (Prague time) > on Friday, April 1. Please send feedback to behave@ietf.org. > > -d > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > =20 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From matthew@matthew.at Wed Mar 30 08:18:49 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B183A6B68 for ; Wed, 30 Mar 2011 08:18:49 -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 8H63AQ7Rni9n for ; Wed, 30 Mar 2011 08:18:47 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 9BCF23A6A57 for ; Wed, 30 Mar 2011 08:18:46 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C13BF16E2; Wed, 30 Mar 2011 17:20:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=xn s62mF6ZahwuEVymvaXxc/vH8c=; b=CcYFGaImsXt2Lge2i0UMCr0Xe9ocmpaEXi JOd+zJvU8nMw4EYcntyH2+DlOIYXk8PTMJD4wTFvNd4f1gKSDNVbC/M+9YcleatU VpXWP/HrgE/+HqoBlGj0v9eLkjVUJUcS2NbxeBBUgT2PmSA7Hqm6Op1rJlHsG26v WI6+5WTk0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id BFD147F8; Wed, 30 Mar 2011 17:20:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 85F161672684; Wed, 30 Mar 2011 17:20:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty47yJAa8KjP; Wed, 30 Mar 2011 17:20:23 +0200 (CEST) Received: from [172.16.82.41] (unknown [89.233.136.234]) by zimbra.skype.net (Postfix) with ESMTPSA id F0B24350702B; Wed, 30 Mar 2011 17:20:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <20110329151548.GB88272@crankycanuck.ca> Date: Wed, 30 Mar 2011 17:20:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17A43FA7-A523-4242-B75D-7CEBA90EC260@matthew.at> References: <20110329151548.GB88272@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1082) Cc: behave@ietf.org Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 15:18:49 -0000 On Mar 29, 2011, at 5:15 PM, Andrew Sullivan wrote: > This is a note to amplify my remarks today. >=20 > Using a well-known name in the DNS to detect the existence of a DNS64 > is, frankly, an idea that makes me cringe. =20 Give me a better way to detect the existence of a DNS64 that doesn't = involve changes to the operating system or resolver library (or = root-level application access) and I'll use it. The issue really is that the only way to find the DNS64 itself is to ask = the DNS resolver to send a packet to it. And the only kind of packets = the DNS resolver will send for me are DNS queries. >=20 >=20 > So, in the first place, there is a serious architectural issue here. > The point of having data types in the DNS is that the data that you > get from it is supposed to be one kind of data and one kind only. But > this proposal makes a positive answer to AAAA mean not one, but two > things: (1) you can contact host $name on address $ipv6_address and > (2) there's a NAT64 here. Actually this is true for all NAT64 queries, even ones *not* being made = by applications that have IPv4 literals in hand. >=20 > In the second place, there's a serious operational side effect to all > this. What this proposal means is that the root name servers for the > DNS will have to take a pile more garbage traffic. A AAAA query for > $well-known-name will be quite common. Any application that cares > about this will issue these queries forever, and when the desired end > goal (native v6 [almost] everywhere) happens, applications on all > those networks will continue to make this AAAA query. It's going to > leak from local networks (it's practically _designed_ to leak), and > we'll never get rid of it. Well, one of the reasons I supposed using a reserved name is that I = presumed that DNS64 devices could terminate the lookup for the name = locally and not let it leak out... and with careful choice of that name = it could be easier to sink at the root as well. The worst case is that each app vendor needs to have = well-known-name.app-vendor.com, which requires hits all over the DNS if = you run >1 app with this requirement. >=20 > So, a well-known name is a terrible idea. It is a filthy hack and it > has bad side effects for the global DNS. Coming up with NAT64 without considering just how many real applications = MUST use IPv4 literals is the terrible idea. This is just fallout from that. >=20 >=20 > What I heard at the mic today is, "We who put IPv4 literals in our > higher-level protocols and who are now depending on them are going to > use a well-known name, because we have practical limitations on doing > other things. We don't have a choice, and this is the way we are > going to do it, period, so get used to it." =20 Yes, that's pretty much what I said. There are IPv4 literals in the higher level protocols of Skype (where I = work now), Adobe Flash Player when running RTMFP (what I worked on = before I came to Skype), BitTorrent, and SIP and ICE. Plus a bunch of = other things that may or may not be as popular as the above. They're there for a reason, and that reason is that putting transient = peer candidate addresses (some of which are in private address space, = btw) into the DNS doesn't work nearly as well. All of these things predate NAT64... all of them are broken by NAT64... = and for all of them the easiest path to get working again in a NAT64 = environment will be to add a shim which allows IPv4 traffic to find the = NAT64. This shim needs to be implementable and deployable on the same = systems these applications are currently running on... so that means no = OS changes, no root-level privilege requirements, no resolver library = changes, etc. > Since I have no desire to > pretend to be King Canute, then, I have to concede that we need to > document something. But while I am willing to bow to reality and make > an architecturally hideous concession, we simply cannot increase the > garbage queries that will be directed for the rest of eternity at the > root servers. So we need to come up with something to solve the > operational consequences. >=20 See above. > The question I have, then, for the people who are absolutely > determined to go this direction is how many restrictions you really > have. Does this have to be a bog-standard AAAA query? In particular, > I'm wondering whether you could do something with a PTR query (inside > ip6.arpa) instead of a AAAA. I'm imagining a case where you get an > answer for a particular address inside the reverse tree only if there > is a DNS64 in the way. Only if you get the required answer, you may > do the forward AAAA query for the well-known name. >=20 > The reason I am thinking that might be better is that there is > infrastructure (the AS112 project) set up to sink garbage queries of > the sort the well-known name proposal is guaranteed to generate. =20 >=20 It would be nice to have it be a single query, but see above for my = comments about how we might sink it better than = one-name-per-app-vendor-inside-.com will be. Matthew Kaufman= From matthew@matthew.at Wed Mar 30 08:19:03 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED383A6B7E for ; Wed, 30 Mar 2011 08:19:03 -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 eQdTfCxhcMKq for ; Wed, 30 Mar 2011 08:19:03 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 0BA893A6B81 for ; Wed, 30 Mar 2011 08:19:03 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A5B3A16E2; Wed, 30 Mar 2011 17:20:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=Tt D63f/b0jhVC2cZjnBStdi6mXk=; b=IQZ4175HI3y8Ss4s6HS9oNtW4c9TrK03TI RrR2iU6XiUJuW2hxIniUJo1cIyOdTBRGvZk1JRW51qxsa/1T3tQ20C2h+DXWQai8 ZaQeE1TFNfP6Z+g7AqT7QGzrS0YfbakkTmOteSA4tJO+3wgFONVNWu+uM+XhbPAh 5KNTAoP7w= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A43637F8; Wed, 30 Mar 2011 17:20:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 549AB169F401; Wed, 30 Mar 2011 17:20:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK2GkBmfUdIr; Wed, 30 Mar 2011 17:20:40 +0200 (CEST) Received: from [172.16.82.41] (unknown [89.233.136.234]) by zimbra.skype.net (Postfix) with ESMTPSA id E001F169F404; Wed, 30 Mar 2011 17:20:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> Date: Wed, 30 Mar 2011 17:20:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D7ED869-4C78-486B-BC60-987E586B9005@matthew.at> References: <20110329151548.GB88272@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1082) Cc: ajs@shinkuro.com, behave@ietf.org Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 15:19:04 -0000 On Mar 30, 2011, at 4:24 PM, = wrote: > Hi, >=20 > Would it help (even if not fully solve) if AAAA query would be sent = only when: > - application actually has IPv4 literal at hand and host has IPv6-only = connection (i.e. not just in case) That's when one would do it. > - application is running on host having dual-stack connection and the = application actually needs to determine presence of NAT64 (i.e. not just = in case) >=20 > Then as IPv6 transition progresses, the IPv4 literals should become = fever, and hence applications would issue AAAA queries less often.=20 If there are really fewer and fewer IPv4 literals (or in some cases, = more and more cases where the IPv4 literal is paired with a valid IPv6 = literal which may be used instead) then yes. Matthew Kaufman= From ajs@shinkuro.com Wed Mar 30 08:37:01 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015853A6B61 for ; Wed, 30 Mar 2011 08:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, 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 pacVYxn-LD16 for ; Wed, 30 Mar 2011 08:36:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 710CE3A6A20 for ; Wed, 30 Mar 2011 08:36:59 -0700 (PDT) Received: from shinkuro.com (dhcp-250f.meeting.ietf.org [130.129.37.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B302E1ECB422 for ; Wed, 30 Mar 2011 15:38:37 +0000 (UTC) Date: Wed, 30 Mar 2011 11:38:35 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110330153834.GF91117@crankycanuck.ca> References: <20110329151548.GB88272@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 15:37:01 -0000 On Wed, Mar 30, 2011 at 02:24:48PM +0000, teemu.savolainen@nokia.com wrote: > Hi, > > Would it help (even if not fully solve) if AAAA query would be sent only when: > - application actually has IPv4 literal at hand and host has IPv6-only connection (i.e. not just in case) If I understand this suggestion correctly, the idea is that an application shouldn't actually do this check until it finds it has an IPv4 literal and knows it only has an IPv6 connection to use it on. While I personally like this sort of just-in-time approach, our experience is pretty bad in this area. For instance, many web browsers resolve every name in every link on a page in order to cut page view times. I presume any protocol that decided it had to keep IP address literals in it would be similarly susceptible to performance considerations. > - application is running on host having dual-stack connection and the application actually needs to determine presence of NAT64 (i.e. not just in case) > How would the application know this? > Also if this well-known name were application/os vendor specific, would that still cause similar problem? > It would be worse, in fact. Instead of one well-known name (which could be the only entry in some .arpa zone, so we could set the negative TTL really long), we'd have lots of them with lots more opportunity for garbage queries to get sent along. > I don't see how PTR could be used when network uses NSP instead of WKP? Why not? The idea here is that you _always_ query for something inside the WKP. We just reserve one address (inside the WKP) for this, and make it always return an indication that the DNS64 is in the way. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From teemu.savolainen@nokia.com Wed Mar 30 09:30:47 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE4C3A6A49 for ; Wed, 30 Mar 2011 09:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 4RDQZli54CEJ for ; Wed, 30 Mar 2011 09:30:46 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 3FE533A6A3B for ; Wed, 30 Mar 2011 09:30:46 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2UGWMK4007715; Wed, 30 Mar 2011 19:32:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 19:32:23 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 30 Mar 2011 18:32:23 +0200 Received: from 008-AM1MPN1-036.mgdnok.nokia.com ([169.254.6.195]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Wed, 30 Mar 2011 18:32:22 +0200 From: To: , Thread-Topic: [BEHAVE] On the well-known host heuristic Thread-Index: AQHL7iQ7X8m/EWs7lE+5meLpXFu2mJRF2FQQgAAK7ICAAC84QA== Date: Wed, 30 Mar 2011 16:32:21 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620188FB@008-AM1MPN1-036.mgdnok.nokia.com> References: <20110329151548.GB88272@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> <20110330153834.GF91117@crankycanuck.ca> In-Reply-To: <20110330153834.GF91117@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.82.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2011 16:32:23.0398 (UTC) FILETIME=[0C304060:01CBEEF8] X-Nokia-AV: Clean Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 16:30:47 -0000 > experience is pretty bad in this area. For instance, many web > browsers resolve every name in every link on a page in order to cut > page view times. I presume any protocol that decided it had to keep > IP address literals in it would be similarly susceptible to > performance considerations. Well, true. Some even query partial names while typing URL.. =20 > > - application is running on host having dual-stack connection and the > application actually needs to determine presence of NAT64 (i.e. not > just in case) >=20 > How would the application know this? If IPv4/IPv6 capable application were allergic to NAT64, it might want to c= heck for presence of NAT64 before attempting IPv6 communications? (Except i= f it does happy eyeballs/ICE/similar and tries both IPv4 and IPv6 at the sa= me time).=20 =20 > > I don't see how PTR could be used when network uses NSP instead of > WKP? >=20 > Why not? The idea here is that you _always_ query for something > inside the WKP. We just reserve one address (inside the WKP) for > this, and make it always return an indication that the DNS64 is in the > way. Ok, didn't realize that was your proposal. Well, in such case the feature w= ould have to be mandatory feature on each DNS64 implementation, as otherwis= e hosts would have to do well-known name query just in case DNS64 does not = happen to support PTR-based discovery.. Teemu From ajs@shinkuro.com Wed Mar 30 10:45:38 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA403A6BA9 for ; Wed, 30 Mar 2011 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 XUcRZ2vvr7ll for ; Wed, 30 Mar 2011 10:45:34 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3EDD53A6BA7 for ; Wed, 30 Mar 2011 10:45:34 -0700 (PDT) Received: from shinkuro.com (dhcp-4052.meeting.ietf.org [130.129.64.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 533581ECB41D for ; Wed, 30 Mar 2011 17:47:12 +0000 (UTC) Date: Wed, 30 Mar 2011 13:47:10 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110330174709.GC91371@shinkuro.com> References: <20110329151548.GB88272@crankycanuck.ca> <17A43FA7-A523-4242-B75D-7CEBA90EC260@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17A43FA7-A523-4242-B75D-7CEBA90EC260@matthew.at> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 17:45:38 -0000 On Wed, Mar 30, 2011 at 05:20:22PM +0200, Matthew Kaufman wrote: > > So, in the first place, there is a serious architectural issue here. > > The point of having data types in the DNS is that the data that you > > get from it is supposed to be one kind of data and one kind only. But > > this proposal makes a positive answer to AAAA mean not one, but two > > things: (1) you can contact host $name on address $ipv6_address and > > (2) there's a NAT64 here. > > Actually this is true for all NAT64 queries, even ones *not* being > made by applications that have IPv4 literals in hand. > I don't see how. DNS64 might be a hack (I've never pretended otherwise), but it doesn't change the meaning of a AAAA answer as just "Go here for that". > Well, one of the reasons I supposed using a reserved name is that I > presumed that DNS64 devices could terminate the lookup for the name > locally and not let it leak out... and with careful choice of that > name it could be easier to sink at the root as well. RFC1918 addresses are never supposed to leave a site, and they have no meaning except in a local context. Yet people had to set up the AS112 project in order to divert all the reverse-map queries for addresses in 1918 space. That project didn't get set up because people had a lot of spare time; it got set up because root servers were being hammered by these queries. So while I agree that we could tell DNS64 never to pass these along, I'm not sanguine about what will actually happen. But anyway, that's not the problem. The problem is that we're giving nodes a way to learn whether they're behind a DNS64. One thing we want that for is DNSSEC validation on the end node. That's an absolute requirement for a number of things that people seem to be doing or planning to do with DNSSEC. So, every host that has only an IPv6 connection and wants to do DNSSEC will have to make this query, forever. Since we would like to suppose that in the longish run most of those won't be behind a DNS64, there's nowhere to sink those queries. So they'll have to be answered by the global DNS. Worse, the more successful real IPv6 deployment is, the more acute the problem gets. > The worst case is that each app vendor needs to have > well-known-name.app-vendor.com, which requires hits all over the DNS > if you run >1 app with this requirement. Yes, I completely agree, which is why I'm not screaming "Lord no make it stop!" If people are going to do this anyway, I'd way prefer that everyone do it the same way. > > So, a well-known name is a terrible idea. It is a filthy hack and it > > has bad side effects for the global DNS. > > Coming up with NAT64 without considering just how many real applications MUST use IPv4 literals is the terrible idea. Two things about that: 1. I was always sceptical that NAT64/DNS64 would really work, because of exactly this problem. I suggested we put in some sort of detection from the beginning, but the point was supposed to be that applications and hosts needed _no_ changes to use this. The goal of NAT64/DNS64 was supposed to be practically no intervention on the end points. 2. We always seemed to believe that there were going to be "corner cases" where NAT64/DNS64 was going to break stuff. Maybe we now think that was a bad decision, but that was in fact what we said originally. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From tena@huawei.com Wed Mar 30 14:56:23 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398583A6BDB; Wed, 30 Mar 2011 14:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.288 X-Spam-Level: X-Spam-Status: No, score=-106.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 xYYZd9wg60jQ; Wed, 30 Mar 2011 14:56:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2D9513A6BDA; Wed, 30 Mar 2011 14:56:22 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIW00DN850PXE@usaga04-in.huawei.com>; Wed, 30 Mar 2011 16:58:01 -0500 (CDT) Received: from TingZousc1 ([10.212.244.67]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIW001YV50MDL@usaga04-in.huawei.com>; Wed, 30 Mar 2011 16:58:01 -0500 (CDT) Date: Wed, 30 Mar 2011 23:57:57 +0200 From: Tina Tsou In-reply-to: To: softwires@ietf.org, behave@ietf.org, mboned@ietf.org, 'IPv6 Ops WG' Message-id: <008b01cbef25$896ab010$9c401030$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvuL6fFhcBvvwkUTCOg/Wh+n096dwArU6oAABIOnfA= References: Subject: Re: [BEHAVE] IPv4-IPv6 Multicast meeting on Wed 3:10 PM-4:10 PM X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 21:56:23 -0000 Hi all, Here is the summary for today's meeting. Next steps: 1. Work on problem statement and use case I-D 2. List the work items 3. Request a temporary mailing list 4. Request a BoF for IETF-81 We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Wednesday, March 30, 2011 3:19 PM To: 'softwires@ietf.org'; 'behave@ietf.org'; 'mboned@ietf.org'; 'IPv6 Ops WG' Subject: RE: IPv4-IPv6 Multicast meeting on Wed 3:10 PM-4:10 PM Hi all, Attached please find the proposal from multiple authors. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Tuesday, March 29, 2011 6:38 PM To: 'softwires@ietf.org'; 'behave@ietf.org'; 'mboned@ietf.org'; 'IPv6 Ops WG' Subject: IPv4-IPv6 Multicast meeting on Wed 3:10 PM-4:10 PM Hi all, Per suggestion from the chairs and audience of today's behave meeting, I'm forwarding the following meeting info to the related WGs. You are welcome to join. Subject: IPv4-IPv6 Multicast meeting: summary of this week and next steps When: Wednesday, March 30, 2011 3:10 PM-4:10 PM Prague. Where: Room Tyrolka, Level M We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From ajs@shinkuro.com Thu Mar 31 01:10:21 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E45128C27A for ; Thu, 31 Mar 2011 01:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 fAIet5DR8CFt for ; Thu, 31 Mar 2011 01:10:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E162F28C278 for ; Thu, 31 Mar 2011 01:10:18 -0700 (PDT) Received: from shinkuro.com (dhcp-4052.meeting.ietf.org [130.129.64.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 19AF81ECB41D for ; Thu, 31 Mar 2011 08:11:56 +0000 (UTC) Date: Thu, 31 Mar 2011 04:11:49 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20110331081149.GA92648@shinkuro.com> References: <20110329151548.GB88272@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962018647@008-AM1MPN1-036.mgdnok.nokia.com> <20110330153834.GF91117@crankycanuck.ca> <916CE6CF87173740BC8A2CE4430969620188FB@008-AM1MPN1-036.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <916CE6CF87173740BC8A2CE4430969620188FB@008-AM1MPN1-036.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] On the well-known host heuristic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 08:10:21 -0000 On Wed, Mar 30, 2011 at 04:32:21PM +0000, teemu.savolainen@nokia.com wrote: > > > > Why not? The idea here is that you _always_ query for something > > inside the WKP. We just reserve one address (inside the WKP) for > > this, and make it always return an indication that the DNS64 is in the > > way. > > Ok, didn't realize that was your proposal. Well, in such case the > feature would have to be mandatory feature on each DNS64 > implementation, as otherwise hosts would have to do well-known name > query just in case DNS64 does not happen to support PTR-based > discovery.. I don't think so, although as I think it through I don't think we're any better off if we use the reverse. Here's what I was thinking. DNS64 says this: If a DNS64 server receives a PTR query for a record in the IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the address portion of the QNAME according to the encoding scheme outlined in section 2.5 of [RFC3596], and examine the resulting address to see whether its prefix matches any of the locally- configured Pref64::/n or the default Well-known prefix. […] 1. The first option is for the DNS64 server to respond authoritatively for its prefixes. If the address prefix matches any Pref64::/n used in the site, either a NSP or the Well-Known Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the query using locally-appropriate RDATA. […] 2. The second option is for the DNS64 nameserver to synthesize a CNAME mapping the IP6.ARPA namespace to the corresponding IN- ADDR.ARPA name. In this case, the DNS64 nameserver SHOULD ensure that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA name, and that there is not an existing CNAME at that name. (We're making a small change, I guess, but I don't think it alters these rules.) So, a DNS64 will always either answer authoritatively for the well-known prefix, or else it will produce a CNAME with a target IN-ADDR.ARPA name. But an ordinary resolver on IPv6 will _never_ have data for the WKP, because there isn't data there. Therefore, we can necessarily tell whether there's a DNS64 in the way because of the rules about how reverse data has to be handled. Now, none of this is any better than a forward-zone well-known name (WKN) that gives you the signal, except, I thought, that it would be in the AS112 system. That has the nice property that we'd be sending those garbage queries I was worried about into a system that is actually designed to sink garbage queries instead of against the roots. But I thought some more, and the in6.arpa space that is the WKP for NAT64 isn't actually in the AS112 system (and it's tricky, because of how AS112 grew, to add new things to it). So I'm no longer so sure about this. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Thu Mar 31 05:27:56 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861DF28C12D; Thu, 31 Mar 2011 05:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.364 X-Spam-Level: X-Spam-Status: No, score=-110.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 yPRdqZ3Kd85B; Thu, 31 Mar 2011 05:27:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 64EAC3A6966; Thu, 31 Mar 2011 05:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5018; q=dns/txt; s=iport; t=1301574575; x=1302784175; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=fsCcV0aNuiGf1Q5qhG126QxED+MVuqx2STmLBaDpZjQ=; b=KPjTTh6QxgWQQo6BXzVu+z+FyNu0gWm1VUU+nUdmMWZCylgTWdXtn7Nj uM204XEv2exNr/zh8TIfmAaTmh+AieF3I33o0Wsby0NbPQ2r+bA0d+di0 b2XBdH8tGM54vzfF+/tWDBoVtVofGovIfRWyKO+4FnMQ+0CaX+tFxmDbt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAJNylE2tJXG9/2dsb2JhbACYDYFji113iHmZYZwUhWsE X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208";a="286494139" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 12:29:34 +0000 Received: from dwingWS (rtp-vpn6-995.cisco.com [10.82.251.230]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2VCTWiQ031628; Thu, 31 Mar 2011 12:29:32 GMT From: "Dan Wing" To: "'Dmitry Anipko'" , "'Jari Arkko'" , References: <041d01cbedf1$329be590$97d3b0b0$@com> <4D91DE99.20206@piuha.net> In-Reply-To: Date: Thu, 31 Mar 2011 14:29:32 +0200 Message-ID: <009b01cbef9f$4aacd3b0$e0067b10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvuFVJ7m6zL2unxS86JVDByZkBUEgAJdQ+AAFj8YYA= Content-Language: en-us Cc: ietf@ietf.org, 'David Harrington' , behave-chairs@tools.ietf.org, draft-ietf-behave-dns64@tools.ietf.org Subject: Re: [BEHAVE] auth48 changes to draft-ietf-behave-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, 31 Mar 2011 12:27:56 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Dmitry Anipko > Sent: Tuesday, March 29, 2011 8:07 PM > To: Jari Arkko; behave@ietf.org > Cc: 'David Harrington'; behave-chairs@tools.ietf.org; draft-ietf- > behave-dns64@tools.ietf.org; ietf@ietf.org > Subject: RE: [BEHAVE] auth48 changes to draft-ietf-behave-dns64 > > Hi, > > I have a question about the particular part of the suggested diff. The > diff says: > > >>Alternatively, *if configured to do so*, it MAY treat the answer > as... > > Does the part marked with stars imply that an implementation must > support such configuration setting, or the support of such > configuration setting is also covered by the following MAY? I would interpret as support of such configuration setting as covered by the following MAY. -d > Thank you, > Dmitry > > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: Tuesday, March 29, 2011 6:29 AM > To: behave@ietf.org > Cc: behave-chairs@tools.ietf.org; 'David Harrington'; ietf@ietf.org; > draft-ietf-behave-dns64@tools.ietf.org > Subject: Re: [BEHAVE] auth48 changes to draft-ietf-behave-dns64 > > I'm OK with these changes. > > Jari > > Dan Wing kirjoitti: > > During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that > > two sections were not consistent. > > > > The text in Section 5.1.1 is clear: > > > > If there is (non-excluded) AAAA data available, DNS64 > > SHOULD NOT include synthetic AAAA RRs in the response (see > Appendix A > > for an analysis of the motivations for and the implications of not > > complying with this recommendation). By default, DNS64 > > implementations MUST NOT synthesize AAAA RRs when real AAAA RRs > > exist > > > > That is, SHOULD NOT in the general case, and MUST NOT as a default > case. > > This represents WG consensus. > > > > > > But then 5.1.4 says something slightly different: > > > > If it receives an answer with at > > least one AAAA record containing an address outside any of the > > excluded range(s), then it MAY build an answer section for a > response > > including only the AAAA record(s) that do not contain any of the > > addresses inside the excluded ranges. That answer section is used > in > > the assembly of a response as detailed in Section 5.4. > > Alternatively, it MAY treat the answer as though it were an empty > > answer, and proceed accordingly. It MUST NOT return the offending > > AAAA records as part of a response. > > > > It seems rather self-defeating to have excluded ranges and then > > ignore those. Then the only issue is: if there are both an > > excluded AAAA record and a non-excluded one, the above says you > > can either return the good one, or not return any AAAA records. > > > > The proposal is to change the "MAY build an answer section" in 5.1.4 > > to "by default MUST build an answer section", so it would read as > > follows. The critical changes are highlighted with "^": > > > > When the DNS64 performs its initial AAAA query, if it receives an > > answer with only AAAA records containing addresses in the excluded > > range(s), then it MUST treat the answer as though it were an empty > > .....................^^^^ > > answer, and proceed accordingly. If it receives an answer with at > > least one AAAA record containing an address outside any of the > > excluded range(s), then it by default SHOULD build an answer > section > > .................................^^^^^^^^^^^^^^ > > for a response including only the AAAA record(s) that do not > contain > > any of the addresses inside the excluded ranges. That answer > section > > is used in the assembly of a response as detailed in Section 5.4. > > Alternatively, it MAY treat the answer as though it were an empty > > answer, and proceed accordingly. It MUST NOT return the offending > > AAAA records as part of a response. > > > > We believe this is in line with the WG consensus in section 5.1.1. > > > > > > The updated files are here: > > http://www.rfc-editor.org/authors/rfc6147.txt > > http://www.rfc-editor.org/authors/rfc6147.xml > > http://www.rfc-editor.org/authors/rfc6147-diff.html > > > > > > We are soliciting feedback for this change until noon (Prague time) > > on Friday, April 1. Please send feedback to behave@ietf.org. > > > > -d > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From mcr@sandelman.ca Wed Mar 30 00:06:59 2011 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727853A6B1E for ; Wed, 30 Mar 2011 00:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4-pxEoomjkN for ; Wed, 30 Mar 2011 00:06:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 505F93A6B11 for ; Wed, 30 Mar 2011 00:06:57 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-164d.meeting.ietf.org [130.129.22.77]) by relay.sandelman.ca (Postfix) with ESMTPS id 5600C3449F for ; Wed, 30 Mar 2011 03:08:36 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2403198B25 for ; Tue, 29 Mar 2011 17:28:23 +0200 (CEST) From: Michael Richardson To: behave@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) Date: Tue, 29 Mar 2011 17:28:23 +0200 Message-ID: <25942.1301412503@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 31 Mar 2011 10:41:16 -0700 Subject: [BEHAVE] TTL in reply for DNS64 -- should be 1. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 07:06:59 -0000 I'm sorry if this a repeat. {Although I've been on the mailing list a long time, I have been ignoring it, and actually made a decision to unsubscribe a few hours ago... I don't think I've succeeded yet.} Monday, I tried the ietf-nat64 network. I found that I got the wrong DNS server via RA, and that was fixed. I expected to have to put the correct one into my local recursive resolvers' "forwarder" list, but in fact to my surprise my /etc/resolv.conf was updated by NetworkManager. It wasn't until I started filling out they survey that I realized I should flush my DNS cache, that I'd have to. So, this needs to be addressed somewhere --- we really need some signal in the RA that there is a NAT64 available, and therefore if you have a local recursive resolver, you should either do DNS64, or you should pay more serious attention to the DNS value you get from the RA (or the DHCPv6). I discovered some things that did not work (mostly in my IM client), which I reported.... aha... do I have to flush my DNS cache? yes, I do. marajade-[~] mcr 10005 %dig @2001:df8:0:7::1 www.credil.org aaaa ;; ANSWER SECTION: www.credil.org. 6118 IN AAAA 64:ff9b::adec:8254 The TTL in the reply is way too high. I can easily imagine wandering in and out of IPv6 only networks (with suspends in between). I shouldn't have to flush my DNS cache each time. I'd like to suggest that the TTL be 1. Section 5.1.7 of draft-ietf-behave-dns64-11 says: o The TTL field is set to the minimum of the TTL of the original A RR and the SOA RR for the queried domain. (Note that in order to obtain the TTL of the SOA RR, the DNS64 does not need to perform a new query, but it can remember the TTL from the SOA RR in the negative response to the AAAA query. If the SOA RR was not delivered with the negative response to the AAAA query, then the DNS64 SHOULD use a the minimum of the TTL of the original A RR and 600 seconds. It is possible instead to query explicitly for the SOA RR and use the result of that query, but this will increase query load and time to resolution for little additional benefit.) This is in keeping with the approach used in negative caching ([RFC2308]. I can see that this is trying to find a heuristic that tries to find a reasonable upper bound so that if a AAAA does appear then it won't take too long to discover this. Unfortunately, it fails, I think, for mobile nodes that can be on different networks in series without restarting. I.e. laptops and smartphones. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.
T= o start,=20 IMO, having something similar to http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-is= sues-05#section-26.2 = would be=20 useful (BTW, you can copy that text).