wrote: > > I object to the text "List in one single document all requirements a > mobile device is to comply with to connect to an IPv6 or dual-stack mobile > network." > > > > There are tens of millions of consumer devices out there that connect to > dual-stack mobile networks every day, and yet none of them meet all the > requirements of this document. Actually, I bet none of them even meet all > the MUSTs in the document. > > > > Correction. There are 10s of millions of devices that connect to *a* dual > stack mobile network. There is only one that is default on, afaik. And > devices that work on that network, afaik, don't work on anyone else's > network (except iPhone ?). right ? > Fair point. But this document is not about interoperability. It's a document that mostly says "device manufacturers, you must implement all these technologies in order to connect". > Everything at vzw is a one off (this is an exaggeration), and it is > naive to say what works for them works for others (they are a cdma + LTE > network, which is a rare bird globally, and not in scope for this document) > Actually, from an IPv6 perspective (which is really all this document should cover, because the other stuff is in the realm of 3GPP), the basic setup is pretty standard - IPV4V6 PDP type, DNS via PCO, and that's it. Basically requirements 1, 4, 7, 8, 11 and 32. The other 29 (!!!) requirements in this document are not implemented because they are not needed. And that's the point. We must not make the statement that all these things are requirements, because if by some unlucky chance the community believes that statement, then we will never see deployment of IPv6 in mobile networks - people will just look at all the list of requirements and give up without even trying. You know as well as I do that supporting one IPV6 PDP type and 464xlat is sufficient to start a mobile deployment. Then why does this document have 35 requirements? > This document is not a statement of where vzw is today. This document is > a statement of what a rough consensus of the ietf is, and the discussion > is guided by 3gpp operators who participate in ietf. > None of which operators have networks that require - or even support - all the requirements in this specification. Only a slim few of which operators have an IPv6-capable network at all. And that's the point. The operator who deployed IPv6 did so without needing all this stuff. And I can guarantee that any operator who waits for all this stuff to be implemented will not deploy IPv6 in any reasonable timeframe. > That said, I am not strongly attached to the wording in question. > > Send text. > "List all the technologies that the v6ops working group thinks might be useful in a mobile device, including technologies still at the draft stage." ... because at the end of the day that's what this document contains. Except for a very small number, the requirements in this doc aren't required to connect or deploy (and Verizon Wireless's network is an existence proof of that). Since they're not required, we can't call them requirements. And if they're not requirements, then what are they? Nice-to-haves? Suggestions? We can say they're the technologies we'd like to see deployed in mobile networks, but that doesn't really have much value from a technical perspective... An alternative is "List the technologies that if implemented in a mobile device is likely to provide the greatest IPv6 functionality in the largest number of current and future deployment scenarios". This is an improvement on the current text insofar as it does not contain a false statement ("Lists [...] all requirements a mobile device is to comply with to connect"). --001a11c21a8cecfc9a04dba97b91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 1, 2013 at 11:04 PM, cb.list6 <cb.list6@gmai= l.com> wrote:

> I object to the text "List i= n one single document all requirements a mobile device is to comply with to= connect to an IPv6 or dual-stack mobile network."
>
> There are tens of millions of consumer devices out there that connect = to dual-stack mobile networks every day, and yet none of them meet all the = requirements of this document. Actually, I bet none of them even meet all t= he MUSTs in the document.
>

Correction. There are 10s of millions of devices that = connect to *a* dual stack mobile network. There is only one that is default= on, afaik. And devices that work on that network, afaik, don't work on= anyone else's network (except iPhone ?). right ?

Fair point. But this document is not about interoperabili= ty. It's a document that mostly says "device manufacturers, you mu= st implement all these technologies in order to connect".

Everything at vzw is a one off (this is an exaggeration), an= d it is naive to say what works for them works for others (they are a cdma = + LTE network, which is a rare bird globally, and not in scope for this doc= ument)

Actually, from an IPv6 perspective (which is really all t= his document should cover, because the other stuff is in the realm of 3GPP)= , the basic setup is pretty standard - IPV4V6 PDP type, DNS via PCO, and th= at's it. Basically requirements 1, 4, 7, 8, 11 and 32. The other 29 (!!= !) requirements in this document are not implemented because they are not n= eeded.

And that's the point. We must not make the statemen= t that all these things are requirements, because if by some unlucky chance= the community believes that statement, then we will never see deployment o= f IPv6 in mobile networks - people will just look at all the list of requir= ements and give up without even trying.

You know as well as I do that supporting one IPV6 PDP t= ype and 464xlat is sufficient to start a mobile deployment. Then why does t= his document have 35 requirements?

This document is not a statement of where vzw is today.=A0 T= his document is a statement of what a rough consensus=A0 of the ietf is, an= d the discussion is guided by 3gpp operators who participate in ietf.

None of which operators have networks that require - or even support -= all the requirements in this specification. Only a slim few of which opera= tors have an IPv6-capable network at all. And that's the point. The ope= rator who deployed IPv6 did so without needing all this stuff. And I can gu= arantee that any operator who waits for all this stuff to be implemented wi= ll not deploy IPv6 in any reasonable timeframe.

That said, I am not strongly attached to the wording in ques= tion.

Send text.=A0
"List all the techno= logies that the v6ops working group thinks might be useful in a mobile devi= ce, including technologies still at the draft stage."

... because at the end of the day that's what this docum= ent contains. Except for a very small number, the requirements in this doc = aren't required to connect or deploy (and Verizon Wireless's networ= k is an existence proof of that). Since they're not required, we can= 9;t call them requirements. And if they're not requirements, then what = are they? Nice-to-haves? Suggestions? We can say they're the technologi= es we'd like to see deployed in mobile networks, but that doesn't r= eally have much value from a technical perspective...

An alternative is "List the technologies that if i= mplemented in a mobile device is likely to provide the greatest IPv6 functi= onality in the largest number of current and future deployment scenarios&qu= ot;.

This is an improvement on the current text insofar as i= t does not contain a false statement ("Lists [...] all requirements a = mobile device is to comply with to connect").

--001a11c21a8cecfc9a04dba97b91-- From mohamed.boucadair@orange.com Wed May 1 23:33:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37F921F99B4 for ; Wed, 1 May 2013 23:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULcENmskCVr2 for ; Wed, 1 May 2013 23:33:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56A21F99B1 for ; Wed, 1 May 2013 23:33:27 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7674D22D149; Thu, 2 May 2013 08:33:25 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 58CC927C059; Thu, 2 May 2013 08:33:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 2 May 2013 08:33:25 +0200 From: To: Lorenzo Colitti Date: Thu, 2 May 2013 08:33:22 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.txt Thread-Index: Ac5GJy1CGfOjcFRgTJyCrpwJqRM4NQA1xKYQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ECB38D06B@PUEXCB1B.nanterre.francetelecom.fr> References: <20130430055848.18338.83714.idtracker@ietfa.amsl.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: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36ECB38D06BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.2.31529 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 06:33:34 -0000 --_000_94C682931C08B048B7A8645303FDC9F36ECB38D06BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lorenzo, Since you think the wording is confusing, what about making this change: OLD: List in one single document all requirements ... NEW: List in one single document a comprehensive list of requirements ... Better? Cheers, Med De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de L= orenzo Colitti Envoy=E9 : mercredi 1 mai 2013 06:46 =C0 : internet-drafts@ietf.org Cc : v6ops@ietf.org WG; i-d-announce@ietf.org Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.t= xt I object to the text "List in one single document all requirements a mobile= device is to comply with to connect to an IPv6 or dual-stack mobile networ= k." There are tens of millions of consumer devices out there that connect to du= al-stack mobile networks every day, and yet none of them meet all the requi= rements of this document. Actually, I bet none of them even meet all the MU= STs in the document. So obviously, mobile devices don't need to comply with these requirements "= to connect to an IPv6 or dual-stack mobile network". Please remove the text or reword it to reflect reality. On Tue, Apr 30, 2013 at 2:58 PM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF= . Title : Internet Protocol Version 6 (IPv6) Profile for 3G= PP Mobile Devices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-03.txt Pages : 17 Date : 2013-04-29 Abstract: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-0= 3 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_94C682931C08B048B7A8645303FDC9F36ECB38D06BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lorenzo= ,

Since you think the wording is conf= using, what about making this change:

OLD:

List in one s= ingle document all requirements …

NEW:

List in one s= ingle document a comprehensive list of requirements …

Better?

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New";color= :#1F497D'>

Cheer= s,

Med=

= De = : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e Lorenzo Colitti
Envoy=E9 : mercredi 1 mai 2013 06:46=C0 : internet-drafts@ietf.org
Cc : v6ops@ietf= .org WG; i-d-announce@ietf.org
Objet : Re: [v6ops] I-D Actio= n: draft-ietf-v6ops-mobile-device-profile-03.txt

= I object to the text "List in one single document all requirements a m= obile device is to comply with to connect to an IPv6 or dual-stack mobile n= etwork."

There are tens of millions of consumer devi= ces out there that connect to dual-stack mobile networks every day, and yet= none of them meet all the requirements of this document. Actually, I bet n= one of them even meet all the MUSTs in the document.

So obviously, mobile devices don't need to comply with these requirements= "to connect to an IPv6 or dual-stack mobile network".=

Please remove the text or reword it to reflect reality.<= /o:p>

<= div>

On Tue, Apr 30, 2013 at 2:58 PM, <internet-drafts@ietf.or= g> wrote:

A New Internet-Draf= t is available from the on-line Internet-Drafts directories.
This = draft is a work item of the IPv6 Operations Working Group of the IETF.
<= br> Title : I= nternet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
= Author(s) : David Binet
= ; &nb= sp; Mohamed Boucadair
&= nbsp; Ales Vizdal
= ; &nb= sp; Cameron Byrne
= ; Gang Chen
&nbs= p; Filename : draft-ietf-v6ops-mobile-device-pro= file-03.txt
Pages = ; : 17
Date &nbs= p; : 2013-04-29

Abstract:
This document= specifies an IPv6 profile for 3GPP mobile devices. It
&nbs= p;lists the set of features a 3GPP mobile device is to be compliant
&nbs= p; with to connect to an IPv6-only or dual-stack wireless network
= (including 3GPP cellular network and IEEE 802.11 network).
=
This document defines a different profile than the one for= general
connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this docume= nt identifies
also features to deliver IPv4 connectivity se= rvice over an IPv6-only
transport.

Both= hosts and devices with capability to share their WAN (Wide Area
= Network) connectivity are in scope.

The IETF datatracker s= tatus page for this draft is:
https://datatra= cker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile

There's= also a htmlized version available at:
http://to= ols.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-03

A di= ff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-pro= file-03

Internet-Drafts are also available by anonymous FTP = at:
ft= p://ftp.ietf.org/internet-drafts/

______________________________= _________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops=

= --_000_94C682931C08B048B7A8645303FDC9F36ECB38D06BPUEXCB1Bnante_-- From lorenzo@google.com Wed May 1 23:45:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497B021F8512 for ; Wed, 1 May 2013 23:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTpuAeBdQY2C for ; Wed, 1 May 2013 23:45:17 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 361F521F8518 for ; Wed, 1 May 2013 23:45:13 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id k14so208399oag.28 for ; Wed, 01 May 2013 23:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ilnMr0VuAwiWYLeaA8neSWO48ihsxXC2idJvAOpHjjU=; b=HcWJ3azmZm5W73Qt9jVMmEn13cqb/O/gfiA26ecctV3ohNDliFu9u2TolzQLczupaH EaCmo/tymHifiSdaiIfJ/K8tzxzHAWngWEza1cuh2ciGYvFPafn9vIp2i6ypF/mszsqr 6emC2ZvFoz2eoLaS5zKt5Qd8KFHdyWTGzqQgJLkZFM++KEHj6FrXQHZuQpsMendK3s4b dXZrvSeUb27ah3iWfJ5tfoRXpyuv9A4hXuGn0pSyhDeMENNqDDvQCW8HalRqlLfAFOs7 K9COpokVt0Deh1k2Cmpslc0ikYXkIUzSuDXee8ovB4X2NtdnHjByOwu2qbl8W4aa181V 71YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ilnMr0VuAwiWYLeaA8neSWO48ihsxXC2idJvAOpHjjU=; b=i3jwcMwO9pkV7yl3eL84ytPxVuihkGQ+VV0mYvelok/VsPWjDfjMPJWDppOXX5wYIU siXfRZZRhipOtnZNvWH/t6PsAYDXgignrV0L/+ocw7/VSLvx63TmvfC0+8+ru7tUZT2s dD3mqIPTYXd8d0kXFOObIkVFVNM1X5vAkoYI+lke2cvxms2rcoH3NWkrZprpWFBB3V3n QQly4qwYtyWIWS32wkNDcY90D9T+G/FEeHp59T5qObY6TL4EpHzTkiDPfUX1jyaS+qcu LzZGhQ6VwnkdjBa4whbz7X9+Da5Y72BQC4fCcf+a0vwRAPG6XwMThuYz/JDYJ41vwp9u CVxQ== X-Received: by 10.182.129.230 with SMTP id nz6mr1299244obb.49.1367477113576; Wed, 01 May 2013 23:45:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.226.230 with HTTP; Wed, 1 May 2013 23:44:53 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECB38D06B@PUEXCB1B.nanterre.francetelecom.fr> References: <20130430055848.18338.83714.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36ECB38D06B@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Thu, 2 May 2013 15:44:53 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=089e0149d27c980aa104dbb693ee X-Gm-Message-State: ALoCoQn5hl4lHPPJsf6ovA+oJUrsjKlrfzo9d3bq0EFTNFEkah1Z6CUaJucrqs2RtEwHh5Igq8lctXLoSsMbybSRUulWT9JRH0lFSH5xIz1ezCSBGGy1E+B16o+QSQaBWWcmjvO2rPnA49fIcPyGqQ0+D8maKRyUSHtfszCNE8grAAKnpwNLnqYWyBH9k+o1xzaUzCbdSAGd Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 06:45:23 -0000 --089e0149d27c980aa104dbb693ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 2, 2013 at 3:33 PM, wrote: > OLD: > > List in one single document all requirements =85**** > > ** ** > > NEW:**** > > List in one single document a comprehensive list of requirements =85 > That doesn't fix the problem. The problem I have with this sentence is not with the word "all". The problem is that the rest of the sentence says "requirements a mobile device is to comply with to connect". That wording implies that mobile devices must comply with these requirements to connect. But that's not true, because only a very small number of the requirements in this doc (maybe 5 out of the 35 that you currently have) are actually required to connect. --089e0149d27c980aa104dbb693ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, May 2, 2013 at 3:33 PM, <mohamed.bouc= adair@orange.com> wrote:

OLD:

List in one single document all requiremen= ts =85
=A0

NEW:
List in one single document a comprehensive list of requirement= s =85

That doesn't fix the probl= em.

The problem I have with this sentence is= not with the word "all". The problem is that the rest of the sen= tence says "requirements a mobile device is to comply with to connect&= quot;.

That wording implies that mobile devices must comply wi= th these requirements to connect. But that's not true,=A0because only a= very small number of the requirements in this doc (maybe 5 out of the 35 t= hat you currently have) are actually required to connect.

--089e0149d27c980aa104dbb693ee-- From internet-drafts@ietf.org Mon May 6 01:13:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F00C21F8F07; Mon, 6 May 2013 01:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNjgLjILB41h; Mon, 6 May 2013 01:13:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D126A21F8F11; Mon, 6 May 2013 01:13:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130506081338.9763.70951.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2013 01:13:38 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:13:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-02.txt Pages : 19 Date : 2013-05-06 Abstract: As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionality that needs to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues relating to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.nospam@gmail.com Mon May 6 01:16:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3B21F8F0C for ; Mon, 6 May 2013 01:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlaEF9SB0wd5 for ; Mon, 6 May 2013 01:16:12 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 99BA021F8F3C for ; Mon, 6 May 2013 01:16:11 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 13so3106484lba.22 for ; Mon, 06 May 2013 01:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :references:to:message-id:mime-version:x-mailer; bh=VPsaSR7hW7IWfKC69BfLXfZ9H4MAFRZFJTurt9cy+HQ=; b=yEfnTtFqqZOTZMMvm5itom3BRSygzkfDQvefupFhihpkNm1HhxHOoFw+HpouTFc4j+ Ssroey8FYF+3xF25kN68R7g2f1nOqMdkVWd2OqN47HQr4vPIMjDNEx/Fqxsekg9nnj4V aSxO+Pgsxs4hT1NGNippN7KLlj/pJiS2WdE8urZk5sSHrh6ZxeBGK2C+v3ayrV7NABXm KvLbXp/+/tVOSOMjK9PU6KufhORYKqyIZXnByH0ZS20kTDUJ+4XXy/YulV9GYNjJdU84 gM0BbryqO/lEfygp2nX+/3ng9K/ipjfS7t/C/mVTuKwKVRo+Z63ioH65x+GYv3jfb2ZI 6V7Q== X-Received: by 10.112.59.68 with SMTP id x4mr7554297lbq.121.1367828170518; Mon, 06 May 2013 01:16:10 -0700 (PDT) Received: from [192.168.250.213] ([194.100.71.98]) by mx.google.com with ESMTPSA id z10sm6561125lbv.14.2013.05.06.01.16.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 01:16:09 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 May 2013 11:16:15 +0300 References: <20130506081341.9763.24469.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org Operations" Message-Id: <08ADEA85-6632-4D23-8998-1D16ED2DE43E@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) X-Mailer: Apple Mail (2.1503) Subject: [v6ops] Fwd: New Version Notification for draft-ietf-v6ops-rfc3316bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:16:16 -0000 Folks, We have updated the RFC 3316bis based on the discussion/comments in the last IETF. The I-D is getting to "about ready" state now. - Jouni Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-v6ops-rfc3316bis-02.txt > Date: May 6, 2013 11:13:41 AM GMT+03:00 > To: Teemu Savolainen , Jari Arkko = , Jouni Korhonen , Suresh = Krishnan >=20 >=20 > A new version of I-D, draft-ietf-v6ops-rfc3316bis-02.txt > has been successfully submitted by Jouni Korhonen and posted to the > IETF repository. >=20 > Filename: draft-ietf-v6ops-rfc3316bis > Revision: 02 > Title: IPv6 for 3GPP Cellular Hosts > Creation date: 2013-05-06 > Group: v6ops > Number of pages: 19 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc3316bis-02.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis > Htmlized: = http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-02 >=20 > Abstract: > As the deployment of third and fourth generation cellular networks > progresses, a large number of cellular hosts are being connected to > the Internet. Standardization organizations are making Internet > Protocol version 6 (IPv6) mandatory in their specifications. > However, the concept of IPv6 covers many aspects and numerous > specifications. In addition, the characteristics of cellular links > in terms of bandwidth, cost and delay put special requirements on = how > IPv6 is used. This document considers IPv6 for cellular hosts that > attach to the General Packet Radio Service (GPRS), Universal Mobile > Telecommunications System (UMTS), or Evolved Packet System (EPS) > networks (Hereafter collectively referred to as 3GPP networks). = This > document also lists out specific IPv6 functionality that needs to be > implemented in addition what is already prescribed in the IPv6 Node > Requirements document. It also discusses some issues relating to = the > use of these components when operating in these networks. This > document obsoletes RFC 3316. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From fred@cisco.com Mon May 6 11:27:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1551221F91CE for ; Mon, 6 May 2013 11:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiNu7kTQgBDW for ; Mon, 6 May 2013 11:27:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 85EC221F91AB for ; Mon, 6 May 2013 11:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=149; q=dns/txt; s=iport; t=1367864860; x=1369074460; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fQexN4IH6aI3l1RR9xeASkqmLFcUagCdiSPav8jvXr8=; b=OyguvC8NCnihXPf2WP1hXpiKnD/XB2i4OpTmYQP3B9B1BuMwDtFJ5LJm S9RvTeVGx7vdHE6RMHFXoiHho+nfRz9xYVCiNehTylSnGy8HtugEWLZo7 PALBosgD45aRNdQqg6+eOWzkVtHeGAXIGNnu88i7FUTabLiyQfiYuW6CR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0HALb1h1GtJXHA/2dsb2JhbAAvIYMHvzOBAxZ0giEBBB0dPxIBKhRCJwQODYgEwEWPADGCeWEDqGKDDYIn X-IronPort-AV: E=Sophos;i="4.87,623,1363132800"; d="scan'208";a="207094526" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 06 May 2013 18:27:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r46IRIMS010548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 18:27:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 6 May 2013 13:27:18 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Regarding draft-ietf-v6ops-64share WGLC Thread-Index: AQHOSodXgSfvVSRVGkaD/gd7VbLhFQ== Date: Mon, 6 May 2013 18:27:18 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B852622@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Regarding draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 18:27:46 -0000 The working group last call for this draft-ietf-v6ops-64share announced las= t week continues for another week. Please feel free to comment on it. From john_brzozowski@cable.comcast.com Tue May 7 15:04:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA8A21F9134 for ; Tue, 7 May 2013 15:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.482 X-Spam-Level: X-Spam-Status: No, score=-98.482 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8HlKZ2gpxcq for ; Tue, 7 May 2013 15:04:10 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9B921F905F for ; Tue, 7 May 2013 15:04:10 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.51631401; Tue, 07 May 2013 18:02:57 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.34]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Tue, 7 May 2013 18:04:07 -0400 From: "Brzozowski, John" To: v6ops Thread-Topic: Comcast Launches IPv6 for Business Customers Thread-Index: AQHOS27Lbvgi7Isd4067IGCHPKwzyg== Date: Tue, 7 May 2013 22:04:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_BD87928F6BFAEF4EBEB883E1C4F5877234222FC3PACDCEXMB01cabl_" MIME-Version: 1.0 Subject: [v6ops] Comcast Launches IPv6 for Business Customers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 22:04:15 -0000 --_000_BD87928F6BFAEF4EBEB883E1C4F5877234222FC3PACDCEXMB01cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI for folks that are interested, apologies if you received this mail mult= iple times: http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-busin= ess-customers John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_BD87928F6BFAEF4EBEB883E1C4F5877234222FC3PACDCEXMB01cabl_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

FYI for = folks that are interested, apologies if you received this mail multipl= e times:

http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-bus= iness-customers

John

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

John Jas= on Brzozowski

Comcast = Cable

e) = mailto:john_brzozowski= @cable.comcast.com

w) = http://www.comcast6.net

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--_000_BD87928F6BFAEF4EBEB883E1C4F5877234222FC3PACDCEXMB01cabl_-- From markzzzsmith@yahoo.com.au Thu May 9 04:05:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB88921F8DFC for ; Thu, 9 May 2013 04:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cuh20tCsHgXP for ; Thu, 9 May 2013 04:04:56 -0700 (PDT) Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1084A21F8EE8 for ; Thu, 9 May 2013 04:04:39 -0700 (PDT) Received: from [98.139.212.153] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 09 May 2013 11:04:39 -0000 Received: from [98.139.212.230] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 09 May 2013 11:04:39 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 09 May 2013 11:04:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 446421.97153.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 79706 invoked by uid 60001); 9 May 2013 11:04:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1368097479; bh=VJh7hf1LMJk3M8VWxWuSvww8iVO/wkd6EuidJC0/NmA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3k/4zJgJoeBXnuhz83js5MtgRuJLXqFUqLXKedRDQ0IDE1EdR+tsUzKOjwUoKH4Ae0xXS8iBTpp2apRikVLd/T1oB0FTT177cYkXxGtsDoqGseBZrhL1EeksqCHAEiqk4D0/lRbDlqoC42k1OkjhnlDM6nCCKB6pNhgn4xqJtso= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jzhRGFzwgojRSc+3awm8u9LpbeCHniTYB8NsLyB6PFJtOtc2VU7dQ6Akp4HdYpMq9gQTNAoScHTzlqFPRaiFFA1tYbSewpYaDCQ9VGodEur2FweFZ9X8G0h1VxHGkespOtgNqh4Q3jMNUt+eppxLzv1t5I8v/Dn0SfOfvSnmEmE=; X-YMail-OSG: EZ35mPoVM1lauMamntlc0UhXh6sk2lFOM2YW6xADiL0eh7H nfWi.ryB6mbojP_YSRvPLs_ekQipmLRDJwEvgYFVQtik6BMm_DoptTFrazf8 vD8DVoFIOPRHUZwNwCXJmRoSiSKmQJe9mOXVcSTjhRA2bfXvdjRzxyqivLij 1oU1icQ_9rPLX6vfjSxQ02z9Uc8gOO72jRtrF6RVfP7ALX4qOUto5o0nFTTR TukpoPuvowBv6HVAAGXVhHKNvhaayY8OdgOb1OVGitZ8.s9MfwMJIKzYd3SO GPTXMUL8JCg8_yMg6Sv6kKxd0DzNmbdgAtQXzcLRBWwHvjwML_fUNsLpOIqY vUwh.HLodmsl7IDKgf0.Yx99yAYE43ATWqsUX88E6CIR8kba7hvgiPC1WHat dhwPnWM_8zBzVdI3eQ1qqiHLQ.sy7NX7j6.QjFvmSEcmu9q1So_76.5fNjK7 PU4tbZ6naT3F8V78iPu7b0x5HLNsf_O35eUWVN.USdVqk94nwzBVQQa2AKe3 InXxS.sJd0d4l.MgEE8fdrVw- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Thu, 09 May 2013 04:04:39 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4KPiBUbzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IE1vbmRheSwgMjkgQXByaWwgMjAxMyA2OjAwIEFNCj4gU3ViamVjdDogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTY0c2hhcmUgV0dMQwo.IAo.VCBoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvZiAKPiBodHRwOi8vdG9vbHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <8C48B86A895913448548E6D15DA7553B8298F8@xmb-rcd-x09.cisco.com> Message-ID: <1368097479.77285.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 9 May 2013 04:04:39 -0700 (PDT) From: Mark Smith To: "Fred Baker $fred$" , "v6ops@ietf.org" In-Reply-To: <8C48B86A895913448548E6D15DA7553B8298F8@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 11:05:02 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) =0A> To: "v6ops@ietf.org" =0A> Cc: =0A> Sent: Mon= day, 29 April 2013 6:00 AM=0A> Subject: [v6ops] draft-ietf-v6ops-64share WG= LC=0A> =0A>T his is to initiate a two week working group last call of =0A> = http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it now. If= you =0A> find nits (spelling errors, minor suggested wording changes, etc)= , comment to =0A> the authors; if you find greater issues, such as disagree= ing with a statement or =0A> finding additional issues that need to be addr= essed, please post your comments =0A> to the list.=0A> =0A> We are looking = specifically for comments on the importance of the document as =0A> well as= its content. If you have read the document and believe it to be of =0A> op= erational utility, that is also an important comment to make.=0A> =0A> =0A= =0A=0AFirstly, I I think this document is of value, as it facilitates IPv6= =0Aconnectivity to hosts tethered to 3GPP devices which don't support DHCPv= 6-PD.=0A=0AI think there are some areas where it needs to be improved.=0A= =0AGeneral=0A~~~~~~=0A=0AIt isn't clear to me whether the document is descr= ibing what has been=0Aimplemented, what could be implemented or both.=0A=0A= The reason I wonder is specifically because of the first scenario,=0A"No Gl= obal Address on the UE". Assuming that the UE is a smart phone,=0AI'd think= that the user would expect that if they enable tethering,=0Athey could con= tinue to use the phone itself to access the Internet, run=0Avarious Interne= t applications etc. For example, they may be lending or=0Asharing their Int= ernet access to another person using a laptop, rather=0Athan switching from= using their smartphone to their tablet or laptop. In=0Aother words, a mult= iuser scenario. I think the UE losing Internet access=0Awhile providing it = to tethered devices is quite a significant and probably=0Aunacceptable limi= tation, and would most likely confuse most UE end-users=0Awhen it occurs (r= esulting in many support phone calls to their carrier's=0Ahelpdesk, or wors= e, technical relatives or friends).=0A=0AIf the document is describing what= has been implemented, then I think it is=0Areasonable to keep this method = in there, however I think the significant=0Adrawbacks should be described, = and this method being recommended against=0Abeing implemented. On the other= hand, if the document is only describing=0Awhat could be implemented, rath= er than what has been, then I think this=0Ascenario should either be droppe= d or strongly recommended against, as the=0AI think the drawbacks are too s= ignificant.=0A=0A1. Introduction=0A~~~~~~~~~~~~=0A=0Ao =A0UE definition - I= think it would be useful to define what User Equipment=0Ais, because I thi= nk the significance of some of the drawbacks of the=0Adifferent methods may= be influenced by what type of device the UE is. For=0Aexample, for a 3G Wi= fi hotspot device, the device's own loss of Internet=0Aaccess in scenario 1= might be less significant than if the UE is a smart=0Aphone (although, if = the 3G Wifi hotspot device is acting as a DNS cache,=0Alocal NTP server or = similar, then the significance is probably the same)=0A=0Ao =A0Multiple glo= bal prefixes - the text seems to suggest only one global=0AIPv6 prefix ever= be announced over the 3GPP radio interface. I don't=0Aknow if the 3GPP doc= uments specify that, however I think we should always=0Afacilitate announce= ments of multiple IPv6 prefixes, so that IPv6's address=0Aaging capability = can be used to phase in a new IPv6 prefix and then phase=0Aout an old one o= ver a reasonable time period e.g. a month.=0A=0Ao =A0A separated numbered l= ist in the second paragraph would make these=0Apoints clearer=0A=0Ao =A0It = isn't clear whether the last sentence of the 2nd paragraph is=0Aapplying to= all of the numbered list points, or just the last one.=0A=0A=0A3.0 General= Behavior for All Scenarios=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A=0Ao =A0Regard= ing the gateway not consuming any addresses within the /64, and=0Aforwardin= g all traffic to /64 destinations towards the UE, when the UE is=0Aacting a= s a host, I assume it would drop traffic towards non-UE assigned=0Aaddresse= s, as per normal IPv6 host behaviour. However, when the UE becomes=0Aa rout= er in these scenarios, is a sink/null route for the /64 created,=0Aso that = the UE doesn't forward traffic towards non-known destinations back=0Atoward= s the gateway via its default route? Neighbor discovery on the LAN=0Ainterf= ace should give the UE knowledge of the hosts/nodes using addresses=0Awithi= n the /64, so that it only drops traffic for destinations within the=0A/64 = that don't exist.=0A=0A3.1 Scenario 1: No Global Address on the UE=0A~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A=0AIn addition to my thoughts in General abov= e.=0A=0Ao =A0In addition to the PMTUD issue, I think it would also be worth= mentioning=0Athat if the UE is providing other services e.g. DNS caching t= hat require=0Aglobal connectivity, they'll also be impacted.=0A=0Ao =A0"The= 3GPP interface and LAN interface only maintain link-local addresses=0Awhil= e the UE uses RA to announce the /64 to the LAN." - It may be possible=0Afo= r the UE to listen to it's own RAs on it's LAN interface, and therefore=0Au= se SLAAC to configure a LAN global address. For example, Linux provides=0At= his option (sysctl accept_ra =3D 2).=0A=0A3.2 Scenario 2: Global Address On= ly Assigned to LAN=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A=0Ao =A0"Th= e movement of the IPv6 prefix from the 3GPP radio interface to the=0ALAN in= terface may result in long-lived data connections being terminated=0Aduring= the transition from a host-only mode to router-and-host mode."=0A=0AIt may= be worth expanding on this a bit further. In theory, I think an=0Aapplicat= ion should be able to survive this as long as it isn't bound to a=0Aspecifi= c interface, or is relying on the sin6_scope_id value (which usually=0Aconv= eys ifindex, as per RFC4007) not changing. The host's/router's route=0Atabl= e decides the exit interface for packets, rather than always using the=0Ain= terface the selected source address was assigned to. How the OS handles=0Am= oving the address may be disruptive, although I'd think it might be fairly= =0Astraight forward for the OS to be modified to prevent that disruption.= =0A=0AIt isn't completely clear to me as to whether IPv6 uses the weak host= =0Amodel (packets destined to one of the host's addresses can enter the=0Ah= ost via any interface), or the strong host model (packets must enter=0Athe = host on the interface assigned the address), or whether it is an=0Aimplemen= tation decision. RFC4291 (IPv6 Addr. Arch) implies strong, by=0Asaying that= addresses are assigned to interfaces, while RFC6724 (Src. &=0ADst. Selecti= on) implies weak, by only recommending rather than requiring=0Athat the sou= rce address is the one assigned to the interface that will=0Abe used to rea= ch the destination. If it is strong, as the UE is becoming=0Aa router, I th= ink a router by nature supports the weak host model, as it=0Awill logically= forward packets from the non-destination address assigned=0Aingress interf= ace to its other interface assigned the address, and then=0Ahandle it local= ly at the higher layers.=0A=0Ao "The UE checks to make sure the 3GPP interf= ace is active and has an IPv6=0Aaddress." I suggest changing it to "The UE = checks to make sure the 3GPP=0Ainterface is active and has at least one glo= bal IPv6 address."=0A=0A3.3 Scenario 3: A Single Global Address=A0Assigned = to 3GPP Radio and LAN Interface=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~=0A=0Ao =A0"This method also creates complications for = ensuring uniqueness for=0APrivacy Extensions [RFC4941]. =A0Privacy Extensio= ns should be disabled on=0Athe 3GPP radio interface while this method is en= abled." What particular=0Acomplications? I can see there would be some if t= he privacy addresses were=0Acreated independently for the two interfaces, h= owever if a single privacy=0Aaddress was generated, and then assigned to bo= th interfaces, would that=0Aeliminate the complications? Are there others t= hat I'm not seeing?=0A=0A=0Ao =A0"2. The UE checks to make sure the 3GPP in= terfaces is active and has=0Aan IPv6 address." - delete 's' on interfaces.= =0A=0A=0AHTH,=0AMark. From fred@cisco.com Thu May 9 07:03:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8C821F8956 for ; Thu, 9 May 2013 07:03:26 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXRNQI9wm7O0 for ; Thu, 9 May 2013 07:03:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7B26221F891A for ; Thu, 9 May 2013 07:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8658; q=dns/txt; s=iport; t=1368108201; x=1369317801; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lZSWauiJfzn4wC9me7V0TVDBoMF+hOVeeFDgGdcTFB8=; b=H/kuB+qc95+vr/49F/L4EvZ9t2iDVQ+Z9Jj6ToJV/VKA0nEWVcdwnBck QGkeD9D2iSLn3XMJ90mi+0rBqjo23c+XfbK7Q/gC+see2ACLfjPyhLOA8 LJuzyQLbhZsRBmyhrJX+iCBQJ/dD9B3142SgLxWYR7SQxsM2E8TAHb1Bq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMari1GtJXG8/2dsb2JhbABSgwc3wAd7FnSCHwEBAQMBZxIFBwQCAQgRBAEBCyQyHQgCBA4FCIdyAwkGDL01jFKBE4EQAjEHBoJuYQOIYoxqgwaKbYUigw+CJw X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208358420" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 09 May 2013 14:03:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r49E3K5d009920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 14:03:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 9 May 2013 09:03:20 -0500 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] draft-ietf-v6ops-64share WGLC Thread-Index: AQHOTL31ZPXqth3JY0qQqLkL+LkALg== Date: Thu, 9 May 2013 14:03:19 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B856621@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B8298F8@xmb-rcd-x09.cisco.com> <1368097479.77285.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1368097479.77285.YahooMailNeo@web142501.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.40] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3647A7CBF6DF0341924A156C9B23314A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:03:26 -0000 Thanks for a very detailed review. On May 9, 2013, at 4:04 AM, Mark Smith wrote: > Hi, >=20 >=20 > ----- Original Message ----- >> From: Fred Baker (fred) >> To: "v6ops@ietf.org" >> Cc:=20 >> Sent: Monday, 29 April 2013 6:00 AM >> Subject: [v6ops] draft-ietf-v6ops-64share WGLC >>=20 >> T his is to initiate a two week working group last call of=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it now.= If you=20 >> find nits (spelling errors, minor suggested wording changes, etc), comme= nt to=20 >> the authors; if you find greater issues, such as disagreeing with a stat= ement or=20 >> finding additional issues that need to be addressed, please post your co= mments=20 >> to the list. >>=20 >> We are looking specifically for comments on the importance of the docume= nt as=20 >> well as its content. If you have read the document and believe it to be = of=20 >> operational utility, that is also an important comment to make. >>=20 >>=20 >=20 >=20 > Firstly, I I think this document is of value, as it facilitates IPv6 > connectivity to hosts tethered to 3GPP devices which don't support DHCPv6= -PD. >=20 > I think there are some areas where it needs to be improved. >=20 > General > ~~~~~~ >=20 > It isn't clear to me whether the document is describing what has been > implemented, what could be implemented or both. >=20 > The reason I wonder is specifically because of the first scenario, > "No Global Address on the UE". Assuming that the UE is a smart phone, > I'd think that the user would expect that if they enable tethering, > they could continue to use the phone itself to access the Internet, run > various Internet applications etc. For example, they may be lending or > sharing their Internet access to another person using a laptop, rather > than switching from using their smartphone to their tablet or laptop. In > other words, a multiuser scenario. I think the UE losing Internet access > while providing it to tethered devices is quite a significant and probabl= y > unacceptable limitation, and would most likely confuse most UE end-users > when it occurs (resulting in many support phone calls to their carrier's > helpdesk, or worse, technical relatives or friends). >=20 > If the document is describing what has been implemented, then I think it = is > reasonable to keep this method in there, however I think the significant > drawbacks should be described, and this method being recommended against > being implemented. On the other hand, if the document is only describing > what could be implemented, rather than what has been, then I think this > scenario should either be dropped or strongly recommended against, as the > I think the drawbacks are too significant. >=20 > 1. Introduction > ~~~~~~~~~~~~ >=20 > o UE definition - I think it would be useful to define what User Equipme= nt > is, because I think the significance of some of the drawbacks of the > different methods may be influenced by what type of device the UE is. For > example, for a 3G Wifi hotspot device, the device's own loss of Internet > access in scenario 1 might be less significant than if the UE is a smart > phone (although, if the 3G Wifi hotspot device is acting as a DNS cache, > local NTP server or similar, then the significance is probably the same) >=20 > o Multiple global prefixes - the text seems to suggest only one global > IPv6 prefix ever be announced over the 3GPP radio interface. I don't > know if the 3GPP documents specify that, however I think we should always > facilitate announcements of multiple IPv6 prefixes, so that IPv6's addres= s > aging capability can be used to phase in a new IPv6 prefix and then phase > out an old one over a reasonable time period e.g. a month. >=20 > o A separated numbered list in the second paragraph would make these > points clearer >=20 > o It isn't clear whether the last sentence of the 2nd paragraph is > applying to all of the numbered list points, or just the last one. >=20 >=20 > 3.0 General Behavior for All Scenarios > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o Regarding the gateway not consuming any addresses within the /64, and > forwarding all traffic to /64 destinations towards the UE, when the UE is > acting as a host, I assume it would drop traffic towards non-UE assigned > addresses, as per normal IPv6 host behaviour. However, when the UE become= s > a router in these scenarios, is a sink/null route for the /64 created, > so that the UE doesn't forward traffic towards non-known destinations bac= k > towards the gateway via its default route? Neighbor discovery on the LAN > interface should give the UE knowledge of the hosts/nodes using addresses > within the /64, so that it only drops traffic for destinations within the > /64 that don't exist. >=20 > 3.1 Scenario 1: No Global Address on the UE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > In addition to my thoughts in General above. >=20 > o In addition to the PMTUD issue, I think it would also be worth mention= ing > that if the UE is providing other services e.g. DNS caching that require > global connectivity, they'll also be impacted. >=20 > o "The 3GPP interface and LAN interface only maintain link-local address= es > while the UE uses RA to announce the /64 to the LAN." - It may be possibl= e > for the UE to listen to it's own RAs on it's LAN interface, and therefore > use SLAAC to configure a LAN global address. For example, Linux provides > this option (sysctl accept_ra =3D 2). >=20 > 3.2 Scenario 2: Global Address Only Assigned to LAN > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o "The movement of the IPv6 prefix from the 3GPP radio interface to the > LAN interface may result in long-lived data connections being terminated > during the transition from a host-only mode to router-and-host mode." >=20 > It may be worth expanding on this a bit further. In theory, I think an > application should be able to survive this as long as it isn't bound to a > specific interface, or is relying on the sin6_scope_id value (which usual= ly > conveys ifindex, as per RFC4007) not changing. The host's/router's route > table decides the exit interface for packets, rather than always using th= e > interface the selected source address was assigned to. How the OS handles > moving the address may be disruptive, although I'd think it might be fair= ly > straight forward for the OS to be modified to prevent that disruption. >=20 > It isn't completely clear to me as to whether IPv6 uses the weak host > model (packets destined to one of the host's addresses can enter the > host via any interface), or the strong host model (packets must enter > the host on the interface assigned the address), or whether it is an > implementation decision. RFC4291 (IPv6 Addr. Arch) implies strong, by > saying that addresses are assigned to interfaces, while RFC6724 (Src. & > Dst. Selection) implies weak, by only recommending rather than requiring > that the source address is the one assigned to the interface that will > be used to reach the destination. If it is strong, as the UE is becoming > a router, I think a router by nature supports the weak host model, as it > will logically forward packets from the non-destination address assigned > ingress interface to its other interface assigned the address, and then > handle it locally at the higher layers. >=20 > o "The UE checks to make sure the 3GPP interface is active and has an IPv= 6 > address." I suggest changing it to "The UE checks to make sure the 3GPP > interface is active and has at least one global IPv6 address." >=20 > 3.3 Scenario 3: A Single Global Address Assigned to 3GPP Radio and LAN In= terface > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o "This method also creates complications for ensuring uniqueness for > Privacy Extensions [RFC4941]. Privacy Extensions should be disabled on > the 3GPP radio interface while this method is enabled." What particular > complications? I can see there would be some if the privacy addresses wer= e > created independently for the two interfaces, however if a single privacy > address was generated, and then assigned to both interfaces, would that > eliminate the complications? Are there others that I'm not seeing? >=20 >=20 > o "2. The UE checks to make sure the 3GPP interfaces is active and has > an IPv6 address." - delete 's' on interfaces. >=20 >=20 > HTH, > Mark. From ales.vizdal@t-mobile.cz Thu May 9 07:52:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AE521F8EB5 for ; Thu, 9 May 2013 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er-wYNLtdCvm for ; Thu, 9 May 2013 07:52:18 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 8238D21F8E4C for ; Thu, 9 May 2013 07:52:16 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id C90262E07E4; Thu, 9 May 2013 16:52:01 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Thu, 9 May 2013 16:52:14 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mark Smith , "Fred Baker (fred)" , "v6ops@ietf.org" Date: Thu, 9 May 2013 16:52:14 +0200 Thread-Topic: [v6ops] draft-ietf-v6ops-64share WGLC Thread-Index: Ac5MpSQ8n5W17z2tTr6Vwx8vF11yzgAGc0kg Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895C712A2@SRVHKE02.rdm.cz> References: <8C48B86A895913448548E6D15DA7553B8298F8@xmb-rcd-x09.cisco.com> <1368097479.77285.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1368097479.77285.YahooMailNeo@web142501.mail.bf1.yahoo.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:52:22 -0000 Hi, Many thanks for your points. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Mark > Smith > Sent: Thursday, May 09, 2013 1:05 PM > To: Fred Baker (fred); v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC >=20 > Hi, >=20 >=20 > ----- Original Message ----- > > From: Fred Baker (fred) > > To: "v6ops@ietf.org" > > Cc: > > Sent: Monday, 29 April 2013 6:00 AM > > Subject: [v6ops] draft-ietf-v6ops-64share WGLC > > > >T his is to initiate a two week working group last call of > >http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it > >now. If you find nits (spelling errors, minor suggested wording > >changes, etc), comment to the authors; if you find greater issues, > >such as disagreeing with a statement or finding additional issues that > >need to be addressed, please post your comments to the list. > > > > We are looking specifically for comments on the importance of the > > document as well as its content. If you have read the document and > > believe it to be of operational utility, that is also an important comm= ent to make. > > > > >=20 >=20 > Firstly, I I think this document is of value, as it facilitates IPv6 conn= ectivity to hosts > tethered to 3GPP devices which don't support DHCPv6-PD. >=20 > I think there are some areas where it needs to be improved. >=20 > General > ~~~~~~ >=20 > It isn't clear to me whether the document is describing what has been imp= lemented, > what could be implemented or both. >=20 > The reason I wonder is specifically because of the first scenario, "No Gl= obal Address on > the UE". Assuming that the UE is a smart phone, I'd think that the user w= ould expect > that if they enable tethering, they could continue to use the phone itsel= f to access the > Internet, run various Internet applications etc. For example, they may be= lending or > sharing their Internet access to another person using a laptop, rather th= an switching > from using their smartphone to their tablet or laptop. In other words, a = multiuser > scenario. I think the UE losing Internet access while providing it to tet= hered devices is > quite a significant and probably unacceptable limitation, and would most = likely confuse > most UE end-users when it occurs (resulting in many support phone calls t= o their > carrier's helpdesk, or worse, technical relatives or friends). >=20 > If the document is describing what has been implemented, then I think it = is reasonable > to keep this method in there, however I think the significant drawbacks s= hould be > described, and this method being recommended against being implemented. O= n the > other hand, if the document is only describing what could be implemented,= rather than > what has been, then I think this scenario should either be dropped or str= ongly > recommended against, as the I think the drawbacks are too significant. The document is bit of both as some of the mentioned approaches have been i= mplemented, some are listed as an option.=20 =20 > 1. Introduction > ~~~~~~~~~~~~ >=20 > o =A0UE definition - I think it would be useful to define what User Equip= ment is, because I > think the significance of some of the drawbacks of the different methods = may be > influenced by what type of device the UE is. For example, for a 3G Wifi h= otspot device, > the device's own loss of Internet access in scenario 1 might be less sign= ificant than if > the UE is a smart phone (although, if the 3G Wifi hotspot device is actin= g as a DNS > cache, local NTP server or similar, then the significance is probably the= same) UE is a 3GPP term, reference/explanation will be added. =20 > o =A0Multiple global prefixes - the text seems to suggest only one global > IPv6 prefix ever be announced over the 3GPP radio interface. I don't know= if the 3GPP > documents specify that, however I think we should always facilitate annou= ncements of > multiple IPv6 prefixes, so that IPv6's address aging capability can be us= ed to phase in a > new IPv6 prefix and then phase out an old one over a reasonable time peri= od e.g. a > month. The current 3GPP architecture is limited to support a single IPv6 prefix on= ly. It explicitly states that if the mobile networks announces multiple IPv6 prefix in the RA= only the first one shall be used, the rest shall be ignored. =20 > o =A0A separated numbered list in the second paragraph would make these p= oints clearer Ack. > o =A0It isn't clear whether the last sentence of the 2nd paragraph is app= lying to all of the > numbered list points, or just the last one. Once indented, it will be clear that it applies to the last point only. =20 > 3.0 General Behavior for All Scenarios > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o =A0Regarding the gateway not consuming any addresses within the /64, an= d forwarding > all traffic to /64 destinations towards the UE, when the UE is acting as = a host, I > assume it would drop traffic towards non-UE assigned addresses, as per no= rmal IPv6 > host behaviour.=20 As there is no link-layer addressing and the GW does not do NUD (it has bee= n discussed on the list before, there is no NUD-aware implementation known) it will be = forwarding all packets that belong to the /64 down to the UE. > However, when the UE becomes a router in these scenarios, is a > sink/null route for the /64 created, so that the UE doesn't forward traff= ic towards non- > known destinations back towards the gateway via its default route? Neighb= or discovery > on the LAN interface should give the UE knowledge of the hosts/nodes usin= g addresses > within the /64, so that it only drops traffic for destinations within the > /64 that don't exist. It will have ::/0 pointing towards the mobile network and /64 towards the L= AN. Non-known destinations shall be routed to LAN, if the host is not known on the LAN IC= MP error shall be returned back to the originator. =20 > 3.1 Scenario 1: No Global Address on the UE > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > In addition to my thoughts in General above. >=20 > o =A0In addition to the PMTUD issue, I think it would also be worth menti= oning that if the > UE is providing other services e.g. DNS caching that require global conne= ctivity, they'll > also be impacted. Fair point.=20 How about? Lack of global scope connectivity will limit network services running on th= e UE (e.g. DNS=20 caching that requires global connectivity) and prevent proper Path MTU Disc= overy [RFC1981]=20 to occur on the UE. =20 > o =A0"The 3GPP interface and LAN interface only maintain link-local addre= sses while the > UE uses RA to announce the /64 to the LAN." - It may be possible for the = UE to listen > to it's own RAs on it's LAN interface, and therefore use SLAAC to configu= re a LAN > global address. For example, Linux provides this option (sysctl accept_ra= =3D 2). OK, that's making Scenario 1 & 2 very similar. > 3.2 Scenario 2: Global Address Only Assigned to LAN > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o =A0"The movement of the IPv6 prefix from the 3GPP radio interface to th= e LAN interface > may result in long-lived data connections being terminated during the tra= nsition from a > host-only mode to router-and-host mode." >=20 > It may be worth expanding on this a bit further. In theory, I think an ap= plication should > be able to survive this as long as it isn't bound to a specific interface= , or is relying on > the sin6_scope_id value (which usually conveys ifindex, as per RFC4007) n= ot changing. > The host's/router's route table decides the exit interface for packets, r= ather than > always using the interface the selected source address was assigned to. H= ow the OS > handles moving the address may be disruptive, although I'd think it might= be fairly > straight forward for the OS to be modified to prevent that disruption. >=20 > It isn't completely clear to me as to whether IPv6 uses the weak host mod= el (packets > destined to one of the host's addresses can enter the host via any interf= ace), or the > strong host model (packets must enter the host on the interface assigned = the > address), or whether it is an implementation decision. RFC4291 (IPv6 Addr= . Arch) > implies strong, by saying that addresses are assigned to interfaces, whil= e RFC6724 > (Src. & Dst. Selection) implies weak, by only recommending rather than re= quiring that > the source address is the one assigned to the interface that will be used= to reach the > destination. If it is strong, as the UE is becoming a router, I think a r= outer by nature > supports the weak host model, as it will logically forward packets from t= he non- > destination address assigned ingress interface to its other interface ass= igned the > address, and then handle it locally at the higher layers. It looks like that Linux implements the weak host model as rp_filter has be= en added later as a userspace function. (https://bugzilla.kernel.org/show_bug.cgi?id=3D699= 8) =20 > o "The UE checks to make sure the 3GPP interface is active and has an IPv= 6 address." > I suggest changing it to "The UE checks to make sure the 3GPP interface i= s active and > has at least one global IPv6 address." If it requires clarification, it shall be changed for all 3 options. > 3.3 Scenario 3: A Single Global Address=A0Assigned to 3GPP Radio and LAN = Interface > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~ >=20 > o =A0"This method also creates complications for ensuring uniqueness for = Privacy > Extensions [RFC4941]. =A0Privacy Extensions should be disabled on the 3GP= P radio > interface while this method is enabled." What particular complications? I= can see there > would be some if the privacy addresses were created independently for the= two > interfaces, however if a single privacy address was generated, and then a= ssigned to > both interfaces, would that eliminate the complications? Are there others= that I'm not > seeing? Yes, this is the concern where the temporary addresses can be created on bo= th interfaces independently resulting in a potential address collision. (low risk, but ma= y happen) > o =A0"2. The UE checks to make sure the 3GPP interfaces is active and has= an IPv6 > address." - delete 's' on interfaces. >=20 >=20 > HTH, > Mark. Cheers, Ales From swmike@swm.pp.se Thu May 9 08:00:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280D421F9051 for ; Thu, 9 May 2013 08:00:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2CfgiCAFUcZ for ; Thu, 9 May 2013 08:00:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2529921F8FA5 for ; Thu, 9 May 2013 08:00:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0D6F29C; Thu, 9 May 2013 17:00:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 006969A; Thu, 9 May 2013 17:00:15 +0200 (CEST) Date: Thu, 9 May 2013 17:00:15 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B852622@xmb-rcd-x09.cisco.com> Message-ID: References: <8C48B86A895913448548E6D15DA7553B852622@xmb-rcd-x09.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Regarding draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:00:20 -0000 On Mon, 6 May 2013, Fred Baker (fred) wrote: > The working group last call for this draft-ietf-v6ops-64share announced > last week continues for another week. Please feel free to comment on it. I have in the past week tried two different devices that seem to perform functionality that is specified in this document. One phone and one "wifi router", both with 4G (LTE) WAN connectivity. When the phone was configured to be a mobile hotspot, it shared it's 3GPP interface /64 with the clients connected through it's wifi AP functionality and successfully forwarded packets. I have heard several more devices implementing the same functionality. I therefore support this document and think it's relevant and important. -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Sun May 12 13:00:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEF821F89FB for ; Sun, 12 May 2013 13:00:22 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtClu14+W1lE for ; Sun, 12 May 2013 13:00:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 676E821F89AF for ; Sun, 12 May 2013 13:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=602; q=dns/txt; s=iport; t=1368388817; x=1369598417; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=nKeTPOiTxgWXg5LfVJaqhREgv0dhJKO3QND2AcNmxKQ=; b=N2vS+R1fn0U5kTApxLGcCzNC6+YCJJDemxkALiqyshFOvV7NUGzHQK8C RCvbGoxrTZUQPmAQXtry7MVyzHzuwsKPW68xKqfl0JxC3I8cUojXwShnz shq2uNNA2L0I1ewKvGyZcOzhAKudnjXe4VXeQSQKWTqa4TSdFFB5DYa9M s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAM3zj1GtJV2Y/2dsb2JhbABagwfAXoEDFm0HgiEBBDo/EgEqFEIPGAQODYgEuyaOdzGCe2EDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,657,1363132800"; d="scan'208";a="209289785" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 12 May 2013 20:00:16 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4CK0Gq4000316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 May 2013 20:00:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sun, 12 May 2013 15:00:15 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: WGLC status Thread-Index: AQHOT0tS0BB5YtwTY0yIFSYVQRMB2w== Date: Sun, 12 May 2013 20:00:15 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B859B27@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] WGLC status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 20:00:23 -0000 We have there documents in active discussion right now: draft-ietf-v6ops-64= share, draft-ietf-v6ops-mobile-device-profile, and draft-ietf-v6ops-rfc3316= bis.=20 We are just completing a WGLC on draft-ietf-v6ops-64share, giving me the vi= ew that it has support but needs to be updated against comments. I'll look = for an updated draft in the coming weeks, and re-run the WGLC (perhaps just= a week) in June. I will run WGLCs on the other two in the coming four weeks. With any luck, we will have this off our collective plate by the end of Jun= e, opening room for new work in July. From fred@cisco.com Sun May 12 13:00:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2382721F89AF for ; Sun, 12 May 2013 13:00:24 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLNRxqKH3m5b for ; Sun, 12 May 2013 13:00:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 46FDE21F89D5 for ; Sun, 12 May 2013 13:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=671; q=dns/txt; s=iport; t=1368388819; x=1369598419; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bDQSmbQoqZg8nMOsNctQNxQNM3RER9hpJr0AyJWTU/4=; b=SXXFZX8EZO+RO9FIp7YzijIx1igGPduhimr2YqiDLy2bitgfQaHWTbC9 gT7J57K6iIQ/4laBlRdscp5u7h8vNCC9BdwhczrNJSumXNahuCYrONPi+ bRDCw2P3uYLII4EFSz8i2D84i1Qigo7FvoTZqTjNOD8Ui1XMKWh5A3aOL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAD/0j1GtJXG9/2dsb2JhbABagwc3wCeBAxZtB4IhAQQ6PxIBKhRCJwQODYgEuymOdzGCe2EDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,657,1363132800"; d="scan'208";a="209480709" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 12 May 2013 20:00:18 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4CK0I7v006246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 May 2013 20:00:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Sun, 12 May 2013 15:00:18 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-rfc3316bis WGLC Thread-Index: AQHOT0tTL1ElBGutnkqO/j9bgsdELg== Date: Sun, 12 May 2013 20:00:17 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 20:00:24 -0000 This is to initiate a two week working group last call of http://tools.ietf= .org/html/draft-ietf-v6ops-rfc3316bis. Please read it now. If you find nits= (spelling errors, minor suggested wording changes, etc), comment to the au= thors; if you find greater issues, such as disagreeing with a statement or = finding additional issues that need to be addressed, please post your comme= nts to the list. We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make draft-ietf-v6ops-rfc3316bis idnits From markzzzsmith@yahoo.com.au Sun May 12 13:59:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18C21F869C for ; Sun, 12 May 2013 13:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ-q6ky1j3JT for ; Sun, 12 May 2013 13:59:51 -0700 (PDT) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by ietfa.amsl.com (Postfix) with SMTP id 96CFA21F84D1 for ; Sun, 12 May 2013 13:59:51 -0700 (PDT) Received: from [98.139.215.141] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 12 May 2013 20:59:51 -0000 Received: from [98.139.212.209] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 12 May 2013 20:59:51 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 12 May 2013 20:59:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 6448.93927.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 13543 invoked by uid 60001); 12 May 2013 20:59:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1368392390; bh=oNPncBzGf5A0ipCbEU6ErCDtzUh0JYJ4xrIlNjq7Xv4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zipmgk/Bl0zTcLt7bth6GYLgyUb+uPlfAOxnW3w6ewsEBNELT3M/eZcHWYehTVWw//P9tJ9wzM9T9P0xxiqyjFgn/1Ut3ECjgj5t1OwgHsEgCqKUv2oaxHGuSIILVvbw49xwSwNUKOL3h1xq39PJgTR1MpCIvvkYmzCJMy0riiE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jdeqEoagL/HevFd+2aBrlQsainJjjv8aFV6Y8NiDuY0s1DK3tjZDZxummlw3P4aCHLZzTG1IffI4NH5LChnwn2jXG4VbZnhCGrWZJmgzOIybJ4ixRlghcdjqk59zU8f0bbbs313OROid7Fm0Mgztsn85k9SZHqoJr1YUo3X2w4Y=; X-YMail-OSG: DlHX4noVM1kUXXW2Lu2anBYtvnVepUM3XyIvQ_sijznOUuF fH0ACsARQ6fQeU4JLahTg_xEeqD.cNpfySQlhuGn6I1Px7zcWVWGn7_7l2h5 Uwe8YE7XpcdgoDNUiTeAP6ENacPiX9pO3ysJaETAqa_yy7cZb1FtHvFlmwuo u8Z1oYoWGN4KVHg9P56W0tE2HL61podWhrSrirBB9CjDYJLbu7zjIgV7csHy enDarbEgJLdjZDV2ptX60bc9jOfOHsXvquSbcmwRmjFfDstcInQlJk5hGiJV 5mGx_UijrUUUhkLvNXA7zmLsSfegv0s4MtdBRizdBHALENIVZPBno76UqhPs qNPEVot4W_11DcA4EmrvzzRx.18LE9ZIEwq5d99nvwiaododGLuMEyk6GJmX 4PPhYGtBpjFpqDZZ6SRd7SiZun8rseeyyXiXQ5JF75Plbxz3riCg3DYJvqgQ _eVpDQNc6DB_SNPfoIIUUIcjWLErevgjDnkK8FGAcz5hHGouVPeZdtCxJbHw yjFo7wEgbElJtRSQ8BsnT6F0YU7kj6q5RWQUnfRcOoHbcHsZwdI8pH4EzwRI JayxmBtdQZTxcVB5ib_75vb_UV7E3nEnww0yEaGKpyW11iwT6IOJNUWtGEC9 bKhgt1Nnf1g-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Sun, 12 May 2013 13:59:50 PDT X-Rocket-MIMEInfo: 002.001, SGnCoMKgVsOtemRhbCwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogVsOtemRhbCBBbGXFoSA8YWxlcy52aXpkYWxAdC1tb2JpbGUuY3o.Cj4gVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBDYzogCj4gU2VudDogRnJpZGF5LCAxMCBNYXkgMjAxMyAxMjo1MiBBTQo.IFN1YmplY3Q6IFJFOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <8C48B86A895913448548E6D15DA7553B8298F8@xmb-rcd-x09.cisco.com> <1368097479.77285.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1808340F7EC362469DDFFB112B37E2FCC895C712A2@SRVHKE02.rdm.cz> Message-ID: <1368392390.13501.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Sun, 12 May 2013 13:59:50 -0700 (PDT) From: Mark Smith To: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= , "Fred Baker $fred$" , "v6ops@ietf.org" In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC895C712A2@SRVHKE02.rdm.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 20:59:57 -0000 Hi=C2=A0=C2=A0V=C3=ADzdal,=0A=0A=0A----- Original Message -----=0A> From: V= =C3=ADzdal Ale=C5=A1 =0A> To: Mark Smith ; Fred Baker (fred) ; "v6ops@ietf.org" =0A> Cc: =0A> Sent: Friday, 10 May 2013 12:52 AM=0A> Subject:= RE: [v6ops] draft-ietf-v6ops-64share WGLC=0A>=C2=A0=0A=0A=0A=0A> rat= her than=0A>> what has been, then I think this scenario should either be d= ropped or =0A> strongly=0A>> recommended against, as the I think the drawb= acks are too significant.=0A> =0A> The document is bit of both as some of t= he mentioned approaches have been =0A> implemented,=0A> some are listed as = an option. =0A>=C2=A0=0A=0AI think making that clearer and more explicit in= each case would be very useful.=0A=0A>> 1. Introduction=0A>> ~~~~~~~~~~~= ~=0A>>=C2=A0=0A=C2=A0 =0A=0A=0A>> 3.0 General Behavior for All Scena= rios=0A>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A>> =0A>> o =C2=A0Regarding the g= ateway not consuming any addresses within the /64, and =0A> forwarding=0A>>= all traffic to /64 destinations towards the UE, when the UE is acting as = a =0A> host, I=0A>> assume it would drop traffic towards non-UE assigned a= ddresses, as per =0A> normal IPv6=0A>> host behaviour. =0A> =0A> As there = is no link-layer addressing and the GW does not do NUD (it has been =0A> di= scussed=0A> on the list before, there is no NUD-aware implementation known)= it will be =0A> forwarding=0A> all packets that belong to the /64 down to = the UE.=0A>=C2=A0=0A=0Aok=0A=0A>> However, when the UE becomes a router in= these scenarios, is a=0A>> sink/null route for the /64 created, so that t= he UE doesn't forward =0A> traffic towards non-=0A>> known destinations ba= ck towards the gateway via its default route? Neighbor =0A> discovery=0A>> = on the LAN interface should give the UE knowledge of the hosts/nodes using= =0A> addresses=0A>> within the /64, so that it only drops traffic for des= tinations within the=0A>> /64 that don't exist.=0A> =0A> It will have ::/0= pointing towards the mobile network and /64 towards the LAN. =0A> Non-know= n=0A> destinations shall be routed to LAN, if the host is not known on the = LAN ICMP =0A> error=0A> shall be returned back to the originator.=0A>=C2=A0= =0A=0AFor scenario 1, as the UE has no global addresses, I think it would b= e useful to make it clearer that a /64 'connected' route, pointing out the = LAN interface needs to be configured when the UE goes from being a host to = a router, and in contrast, it may be useful to mention that in the other sc= enarios, either static configuration of the global address on the LAN inter= face, or SLAAC configuration of an address via listening to it's own RA (wi= th the On-Link bit switched on in the PIO), inherently create this /64 rout= e.=0A=C2=A0=0A=0A>> 3.1 Scenario 1: No Global Address on the UE=0A>> ~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A>> =0A>> In addition to my thoughts in Gen= eral above.=0A>> =0A>> o =C2=A0In addition to the PMTUD issue, I think it = would also be worth =0A> mentioning that if the=0A>> UE is providing other= services e.g. DNS caching that require global =0A> connectivity, they'll= =0A>> also be impacted.=0A> =0A> Fair point. =0A> =0A> How about?=0A> =0A>= Lack of global scope connectivity will limit network services running on t= he UE =0A> (e.g. DNS =0A> caching that requires global connectivity) and pr= event proper Path MTU =0A> Discovery=C2=A0 [RFC1981] =0A> to occur on the U= E.=0A>=C2=A0=0A=0AThat would be fine.=0A=0A>> o =C2=A0"The 3GPP interface = and LAN interface only maintain link-local =0A> addresses while the=0A>> U= E uses RA to announce the /64 to the LAN." - It may be possible for =0A> th= e UE to listen=0A>> to it's own RAs on it's LAN interface, and therefore u= se SLAAC to =0A> configure a LAN=0A>> global address. For example, Linux p= rovides this option (sysctl accept_ra =3D =0A> 2).=0A> =0A> OK, that's maki= ng Scenario 1 & 2 very similar.=0A> =0A>> 3.2 Scenario 2: Global Address O= nly Assigned to LAN=0A>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A=0A>> = =0A=0A>> It isn't completely clear to me as to whether IPv6 uses the= weak host =0A> model (packets=0A>> destined to one of the host's addresse= s can enter the host via any =0A> interface), or the=0A>> strong host mode= l (packets must enter the host on the interface assigned =0A> the=0A>> add= ress), or whether it is an implementation decision. RFC4291 (IPv6 Addr. =0A= > Arch)=0A>> implies strong, by saying that addresses are assigned to inte= rfaces, while =0A> RFC6724=0A>> (Src. & Dst. Selection) implies weak, by o= nly recommending rather than =0A> requiring that=0A>> the source address i= s the one assigned to the interface that will be used =0A> to reach the=0A>= > destination. If it is strong, as the UE is becoming a router, I think a = =0A> router by nature=0A>> supports the weak host model, as it will logica= lly forward packets from the =0A> non-=0A>> destination address assigned i= ngress interface to its other interface =0A> assigned the=0A>> address, an= d then handle it locally at the higher layers.=0A> =0A> It looks like that = Linux implements the weak host model as rp_filter has been =0A> added later= =0A> as a userspace function. (https://bugzilla.kernel.org/show_bug.cgi?id= =3D6998)=0A>=C2=A0=0A=0AThat's useful to know. It won't be performed by the= kernel unless the rpfilter option has been enabled in the ip6tables firewa= ll.=0A=0A>> o "The UE checks to make sure the 3GPP interface is active and= has an =0A> IPv6 address."=0A>> I suggest changing it to "The UE checks t= o make sure the 3GPP =0A> interface is active and=0A>> has at least one gl= obal IPv6 address."=0A> =0A> If it requires clarification, it shall be chan= ged for all 3 options.=0A> =0A>> 3.3 Scenario 3: A Single Global Address= =C2=A0Assigned to 3GPP Radio and LAN =0A> Interface=0A>> ~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A>> ~~~~~~~~=0A>> =0A>> o =C2=A0"Th= is method also creates complications for ensuring uniqueness for =0A> Priva= cy=0A>> Extensions [RFC4941]. =C2=A0Privacy Extensions should be disabled = on the 3GPP =0A> radio=0A>> interface while this method is enabled." What = particular =0A> complications? I can see there=0A>> would be some if the p= rivacy addresses were created independently for the =0A> two=0A>> interfac= es, however if a single privacy address was generated, and then =0A> assign= ed to=0A>> both interfaces, would that eliminate the complications? Are th= ere others =0A> that I'm not=0A>> seeing?=0A> =0A> Yes, this is the concer= n where the temporary addresses can be created on both =0A> interfaces=0A> = independently resulting in a potential address collision. (low risk, but ma= y =0A> happen)=0A>=C2=A0=0A=0Aok, in that case I think it would be useful t= o provide some text saying that if privacy addresses are enabled, the same = address should be used on both interfaces, and their preferred and valid li= fetimes are to decrement in parallel, such that they expire at the exact sa= me moment.=0A=0ARegards,=0AMark. From v6ops@globis.net Mon May 13 15:01:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB36A21F93F0 for ; Mon, 13 May 2013 15:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMZ9PrqDRrll for ; Mon, 13 May 2013 15:01:08 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D650521F92BC for ; Mon, 13 May 2013 15:01:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1FF8D8700E2; Tue, 14 May 2013 00:00:45 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsfd98n6ipjS; Tue, 14 May 2013 00:00:45 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E684C8700AF; Tue, 14 May 2013 00:00:44 +0200 (CEST) Message-ID: <51916286.9070101@globis.net> Date: Tue, 14 May 2013 00:00:38 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 22:01:08 -0000 I have read this document. I cant say that I support it. IMHO it's too time specific and too version specific, without proving added value and general guidance. On the one hand there are requirements to implement a kludge to cope with historical limitations in mobile networks and the fact the gateway could only handle a single prefix route (RFC6603), whereas every other network I know of easily handles numbering of the link "to the site" without this. On the other hand there isn't a requirement for something really basic in the IPv6 vision, like BCP 157, so that a device can always be provided with enough addresses/prefixes to properly number all of its interfaces using SLAAC without resorting to workarounds like draft-ietf-v6ops-64share-04. I therefore question what this document adds above and beyond reading the detailed 3gpp version releases/ specs, and why the IETF should publish this document at all. regards, RayH Fred Baker (fred) wrote: > This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. > > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make > > draft-ietf-v6ops-rfc3316bis idnits > > > > From jouni.nospam@gmail.com Mon May 13 15:31:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD89121F8F0E for ; Mon, 13 May 2013 15:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9Eo1876wy0P for ; Mon, 13 May 2013 15:31:00 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3F46F21F8E9D for ; Mon, 13 May 2013 15:31:00 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id c41so3981468eek.23 for ; Mon, 13 May 2013 15:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=VY+1uTLUD9ukYB51LXdz5FZxUADeri29x87xwiRT0u8=; b=dZDA+jUtqeOuVD2fy9U1jmLXcSUM0oSGkG9MvDm6vLRS/zNq5Xn5UH4lA3g9AcgW3K OLRbKc+sswN6TAMXIRnMpC/i3cNbY3uyvwJ7A4y0xnbXb5+J/05potwJk2Gbnis3TFXF dt+Ligud/QzXcqvgbN+CkW0Gc9VHR/h7RuwWseudaESuVlUzSsSnpCQ0KbqFLObHXHNV paqvLzBGB92TS1RGoFUF900unqiBCawHYVMhqAtwRjnRWANM+HdDcDVqLiYkbXSHueph 6X6afrJ4X6uuSvS+HmEzcNbPV6zyhS8vGfTID6mrkTVcFuQ4QSTboVwaDIpQAcFf9DEE /1pg== X-Received: by 10.14.99.198 with SMTP id x46mr83250931eef.38.1368484259293; Mon, 13 May 2013 15:30:59 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:9c8b:119a:ccd5:7909? ([2001:1bc8:101:f101:9c8b:119a:ccd5:7909]) by mx.google.com with ESMTPSA id e50sm25748996eev.13.2013.05.13.15.30.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 15:30:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <51916286.9070101@globis.net> Date: Tue, 14 May 2013 01:30:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1283) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 22:31:04 -0000 Ray, Thanks for putting effort to read the document. Some initial comments = inline. On May 14, 2013, at 1:00 AM, Ray Hunter wrote: > I have read this document. I cant say that I support it. >=20 > IMHO it's too time specific and too version specific, without proving > added value and general guidance. Reason being quite simple. When describing what a 3GPP UE can do, we = cannot really go beyond what has been specified so far. We can point out some stuff that would make sense but not really anything beyond that. And we have tried to be pedantic on that. I somewhat disagree about the lack general guidance. Experience has = shown that it usually takes real effort explaining some of the weird details = of the 3GPP link and how corners have been cut there. Take the NDP details as an example. > On the one hand there are requirements to implement a kludge to cope > with historical limitations in mobile networks and the fact the = gateway > could only handle a single prefix route (RFC6603), whereas every other > network I know of easily handles numbering of the link "to the site" > without this. >=20 > On the other hand there isn't a requirement for something really basic > in the IPv6 vision, like BCP 157, so that a device can always be > provided with enough addresses/prefixes to properly number all of its > interfaces using SLAAC without resorting to workarounds like > draft-ietf-v6ops-64share-04. Something we have to live with at the moment. RFC3314 tried to recommend otherwise but what was recommend did not materialize. Even if I really wanted to recommend support for multiple prefixes on a 3GPP link, this document is not a recommendation document but what has to be there for an IPv6 enabled UE. > I therefore question what this document adds above and beyond reading > the detailed 3gpp version releases/ specs, and why the IETF should > publish this document at all. The original RFC3316 still gets referenced and that somewhat needed a facelift. Mostly because when RFC3316 came out we did not even have the node requirements document, and a lot of stuff that really belongs to the node requirements document is duplicated (and now outdated) in RFC3316. - Jouni >=20 > regards, > RayH >=20 > Fred Baker (fred) wrote: >> This is to initiate a two week working group last call of = http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis. Please read it = now. If you find nits (spelling errors, minor suggested wording changes, = etc), comment to the authors; if you find greater issues, such as = disagreeing with a statement or finding additional issues that need to = be addressed, please post your comments to the list. >>=20 >> We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make >>=20 >> draft-ietf-v6ops-rfc3316bis idnits >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ales.vizdal@t-mobile.cz Mon May 13 16:14:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0721F8FEC for ; Mon, 13 May 2013 16:14:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO3pb4nOM43Z for ; Mon, 13 May 2013 16:14:40 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id E0DDF21F8F07 for ; Mon, 13 May 2013 16:14:36 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id A2DBF2E081B; Tue, 14 May 2013 01:14:18 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Tue, 14 May 2013 01:14:29 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Jouni Korhonen , "v6ops@ietf.org Operations" Date: Tue, 14 May 2013 01:14:24 +0200 Thread-Topic: [v6ops] Fwd: New Version Notification for draft-ietf-v6ops-rfc3316bis-02.txt Thread-Index: Ac5KMgmory+WCjzNQgKjZN/jHMmQSwF/SA3Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895C718C4@SRVHKE02.rdm.cz> References: <20130506081341.9763.24469.idtracker@ietfa.amsl.com> <08ADEA85-6632-4D23-8998-1D16ED2DE43E@gmail.com> In-Reply-To: <08ADEA85-6632-4D23-8998-1D16ED2DE43E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_1808340F7EC362469DDFFB112B37E2FCC895C718C4SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Fwd: New Version Notification for draft-ietf-v6ops-rfc3316bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 23:14:41 -0000 --_002_1808340F7EC362469DDFFB112B37E2FCC895C718C4SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Jouni, Thanks for the update. Please find my review attached. Cheers, Ales PS. Not being a native speaker means that my language corrections may be wr= ong :-) > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Jouni > Korhonen > Sent: Monday, May 06, 2013 10:16 AM > To: v6ops@ietf.org Operations > Subject: [v6ops] Fwd: New Version Notification for draft-ietf-v6ops-rfc33= 16bis-02.txt >=20 >=20 > Folks, >=20 > We have updated the RFC 3316bis based on the discussion/comments in the l= ast IETF. > The I-D is getting to "about ready" state now. >=20 > - Jouni >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > > draft-ietf-v6ops-rfc3316bis-02.txt > > Date: May 6, 2013 11:13:41 AM GMT+03:00 > > To: Teemu Savolainen , Jari Arkko > > , Jouni Korhonen , > > Suresh Krishnan > > > > > > A new version of I-D, draft-ietf-v6ops-rfc3316bis-02.txt > > has been successfully submitted by Jouni Korhonen and posted to the > > IETF repository. > > > > Filename: draft-ietf-v6ops-rfc3316bis > > Revision: 02 > > Title: IPv6 for 3GPP Cellular Hosts > > Creation date: 2013-05-06 > > Group: v6ops > > Number of pages: 19 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-r= fc3316bis-02.txt > > Status: http://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc33= 16bis > > Htmlized: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis= -02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rf= c3316bis-02 > > > > Abstract: > > As the deployment of third and fourth generation cellular networks > > progresses, a large number of cellular hosts are being connected to > > the Internet. Standardization organizations are making Internet > > Protocol version 6 (IPv6) mandatory in their specifications. > > However, the concept of IPv6 covers many aspects and numerous > > specifications. In addition, the characteristics of cellular links > > in terms of bandwidth, cost and delay put special requirements on how > > IPv6 is used. This document considers IPv6 for cellular hosts that > > attach to the General Packet Radio Service (GPRS), Universal Mobile > > Telecommunications System (UMTS), or Evolved Packet System (EPS) > > networks (Hereafter collectively referred to as 3GPP networks). This > > document also lists out specific IPv6 functionality that needs to be > > implemented in addition what is already prescribed in the IPv6 Node > > Requirements document. It also discusses some issues relating to the > > use of these components when operating in these networks. This > > document obsoletes RFC 3316. > > > > > > > > > > The IETF Secretariat > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --_002_1808340F7EC362469DDFFB112B37E2FCC895C718C4SRVHKE02rdmcz_ Content-Type: application/pdf; name="3316bis-review.pdf" Content-Description: 3316bis-review.pdf Content-Disposition: attachment; filename="3316bis-review.pdf"; size=411931; creation-date="Mon, 13 May 2013 23:10:38 GMT"; modification-date="Mon, 13 May 2013 23:10:42 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1HQikgL1N0cnVjdFRyZWVSb290IDYzIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDE5L0tpZHNbIDMgMCBSIDE2 IDAgUiAxOCAwIFIgMjAgMCBSIDIyIDAgUiAyNCAwIFIgMjYgMCBSIDI4IDAgUiAzMCAwIFIgNDIg MCBSIDQ0IDAgUiA0NiAwIFIgNDggMCBSIDUwIDAgUiA1MiAwIFIgNTQgMCBSIDU2IDAgUiA1OCAw IFIgNjAgMCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBS L1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAgUi9GMyA5IDAgUi9GNCAxNCAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJh bnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2Jq DQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM2Njk+Pg0Kc3RyZWFtDQp4 nNUda1PbSPI7Vf4PU/sJXyVCmoceW1u5ymZJNrlKlgvs3ockH4Q9YB225EgyhPv11z2SHINnIjAt 111SBZaQ1D39mn6pzY5O2C+/HL1/9fY35r94wX797RXzvUQm7HJ0ILny/ITFkedzyQLpe6FkYRjD ISv16ODib6MDdvz+FWMbTwnap3wdHQhPhN3dMuKeiDbv/tffWD46+PVsdHD0OmCRl3B2djE6CJgP /wOmEk9JAJcEXpKws8XowEecfPZmdPDpkI2/sLN3o4NjuP2fFiw4MRYxB6I8GgtBjEUkdqGFJMYi lF4SbWHx9uQ6ZH8sdZnWWZFX7PPhX+EfJ6efx6zv3zuP/aMoZ0Wu82fseOrdXc5TsZY+3BC4sO6j nSKmnQrxhi3a5bUuc13TrjyJvFBwF8zntMACJHPsAvZbmV7UvYKw8e+jznWVVux9cZ7N9TASYUe1 TyJCYomQcH+4hcUf51Ux17WufmZCBCFoU3bB0uWyLK71tE+nQKFelldXxYDaZMe6j3YRMe1E7NKm fKqnrKrTegUUfJtfFOXC2KV0jgSipQnngedE5secokVEgI3jyoXJcZlNqqrIhxEIx+p7BCImFgie 2MTy+NsyK1GVPoD2LM51yaJnjPuB6LdDZx47Ta+LeZrB7jQM5ew491Euoaac/3jpfdA/YhGPYk8J F7ofiqssHYhLdvr0cCnwidkUBFZh+R9ikEzQU3YgegquXplVs5yYSwJ8HRW6oA6kuA5e9IkEdYAE 2AQBueYOszPZcR12Z3LQp49NxBGkSsT/h+Y6EH2f3rKw2TUHYZOLPn1sIg6xVSx3khbiGFtFJvPy aDSIw1UVhl5gSXvsQRoDtBixCwOTbACnnok3JyfslZ7PV/O0ZL8XVV0RO/e4szjx6GUIcbSoVOQF 8UMYQswN5btgTzG0J4YWCS8OXACpExfoUYYuYJmuL4jhYVqG72lx3Dc3OIBdh8WSWl14iJD2tDrh e4lwASsvJpg6Oc+ol4gC41RF6iXGcLsLFjC3/kasewK82tipDr32jjjDo2S8k9klzisokdio8fK8 qst0Mkza1gGzd+nEiQEFOrYDBzhx4Kt44Nj4aImPOw93gntZsXqm2VQv58XtQuc1Ky7gTFZOWZpP wSFZlfWMXeq8rYKwSeeZ5Lq+KcorYlMkYrhSOInTxyPiSFQF3ONifzyyg1uWxWWpq0pXz1jKgPaX muUrk/UDZq0ZMkNXkToRjOyINhGDv3i+L+C67nd5aTv70aCelvoeRvb713CEl4Sg8SADeIGI5bos +2TJ8sH+774S6j0X9nEwirvjc4+s3eqMaQtMoOHDjyhJ6AgIOilil5Ce6yy/ZJMiz/Wk1lNWF9RB dYTxo0sj7wIzf1IAAR6CNPEVUENFIQPBkrG70s+7FAlSPRaq/bkpoT4YJsDeU/Do2EvUD/oGOHUk 74sH7RjbiFDF8p2dsiOCG0lX9/UYO61hB0nLafafZucoyss0bw/u26ltlKni/jXfrCijfVqkVyC6 ffhQhb1CKC8MnbzsQ4PKGxXS99wiZa/eb2ND5ZS2NZCHEcWYuBuXZWScvWPwyH8zo7LodoLK+pIt Gh3motFhweajg9PRgTkZNCfhb+1V5gR4q3zrqsTj/M6zEoTRXoXMVWIDouH2fYh4MuIbENcnNiFu nGwgrp+1AXGbJcTOskzkPj0gB7iTsqiLSTFn17qs0JZg+wBmzD6PQX3zKbHTg1uzcuGS1kV5y7Ic /easZNVST7KLbNKYNeLeBAFckJGTCX29WsQRi4yVx611mWFkwQ7u9+JGgxg8M3EL+BsTvTRBi0mg TgqUEJSJW5Yia8AjxjgG3GVdFitqH66pAbno0sce4mBFRqHHrfWYYdhjB3dPHxh4BCydTjM8bHk2 SzHFoMusqrNJdSeGmWc5eUSZcEy9uqjTxyTiopkMI2+P5tQKDW2XLheG8uegHTfZtJ49A92paqMs Uz1Pb9lyVTfGLZ0DxK+rrNSYH4C7cgg1bwYpmTmo08cjYj9bqnivimQHZ+xZVrFVpalb3oLGtXCu kxiaVOjBOKCdzWCN02KyMsknsOdVNkUTvq6H3ctv1LOUOj/cGggHNfqEj7hOKmWyTwNhhZbWdTqZ QQhv7PUbk/ybs5N0cqVr9jGdZgU71eV1NtHghr05+Xj6efyM/ZlnuPfChUN0uHZMslOnj0fERWQJ wdM+DYQd3Jme60mxWKzybrdlp7dVrRfAlD/fnxmmgP4cXxfzaz3t2Le+5Bg72QdpZXORp49LxJVl KYJ9apIVWpckB3r/rkudXsDGC0ZuDpyrQV3mtwDhQpelSZiBx9pU/5u7qEMJaWy+Fc2r6vMYXDW0 xcPs63ZW9AkEcelNcrhP7U8i7ODWe106rwpweHFTKzpfCxznZucjjmiR+Xcwelyy+WKVT5pe86y+ fVhCv4MoPT8GTL1QxtQJ/SYfTbKoYezgrphleqAYaFeE7hcbOsobOw+BVRCF9OWGpgHWoUXoBv4g 6Y+oBZE16U9lTAJhtfeaOBmFogRr+A7ucZyrHqKsaxgKa6+guIadlLqKPR+KO4hGbOwwU+u7GAS7 7DmxaxoEgZcED1vbHRmF+zhvZbSnlCSI2z+kL/e6FdrBZYvl3CQVwP3JvqeJqONPrAAlmzg8ToVA ZB6iRGswHI3iMCXYtvnNQc4btIkQTadz8DSnt2xZ6mpSZudAXeLtBLvUgt0pmt1n8fqBIXoLHe1I nQWpvOAJQnB+O4w7vis+9wnYLW9A4euKEXbhM8Xfbc/1jsHD9xYG3ZRFojyxbYQ/FFNim9/umA54 vYENcZFOxCH6Y/uy5g5wHzeTxF2UM0gb9QYCj9OaTx9fvwqlkF8eZNA7YBJ1SoIHLekNelNqdFAU qydtnDjNqskKW8BYVSw0WPlqpambvQQsOFK7U7fU87TGLqB7tql7bIzGHd+qje9b900r0dLb5hZR qUsUeZLvukBiZ7VxjHdGiTrcwEARoq6d8XmQq7Tmg8Lk0FoiaFWrbTreWMm9OAB2LGLrhG8KJC6I P9gYkRBcft8YuXRHApK4qC/ghn3uHXZwq0o3jce6wqL+YomjU2AbuZnpnBXNCBYwLE3XBVzS5VUH SVp2BstBmb7ZNMRlfeN2Wd9jH4ZBdnDrrGXRjfFgsJeaSR7ExUmOnazcuew+6hPX64XydxIC4pK0 kIGNGqdmHEjbsl+x93pB3HWLb8k5YPeSgLgwKgTH8OPRaBDX/gQXe1VHOzhTNR9mxlLbHOAATP2q IrahRi5gzYwlWGm1Ol9kdZsmuljN59goYCbg5BPNbrJ6Rr+bt81dLn73iR1xMVNATG+T/qHEzg4O hzVllSk1g8359dUJBMKmZch8TKh3gubNS9fS+zhAXD0UvvKkJWXahwZx5pYnobe/xK0d2kCGp8mj 20FS2x2Mu0MHLGN2Krb97tKToYb4YpMDKvqz6ON2nla7rX9/pYId55dZrnW59bbCk00dRKE8dolW n4ATJ7MgCsSXkfcm4XZwZ2l1xV4XpWlxent89to0SHwoam060FgBnCnZZVmslthufLvO0tRldr6q yfeixEmXHvYo4njRvCu+P+5YoW2rSjqUN8TRKDnQoH4xvskF2mE1NsmEu9o0jZi26VVZYkw2zNLb poG9rL0t9juEq0/EiSNuHiZ7tUB2cO0uhPW8ms3qevnz0dE0hYCvxEa+0sM5Hl5RXh6ZcSXVUSsM R9SvoDSVJRdN+lhDHI7z0N9FQIijca6CvQqIHVyr9cQuCmZfnCAH8vjswAZy+ezANnw+o08be8t1 Os+mphU9hZ3+W7ZYLdD4Vtk3tijyejZMy6RLxvpEnTjrwiX3lGVs11CibgeHISY6WeearZZgBPX0 GTx0OU8n+Ak402Ulp+z8tvXNNpwDfK2Fun7fblgO8vRxiTgpxYXYq0Gyg6uzhW5KlrBpZbmZ7bws sxR95gLfYxnKR8N8feTCitpLa2YlOYB1ZqRq+rp1PhkiEnBwu0/oiFNSnMu9mgY7uEWKbxKmc7QC IGWTzERoetFaAQjWcmTHTxgzYPYQh6kQs6TphnXgh4NbvJ+ofTIz19LFgD45IE6M8UB5aofvIaBO jPkhTqF7NBrE6QszDO/xL7+ExGE6diPuQI2QOJQKosRGje9fjqGxv8XrRjy2Y817p5p/OkkvNQu+ DOJ5OXDuJR1xqBNE/k4cJI51gjCwUWPQ7/dwwBzm+z0cwDa+32P9KqpjPOumZOJQ4cEmCjtQ7RUJ 4pggUNyLeucdADC46R0oqxnYYn58gTNsyg6klAhS+cozA1AkF9+HKzWTTfqesHnHYtRMSwnvPyHY GuPU9J3dtE/uEMEJDsog0h1LL1BMSoUtazIWOPNJhp5sP09GBwp4wbvjOR5znKrbHKtQoO62j1kf IRBzqzlWEGqHUXNveyLGL0Nqn9TOrWrhtEcTRBHxaI/neGyQbE+sKWsetT4ykCaju+uFm2fA7a7L 6GvzrFgZvCNhImYfYhzwNjfF445obQQyD7q5kS3OQsOHOzKOQ7WU4WCyLeOvxslhMX4e+IeLhR7D r7weBwHI3HNx+GkcHf71chzIw2D8XB1+gcOfx6FFHh+BobBgqEALo9iB4S++UMcvyCGqZkqTHWIQ qReBD799MDnByxcSPgbHL0LE5bXv+6L5S+LjKXOYvHzxHD4H6qW5Mu5O++beOOnOBoG5p/0DXPOU lUk3tx2TbWbpWB5ej9WhRj6e63FsPuVsBeeWU/iR1sjq7eDqqWglZli6A63tXssng4uwpvyw+T4U 4GKchOsABxQNQcfkIStBg5DeX5HcGZzpTjCjgW9PUAGRPZb3VInkIgYjZxlMMAckOmTSKWB2Cx/+ To5EmOCkLQcS99bc7bj/BVmEUwENCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBl L0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FCQ0RFRStDb3VyaWVyIzIw TmV3L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA2IDAgUi9GaXJzdENo YXIgMzIvTGFzdENoYXIgMTIyL1dpZHRocyAxMjIwIDAgUj4+DQplbmRvYmoNCjYgMCBvYmoNCjw8 L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NvdXJpZXIjMjBOZXcvRmxhZ3Mg MzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODMzL0Rlc2NlbnQgLTE4OC9DYXBIZWlnaHQgNjEzL0F2 Z1dpZHRoIDYwMC9NYXhXaWR0aCA3NDQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYg NjAvRm9udEJCb3hbIC0xMjIgLTE4OCA2MjMgNjEzXSAvRm9udEZpbGUyIDEyMjEgMCBSPj4NCmVu ZG9iag0KNyAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMi9CYXNl Rm9udC9BQkNERUUrVGFob21hLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNj cmlwdG9yIDggMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMTYvV2lkdGhzIDEyMjIgMCBSPj4N CmVuZG9iag0KOCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUr VGFob21hLEJvbGQvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgMTAwMC9EZXNjZW50IC0y MDcvQ2FwSGVpZ2h0IDc2NS9BdmdXaWR0aCA1MDYvTWF4V2lkdGggMjMyMy9Gb250V2VpZ2h0IDcw MC9YSGVpZ2h0IDI1MC9TdGVtViA1MC9Gb250QkJveFsgLTY5OCAtMjA3IDE2MjUgNzY1XSAvRm9u dEZpbGUyIDEyMjMgMCBSPj4NCmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUv VHlwZTAvQmFzZUZvbnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5k YW50Rm9udHMgMTAgMCBSL1RvVW5pY29kZSAxMjI0IDAgUj4+DQplbmRvYmoNCjEwIDAgb2JqDQpb IDExIDAgUl0gDQplbmRvYmoNCjExIDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9T dWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAw MC9DSURTeXN0ZW1JbmZvIDEyIDAgUi9Gb250RGVzY3JpcHRvciAxMyAwIFIvVyAxMjI2IDAgUj4+ DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2Jl KSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KMTMgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmkvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQg NzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMS9NYXhXaWR0aCAxNzQz L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94WyAtNTAzIC0yNTAg MTI0MCA3NTBdIC9Gb250RmlsZTIgMTIyNSAwIFI+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwvVHlw ZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GNC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMTUgMCBSL0ZpcnN0Q2hhciAz Mi9MYXN0Q2hhciAxMjEvV2lkdGhzIDEyMjcgMCBSPj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1R5 cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmkvRmxhZ3MgMzIvSXRhbGlj QW5nbGUgMC9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUy MS9NYXhXaWR0aCAxNzQzL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRC Qm94WyAtNTAzIC0yNTAgMTI0MCA3NTBdIC9Gb250RmlsZTIgMTIyOCAwIFI+Pg0KZW5kb2JqDQox NiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEg NSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFC b3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgMTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91 cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4N CmVuZG9iag0KMTcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTUwMz4+DQpz dHJlYW0NCnicxVvbbttGEH0XoH+YtyZBuubeeCmCALXsJG6TQq0F9CHJAy2tLBYUqZIrO/77zsqX ODEXLLcjVYIN67Ka0TkzZ2aWaziawqtXRx8mZycQvX4NxycTiFimMrgcj5TQLMogTVgkFHAVsVhB HKf4EBozHi1fjEdw+mEC8OhT+N2n/D0eSSbj+9UqEUwmj1f/+QKq8eh4Nh4dveGQsEzAbDkecYjw zkFnTCs0l3GWZTBbj0eR8ymCt+PRx2fw/DPMfhmPTnH57x1eCGIvUoGgPPUCvvPjv5pLJEuF19xs VbRwVlnTVMbSGuZSs0T4DP9IbAwjSSU+YydNvrRwXZQlmC+bojFQV/BbfWXWF6aB5CWIiEtG65EU nMnUS3NPsEniYMMoCAh5RexFrFiWPPFiUm9umuJyZZESW8zNfsKw23YfApoYAR27BUO9iIm9ULg+ Ppz0dJv7SvunZ/NPz3c5SEy9+77S+3WJjWGAidRn7Ox09gZmzba1kFcLsCsDG9O0ddVCsTCVLZaF WUDeuleIdQhZSPS/BOFJ5CXEkSfTzvjfV+R1m1vU8+0aQYd8a1d10zKAn7E07IKxxY9vTXNlFsT1 QCAE2AP5EOjhISXmQWQh0ZBRexEdNBq6ze1aoIeQwL/b7cVfZm7B1nA8mUKSPqTs1yz+oYX35jIv iXPVaYj24tLDDo+I6eH8oGWi29y0qa+KtnBK+Ycpc1tUl46ZHRUnd6y1xKmqMpal3u/fRwP1uBIJ xvnhaOg29+nZytrNT0dH1oW/Mawwdsnq5vKoxJataomrlhAx46nPGeLhQUicT6XPWFEta2xPigrM cul0AWcHJwYL4txXmvHM50RucWZZ7qcz8MRXX5gTz8M6k4dUG4+5zfYC4xlVBkmul8jzo9qAbcK0 NHlr0MxVYa5dFOCDxX5ESLp+IfHC0scO8QCpU3VIEfKYm+eNWW7L8ublXat8AwvTzpviwsBNvW3u WzhXr7GNs00xt7vKcV3YlXtmg/lL67DC7JHci08fTcQTtk5222sHo6nbHJbn7xNnUi8M/lpv6sql CpgvtsnnFmeeZVOvv307rLHCECdTljAde+HpY4l4F0DHWNwOt/XnMVdU83KLrJwX6015O38en5/A +9tyDhYpgnwvjZXHofYhmReu2p6bXfKCYnsofSm+U3qJ6IsH4v0YrRPX7BwsHrrNuZ7mdodiN9nA o8bb6SlKL2zcUwukx+lpvbVwnTdNXtkblOO99CY+ZPoIIt620Co9aMJ2m/smOxxb3ZlLvW/hZtLY C0EfE8QbF1pmQQFBvHOhcWIIQEMQT+ha8BA0BPGEqrlgQg53g3qCiGQQGsStsspUEBrEraBKNRPD O1JB3OuoJHbyMdgN4hKr4oQFcEJcR5ROg8AgFlGFbVgAGMQaqlQUAoYk1lAleQAYklhClcB1ergb xBKquAwBg1pBIxUEBrGCykwzGYAGsYLKNHYHCQa7QaygMkmYGn5RQhJLqMQFIWgQS+hudy4ADWIN lToKQUMRa6hUPAQNRSyiUgq3ZTrYDWIRlUIGoUGsopKrIDSoVTTSTA0Xc0WsoiKLWYAXxCIqcL0e PjcqYhEVSRoCBrGGijgLAoNYQ0UcBYChiSVUaB4ChiaWUKEE08N3yDWxhAopg9AgllAhVBcav9bN yl3HeAnGQl4yuLud7s6Wtk9OlsJ3t4/T/NKA+LyXK1Een3uhI5Z9wTXTAectqWU/iln8tBbfnnim xT9NGY+8FqlPV2cJi6XwWaM+Xe1CK/UZuz1dvbudTa9iWNbN7ke+nU5hYspyW+YNvKtb2z7Ogg/5 zR7OfN5nQberveFHXO+5o2n4HocmrvccYzMEDeKCz5OsC41ZflG6S3wwqTEtyQ9S3P1rgMd4LwbE 3QZPohAqYuJ2g8e8E409XdHymONYOlGKm3qxvb3WywbfQe1FP3z49NFE3I5xLVjSeeyGmqgUV2vh M8iZo+p8Xm/Mw7Go+8OX/ytNHnw6aPoHeQ3PzA0KZW5kc3RyZWFtDQplbmRvYmoNCjE4IDAgb2Jq DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUj4+ L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAw IDU5NS4zMiA4NDEuOTJdIC9Db250ZW50cyAxOSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJh bnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2Jq DQoxOSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyNDE1Pj4NCnN0cmVhbQ0K eJy9XNty2zgSfVeV/gFv60xlEeLGS9XUVMmSE2d3ldLant2HOA80BUmsSKSWpJR4vn4A6rJ2DISW pgHJKdmRqAP06T5oNECgdxP066/vxsOPIxT89hu6HA1RgBOeoHm/x6nAQYLiCAeUI8IDHHIUhrH6 E1Wy35v90u+hq/EQoSffQvbf8r9+j2EWHq7mEcUsenr1f39BRb93edfvvXtPUIQTiu5m/R5BgXoS JBIsuIJLCE4SdLfq9wLdpgB96Pc+XyD9ePMF3f2j37tSX/Hvfu+vAsbqakFtgARTjNDg4aGS2zxt 8hIWnIQc09gGXtQI4ROeSMC2jgfqAmLl4jnYC4+gwB4RU+WgPj3CDEgwU5YeyuVys0wrdF3WDfo4 2YbovUybTSU7OUOhG5Ys9ulgiQGzFDFL3MJ2WsHE1AqnY/YyrfNMMXNSBD1hKXLDksU+HSxxYJaU 7CSRz1gyA1JMlKU/Fo2sCtmgSVU2ZVYu0X9kVedlgUJjLMG2kKnx7ScmgQYTmCQ2MPfe96pOvvA+ Aex9ItQXePQ+MyBtx/ZPMp8vHsoKjfI6K7eyekR5gdiHyUS91Xwrq69WRXfFksU+HSyFwCxxdX3o kyUzIG3H23aEvW3SRi5lXaPBdFq1rxstGMUsn28qnZ0VJpZiNyxZ7NPBUgTMEos9x5IZkGKuLP0a gl4El1uWLPbpYCkGZokmnmPJDEixaGMJbQ8DLPR0RsEya3eBwXQOSGxgWsnRRPmZxd9+0IjEjfe9 yhAvvC+B9r7As0aYASkOlaXH/xq9jhOPLJnt08ESCYBpIsSzSJgBKY6UqSdVvk2zR3T1vZGF1ooa zVSSdND14Y+a3g7QO5pI4IYmi326aIKuTKnWEOKTJjMgxbGiafRYpCs1z23LEM9JOc6mNG8tPfcX o+uhmwmNuY0K9P4NcuoUFja6nAK4OCUS5jd2LYAUJ9oproea7kklZ/l3NFIZ2dyWHP/4dESTzT5d NAFXp0TM/cauBVD5bIDRTblpVJKyVjTJShaZrFFaTNGqrCSq1zLLZyqwK/2hFzNQVzRZ7NNFE3B5 SkTtAoRHmsyAWlqwqUCgaUqn01wHVbpECy2+pmkoIW5ostiniybgOo4IQ0yMFXkntV4L3K46gG5l tqny5nEXKU5mGpYGnFZXduUSFi66XAK4aCREhEnsM3LNgKwtLB9zV7SQ6VRJrYrROle/tDH604Ua VzRZ7NNFE3DVSPDYa+Sa4XTFaFw+5EsdtqdFkWuaLPbpogm4bCRYYokmNzSZ4dqS0eDTQE8vXhk9 +yf0VCPRC5w2owCDCY4jagM7uh91436v6uJL9wOuGwkWeFUJM5yuGQ2yr0X5bSmnc7mSRfPaepFz msz26doXAVw3EpR4VQkznK4ZHXOwk5XCKU0W+3TRBFw3EoRiyvzRZIbTNaOb/883zxpzuRuaLPbp ogm6khMwzxmsGTBuM9hPZbVSQbSVSBcJoGc1MRahDf8kB3HlEhYuulwCuGrEE26JXEcuYQGM2/0K H4vZM6c4gSjiZn+gzT5dNAFXjXgsMDUW95wIrAVusF7LYpp/RwPzLsH9AkpezPWqSbOQu5WwcTmV ywNNbjYI2uzTRRNw1YhHIabGUrkbmsxwR5ouNU2LtJirGGpKdPN+iBgj4U+iyMlEw9LMY+S62Wlk 46LLJYCrRjyMsFd9NeJdtiPuYevhtEpnjZMyohn9704GdzNWLpsZMFwS4dBmWOCu0aC9wIy1Dct1 DYxHQ52F+OmbmlImzIJVzTItTQ85dAe1r9iiELqDOgQtUOobjFmLI+0zi06X9AFXYrmILaOhK+0z A162uaUH8TPDO1I/M5g7+fPSuYP+mcEcCqCf3u0V0AzmWgL9dHGngWasgHgVQYv8dKkg8EIH54nf BNCId9nuNPeggUZ0RxJoxHKngD66dhBAI5ZD/fPSt738GbFcq5+XDu7EzwgVBF61zyw6XdIHvMjG eeC1HGKGG2yaRVnVfzuUp/YFRWCN0NQTWxNOWoJwc7OIjYuuW2iBF/Q4I2c4JgNer+JUXSdObwbw egwn7BxjQC8BBPwsYwCXuFkiMDvDGsAlXBaHmJ2+LsOAy4YsijA//b4NBjyFZ+qCc6wBnEMz9XqO NYDHMyaCc6zBgTWUcXKONTiwiDJGMT/9hmsOLKKMsrOsAayijPCzrAGtooHA/HQx58AqSpMQn9EK YBGl6npx+iYmDiyi7RTk9FYAaygNE5Mx/llWi7KQxVskG5QuMdo/rr6vc33gy6dyK1cPskLRWzU5 JQz98Pg8SecSsS9OklZLmztNB6z7NAzOIFAAyz4VxGSMwwkjsATokgejNkzoeo5mO7aBjXSxauds 7S4Dfcuf/tfuLXi2C6F+6pjj9LF1WDeOaW5qp0sAD8GUUyxOv1lGAA/BlLGzrAE8BFPKTdbYH8NT ldNNpvdsAvsuE3qPgwW70wTAwz8lAoszDsGBHv6DUFdMfRV+LHB3MlsU5bKc52ocqzfZAqW1m7un LA34MLm5RfcXH2Qhq3SJJmn2VQ2yN+k0L9GtrLZ5Ju/fvEW/j+9ugTfehImVgy5XAM7B2uK5vxqg Be7+4vci1weDKBra23IkupNLmZWr1abIs/1e7tvHupErTcnVtlxu5fRA2e4NYI4Sql3HZp8umoBz VBLHPiPWAnd/cTW51fYfjsYDGgSBip5hOZVolG/zduVqvFk2+VrRN8gyfVaD/tD9m/amVXl9MxnB x5HNMl0EAafvJEq8xpEZThFULNIiU6Fxnc8XSssaeQiSUdqkmopKolX6td0E2qB1Wdf5g+JLZ2zZ PlmDDqRIrwbaDNTFE/BcgUSB10Aywy2Az3Ldry1b0HTm3ZRokW6likQ1i/yWPgIv4+3XVywNgJ6P qJAPEhuYUqGsLArZJpO633qj82EWtj/ODXofbaJrS0/ao97BQaCGkONrNTf9740pBv66KnJMhdXT n4O1bwmFoL6EKAjBVONEpNBxInZwxjOXQ+DZMwmJV/00w32+eT+kPAy+qGCp0YNOQCTSa5JFk6vU RDlTm6cWh7Oj1Ie0dxWbtgRTzqCZVFFF46eNPc2xdGOft8h8/RFHtVbFlT5ITX9A+XWSHF0AaGpu I/onbqldJH6lWwLP4IlqQ+Tvxg4L3GFgbk/7qFGufoqskml7K0eVrvPp8nF3BGIxTatp/sfuIJCy mqfF/g9gvT8M6hbzGAb1PwFToFfFDQplbmRzdHJlYW0NCmVuZG9iag0KMjAgMCBvYmoNCjw8L1R5 cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDcgMCBS L0Y0IDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9N ZWRpYUJveFsgMCAwIDU5NS4zMiA4NDEuOTJdIC9Db250ZW50cyAyMSAwIFIvR3JvdXA8PC9UeXBl L0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRz IDM+Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzODIy Pj4NCnN0cmVhbQ0KeJy9Hdly20bynVX6h6k8SSkZxjG4UqlsJbKdOFve0tra3QeXHyBgKGIDAgwA Uqt8/XbPABSPGYOiG1AqlgAR6J6+rxmx17fsxx9ff7h5/4bZP/3Efnlzw2wr5jF7uJhx17fsmEWh ZbucOdy2As6CIIJLVouL2fz7ixl7++GGsZ23ON1b/ryYeZYX9E/z0LW8cPfp/3zPyovZL3cXs9fv HBZascvu5hczh9nwn8P82PI5gIsdK47Z3fJiZiNONvv1Yvb5kjF29YXd/X4xewsv+OfF7FvBhZ4V uUZwj1X9R14+sMe8XbBUFMW6SGrWinRRVkX1kIuGLZKNAEBp9VDmf9Hi5tnwgG/CTWSsXeQNS8qM LZNMsPe3m4AWAY4IOEZe7AM7kgiXWCIiFwR0OonQg1sCuZO2qp9YXgL9RV6zZiXSfJ6nSZtXZWPR YuN6vhVExsUPsMAjZgHQ5gxB4MRYBNyKw+kEQQ/u03q1quqWzataap7UQxAIkIu2rrJ1itLAqjn7 14e7T6xpk7oFjZWGxPv19pbYUgCuoW+kzAB/fGL++AE+MBl/9OA+ikIkjaAF6dih5RhBviIG5oDZ dUzAQA9L0aKDUi5gUTVtYzH2DuSR2ARx33L38IDfWLbtwef67/WD7u5HiSkqxT5G+ue3cMDIMCe2 bD+A37tRZDvbsOOb1wIa4gYmmmaiTfIC1DQTTVrnq16FpX7nJbFzBfZGZm3ZByZ/5QMEeIkikG35 IQC3Yv8rQVlArNkcng+m02w9ODSfz7Kfl2mxzjBIQzl7u6mKDTDwNkn/EC379NS0YnlNbGyRcYGR GNTAAivwTMAaIdjnj+9uAu7HX4gjDy/yQPlOXOaR5IXEkudFJ2jJERYRMRZurKOFYzlgeD+l1Uqg tZBR+ZsqXS9F2RK7hNiVNkOPxxA1Ympq2OfwxLGJ0QB1nNIo6cGh20UDtFrXq4o87EDP6O6CfpkH bk5xv1sgrhXGjFthiO4XsKbyvY5vG5lFTC+fy3BYD6xX0axT0WuWPOf2EL2Lep6kEMc3LIV8Ls9E LbJx8uqTiLHn+m1w+NFpvt+hrsgA0o4znZ7pwbUVuxd9ntVxCu7tcDBJU9E0fYDA7iEJyFglk3Vi B4mxpG+ky5AZJC6P+LE3pRk0gJtXRVE9YjQGGW+ZJXXW/CDzXfbr7cdPMlGR+fAo2Zkbh5YfmVAj zs664pwBWBxfj7NGD02bO9UaQbZ4aALGQfGoyxiR5XtGUR7SKOJqlx/xKQ2eAdyYdQwDyHHqGAZg jnMtzcLb27Gsgi0fmGatLhLWNQGL0FWNs0hV15hokUGMnzQylCUNewR3jN+JDQRWw43LnK/bdS2U g6nqUUI2k00YMk3EJXA/lB26yUyTHhyqbK2kGSuPPz/HYFiM3A+gmQrcEvUrWQZv1umCJeOwyUCf ITYRV8L9IEAzOxmb9OCOcxviSpGDxicyrnaI6MRFSt8HExy9HA3iipXPo0l5rwd3t5vogjouV4XA HxuZQsm6dlll2MD+c53X3a9URdHjX8hr3l1N0USbIRYRl/N8L9ZKylgs0oNbFaCR4DAXYCZZCno6 Si3EAPy5b80SAF8KkfVdSuKYATjv7WIxUg+pAwMmYLeFFMYxWRmrT/z0BM3yJl03jWwcyZoDWzdY FabuHQVW4BoF2FxAAsp01SMgDo++Uj0iLhb7nj2pOdSDA34ANxqIWVLsxkv7tz++gXoIrFuJGq7L B1ZtBHU/tQ9in1F8mS4kJ2lCD8UFtHzgNvxArwrct5zYROw+7hjHhRjk6SuiryhxUu3UJe5R+K4z qafRg9vGf9T5faAkzTnPtp/WneiBuFhL2HYn/JhQnB1YgZlZ2OKTGcu+xcA0pxRYck7UUFhVZ/Qm g9sHmL3QfVbUCHVlyHMREmVyXxy69H6V4LiBxaHly8eITVYEn/TOR3x+NF6zfaOUTEemQoeSuWeH 5PJ0ZojK2Diu5Xo63zeOsdGDG5wOJW5P+bY3qYnVg6tWbb5Mii7o6weHdttTo4yH7mDzMnHuu2Qn xdY9LFAdhvMYEX1E4eIgY2iirig3eV2VmKVaIwVlBikax5zrgd1B0rA7gPaVkEayYkRTwmOu0+28 oaUH1pPBmxigDVoS4k4qj+Qc4lSWxABOjvTP62q5azxk8XRVQSCH1mWTi0eISm62VR2MQFT7m7rT HRupMsQc4qYcDwNsdEzGHD24vR0gy+QJS9vUNdUYo4od+C9MEjdJXsgY67CGZ3hPDw8wATOI7UGO YUzE6Wy7G6C5I1gShLOvqR2pmh04G7lGbQcQGbt/2sdsu2yOCasDWajP6cNaFY+btGOUsQCTboD7 MkQ7u76ro8eYzisIrWNvgib0mt2vW9bCj0KVPSvqOc1Om7QYDJpM4mYh96NJTaYeXFcYBQWBeFgN 2oPver9ErUlkb0K1Cneq0Q/5RpTPKTUxjzycpXVM6FJPtqB5CYysGJII4r4k57FOLscSCC00UeTL vExawdblc/0E8qYaRWG+ViX0TXeZP6yVZLBKBsUN9Uy/mjwyEGaIPcQdTA7pwZQKqwcnyganKWTR UNbD7/Mib5/UPreKrepqA/oKl0wkzRPAm4talKmQO+KkbaUu/Mo6i4k4Qzwibu9yz5lShbbQXhaV PC4qaUlPiQB7UG6MY+Aj5ffdLJieenmfx2DjRVM6QdeNPqPdr7mCMHay+pVoQ61qzGjDlW3B42go IfZbaKlgEQZ4g3pA3EPnjjelHmih7QlIFzpUVcbSvM3/AtEgzhS6eF6/cOrynm3FngGW3Mcg2Hs0 0KVoqbd/4STjaas8FjLi5jG3+Tmy7hF38bzYt7zphN0Abn+kJ8cdkOBxlzI6Sgo0maOUmHeweZkP ytvDKdCvlpe92ENLPdLwhot5spG0EI6CG1HzyLnyMlUrI6AykyOMo+wANomV2Zt1NDqple0R91m8 KLC86fosBnC1kGNT12y9yiCHuIYUEfOEtk6yPG2BgU/dcEe/C2WrMQ1TO/VGCU5NxBkyVMQVbC8M La7ZmTkWj/TghqYLyU9Kkb7StPYhFhDXqT144BxJIK79yFLdhJKgB3fkskYZcdwB/jIPtUzysng6 yUn1oALHckDWAG0vIC6TO2hK4vNXs6rzZVLnxdM46nUuWofk7VcZWh7fHfaIbLrUrA8p9FLZJvWD wIo9MaFCWeE/m1Bt9Sgd1kEXoXtrJ3h9dk4peN1RE9+AOLFPxUQrIJO47fKkxPVzOrQC56GSOEaB w13LfY1D1Ics3ovwAEu3747sj+qSeQZb56AgqRxnbrOr/BjADvpF4gq4x51J/aIenKpXYImIPeZF gV3kddPP3+/10bbH3RR506oeCn0Mq2rgJtIMcYi4CO55LjYZJ+OQHlyDh7pYjMmZnD6A6UrfDXtY 51mCJe+qZI+LPF2opKMWBeQkxGdGdE1XE1mGuENc/vZcb1L90YM7GN3Hwp/aZvhsZaWqyJ2G+1VC 4OltUrfUgzKqp2iizhCTiGuzHji5KVVID+7wuBW2pI7+Y2m29NCTJ5YUTcWS1aqQrYIK7Gb9LAxF Xv7B2qeVaORQwCh7FUx8GBIH4iqqZ/sW11RRxxIHPbh9WcgqoYpsz+3EJ7Y9hi8pk+Kpgc9j31fy Ddk1TuXGQJwBHnHiErMbB9YZWBDX+Fx43n/5/kxOXMaSOc/LsSCu5OBpBxpi/L2qF1UpymsmWjAx 4E/U19v/rfIahPof1UYs70Fkw2vm2pCzHXx9vk0eBONfRtn/bsB5kHTE1Sc3sM9hIHGs7/qOjhh9 34yWAXEISaZrgkl9sgpyOzIBe1Mn81YJmwxLcS4D/5fHMd30DvA3mYP0X9Rz7jGeWm3Ajx6cOpDL AO4DhAKoiOMonGGJQ6JOnDS53LX8Mw7oJs4OXM87ixrE8a/rci01Rgp4DOBkcClTyN3Ap1lU6yKT oU+f9SeQwUDsM8/LvM03Qqb6/SaicYTWQJ8hNhHHpa7jW/50aYoB3HxdpqqFnlMPA2NRcA/uCxvo 4rQdsj0YyD2DnfpmGBMe4anOCD17KUdNlv59oeWG203qXsQhIifDWbVsTGyvDpLBpss02kVSdiPi Xc0tuYeQjvyQZZl9mFTAXCDu2HzSCIBPnaTY8vSJyRRWD+6dOu0rBT49CJyCYfsHg8uyar5cJWnb nUe13SalykXLhLhF1g15m8gzYFZ94iTOwVB0uiliAzhIhdYFztB0kxoN1mDaRU5sYlU30YDDs9ul HjnAfZyBkdJDDCdOl5EI58gdcb7shPGkcqcHdyePU8KKcJbP5WR6yx6TJyl+W0NwUBP+YZT+pYke Q2whzsWd0D5LOvpkHF165Pndv3JgT+3VlvVX3N9mBc6wKyJOeJzAOUnYjhGhSnl6MdQjUqnWkfQ/ KQQU8gjE79ICworsOwj2N3kqdMdtHeNLlRv1XDPgi+cX5H8dDUUc40OVBHiugzUMAz5Ytu/7O9cD KAVUYU5XtjfJ1kFQhrsYH00hL3PZ7wxe+V8G6sIRvlQXly2V/sTqRuCw4mL26WImb0aevBk6/afw RgD6dfghuBfuvgmuo/4zSFfX3wEnCe0fgPPUkTfP4Pobu+B27oW7b9oBd8wM6mgG4t5Quymf3LGA G3VsI0SprGXFVlXT5N2WKDyAPstwsDSrHsuiSjK2K7gqFEX1xz8WOErMaSLPETB4CATys6323sI/ X+AOy9iMcyWegfxLYkv8K5CeZW/Nu2Lz0Dv2HumlKTp6h5pbeuzetAWNHW752PaGPCaSQ5Jo40vk hgQeWLz7OYVsCHTU7a8LvHYRkrr2YS3B9jXbKwlFPqtu4LGlvnq4uxHKU8+7VwXqTPIOkLpKEUeJ iLou8FphGXQbCTtqyldtrySk9OJgxfD0Aljc+8s/1csiX2IeqgO27AB5H+/KxJ667cSSJz2sBMpl gWTFXnEIh/FQu+UZJYcSdXMVX1ZXrxz7crkUV/CtbK8cBwTtlXf5+Sq8/PfPVw6/dK9e+Zdf4PKH q0AjhC/AkGsw9G0Q9siE4S9Xr6LLdQ7Aiyt+eVzL+VbgDseZQgPw4wL/N4MLlBRqweWwwvJv5DBd bnkmkAfc7B3x/wEI2uG/DQplbmRzdHJlYW0NCmVuZG9iag0KMjIgMCBvYmoNCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vUHJvY1NldFsvUERG L1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45 Ml0gL0NvbnRlbnRzIDIzIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgND4+DQplbmRvYmoNCjIzIDAgb2JqDQo8 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMxOTc+Pg0Kc3RyZWFtDQp4nMVdW2/bOBZ+D5D/ QMxTO/CqInVfDAbobbLZnXS9TQZ9aPsgy3SsrS15JDlp9tfvOdQltkNGtnvkSdGkiWN95LnfyLJX Y/bLL6+u3l6+Y/avv7I3794y24rciN2en7nCs+yIhYFlC5dx17Z8l/l+CN+yQp6fzX4+P2Pvr94y tvEU3jzlz/Mzx3L89t1uICwn2Hz3p59Zdn725ub87NVvnAVWJNjN7PyMMxv+cOZFlucCXMStKGI3 y/MzG9dks4vzs88vmPp4+ZXd/PP87D084z/nZz+KGIYWt42Il2OW5MvlOkuTuErzrLQYe50x+T1e rhaS5TNWrhPaBQnftYRvWtCcxWyelxVLS/jXnSweWJniWmgX4YSOJUIjH7bBnkiDIJaGUIBwnlQa 9IizvFgiz2O2zCcp8H81zzNp0S6BR4HlC+Ome0jvEJM+cAyKSLtpgAmFES5n7GYua7lP4oxNJIPP +UpmbCrv0kSOmLRurREw5qdyGRdVzZif2P1cFpKlqC3E+gFM8nwjeXqY5BIzCSxGFJxUP/SIq7ws 0wnoRZWzaX6fLfJ4yuLVatFaT3xBfl/F2ZRVwNDZOkvw5/EirR5Asah5JKyQG6nTwyOPmEeej284 JY/0iEj3Wmmo7RZECm5g3GgPuX1icrvwfv90dksP19itRC4W60VcsCKepjn4jqlcshWaKTBmxMGD 61mCG7dPDRZZUWgCAyNdSthlXMkpmxX5Uqm8suGXY+poBX7T2XPXT0QvIBY9Jzy1pusRyypOvrH7 tJqjt0yzShazGNSesX9TS53g1tYy4AXLtsEAd1+LW91PP6qF7sSu+je3GJ4VOcy1gsCHl0UY2rzL Sn58G77FQyMDiWnm2LgTA9h2gjEnxnbswOLH8yveWU77OMUaUAJIHKhZ43Df8o3UekyIFvGqylfD xBF7iYV6yQMEeEhDEdvyQFhDK/KeSaBDYiMkIoP/G8wI6REhe16twfKA8Y8rti4lcumP6zePTrF2 h5BaKf/Q/ThOElmWxDFKy0oDdXocRUTNI/uYSInbxMvg/KShkh7uErPqjvlKoecxyMp0mtYZArn5 9Sw/3FzNYTYQC0PxKsZkZy/v1cDZIUZMjX1AIxlA+kjmvzAMCkwU7gIA6lQYt+YfT8ldZ9I+TlhB 1Dl6WB+ZK8E8xT1+vXnG7ucp+GQQAfA5O6tvH65W74PTcsPt5W85iFocdA6CSrltYXF+xC7BUk/3 EewOB7TbZRzsqoO/4MA3VFsJQkWfja1sivWI2JvBuz1hAnvG2XtR9OjsgQzAd3O1nLhc7kWO3oTT 0saHbQXCiDaIuzCAfXmhwmLwEO8haigyWY3Yp99ffxixN4u1rPK8mo+YrBLry0sMKzL8VEi2jB/Y hLpU7oGR2pcqT0WBuFbuha5WcAfy5ga4DbddyD/XaSGXMqvKLsprq7YT+ZBnU7CnsYrfp2mZrEuw PJCtDhL4majTxyTiqroXqBbbyZikh6vmSPI8WSNvsK/VMW3xMGJbr8I/IHDP8go06BsW3x+I2YM9 L89Ilz72ENfTPfDbXNtvGoY9erhCYudRZtOmdJ5nmpp5o11TfLXOfalLBXVAY1hjm91Rh5R199HE hz5xIC7de16AZaGTiYMebh7fpdntZpLUBfSs9YVxxuRyIqdTEIg6rQZ7W6fb6ttBemAm8vRxibji 77nhSZVWD1dWafJtxHIMN7DkkbFOjZF7izT7xsqVTNJZmoD3Q6YCixrVbjlLu2AXQlmHG+nTxybi 6rjnRCdVJj0c8oG4tIRde0h9TPvrIzNx/c9z7KO4TVzi8gQ/Kbf1cDfboUwTZJaQwN/5O/4UjGg+ U8pYpUuJ8wOZioSGiUYN1OmbriEuAHpcWMI5HZP0cB1/sOw3kZI4AeCYpXnGvVKDAWUdE9h9kVaV zFQf7jZHt3CfF9/QCSiBxBw1ns1kUrV50TDCtxclngofdenCdk5qIfRwj2H0DAxCtS7qRjV1+4Ej 6c177iM9canAjdyjJIA4GXZDNbJwKgkwwN0UcVaq9JctZQKBW1ouS+xXTdnkYbsxAXE2yAcmw8SK ie1nf3OBh5Vsp7JMihTC/706Eh2ab0UQJEIoH1EXbh0gOdhcA8XJSzx10mgSJ3Pl1oU38v26tIK4 0uAGPs76Hs7ra+LKLliCyD9+OUm+2u2DEbWVj17S7jThs+0LN3AxXMYOfxiS9+Wa1GBjK4MaOs55 rdJauO26Hk5iojVbyFmlqrOzdaFy17JaTx+sen5tVaTLuHh4ToVq+g3YyHL9wHrqq6rOahOTECda TKC9DpK4/uR64UnkpnWQerjOK7JyvVrlRVV7RmK6Y/uNby7hMKXHxG0fte9wwAcGqmvpteNkdJIr bPUGAz2dC+IhSIEjUp4JTvWqp+t4QQwKMupGJtC/DXIyxgBWjzt+/vjbW1dw5yvYrnfk23X8U+21 jZ2e2esg1VyTsXnG9tdKtF/8RFz0dd1IZ6CHsoxatHYMaCLBkRLXbpuZ+kfgw8xhuZctbDA8btkc B2486jyA41C6MDGLuvRiH0+u2rF1FahdV6IeHeBWQhtw6QPFZib42PXf44jD9prbJ9bMFSDHdkjM XYGVNZNyxKoXVeXsYvzxGoLKuKiw4KWOAwxyBuBY2j2NHLoHKo5z19IwfMsOwi9yoR0AIrN2tiGS GLOPciHjkni0hWNI4ZtwiT0exwF/4yYjTFWojWtjlrSAvVE+cWPMdfgpXZkWDfT0/XhYNeW4AL6B f7iaKnnfy7M1WCJSfFa1V3KT3UTdWnoOopTNqSs9InXE3dh2LVaogm3f9aKvo/qkbbw7DvvDRr2e rTtWWtJdF949z0HT3tp0x4sIJULlCD8g3jsrxqfVAryHC6p/ccgyjID3eU+PK8XFIpUFMffbutkj 5mHU3NtQdEDKE3RREq2laP2bnoJFbSqIe31NI9KA+VxSB6TokrqeaWZBPLvgcueUnrBDG0i4OhwP bc4gIXgrv0dupet+bm+neyofzn22yaeW5cv1okrxFGQJwQh8uRzi1KoeeoxXq5TYDazTenLHpo5M HsuweaxyqomsG5S605iNuAWwReGS9/VCZVW0lIN1PWNWalka0kHZrs7UNak9sX8ClcCSmR6yN4Eg nrVyIs9yTmc3DXBYYmaqPEk9O4H96si4yx5iO8QzU07og0odvgzi6RknCEC/nywDlAzn+SeTQt6l 9fg4fZXNgN1LAuIpFgfecAwniKdYHGyEaKgxlPbp4cQFnu++lgmeqrmQmSwU99lVfV3VDQSZ29eZ jbrZ8YvrK/oSS1NDMxGnj0fE0xaOZ2tFpf2g7iELRDOAqnpoJZN5li/y21SSj5oh5SPjlvsoT9zC dlx+Uu3QwzlKO27maXGocvxxdUM8cYN5vYkqfcwhbqI5jsAY/MRqoQetyCvYahbGgNZo3wO17tWz xia69rGXuLDsQMp5jJQRZ/UOd4+iBnWUbHuWe3iw7hLHjyLyrSNWQRw+Qi4PXw9fBnEIJzCfPHwV xBGc8CMdMf6VF3iXZIbHyVm8sFqr+P77Ki1kyT7kd3jmrmDBiAmbO2zn4/M4vpXM+zrIoS7DmntJ RxxYCd8+hoHEQYbwuI4Yl3hMMpPUuX9dHDNgUrdGa59pAHtXxLOqFrb6RBOOccJfVaF8206u/0NN rm98XMUPSmCHEUz9UntFgji0Ea6wvCPuZyV2wcJxjqIGsQsWwtVSY6Ao3ADnqij8txwHjQ8Mw3+/ eU8fhZuo0scc4sBEcM/yTh2FG0C7vHSgyNi01x6Se9RBmO3jTdsn0wc9HLEBbm5LMoChS2DOdv47 josKvinn6YqNi/y/MqnU4H+Rr2/n+bqqb2xpTgwQX7fUHEY0caJPIIjjYXX1uunWxKF00ACqziDL Ylm78S8v+pn25SWDMAfPkg5zHYeJOn1MIs4WsLKl19ohmaQHLeQMe4NVzuIimadgN/HsaIkNkGwa F9P0f/UpCeThiKVZU5od1UWoQQa4TeTp4xJxNsWD6C9QJT0oHnJ6Gm+0Exd/Z1E0Yu6I+oLJ+jLG Z5bkjTCmuYcAHb/Wx44HCcZNvOgTCeIskQf2X6C4etCW+eR34KuRUtNO+whOnBBznxt0cJD4xgD3 evwBEF+r63zZOE+zin2Il7I5W4iv1jc357cQ8C9YBq8xZVcLHEFF0zpIT8pEnD4eEWeo3BNWoD39 PqRS6EEvLq4/YA/wlbo1anzxaVSfD8X/7whrKMidOsCgvpZZjayYSKHhyP8BPsBhUw0KZW5kc3Ry ZWFtDQplbmRvYmoNCjI0IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl czw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAgUi9GNCAxNCAwIFIvRjMgOSAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1OTUuMzIg ODQxLjkyXSAvQ29udGVudHMgMjUgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5j eS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KMjUgMCBv YmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzE2OT4+DQpzdHJlYW0NCnicxRzZcts4 8l1V+gc8SlMxQ1w8tlKuyviazMYpbexMHpI8MBJsc4ciHZKyx3+/DVCULQkIbaWptcuWCBLoRl/o bjRIXk/Imzevz4/eHRP/8JD8fnxEfC8WMbkeDgSTnh+TKPR8JggVvhcIEgQRXJJSDQdXvw0H5OT8 iJAno9DlKD+GA+7xoO0tQubx8Gnvz7+RfDj4/XI4eH1KSejFjFxeDQeU+PBLiYw9KQBcTL04Jpfz 4cDXOPnkbDj4MiKEjL+Ryz+HgxMY4D/Dwa+CC7kXMSe4kwlMkpzcFdmdmpFJMv1b1eSoKJWHiwWN Qy9gzkmvA9siPUMmfcRAEvZHeju4k8nFNukvHqpazZGJz/zQo8w57Q7ic2TiA1X2Kfd2cCcXE038 fJrcVossqdP8mlyo6QJZ6qNI2xkHDmVaPwDfH7IimSEzXEiPUSepOxgukBkeCC8O98dwO7izs4sP hJwltbpPHsjZ5OMFuVjc3hZlTT4UM0W+jhIyU1fJIqtJWSxqVZKroiT8bDIh7yZ3AS6uHJANpZM0 HQySyAySge5gYVDzg6wTPnSIXECnKstAH0tyU1R1RdLcsOrrGNsi0sALpHPmHfQPkOkvoH+wPwWx gzMqQc5Ursoka5ejj8ksLcAwlnfpFNslYOB2icA5+w4ehMg84JFDB/rhgR3c+8sTgPi+gMXoUpVz 4xws6rTIe/LGHJPuIH2ETHoW71X87eDOL7WpOy++p5kyxE/zJHtl1gD1TzK/zdQrkpB5c//2psgV uUnyWaVqZN5wKbyQOanSwZsYmzf+XtXCDu788pPmDfY6BE6xE2TyTzpfzMllmeTVPK0q0EHyKU+x mc1Y4NHISeYOZlMfmduU7lUT7eAmx+CotQvQcVIn5IOq74vy756MoGPSXbTHTgeAW0Tp/mhvBzc5 nmzQflIWdTEtMvSQtOngmHUX8ZETAjLm+xR8B7jJ2We74K/Clq+j+kbtM0yJmRdRJ3m6uIScOZCR cKhIj3GKA+h2nHIy6SNMoV7snHcX+ZHjeBmapOnelMQO7sIoiYlIwEteKoZHyCUoxqICdbjNEvDN 1I9FepdkKq9JcUWSnFzo+D9FVo8gdqFp5KEfZXSwoUsakJMGMgi0+7RnZbQD/ToCT5x0mUayobP3 NyoHkQExwsVVaFypk0BdfEJOLkgZag9zz3yyA52caz6gW0m9fyNC50y7CI6cSZAicihGP2bSDs4k ElZxLDkBc3g7B2u4FdFmyW1d3JKkrpPpjdJaBLpzfUMSZOOlM+HcSZwuHiGnHCSP/w9KYQdq7FM/ qQQaCI85AXcSHTmXILm/V8Wwg/t0fnlBdCh/p8oKNGOV8cnUtJjPF3k6TXTGrepnK47rrIOTFF3b oMjxvmTUoQb9cMQO7vP7txDwf05LhSz9AM49yUxVFXlfTEEE3paqrxwD49ILIiehu/iNnGOQlHmM vxwN7Gjb5zZqUI+DH3/UOml/gJPW+G2nKqkXpap62QJyINNJE+TYVsRiJ9Ygx3giMhvH+7IIDnCX N2mFDFDn+jh7ChDueL4PQdXqs7y2tX40KFW3appeLdeGDdzsI60gBl5MAVMvEBE8wCOxKjFCWt93 ntSsmC60U9hLam9nrDap204S9JQICIEFPM+iMI7R6Lisj9mdjuoqzdWmyK5GNQKgt9oibAFY1nns jHiW6kAYYmVkCdDOPp4ErGZpJADUigb4IqCTK8xlkMwydLVchkwEtcolrKNqOkmAHbMlvr4nQ0DL iyVDQ7Y11mHgse20bJPdwOUoMJT6axBfaj6zFFnIqM6N0t1RepYRX81baH+dRZ7EFz2qHZHAxc00 x/aKA4/Gu5OtLjbo1o5nKASCySJ8CoEXHTIXhbCj9Sab5ABW35QKO05ZLnDPmt2agWlobrMw244i cvpXBKFncVf78hOt0K7LYnFbYedMmrIAx/y63HHk5K2Q0TNkYhsN5JSmEPE+mW2F9ntSpVOIB/tZ ROwT7CIzclZSgOXZhdttnk6b7IjL5X9txNuBWewxBtJJtffcYSk4cpJJcGoXni352UYFK//RLuNW VN7lpNYBpzEnr8h3I2i3Sak946smA5GUemupmpbpdzXzurDGSpdwRnXe+BHrX3JwTMbx3vU4YeRP AjD/S7TQhHFghAYc7bmRorCRIUmy4eBiONBNgd8IFoha84xp4KEHU914Chq5eBwJLsXqGT1JGPcR mpm13IDHm1zeI7y2YQ3ek8YGXjvWU4hrK2ijGM9aQTl2xocxjduLT2NgZ3wo38H0cWx3whdWYvS1 xNjBvZuYMyAlcplA6+DbgdYP/Tj4Dop2MRbZg+Gx9PgO8oXswfAo0Kb0OasQ0lrjgLix2OiahZXU 1Q/IqCx3H56g8rIVpFRZUqvZsyLlFSyhfZhVtgs5S6OPzYQu2jZr9s/WaoyCH5coueO0JU2et8og +5Q8hKXv5ZXFHHnvl0MHu/71Yt8d4Mxeb4pucJsYwjXFrsN2yO42h88dGC6Qtxq59PdtcO0QNwwu GNsseVBlc5JDm9y0qhaqZ7MhpF6SXTTpYg3y9isXdCcJQfZ/OWc6z/ZiNJD9X874TtRAdoA5FTtR A9td86UnXu41CmR3jcWBt43Fv4tSn7vKXxFVkyTz2mqtk39uU70v86G4U/PvoNvhK8J8ysnGz5dJ cq1I8K2Xck87yp2EQ17uwd2Cz5ejgbzcszCyEONdXqsyV8j7QMt9djvIg14q+eywjsvkqm4krdkv LEwBch8nAuwIYEcPTYGMHZapWlyr1ameqtp58mBUsB9Ve87st2RcIjtaLIh3UTWJ7GixwN+FGMg+ BZPURgwGNrqvxL3JqTjgdk4f2Zdhgnny5WcyJLIvwzi3UqOnKMsB7rTQ3nVVL3PopbqCJbkulrkO MIzmfRsf9QmdUunyo4r0U4i0PEntokoXc5A9PMaEVUb6Yo4d3JePp0eB4OIb9rZpk3p3TbKL1shu LKPSkzu8VwXbjfUDfcJ42ypSsIutN7Q6YUv+UqU5Z458iLNdx+3IdNIE2UM1p65fvskpkT1U/WYm GzV60kYHOH1o8SdyQL6OmgNTJK3IsgJVzfRhU63GTAQ+thrziOtaFBd1OpgUILtYNIytstIXk+zg TDXyqv63l2IjB2RTawzAEzJP8llSF+WDWVTbfWmwIm/XTzWS+aJCXkWXTreLF10igezu0tDfq97a wU2LHCK7OXblWZNIfgLz10rzkNb0nfF51r5RO2nASnLQB29ZPxj5ePWyyy1RBzO1X3qtX3tlwhTw T83JkzX/dOU1vSKLXJ8cQra6zdvgXLLt3llaUu1ZO0sBcshHA7pX42wHt7LLWQa2sUhzvV9ZLMBE AlvL+7RSerk0OwBtkIG9ZDZVOi5ydNlH5EiUgmSEne+KAGDQ6U9CvvhNBSn8+wYtZEYGQggNUkDU xGNdRCMYN9X8Ta1MU0TTNcZal7ZcJ9oaY7tirTkfcb8ce4WML72oQaZtEDqmE0J6PgzrQ4Snq/gC T7QXU1ASYAlbNWS6AcL01eMy4FrdlkOtrgwk07tp0LXHcdN72RDqt3G0Y/HIoyFpQTVXU42nwaW5 zvR1g2nTsKKxGWp1ZSBNhxuzht43wPhWp380g0XS3IfHdCrED4iuEnsqKWtS9iTR8KzOjZgxEhh2 rLkDIvSkLqny9Xw25exoHI+K8QH1R/O5GsMHxPSUgvgd8NGXcTj66+2YihEfH8jRN7j81ziwiOYL MBQWDCU4LGHkwvCP8YEAFMXoniTfx9J8XdS6kVTj5s5cI64ANWgORjcpIJpf6xn8Eqr8J8S0loK9 8anPfBqcHgbwNTw+FPoj8Kn0Dw/4Gx/WUJ/Gbw8P9G351qf05DBaNkMnqVsfOzU3aezrFvMMjKif YVHbi8sT3wdR0YP/fMBmlBa4fTTqn+oJtM+DTDz2p/5h069p9tnpIYXePgTgMdw+gsfhk58y8wyy fLREB19DbmdOr8aR4X1SayFdlCDQ+lLLBmm/6D/9PTdyk8JVkmlJ1n0b6S9BZkgjPgoayRRu6x4Z PKv/FvAUM9+SUt+/2XbdflULhNlsdsyyMlgaBM3MUtAE8wUbjZbYfqBH2arYKY29EKM7gK/pONPU 2iw4QsAipPrN11YsyIF+917EyeXUetrml0EHxhrZCYBvUcJIr7B2cG/W7QUoY7huEpZ6DXofrLT0 scvSmKxsCpen2LopaSO1z6JW60/9D1G799sNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNiAwIG9iag0K PDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIg NyAwIFIvRjQgMTQgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUld ID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45Ml0gL0NvbnRlbnRzIDI3IDAgUi9Hcm91cDw8 L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBh cmVudHMgNj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDQxMjc+Pg0Kc3RyZWFtDQp4nMUd2XLcNvJdVfoHvK0mJTMECV7ZVLYcK3Gcrbi0lrx5sP1AzWAk rjnkhORY1t9vN0BScwCiJDcZuyyZGBLd7PsAMOz7c/bjj9//8erNGXN/+on9fPaKuU4iEnZ9fCS8 wHETFkeO6wnGheuEgoVhDJesksdHy++Oj9gvf7xibGsW3s7y1/GR7/hh97SIPMePtp/+8ztWHB/9 fHl89P2vnEVO4rHL5fERZy785SxInEAAuIQ7ScIuV8dHLuLkstfHRx9OPMdzGHsrs+ubq7JiZ1k9 L7/I6o5lBfNfn5/DR81tWX2uZ5/Y5e/HR78AmP8cH30rUl4gnMiKFNsFdkAaj5g0sQecejIWPjEW kW+kBWO0pAcwsWcF95LNZZ5v8rRiN2XdsNUGftSb9bqsGvaWWAh46ISBDZNOJC/KPJtnTdpkZcHS YtELKy0yPmARWZEZkgVBLAuhcJJoOlkwg3u5AEvQZLVcyQIkQdZ1ei2JDQGPYicItzGATxzX9eG+ 7nd1bRp9Z2LMN6MTw+P8+eh8ePfrKxGH/NMuWpZJunf3nDgEXJ2Qh3CDF0cggZ1f+GYl80KHxzYW g+2/KFeSLTdVcyMrVpSNrBko2k15y2Ckliyt5B6R1QQB4AGgWuRdJ4gARycJPDLMO10IQnxgH/N0 vc4zuaBlfwIvgxwxgxwyAgGxEQCJcMPpjIAZHMQBIAdsnYIlmCu/0NytJSuXYIshSGhktUznks3h 6kqyTS2Xm/wUxUeC8fiB2EaHiZUqA7wJiXnjx8+RkKjFAu1B7AftT20LgAtgeEBb45jxxHF9j8FP EdsjxJj4nbzkUfJ2gEdChEcniGY83hRDeHCXCJE4dri7g8jTvMDr83cXp+z9H5cXKmD55fziMe6g g+q7ThSxOHAiuHIdPxYPJAlUWUIvf898ZcwV9l7yXqKTXqL3vdvhC1HF9hxtuV2oh0SJKrjnCbh1 z4ZG0SZXp6xGL2xIw7qoaxBhqghUuJ6KgMwIg5kfQoTKCwrMDqyU2w9JHC7YrU08mcd+ZzDl/xhI pcDplFR6bKXFNMEBQJOz/Pjo4vhIy26kBjnv7sIBsNZ7t/iBw7fngWuvvwdkMOLbwFAo92HBWLIN Sl9vQeoGHL41xxacnXhMOxAdjw34D07tFD3X6BTHCljM4DAKKQo5R8XRdYw5ZDEp/k5rWUPEe2ie WZ4Vn2uADbnOVQ4xLy3CvU6Z6TOkURExmzifNK40g1uXEDwSR+9gasHHWAC+IM4UkaexDVhTEkMD MAmf6tXQ8oYPMk4pzD/ZjSzm8lQlCDtlo39gDpnfsaJzaKXKIoizAeB3YEVzUKuoo2eQBzDgk2mV GVzPBeQPy2rFmoVcppu8YVW5gXQNhtIGP0rzSqaLO/a5KG+RPfDx9Q0xi2IfAj4rbYZYRJVYtCwK En9Kw2cB905zoQ/xwCFd7ukPcZlVuI4Ibeg0IAe36V0NEaiqs9ZsCfqqRaVmt6Dho/hCGy+GKv+u PYPWkXYQg6X0mY91vMEM2iNusgSxeJQROESEKu3pZM+MyI6hvi/eZIPphUecD1nwk0UK4ddiCBmq XMeDVBtkxca1ITSoMh0PYvkwtqHx8SStwYTX8yq7kguMZ/si8ym7kHPsiwxhShXod8r7KIIpjYyF 1shQpy4R9liC2EPd79ObSL89+Ij+LhxIIFoO9u+CQR5szwUD8CbtXcjQeAuguk72ACquJ1sAu4Ed gFuDGmA31zbAQ0oTx+pBpDrHk7ksM7jQ8Z3o48yhjqAjzNptrzgk08TxWxCGiM2T0aCOUYII2zWT MdwMDgKSSnd+ilKHknl6B0FLulhAjlxTNwE7O3yPzN/aBOzs8XPR0cmOwdE+pgrc0wLLPdwDxUuw ahoKl5N11nxcfeHZmK8D0kpCHAi5nb31Byje15k8QYZdpwkiNilkK4JYqynzTbcogNgyhQLTFgsG g+tCqNoQHSH8ZFKTYAZXyK/U5RrdbLXAI65ptLUhC7Cbcg0hFmjpKivahSbK9jWskMRVi864mBFZ yAWo35vlYUmF1U2W59TpOdzpWwVsSM6pkyffNarbaHJuBJc2jVytm/2MiKimtgX0aT6lKdmiZI9x IB0kL8Zo1lNLTKgXlXAROJ5nIyHKrsFMS+faOVXVhcOi1CnLmodcjX6ZEVeZBB436QAufyOWvli9 hAXeoM4RL30MuOd4/nQ6ZwanWjYLWdVNWS50fRJF5PXri7ffn7/+k63SO2WM5ReJ3r6+lVqGWiEb ZSGgjTJDDCJeFRq4/qTO3wxuS4vfmtZlYlftZbHQDMqWqMyLUta6MzDOes2uFGGhzxCbiBdsikRM qUcWcC9HMVUWYDuLQ7MaNDjPPsv8joGrmpeF6rgi+y/T6lrqhhGxooIJ9WMbesTxo4/LKK202MmO R4nRbAI2JOfEaxJFDI5/ui6XBVy51jG6am/tFiqIg3VXPWBBg1jEPKyHeTZg4xZgUNV3yP33FmBw FfbzsWnrL8R6iGH1NyDVJ3PEaIFiiuj5aB3qjKUs1UkIuFuWJE4SC/KswkcYvk0BiKvPbWvaZtDs uYgmgSkVObS+xAusRBQ63tObpj5xU0KEkTNhrGOEtt8y39+p1EWp74tKpvOb9CrLs+aOncnG1DGj klwzYYbYQ9zJEEFslJKx+GMG9/Hk7fuzjzN00vVazrNltte8xG2HZSPv073xIkQzhiNFiGZgE0SI FrYPSR9xA0uIZErjYIQG6UedLWSlc1OWXpVfIEjM65LhriGVoajE9P1Zu/gG/seaKru+hmiSuJeA e1YsNBnaU0jcRxDCndQumMH1lvnlfgKpGDR9FtlqjxlbahuBPQ9u5cSQQBAX3IXPp1RVI7Qdu8im S+xC7FlacKLO67CgGD3m/anTOl8EDk+2IP+tWZ0PVjARz8bGmNWZp+je20uwS4FLAf3DHshOTK/v HLG/IDx4LviWvPGxmVoPUNmYkDtxMkIDCCKr3bc6XEFA3EALXBu4h5I1oAKPHrcdRhD3VgT3pzSv Rmh7LeSbcpMvtKO9kmxdyTVY2IXqyaXd8vCPJ+ME4Ub8Mkc6p32j5+NsHHdrZsSQtyXu5AhXGIV3 LHkwg8uKrMnSBpiuo9/f9EZt1X/dLuL34gBxmJIdDJG1/IzDIwt1hphE3MfxkwCcxWRMsoBDjrAm /QwqmuP6bAyJrLvW8AgHKdnL9VoWi+wre4nqPEqMbCPOEI+IexB+HKJBmYxHZnCrEmLTRVbPN3WN MWsbnhxqDXHdso0mbUQY4gVxRdKPIkc8fUujIK5I+vDAlCJhBvemMCnp/R5vbWLVtu6FrLOKeJep j/0jG264qxWEErz9BgxKWtyNYyEsfBgSB+IKqGqKTLcR2QIOkroM09k0Z2tZZeUim7M6u4brrLje XWRrWO03nqu1UWeIScSFQj9wJ9VZM7ismOebBWgEW8n5TVpk9Qqr1BvwplW76H1dlU05L/MaFQgu vmRw/3ZXYZRtrTbyDHApIC4a+oJPqkpmcPOyWGbVqq3n4qZEBkaVOMHUp3FZMKDeYq3PGbMAu03v 2JvzVvx2+lftMUstPchr1bonauP5kOgRlyd938PW9pPRIE7jfc9/FjWI00efi2dRgzpBcgNHHOZp /y6rm7KQxSmTuKEYvJv6Q70tI1FBhhkFamD6+CILsF++rrNK1uxt+UWurkBLo1Pmudxne38+nKfX kkWfaHFr1z4+jhCHIkGcj3lJ6DwDC+JMxIPng8O16G9w7xWE4KPsJrHAHOekEQuwsypdNlrY3px/ CVUtD/+pw3tfdTHlbxBT1tuC+Qe4GBTYUQTTguqgSBBnhWrN0tOxIE5GsNX0HGIQh9te6JqIMVIc Z4b28aSW0rB9HabxHf5xppOiuo9vunivrVrn+kzSUcJtC3kGmBQSR9tewI2yMhaXzOBwERW2I1VZ a4k1LOpWToKrpSzQqa2n3stpAVbJXBXD+2P2IPdbYf6tzwqjXkLK8axcG5OHZI04vPaE5wRP33cf EofXnu9PKvJmcOgf2eWrc5at1rlakaK3gbYdM1PWv2OkQG5GqdXYqDPEJOLkw/OEUVbGYpIZHFbJ VmlRQLgtv67zNCts56Foh0Ktvqq+aiPFEEeI8zCPB07w9HQwpI79XXVI52SCYQaHS/huQT/rNZ5o hodQo996f3bef4tFV4Rn6xLsOktRo69A0UfolYWJlSpDzCFOidSZOdMt+LOA07YzK67t1hN3D9aa X00t86XuRKe6ZzHKSm0baYY4RJyh8DieUn0s4DrvVm/mNzt8OVXrZbN5G4dXm6JAPmKrs1x3KjZO p0IF5TbyDHGJOIPjUTKpHpnBdVxSvaLt0ONWLZUEw1ZnoDF4fESxdVz/qS6XK+WiXl7YcslCniEu ESe4PHIn1SUzOPA9ej1VU6VFjXtRUGPO3l7oJh/8B2DAeAE+qg0u9dcmLHDVa8qu0pqaTW1Rxkaf ATZFxCkuD/mkymQGp864fMAdXWSrjHjdhlAbzSz4gKLmdzuqqmWC3P1BdGLjwJAgEOefPFCHo08m CGZwvZqyd5fnWkffYR7YNX3ZUsrFVTr/PJW2tomfjToHwOCh3xn7oA5iUT8+wQhbsCMhBIIMfd4e YCg833Gj7oR4fYDh0Bw7j+Da5UR9Vdr+HPzgNFb9vRW37dw9Mq6P3/iFyHQDHu70Bd1w8Zhg7ngR XIWO6C7mx0cByKvXD+Q44DlBf3sQ+up7AtRM/YWCox7WA5hH+/rhdkDg8f3dVH6gDl1rIemrOWKp UNHXOV5rRPVAT2E1VX+lIM2P994Znr4BtncLj//Sk8WBQjyK1QFBbshwcfy2nOxo4Fbp5VEPayED FBQzdnyCANcdqG8diA99wqtZclLOXnD3ZLWSM/hVNDPOQfhe+CcfZtHJf1/OuDgRsxfBySe4/GEW GgTzCRgKA4aBfs6C4Rlg5wGO4kQC8Bp+s2wWnDSzF4DKClFOP8NL4Iesbu8qavihRtRt+DA51j1d jSf95wAyg3+IkUY1zQEfHIYMdRbrwdsS3qQCun6GEfVqKWIO5mYOA4j2Cimv3lK9FzwFN92k7cxg onAa9dFoL8hVTHGwKFJRftESnOGPtAKk9Yu3SOGraRYolDUh9HUJH3Xsgoy+pU3evlR8wvBZ/HAJ F/CWiZqsmr3Qowucxh+Xs65Ag3Gw1qsGnjH/9cw/OQe5w38PcfRf5NglodIWM3Z7xDB6962KYfdl Kg94lSAOccPMvVdpj93e9ioPTrPz1AqPveR63t1p7uF1N/YDEM3yznMEkIIAc7S5bi/uPUc7cO85 2oHWFbRT9Ve8Nf79ACShW54jiBP02d1UiYtfb9RB0le952iv7z1HO9C/hJqqv0JA8+O9d7Y6Dvzc TTpZgfgijm2OQxw4jocfHnQceHhyfFgFfZzjCB7lOB6D4QOOw4LhFT24EM/CtoBDpUdztLlGEtwc LkP4Vuie6g9YoNPT1hNK2s3gNuuZ59pt27OBQnwlrEAttu3/EMmpaA0KZW5kc3RyZWFtDQplbmRv YmoNCjI4IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8 PC9GMSA1IDAgUi9GMiA3IDAgUi9GMyA5IDAgUi9GNCAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAv Q29udGVudHMgMjkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZp Y2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA3Pj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzY1MD4+DQpzdHJlYW0NCnicxRxdU9tI8p0q/4d5xFeg aDQz+rhKsUUgybJbm+ISbvOQ5EHYA9bFlhxJJuF+/XWPJGNjDcKmrSMVbA0adU9/d0+P2KtL9vr1 q7/OLs6Ze3LC3pyfMdeJZMRuBwfSU44bsTBwXE8yLl3Hl8z3Q7hkuR4c3PxjcMDe/nXG2MpTeP2U H4MD4Qi/mS0DzxHB6uzP/2Dp4ODN1eDg1TvOAify2NXN4IAzF/5xpiJHSQAXcSeK2NVscOAiTi57 Pzj4csgYG35jV38MDt7CA/41OHgpuEA4oWcFd5PlrJxoeFA8msTXyTQp79koS2+SfBaXSZY6jF3c sDhlH6/OLtk8Hn3XJUsKmDDSyZ0e0yIrQuF4oZU268A2OOQRcyj0QGD641A7uJ9JOWGxofccGQLf 5llesutpNvrOknScjIBR6S0rspmuGVSwSXyn2W2WamL+AK6BslKmgz+CmD+ATJ8a1A6unOTZ4nZy hGqUVvSnBc99aXTCAr5gcV7rL0oBKvNc67zSW7i6r2TB3ECvrnCnsDKiQxwksTgAnaKgP3FoB9fQ /2iF9vG0yBoGGAalOrmdXGe5Q4uZF3mAmpUQHexQxOxQPk7YFgufGAsJ8/3+hKId3Gc0Df8+v0TH uShACIzbzeO0QFOOavvp4vII4MB1WuiClRmOwMCPhS7KgtqIh44SVtJ0MCggZpAIW8VkXwxqB1dM ssV0zK51xZ64MGq6GgfBQFwu3Wuh0xKZ1Gg72mBiJkWBo3wreTqYFBIzyYt61aJ2cEsfl5QONWTM AWRgg2z010iEnk4X0zhnk6wwYXA8MupbC0yh8zsQhiIZa9RfWhSlCxO4lRcdEhFRS4Tbq9q2g0uz sT5iacaKxWiyrq7Am1ud6jyeTu9ZfBcn0/h6qkFufs9+6jv0z7FhIrXWggfmVup08Ii7xEzivFe1 bQc3i+8hTSl1Ps8hdaySTcgd5yXLILE0fu707M/G16Eqbdjd/TDJQp0uJlHXAUCtOe+PSe3gjCPL 9V2SLQpQGOPfmnAEHV3Fp4sPf19cvV2yahITM0Yox/dtKBarIfR+nK2FFV0SQVx3UJHoU20t4EwS SQsQqOwLbxUg/MVxXVDI5Wd+2zb6sY0RBlsFOET4TNeJQrhfBYCfE6mnCnnEdQgVykZsXrSeZikh dyJRLwV8vQyfWApxDq0CUxjdfimfTfyclGwWf8c4qDYbM7Ajy+B5LYBKdfkzy78z9A7XZsYYA6mP p8UjqrTjscTXQ7YLBcsO4AYvDKJoSa41AanubBMQKtr5vsPlDrTDcOSeSQhHFrlJ/QpTNEhytMAw NoKEELziBJ0o0DglNgN11WBn9JGtxOYYPHPo746ReH95yYq5HhGjpaQTvIBQv20j2L5ErLwoqmzB umC/fCURZjs7r+QpQ1wh/jxDTFxyUmAGeLi9/yauOSkZNmRdRQMehkXZyzuffSrjUk91UbDT8Tg3 n4syM2Hv7SI3cS+xjmPJx4pZJ4GIaz5KRDvxibiqoYTbSo19xVnt4P5PAoGbCr6VBNTAIrzTAgwy 9bG+SdLKt335+O5Mhr73jTj2rHcWn7fgTdEjLp8oj7dqwL5Erx3c1QRoj34yuTGbiFXZJIaYLB3H ZQZByTzOTZpuhBRGq60M9PhZOr3fS1naRpquvV/i2oninuOJ/jjUDu6BEzNdTrIxRoeNVdC4K18x prYZ+4kLHzDbLkjYCFTbpy/BCCfyIaFBLXUdEUq6aMeFsGD3dVxTyzn3IQ3eHZ9HVG1WZ+xaQz7i cBFUUoQ2GY2ZibebzG4vtTqbNj4RhwJBXPW8LNojLukpV/Rq3dvBYXV7TwUcy/q6TDRxnUxG8hlC sYkGcflHhsrxNquGniMh3H9GYIdRj9GgD1VJhHq3tyqqWrDsJBZxgUkGPsadW6NBnClKP3D6c+7t 0E4f7yYSh/gc1ypsS91Lj1I7rNpBLCt+C1jsPM9GqA0x+5gtSp2DetzpvEwKjSXDvWycPosQm5JH XByQKmxVgH2JXju4GOJ+tEyPUi7GriC0b+MIRp1lnKRVevArmS1me9mCsZGni0vEFQopoz7tQys0 SLuy1OzK3SS/gE83WbMlmlWNoJiPYSoWN4waNzeP4jTNqHdNqwTaQpku/hCXbqR0e9WidnBYuF/2 DGFLF3WVpjGr7eCPqYFF2MxpATZN0u9srMEwzJK0EsOvh4XWxnr4UkXfjtgnPSoT6pq7qVRbkAIk IKr5OqSuFdW2yCJkXbJOXCuSgu+gcYK4HiI9mKf607h2cL9DoFQsA+Y6oijQ3rFCl+x8Mccw+xzE dFReYX/lLIH79Y9FPMXSyX91nh3tR1Ys5OniUpN5YrIfClX/Nuk/504EUQt8eB7g5fi8c0NFUGdY XDzHDW7iQZViNdLQigcEMdgQ0okMVQqz5EgbMmPI8m5NRNWFDlUq08T3reg0UUPBFmnyY6EZHiMB vUF1KEbZHAawp/EhdOjCmioMrgs6Fsl6VM/BktZPWyWMeewPBk/8DwNd8RzQDtQV+MCKGgy4QaU8 ik0HB58GB5VGVYOgY7PBw0DkwFIe3wVxjlx7Fniih7vQL60CxOvoMUDkULQKsBlYA/gwWANsnrUC cJMh1BGvK3u17+3gFkVzhsUY+OfujeG+KnHo1QQeFrJ0qQtxvCsi5Yj+EhILuHg8TpDc5mwLbtrF i2nJ8ipd/Hr4/v2nD6+I9yCwLdu34XP5/vPXIVi26ZRBurO2MUJds/cjKw+6RIE4HBShj8X43kSh HVy95aQLllVOxXT43sTYq3QdYz4E45UTwu6lhwwVojDU6r1sHdpI03UOjThUFkHgyP564y3g1oqL hk0lfNMrjDLlnkVRaXNzoAEVCft7k5z8sGDl+W3U6WIS8R6NgAl9qlE7ONCGOXAjy2eYu0xxF14v 3VyVxpiCz6PTJ0se7qdJwkabLhYRZx/GBe8gKcT7O0K5O1GDeOdESL4TNYh3ToTwMC7aGg3iMrrw RBs1/szySZZqiFB0yeIpsXpwobAB1AKb1T/EMNGAcBvMt7/mYKgL9iG707NriMKCI+a5XLBHP18u 41vNwm972Vix0aNLJIgzGMHlTpJJHaq7ypGbGcMFmuxUExfl6w15C0zqAjGyO7QBO8/jm7KSNpO2 YT0c/5tE7qzxXFUBb+Xnr/jeSOx+JLMd1U6RIA7Zvch3tsdCEYelHsxX27c+KuLAy7Qi9xZ3tUN7 t8ghnspnWa6r6NekrpBOVsnkPM/u8Ajv5onf6mUs1KWGKnuxEKaLPcRBF/bqtknJvvjTDm4Z4DLg Q1omN4nOq0NEpntgdc8NN6aoGx9BUUIbasRGVbhm48ACbJqNqM9YVr18NnhNLyl1+URiWdQmW10i ThzQe77bpwVqhfa4fIl9F/SSzPH9PJEFBeroANN723JRjpey9VCoAw3OsxkodrJSQNpLJGDheZfk EedwnuK9Gtd2cCsmFd+SsIjzGGgPzMDaj2kwn07R/RlnV+5FMIXn48aJBUFqEytc3LezAFsTzb1U vGxc7xI+4szdkx7uM/UmfO3glieBlyEXePL1UuTGS1ZWa5IgoPthkoU6XUwirmt4QvRqIdrBPVWT JI618PSCZ8OjqX82b6ncgyGqw692+OSxHh7VsMBad5HUGYZ5beMK5O2OnOgE06XnnOZZQlKOF0DK ib0x5jSPK8iOozQu3aIq9jMhnuC4m/iss8mKuDrlebJX69sOrq+NBI6FKc+66C6jSlyS87gClm+P BnUZyPWRKL2JQDu4Txqs+XyO79v4xU6NacU6CPZ2xsnUbBQ+0XtBv61uo0oHc3zi6piR2P46ii3g Njtb9nImZAX6i84e1naVR+rBrnactfOJy4mY4tbiQ7KU0EcCLV2E99RSiEtvPIh248oF9r7U76+s 37hj3pJVR9pxUSS3OGJU+qEz8C6GNG8ZW23xchIemAIZ7vsEsj5t6i/ptOpx8U4ZtkoGGdHc3fg/ TW50mcx09Ra6y/NLc8RF/yLeoeGBiYF2RpN6OzEUGDvtjA6eOalOl6CwjSZxeguChZWCbAHSpuMc G/jG2c90a6Hyqx4eyMOC6lVOoeu1C1V15x5f5cR9vpsmLgMrzFRegUClVQazlz3hnbF0tmELfoaM c/MKj8e6TqUdu65kT9rxgM4zM4uaSs/KLHzicjYHHILOk70ADCb9wdgX01Vtfn2DETZmB1KadzZJ CJOlhx3IEix70z7t1R3IXc9Ym1J3MfvexjM2DzpUL3v4WT+7QQa7LSF1QGSaAYkppZTKccH3RMIc i5C+I5uLEbADOOctB6Y44BlXVQ0oXyBO9aOWVwaSmS0qlAMniKrZ9UCEL/irnyU9WDjONqDqqxHi ibjU11O8NpjWA0sam0ctrwyk0eDRqmH2BBjfSM+P6mGhMpjDB+c+vkERSK5WJWVNylZK18+aXImZ x3zDjrV8W4K7V4Csh+t5LGdnw+gwGx5z93A200P4SMsh5yB+x+LwyzA4/Pt0yOWhPzxWh9/g8p9D v0U0t8BQtGCoXFCB0ILha9cN5Al3X7s8OD+R8PFGudx/dxLAV34Ko/6Jeu0K9eaECxiKTk+OfZjk Cpe77+CWtydhfcndk2P4jpPxOfAXuJG7nsvDM7ypGYGr48DMOSFeacOL1rb0B+TrlRqkcbWRW63W oIejQp2ecFkjD39Vr80HjqiKSArWiqOB35AAiWWo5K/Nqyhzau4ysNep0zzHTDitvtd/gklmcqBO uLcJWZ1WM+SSGSc8XF3FS4gr7cQV2K7RcjYhHarDsR6GhznIcTGUh+Xw2AfZl+b/mMXwG4fZOagD P/x9eCxBO0AjLkFF7mCyz/Db+W8vEf82vBUP0ahY8H6kbU0y/T8mzXIiDQplbmRzdHJlYW0NCmVu ZG9iag0KMzAgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9u dDw8L0YxIDUgMCBSL0YyIDcgMCBSL0Y0IDE0IDAgUi9GMyA5IDAgUi9GNSAzMiAwIFIvRjYgMzcg MCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94 WyAwIDAgNTk1LjMyIDg0MS45Ml0gL0NvbnRlbnRzIDMxIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgOD4+DQpl bmRvYmoNCjMxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUzMDg+Pg0Kc3Ry ZWFtDQp4nMU9a3ObSLbfXeX/0B+tLZvQD163UqnyOJlsZjez3onvnQ/jfMCAbXZk0ACy43+/53QD enULWWp0k7Il2sA59Hk/uiHvrsn79+++Xn35SNwPH8hPH6+I60QiIg+nJ4J5jhuRMHBcJggVruML 4vshHJIqOz25/9vpCfn09YqQpbvQ9i5/nZ5wh/vd1SJgDg+Wr/79b6Q4Pfnp5vTk3c+UBE7EyM39 6QklLvynxIscTwC4iDpRRG6eTk9cxMkln09P/jhjjucQ8uWaPGdVnZcF8UkJX8n19TXJC8I/w+ev WfNSVn/Wk+/k5pfTk08A6d+nJ4fixfwIzzTgRVaBbcwOszw7IQNivRkL3mIBd3NC7rW/K7gBDbgT UuIHFD+oYE7ICDywCM0UF5afCVDQzSwZeirPEh44BcyIxyVJsul0Po0r8ljWDXJbPISZbwmznjpa zCTTF4rpSfMYN6Sez2Zl1dQoFgMoBpZQ5NR3fG5C8Zw8zeseL0AyG0ArtISWcOEC48yt0c91qCAv 8mLHdTncqvv8DU4njPxC4Jb/ISAtwnF9JS2CPCnxidQAiOX09OTb6YmSKUAWcHb7s+RA5ER8/awQ YPHle8EAZd1ZOL3eEkA53Wvw5Fi0BK8fWIbXDfbw2lstg9sgR2RZ1H3hRMGwqNuSaD24L9fP/hWa jSar7uMkI3maFU1+n4M9KWcNWBcwNTePed0eEfhWZFmapZbR5J5wAmZCsynJXUbiu2lmF2onGgZa DAgodS2zhOfjBUdjCT04mOukLIosaUgJSqoiafacJ1lN4A9wTL4gr4CqJfM6Lx7AAKDfMc2LP4FE zUuWFZuqzRaZDPMzRCbbbpkIUPMdjUx6cL0lVuQht2dfb24nJC7SNbLdnt18OieZ8+CcA7Gm8awp Z7cTKdYZ+XpjWYyjwPF84xQNUcq2i8jDowqUHtwMVGtZPdVSeq4/XpOrEkToR0PipMmfY6lW7+Ia VGqJ/lSV/TXPwFG4r8onecnNJ8c2kZh0pQyzM0QkbplILDqqOOnBSRtXZfV8Ci4j+rVFZxTtYkFB QHxmwmLVAN9lqGDr+cMD8AOwx92r5IevN6CKxxFbAymGOMJ2FMTco4qtHpwSvfPWzEnLp5ylhV9U kvi5zFNglleSzmfTPFHSDPyDBtEyjcIQvVUDthfjqAgDJYYYwlY42jEEpUdVEXpw0zKJpyROU1AT NRjWJXcHGEVaXvz6+fO3X99df/79vBNWGfbF05f41XI6piOSYXaGiGQrMu+IBE4apccjkh5clf1n 4bkuVKcuwKk7hQoGtg1ylAEYR7fq8bXMEp2nbKDFEEvYyoS0LOFF/JhyawCXL0RUCuGSRtfGvesG 1zI7BKHjcePUDFHIVlKoo1Aojim0BnCdyiTgJ5McHDD71rNNHxoQsGw9KdLYNwFbsSOWXXsmPIcZ H3OQuyznuLxAFlHeXCiwnFfxfB+zmkdjcj04DLeVdUIXsbw32KQNdx/0FqbfiunrKP6kaXKGaGQ5 qeJ5gUPD49FIDy4ti0wqoaTK4o5OIygjdNyMSNhWRiriNABbc2rPSZwkZZVKA1nKWqLtPG/kiMBI 7iGus5wg8kR4VM2gB1fPsgSkP7FMdwgLImqCKbm7brOA8zpDRp9V+XOcvC6FOH/89vOViAT9LoVi XuR/zW27Q60WMhBiiB8s56I8Hh1VC+nBKZnEbANOeRJj+NiT5Pbsf/95eTtRpKER/y4Dz4dpebcS nObWY00ZxZgmaIhOXYaIYZkHHpwBXI9Q+PAECZ3I29JVwSxnEzzu7iT0m4jYiph78msRKUqg9/09 OAoLJyC+K58zENAyydJ5lTnDuNoK5TqK6XG92cRN761sImgrkuEhd1hopOoqGif4OFEEDBjgB5yM A2GkODLsCsRyUI4Bs3cnAQh/8xwYo8HyjWCABaYiMus87I4XKcgT4QBIRENywG27xYzupOw2EbHl +3VyoEckKYsEK40pecmbRxLXdf5QbI3cwY4NoW7LgeAM6O6bUE+lvcSqD+A7hJItG9aZUgNZh9AQ 65zpoormVGBAOdAGxW2raMocxvdhTdsqWo/IZkiwiYktBYyxAlpePSYXQ2jYUrMYRXBmnJCNMAKc krQERwSt2azKkuk8lbGsLGuqDJxM0g7hbyslwYGigWfkrAE0hLsmHS7dWW8L26Gyy/fT28KW8uuE Q4+IPq+BCnHhnkqNPo2rB8y3JuVMOra5kznnBNzbeuhBbKtMw4wOobGmMgWIKqjMgDpisG/UssKE IG0/hSksK0wDIosY5XbiDKFkS3NSju3cxrlZ8wwp9xwvUkSUTh8O+KEcoL3Xh4OBGmT9WTDguS76 gatn4SALlu6FA/BABudQWE7ui1Amg9/M1pazwCIAj3iz1MEcH8KYr//8OHLTOoX4gFMTFoON1Zad buEHztvNj2fZhAgv1E7GSHkOA7jfwQh0tG97t8FzwM7yum9BVE2HObaz3cfzaUOqcm45syFcxzwl DdquW1WhGqV6byLFEEdYzoQKEen4ciyG0EK7/vz77YQ85zGZleBEWFYDSObAANl2yh2rcMwAy3bv FsUEjXekB0Nu4QZYkmiyWoJ55a9lleGyJNkGU2Ukhp/sR5w001cCok6+2C4sKFfOwMdD0mQ5jyyA 2Y6pX/Xgug7gVpdmadfCPYJ4MVxB4ZkwscyGjKGLbYBlW74YepH8WE/W+px6YAsJUwF2UZK4abKn WYNJ16c4tV2cUUl/EzcPCZXltlDB6TFNlBba7Vksl26NURRuoxUtXNt6HOMTZoA1jV+zCgwxKAtc rIYRu3xkiOBfYlUaLu/JEzhjqjbVVPH9fZ5Yb1JXvKcn+hDr2Q6vGVznHY/39OCuyqLGxQEF2NBz UmeFpAVGUJVlLeTKCwxoZGpdJSZ07EsBwzSdEbRtbRvI+qMB2Hq/r1ztOkJHRMvoBhYb4nTLXbyC 8mMqWS20rHjOq7J4AkYHo/YqU8ht6+ZdBpEi+DR1XL3abp3zBVo5wwQMkcFy56xwxV7cYDmDxCPP 4cdjBwM4mSPq152i3lkYn4eqnM/In0X5Ms3Sh0yt/c5V2WGENRiqe8mAp+01GMiQngmY1E7jLAwz UX2I+SznDXnoO/ztWXnfcsaOB4Ej3r4GxrecsuNwwT6zYTlPJCVgj9mwHGBzz91rNiyHJFzQvWbD snvKOUO1tI7GP8rqsSyy4pxkaEAd0v779GOWg09Dfi2fs6e7rCLBObh8lJO1f39cx6BRo++jLFEx 4Dw4dZb9Hc74XhS0bO+xzUIzG91ae7sUaEv5Bpi2Q00kd2gC9hFix4ZY9yfaBKwBqHVoKgNroiH2 cbbtQKrWcdUt3f+7LHUs/fsK3i5K4jgSZ5iNIVa37VO6niPe7tr6lr0LFuFuMm/FIrDsXDC43tvs WmROANr6uu3H/vSjyQrc6UsF3ZcqIsVtBO7zh3nVrzlGTrPsEGI60jdhOThZll0gGa6/HQvLHhBu gqabjJFiIgM4A298a+ImmyJ3dFxyOW/KZIVT+qb+UfIYpukZopJlB5H5ro5XRiOSDlr9WM6nKeYs 2k2/shSkGmYfW1KoSuF3ay5AfB+yIqvi6TmGr/kTnD/KwlM9qk1suyDUs4OWDkPcYNlPZx49qszq waGALu+gBMxwtbyfXi2zXbgYB8/Cuk5ZxdXyepx4nFUdpukZolIXxlCsvUaEYYkds8cySTLQARdY duSZYNi+9fYOuMCWK98RX49ImtVJld/JvQh6HTC8jiOw5X31NNJi9/fyJeuK9d1yMLld0bqZAeyH MLbWsdsyp4Gw6+178HxcKB5UOw3CAFMD3mI/Qhiknhz0+7PkgFSO62eFuJ/j8r1CLJsZ2vfCtR5h xqkjfPB3I/wYaBIObftKnO+k8TYRsdwkbEAkLshymv9F9ojIUGlJ28EQ2NCqGULZlu/AUEYCE8pD rfahLaPFIrn1rAGNaf4MSqSri9wN7iJqK9fE/cjIVUM4+GuSwRgail0apUPLiRbGxH5mIrSliDu5 0COyqG4NY2RL0badBwaMLlXDQ5M/oV8CvmlaJnMptAP4RbZi5XYJogG/xxjLgllBXqq8aTDbqRrO ZBFoCEVbWretnJi4a6PV3FVns85WIQXUwJKt4mqkNVRctSItWal2pDVR7S3gw2yiItuxMPUc73ib 2BrAZT9mWZVnRZLhDoqP5QuZluvL7g6WEbWliwED2zlT1bJuAKYMQL//Z7frdWs323WSKKC2gwW1 0NZE8yFRsx3guz5ua3E01tOD6xYtxU0TJ49y0rsmy5YuuCerXLCNS6WnWfHQPKJzPU6eboEk3di/ W25xr93VW+11uIqR/voeDvjajFCw3SATWIkDX7234YcX2eVW0Hs/TFxYnlxVh98bn7WZ7R8PTAXB 1bUhnA+ep8vszSC6anqGbbXEKAUGk0iuApN/8uCCqJsEMGrBYIAUWU4JyW1xjteibQC3UNaWLQh2 SK9AfRvP1rtogx5IJLsFncBj1pUBxXX2kZFao7TgGoCl2Swr0to2THynCt+fUvPZGqm6+0miAK9L /WKZKMoZMswT+GBPuCPufZw0pdzRLMHdG0gVpznuLf+cVfFDdt5uUD5KQnM3dlnWRDTyMEujVNFA TBpZbt/A7NIRXRkDuLqJmzm4j5atJ8WFIb4JaIrJxgo3CLiHmK2wzQ7t3mdLwMdQgy2QyEWnaBw1 2HZkG2YRvMvLNM2xuhdPsTd8OYvblRFGqSaZWHeLoIU+XtjbfLZN0CzXCGgQHdXm68F1gZrcA+HL dZ0lMps3zWK5QOuprDJyX6lGf4BWZA9lk6vSbVtBGmXlnGlyhuI6ywk6GrhHVYZ6cN+yZF7lzSu5 rOsyydvd8kZJKZgeeGjeLbflUJ/uRX7LbTkU1ERwvA2JDeB+Q3OEwvit3a41UPuXkDSvk3ldtzuD opq9AwG9xz2LFxso2g4/I+OsbECCK34h5A+5FZr89R1GSEpOhBAIzw/AncZ0oWAcSx3ty+5UunDo FiuXwD3wrVkB37gH3XizHlpD+VYxee8eFxrh5YhMNxBiWUAID3fg8GmASyCE8B3RHSRgRoBPWT8w xQHmeP3pns/l+zXUrfojCUlerQZA9ESorm4HItzMrb1VCKj7pIOkjhJEU6Kijqd4rBBVA/0M4536 AwknOV17Zrj4EUje2by/1L1CT+Id+dJpwpergZsBRwsmWX371FJ+fbfLFY8BFpIeKxG8AL/Zk+9N CzZze1eT6KycXFD37Okpm8AHhKuUAvtd8LM/JsHZ/11OqDgLJhfe2Xc4/J+Jr2HNt6AoNCh64AIF oQnFLxPqnTWTC4D8hBjGr4AIIXcTfpZN5OCFOMsnAlw6cTaFHxyN04kaLB7wUezj3E2r/v1icT3x zohEGmx6eEb4Z0D3GiYbf0iBY/KvLyWcWMED/YlnpSV8Q/TxUbDGEbQPjscQDnpnMxyrJhfdH65x Rvr7HvSUfMtTegHKy9pTvne5F32wPrGgEFGcdCDJBXrnDHjlJtE2+x4OXMjXFWqfV/KTmnYgm382 nwItUmBETzFiAr96/quAnvgFaasYoUSa1t0t4gZlKhtHnpiHVWbDUwy/+47up322iYnYq3WQumw/ VOg2VNjm+hLJWBScFOQr7btQZXv3QZTahhP3Npfhr+C04wtQLaDkwfxA/KZFSeeXHA7Pl5Z5cArA MRtt/nGL2HUnbAX46saky+8H+nozIlrgfmxl1e7NRLoXyR0suqHsbtIiscEIeuldKgx2b5/d4sGK yMc+r4UL2+66t+zCbr3NylWycC714PptenhCbv+x8FIFj5AVW+dP8BCJoFzD9mDhpbYDCy+1HWi9 zvZW3ZGCtPBSRdS1m7UDuH2cKzo3Ve1B2UJSB72Tqg4XPqo6bp+gvU0/oRLKwkdt8TD6qPh32vMK xG2Um31UsaGaBy4f9FEFvjlnMxbazUcNd/JRd0Jxi49qQPEGfdDHHKBLzy0Hl0B+eW59A/QCNoPH g3HCooZx2kaYA46JPhO8WpIIfSTppuetNx7DMFt3gw5CbYujivsibr4d571Lo8sPFz58epcupZ8+ hO9d1+WLYRjCjyv/A/UXZ8tTXAY/P38QMBx8lB9X7gevvwbP4d6lyQ3e6YG0JiCU6QLtA62YgNWX z8BkizNdE8LB+LQTHARoTbbgo98jdjx8XGwg24LPW966cyhSHq5djvRI7eLtevup1G3zA+bF2+pC 6PJvBwP3wOcIdwC++1t5DieN3O1ci5Kuy8vW/Hs+Zgi3TMH21/SMhhcEZBsbyK7gpd0O52Do4N8E kR76LgLi2xcQQZFV/58EZBB49wIhU5niLYh4OrGAKyjTIwJ20/3JP8iyab0IGmE7qx7kbnFF8Ka4 gjHfCZbCirZH/Y1hRXuV6tdFJ3v9Nh04GlFMMCzCCiwfy/0rpb9Ow6iNKfDbIqDAo0U0gUdtaNBe 3h/Juy9CCYZvdl5OeGOfcB9JtCtVWhjtUR9LtMeLYKId6CZO3qmfRQknOV17TmMwgXj7tGMQvui8 0AUT4YZgD1w+GEwwIBvfN+Ed7RRM7ITilmDCgKJMeJMYvGi2mQSuAH+VNcRnaE+VOe6qzR1vzSnu jXI3q/oWYZXvRgQfVYIacbaOgiqs7dyofTi8CF1wU692W2DoQryUpJMLRZsZpveLtAsCD0JMF+x4 boA70usR25qV359jKcXVCFqQu2blDwAu8GUcBkIgEe6xerJUbrGPAmg/blymgPzeV5y2BrgHyx+Q PtwMLbD0UC4xo0ToAZMSUhv0+Yh/wZd/2MctlLlbA24jzEWIBt0AbokLvsjqGM4Jrj2E50877VnL ciFq0Heo7mdqHMQXGSnHO/zAYiNti43jUVP7ZrM7if0U8C5VBdO+ZpM5dwP4MTQpbu9hADcdTXHr 4a0obZmcOoy+vpZDGQY4egzArWYfrWtoTBihhtY/9BhCGEm3WA9POSbLZdJK1u5l1VNKp8wIzuaT rraf99/mBXxN+3PGEj58VS/XvLK1reCiSpXeVl/1fe2KvFIqa/iCf1Is1Ctd+YCdGSg2V2Mc7jpK 229A3hA9/Rf8zQ/wDQplbmRzdHJlYW0NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1R5cGUvRm9udC9T dWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStDb3VyaWVyIzIwTmV3L0VuY29kaW5nL0lkZW50 aXR5LUgvRGVzY2VuZGFudEZvbnRzIDMzIDAgUi9Ub1VuaWNvZGUgMTIyOSAwIFI+Pg0KZW5kb2Jq DQozMyAwIG9iag0KWyAzNCAwIFJdIA0KZW5kb2JqDQozNCAwIG9iag0KPDwvQmFzZUZvbnQvQUJD REVFK0NvdXJpZXIjMjBOZXcvU3VidHlwZS9DSURGb250VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lE TWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAzNSAwIFIvRm9udERlc2NyaXB0b3Ig MzYgMCBSL1cgMTIzMSAwIFI+Pg0KZW5kb2JqDQozNSAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRp dHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjM2IDAgb2JqDQo8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDb3VyaWVyIzIwTmV3L0ZsYWdz IDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDgzMy9EZXNjZW50IC0xODgvQ2FwSGVpZ2h0IDYxMy9B dmdXaWR0aCA2MDAvTWF4V2lkdGggNzQ0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1W IDYwL0ZvbnRCQm94WyAtMTIyIC0xODggNjIzIDYxM10gL0ZvbnRGaWxlMiAxMjMwIDAgUj4+DQpl bmRvYmoNCjM3IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE RUUrV2luZ2RpbmdzL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDM4IDAgUi9U b1VuaWNvZGUgMTIzMiAwIFI+Pg0KZW5kb2JqDQozOCAwIG9iag0KWyAzOSAwIFJdIA0KZW5kb2Jq DQozOSAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK1dpbmdkaW5ncy9TdWJ0eXBlL0NJREZvbnRU eXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZv IDQwIDAgUi9Gb250RGVzY3JpcHRvciA0MSAwIFIvVyAxMjM0IDAgUj4+DQplbmRvYmoNCjQwIDAg b2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAw Pj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJD REVFK1dpbmdkaW5ncy9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTkvRGVzY2VudCAy MDUvQ2FwSGVpZ2h0IDc3MS9BdmdXaWR0aCA4OTAvTWF4V2lkdGggMTM1OS9Gb250V2VpZ2h0IDQw MC9YSGVpZ2h0IDI1MC9TdGVtViA4OS9Gb250QkJveFsgMCAyMDUgMTM1OSA3NzFdIC9Gb250Rmls ZTIgMTIzMyAwIFI+Pg0KZW5kb2JqDQo0MiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgNyAwIFIvRjQgMTQgMCBSL0YzIDkgMCBS Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAw IDAgNTk1LjMyIDg0MS45Ml0gL0NvbnRlbnRzIDQzIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgOT4+DQplbmRv YmoNCjQzIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUxNjY+Pg0Kc3RyZWFt DQp4nL1dW3PbSK5+d5X/Qz9aWzHDvvC2lfJWxk4ymT3JeuPs2YckD4xE2TqRSI8oxZN/fwB0k6Kk btOXpmYqttgiCTSABj6gL2YvL9mrVy8/nL+/YOHZGfvt4pyFQaYydn18pEQUhBlLkyAUinEVBrFi cZzCJVsWx0fTvx0fsTcfzhnrvIWbt/x5fCQDGTdPq0QEMuk+/d+/sfL46LfPx0cv33KWBJlgn6fH R5yF8D9nURZECshlPMgy9nlxfBQiTyF7d3z05YQxNvrGPv9xfPQGXvDv46PnkktkkAonueKvVVHW s6qs2axkOZPvLi9ZWazuquWPwC8jggMHzm5v09oTvvAs/FSALTyaC+mZC9CNRRYiSIcxATu5gLGL X2W+mI3Z71W9YudVOZ1dr5f5CsyCXS6rVTWu5mxaLdn7y58x+3py8fs5fPg68sulhGHoFkqfapRn 1cQqyJJHcxEZLuBtQSoj83MJL2h0EEHvmORpkKUMfkT3OJzYc5eiGB/odTh7fCSe+GhF0PKBYgpD Cfc1v1FU+62fiNPX9Q6n9sdbMkmQCHDugUjhe5kqt6RTTz1M04CHz+hhNd3pYfvCh/cl89QXHsID 6dP78rnHqnjojdEk4M8Q+k2xa1ZNz3Go8iwIoxgeEWka8nvQgS94wAUP3KOV4vOnYl7kddEnYF8x kydpACJwcHTax4avoMlTeJy72OB9bPgKEBzGJGDHJ5tbuGNszevQ2FSQROIBthb56ksGWOMZQ2dH 6O3ryFtBZ5K4z1txX0GOZ0kQC2eQ67MOXzFOhPqBp0p0Vq6W1WQ9LmpWr29vq+WKgNcKnJRGXQDI iunsr50OtWS1yyIgtWtGIXrJOxdpJtgfDDrwf+woUUGYxPQyUN2CImpm/KFi8+Ojq+MjirKka7i5 uYkaYsD38e5dsQAv2nkVXIvmVaSnCPjPhOlAGERAfxsd7SOqBtYoBTQAPSZwyTJSm9vcfEX6ljg8 Hz9Bzxfgwq8JYfdZpr94rsPkUzl+wb6vV2y2YvVNPp+z7wVbFCV2oJiAeearB2Gzjs7ADESo0FGA ocYSIL9Ta8IXVBCA6kXclUHXSXzGQebOhLb7t2W12gS12W5boNtsZRRkkoGr5KIvERC+Sw8ytTnJ bqrXl457wxY8DuLYxdGOzI/w7kiS7NIE3Qk9jg0xKtQ4HWwEszKN5i5sULLjmtpGZVxT8y5o4JG5 a7/jvksAIrOZ4mBVIDu5nbyeffn09lxKHn1js5qVxQzCz5ItPZeDVBQI7uKo+HM9W4JnKSH4mUAI VxgK88lkWdS1X2YUxk8nM73FKd/FBxE+KFP3ZhRWcvkavUHHAwaMoYskY6lX+QpCWF2zvdvgu9l8 7rk2FGdOqfQpxxdYbpTD+UFHrJ3csljks7ImYFiV819skZeTfFUtfzUDhG0rZVGsbqoJqPD36q74 WSxfeFYQpjHSKZw+HfkudcFw5vxwOrKTM4B9kf9CtLSui+lal1Er8qfb+imLYlKDKlnOxsV8vp7n nv2txCxeOkXTpyFfCZLRUJTJQ44iB7kbQHkBK4JrGBdXq9wvaY4BTrhIG+9pbIQCbiLjbx1rAVhd tUYCyPTjlWeDwGydOzXRZxCeM6koVYccsg5y4ETZ1ftLVhdL8JGNKy3qFwy/Mcq61Rn4pE3htPpi KUl9vrWUYPHNJZ4+LfnKHhstJTRxejAt2cl1xodRQgFu06gFGjEoNk6U4RgnrwuPoH+drTxjR+NY XaLpm1L0lds2GopjTPMPpiE7uUl1V9arZZEvAMGXvv1qGKjERfl0GCduJ9Ya2XxW/qi9z5dDPho5 FdpnV55rBhFWKtLHs+F54j5SqU0aIshwGnurQtqU2DwbhK5xO/jwbeumruug1it8z8WKSGZPsgHP 6XEkw4O6ODs5wIvL1ay8ZtNltbBPyT1/4k0SQrMz4NvT6Vk+BzEeOkYXRNS7vEakBAEZP3geATKV OOnt0nmf6XlO/iPBrSNgKNOzk6tuUe45JJNFvsLcwGAemhyuf9WrYsHy5fhmtirG9H2LT3UJZxj8 4xBNn4Y8p/4RF4GQh9OQndx+irCo4AIaprPSFDIHcRkCleFky7PLEDgj76IFHmOpq7i1nh9CC30Z q2HSI4fW+4zPd1UjlAd1D3Zy7ztJal7Xs2u0uGEi04aBx00mov0/ZL6wpaOCjNNaHCl2lhT4AnRP 7cqqGgbyPZWfXbk23QPv3C4gE2nSmW99Psc0iemwxp1kfBh3ZycNiT943jYyYpLGFut6NUwdzTH2 3dPGWie2xQ77jspztU1l6pBR0kEuv75e6urN3Wx1Q4qqb3Cmb9nWdSas483MBNRWaWeQcOIST184 8VxtUylNkR5MS3ZyoJL1fMJmi9t5gUs+SE8mC3jz13i+nhTsX4RICdZspQmetQNyUYlTLH0rxD1X 2lQS42KSg2nHTu5iuwodx6H8xr6e1IVG/bGKsm8v2BUkAnhLBHgNlTRdL3EOahj1OOTSpx7PBSsV J8EBPZyV2mRWj9c1bq/5OvJcHeQSdzO5etkna89VORWlT1K55/qUUplFGCLgIUSOT9UaA4tnLYg4 4JmDMAatYlmUuJgTp48WFaTi9W0xnk1nY7ZEfjxPRQgMX6mDnV5teC7TKRU+ySg8l2yU5If0A1Zq e6iFWYPqRTHN1/NVY6qX2/YzyIonh3T6dOS5aKMEPBcdTkl2ch9gfPqlh5kBwkk7Pc/VGFwAD9mx g9hV43fIuGrWbvz0LGKB21e6TDw2m3ZyZn9RQ08FYcpiHqTZ7p4DP1Uuh1iBXzNaX09+FsvVrKbh PEiG6Rol7gxTiTDgyWZhskrdKabyXAtTXB7S71qpLYq6zq/B2hEKK55xUwDHlQCUsdRsMciq1g07 jzP/3dUjDptviHCcmwZxD1HUiVSQqCd3ZMeRtm+LcJVgs83J6yjF5CNzWZ1nJettBHZa20v9tqK+ 74UnpljxkC5veQVtNw8qPCnfhadQ2SO9X9HE4OxwC5qD2jAuyE6M5j7yeV2xm/xngROlMzN7Nysh bkxzhHc4i3ozG9/oatespvVNnjNGGdFum4fJZN8QPNe2ZBYF8vHIM/JcxJFpjHt9H82G52KFTJJA PX5te+Q5j5fwwFOk4TmPp0LSvjT+WS1vqrIoX7ACRxSEcv3fm79uaZbxY/WzWHwHKJa8YCLkkm3/ 9+USoADj4bdBEikHz72i85x0yyh8kgY9J91ScZs03qPHKwvP8NgkPg6avpfJ6MMBHMQulvl0pc2N PDnVWuEfzT+dN1gANxfWXdP8kP8iix3GMu2s9pqE5xxfSoHV4Uez4TktkUI+SRqecZDkyiYN3JsB fu1jMbu++Y6TKbN6DF4Nd/WUky52uPGMaDV6dnCFBaut3SqDHPzjIN6rGd/AJIwC9Xh8FDfAZH/H r8RSPRZnFXoOBd6K9+Lu2DPAEFkcPKDAts+HL4RhQLKdD9p5/fGq2XaxvTMK0PC8yJe0bAqXWvZx 7AuMCNzSlnQ4fmQla/9cGXsy35Ah62iXuODZDffZhy/cIHHxhkMtFLX6xO0LObSjxMYJLd2Y5792 pyz32fEVtcyqRse42dmXLiUPYEyTDgXuJccGo1QINmbHOfVQN0bmLmqQEKeB1PZdpnHzLmyIpeXM DGM5D0rn48TppRpHkUYoNn0uwfZZBiZImDskiFfuHnewT9Bz3BQpHfPxBEfmK0w0jszOCK62y8Fa r3vYSbydfqUPUHCw09nva9kV1cejrxjUGo5dZHoqrI8ZX4FIYDFduJihQs32rBwC+T7mfMUcA9ld Vm4/DoMGZPc4DGwAJLV90AU2Rt3jMEQGSDjdvQsao7T7LmiI27tQk4nqUMSGWO1QxMYo6lBsGrYo dho1xeZd2xRBXXHWpQgNSbZLEZWadimahm2Km0ZD0byrS3FfuZ5TdFqzeLCJETs125yVWcRV61Vc gMa2j7+h1UQ8jL+1G60GyVYd0ukbgJ7rFyLOHhRmfCnJTg6QL52lwdoNH55rGdhb6aK+P32hd0ET GMeNT6st1D7Ith+XHvrMwXPtQsThIYeslVq7F11nQSj8DSpmLe5g47zEAwTGayyF1tWiYHc3hV4F /eHzMEPWLp0+HXku7IiIH3TI2snhAEFRf37DclztVdzmS1rGvK5ROfrkj1Uxvilnf671zpiSXUKa 1U4G+Z710WsHXNLpU5Jv+K4gq3n8JvnEc41HQPJySFuxk3OuCtOzhVVpDn788Pk/JgLgGe3Y8snz NgqzctfBJ0KFQbYMutTQYw2p5zlAIZTVKIeyBju5bSy2WcGt0ph3VnCrIA7U11HQ3ezpuxwb4ZpW l1T6lOO7cMkB0luqwkMpx05uazftut6sn/tZsNW6LAsKvTM6XYTd5uMfBVbM4V7zpxSGGT4O0fRp yPOksQhjPHn3YBqyk/tezKu7nb1eOhgDisZDlQC20okxRjvTZX6NI62pMdcQjT2H3gYeOeTTpybP k+p0QPLhtqs4yEHMWxaQWRS6HvXu3dXHl5fv/ksaul1Wt1WNR/lgxMM97b5Xx1Plx8HZXjDGhTuD YDGXJvoMwnMdAk8eP+C4dZBb5T8KfYxhZ3Zz41Jx8vMGRy7g44rl43G1Lle+ITJu4oid8uhTi+fS A0+yJ1mH55SXJ+GTpOE5q+Mxt0lDBrjAAkHRejlbeT5yzWytcpDulYDnlIlHIkh6dzsCMXjoD8a+ 0Dkp9OMbtLAJO1J4xDGedAytWPVUQuKEkjmBWlc9+16x9UhTQ4733qHX9N6ZN7WUQ2XOa24bJJZ+ FSBNXLWPU11wAcDWfB4fH0UgfdFcz/FaYNFWX0expMP+9WvaK6JCz+oGSDZ18bdtQFfEmlfpU7sb QvpqjDwSI/p6jteaS93QCpNe1V4RpfHxTo/h6RvQcDMx9qd+WRrR96GkyZswhrjQTqJpm9iyp07u +7CntUUBE6SMLUSCh+RHdDJ2sg8cz0fZSTU65eHJYlGM4Fe5GnEOlnYqT76MkpP/fT3i6oSPTqOT EH98g7a/j2KLKT6GT2XhMwLIlKQuPt+PeHSyGp0C5TGQr0bqZD0HXibs+yg6KQbhqJGc/YDo78Uo PSnxxxT+zYCh8ehUf8jnyA9xi4yyGn7QFYCLU8MtXd/kI56ZbmEHP41OM/p6/yjlZ4uX0xIXR2f2 F8w9n14SSOfh4zxkKCgwtlN1sgQ9opwma1AlahclgDIbUKXctk3xEgbDBQwGcfJixKXWGykQG/nJ 78jsOQ4SvPEnMBtTL+pGx3jvAr/f31LmY3QoF983FUjwDliITta38OMWRnRCYiXTQnFOWI7ynsC3 w0mVW0s72tJptACLhicw/A53+6PhagRa+J/Xr1uRg6SjjaTpJpT93PxjGyqsgjtLdA6/BnULIbzG sv1I6z823a7IR03Rp6J1oE4A9KKxL0dZa+g1eWCW1+Yae3aNrqJcoBzwNj1U9lHwsw0LgE8au3qz Iz0b9sk6lbnmz83cg0hEmuEU8waSmKUlXUhy72u2ntqgkt3XtPQSmlbf4BCBRxWIBoeIJMI8QMd/ c7FBIqZhA0VMg8EW5lXtFVHaYBHMPUPewSI45yyjBouYNTwNKX3VYhFzvcEizVJC0wv9qvaKKI2P d3rtxCLIOURZYy4QGlLolR2LZHwPi/Q83YtFBG7AeA4U4Q+CIg9i8x4oYmfzDt2LwR6zxp0xGvb5 DzOmyUfRqK1NOPPPZCNL69z5BnuU+SYoARuX+Ikc6r/8c5SCJbs42t8H93xyktalPGTxgBdyNPTt 5LTdkndv4xQ1zZpgtYGDpBb5biQJRuA/MpdbjF2IfmZ4o8aU8AFb/uHfwnHLyMNEZ/X54nE+P84Q e/rz+ejvMuH0+Rz3maUdn88z+otlxpPi8WhZany+udj4fNOw8fmmwfhw86r2KjJeuw0CHHPEjs9P JG7HbuOHCkTr8uli4/HpsuPw6bp16PSa9oqojI93euz098g1sqsNBYJDkrpyz0zu+fuep/v9PR5n vV/OeITDFw9y+A/i8z6Hb+eTcs96G2TiUCeHmpfwxa8W72FEKK+xBxqG+ue1kWmU4kTDLq+4WovN SoT5HUTccNskVxpM3ueE8OIfoBs5hLQl/VEfRw+GoMcDJV30XqOy3iLMpk/v/ZNXkka7nfw/B6AX k6s5lHhbgwyR7D4S8U9Pr0e109senW0wLiuCat55gXvBLTt40VWE71jW6GAAPST/c4W+7jf/2uch /sE7B0fOOs8z6On1tXZ6W7k6+pUf2Hf8kNdN3U7X8zAMGFQ9mIUqYtVayBuAaEQFNwfRdZMYTNAo pAaFaK3lGLjBisZ60ghI+3Rw1aW+VxtQx12fpu7CwDPcSEhLQuz8982IZOppKOI+9UmCRY/mJHoa J/IeTkRiOU7hVRiKt2c8ehXK6LeQn4ch52/OUmgOZcjT87PkFbXE+Cs8O003l0kc8uz12amCz/Hb M/x1nuA39Gj0unkTDwW9iR59rb8NBd0fvoXXXBCN36L2beYO+h0mb89O8Z2x0t/x87NTae6hZ0J6 HN5ETXApxCt6FdKLLogOcI4cx+emZ2dDDVZOOwXsxcS8zapaB0+jmL7AwiwVlzUMo6Iay9mS0CaM K8I+OLAwSuwUemetq8Yv1yW9nWpzO/XdIVBo23OOr9nt+Q8zy6BruAguMUdkb7CT27iUJiV0L/C2 n8aPUHbahB1wGZ0Jik5c2hQIWE6l8Ptrxs/ubKjsf0vIRHDS7Uf4QeDsM6pOKTY1MwbUJYDncVuR V7ov+EU+xbu3JmcCRPI6MSdQv6njd5+Cb6c6Zpn8u5PTDyQGnsW4i3AvNKHRIvcTsmUdLzDFINVv +sFyqhM3KKctSDWzE7rk3lSnStLrABFDcNzL4+iLo6zw/xhRtigNCmVuZHN0cmVhbQ0KZW5kb2Jq DQo0NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwv RjEgNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVk aWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgNDUgMCBSL0dyb3VwPDwvVHlwZS9H cm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAx MD4+DQplbmRvYmoNCjQ1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI1NTg+ Pg0Kc3RyZWFtDQp4nL1cW2/bOBZ+D5D/cB7bQZYVSV0XgwHaJG2SbopsEmwf2jzQFmOzliUPJSXN v99D2e4kUxFCPcdy0TZ2LH/U+c6dh4Y3V/D7728uj89PIPjjD3h3cgwBy8IMZocHoYhYkEGasECE wMOAxSHEcYpPwerDg/vfDg/g9PIY4Nmn8M2n/Hl4IJmMt1eHiWAyeX7159+gPDx4d3t48OY9h4Rl Am7vDw84BPiHQ5SxKES4jLMsg9vl4UHg1hTAh8ODL68A4PUd3F4cHpziB/z38OCfwiWSpcILd35V 6yl8uX5/HMqA34GpQcF9W+ZqqctGFTBpGyirBpYKX2sq+wQrZRuo7uH86iFmtGuVScoi6RXNS7Cf CBLEBKUC9WU8gvrhrvW9tsSIPMAL0ueI+BsWBBLft/3fzvpeve7W1FTQzPXfFuX5iC1UwNIYJC4b 1x0wkSZI8NbU/vH9yIglwidBp6fwqco1XOs/W2O10+wabvS0MVUJnBNLV2QJi1Lfaipii3HyjXxg 99RgCeNeuyDG4txpjAfMOaw4lOEd3Fe2Rxm790YImYmt7gUsSnA5LIsEmeJtPQWacI+/Qs/aWtM8 0QoGtSuWwoc55CMlsY+MQ5Yl4/nIfjj73K4bYl+JyUGY+JDnqgFV1BWo1ap4AnSMU10UbaEszKu6 qYnj49a1eKQ+wH1IzH0Uuwt+dRUR8SpCvD7+aRWScQZw+r3RZe28/FyrHOPotMKn+INyrr8mJgej UJz6FjQklphYLDLdhZyEeBUi65XFvtxDP9wthoe6Xa0qzFu34eK6ahtTzuBsrRe3TyuNn/T11fVZ 8PU1zFUNE61LyPXK6qlqdE4c3TLBUu6VzwBLKTVLQa+u7I2lXjgX0qMgi+7QbpExq5EqfdSR9cKn Qj2v2iIH5SqVXN+rtsDXdOPopCYJvW3sFc8ASRkxSZgPjWlK/XD3VVFUj2sLOgtgZauprmtnSLmu p9ZMdE6dTYcRE9y3HlP+yOOlq0lRh8ApEXVdigFXRF4OBjSBB8SqgDk/Vi2/vAziBkaUyTE10gPX VXcrNV1odO5Wzbq2RacQzokvyuqxhG0i7sL/VNuyXruYH35lL27DJ54hloi7GFEa9irLvljqh+sc 97KtXQD+4UHmqswL5zvQcKsHbQtMot3TLY218/E//MpeArBPOkMkEZdRUdL1I0cjqR8OnWkXhBMh 7gC56Ym9HYWuHbjlCN/3BKU2s/mkorajVDKRemUzRBFxtRPFMePjdQM9cLmpp85UnmCJcXcvla4H Wc30S3sEU+6lfvIJeohv4royihLG0/H47of7ck6LhiYlI+FD+xcxWMp44L21E2Z0Q9yg5DxmcTzS 7XHBmV9R4qUito+tfY5zcy7t9ipKSRyNeRSyJBrr1pyFSx+Y3raMiJ1b0F0wzh0K16f3krduhdV3 1L3JMGNZ6vWbQ+6buP8VhelOUYS4ARbJbCdpEHd4Ihn0SSPEOuiympiCfJNi64j7cQdvn7h3EqGn 3oEFQVy3R1wwIcdLKfrh3m86oKvWrqoakzqsvpq5wcyumrYupT+C8ytYbtTCDQS4fN/qQj+osllX zvspmD3iGWKJuq0RyFETv364JWb5XX2F7LzcUoJHg3SVID9cXWHl1TxWdlE7mrpyGvPyyRNgVb2g LsbwndIrnCGOiJsaYRaOaUkeuEI9aYuF2BQlb+olklDCUn2rulaT4426PgpYJn2LUWjKbK0U12ir +JR6Px49uhedOIGR6LBl6gNLUdCNrfJ2qrsexV68kU/FhjSduDMUpl37ezRN74fLW1UQTzEIljop 9+MRq9NmZMIDVjdquljnQbobaoOvr05uLt1PX193G4YKpoVxzniCZpX/iI3EeoeMY3nnI3xI74jb XWESMzFec98D17Uj8eH2BI+fU/C3DKVauY6/KmATF4mZcYW3XyRDzBA3psI4YSOGvl40Zadz0+hp 01pNXEZuZvk8dzkka+IqMozSnSgnriJDLK13EAZxERmiGewiDOJiLpR8B2FI4louFN3c5S8vg7hY CbncRRjU6XgQ7iQM4lxJZhGTP0vjY2XnVanLI9BuWA9Dyfpx+n1lLNa/n1ypNcFMPjnCkp9LePn4 cqVmGji/o/VzoWsIct+aB0VHHO5lGruE+5eXQRzbZJKw8OdRm/Oy0RZL3b1khR5M6qbzeg7eA3Zi 1X2zVrcuAXVJp/vblXPH2/L/rCv/nz0u1VOnsfvRzP6lDqoEcQiWeMEumkkcgrvsfAdpEMdgGQV9 0ojQqZ2//fQWjvc438rjzLWAPEsYlARxGiBDvgshIXEeIKVwVdtY6bgH7vZ5/7YbfCqrtUKobjiO fA59vVXvu/khDoiTICnkTqpAnAVJHu4kDeosKIhY+HMyFqOLeDt183CFzmfrsxJ72cT14A+KgTij EVnMdlgFcUIj8PpovKkhD5ybdVRtM69sDY/d8HRhFhq6Y3yqXHTbQZU1M+NaKNs3biblDfVUV5x5 pTJEDnFqIdxp0/G46UWb2aotczf16PZxoCrXe3HElunGfrhnBduwUf8bPmg70SV8bM23lbb1EVxU 8xL+U7WzeamfjvYy3uchYUgViNM7EWej2mk/3Jmu52oJN1VhlqrsRjAv2rmCz6b4phYLRR7Fuw0l 370PUUCc2oo42EURiNNKEfFRFaEf7va5Q3ZnGqTk8V8J3qM7ntT1wTt/oRGwboum28pX0Gi13I+p emQzdOCPOOUWoWDReMPSHrjGHf005bRoc+ThSjcaC3Sdb+32StumMXDTVktdKLcvofLcdOcS1qfn 9/LFCT7RDDFEnJALKUc1on64TSKDee+anWe0zNWDdodBqCfgAhbGvuU01kzaxs1nVM0cjfR7s52x N7br+uxlG9tHxZBGENdGQoSj2mw/nP6OaY3R5XST+z4rmqlD63oC03fbQ9InLgkFj1j065VpRF2S BTGLxztn6oEbKoYuzBLeuaT8CN5Zg+78WNmVdh3oI7hp9AO1597EVo9shigirle5a4qPt+3vgTvR aKblDAmoJnBmytxt3nzUBv3mZdWdCr6dV0tMgj4p27jfnVqzgE+VxfBrF9R1Cq41ibySGSKIuGbl aTqmDXngLs10rnSxoeEILpWdKasb+KzqWtttEoSBDstIwESJeOtm8+UwntXNN2M8nz/AUpliX+fC fVQMaQRx6cqTbFST7YcrTN381TLC3Gq5OcFZuoNiq5Y8wK470L6bH+KAuHblSbCTKhAXrzzmo6pC P9xnvYmryn0xzsvgeqIeTA4n+lgtV+jSlcVge1qg/ygWpnMji5a4K72pjHyiGWAoJq5deSRYMt44 pwfuvEa37QSOhZGrjFybr3Zx9EKVpYZrg/+65p97clOZ0nTTE/8rVI4ZkLGT1pn1XjadffLpoen/ CZuSmA0KZW5kc3RyZWFtDQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIg MCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GNSAzMiAwIFIvRjIgNyAwIFIvRjQgMTQg MCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94 WyAwIDAgNTk1LjMyIDg0MS45Ml0gL0NvbnRlbnRzIDQ3IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTE+Pg0K ZW5kb2JqDQo0NyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MTc3Pj4NCnN0 cmVhbQ0KeJzFHWtz2zbyu2b0H/DtrBuF4QN8dTq9ae0kde/ac2vP9UOSDzAFWbxQpMqHHP372wVI SZaA0HFAnjNRTIjELve9iwVCXt+Q779//evl9RWxf/iB/HR1SWwrpjF5mE6o61t2TKLQsl1KHGpb ASVBEMElKfl0svz7dELe/HpJyNEsTjvLX9OJZ3lB9zQNXcsLj5/+8+8kn05+uptOXr91SGjFLrlb TicOseGPQ/zY8imAix0rjsndejqxESebvJtO3l8QQmYfyd0v08kbmOD36eRbwYWeFblacLcrdp+z NbltsprljCyLktQrnpYkKdZrntcVYfmCpPmmqeGTbEq+YaVZDD0PGOPoMGR1WuSkWAJaaWUYcOxa kRbwCR/O5ME1LA+RC+I5njyowS2KpEG2W2aBOk5gBYH2HXso7RmmNJDgBfymhrEIqBWH4/FbDe6t 1HeYaJtWfEG2vKz2+sbJH28vQT2dQFywpl4VZUUeiyZbkCz9xGGY5Z9MK2Vo+YGWPD1M8g0zyQ/w gdGYpAZ3xbac3K1YxkthoMEQKsyzYZV1gQTgLXUU6OFDYJgPFJ4PvhqL0DAWXvQSWkSGsXBjFS1C i5BbnjRlWu/IZZFX6YKXwnka9ppOFGHwpEGjjxixaWLYL2GJYxtGw3GUxBjKTqjB3aFh6Dw4/MIr khc1qTY8SZc7sBQ7kvNHiOGKukiKrCJgS8zi15HDdi3HEfjBN5ZtQ6S1/7d8UI3+Id5g2eQJiizL QIqfoqaeaA8QCIN0saI4gBs8uOgC+W+Wd9exTL2TYU0MI+EqX4pZyk9Mw/5VhVKFcAFPuFEI0ZIx amLM/YSaxxI8N0wgiCUCVwfsRPbFVz5AgEn8OLZiD17eDwMCdo5GX8gLDSeGfuyNaUs04DCsYBWp mkESAQ3QZDUn6ZHlSvO6LBZNwve2q+o83LbJcvBv9yloFcix4eCnDUJ1rOjzLoZTQz+iSvkdSiLU 4H4uHjmkB/PWn6QJOpJlmgGvIFu4vtkG5In5JqzkeMumwMQC4lbDLIo8ME1a2vSxyHBO6YeiojQa i9TgFulyyUt0/lVaNzL4m4sM4URdyJrtSLHhOYYASQYcIgsOl4s0fzCLMAXb6zla+vSxyXDS7QeB 5YxXZNGAg/z6cZUmqxN9geAtzZOsWYC6IM8eV6zGQbCEps0bWmFPTw3D0FwAE+ig3a1AYoWtYFlV DFLg071nn/AZLib4fmg50XjCpwbH0HzXVVfhSXiWNRkrCc+3aVnkInWoUfLW7BN+XdYszUm92wg7 b5g/QaylSh9zDFcYfBqNahnU4M7MdAF6UaHb5ZDeg6qAH82y4hHMNFiGqoFbUHMWaZU0FbjZ74bx sRra9LHIcPnF9+IXSYrh+ovv2aNKihpcIcWhah4eeFVzrMeu01q6fPLh4pYLx0I8y/kww4Ub1HUI xhJeVSg8xjUZsA19LW36WGS4KuRDHqu2tMa5FIFq2FqI/HPNc1FQX3G24GUl2VQJX2cYExeX0Tw9 JhCHN2Ar6oJc8Txl2TAhhRr6K9MRhWN5kQ6YcdmW65MjvZrniwRZDeyWl9sU0uEPF1fF7YfZMEmv Rnn6lkMNl1R9x7Vcb1QdVkNkdc2STxVY0LJoHlaHiGlVVLXpwoOL7I+0L9/HA9OlKNsbNWJVgwNX J6oLbLEoW/e1KdMtS3bk/R9vL2lMnY8iob3npMFaA7i7QZnUpRUa6vQxyXB1CN5/ZEXRQNwXiNKa VCuxSAwcgewVWCIyijYM8d7d3EBku+DZXFznvH4sStPLyLhK5WmJ08ejrjyEpfPI89tPUUwPYjEx hMYOoSAIASWRFftf6BxyDVcxaORbrrIeeMbxc1xMJbWdLKhxkT0CDLT1IReF2z60TKVze/Yo0WpN yOm6xzk6plIX13GsWIfNHDViDQaqDxtTGYzrUyvUy08fGqai9La1QINGwoA/c4xThe1GGpUFW59V Js/bhExFIG3a+zwyiYTnUbfIRlzyC4Ep/0uE4RCzehbozVpaEieWlsQj2XRyO51I8yIHwW61d+FA DFGZf3oXDLru8Vww4LndXSh8YXAEEQei4ASiENHgCGI38ATi0aCE2M11DPGcJYYDEhoGlqtcGxvM 16khHurrolRb7zZpwrJsN5eZ3eOK50/La1KWGWTlW1ZzwgYJ3XXk6VMc0xFJEFrjBiRKgDdXN9gI U0MSjsscjNxc/YYDuayNiIJaWpE1Z3klAxQRmbThiOle0zYeUZOmj0GGV6uoH71ITkzHMTR+CTEM l+UptV9EDMMFaOo5CmL8syhXRc7zOeE1mBaLtD9vPm9SiGTIb8WWr+95ScI5ZOBg1J/+vL9hD5w4 7sdBFvXUKPcSznBZmLrwnP/1aBguC1PHUxDjGsxPCRbFLP2xrQWcrhqk4YKUg7yONLCuSraspajJ BoBCdqgKQ3rZ+b6fhe87+vkVknWU1mGkUolprzgYLkFTm75EKqnhKpoX+5b39dSghuM2LwpQiEYM CTQQH9MsAztacrbY4XrINl1AMCar8rJLZY0ro+elJtlGkRtfoBZxm448fVwyHLd5YWhRZbf7YFxS Q3zIinuWkbpkySe5WgU8Qm5kXATS2BWxKYA/9xnf12XFsork2zDdYDry9HHJcPDmwQMj65Ia4r9l ilPAB+Q3oB5z5BE265F3725/e33z7s+/4UYFwxVybHrV4rTlJUY8DBQchYR/xmYHrD8axqL1NTpe 9ImE4UDaw4LKuIqrhnjPcQfRjoDXBy6ILDgp1htgB7KAJE2J3WnZDrvNsmIHowu+ZE1WE9BhiJSM b/CTiqshTx+XDCcanm+PrbhqiB8u8kIobIHbvcg9JLwcONUprewp6ezrhxm4vqd1DJKwfBh10lCo j1FdKuZgp1kM6TLklRgCWHYU9RXnqeF0xKPOc3XxHBdTOUnHfzUunzjfQDjTi42pkLhjixqb1mf3 7uwzFRk7AcU6rAabpagUZQVEHXW6xq6rnzn4tLluCbIPa1OBdLvmqJOup2hMkOIoi54oOWN9GAYg HRGaEe6ryDDoykEadnfhAA0R1ZO7YJAGx3NRYVz3FWmK1eIjiEhmegoRBj16DLEdeArxMNhCbOc6 hnhOatPRsOcikmOaazVEsLa4kGo4rZdbfTQgm7ZlHwU+lR3K+zX3RVOi/GPohxoifumC8sKwX+gc uIYVfcpnOvJ2vbHDLDVEuedXUL5iaxnutv2hHZeWnNUNVghResSaRNcdYToUbivbOuL08ch0KOzQ sbVWDZFbD9ZcNlEftmVARptXm6KsSYVuRCwfbTYc4iqMjgtg5bIs1uabrHVU6WOO6QjY9i2qKIoN yBw1xANHrm/IvikAnf1RD4vcekGSTPAH14cMM4bGeBqGBkVQ7ooP0qSr40KfMBhe8HDjwBpVFtQA jzwcX4LLq7FkkS/BVEIKVIOIpPBNcV/xUiRLuBFx2ZRY84C8yPgioWg80FCmjz+GExkXnveVfe6D MUgNEWi9A55gQ9G6yNMawpIiz3bHvWN4LtEy/Uw2rDS81OLJNocj1L5uj/W3UMrXtlm/FJ3vbfsn 54cherH/LwTSbzZ7MTooVKbNvI/Z74sxkqL9nMMQ9rIK9t07HIaAG/gDYxv4Wyei0VXTlXcs9npa U6TfwI808ILDBn73cB7EueE0vBIsKtSjNU2robXbg9CLFUuyZWVaNNVh93wl9xHg/v5khfv8r2/g O+ySufvXbZtaDNIzraFNn2szvDjrBvHYrk0NMdl3I4n9mLKLDFOCDH6R7WVPm9kH2UejQU40X1aH zYWDpPY6VvRIRGB4ndwN7JGDUSVAYPZ+555YcG5DTQhFU+wkETWZksvDvxZdA2LJyUO65aZrL20w qqZMH38MNxC4vjO2xqohIjf4MKcj6t6xj9SG654udS1/vKMsNOBaB8bSUhQZReXqfnfaT9su8eYV iD9k79c5qbCIIlvIh3FgGur0MclwKdL1vLH1QQ0RGFNKE3SfZhmeXJEkRbkQFeJCHhu5Lpq8Rv8G BosRkc2JOtiSl+aLka1X0ZCnj0uGi5GuSzWqNBiX1BCFKzFeWWzX9XRvaRgY7sLVvqA8sxiNApoB UbtLyibB2g26zPuiXj2pF4im/aFi3GfR41z4DBdbXceH7GdU4VNDlCZCFFDrI5MOLBJWHcwFRDTY FCI77MCig3kgyQp7SIRpGcZEaMjTxyXTVVA7wCPqxuSSGqJIOmSbjmTYohGHBazT6p6v2Fau+aXl QhTZUlEtvzva4TKMKmmo08ckw6VQcY7gqNuONBCzNP/UHh6xwkOBD52rCduwBFL7eXu0VLerZZDq mgY7qeA7sRc7L0wXYqXa6ljRJxGGazx4CO64aquBmHM80oWVaSb2vzPREVuIKGy9Lha410wcIgQm dYln9uGJ3fJksVrWhwwrbtvJpaNPH5sMF3qcMB5bcdUQK56JRtT5vuLGyLrJ0BEuUnB2LMO9PT8e 1qI6fq3Th5VpTZKJvY42PSwKDVdenNAeW5PUEEWBBVeFyWPaRottmZRkfMszkWmWKXaDiVS00x/g 25+rNBsmltRRp49JhssvTuCMrUdqiL838qxEyCa7s3DWhinfnm+uQQDC0jyt1hUoZp0+oHkVC/W4 lwRML4yj8TVdiQu06PQKguHikOO7Vvi8oydMCYIaojhZq+76NKpa7OvZYKd5d37hVXFLusMO29Nh VmBMMzSo5ovZUls11DkDBg/9Qsh7cXaA+PgII2RBJpRSBEkj3Ca8xv+pyLPssD1tRDY+9s1w/ES3 mz8+ncE5O9dEHpr+2M58QESi0V05eDoRpb5l40kGwjZRGli0u0imEx8k1d0PZDjgWv7+dj/wxFNy qv2VJx9tr8AzhfJRORA7CL6bCIht+6SDI68SRFIgIq8zvJZoyoHuFeRU+xcSkJLp8fvCoyvgdbdU +JecKYIpIhd3CmO51gZZEd3lB+F4onZH5b5nPSwlyyWB4MKTgAqbXvFxqjqK+nIWXxSzV459sQY7 CP/k9cxxQOJeeRfvZ+HFf36cOfTCmb3yLzz8+Ahj380ChUh+BZpUgaYPmVoY6dC8MQ7OsSW7lOBK eEsOb7mcvQou0hm9+PwP4whgkUcH/4S6SsN8VGrsjhD5gkHwqGf5zpFFaPc4HJuEL07z5Kmu8To6 m2YPD+4PnSPV93CXddypvlg4pK3qtxcH1W8HDqrfDrTa3E61vxKQDtqP/RKxc6T92Pbtep32ezSy 3LjT/vZqr/3t9UH724E9GcVU+ysBKZmevLXWACDmcdgJCza8to0VCgvgn1mAnqd7TYCHBxV8iwWg z7IAz0LzCyZAjabWArwcnDQBanBfYQFejoCs86oRGIC8LjzhaMBdzxz/IicJCAOrZr54d1LAL8tZ NAAunUSq+/JvAAtkANJ9CziwBC52iNEblMrPNcohYphXM8mdAv6KC1Ijw1YcsWYLGF2UMBneW8EF /iVC1hMYWTF86gGn7G6YzxxvwNcFhgfnr3vfwDsKvI+x35SojFIGIymCpOpuZDugyHnz6DfjGYdY ntPgeb5q/e3wIisMdfA0XvB/732l0A0KZW5kc3RyZWFtDQplbmRvYmoNCjQ4IDAgb2JqDQo8PC9U eXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAg Ui9GNCAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4v TWVkaWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgNDkgMCBSL0dyb3VwPDwvVHlw ZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50 cyAxMj4+DQplbmRvYmoNCjQ5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM1 MjU+Pg0Kc3RyZWFtDQp4nMVdbXPTSBL+7ir/hym+rE2ZWc1II0t3W7sFhLfdg+MItXwgfFDkcaxD L0aSA/n31z2SQrzRIMi1tKEIkWKpe/rp7umnZyTYz6/ZL7/8/PLxixPm/Pore3TymDk89EJ2MZ95 UnEnZMGaO9JjwnO47zHfD+CQlXo+296fz9iTl48Zu3EX0d7l03zmctfvrvbWkrvrm1e/u8/y+ezR 2/ns56eCrXko2dvtfCaYA38EUyFXHogLBQ9D9jabzxzUyWHP5rP3C2a+lh/Y29/nsydwj//MZ/+v xCDgwrFKTHJW7zSLdZoe0qhkOr9MyiLPdF5zxl7ULKnYvqiq5DzVbFvAB74kVZ3kF+ykOKVV1F0H XLlW0xwLuwWQJAYokOAvkwLULzGq6yj+WAFKUc0OVQNCkld1lMea7eF3umZRtk+TbRJHdVIAoAU7 18TYKI+vpdUqA9i4xNis3amDp19idThHHOqEVqhwMVfZhEZpesWyotRsE2XRBYaiCWII1OPgfV58 xtiuqF3BD60IDPiBR+wHvsfD9aR+0C+xi9E4yiHy2L4sah3XesOiiwhDFZMoJM00ZfCBqNQRK7Zs eygBnZI6h7p8rayWGcBHEeOjfLxgSnz6JVb1YXN1PZ1FaVUAALXOmY6qK0yXW8TmaB5Mk/wjoLVh nw76oCtabT0HLhBW+wyg5BOj5MH1/qQo9UuEmeu8qHesSja6Yp8T+DHabBKc0qKUwawHuFx0U17F iQNHCB74VmMMQLImhsQNLIFDO2hIFoG0iisYewcgUE9uYOhQ2GTmrCoyzSpdXiaxyaSX4A0ly3X9 uSg/ViuWHJekWOscrlhE7A2By2VgxWHAGwJib5Dh1AHaL3Ff6n2UbL4mSax/4jLZm6oTA7Y41IAZ lBy5oQh7XVYYvNS1aMi9tdUsA+CE1OA4U89x/RIhTMDoHQeAye6hKUoAgYY6fE6qHUZLqTOoSdgh 7y6AMiUuDumGGKRwzZVvNc8ASMIhRgmSzsQh1C8x1Ze6jGAWw3odQHoFlWKLzy7BdAY1CJC8ku2i Kv+phmoSqhRAahw2169j6xUraoeQPBBWJIYcouu/wO144Kr2ewl3kI7RRIUhD10mQocD4JAavOAb 3RzqbgHoIMR3+ddtXajYced5/bqgZ+lPh2SP7LBlI0n1z0HtqDhbC9M3tCtguojqomx41LZI04bA siZT1VdQtA9pS8VgOm+14HqshsOFxz6bi7njwKXX/76BjzPJfmdwy/8y46q+bFzVZ1njuwoC0XEw KNL57HQ+Myc915wU158yJ0B7detTgLo6ulfAYcTNp24bqCMPreMqCJcwYFKELOCh+lYDlLjGVaH7 vSn5ti5UFVYbMhZd0Pc22hSiyATP0yL+iPXntiyyjr5jth7SlqrkkNggtWoLs8nboyjKDlUN88jl kH6SarJtaa0N2WM1ZjgaTzQeKI0D4/DwBMwQ4trN4aRvzkEcth/C4/CvHwi5OLpJyKUtCCRxM18F 3vdmfyqH7ZcIdCnWmwMU4NgS3KdRbAhSHX3ULC9qdORii6VHuQEaXUJGjYsMPpbkNXGHo+1D2Swz 5JHE07NamxWfKQHql1jqi6jcIDVqC70GD52ULD4QQyCxi+zaNKmBZpfVT21+q5rmWBZdNd0x8uWD hk/bcBhyB+L1A+X7OGNP6Q79EnMNpq+i8sos6hzXQBC3mLtZ01sGnLCl3KzuFGnD6agxgk+6VuMM YUTc21dqzUUwKUb9EnUenTfELENM9BYodgL1aHrVYsK67n8aHfJ4B3Ta1AdwAf26i80qQ+AQN/aV F0wdQP0SrztRu6IibwkLHK1rHeyQzYnb9MoNLQExSk/YIq5g7HFn83bqaNoXJldBgRylXa8WSpBa l9sIP3K2qA7xjrxLixHRr2fF3v3r4atRWlo2IIb8gZo/uc7UMdgvEWauR+lBw7RU786WpoY4N7XN BvNlkxTZ110MZXG42Jl0umKHPIX5b5Q+k808QygR9+6VFFNPY/0SsbhowvNGWEYlLrXEQBg2SBhw cXoPHGJfJlGtAck81yX1OpvvcamsdhmCh7h7r4Tk0p0Unn6JwNxLDUWgXtmTaLXDNn1bFcZYOQJ9 y+uySCHQxkl1FvMMbfch7t4rx72Ls7jENN8LvTtZg5jMeoHi8sc5tUtMory1z+XtLs8fRbkrcp2v GG5LSzlrv5582SfYl3hVXOrsnJjpeg73fJtGumTrFZOOcNnx1/vXuBAj3A+jbO6waDMIEzGP8vw1 v4PPEhMGTwV9xniByQ0yHS0AkLt8V9pkPiAmCYh2YBN2UkbbuvG2F68vfUPz8a/77PXrr4X0cyQv Nz3zJdRQ6LDjOGa/qoMuQcxnPC+8i2MSV9EepI67GIO4TPRc0WeM8cqQfoH7Ul/i6mCBKxtV08c4 VF278ohss6jCetGUJ5neJFF5RV0pNv0oi2mGACIuFD0J16nJ2LdFXNEs8ZjsYTYoZsVGpyxL6uQC KvYKjgGZpqXMPubF57xJO0VODA3EbmjVkjjDtpsVLMK6fZqjkEgb6kPbnInrX0+4luxA7HwBV2vf Km6cRNQrLNfJxe4cJso4isGVa9z4afZTt22Es0WlNTttO+JAUswC7cP9Xueb5At7eLakTkYNIbKY ZsgfqImI402ajPrFQTJ6uDGL4+aJlGyfatxaYrafVax9rgiZKyakVx2gJ0kVAwUor0Z4fqgNWot1 hkAipmluqLg76ZxukdjFzNfG3PaAXaBmp+2NR0Yq9v7N08e+CtwP1NHjmU1ZNpMMIUPMXN3Ax5J9 qvCxiIPw6fJXiBECpme+p0K2gQg5VBXM5t0WEwNUqWPAiBgXXCIWVoNQC1Pc923C4iKPgQuOsw3h +wZ42/GIubi7XnNv0r3CFomlTqO66c8fr6A13eCkpq7lJdZwdgMM4UDcjXDhgru4AzEDNvvY72AN YgrsKqfPGgFn7I3e6lJDYBKHpZA+F6FN8qABiMm364k74UBMMV1X4mMNt3EQZp94mUFldYnzwEiY BC52hyxaDD45SEx5XOneBRNFXGm7wuu1xlilQr+49y+IJwe4WkmbNGL63s1E/cJOeKLrLbEnC98U GpMMT0jB7Y7iZxFx6wVfVwGCJhqcp7i0Ogp100VgkaCmGlqzucciTH+pdV4l1H2z9hmIaUYonTUX VvB2OtrosiJe+5KeWZu0pc2h7E1NwR3Fvd4+yY2vcSqbfsnPirxesad8xe6dtoU2e4Gv7ojbrgnw QNOwfVpGF9fNlFG24tpsMwQRMReXoc//FoT6BZuHzg0CtxtW94gfiJN+iJ+0WGAIB2JqKuF61b+b bJQe8zfkjQl6v9QNrtJSTy+OTRr5RGZmTYuwEaorrFXFVINDd7F6ywjVFe4dkBMNrq0GLMKoqyuJ 712YamRYgVt9cqziCtspk40QtzFaHbMtrohF4hJUMNH4XMesfFqEAZ87W7TbE0dZ7LVND0OzInGj 0DxM+LdUJ72C92VxUeqqOluu2MuojHdmkxB1q7Z5bMwy9CEAiFukWCPdxQ+IW6TSd/r9YJQuUL80 XJuTnu98YOxE6zLJL1bslJt17zecPU/yDW66vNdtqWOvy6Iu4iJdsT8hFeEykz/KcqvFNkMIEfdw pRLfrifHC9V+yWcLpBFnS3a61/H1a1nurcw6H+K4AhhjnZ3rEqqOMCBfcTU7dGxmGUKHuLUtPcnV jz/36RM3laXrWpxknDjuF4eB7EnhfjBd/U0WlR9X7Mk4dXO/BtdZ41mSpslFhHnjUVQlMXtbRlCZ mUXplzreRXlSZeO8+86GxZBLEDf4pfR6PXOCvNEvGffSmAZEsynYAFUcIKdXbe5A11mxf8d1galD Oo6iTh3NmrnNMkMAEffwpFBc/Xgr0afuUzk+EsPJUke/OJM6XEdA6vhDYyuxLQD+4OxUFze7ig+h Okzw6eRDqbuHy+kfvrRZZQgc4uaVYe22V8mMGsQWybeKsC52Absb8/4YwdtssrFZZAgYYv4kguBO /kHMIsQ6tPjHKMFrEWeCN/AxeMfxxX6xr6KyRmbwlq9u1htwdJpk+6qAX72DA0wjzyGNFGmSQUEw ypqDDYchdyBmc2LtWHL56OmiX/K9nt2xTR3ALjvuxjpC0aUS8CRylMwDFzbzDKFEzOiEL/6upN4v +VTv6+u8vaZ+10TTeLYNesj2xHxNKMnXg4+YgjC46HfG3ptH7c23D3CGbdjM8zwUqUKFT+5m+J9u uNxZd++ba17MNXSPo0uy9t1f3q174CYy8/49c6dr0YHbie5OCB64zPMUdwI4cngABz732p/j+UyB +WV3nOKxxJZrc6x817y8r7nN9ZGRYq5tTmCXVjUXtycCHsAo2ls1b6nsBDVHMepoFGmOUzxutGxO XFvT3Or6yEiK538ZMVy9A4jvt37yqblZgC/jMswLt8c4UCLAOeHfcIqj91nfYN7fd3XjUpL5Bowj wucZPfEVbsFtwvd4GS6K5QPhLLJML+GfvF4KAa72wF28X64Xfz5cCm8hlg/UQuG3D3DuH0u/xxd/ RE+vR08Fxew6sOl5AjpK0NRbsCsQjz8cWLaEcxoOoxx/US8f+Auos4MRtOus2P9CtRdLoRYvl2px unwgm6PfQGF3wR6jNW+ql4ABKzzMC/jJnMPXfYHOMQxkF8Gv8gu0Po5r8xu9mWXAveA73wzXJbv/ AZ1Y8p0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAy IDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVu dHMgNTEgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+ Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxMz4+DQplbmRvYmoNCjUxIDAgb2JqDQo8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDI0ODU+Pg0Kc3RyZWFtDQp4nMVcW3PayBJ+p4r/MOWnZIszkeai S9XWVsXG8SWxzQbv2Yc4DzKMsdZCIpLgxOfXnx5J2HgzE605LXAqFYgRPerL1/319Ii8G5Fff313 cXQ2JM5vv5HD4RFxaChCMuv3BJPUCUngU4cJ4gqHeoJ4XgBvSa76vbtf+j1yfHFEyMa3uM23fOv3 OOXe+mrhM8r9zav//IWk/d7hdb/37oNLfBoycn3X77nEgT8ukSGVAsSFLg1Dcj3v9xy9Joec9Htf 3hBC3n4l1+f93jF8we/93v8rzuc0YFZxXz5/OBKBx74Scn2fzYssHZAxHZDLKC8VvL6G11E6hX/J eZzOVTwgB2ejlUfGZVSqRBUF7mp5AJ/kVuW8FPaDiRiyiQIGHmMy0cYP7v27zKNuaJP8fjrNQeXk /bLMJll6hyubOfUFZtnxbJlHZZylBwMCTkO014CvqEWp5rcqh6sdnyI7gx9Qya1maHEGjuwMEEhb uKRAXoUnaOjvDjXM4irUCIULqLEJFMM8WqkC3KMBjTElH/O4uE8j+MDBKI9X0eQR2UVAL8K3qqXF OBLZONLTF+wDL8ySj7+DbQqI2YLcZfkzZpO/A8lTcJM47SaGLappMZCHbCAB13t7MZBZsk6lazyF eOoYT5m2hV0LLbbwkW3Bg208IkBeBQstHtENnprFaTyVTigBT9/fJupxQM4BQsfRKkuiARnBa2RH 4JJ6gW01GrpPKLlUqzhJFDIc6BpD2iT/C1uYT12brEsVJ5CVhmqRq0mFfcjCQ0YDq/Q2Nw+x3dzZ V2YyS87uyPXjQsEnP2fLMk5n5FRFU5UXkIDIBirqqBggGwbo3k9U0mIY10G2jOvuKyWZJQ/VpLME 5OqYsN9zm+qxGThgkeu+fhnILFOGfJcpyCKuSkE+042A55pddwIOTiEfJDpCIWavVipPosVCv63a AB/yaDZXaVkcYEdp3QiwKafNRsjkTwbC6CrdR6lFcoWNYC4gXRvxGmIXjBoqPevdtxkBmftKv+ra vXoZyCxPemAYY1eom3g1i9Px6gkuIF7Po/QhVv+Jkf0PKDULbOIn/x2QY0CHT9lydp+uK9amU7ju CdSdwstsil1ENthgMUSbPyCTSimhygz2gg1myZ/Vt2WcqwaWqzJKe8oLqIAMjGwT+MbAsyqjzSbI 5FKKYCvXQGaXkodbaQO5+pfc2UYbDLnUlcw1aeNjlt9nqcYLVZIooeuQOf6+AC8uAD9Wtdf6A+24 /GVgkS+jaKYg13zF9WehiaprW3Or6pBLVekyyvjrl4FdqjrcpI2ztFR5qkpcC4Q+9TizyURuFbja 3IFN2DCP7sra3aqUppup+i8/GY3IkUqSZRLl5DQrymLTNS+ix8pju/FM81JbXQK5Mhah2MozkWtD EUjKXl+iMuTaUPgeZT/SlQA52XohdXxmk8YAQs9S8M95VMYrBV94p3KVThTyXm3D5i2raFU9chkm PJ9u4YfIhYeQgVEZHZEDizhNDjh3dT95mGfzZkvuMFum07pQ/3eWQAF/qAt4Nc+a7buRyh/iFD58 RLsh8zbltNkIuSoTIjR5Svf1ulmwJk0XlBxFecWjDoaPaTSPJ1U6IUcvNudGeab36xKdfLqxkFk1 bQZCrleFcCxB1L2FjJKrpH/zZnh6BC9u3jakSkcYhNMy0VkesjFy7wXqHxlYddE2/IBcuwvubuEY HLkMFqzaPdoZuprFVejqca5npvJM90mvaNX6+ExruMXerHNoyG2LWXdZRpDl4+/kalE+bfc3QNLJ tpbNEm0OgUxIhMv3BOVGwT+D7Bo+bt6Slcr1SAZZb3FpV8LOt42RzNppsxE2Q3CEJWg7N5JZ8mbH HBu11zWx5Z7bVI/MingoKd/CA5BZEQ88Ta53BdsWcRVs+9x7WRQfPA9F/YPCCztMIcV7VvW0WQmZ QHHfp2IvMwIWyU+IOVb5Kp6oKqltzAZoYyKnWl0F+7b1DMj7RR4nGjYEdvcc6u7QboI2T0AmsRwu 2MYhkXlaNdtpdMhuYMMsrpp1dUO3go31fGtV7g0pub6PEpVXY0R30TIpq2kWyCyj556L/mg3sGFR T5uVkMkal44F3DuHDbPkiyxH3m90haSM2eRhd6KlY5M0XqhJfAcZqvKy9d6eds7B8y4JoJPsCJ0s lm6bgEemoly42/i9QOainDM9eb4zdDKLa9BJc9HTOJ3qXbQGnQ4pOY3AIebV8P0fafxtqcinbBIl 9R4G/M8kKpD3bHjA9dCATTdtJkJmh5zxfVU0ZsnN2P1m6PIBuepkuNeyhEmZdYQSTFMfZlV6m+2R WSd3xVYuiM3AQM1idx0ri7hquA9+ACXGWRJXkHCqyc9FdhsnqgaE8XKxyPKybh0tASaAGU0eml1N 9CKm2cW06afNTMgMlYUe3UuLwiy4riLXKKEtp/vMqepkxk9vJjKbBtrsgMxBGVwvXz+pIpAJUHVQ ZmdBa5ZWDfi5jm5XnKssndUbd6Mof6jncg9VklVHGD49n7a7iKZRGi2iJImxO4r1MS6LYtrMg0wM tcuavGQH4WqWXLfgG+73frpSeRkX1QDey4b8JbJRmKsLcsuixi97WNgD2g2A22zR5hLILJR5zp4A 3Ci4mrmE4H3By1ynm/Fsy723nX1FpmVMuts4gkSmZUwwKnf3WAWLuHo6W4b6NMXTeGN1pi+L0/jp 3QgiM6nnMOrDfvWvrvHnLypaZtNNm4mQaRnjfF/wbZZ8GP31kA3ISZNIP1JyFhfRw0OsT1/W2B6n hOdTcqJSlXdxWBDcyZdWzbQZCJk7MSYsMdS5gcySoeopQfHFfbzQWzF/qUlJbt7o6cubt+QYAmel phBMkwdVkvFjUao59lMGBPWZVS+dPNLAIuzmzfForEdQOtkx/md3+KMDIrNm5koqjb21zh3QLLk+ QyHDgT5ss4zyaq6XYafzunFju/k2G2BTYsej3uv7OBKZEbp6DHx3A5UWcVU+l4Fus55EAENp8fA4 IGdU+4OazYBuPZ1/+pOSj8t5lOsnJV0tmmwRYe8c1+N6NuW02QiZLruwGpOrdB+uFsmXKp7d32rG FRcTKMAhXiFt3CZq/nQgCow5AL6cT+67CGXuWdfWahxksuz64VY+gkzQXN+x+Eg3cWwWV8Wx5/Af 6/KX5fffzkDruL6izbRfJ5u5NvW0WMlDJnGu51rQtvNINks+aOYaj79PkuVUNe2UuptSTeNiD4Do iTnLWpA3epthE4uw26jQNW1199i7ufInCm/1OGS+7kpG/b2crLdIHqpEzTYfdKfxYrA+y4Ve89WP ZLJpwWCM/wGAE2XbDQplbmRzdHJlYW0NCmVuZG9iag0KNTIgMCBvYmoNCjw8L1R5cGUvUGFnZS9Q YXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45Ml0g L0NvbnRlbnRzIDUzIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTQ+Pg0KZW5kb2JqDQo1MyAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyOTE4Pj4NCnN0cmVhbQ0KeJzFXG1T20gS/k4V/6Fr P5EtTpFm9Hq3tVUsZtncLTlfILUfwn4Q8himIkuOJEP499czkh0DMwiclpJUNjFruVv99OszLcPb Kfzyy9uz43cTcH/9FX6bHIPrJH4C1/t7PgscN4E4clzmg+e7TuhDGMb4Eiqxvzf/eX8PTs6OAbY+ xes+5cv+Hnd4uL7aj5jDo+2r//oZiv293y72997+7kHkJAwu5vt7Hrj424MgcQIfxSWekyRwsdjf c5VOLpzu7306gDd/w8W/9/dO8PL/GbRgxFrEDI3yVAt4pMf3iou4EzOruE8X5w7jbuj+TSvVY57z zE32mJoTmxptYAL8wS/q+w8dL7FJ5qfT6SH8dCoKUaU5TNPss2jgQzqTJZyL6lZmAi4PTqcfzi/f /Gv9E1oFeWjVrg8dnxid0HeS6IegY5Y8E3VWyWUjywKN36TXAthPh6BAg4tzYNzBeAHPczCVHcJZ WmU3xPpxBCYKbPox1+MOscAkcoLQCkWPQwTEDhGE6oLXahESa+Hj9eF4+dksrs3PvusNlJ8tN9lj 6ojY1Dw2Aj5CBjBLfk1+BlHcpEUmFqJoauKojPGd3GqeHpBiYpBYYomHwUEyS56XFZzclvmtmMHH Qt6KqkasLkRVibqpJP67Bewoy0Rdw3vR3JXVZ2qEuMNiq216EEqoEXJ/VBiZJV8enBCL44ETMZu4 fxALw+HEj2zCPl58OHqP0Z9q73rYHmC6ftQeDFGyo9gJuBX0HtfzXGLfw/vdIQI86tHOZY7njVe0 zeLWRZsNVLQtN9lna+IBNkj4TpATD3dB7O9kDeIpJog0sfFqNYh75yDEhPx04P5PWd2UhSgOqfO/ GylxFqnYM6W5s648J1+XEkszvC9vxeJKVBAd6rz4sD7Bp6kauLyAOHYwGh3u2TTthYl4uAgCtFv8 ejWIG+/Aj03WeFc0oipEQ4sAjpghZzaZ1MVbwR3bhE2qdN607vZuehuCaiXVH13Dj0Wer/K0gj/K uqm3XfMsvdceO4xnmlXtdQniNj/gyU6eSdzLBtzdxRqMuK0JsOKarDF8S22R3E2mR9hUykZkzUrN p9sTqPbjoiyIm03URoWTWSni2OXKAuFzFui6boF99yA8mA32Pu8j7mYDj2Ef+UO8zyz5wYzD1IwT bs84tKowRYJGNlXI5ymmyBaruF7oqZtrl+/kgcTNtZ/4Fg8cZJ6yiNPzVOKGA5GgtpvsszXxBOHH gcOMs+vQ0W6R3NUa3Q0q6kwW13AlmjshCmhuBExXV7nM4M+0mMFZeSVzMQzJ1jVINvv0wUQ8YflR 6LAfwoNaJF8eTP88U1RUvVouy6pRMC1bxvoqrcUM6paxrkEB1XHZk7RJByGrbebpQ4l4wPLDyPkh ldMsuIuLGhCsCWK1zRcq6ljzhf6wfGFoU64XG+Kp0w/inVyEeNLx/WQXYxAPOr7vmoxxtFyKYia/ wpEDDydSYq+Nuc6tZi2oQ0SliMQmTE/iR7NZhZ29ymGyrTI6Ts7KmciJ48EPdLy+6M6fbqgQD5o+ 93ZwRk48cPgMrwvGa/fM4i4Q9XTt/6lc1NCUcCuqe7iqpJjn99BuaFyJbw6inSfdOA/1VMic2LNa pw8k4tHAx9IwYktulLZQ8aipBna6OQlXNQ1ffDy7UMfiqtnw1euTqXqZrXNYsS6F86pcDNOCmA3U BxP16OT6o8aSWdwHkQtsAgdh/S0iqZlc7IwSzyYsSaAs7tJqVmOdPCsrgWUD3XKRqu2ttYMqV0TX zNIC5xf84QpfD7IHsKUk/h/HdTFzbP6urk0//dDuMjyJBfP1Gzmh48bgYevI1Rt47G+2Z6mmrV1v RVIPf5HuGXZVp3iE9Ob2mCr7GKpoTuwA4gg9aW1C7WABvg8/Rb3Ri/AtQaTe7voxmaW7RMGTwOF8 h1tTxe8lTrORg77DwPMdwy1/dxaKtYG27uWZ3Ltt306r1r6xkwTP7IFzYsaFx6FitcdK0RZx2L/Q isMq6LlWcTh0iuymkFmaw/lSZHKO/1TZsoZvy+A6ZX6j3TC3YlNGPY+iIwZWDPqqNTGrw6PI8Y27 U8O4glmc+LKSt2kuigZmZbZSBzrfChk2U8SMt2Is4m1dXpd/HtTTl1awjdDE8TjELioVE1cwrtqT 3W9L1mqseHgv648MVO1gsTojos6gnAdOGFodkXr4dR2717fU1DpLDFLPX3abDwoFGh8Fbgox858p FMRsIscLxiwUZnHGbK1Www/h28bZ48w9yNGszR59SZuYSOT4d78TPVWDmEjkgTuqd5jFYYHG6SfF Pzhfw7Ksa3klc9lIofmTNM9L9JyWMumIEl1WMIlr8qTAkX6Qw3SLvv8c5JDIhkWfSxCzutz3Rm0n zOJq7B5w/q/bkx/9ar7KIV01ZVYWc3m9qnQuadu7rTe07jHIM002y/Q9c0bMt3LO1HL3aACZxXVB qTq8BZbbtJD1AgohZogYTP44nuqzO1E9F8DDxKzFPH0oEfPRXC2ajBhGZnHK4JsUibHy3/ZgosT/ VICgzQ71661oexxgg9CcNuP0YURMR3PPHzWSzOKWVZmJ2Qqr36zEgleUjY4jTHz3IL6qdVa9J9dI 4vOzbknJotU9yKJ7Qqk7zRomtbbnEzYk+hyCmPjmbuD44xHfFnFPYhAuD9JlWjV6UtVYnJ6ev387 Pf3r8g0G9VGjf9bIBUb2HO4q2QxwjtQmV4uB+nAiZr9YEjrjwWSW1tzgtL2mOto0qjPtVi7tKt1T PDcVc5BG0mKdPoyIaSmG1wfjfUmERRxiVDcyz9uyV+T3sMCqlzZldd92lu3ikUq3HVpDVr+2j7RZ pg8gYmaAKeJ7PHyM0haiuSlneph7eiTw3cdvfqD4ebPkzaGuZoxyWXymXspVpFhss3If1sR0AwuT nVyOmG5goTumyxmlvSugrGbtYNJF/7oHxsRQzSxZnDgTtIypxR59qBBP/CzwRs3UZnHPVElIa/z8 rFxgqZ1hqr66b8vtycXvhw/aoUF6Hpt5+r5ZhHjsZz5zAuM3AQ2DkllcfYPDPOJRy+sCB321sJQL eBv6bdgsKzGXXxGTtAEsvatCflkJuJPYLBUgGyzGWbkk5urWXY/FPn0wEc/9jPNRg8ksDnObSLMb xEMuUmx1ppMpHJdFg/Mk9UmcOl5iNj2wrk8n75XoQmQ6qLVrrGocdJXDEAesItUjKwR9nkDMLjDm jxqwZnEvGEc0h4rRmt6WcqZPEAHRUtuIDSbachAGyGacPoyIB37mBU4wHgNkEbcUlVr8gslqmUtN lHa7xDARTRc3lweTo4naTWw6gPQqIuTitt1mHAYli3n6UKIe993QCcfjUi3iFB+3jqGrlcybdR+y aB8guinrpjuOWPcjkOZ36X2Nabi8lTMxDHdms04fSMTzvqcekh/vS8cs4lJsM9RDX3PqTc5QSbMJ zQQgvEUj57IdLMxuQQy/XuzYUul1uyLdY28vWt3sJCVKQSyunId67wUbZLodknatY+fbod7Hbh+x 2Fkdk3E3t4hJNdB29Fi3ixPS2bHlmCyeqpyx7b7s2ypKPz8ccm1UPUxjyFhPVpeoUoVZXG+CJObb vCgZNUGaxbXZ8VHG6urTZrLe1C9MZdf6mwSxJ1Hjm+LJBuk0LNpSfz1DWzFtSPQ5BDEp50XumG2N RZw6mt/sTTzuX9aNi/aKDWWqs4ga6p9uG35/+tJfDWczTR9CxHylF3qjhqxZnClkDzGLr9I8V8e0 kEKVFrNyoc42MFgRxHfEZ8Xd8pzNHtTkqKsem7EIW6zQ+URRqwNzcvfruKSX3edT9yMmZj2syNF4 XwloEdeSeIUae8o51KvsZrt0lO1ygCoMOKNKRziHUJSQlXkua7XsSf8ouM0sBnT+DyU8YMkNCmVu ZHN0cmVhbQ0KZW5kb2JqDQo1NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNv dXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgNyAwIFIvRjQgMTQgMCBSPj4vUHJvY1NldFsvUERG L1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45 Ml0gL0NvbnRlbnRzIDU1IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTU+Pg0KZW5kb2JqDQo1NSAwIG9iag0K PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzOTAzPj4NCnN0cmVhbQ0KeJy9HNty2zb2XTP+ B7zV6tgMCYC33U53Gju37jTjTdL2Ic0DLVE2W4pUScqO/37PAUhFsgDTUg/pTGyTFnkOzv0GsBdX 7IcfXvxy8e6SuT/+yF5eXjDXiWXMbk4mkvuOG7ModFwumSddJ5AsCCK4ZFV6Mll8fzJhr365YGzr LV77lr9PJsIRQfe0DLkjwu2nf/+eFSeTl59OJi9eeyx0Ys4+LU4mHnPhn8f82PElgIs9J47Zp+XJ xEWcXPbmZPL5lDE2/cI+/XwyeQUv+N/J5J+CC4UTcSu467S5T9OCZU3NyvuC5VnxFy18L4gdV9jg nxMDw9V6NmB5OUtylsznVVrXLCnmrLlN2SzN83WeVOy2rJvv6j+mDi1OAhguQyu/d4HtSR0nlrqI gxIcjIUgxgLYNKbsm8G9K1AWsiYrizMlCW/efHz/4urN7+w+y3NWlA1b1ynIyQMrF+oDqypdZF9T kJ26zm6KdE4sKTFX0muhTg+PJDGPAunE4Xg8MoNryl39rBncuUmLtEoazRpabLjwnSCyYQNi0BnK 1oqktcPYp9usVqJSLqgFInT8wMqKHoHwiQXCD/CB0QTCDA7VMCuatFokM/htnhZNtsjS6ozNyuV1 BjoJ2tvcKnWFjzTwS9KwNJndsqvLK2L2BLGVKj28CYh5I+H5YDzemMFdlMCYrw0rK6D1ewaXRTpD 88pAP5Ic3W8D/EnYusj+Xnfm9EyZ22F8roUsPcwJiZkjolEVxwwuzbNlVqDVRNUoUmDEAhh1+dMl W4IhS27ArZV3aaX+nGTVNy07w1CJmD+Aa+hbKdPDn4iYPzweVXnM4GZlUaegFUWTP8Db5usZMGSY 6NiMANjOxSKbZYBB68xYlcyzEt5cl+sK0KEOjCHveoL8PUIQUwuBe4woei4xGp53DDE86uTU5Y7n HY4Gcbbix8JEjf+W1W1ZpBC1pw34FYjA9Nerr6sMhJW9Bzu2vAZTFp4x7nqC7X59vgJjB3npF1px lkAz4dlw7iUdcYrlR/IoDhJnEX6oKi37qRf4liJtaDkA0XIguA0mdakB2R3ZgF1WyaLR4vbu6i5Q rhb/izdXV+yiy2jeqoxm6+uX5EFJ7DCSaUa1VySI8wg/CBzv8BKERxwy+37oeNHhaBAHh76MjNQY KPiwgHu9riDsq5ZllepSSButY+wOcUDShuqYfHepFNuJ9okjg0g4PLIh+54aWIQFShsj+uSBOBj1 RWwUy6HkwQxuK3VTtTAUh/tvBZhsucrTJQaKKCvEFRhkR7iNGPzFcV0Bn+t+Vjemux8U6qsqu0tm j+tC5nd0sCAQjWKGyUgUwQdEJDdtgH8sXRysXXD8cqhLFsJ1Yu94dIzE3awRLOo3KvIojGM6OgbS 4f7xiIOlSosaBPpxUtW9WMuADB1fPbstA0ozfEAY/gKLhL/6YcAga5ER2fo26u92Vuiw9b2ilRMk Shwcj46N2ua3dIvngB6wAnAN6CXIg9RKib5rsvNZQRwecs/Z5ecTXmVHwDQRtIxFTuw/1ZIkToJ9 QHpM52MG9/nD6wsZS++LquSW62a3YrXQscpO5Yq6MgGIYWxvIUdfy464JuB73OHicDSIawK+K0YV DjO4dwXEogmEJrP0UdOuLPIHJSUqRKlAblQYyxpIxRbZjBhLIWNspG5heZiBnKd1o7oVz7GPG2Ag j0xyJwokvYPVzUcL2YGiT5gshZfJYhGJHlgDkwYA+wcRPQu4XoUjrn7JyHe4oYQzkMJZwO20X3U3 bZFQ92s8SPiEt43CYdpUP0eLNkAEapETgrSSxxiYUMRWzhETDTXWyrd1MW+bOW3u3s0sqASuIa/l +45nXzi18fWBfdwGDdvxg7SrnsfWbcuoZe1ZsRwnLgDLMHD4eF0tCzisFGRpveupl8nDVgkhYcus yJZJDs47u7m9hhBvntUz7EU+DMNGC2X6zDtxaVwGoWNwMkPxxwhtVZVNOStzVq+v67T5N6uzAgOr +Vq3iVdlVhAX6TnGMpEFH+IaPUc7YVt7UxIDw5w5GGlhOFTJbUxFpqlJTrYs52neTToOUqO1SHGf LhH3FKQfjWrszOAS0CFQH6yYDzBHCx6Wcxto6uaW79og5ckDxBXt+FtW3Oh2QTtTi6MC+VrVjWdJ wa6pZS6Irazukzji9pEEMzai9TZCw9m3KoWst24SSIghKn9gs7JYZDfrCuK8VVp9a9RQF+nhcQtW pgGwAUaI2qamhQ990tB18TA4i4TffscsoaO4iBwvZMIFD9IbuhH3gKR0n2XN9hGhqgduxM6ICJbf UpzpK0pdloOMYp4uUnAzalhalec6kwAZY6FsxL5J3B8zp6qctQUTC/7nfWhQVc66PMWMhtqO0IcK VU1BhJHjC6toPUphsGZ9b0u3GWc/M3jln2wSSseF1EYpi8eWSnswuINrzvKTyceTiVKoSCuUaD+i rmWw/xm8F2+9B65F3H5onzZdxtSpDY/RQ3qQpQW96ZagjuaF9xx/sI8HVSS0sVsmPDplxPo55lVs XeTZX+g65mtI0HAut+5DlMqBcqmyaDOi3TT9bYITw3UJBmWzSaNfWahmM9qRAAtPd7GY4HrcSEmf F6Ds4g1wHUoc/U7C1ar1TXA07afwhggdQPHRp+CmkNvvghtSWhWB2v9wjkiOFtyYwaWLBQQPDELJ RFfzK/Qzqgr5/tdLJSitG6pSFfp03giEfJBp8i08D6tOUle/dMf6aHSyRxm9pefQLVo5DE9iskfe c2gLMmYBONPVCOqwMVQVWouIP1HKA0J45t7/vkIS92WlJ8ZMNozQFlW53C3jUaecsQpQjMB1SQPy 6rssvWdZw+ZlWqsdel38OUvAFqB7G0bXNlgdpmrJ89p7HRAP4xcggztAe69VNSN5MY/PyRVN52dm 0X1CzzQVnlUzl8SddgnZ3piOzwyuDdaox5VDDOq3QB44P/W8FlsHJcCQCIjKqefpPC/A6N5CujP2 5xriAxUuDLJ35mj6PSZf9zquasagmpy+GYkpn5VU1Oa7ba6agaHfuL8t800zcpjS+7HMmeOO3l2U Nq9UDOLALZc+/mnnT21EK/fPJximhv8sCdkx0rg/6JnBkCSeQxKx74jxoqEtcAcKVVbp4udzDOcG WKgST9XYH8RwWqgH6dTb8j69w43Ue0LHlmhUr5XyrpKqncOj7yjpEMXGX7s0ilg8P2QgHtIRUYCj gqNJoxncppwDHNSBMshemt1hfybBdJklN0lWABfx/AL65pSAoC0KbNgRN6cESrKwAds55AXE+h2x zWzjWhvf+w7pIJ7yEGHoyPH2llvA1bflOp+jhYCUDPMxnBJDM6K2u9WrdJYtMr2dqGbtn5psqTql 91XWgJgOcpLKFrr/qGLT2ZnQx1rdxutx+YSdIa4vC3hAHDNoesgAvghdVcpsw1FK99NuKNhaxpAD Yp24mqE1WGGel7O1nj+qUlZnOf56j3LbCvNtslrhwVj65J/9AuQwVsVCnid8X6BaJs/zfcRTF6pE OKLxMYNbJFlOvQGg3dxrW2CfkSeeNRC+e5SvId6qKqQ3KrvN4D6mKfuoA+ua+ehBcL9IIP34y872 EJwhXNe12sFaaEc0SGGl7RXZiNPHI+LWjRAcq/aj8cgMbmv3MM6efRtFo1ZT3PHPrYvuoz1xlV5w cYwI+MRFTOHJY6jhU6fpru/I/aLCTyvijYoQh4XcBg08+Dz7yl5CHnBxmxR4xhG4cLAXIDNeQFyE wv2FNkR6qU+clkKs5RyBBXF2wuF5f3/340vHA4b8llbKOs/xqAz68UULbPJBSQyWbcCytCE+EbCt G4+0OF1AtgC7C8oVsS/lrnpgnNVx7FVwG7BqMUMTcU29laQdSR9piRi/xjZgLh9kKN0Crdf2ECfM HIX3cCyIUySkiYkYA8VjFnAluL88qfCgzDlLv+LEV4bHzKk6ja4Pbtr7N0mT3icPkBLPU9a2IH59 9R111KxPNrWRp49LxAkWD1yTrKgv2nVDsuC5NoADbBrQ/VgzOGpvoc9XsCxt5+jtrGarEnKz6zwl zgja83stDO0TK+KEmfveqMpvBgfK/9N8DopfpYu0wg0qKgg2lGapeYEW2E6FPmYQZ8Zccsc//PQz nzhJ5EKYQ2I+Qkhshj1QSGwGNlxIPM7i2pDYDGzAkHiU1XUhsRnY0CHxOEtsQ2IzMNcbJiQ2Q+s9 JJy4MsS5PMYEBsSVIe75jj9ejdICTrvFdmMBm+nwuDvysFAxcVc33gxDYIBGfwqy2qpkI0ofb6jr Rm6AFdXReGMGtwlZkmKTrqjW8rfOcjtHVn7bW4ZR5YtAUrNHz+ba6NLHHuKCmip4j7fP2QJuJ51U HLl8e4Gn3P5x+uH1BfgI/4+p3h6oThKfY8sfT2LC9sxAPRg1x2ajTh+TiCsPeAiMWYeGSictEJM1 Hu6g9wMrw0bdftGRl229fWQnLrV4YXwU94lrCV7omqjx0hEqwKflQHvitQXmoMmEBeYwyYQF2GDJ xEiL08mEBdhwycQ4q2uTCZtsDptMjLREnUxYgLnuIMmEBVqvnSMubnmBd5S5JS7reD53wvEOybOA g4joQ7os7yCTwOPSIdapuxEVFR/pw1CYHgnPHyASWhdzXXPHZnQgBXncqgvsNvLsAYOHfmbss9r5 r759gTtsziZSSgQpIYUVamu+5EJtWtC77fWW5L537DzSbmsWe6/w9g7j0DOI9+2rN7h4AvNYxKW7 wdW26XYntt5BhocHyO5idjLxQWD55kaON7jjbz7uBwLVqn3V5kpBUk/rG8J3wlg/3d4I8eiD7l36 1JAOlL6aIZ4KF32d47XGVN/YkFi9anOlIM1OHq0anr4FvnfzfX/rl0W+whx+4Jy/q3asyDjYkpQd Jdwqaj7vaS1nnAWKITuTi3hkNjwv1OjoY0G7mMan5fTcc0+Xy3QKP4pm6nkgf+fi9PM0PP3tp6kn T73puX8a4LcvcO9f08AgoIfgKQ14+pDBhZENz7fTc3m6RATVt7OpJ05ZMz0PTm/TaXRaT+VpOgha HfnM+5Hn66l/usqBKBlgMAMMkgbJhLggTkxhi1dJgZca4wR+Vb9trYCxX18h0dm8hLdtni/KKeft hwdbmyfxx97cJmBVAg55+x9/v2dqeRpj8WYqTq9AgPA/q5UUrfAvs+l51LKoaklzox5rkIv/oRcd 3PptW8YjsnU+7/+E/RznDQplbmRzdHJlYW0NCmVuZG9iag0KNTYgMCBvYmoNCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vUHJvY1NldFsvUERG L1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45 Ml0gL0NvbnRlbnRzIDU3IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTY+Pg0KZW5kb2JqDQo1NyAwIG9iag0K PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxOTQ2Pj4NCnN0cmVhbQ0KeJy9XNty3EQQfd+q /Yd+41IwmbskiqISfMEO2LUEAw+Bh8nu2BaryyLJJv57ZrQbyGUGxaKlTfIQV6Qzfbp7+nTPbODJ Cr7++snF0fkx0G++gW+Pj4CSTGZws1xIrgjNIE0I5RKYpERL0Dp1f4XGLhfXny8XcHJxBPDWW9jh LX8uF4II/eZpmXAikref/vVzqJaLb6+WiyenDBKScbi6Xi4YUPeLgcqIkg4uYyTL4KpcLqhfE4Xv louXnwLAZ7/D1fPl4sS94Mfl4v/CJYKkPApXAxwVpsmv87Xp8rpqoatBfLdaQZFXWyjrjS3AVBu4 rf+CS5vf3L6qGzjO23V9b5sH+Ktuti3ugiV1D7AoP++CfeAljuyllLugCXkJ3VFpShiNItYV5B3B RWRME62jNg4wLZCZdoE6Zz6E4Vw+PNtscp8KUF/Di9MjkCxj7sXruixttdlnCbIjuJaE6ygFA46Q yI5wi8mSR69CIa9Caf/AY1ehkVch3fP60atIkFch0jFcpMir4NkYLjLsVdAQF9/XzW1d2eoLsNh7 pCtDLAbbgSkIHD4nr3d5Y1u4dKWxfGUbSL4ATpmAdz8vV+bGAkt+n6Zshhc65CVGkd3kaBsRLAxb ZDlSGPtgGedVZ5vKdrgeyBKiBY9hfokcl97daQzsuDHX3T7czlf3Gq6daPN/emV3ZIvizok+OKvb rn07NC/MQx+x00RmeKmDIYGs6FQmRkUmstxRqRzFBnKxV0nfCc2luiJw76mu47MjF7TI+eJXwGIL wE7OJCVKx8BemdZuYNXY6/w1HNvC3vSicmKNKXQW9fZQ0CFrO6U1YcGmapqgC8MFpL5mbmeYRerH KBjyBLK+VSohLJ3PE2G43hOT1OII4LteV+7j3nljmk1e3cC6yG3VwT5Ly/pVXuTdA3YySkr+g/6h KEDuL5RMZ83HMNz7+VjfOZHmfnRvmy5vbemdcnH1M9S7/p/cmmpTOH9N5JkIJUOeQe65lMhmzc8w 3HueObmvi3tfwcx6azv46aHtbAmdfY09n+JuWUkSJWHIF8idpxJ01iwJw70/sAX3u7u1sGvy0jQP e4Xfa/6uMVW7d1pp1y5d8rbEThbvIBVlZmhUi9xzKs5mTZYwXEBWKJop5ySD3G9y6qoHj5qNDObn IDGsjd051WQ62/ax+OKMIoO7cq7Sj7T0wzhDHiooxgkX88VZGC4UZwnn/WHNxrf/yC5wOZ6J2GKQ +ycuFNFpDCy33TUynpIkiTKNbZwLI5nFwHRpKuwq6prR2YxL3eMxrApZ5POMuwyZy7LDHhQGc+LH umpbI/vujRqdxUIhFWHRwLy1ZmMb5LNe4WMzGi+DGzv2aJCKiICY6rA3gvhvM+rL6X6C25gb3wKZ KZsf7pZFkygPQ+5AHpHKTM5ZZyNwoTGRSkU/Tg9ciNjYKjcFcpZwTZiOLRB7F/CFnkXZQK68hw1u JtP2G1wErLXNfb5GPj48bHCxUB7KKORpv0wV4YFDh+k2uAii6Tqz3sK6djXTVZVJJq3Mq4O4zUPU I8+8ZaL93He2zSwMV/szvo3ty8qqHxT8gky6H2+nMXh9tIL2brerm66fF/kA2G+tpsAeTfhDRxWl fcj7yHN2qRMyIv2R57xSpaPIQB5qSpkFyHh2193WTfuJr7aNbVuLLDWZ2/xdexwGH6QAeZYoXdkb 4QmBPDGTgoXImGpPCqI9r++qHN7c34HfPrVuR6ib3z5Ddr9vTFnM4iHekSdIkveb02zEh+Fe2Mq2 poULf8aFfW3K67okaugQ38iNnWRizjgPoq3qZrs1ham2prtzyg6Zb0VjVg5xjd21UTlrbIfhTs8v p9GzYTjkRsUrV6VjYJSylMKZLdq82ubYcZT1/UrEiUOxhNyviEwRMV/iRuBO88qlLfLskvnDm7iF Q0Qjdyci1f424aOXgSyTRZIQGbi8OpW/w3AnpcmLr+APL0xIVbc7Uz698T8j67qc4lQtZvYQ+8jt gXAPjAkC5PZA+POREWwgS3ShaJCNqWIxDPfcNDk8c8qhnk4Z71v2mL1DXz5BbkmEZLNuAWG4kyZf ty32ac7huwQxE4eYRm5ChOBeos/GdBjued3cux4E3Ks58q0BJhRJeNTOIbqRexDBxayBHYabVMtE LBwiGrkBEUyO8je2dqWKyPn6oAic0zKT9EERuF43uZJFjC9ZT3f53a0h6F+04bR/IMbwkKORtTPP NBmxCmTpzN3z6vF38CSyhuwvm8wW9GG0K2vLO/jJ3NeFySuLXcQVjVk5xDWyUOY6C7p8KrLDcJf1 NkfeYw6X92P2DdGM3AhwTecM6SDamW3K/DA6ZByOJwjpsJVDX/pGVv9csVlDOgx3eo5cM93TisfQ kGeHhwIdARMi4RSuTLmzDfbI30dRxH9DYYTc2rhegqj5vtUYgTs9v/zh2SV2ru61dszCIaKRmxou xCh/I0t+zuWs/g7DHeaGnZcfpP1HfjytfIWcYHa4v5Eds33IBcjtDmeKqBH/awi2GKea6Mf3oApZ jTMvYR5/vq+Q1ThzxWAMG8hClSXZKDaQhRxL6Bg2NLLGYZqNYUMj10imOEk+7l7c38F8IjgNCmVu ZHN0cmVhbQ0KZW5kb2JqDQo1OCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNv dXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VD L0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgNTkgMCBS L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv U3RydWN0UGFyZW50cyAxNz4+DQplbmRvYmoNCjU5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDk5ND4+DQpzdHJlYW0NCnicvZpvb9s2EMbfC9B3uJdrlzHk3fFfURRDHK9LgxTu ZmAvir5QU7kx5kib7GTtty+dZkCKStDEnWPDMAyDvoc/ks/dyYLjBTx/fnwxOzsF/eIFnJzOQKvI ET6WBaNVOkLwSiODYa0cg3MhfYSuLovV07KA+cUM4MGvmPtf+bssSJH7dzR7VOQfjv7jKTRlcbIs i+NfDHgVEZarsjCg09OAjcpyCheNihGW12Wh95o0vCyLtz/Ak3ewfFUW8zT8TY8KFFYRMEGZrIKE VXjKYcHCKhyr6L9Tcd52V21TN0dQ76DaKLh/zD/9te7qLbxub+vr93UH/ghQG4JvH28X1ccaTHj3 7WT+r2bWaYAZ0jxGzgqTs24/YKoKJ6yC03j3nYqzZld3Tb2T5R+9coRDMX+SDWb2ix2Ggp121Wr3 dbOdLW4drISDB7rbaf3B2w5W6UUvFwuY1ZvNzabq4Nd2u9s+PAQX1ee7s3GYM9CvbGz3eeHdRyHn DARhFRhzWERpFbqXBYDsBkhpI+BguN9vkj1fwXm33l41VSN8KtgqxMGZjvA2Whi4Mb3Lfijg/eHm 3fpyu22lSadg0QxOcYy0dNmWPMeYxyPdHy6w1nBaX1bduoaTze0HJcx8P1sanOwYc+Ei1UZ6zN09 EG7Z/tNAu4KL9qbZwW/t52pzBG9mB0m2QzMeAy9cl9vAj7nZB8LNqqb6UB2kohqa4Bhn4c7D+rt+ dLIM4TLeOqdMTzN4qOXuD7fYd1vP4MckK31LbMHH5HafGIM3skJwn1oGpz1GX7h9sdYrEx6Pfn+4 +XW13jyD7V3tpP68r51+ru9Tu7psr4XXgLViNzj7sUUQruIth6y9IFzGW4pZNITreEs6hwYKV7cW TQ4NFC79rEGFNF2GdDWkKYuGcG3AkbNoCKdODqkPm57BUTh1sncKpxdsKJxD2HmVsSbCJso2ZMEQ NlHmmAND2EM55bcMGCTsoUwmAwYJWyhjGmenyxC2UDaUA0PaQTVnwRB2UIpWUQYNYQel4PYd2WQZ wg5K3iuefkGPhC2U0oAcGsIWSuk9h4awh5LVOTRY2EOJTQ4NFjZRIlQ8/T8/FjZRQsqiIeyiZDiL hrSLaqt4upmzsItidCpDhbCJYhpvp/eNLGyi6EMODGEPRRezYAh7KDqdAcMKWyhakwPDClsoMio7 /YKrFbZQJMqiIWyhiJxFQ9hC0VhlM+5lkbZQ7ZSbntessIea/R0m0/tGK+yhJoQsGsImanzMoiFs osbrHBpO2EWNM300zmWvzDtWqZwYCiZyV1w8zF1xA5JHl0k4yxiLyv+3a5NfAKptNckNCmVuZHN0 cmVhbQ0KZW5kb2JqDQo2MCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJj ZXM8PC9Gb250PDwvRjQgMTQgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9J bWFnZUldID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45Ml0gL0NvbnRlbnRzIDYxIDAgUi9H cm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0 cnVjdFBhcmVudHMgMTg+Pg0KZW5kb2JqDQo2MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAxNTU+Pg0Kc3RyZWFtDQp4nE2OPQvCQBBE+4X9D1Nqis1esnfJQUiRD0UhoBCwEEtj paD/vzBChDDVFO/NID2hqtKhPXTQukbTtVCJFvFgssyLRpSFaGZwphIMIZRzxefONCVM6IcWWFnc Ynkz5ZKHP21FJnmxpi8JXkzNyJTuDKUUAePE5KBzHHwUb/NcVPElxieT/j4p9kzXDbY3jEemfsbP y4svNZUndA0KZW5kc3RyZWFtDQplbmRvYmoNCjYyIDAgb2JqDQo8PC9BdXRob3Io/v8AVgDtAHoA ZABhAGwAIABBAGwAZQFhKS9DcmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABPAGYAZgBp AGMAZQAgAFcAbwByAGQAIAAyADAAMAA3KS9DcmVhdGlvbkRhdGUoRDoyMDEzMDUxNDAxMTA0Misw MicwMCcpIC9Nb2REYXRlKEQ6MjAxMzA1MTQwMTEwNDIrMDInMDAnKSAvUHJvZHVjZXIo/v8ATQBp AGMAcgBvAHMAbwBmAHQArgAgAE8AZgBmAGkAYwBlACAAVwBvAHIAZAAgADIAMAAwADcpPj4NCmVu ZG9iag0KNjkgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNTAwL0ZpcnN0IDQ3NjQvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCA0MDMxPj4NCnN0cmVhbQ0KeJydnc2KJcmRhfeCeYd4gwp3M/MfEAIt tNKmmZ7doIUQYhiQWkK0FvP2cz7P6hRSZ95SnKaK8swb5ubu9pnZ8VuVt8e87mveV7Vrtqvd/Zr9 ahXXjKvfec28etU1xxX3vOa8otY195XtvtZ95WjX6rKOa8VVI69V12jjWuMaY15LD7d9bfnQ9JuH +7X1sObd+tXHtfVrLv2W97ivvfWnpmz3fbUWedbUmubTy1frsTTQd7vmbHddeoSHZR2bh/Vyph7W +lpufdW0rSom03PjTKZ5Runhpt/z5mH9nsXDmmdhqkXLpx7uMt88qIW3vRiUTiZk0XU299KD2kWX Dw3m1Ttr6VuD0kvaUQ+WEF2DIc+hg812Fq7BYOGasHCoSXsRhtA8o/Pw0mDysCacmr6lJpwKQMt2 9RV6WPvvS6ffUjNvTaYD0GDxcClswcPEb/OwIsiDLZcGm4f3FV3fbjqj6By/WIgojq1fkZy6eIhk gzq1KDaoL6LYYGnmcc5YMw82qHOMyQb1ckw2ODTzYoOiJRYb1MnGZoMyiM0GhU7ebHCUBmxwDFHG BjVFNjY41pWdDQ4B2NmgyM1gg5o0gw0K30w2KIAz2aBQy2KDcpPFBkVzDm2uieecQCQA8wAA2ovt APfSooTDlftwoZm3HLKUulm8aNBhiARBX8QcTIsHmxZXZ6nKgFJ4NNhXRUKTsu2wquVWsrCtDCp4 V2ZU6bCbXq4BmdpADc5ZaSI0YFAzTx2SYLxqNc2sLRWn2jVF7UOlZt7aXBfug6wSsBqst5weB7Sb RNWiutyMDkSK6+gbutc1QoD0e18jNVlXSgwdogbtGgDQtZShJWqgmTWjBppZ/5EK1yDru9JqTAWk 6/jGIm+03LF02F0vj63gKl000EF2Jdq8AV+JNm8dUtcRzwO1tjQ5AKWUylOSW0MFSpvrImYKRA1U aZKFKQxTYVa2qeiU1qv800CgdeXgHFpdVw5OylNXDs6zVIVqUqKUo9dcnYc181JwqThzk9DibG4F tye1j6xVONet4HJ862SklruIXlcOLtKqKwdXKDLKdQ2K7FddTJ161xGvs1RtaQkgZb9mVrypByqh Oq0uTNdgYUXVJLgKw5oEV9tW3mtm5eCiAqh4XGufKqKZN8Etii/BVaj2TXAHdZjgKgc3pHQdzWbW Ltw3Zb5rBZpGMyucOwmuDmsnwVUObopVVw7uIrhKiT0ILhV+EFx9d0+CqxxUbdfMlPtFcJWDWhc1 TDNvgqud7E1wJ5X9Jrpk/03d74siT7Hp63QnkdlPc2AbnZpwq5xpROkPIqpUVH8QVf20jKSPUSnu okqTiHdp/k7dvgeLPI1kcHzUj3sS2H16iuxUUGkqlN+39rKxwMdZ/MbH5ljpX7ij8tJ0iDi1pp3i eZoZmRY6cI0ojW+tSFEPSqxykmJ9upLiHlQlVWsVzNOgSpEnNBrRhGlzqp03VZ2RVh+nbU1F//Qb lTT5aKd3Kv5B01O6F+Wf9nbqPy3r1oqCBqiKIB9Uuk4/DUpLP7Wb0t1J9NC5aiQOgr7YeSVojMoW +aAmKhWKhsJIEY2Oj9I5R8dHKVJBmRd18tHxMfbpPLRPnWkEPqZONij+Cq18RD8dXz4CH5v2gzbQ wS6aFSOaC2056OsRNFZaR6AYgjpzGkUApboajVgrOhVZD8sHOiIy6HnMTEEOGonKS9L+6M/adaAu hBrfw8c8s+Bjst/EB1kZaI5YovX00thB78THFpkUAvVyrS1QIknBo44p+ERLGa0R0SraOJUC4aVq SLToB4kdOapuT7RGO8JHs6BaEkV25EYW0aKRSatpl3QOqY5Os0YOEC16dJ7VD3ygKmLgYxGteZQU 0aJz52alRyTeRGvS8W+ipRORdCBa9POi9wTNsShUOhxkBNEiz4v1cupSFESLPC/EUKwj14gWeV5F tMjzGpwzeV6DaJHnelE+yPOa+jrI81qcKXle5GqQ57UV0SDP1f7lgzwfN3qHPB8IyyDPx1Ez5Pmg 9QV5PvrRKgOponwJ8nxwTkGej4QI8nwkOoM8l7KQrCDPR6EiyHMJI8kR8nyMhcDBxwyewwe5SkdQ IotH4qnRxgIfO7HAB6tHeUv3JBocvaP6qBFiBnVGsZYGunkOdUvdP2pzUgHyCN04ygpBJMSQVozQ TeT5VLgu6qdGqCLyfFInkzyfWiAaDOnE6slzqVH56EdFiYgkz7Uh+SDP584j1lBUOok8KukWEUme LwQ7OafR0XIoL/p9kueLipzk+SIn8+gpIpDkuVonFiiz0skmeb5KEcw4SkwnluT5GgNNyMzI0swj z9CSZLcStKEYGRFB8nxtIkieq4nKx9FoNxEkz/ct4pI838hyVqGRSEryfNPwkzzfdII8ao4KgHxS 2b1Ro6i3VGZnHYmniPKVRsrYJM83d6h8032IXfJ8T0WAC5dGSNlxLiQ62STP90KokuebSpNHIVJp Tte+qTTkl0ZEayDuqDQ5UIAoFglh9KJ2DQsSjGLgdM+bzJY6RjvijSvhnajhozkLYtFJ9yBuR3WO I6zxIZWmET6msjgXPpaiJ5GNvIRTFJUKCHobFXnDKZpBTZnnUI1cx6TGGcHpOvoTTtFeDeWQiJ1G x8h9RCmc0qsbhORGhPKKChkCFU5RaSoI8kH/VgLLBzpEIB6lzwhONz4WnG58SJZd9IZ+roV11LFk D1cC1KxODRq5BnJNOMJWGVE3GpXrRaH8Olr06OiOYil0TadTqZQy4mrQkMCQeURsZ0VHI3Zus9R3 NWJ5KvSPFBs3D3xIO2uEjzm4meNjNS4o+FiK/JFvkjjygU6SdJGPjvblAladm+qtSNWRwVxYUR8a cbtB6AVS+OipQClR77R4Vio+NOKucgQz+VLnCsyJoQI0Um7U221Yp1Nch+Osnvuwmg0W+JgDi6O/ tddCPKrU8xw+lHDcohiJiOJWrEKrXR4RLtg0QqlzgSTaGnFb42acSPtK5DvaT20H2a5n6sj1s3r0 cZLjhR5NYsupayQiqvAxWGnhY0DEm7CHCJR0cu/lWXVuiKij9iGimFmaWiO8oR25R0v5Ey00t8LN pQ/Jz41XjY9bANHiDlNoad5okagiWueyQP+kz0vFEy3yvMiXIs+LcyryXI7kY54bg/Zf51oxuEeS 8aXb0kW/lUgjMuetn1VcN/GxxWOR50oZ+SDPx924lXKXuDX/0dWDN0roexrJrsjzwe2syPOBji/y fKDfUIMacVkmzwf1usjzQZ7+8pdfvtOV8rqv//zy/Zfv//r7H7781//99Y9fvv/xb3//w4+/+dMf //zlu/+54rz+2+v+1a/+4xf/bPLdz57/7X9f7XfXu9m/adKfm8Rzk3xp8tn223i4//LcrIduhuVG ufLMzfTc9IdulucmP3fzqc3TeG5vaU/j2W7LTzwNaHudn5/5yacRba+T+lM/L0L6sR+jErTXpeBj Gy+v8yluzUvsfMzb68z+2OZ1mn5s8zp/Pu4HXi7U01zoXi7Ui1z41OYp10clXuf9SGoWEtArkvVz AtvXwvlZa3mN+q9/+OEvP/7+x//9y8/dnbwvnjOC7hXaegp+eHCNp3CFIYTCUUJGAQyjAMZrKj62 eV3MPrYxClMYhSmMwpSv2fnYxuAgDQ7SkcQGB2lwkAYHaXCQBgdpcFAGB2VwUAYHZXBQBgdlcFAG B2VwUAYHZXAwDA6GwcEwOBgGB8MRxm8mb/fkZxf+RzZh2KRhU4bNMGymYbMMm23Y/HQZfWbkkNAc FJrDQnNgaA4NzcGhOTw0B4jmENEdIrpVGxwiukNEd4joDhHdIaI7RHSHiO4QEQ4R4RARVrtwiAiH iHCICIeIcIgIh4hwiEiHiHSISIeItBSEQ0Q6RKRDRDpEpENEOkSUQ0Q5RJRDRDlElCUqHSLKIaIc IsohohwihkPEsJTlV5tl3Eue2IRhk4ZNGTbDsJmGzTJstmHzfi95ZOSQ0BwUmsNCc2BoDg3NwaE5 PDQHiOYQ0R0iulUbHCK6Q0R3iOgOEd0hojtEdIeI7hARDhHhEBFWu3CICIeIcIgIh4hwiAiHiHCI SIeIdIhIh4i0FIRDRDpEpENEOkSkQ0Q6RJRDRDlElENEOUSUJSodIsohohwiyiGiHCKGQ8SwlOWb zdu/xHt2L3lkE4ZNGjZl2AzDZho2y7DZhs1P95JnRg4JzUGhOSw0B4bm0NAcHJrDQ3OAaA4R3SGi W7XBIaI7RHSHiO4Q0R0iukNEd4joDhHhEBEOEWG1C4eIcIgIh4hwiAiHiHCICIeIdIhIh4h0iEhL QThEpENEOkSkQ0Q6RKRDRDlElENEOUSUQ0RZopKf0Lr42aglPf+uzv9lDn6o7JXK/MYeX/9D5nj7 UQRH3VrC7qtNN64FT2zCsEnDpgybYdhMw2YZNtuweb8WPDJySGgOCs1hoTkwNIeG5uDQHB6aA0Rz iOgOEd2qDQ4R3SGiO0R0h4juENEdIrpDRHeICIeIcIgIq104RIRDRDhEhENEOESEQ0Q4RKRDRDpE pENEWgrCISIdItIhIh0i0iEiHSLKIaIcIsohohwiyhKVDhFl6YivNmnI8Sc2YdikYVOGzTBspmGz DJtt2LzL8UdGDgnNQaE5LDQHhubQ0BwcmsNDc4BoDhHdIaJbtcEhojtEdIeI7hDRHSK6Q0R3iOh8 BuR1PhnxQ2s+DO1V9fvGOb5+94jPXLvf3z161BGcoIcT9HCCHk7Qwwl6OEEPpwykUwbSKQPplIG0 RIJDRDpEpENEOkSkQ0Q6RJRDRDlElENEOUSUpRsdIsohohwiyiGiHCKGQ8RwiBgOEcMSj19thnHJ eWIThk0aNmXYDMNmXuvi460vPiCWTxy++CzYj73zIZ5vU33zE8lmfGD18QI+jgIfHfrK6uMz/YYv Ppn0H0rmk2P6hhiaRwydjzt9+zO/PeXrS8gjo+kYLcdoOxnFZ53+y+c9OdM4u+zOLruzy/f3uR8Z ORUqrBLl1KhwilQ4VSocIsIhIhwiwiEiHSLSISIdItLqWg4R6RCRDhHpEJEOEekQUQ4R5RBRDhHl EFGWkHGIKIeIcogoh4hyiBgOEcMhYjhEDIeI4RAxLG3rEDEcIoZDxHCImA4R0yHiJxvjB8gf2YRh k4ZNGTbDsJmGzTJstmHz/ldAzg+QPzNyUGgOC82BoTk0NAeH5vDQHCCaQ0R3iOhWbXCI6A4R3SGi O0R0h4juENEdIrpDRDhEnL9m0i3yOv8Xqn/c1/55Dv6fFP+OMvjE8+t3Werto5CdxTsBCScg4QQk nYCkk6LppGhaDdxJ0XRSNJ0UTYeIdIhIh4hyiCiHiHKIKIeIsjSdQ0Q5RJRDRDlElEPEcIgYDhHD IWJYwu7NJt5/jOT/AYaEv0cNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1ODggMCBvYmoNCjw8L1R5cGUv T2JqU3RtL04gNTAwL0ZpcnN0IDQ4ODUvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MjQwPj4N CnN0cmVhbQ0KeJydncuOZEcRhvdIvMN5g85LRF4kyxILVt5YmB1iYSELIYFtoWHB2/N/We3Blqur XP9ipqKrT2TkifjikqerZ3LNq1y59pXtyl2vWkOv7apDb+1+tcbXcbXJ1+Pqna/n1VHZ64rg632F /oyipZKvUzLfL9fUe6PUa57vt2tl1Wu/dgm9xrVz6jWvWioXDgmjS5jaSR0SloSxz3q1tXYNXVfb lIWq3fa2JGi7fWnd2q8a2uDQTdTQrY2qlTO0staq3M+oWnkkWlp5Nt7RylO3PppWXql3mlbeUh2y V/fQxbqulcY1ckWZMtHyatqHhCFhyYS+aK2jviQsbb7tS29o871IkFdHr1eL0Mq9SZD/hhRa4hTt u+GR0bXywC1dK0/c0rXyxC1dKy/cokVlQSvr3trGLaGVN26JdvWCW6JLwC0KUa+4RYZ7xS2hQDbc Eopkwy2xCK1Wjn31kGtHFgmK+tDmeurCIUQ6MR7yUeevoWD3qaCN1MozuVgrLwWEG+hraD/ydd9y 9tC3+55aeZQrCp4fVQJ7Hu2K40zdZFSMSjPalNYYV3R5aygM0fGqblvUaRtT64TYHFo0UncwptaB sjGmhOTiuGKy+amVV0dL76wl6zIcWz4eUya2eB5zXlnkvyHDWaAY6isrK8DZxPGQQ7PpvsdSwnRx OrRWyi8ShH6IwbFSgjY+tF3FVivL6Zna3VhaGXYG+YOdoSTJKS6GEMypNYZAyaWYDwVGqamV90lC raw9Kdu0Mn+KYjU2lHPLwFQVh0GmNeXNSb0mH0/23ZUTk+u6fDMLIW+kJ1jIN7MQKrF8C6fue5YT jyaBMOieZsFHYvBAScpMQFmK3iTkWyxP7n/rvuexJ05nPZpcc97VV8rBWTfr6E9L1tF1XXuZ7KmL nalkmyE7U3DPEBfk6kzWUA7OFAVSvSY5Otk38ZxiaM7GqvozF+q6bnEXiv1cci++nsR98u5WQKb2 vUpgOSSwVeXgqsHFQ8Lm4nktZezF/YsjrtkS5PApzRU4XDm4AofHKXRSV8xW4nCttSgwU/e/gFH3 dK2zcdG5Jg4XZ+tsVWbWwuHKwbVxuHy0Ng5XDqp04gBqqII/xaJqlVbWVnYrOGlI0F9TftxdQZvK Qd2xVlYO7iAg4nWHUmpquztxtr6tYqyV5etNMZvKnQ34U8m4cdIU03uu4+xrL4KrJZQ6Wlnx2Jvg Kiv3JrjKyloK0RX41HetrRuXRHxlSdgS4En1b0R4Uv47IVYmSiLGShFpEmS5SBJR1p5qSUK8sJH6 e652WkcQbSRlHMlUC+GZCxuK+sXua1GUJGFDXgULSZudKiurNq3rlHaSCO/pitKW1JDkQ1aqtVVI CiR2r9ysteNc8SKJsG/62Em0TSM7mbaxQaqtgg1ybRVskGyrYINsWwUbB7eCDfax6JR1AROtsi6t v06v3KBCs2zsfp1uWRJ4tXKrgp+qLEk+WbRHtSqtTMdsaiCSaKsdzuiZjTZKp5EkPy26ZqORLtpm o5Mu+majlSwaZ6PuLDpnA9JF62zsdzVsLCGo/JG0taPVsLEF2JIftLtKdk0k4bMUWTlSekvZK0lc ULrV7Rs5d/o+d95p/J07F5zqcNy59i2JO1cOV30TDWyo7F5UVQVGd7g6NmgqYFw79UZJjCQyV2CD Ha04w8UixbFBjcP/kkTSEvA1qHIQJQlPKp9rUOeWElqSIr+U0cIA72q3mlEUUSYhScqFJX+p2CgC TB+S2GkywlBDVmIjlXqqJJIYXFZigwaIX4VVQwMbZ/cDG3h2jXoGoUXxkbTluzWwQROhPatyDN6T taz4ZTAoVWWTqpSkRiWUlyQtVpGN7NQ52ZYk+hd5nnGqmGxkiupFnmfqbhZ5ngx2izxPpoBFnict Y5HnSX1hjzWha5Hnyap4XdkmahZ5rrFTNshzDZCFUomkv6nqVcOfbJDnchD1UzY0rckGea5RLKmp kvops7Kh2YmqWpDk7UWea+qRjTP/atMUX0nMlYs8H0wjizwfdKxFng+qG3mopBXVizwfx+Pk+cDj mzxXU1Q5Jc/VFVU9yXO1RRVL8lx98TYTS9KqmzyftJtNnk/6zSbPJw1nk+eTjrPJ80nL2eTvhBfy SxIVmoyfdJ1Nnk/azib3J32HAVeSvL3J80lebfJ84tl9xuOt6O/bfCwv7jMgQ/smz1VkpEGer7N7 8lxFgS4kG0p2NGRDqasdkOdKSa6TDaUaTWoh0ZPIcyVEo18h0XHI8wXtmzxfTHlknwZYrb/J80Wf YI91UR9o6pLYPXm++JruKUnx3uT5Zrzb5PlmvttxJn0RscnzzYTHnCWJtkqeb2Y8GpukW9OUxJS3 yfPNmLfJ882ct8nzzaBHPVYkdf/0FUkiYpPnm/ljk+eb/rTJ801d2uT5hsdNnm/2welIEkQoz1Xa IUL+0j4hQvuRBBEiQOcTiFCeS4KIwZmFsY86Kwki5NdW6Edb+5YEEXpfrQIiBjboR3tgg360Jzbo R4zuOvrIn3tig36km5FEPdwTG+QBh5BWuP89ORrRj8jcdrqpbloS3XTLTjvddCvP2+mmW3neTjfd yvN2uqmcg3QmDtmgoEri9BUQsbCRELGwkRCxsMGhi7hLgoiNDcY5xihJELGxQYXfnHQrmb0561Yi uvVVk8tlQ/6XBBGbM97Z/eaQV8cZdiQ1MqwIdImUUPTUYsmdolBJPENQOSdqskKxRDzjTcFS9jMv YSrP4FKwxdlPIsY4KUjEGnPlOTFLpAiVirXTZUrF2ikvpWLtcFWEQeusw/iFSGcoSnztkZJAB5ZI zS9KuaZWi7XKCbadqa1xhu2kMQdhiWceU/q3HiQoJzqJZ9LilKxcxxrn5H6eLBROyp3TqESscXap HFXlHNKlnPPymXvKOTGfhlc4M/dT6Qqn5g7iEmUtuBeJgUiTKpyddZKsZ3pEPFvn/KwR8ly7EG/j paxp52eqLIhnmIxzQqfOUCoknhsKrOWJRWCNJyYSscaBWyLWOJ4xokpkmJeItTPckbkSyfaSWDvl nOlY4rjNs1fLcjBKngmUg5EUNDYcjBRHiQcj+aXl7YZUISQejCgR2Q9G1Aj5H2sUiYyzdapExsGI MqEGjRrVIXnCcR69tHMqlYg1DimVjUiknRVqRZ55BX9rDjyPbqgWuc9ilIsBjhIr4jgzuKyNSnMp VIxRmR54jNJ0fMMwNUNnDqxRNMYtLFSN0c9kT9kY0W9jPOKZ2SkcIyniPOiQSJculI7Bo43KdNAG B2FmfkQKb6F6jDNBF8rHOKNToX4MeuYXX7x9rRPvVa4/vX3z9vXbn//743dv33z693/+9umP//zu X29f/eVqf73evv77JUp10Zdf/v53v0GnXzrFXzp4XOuuNo/Lburf/Pjt979a4bPC21fAe0ftrlVV jCfWPlCrntp9z/BI8Dff27yj9oG1eGLtA7X01Ian9izcd9V42Kpvn4ett9f1/rrPKw/i9PqYwz98 //0Pn7799I8ffu3yY6K+L9neX/v7a7y/5nMTdze/DZ16n9MnSvcpfaLkZG/tjtJ9Pp8o3afzidJ9 Np8oTUfpPs5PlBwimkNEc4hoDhHNIYLJiO5zMQE5nlRj1PVq8pqFurMDTUtqo5qOOk/or+5ERvOS mq4Gn3B2oAlKk5NGi3D4C8dr4dxlOvylw186/KXj+3QqUjoVKZ2KlA4R6RCRDhHDIWI4RAyHiOEQ MRwihkPEcIgYDhHDIWI4REyHiOkQMR0ipkPEdIjg5zL84ObSSW06nuQROz8ZuHiiy2NvZw0eM188 qObJ6bUdP2/Hz9vx83b8vB2/bCfztpN528m8bZ0XbjrRXhmeDJ1u6ISh8/5o4OJRxHV+anedz7Nc POPiAf3FI3mey148f/voVuLdxkfn7JuCztm73NG6n1X7A1vzN9tqd7Tuo/BRWB9rfRSkx1ofhemx Vj7x/Ae973Z859Mr53WW99f6/nqWe8zN4+M8n5m5mRjvr/P5kg9PNq8pOdC3j5z5UGk4StNRWo7S R+nysMoUR8mpgd0qgg4R3SGiO0R0h4juENEdIrpDRDhEhENEOESE1RcdIsIhIhwiwiEiHCLCISId ItIhIh0i0iEirVHJISIdItIhIh0i0iGCT53yoeSLDwfHxcdtnbscfIr14tN2RWdTnTQ/nxtfWmY6 sZxOLKdzl9OJ5XRiOZ1YLie7l5Pdy8nu5RCxHCKWQ8RyiFgOEcsh4qcwxStzpKHTDZ0wdNLQGYbO NHSWobMNnZ9+YPmakkNCdVCoDgvVgaE6NFQHh+rwUB0gqkNEc4hoVm1wiGgOEc0hojlENIeI5hDR HCKaQ0R3iOgOEd1qFw4R3SGiO0R0h4juENEdIrpDRDhEhENEOESENUE4RIRDRDhEhENEOESEQ0Q6 RKRDRDpEpENEWkOlQ0Q6RKRDRDpEpEPEsCbLd51hHDFe0emGThg6aegMQ2caOsvQ2YbO5yPGS0oO CdVBoTosVAeG6tBQHRyqw0N1gKgOEc0holm1wSGC3wH5xSccb59XvLsSv3J6W+rDnx/fbH11zbij dT+b7yPJL7o+0rqP1xNb/B5t+fwD1g/c9Phntvx6rq47v5x7e+3Pl3x8aHhJyWoATtZ3J+u7k/Xd yfruZH13sr47WR9O1odDRDhEhDUTOESEQ8T5pLEGeo3nGrb/Pzq/NI04fknHL2kNS45f0smUdDIl nUxJJ1OGkynDIWI4RAyHiOEQMaz52SFiOEQMh4jhEDEdIqZDxLRm6Hed9cqUZeh0QycMnTR0hqEz DZ1l6GxD5/Ox7SWlX3zk01ngFx8SvbvAevwhxflk309m2fGzXxd8jWcrCZwsaE4aNCcPmhPC5mRC c1KhObnQnGToTjJ0h4hu1UWHiO4Q0R0iukNEd4joDhHdISIcIsIhIhwiwmqVDhHhEBEOEeEQEQ4R 4RCRDhHpEJEOEekQkdb05BCRDhHpEJEOEekQMRwihkPEcIgYDhHDIWJYA7VDxHCIGA4Rwxqqbzr5 0i/LGzrd0AlDJw2dYehMQ2cZOtvQ+emg9JqSQ0J1UKgOC9WBoTo0VAeH6vBQHSCqQ0RziGhWbXCI aA4RzSGiOUQ0h4jmENEcIppDRHeI6A4R3WoXDhHdIaI7RHSHiO4Q0R0iukNEOESEQ0Q4RIQ1QThE hENEOESEQ0Q4RIRDRDpEpENEOkSkQ0RaQ6VDRDpEpENEOkSkQ8RwiBjWZPmuY/w7FC/pdEMnDJ00 dIahMw2dZehsQ+fzueQlJYeE6qBQHRaqA0N1aKgODtXhoTpAVIeI5hDRrNrgENEcIppDRHOIaA4R zSGiOUQ0h4juENEdIrrVLhwiukNEd4joDhHdIaI7RHSHiHCICIeIcIgIa4JwiAiHiHCICIeIcIgI h4h0iEiHiHSISIeItIZKh4h0iEiHiHSISGuyfNcx/iGAl3S6oROGTho6w9CZhs4ydLah8/m04PxD AK8pOShUh4XqwFAdGqqDQ3V4qA4Q1SGiOUQ0qzY4RDSHiOYQ0RwimkPEz37b6PavoztFs//8X0e/ u8D5P1Ie1bYnuDz+COX5z1jKT5+hfG3vDtzdgTscuMOBO5wghtX6HLjDgTscuMMpd+EQEQ4R6RCR DhHpEJEOEWlNQw4R6RCRDhHpEJEOEeNXRPwPj0MoYQ0KZW5kc3RyZWFtDQplbmRvYmoNCjEwODkg MCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gMTU0L0ZpcnN0IDE1MDIvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCA0NDU0Pj4NCnN0cmVhbQ0KeJztnN1uJbeVRu8HmHeoNxC5f/gDBAEGkwQzCGIYbgNz EeRCsRW7kXYr6MhA8vZDVq3NVoD0WGKQcdytG5FHKm7WqVqLR6qP3Tm1dqQjp54O19nm8aXMjhzZ ++zoIVlmxw4pPjt+aG6zUw6tc0Cvh4nNTjusnsP74TKOyWkUbml28lFUZkeO0mx29KhaZseO2s6D /Wh2HlyO1s+D69HNZ6cdvZ/HzJPyMevoXmNHb770OntjkJw/yOPtSNHZG4donhPlUUlLn73x0mTO kMcwq3OK+Z6uk87jEG+zqIxSReccMl6WNueYw+p5mjLK1z7nmO++2ZxDRqnW5xwyXnafc0g9JKU5 xygvyecc0sd1PU9c0+iVOYfmQ2SeUB5XSqTOOXRcf50T5XEaovPqZvVDTOYc4/qJtTmHjjlc5xw6 5vDzeuqYo9icY5yulD7nGC+l2pzDxhwtzTlszNHm/c825ugTgDyuuvRJQB5vS9O8sOM6jd5kIFsb DMwLlq2PXj1vQDpU5oXI4/ao1DnHePuqOucY5VXbnMPtUDtvvA+SrM05fMzhJtdtVO9zjnGZtNic Y5yG1vNMy5ijnte0jDnaeffLmKP5rDdut/Y0R4zLqb2cI/yw6+xLGb3zOpfB64nAuKOjdxIxvgwg 5nHjspucRIy3ZXoSUWX0TiKqHmYnEdVG7yRiHGx+EjFuj/lJxHj7Vk4i6pijnETUMcd19kMJaycR o6i1k4hxG62fRIzLZP080yGKp5OI5qN3EtHK4Sd6eUzu+SRi3G6Xk4h2mjfnOJ0+iRhWu55EDKnc TiLGSbqdRIwv7icR47J7Oa/zUNvLScRw2+tJxNDP60nEtLudqp16TyJk+O19EiFDcO+TCBmGlzSJ kHGjSppEDPqPMpEfvTJ6kwgZlheZRMi4eUUmETI8H+Khc9FJxPDlKDaJmCtSGRdm9sYc4/Rnb8wx Jpm9MUeZd394dZR6LgXjIpZa5hzjJEubisv4MpQepcZRfZznXC4Ge2P0qFfSuCbzrY0TGnOMWQeM 5ZhgDBZHZ3yn+lypxmm0+Z25qjUfpzGhaH3wMd9Jt3HhxnUfV2hcmfE+xhsfS8P45jjPNFfWaf1w 8lx5R2fQOVc5Gbqc4oxeP2/FGGF2vtVhs836EwMZt2xekvHTMtk9V5FSxwrys5/dfD7fWzq+uHl1 8/nNl3/9093Nq4d333/18Ms3d9/d/Pq34wb87rj5/JuBwjzq5z//9397yiDZGaQ7g2xnkO8MKjuD 6s6gtjEoblN5xhjZGKMbY2xjjG+MKRtj6saYtjGmb4zJaWfQDgl5B4W8w0LegSHv0JB3cMg7POQd IPIOEbJDhGytDTtEyA4RskOE7BAhO0TIDhGyQ4TsEKE7ROgOEbr1cbFDhO4QoTtE6A4RukOE7hCh O0TYDhG2Q4TtEGFbv0HsEGE7RNgOEbZDhO0QYTtE+A4RvkOE7xDhO0T41i+VO0T4DhG+Q4TvEOE7 RJQdIsrWb5aMaRt/lzxnjG6MsY0xvjGmbIypG2Paxpi+MWb9XfKsQTsk5B0U8g4LeQeGvEND3sEh 7/CQd4DIO0TIDhGytTbsECE7RMgOEbJDhOwQITtEyA4RskOE7hChO0To1sfFDhG6Q4TuEKE7ROgO EbpDhO4QYTtE2A4RtkOEbf0GsUOE7RBhO0TYDhG2Q4TtEOE7RPgOEb5DhO8Q4Vu/VO4Q4TtE+A4R vkOE7xBRdogoW79ZXmNK+tsxyphXd189/P1AZx5w1HQ1+WrkavRq7GrK1TCgn027xrVrQLsGNL+a a8C53+KLo19H9muGfh3Zr9L9OrJfpftVem6kuFqhVVqjddpKe000d0lcbaZlfGZ8ZnwutIzPzCuM E8YJxwvHC8cLxyvzKccr8yjjlPNUxivjlfNV6hh1jPmNekY9o55Rz6hn1DPqGfWcek49p55Tz6nn 1HPqOfWcek69Qr1CvUK9Qr1CvUK9Qj0QmzsPrpZ6MJeBLkNdBrsMd3OvwdVSDwLnLoOrpR4szv0F V0s9qJw7C66WevA59xRcLfUa9SA2g+zcSXC11APeuYfgaqkHxnP3wNVe9QSe576BqxVapTVapy20 lbbRUg/OBc4FzgXOBc7n3oCrpR68z10BV0s9oR78C/yLUA8PRKiHD4IPItTDC8ELUerhh+CH4Ifg h+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH 4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifgh+CH4Ifg h+CH4Ifgh+CH4Ifgh+CH4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KH 4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KH4ofih+KF4oXiheKF4oXi heKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF 4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4oXiheKF4YXhheGF4YXhheGF4YXh heGF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhheGD4YPhg+GD 4YPhg+GD4YPhg+GD4YPxeWF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhheGF4YXhh eGF4YXhheGF4YXhheGFwb3BvcG9wb3BvcG9wb3BvcG9wb3BvcG9wb3BvcG9wb3BvcG9wb3BvcG9w b3BvcO9w73DvcO9w73DvcO9w73DvcO9w73DvcO9w73DvcO9w73DvcO9w73DvcO9w73DvcO9w73Dv cO9w73DvcO9w73DvSj34d/h3+Hf4d/h3+Hf4d/h3+Hf4d/h3+Hf4d/h3+Hf4d/h3+Hf4d/h3+Hf4 d/h3+Hf4d7h3uHe4d7h3uHe4d7h3uHe4d7h3uHe4d7h3Pg+czwPn88D5PHC8cLxwvHC8cLxwvHC8 cLxwvHC8cLxwvHB8cHwo8Fvgt8Bvgd8CvwV+C/wW+C3wW+C3wG+B3wK/BX4L/Bb4LfBb4LfAb4Hf Ar8Ffgv8Fvgt8Fvgt8Bvgd8CvwV+C/wW+C3wW+C3wG+B3wK/BX4L/Bb4LfBb4LfAb4HfAr8Ffgv8 Fvgt8Fvgt8Bvgd8CvwV+C/wW+C3wW1i/CxwXOC5wXOC4wHGB4wKHpcZr6sNhgcMChwUOCxwWOCxw WOCwwGGBwwKHBQ4L63OBxxI8sj4X1ufC+lxYnwvrc2F9LqzPhfW5sD7Pf55wtTw0gu8K3xW+K3xX +K4pHjk1WurleAZFPfiu8F3hu8J3he8K3xW+K3xX+K4SD7WoB98Vvit8V/iu8F3hu8J3he8K31Xj KRn14LvCd4XvCt8Vvit8V/iu8F3hu1o8dqMefFf4rvBd4bvCd4XvCt8Vvit8V/iu8F3hu8J3he8K 3xW+K3xX+K7wXUs8F6Qe63SNR4qs05V1usYzxnjIGE8Z4zFjPGfEj7oeOFIPPyp+VPyo+FHxo+JH xY+KHxU/Kn5U/Kj4UfGj4kfFj4ofFT8qflT8qD2eiFKvx6NRno3iR8OPhh8NPxp+NPxo+NHwo+FH w48G/w3+G/w3+G/w3ySezTI//Df4b/Df4L/Bf4P/Bv8N/hv8N/hvGg99qQf/Df4b/Df4b/Df4L/B f4P/Bv8N/hv8N/hv8N/gv8F/g/8G/w3+G/w3j6fS1IP/Bv8N/hv8N/hv8N/gv8F/g/8G/w3uG9w3 uG9w3+C+wX2D+wb3De4b3De4b3Df4L7FI/d45g73LR6+x9N3uG/xGH49h6ce3De4b3Df4L7BfYP7 BvcN7hvcN7hvcN/gvsN9h/sO9x3uO9x3uO9w3+G+pwgMqJcjOaAenwudz4XO50LHi44XHS86XnS8 6HjR8aLjRceLjhcdLzpedLzoeNHxouNF14g2qIcXHS86XnS86HjR8aLjRceLjhcdL7pFZkI9vOh4 0fGi40XHi44XHS86XnS86HjR8aLjRceLjhcdLzpedLzoeNHxopcIdaiHHx0/On50/Oj40fGj40fH j44fHT96jbSIevjR8aPjR8ePjh8dPzp+dPzo+NHxo0dghR89kquIrvCjR4YVIRZ+9EizVpxFvfe5 VgRbGDI6EXGtjGuFXCvlQpPRibwrAq+UonJEXymyrxThV4r0K0X8lXJUjiAsRRKWclSOTCzJCuOi csRjSaJyBGVJonJEZikysyRROdKzFPFZ0qisK/CLyhGlpcjSUoRpKdK0FHFaijwtRaCWIlFLEaml yNRShGopUrUUsVqKXC1FsJYiWUsRraXI1lKEaynStRTxWop8LUXAliJhSxGxpcjYUoRsKVK2FDFb ipwtRcCWImFLEbGlyNhShGwpUrYUMVuKnC1F0JYiaUsRtaXI2lKEbSnSthRxW4q8LUXgliJxSxG5 pcjcUoRuKVK3FLFbitwtReCWInFLEbmlyNxShG4pUrcUsVuK3C31VZBTXVFyDuNWqLxS5RUrr1w5 h3ErYX4UMUfl92FzVF5x88qbV+Acxr2Pnlf2HMatFDqHcSuPXoF0DuNWNJ3DuBVSr5Q6h3Err16B dQ7jVnS9susVXq/0esXXK79eAfZKsFeEvTLsFWKvFHvF2CvHXkH2SrJXlL2y7BVmrzR7xdkrz16B 9kq0V6S9Mu0Vaq9Ue8XaK9dewfZKtle0vbLtFW6vdHvF2yvfXgH3SrhXxL0y7hVyr5R7xdwr515B 90q6V9S9su4Vdq+0e8XdK+9egfdKvFfkvTLvFXqv1HvF3iv3XsH3Sr5X9L2y7xV+R/qdI/7OkX/n CMBzJOA5IvAcGXiOEDxHCp4jBs+Rg+cIwnMk4Tmi8BxZeI4wPEcaniMOz5GH5wjEM4n47w620Tza NvPlu7u7L+7vH26+uH9z95vbPx0XGTef3767e3v+9LgQuf6F9VXm0U8/u/vLw6/v/nrkTu1fjWJv 7x/ubj6bX3759uv3L74cx/7+/i/X1p3/urv9+u7d1Z9jov/fb9+8fnv36tvbeYrzG//xdlS4fXh9 /5bX7x5e/+F2dM5X/3P/7o+/v7//480v7r/6/rtxUud3/vzt3d3DPMuHm9/cfvXu/tHr//x2fH30 +hevb9/cf/PoG6/evP767tGx1zzjsG/e3X5386vX33z/7o73+tn33/35t+OShClHJNdHRHJHZBFH PGQ94mnWEX+mH/H3yRG/cB1rwT/eL/DHWr7lWMv1+Z9xXN3z/5q4uud/5nB1y7EW13qspbMdLJUX Ek/bNRVPB66Tjb9FrzOOvxiuJn5f5E18aLvT+hCi/dD2psX1Zhvj45q9bGu62lg4/CJhchCr98tW J9qPeqsT9zy2O71sezrbj3vb03XPV42XLVBX+1PbAvXUNrZI2aN7H9unXrZNXe1PctsU9zK2Rn0q W6g+1H6iW6pUHrEQ26d2t1n9o+1Tt2c9t33ZznW1/9ztXMa6aayjVh/9XdCjxqe65eup7Ue6Jexa l2AhfvaBbWJPbH/8bWQ/1NYntu2Zbf+/27WN7UPtx7697Yfa/rx2bZN7avuPbadzPleczxUPX2IN 5fPEexyPF7E9LaVHrkXtp27R+xdpX7YI0j51i+Bz27zZ/jhbEEuJlutcgue4/9wnPt9KffR7bYSd L/sYP+p9jHGz45s/0U2Nu+2Pvgnyqe1PZLMkK13L8frRE7DY9vDP21H5Q60+sX3ZiXm17FxD1v/v nZitPPpTOL9sz6T9JLZnxk2PvZkvezXpfGJ7NYODNfIT3Lj5rI48p/OyAfTvbQAtj8lbyL9sC33Z FkrnA9tCg5iXPaIve0Svzg/tEYUYXUV7fPd/AQ6L7dMNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMjIw IDAgb2JqDQpbIDYwMCAwIDYwMCAwIDAgMCAwIDYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAg MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwIDAg NjAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBd IA0KZW5kb2JqDQoxMjIxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ0MjU5 L0xlbmd0aDEgODUyMjQ+Pg0Kc3RyZWFtDQp4nOx8CXiURdbuOfV9nXQ6WyeErIR002SBTtjX0JAO SdgiECBAgixJIBBFNBpARSFxwSWggCsKI4y7RrATUBNACANuKOKCuM4ACjIj4o4zIyTffau6OwTU 0fvf/7nP/9zrd3Leqq/2OnXq1KmmG2Ii6gDQqVfupNEjQ+oGNBL3ziVKeHRkbt6IKEvoZKJP3yAS F40sGD8p/r4XzhAdjyUaNHHkpMnDA0y7fiBOvAyNHBo/qWefcOfMDkTciFZLpuSOLerTMDYVbdUQ Rdwze0Fp5Z5V89BWRhTKfDd78ULb02HliGfdQxS4cm7lvAX1kQP6EPU0E5k+mFdaVUlOCkL/O9Ce dd5l184d69k/l2ikjejqNyvKS+e8+3nApWjLhfwBFUiwbBaI80K8d61YsPCabqc6PIyxY7xxcy+7 YnbpyomVXYl2foP3sgWl11RafwrujvJrUd52eemC8ts/uCiU6INCIkte5RVVC1tTSM5/vcyvvKq8 csfGVUlE/Y4gv56k7Eyduv3tTJp5VrjrtDkIw8bzSPKEUhm+9NCEVCPwp9X6GbMTr0GqvHwQBjzV 8gCEvt8INN7Rz7Tl+B9NpoR4aBRi8hFkpZ5yJNpR9KtS9P28mkxkNj1o6osmE72hVkpzRaTJJAK1 ICFMQtePUHejma7JUSPAUzg2x0ZusmnL9BOty+RIxDw3sWEYqF2m3yVnSrq+n+bJ0gjlgE+yhbbT MXArHxUzOIM+pdXspG28nz6n48ipoz10iPZyJL1LJ7gD7+dBVEbldA93oPcpgqZSNT1ERbSBamg+ atRRMWKx1IMqaAu4iJpoFU3CPJOpgGbTe2IofYZ1PYbed9BqykCNZajxPi2FHF6krbQLo+lIl9Ea 5NUg9wDdRRfTEBqEXu+lU3yvcPE9KBMBqkb7sqdJaOkc1aGel7b5SLbmp4t9dJYnYBTX0yq+Qo1a iYW3cxb6icRYF6ClMroHPI080NcB9AQd5TROoaGYTSV9zicxz9upHmOZhJlVo54cUwU4ktYY32L+ H3MLJ6OddRj5bEg+kOaLQgqjDnQGknTSEbQVgTlILoL0vFShaJKibexCny7OFMT1vI2H8EFIbwr6 bIJk3qNTwmW00A1o/V70l4HVC+PFPJln+zROrstStClLV2OekpcZx8Ve9Lla8UN4b0HvNYpr0LKf e0BukisgtSLUkyzbWYUVkTwJUpSMUSiuxgynQV7PcQKtpbfoOuM4RyIeRoKX+lkiPQVZPUCrRaLc ICJRJEr0sv/hpciVpb3b4lfiv/6Ief4IKNzHm7HeKdh7GkaSTY2YpcD8NnA4xh2EVUEy1ms78gRf wpfQZuiGlJFfcn4peSW1tI3nQ3fn0zDIeXs7fhE1tkKzdkFWfnnW+OTpl6lXnkvaZOnnZOi7XNP3 Vf+R0LgCqsSulOl+Rj70y0W3YfQhKBdMCcIM/djOZnIbZzGfbONHmImD9J3aqeXo8T21S4shDblH 78Y45kBv9mIMs9FDIrmQO5vKsGoreDtNZZ1G8BRaQVtEODQlmwppDOdh7Psw7qlYwzxaxGmIrQEv UppcDWpSelxHDsg/gq6mdPQiRyCtxRgqMs7QVZQGuholYjEi7yiqMYp0NY5i6oaTS1drNxXaHY3x robsroNeTUMYhbdM0DXUl5JQfw1YWpLHMf6rMc+xNILsoHy0/jjdSF3pJtS6E7WlPXkRFmEr9TW+ wopdgxrz0fNa7PDeVCGSeQyP5tGiK78AWstrEcsXXcUAaPVa4dJWUBO/Ad1+iDvSI7SRr+bRWN0K rsJabaVmWI3l2H+daDzi39FP9Dd6mF6iZ+gN2ohVXo7cXfRPrO/fUf5epZ/NyGtS/JYif8vlsLTn 2l2u2pQttrXHV2NFtiLlGZHDK7mEu/Ir/AqdEdhU/AnfD/6EHwHv44/5Q54Dy/YDV3MhD2QzB3Iq 3YfSn4sx/DZ/z6GcyhFY2XP7b5/QBAuNH+ZHuY4X8ESkrecyLoHuJasiwRSgSloxDvmshuQ138lm AcnnaVjKb+h+8Dco9RD2AggjkXbam34/38TvYeRP8j6UT8Q6ONtCf/y/4cHY16sTjigKu9xCr0NC 90Pzm3kH/0uNUxkLxH3z41f55ra5+tN8c/1Z+BBPkKxkIDnAK5u28MInxCcfX8jxWN92oV+20N5D KtyK/S7zzXSlChu4QaW3Qqvl+/cYq3wwHzWXp2mxep+HPXoj/ZnWw5KARRxWG3pBpXQRJPIxdCMU GvAIJDED/oEJ67AP9B5W4ybkyl7W03r+gk/zaezv+fwc/8CfcYqYDal5sG+yKYWPIOUz/op3o8VX IIWH0Nf78BvepP18KXy2O2k/7VDe3L10OzQwgr6Ctu8AvUIPwn7cwjNAO0E7+EE+fE7abVKQmiLl nKj0gXgkqIi+p4/4X1ivN5Ek7SnsJsbwAHbtXn6dm2EHX4LmNrETOyOWZ3KutpReVfU38Iv8GO9R e9ypKE2R0UZ7IYH27+doOEqD287P38vtz45f4uOwSvLM8J8Ov5cvPDna82zld3hZjkH28St1uCdH 0WkwbCHscxTs6DWK54PKUF9yATS7G2yrPO+GY8xoC/qwki/mUbwLNErR1WoXSU30a+MFu+j3hr+6 235jF/4i3w9e126H/hpfuHN/Ywf/bMf+Vih3tJ9NIPn4raZvl/8s9FvT3wjbrMOvhH5r8Vthmzxh VeB1fq/iCMGvtq3rr3E4dqnPmvrW32uJZDjNS/LEwW2iCKdKM28UFpxyUWQRCaITz0dKFb/BC0Gb qLe0CiKBmy9cBb/UYckblPQ0nPTr6QW/nWvPaC8TvtxyESkSMIY76d8cqnyR+5Wv0hF+UCT0bQK8 Dx0sveho5GYoliXq4B/LlBp6Djv1KnRbg/tIR+ymz5R3tx1WsCNSpWfnwu6KRr0tyrPbC9/pLlhW 6S+7sMuGopT0lP+s6GN4I3uhc3dRBu40J6gcNwozyILxmLFfA0EW9IWdyz3b/EC/zyl79tuAP9NK 6Iq3rsyzYATS27zQ9nhtzLbzPFDJfjvg9+7rQF6f9hY6oUbsb0Xu+LTz7I+0LRW4w3VXHtiliMn7 3Dh1wlfQraCloDp6FGUn4zyaRy/Cl5Qe8nbcKiMguY4+6WWixDicMmuoSlEdJPQJ8E7QAdyzJL2N 0cn7YCPWQ94Js/F2CjezlbQJGrYVXIder0OvcgZNdDk8uxqVY/FRWVvsKdwmI0ELOIO7gzLo7zgN Gb4Rbm3cIsJEGO5bbnULXEJLxACcKDuALpxTO+RZoEqsVeTijbh59eWxXMz92Y13F25/QNyB5N0t C3tnCLtQ+z2EmSDZR7IWp9rytnDiXGtyrrIO/PltfFD1aZetqZpp8nMR770QcnsCPlwY3p7mzrxH EPrbgXGmoXWzrAeteg8tes+3S/kF3wZKxVsvLuAUjuHBrGEl3oYUhuAE6O+dJTR4JLxZAq+hPjir 5VqvxDpsALlxI1iJU1munFdXFkHWTbiJ7FF39hugNTtUbCvq1dG/oTtpeM/EPr8PfvlgZT8j5I0L FrAbzhUZXosdmYgbhewpHqsruTP8ezfNQr0ozFTWrkabWyFllwgVocSgNLQ7leaqnZtM/bBDV6uT KwZ+v7yRW7CPpmJ/yxvcKtjdEJA8xUywVZKPt513Dtwn5vtIloilJM5s20Vy98k9gJNP1ZD97IEc ZP+S/TviBnhc6dgVfpYtCbS1EDvDihnJXT0BdtCi9muUkhPGBV8lnz/BDaQRvskHPBR4DPyYNpo+ pSiewsuwjkiho/C2HsN7Hd7W4p34G9xSeoLkGv+Vr/NZC78N89qxOnnT/xn/kieyAXbz3K32fJYe irQg0vr4uf1nBpJjoRV+9n+G0P6zhPa8RdnKjDZL1P5zhgvZ/7nDhZ8/tGcrdEay/44sPRbJ0kr5 P6eQPBn1ByFtNeZadgG1e4wEI4HbUfs87IHz6YJ6IpSPwyrcp9hywUeBUm/XtCNZZz1or7FXnU3t iYyFoATssfOJjC+NKaBloAQjUI5djRFj4RquU+1OVffyRb81x9+ay+/pux3JXSfv7hHYowMgB+hl u7aFj+Yrnz8NFjhKSVd+OCo/N0CeN6dNAvtAMpwNkjXh0cC6pbUbj79Nl0iDVXgAuup/5GeKKbBv mfS5/EwA99mHsW+OwR7vgCUegv738z98JC3saD4Ge5qJG4IsFSvCfO1ILR2C+0cyNFF+iiBpNb3A jH10AFZKnl43guugbQ7uqqT/ON0EepymYESxOIXkiXUKtTzIW4u3+chLhM05Sodw+47gaFjjGHU7 nwtP/AzH0EH6Fp5SJCzDRTyAHRxMf1W7XKN3qBV2uxfsdW+QBlueBhs+BBbdBU5B7hC0dRH0+zRq FlMLPHMbTrkC2PkYpMmU3jLl3EprNvhVt/BdfC3qzsC9cKeIh2/vv9f6n0wKhd3qjBM/Eb5OZ+Qd pgaMyAkZZbWVkh5ptbSg8HxHgiKUDarBzj0AGVyjrcA6JPBGlHIoL0vSWmhtE2zZ1byWPsFd8FN1 q9gPXfgI4/zvukW0v6v7/MoL79+/6tX7PfULQv99/MJ7+c88a78nfuFtg3Du7QTKE30dzrtiaPsp Gsdx8DkJfuYxaN8UGgBchhUNb/uUPEPpYj10qRzlp2FNlmENBqHtQPX5o/xXhZXQjsEcjltwb54D 0uApFIhevAhUBu/YhfXbC8/qPaRHQXeiuJDHKe0ZxR1wWz/NVyrqxzlSs/hLaNh+5T+kQPv6Y03l uViNU+ECK4OWvBTipQstG5tA7dOlx/4idkd32PJwdRZJD6IQYThi0obXKdquPrHz23Z5DuPk5qle ot20G+uLvYu5y726EOUr4ZsUKV9bnmLy1JKngPd2ex2/zEdw83Apr60G51QNV3s/RedruAK29BpQ DSfjxKpRp8oinMgVkLmJ4iGJDD4KWgo6qcjl1wyWj0nTGE4lxZq+DG6mf5kNnPoBRisFURDuFRaF wRQMhF8CDAWepTAKBYYrtFIYMILC4XVEKuxAVuWBRAA7An/CPowExlAHYCxFGf+mOIoGxitMoBhg J+C/sGdjgZ0pDpik0EYJxj9hGyV2oU5AByUaP8J7kpisMIU6A1MpyTgNX0diN7IDuwN/wM7vAkwn BzBDYQ/qanxPPSkZ2Ethb0oB9qFU4ztYvO7AfuQE9gd+C81OBw6kDOAghYOph/ENbI3EIdQT6KLe wKHAr2kY9QFmUV+gW32Wm039gMOpPzBHYS4NME5hXw0EjqBBwJE0GDgK+CWNpkzgGBoCzAeepIvI BRyrcBwNA46nLOML6JjECeQGTqRs4CTgP6CXw4GTFU6hPOPv0OCRwCKFxTQKOI1GGyfgl0icTmOA MxTOpHzjc+zzi4AlNBZYSuOM49g14w35CbzEOVQALKcJxjF4txLn0URghcJLqND4DPetycD5Ci+j Kcan8NenAi9XeAUVASuBR2F3ioFX0cXAKuAR7IvpwEU0A7hY4dU00ziMXVECvJZKgUuoDHgdzTb+ RtfTHOBSKgcuA/4Vu3AusIbmAW9QeCNVGJ/gzJN4M10KXE7zgbcAP8at7DLgbbQAeDvwI6qly4Er FK6kK4B3UKXxIazllcBVdBVwNVUBcSs0PsD+XQi8W+E9tMh4HzZhMfA+hffTNcC1dK1xCCeuxAfp euA6hetpqfEe/YmWAR9SuIGqjYO0kW4A/lnhw3Qj8BG6yXgXN1aJj9HNwMcVPkHLjXfoSboF+BTd CnyabjPeho25HfiMwk1UC9wMfIuepRVAD60E1itsoDuNAzgnVwG3KnyOVhtv0vMKX6A1wEa6C9gE 3A+bejdwO91ryM9Q7zfegH1cC9xJDwB3KWymB43XYfUk/oXWAffQeuBe+pOxj16ih4Av0wbgK8DX 6FXaCHxN4T76M/B1eth4ld5QuJ8eBb5JjwEPAF+ht+hx4NsK36EnjJfpXXoSeFDhe/QU8BDVGS/B ekv8gJ4BfqjwI9oEj/Zj2gz8ROFf6VljD/2NGoCHaQvwCG0FHqXnjL/Arkr8jJ4HHlN4nF4wdsN3 awSeUPh3ajKa6R+0HfiFwpO0A/glcBes+ovAr2gn8GuF39AuYyf8qGbgd7Qb+D39xXiRflB4mvYA f6S9wH8Cd9C/6CXgv+lV4E8Kz9BrxnY6q7CF9gFb6XVjGxkK29t0i7Lplv8vbXraHzb9D5v+h03/ P7Dpa/+w6X/Y9P9RNv3/JT8993/Tpuf/YdP/o02/8g+b/oef/h9t+rb/UTad1Gd1kjv5vpl7s/cb uVxLOnYrwTpbkRIA69oNtmwq7MEM7KyNtElbJr9HCwucChuapdJL/enGZ+fRbGP22Y0/++Zv28MB dO4Lw0LIrxxdUABD1NXXAizBIRQWbo2I7BDVMTomNi4+oVNiZ6R3cXRNTklN69bdmZ7Ro2ev3n36 9us/YOCgwZnIGwYrS5SbN2LkqNFj8i8aO258wYSJkwonT5laVDzt4ukzfm1Y/8VH+69V+78mbXd2 oTtr2FDXkMzBgwb279e3T+9ePXtkpDu7d0tLTUnu6uhityV1TuyUEB8XGxPdMapDZIQ1PCw0JNgS ZA4MMOmaYErPc4wosXlSSjx6imPUqAz57ihFQmm7hBKPDUkjzi/jsZWoYrbzS7pRcu4FJd3eku62 kmy1uciVkW7Lc9g8+3MdtkaeNqEI8TtyHcU2zykVH6viq1U8FHG7HRVsebEVuTYPl9jyPCMWV9Tm leSiufpgS44jp9ySkU71lmBEgxHzxDgq6zlmGKuIiMnLrBdkDsWgPPGO3DxPnCNXjsCjJeeVzvEU TCjKy02w24sz0j2cM9tR5iHHcE+4UxWhHNWNJyDHE6i6sV0iZ0MrbPXpzbUrG61UVuIMmeOYUzq9 yKOVFss+IpzoN9cTs+RY7LlXNB6ZU3Rr+9wErTYv9hKbfK2tvdXm2TihqH2uXWJxMdpAXZE8oqR2 BLpeCSHmT7KhN7G8uMjDy9GlTc5Ezso7v3JHnkwpudTmCXIMd1TUXlqCpYmv9dDEa+0N8fHuJhy1 8Xm22sIih92TleAoLs3tVB9FtROv3RLntsWdn5ORXm+N8Aq2PizcFwkJbR8pb8tTMVVcxvIntkmW 5Ygco6EQHttsG0ZS5MCcBkkoH0S1swehGJ5iRi3PHKzIJZ6gnJJaa6ZMl/U9pmSrw1Z7mqABjlNf np9S6ksJSLaeJhmVetKmasj3xz1Op6d7d6kigTlYU4xxmHrvn5G+uFFc4qi02hBAfFQA2ZYWZ/aE +O12ucArGt1UhhdPzYQi77uNyhIayN3TWewRJTKn2Z/TcbLMqfHntFUvcUCTt6pt3dFjTmn7C7dG d8iryPRw9H/ILvfm509y5E+YVmTLqy3xyTa/8Lw3b/6gtjxfzNMhp0hLEL6YSNBULpRyelth+VIU 4tGT8ReglHpOY6AZWqlS2DbCYy0Z5cVii93+Oys1Gt/IWio4V803TE+m8/z3Iee9nze8kFoNA9ZT RH7htNpay3l5I2CBamtHOGwjaktqSxuNmjKHzeqobdJStJTayrwS/4o2GttWJHhGrCzGJCo4E9oq aHi9g2+bUO/m2yZNK2qywkDfVljUIFjklAwvru+KvKImG2yuShVtqfLNJt8on6HpDcKsshKa3EQ1 KldXCep9diOTSjP705hmNwpvmlWl4cnYBqe6WWtumNzX3YggUwVbwrr2qZFhcKgKG4L6ZmX31Jqp Evws+ABYp1nAal+KRknALLBMXaXyN2rbyQNuBr8FlinbkLINKduQsg0pWVojsfaC9nxD1yR0vXVL XNc+X2fHa1vIAAttjbYCF7UkbaYvnOULVyHsjnC1L7xDW9EwJCk8OwjvTF8DDbDA3NY3jBzfp0lF BrpUZJ0/Zd0WpCRlx2nrMar1GNV6jGo9RvU1kNHqOqSvQ/o6pK9T6euIVVP2br6mfJH1DeHRvhRE si1asTYFd78krcgXTtWmNPRJ2pVdok1G088q3KgVAlcpnKVwvMJqlVut4leo+BUqnqXiWb64xJ7t MElhuERtojYJvkCSNkEbo8ICLQ/32iRtPN5lOE4brcKx2kgVXoT0WIT5KBeJcIymvrOjjcZ7LsJR eJfhSG1EQ25Sr+xKvM9CnkB/Mj0XY8jFmHIhJJmyCrwRfFilzAJWgw+ANVWStVxQDihby0YNN9pw I8dNmuYGZYGGacOQMxRlhwLdmkvN0YVSLvTkgqxcaNmF5XFheVwUqLmANq0/9QK7wQXgErAJ7aSj XjrGlY4e0rUM3PWTNLtYSVEIbb4wSayQ35PSOosVDZ2T3NlBYisVgEvAleAasbXBFBmeHYVysmxP 8HjwLHA1eAP4WbCZsrw57mCRJbK08WK8pkO7u21xufqosO8Ab9gp0RuGxPcJz75K6wYxdaMNYA1D 7oYhd8NU/W9JYAHVSaVd4APgw2Ap8FQIIxXCSMUEU1E/VZUKUOW+BhtgDUqUivbPL2NStZPAPdu1 IlPTkJKGtzTUSUPZNKQeBrKqIfMLwKvAu3x5XZQyd1HK2QVtdcFoewKzVCwcmKR1aRBB4Y2QL2eG Zw+E3MeDkSnugDTvgNzukBoi5CbuiZwsX4lV4GfBJq0J1A2UCkoDdQHZQTYQVlDrjNVbDVoFuhN0 B2glaAVWI+pZ5y6nmNX/iv7V/Vf139D/2f67+gduF6WgElHitlB0NE7CyAhzfLZV6DSdQvknhZsU XqXQrTDGHT899Nj00Fenhz4wPfTe6aFF00PHTQ8dMT205/TQRi5zxzhDP3aGrnaGTnGGDnCG9neG 9nWGdnOGZkdwMU+lUNqpcLjCPgq7KEzkqQ2hFLSDLya7GRrPqVvtNyQdtzfq3JB0k73RjOBG79vF 3mCITHw+qZd9XlK6NyXFG3S1v6ijBZrMz1AgO93pga8Fzgp0Bw4O7BGYEZgWmBroCEwKjDJHmq3m MHOI2WI2mwPMulmYyRzVaBxxO+UtKirAKoMAXaKu4lb5zSF14WL51WGzoDHk6aDli/xJwznf0zyb 8stsnh8nORrZgjPV5BjOnsh8yi8cHusZ6MxvDDQmegY58z1BBRcX1TPfWYw3j7gNR1ZhUSMbMml5 gnRfm4g5ffkdCb6wuFjWKarX+Y47iil6cVZsVuSwiMEjcn8BSnzoPPfEOtu/YCSJnvvyJxV5nk4s 9vSRESOxOB+Sk95ukxgkBuTlNomBMiguarLUiEF5E2W6pSa3+Fw5siE9t4nsMlDlyCbLke2Ccp3F QFkuWQbecp1Vuc7nlasfas/Lrbfb/WWGqjJDzy8z7/wy81SZeb4ymreMvV2ZwCNkV2XsgUd+Vqbz 7yiT/Itl2kmzfLjzPzzcRGP4UH3OEnlVKHHklYNLPCsWV8R6aspstibK4UO+W0RKSdnsChmWljfy IUd5rifHkWurH7Pk5/meJTJ7jCO3npbkFRbVL3GX5zaMcY/Jc5TmFm8ZWdp903nd3e7vrr576S80 Viob6y77GrnpF7I3yeyRsq9Nsq9Nsq+R7pGqL6X1UEszDS+Gb6rCLSLYAgUuSbAXD4+2Vg5T2jzE HrssYZtO/CQFw1UPwbUvFCyzMrIzsmUWdpnMCpM3Ql9W7LIh9oRt/KQvy4rkCMdwis27JBd/VVW+ yO/8q6qqWjizamaVDNVf1cJFYLlM8sviCwkzyA5R51sSrLG0zSvAK5WN1qqqiheSWtOqRSRbWyjh XONtsUVomavaKwFVXfhIzXCSl9Fc1SJGKVlwkU9tquRPitAMyUH6WiHST4DvogSEnbUynNhkHPbx p/IX2zK/tcUwxPsoXOhj71MIuldhIY/1hjSHDqrvZt+PtL78Jj1FbgpH+kHSmLiIXHQ3XU3v0WTj W6Ta6RH6mtJpMFUYreq7eK28lB5h769jB9G78vtowqU59ZMwjt25l1bHN1IGWimk+yiGDqDF7oYF 71tEonChViG9rs0ypxu9jO+4WX/NKKOH2SUO6ZvpDTrFXXRqvclYYawz1lMY/aAltuwxehsLUGsy ldAiuh4jqKGHaD8Xi6Fil3G7+g10OVJfoNfZCYUqgUc3EaVvprXURDvpAH1Ax5k5nNO4ht/lgyZq 2du61xhtlBlXUB6NowKqQW4iJ3O2mKZN0zZp77d81nrE6Iy2C2kxXUPX0Sr1+/D36UP6mDVhEYVi sraJEmio+uXyGsjsIUjyNTrMZu7HmezmW/gZsVjXWvbihNepIyQ4Skl/Da2DTB+jZ2kvvUVvo81v 1Tcy47D4k3k6L+XlfCffw4/xM7yZTwqT+EDTtBv0l/WTrYcMi/Gg8RT6TaBOZIOvm441uAjruZ++ wPy6czpn8TvCKdI11kNaWlv7GiONauMl431yUCrKDoVfm0djaSpGfS3dRNvpZdTdT2/S5/RPSElj C0dCFjZ28ESexIswik38NbeIaKzfIHGZaBAHNae2X5+qb27Z2tqxtaH161bDqDM8xh7jDbW+A9BP DlZgBlVii8kVew79vETH6B90Gn0EcBLGOorzMd+1aP8wn4U6mcUy8Yww4P2u1l7T4/S1reNaF7Su bd1i9DPGQrc0OF1x1A+UCW2S38WrUt+bfUT9dmMLtOcQfcWx3Jl78WiewkVcwhV8BVfylXwdXw+p PsVbeTsf4o/5K1wdA0RHyMkpZosbxd1iq9grDoljGmmTcIe5UrtOu1vbqr2l/V236ul6L32sXqJf qy8xwSULiDa/cTbm7IKWspYHW/a09mjNbZ3fuqJ1d+uh1k+NYGOXcRyuaC+MsZjmYYxLMf9b6E7a AP14GmM8SifoJNb8O8hC4yCOx4iT1LrlYNxjMfKpcJnmgir4Usi/huu4gXdwM+/m1/h1foc/4a9x ee4oeoCGYBdMFnMxhwdFnfCID0Gnxb9xLU/X+mh9casowWxu1W7DfO7XPtGO60LvqPfWJ+nV+ism zTTHdJ9pnWmv6VXTFwHWgIt9NuKcBZGf1b4hduvDtMtoI24HmvaFeEe4eKk4w0+IRN6N3hJx3yoQ OWIIfKPt0PIFFBW4LsAeYBdRZA0skW2IB0SGNlVP0UJoofzVhpgmbhEl9DjvoDNiFDRtsbZfbBSz tHX6Xfowfh/3i906iVD+kbIpm4dh7d6lK7FCGdqzuvzdJpnM2lnTAhFq3KqfMAntHdjBoSy0fTyN T3GBiIa0hog7yYF3K59COBo78ENofhPczkH6EW2lGCM+RtpldDfvxhy302ViOz+MdRmE/XgVF/B6 rTct4yshjcF0qbiHuohK0QX6PJm+5xu5I3buGaxNVzGXdC1UzKaDohir/hZHih68DHq6gFZwLaVz CzfTG2INDeBybefZuJY0wWdPcb02iur5jP6a/hqc7zOQZCI01wyH+yh0eh16eZnsWgq0ZhCZBO5x 2E8l2OsR4jRfLy6jS3it9g9+TGTTeCrXqsQIvq/1tJ6t9YXEtsGa5AQMNpPJZUrU+2HFT9Aw9Rsq CqjQD5tulHHtXe0Ho9iwt84yhbV+QksgnVGwbiuwl0bRRxzNM3mCboh83TCmUJ14Vv/EiOEQttPb BnZY63Ps4q6Gja80gnkCNHym/D9M9BX6cn2Rfj3OpjOwmrfQXfQg/QWnyaM4t1Ihx4sgzemwPZfg jOhFfag/ZjeMhsMqjUZeAU2BPS2BlZxLl9OVsLx/omeoHidUPuQxE/Xm0qVIr8IJdR0tw/6/lVbC BtxHj9Pb4mmxAXfc28RLYrG4hD6ij7RXNDdPoYP67Xo1TcIdeAJ3QM8DsUpJqLfSeBe9daMEWP9+ 2KXQe+Okcch4suUA2ntc/mIsYDidDMihNBrPP+rxbIJ9gwz1eSb5TxiBNKI+ILCRQ7YKJpMuIxpZ AkyIPK9pIj4oUKY9zxRnHn9drHOc9QfX2BbXOOuPrrHWFlzqXS0uyb179Y2wRyTbI+zzdDpr05rP uk10hmx6M/bTSeNT8anJhJMoica7ww8FHw8W5kALWbnDwng0/4K7QyjFB0dvtg5jy7DEzbhGBXLg DjEap0Mrj6NYp/XHGaeOHbMeO0ZZWaespzgicjD+eveCWdQCAhxdUlK1lP79BvTtE90xSlMY4EAq ksQLKSImIjJGJIueDkeP8lTn0GHdJeh3tUyzxcfbxOOxwV169HBYzpqHOtNdQ7tnuOT9yCKe0Hbr 76jfIpbUh5kaxS1uC1uC5P94Y3k/aJt4lILFTneILWJXxIGIwxFfR5gitnE0CbFzixl7v1E8+lwv 8xW4l+0QD+A0/5YLvPP44ZS1BbP54RRk57K6IE9Mw+6bxbkI+hoRYIuLswXwPBWNjbeZ9Hda41OS klL4c2+IG9ZR3JlPYmeYqZvbanoet7vN4i7avMpsqK7HUtA5ER5rgfxOte/uqGzaHote9BMt33e3 2+V/HCRmtJ6FhTqB87nAndotpLtVmGLCOlgiowMCTNaY6A4dh3UwjQ0K6rAxrCuRFeoU12nfNuhV LMctlxoyY2zLDy7rKSt6g3JgoQbLBZPLNYP7RUYO9K5TIA6vqMgYtVZdUlNEipjhejo1JCwyLvDy mTMvD4yLDAtJftLN31Wx4ImO4NgIS8i+1sZHH2ttfC3EEhEX3IXHtEICGa1nRbVvtN2CRFB8nIiL 1+WIgyIDYqKtpgCM1mLBoDHecKigoPjER/8XZ98C50R1vn3OzCSZXOeWTGaSzOQ+2WRy2Vuyu7Ah syyIosBiEdR1WdSqRVHYQr23iFYRRLHeqiKC91uVynVdVGir1Wqt1Eu1aiv2Q7xULPqnVls3+50z ybKA2t/3//LbPXPOSbLMnvd9n/d53nM2DCEuWb/fL/D97kE3bN7uYXfrJQib1XSkthJfbCVSNS/z i7xILP3Wu/1scXWk+mjMJaO7/R08+t774NEvoLtFPlbdiu4WMbBuqkxNQ7fRazTJveEwQLr9AbaX eoBmeu12OvQO6KX9vRwn9bIsDXttNvqdRhd0yRG6Z5mkgwI0F9hcX/SNL8iqrLncw3tY7FHYwpzX vG0uagZBS5SrBQcXrcUG8TNJ4KXqKjUQUOES3IdLcJ8IV08x5+71C4If3o371bm4j/wC6tXXiD/C PHKpFkP6NXgF7Ab7ES3cSsH/IX4FXmFsYRthexLeChzgXKiM+Vxhn7mYUVhfSkQDuOobQU2OkzA/ /GZzXHa4cFliiLBRArEUoVLAcIGdyE4WQqZOfwTDzh52LyhMwz/IFy1SwtcPEEsvvBDd00sjf0OU /zPgBiEUnxtpJ/WmU/ac+wRUgYlW0/aZLp88HBROSLT3zGzDzWcz2sdNx9/o3987Mof82HIuculz jXF2uwhlO9kOOuxHwWPsvfZz7OfDC+0r6BX2W+Bt9vvgQ/atYCt8Dv7O/ie4F35k/wJ+afc77dA5 CJ/fQjongF77INyIbqqXfqpAQvINbhBuf/xJtCoH+oZR/NfXZaCvDx5cmFIdwnYPn8IFOdlB3OP0 ejjZkvj3iUmZcfksD/o9MuNELvw++r0/tGA2WYCPbuIJR3xo5HNAjhzYmKPTXXbUbxg5AFIj/wIi +vaN/GtryGP30B5iaORLwI58vlHx5PA7MiOfG/G0JeQJe2L8ubQa4kEepizuWNwTLfPZsoW3WNyB MsKz329tSpQ9cuNdQ9CKQid7ZW152S/QCleQ++1DQYNxuaMWPd0XGScTeVaTZL8syj7ZK1usoaAS VIPhIGVNaQ1aWstolNXpcrjsLtplc1mspBbjEgaICAED6takAXJUwYBxJmrAoIwazZU1QJ5AjSk1 TXGZQQ99GWivP2D7oQ+kiw0fpwpyxaty/gqHG1FV+UpscOQ/hoE6KW+IQ02QRY3MoMbvqcRxk/KK btRDDelFryNV3lnJOVAj4p7ilaP4h3xi+FGH8frD+F3hCuFguQl+3MBvqang2z4J+lgTU1Ia+ioW WRMO/SL6srWimZQWjxE+nxeN/WJLM18kP1x2xu1Tr8grkxk/6h17eV6dxIqzujNyQ8eUa9d361JD x9Gr1hNv76p+duel44vRG8qzF++CLO7HbuicvfSCl8pxOV7dvfOJC/5QjskJGN2Jo20PSv8fUl8i 3Hx8I08HB0e+NBjOCmh70Aj28D1Bys4MEQ8BF1xj2FmXi2GfttMEnrGgGR5aLAR8mq4fHbDxQe8Q 0u4ccdY2YLHTLpnwbieWodzpJ/5gOMBZHAfPQvmefYpYhETfXUiymx6E83onO7yPNdNhZR/O7P4O wA6X+Y6CBNl/HnjmsEFTI+gzrTwKZAfxzTIK023E9TCCcWt4gYlkkeqnXjsjO2iZ+vI/p/gR1Em8 4KcaZ1tljnHTOJ8/glbiDRRLOow8biW6Z524LejULZQXgEHYu8Xh8pZjFoQilWF8c02NwSdQTP3V yAYTrUczF3uuSl3VcFX6/ob709tdmzN2N+8Qi672DJWOZ1Tdm1Ib4i6vE3uK+2N+n/hvflikGujR lXxnW30hLU/BPQhYndCNQK13s93ucAUG4VebzX97O2JEKOjRPP0eV052uYmFiHr60ayKXu8kzkUE /WejUcl+cQAHJWow9O2roPXdgyhTfRlBbRlRdIbCCV4SkxHNF5UMIMQ5A/rDXgPyCdTUo2vZstp6 owcYgAP6SW3ROs1CKJxom0AUW5G7Wm3Wepas45fVagO2YeJKnFi+fg2CzwdmhR+75LyHZavdxXL+ +U+cuvZvWu/51TeHZkWxkX506d5PF/5gRsOC+3/SJ9kcfrbx3rlvrRx36uIl1Xfuwr76m5G/UWih ADL8pgXtEAwi1Gppbi5y4xLHJKYmu9t/CKxLo1e130zdWLyl/b7i/e1PCEP+F4UXvS/53xb+4v9E +Ld/pMDh923xxpDhuEFkwRDqpGnGqTdwZAHdiAQs8RCQ1UiDlpWR6TdFInx2EF67SSu3eNB1C1+2 xsulQeg2HL4yGQp1kIFxhSFkghCxbJtT7mixWN2fDMHLaoZAsIiT9bQ9e6aze9HaT2Mx68PWGN6D hvsQTmK4NF0efXE10Ay1FhNJwUtZkq1xAwoWnwETRc2AXoo3ADDtsgw90KW9b6AdtA9AsUahtIPk pKW5hOyi1SzS4jdHppVGY6RmJFJYcvE/Bxd8mGf8LOtd8+gNz566tU8NyPLRAzfefumcG7Is5+Sk ORfdvu73pxGPtG457ecfnNLI8qzELN626Njrv4djCa7snXt9Z6vX7mcbyifs+OmsW1Bu+hOOJ8TI FIB0luFG+TxCqFGLEg6JaFn3blWUp0XGxw/CeQbv8Tzti0SjZxEk4lokEQ1H0MJvI0nKElXdKupv BB6UfFC+UkI4DETAoDnRRw4SVxgMtHjOUpQwYFSIQkEdIs4DUdhrOFEMQTlGUT4XylavIHMkDppj YBqi3wOdiHsPd7KYOe3DnU9NLmUS8uFOrsOyPK//mH0GRQsKnH++1jl6ZZoaB2C0CFu4UT4x2qkD UQvHxSFJDr8KX91wVDgQCB9lttXncbs2W50D+08lU1//Hq9d9Z+jaAT7iXeHo8jPn8F+jlYuC/5q xJxBeyhmT8vjJEsufVy6P31e+tb07+S3pb9LtIydWMROLKBOMBKnvWwkIYYDMKxEwVMQf4gexNtR cI9hV8oU5QBaUhiE/8ew+8uOQJlFAmuIuBKkiQVb0CvPSiYG4V+2sXIuSTlGXXhszRDdRGu0b7iv 5r6Y0hf2IdTGLmySZX7UeyUpZLGHLCh/S3bUBK2KAWXaP+a5KIR1vW8AcqNQgbn/EZ4bj9nq7LX2 Crh06tXlO1/fv/mC86YbmsRyws833rjz/suuuCLiRkR8KoYQ6obqGeHwX7c8/2Ux2RYVeZm/9ncP XPfoZFYSiRzGIQSfPFrdAEKROGiEDxuufMybaI2puhpVtaGRL3Ap2vAUqfF0N3UsfQJ1Mm1NogXe hNY3Ur/GzGu8NTE48prhwOiB3p2g3YPonUspiqK9lJfWKI3OCOOEY4Ve4WzhIuFq4crEdmFL4i3n W/zf3YITWmhbxKrJTCKSjJ4ROT16UfSihsWFRY2bYtszf3L9zbHXxZ9MI9LDcnxE8IZ9qqj4ZVZy x0DC7Uo6NQdsLBD5LMoiaZuesfitHneiCcXIfVtyZZK0BwfhXw0xXPZaUmW7W3rPWgYZNhPJNGao zFPES6AZJGACuIj7t8XKjR7okZu2w3a47CCl65uGc8dwnykWUQLBtt5TU9z+jloGxDCVzEailMAy HMMzpNXldroJa5bKGDAixAbhLwwf0ByIyyUTDTSa1C05A0aZMH7GCZPulAHStpTpFtgx2E6TyWFc GzATjsmWaqlHh2OuYnoKSjvYV+q+E48BnxfRpzHXgQum33fGVbuefuDcp0rdlcb1r186q10SOTef Lv+mukPW7lm4aN36M049uZMQFp/37r23fHXVNY++cufV89edEWNk3u/wVh//IPrHrXdsWHXFL77X hqLy1ZEq+ScUlT5w2eN2EiduK4KuDGG1ksTTdpfbfZYPeH0+4ENkwuV3+lyAZCFxltPBMayDYl3O IRSJkHhws98ui58cQp/3TDOJT8UEHoQ7fjOacDAt9+R1D0agI/I2LEZrC1FEHTgK6OSy4fsxlpBk 9TFa9PCSlVqgmWGx7qr/PB/gJNbBIxT+AGmGD0zNkARNcLkxiX8g9gL4FHzqogKU4tNzc/QzCIvT Q0lBj1daKd0Eb6dvd96YWqffkXsI3pPaQuxwDLmG9JccL+jCRfC+KNHkzSFmszEUVwdH/rKxMZ4f GvkLEhtfbubohoYEnss0xIZGPgHJkY83pmJRTIN4vcGg4+V02qqUBUuhbHXHB+GfDTadFlmtTL4X KFfEGSIhDsJ9hrMlUmbfy5btcvMRsgO56AFcRcFQtNd0VOynpms25pqCYc5H0SofMUDIi3Aob0Oa odGC0miYQ4gU9KEmRxcM0IQExpiYwIn1m0oC9MG+ATDQjTeE9ZEPNyE1gH6RDzchkYCvRiPSCBYJ jSwS6kHcg5I553VVfBJ6uQ/P+fCcD88dJg1OOpi/EQa2jUKhWR9pM9M2kgLIt4VD+qQw/5zd69fv PufsUzLjXr/l56+NS7vv+tGSu9adf8E6/y8uu+wXjy5d+ihxTcsD825+662b+x9oLXbMPG3lyy+v PK1n3EcL1txx9mk33li1Lbz33vN++OCDCBcFhIt+5BdJ0AJ7jJyNpjI2HeQfTgwlrBoGyXgWNR4J NW6P2tzqiqGmWWzJprI+zMSY3qb3+a/i/5M5kLfsALAJoyR+1yA2uojs/zFoRuuUQ++yerc0PdP0 ahM1l3YngOZxpZwN9gxSf6jn1tCEm2IS6bLDgvHMcBQQoDmiZdGtDSHMchP3G45EmQkUA+/Zytmn iAdB6xh0sQeGEdH6ArnG+6DmDXsqNT3Bmcq0DlypVD4Wp3xuj8tDWDlEZwTWy1JWSzJjRz7S4EQ+ ktJivgRGKgHmKSw26TSa9KAmzkbR/BaQsxYOYtch4AX6dAxYA/AghqG+GaR1q/pNu5ps+ZCcB4qt KW3MvG0lckfXprlz7pm3Y/0Pn2zt7tBuPOUnV5/cEZA4lz/V8jps9hbXzj/n7rvPHL+4JUr8dvGS 7//q7NuHr1v+6Psbz++5pVCJsRLndwqw5YPMmy/euPnaFZsMQ0d2Nmsl5GnAjTRfk2FnNopOeiOw 8tuhiDCBguIWp1OWQ2PFk85pbE1FmFXDw0oowncVVMYa8rSetvHT8ffw6oNVFgK2j2RIYN6FBE40 uJ2eXZ432d2ej9j9nq9Ymx+RlIc3NTKQGYQBw47uj/kf9lciNQhFw+1s9bzCiFB8SwbW+l2CCkRA cOBArQy2D3VrlbvDbo+MHoRKYlayfUZPG2pmngLp6vs+mZMi1kNu9ffVxhiv+lzmByKjyCD/Tv0S MYYm8LTRNYmGaz13coTbs86xxk2m7Mn45fENHipH0yBO9iDqxgcYMbkk6xTXM1lGLaiESlFZFfb2 IL5loxsG4XhDKPyUpptbXNlooEXoleTme56UBuH367hmejAGtQO4vocIF+4XUDKu7DOJVl/djdVg xM2FNFbhU+glwYAn7GqAXJBJQXeEaYC1pIo9E6VUjF59cDRvIP+q64FDZmrLdfiqETchbiq93ZO7 5/KJP5qF88sd+enTH3jxourvZ2XLlcwsvTyBIE7AaebamTNzkxatU9OzzdFkl/D8bXN/Vj3+kIo6 eGPkJ0hlc6AMpsC+JwA7snNTSG3lB0d2GnZebXUbqKmg0SZ0FepXybxKrd34VX7UGaKfNAieLbjj LPkDOqLAcqljEHoMR6nUXIbUlAmTlEHSYtjlpqznnQm9jvIgSRoclZ00SXZYE1nZGXmsY0IJaYyj DLfomFAsJSZMSYASRKJu3caurG0QFgyn6EvkxESuJwuzT8IPwNHgOVzcxsUKJBaQth4+0DeMCTHS D+wBkyUhG2FZh2y2x0zgplxgO0GfaavjK93JVouU0dN6g57SNd1iFby8l/OyXspa0FqSFXtXA5CS Yj9gGn39wN3sbIDdFjRn0BMaoF+X+4E37+mHrlZPA5xondRQwx59NJGMMqfRozvFureXWuqUCGGO j/PyLc0Ha+8HC1BcrQAl+jgzD1njpHUUh8heOcNfsvY3D1995pSKHmqcvOnWW47lWE7qnLem58pc aDrrv3rBncevPNvrdQvSpJ/efO5pXNIL806KunXBJY+fet6qhJyoPH5Fdcuvq/+awkpsRCuPbw3f Mm7mItgDwd2XT75r/vBOAlEznx3uhpfPOu5MC/7caw4Aagd1A8iAPNxq6CUOrWhwQrYtN4U/JnBc 9qhcD98j9gf6sz25LzOMDjKZbB4SRM7BDhL3GqJ7tXudm3jXDd1pzu1mOcXB8fE0fsqjaS0ZTUtn lHgmayfNKau1xSRyip3IyYI5JYqzeVEUeEXmuVgITx0dBuHLwteHyV1hGE4Hw+FQUIkFA4FsJqMG A95gMMBznErkkIbNJeJxh50GUNWZfDhP5PN2OZfVAoIWkInAEDwRZOEEw5vRggZjrwAOMsFwcHdw f5BCxD27tZHQuJzGD8EJgEO+zzkqHPZ9Fr2W4SDgZnD/4EY4ikOv3VSYvAAhR62MNoB84YDpnbg7 bNbTsLLF8NFnbtIhf11uMWXt8rykL/8xUrf0wdraZ30DhQPPHDrxvxqa77YhGou/a8V+8ghhDOse GYVHPEGScZK8ZPjNgbvM3Ybf4rYLLv7SrN49AG/vMqefwwJ6/Y0fht+Dy6svjQpn8mO8N/GfXx8U 0suJ04fX4n3NOciHTkI+FAIp0AzPNJ7akHlE/63jWecbDsvqzEp9bWRNcp3+WNJ6SWJpcrH+o9xq x2rvNYnVSfoE9gx2qWMRu4hbxC8SbFMj06LHJI7Vr/JYmpnxkXHRcclKZrw+mZnC0vaCHAlFg8lg JliIMxmdvoh9MvFcgTwqckzy/MhVkZWNN0fui2yJ0Fk6JMo6AIpI0BYdQoVujHjIeIOnOZJS0pqY 0mhVUZuam0WaEOl4knGFXQVXxTXD1e9a6LK5BuEVRjqXBCj4CIa7ntvJ7eJ2c/s5KxdoTTWo0NyG 24+kitwy9aKaT2AlN1Dfq+0zix5YaSB7mVKerVWf6uXWw4sctfySyPJeh1PQ9GTGm8vBpCOeg1k+ nQMJp5aDYIwx49wyMDDQhx5JbtTIJsjUAaVuaCGK0MdMPVEk7Eu1ElUUggFz44ld++x9V1zcc9+p w+am1LMw3T+jPOmmC6qb4EMzL5xw0p3XVF+ZVTP3lotv7y/cMXfWNadhkxOleOjsthlXfi0efXaH ceEEfAp/5F3qOOpR0A7eNS7MeWEBVMAMQFpEnzjbf4b3++L8/CLvYnGRtNnvaAuVGqeKU0u9/t7i 2f4fFK8M3VZwtDQxkWAMApL2iP625khcZdyA5J3xzTqfbHNeQ6lJvY2kCN3u0eh5UU0LjAtqTFO4 qdBUaaKa5I7lhxihltOHh/Hym/sktdU3aWl9b9TfgRkqSuzg2F86v3fsLxMzT0ZaI4SUFecFWD4p I59sEUV/SBLrmuQknNRRpI9WY+viOFVHe5sVTQGTS9bxHjPOPFkstvJohnwTr6Nf4PyEZfaSm06d bWgTUyHIbl7wSA/n40X9+Jfm9849eu6K5is/WL6LCo/HJvkoHJCCs7pO0sO56f1HnXjjk9W/z+33 iZy/cEpfPHj0Iz+b88ilEP8BB/6kOep8FHsKgjqXEb3OscJ5Nb9CWOFd5VsdXh1ZGb02tTK9OuNC WS4VSYei+Niy/bbUlijRTfsVjLfOQBoEAgpQ/DSBx0VL2qyTKzSXZ8KqKCqqn9ZVu51QaSKhMYgu MhGGYAL5rKrCCLI2AeTcdtgB6bG6xlgwYEqLgsBssOL+bxsOKBZaIxmHz8O4GRfjZCirlkwlG5Lp JGUVeC9PWKPJjCORhxFfPA+TjJ6HMT6crxe88PZUvYiO8vOh8YG3d7DdbGNIaEYF1gIpMzKUKSYE PnP2hvyMtPLDK0+/vNqJZ9bAprOf6JMTExOrZlZfrgfFie39Z0+bv2TZ5ydPxFGx8ldzb51ePqkn ewyKhxORPQrIHkXIG4H+8ELrUivJOT06zyvOWChcjMeVEGm3Yq7FqBV8NbKMXLHOJlBW9Ab8uiAo gdY8dnCiSS8WlXwqh2tKREbXNCUXHoQLjM4AATVnPKEFikBLqgA4A4STjmlMCP4jNBIiQl2kBuyw x77evsu+277fbrEXNS0PcmyOyA2ijCgmkwmUNO3HCwX+H/x+nuTl0tSFUt1y+4ZxxfYAzmRs3wCi +QN1NBuulWzxF0KvfYD9Z99rnQc7dUQzh7o++sTBebydBLnRLQ3uYA131ErcaKll7DX1GXgCcRVe 9q9PxRYZMDGMXIxnhu+HZr0Rc2eiWA2beay6eSxbVd/FMy9Vj+03n/kUt/3ISuuQlZYgK7WCz4y5 8yyQsbt0llXs0aBajMWUYEuOaQw3Eo16a6uSQ2mkhNMIL/t0jlNkLQvSbJpI68mkko3FNbkVJBMa ADKyil0m7HRrMpfUQJbN9mTJLF7vbCIRB1BjYxoIRoJET3B9cJfJQyzB47kICwF7GXs9u5+lWLn4 xRM4jg6mFLT4bN0euGiOC1jDnWO2OHL1waFW6PsWI8C+I/fz6iZo++82uKO20VcNjtqAcarkWrzw wz8+3AiH8QW349tNgGxwGcocV6LM0Qk1o31V5PYIUWAr7AyWPMZ1VGK2s881O3G/8/7Ek9Yhl52K ++OaKxXXEqWEtQQ6rgcdHUApFQsYsFqYZthcyjc3F/JK0UGHU2xOgKpfQukpV8qEFZaMBju1UkEr nVksUkI06SER/ZtvRLxegcgkKbt6Zj6fUyEEgQkpjaHDNEHL5eULj0gr5iEs1pQgJp5htrdnLL3U ivP1kuJhMNdXw7nagH3msMzT5UDi7BNgwZ+WMvIxSKPvhpGPtyTEmBgfzT8oAQ304QTE4cySJ+qJ xV/fARzNR7VtJzSkcC4aDTBLbY+QKszb0b/8petmrPh01YurbLhuKfGcH1r/eMmS7TNLELx33OVz aqaCN6kB1gs3Vm8tlnqu37ji9pXQsnJhk5cJqE+HZb9ywoIzrus7/7Y/fhFpgG3IxBL0C27Rhix6 DoqqhSiquuGvDRd/l/hYYZO4o0DVpILTrdcVQiBiMn9WgYoeVZRIVAlkm80pUICFdEuh0NyiZDsn 4imWqYQrREXvrlQmdiudNR3htOp1GVETEU4xXdcQetL8OUiUN+iJhoZkQtHHF/FUN2iH7Xpre3ux VRkfj6kAQrvcrGWzekQLJDVdr2mGzvHjHUhQtKiJVjXRbYTCreu6N3QTq7vf7Sa6B4ntRnAyr0aj nNpIGMT1BDmD2EUQDNFPLCRI4kliO5iE/5ADmOdOUORi8ofCWO80Kzs4YjuxUjA5IW65OkU80lW+ dfTdg//2riN/hokAZnm1gIsBjLciGqgpoES0zSOgAWpqpdLoN7bb6lB9cDsu+o2ZI+XGFcOvmnBd fccM+1YsLL4yEYTILVIDcvgrPNPaP/oaObyIKFXVwyWHCeTHwc2j/a/F0eeRz72PBMhHyOfC4A0j V6Dylrgr4o54I75CqKBOsLS4Gr2Nvkqook63dLsMr+E7NjRDmaH68F/ZIc9xlczjFsiTwuY4VAKh UBgoco0LORHy17iQxONxylfifD6eU6SwJvOaLBGERjOa3U5jEcrNYCErR1a9Kx3kQNjqyNgVs5jx /2DKb7PWN85fRA8h/vh82RFnMHabJP8mc6duwthijS0mRt9HEPpuQOumgc+NS39CLhUu9q4gVpGr hZXeL0XaTji9Th95O7HW9rDtA/Z97/uilWLPZLeyW71UM61F4kUksCJyOPS2JClhG8M7nVQkTPAI TSU/hlLDzVWA4WIruwG8DP17gQbmTI9K0zb8hA0/cZkN2uTU2ifg6/V0hygcxtg90+sSu37qdR8+ J1hA2Ppt0inGioTVJ3pRy1kYhLqM1SaQ/hxkrQiDRYLP1cihWZ/L1AVUX/3IXqp+Uo/EO1pYLx2x suSGPXf2b1uAExuc9vOpxx/T1lvdhh2WOLO2uMOB23bPOR2WTPf9fMqUBvW6mcTeg8sM8f/2R92G Vnki8X2jT8pJpUBXoqXY0laaEu3tOiu6oOuC6KVdK42VXbcZa7o2dG3verFFYECpZXLLnFaKieml o1q7irObnqn8xtjZRQdjwab5sflNN7VuyD1U+jD2Ve6rkqN5IgBNo96sH+bNHhCCoZYIcuiIImca zYJNJHd9jmjMwVzu+qZcrrFJyTSBmq97gAVaWg5zdyciPDV3T8fxuEdjtLDWqJGaHsP5RknHol2t RomqTIw1AR6o0Zg3Go2BaFOMisBGLRPXMum03BSLRVC8oICRiPY2bUKlQtOsZthpMEhcvDkalezN g/DEbZGJE5vARK15CD4IYsTFht/oaZrXtKiJBE1GU08TubtpP+LEXW3b4YkgAiqwZHCTohEcd4CF +3HodU8dgrPGRIgpyTs7ZfZAYFhCw4EAPhSCQTcgm9i7T6oE9pmwPNxpChTzTGcnPqdgpvXleR2f apOBoXYibw61oUZuRo0/hxpvQ6VWGjxpueXHzwD8BunQOk3hvyP2oRWevoH/Cto2D9vZWTsu9QSI jezeJCdasZLbiK7oFk7CMGFK1O+C7OgoQMMjEBvis3D+0RGhpeDsNeYhivVjXBvOwzNriEmn4Ou/ 8FSs2nzW1ZXEvPl45u6fbl4OX6iu/CbQDP+HsBxE8NMzP1nStd88yDL/5YzJAFF0nIiiIwoWGO1I JBWxSMIUHGFLEImkt+uaqIg1EaE5g1jmMHZoDyA2rQq8HLvvokOOye/tQ+y4to0yxoG/wYzxgd2x I7rfvk7wdSJvnqeah3/Z5583V+H9UUCF03Giqs49AlQhkNDvsxP9Pu1Eyhj3N2WvShwFprbvBLvA q/DN0B+VL8AX8AvFkQQpJaVq7VNCc0IPqk+or4HX4GvKx/BDxX2iCl1m5AnrsMwOI5mdFhiGFxRX 2KQ2LIj1xIhYWovFkpoSLpjkxtncUmpuLpaUgtNijukWiqYtlOIM+mo/TIKMFJYIKe2VJJ9XCeYb ahGv9+iEnk7pekNKyQ+OXGOEFAgiIUVRIeGFuFXbAVAV1YumULQqhlNNauGwqoYUDeLx1FAo2N5G kD4tSOQLqZJWKDidLkrQXLSWam9XVFVpK6kpA7wMw6n+1MLUhtSOlCVlpNKtKYMvMqnVqV2p3an9 aG6QeM/wKWHYD4nV8GX8WeZUKEQRBKUMEhcZohAhKS+lzhBeFt4V/iFQgtzx67pmnYaDOCCz+ySu o1D76htAwz5dH5DYvQHznBGexQJquBbj+FLB8GAOapGPPAeXbZf/+JnldF7SLT9mn9Gl76ZWA/9/ /GzAzOs/RJx+AMbhN081jYYohN958ClO3Dmv+hS7xkw8L+B2ShG3f4ATYMcfTE5VOwv1ohpEocvj Q09HMoHhLPHa4XSK/BhHZR558TLkxVm40BBpAtpDcoh4joBOaA0GoRiknJzpZJ407/FwKGKTes2Z EOlOZxsa9KySdFDmS2wtpM1GkYjye82xX0ex4kXBnFDxOBZtUaJRVVESQQLyUA0FvcibYBAIupZM qloigRLTxVuDXg1Ffgh1DQd0OhyQVkIqROLMCAKQNZJFJjsj259dmF2dfTdrzQbyBKnyQfxyge8X Fgqrhf0CxQhQkHPjzjko6gZwpYOtVakw1dhbI2uddbJWO+9varp6FmAgjRAferkQatigebLgJLO0 /78mdt8k5SZ8R+PfCeAt8Egop4gFwzfXsPpF8/CbidXvEAvWYHSqcZIplP/r8hH1+w/IZ8d4IAF+ gHjgD5AKdwMZfm2M/I55Vib4veJe6Sv2K/6AeEC2Pif+mf0z/yfxDekj9iPeFmADvE8UJeo5/t/M FwK51n6z617iIctD9ntdL1hfoOkriFWWa+nLXCuEFb6biDUWus3aRrfYO13j2Ba+RRwn0RlCdxXY JJ8UC9J4wvYks4PdyG8UNvp+Ke6QhmT6UeYx9j7+buEe373iBulhmZ4jzBT7pHXszcKN4h3SbTI9 WZjsmyxOlY6TT2ZOZo/n6bQ0jikJbb4OaTozlZ3M006rgw5ag3SaSQkpH9LFMqRogXFTwOZHJJVL OkhPEpfyI6ARrAcWcIE3aZM3Bbovrv8pAz6AhzfjzZKx3/z7J/OBa+8ocvv6kE9sER0hrsL/X86u BDyKKlvfW9X7Wt1dS1dvVdVbeku6k3Rn65AUIEFBBRWEKBEEREWdgMLgNhLHBREXFFEZt8wobiBg whJAxXEQYZgZ8AnuM6APHccRZeah4wjpvHurupMmLt+890HfWrqSTtU959z/nPOf030D3/SiLdU3 8G2v093KYnq3jfa2sm7W3+rGgxEt1r12Hr/1Od5q+wbeHjw2O/Hxa3hrLG5deIuAMoN/Tt0el20I NDOi1dniCqABYlqMi2+1FrcE3lJMq6W4dWO2iNXhaoE2NFiCeO+HWfJYjgGuv0GYGDgogETQqc8S mBqP49pOzWV3fLV0b2EvzO1d+uXSyV++/OIJqF/98pdE27OFj7phO7RBO5zaXfj4uT/CtsKeDz8v vIO/4JUAvciSXIgsSQhUgmOyW+PRePUBILi8TiHizXnHeLcmTQlnRd/AlzK10HOrh6gwJAwrPCsF Yjie/WFvrHoQnqYUXywEAhGnPdwaJsJhN3LJ4hE7AsCedCWCiBRf9c1QoqAUnsbRaexddABFw8My evZh5BWjwWzHfnB7sebuP3fXMHsbB6B/JMxWUmCFxh0p5mZCEtwwPL6GEMdnL3wwtmb8xKbzC/+G lo4nxz//y8JBeLiw4FSN/sPSc34ZafC4Jp13bcusx1Wddig6XQWa4B55+pLk7Zk7sw8lV2WfjT2d eKrK4JxbfXktYaogk94KOklXRsG4zOjs6LozGsc3dYQviJxf0ZE5r3Zydkr9hY3TmmYnZ1dfmp1R vy7zZLa7/uXM5tqe7Ib6rU27krsywYylHkn75iZTxhDGu8d7qg21WFjbk5YKQ7wy3piLtSaaKpsa zwiPTd4dXlZxS/LWqlszS+seCT9SsSK5vGplZlXdavB08q3k3xq/y3yT/abuuyZfXX1jkyZbmyFT 0SBEACQUpEPI3ZiDdBQZ/vN7zHP0fXCp7CIjXEMUGGsicS5Ohoy2OSnQBzt64FERLw/uXDqCw7Bi KpPqTmlTi3KRKJ9HGt43SG1DWk59038Eh/Va0ziqh/zPEtDWD7zaY6SyyfYj/CdudF6BBrZf7Byy CCW+vpJxUFhrcluombe3Vs0OOFuTMTRUYQtRF0BDFg91uPoli4e6ALquDle/ZPFQh6tfsnhI0kjh 4TAtbYcdWn2RwjSYZ1KYBWoSSg3h1keJHNZfrMWuMg0mrp53Xt3Uyc1S01ifxcmZmHENdYkHxlSf fskI2uhwc9uf+QopN1Lwwv4PBtVbmuQQubSTc9nNbpGvszgcWjdNU0vicNxnWOELzxb+Ufi68Awx u1ztCSUD8grS+kpQD3+9FUgDO+WzRaklSXPulgtzc6oXVpP6ZFP1uOoLPFOrF4gLUtfm7s6tTjxf vS96UHhLPBQ9WPlV1GGPGqvHCG3StanbhDtT9wm/Edakdot7pE+T1sD2gW+BEdh/0EKc6sDmhyyE ICaSki5YmQoJVaCu6I1WgkC6Cit9Fdb3qioDcnSjiQSO5wjbiOtBJdEtWwG6kQBVG/GBKIwi8dq0 2HevD+ERGJNxU6KJwe7g/uCxoCaI8bDdIVMwTR2jCIpvGHflqfnhjvlHOo50UEpEX6nlUvCGwhtA hrjkhJZni/9Ts9MAxm9wFmPKPYJF3DZwHDfi3pi05FgBrU89WbEarTUllmUxpIypSz/tMurZU7zD SO2gwZr8fT/x5GPv3PboBV13y/ho3qNrOgtff/Kz3nOeu66wlzAVxp1qtt74xQVP5Foe/afiEHKv 5CZNvLJh0sMIf25FiIRG1us08IGcGFF7pndCbUftIvZ2dolnqfeuxlWjTGeIbSMJLBLPjXx21EHu U+5rTu/FN+ly12GafntSjo/Ie9x2LQ1gva0mEyKrsjir7DDz0ebmrCMy2rxMU7WsIhuRRpMatOxI SnK5PjI90BkgAp42OiJXR0NReWRnfHH83vgT8fVxbZwf89g2KJRxt48cRUBRrWlVM86llHO/Qyk5 USncKmmfU4uoMeMVYvgwPJusUhIDBE5VFunWJcpYkc1YZF1XRAc5/OQKFck5Oah98tZlT1WdOWPO mpFT2j/93Qe34MeqvrP98ce3tI3JPPzmtGlvvbBB0+LDs/N2ACeYb7/34ppzawWHz19x50XL9y7N 4Lc+w7nnaQ89fuWoSwOMJ3T66bfd+gr2C+5Fet2srOb3yAm70ZLDCbOgT6jDKU3CoM3hHJmLZ+uQ F8+HnMjxIJAa8X2wczNFOQLoV6BdWaR8ad8M3z6fxu5r9U3wTffNQ9q03nfIZ/D9LYIdOhz9O16s GGlVFt9hSazvpbS+J8LSYEluaYdY/r4SI1WiF+8XnlUY3C/gx3dqiLTwZyzVcFFhqbINofs+D8nj jei+MzC4Hfhwk/yBb3sEyoeLO70I6QUXeY/oPvV9Lvyb+Fr3tfdb4YRoNBMaHfSahdu8j+h0Trfq uTMUQzC1PMO4eb9TDcfZQCWsjIPKygzwJxwmNU8SN1qtJqPfocbcxkZri7G2DLJMoWg87o46TVGn g/AjHBuUAhB2orkh7GACmI7LeWt4T8BgmGCcbuw0Ljbea9Qa+eoyv6dDCatiqe0YCrAOOjz/r3SD UlmrmJWGYmQVPfHBpGLJh1V4bnW5YX4M2f/FM/PWXT824LFZAqrX8sgrvzxv6aWKb6ue0LT0j3rx 2Mw3riVeUVKKivc6atlrZz4+SzlTir9QxZUnCdtlnx7o3Rlwpntccob/fmq//9/ufydNz4Jn/YSF VvNPVC1DUTTjtzBsMIFPIQM/L0qAKBWdEd0f1USj8WQ0mkj6g0lgVhJP7k49xJXXnXrk18YJvZ4k /GYCSjx+8wy/v9bt9/Nuv+TmGALCALpBpMvuJAIwnJvmODfHJqJBPirRUQsZNQclyWIxE/i7+pIw Gc24J7o3uI+5NW6cMjZzRDTNTGd2MCSDjnsHOMhtg7cAltjfm1K4aLMxDfvTjuMdCju/Q9GVUhQD /0unS7GMH6CgDaeYKbGMnzxRnGbkoxYp1soUqqyjEKz9obPE6oWF9pEcbbXSHGx0u6w2F/dreLsO 3tztptGBGzaoW1nTYmQsFsaojidZ8vPyY2x9kK+meQrNbYz4h4rPZDfjJlhOq9Mgxy7moXVR0UIY wwQTV5dObDialZYISh2pfF6np9Pb6ev038Hezr2qfZX+jDXOoGY4ZjhnuDT7CEixFCezMqdxE14u wAv+QCzO1RF1bDXXRrSxI7l2eCE7lbuDe5bbQ+xm30e3pSQfHdREClI5mqJctN9KM1IFPhsIi+F5 YQKEqfDE8Kvh/WFteHksHK6I+aUYsOiUS4x2o2Ak7MYdxkPGr4wDSFGXa41GndZv0WpED76E9k/3 Q3+O9/s9vF/k3QDdsNhX+E7OMhpSpLUaTYChabSGxJCIuXna7eYJSJAw4ObQPkeQBCQDDIuuYIko 10f8XA64cSMLkomSGkNFVPLg/6Loilp1UasFfxtqCgC0wnUAHj30DrlmHw8FHvJyIsfL2bos35VG O6FwlpejFVk+KttjQmx6bHHs3tgTsX2xr2KG2HbiOgQCOQS/ORb9GCun0Qv9KCt7cnb2K6XYZOpG Qo7mEGK7rkcrMi+jj6MBiT5aAytlRqDhqzSko5QWAu0E7b3afVqN9mX0bhyMUaL7s1US5lEkol/y 1BEP1Z/sn49hsvtTnuqf73EfVasBOo6gd93Ul2DQvhUzcTjA369E+gyYoalF+jG4M0TZRL8PDA/n /xSJ8/snVJ0ZvyGKgFkCAbMtRBfh4TyspwjBxm/wDBLQiIEveggD1zdw7EWWKkE0HNLv6GiXQpi3 OSz+43LVulzDzpHv3Prl3269UVBMZwNewXZ2/vfNf7vqddWW4hMC2Xryt5qWwVxqkEyffJP8y5AV JUYU+smVmr8CB2iTow6z7Z8A1JjR+v5PCGsMZhNlcAIYNlKmjGmiiTTxzkueK093tv5QvL20Pg+1 xPiD4uweVp1ezf3f7cAfrv1cKR5EAtpc6CceUP6GFlkc/jdQZqfRFIatmIJZ/PSTpU8f/tnaIX5R ER0QrXvL86TrtSNxfu87BQMgwV2OVvvzyS4QA3VwpnzO8/qnhOeryKg+IuQ1C1yLPD/3dtG3ee6n V3rW6Lvppzzr0pv0L9lepDd6tgb22o5XMybIwwQkf+V4wEPcUHVn1SNVz9vWVL1efbD6k2pDDPkI 62RPJC1FIkEpGHP6XVy8TgJ1cUjWWoypuj54WL4A3hEDplqJNBsl7L7OS5GpeN5iidGPUpJfj9+w AlGUZCvbapdgWmqVJkjTpSek9dIO6ZBkkDwN3L0ZSYff79Q9oduhO6TT6Pj6xPYhEACTZ/V/Wky0 qo+uVH6Y7jiKEYFS7TWIXhsdjcM8DuRv8EXh3YE85W9BduAYyKEXP3C812moMhSpK0iEi3QXGl26 HQTQJa6BV/E7CAR3SLkSex5B3LJyVNxcQE3RFGWHjCrvldjyU7fsf+j5w+803TGhq2vmi6KR4ky2 WY9OfKJnHhby1/O3nrHl0rMXXX3V9lnX/WpV5/Wb7dQdY+Y0mtxOh8nuSTw2q/+A4nf8xkFNyJ97 5mVTpuO4SSWa+ylI6nwgBsMvYvO+TjZTacW0B60+Fh+7+DTD8ywT9AX0JDSLUUuHuQ/O2hSVjKKE EO4sOUH6ACD1RrNfsqMnT+g8idAkYBEZGpPQ7XQnfYgmaT5+0T3l04En4UgpJIW0CJsuZK74I+4j RV7RTzVqGL/BUpwMedJcI8yYM+GxsfNjs2PPBVeHt8Ct5pcCmyt2avcaDmg+NBzRfm5wsJpqWKMd YR4NJ5jPCJwPJ2s79B3m2XCO9krzQuIG0w2B64SlgW3Cy8FNERYis9RjpmLIg3wxwKodCjrg/Hbo QHMEGBpgbyU0zIGEZVV0MPHwO31QV/jXpg9XvF7G4nv8/fvvfx+/NH/tf2tX4evXdhaO7VqtNI1o URJwu5/485+fQK8iY2E80swEOLZJMiF3nUEun5xCO28wH0beqzgsHJb+Hvm8Qh9mKtjTxLMiZ1VM FjsiF1TMtc/lL48s5S0sDole46LbXeczV0TmVHzj0eo8PMV44lTcGfHcST1CPehe6VnNrEbXhhDE tvO0V2Em8z5O9R/BHQ4prjf3anS+33BSyGzLG9q7BbhceFUgBE+KlqJ4krujECfKl0fJKJ/cWTbP SNsULlnH/LOOqx0j0L8jRQbZEDlZdRUxpsZkBVxkUnQWdeXOIlvOOQ4FQS4LkE/4ukJXUPjGuvUP bH/t7edn7j2XoRzcJU/u3ls4Ac17f0tafVhLXhE8nHds1+cPPXng9Ik050iOugKSb+yFFqwLN6Gn vQZ3EEXP+6PNZyQuSxA4xLJOpQmklShL0BBw41OUN815vW4uGDCxwZixw4TUoDcmoeeN1EEMSnQA WMy0HrdD5gSj2IV7a0LoSUWkLgSd+uBdvclEV6m6Yn7x+eAQSbNC40YryhH0/zjWgx93Saoz4zew RSXotRmcBmxihvRiK0igFVakK7DbFh34a2/IEOYHbdTgEhXK6QaBbA1XEuXyglANoZqY+z+6+s3r rnvzmg8fVI7nvbvywXfffXDlu5q/nrgK25Zndl93eNG1h67fDd9XJbn7ww+7sSQTCvMxjSSZByLY L19uYlcxRA0xijiXmEXsIna5fs+/73yf/9D73+5PhO9YK+9L+LJEQ2Cc90xhmvcCodN7pXCT9y7v Kt+qwBatfSG7zbeT3Onc49sT0Bled3hEEa2gDr/E6TWSw2yZ5Ml3AzgPaVAf/ETmgmIe5rtp2Env oPchU6SheSmxtkxEzzqqFLYcPVKq9FWKGE4xMj0srUMmYaOXFgJE38AXg6Yeov8Syw4jw6uSCfQq RVFTefJZ9pPnLvrTSJeNclOZr29+t3AI2nf/CZqm8AdXrDjggY89+UZLrZ13OKiaKdC7ZwuyHP9z 87J1a+/GnsA7yBO4AElmFuyVI7JlorZLe4vl5upuS49lY/K15IGkiTPYjZbdFBU0ZqtANazuIzSb AQhWIQDRB2XZA5HkhmNBEOmIS34AnCJfVenWGQ2mIJJF2VQHUlD07FNEc6VsTTMyM4/Zz2gYPrdw K/xDka10lkKQbqY+VRyvZhy861dK94fVeHQMYyzZEkkvmtCUAJLeuACx64fLBn80XVBbLF0dqsHX MUwJR6WhYkf7O/G4dzMeN6+9Z9GSWsZNG1wPXfazRXCpYmit/WNLQQ5iK5bHxXMfZQ2s08mR3JVj Fqu4iwC/KNykuQlJZgWohQG5egw9jyY+lN6KfCEdiZyQjod1V8SvqpyVnlV7vfXG+Pzau+JdtY/F 76tdE++u3RawEQZsDWYqBsKo1RqMQQIEktVukeJENJe2wIpqSTQlJbAiqjfkCR3UwZhfhKLJRBm7 jRuMpN2IwxbrjfuQL+TJVUldoeWh7tCGkGZHaF/ocOhYSBPis4mLTxFWxVpg1geaDAwAW49gk9pa qrtpHGYkyqR4O/AOHAeegeM9CUNN38C3PQEDwBmMlCGDN3FLLT5ZyaaHAqdFQcfIBeYGs/O03kaE hjrA1NflsBUhcllnbc0pteQ3q2tf2D1v2lkKEfof4xZVsEsOvnDixAsHl+y9++7f//7uu/cSu3+l WIytk0alLoopDNszz0iMPLkVwk2bICiMf+APf1zxwB//iHRhMtKFq5AuNMCr5cpVnhMioYEMnK1b qFsOHyC64VPEBthLmFbrntZv1G7S79K/qz/k0XsMDk6x23ZaoAl6mpumOXfQEU8rgCc1LZNKpTPB OGVS7b0VWqcpIakgpeJXc2RaEb821ODjUC5dncvVVAcbIC4x0cRjMTTdDUCjp0wGo8gfckO0Tjwp m5uAJFbvyOzLEJk++PfexrEXD9bUYSOjaFTR5CuBDMePGvz/lCeL3iqlc+DAq7ivCMS8KYenyJtC Ckl5vFq9LuLV8gL06H2qSuLuKUMR9a1AN3B8k2gRaBX9tKshXLWvyhBGHVTdYiHoj4XW4bkTV1w4 c+m0iwSeFwpf4eXjolsWThuZvrKcI69oNsJFJ6aMHXPvhP5/DeoveeH1leKi/i8G+2u1qD1XwMtI GlitA5AIwS6WE0G+hpf5c/lZ/AL+Vl7vslJTaYRjdRbjVK02aGF9/EoG4VjydaIPPrDZp7NaTABu hziISCA3xKbRIOd8AnLFef85i4d8PKpfmaXm1m+ODnP1QHmVARPKub7HXC0+AGL5jYvhOHzf/W7F GRv3NeapaB3vvVc45+Q/yywVwjLYLm0s3EQ2KHfmB0/ISQq3NyMo8kJ7uw+hO98Cexfogl1EF7nS bjvbcK/hCcMa3zaf1mfw4kSID2mz1mzogy9s1miCZvWGZZtZ55nEi06XjV0RwMHp6bKDIEgyIFis ot8/QQM1fGAb3ATfBO6hwKlC2S4Fp/uPtH7TP1TfgvtYoAUQ3/ngHZcXHWlr6nLEoRtvLlgxRYMY O3XqiEmFr5UHYLziVnz3/ScVzZ91xfJKQVH8uy5FWr4DzesKpOU5om8riCMxZq2tcVxBRFuUrTzB aW691PW0i9iZhQk6EamKJ7KxXGO4NTIi3pqdS88Nmee4YMhV5yKS9IT4e5H3sl9EvsieiJzIGpoi Tdm54bm5NfSakC6cC4WAasbNgzbch5V+IxCgIOAPtVCtglImi5C3MC0kCMFQ0BcClbWKtchk2rKZ TG02WJnNOczKL7KlTTab2RR0YDYa8qBUKpp7lcJFC3ppVyqKz4+Nx6dF4vFoJJiKhCPhsJjL0rlc NkS7nC4RhGgAQsCVC9PaEAzmfT4m79VF86nafGVlKkWY804HMOQhYaKxC23sDMHQryLhybltsBtE 0BnrvGxXlhCzmeyMLJnF1shf70JrP1p95hm7jARlFI0ZtIPXIZ2Rr9sOHwNdarBpiEqKW8jiiigl 4orDSsVokkLxLvKFuMYlGoUwtBX5uQd6A82YzHGg11evbvkadctVKtueIRIpxCzSJbYi7+yno7XD Dd6PX4tM2fcuP4VO6ho43OsJZ2mFoeLA3QAO96Ct0j5RiV4NIegQQtC0IYJbWWYHvimvTEFXoKsm Fq/6tjfCZ8XBykmcyx6kLw3hmkEuail6BYdXK0P4Upmz+Dq8JKnoihUbjosLffCJi5UU5DF8Nl94 CP68cGeZ6/gdTGHzoTRf/bLQPli2fA3SqO1Io2ikUW7QIWdnMtcwtzAIfFimYsyIUOJUjBCdbmal wxF0AwQMARQdFDWB2kGRFM+XW0OlleKPW8EftYD3nWr//ontX8l1KDPq6G9lcIU+wmRtREJuttfb G2yN9iZ7s32EXbaPto8xOqOWOstGb09KUwHrIDHZN1M/07dAv8CnrdPX+Mbox/gm67UZQ/0IRT8P NcGmtpamphEtwXrGjk8FRCec6NzvPOw85tQAJ+WUnaSzzeZ02m1BJiIoQAEEqSARbAsEg0IgGKnL qCdrqVqiti1dW5tJB+vaZHzykkOj4ei21tGj5dZgZVoXiFZVxvw+HdQn6uU8aNMlJNIjGY2kvr6u LhJhTFabyLGykMuwXSzBnoz6A2JFFB9Hu6JE9GQLSIutLTiQBVp2tOxrIVv4sYkX3GUxE7STbB7c DBbZFIsuSvlXZyP4f1TLdHyfll3SGh22wgqYGA4qiqhCjMXdvMmi0ZojcU2FALU63sQJMKZNCNBt 8QgQlHpxKY2QOjoQ3PAOFYWZBr4EGvTSD7yPPut9BF7eKmFPqHZH0uO/wNOiVJKiLf5LetBWbXva 4WKUiJrixQ4BlJBDbUZy6nEZUhmupJ9dceXImVLDNU0X1o1VKmQfObu2as7INmV3QnVlasRo5fTH CttQ2SVnTr5mTFvbmPyZF/RvwtJMPCRPGnNJ/1vK/n2jp/jjs9WDIWcESfmVSMqnIClvgEvk+oO6 gwZip26ngXjS0KPrMZDz9V16YpZ+tmG2l3zEu1pH3CD0wo0E6RPmCgSAGoIIGJxqLMLOCAzBtClp 1qBzOKZVlyQbsEFbW3FVUjEtBSJUhBgGbK25NhXY1uQbdHAbPAxEOEt2+SWNHmFcp9NhMppEzyEe 8nhBoRR4uzzTjeAtj7HtEGQqIltVOPuPo8Xi/17J9X/FtbTXpzXoDToDofNpkcB5DX4V2yYUbOsd ZIvQ6Ef/8qKXVsVrvtJioKMDIbi6ouP5Pek4VYq+B2+nTL2nfcaEhgsVefhIIaf+8qrzrp9fjm6L srK4/bR4YNkZ/V8Nodv2G0bf1v+PYQKCMOB9A4c0zUhCzICDp8sNTlbD0hxL7oF7zAeJD7R/1h80 667QX+4gLiEu0VxuuNw013ql4xLXHM7ASKRdMpJmo94iAaXymm9VtjZO2cpWJrcBQApkwAwEMfuI JbLbKelkXJcto2s6dTt0+3SHdcd0Wl0f/LjXjUxQyW9Bi9vR/o752GUo9WY+pcBzO2ARAqUHjm+k aBvNbRv4GK24H/daA47AkD+Ja5JU+piZxdRiGg8OHN502QOtZhoNBhMa9Hhw4MZufoT49LTZid5E A0s7uBYaDy7aTuMrdspOtGMyIbBmwANB2oVmWKJ7ljVEw7HbUnymPMrVXDj62s7Cl9C58zXomvxR d/dH+AXXv1o4Bh07cFPxY799/C+HHnv08CEcOS/cpGgv7nVXKbdWm+yNFeiVqzwHTiY6rLMhmhPd FdYF8IbE1VXm3+leNb2nf8/4fsV71Z/qPjEZeDJF3qC/i1xFriV1rE9RWT7t53mfP8iqq5TZufuU JWlkMF1cjaA1nrbnGV8eSaotLZlNcQmu0OiBkI/oopLdAA2e2hSwiQG7f4J/ur/Tr/HzNeXBdwXa lULvR5uVAMIPxQ9+moJVHh6LWTLY76hUCFhWEeJZrx7484sVoVNKenGRm6plOLqDg+g/qlKnxNLH r114439dU+h/+aO71DxaZ1lI/bG3Hl514MCqhw6QM1ddOG3Bvqs3FQa2FHQqHwjhirwCiC6/b9/+ 5fft34ejkWjunkdzFwJpeCbuuvdNj70xjoWvwd64DjzjXRchzwXTPbPBzzxzpWvAjZ6fV90C7vbc XrUq+mjqoarnomtTT1c5ngrBR+JrxDVxUvUfbOVhINU2m5ndRbOsmuFzsRkuOQfAU1HpzjsxkLdV Sj6TEUeIKiSwIqgPQ97Ii10maDcdNh0zkSZPdULCLYK6hQ2CZp9wWDgmkAKfKQWRyyNDSmkIMr1o UjG9rrX5h8JCP2FlT51Yj9oiJI2AcIRO4XaMMTrZh2Y2Pmxm1aj9j9ZvqEHR8LDw0NrXlUiyEk8u zFNCess+fqnQD8lXDi878PDDB/CL2LMKz+CJ10szCr/bAuGmzQOF8fft23ffffv3q122NReQi5C1 Z2T6RhtMGSeY5jqvcy51Pqh7zKX3qWEcYXfRe/My24h1yNmRZWPRKcOF1OvkCbGzlSrqYNJso5Uv K9fqrdAFaBtlCkfyIKkztVJoMUS+GHbJvCa7/pie0HsqAS2G7aGJITWAdyykC/Gp/nvcZa1BcLGW Wqul9M1WHOtS70DoaPxPqY8/uQiimXMUZ26Ti7axTl8JQRW17pTS+R8LwBLEU0+OGX8z7zLZXKEs X//IDrhAge5XYS9+r1JuQc488MDkSzwuXu8KeaauKWSVyXE6OOKlIr7ZN3CILCAtOw3+Q76DbvWN JJxngnZw+WlrxbX1v274g2vPqL+43mbfbvlg1N9dR7KfjTrpOp79dpTT7NKx2hbjKMHFsEyLd9Sy 4Mrsdrt5iuuChssb5uavb7gpv7RhaX413UOb7slvEohzDMl4KFotj2jOetx2m56xNIJsTSakqaqz 2yykCZAOPj9ihOSQRpv6YG4jKVbBqj74oOyL1kkSyOsnN0oTApgISQY8bdWTQvk4I8l4lWTReii3 d8ZhnB8zWk/qoibJfFFR5RT2Y/HrMmDyaLGKV+FF4jnuGCJFNpbRIoudE5xqm72G+lFO0RdxRbgW RgB5b6MA60U0OEehQ7bVLQDO3TKiyd+MsIwn39wg1AmAHulQoLRS36sMRea0gnFKs78xT2dNvpcG /go4pL2nIbVtoeuR9vYG2WbfUFxXbd6noOsGtMYakduRp9HQgFdcN8WgIzSchpfY02i0qJ5Gm+2t Pvx70JPBF23BwILGQ9kSi1b3H2ochBvplpE9aV0Z2XOoyW5FNFzsZ0neqHqzOK/XcO6Su8/Ot2Vu X3/axdP/9MYbiw2MVaF78lxoVedT3eecW3jjjjMPrFhHJv1IUpcHPCzfXNHQmMw1x3x2lzt04+lX PHNJkLZ5Ai8g8WWqhEzr9aednU6L2cuar1yMvc77EdrK4yowsEcOn/BCq9fjJZ4ybTK9ZnrLdMSk /bntdttK29O2Xea3zTrOgDtcrwMaeLXMGDQavSEIKdrIOOyUw0lreUu8Dz4pOwL5cFifhxDoLBJv pu/Q9MHnZDqVMhjFqLQL+Cif6Jvn2+HTIgTwSW8ldvTwt5ooaZbjpcYbuFhPTZR+r5uQml/xeE1m s8coAJPXIgA1v1Is+y5puIMenqKK5k7Nt7AMgvtK3WehYeH8ybvqaSvltor/mr9inUJMfARPBjkT K3f/m2fMrBWt+BsOpLPuXEik8UmlEw1+jhei59hOzgQVyBJbTJpNLBFjocdgNyoW2JI2WCxGQ9Cu JlLN3rOLidQKCR9X4vbRbWI4LInBCsjaaVHKgwoT584LgYDdYMxTdh0tkWZRBIBjsQ9ijFMO0bBP D/U4wB4bHmBvblZbjKodFYu1Lf/xclgyt7IJytjYiqeE0Z0u3NnVpXEIwKmj1SevqqGrqIYvAwap H4vAkHPg42LGUCGAVJQ9fmVu6ocOS/yP29fuvkE+T40EXXb2H9co0/CV4kbc8OjoqQuJgDIZd587 9yV1V40j4znI4+/DRHMQgtPl6jVwjXOtixRNolnErSJsol1EnlseNjibXHOISx2X05eH1qOLnnc5 ZQHi5iXrZMYKrJQ1bSWtZytNTIImh1NdRNHdCrAsDIo7lKzDnQ6nKS1KgkYCqmHPVrca9zx7MOzp ICAUnQ4a+ZF0CADRRdMuF+1yQmAqBji9VN5E5k1GXShP98G5stlF5NOOVsd6B+nYBucCFzTKVtkJ M85OZ7dzv1PjfBmuRzITgVKRJ4eA0KcKQ/QoKGP5tjb/JDl0ONXtB3htP8Bzw5FAlR16SlCvdvgZ YsM9hWeU3qVQ6XW2DGYjsEr9eqRmnBGZTFqVfkJ4Oseq/l8pFtYwMKB5AM1kjEzJq2NsBXc7+Ty7 musjtrIbOQMgKGIxey+7nn2FPcQWWEM3sYHYR5AGjYFxa9xMjIhrYkwF16BpYE7XnM5M0UyhpzJT +amxOfAKzWXMpdyl/KWxGzTXMg+zD3JPE2s0zzLd3CZiu6aP2cBt4bfE9rBvcB+wB7i/sUe4pJn1 skkiySa5JfyS2Fp2O7tLu4v+kP0MfsZ9S5xgv+UcKofIRg2SiFR+6Do5NS8MQVgMy2HyGN7rDu8P k/PCXWECE0aJcHiVwhYNFtmi6+T4dIXMTWLO6AQj+ZURrleIoySuhzeuUoijwSJxFEml359WWKNB kXevVFijA+PkmhJrVBxkjYplrFGxjDUqFlmjO+Bh5G4vQNJ0GIci4WE5pAGTICQnaUwVecmTF115 qy5vkUTRarXoOt3Q/Tse4jR6FKzg5UyOl2PJLC9HKtDgD6CB96DB7sjyeXlGDMa2w2cUuugymWMn E3J1Y5bA1xH4OkKmHFmiDz4jW7XiDAYyv6M1K+i8Foe6Mjm86f1f9q4/Pqri2p97Z+dmk5ufm5CE hISbTbKBkOyGJCAShChIEQggIo0KlEACCYYkhoBAKSJSpRQRESmm1kcppchDpKgUKVKllFJKKaVI KaV8kCJFH/6oRR+lkrzvnHuTbPjhU/vD/pGdzzlz5syZM7/OmTtz997dPjcWcrKHnUQ1HEMDxyjP MZSpuNgTn1Aoizv1ekA+JnX1dKkuX9FOU/cgj/lo/PjWa/c76gnS8eoBU3wu8+Ol41seL+1x4azK pMT2T10PuKB+qRbEZ37A9Kqb/OPH33fVU9nXYjpPmbbccXipm7uz2xXdtqHR6tNChMhqeYC05VAS /ABpC08srnx5e+Xm7soZ/6zQvU++UL79sWnq7vRZtentpuldLp/Rgjx0ih53+bzeGOylFVhvp8FL B+orip/sGtPVo3v6xHw5Rk9W91i6eidq0z21abXpEwf+VPtp9EHPwbQD6QfydxfuHhjlpkRa7RWU r3kGxngGpkd706PTCgvytbTC/PRoT7Sl5cdpWn7hQI/HY6UVxqWlFepFWlFUERbK2CJPUVqRVZTU syi/KKMovSj7lqKBRb2KCouKigcOHNCnz4D09Cy/P2vAXbJwu+Z/0RrYOCBafVmUrGkyPC0tPjxc UrwWH5+iNUbJWphG0q35yH8hvTHLw3JpjVl3RaUEnNsIMqXzoLCwpLBso8g4u0MLaf0jmpaN8JnO FxLf6RwNpPbCnUvOJKo3TbEL7qx+jEDN3jvq8eV3EqPPKKZiOHESJUa/8456u6gdko84Xyx5mver L5I8zhdJiDe9ENfNfhHZk67i0+reFuKTW5P79Xc2os5qr24zpUf3RvnoHBSOVr9jEh2GYtGpKBOd ig1vtLe1FBeLwse+9L8UkxgRVViwvfncVsTOb4/wd0DcsILm08WhHnNATKrpGVCg/qpjKIiYsPiE /jG4ZPYfeHOqZ4Cm0MAbusQM0BQaeENyNCiggepfwTSF0sJSrP6FUUD5cZ2T+0erfXe+2mgj9jjx wO3Ne16IjlN3vvcUR4BI7weUptB1X3RWm3HNfj8h6Fumdqfz3mA4vyHf+iMp7X81xUjX12gP+uKi cEr/QDnFN5tebvoxX8Ca3ktNior1aQ82bcyIRf6b6npWriVrKeXKhd5UuRnaz5oeC4mPcL6OurHp 5/a9zoj4EBxMh7g5R92jeU+Lsb0qPN4Nr3qyab5rNbwqX9uJzQQlehK9PSLSEnppvWJGRhQn/D32 b14zNHZY7FBvpVYZMzt2tndx7GLvyzGvxO7w7vX+zhsJ1/Tke2LyY+09TWpERKB1M5PsTV2QqqU+ 5U1N9XqTvek9eqrvfP15fDZMKDbz/f6e+d4e+bGh9kOAUj5lPwIYqpH6cQdcchLyErSEAP/Agzcp Nj87Q3GnZ2UF0rOyMtK92ene2Px8y36TNwbuS1oceWJJy0eGJ0Yjd6r0hKqtT3JyXFFSEjxaV1uf jKLsnkU9emRHUuqoVL0u9VTq++pkWjhKvR4QLS1ZJ0/J96UhOxdk7+BV3P67j/H3RZ/F8tdykyFo 8+M8afmI28/ftD5iL8qftBZ/2g1RSzL6SukQd3Q/dz/7BRqt5d+7rmteV3wPmqZXN83tnJoU0Sn+ LN/o076sjeaN8Jtdk6Lj/JfPP8S2xy/2aSFYmz0RnUJ5cR6p/9A2IRhX2x0jtUa/QyTehTUl0FvF YZHqFrHmjgzTX2n+iCKaL1IYudR5JCTAP+DhDYtnkxkUG4iKjY2O8sZHarpHtyIi4yIiIiPC9Ugt PkIP1yKjLErArtcyw8O08a6iqLABYbXqfl3n+PG16o81E2cG3aIrcZ53PtP6z7Y3tv3HEZY6+2fq dPtLc11dxrFccYwVC/GxrVivWpao9n/ecuU/ufAb2j20TlrL71qGpPXSWv/dRRy9/E29Dz9vcZn0 +ssf2Ye7YZdv4j/q3DdM312viJ/z31vf4ITH6c2WoEVpU7RXtFf0ZH2YXqF/U3/DpbsekaVGwDgQ 8lX3t9x/DwsJ+7vZ31xph/C+ESMj74uqjQ5E/2/Mfs/S2Jlxz3ca1qkp4dGEDzuXJo1M/lqXG1Nm p67uWt71lPVS2vfSS53QiPA7O2S8nrnOd09WaNaGbmO7+7N7Za/tkZazP9fyPxFYl1ffc1R+3wJR eE9hc6/Xeq/vM6dvRtGwoj93hI7QETpCR+gIHaEjdISO0BE6QkfoCB2hI3SEjtAROkJH6AgdoSN8 EYG/Y+mr7yL1z6LqM42xojWK55SidYrU8hxa0N1af4d2BclIStRWO7RBXbQtDh1Ce1tl3JRH6x06 FDIHHDpCb9TOoUb708u10KE1Ml0/cmidQmSSQwvKlWkO7QqSkRQuRzi0QZHybocOocmtMm5KdL3u 0KGQqXToCK1EzoJmzSVQV7jxU6Yl6Gjjt0wbzP8T0yHMf49pN9PNTIc6Y2jT9hjatD2GNm2PoU27 gmTsMbRpewxt2h5Dm7bH0KbtMbRpewwVHRbUflO1LSSK6fAgfqSiQ7oyHa3aFhJgOha0J+QmpuOC 5DtxH206PojfmcuOZDqZ67J1pgTJdA2iM1h+PNPZTN/LdC7TcxTtDmq/O6iu8CB+eEtfniWL8jEi edQH1BiqpArEJVRLNYAGmkN1zBmIVD1ohcvAr2IJP3JupmoEi0aDNxXlG2gGpyoQV0B6FnA5JJWG mUhXMdeiEYjvR1zF8mWABtZdDv50xPV0L3i1NOVztEtprWGNdrk7kapCSrXEojtAlXHKrrkG3ABr sFh3pdPCydziGm5XFUv7uV9Twa3mFl7Znr7X6WVfHoV6aGhpXy/o6olgUTdoqUJd9ciZwf1toO40 9jry7fXb2kehRyUYoyHIu5/bpXo5DHkNCNUseReXs3hk5yCeybNjj5A9A1O4pgYeEZWu43LTedxa Rm4Sl20Z1VsxrsMx/3bZ+qCcOu5NOWqZzBrt2bif65oMfO167bSSnYxWz2RLKGfZWuByzq/jkZ/T Om92XVWOhsmOrgrGyjqtq3quJKqZ6oZy3REre5vUWte12lVzle5PP0pt2stZ01Tw6tmabLua3Gq1 1+59myW3b1dR0Bionth9aeD6WvxB6bf7Ws62oXpeyz527Z7aI13WblQrHL+40jvUqDZAbiaXVK2d xb2paNWjJKsh8Ylz9KyVn5fXxxpTWWGV1NbUNsypq7AG1tbX1daXNVTV1vitm6urrdFVUysbZlij K2ZU1M+qKPcPrJ1ZX1VRb42ouN+qmmGVWQ31ZeUV08vq77Vqp1xXl1VVYzUg786aqoaKcuuOhrKG ChSuKQ/U1lu1yKm3JtfOrGmA6hn+0RVTZ1aX1bfo6RtUZd9ZFfUzlL5e/p49rW4lVZPra2fUTmno PjaI78hDfNQdJWOG1N5fVl9uDatoaKiuqL+rdqY1vWyONXNGBRqEDkyprWmwymZYdRX106saVOMm zeGm3nrn8JuRW8+Juvra8pmTG1Q37q+smlwZVBZxVc3k6pnlKNpQa5VXzairRgXoG0pVQWAypCpq GvyW1VJ5bU31HKtbVXerYvokVapNV02L9DWbxOLlVTVTrfqKGRiryWpog6rnQXZ0FXELulWhloaK 6Woe6qtQa3nt/TXVtWXBlaLRZXZTMcat01E7s6FuZoNVXjGranKFkqmsqK67okdYBGvZBctgbDUw 9lrlgFoEDGwa0m/xAt2Sby/9yml4mRSN4ofiFfETwMtih9gUpEtJV7Wm32DdFe3qqminjfW5Ul09 XcNcX3LdBHwjpMvgFMrd7ItEpbZF+y72a2oRuBny9c7lpaxlz4hPUzpWcmrdywV/BKmdUgZpzbxX Akf9+N0g3ttNAD7Kvzf2O+Qd05eSpj+qP0VCb9QbQX9b/zbop/WnQX9Hfwb0f6m/hdf/ol8E/Tch SROGCCEh3MINOlRglyXCRDjoCBFDuvCIeHASRAI4iSIJdLJIBt1FdAGdInqDvkEMhuSXxDBwhouv gp4nvgb+fPEA6AXiAugPxcegL7vQH5fmUu/DC7Wjc4Wp/ZUrAjsl4Yp3JYBOdKEWV7KrC+gUVzro DJcPdJYLey1Xnqsn6HxXIehert6gb3Bh3+Xq7yoGfbPrNtBDXcNAD3eNAD3SNRL0KNeXUWOpawro qa5q0NNdX0XuPNcDoBe4vgt6rcwiTXaTPUjIHONm0oxbjCEkjNuMoaCHGXeAHmOMAX2nUQr6LgN7 YKPKmEa6ca+B/ZhRbVSDnm5MB11jzAJ9v3E/ZGYbs8GZYywA/aCxEPyHjMdALze+Bf5q937s2H7p fouE+20zgjQz0sSYmwkm2mN2M7NB9zB7gs43C0g3C80vgR5iom3mbeZw0CUmdpLmKHMU6NvN20GP Nu8APca8C/Td4cOw8xseXkJ6+Ijw52EtLsfSFITBXY6QKKsvm0RxlRWT6im/uqyhhvojR7tz9CCL 4ohgebptq0wpDUqHSmlq90r68DFDLIofPbLEoi7Mp3ZYqkWaLMbZjAun3zv9Xrqb8aTWs5PejorB zt7ALt6NHXsYmbD7CIqkKNQXQx6KRcs6sRcIbo0dp6Llg+GCY+EbU+Bms2g+PUzLaBU9Q5toFx2g k3SW3qWPtHAtRyvU+mmDtOHaGG2cVq5V26Oi9YYeDfFF1I843EIrEEf2s+No+zylRW+w5WKKST37 qnnikA5BXGzzPROd+LAdx+1gOVdCdcKChJUJGzhlJJ5M/KCz0Tmps7/zLXZ+0u6ko0lvJzXZ+clb kvckH0s+34W6xNl6UlbaceoCO+56N0u6rUJriDXBarCWWGusbdYB5kZk7Mw4lHEm42JmeKaVWZg5 JHNcZl3moszVmZvsVvvKFUa8xNbmW2HHWdV23H2uHWdvseVydjnxXrYELacJsZLN/3vBvz6grihe vYjXLTevWGFYpWLJ5BUowmXgxOmBH3ejWPbgOPjuSEo2RsODLfjuWPIapfDgDPhZJ8qEl4ylXLMU vpJHWuig0LXqjIRVNZ8oZzAAHuY/iHg0oBT0EcRYd3PKAbMAiwG7iPKwEvqPg65z8vuqP35zAGfb glsQzwMsA6wELAQ0AtYA1jvxJsBWwHboOoV4DwCrg/8s4kOIz0PPBsAQwAgArhkFOK0XTEQ8BVAN 2Ax4EbAD8Cpgr56cE+7vlvtMYEpOht/PkO0vzskO1Ofc4i8PzA7Mz3X7L+Wc9F/KTfJPUJBT7V+Y M5FhZc7EwKKcF/27FOTm+99liPRPCCyxZXN9gLP+07lHArfkpEK3gkQHNqOcAo+/L6Aw9xTkjkPu bpRfjno8kPG0tMc/HO2ZEJjtL8/dCJ07kZ/nH8wwBPxVSPcGrWAE0k+3a+ditHNtUHoZQz3oKQzL cg4D5vs3MSzyb8rdhngD2rbBaeOrgL3+PQ7sZzgAWsFh0IeZd4LhJOiTQekzoBW8///ASf85B/aj 3v05s0Er+Bj0ZtZhzwPGNzcO/TuDNp3EuDvzkptzxfiPDXhyxwEaAqm5c5F+JpDHsM6/PwD9uRsD vXM2BzbnjLHHL3dLMATCW/qfezYwRM0f4hE8j7ZdvIg5Gcxw0mmXhXKA1vm157Vv6zwGj+fmNr05 /fyDAzuC5u3KeVRzb8//NNT7KuZ8NMMYf11gL9JXyl9dvhT2fADlZ6H8YYzpQgeWOdA+3WYnjQwq Xc/pNYD1wfKw2WD59Sy/BLajYLl/qwPbGZY4sAp5qzjf5j/t3xQ4hvRaxE878UnEOzBOOxzbe9UZ u0+CFjnHH1vt85j/EOBokP0eZWiz36MMe/2nGU5CXkGL/b4N23s7yE4/Yps8l6uD/pjttv38n2Gb GMw2CVu8Kv9t0FhTeG3wcT7bcas9u20a9nyB4cp1pcXO+yN9BmnQgbeRHoT0+yo/QLn5gY9yIwPh gSWBj1m2D6BlPQKdpyM91D8hz63SASNPDxi5SYHwXB+gT4Dy9LxIW16lHflRkIff5U4KePKS4FcL 4FcrkK5E2kL6YaRXI12DtA/ppYHUvD7sh4nww0T4YUbu3EC27Xd5ObDfeYG9efnwtd45GwKbc7cF euceRLwx0K8tH+sv85FuW68aYXeNag1k2I262vzWo+Aq29h8bcjddwUcdKDF588j/oDX5PLAcrSl Re6svxj5YyB3N+KJuRcxfgqabAiyrUPtbOsM0gpa1jbMG2z2Aq9Lfex5yj+Wv0r5A/tEy7XlIPq2 DXPhxDnZBT6GWwLzA6uwtvfG+qBgREEOfKjcXjMK8nmtWhWYj/VieE4e0mOQxpgW9PEPL+jTmn7x Knm1Ji2HHbdci6Y4Y3/NNQLXwCUF/QGDCoYWjEI8tnXcr7xGfGz7TotPFUzyn2MYB3pcW75DX+1b V6Sv5QsMLb6g/IB9oaAysKSgpmBBII+hAfXNxTWg/TXhUu62godzDxY83DIuBUsDvQtW5KkxnVCw DrAa6Wfa0ldeY1rXnivXIKf//+Idmk4J+ns4wxLOnkiJApxA48WDOGMm4ZR3Oy1zjcFZb7nMkd+j lXK9fFYLl5vlHi1a7pV7tSy5z9C0bmiA1CYZbiNCKzeijXhtmpFoJGn3GV2MLlqDkWrcoM00+hoD tMdwyivXnjSmGJXad8PuC7tPW4dzWar2ffMec5/2HM4IW/TItv2iNx7QhbSMZxB7Ad1Ar1M/6w0o BGA/6S0FYA/ow1kiYyPoYic/DBDtAPaO3T2IhwOwl/Rir+nF/tOLfaQX+0vvLCfGftKLfaR3MXRt QYx9pRfn/gz1U+JrEO+EntmAREAqIAOQjT19HuLegH6A+YBFgCWA5YBVOFv5MNJ9aRDOUaU4nVXj FLWAltBKnKE20FbaSXvpEOm+j7PcWXoW+p8V5mvKis5ygQr3Xcjy+C6B0n1vZ0X63ofcxaww5MaD etd3NMuTlQjqjO+A72PfYVDHfbtROgwlDN923znfLi672fe27yPkNvnW+Y74NoK65Gv0HfWdBvWR b7nvVd8qUB/4Hkbpg6BWQvcmH87WviUoudm3A9QCX6Vvta8G1CzfBJRe/y+3TcH3OcioxenfzWfu aNiIR5uHk1I47aAeRF0/AKAFXZuILJxbLcy7hTm3YC8WbMTCHKefRtzFzuuKvX/X8zZYsC/fu4jV W/GwEQu2Y8F2LNiVBVuxRjsxbMyC3ViwGwt2YsFeLNhKFs4LvguAS6BxhM0yALAzzAhl3Q3AOSIL 5wic/SirnnpkrsvcmLklc1vmzszdmfsyD2YeyTyeeSrzbOZ54G2ZH/hmQeJiZlPmOp9LYUBT5hZf mC/aFw/Y75vnW+hb7FuG2Wn0HcLsnfCd9p3DOMVgFjAO+gX9Q9L1/8WMuHhGDJ4RN2bEQ6E8I2E8 I1E8I9E8IzGYkRGUyDPSxRiLGUnFXHioqxmHGcngGfHxjHT/N9akwV8qeZazKQSjDU+0cLqzcKqz cLqzcLKzcLLL9FFIxt6MAxmHM45lnMw4k5mkvqHV/6r/FW38SP+INBELa9SNkbA6AXu7k1xsb9KM NWPJ+MzSQ3Ayt/4Jp+5I/VH9SdT6Lf0pCuX7iuF8XyvCfcD9a4p0/8Z9mDzuo+6jFOc+5v49dXL/ wf0HSnC/4X6DEt1n3G9SZ/c59zlK5jtaXfg+VVeM12Z6kUfNo+6pYM0s8Xq93bx+b6G3r3elt9g7 2DsceLS3NG2dd4K33DvNW+ed5Z2XdjDtoHdh2hbv4rQtCE3eRm+pd5l3DSRHp61D2GKD1/4Ea2zT V650KU1BelYivxTUCnBWtA/qboeOVYcMfY3+CsbiNf1nlKr/XD9L6cZcYy4NVFcIGmR2NX10K9+r Vb+q5XHutMW3lnehPK4K+np9B0l9J3QlcRlcOSiJvDwe6htcyggHTCHNmq/uiPEdXOhAHcraitvG zZpIsdbdCIetY4CTKmQsQBiaMSpjbMa4jEkZlRk1GQ0Zc7kNq6E7VP+B/gO04TkdVzH9ef156N+q byWhv6S/hBb+GK2S6Ns+cnOvwriFJlazxdo+vuKNphhndfr8oKXvp5KuaxDWAzYxZYdg+lppFbZe wd96DRkVtl+H/1nDJ7XxyvZdry3Xas/6z94WzEAYeyGxF2rshTp7ocFe6GYvDGUvNNkLw9kLI+CF b1HUp7ZiTR+sr4Ath2MPkESUgjUnCOgacD3+9WSDdelppzguSVl6VdiI0EJvQbhaYmnKCoSlKdtS Tl0z1w47U84Cr0Zoz9+dcrCV3pdyPijnA+Zc/ASdwa06mNIEfITxPx4+udd2f+0aj7drydIr+hjc u8/ar384qPWi9frxLaw9T+EqEub+pfuXsM1D7kOwzdfdr8M2T7hP4VryJ/efKJavE3FmiVlCCeZI cyQl8jWj82daf0sBowA1vAInqH+NoHW0DKl+zqqcwHJ7ANir0/E2OS2aLiEV1yqnVuBvw9ewy7Pr 59pSuTb1rI6bfZDYB13sgwb7YAj7YCj7YBj7oMlXwoh/siY1GsSjIXk0Mr9gTWpc1XcFWJ3oCI9h IvPUE2vqO4emNp5m2POkdQnipfIsaVphEK+3PU/a8CDeGJ4lTZvm8HQy/yFbU1aWeN25MVgTsSaN NemsSbAmN+sIvW5pF1r2KFr2ONqnccsMri/kuiWEvkxf7vRFcDtd152jzyL7yS25VolP13PlYY20 iOfT9pzOPOu2z2nwvhaejr3fap7PYLm19mzSdof3z/OrT/bf4Nyre//pclWfjjg2b/cpiXkf0Am2 +SCeFkYXgsbI5hU6Nh/MG+7YfDBvmmPzLbx/rcX/82z2H/On/1SL12gbHeC9uJodSsRZOxFn7U67 qCRu739qUH12/9b9W/TutPs0evdn95/B+9S7QtpKO9rOKbHYtSXMo5LYowgnFE4Yw3Rr7OScCEpd Edok426xIahca36Qvqt1BXHidrQPykfdv3Mf/7w99DQxlMTPR1iEMD/WE+tRqdhjjCcyzrNjh0aI X9KSViVsyTaZ1rAo9kCLxjZ9LXKsJ0hD/HzPBc+F2PntA/fwiPvsZ9gf6VoGn743OStJMnhCW6s9 reUgvTqYq7t1XVMn4IXtuDV6pXaR+J8xgrhH9IP6BKTHBnNFX1Goq31WcTvuGtEospHODuLqLhLL g1a45KC+efS1+vfQt+/r67HqPqs/C7/epG/CWXWLvgU9365vpxD0/DVy63vQ/1D91/ohrI+H9d9S hP66/jpF6cf0YxStH9ePU4x+Sj8FnX/S1ZpomRbWxHQznTqZmWYmz/wnrRr/3raok/ujjB//Aut+ 6gup+/EvsO4VX2DdK7/Aup/8Aut+ilenfLUOaS1Pq3VhXjbWLI3eb8fz8rnhRDtekqZ2kfva8Txa OFIvtuOFaerppjXteDp9jNTSYB7OgheC9nVdnH3d+aB9nc17m84E7ets3mne//VrxzvOZ6Ju7XiH eR8R18pTK7lacYj3IRrvQ3TehwjsQ05iN3wKu5GQdh7SarHuE+2sV+Engvg2faTNytQep3XWHw2i H2+jg2Wcsk8G6bTpP7azHtWvbuQFjldPBnLPUtrk0Aslt5Xse6MahZHErj+sNd3uKhx5hiiqD5WY Nf+pIeik8Cn3GdoG7V2+n1qPfmN7TlpkZCuo9JVg8/UgGHdFelIrrUVWAmo4tnluKgnL+wLDyS+0 9s8d/mlnrE+7+zytxbPdDybMdrgfUEgUWndtCA9z6NI2CI+nEvfgzx/C6R8p/f+Fz3mu/1w+FbKZ tJD5raDSV0J7/sSrZdxJbbKgW6CFV2Kc+A8Opx34Dwv/dp9SzztfCjpLqG/n3E11l88Eh89w1VU7 DI29VF3H9jX3abmu6WWyE+NU4HLGM2Qe0xrzuwFPY36peiNX97pKmJ8FXCUnAxe7yoC3uYYzP0qV dd0OPM41mnOVzHTOvce1knMVfYPrHqbPKJr1j2bJexx5lbtbbATOU2/56nnGbqbfZ3qCwuKIwq4+ jPdwLlorwhVfhLueVlguZUyM1f3Y3WK1wq6JTBcy/pg5SsNO1laqSmkX5D5FO5zZwD7FAf+Eorl2 H5fyyXLGSxmr5/InqFxtgmoD8B7Gdo1HuK4+CrPkbtdHTM9mzC3k2nersvog1j9IldUH8VwM4rKn WHI50zkOfpr5Sudy1rBOrgGep7C+yPUQsMV4rjwNfFF+D3iLvIyRqZOwD32JGmdxxMhRWI0z6OWK rzjIVSPv5l7vZLyE27bEprltS3gElugbeGQm8mhwOxVHWy7quM17mD7C9Bamw1X7WSaHtX2luSdj ZWP1zTcCz2q+A7iyWc376OZngd9t/raacWXJ+srLxxWtMF1qUvdlL7GF72N6X5Pa/61SWPcovrZZ 8XVP0zbG59ScOhzVqvrLsFItUuVq9Swf2VTHuL/iMD+Hy5Zy7aVctlTVru122mApmstO4Novce07 Wf9y1rOba8lhmeW2JLf5UtMmxeceeWys5EEr3znONXpYJlFh3cd6JjTxGCpMl5izXLVKW65o6IQG OsujsZG1uVlPuezMI6MkL/CMDHVGTLXwFM/UBZ7BC2xdF9iuIu3+2hbOvc5hDQdYciiPzwVlh7SU +5to62cPKlW+oyVy7j5lt3RC6USNm7i1x5n/NPPXqHs4ik8vsiUflD+HhofkS8Ddld2ip8e5p2yB ylZJfbTmpxlv4T18PtN7mLbPWHySaZ6mQ0NzNNPHFMYJTtGLGTfYpZr/F9hQkk1850lbxxrsc9Ql lhmuMFpALecmjJ1aDUqZ8yHjn3DZeqafY/x75sxj2j4N2ue6HzDeyvjXjA+z5HLGp5izijGfK7VE pt9m/ILCun1/6xWHxulE3MojvJe9u7B5LEptVxj8UcyPU7Rrn6INL3N2qTVBydBeF05lepfLe5ke rsoqGhpwttXfMEoZFyusZlbEqxVSWOp9M+BSpUfJi9UK6+XGSMYvsO3tY3qdGiteYUYY8xQnJIFX eLXyDDIiVW5IKfMPMWbaOMDr4Wyml7M2ti7WMMjhnOBc1nlZXWXKm+4Fbrys1tVZl3+krjKXf8G5 ir7NdQdfg5r4GvQcX5uUjz8ucf3UH2j+DrDf9SFrvonLPsH6p6hc4/tKg6G0zWL8kvGguvYxv5zp 0WqE9dHSy1e337D+44z3cY0fMv6JylVPSeizpGr5PcYwxrcAxxp/UBqMTuyzvCawt65hf8xjD32w KQa4mPEBvlrFqrWLfscr2G51nQJWZ7/3eU1Yynp2qnUYVzqF3QrTPvasCcqj6RL79QQ1wqDVdSpW WRRqVfZvsM0PsX3KOTXnKn9n+5zAeDfLWGyTPsaDmM/3V+27JliPlMwyxnMVRgsUPsN4J2seojQT NcdzLbsYY7fQPKHpLYVZz37GrzF+l7APQRlFP88aBjDeaK8TpN4pfFiroeB3CofwO4VjW98pTOX3 AkNI/d6Im6IoRv2YP/PUHi2EQrGniiYPmSRb3zTU+V5C+3cNU4PeMtRwQrDjSIqdPHl6HTUwnst4 QXl11VRaPKWqpoyWMV5ZVVPVQI2M11TNqK2m9Yw3QbCMtjLeXl07uZp2Md7DeP/0ivIqOsT4aL3S eYLxae673op1fmeReHeosAzCIUHYFYTNICycsSTeYSpsBGG3gyMxAj7yU+9rvvVol6tz4ln2e3y0 1N61auOAQxHPcuLldmwctuOwHMgjjthrl4s877z9uNnmxzhvI8Y47wnGzFNnOtLCR7D+BvXMILlC wkMiQiJDovi7pb+p1V3rqln85uBuaEkkL+Wg9cU0lMagxcpLXMKjntRk6kut1JBW6rZWamgrNYwp AzXGURJZGJMc1vIX1vABl/4rl7zApT7kEh+pX76BlSViFDMEThL6RZHApZK4VDzLd1by6lRA4aIT 64njsupbw7+gVhIhIoRC+ElMN586hbHAeEBnixX2j/+EiTDeQ4fzOEBCvGXEiSeUhBFvxMMNkgyc KNXz50pCG0sbRKqwRIboJnKEX+SL3mKhWCQeFovFErFMLBcrxSrRKJ4Ra8V6sVFsEpvFFrFVbBM7 xC6xW+wV+8VBcVgcFcfFSXFanBVvi/PiXfG++MB1u+tOmSsDsqcskL3kDfJGeZO8Wd4qb5O3yxJ5 p7xLjpdlskJWyemyVt4nZ8iZ8n45R35Vfk0+IB+UD8mvy0fkN+Q35aPyMfmE/Jb8tvwv+T35A/m8 fEH+SP5Y/kS+Jn8qfyb3yV/J38jX5e/lH+Ub8k35lnxH/kV+KP8mLxuaIY1QI8KIMToZXY00I93I NLKM7kYPI9cIGD2NXsYNRpFxkzHAuNuYYEwyKs1EM8nsYo4zJ5rlZqVZbdaZDeZsc565wFxkPmwu MZeZK8xVZqP5jLnWXG9uNDebW81t5g5zl7nb3GOqbzw3iBSRgtnoKrpiNtJFOukiS2RhNnqIHrCi XJFLUvQUPckQvUQvzOmD4kFyi4fEQxQqvi6+TmHiEfEImeIb4huwhkfFoxQhHhOPUaR4ArMZJZ4U T1K0eEo8RTHiO+I75BHfFd+lWPF98X2KE8+KZ6mT+G/x3xQvnhPPUYJ4XjxPieKH4ofUWbwkXqIk 8bJ4mZLFK+IV6iJeE69RiviZwKlW/EL8grqKX4lfkSV+I35DaeJ18Tp5xe/F7yld/FH8ERb8hniD MsWb4k3yibfEW5Ql/kf8D3UT74h3qLt4T7xH2eIv4i/UwzXKNYpyXGNcYyhX5sgc8ksECsg8nFLz ZL7Mp56yUBZSvuwte1OB7CP7UKHsJ/tRL1ksi6m3HCQH0Q1yiBxCfeRwOZxulKOw8+krx8gxVCRL ZSn1k+PkOLpJTpQTqb8sx1VygKyUlVQsq2U13SxrcMW8RdbJOhoo62U9DZINsoFulbPkLBosZ+Oa +CU5V86lIXIertq3yflyPg2VC+QCGiYXyoU0XC6Si6hEPiwfphFysVxMI+USuYRGyaW4kt4ul8ll NFqukCvoDrlKrqIxslE20p3yGfkMjZVr5Vr6slwv11Op3Cw3011yq9xKd8ttchvdI3fIHTRO7sKe bbx8Vb5KE+RuuZu+IvfIPTQRdr2PyuQBeYAmyUPyEE2WR+QRKpfH5DGqkCewR5oiT8lTNFWekWeo Up6T56hKnpfnaZp8Hye+e+UFeYGq5UV5kabLj+XHVGOohb3WcBkuqjPchpvuM8KNcKo3oo1ommHE GXGk3ktJpZmGZVg0y/BiV3m/kWFk0GzDZ/hojtHN6EZzjWwjm75q5GDvN8/wG376mpFn5NF8o9Ao pAeM3kZvWmD0NfrSg0Y/ox8tNPob/ekh4y7jLlpkjDfG09eNMqOMHjamGlPpETPBTKDFZmezM33D TDFTaIl5j3kPfdP8ivkVWmpONifTo+ZUcyotM+8176XHzFqzlpabM8wZ9Lj5f9WdCTwV69/A58yc OZZBQiL7vmfOsS8RIslOdC1l3/f1krJka5EUQnYVopVQEiUppHDTaintmy6VpHjnPNW5df/d976f z/u+//v58zF+zyzPzDnzfL/P88yceU4sFgvtwTZhm6C9WCKWCOViW7GtUB6WhqVB+dg2bBu0D8vC sqACLAfLgQqxPCwPKsIKsUJoP1aClUDFWAVWAZVgB7GDUClWi9VCZdgR7AhUjp3ATkAV2CnsFFSJ ncZOQ1VYG9YGHcDOY+ehg1gn1gkdwrqwLoj+rX33oEBEHJFG5BEcUUXeIjuRPUgBUoyUIweQGqQR aUHOIh3IReQy0odcR35DbiH3kHHkIfKU8OVL5C3ZjuyI6qD6qBG6Gl2L2qFWqCPqjG5EPVFfNBDN QfPQQrQErUBr0RPoKfQ02kbkIY12o73oNXQIvYneRcfQCfQJ+gKdRKfRGXQOXUCeUjBEnMJN4afQ KC4UN4oXJoxtwDwwHywAC8EisBgsHtuCZWI7sd1YLlaAFWPl2AGsBqvHjmONWAt2FuvA6J/BDgQm g4DJSMBkMHAYAhxGBg5DgasowFJMwE/MwE8swE+swE8Y8BMb8BA78BAH8NAi4CFO4KHFwENcwEPc wEM8wENLgId4gYeWAg/xAQ/xAw8tAx4SAB4SBO4RAu4RBu4RAV4RBV4RA14RB16RAF6RBF6RAl6R Bl6RAV6RBV6RA16RB15RAF5RBMQrAeKXA+KVAfE4IJ4KWKcB1lUA66qAdTXAujqgXANQrgko1wKU awPKdQDluoDyFYByPUC5PqB8JaDcAFBuCCg3ApSvApQbA8pNAOWrAeWmgO81gG8zwPda0AYwB6Ra ABYtAYtWgEVrQJ4NIM8WkGcHyLMH5K0D5DkA8hwBeesBeb8A8pwAbc6ANhdAmyugbQOgbSOgzQ3Q 5g5o8wC0eQLavABt3oA2H0CbL6DND9DmDwgLIErhSygSEUOkEDlEGVFBppEdSA6yD9mPlCFVSDXS gDQjrUg70ol0I73INWQIuYncRcaQCeQJvVSQbZFpsi3ZAdmBaqN6qCFqgpqhtqgl6oA6oRtQD9QH DUB3o7loAVqMlhPWrkGPo41oC3qW2GYIkUIvoT1oPzqIDqN30FH0AfoYfY6+RqfQ9+hHdB55gmpT WBExCheFj0JDDYnImbKR4okOYgKYK+aOeWP+WDAWjkVjcdhmLAPbgWVje7F92H6sDKvCqrE67BjW gDVjrVg71k281sj/MOLodb4Q4E4YcCcCuBMFtboYoE8c0CcB6JME9EkB+qQBfTKAPllAnxygTx7Q pwDoUwT0KQH6lgP6lAF9OKCPCuijAfpUQH2rChhUAwyqAwY1AIOagEEtUN9qAxJ1AIm6gMQVgEQ9 QKI+IHElINEAkGgISDQCJK4CJBoDEk0AiasBiaaAxDWARDNA4lpAojmoby0Aj5aARyvAozXg0Qbw aAvqTDtQZ9oDNtcBNh0Am46gnlwPCP0FEOoECHUGhLoAQl0BoRsAoRsBoW6AUHdAqAcg1BMQ6gUI 9QaE+gBCfQGhfoBQf0BoACA0EBAaBAgNBoSGAEJDAaFhgNBwQGgE+HQ1G9HDcYMqoXqoCeqAeqDf oFHoKTQFfSJ6LF/7P5A8hBM9MV2E6OsQfY0ZYpqKzBLTTGSOmO6iJBNTYYo/BKNKlEBiqkwJJqbU n+TwHuTwAeTwEeTwCeSQAnIIADkEgRxCQA5ED44SSl8DRGGMKJwRRTCiSEYUxYiiGVHMt4jNnBFZ gIjovxHWGYcgwg6TxF6n0GmITFiC6DUSppiDmAnCO+jXJ0jFED+kCRlC5kRv2o0wXBTRl85kvHd3 oIf0R7BIPCRhkiyJRtIlmZCswSfjyJgs0S8sBJEcI5L/FsFXiagARP2M6Bojus6IBkCEgN49DzxI T8HnIRizhCeIOB+sM8RY+zdGdOOH7YbBdheIaRbcSUzzwDo3v1uHF75Izw/uIvqxBcT/W4ycbjOi O4zoLiO6x4hGGNEoIxpjROMgYoI4idIh+vUqhS58hdhbCbG/K2CvJXA3eK6th0iVEukeMLcUJlo3 xPQ+I68HIKI/+/jl877l8CFizRq4HmKFj8JHoUXwcfgExAk3wI0QF9wEn4F4vo7Ay0Mf1Qc8KweB O8j0Z+8qiAV1cB2RZyOxPgK3wW3gc8MwnAvuRtKfq6L305mIPFBwPUvi64hqQmAsNWEij3ZIBNxd 1Ad3F+n5m4GnpKQhVXCtgBOjEfUBUeKQ598iCi8oESpEaprow4+A9TiQRKL2IJZ9+Y88B1cN6D1L CPQRScSWY+B6CRf05Q4mGX5CHCn9Cj4JLgf7RYn3+Nt1FHCdAu4Fr6WPcd4f0j+VAqJHjOjxt4gS T1/7v31vvl2H+jpqmAD9iiIPmAsJpOMpAikUFvl00/QZdhITXJ4iEEnMCoVJJCqGs1BQBQ4EXoZC uDuFVYFCIpNSNGASudwOt8EVv5sjWCmcJAjpgl8ryAMMihoEBjP1hvTov7jYd5mRecy31CTyv/AV Dz/1YF31yOGePo21AeUpvKvxFDIXngJ/LEdgEgwvgs5DO3R1MxcP6L33fDm2EmdnHCl9lGI8jKqA y1GQdWSMW9woNCwugj7kpKisp5woVUtLQ5QxyCMYUHI5VRgX/LLykh+XfB1qkiqGi9CXI9x8fyy3 DQ2NEjWIjvILjfCPisOFl7JraeBUKo5r4MSP01J2Gk6lqVC/Jv+BI0ohiX//tpBQCEkhLYKI+axw CokE1cJt58Me60xZCsiW7ft1A/68sjZLauOH+Tzzqub5kkpRvQSbyv2V2W60wAFDr7jX9TFX7O9M vShOF8wuS/Vp6AqM95AYFtIdXUTa8zT/YruST1GRn3ThdW3FdrZT66XPmzxh1dPMV6yV1ap5uWar 4UTqotaioHXu9SkJFW5KsebPChu9dIqsBanMkjxltU9yFPgeryjw5HFbj3qXCWnYZsxUT+bClwSG 2tcZN2xLatd+aZ9refRzdXxwlOUxvr58FlkxyHG3m79G61ouJl2HBee5Az6szIcGkx0cJ5t0NvAm x5LvvD93NClv/vjVxOHqZREuuj1n3zBXieMNlLQrDaKx3GljMEIU/KrkGjz5IJ5cSbybQiRychGe vC+J0/l62KR/RKmEzRaekxa7FnorIv795y/lb8o4Qj+HeU+xjqzpfXxqr1pIkrdiF0+7uNHKSrFe PTQnM/uK9mOxqTeOexVPla++7DH56Wafjo5Trbq9/7xksP6VvsOjaMIINWtFGWdYQOs8lxWff8en 60YTi51ErZ57bDp2mP+ygoaU0jnvCq7tUos8q2bsBWfFrgwvmbatDzGiMX1OWfrhkW8Qu837tt9t u9ueXMQ/iVJZMoXy5JZZ3BCCD/6eNI40Or89MXLZ8bX3mm5b+6ZGRJZrYffwG+bsLS37uuo0FB/G P6yJnYgph64H6J8fVN8+bsBVoxYgEHBX7f5vguSHNcbky04qmiEWguwezayVO4du2OubXBVcdyjs Lpd2xt7osurBcsIKbngKYv7FCqzL6xbfs15wKent+OYUoX9KBgT3mjTihzAAjZABlUYk1b7JIA4Y lMiEwg2vs6Ny44vpCWZuVkf3SD//EN8oYjecOAd9JhM3k623V3BoiNe3A2P9qwOTwMW+HNiy75d7 eYva+fuG0Id4tTYy+FsrNMdtHnZtMNaqUa2n3pmVUlsT2zEnUtptHD45YPL0t52dgea2Hm8L4U6L W2uClCX1vNv7JZox0+bE6BHjtsPZHNZdUgpT5U/YJUQGDCQ/ehRe4zc+uNdMpPBqg7J4p5lSQujt JcI6O7U4tUba5N766CiRaAvzMqaHTgWRMornzpz0TEyZdSlPTk3bdXyqJbfqmuYh67SlMhmWI/h7 aMXbS7Mrks+lvwrSql6u+r5x+THWzR45v/oUF0Sypx+bujgtetqKK8uzV/E2zZj/datZvo61HV+/ j03c4SMZlx30ylKsM0PQE2rnN0m22fqsKLTsU9iiEpK6mjJQet0sHQ5Jhw50ZIzZfbXCRzx5Buem S0GKzIazUpiJCg1FmRDkP0MVi+jHyE0iLZBRHCH+4UL0GRxkXjJPn1B/DBTmfOz3Oxcti2xWLa9a 5fkGx+iLF5HJBEbp36EDHLOp7ugWM+mp/rOWUZXrZaLkoxvSP9eZ5/4KWTzrecF3z7+LozJhGja6 1JPR98Gu70JZm0PoG89Vtaug1/mXi24ItmBl/Oy5N+8IH5HbPPnqUGR99qjWrhUFAWc1gwczj0l8 Hns27M+Sk9k2fx9qVZ2eSZjl5FqOvpDL32sYKBverJk9zsR+xdXvaluSQaBPTWtz6y7VnimEMyH+ 3eC44dim+fv36+ffj91gbwgb3jNh1aRZmaD024q7qpiHBlyWHCCx7b2LZ/Zxp1atm24716UuU3mn U1Cewla5cUeDYnPFwd66O6JN7Th/migPu/xZ27cG4xvwiT2y/hnnwx5MV9f1JxlGxHAQjoknHOPx 1THuFJlk0EJi/p4jlPDMP0g1XTiahGloNCpNVU2NLhycaH4QSRV6Ek/e+v9ybOyg4BBFl2xhZW37 bXXkL1b/W/e0RTRueyJYltYd1eLmgqivKP5cGF8kZyJ+vDrD7tVrE+1uZxRzrGnuQfuGzGNXh6U1 POod831S9TlKZq9v2c3tyCr80syVM1e0hZgdVlktZWafbeT3OywpOIc6pj3rsmQS06h+0a+o3GR4 VQytHn48JOvYLRDfL6fOdLV0XV/r7+IvaiQOsMtdmLve6aTnuaJbcQ22KS7tTeZkeJuR00RVA/v0 ujmp8QeiQ0+KNuQeVFGSTXQUWBfARls16RMU+kazeBI+UlQxUsDEyaHL5/8gztKEZ/z0zuvRwcX1 ULGS4TubFqe3vxpvfbY8QaHV9Sq/u+yRXCPWrgDDhVO0owfkxEd5nw59dc8HPPndz93zB8USA5Hy 5m1zj8Q+hgsXLhlYOnvx0HZw+oQW0aknQGZKAt4QkiDz4bxJP8d+FX0FEfIKXAfXKtcoV0tX8YuK CtNWVvaMCFoe/O0cLvcMDVYOC/Snz1X+Omx5pLKRHVHwlhOzcNNvR0i0S3RxbVzzWxqH0xW/Zhgb G/uzDL0jvssp6k9AAfsYyV3zbAuaiAzuLLwZzJapc8k0Ml6qX/GBxqYS1bI2if5zY7dc4hYHctuI kjxPR8wwT1zabCPPK/vbwJP98tf42Ae5w3PkXjq0zQ53sSsf81YKtjCWc4hItdIfDBAy8KiNc9n1 pjt2ey8su7yku1jh0Wl5lpGX+x48is/awJlpVzHiZhVbEO5W46yVM1THJYI+6zSuHbpgc/pYy71P lFTobVTV3YU+oXIJlOmhjNqFfbv5D6e4yTydS1UQHiD37rqWwn6zxsJoZfTg6Ejs5HaXwEUZXtmN Z5rP1PnaixkfNvN7Yr9hB4+L768vd7sgnDnMJZKi+56OQYvDamdPRoQ1H31woYwXJuxTQtgn7Yt9 OAOwQqsOSKpu8V1jkfXxvpV/dtA/09ZRx7Wo6jgVV1XVoKtHi0j+A20de/9g78go9+Cw/2lb555G yNyxy4Zm4XyX+0317Do+1vGcUaS1clnZXt76Sk/l9hrqHtmmHK9xEevUMxfWDiSiHyajz+3orrlx 1D/M51cZn6dNzZNpp6++PvyZ6wD2i7ic8rWVtx3IAjGngr2Czezvjvw+2l62tTtpLNEc1sh911HK 7CDst/rq7Y4YF+XNTVLkRgfnAEHPhaQE3dc3yFIWWrFRTK4XXG6layhGX+F4LqzFkhAzXxIUEj/+ Ui97X2k4x0Z5Kz4PN1rp4FZLBXEXP+Mdo8qpnNYnZ08tywp6LbWf+0Mv5800jrcpMZHql/LiK/vc KC/R4+kqzR9ynVMNUten5YYcF1E07QstNhoPeJoovSvwi29SSLLEOyL5M+Mw/2e0djgpLF+vNywh 0Zsw0HeiDH1qqb/vtGrd2vTss8XP63UMjC5dx/kZG/DAZDZhVsgOioY8ICPI4MeW0L80o34iqFyL xdQLCdati3dVuDOROHaGGWdNRtq36bOgSgstNnZpgq+0cpqrHLDRnU06AgNz9dVXmk/YiAmEMvtv CUQqxU1eBTUGJ4i3mAylTmctOse0Xf38iy3PwlyNy/YM9vWP7Oq43y5/NeHllaO0Gxmnez0vqg/w ibXHjOoUNQhElopl3mps5LLf+bb4grdZkax0sdv2RTrd3N6/mrZeO7JV2+q4x/pR/NkzLaGJbVN3 tJJnucV2eiV5Usj5U0WwkfImk8wzC/Bt71mz0TtI1N4GNIStr+SerHuC6e9LixeLacKCGfWUrnxa y6OVl+xWtNVuG33qo5H1Vjy/uO94rL2N9nDEqpMS7wlBHSYEtYfRPMpVAs0jln+uefQvIgDNI1yD pkaoiUYFjlL5kqTSk3hyw7+jeSSDS31JCocY+YfRvxFjlZ2xqLGdpbaGgSZNSV1T00BJy0SLRpXC Jb68JsEfX5OSHf1Fidp5R9C/QeNv9ZaXzCpqyGcTfzvv1f7P9zIG5jiyuZ8f1pDlipm3sK6L2Se/ d/V4rYM//Ch3i0Xa3cTwyWjobqtR0FxoffgbhYGEPf25S0squs7MzmwZcb+vhAsXSyvF6D82yd91 9NY2jVt9k9PXnDs/+Y1PeWXvf9rJNVt1LvXT8I5+dEUbKcZaBvmQ2sybnuV2zlVOUffawc8FTmpC VrwdmreE3fVXqDc48CyJzdPh/Agd3/vAVaNOptVT0ZQned1E0PNahbysTI4tVdDBWEmmAvkwpEVe cnfRaFel+Np2818osfYRRsf1vEb2pjKvb5p/lrGGRb2h4YNK7RbzyrhE2i9yHKWn3o3rluq/NNH5 vjn1hxBk8zLbYZ0Xd3LPbDZZ9LH37ZaShYEfWko/Ncb/pqUUFRnm6f5/0lL6llPUz2X9Q/uP0vEz W0Gv6z89GMz06ZGbcDp9FUrZstSlS/IXrtaamcCbGfNZvadiRATE38/c72k8bUBapnHEVCM/7GOf SrXszhasKYpbtrkh+r48y4MdVmMF+vuaVbmSn3OOCN0743XN0lrHfPtn/hGpozfyM56vvfjozazB UlfSC8fMzTHxj0LnM0Tr9xbvLGrfuKx8CS45XrnFPUdITq5zzW5to63bXo/e2Dpipaim88TAgHQY YsOmhtcI9BtmbTo+rZTlKnf/XFZizpKYRrc5HpnDoVyehrLrtbfr7Fj5sLmrb4+joIlDYHbvHgsH FOr5gK80thzjz2x7x/lmZNmYrHCjzVTsuPREK0sy1z1h7evG1BTyEcJYtTCJhCdn/INdth86kn9c AC9PvoXzMGonWRKVCUHBLQ96nfX1ZLIgVLbvr7kTR/NHCqNy4N8vXUK4hLEhmUoA4BduP2U16lpE EeTR49stm1nCdSQX9/huEzaqPW5bLpsk/Zff8vbD96ZVSCdJ/mXZjYoLC/WNcA/zixP9k6vIKSRI b4rpcqI+Qjs5YSM10/nc/mPPXrvd9rNaLSUk1o/tmr+U8cslxk7vuaVXZhbPcfqx3KVnNtEy6a+M JaK2x7FIiCcNprR25XJlF52VXO13tJvzg+/7vSfVL7RsSYp+dMyGlZf8eMikpXQh3mTXqqc1HfYf eR3zAlulYnZZ5C3PhYqlNwzLBK9RWX0wN5LV7NaTgvloKzaB+BnZ22new0bvqZtdnIbezZDFJVnn V4Ydukh73kMxzah5yV2nG/Zhc9XNYLdwkTkp/QvB1TY8O4L1j8lvkm5qtMnTNp6UM53Jf3DBBrry uSwlNcyqIWtaZv3qjp2n+d4a6BtUfh624PUzu79qgd35yHRFCiyCp8ACf5whCjUFZiNmMf/bC+if K80fqnKmrwW03BXn+74cYn/cICIR+2QsQamLiCpXi34HhPhTV1Vz+pdiuL7QzrclfF/WuntBMi2x GtXma15e/JOx6EXEp4IpLX5/94m32VRli6htpS+8rM6c3C8UsOdTaE+/f//A2B33eVNH3zkxj44x 8WVc5I02O8yitHgvkS86SGpa6vtocecanOoYVMzIvyeVN2QaUlQ2G3rw+CXT7QrFkrMwrZN9ht/E 6YX5u93exxqcuffKemdNbH7JZHgmQz2q824TNKm1LXL6oWTsXJNsjPGjLPj2GxX2uL6wX3mvzTfa vppgcV0WI3WmNo6f46ZFM40/Lg92tRj7bLUpJCV0J0sJk5BIwgTn+dtcMaHJIk54lo3lxd7MTUva F46Qcs59YnV+FGdgxIaY9PdGTj5es757s0eelB+/xHn/1Yl+Ju/8g8N/r7t4CIL+C9B4e0ENCmVu ZHN0cmVhbQ0KZW5kb2JqDQoxMjIyIDAgb2JqDQpbIDI5MyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA2MzcgNjM3IDYzNyA2MzcgNjM3IDYzNyA2MzcgNjM3IDYzNyA2MzcgMzYzIDAgMCAw IDAgMCAwIDY4NSAwIDY2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NzUg MCAwIDAgMCA0NTQgMCA0NTQgMCAwIDAgMCAwIDAgMCA1OTQgMCAwIDAgMCAwIDAgMCA5NTQgNjQw IDYxNyAwIDAgMCAwIDQxNl0gDQplbmRvYmoNCjEyMjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggNDIwODQvTGVuZ3RoMSAxOTc5NDQ+Pg0Kc3RyZWFtDQp4nOydeXxU9dX/z/fe O/u+ZJvJ5M5ksm8TspIQyEAyIexIAiZAJIEAEUSCAUXUB+oCGnBptWq1KtrW56m1OCQtJq602Fp8 6oJ1qbutVauC4IYKZuY5986dCeOj9vfq7/fPD8978v3cc8/3rt/t3pOZuQMMAFJQBJjf3DZj+uWh tx8F7shDAGkXT28OtXw5Gw4D55sNwM+ePn9eG3eG5T3gcm4GuHdketvCaVMK/ukH7tB8gMw1s9vb WtfPX/tzAA/mmxbPawtUvLLuLAcA+yvupXtR85yOzZ9vPReg6FMA1Zsr1vX08/3ClcCeuhzzd604 f6P3wQt+VgTs1W14QNpV/avX/f7Jd2cAe9oKoL50dc9AP6SBDo+nAZe3rj7nwlW1+3Y5gL15JZ6E sa933eZzahuOA5Q/B+y2cN/Knt7XH9quwf0vxeVr+tBhWa/G/bMbcD6nb93GzYOpBh8ANxHAfdY5 61f0tP1y7uPAPsN81551PZv77QWaAVx+BJf3ntuzbuU9L/zsT8BZm3H3L/SvH9gYHYCDeDyZUn7/ eSv79x1Nbwf2PK6vfh+kslU5L7IePqt3maXhM3BrQWLPs29ulqYHZ4ZmnlgbaTGBdjsui+cFMXA9 LYt0Yhn2nVh7os0ke5LolDymRTAdeHmeAysEYSGW2tm4XwleMHIPgQq0qltUlbiB3NiU3w0Hub1a 4AxagVcJAif8Dcqi+6F7Ca5TKK04p83rBem1W52FxzBJy9h/ehmLegtw6ytUh6QzxcpRDonrUNIj cDP/PmyFfwNVOszFdADTTZhWYyrFtBnTckybMDViaub+CQe+dRtboifk6ZnQ9H+yT00u3PIvj2tV 9NjXffxdcLcy3fGt6+mgRtgPVd+5/zthu0qE7cKx8eX4zbBdnrZByr86NoIgCIIgCIIgCIIgCIIg CIIgCOL/N0yLGMvKMhuTnIYEit+MrzgJS373SI8vGaZMwcLsuIVTViAIgiAIgiAIgjj9YdKLMTDC F9ooaEEXjYBOVgybUA1gQDWCMToGJjChmsGCagErqhVsqDawo9rBEf0KHJCC6oRU1BRZUyEdNQ0y oichXdYMcKG6wI3qhizUTNQT4AERNQu8qCL4UL2QjeoDf/RLyIYcVD/kouZAHmouFKDmQWH0C8iX tQCKUAuhBLUIylCLUT+HEgiglkI5ahlMQA1ABWo5VEaPwwSoQq2AatRKqEWtgomo1VAX/QxqZK2F etSJ0IBaJ2s9TIl+CpOgEbUBgqiTYSrqFJiG2ghN0U8gCM2oUyGEOg2mozZBK2oz6scQghmoLTAL dTrMRm2VdQbMjX4EM2Ee6iw4A3W2rHNgAepcaIseg3myzoeFqGfAmagLoCN6FNpkbYdO1IWwBHUR LEU9E/VD6ICzUDthGepi6EZdAj2oS2F59DB0wQrUs6AXdRmsRO2G1ag90Bf9AJbLugLWoPbCWtSV sq6Cc6Lvw2pYh9oH/ahny7oGNqCuhfOi78E5MIC6DjaingubUNfDBaj9qP+EDbAZ9TzYgjoAF6Fu lHUTXBx9F86HS1AvgG2om2W9EH6AugUujb4DF8FlqBfD5aiXwBWo/wE7ULeivg3b4CrUH8Ag6qWw E/UyWS+HXdF/wBVwDep2uBZ1B1yHeiX8EPUq+FH0LRiE61F3wg2ou+DHqFfDjajXwE3Rv8O18BPU 6+AW1B/K+iO4FfV6uC36N7gBbkf9MdyBeiPsRr0J7kS9GX4WfRN+Iust8HPUW+EXqD+V9Tb4r+gb cDv8EvUOuAd1t6x3wq9Q74JfR1+Hn8Ee1J/L+gsIo94Ne1H/E4air8F/wTDqL+E3qPfAb1F/Jeu9 MBJ9FX4No6h74AHU+2QNw0Ooe+Hh6CswJOswPIL6G9iP+lv4Peo+1JfhfjiAOgKPoY7CH1AfgD+i PgiPR1+Ch+Ag6sOyPgJPoD4Kf0bdD09G/wq/k/X38BTqAXgG9TF4FvUPqC/CH+EvqI/Dc6h/gudR D8ILqE/Ai9EX4L/hJdQ/y/okvIL6FLyK+jS8Fn0enpH1ELyO+iy8ifoX+Bvqc/D36HPwPLyF+gL8 A/VFeBv1r/AO6kvwbvQv8DK8h/qKrK/CB6ivwWHU11GfhTfgCOqb8CHq3+AY6t/hI9S34OPoIfgH fIL6NnyG+o6s78Jx1H/C59Fn4D34AvV9OIH6AZxEPQxfoR5BfRo+hDHUoxBFPcYA9SPGUD9mXPQp +ITxqJ8yAfUzpkI9ztSonzNN9En4QtYvmR71BDOgnkT9M3zFjKhjzIwaYRbUqKyA4yiYOnQ6HfA8 LySN/JoEsU/O4+CvSWTqEktJosKXjFodz5csFSRvkSAIgiAIgiAI4rRFr9dTXEUQBEEQBEEQBPF/ gcFgkOIqdZLzO+MqfWIpSRJxlSa+hEGyEm6CIAiCIAiCIIjTHaPRCIKgSo6rtAmUd510oE1kGhJL SZIIoLSJuEqrldzJWyQIgiAIgiAIgjhtMZlM3xVXKUGT/pviKvkDgep4AKWNLyHHVWqKqwiCIAiC IAiC+L5gNpuluEqT5NQlSMRViU//QeIhsbIrEUDp4nGVSaejuIogCIIgCIIgiO8RFovlf8dV+gTf EFeZEktJool/80oXf56FHFdpKK4iCIIgCIIgCOL7gtVqBZXqW+MqJToyjn/6b/wnCGVXIq7SJ36p ULI0kLxFgiAIgiAIgiCI0xabzYZxlVqb5Bz/BfhviKssiaUk0ca/eWWIx1VWg4HiKoIgCIIgCIIg vkfY7XYprtIlOcfjKiU6Mo5/qwqscUN2jcdV8cjLZjQkP5idIAiCIAiCIAjitMbhcIBarUmOq4wJ lOjINP6tKrDFDdmli/9OsDEeV9mNxlPCLYIgCIIgCIIgiNMdp9MpxVX6JKcpgRJXmU+Jq+xxQ/6i VSKuMsXf0XJIlo7iKoIgCIIgCIIgvi+kpKR8V1ylREfm8adVgCNuyK7EkwITcZXTZDol3CIIgiAI giAIgjjdSU1NxbhKa0hymhMocZVl/GkV4IwbsisRV5nj72ilmM2Sm+IqgiAIgiAIgiC+J6SlpYFG 87W4ypJAiausp8RVKXHDKsl4XBV/RyvVYk7+wSuCIAiCIAiCIIjTmvT0dCmuMiY5x+Mq5V0n6/hT AL8WVxniT2C3xOOqNIuF4iqCIAiCIAiCIL5HuN1u0Gp1piSnLYESHdnHn1YB6XFDdiWewG6zKm6X zZb8g1cEQRAEQRAEQRCnNR6PB3Q6vTnJaU+gREfO8adVgCtuyF+0SjyB3R5//nqmwy65k98BIwiC IAiCIAiCOG3xer0YVxmsSU5nAiU6Sh3/9B944kaqJIknWjjjkZfodCY/mJ0gCIIgCIIgCOK0xufz gV7/tbgqJYESV6XFgiiZb4mrUuLPCRRTnMkPZicIgiAIgiAIgjityc3NBYPBZE9ypidQ3nXKwFcc X9yQXTZQPv+XFo+8/OlpyQ8QJAiCIAiCIAiCOK0pKioCo9GckuR0J1CiIw9kJjLz4obscsS/eeWK R14Fbpf0TAsbEARBEARBEARBfC8oKysDk8maluT0JFCiIxFfcQrjhuxKiX/zyuNW3CWezOQHXRAE QRAEQRAEQZzWVFRUgMViS09yehMonw/MHv/0H5TGjWxJ0kAJycQsxV3uFZMfdEEQBEEQBEEQBHFa U1NTA1arw5XkzE6gPIwiF3ISmeVxQ3YlvnmV7VXcVX5f8oMuCIIgCIIgCIIgTmvq6+vBZnNmJjlz EyjvOhVAfiKzKm7ILlf896xysxV3bW6OFG4lvwNGEARBEARBEARx2tLU1AROZ5ovyVmcQImOysY/ /QcNcUN2ZYHy+b+iAsUdLC5MftAFQRAEQRAEQRDEac2sWbMgNdWVm+QsT6A8jKISKhKZTXGjUpJs UN6nCsQjr9byMulh7OMPuiAIgiAIgiAIgjitaWtrg/T0zMIkZ3UC5c2oOqhNZM6MGxMlyYs/d71q guKeV10pffcqGwiCIAiCIAiCIL4XLF26FNxub2mSc1IC5fOBjTA5kbkgbkyRpAhfMvXxyKtjUp30 hazEz1wRBEEQBEEQBEGc3vT29oLHkz0hyRlMoDwGsHn803/QGTdkV2n8m1eNkxT3siAGXMXxcIsg CIIgCIIgCOJ7AAMeE4ARBNiG00ywoscI2VAPUzF6mgOLYAl0wUpYD+fBRtgdjeJSXihPyu2FdfHc 6Fvf8loh7+dbCQbbW+sbJtXXTaytqa6qrJhQHigrLSkuKizIz8vN8Wf7vGKWJ9PtykhPS01xOuw2 q8VsMhr0Oq1GrRJ4jkEJC6c3dezN0BS7fT5fZ6ky70qeD/O51o99YbAnLeT+2kqZX5v3fG0+KzE/ NwzOcIu/qVna8F5oeScMjjBzhkHaC3PMwT0pK4V61/hDZ4czmnq7u3GNZr/VG245FlAORd72XoO+ yd+0Ul9aAnv1BjQNaOGy/XtZyxQmG1xLqH4vB1pTaUnYXhzmckNSWhMO7uxGw9+MW8Icx3jOSHT/ rlOzAFeLW46YxcLqprBG3q/37HCwJww7vXtL9g/uGrHC8u5iY6+/t2cpllwPHuNe4HNDfe1SOYak 1N3nDQu4cVnc6PGG+ryDfqk4Qn3dqP5mXOsb/ejWNXXs8O13h+04DYVtxeHpuMT0Lf9w84Oh9LO9 0uzg4A5vePcZHafm+iTt7OxMxwMeDPlxg7ix0JppeCrpgdKS2DkpBdDbvUba55oe6ThDa7yDO1fK x7pLPgZ50VAfVkzPv1pqcDDU6w/19vROi229KRxslyfQvrhDPkEsuuZOxaUsgDmCnNPd3OmLFfas BR1N0oH5e5rdsWpPeLoVDzpC8UyvdAQzcANh7wpvGBZ0+HHRiZKsnAiDKybKjcfXyXCt+eNrhVW5 Vr938DMIs27/kcPJnh7Fo861fgaS2eJv6R4cbPF7Wwa7B3tGotuW+71W/+DeWbMG+0PduNf5HbjW SPSBne5wy67OsLW7j9Vj2UstoGVBR6PbZ+uMz86PzwI2KWxYBvl0sBTwb4YywVKG9g6fFwtqYUen G8upQ7Lb0Y5NpYaEDXci1rFSbFIZrZyYKJ4mxfT5pNa5cyQIy3EmvO2Mjti8F5a7hyAYKMb66JZy 9sdzUhZKOdviOYnVu/24l9/Ig1RKWJuX+LNYUx2hvvowS/2O7JWx/LCjqYN3c50xi3PzkqUvxp7e EE4rRrugeBAr4Rl/2FocVnXsdzd0eq02HAGk2mvzzzpjcYc3NJhoBTGPcqZSO8Cm7u/pG1S6ktTo v9k7qy1e4FKLxS69E0t82/I12Gjwr2eXNPz4Bq3hluM+t2/Q5rd76wKdsVZtfcZ/kOHAhcOaNcwa 5NNi8piGe5oR5tMmYua/vYfkU8JxbNpeP7vyjL1BdmXb4o5RK15armzvGOIY19Q9rXNvDuZ1jHrx 6iB7uYRXmvNKczBL6j1DnFbOco8GAbbJuYLskOdXjDCQfdq4j8GKES7ms8o+pBRgb/uyqWl4JcFK ZmOoVtQgpusw8dDIPoNlcjoOz2ASovtZ8ZDRVDOKRslQbqFiOH0xY1hnrQmOsIIhl0t2FAybTJIj d7ilRZ4OiV45I3fInakYKamKYbEpht4oG9lD+fmKkZUVM4b1emkz2cNGozT1DadlSFN+KC1NXoAf ypB2/HuWMpQlKobeKRuOIVx3NPo7ljrUtlAx5s5TjFBIMZqaFKOwMGYM5+RJe0gdysiQ95A6lJqq GDabYuhi5ZExNGFCzBguKZFWyhgSfUqOJ0sxlAO1D+NmcBH7UHpsu/ahuXMVIzRdMXLzFEPZkz1e 8uKQwaAYprhHWUYccjgUQzlQUS5Gls/YUIWIu1QP2e1yBjdUEKs/NpxfKB0MN4xHh1MWP8qcofR0 xbBYax5mZqYCG4hYLqphk1zTwjDuV5oO6fTykkK8oIShhsmKMXNmzBg+s1NaNjCkM8iFqx3SuWRD NxRsUgx5JckoK1eM/CLFyM5RDFd8LWeKbDiHcnIUIy8/ZgwbHTWWqWZWiU24EptvJTZmkdmAMSuz QBXaliFhvigdFgRFQ3pN9D1RfP8Dl1j+AXvP6RKPHraKH2KC48HjHF4cgunHDcaa48wlHjlsEK3H rj3GBQ/3H370MI9D9vAJq7MGp8H6L+3OmnffcYnvVLvE4Mt4wI1/ZYdebBRfeNElbnuePY+T7hf7 X+SeOFgkPnGwbuITzPCn5j9x4VcZrr7vVew9/c9KZvCKZ/WOmpxd7bs27rp81893hXc9tksTPMBq R23i2Zh+h+lRTI9gehjTQ5geXGQTHxh1i79Fe9+oS7wf0wimUTyWhkabOBnTFEzNmJowTWtMEadi CqLdWG0TKyqdYmW1U6yucopVON1dLR+Jr9qANb2hvr7mjQ0suEHnqLm2P9zPvbGeBdfj2T5zrrxU 6rnSsa+6blV4FR9crbPU3LGShXvlrEm90qCwm3l/HP4x1/gjtuzarddy3qv3X8151wbXctDH5L/5 fd19/NYeVr4kuGTrkm1LhIk/tYnS+p/81Ijr/4EFh9lerJmwM0W8z2kT92D6NaZ7nQbxV06zeA+m 4iKb2F/ESkrNYqnTJN7ubRJFZ5aIF13R62wQf+PKEe9wrRTdrgpxq+taF+dyZouPO1rFFGdAdDi9 Yrk9aJ9vv84u9Nu32Z+x83ZnumjDBE4239nt7Hfy5WYGamZh+BdgjWw928ruY4+yp9lRFmV6C2Dj CkAjBg5b4T54FJ6GoxAFvV5XK1o4C889zT3NR7koL0genbZIFFRFIsfniUZTnUqo47k6BnXzVWwE txa2z4JZ7dPCDobTtml7dRXFs8K9C6ZdcfXVnvCN0v3FNk/niBaXwRuVMLumM6yVrlCymXgS38BG /BvYGOZDYXWoryes9jcPSDNmacYszZhDYYs0Y/E3s7Az1Bd2ondjcfHGTdL6mxJP9BsYtwakNIDb lZHmB3DBTZLAKcv9bwYGGOYPgLyFYlmY5JcdxfGE+/6ujfwbSMdaDKDOUjtVx1SHhO3CCv5+jPog +vfoa5HNkd5IJ3+r9ER3toh1szXsfHZpIlg8i62WjZ+zHraWXZAUwM2G32IlvwxvwUcJX5QJOMZI P8b1NnPAJfLaf4HX4Q34FE4yFbMxF/P/yxj1FtijWC+wEU4jW3rYxd0Bj7MI5t6CkWgTHs373MX8 FbyUvx0uwXGt6lu3+B3wJu5atpS7AHazO7kmroN7jbvn1Hymhdl47uexH/3vdVkqE7Er1LMWtoAt Z4PsKFfJpsJ78AmMYUk4mAgPwKvwDzjMOKZlTjaTXcXN4U6yCFujHlTZhI+TtnY2a8UzWcoGWB/r g+Not8mlcQPquRiju+LPMcH9FsPvsK4mMCO/nBviZ/Nb+I9Ven4IQHUIXGor9ym3CjvhVrgeX52A 0QJ0w2XwA3gSy/8Y+woK5XK8DZdYi683hBXChfzjbAhWYYS/Cqd/gcXsOlgBV+H5zWEZ3H+DE4a5 t+FOeIkt5afC9fyFDO8rcChYj8dzA671KgzDtcKhf6cOiP+XCC9rMjWH4ddwJaZ72P3CPtXz8AHc DS/BOvgDcFJIowE1Nn2ceIIWNScApnIIwnz0BbqefO1JCKBMKPfZfLZcFBz34cQ2FZyUpoAGcHAz Sh62NmkrgaCH43hevV+l9eoadfN0PLqFvTyorCqvilcFuirHKgKBLmg80lgXmFDOeB/PcLtcXmHk sUK2K3I+G1QdOvmqkHMigB0Ot76Vf5xfo3bKW28KFnBqNWiYVRfQ9eO28RytYBUE2BPgG/ll/Hp+ K6/ieWGPRroh0dlqNYHiI5WBriNduMfKykCltEe//OLXNDzVsAyT2jk2zM2REu5tbvRvwhOqo5AG fmgNZrhH6+0z7RfiNZDzjVarQ+rz1bxa7/eBdEk260y1ALmWXDGXy/IZpT2a7LVG3GOXrRIVGruO 4B/u0slp1Gp/dl5+HlddZa+tqamsSE1Ltausef5stc2aWllRIzwxpbn55dtveznUPGXy9JZXb77z xVDz5MhVS85Zu3Tp2rVLufd+F3m9p2fFihXLmbj/jyx95Yqelb3LI28+yJxvvBF5P3LsrbcwcDmA JXIr1rIFWoLFqn1qtZE38yNMexTzVDhGeSHAeDCavczLz+c5i020YXXZrDZ7XaCrq/JIXUVXoFKq nrGKxsoAHrtPqnlfdUUNHnUtWsKtXxWw+sgfQ1cWllcLON5VMoF3fIL3CGc0nAzgXm7CI3hN9SF4 4Zpgqt9U755hnumer2k3L0pf4jlb2OLWO0ei72GIVGsZid4VzDNba8FudlvtHnfAvdp9gVtjtxse SOUCGAqKo0zbLfaLnHwLlGaw1tr78ci9Wp9o5zIysi3ZYjbHyVVtreUCxVK52+vqpBrHGWxjdV2N 0syE8uLiLp+vukY6i+oqqdSxQjR+W01OpVdIccpzPuG1kw/sfK193fKL19etrKpstXsamfFipmO2 i69bfE8ed8En5z7WMbBnad/6zNS0ciMLZTUefuHysR927vTgea/GljOiOoZXpPuC7hJTTnHe5IqG poaOSQumrpy4YtrARH1JFZ4rNpMXhnFagYUQnIctSJuGxz5lsnukO5NlZlap55Wz8vLCB6q4oJ7p 9ZYH1PpAEJc3tKD4fQvrWb07UO70lbsn1ws6wMs3BxCyhMQQZ9BJJaG31uoCxZVSUXTZ0+qOYHVi +8e7C7kkZJEre6yuTioWLBgmn7/UPG2VqVJbjBVSfl6e329Lmj2l2KQGnCqVXEqqZAkjZ8yd9/xP 9nw5N2fBa0tqthZnF9aXl2+vDE5qPq+goLRIzOnOrj2vpmhpqjiHqa684kBo9uzrN1evLC+dxA6s +01jY1N9Dmuqmu3wZsxomjbdahOY2mh3NNeX1lntRpfTWmlijb7JZSWBHy7Z+mimWZtXnH8Rnnpp 9CvhQxx79GCC84M1RpOpVq1x4kEa1RqdaZQ1CvOEZcJWAeE1PB/QNGqWaNZqLtKoQGM08WrBCzr5 /tyuM9bi/azFgreoJnXQllqrVkqxuLLyiC0NSwwCjVLB4QBmq6vboSorFi6xPoa92y/1EBuOYpWo wocHIzeNbeAuY5sOjj0V2cGWRO5ky1gq3/3VjexkRIUtZTO2lAfxmMvgwuAcvbbEUiFUOJuFZmeX eWGp1tSOFa3NwEbh83lGCwvVuaPZvNwWbNgW/LlidtBgrs1O8/mz5er34sgI5ZZysZzTKT1BF+sJ XVJXwHEoEK96PHocfOXOoNR5XqzO075W7dlSJeNJpSgjVarw4Lx5c1+87e6jc7MzW+qq1zXVby/M yi72V15XteDWOi//8tiOrLa0tftaFp7Fvtj4x9bpc1ltNgtZC1JT3J68rJlTqmalZTtcFr458u4X HF9cWjsqje3LsSSeUx2R33O4KNhgNJozPEYxo8gQMJZkLDacpzmvSu/iS0bAY/VwHg9vcTjSRjst zMJNvL+Gb+E5Xr8ImN2eFxuQLToLDsgNlgaxgXNV+OTiMNil4hiriA3J8tAmjcpYDnIvwDKZUI6l Ab7x0Vlu3DZ/rBziJcBOLRynOsWpFJrwXOSFyFeX/nn6wsXty5awvIMzrne7XZvn3PdI6oybls2/ unbOkshcj5jj87UH8ttyuNJsV1NuVgs7+UHk0KwZi5j14cdY+ab1lzjUkVdMvpF7AxOLCyftj1yV s3BR61mZmSlOi77Mv+2nBd7MLOk9m004uj6EbUcNvcFsHgP52zneiVdc4PhRFc9peQa9wLgOaTzE q/lI9NiwdJWSSseoM2DpaC1aUcsJSksRYi2luBjLolhqL9DYOGbDIpGa945LHmPMJ12dhYfGtke6 uZ+M1QvThV+ePFMYkW7teWiMvi68pPoEcvGOuwV2B1eqAimBAnNg4gTv5Npp3jm17cIyc2ftsoaL bJs85vKyqopgWXNFZ0Z72bLaRVO7y9bUbizbWrtlkmlSrSm7okytLrx/dQbeY069X61fnL0Kzjae 7VglqvK8YonXYXGI2YKx2qtce/GyAa2WVrGVm+KVr73WU6+9OPIFjgSOyPcZXdJcl1zN8YEuL6+6 qqa2OjaJV7EymjH5+hCr4LSaGodc6/lqyRPrJMJL82bPfuXqG//eOr356u2X9bW2Nh+6dPDJac2t F229YVekv3fRgpWTg5lzgvk54pRVnnVF+ZMvP8czy+PNZ3d0/6KhoTk0adLuzm331KmD+/oXXFdX M3VS+YSdZ6z5Vb264QBXMHvJgoaGGaI5K71y2dglM+ZOMBfZ8wdCfRc7nGlTpF7THH0L7+SOQgHe p20Itlh5K94/eXmvbRE3wGmc/kkjljQxjUtLUwfur/PP8HN+Tq83jy5UM7W+08N0zkKfzqNcOaZZ ponTuGqfRypBi73Wo5QgtgXsIlJnwYlUgqf0FbyZEZKvFrWnlmri7uaUa0aiu9RW1Qj7Orq6I289 3XJzhidz9ZIZV06obDbOv2rVnKvr5yyeN6P12R9c+kRr+5mRawpzXVPzfI0eV06u17ugoqjTzfMN j0Qe2zBwkV3Dcs3e/KKSy1dUVBcWNzx848Y/zGhdMGPWwsin2y+8rcSb6fZ5+ptauzLdqWlGQyGe Kt4ZcbnCCvk+siCYwQ5wKvUBldaq8+owsgyrAeNVL+OZPMDL7Ua6c5PvfrB4cyO3s+VS4l5mV528 jV0FXPQExljbsC9q8Opzc3Dio7qnddyjOpbHCrlWmM53qhapO/RbhE0anU6n16oEB45XOr1aY8eO vIVtwl7rlVrxSPTNYCoa6qpyHOV1esbzkC51Wq30X7VgCmbxvNFiFI2NxnnGrUaVxcjw3lxu59BY 3NBYJ9UNHisO6zusY/v375dVu591QVeXX+rB0k023pSzz9nN7PPI1q5ISRd74+abVYfwJrs88gw3 hX0QScHRpSn6lioF791K4a6gT9Dri5x6d9Hk9AmZc9KDmR2pZ2ZdKGw0XFxo8vfhNco2Er1cupPB +699QR0esDATRWpIwRI00oIoAZM3n5NlvYmZTM7qLdgIue58lp/vrd6Ee9SbCmJXX0ttQUHAEggG lgV4Vwq/qsz6aawrN0gDtnT5krWrK3bTgueq8oLNCj6568rD9Te0NmyalTa15OMzI3sxuNjJ5nVe M7Vyc26ee0FV1SXNZ+yYPHH6zIb6a6fP3F5WMTszu/CcupYtHvZjth7j+F847ZYqR+S29Cavt7Sy se73l+98uH5ixYQsMZgRucsxwZaSiudwC4B6J7YDI3w5CvronmADlopqs1Q0kqj0UrULLiEgNApB oVvoFzSCoDHoeKbR6vQGXsU5YaXZYg6a55t5FRbH/VjlKrum12Q9fqS4CwVvP6CxobFB6oU4luHZ 71VzTe0dv9UHYxWwX6oIlTLVSyVqwtLnpCpQSaL8J2xCuTs4y8JZVKDn53HzVJwk5+nv4+5T7dar F/BLhWWGbn69sEa/3tDPbxW26LcaDAa9zuDWZxhKDOX8ZKFOP9kQ5OcJ83Qz9CZsdF1SI9vQiWEC 8zOpq+AlQ70zsivyUTTyUWQ3u4/NZDPYffwrY5dxl3yVqzo05uPewA4QPYa953z5SnZbcDKouCIu F/sHXsIKWD7XxGZzAsd4Pah4F6TwxZDDT4IqfjY08UuhjT8HVvAXwwBvvQ7LP3Zxs8Yubsu0HB+Q Gw72kLo67MiN0nUtVl6joIruH9I5sDykokgRVE5VEKNSQaWWOmWsi+JJSR0Ik3Y/dHXKl0DGVOdH ILIlAuxy1syapZ6jOvSVhf8I9393ZDPvwghVAxOC6apHOKZ+hBksOsZbQISAdHumvpfJF1y8xYzd hFSeOsCkYOJdY7u4jZEHWSiyWfPTwycacLs7Ipu5k/HtCo9oGK9s997EhlWnbLdSjnMT262WwjYf d3JsF27zQdz25sOqxw5L148avOu6DLebijFuU7AUr76e2abZnn6Hyl9kxMFGkhRwT8V7cK1vmlbv TGMuWJ+b5Tb052BjtI6NVVRIu8G/eGCljl1YOVti/MeGYMtTLqTSbdJlkbuyz/QVLajb/+bspsl7 ejo2zGJnRe5ytWf9x9aVG8rO2pQZtDqdbArTX//X+TMW5uaz109mc/kmW/j2u/+Hve8Pi+q68z73 zmVmGAYFREKQICpRgorEUGssNdRYQowBS4BamxB+DkqY4TIzILrWEqvD/GaYuTNQSg1LXWtd1xpr fa3ra61lfbPWN7W+iY+1ruta17WuMa6hxLUG38859w4MaPr02fd53z/eh57ne87nnHvOud/z/XXO uRmplAGucx9eFfyCjaThtFGfP+fp2NzYr/DFwldiX8uw8Juna1Mo20/nxcSQ2cvVQn8yl6y4Ay3z n8ThJzk5Pp9EP/nkzBRd87yp87inY1JU4ty4YYR7BJvn5GMy1sMOypDhaIhBPn1W0qMxZZoccPh/ GDk58ndcHpfK8ZzwGRe1NHth20tfbn12/stPPD3/peXPb3pKVVVrsKjTuBzuSW4aV4jr+mdbizbM nDljRtK0BfEj/xz/1NSp8fyVJuvmDfSUZyNEkyFsI/NJdf4idbp63vT06fMEzbSVM2ZlEH1Ucprw ZFSydn4KqZr1REyKfsYTKclV7foD+rN6FT0K5cfB5fX6hQviFi5amL+wcqHArnzz3xj6bHHcR/HP D30Er3gBgeSzxdjQZ8WPbtTx43H4/D96QIqPGlRPnfrC85lF2SP9GqCl80vmjQxwFeU9b9b3PVP3 k9eLtsxftIh/9jVzRsasOekPrvHPllgAM2c8uCbUbHm5pLqqom7x4iXBts+eltcpDGCdSeT5/Aw+ cVpiru6rOnF6VFysduU0YUoUF6ulppdcmczFxaTEmp6QlTX8EY2GL8jnkVmP5Xm6MDDSHzM1YeXz 89cuZhz+oGbfYX7hyo70ubPS5yjc/PZ9wizrn4RjsKwY+MPT+dMT8qOFtHyVTj+DND/9wtNc8gw1 s3tqJGHvko2C5dxjjzk4JR4b+c3Iv498NPJr7lnoPBEb7XdnPTWzaPGi1elpGbNnpJY+l/X1lJnp /LPo9QvuBW46l8x9eeQXIzdqd2RmzXrqmXn2+vpvz52XkZExf5MsK1WbUE+mk5qf6qMRroRw3BNW JkTpoqK1LBDGR8cjED7BToB6TUq0KYnJTD4s4HA/n118wuFQHxEOf0amPLxyEH4Cy/8GN2ecRBWn VrU9lbg6+4ubnqcSTS6bM7duYXxWvCpZo0lP+ixOqPnrpBcTn5jF89SGpz+8qVoVtYvMIGvzp8dQ 39BqY4UXdJqo5OTEF0h0cgxll56AYmKeeuGp4qd4tS42RTNVPVOdjrMKUcWpfqzCjR2xkn4ylG/i 9LvUohdQfw7X2DeiZs/9QvycLzwXLwfRUeE/N12t5nPP/9Jm4yq4r438mJ865aWVqd9MSHu+PenA e3zsEPeVkZ8PjZi/tHbOnGeSdZ9OjScEupdTCXH8mfQHLovbzVfxf6/KV/1WSBd+hz3sncik1iL9 4NGkWf5I+sFo+jXSnyKTtlx7ZnyKzo/+TvR5mnTZSLbJNJkm02SaTJNpMk2myTSZJtNkmkyTaTJN psk0mSbTZJpMk2kyTabJ9P9PYj/uf4G/T/+Cg6AiPJmCJGOBpBLCcBTadSRLwQJJxhOK1WhXkxUK FkgiyWVYg3YtKVewQJJIIcNatOtJo4IFkkIqGI7Ge2pJm4I59LmkYMyjPadgFcnSHlAw5tQOKjiK JGsvKliN9rsK1hBrtFbBWnBvU3A0SY3ar2Cd5oPRd8WQgugtCo7le6JPMqyjMtGvVzBkol/HcAza E/TbFSyQdH0rw3rKs36XgsGnPsTwFLTH6QcVLJA0/WGG49g8uxRM55H7T6Oy1V9VMGSr/4DhRMbP sIIpPzcYno72xNgEBQtkdqzAcBLtH5urYPSPncvwk6z/GgXT/rIeZ1Bdx5oVDF3H1jL8FNN1uYKp rmWdzmT9nQqm/WUZ0t9Z6GMHFAxdx0oMZ1H5xB5TMOQTK+tiIZvnnILpPExW2gj5ayPkr41YlzZi XfqI/vqI/voIvejDeiklVWQ9aSJGlOmkiNSRemJGbkV9/DMraeFiiYn8YUK7Ab1rJ7QVsBms41tV dtV/Vw2qfo78XfIj9FpMcsizSOnkVbKB1OC9TcQCMmBkOnmR/aUUkeVVaNkAZCLZePIV+E8jSjPa 6jG/FaPSGdcWkJm0Mo6yJ/C0gfWic9Sx0vDY985jvWifjSgtGGliLfLMG9goK9kEvuqAqzC6jsmg Cm/ZAK42MC4oly+zVdSwN1rY260KB/IcG4HSydfxxARum1CnT0vxlhbMUaq8g85NZ5DHZrJV1qNH I95oRksVG51OqtGrEegZsiCidSOQhXFBx1Ep1rF2K3t3FXCtIjcLa13P3liDsorJuA7z1LPnYb4p LwtRl2ekz9MxB12dyHjaxN4vMu6sTLphXhvxLJ3xQKVpVN6QzmSzWXnHhtH56NMmvFteWZvyPLwu I3tzC5N0LPvXCjryGhst6yO8kkgLkMeblfbPl/KC0fGbmCyqGE/VrBe1FGuEHMP8WFi/xgnSNbEZ wuuL1EsVe9cGSLKK2UwVsy9Zj5si+DezJ1bF9jazkvZpYbZmVSQmv+9xPjTRup4nX4jg4i8ZUQQZ pWNPy4avZjPJrVf8TPZ8KosWxYbSoa8NzPvGVhBpvRbmrybmRRsUyVoVO2xValUR9tY6ut4NeEJ1 KLJZNikyMT4yfwuz3XRF26/CJtJBYR9+bdSHx6ymVOFztRJjTExPLynW/VaEtF7Ee81M7o2M+7Cf mFkUkHVkYT5Xp1hZLVuJvOZI7W5kMa2RtZiZJVNpm0atJ2yT48eb2YqqWFxdr8SnFxU/o08j7Wu9 ghayFVFpmZlsrOP4aGT6q2V96tmoDYpdyvU6+J3I5ray2V9lsm4a5XCeErGamCZKmFTeUngdsxUa r6mMqtlzOk8hWqvZyjdG8FzKuN7wfyDXsM1N5DOdrGSzbRxdWTFsQLbBulF/rWHrEJlU5PhinSDh eaMxagOTUhWLX5HcWJR1R+47FrYXjt9VrMqq6dy1EZHv8bY9/h1je8sGZWQt02OjMoLaSYviofKs ZcruRceZlLWM7V2vsdLEeNnAYsGYTpoUmZoV76W+PrYXh3fdZhaPzKPSDetBHN2TTUrUlMeF9xLa X+bYOOGpKWKWyL0m+7Exa7y8Vyg7YbliOeFZv8Bi2NJxvReO9n7cWUE+9ZiZj9SxJ2YWEcI7eNja HuWontVbWLySe4etq4pZj3xGWM98WSTLyCKkjSxls3PE+PmyldGLFItuYvPTaLge9W+wN6Uz/jZF 6N7K/Nkyzo7kuCj7tJHp0/pYD/oqbGY1/HbMoiJ12oQRcjQJW9hG9i459j7uvRtGbbwG0m5h8hzb KcefH8asT1RsauwcZVVsifrAxHXT5/IZIxOjnmHxy8j27drP5cr0yMx/uYzGZh+LoLK9WxnfNeP8 5NG1bxi18vF8fSlCAnQl8lrkmBA+Dcv70CYmO3nvoKelqs9dafhEEilT2aublHzMz6lUqVW2jEae 1gmRkvZsZLb95zT0+JvFhsfcLFajlUb8VrTIMWb885eUc5AcSSkPE28bfwA/b5FhzPAH9B3/tJyN Gt9WyOJlKzvBTHy2RvGvFrZjNbFT3OevZQIvwkxhufAl4UVhibBUyBe+LLwiPD9hdOnn3KNeoTxx z+LJxHZqVSLWN+FdXDy5qpoDPFGaTcoJmn65YP97KJJ//Jw/aqAi9ItEHOEePhz9C5aEL+cr0IoZ +JcJx6/iXycq/g3eDezhvwvcy/cCf4//HnAf3wf8fX4n8Dv8HeD/4O8B/6dKTzhVrCqOqFTxqieB U1QpwDNUBcAvqV4BXq3aDPxXqr8C3qLaCvxt1bcJr2pXDQH/UfUA+DNhMe7DzwnPEZWQK9QA1wq4 jwt1ggG4XjACm4QW4FbhW8BbBRewWwCfQq8APoXvCX8DvFvYDfxD4YfAe4TTwL8SfgV8RrgC/C/C 74GvCbeBPxY+AR4SwIPwR+FT4HtRvydc1LWoG0QV9Yeom8D/HjUE/MeoPwIPR2G9Uf+pwbs039P8 K1Fprms+IbxmKHoF4aJfjC4kquiXow8B/zT6p8CHo38GfDT6FPD/iP5n4CvRHwPfiX5IOB3RaQiv 0+q0hP7ztXjgBF0C8DTdKuBXdK8Ar9Z9A3idDvd63Td1InCzrhntZp0L2K3bi/a/1f0tWvbpfgx8 QIf16n6l+xD4fAx0GrMqpoSoYl6LgTxjamMMwPUxJuCmGMwW0xzjAHbGeNDujQkASzEh4O6Y7wL3 xrwD3K+vIpy+Wl9HVHqD/vvAO/XvEF7frz8K/Pf0O4/+H2LLYFMCIcyyeDIPtrQKFvIK/woR+NX8 q4r2ZZ1GQZsNyN+CTnlocyPwZug0SghCm1HCO0I/iYKEsS7N32kOEEHzruZd4J9o/hvwUc0x5D/X /CPyX2vOIf9fmgt4+lvNb4Evai4C/07zT8CXNdC45l80V4kA7RQougjL6le6/wn8vu43RNCd051j cnARIcYd42brhcT0tfpaIujrsHZOf0z/C+Qn9SfR8kv9L4EHsXaBrVhH3JyBRFWZq6pJes0mcyPJ W19XbSarGqusJlJuXV9FY4iOcGUlK9NJIjz1If1npPSPiABxRMNkJ7dyRDta49jXSK6k+NWxUSoS rSCB6CLGRZEYojdWmd8iq1hewvK1LN/Cch/LdxnfMr5F9rL8IMuPsvwky0+z/BzToqxNDjPTf/Y6 DRxMJ0nkCZJMniQpZAZJJU+RNDITsWgW+3+yp3xHYU1acKgDN7Gf08bRv56E+XkWt8bKKWTqY8t4 kkDmk7WkEtFPxF2lndiJj/SQfrKHHCBHyAnyHjlLLpAr5Aa5Q+5xhNNycVwyl85lc3ncKm4tV8mt 50TOxu3lDnJHuZPcae4cd5G7yt1k+uO4XkL/wgAXcwycopySKJdTR2Sbjtspl09nKOWwXM4rlcvM xXK5ZIVcfjFLLpdOkcsXJCJgiVx+GlFDpFxRElHjAbfGLD8vWUDUEDL39Qyipv8KZO1pma+1I5Ab ynVmub5up1Iel8tvLpDLN1JYP+HNuW8ue7PozWqldvbNa2/eq9TLtcr3Ki9V3qkS5Bos1VbVW7Vf Hl/dIJc15XJZm8N6aet0dWl1uXWr6irrWuvcdQOsdarBbugzHDAMGi4YbtWT+sT6zPq8+jX1tfVt 9e76fpnj9Y00R+mXZ1zfK5cbrHLZcFUuG5PlfkabUnqZB3BG+Gn0yugQ+4p+kTxHSNNu0D7CiWdQ HgQdIZxZR8i3TgIfBw2CThNixHMj7Nd4AfWzoPOgS6CroBug2yBEfDEH5X0CgwLBD0Xsh6IZ1KbQ VtB29FuC0gnygUKEa5JQYidsHkE5ANoD2g86BEJENEOj4gnQKULar4Nuge4S7u0GlPdAI3yKsaTJ 1LTZmNTUbqwwphozjbON2cbVwCXArUYvq7caGxiWjL3GfuPuZj3aZpuWsHY8b9ppclIy7kN9n6gz mU0ZlFDPZnQQ7ZSOK5RrzDatMOabBkyVpgFjg2m/qVIUUB41DlIyrjXWGk8bzxrPY2yuMR/1CtN2 jFtrqgRuGOPHRIz9og58F5hCxoJwu2kr+p+I6KeMj+AzE3zOHl83ZkbWm9zGTJPZWCBmY97j8vym E1hXBDX5jWcZ9RiPMPqcOnjJpDRaN7O5M8HXn6UmN/ihZDNmijcwJmRyUhJvo15rzJT1YMxuTjBW iCLaGqAT6CVchw6zGYXlL+uDyZPJcZ94BHQcfQooNVmZrvPD8hNPo32bItst4nm0DVIK6w9lg2kF 3hmhB+MyEOqmBDxLkGVPdW5KxjxpVJawC5ApC3PkYA678arxEuYQTXkmvfEqoxWmQuNtU5Ex11Ro KkWJNZnWwVYMmKcRZSO1BdjIWtiIYhOQ5yCjsA2FeQzbwA3wcTDSdmRbHrMZMc50QkwytWGuNsVm jjLM6kwm28fZntPYb/KFdWLqg376xmyI2g+jMZsqMO4zLRmri9TmGkx9dOyj42VfousSS8RsUC5o mVgyaovh9nzYaAFoQhn2wYk2+7mk9P9LbVqseMTG71OaaPNhWxZbFdsdAr6vxBkaO9rFbcYS0d5M xC3G2eKW5gTRK4qiFPG8F8+lZjXsHPbenCzHqWa9YutKCfttEPeJuyfGnOYVGEMpDZhSITClDGAQ 5u5ndBC2REnxmXD/cL1pJeLHyrF6cxrencbeG+5/ltJoPQvjs8Z8rrnIWAEaq5eiXvrY5/myj2Ld oCar2A9fgU/Cp06IOnEQvFiN+U3W5nXsWdhuE2Dv6Dfe/tCu+Oyo7x4fI+onsBdG4TbsA4xG+yl+ JF6SYzHjY7uYOtoPMUC8ymI6o8+NgWbYB6WxGHYfMew+/OBg2JbDsjOda3qd2rm4Wlw7aschU554 lsZ4k5pROOZQX6Q+edpE2rdG1Mf8m9Xbt6IujdXZeGli//btEf0r0Da6ZzTtpL75qH+2D7Tvad/f fgg85onZ7Ucn7g3UTyhNiN0F1B/al4Dy4Aupsn9E1o2z20+ATsH+dcaS9jNjdWpj7efaLxuzGV0D D5TC9QHK01g9bNdNO8UjoOPtd4wFjIbbHxj3vc1jrj2Umqxva2nsb98qy+XtKdBDG+pOY0W7j8VA tje0hyCX04/uJabtWHcETVw/Tk+x7JZO2J1cy27j0ew+PIXdhKfiDvwxSRCGcfudxu6903HjvUNS oj7BvTed3Xhn4w75NfI0uw3S/3KdzH+M2z9RqVVq3NoTVYm40yepnsAJ90nc/tWqVFUq0ajSVDhD qp5TLSEzVG/jlj9T9ZnqMxJQPVQ9JBLu5XtIEDfyyyTE7t8/ws27neyN2ha1jXsuanvU77ncqP9U C5ykVqu1XH/0weifcD+gN13ub3CXLed2x6yN+Qa3F3fTWA5nQu4Wv3zspNiM20VzEk5iOLk1p4Jm E64Opy/LTuBMUDYol5AanN6al4HyQQWENOAk2bwaVAJaC6oA1cpjmynhqNjcSsiGZJRblHIbyA7y Kv1wOjQYUPYq9dXgIw9lPwgn2OZ9IJxeDX3K8yMgnF5bcVJsxftbbxFuI/hpvQu6h/vWArKMrCRF uP1Usy9Z7cRJJLITN5+D5Bg5hXvPRXKLjHBaomomzY3N6mZzs765jfDiseZl4kmsjRcPNueIR5qX AO1pniseal4AtLM5VTwAyfCI8gnivuY0IGezVhxoTgFqF0fEnmYBqFUcwt5wnz4Vb4rbxTvs6RVx s3gdCOcT7BuXgMziGdEgngMyiSfF18X3gBrEI4gxx4FyxFNiIU7IvDgXT5eLe4kg1opn0YONx1tw H4is1RwQbxC+6R5wnLiF8C1HxEZRjfP5/w2LjmJfowj7DsVpbmk+IdHs+0g8+9IxDfaVwG1jv9U5 insoEQtBRaBS0DrobyXKShD0LjbKtwjTRfkWUQO7Wr959DZBTODc9P7YjcKE20HNFnazoLeKx90o SFMSCHZamzB2s6C3IEibiLjliJdB1wix2kDVIDcItm61kvlinrgCkl8h9olFYinKcFonVrJkQKqE bM1iG/I2JDPKSpRbWVkJnW9neaVl2PLAylu1Vvr7ngRoATbKD/F/JDz/KTQiMI2omUY0TCN6ppFY ppE4aGSYxDONJEAjt8kTUXeglxlML6lRn0Z9StKglyIyM2YNtJMB7fSRuTE7oaNn/p+/jyP5xMo0 no37LKmCRmrgtTXw1qpkmWqOy6X5NtFWtdcMVG2u2cPSfgv90qrlP+E/Ab/D/DDhhE9hjXzUx1Ef ExUscJgIUfdgh1ExxTHFRB3z/ZjvE81/aQyXcGPaMvr/P8QdR3QgljzCB2FtlhUgWKkFVmqBlVpg pRZYqMWg1CnR/mb6YzSUbQptVfqAKo6OEudNwLztCtkYEct2ePOp0TrDkAUfdI9vp1Qpju9HibaF ic4bblf6E4tT4dMn80Z5sYSUZ+vGvUN+1sf6hechFniSBXqz7Ffo0H+B6LwnmDzG1i8TsYytgTTf GiWZPyrDMwpdGEd80I/yMsoe/tKO825D4Fb1Vndj4O6OS25z4F61090WGNlx1b3VSnbccG+XhOpr bqekQ7sP7bfdISluxxDypB333X2BuzaCPqk2tXtAmo0Z+loSkbcF7mFsoyRQLGUC78E8W5Fn2/Tu /VKuLQFzLsPbfYFbtmT3ISkfT49aGmguFdjS3Hss+2wZ7hPSaluW+5S0zJbjPiOV2Ja4z0lrbXnu C1KFbYX7srXQVui+JtXaitw3pQZbqfuOJNrWuYelVrQ8GG2p9PCWQZvBo0VLnmcKxjYi32Ir9CRi rNmTgj5tnnRpm22rZ65kR88Fkte2Hblkc3oWtyy1+aruY41t1Xqp1xaqGtpcauvzLAXnLMcaG6V+ 24BnuZXY9nhWtiTa9ntWBe7ZDnnWgPM7nl1YxR3PXpZTPOw5wHKKH7gNyOnqDnbwnsNSBfJdLKdY 6zmGfIrnpHQE+XvIE4HFjhTP+8jTPR9IDeh5kfUfy+VRWobneq5I3nF5uuc68gUYe9x21FMu7aZa k/ZBSrekQcjnrnTaLnaWBrfbTnhexxpPeaqR7/GsD9zrWOWNk853rPEmSZcq73nuSb0d5d5USwN6 mtDnjMcKzcqjznk2Q9oDHmwBtguedilOyS97bKP4mscNKUXmNz1+SCwi73jdOxvaId5MKbWj2pst Xe1Y71m+SewweXOlGx1Wz3LLvo7Nnl2bS6udnp7ASMdirL2kus2z09LQsdQzAg6XewXglV6ddLaj 3btMut1hgxxqbZe9+VIcs8khpv1e2zVvAdbohvxLOvzeAul+R49nV5B07HS3BdUdu7yrA7c69qJF T70mmEDtM5jcccBbYDXYlnhLpLXVTu9a2XeCadRKgxkdhyGTho5jnsPBrI6T3gqs4j1vLV0R85pS b0N4dcAi8DVva0siNHURo973thr4jg88FyFDJh/o9wPo9KJnuSR0XPFukUSsdDlWd927TcZSdsdS rx2WDC8L5lB7Di7puOX1Qi9bvRJs+6a3F1K9Sy1BkTDDkZLsuOftBx6pFYN5dsG72yLa0rz7pFq7 znswuMLW5z0SuGWPo5KJlJhtv/c48GLvoFRiT/KethJYILXhw96zWIsbGO2ezVZiT/WeR3s73q6z z6a6sGd6LwFne69KtTTaBAuV9lzvDej0sPe21LDjkncInlXkvS812Jd1EimuI6VTDYld7tTDlko7 E4AvdCajPZFiGqmCS9CeFiyy53dmBEvtBZ1ZwXU0agUrER/2BA321Z05sFLIP9go92S+0E9jRdAQ iW37O5dgdfCpoNl27VulwFRHXkS2B8E2GkOCRaOWaZduKFGOydxeAqtbBr+jMj+ElYbxzc48YOaV NB4Gt9LIY620r+1cIeXbKzoLW5baaz07pQLZku0NnUWSOO5pBHY86BKlfCff1dqyNNL+d1zqXBe4 Z2/trJS89tudN+FZhs47kheWb4Dlw4ZDfntt1xapwKlFjNpWPQDrNTDrzZH91zmFRiRnYtc2plNE Fcg5Q4pzpth3Uzl32cNyZtG+n8ZYjL3W5Q3cw1jaf3R1mJlZnZNJgEX7ITmuyjyDB/DsnNslWRoQ YYDDluxPCC6RdxZbG+L/NuplocMyn9QfQz3yWpwLvEcQkdiuQfc1zA8c3EqxNcMBbG10Lu7qDYxg N9lKfdbdFtpJcWiXcynwXoqDlyPb7Xhv8IFzOfABRT454OFgJA/OlV39kuBc1bXbWuhc470UmuIs 91xB++KufYER5+tdB6UGuodizqKuI0FDuN17RGk/RtutlZF9Im0YEak1cBfxZDl8IcKGKbYOUIyx 2xFJzjqrO9NCJ53rwc9Zp6nreLCItofeo/OE3q8egLUb5Dmd1q5BabZzc9dpy6CzvesssK3rPPZK 7OahD2yVXZdCJqe762pLotOPuNow0TtCFym2Vka2IzqZIIce6H2LcyVWJzh3Yixw1w3gXV23g3n0 PBC6Qr0mdJ3iikGbuWsodMu5AH2ynXu77rMItgfSO+BJD62RI5vzsJ/APiMw7Y8+6B9c4jzmV0u5 zpN+PaJchM0wnEFx6O649kibfBTnYPc/aDvlTw7ccr4HW5VgY07YGE4FwZuKr73vT8PZAKeX0D16 TgiNwPawGzo/8GdIqY/Be9mOKUdaE+JnHj3nYCfCiSK0nGJrI8OLZUvAWrIku/OiP6dlqfOKfwn8 4ro/T1rtvOVfgTiwBeeZEvu2TkPQabe79xvS7d7OxqDZLnWacXZa0dkmbbP3dm4NEnt/53ZEgN2d TvTf1+kzaO0Hvb1Bn/2Iuw1R4oPOkHS8+kxnXzAH/QcsxzuWd+KcRs9vwTb78c79iMyD0O8WnAoO BUP20/RMteN251FE3Sx3n2GufNayn+48Aa7Odp5CyDvfeSbYR60iODBqIfBc+6XOc+DqaucFKQmz GTDbjc7L0lm0XwvuoXtiMMt511/YLcCzGhFtqjuHg/ttWzsfBA9Bd21SboW381TwKMXw+ks+HnMO +bTBE/b7vinBU3avLzF4Rjk9yuc0WcIst/f6i4LEecBf2q1zlPp2hg477/nXdcc5R/yV3UkuwW/o TnXp/I3ds11xfnN3pivJvac725Xqb+vOdc32b+1e5srsPNOdbzvh3x645cr27OousF3wO6U4V67f Jx2RI55rGfaILDnKufIRAcwOsz8k3XAV+Pu6V8NmBhCf2YlaPru6Vnv83SU4V1zpXov9rhX7HbOQ yFgKH+yV+l0lmDmHPpVqO0z+PaHrrrX+/d0Vrgr/oe44V63/aHetq8F/ojtV3lvp27GfOv2nguod V32LEanY6QKxF6cL+ZzmEtm59IT/TPhsExnzbQP+c8DpwF5Xa2eGYakrF3vrEdcW/4WWBa5tnpPd DePi/DX/5TBWTikm75Zgnsvuv9YturzeLS0LIuO/vAO6JOASx03/ze5WV6//jrUUfN7AXj/gH8bJ J8Gn7d5iHwT/c+2D/gehuVSb3duofrvtrv4Aj1XsDmjhF5AS5F9CT7/OBYEpzOPoDuLzpQSzHMSX HiTVR31zpeP2I+iT7VD7FgTPOfQ4xV2wLfEtDl5GzktrHQmI56WOZN9SaZsjzbc8eMGh961EnuZb hZ45ODOUODJ8a4LXHFm+clgX0yPmfx0nou2+6uBNm8G3HqszdOYgnhT5TJA2chp1fVZJdOR4Zwfv OJb4NgeHHXm+duQrfDbYKo3JhxyFPnfwgaPI5w/xtkpfT0gLnncG0+QcdrsLMpFvMZW+vZZBxzrf gdAUR6XvcLDQluE7Zi10GHwnkTf6jln6HexkIuc2s+89vL3N975hqWOr7wP4SKHvYkuKfPp1ZNEz nmO770ooETNcD6VgdVq0OH23QukOn+8ublXyzajRdw9aoDeFCqx3RJIcoS4htMDRhxOF5Gj03A2l KHGM5kuV+MZyx0CXLrTS0dcVZ0h37OlKsvpsbV2p9JTCdvacrtTQKkhvruR17O+aHSSO0q5MK8Go 7NAatO+0VmKnyMW51Nu1zJo1brZDXfmhcsfRroLQ6wxXO0749obWO051rQ6ZHGe6SkJWx7mutaHN jgudd0LtjsvVapyarnVVhGyOm121lm3udYGTPWZ64+hZ4U7zrZFa7UcCidKQ/bTvbrDItQ/rHXId 7FR3ex13uhpCbscwzV1HAindkut4IL271zUYmNvd7zodWNC923U2sLh7n3zOd50PLO0+SOVs7WN2 e8R1KbC8+7hyt10SWIlbrXyfjbyryrdUdj91XQ2smnBLZfHNdSOwpnvQdTtQ3n3aNRR4vfus636g uvu8mwTWd19yqwMmjGLzuPUBa9DsTghs7r5K39t9A+9t775N39s9NHqPftB9n96aewjlpEdNOUHL KCdoBw89etla6G7Yk0Bvxz3JlJ+eNHoG68mQb9ZUR23H6OmoJ4v6UU8O9aOeHOX+Lr/F7D7Ts0SZ DdbVfd+dHLD15MlfJOSvBPSkammgZ62eQndWwI/Iz74/yDd9d06gp6fIvSSws6dU/s4gS0z5ksDO lu7SwLGexvCdi30TYFj5RoFRwTZ3XmBXyO9eEdjbs85dGDjQU+kuChzuMbgzAm6rmn31XcW/Sgj7 FZmg+Z7mXRLFfg+Wyn4PNov9HixD82vNVbKI/dbrRfZbr5d0v9KdI6Uxzhg3eZ39hu1N/TH9IKnB jEtJBvkyIWQleYOkkGryNsllf6u0lPhIFykj/eSvydfJbqRvkH3kAFlHfkaOkjfJKfIhqSJXyL+S ZvJv5BbZSIbJQ/ItjueySAe3lFtGDnArue+Qn3Auzk8+4Qv4l8mf+Df4SvKQb+E3cyp+B2/nolWr VcVcrKpWVc/Fq6yqTdx0YaGQzc0QfiGc5J5SP6lO4WaqU9VzuFnquepF3DPqXPUXuefUy9Qvc19U r1bXcy+pRfVGrka9WR3g3lL3qN/ldmiGtZncO9oF2oXcOe0i7SLuA22udiX3ofZV7avcdW2J1s39 m7ZL6+dna4PaEJ+h7dMe5edqj2nv8V+l/3WF36Y7oHuX/47ukO5n/I6Yb8fYeZd+ij6PD+r79fv4 Qf0p/Sn+N/r39O/z5/Qf6j/kf6u/oL/AX9Rf01/jf0c4yK6BfTVNo79rKt4OcoJ8oBBJKV5X7Cz2 FYeK+4oHivcA7S8+VHwUtRPFp4rPFJ8rvlB8ufha8c3iO2gxFDcWDxc/oL8NY78fJJo+TR/h6d99 JfTf7iZwF7mLhHDXueuE425wNwjPfcR9RFTcHe4/iMANc8NEzf2J+xPR8CpeRbR8FK8l0XwsHwtb iuPjyRQ+iU8icfwMfgaJ5+fwc0gC/zSfSabxuXwueQJ6+AVJppIjT2JNF8hltrIE+pu40pOkuqy/ PK08ozyrPKd8SXle+YryQqSi8tLydcCV5YbyxnJzeVv51vLt5c5yX3movK98oPRw2e6yfWUHS0+W HSk7XjZY+l7Z6bKzZefLLpVdRduNsttlQ2X3y0np++Xqcn15QukH5clla8sqyiowsqKstqyhTCw9 iZ6tZdtAW1BvKLOXeUGSnEovll4pvV7WW3qrrLcstfRu6b3SkTKhTFcWV5ZUNruspCyzLLsst2xZ WX5ZQdlq+kur6I8hzaRxvkB/6Z1LRFj2MrIJfrGC+cIr8IED5FV4wc9IEXzgQ1JMbiKtYTL6Gmxp JynR9mv7SZl2l3YXKdfu1v6QfF37o//N3tfHRZUdiZ57+5OGQURFZJAAtggd6DgMOIjANC5hWUM3 3bebj3EIY0zT9AfPdY0/YlzD8ljC+ljHZQwSY4jxEWIY1xjWEOMaYghxDfGxxCHEIT5jXEOMj8e6 hEd4/owDr6ruvU3TYDSTvPy11K/qnK5bt06dOnXOqXOB29q32Wvar2u/znZqv6H9Bntd+03tN1ml tl/7PfZR7aj2J+wN7bvad2FOcawDZht6ORH/5tB2kzEhDlAPaADczHJsl4WzQo9wUegTBoRBYVgY FW4Jd4Uu4b4wKUwLj4Q5u9Kus0fYo+yx9kR7st1ozxDShXghyzYi5AkFwg7BKpQJlcJu25jgFvYI +4WDQoPtjm3cNiE0C0eEY8IJ4ZRtSkgVkgTeds02ZM+2zdowDjnNdc0w/T2ibpG3PgWQwX4EkMl+ AbAFVoZfslfYA4As7Q+1P2RbtcPaYZat/Zn2Z2wb48KmXlDTbysNTMOY0wu4l3HuESjrAA9BfYxx RX2Kl5xOd7/T677m3Osecta5R5yH3GPORvcd52H3uPOoe8LZ5p5ynnTPOk+7nzjPeHjnOY/WecET 7rzkWe284omh8qon3nndk+S84Ul13vSkO297spz3PHmk+4GnwPnQs8M547E6H3vKqpmnslrt2V0d 5nFXR3r2UD3as786znOwWu9pqDZ4mqm+2XOE+Fs8x0gGMcdzonq751R1kaeLrlk8Z6sdnp7qnZ6L 1bs8fdUuz0B1rbsfkfoDfane5wmvPuBZXV0PdqENyyDZhPYEItoQiLItwYj8QOz0jFY3eQbRL9Xd nlso4yrzFsp2kS2XPZPV/Z5ptBn9Q/wWsFUuEVvdU4sQ75MR+uJHtO2a51H1kGeuesSTRP4Z8+wg X7R7hqvPe+5Wd0Ab6J9ez33y4x33OJY4ttXjlbN4D/qL/DAhlVNeJY0f+kgqq2fdI9VPvDrUS75F P7WIpYv38GgLxohL642gMtwbRf5Hv8gl2o8+We2Jx/GUS9l2jCEcX1eMJ9UV742lPuJ9cin3TSpd Sd5EV6o32ZXuNfrtnFjcl2Bb/aXkB78/DoulK8s94crz7HcVeDNcO7zZ5Cfsm1TSeAR8xvmBsYtz hOIXEPtP1y6I/faXl8T++8ury/df7i/Op8D+y59xflHsS2PrsnpNNedEXnDpl6n0Frt2ewVXl7fN ddZ70u+v2meXNRee7/oiuWB/P0dZcyngc7CfJZ/JMfS7yporC59rror9flop+yXY1zXXRT89q6Q5 jPOrY3EpjyXZDf2R41D2e80NWHdhTaT1N6D0xy/ON4zLut9dBvvR305Q3NfcdN+puQ1r7p2FOKdY OiqWctzLn/1lQNzX3PMcrHngflLzEGJcind/KcU8rgUo558DUlkz49Hiui6XuJfQOr8vaI4ElU8b V//4PvbEYH/kUl5T5LkV/Nk/165L6yV8drPFJfJxDaLxu/GU8mbQnAyKHyzRn261Jwv3KtwXsZTn pX8O47qPe5hcynEkrXG4fwaWpBvXCLwX4wxiyR3mNWHsuNzeCjmOXHu8VRRXuBfK6zus3a79XifK UOzgGgRx4jro9fr3fbDT1eDdK889/7qGMYDrSLO3DsfGdcR7CGPbdczb6DrhPew65T1KcSnlA+TD Hu9p2v+C/Oe66D2D/nL1ec+5BrwX5L6hrB9vea+7Br2XUKc70tfhjvZ1uuN83W6977zb4OtFP7g3 +y67t/j63Tm+a/51R1o3/HEijwfMAfd2zyDuy/JaL88Ff0wHrTHuIrAdfQ7ru9uyYIN8n9vhG3Lv 9I3497fgtTF4jWtdvIcEx/KSfTFo/3Pv8o2Rn6S56nb57rhrfeOI/viQ25Z1y+sR8qRcyp+LyfmY lJO5hr1XXKPeq+T7u94brvvem/48DefWpPc25V2Y5wTmPVKe5Jr23nM98j5wzXkfUvxg3OEcl/M5 XFeV3hmatzrv45oIH6uJ8qmpr0FYE+sLQ8Q9GJHiCWMJ7KlJ9EXWJPuiaR5I+WCN0RdXk+HTy3lh TbbPUGPybUaf1BT6tpBvEOV+S4hjXlPsy8G+Yv/QvhrBtx1jvqbCV0R9l2RrqnyWGqfPUeP17azZ 69tVU+dz1Rzy1dY0+vbVHPYdqDnqq69p8zXVnPS1uM/XJsl5rXufb8J9wDflrvfNupt8T2pO+1pr zvja3S21PCLtCdIcpTwb5wquTWCvu7VWS+OFduBYyL6UcmL0kT9vwP5hXLbXhlP8dtSuxjEhOzDO wT/op0X6sAzOuwPybfI5+hTXJlyHAuKIYkaKF3/eDH2ge1APyuN6JJ8L5L1JypnQZ/KaQWu0tJe6 u2vjA/cPOmvguoJtQz/dnbUxuOZgW3iC1/xC80vGdD/G/0sMfTP0TYbnn7Q/8fOXw2xeUaz4K+6D 9LTFRk9byulpy2v0tOV1daz6n7iP0jOU/6NN1X6IT8KnJ7wBz7f8Nnx6wufQ05NP0tOTT9HTk7+m pycn6enJu/T0ZIyentyipyd36enJBD49UazDpyeKJHx6otiET08URnx6ovgQPj1RbIZzbxc7u/CM wdTFikzDplumu6b7pknTtOmRaS5fCaDLj8iPyo81nchPzE/ON+Zn5GebuvJN+YWmwfzifME0ml+R X5XvzPfm782vyz+U35h/OP9oflv+yfwK01m4djr/TP65/AumnvxL+Vfyr+Zfz79hOkvQA3CRoI9g AGpnCbEOiM8LNBdg7EKDTsAHYew+zf4Gzr7nAbbSaTibvcNG4Lw7CpDLfZI7wPLwmRcz4TMvuJNj FawqoL/TLBF6Op2zz/Qorw77apozTWNvc2Owv9DrCOgx9Dc3PO9BfnZebH5yXl2+KTc8Nxx6D/3P GcsZyw0nG78DNq4FG/VgYxIAx5IBeDhx45vdUhn+35yRfYip2EssHU7hmSyLhYBNBewFVggQzooA VrAdABGsGGAls7ASsNTGBLYaorOCRdH/qMewOoAXWT1ALGsAWM+GAOKg7z9mH+DCuXCWwDh1nfrQ Ql/N6YqXzOnbJk1h5qzcWXMelAWmdvMOoBNmq7nMXGnebXYD7skxmvdvmzQffPVxkXNbs7nBvMek Nzebj5iPmU+YT+WOm7uANuVZzWfNPeaL5r7cJvNA3kHzYJHTPGweNd8y3zWnA9yHVkCraQg0LMA0 6CHIHReBtMjwSITcIfMk2DNnUVruka5KS5Ql1nwLWkgHrYC5s6Z2EUCuEltByB03TYDGPeYBsPuu OcvcA3fcsugsEaYwS6Kp3ZJsMZrCTHpE6FE6cDMs2UV15uaiOovJUgi6j4CGJtRCmsrAOsRKsG23 pdi8O7dpW3OO0SJYKnKM0Of95kFEbA3RUmVx5pjM6TnJciu5sxavjNDaXrTDUmfZay4wnzIXWA6B TY2mdmgN0HLYctTSZu6ynLScNp+ynLGcs1ywXLJcsVyl9gEt1y03sHdgwU25bUTLbctt80HzMPYW RgNqMiKH7kZJsOv3wW19JUXokeUQrlnQ5hJHyc6SXZZE2cJAXI6PPHzOGmg9Ysm+bT0lB0rqTb0l TfjEtshZ0i70546ZwqyPtg0L18ieyW3N0nNceopbVBfwFHdEfI6bO1syhc9wrbxVCxhO5WprzJ83 WOPR59YkayqV6dasHFNOrDXPWoD9yJ0wRVt3WK2AZdZK626rG3CPdb/1oHV/TrK1wdoMeMR6zHqi 6Iz1lLWL8Ky1J3e2yGm9aO2zXsSyyJk7ZB0AHAQcto5ab1nvWu9bJwGnrY+sczaldTrHiHWbrmQi x2iLsEWVtJZMlLTaYm2JtmSb0ZZhy7aZbIXoD9OQrXjbZEmLTbBVbDtlq7I5bd5tzSYLInD3YsTZ dLY6wEPWVNBVZWu0NmP8f6RwWzMA+MvyAKOwqK6oDqSbLQ9N0Sa9ZQai8HEJw6hDX8AoqkvCzGUl kebKkuiSOFgP9li84iwq0ZcYzAMlm0u2wBx8UJJjqcBWS7ZbkoUhtEMYEcaEO8K4MCFMCbPCEztv 18J8bUCf4njDrLTYw3MK7athvTmBiC3aY+zxhEn2VHOXqAGv2dPtWTTfQAPitmGINEB5hvgjCeYh ImqnFvJemSK9BaYhmHsO+w7SUCnOf/A8gO2w7aitDRBpm7920nbadsbaZztnu5Bbb7tku4Jrkqnd dtV23XbDdtN223bP9gAkH1r7tvXYZmyPBYZ3C2ohTIgUoqEWl2MU9IJB2CxssUWUNIGuw7Y2a5+Q Y7sEdLtQJFhKmgSHsFPYJbhyZ4Vaun+fcECoh1K80iK0Cu1Ch9ApdIuronBeOO/w4lprt9rL7JXm AaFXuGzfbXeb0+177PthjAbsB+0N9mYYp2bzMVqNL+Y24VpsiTDfzR2yH7Efs58wtdtPmS/au+xn 7T32i/Y+4A/YB+3D9lHg3rLftd+3T9qn7Y/scw4lgM4R4YgyH3HEOhIdyQ6jIwP2gf243joKYafo chQ7BPQ7enXbtLhSmnc7ss0NjgpHlcPpMNFOeOU/M61lMi18jwA+gcc3a7KsO4zbGs9WZw1vjci6 tTU2ozPDkTmceSvr7tbElx9uTc66v9WYoX75YeZg5v2sya0ZwMvOmt5qynq0tZB4c1uLMzq2XM9o z+jcqtwqZIB7t+q2VuDbGzSXNP9M72b4MPtzGIG/YB+B/MMMWYSa2cHPoTAiH8X/MAHLHpJF9Jsz xxbGlfdCmQPlZcVLjs2l+x1bAHMAtwMWAVoAHYA7AXcBugBrAfcBHgCsB2wCbJHKVsB2wA7ATsBu wPOAqLsX8DJgP+A1wCHAEcAxwDtSfRxwAnAKcFaqPxH5pbwkA1iqBQwHXC1diwGMB0wCTAVMl9rc LPWnKMDWTsmG5XBIsicQJ4JQsiUYyfYALC0AzBLbLN0hyfUF2IX8SsDdos3kn82SrXJZJPk9EJsC sDMAwbZSN+AecQzQP+hv9EVpHqBVbIP8Uyb50iGVoJcgXPLX0EJZelCypz+ghPgobRD1ko1jAeU+ yU9QljZL5RHJ/+MBZZPkt1ZxPP2lbHuHNL5YHpP6OB5QSn3z9/EE4CnArgA7g/qyxFa5lP0QXO6U xvIsYI/k/4nfUeL8wNjFOTIroeyPp/U/2A/B/Q/ud3B5Xox9/9heDOAFl7LMAOBg6f4yHWDEMuP7 xy6f5vfnLYP9HOy75yzlfj+rDPax7KdnlbJ/l5TyWDYF9Uv2D66715Yp5bjF9XjkOcrn9Seu67jm OkoXxfkzy+BxkOM8uAxYA5Ytce94skwZPEeeNWeCyxapP3IZvLY8ba15Vhm4Fi1XPmuOymW3uFf5 y+D5uVncw/xlrxQ/QWudvxwX26e9D+X6pfkPsVM6XOqPo9LR0oV4ktd13BNuSTIjkv8gPkrvli7s +2jn/YAxl8d3QlpHJsWxKZ2WxuAR4BzMBeWC/2UflkWJ+1+w/8piRf+UJQImL/SNZCUsMwEaRZ3l kYDRgHGAekCD6Idy8Fk59KU8p3RhXgWvF/I4wBzAvRn35SVrvtzHoNgiW9DnU4ttkO8rhzlYLucZ 46XPXgOftaYFx2pQLJVbJHukuVkOdpTvFNEfH3Lbsk45nvpL/bmUPxcbCuCBfWUZgNmS7wsBi0sX 8jTAMkGMYcxzFuU+Up5UVgFYBeiUeDguT0r9+Rytq17RrrK9gHWAh8S+BmNZo4i4BxOGi+OB9pQd BjwqzYPVkt42wJOl/ryw7DTgGdEnZeek+EoP6LeM4KeyC2JfsX9oX9klMR7Krkh9l2TLrgJeB7wB eBPwNuA9wAeADwFnAB/DeDDAjlJ/XlsO410OeUI5xFk5rIflasAwwAMi+nNWbAfXyw6pv2Bveb00 XiPSWMi+HFnwkzy3qH8Yl9LYl7eIY0J2jIj+QT8t0jdSuiTvXpRv90k+TZL0B8bR2EK8+PPmIWmc xiX5LaUL5wJ5Hkg5E/ps0ZotxWp5e+ni/aNFlKG1DvpZ3iquOdgW/gUVvXmP/eeJdOmJlGvlHuPz YS6cmRjL3A94ELABsBnwCOAxwBOAp6TPiF2AZxlLyoKyR8KLkgxg/PQCZvYBDkj3DYqyxB8WdVN9 VNJxC/Au4H0JJ98Hor5Hki1zjGXoFxB5W5QS6iSMkDCKmTJjMuMzkzJTM9MzszLziGYBlaEgoQ3o DgJrQht8KstMp7IA+HmZlZm7M90EewD2Ez2Y2QCAtWaiR/AOkD6WeQLgVGYXwNnMnsyLAH34zkF6 gyULeHelgt5IKb6Lcg29czKK3jYZS++ZXE9/dRxPf3Wsp3dLvkRvlcyg90lm0vskt9CbJLPoTZJb 6R2Sr/4JW8K3WHgX3mKRsQvGvOB3Y4YLsHYZ/r6n8JKgPABYv/RaRtNS/jPbbwFsZR98+cHLD//I MPPyY3zDJL2hlNFbRsX3i6ro78l19PfkL9D7RaPpzaKx9E7R9fQ20Xh6a2givS80id4RmkzvBU2h N4Ia/r/p5ZQ9yhGmgxG04Jt80+4xliYAVvhLrXE7YYgRPJ5WxTRpMLPSnIw3hjEFXFca45gKUA3y WQkZy0DVUkhLXgoJhcvAMvrSjEshIWoppGUshQ2DSyEtO+0MoUxRoyntHKFEjWqjOq1wGSheDMYw Y1iasBiMkcbI5XgJJxeDMdoYnZC8FNIqloGqpbCs//4Qn5qWgYhlYBl9G9wJ2QnKtJtp99IeJugS lE9t4wyMiXvjSEJj2syGRxvcyNNnLIWE2LS98XOg8UHSDtD5GHnBPkVY1r62ZeDCMhDUB2OcMS7N uQwsM5ZJO5ZCmjftAqFE0fdpe5eBurRLhDKFNjY0LIW0Q2lX0m4AXoEa1MkzuqWQ1ph2lVCiyNtQ thSWs3nDnqWQICyFtKOLIcGb4E1rWwxGvVGfdnIxGA1GQ9rhZaB4GVhGDp970/ueGb29G9/bXce0 ykPKT7MQetMzfq+YRpmh/BhIfFz5cWZUViur2YeUf6n8BNus/Hvl37NMerP3FnrH9Suwgzm5ZqaF 9W87e4GpUzoZW4LdjFvXyJSAKkAN8c4zHuoKwMiUpmTjuuJNoyl3UprWFRuy1hUvgGG1WKZ0Agyl DD31c/cHdAuf119LOb9+KGUkZXb9hGF1SosE4wbeEG/IS6lP6QCsT5kyhBtSDQUprQD9gMAzpBt2 rCuOi980HBe/vn/9yPoh0F2f0p7Sm3ItZSzliSEmpT4u3lBmKIt7ZKg07N7UB61NbBqM04Ls2Ka+ FBfeAbx+0a5Ng6gN5N0gv8ewH+UD+7V+ynCQbLsMOGHQGpJSWgxWwAbAZsMRwzHDiUVj5qUxk9/O raH3cuOYqZ8qQaNKchH0Nxfp9DuNGHzjfFIlIdt0lSk29S0AngvoTeAsoMZxxZxj4Tc06xsYF1vE zAa9Qb/26AIY4Ce20uCQ64bNhs3ytY2TGycNWwDgxy+fY8jx17cDFBmKAnUFllBzyNdiK2Mr/XIO CYJ/9AvwVBuXsS/QrkCbgu2RddB9sowFQGoP5ZbrM/4Wim8P+zaOG3+a/w64+Xv8v7A4/gf8fbYh 5Fsh32J/RvOrIPT10N3sw/TtAPhW5kjp/d8b8PeIPL6JWQn3w4mDP8NfZiq+D3TF0D2xIBHDEim3 pPHSGxkr6WTcmjvUOn5nAOjA99SzLSxn4e9g1k2zlS+2vNgSkxFzb900gl6tV697tG4uRhmji4mI iYqJjUmk9jEyQ/iv8l+F9r/Gfw04X+e/Drov8BeYgv822KKEHg0yDfUlBOx6g+lCPwbWrYBoOswN UzQJbCW0eohxm+CUtKGbsTU73heaN1VsqojeG703tj22HctNVZuq1vWu69Wf1J+MkX7WXVt3bZNz AWLCY8JRLiYeoC+mb8PAhoGYVIA8CU4BnAAAOayvHVg7EDMaM4r6ZVjXsa4jUCcCygUC2iYD3oNt +W2E+zfGbYwj+/at27dIE1yP7YjtILtkm5axZ8P+DftJH/YJZPzWeaO9awfXDsZkxWShLgIvAJRr p9dO49+N0XdJMPqWB/FbEnjdUd1bTKH7rK4Nxu6E7gQL0Z3UfYHpdF/UfZGF6b6s+zJ7QXdG91UW rjurO8sinjuOOe4cN0mjXgfRydblMBYDZ9mN1wCHxPraZhGjb4h8mbehZwHXRYoY+BnLVY4FlD5z G8eZOfryxrzo+qiyqLKYQzEzUWWJpzYWrL209uTaM4kN0ZHRDDFqx9pzax9v3BFdD9gJELl2Jjpy Y0GCK1od0xjduXFPQnf05ejIqLJofXR9tH7NeHQTlPXRl9fOrHkC9cg13dFx+CmqzI+X1jbGNG7c gQgaRES5AARb8mQUbYzuDLCxce2lDUrJvgrSUy/r2VgQg9rBLtmmZe25lLAT9dJ9IIN2ResBI6Os UXlrzkdVghToShzeWLCme6N1434or60Zw/+p49/kj8OYfo7/HMzzz/Ofhwh4U/cmC9Ud0x2DOPic 7nMQB6d0nRAHX9F9ha2ib7NYTd9Xsfb3Wtvw9/JWwD20uunpv0l30t8j5kgrnp7kDtIOxrHCALl0 5oJPq/1yuLp9AaMY1iBqn1qLo9bw20K1FN2MoltJ0a2m6NZQdIdQdOsoukMpul8gTdgHRn1QUR82 kj2tkt1nqG2Rd4is5uBEv8AblOwOlOslqzn671zk/SH+Pk7+Xr6/atLBSAdHOnjSoSAdWri7jeE3 3aqWtk76Q0OPg/7wp3qBZ03sCPlBHAH6HlR2QPLCXj+PZ5XS+AXKuSQvFEm89zM+zxrxp9ndyi4E 2L2JeL3sVEDUiTy3NH6BvCPS+Mm8P3z0nsf/f8j4LucFjl1kQ7T3Yz7IYhMBoZ+xRmaOtMQmrYyK TY0sAjREFlGZE5v+wkWoW6AO16FWC5ATmwW1HIDa2FSCdPwUmxebR1wEC0KAxl0B+ugKakI9gKKe JNBSi9LUWpHUMmjCvuiO68BXui5dF/T5bd3b9I0lz7kHwahfXsiLIgXGwm5gfyMdK1oA70SGRe6M tFDpQFhxJ6IgcteKKaCuFXdW3Fn5kKQcK7pRCkGWjHS8GL2iG1Hs72KNslREAeqi+/x6XowTWwKY jVQD1CJd0Q1t4rd28LrP6zrebw9XngO8wMwrz4dPrexdGRY+taJg5eXwKfh0OXxiZf/KfqpfWzkE tH+lHnAEuSt2hI+t2B1+B2FFQfiEJDsmwsrzCAsaI46GTwFK+kgXavLrAQ1TdO3OypEVPNxRCbzd SFeOUQ/bdd2/x56BM/Um3HdOmoHJwFNw6VwWw7+IP7GIm8wZQY5jjYu4cZyetcPn2kXc1VwMg5MN K1vE1XERtE6bFnEZp2aQYTBDAJdnsywvYGVIDujbs2d4JN/JfxkkvsKfgTXtbf5tyKDP8efgzh6+ B3xzib/ENOCb7zEtfxU8FML/iL8BGdwI/2P2Av8T/idsBT/Gj7EI/hZ/i63k7/J3Qecv+F/AalMZ WgmrzRuQg6+BHPxjEBuYw79F9E2in19Sfyugfiyg3hZQPy7Voe+cg9sJOV6q1PcU4hVzAvCiF/EK uB3AUy7i5XDb4dPUIl4Glw2fbi/ipXLptKMG8vScgXbUQF4sh6eU04t4OLocrN2BvDAukvarQJ6S 08EnZyCPPeH4gN1C5M2wxwG7hcibZNMBu4XIG2cTATGRQnGO489o7eZo7eZp7VbA2n0a9r1OWME1 wSOhO7VkJI4F8D9L9faA+rGA0XoroP7mkvrxAJnjAfceD9B5PKAtsf6lRREg1rG/ifSfHVFwChV7 bFiQht6JZ1ekuP/qmIqtw2/UkriL1q6wJjjbPWHmsMqQybCB8PqwvNCJsLKwPCxDJoFXGWaFa9Oh U1CrRI6uDbjpYQMh98Pw7TIAfsnKkPsiYD1Y44IU6sL6gh7xGnF266LW3NcdDbOumQSap8sOyD6e 9wwUzlmoh/ug3yy0A7ATsFvC84AQyaGXAfulOlwPgfNMVDGgIGGFhFWATqkO10OvLSB+jj7FzLoZ 7Xnd4xBrKAtVh4YBjdRVaHtDykKjQ5luRjUB3LjQSG1vqD7EHarX9mufwOc47XmEULW2F65EA8SJ oJtBWKTRr083g7pQ04Ie0HA+pAzvAIlI7WVtdyiDujXUoB3/I+RNz7sn3uOiyOv4n0RMlw6nQzfg HsD9Yl0H69aqg1LZAB7fByWcPFfBerHqGHxuZeaQUY1Tlx06G3IxZHfIMFAoNU6NM2Q0ZBCueUPc UBtFjjYMuGd12Zoq4NwikCVHNVUiYH2JRr8U6sJ6gJ7d4mfg3NIcXVWlVYcMrnICvUj/AfZ+Tjbv K2bVuxjT3hC9E7lT+nxVxJBaEfG6tg7wECDsvNrDgEcB26T6ScDT4nW1C3RdFEuSL2RmrUn1WFuo 7tAWawVtBdAqTZeaqTu1TqibFFuA69VWqZl2r7oXMExdBJ+9qscIWkGNX2/nBPBKYEJYpHFBnwl1 oaYFPVoBZPfiHSBRpVarZrTFUO/Q1qk3/wljFr+37XFABoHPALVze9975Ie+ubzfYzfBkxZH44jr 8OB8lrwuc7GqOqDpajizcbmqV3HVxu/sZPdRhmtVQ57NF6icUL9EHJE/Q5wB9Qxy3ruFksRP19Ri Ha+yx3gvx6itaZKJI5kBFVjDJ4kaVAeI3kaq7MEcgmSi6SqbC8O6sgOog+oDxK9Sm7BOklXUSqoo SfU4amuGZFJJf+vcKNmDnBkFZiUzyIG7OqkVPKsOirahDJ9Eeqo0N5BDNBW8jTbDeZBvITvjkMO1 im0pySdY5yuQKuLJzggtZg7TpFmFdeDEo2bSk6SaQquQAmeKLMmjnuaRJV1EMc98rGnBcZH00IlZ s5n63kz3OmmvZdju3FHQ7KbW16s+AXSbuhWoXo1r4JQad+J31HivVl0J9FUVtvWq2gZ01fxvUI/q Lxg3P6rEZ9WvYJ29p95H8pspNv4Wrv6c+KFYB/mX0T807nFzCUTtNNaX0RKyedU8+j8U9XNvIwc8 jP26L42mg8Yrlfqbih5GPv9QihD0UpSyi9paj7aRhRNKzBZCNWuh/hvl55FDVjGVAznYI9ii6HmR 6l+pL3g+MGNf5ifUeAJm1K+4+R8C3YBeBcv30ih0Ur2TxmIv1TFaoqXoHUSbaTQHiFZpsilOkH6L Rq2V7v3ZvNiL12geYVwVUAS2Un8HyGONpPMVauWnNO4JRC8RZRRd9yn2KshvFaJPiH8XW+G1RJOk eUfzSFMB9AtiZFJczdAMaiUPz5CFM+oJ4kyQVftoRMKpHk4jglc3kc5UcX5R71Ipnhn7FEXjz8l7 XyQ9++iuAYrVG0RryXLy5PwxioEf4rjgkz7w57dQA8YJC33vnyBu6TTH99Fvm1qRKq9SPPdTPQKp ijJ1NZ0xFKPEH6P6A6rHEJ0kWkz8J1Q30r3i7DhKrdyguku8C3TAXUj5hyTZS5zLIiUZL1kltttE GiqoTmdNFZ0VYEUAqimgqy3kAQa2cHwD/qcxX6F+h3Hv/VYF5425WJWGrj6hyNRgr7UvIiXJbqSK MJGiHkU81fvpahvVH1C9TpWM8kRPiRRbgbmD9Vqkigyk3F3ifI84Brr3VeK8SDk6nVf4jxL97hzM Aj5nvgNHBCnfN4+eaSPaghylHql0qmsnepboFaLiCYvO29Ipj851XDjV7xN9TBzxRE0nPK6KqIPo XaLn6Wo6WfVvxNHSU8VvE31PonjG/hXWuSPEmUbKj9Ndm2mMwujeLqJucYWk+iWqF5FkA40jndG4 m0R9RFdJ7SLdRTSD6A6iryKFeYsa6LdzENsYCcdI83XitxGlqFDWUyviiTZHjD3am2aY/3kBeBbs V+6nux4Rf5a0XSDOBFE6WSkspI3OwsrXVD6499cqOMOpclRHsHXFHeAfVuqBzqp0RN8iDpyClfdI ponod1BSMYo5gLIP9SjXqCrQBryqLCb6BPmqZJIvIk4PUu6XSNUOpConXf0H1X+FqyEks4J0FhAd JpnVSDXXqM5I5k2iHyBrOaKv4wqm+D5ZlaF6FznKFKCrkMP9QLkBPLAN5jSnjFLiLvY2ru3q4wr8 ZvFy5Cj+DOUVp5RKuDqEq6UyF3utPk56coluR47iAdYhwocpkldgbMz/GttFyj9CPt8tRpFYl/hA uSeYVfEttG7PEWcTjU4dUXqyxCdRnAyRBoGei3uQQgR6gOrn/h2uJs79EmzbQjI78A0MihO0nr/J 7Li2E38lUQNp2Mn+DupRqIF/ODcE9U6sc5nzsaAnkSQ7iWZQK0dJWy0+ZefmiE/fJM0X8riP9+CT AG6E+x8YpRyszHw8h0+8H/GQObA73Gfg6m/xKpvBb0Lmejn8XW8yj63/A8Oc4bvcf2Ds8biSryLK ePAJS+XzQcbGXQX6Ux6yF17PfROjHWYVx6/hfgA0m/8gcBQcjDi/gXuAHA6sZb/kcLe1c2W4eig+ Cza/zr0OV/O5N0gP3msmSzZwP8WZzmEWOgerMqeAZRbqj9Fm7j+4AdSPv+/mP8PDbsX/BJ+a8O+S /a/zPwL6SR77Xo7vS+V/zn8P5Ov470P9Df67uOYrQEYRjk8n+P/Og//52/xfA92p+AzVYY/jqxRf wJnOfxn7y4PNfBfk9hz/3xRb4d56HvrCf4w88BGuGKOX/xtctTicayrF58hjoE25VfFxXH8U/xfq f4vfR63UY119F/YciG0F3Kv5MNa5YZJJUECPlJ+guktxGNp6DS1RvKc4CPRfFf8G9JDiJnFwDn5c gf7/Psrzc3RXsgLWBPV6qh9AqlIgVcQQ538pfkAW4oyOUByhOtICtBOsxX38uyjJ9Sp+Q5qBKkvo apUCMjHlfyE96aTzhArGTvlRxZdw3sGujivM16Geq+rCOkm+psBYrVD8O/Ud4oF7R3UWLJwjDxTT XR/DPir/EmUUPlolvoZ87rZqO64V5LEvkTYjyfRTvUYVQusPnDtUK5RfoNbfoNUGqKpQ+VvMLrCu 2Ev8OZUbLFFgXX2IZF5UQjalbMRdW5WjPAH1f8S68hhmpMpfiXqIrkYKqxzqmSSOiuo9SLkMVQPl 2xDVXIoan0lOq2Hs2DXKSKfVNSSDu3auOglouioFOZTNMszV539OWfd2zHK5VZR3rVJvA04C8ROk zByz91TMkCE3fkK5sYM49ykr/t/IJ8nt2CJ7BSlwBqiVMcqNxQz50+CTZjwpsHc0YRi3mm6qE8Vs VtGsaSOqJYoZy1tI1U/UcGZV/k8NRBHXqSxnnPbL6l7g/0QNM0t5QwNRyo0rd8MpNFwBGYW2DK1V PcSrkDFewZyfwbgrBue/gb6aP4S7/Fws0U3Av4PZo2JmLh10Vs7D+qCMpzzTh2940Z5AeXXNvAv4 W+b/ijIEOAGFqPFezdo5mI/KX8+9S5r/DltUYTzvEk8E1Pf3sO8wLtuII56VkmlESnF0VHH4BBNH BHK5ozSam+mcgp4PRUkYEXwLc5Q4IiQZhTEAMpgfpmrwKXUU+TYKxxfGaIDOVmPE2YcydH5JkKya Rqq1ItVEAP+yZpLqZ5BC7oynQpEzSWPXTxw91SupjpHGSEMd9o7zURz6qF6qmYN8Rg1ZFe7EmGk3 006RTXlIKGU4PyRKeYj0HF58ei4+fz9NVylTYteIniT6DlHKkPmXqP4e0Wmiv5J2K6QHKacSaT9R yvMhL0JKGsDvSMUMqkyqw9jB+AFVUzaloX1TSbmThvZiNe19ysNEJ1FSeU/i4L2DuFNA3oXZAtnP 38A9hb+GVGFAOidIbTVSW42kp5E0NJKGu6QBtM3rxdwMclg4i5HlWaSzRcoEGD3/ZrSPI71IMnRm Ac1kP+YVylmiXqJjSPlrUiaA8odFb8/ByM49wLxxPoJoFmWSeqzDPZgbHxIzTHxCwgYliudxBict br5evMrR+ZqjcxzymY4ooydHjPSkQj6OV3GVGCT5QpRnVyRJK0UCnk+jUWaeRmd+FnJqbv4e3cWI HiCZVKqn41WgA6QNqVPMsUlnO7XymOhp4gxii/N0ppu/jPz5q9SLYeKPiVZJZ4c4OonEESeZsu5C OqEU4l0kU0gaLpO1w2LrxLknekP5L3hCoaclGTS736N5dBtnJZyytf+PvS+Pr+nq+t/37LPOvbnn ioiI8ETElJpdaqaKoqaExtBU8RhTNKZQVTVGTEG0pKSqEaqoqaaKGlrU0KYRoWmoEqpaY1WJIVTy 7vU9p/fxvOPv/eP3/j6/z+ft83m+Z92111l77bXXXvvsfXYOfp5hVJJ7kNVZ5goy6kmM3DvWuCNe 7Z5zbmM9nA/FHVccODxyQ7BCD7P2r5xpQF47hxjsGcGZ0NEf/HfwtJmB/ajzoM9jjT8Gewi5wN3g 72a+6nGDaWuPBfl5AfLYO6jxIvgXEVeIN7VaH4N9AFVvkfXU+iJi9WfgNHCw3nHUwU5XAOjfrfjB mrEvYvivN2D8TucF0C8De6DXsGbnMwcKywIrQc8MlGZbT85qdDqKwhmfnAWmGFaPXII/EZPqqZk5 2cCuHMlWqRr3qt9tSTewOuRboxSzm87PgfVYRquH3ch6vKen+Ft5ZEFDkK6eKIpvMqq1s4p8bR2f sNXWMe3ooQdgt0Q9gT+5zFg0CXSaKxF1ZQGHIeumgC4AHQqMQx72gF7PtRtbgBgjvNOiSoNBR4HG rovzMttma4Y3eK9Gte4RW8j9q60zorGHwHgX8dmDZwEttBhnjYoxFxT3BqK9xZgRiuETNSZUfKp1 Oa+IeX8y9Mll5jM6GjJq08FpWcz/IuoKO4Ox9zbx+kitnrJ5rY01VCI4DYEdsW66bJXyeFRrLpZZ zagHQCYRMl5LkmUcLaycWZSIlRff2xN7m0exFkuydaIXgDHQmQucBpk43FUADYOtWYZpozXuXV+U in0kfibEXVoa1nGTgdFFb/Ozn5XJUZqk5iVlOWyIYdSHqlmRd4RUjMlWTKs1u8l2Qj6G5VXtyfzE C04K7r1sa0uGPWPQFrZzGDREQUMI8CLaEo4VXDtGqfFdyg+TcC+8AT2xsC2lKJP1F22CzCbsLZRE G1nbMI4BLQe1D4ZtLaAhh2lqY9nMlqjIXsoZA/0SDP4ga11styiVEfwc1J5q60zGfl0Y8kAYsgrL D4O1HYE1Yed20Kt5N1gGF10C5zdoHo9Z0gS9C6jWStpGyFwA5jBf9UIW71cI/hu9K4wqcixtp5lm SUVngbY4B8FJQr+kI8aCsf9jgq6EPUPuzTt8IlEh69wES1pAJonvUn3xGyJnIz8jocZuiFIX7B9W LCFzCTJZwN/Qaxvhh0ugTwMhj/W7xlbJTDuWgJDJRGlD1NIQ2o6iFQ1h/1HY05FLVfzcQ79PA/Ju QE+rXXyXioQs0BtBbwR9EGPwOnr8Hvy5C57ZCHoj+vceOAeBPdAX/VF7Empnm1ejdD2sWs31Kro/ xuA99NRB+I19hblDD4AHpsGqgqKHiJmNQKuv02EV3/s34DS8LzjGWUvpSQJyG/sDkX+0tyG5gDmO 25hHbuGuLNhzmiNK+Zaf8YLQxkLIL4FX2zFf9mPNjoXYl27N8o5f2BJHF/iwFuS9Fs32O44hBg5w /DgWcr0qd3GNy4DzIBkDPdZeUAr4v1gtKnoPeYnpdcAKkGyISJuM3r/KqDeBV6+D4w/J5qgrXKj1 tRYJzgbgT3ZPdUSW4HyCPVhHSNFItQ7CvrqrBJ4qK+BJOM/KaSwpJ/CYdWLf0lmCafoFGvBUT8XI mR2Rf5KAt1Aaw2hgd91RG08Oa/h5Up/L2VU9hwk8tfLO/5eM+gpGAzvAMg/1Niy+gqzOuJnvVaOA 93ywXyrraH48sljSWQe1fAf+QOBM4Dw8FX8Ie6oC18OSrbirEUp3gLMPNW63PAN7UKrFgd8fmMi1 K++xJdeKjvBeCqOGZxtHEeiWyHufFb2Ce1kGu9b6eGtu4qdfNX5VvjWyWCdtQC2ByI1TINkFllu7 uEnUhBHvCObxqlybRypj0yRnoMIpwJcZjZKM+k3gWvDvg1+BUeaD7wB/MegURmc1yNQE1kBpW+AJ YClI/gr6GjCW0dUMdD+UPgZmguMPuiloP9AHUDtso4qM2gjgFZSegg2rQN+G5ETQYaB7gEapExw9 D/gBsBF0TnI1ZPuBNRjpGqPzmuUNpmU+SutbNkMG7XVOg8w98DugXV3AvwT+Lti5xfID36U/xr33 GdVTFjwPjrD8j1qSLN+i3htoheW9E9DwK7AAtcwCvx7wttVT0FYRetqAXwY2oKcoBDJ7QeugW4GG P40c0MHQ/CMQviX0vus9yGwDSmAkSj+DtZfBqQ5ELNE58MeBsxK0F9gApZbHAsCZiTamAZcBo1EK SQPxaSBWjSiUInJ09DL1B8YAg8C36hoLzhLQ53HXMeAfaMswIKLL7zA0fwL5M2g1anGuBr8r+LhX 7wRMAL8JZAKtSEaPZAIPAG/D/3uBkeiRKeCvRZ+il7UR4C8G/xTirRo4bcEJAx0LSUSC+zQQo8n1 C/AIbMhAK+6CcxIctNeJGKYQ616U7kNbWqMV8DZh3NFgtGgH+PChgX7XMZadm0HvhvcKoScenEdA jEf9IKNjUfFIzDhleEzx0ztNAb7MaJRk1G8C14J/H/wKjDIffAf4i0GnMDqrQaYmsAZK2wJPAEtB 8lfQ14CxjK5moPuh9DEwExx/0E1B+4E+gNphG1XEumME8ApKT8GGVaBvQ3Ii6DDQPUCj1AmOngf8 ANgIfFhl1Id+tMI5DaX3wOkAa7uAfwn8Xah9C0qxGjKSUNcNIFqqF0B+FmTqAWGb0QZ0GWiA9ygE /L2gddCtQKONRg7oYGj7EYj2EnrE9R5ktgElMBKln8GGy+BUB6J/6Rz448BZCdoLbIBSq70B4MxE W9KAy4DRKIWkgZgxED9GFErRmzo8T/2BMcAg8K26xoKzBPR53HUM+AfaMgyIHvc7DM2fQP4MWo1a nKvB7wo+7tU7ARPAbwKZQEb3aSBiz/UL8AhKM6D/LjgnwYElrn3Q2Rra0GpCTNJgaN4BPtpiwP86 4ty5GfRutKIQeuLBeQRErOoH0dfDeA9Zi+GzImouy0e2ycfMko85JR+zWD7yTz5mn3zMFPmY1/A+ FPzFoFMYVS7Kx5yYjzkxH3kpH3NQPuayfMxE+Zgr85Gp8pEJ8zE/5mOmy0dWZI4/6Kag/UAfQO2w Tc1W+ciHjFdQego2rAJ9G5ITQYeB7gEapU5w9DzgB8BG4MMqoz70oxXOaSi9B04HWNsF/Evg70Lt WxiFgAzQSEKNN4Bor16Au2ZBph4QFhptQJeBHvhQ5d58zAJM66BbgUZLjRzQwdD2IxCtJvSL6z3I bANKYCRKP4MNl8GpDkQv0znwx4GzErQX2AClVqsDwJmJtqQBlwGjUQpJA5FjIIqMKJSiT3X4n/oD Y4BB4Ft1jQVnCejzuOsY8A+0ZRgQ/e53GJo/gfwZtBq1OFeD3xV83Kt3AiaA3wQygYxqHmREBLp+ AR5BaQb03wXnJDiwxLUPOltDG1pNiEwaDM07wEdbDPhfR7Q7N4PejVYUQk88OI+AiFj9IGPxqzz6 igfglF0GzswE49xLGvAoo+M6aBdKNetEDehk0HHAh4x6edBJwObUBvz5CqeD7gc6DnQ70EmgU5h2 NAZuYZS5Fh+4HRhq3cXo6Ix7o5iWqeBPAAYCM7BPmMYnhWQw3rIFg/OQUR8A2zJwjgj7w1oc6BQu dVxn2nGdaRkM/kNgc2M3MB6YhVbvBsbzWphpZb+F8WiRhbvhSXgAnHbg7AO9nlHfCr8ZsHwfbGiM d2f9rTNOqD3UOq0EOpA1yJqgk3DidDo4GjgxoD2ocQ84g3DvZauNwAmwYQJa2hheCgc/Dfyjdo27 0e/MmW7di1YnOTNQGs/7GIiBaPvUVjfWAD/H8V6usg12gpMEeY/tW/Z5IOj+sC2FuqN3cjh+YE8q 6t0OmYuoZYx1potPvKj2cusu22fA5qN2xBLODcbYMQzLeddXNgQnE/L7EF01Lf2I7cbgR0HmDuhb VovQI+sh+RCYA5lNdin30SGcDYsABgLb2Zw2eJvQBlapGsUNyGeBnwVrA4G3YE8mJNMQz63ss2fz EWlA6AyFhp6gB1n6MV4OoRVbYNs86IkC/yJwtuUf+op3FZimc4z6CubIXHC6M01B4JeHPam4KwIt 9QLPQvNZrl0vzzGgZKx4PokeP4nez4E/0afAfejrfZD3IHLOQttr0H8UnHYobQU6zvIJ047aVv+C bgyZZMRGLmuWyeDkGiMxujNQ40j06UngSETpSFg4Em9wkD0QyXHQ2Rl3RSEyUyE5AdpS+Y2Dsoqx OSQvAgtYgyuWNbg0fu9j5AF3s53GZPg/n9GJyHQifxprbB+eRJY4iVowlhn1w2hFR8sq2Lmc+a5Y Sw/XaOTB8ubQUIQRUQCsDT1nLQ7o6ZApQIRkoHXN0a59iJbGPEJlHvrX0plhXMFIuYJ7Q2AD032N efyuCjKJOJH7J5941yZSc35eMu4rzgmmVaZqzm0BbgKWB38LYrUAERJnVFa1RBjHoM1qS2XkcN6Z nIKYj6E+ii5JLRQOID5REMZvmlQ01kaGrM3zOzAInBXAxeAkAJcyqn5kegOjsQUy2eC4GV2tQC+A 5FXo78qtlrtAr8AZjPL8nksmgj7M78vUfBGCWApBhgyBzhD0C9811UJ+C6bkD3N+4LvU/BWEllp6 zqjebI5Tsl05ZvRsfm9F5/itE3VgDu1kdO6DzV25VN9qlTIqmjkrLGRJmcm0yml5kGFtCcAgrpEW QLI8st9VRr08Z05Vuz9sPocx4o/4Z9yO0q1WKfCwhcx3utgn+la0dA8k93ApCT6TqTLJUuXbYLbc GcNtVB7OQ75i+cWoKwntMnBXAt6upvL7O2oAO7uijSs4WlQvs8cWM1+bzm/01Pg9BM+jZ9HqTWhX PjAXOt2QjwF9zu73Q+xz3CWAHXiWUW3MQy2HEAMbwDkE34bCSxsQUXloO9NLYeEAPiVOp6B5AOo9 gBr3gU5FeydYNHarQq1ohEwaPJmN81RBaHWCM4KjkUuVhf6INyvC/dnbtrVc+0ToybRGAXVgX8Hn UxHhayA5kf1P3SFz2BodfIJdn2uPF6XTuI7eSWEblLUh8FVtzODMR+844WEjnmNY1cW13Gc0cAbe 8Me9u/AXBxPAb23Zibsm2+POHxZyv2cj2rcyyl2gL1n2IJbKW2ME4+sSo5r7gvhsJ+wfDw1n4LEO oAcgiqJw3jUaIwsjRc3LtTF/BXHsAV3WWAbe53qNeGiuzfXSTrZczbDcFmQDGWvVDkvmQqYB7g1A aTjqzQFasdQH9yZCZ2vQB6wxa/U4ImoALP8CI+W+Lb+Bkd+8G5WRi2LZNpcHFvaE/5vD/ghr1Bg6 Ik3neGaOyl15kNmA+bc5cogLYwFexdhfgIwRhOhdjCyRiGhfCs4AG2vjSYZnri18l5rF/JEtMaOx zcYW2L/BylTQswme34S25ILORY1uRH5zG/0xXlywk9t+E5LhluV41t2D2fYqR5SMhebViIc98F4+ 63fvZM1+N1mb6wAw1sotjH7I+a5J8PlUZIOrGGVnrdjjfnRuR1sKYENTjK9olnenQwP+fsGVC4y1 sjePR5UBIpBXI+DPCHiYOX9atiGGB1ietzIq7L/KtaiMxznkDMbCVcwOV3lGUPUuU/wb6IU21Bke Uxz5kxGGjMdP/gFsM/npCbxSI34quI1WvI+5CZGpcinXux6SMYjVrciTjTCOsihX0QcokqPO4NN9 H+p8LrQ68Qx7xZjJ6z5k5rOwai/Ps3ovnbOrFye6BZ9WUhiGsw3ZONvAc/d0/rs6LQNvtDVgML+H kh68qTkKTk3mOK6D48JbqgngJ+NswDvg7APG2WfCr7D3QG8HNkfpdGA/W5Ixic9raSnQ0xi4BZzt wHZ2vVcgwxgFbe24VAYz6gNsm9mH05njaG2fXuBW5Np1beXnTMhvhW0GNPeHZCgkaxbf5FZAs4a7 Ymw/MD0ImIETAs2BacA44ASrFtR+HZaHwqpoy3vgNwY/0KrXqsVqO3ACMAl6joJ+iLsu8tteGQs9 mcAxwDs4K7LVrqU3P2FCvgB4yDqNAPs32acvLD7rj7B6wT47wXVFMYob8H8W5G/BwkzLhzjJ0AqW 74Z8czsSrP5lmXmgA+GNQLZH0VzjbPCnQ/NF5hj+TNM5m+7NY8Q6qcIc6s7aKAg9Vd62ljWcteoF ZsA2D+h+wLOo9zXQaXZpMt7G9kW/J8P/3IpkO3KYDrd6ysZk9F0y1wuZVMufaPVFRhd6wYUxYuQB dzPfmAz5fEbnZeY4YYOxBpq9iLfDaGNHK5agebktz56pbbXROvODtjwEJhXdgSfvYHSwn/MstPxQ PBuRPxkenow4nw351TyOoC2R34M7/gQ9kWm6hhpPgLMJ9jzEu/J+kOwJOgV0Y0bVL9ab9I6Ik46I 1Y6opSN6pCMifzX3FDAUnPKWBoypNLxHjoDNifYYYckp8AlGmVYS9gxgurg7n7lVmcot0hwbBA2M HzhIhA9+Kz5O9Bw2dFC86B83cPwoETd+2MDhYi6fNuoV3S5c5TVRXCyc6j4/YYpSorQowb8Uj08k 8neJS4pAEST81W/+SywuET5Kw7/6qnRFd4sM568LKh5O5aFMFwE+SYcgUWbw4JFjxHTgbOACYAow Dbh+SNzw18T22OGjBordwC+Gjxo+XhwGZg4fNzpO5ADzlOBAcQ54KW704DhxFXhr5NAhw0UB8FG8 KnYIoIFTgk4faqpFfupqnSHU/hWlK3utO/B3M8LzFJZ4Cs2nMOApdD91PtH/KSxpY7CoKxqLVqKD iBK9RX8RK0aJCWKqmC2SxVKRJtaKLWKX+EIcFdkiTxh86FVshTf5nAeuRjr62+FqLQz+uxpXb9ju cMVblrumKjmHuu6xrn7+iq+u7hxG4TD55KOfuna3r0Osa8AG6xrUVN2nrmWPWveH3LSu5dopG5T+ cj1V7PF1mGVHuXi7PNFut3rexxckhaL4+0pdRaQQrh2uHfj1P/aNdBqh+jLAUVlrKDvoMSJUNBdt RWcRLfqIQWKEiBeTRIIaEe+IVJEu1isv/8Pv+eKyuCkKxJ8O3eFRXSr97vs9cDtwfejWcC10S1wf uXV1feB33024PnAbuD50O3EtdLtwfeT2E5oqdatfD5W0iesDtwfXh+4SuBa6/XF95C6ppB+6A9Sv QiVdCtcH7kBcH7pL41roDsL1kbuMki50B6tfj5R0WVwfuENwfeguh2uhuzyuj9x/U9KP/pVH+N/R myim/x95JBQtv++uYHsmzPZMRdsz4bZnKql67rsr2/6pYvulqu2XarZfImyPPGN7pLrtkRq2R2ra HqkFj9S2PVLH9khd2yP1bI94bY/Uh0ca2B551vZIQ9sjjWyPNLY90uS/8Mi/HZv/7JGmtkea2R5p bnukhe2RlrZHnoNHWtkeed6OmNa2Z9rYnmlre+YFREw72z/tbf90sP3you2XjrZHOtke6Wx7pIvt ka62RyLhkSjbI91sj3S3PfKS7ZFo2yM9/hseOSyyRK44h+8V3RGPHJrD7e5pe6SX7ZHetkdetj0S Y3vkFXikj+2RV22P9LU90s/2SH/bI3+HRwbYHhloe2SQHTGDbc8MsT0zFBETa/vnNds/w2z/DLf9 Mppb6h5h++V12y9xtl9G2n4ZZfnlv+2Rmz6PjLE9Mtb2SLztkXG2R8bbHnkDHplge+RN2yMTbY+8 ZXtkku2Rt+GRybZHptgemWp7ZJrtkem2R2bAIwm2R2baHkm0PTLLjpjZtmfmIGLm2p6ZZ3smyfbM fMsz/K1nthtz1GI1B3jEKH7lqrJ/qIgQXuWvdmq2i/Goecm5wrlB6+qZZlORnumgNireDJuK9CQo Kg1yM20q0pMIiuVm2VQkvj5YVc2nTVV/dFWz6QCV1ceruXSuZ7avpjm+mub6aprnqynJV9N8X00L fDUt/Ksmz1JFpTtXKN4ym4r0pIJKU7z3beo/syjZZ9Ein0Xv+Cx612fRYp9FS3wWpfgses9n0XKf RR/4LFrhs+hDn0VqrnLUddRVXfM1/22u46TjJGZhf6HrtfTa/K/n4Hch/129o6IjnO/wzeLlMYuX 5qcjvbX+wtNf9VYa+Dszmj5ZH8qzvx6L73KGin98bToI8vwdcfHf+NJ4B/U04S9C1BNEbfVLly8K TXsAqpOP6gxKqvr9RRAk7qC0ACX38NXKO9odVW2BxudbH0Da4Vghyv3bvhGrxSY1Zg+Is+IyPyY5 ghxhjuqOBo6Wjg6O7iqiVY3qGUnDl8p0c6iPiv2L0o4rKhVUto864aNyfNRJULbd2in+pf3M3/TW DgrNsxcy3/mkc33U9/90Xx7uO6RwofaVwvcgc/opmWDtMLQeUX5IVdczPk0/+KizPupHH3XOR533 Ufk+6oKPugjKqforRISrMc7PtC21b1RtH6r6vkGtH2rH8L3wTPUrTf3OBDdN+1px07SffLougdKE U0vW3lE9lq6tVZLrtU3CrW3RtoiS2lZtmwjQdmg7RaC2S9uj4koiooJUbuFvK3KslbG/ab5KFWzU NiqdO5W81Pbz18Q5wrUUfHmJv1nN8a6ezQRh1aSeSrTl2nJRQVuhrRBhSseXoiK+p/Q8vqfUGt+d ls57zgKNVzdSonrplvyXGx7pgT4lIa/JJ3IJ/9Lz9DwV6T/wX/0KzdFHbJBNZLgMlqEyTFaXtWVd 2UA2lgkyUc6Wc2WSTJbvyBS5VC6XaXK1XCs3yE1yi9wqt8tdco/8Qh6SR2WmzJanZJ48K/PlJfmr vC5vylvytrwji/Xj+kn9O/17/ZyeL6vqhfpj/YleTA6SROQkk0pSaSpLf6OKVIWeoVpUj56lJtSM WtBz9Dy1oReoPb1InagLRVI3eol60Mv0Kv2dBtNrNJxG0lh6g96iKTSNZlAizaOF9C69R+/Th7SK PqZPaDNto8/oc9pPX9JXdIS+oW/pOJ2gk/QdfU+n6Qf6kS7QT/QzPaIiQzNcfjvMnmZvM8ZcZX5s fmJuNreZn5mfm/vNg+YR85j5jfmtecL8zjxt/mheMH82r5g3zN/Nu+YD87FZrFzu9Ph5+F8vWC9d 0qX6oqKsqPqiiqwiNFlNqudIWUvWEoasI+sIp6wv6wuXbCQbCT85Q84QbjlTzhSmnCVnCY+cI+eI EnKenCf85UK5UJSUi+QiESCXqL4sJd+T74lA+b58X5SWH8oPVbZZJVeJMvJj+bEIlp/IT0RZuVFu FCFys9wsyslP5aeivNwmt4m/yc/kZyJUfi4/FxXkfrlfhMmD8qCoKI/IIyJcfiO/EZXkcXlcVJYn 5UlRRX4vvxdV5Q/yB1FNnpfnRYT8Sf4knpG/yF9EdRVd10QNeUPeEDXlb/I3UUv+Ln8XteUf8g9R R0XeE1FXz9KzRD09R88RXv2UfkrU13P1XNFA/1H/UTyrn9fPi4Z6gV4gGukP9Yeisf5IfySa6H/q f4qmepFeJJoRD4rmpJEmWpBOumhJBhniOXKTW7Qif/IXz1MgBYrWFEzBog2Vp/KiLYVRmHiBKlNl 0Y4iKEK0p5pUU3SgulRXvEgNqIHoSI2psehETamp6EzNqbnoQi2ppehKraiViKTW1FpEUVtqK7pR O2onulMH6iBeoo7UUURTZ+oselBX6ip6UhRFiV7UnbqL3hRN0eJl6k29RQz1oT7iFepP/UUfGkSD xKsUS7GiLw2jYaIfxVGc6E9jaIz4O42n8WIATaSJYiBNpsliEE2lqWIwTafpYoiK70QxlObSXBFL C2iBeI3eoXfEMEqhFDGcUilVjKAVtEK8TumULuJoDa0RI2k9rRejaBNtEqNpK20VY2gn7RRjaTft FvG0j/aJcfQFfSHG0yE6JN6gw3RYTKCv6WvxJmVSpphIWZQl3qJsyhaTKIdyxNt0ik6JyZRLuWIK 5VGemEpn6IyYRmfprJhO+ZQvZtBFuigS6BJdEjOpkApFIj2hJ2KW4TAcYrbhNJxijt92v+1irtnD 7CHmmb3MXiLJfMV8Rcw30810scBcY64RC8315nqRbG4yN4lF5lZzq3jH3GnuFO+au83dYrG5z9wn lpgHzAMixTxsHhbvmUfNo2Kp+bX5tVhmZpqZItXMNrPF++Yp85RYbuaZeeID86x5Vqww88188aF5 ybwk0sxfzV/FSvO6eV2km7fMW2KVece8I1ab98374iPzkflIrDGLzCLxsUfzaGKtx/AYYp3H5XGJ 9R63Woh/gu+kjpOVZFlZShqyhqwnn9XXy/nyXblMfiBXyo/kOrlDZsi98ks12o7Ib+UJ+Z08LX+U F+TP8gqPH3XnXT1bXtFPKw3zyUUeCqAgCqFQCqeqVJ1qk5caUk+Kob40gIaoOBpBoyieJtAkpass JdBsSqJkWkxLaTml0WpaSxtoC22nXbRHz6YDshIdpXPkUdfHVGxISjZfNleba80N5hZzu7nL3GN+ YR4ys8wcM9c8Y54zL5qXzavmTfO2WWA+NP/0CI/u4XllLDKbQGZzILNpyGmEnGYgpzmRu1zIWn7I V27kKxP5yoN8VQL5yh95qSTyUgDyUinkpUDkpdLIS0HIS2WQl4KRl8oiL4UgL5VDXiqPvPQ35KVQ 5KUKyEthyEgVkZHCkYsqIf9UxnxYBZmnKrJKNWSVCGSVZ5BVqiOr1EBWqYmsUgtZpTaySh1klbrI KvWQVbzIKvWRARogAzyLDNAQGaARMkBjZIAmyABNkQGaIQM0RwZogQzQEhngOWSAVsgAzyMDtEYG aIMM0BYZ4AVkgHbIAO2RATogA7yIDNARGaATMkBnZIAuyABdkQEikQGikAG6IQN0RwZ4CWM5GqO4 B0ZxT4ziXhjFvTGKX8b4jcGYfQVjtg/G7KsYs30xZvthzPbHmP07xuwAjNmBGLODMEIHY4QOwQgd ihEaixH6GkboMIzQ4RihIzBCX8cIjcMIHYkROgojdDRG6BiM0LEYlfH2qKwsg6RTlpM1pVc2lAVy gVwsU+UKmS7XyPVyp9wt98kD8rD8WmbJHJkrz8hz8qK8LK+qJ5mb6s4C/YS8qp9RGuaTH5WgUlSG ylEFqkTVqAbVofrUiHrRK9SPBtJQ1bev02gaR2/S20pXEM2kOTSfFtESWkYf0Er6iNbRRvqUdlAG 7dVP0EFZmY6pUVlCjco/DbUcoUVmH/Mjc5250fzU3GFmmHvNL82vzOPmSfN78wfzvPmT+Yt5zfzN /MO8ZxaaTzwOD3lK/O+o/N9R+f/JqHQ4DLUuCVMr3b9WuJkiV+SLq+KO+BP7MyGqtKqoqdZRav0m 1bpZrUkeKEyUhQrnyscKk/12qxVNofNXhY+dVxU+cV5XWPzvaLgPDQ+h4RE0/AkNn0PDFWi4Bg03 oEGt/5w3WQLUbz7qlo/63Ufd9lF/+Kg7PuruX5QnzUetBKWpEXlBXhRCzdFqXajm6U+FrubqHcJQ 83WGcKm5lvAd8c7Yu4oQDfF+K8AcLXS+U17/i9LzsO4fo37dVWu285Dzl9PUekOVWVd5HWtEXkkI rAkc6s4LvBOCHRUX1rzKE2p96xAOLd1aO4rv3dvcW/+dtyVu5afl+vyndmACBOlv8m6JPkl/+6kd FrafVCnvmzTGqlX1vvYtVr5Zvl2Cy/zVcVC/+Khf/6L8Mlj6P11JC9TksN78CFE2Fvs8+K9sf29C 2T6GX83ZHWc/KOFwaukJZbso1ouaw1Hf9PoZVMtfauVJeAca7lqGQ3ckNNEcenoP70ve2k9xQleH TQ8VLfG/bmKQGCdGizgxVIxX/2/F//NWekqZHvR1t0Mtm3x1Psr4ofy04MDY032nzs1LTwis703Q B3gTZNd0qTk0zV13Y6lz3Yv7fvjtgb/urqBMGVO/lreGIXvpZunKL4we81b88NeGjQ+vPrhGeP1m zZqERw4fHD963OjY8eEvjI4fU7d+mDfUEi7zzyWj4weOHz56VP1K3opcLkuH/KM8evTo8eFt3hg/ bHT88PFvecPKlvA28TZtoP57tr63QZ+yJeo3UD8bKab6r4/3LfhKKTFKa7161C/tLcU/XKXdLw8c N2z4qNfGq2oCvP7MdJZ2Rg8dMnL0qCF/Geb+jwyr4q1kGVb+6fIhQ8N7DH9tlNIa3v2FNt4ER2Vv CV8HOhwkZIKjpFB8t5bgcIiMt6bk9dvRvtn6hpvqny2s1qjTmwceV0w71n7s7yc7XM1d8NXrXaMH FbyvfRV5plNcvaqthn6ZXSXD7Jgx7Y3z7fdvWOTf/Ui1WnfSr5SoUvFkm6qPBr1/olz7j5d0rvj+ 8R31Kn/Vuc7k0T+UCWuxoFlAs/P7axTEtqjjaFBc9EzHtZ/FOeaseLxn++BpCYV902ckzkreemd3 ykcnmq7tPqvsM3Oiznvvi+cKjhY+N+OL2b/FNVtXt+H9nXU/dU8Z9O7E2BWp40rM/vTO4bvhn3cL XDj429o/NGhf7tbezktbdO8Rkh370lsbNs/5unerlQnd546ibY0Ovl11f3Tsc+9HZdWa+uyoxBeN k2k5nWdro2aLNQfmXOih8b/d8dGMR94ZD7yllTsrVNM9XrfhUqFL5JTSO2M1cx36jOXeGcumB7ya M+b34fFpVV6aGrQ9Mrn421Xx//PxllBSHBTzW7acW+pkq/uDb15o7S3JNpZ2OIp18kp18VZghr8e rAdlVcieIMa8+ukfZw9HLX+pXd2P2g2+7TW5uKSuq2E0+6mhIzki3t64ZWrniDvZ+6LGr455ZnzN N3bMfrKxa8pEEXkt80bIueFH/FdPvqu9cDRzTtbDHlmHVu7vPfr24HaftBO3ln69/PvQ3ebKciVS Tp8N21xjyu+/rR23aVF+s+TnUkfsazry1NxPqzy5cC1vuN+7c/cX/ST2Nrz7YHJhQGBdulFj6ZK2 r1cfm9F00UVniW/6DTu+f3qb12PX783Ym9ww844MmDzp3qmLbS+8XfTTT5uK7l/4vsSOMXmLf+62 q+nqyXVyn/uxoTmoibZyxogq8+73Hbxoa5+9zU4PWNArsfyz91qkpid4Vv99/o7aGas+/nbj2fBd X3rLzQoPKlFzX3RBm4v9vT8vrj58zsExl+6u25g9vW38BH+VYyapHDPIzjEDHSdaIReWfHockcoz /w9HNSecZirHNGnQoKG3QTNOOPW9z/p+emfM/L9iWwkEjgpdPbJb9+i/xOV/IP5f5p793nmP28ev 7/F62rxuosqBL3IrPLftldZN7457NyHi16WBoscPoQn+LbMr7N3/oO3CZbl/Ni1/+fPCn29+N1B+ mf5d3huRfTt88lv/26cuDX+1/LjrO0IX6sdrtEsf8kq9sNR+o45tDGmWMPTwun0b35hb7vqcZUER O6ZFTFiT27RZ4s87Ir4PKax17dQ3wX16VrqzbOGc2TWKCjrV/nX+Q/35KcePL108u8RYeSmnyNO2 UfHp3c+fT27vnnL/dJfNr96eEF/hzSpT5jU6HNpve3fZ5cWRznX/Uo2Zh0O5t3F8ZowtGrLlZBca sjxjmxkTYiJk61iScpgY2WeMMQoxM9aEyh5CnHJCHUWIrEVElt5X2ZeDjqxRyhLOUJ3U8V7ve13v e52u95+5nvt+5vd7nt/zu+/P73vfVpEpLNQbtFuWpl2058vVujWIKqudVzotDHmAybHrkYE/PfK3 5YtgK0a6Zk0qS0WzTS79k6986MPTiZ/5P7FnEaAtbM+eL1mMOsPs0yiknGYfF2716/nyhit3yLGb 2yfCtZH1jERmpW5yQ2QvVBAQoG6f9oc2/iAG1QQwADoLmaUWruJCJhM1lJQcSR6Knp/3UNGR4KlE dHfd8CoRSQQnX0eyjxLWghF4igwXYPD5DcFg6AFAA0B9tgFIuPynCf38/LabEE/aMhP5m4TapA+c KSSfd+fc2i6CLqULm1/WoLsshVe97VvoDcQmlYQsk0bXniJ/1yCmHBWHlXsXN73tHI0ahxN9OqeH 6wJm5qxVban0Se4XJKYJHtOp/p3RAYfMOHG+q17prP2t+20Fd6ILHVZ71qF5kJyu5dicispaN0sM wn5U3qt5zkROeF6UEhD+a0PE8zty0wUtsJrRzODxtvFQkiVd0EuuMSOxeI9oLSG+99SN2iPut5qm NeNG7irl+/uhT7uBAuhXmbgHHBMNZXQHEiVrIzja+XLs+3yUSeqi642y9VI/mjkbNImI3KyXQbua m+ZO1bF4KJKE5iR6PKUMqDT+g4GZLWSUkRmDPlcZ9An7SB9uN44rZjUg6fxdvXpiNv6ns79l0PfR OuoM+KgDCEBVFbmBHjTD/A5ax9LVE+9DxnkS/1Ot04f0Wvm1UdfIW7Cx1UDLomY5n69cXrmCx+zH xpBpLZVuQ0QcvOSy05CYeWh53ZGOYObFWd+qC49/6bztSnQ+s895vKR0Nuz+05m8VZ6fOY5Lyiq1 Hey2hgpR7nk6eRpZ9vbPDVRnhjymDgYbQ5AJCzUZbNaiLoefdtdQTiqdK5GGFlufcBN2XKcGHpjp hEqboP3IrHZ1J7vCkfK+TbAJUTR7IGXtqoeX/9CU1sXkDG+YvZyZ4CkH5YxnIab7JU+66F0YUArl Nr+7dG9PjMeMdBrvYjP3izDYWzrFR70h0T+7xYFlirkwXKV0MeFEqE6oTViCV6GYvEELIR075DYe LBPr/pE3dDCc8UWktiMO2/+H2uFmYf9UWfCDNyQMaAsoCeOm2sn3VfOPhF98kD5RgNHBNrQDP/w5 gA8C5RTdAbIA+TKqECxI52sl9BcZtQ2gEkx2IeoCzSt2xV7DsYJh0US9mFkfy0ptdmaF9bKjFmHC 0+jLpTnWHAPRJRihjpWC3KbSO0clhAhsrkHuTNmS+tMexZ6BkmX6/wh9E8NVxRqlXjsZ9Ipop5cZ 96yltT+2Zrha7mngVNNt5c6I+82Oj9Q7BCWqKQOY1CIhnwyJyK7iYh7L6LfpdXijVLhMukMUF+Yx L/6MQUXbrRANs8JTNgPAq1dokZHz8z1o2hKvRLQT1ZEFmjSfCsEqBehHlq9DuvFLRgM9TOT4ImYv zparfXBcoMHc7vRdEiiIcEQBS32SctnYwQYLzcqb5wfGnZExbyWT0lsK/SyPajwnHbq79x0DUHkM QMV9lkcsCQqb8oj9+8mjv4Bgg1EohhpSY6BJGbHJKJWPJmLDBGhFf4c82gdIfzRFvbCuRBc8SfyQ hZ64noWpBlIHpaygjkLpKKD10coIaWDvxzUJf70mBYuNRYlb4EkUV0f8v8VbIm2HuK7gUf/uxOm0 1b6IjhXYRd6JPCSch7JmYp5PSZaLPzx009oVMpYQZBLWG+w96wvqrcB6rBAKvF/v7wiMa03YffVa ffnS+6B+3LACIJouo0DRfqmfFHu76zyyq2X2TduJhx9chuadLqaNP+RZyqkK/fD8QiuzZiWYYr6P aTG0VCA8xqHKTlb+QNv11RRbNREzgRpUlyhOW1O9yJqP3y8Rw70MKoz/zQ6Zv6/CUd6Aj2Y14jFx c39iTCQsKAd03U+KNUWOyFQmJ3UpdaA+W/JItfFxFj9LErZQy6k/PpTNpmTtVYQhu3pR0aLKzSDj 7LPBysdlYRn3FoYOZGhP6WO2yqkvQIAnRlZDMJM9CeXn9LmWm98GXV3v+EopbUuM/0YpkX2Ijrj/ iVL6PBN5e1h/pf9YarajFWim4MNvzyKdn8iO2N5/CqIH7T5ZL3Wcp+KX9+4vItZimu9RxIQk370f flJ8Xwe8B3nLAJlEXG5RyYVHl3GUkHnhpUW+w3Lsv10wG0zRTi5V5aFNcPeL9JU7tZmaY4yjVn/o l77dmRQxceTR2Oslnd124Mljkeco/mOEtQjxgvj06NRq+z1Z/IDUUHYQ7rKIrOxDw0sa2JDzMwOd If1m8mqY33V0wHkgTo7554ZCrboxAYVvFGLsZIerYoIv81OKHVb49uUReBx14TYaUZgLB0dL61vi jgnrW7tfbI4zsWYGPVkEDuqZDv4QWbnA/bp/zyBctPjovN+QzEgFO42nT1SjXQ9Bh6YxiJUMAYMB WsR3LNm+KiS/tLqyaA0bp9OnbWNnQnBu7aMxnvvF4kDAgK13+RnU+HMgFMEIdb0ICcE1DK922M98 iH64ncCUZsIBwHnLEE6EDWCdJU+VA5mAXEGOIBKIsNmKcwaRQeKM45DA8BA3f3EMjyvjyuuaDFXq X0Yq+SyRcJqEI7qcFf+GTFA6GETPV5PMfchl92O/vf4tVMoqeiekyYOQEjVz5uZoR1NhM1QzNzov s33vlQfpv/SUj7eSlW49a4vFr8riqcr2yQUJWvMcbjdOsj7yc6/VPg2r4N6pGokkhbL6sFolIh/I pHvZKw4GyxwP6n4/h3Bcv/bOaZr9JbalQdPyBCxY+4a8nutqy+NmqPFCDut99hfGxwqNwxtdFd1i mu0Gy3qDSywOjC03vFxRQE1zcspURY2kBV7qfqVYx9sX98aLetaqTHPwvfgSprRa3X5utLkAyW+O eG40Z77qTQIWlgStOnp2lGiWWBwirbyWMDxnTfQUoz9kDUpuNBzKxaNtS6UGUTQo/BodIgbQIUJf dokFQYdwMlxsf3s4fntEfnVws34Kxyw7QHBrLHJ8afyCGc/88w4zgmuz4YBgFAIIVZQKQ/V/G4q2 /sxqAsKdsXeduxLev8AZ9dJNsN/waSNEJAVeR2GH9U49UBIwTHrHq/OgvHy1MMwwtHasS/iDl2my rwjP9O/3/MqMrIoEL8mgFjjavQSlnvgdS8vU5o0f7LEJg3oHpDkshL/E16W6ra4dxt07Mv9hDZfZ mjYSGnam0GwazC0vwnmdQrvYf+7UpZ8gblpos/pe2A2q8I7YovaxFK6FG1kZ+0nTfTmKL3htQFdo g2qY7FdL6LOPSvqKKsVkPNMrJS/dmczCLBLfZKfWdOYaRlF/mpXUHefnt5xu1+qVD747eyUBFC6W YNGVsXQB543Mg/vUhoycNLM778I2lDJV3uytv9T5SEWyGIFMR+InDvfg1iYeOHd3uCRmWU/BQKA/ AFiwTBkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMjI0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDQyNT4+DQpzdHJlYW0NCnicfZNNb4MwDIbv/Ioct0NFHErSSgippUXqYR9at9O0 AwW3Q1oDSumh/37BptvaTUOC6HFe49fghNlqsbJ1J8JH15Rr7MS2tpXDQ3N0JYoN7mobgBZVXXYD 0bPcF20Q+uT16dDhfmW3TZAkInzym4fOncTNrGo2eBuED65CV9uduHnJ1p7Xx7b9wD3aTsggTUWF W/+iu6K9L/YoQkobrSq/X3enkc/5VjyfWhSKGNhM2VR4aIsSXWF3GCTSX6lIcn+lAdrqan/CWZtt +V44UkdeLaWSaU+QEY1jIpUzTYliQxSzUo+ZxkRmIMPEefGsJ5CKSAP5GSrD2cfZNkhKApCsVoP6 b9sAM5ZReYAlE9kGNWHSRPHwQsM05E2YFkzUIGhuXs+ZuAkf/Ne2icm20axeXNg217bNUDCnEpMp kZFMXN4ooinbNhET2zbc7jxm4nazQal/Gh3/MpqRQ8j4Lxr6AFFMDmh5TZRUOn2j8IzDc78o74y1 Sw7mHMwuOoWrTqOc/3p04aqfx/7YfA17eXTOzzmdLRrwfrRri1/Hr23aPqu/PwHfD/1dDQplbmRz dHJlYW0NCmVuZG9iag0KMTIyNSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4 NTM0OS9MZW5ndGgxIDE4MjgxNj4+DQpzdHJlYW0NCnic7HwJfFNV+vY592Zr0jRJ23RL26QN3UhL gZbSQqGhKzuUEmiBQkvLpiBr2QRBUMQqLgMuuI8LOtYlDSJ1GUXFfUPHZVwHZxx3HHXUURD6Pee+ OVAYx5+zfJ//+X89yXOf57xnuee895z3nmqUccaYExcdm1hZN6rmxbV5U5ly9x2MJa2oKq+cXHH+ d0sZe/ApxiItVeVjK54dMPNpxvZeyZi+f01lVfWHj33NmNLxIGPq5zUTJ9QtaB26ibGnXmH8msia ukC5quZ8z5TWg4xVvzmhLn/g92+/fowx/nvctallUfOShwY9fAVj2QvRfn/LyhWe4NX7X2asYQb6 T567ZN6ib78dF8lYbn/GIpLmNS9fwpKZF/ffivb2eQvXzGWfr9jP2MzVjGXePH9Oc+tn7w7EvTja s6L5MFjvNA5CfgfyfeYvWrF6+3o72irFqF94+pxlZzy75SmM/Sbc33D/wsUtzaUPDnqIsXOTGUsd v6h59ZK0wj6fon0X2nvOaF40J/H2pWcydns2Y9bhSxYvX9HtYlswnvmifMmyOUtOv1vB/AaNxe3s TPhW3zUpsD34yixb6Tcs0cREeuDTdc8JfvbN3ZuPHD56QcRnxnuRjWAKo4R2BnaM8f3mG44cPnxD xGdaTz2S+rWw2DJZE9OzUWinMDvLZ3MYc1yi3ZczVefjl6DUpN+pL0CXqcTqAbZFYSam2PSKouhU RXeQKd1+dkc33ZexcXUeD/NjOpk0BuN1SqaH8eu1++7VR4mZoveoE6PhL7L/60n9iN3xn+pL0f3n +pLJ8Pp/rk9d+j/fl/oBs/079zSmsmE/+14Ps6H/zr160/+epL7KZvyzbXSFbKc6m037mXWbTrrf Edb4c9opS1nGPzuu/5dJ3c8G/Zx6wldS89fYuf/y/W46qZ+dP1bH0Mp29rzf342l+Oc9s+P1e/Sl PHNyv2oaq/05fSh3sbR/5p7/TsJ4d/zcuuq1LP1H7atYjnr9j5f1pt7Um3pTb/r/JylXc/O/2la/ hV3Ou9mFQF9pUxvYVsD3nxnd/8ykDmIX/NJj+E8l/J18+i89hp9K/9PH15t6U2/qTb2pN/Wm3tSb elNv6k29qTf1pt7Um3pTb+pNvem/IqlhJId/0XYYOSjlA6Zj7yKfzTxQ4mdyVpbOilgVG8XGsYls MpvKprEFbAlbydawGzyJnhRPZne31ocVbU6t2cxOZ8vYatRM8CRrNXn3N7j1g92vd3/Q/TdmZHaW In8hwsd3t/ypHJ+C8Kj6/N24EzCygSfPRB2tXsEVbuN2nsRTeTafyKfxRr6QL+ZtfCVfz8/nF/JL +FV8D9/HDPwzrdWXp/6SD3kl/Ls/hf104ifu+3Ncjapf/WRxcpjzw1ypXaeGc63adYV23XDSMP5u zrD1mDVyJ+bN+BP8yZ832l8qqQ3aiuxpmanOUqep0//FDv9Xr2R/TeusmY0zpk9rqA9MrptUO3HC +HFjx4weNbKmuqqyonyEv2z4sNKhQ0qKBxcNyu+Xl5udmdHHm+5OiHXYbVaLOcJkNOh1qsJZbpW3 uskTzGwK6jK9I0fmiby3GYbmHoamoAem6pPrBD1NWjXPyTX9qDn3lJp+quk/XpPbPaWsNC/XU+X1 BJ+v9Hq6+LTaeuhtld4GT/CQpsdpWpepZazIpKWhhacqYX6lJ8ibPFXB6pXz26uaKtFfp8Vc4a2Y Y87LZZ1mC6QFKpjtXdLJs4dzTSjZVUM6FWayitsG1Yyq5tbgxNr6qkpXWlqDZmMVWl9BQ0XQqPXl WSDGzC7wdObua7+wy85mN/kiW72tzTPqg2ozGrWrVe3t5wUdvmCOtzKYs/b9BEx5TjDXW1kV9HnR 2ZhJx2/Ag/oMu9fT/g3D4L2HPjvZ0hy2GDLs3zAhxRSPuwnlUjOMDSPE/NLSxFgu6PKz2cgEN9bW U97DZrtCzJ/vawgqTaJknyxxBkTJRllyvHmTN008qqqm8Hfl/ITgxtmevFx4X/tm4ItyT1DNbJrd Ml9w85x2b2Ul+W1yfdBfCeFvDs+1qrN/Puo3N2ESC4QbauuD+d4lwVhvOVWAwSOewYK6eq1JuFkw tiLImlrCrYL5VZViXJ6q9qZKGqDoy1tbfx8r6D7YWehx7S5ghaxBjCMYV4GHklnVXt86N+hucrVi fc711LvSgv4GuK/BWz+nQTwlrz2YcxC3S9PuqLXC3E6pLSuLmRszTJ56xaU2iKcFg6caF295KQrs eFxaVjzR8lJPPXcxWQ13CdcQ6qR+kFEzKkaKIlU0rRjpSmtIo/QTQ3KFx6TPCJp69GWH4fiY6D7/ cGhUWwwox1M1p7LHAE/qVB8eYLi3Hx+nInwRvjFamMTjHCmL1AzsXNgUdKOZxFNM8ATZRE+9d463 wYs15J9YL+YmfK093zF13jG10+q1px1eJZNPylF5MeWCLA3FMqNUYA1W+1zysWr5Gi1/PDvylOJR stjTbvKOqWsXnXvDHTIPdhAmbcgc1XxBcXQhtmY1opu3utnrsXuq25u7ujfObu/0+9uXVDXNHyL6 8I5qbffW1Ze6tLFOql/vWituFc3G8DGTy/NyEXvKO718a22nn2+tm1Z/n50xz9bJ9SGFKxVN5Q2d fVBWf5+HMb9mVYRVGEXGIzKip0nImLT6rvv8jG3USnWaQcu3dHGm2UzSxllLl0I2u7QpsOnI5tds IuEhJcyHixFuqzyt4vGsa5jf3tQgNheLw6PElwe5dzgLKt7hnVwxRAbN3jnlQYu3XNjLhL2M7AZh N2Jh8DgO54iY1N7kRZzCgqpnLk5LURVderq6uyfXpz3vOtSQhqU2A5hWH4zwIfbrM0ajXo1AE8w1 wY0tzWIcLFAv2hozRrU0YNnKDlFlVDACPUSEe0CNaq2NWI5o1IJngweotd+ITHBjQ7DBJ25av6BB W872IBvpHYLHTn3qM8WN8hvao70Dtb2JrWDOOE9QBMbG6urJ4kIWN2sgJxkjMfIWL4pamjzwto61 1GGpUyw1u8gyByFRlzlHg9kVLmRiWmqGxWoORvRDh/gKbekntqQ+w9jQQIPXcueFK+De9qAFI8rs 4cpwA3gHRaPEWPA9D0MVVR8R3dR2sUne1YgsYtBaT0YUB60Zo5oR/Km9BRZvsWxsEjHCEu5jP1mN YuaR8LuaMbmr+1bvmrQeKS/XK14OYmEy131Y2Kyh/VRDcLovL9d0qtWqmdvbTdYfb0D+MlmPszB6 qvDWYCwUoXq6lHPuiUjgoyE2S7FJirOl2CjFBinOkmK9FOukOFOKtVKskWK1FKukWClFmxQrpFgu xVIplkixWIozpFgkxUIpTpfiNCkWSDFfinlSzJVijhStUrRIMVuKZimapJglxUwpGqWYIcV0KaZJ 0SBFvRRTpZgiRUCKyVLUSTFJilopJkoxQYrxUoyTYqwUY6QYLcUoKUZKUSNFtRRVUlRKUSFFuRQj pPBLUSbFcCmGSVEqxVAphkhRIkWxFIOlKJJikBSFUhRIMVCKAVL0lyJfin5S5EmRK4VPir5S5EiR LUWWFJlSZEjRRwqvFOlSpEnhkcItRaoUKVIkS+GSIkmKRCkSpIiXIk4KpxSxUsRIES2FQwq7FDYp oqSwShEphUUKsxQRUpikMEphkEIvhU4KVQpFCi4FCwveLcUxKY5K8YMUR6Q4LMX3Unwnxd+k+FaK b6T4Woq/SvGVFF9K8YUUf5HicykOSfGZFJ9K8YkUH0vxkRQfSvGBFH+W4n0p/iTFH6V4T4qDUvxB ineleEeKt6V4S4o3pXhDit9L8boUr0nxqhSvSPE7KV6W4iUpDkjxohQvSPG8FM9J8awUz0jxtBRP SfGkFE9I8bgU+6V4TIpHpXhEin1SPCzFQ1L8VooHpXhAivuluE+KLin2SnGvFHukuEeK3VKEpOiU IijF3VLcJcWdUtwhRYcUt0vxGyluk+JWKXZJcYsUN0txkxQ3SvFrKW6Q4noprpPiWimukeJqKa6S YqcUV0pxhRSXS3GZFDuk2C7Fr6S4VIpLpLhYiouk2CbFhVJcIEW7FOdLsVWK86TYIsW5UshjD5fH Hi6PPVwee7g89nB57OHy2MPlsYfLYw+Xxx4ujz1cHnu4PPZweezh8tjD5bGHy2MPl8cevkwKef7h 8vzD5fmHy/MPl+cfLs8/XJ5/uDz/cHn+4fL8w+X5h8vzD5fnHy7PP1yef7g8/3B5/uHy/MPl+YfL 8w+X5x8uzz9cnn+4PP9wef7h8vzD5fmHy/MPl+cfLs8/XJ5/uDz/cHns4fLYw+Wxh8vTDpenHS5P O1yedrg87XB52uHytMPlaYfL0w6v2C0ETs2h1OFunJlDqU7QJsqdHUodAtpIuQ1EZ4VSI0HrKbeO 6EyitURrQikjQKtDKRWgVUQridqobAXllhMtI+PSUEo5aAnRYqIzqMoiooVEp4eSq0CnES0gmk80 j2huKLkSNIdyrUQtRLOJmomaiGYRzaR2jZSbQTSdaBpRA1E90VSiKUQBoslEdUSTiGqJJhJNIBpP NI5oLNEYotEh1yjQKKKRIddoUA1Rdcg1BlQVco0FVRJVEJVT2Qhq5ycqo3bDiYYRlVLNoURDqHkJ UTHRYKIiokHUWSFRAfUykGgAUX/qLJ+oH7XLI8ol8hH1JcohyibKoq4ziTKozz5EXqJ06jqNyEPt 3ESpRClEyUQuoqRQ0nhQIlFCKGkCKJ4ojoxOolgyxhBFEzmozE5kI2MUkZUoksosRGaiCCozERmJ DKHEiSB9KLEWpCNSyahQjhMxjXg30TGtCj9KuR+IjhAdprLvKfcd0d+IviX6JpQwGfR1KKEO9FfK fUX0JdEXVPYXyn1OdIjoMyr7lOgTMn5M9BHRh0QfUJU/U+59yv2Jcn8keo/oIJX9gehdMr5D9DbR W0RvUpU3KPd7otdD8VNBr4Xip4BeJXqFjL8jepnoJaIDVOVFohfI+DzRc0TPEj1DVZ4meoqMTxI9 QfQ40X6ix6jmo5R7hGgf0cNU9hDRb8n4INEDRPcT3UfURTX3Uu5eoj1E9xDtDsWVgUKhuOmgTqIg 0d1EdxHdSXQHUQfR7aE4xGv+G+rlNqJbqWwX0S1ENxPdRHQj0a+JbiC6njq7jnq5lugaKrua6Cqi nURXUoMrKHc50WVEO6hsO/XyK6JLqewSoouJLiLaRnQh1byAcu1E5xNtJTqPaEvI2Qw6N+ScDTqH aHPIORe0iejskDMA2hhyIhjzDSFnEegsovXUfB21O5NobcjZClpDzVcTrSJaSdRGtIJoOXW9jJov JVoScraAFlNnZ1DNRUQLiU4nOo1oAbWbTzSPRjaXms8haqWaLUSziZqJmohmEc2kSTfSyGYQTadJ T6OuG+hG9URTabhT6EYB6mUyUR3RJKLaUKwfNDEUK+4wIRQrlvf4UOxm0LhQbB5oLFUZQzQ6FItz AR9FuZFENWSsDsWeBaoKxZ4HqgzFbgBVhGI3gspD0dWgEUR+ojKi4aFovN/5MMqVhhwNoKFEQ0IO sTRKiIpDjhrQ4JCjHlQUckwDDaKyQqKCkCMXNJBqDgg5xMT6hxxib+YT9aPmeXSHXCIfddaXKIc6 yybKIsokygg5hJf6EHmpz3TqM40681AvbqJUapdClEzkIkoiSgzZG0EJIftMUHzIPgsUR+QkiiWK IYqmBg5qYCejjSiKyEoUSTUtVNNMxggiE5GRyEA19VRTR0aVSCHiRMzfbZvtFjhma3EftbW6f4A+ AhwGvoftO9j+BnwLfAN8Dftfga9Q9iXyXwB/AT4HDsH+GfApyj5B/mPgI+BD4IOoee4/R813vw/8 Cfgj8B5sB8F/AN4F3kH+bfBbwJvAG8Dvrae7X7cOcL8GftW60P2KNdP9O+Bl6JesPvcB4EXgBZQ/ D9tz1kXuZ6GfgX4a+inrae4nrQvcT1jnux+3znPvR9vH0N+jwCOAv3sfrg8DDwG/jVzqfjBymfuB yOXu+yNXuO8DuoC9sN8L7EHZPSjbDVsI6ASCwN2WNe67LGvdd1rWue+wrHd3WM5y3w78BrgNuBXY BdxiyXPfDL4JuBFtfg2+wXK6+3ro66CvBa6Bvhp9XYW+dqKvK2G7ArgcuAzYAWwHfoV2l6K/S8zj 3RebJ7gvMs9zbzPf4r7QfKv7XDXDfY5a7N7Mi92bAhsDZ3dsDGwIrA+c1bE+YFnPLetd68esP3N9 x/q31vujDeZ1gbWBMzvWBtYEVgVWd6wK3K9sYXOVc/2lgZUdbQFdW2zbijb16zbe0cYr23j/Nq6w Nnubp02NXBFYFljesSzAlk1ctnFZcJluaHDZwWUKW8bNXd37di9zpVaD/euWWe3VSwOLA0s6FgfO mLsocBoGuKB4XmB+x7zA3OLWwJyO1kBL8exAc3FTYFZxY2BmR2NgRvG0wPSOaYGG4vrAVNSfUjw5 EOiYHKgrrg1M6qgNTCgeHxgP+7jiMYGxHWMCo4tHBkZ1jAzUFFcHqjB5lmxP9iSrdjGA8ckYCXPx 8v4uv+ug6wuXjrmCrn0uNdqW5E5ScmyJvGJCIl+cuCHx4kTVlvBiguJPyMmttsW/GP+H+L/E62L8 8Tn9qlmcPc4TpzrF3OLGTa7WuKySeMAgba7j4ryZ1TYntzndTqXK7eTMcdDxhUN1Pmx/0a7YbNxm 67Ypfhuq26LcUYq4dEep/qgBg6ttVrdVEZduqxrnt8IiesyKnDi52mZxW5RAmWWCRfFbyiqq/Za8 /tVM5R7OGbeDVJMYBXe6q7Gvd8dxPcf7vHNync83psvEJo0JmiZOD/KtwYw6cfXXTgsatgZZYNr0 +k7OL2ro5ErF5GCs+De2Wv7cbdtYecqYYEpdffCGlIYxwY0QfiG6IVhKZxwrb/DNXN623OdbMROX mctX+LQvcrxN5HzCKL7LVyAvPm1anvl+MlE10KzlSCukccVPt/qfnvgvPYD//tTJxI8MRnQr57BW ZTOwCTgb2AhsAM4C1gPrgDOBtcAaYDWwClgJtAErgOXAUmAJsBg4A1gELAROB04DFgDzgXnAXGAO 0Aq0ALOBZqAJmAXMBBqBGcB0YBrQANQDU4EpQACYDNQBk4BaYCIwARgPjAPGAmOA0cAoYCRQA1QD VUAlUAGUAyMAP1AGDAeGAaXAUGAIUAIUA4OBImAQUAgUAAOBAUB/IB/oB+QBuYAP6AvkANlAFpAJ ZAB9AC+QDqQBHsANpAIpQDLgApKARCABiAfiACcQC8QA0YADsAM2IAqwApGABTADEYAJMAIGQA/o RnTjqgIKwAHGWjls/BhwFPgBOAIcBr4HvgP+BnwLfAN8DfwV+Ar4EvgC+AvwOXAI+Az4FPgE+Bj4 CPgQ+AD4M/A+8Cfgj8B7wEHgD8C7wDvA28BbwJvAG8DvgdeB14BXgVeA3wEvAy8BB4AXgReA54Hn gGeBZ4CngaeAJ4EngMeB/cBjwKPAI8A+4GHgIeC3wIPAA8D9wH1AF7AXuBfYA9wD7AZCQCcQBO4G 7gLuBO4AOoDbgd8AtwG3AruAW4CbgZuAG4FfAzcA1wPXAdcC1wBXA1cBO4ErgSuAy4HLgB3AduBX wKXAJcDFwEXANuBC4AKgHTgf2AqcB2wBzmWtIzZy7H+O/c+x/zn2P8f+59j/HPufY/9z7H+O/c+x /zn2P8f+59j/HPufY/9z7H+O/c+XAYgBHDGAIwZwxACOGMARAzhiAEcM4IgBHDGAIwZwxACOGMAR AzhiAEcM4IgBHDGAIwZwxACOGMARAzhiAEcM4IgBHDGAIwZwxACOGMARAzhiAEcM4Nj/HPufY/9z 7H2Ovc+x9zn2Psfe59j7HHufY+9z7H2Ovf9Lx+H/8tTwSw/gvzwlzJrJmPE6xo5tP+nX1hPZaWw5 24jPFraNbWcPs7fYbLYZaie7ge1iv2FB9gh7mr3+L/76/EfTsTX6RSxS3csMLIax7sPdh47tArr0 UT0s25GL0XlOWLrt3Z+fYvv82PZu+7EuQzQza22tysuw/pUf7T6M9yvy3UUir5wHbdNafGm87tjd x249xQe1bBqbzmawRtbEmjH/VjafLYBnTmcL2SJ2hpY7A2XzcJ2L3CzUQizR9Ilai9kSYBlbwdrY SnyWQC8P50TZUi3fxlbhs5qtYWvZmWwdWx++rtIs61CyVsuvBs5iG/BkzmabNCWZLJvZOexcPLXz 2FZ2/k/mzj+u2tkF7EI854vYxf9Qbzspdwk+l7JfYT3sYJexy9mVWBdXs2tOsV6h2a9i17HrsWZE 2WWwXK8pUfoge4LtYXexu9m9mi9b4DXyiPTLXM2HS+CDdZjh5h4jJv+tOu6tszB3Mbf28ExXw76p R4uVYT+KmptRk3qh5yB6WX+KJy7BHEifmBHlLtPmf8La0ys/ZZX+uKaHZ67WckKdav1H+nJ2LXbg r3EVXhXqRmhS12u6p/2643Vv0PI3sZvZLXgWt2pKMll2Qd/KbsPevp11sDvwOaF7KuK72J3akwuy ThZiu9k9eJL3sr2sS7P/VNmP2XeH7aHjlvvY/ewBrJCH2D5EmkfxkZbfwvZw2Lpfs1H+UfYY8qIW 5Z5gTyJCPcOeZc+xF9njyL2gXZ9C7gB7mf2Ovc6tUC+xj3E9yg7o32dRbARj+vvh52vYTHz0iErL 1ZcRRVRmZCVsHBvPpj/IrHjdx7EhfM8eZ2WlKc/4EF7lCvPgMGBinFf4bTrFujcpqcy7d5Bhm+oY 1cXz7ikzbsMxt+zou0dfyD/67qHokvxDPP+d9959z/7lC46S/IL3XnlvQH/uSHNoiI1SjMZYgze9 nzIoK7OooGDgcGVQYaY3PUrRbIVFg4erBQNTFTVWWoYrIs/Vl3+Ypk44alDO8pZNKdCnJtlirQa9 kpwQnVeaYa+bnlHaL8WoGg2q3mTMHlyePmZhVfqbRkeKMy4l2mSKTolzpjiMR9/SRx3+Sh91pEK3 8MgO1TB0Rlkf9UqzSdEZDF2pCYl9h6aNmmKLsessMXZHnMkY7YjMrpxxdIszWfSR7HRSX0fHMS7+ L+HqOngwl63sTMrq6v5ot52PA3+x2xZmq8bf7o7U+KPdFsGKwx8REeOJ8bAIltTFTX7rxky+L5Mf yOSZmYZE8Q9RrbVZoE7DZFZ2qEx4tHHpMjg1P7qkJD/f/p72hhs4oH+GcFFaeuYgR2FRQRp85NQM jlOkuk5ntpqObo/PyYlX5pqsJr0el2MGHjJZI3S6COjxCjdZzbqaaFe0yZ2l25TlNkW7YqNdDtOx 0yLsyTHRSXbjsQEmh0v8d3B3dB/m9fpY5mQT95bFT4i/O15l4dmz8OxZePYsPHsWnj27H39Pmbv3 7XXycWb7JH2AlZXxfB/NaED/xgz50B3hp+7k9abYtMSE9FhThDMtPjEt1pRkijTq9cZIk+5NqcKj MvjwNErZHX570/AlwxVr//7x+fnmfgkJSeHhJYWHlxQeXlJ4eEnh4SWJh5PaZ0BkpDnBLkZoExdU NJtRy5yAKmYxA9a9z58optOnqNaSEG/NTxjQz+DOrnUHogPanMrKouNLHAWY2yvhyQ10FNiPK0fJ sPyCAkfBSTP28ihVqCzudZxwg9ghqUo8L+DYFppHDD5TrDsxPi3GpBwrUC3OlFhnaqxFOVbDTbGe xARPjDHXNd/Tv09CBF+l51ssSe7MxEU2V0zkCcfNO7LDaDaqOqPZgG2w87h9V98+kUnZrh+mqrtS +yZaImJSnNj+8Kz6JDybzHLY6s4+hrAzDWFnGsLONISdaQg70yCcGe9IEZ5MEZ5MsUda+dgUD8pS xI8GmCOji5t3GwyR3i5u2e2sjRSuCweQVzRnnVjrInB4T3YM1rbOWNhPmEUUUZ/0r7pz9faImLRE sUz6JnFn33ELFo3N2TN0amPu9VePn1fdR93efM0Zpcf6HZ/x7dnpxviyGWumTjitMOro99k1LWIt 2TDj1zHjdDZnb4Ifc0twYAXvu0es6J89fbFQHN379qDMYYju4tm7U8IzHIgl/6U2scd99v2+8OTS TkwuTcY9bfu+rm3RHXIfQIW3sHqOtoH3xyQ7TEeuOz6n2SZHckwMBSoxm2HYGQexX0vZvN2ZpXxg V/d3/gpLJB+bgYGYhMjO5xl2zZLB0xOEyEnnCR4h8gbwvP48rw/P8/LBk/pO8va3qNEpk+Q6xzIv K8MyRuK+RvnJOL6SVakyM4uKeqzkHiouzmDUb9bZk3NS3b7kKN2xL5XDalRSjictN9mmHrvdwB2Z HnefGKPCvZzHqhGxGanJabERKs9ReIpqiPGmpHrtXJ8Z5RDRzBGlvvRDvtS6jvikKJ1qirIc2a8b YrGZdDqTzXLkCd1QM7Q+KileeGgoIvkOPO8cltSZ7ujimbtdtZEIwVmdehGCB+LbI9qKJzOY93hG cU4RbY0cSt2BhxVxVJfkUc3RViVwNGSOEiOJMisHXG6d2RF19C5ltSN6ZAwircebYY1LdDvVXYis 0bF4xbg9WfbEpNTYH2ami/8ieUb3IbVMfYYVMD8L+j22cnd5frlqiYgvjMRKKxSRqVAEpUK7zc7H Fnbxv/mjWFaWjfFIJnYcGyIWJ6oOEYvSGmYL8T2izZAuxeSPdcQ/zgrthcrQfYWcFfLCwn4j+nZx l992IJ2np+tSPuk3etjbkeN0LF++jw45tLfSzEZsVW2P7vfNbCwJv5sGlgzoPxORzYDXfCb8ZTAc f5EXDBIb9vjLfrhOC2lGYXHGxhUMLBqsltmTXUnuqKGX1tYsr80bvuK2BeviBowvGdY8akCkKTJC Z3SVT5lb2Lx1cubN2ypby90NE0csHpYQGYk4EjmtrDqjeu6IsUtGZ1QXThzkSvGmmOyJtsSUJG9K TG7grMn74/PKcqrryivh3Z3w7qv6pawvG8bO3YMXkTmtKLyJi8KbuijsL5HX/FXUxb/zu5y+aFTy eVDDJ/zvEzHOJzzu61LM/gjmNBcNStPp+3dx/b2Zo13V9rElkJ36ceKFLmJcfIkMcb4TPmvk4QiQ 5fy796CDNo0x7D6jIy5OC3qvFrRc0ugbVV2dhTe2E2vIYIzxJCR6ok3ZY0aOzJ59wdTsu5yFU/ye 4f6qrMp1FcPrByfyD9seOKfakTkk5wwEDZ0OQUNfbIoUeyPSdPTPOcVe+/jNwbaqTa3DovuWDzy2 s25qacuZ2CfT4DGP+jQbxM7vTBYRMfzOPxh+1390j3gp/shR6POTj0Ddn9DRSLH4rflRPCrxQ7ff bB3p7tPFlXtiRqufDhDRNsI6ckBuFzd0RsBtR1/xHdIuPL+R/Lb/+CHI0OOcaHDS4dKbDpWqCB9p p0mPojcmlo6pz2++fM6gEUt3NvhqKwclRBiUaKstqzQwZNWGNH9jacmUMl+keDXe6Eh0WBMzUqL9 Z+5uO/fhtUPtSekJUTEJ0VnutOy0vXdN3Vzv6+PzmmJSxD5tgl+uwd/4mThJX+B3lw3lFleJ2J0l 4txQYreLCzxRIhZLyQP8e/wVnk9eyw87Kz/srPzwjs0POytfLChzTFq1pSTLpYvqK/6VecJobHXd 7qhx+rHidaItp7LwPvSFV5W2no4fLnpuwYFx8cdXlZqZSVuPPDVYvcboSI4Vh92andNbLpyaPXD2 pbMmbPYbY91iTUXsqlhfWYYVhBU1Im2YvzorUS6gVeOmjNvcOXvFA+fUVFUoFqNVvIysxqNVWDuz 1/krN83BWqoYILzVCG/tRFTzsUJ2l79vflFZ0eIiNUbsphgPXBATk5ZrhwtyhbdyhRtztfiGtfD9 nkrfzT7FByftEbutUBdefLrwGtPyFo0pwOmE/9LScp/cqLtEp+zT8QM6rtMl57+dOTrhk6aoJVFK VMQnydoCa+x51qZN+Y6PFhvM2vmUY3Gl9VhWzpMXn+LMKtIcalR3ZiUeDaVWL6n1t47KjzRaDKqi Gi1FU5b6F9+6bEjp0htaTrusKW+XumbVsBnD0xVFyUobs3pKP2eS0xiVGG2NsUVaEhNihq/tWrvi vrOrKpdfXR+zaUe/sXMGi/dVRvdhZYt+Nd7oraE4u9iA2sZzhaOWS0YrVzicucKLySV+HNi/b0ZX 9wF/tN2B9735UFFNUuah/iM9Y+0jxQtdvOxwPNlf8CXtsYL94eNJOgUep5Pmbeh5GEOYl9Fd84NO 2aLTmwxGZ2qOK6PQE/W0yRKhj7Y9bUJowgHVtMFuF6Fmg3fkotHe8j6RJlVvi4mP0kdYIhIKaofM NjqSYvp4fvjUZBExyWJSnZ4+MUkOY+PM86bkWG2RMS7x/zEZdGy7er76FBuOv11nsQN+Z3Rejdhl NSZMucZjj+FjawrKcNoRLigL7y/wwXtFUZlxAqTfaovmYye4dLb+aoHRKFaPXfPXPr8VIq/A6HIZ C/J0wsf+QuHkenGLeo8dzer7Zvgt4Axbf6NaPPrNyLqPnM6mYvXj0pF9PeVvFI+e/oZnQvhPuDLt jXnoNQr9voLnhXPj8edcPlaWA0b78z58ffIivA4fx8XRqyAzy4B4Fhcfn6r+H/a+PT6q6tp/7znz OvPKPPKYPJicvBNCJgECgRCTQSKQBxCjoIIkDHkRyGNIJiEBAlOKGCy3zbXWKlUvta1Vr7XVnyJa 20bhButFLiq1/Cz1UqpWLVrqtUgtZu5373NmMgnB0v76ub8/bmY56+yz99p7f/daa6+995l4iIk4 GBdhecWJOTMzNLOxBaGFmeHltFTlKMzMyrIIyp2w1xH1pbSkWWsDy4saEu1xC+f+fpGv1l246aHN 7feun2FNmSnNzJ+VkZxeeOuXqnOWJFOrzTY62rS2YEl+XNOamUvz426ov/59Kccp7u6taipNFPxp yek35S/vu2HGtFi725XmVhlUKdfcsqDUt3JmhueWwpTSebPj46tnXLMuM2Pttcu23pgn6lNG/3hr izSvIvuW5uSipZ/XFZep9PF5OdkxCxdNKyhl/n0v9t8HsDLPIv1PlRXS6Q7Ffx0hx3Yoju1QPN7B luU4l5GFWyOLGEYWO4w8bBhZmYF42DEUpxorVpRn8irTF8dX8/DJTxw4W+dGHDjmjz+K8tVEZ7t8 TZa3tDHCAb1dXnOd7oqC0u3luOUHsdBSvGSoYvW26pT4kD+ropbVlaffvPLzr4RyItffqoprmvd6 WaS8DSft6zX5OGmnkH3PlKWtSOtME2KVvVysogN+7+BX7ryxiqfHKkqL/bFqM85uMbKmYpRaMUpp TEilMVDTQUOyBzXZn8k9FW+t4Pp548NcJRoqK8vk53QHW3aZM8ILaelEBThmLCjOZd+wCoTdOnnA OlpQPD1nPr4hy2+H5QvJNzymsrk0Zyad6bHTZdgQnOAwZyoBfybbRJj4lQf8mT9WZeG8ZlJGY1Ic w6QM16QM18ScISE2L4+wgcpOEZtq1GRXJC22hRzCPh8Oge0F9rM8Cs46Exp3eOBZdBJ3UA42CI46 SmNjhe16R2pCYpozSju6e6JG6I16e3yqMz41RjRHjT5HO8zGBOYCgs4s0o9HzZc7xqXXaK/BLApY RkST0zr63GiGLUbRGS2FzmKIhz+P6eTPYyZ//hKyNmH/G6HBupiPWLHv5M9fLrNl/OXQFBSaE1jV a8gHnkS7lc1WNgcz+bkyix8qfbV0ccTMDU9p5rUOxWsdyuaQz2iXKxZJl2uW/PyFP4nhD2H4xDZg NXumxmOjy2pKL3/MJjd72eO4H9OLCCtWqn2yqhLbTa3HvLCydHHevIq86vgI+7OgHdpRzVee4djm h55UsfjA/0Doi4LElaJGjHIQVpxFc0IOHg599Ixy9/zu69giGZfi0MXOWOSe7w/HEq09KS52mlVX /bWKebeUF1jzrq9akn5Tb0XyWFRJmz8hqlyeI+zGUiwIolG/ZeWKhPyF2TPLpzsQbqpDURcWnEXu 8kTJFmRMCcATraTE3YnWZMcjl5HteOU4zFZLOSzziIzyZ5RQzAKxx5BXOT0+vSKkerZOhmNx6OmP ou2rCMgxfy0gh5X4zWV/JSCPUxQUtI7FY3b+eQsacpAs8rAnqSyHZttpjo1mmmmmiWbqaaaOTufP JVzKtt6lKMylhC2Xsk91KQpzse2pK99ADdHsDBnN1BXNdsLR7IQZzXQW/ZzKwJ44PhNFlvlgpnj2 l7FRlWk4KykHSnYmUlQWOhzJj2T4h054kB46QoY2/cJbxd0/6Or8Xsfc+d2PdeNa9Hhi6cYVFa3l KYllG1cs3Vgu0Xc6nt1Tde2Op7pwrcR1e8Wu9fML63ctq9zlnV9Yt4udpkfvEn4B3bDTdICdplPm GhQvMSheYghFH4MyegNftmPkgzQ/UjtZsXymnvQkXWFdccWT9GQH6Ul85MoH6TvrsssXetIjnCU6 JtGuy6ledn3e+jvYQXo2P0gvzirfuqj0lqIE+n7v819eYk0tTBstDcVC9fvwGUGA9/RPL82Jqd79 w57rvtRY4shZNHN0/w03lzRuV6Kl6vv8yU7DU745NDNKUVGUopmokKqiFB1GMVXZicfBVi2EPMJ0 RhKgwQyPmFuZGRUjVcSwOcSDF1++csN7mcgN/GTThqtEq/q+Sivq9XHT0mPiC+YUp02cNBkLi+dP M6ekTzOpBSqsj3XZRFHUR7uriz7/0eXT5stzy7OiBL3BIFr4rwbXBz9UHceIK8hxjym/qqxqRdXO qh9WaRYqA1yoaGChMmMWsscLDuXeqlyN7EpPe5LTZ6XPMiWyCJPIgksiCziJLFolshmU+By9wB/S G9gib/LwhR+3mWivzPRDk8rk/nWR4fe2Gts6m88mFNmKbLElv1qYqMmpjH1Pdi2o8UMb+7llrfVD K59guaFH+fxXmLG9kKJcdWh+yb9oubVjDyQiTk/RUPPx2XW7lhfcdF1BrEGtNeqMuWWr5k0vn5WY 5alZeb0nK6d2W2360uKcGJ2Atd6gFVPnVuRP9+TEZHtqV97gyaKW69pg77j46PRkR4JVlygl2tPm ZmQWZien5pauKpnjrZhhssdYTVGxVlu8VRcbH+tIK0jKmpMtpU4vuZHZIiX4B1W7+gekmNz6VA6x peUpOs9TbJGn2CJPiWJ5ilfmMSc0xZnzPkxbOs38YdzSmYeo+gmdHIReYW43W3n68MoR+dGMevID 4vhjZGzoOK1q11ulHHfc4kbPtB1RdvaMeyC07fgde/Znj/pd0ZK49KRovUbUqNdMS7VaRG1GVfdy lUU+Ib6hM7HHrSYk+Bly1LC2XjSIGouTjfsu9pxGeB4r3J2eZKxrxizmQVnMg7L0bNfA9xVZVr6B oH8+KM+0ZEUryYpWcL3I5yZLMLUkhyZrsuKj2ED/2SM68iqyjJr4CmwzNGMPa9j8DO0swi416cOa sY0lj9Rzi8Ye29yns0+LiZtm0y67my9kumj5YB2Xv7SgdNt1uuhkzFy7GF7ftqxcXtKyd70qNTQ7 P/9kRf2ijJtXqnpCOUw/qdgBbIN+ZpDfPkvSgojNbNuWzH8jyEimLjnhorHKOGOUa/TYZo5f7crV hnJPERJFWCNtNMtKszU0NRsZ16TS9FSawpJlKTQ9hUo8V6LpEs2Kor0pNIU9pBBtMUtTJMxa3L3n EeGKKewJEbtjlkhh7ZtQMSW7IsWYUGGUAyD7SZF9SO5avg7myv9RthrKeme/UuTy36LDP7qNLZBx jrgih/Ij9DaqElSjr6jNCdkuV3a8RT16XK2hekdy3LQ0h6geVQt/URkcKYlxLptO+Be1aDDpLj1i tOgFtd5iEG4y2UUBRxwVmPh5gsmkelc06QWV3si0nQNtV0Hb+WTPs2QmwpONPe9jfuhmHrjATZ0Y 30H2fN9J4xRfiw1lxVKRjX4629WzOiWEzkujc43UKLHNl8S2XMaZBTkVaUbbtApbeIM1v8xmp/Lj LILNwVqmDFkfuRmx0bLrZQn8d5vMzLlFdOyXG4cj9HMNFRbpHVnJrrQYo/rUL9XGmNSkaRk2KlLn 6Kd66siSpqVFG9SvnFAbbMmJ0zLsKnH0zzMsDpMGZxcdbRr9Fi6CxuSw0Gfo9y0Os1rQGnSjT9AV WvarpDE6arSOeSN2FNuhn3RS+yxJxFjnME9KpDmJ1MmPFk6aaZlrUWWJNIGF+OIEGj+PKS6eJlfE GxwVhir1ClKlbOnZr1S5shMwZ0gR5KEWOTIzs2hmYfjXKQd/kBIbrVPN7tPOnJUg2VTa7aJVGP2Z 3prucqVGixpKhYtaW6qUlG7Tjj5ttWlM0RY6X203CLfGOC0aQR9l/tytesNh1CDu2ImKGoIX6GlN HU5oOcTytCYjcZl1MWD9+vjYs7U5Qmb4JD3hDx9+omN/eJBk19moPiYtKTEtRm8R47OTk3OcoujM SU7OjhdpT2j/ITxnsps0WpPN9Jf5KbmJRmNibkpKXrzRGJ9HBHJ38FP1efIWMZI4kkam/4w4VduJ i5hU24gdO9ztz2hTYsTEKAHOMnv2K7NmIVIxYrF87HyvuUKatuaXFLvZlx52s9SCBXn0SCivbXG+ u3ySLyy9T+ihJzV9JJGIT2pjl5Ay9vhr3HOuItn1onU42jvT4+PT44xaS5xtL5wo3m6PM6rVi3cm Sjat1iYlugrdbudxvUGHw7R8Np2O9ruV9o1xSvv8L1Hk2V/kCCu7W27W7Ih32OIMVH2b0ZmewLrT ZCbPzs9zHteZsC5jlaGOnQmSXau1S+xkMChsEdy8hyJifkqbGjsLvUCBk44Du88rjE71kDEuzelM jTVqzXHW2zUme7zdGmugmtG4SQow+9RLdigoElyz3Xnxr4SGPfrhFQoY2lxhi+rVMFpjVtzsMNqw VjIzC8fUoplUWapXGZhBtdnuZGCE3Ya4tPi4tFjj6P6IAsBX8xKGXpOVDDTOV/RGoEFQpDZokZst 4UoFwPsVoVm1X9MTmj+JmUusAFwWAizPn9DxZkJObIzqy1prnN3ujNLGGaJT4pwp0SIdvX1cXkGm sCc0geh/hFKjM8fnWa3Asgl7iJ9oJFJIlpJ7nyWViNtxUapl6yppbk8ZbS6ji8poYRlNL6Nlh1SL PNGmpCTT1jl04xxaNYcWz6G5c+gcFBzEUU6Ca7JzofwHM+89g2ZIgYliq/oZdq6qZabiYEGBJvMQ JU86bik/RGOe0NSH/iKIPaRfexKRe+1v+CnPzn585alZLNBFbErVEzehugknoNA58CeFbQ9tvn77 rddkWO3uFVse6sio9syw6NQqqjOKxsy5y2av3bMyR0hYuGzVzNahWzIfj5u7+tqMyuvKElLK6so8 daXT6HdW/kt/RXZl2x3frbvh0Qe+0lIiRtmN5iiHxZ5g1VtslurAI7dGuZxR85v2riuuvzbdHJds /9LjrXkF1zeRYDCkW5UW5wT2+fbfR3TaVdGGqyVVzFXRV69If/piEvZMSq9NkfCa+ktXIk2C5qHL SXuNQm9dTjrvP5b0yyeh1xiJVV9I7zAyZI8R5tf+SDJlX4F+xsg8T6HRy8my9e+hKMOk9MIYWa+3 HpyiKfpfT3/5IrIttvXavs9p1L7qf5ju+58gR+U/mGqnaIqmaIqmaIqmaIqmaIqmaIqmaIqmaIqm aIqmaIqmaIr+fuK/J1NCtAcJpUlaQvTkYZJEdgYvkCSqCr4Fbg2+DZ4QPAvuCv4KPDs4DD7A0/uD 74EPB0+AHwW/iTQGPwXfGfwtuQktnAS3Bn8BnoDWbkILvwTPJibwAZ4eCp4B389zjjIurCZm8DWk ALyOp+uRbgQlkUa0yd7ZZg2yN68lBNk731xB9ta1miB731tPkL1VrpfzAZ6/l6f3cT4UZO+Ce5qn h4PsbXgjQfZuvKPB75BG9BsLzvptRL8szfr1o8dnwa3BJ8ETgofAXcGnwWuCL4P3BI+A93I+EHwU fC9P7+N8KPgM+NM8PQwN+NHXvxM/erGA14PvJP7gn8lO9HIB3Br8BDwh+BG4K/gb8AFocifqvg5+ FDrfibpu8HripirY4hPw/cEPwdE++AhPHw2+SVXC6uCvwOvAoyD5B/Ch4AXw/cFPwYd5eiT4S/Cj LA35D8DrwK3A8wfwAXAX6n4Evj/4J3BWy4VavwE/Gvwv6kItlKLWRzQbtU6BW4OvgycE/x3cFXwF PDt4jv0bzsEj4APBX4APBd8BHyZm8KPEQLOh/3jwNaQdvI6n65GuQZtvgkMz4AkYXQ3a/AN4DXGA DwQ/Bt8PPDXMc8DXkBvA63i6HunVXEuruZZWcy2t5lpazbW0mmtpNdfSWtSNBa8Hb0O/vwa3Bk+A JwRfAncFfwo+EPwx+BBaaEObF8CfDr5Le3gvPbyXHt5LD++lh/fSw3vp4b30csleLtnLJXu5ZC+X 7OWSvVxyAKWfgo9AqwMo/RPdy+24l9txL7fjXm6RvdyOe7kd93I77uV23IdRvAFuDZ4FTwi+De6C 5vfBFiw9EPxP9u9oY6T7YAsHOLPFPmgyCXwNWQNex9P1SA+h9w/Zv7odfB98GDofQr8fgMMz6RD6 fQe8Dnw/+v0duJXzBMjvR78fgA/AE/ajhd/S/ejFCL6GLAGv4+l6pIdR9yw4qzuMuufAXZxnQ2aY Ix9GOx+CD0EDw4geBvBhYgI/yjhahn+j5RLwOp6uR3oELf8K3Bp8DTwheBLcFXwZfCD4c/Ah2GUE rWnBn0aPI2hhNng9+FHU/Q24FbY+irrvgbuA8ChQGcBreP4Az2e+cZSjOspRHeVaPcpRHUWbpeB1 PF1PSpHbSNaA+4lBWI1ejoNbg98GTwh+B9wVfAS8Jvg4+EDwOfCh4KtopZFECWsgvwncGmwDTwh2 grs4rwl2g68levCe4OvgvZwPcMm9PL2P86Hgl8Gf5unh4DvgI6x92PQXQMmw1XFsdRxbHcdWx7HV cWx1HFsdx1bHsdVzbPUcWz3HVs+x1XNs9RxbPcdWz7HVc2z1HFs9x1bPsdVzbPUcWz3HVs+x1TNs fO3KU6US9n89s08j5wJf0Sz8jqVVxCKolbRA0gW7klZHyGiIU5irpLUR+TrSKyxX0noyHSVyWiSS cERJG1QHwvJGskp4W0mbyHR1sZI2q+5Rh2QspE17ia25/DNLt0FJU6LT7VfSKqLTf6CkBWLX/1FJ qyNkNMQkCkpaG5GvIwvEKCWtJzG6TiUtEqtYqaQNtCYsbyS54molbSIx4m1K2kyrxZCMhcw1vAsk VC0qepbTsp7ltKxnOS3rWU6rI2RkPctpbUS+rGc5LetZTst6ltOynuW0rGc5LetZTst6ltOynh8h EpmFVXwmuESW8bcOdpFO0o1vM7xaIov42xrldzZ6kdOKVAdWWIksJG0gidQir4VsQFk3v2vCtQnS veCNkFyEem2QWY+8Vki0cjkvvu1oq5HLduCuG3kdvEyu3woEEr5eyLWihX7cbUHKj74k/o7I9Ui3 QVbimHtQu5G/g7KFt9KptOqHRLvSJ5OQMMZO3mcTf9ckG0sFH2szcrz8HYhdfBQSv3r5KFm/8jga UDKDt9zOc9p4i17oSM4P9dKOdtq4xnwKyg7ktPNe5TbZOP0RCFiPPj6W0DsyZW3L2FlPndCAxN8O 2cK10MrfB8nes+nnd2zE/rA9ZJ3JvUgce4cyrk6u2/Vccgxx5IiY1vp4PXnUm3Dv5v4Qac0s3lo7 b6Gf66FHsXykvpnF5PE3cfxs/LJdurg3sKvcI7O1hDZ84dHIGFsUmW7cbVVa92MUsoV6w1bych/x Ird93LhC3twAJF7ef4PSv5t7bAu3FSu5fA4UXzbqVYrntCo+NgetFGEGXdnT/bzPRu6JrJdNYRuE dDPZ3GtR/NoXlmaeK1u8A/JN3HeqIdFAsrlOcyDTyNtbwut28vb9IB/GkQ/awsnN59T4/txK6/lI 93MPbOGofWihH7lMY818xMxTx7caym/mb4bt4v4Sau8WPgbZS/q5dbs5Qj/3424+7+TaEh8DmwNN 3IKtvI8mbsP1vG5IW9eRlRj3QqVuV0SJPH8auU7G5sQW5Y2qG67Qr3zPZBtgwR6uw8awjzXych/3 kP4Iv/LxkXYoniW31cQ5mykTx83K5RmZjVrMUswb1od7mgxVx2UtX72OxloPRUVJiWt+jrthXHy5 fOyhaDIR14IIDbCRyGORo2xonegKR+xGHrM6eOzyXnGksp6943Qqz/hOhcujktM93PN6eM1GPv/Z aJrC7TDJNj5rvshC/6h5MTYn8jkaNgfkyO/mtvKRvkekWQUzZ0nLWhu6Ors7m/3Sos4uX2eX19/a 2eGWFra1SbWtLRv83VJtU3dTV29To3uRt611fVer1NoteaX2zsamrg6p29vRLaG8tVlq9ra3tvVL W1r9G6TunvX+tiapq7Ono7G1o6Vb6oSov6kdNTsapYbOro6mrm63VOGXmpu8/p6upm6pq8nbJrX6 0UdD9wypu90LBA1eH9KsSntPm7/VhyY7etqbuiDZ3eTnDXRLvq5O4Gaw0XpbW+cWaQOAS63tPm+D X2rtkPxsHECGKlJbawf66myW1re28IbljvxNfX5Ubt3U5JaUYWZ1S+3ejn6poQeDl3H7N6D/pi1S lxdj6WrFsFHR2y71+Fg3aLEFOd2tWyHu78SAetmQvNIWb1e73BdTc8MGbxeANXW5a5taetq8XWEL FIe6XgXlYDjSHHfRrHFK93d5G5vavV2b2AgYmjHrtUDXPpbd0ImBd7Q2dburexqyvd05UmOTtKSr s9O/we/3Fefnb9myxd0equeGeL6/39fZ0uX1bejPb/A3d3b4uxVRlm72ovtNTO6Wzh6opF/q6W5C 5wDEiiUvLNDU1d7q9zc1Suv7OazrVlYvRGkXv4F9GntkS2zZ0NqwIaIurq0dDW09jagKjTW2dvva 0AHTla+rFQINkGrq8LulUN+dHTBkdmuO1NS+nlUaa6ojJDwpIi7OXBFm6fZ3tTbI/hLunblJqK0F HEB2K3qBy7I50cUcu7FzS0dbpzeyU2D2ykhheAwXOmaJHr+vxw+197Y2NDGZDU1tvgkDuhpbcEvk NzY1e+H8bm+3ry98biJBJ9kz8e3syplEwB7cQBxEFwySKOzx5dMGwZmXsDf9hs8xk3+ShI9NJgoZ evJq5c1mJq8KXK18VBSTF2ZcrbzVyuVPXa28zcbk1buvVt7hgDyuhJ2+1FyenT4zSBJ4PjGTcpJA bsK+spEUIoIuJDvJKqoiDTSKdFAr2UYTyB7qIl+Hhh+gNeRf6WpyCCflf6Nt5DXaSf6T9pBztJew p0Iqupea2VMdOkQz6H5aQJ+mJXSYLqEjtJYepWuFSrpRuIVuYc8NcJ6/Dafzf8LZ+RvCN+n9wsf0 exjOk+Ox0oOTYGVRvwRYK4C1Dlg3AWsvsO4G1q8B6/3A+jCwHgTWw8D6KrC+BazngPUz2ks1wGoF 1kRgzQbW2cBaCqxVwLoKWL3A2gas/cB6O7D+E7B+A1jvB9bvAesPgPVpYHtxPFahLwKrBViTgHU2 sC4E1hXA2gysfmANAOvXgPVbwPoosB4E1n8D1pPA+ltg/SPtpIT20ChgTQVWN7AWA2sFsK4EVi+w dgLrNmC9HVi/DqwPAusTwHoIWF8A1peB9XVgPQ2s7wDrf43HqtkUgTUKWF3AWgSsi4F1JbB2AOsA sO4F1nuB9XvA+jSwvgCsrwLrGWA9D6yjQGIBVhewzgTWa4C1AlhvBtZGYPUB6w5gvQNY7wbWB4H1 CWB9AVhfBtbXgfU0sL4DrB8B66eYa9rxWHWbI7BagVUC1gXAWgWsa4C1F1j3AOvXgfW7wPoEsL4I rP8BrGeA9TxdSyl7cgqsKcA6C1iXAOuNwOoF1s3AugNYvwKs+4H1+8D6FLC+AKyvAutZYP09sH4C rJ8L9Sqt8E1VlPCxygms2eOxivdGYLUBayqwlgFrDT/N7iQ7gPVbwPoIsP4YWH8OrL8C1veB9S90 NTUBqwtYC4D1WmC9EVg3AWs/sN4OrPcA60NA+RSwHgFW9tzwfWD9VKhURQu3qDKF1ap8YY1qvlCn WgSsy4D1JmD1AmsXi5d6NdVrzwcC+C9wXk+pXh1QPno91RsOH/4ePvfeq9cwscHBQSan1xC99qIk f/RGojfulnZLlZ5Kz/UgKSAF9FpIXFLrrZIncEmroVrdeX3f4GAfa0aHjgZZS1o11Wp8rCsfz9cz EQhxed/gxUCgT68GwALPeQ/7QEir7RsaWhfwDZ5XWvrRS6yKjJsouNmIAoGhA8MHDgyNG5FWT7WG gz/fiw/vQ66sdIcPgwGkg/IwtQLVqs/IFYFU6wsMF1jP6NREp5YBFfCaTPqeDVoN0WoGB2tqJElO IlEzqB/LBfwxKJjyOtzdKaioXvAEAoKK4OoJCICuqTlwQMCwNTU1BwQB9wcOHOAKn+fhevN9gcVE qje+EHgh8CDoLtAgiCvqipYzXa3lRA0VdYFI02ll0/ECfdh2rGDd0HlWoCYibDeZ8UKNTWI9UU1F WE8xn0ipGB7e32o/5l4/Gp5gP+5RnskNqB0zoHbMgNqQASPByBYUmQVFxYKiYkFRsaCoWFCULQgr hCzIh38xIJvw4vgxigYqmobx+bbn2547Oe0DiVoq6i/u3r37IhfSEVE3alU+opGKZmbHOxRLzgww S8pCKtmUozoN1UFLMNM9GwxaatCjmUNH0OCRQ6xI6xtExqCPF6nVav8+FO3z67RUp+/bvftSILDd oCYGTdieHkjqdNvZcAIQ6BvX5u7d8qAUmwYMGmpg9h5kVh0aNFBqGBtxQCdSnen/kGPcXWXi/SpN hTDslntR8o8cYjXVVKeYmKeZS66zWs8w19OEkBbwBnh9DIipgRkUFpXTSNXUDBoi8mFqA1UZNGFT B1Q63N95p1oF3DB2QE7A3GoMTLt0aGhIrSFILF06pFYjBxlD3MiwuGxyrp5LzNysyUsTNGAwUoN5 eN3wOnjKgX+W/hmWvENiFuXVmNlluxt0xKAP293Kqll2S6EpPGZ6WY6ZXra9rEH1dijAqKVGZqdI 4+sU4/My9eTWN6qJkVk/bH4dynYwmwS279q1fXyzE+1v1FAjs3/IAYyUGiOG/4/yADaUPraa6M// P3uAkaqMIQ/gLiAigwGD7Y0hJzCGnMCok52AJWQnMHIn4PYr8Shq6eNaYl6guMFEPRjN1Bg17Bx2 Hsg+kD20dGgpi0236W/T79IbddQoXty9a9cu2RWMOmKMcAUrr7oLgtdZZcpmbRyweqweox6iQRpy h6BeS/WyO0AdJh01ibLh0PauI4dYqW5eOcsqn8dLVfgUL2ali4t53XnlzCVQqiEmzbwxn/AApH7M KXZtn9D4rl2y34fcImDSUpM+wi924zBmilRIQG+kesuzwyPS7gjSoxsx1CS/mVfOkuXzjGMl3D34 Wqm4h7wSwtXXWfWYkGzmejwXZeDzeCtygxikjuj1aK48O9tq5bX4CgAnMUaWWCXJRFUmbRis4iYm xU1MITcxhdzEFHITU8hNTDrmJty4spvwYXC9jbJV4BJjw6MmFfoZjviYLNRkPZN0Jul8yYkZp9pO tb1UfezYkX1H9x02HTaZ9NRkuDRy+PDhEbm+SU9MYtA59jFFUZPtBe0L2sN7GvY17Gs+1nxs7qnC m0v6nAXOApPIpAM0IOAorSUm4iQFoHVkmASxqlBR3D6i1e4YGTnea9ZTs4H1cPrdw+zz7mlWri9p 5t02l/ByAZ8FLby8ZYGoR/2S5pERDG99iVlLzdqSdevWXVynfEysfOcIPtuHd6DGjoldHD5sVlGz eniYkLA2zDpqFlli5Nip8+dPHTs2oshEfEQTFaNOn/ldwcg4YngM4ab5XUkzTzeXmCLK3j3N2mAx /dSZUItsTe47MnymL8m0r4/FOO3YQObxppRmMWyRiCLbmjUQRnNBSSBRj/8ONzeXOEuamw+bJhdy cgOYVSpzhAtg8CoDso4NHxvWCNSskdYhl6fQ+3BAA5XoU5uPHTum0RGzvrm5+digBtrWH2Mf7iGu AghyN2kukZ8cGMiDqpuJ0NDf1UaiW7qaNpHiNq+/g1SjhN5Qe60EJOyNH+yJgRbn72jljhIdTrgx PF/OwYYW58hYkFBRU7OUpNeuWCaRghtrqyRSqsiwZzdWEsfvBPRgC7eOtYbYSbxyhyhDHDjpJzb4 un3ku5w/yvmPOD/I+fOcv7ipqauDvMT5cc5Pcv4m52c4f5fzc+zRIvmYcarlPIFzN+fXcr6K843t m9o30R2c7+H8q5zfzfkDnD/E+ePhJzB/jdOr5HpoUoAOtNAwfAV6+f+Xp4IdzH/z1UJc/Dc+9qvU LnIneZA8SV4kr5Gz5GOcfUU+Ur0y2nOE/b4uoF40/J6y8yktlq+De+Tr/Rcj6sDfPnpw3D01XRp/ b8kcf2+zj7937B9/nzE6/j57Qvn0hPH3hQVEVEXefxJRriV0Scn4++o7cDXAp7NJDfubBNTZBVUV qGrITtV3Vb8kB4T7hfvJSbVf/W3yC83r2kEqGG4weOmzhtuxXXjJZDVdp1pkWmN6QNVvbjRvVP3E vNO8T3XEorLoVa9ZPrV8qvq/hAYuMN1o3zAfnJROgN40vx1BHyh0YhL6xJIapmxQMagctJHTPRPJ fMLyoOUp690KHYigRxnZyKRksNWE6Q7bXWG6IJM9aRJygwqj90fQd2XiJRMo+snol8J0POYM6F1G serJyO6Otcdmx90RQXdxenFSOhH3WYic0c6EMJUrVDkp1XBapVzHU0DhTG6E08kwybXfcp6Pnx7f GP9A/MOMJrYe//hkJLcefyj+rEKfjBHrJf4z3leAfadVpxWHqTqtNkyNCm0EBdI2ste6pnsy3Bnl aRvB3RkvZr6U9QanT7JXg3w5maAZOWdzLuJ7Nmd0+ku5DzDKOZv7fO4HuR/MUM+wzIie8RzopLsU VONenX+fQj+dGZidOfu9wjvnFoJKi5xFq4v65j2p0PPzRuadLJ4Omle8Z8Fp5UVCQ9e8yOlS6dzS xxQ6eM0l3D9Wep7fnS9TlalKHyub4fmq5/mF7utuBr21ZMM1Q7I0rudlqYpSJldRXZlaWVBZWvlw VSanmqqNnPqq9lTdB95X9TLoTPXW6kD1W8t8oLuXr4NUzfLjy49XvQx+mqVAZ5efW/7ZigCnh1Yc 4/TWinP4vrXiQo16xQWUn6tZXXO65uz1ftCdtRLkHlpxQS6p3briQu3btR+trFk1cvPNa+1rk9Zm tqhbVrecavksdN0wA/Rkh7Uj1dfn2+Ub9p31nfNd2KzePGtz+ebmzb7NWzcPbr5782ObD24+svm1 Ll/XnV0Pd33cTbrt3Uu713c/3/2Gv9C/3n9fz6qewZ6f9nzSq+2d0bu497Hed7eUb/msL6lvcd+6 vq6++/oe7zvVn9p/a//B/lP9n201bY3dOm/rtVsbtz609dS26dvKt9Vtu2fbo9tOb7uw3bN96/bn B7QDnoGugR8NjAxc2pGwY8OOh3ac21m8s2/n44GaK8SqgxPj0fhoE+gdIxZHAgfGSI4gV5h7lRNn 3Ph5Inv6pFEnFHkiaHzsCIyMEYsOgZNjJMcFFkOtjzpH4u5CHH6z9DyiJo/B/Ip4a6tBfL3H8qD1 bvOJcMyErO1CWiOraz5ouWcsdspaQnQu5/FXlkq1PBjSHstlsZjLvsnKubyiQbR70Pw2IvmDqPEm b+0E0N2N65ucxlaHDyasCuUR68DYSvAgw31Z9H/0suhvUGL+HTze8yjP20FtSznS94QiIezxsGIv xCY5/sjxTbEjYiIiILNaYzg6hiyKGOesDJxlNcZsnFYbOBs4i9aY1Ccoq4k/m1Z7uU8gDp6MiKiT xNnIuHp5TFUi9wj3JjmKVofiJ4vryEGvgXPxDyOn1lkzt3D58Vi1vI7xK9asuM9izsCr7KHVJ7Sq 2JNi1WMrkOyVbG3j0momgbovxtpZCcthUizfnmQ+EfJUZ4I9CSugndVnaTl3bB2NXEkZFr5qKutm xMppRwsT18m7xq2OJ5SVMTqEHuWfyb2z/qtqYs44y4FnnPaZ1piOYamIGRvSsTwTmTZlT0lrhL4r mTWZJpw10fu5vR9mtomY1cXxj2OsoRX2pNxq4JwzEDgnE+uBXdNqmVVYSvY0dg2cy3Cnz5K/8gqX PouvShHEVjh5dePr499JfE2NoMsl+EobQcqKG6bLa7CV9m8jvhZfNYVX7CvQRE0xCq/jVyC+sv83 b3ceHmdZ73/8yUyapMkEKDsUKGFfRHZQKrIolUXKJljBg5FNwyZb2bTQkgKyFmUr4hGUHaQgsUcR iAUKtCmBpk3SkMSGJh2SDpM0STOTaSnc5zVD5fLo9buOvz9+vyvXm5l55nnuub+fz/f7ve8nNuO/ /VPYbfybP/+sTmGP8g8//6pfYe/yDz/5vP/c6f+7n38d+X+f3b/387nO+b3LRr87vOT4nQ5fX9me 3/UUfu4pHCnJ73QKr+45fqf8HmjDe37soL6S3zV9fjTf+/PP8j+F3dGUws4qv4ca/PpgYX9kd+TZ G4ffU9idTP9iF5P/efKk6ZM7T5qe38EUXj25YZ/z+fMn7YK680fyO5r8dZM3/BR2PFcV9kbOLbz7 ZP6/28xx9pP53ZRusdvkzsK+69oNPycXjuyW33UVXp08uTPflza858fObT97tfwOLX/dLYVnfgr7 tMsK+znnFnZqX+zXTjj5iFhBkfV5LU656nMlDi8pxGPGn8/0hIbC2PlPuqUwVmHc/1mJ/+roP+bB 7q2fv4pKiuaF9viJ4dX46dHG8SlRIn5FGIrXR4dG+b+dWuxVsvAsHT89rIyK/Hc0ivnvwviUsNgd +nNhfTQ/rC+qjjYr+mF0atE50TZF50ZVRedF44ouisY58yBnHhG/OPw1KjJOT1Ts3IRzxzk34dzy wnhJZw1EY4vyf1dTHe3s/dO9v733dzbWrsaqcvXD5rM8//cu4SXzHRf/mXlMC38y38PiPeHB+Mpo v3gyOiDeG+0dXxWa4il3u/nRFxu9Oyr2LBaf8tknZnOfkd6Mro02jo6PNsFh0Z7RRJwXmqLzcQGu DL3RVWEkmoqrcQ2uxXVRIro+LIl+ip9hGm5Aretn4mbcglvxc9yG23EH7sTL0dHRX5Dz/DOEaM+i CEU4OZpYdApOxWn4Dmqik4rejiaIuCZ+RvS1+Fn5vxHBxdHP4zdGO8RnRDvGa6Mdih8JS4ofxW+x JNqzeCma0YJWLEMbPkA7OtCJv0V7jtkkNI35MCwZ83GUGJP2vB+DYUnJmOj4kj09HhjtWXKIx4tD U8kluBQ/wdTQW3I1aFNCmxLalFwP2pS8EE0seRF/wmg0sXSvaELp3vhBtGdpNc7B5bgC12E6ZoBG pffgF3gEv42OLn3OYz8GMIghDGMUNCw7F+fhfEyNJoyNooljN48mFHL3I3ldXni2iuuj0Raytk7W 1sm23WTbUbLtJtl2mmw7R7YdJ9uOzP8tpHz5cvyMcHf8u+F6GXSwvLnfCNXx+vBkvEeeJaN4/CM5 uCo6q5BnK53VaZv596o4O9r3H8Y/1vhXG/8Y4x/q7DONfZ+x/+SqA439gLEfNt6rxjsj2sgoq42y 2iibGGV3o1xqlH2Nsq9R9jbK7vm/lDPSHkY6zygHGOHpQqQLPXsh2toYfzXGX42xR9EPwl+Ms69x fmCcg4xzmnGOKKoJ7xtr36LZ4c+ufMV4xca72swuMOZmZlZrtDvi3WHE7Brifap1VbRPPLWhYscZ dS+j1hj1UKMeY9RdjLhH/i80XblU5Z0oytOjig0d5lOdJN9ZHopqQzqaiZtxC27Fz3EbbscduBMN IRctwrtoxHt4H4vRhCVYima0oA1/CyFaji58iBXoRk9YFK1EEsOhI1qjzkeQQRajyOlua72/Dp9g PT7FZ+YSQrooQlGhK/bEz5Rh3w+r42d7rA6ri5eEdPFSNKMFrViGNnyAdnSgE39DX8gVr0IKHyON fgxgNQYxhGGswQjMpfgzhLBozKZhUemRIVd6DI7HCZgceku/4/F0nOn9s3A2fhDSpdU4Bxd573KP V+Aqz6/BtbjO6595nO5xBm7x/FbwoXSWx3s8/gL3en4f7scDeND4jzj+O88f9/w5z1/w/BXwqJRH pTwq5VFpRwilneBRKY9KeVT6oWtWoBs8Kl0VOkpT+FgsafSHxaUDWO29QWMPYRgjXvOuNOtx1Gse lZ2L83A+v2LR3dHmhZUrHt0td0+Xw/nVa4xXz3t1vFfHyfL58fejvaMiR7PRN2Vmh8zskJkdMrND ZnbIzA6Z2SEzO2Rmh8zscHavTMvJtJxMy8m0nEzLybScLErLmKyMycqYrIzJ+rx5Pq8j/h/RmPgP cY4MOjf0yJoOWdMhazpkTYes6ZA1HbKmQ9Z0yJoOWdMhazpkTQcns5zMcjLLxQ4udnAuy7UOrnVw K8upLKc6uNLBjQ6q56ieo3qO6jmq56iapmqaolmKZimapWIHFbNU7KBiBxU7ChXbHpXS8iiVXGbt fc3aOze+2FrbZBWy2hT0TYmwSYQrCvr+zKutvdqOvjcZYVk0xTpZZZ2ssk5WWSerrJNV1skq62SV dbLKOlllnazySYdYK3exVu6iZpvVbLOabVazK9RsRs1m1GxGzWbUbMZ6uqmaTarZpJpNqtmkmuV3 dIJ18yB1ukKddqnTFeq0K35OtFv8XFwczbSOTrCOTrCOjrd2Vlk7q6ydVdbOKmtnlbWzytpZZe2s snZWWTurrJ1V1s4qtZhUi0m1mFSLzWovo+aa1Vyzmkta46qscVXWtyrrW5V1rUqtJK1tVda2XdRK 0vpWJf+b5X+z/G+W/83yf4X8XyH/M/I/Y/3b1Pq3qfxPyvlmOZ+R80lrYJX1r8r6V2X9q8rnexim 9bD92d3hZg4cq5+v0M+ncuJYTjzh3Ttl+zHxJXZSzeGzeEt0TsG9Dme3O6vNinl3uMGrc1y7xLVL HT3StXe79h3XHu/aZtd9LyrZUEffdWaLM5udeXxhf5XPmacKI53v/SO8/573W70/0Ui3efdFIx1t pAYj7Vc4/4PCPnF54b/ZqLxo42hC0Zm4GJfgJ7gMl+MKXIXbrfTj8n8371NuMvq1xllY2Bs9Gm0V fyU6OP46/7ujna3ap9klbmrl3tYuced4n86wygxSjn0cHWw9vyK87oot7Sl3yq/prr84Os4Kdmb+ r4aj4+JnF3Zfx0Ubmdl4MxtvZuPNbLyZjTez8WY23szGm9l4Mxvvys1deakrN3flpYUrK4vyf5d/ MS7BT3AZLscVuAq3i+ZM2XlWtL8rd3Pl/oUrE65MuDLhyoQrE65MuDLhyoQrE65MbLjyoA1XHiSS s6K9PNuroHFdYY8wSq2O/N+94hScitPwnajc3q3c3q3c3q3c3q18bP5/py3O/zW8a07esNOYX/Bo RdRctEfoLtoTe2FvfAn74MvYF/thfxyAA3EQDsYhOBRfwVdxGCbiazgcX8cROBJH4Wh8A9/EMZiE b+FYHIfjcQK+jRMxGSfhV3gYv8Zv8AgexW/xOzyGx/EEnsRTeBrP4Fk8h9/jeczBC3gRf8BLqMMf MddubZ7H10N70Rt4E/PxFt52/J3QUrQAC9GARXg3fFTUiPfwvh3Eme5Wzg6Li9+yk3gb72ABFqIB i/AuGkNL8Xt4P7SMGRe6x2yOLbAltsLW2CZ0l8zCQ6BByW/CRyVPhtUlT+FpPINn8UfH3/Rot1ny lueLQ0vJUue3eZ4N3aXbYwdMwI6oCqtLd8LO2AW7YrfQUro79gjtpXtCLpTKhVK+lx7g9YHemxg+ Kv2ax1PD6rJY6C6LoxhjUIJSlGEsylGBBCqxETbGJhBv2abYDOIuE3eZuMvEXSbuMnGXbYvx2A7m X2b+ZeZfZv5lVdgJO2MX7IrdzOmA8FHZgfhqaCk7DBMdOxKT8C38wHnneLzAez9y3o9Rgwsx1XvT cANuxHTMcvwx5z/l/KdDe9kzXj+LYccyoXtsEcQ6drPQMlYcY7cIH43dUQ79tPBtD9Qpok4RdYqo U0SdIuoUuaKIOkXUKaJM4TshxmFTbIbNsQW2xFbYGtsg/60R+e+MmIAdUYWdsDN2wa7YDbvnv5fE Xfae2At740vYB1/GvtgP++MAHIiDcDAOwaH4Cr6KwzARX8Ph+DqOwJE4CkfjG/gmjsEkfAvH4jgc jxPw7Sj//15WUTQZJyH/fRen4FSchu/gdPM+A9/FFHwP+W/EuAE3Yjpm4CbUYiZuxi24FT+H+43C 92f8Ar/EvbgP9+MBPIj8d1g8jF/jN3gEj+K3+B0ew+N4Ak/CClj0NJ7Bs3gOv8fzmAO9tkivLfoD XkId/pj/9g69/HW8gTcxH2/lvzkDC7AQDViEf+4ip4cf6tJT8t+ukf/Gj/w3a+S/7UPXbirW8Yp1 vGIdr1jHK9bxinW8Yh2vWMcr1vGKdbxiHa9Yxyue4x7lBbyIP+Al1OGPmIs/h/7il/EXvIJX8Rrq 8VfMw+t4A29iPhqjRPF7eD9KjBkXlY/ZPKoYswW2xFbYGttEFSV3hv6Su0K6ZJbnD3g+O/SWPGRN 4kGhmz3qPbGUPOE9cy4x5xJzLtGlS14IK0texEveq0O+y/2X8//k2Mve/wte8fpVmGeJeRa63zte N3hvkcd3HWvEe3gfi6NEyVKf7d6uxL1dSatjy8JooVO2m5v7uZJe17pnKUl7bnddYnddshruWUrc s5S4ZylZgxFkkBXbaFhZulHoL90Ym2Actg6jpdtgW4zHdtg+Ki/dAROwI3aLEqW7Yw/sif0dO8Dj gbDKllpdP++6UaIsFlWUxVGMMShB/l905v+p5liUowIJVGIjbIxNMA6bYjNsHpWXbYEtsRW2xjbY FuOxHcyzzDzLzLPMPMuqsBN2xi7YFbuH/rK93aN9Cfvgy17bKZTt7/nfO/FBnh+CQ/EVfFUch+Hb np8I97llJ7nu5DC/7BSciu+F0bIfmOcFzvvnLu1+t8z9btk1mGYON+BGTHf+bT5b/Re69gMeZxv3 IfwKD+Mp4z2Nv3fx5xzjYVnGtZ+E0bFRWDm2yF6pLKTH0nNsucdxjm8WJQqd3Qo1divHtsY20I/H bpf/vWS+0jfsq6ap0JbCHu2NL45f6vh1hd+j5PdbA9GY2LHh+/ETw5t2p+X53215rz/6Umy/kIod hENxBI4NTbHjwqLYCTjRrvz0sNzuotPuorN8SlhUfiZuDanyn+M23I47cCfugnu58lm4B7/AL3Ev 7sP9eAAPYjYewq/wMH6N/8Rv8AgexW/xOzyGx0MqsXdIRXEzzcamuCe+wj30RPPPmH8mdlhImn8m 9g2Pt4UVsdvdu5wV7aN/7ePMReWnhWT5d3AGvo9zw4ryC3ExLsVluAq3hozYMmLLiC0jtozYMmLL iC0jtozYMmLLiC0jtozYMmLLiC0jtozYMmLLiC0jtozYMmLLiC0jtozYMmLLiC0jtozYMhXHhxUV J+DbOBGTcRJOxilhhdgzPDw0LOPQu7GCj2FB4TeHE8T+tLifjp0V5sTOwyW4Lcyjwbz8/bfYnxb7 02J/WuxPi32e2OeJfZ7Y54l9ntjnlV8b5pRfh59iBm4Oc8xrnnnNM6955jXPvOaZ1zzzmmde86Kj OFDDgRpz6+FAjfmNyqARGTRinl1m0mYmbfHTPxuJT/ksk/9uMc7sm/9eMe7su+Eef77sGpFdI2bX ZnZtZtdmdm1m12Z2bZyp4UwNZ2o4U8OZGs7UcKaGMzWcqeFMDWdqOFPDmRrO1HCmhjM1nKnhTA1n ajhTw5kaztRwpoYzNZyp4UwNZ2o4U8OZGs7UUKCNAm0UaKNAGwXaKNBGgTYKtHGmJvoGFaqpUM2L hVSo5sfC2LHR9qKfLPrJG37feseG++m98t+Rl/9OrPz34+W/FWvDb4m/x6uFvFrIq4W8WkiNydSY TI3J1JhMjcnUmEyNampUU6OaGtXUqKZGNTWqqVFNjWpqVFOjmhrV1KimRjU1qqlRTY1qalRTo5oa 1dSopkY1NaqpUU2NampUU6OaGtXUqKZGNTUmU2MyNSZTYzI1JlNjMjUmU2MyNaqjUrkwIuKEiH8h 4qtFvKkIbxDhNdE2NJpPn/m0aaVNKx02pcGm3r1X/PPFP1/888U/X/yt4m8Vf6v4W8XfKv5W82g1 j1bzaDWPVvNoNY9W82g1j1a1UhOe+qd+NxLtEztFj5uCGn3uQj3uIlwMY5vxh1/0uml6xo1hUcVP Q6riZ5iGG3AjpmMGbkItZuJm3AK9sUJvrNAbK/TGCr2xQm+s0Bsr9MYKvbFCb6zQFyv0xQp9sUJf rNAXK/TFCn2xQl/caCzKUaHn5Tt7qjD3jBpPqvGkGk/SLX+fvpt3l6jdpNpNqt2k2k2q3aS5Z8w9 Y+4Zc8+Ye8bcM+aeMfeMuWfMPWPuGXPPmHvG3DPmnjH3jLlnzD1j7hlzz5h7xtwz5p4x94y5Z8w9 Y+4Zc8+Ye8bcM+aeMfeMued71pTwAbXfpfDrX/SsfERd0QEiqvN+t/dHubGeG+u5sd65Xc4tc26F SinPf1OjSinPf1fjht8Bvc2h9RxaL8o6UdaJsk6UdaKsE2WdKOtEWSfKOlHWibJOlHWirBNlnSjr RFknyjpR1omyTpR1oqwTZZ0o60RZJ8o6UdaJsk6UdaKsE2WdKOtEWSfKuuhgkdTyZgFvFsRqou34 s0AE56qAtSogK5KZItlqw29mtsr/ZkYkD+Z/m8W7BbxbwLsFvFvAuwWiqhVVrahqRVUrqlpR1Yqq VlS1oqoVVa2oakVVK6paUdWKqlZUtaKqFVWtqGpFVSuqWlHViqpWVLWiqhVVrahqRVUrqlpR1Yqq VlS1oqpVx1MKdfwVUby/4X9zmmTW95r1S1GFeBvF2yjWRnFtIaYtvHO/eBrF0yieRvE0iqcxKolN 5evVYW3smvBRbKa8uCsMxO7P/6bd0XWxmSEbFfnv2mhPZ2Rj18qI6zAztMRuicpit7r6ztAXeyD/ 3WThk9hD4ZMK+9sK+9uK7bEDJmBHVGEnnOec83EBfoQfowYX4iJcjEtwKX6Cy3A5rsCVuApTcTWu wbW4DteHTwrxrDPTnti00CuWlbH7wuqYO73ozNgVsv1KTHX0WlFehxvD4th0zMBNmBltEbslvBCb 5bx7woexX+CXuBezw8vie7kiFt6tiKMYY1CCUpRhLMpRgQQqsRE2xiYYh02xGTbHFtgSW2FrbINt MT4M0HCAhgM0HKDhAA0HaDhAw4GKw8Liion4Gg7H13EEjsRROBrfwDdxDCbhWzgWx+E8cZyPC/Aj /Bg1uBAX4WJcgkvxE1yGy3EFrsRVmIqrcQ2uxXW4PrwcFcuc5VRcSsUVsQfCkFyaGYblyWh0Mhdy XMhxYB0H8hm2woqTteJknZGlco7KOStM1gqTtcJkrTBZK0zWCpOlfo76OernqJ+jfo76OernqJ+j fo76OernqJ+jfo76OernqJ+jfo76OernqJ+jfo76OernqJ+jfo7666i/jvrrqL+O+uuov47666i/ ziqXtcplrXJZq1zWKpe1ymWtclmrXJa6OermqJujbo66OermqJujbo66OermqJujbo66OermqJuj bo66OermqJujbo66OermqJtTc1fL7nwtTqPpDbJ7ZrQRtXuo3U3t1dFlNK6ncb1M73PmAlr30Lon dr3X08IqVw3L/LTMT8v8tMxP8+FTPtTzoZ4PQ7G7wzsqYJkKWKYClqmAZWrpXb3hbR618KiFR/U8 qudRPY/qeVTPo3oe1fOonkf1PKrnUT2P6nlUz6N6HtXzqJ5H9Tyq51E9j+p5VM+jeh7V86ieR/U8 qudRPY/qeVTPo3oe1fOoh0c9POrhUQ+PenjUw6MeHvWokLQKSauQtApJq5C0CkmrkLQKSauQtApJ q5C0CkmrkLQKSauQtApJ87iex/U8rudxPY/reVzP43oe1/O4hcctPG7hcQuPW3jcwuMWHrfwuIXH LTxu4XELj1t43MLjFh638LiFxy08buFxC49beNzC45aohoNJDiY5uIbfb3BxNefaOfcx5wY4N8C5 Ac4N8D/B/5e4l+ZeOnaHY3dxelZ4noN9HOzjYB8H+zjYz8EhefIaF7u42MXFNBfTXExzMc3FNBfT XExyMcnFJBeTXExyMcnFJBeTXExyMcnFJBeTXExyMcnFJBeTXExyMcnFJBeTXExyMcnFJBeTXExy aYBLA1wa4NIAlwa4NMClAS4NcGmASwNcGuDSAJcGuDTApQEuDXApzaU0l9JcSnMpzaU0l9JcSnOp i0tdXOriUheXurjUxaUuLnVxqYtLXVzq4lIXl7q41MWlLi51camLS11c6uJSF5e6uNTFpa5oPy5l uZQtVOPnLoxwYYgLQxzIciB/3zRE3SHqDlF3iLpD1B2ibpa6WepmqZulbpa6WepmqZulbpa6Wepm qZulbpa6WepmqZulbpa6WepmqZulbpa6WepmqZulbpY6Q9QZos4QdYaoM0SdIeoMUWco2ktnWK8z rFf9aet5eewOUdwpisLsPX8As633D1m3x9vVbYftsQMmYEdUYSec55zzcQF+hB/DDpLWo7QepfUo rUdpPUrrUVqP0nqU1qO0HqX1KK1HaT1K61Faj9J6lNaj0Y9p3UfrPjNOm3FaFaRUQUoVpFRBqqD/ 3yuA7v+S+XbwsfxvNv7P2d7Hjz5+9PGjjx99/OjjRx8/+vjRx48+fvTxo48fffzo40cfP/r40ceP Pn708aOPH3386ONHHz/6+NFHwTQF0xRMUzBNwTQF0xRMUzCtGlKqIaUaUqohpRpSqiGlGlKqIaUa UqohpRpSqiGlGlKqIaUaUqoh9W9UQ4pDKQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJTi UIpDKQ6lOJTiUIpDKQ6lCmv8YOF/hTyEV2lepXWbtG6TpH2a9nmN0zRO0zhN4zSN0zRO0zhN4zSN 0zRO0zhN4zSN0zRO0zhN4zSN0zRO0zhN4zSN0zRO0zhN4zSN8zGmxZgWY1qMaTGmxZgWY1qMaTGm xZgWY1qMaTGmxZgWY1qM6Yp8LkzF1bgG8k2MaTGmo0304sz/rBmZdkeh0rN6avZ/qxF796vtUd2Z qraEaitRbStU2hYqrTya/EVHmWo1noYb3JfP9Fm3hUGZPejsnNoctDqPuOrLFM5SeOQfdk2DsntQ dg/K7kHZPSi7B/8/dZtB2Tco+wZl36DsG5R9g7JvUPYN/j/dFeXvVnKUeueL+5aRKL7hWI5Ln0Sn 07aBtg386+dfP23zdzbtnBhD31769hb63yyv73OPcL+d0mzHHgq9dO2lay9de+naS9deuvbStYGu DXRtoGsDXRvo2kDXBro20LWBrg10baBrA10b6NpA1wa6NtC1ga4NdG2gawNdG+jaQNcGujbQtUFO 9cupfjnVL6f65VS/nOqXU/1yqp/uvXTvpXsv3Xvp3kv3Xrr30r2X7r1076V7L9176d5L916699K9 l+69dO+ley/de+neS/deuvfSvbciH+dUXI1rcC2uw/Wht6Dx2g2VkIs2i82Ntoy9bsf5hrx8M0yP vROejq2xz8iEWbG1YXFc54zv4+513/BC/KCQ/OJfK58RbRL/bpTY8G8K+xId4T2OPW7cOXhDBbwZ mmPzZfpbeMdnLvC4KHTE3nOn2+zTWjy2oi8aG1ulUjP2uFk7oVGsC0PxKHwYL0UZtnH3v2/oie8f 1sQPwIE4OGTjE0N3ojqkE+eHxsRF0CMSP/F4WehIXA49IfFTj9M83gB76EQtrJiJu6AqE7O8f69j el/iQa9n49fGeDysTTxj/BfwYliT+ANecqzO65c9iimx2LEmLMEyr9vQ4XknPnRef/gwsQaj4cPK zcNA5RbYEu4OK90dVu7i+IWhsdKevtK8Km8NI5V3hTWV9+MhPBYGouM3qNrOpxxVl1G1n6r9VF1P 1ZVUbaPqMqquoeoyqi6jZpaaw9QcpuQwJYcpOUzFtVTMUDFDxQwF+ynYTsFlFFxGwXYKLqNgGwXb KNhOwbZ/UrCdgv0U7KdgPwXbKNhOwXYK9lOwn4LLqNdPvX7qZaiXoVw/xTIUy1AsQ6kMpTKU6qfU MKWGKTVMqWFKDVNqmFLDlBqm1DCllm1Qqp1S/ZTKUCpDqQylhqOdYs+Gn8bmhhcpVS8HP6HQk1T5 OLY8/EieTY2tCo/I7jNiI3baa8PX5dnb8XiYHy8Jd8cT4VLZ3hLfPFTFJ0QXxHcNV8n8neJfDkdT 7THZP0nOPRz/erghflQ4a8O/zuqKfzc8Gp8SLozXhNfy/35JVH/Rk163SryJd8LffOJH/FjuE5M+ YZVRB43YbcTVammiWjrcHeGzHHs9NLkqXy/vFmqkL9rB1UtcudCVK80taW4VRmgu1MNBodmVr4eF rvrIVf/lis1cscLndRXq1111oYYnqNN9vN43LHfVh2Y5P9peZq0pXDlfZr2FBTJmkavfk1XNdpEt HlvDStmxUnaslBkrZcYKmbFCVqyQFWtkxRpZsUZG5GRETkbkZMQKmZCTCTmZsJJzKzm3hmv5zt8X bWQ+JWb+uM971uf+WawvY0FYR9dOeiYT14as8YeNP2z84cRDXv8mZI0zHBW7asTMr3BFdz7v7YSf 1UvmiuXNsNjRjliTPpLXcHlI0a3JuMuMuyya4lNnOXu6muopZMufwzSfPs2VQ5RYR4l1RuihRKDE yIa6GqHESKwtzDFinUxaHEvLnnJsHs6Pb8mNrbA1dg5XxnfBruHj+B583hP7cI/u8SO8f1Th3y7v bzb7q70e6o5Qd0Tt9VB4hMKBwkHt9VBhGqUDJWZRYhYlZqm/Hmqvo/Y6aq+jdlB/Peqvh+rrqL6O WtMoP0KxaYnndaI5eCVcmZjv8V004j18gHb8zXtdHlcYoztcWRmFtyvHhDmVJShFlde74UIdakaY pQZ7uLmu8oHQXfkgZuNX+M8wJ6qQkcOysZvTB+o+n+o+n+o+n3L9UJX+qUr/VKV/qqo/jbbjR97L LO0HaT/oqhI9akiPGtKjhsQ+IvYRsY+Ie1Dcg+IeFOugWAf1lyH9ZUhvGdJbhvSWIfk9pLcMmeuI eQ7qFUN6xZBeMVRU7hNnyIAHuD+P+7/k/i9jr3G0Hq+Hd2LzrYpv4Z3wmCz4JLbE8Wa51Ramxj4I r8ba0YFO/A3Lw62xLo/d6DHmSo9J9KIvmiFb6mIpzz9GWub1exzA6nBlbBBDng9jTajRmxbr3G06 d5sKPkOPei/2iffW49PwWuwzj8EqXIQY8v2rWLaN8bxEnyoP0+MVnifCJYV+trHHTTAOm2LzMFG2 Hitbj5Wtx1pbb4lvG66Jj/fedpgQfS9e5XEn7Kzn7YJdw/fju3m9O/bwek/s5fmXsE/4hh75Q53l ea7N4NoMrs2Q7Sfql3fFD3HOofhKuCn+VY+HYWK4Mf41j4fj6+E/VMWx8SM9PypcoTLO2PAvZp9X IdfEz4y2jp+NmvC+/vr7RE1YnLgQl4VPVMknKuSXKuQTWTJDlsyQJTMSM7x/E36O23A77oy2TNyF uzHL+fc79gAe9Ho2HjLOw17/xuMj4ZLEb/EYHg+3JJ4I11jNbkw86/Vz+D2eD5NU1SQr3I0ycIYM nGF/cItV7sbEH8NNibn4L+e97NgrznvV89dQ7/h8r99xfIFxGxxbhHcda8R7WGysJizBUucvc24b PvBeO3Rv2T1D1U5KLA+vqtxJVtEbVe+xqndSoscxOZiQg4mPIA8TfVgV5iXkYUIeJtKQg4nVGMSQ DjCMrOe58FpiLdZ5/inkXELO6QrTK+VdpbyrjIfXKos9jglTdYmpusTUyjKvx+oe5ZCDlYkwr7IS G3m+MTZxfBw2xWaObx7arPRtVvq2yq2Mt7VztsG2GI/tsL1zJ3h/R1T5/J0c02F1o+mVN4bFKnxG 5a3RlpW8ruR1Ja8r78CduMt794ZrVP4MnWqSTjVJp5qkC8zQrSZVPmyc/zTvR4z5mPEf9/oJPImn wpVRlS5xhS7xh8LK/EZhPX9LJ+hV8bNU9n+o7Lmq9gVVu9Cam1Gxf1WxPaqySTU2qMLXVOFSVXeM yjpbJb2gYu5SMW+pmF5Vcr8qWaoK6mX/E7L/JNk/T/bn/1LhEBn/fnSOfvWMmfzeirUk9oJVaq6e 8GfHXsYb1rk3vTc/tOqerVaueXpWv5VrrjWw32xXWb3mWr3m6l+Pm/lb+tQqM39PL5pv1m36Tbd+ 023mvfp1s5mv1rOb9exm/WS+2T+vFzyvFzxvlp+Y5an5PY/Va0nihzrt+WGuFWyuFWyJFWyu2uxX m/1WsCXq8xn12a8+n1Gfz6jPZ6xgSxIzXXcz7sCdoVVXb9XVW9Vmv9VsidVsiQ7fqsO3qs1nrGZz 1eYzaul5ef+8PH9eTq+ynjRbT5rl7SprSrNcXSVP58vLx+Xl4/Lycbm4Sq51y7VuudYtt1bJrVXy qltedcur+daiZjk13wo3V049Y4VbYuVolR+Py49V8qPbDvI1eVCP1+3Q3gl/pvRKq0OTXDhaN+/U zTvlwyKqfkjVxVRdLCf+pHMvp+wCnbqTsgsou0BufCw3PtKNl+rGS3XjpXLkS3JkVJdt12Xb5coH 8iSpszbqrI06a6OcadFNP9BF23TOpTpik47YRPWVVF9J7ZU6YJMO2KQDNumATTpgE2VX6npNul6T Tteko7XpYu26WLsu1qaLNepijTpYmw72gQ72gW71gW7Vrju1607tulO77tSoOzXqTo260we6Uruu 1L6hKzXqRu26UZtutJQ7C3SWTp2lk0sLOLRAd1muuyzXQZbrFp26RafO0KkzdOoMnZxazKnFnFqs KyzXATo5tZhTi1V+J6cWqPwmFd+k4ptUfJOKb1LxTSq+UbU3qvZ21d6u2ttVe6Nqb1ftnVxcrMo7 VXmnKu9U5Z3uifvsjvP76oPC+uhgVZa/z7pIRc1WUbNV1Bt8nq5q1vL1Sb7W8bVOtaT42sPXOTyd w9M5KiKnCnK8mM6L6Sogx4/pMj4ny2fL8tmyfDYvpsvynCzPyfLZsny2bF5Lrzl0miOb19JqDq16 aNUjq9fSq0cmr6VPHX3q6FNHn/8m7kygo6jSvn+rbnVVdXWzCCGssu8uLKKOKMZxMi4j4DCKg6CA A8qACYICAiGgjssoKosKyCI4IEZ4R5A4KosrwzAugUAaKDoEIxAgnabCkpCEhL7vr9rMfM58835z Zt455zuc36mu6lv3Pve5t57n//QJ3UfZzTXs5hp8lIuPcvHPu+zeanbvEnZuDXPOZY7b1Uvs2Cpm 8DFn57C9Uq1jbx4WrZjZOc5KmFkpMytlZqeZVR5xIMbM8phZHtadw7o8rMvDunNYl4dV57DoHBaV YlEpFpVizTmsOYc1pVhTijV5WOHXsqWiHSNVMtJBRiphpBJGOokP/Ro1n9EqGC2f0fIZrZLR8hkt n9EqGS0fX5zFF2cZtRJfnGXkSkYuYeQSRi7BF2cZvZLRKxm9hNFLGD2f0f36sIQa4TDx8pzazax3 M3IFIx4ilm0m4h4g4vr1wYfJiGvSqqK+horV/x+mXnKY6Jv0XDHvHOKd4uSZX9vVJv0YqL/rLGdx +t9P/2dQwy6aNo6HLzBPB08ICKBJTbCgA+ddYYU6TR+Hkyuzh9aFZBHfxgrRlT528M5H+O8sfW2h xfG/1PfJfCOILxbY4KgtzGoIsxmDH8/ix8P48TB+9Ovrw/jvLDZswYYd2LADG3bgy7+tu1tDmx/U 3x1o35lnsSvHFbRfyTW/5taYsyeaY98ZbDqDTWXYVFb/CU451pdiVzl2lWNHOXaUY0M5Y59h7DOM fYZxyxi3jHHLGK+M8coYq5xxzjBGmehM71uZ/Z+Y+Z9/EGUj+Pn3jHQ+GVWd5F+KPFO/lgeZ/Xj/ L3r+En2Y8Z8ZdSujbmXUrf8w8viRpgPt/CjTlaMfMVbQ9u8jRjCZRc+hA2qorU3WdaiaVP/XHbsZ +d7kX4z2xe7DtPyQVcujLtiP/Z/ipQ0/iCB+ZnDx1ArW2s+7x/HWCry1gvl8Sq9z6e1dVjEP7bYf D67AgytYyTy8uIInwuWJcFnRPOb3KU+FyxwPM8fDzPEwq5qHBtuPBtuP3tr/d5HDZZXzWOW8v0aO DvTRWa1g7p8y78Oscl4yerTG64V4vTD5aUQlUaRGbcfqU3i+EItPYbH/Gc4pvF2Itwux8hQWnsLL hXi5EC8X4uVCvFyIlwvxcCEjncLDhXi3EO8W4t1CvFvIU1VJ1L1A9mP3sMMq1adCJwteQCnVCIka 2cnZGc5OiA6cedQw1egTD33ikSmryJRVZMqq+s8IY2iW0+j4ajJejEwXI9NVkemq0OvVZLsYGr0a XeGhyavJblVktyqyWxW6uxrdXU1mqyKzVaE7PDJbDO3hkWmqyDRVZJcqESSX12DJcnK3R872dd1x RvVYwdWs4OpkVAmS7StkCpHkChVnBqW0isurRSMiDDWP6MM4rjDo5xj9+J+5VvszYMbh5CcIMb89 nkjhebpaVXPd/1SWFtx3RDTjzJ99BbOvYPYVyZkP938zU+37wcwrmHlFctb5HPfAXiiEQ8DsmFkF M6tgZhWiPaPtwr+V+PcA/j3ww8qcseOMUoJvKxmhhBFK/lqNb0p+4leCbyvx7QF8W/k3FfoBzt3k p4DJSh3fHmD0Enx74IfVutCYeaXoLBvwKkWtRC15qCUPteRh0wfY9AHeqkQxlaKY/E/XTuGnMpSR xwrUsQLrWYH11JFNqCP9v470VU8pqqcUuz5A3ZSibkpRN6Wom1LUTClqphR7PkDJlKJiPGz6AEVR iqIoRVGUoiZKhYU17zHyOUasZsRzjFbDaF8z2teiE+9+h99OYONBbDxIy/P1n2H/nxW6GmV3Pfv6 x/hhjTqBDy/gwwt/XaVNXMvlfDPHrSitnRx/uGoHOHfhL6tXRJti2h9RB/9mFVPxWjFeK8ZrxXiq GE8VY/e39Z9JFeORYjxSjDeK8UYx3ijGG8V4oxhvFOOJYjxRjBeK8UIxXijGC8WiFfMsYo5FzLGI OZYzxwhzLGCOBcyxAKXq77oC5lOAqoyhKmPMpQhl6e/AAuZSwFwKUJIx5lHAPAqYRxFzKGIOBcyh gDkUJP8XZSc5SnQSS8RY9bp4EB6Cx9QqMVMtEFkwC7JhNhxVS8QxKIGztKlR88UFqIU6uKj8Xw/O 13pAT7gMLocr4EroBb2hD/SFq6AfXA3XwLXwI7gO+sP1cAMMgBshDW6CH8PN8BNIh5/CLXAr3Aa3 w8/gDhgIg2Aw3AnjRXPtM/Wp9rn6UPsCtsMfYQfsVB9rf4Yv4Sv4Wn1srFQLjFXwJuRxvgt2A3M1 EqDU/EBj9XqgiVoSQGUHUNkBVHagObSAllCsFgTitDkFp9UCswdcAxnqdTMTJsIjMFWtMqcBfjfn qXwzX31sUvFYXdXHVjforj60ekBfuIrzG2C4WmKNgJFqvrUY1kAx59/BEWDNrFK1yopBOe9VcH5e zbd1lW9LMCAAJqAUbZSiHQQHQhCGBtAQGkFjuASaQFO4Tn1s94dRvH6I4xMc3+aYoz60K1V+kL6C TdHH94smapdoCkQ/0QxSoTl0g+7QA3rCZXAHDIRBMBjuhJ/DEPgF3AX3wL0wVi1n5y5n5y5n584W U9QKMRWmweMwHWaqHHZzDrs5h92cw27OMV5Qu4y58CK8BC/DPJgPC2AhvAKvwmuwCFZy3yp4U+Ww 6ssDB9SuwCEogm+hmOvHOZ6AOO+fgtNcu6h2mSZYEAQHWkBL6AJdAT+Y+IHdkWP243gNx+s53gr3 w0gYBaMhQy1n5yxn5yxn5yxn58xm58w2ma/JfNlBOfYjvm/EApUvFsIr8Cq8BotgLbwNOfAOrIOv 4Gv4BvJgF+yGfNgDe6EAIrAPXDiqNhETNhETNhETvhTnoAIq4TxUQY3aQJzYQJzYQJzYQJzYYJxU +UYpxKAM4kB1YnhQDqfhDJwFKhajAvz7EqDUBp63TRaxwOLZt3jWLZ51i+fcGqy+tO7mOBSG02YE jFQbrIc5nwJT4XGYDrPgWXgOeN4sfGThIwsfWfiI52mD9TuOazhu4LgV8IOFHyz8YOEHnrVNPGub eNY28axt4ln7kmftS6sM4lDOvRVcxx88dxu0K4UhLhEBMMECG4Lgf3t3CML+V0xCQ+gvUsX1MFZl scez2ONZ7PGp7PEJ7PEJ7PEJ7PEJ7PEJYgY9zFSZ7PNM9nkm+zyTfZ4pfiMaiafhGXgWnoPfwvPw AsyFF2GzaCu2wFE1kxWdyYrOZEVfZUVzWNEcVjSHFc1hRXOE/w3SNSqbVc1mVbNZ1WxWNVtbqvZp y2A5vAErYRW8Cb+D1bAG3oK18DbkwDuwDtbDf8Hv4V3YABvhPdgEufC+2qf3Fo30PiJV78cxDW5T Wfrt6jH9DhjC+Xj1pD5BZegPQ4bKQLPdIUeoKei2O+QojlPUV3Kq2iPzRUDuESmyANW7j6p8v3Dk UZUjj6FFSkR3eZzjCf+7gTiWiSbGFHGJMRWmweMwHWbATMiCWZANs2EOrFSZxItM4kWmsVc0Mgog AvtgPxwAFw5CFArhEBQB/mS3Z7Pbs4k1WYFL1D52/UxiTGagTDjElyziSxbxJTNQKy4xJbC3zCbQ FDpBD5Vp9uTYB64SqcSUTPNaXmeoLOJHFvEji/iRRfyYSvyYSvyYQPyYYLKXzJnAXjJfV/vMpcn/ Qb/PuhTaQjtoD31gsMrhSZvJkzaTJy3bmiwaWY/CE/AkLIDFXF/J8U3Rlqcp21rP62LafwdHgD3H k/MqT86rPDk5PDk51ikRtDwop30F77P/eIKyrSrRyE5R++xmkArNoQW0hFbQGtoAttrYamOrja12 B+gInaAzdIEx9DUWHoRszmfDHLUvqKl9zjD1mDMcslWGMwd4bhyeG4fnxuG5cXhuHJ4b5yV4GebB fGC+zkJ4BV6F12ARLIYl8DoshWWwHFbAG4B/nFXwJvwOVsMa0SiUBbMgG2bDHMC3IXwbegp4vkM8 3yGe7xDPdwg7Q9gZws4QdoawM4SdIewMYWcIO0PYGcLGEDaGsDGEjSFsDGFjCBtD2Bi+TDRqGAQH Qv4vQ8rdPClHiUb+K/+7R5rrjxPNwslfF/B/5MICG/xfbHcgBOHkN9iHiWZhFEAUBRBFAURRAFEU QBQFEEUBRFEAURRAFAUQRQFEiXxNiXxNUQIxlEAMJRBDCcRQAjGUQAwlEEMJxFACMZRADCUQI0qO I0qOI0qOE79WnhgPE+BhyIBMmAiPwCSYDI/CY2o8EXUSEXUSEXUSEXUSEXUS0TSdaJpONE0nmqYT TdOJpg7R1CGaOkRTh2jqEE0doqlDNHWIpg7R1CHvHiLvHiLvHiLvHiLvHiLvHiLvHhL+5x058A6s g82iJZG3JfnXI/965F+P/OuRfz3yr0f+9ci/HvnXI/965F+P/OuRfz2i9WSi9WSi9WRxglr2JJRC DMogDqfAg3I4DWfgrFpMZF9LZF9LZF9LZF9LZF9LVJ9BVJ9BVJ9BVJ9BVJ+BpnfR9C6a3kXTu2h6 F03vouldNL2LpnfR9C6a3kXTu2h6F03vouldNL2LpnfR9C6a3kXTu2h6F03vouldNL2LpnfR9C6a 3kXTu2h6F03vouldNL2LpnfR9C6a3kXTu2h6F03vouldNL2r/VykakPgF3AX3A1LVYRMFCETRchE ETJRhEwUIRNFyEQRMlGETBQhE0XIRBEyUYRMFCETRchEETJRhEwUIRNFyEQRMlGETBQhE0XIRBEy UYRMFKGWyKWW2EYtsY1aYhu1xDZqiW3UErnUErnUErnUErnUErnaN8LR8mAX7BYOWSxMFguTxcJ6 f///qHL8Ccfb1Byy2WCy2eBkNhuh4vpYGE92+0FW0zNVnMw2gMw2gcw2gMw2gVp8nnxM/V5uVV/I T0RD+TnZbzf1/B7q9ALRnCwXI8tJeYD6/vtMFyDTdU5+x2SM62VknikiTJYLk+XCZLkwWS5MlguT 5cJkuTBZLkyWC5PlwmS5MEo6hpKOoaRjKOkYSjqGko6hpGMo6RhKOoaSjqGkYyjpGEo6ZixWnrEE XoelsAyWwwp4A1aqdDJnOpkznborl7orl7orlyzqkEUdsqhDFnXIog5Z1CGLOmRRhyzqkEUdsqhD FnXQmR4600NneuhMD53poTM9dKaHzvTQmR4600NneuhMD53pGZUqbpyHKqiGGrgAtVAHPBNk5hlk 5hlk5nFk5giZeTL1n0v951L/udR/LvWfS/3nUiVEqRKiVAkxqoQoGTw9cEx5VApRKoUomXwcmXxc AJsC2ERGTyejh6kaooEE50p5pgANdJAiTKYPU1FEqSiiVBRRKooomT9M5g9TWUSpLKJmG9peCp24 1oXzrkCspcqIogzSUQZhszfvswdRB02pOqIohHQUQpjKI0rlEaXyiFJ5RKk8olQeUZTDOJTDOJTD OJTDOJM4ahJHTeKo+RhMgalqPGpiPGpiEmpiEioinXrWRUlEUBIR843kNzKlmhvh/eS3MqWaOzjm q1xURsRkLal7XbNKpKI4IiiOCIojguKIUAvnUgvnUgtvoxbehgKJUA9vox7Ota4XDjVxLnWBR13g URd41AUedcEhVMpa6gKPusBDrUxGrUy27lNx634YqWZQH3hWBq95pqyJ8AhMgsn0+SgwL2qHQ9QO HrWDR+3goXAcFI5DDeFRQ3jWC7Sfm/xWQQ/V41BPeNQTHvWERz3hoYJmoIIcVFBL6goPJTQDJeRQ W3jUFh61hUdt4VFbeNQWHgppMgppMgppMgppsnWMvkvgOBDrLWI9qmkxqmkxqmktqmktamkGamky amktamkGasmh1nep9V1qfZda36XWd6n1XWp9l1rfpdZ3qfVdan2XWt+l1nep9V1qfZda36XWd6n1 XVRXBNUVQXVFUF0RVFcE1RVBdUVQXRFUVwTVFUF1RVBdEVRXBNUVQXVFUF0RVFcE1RWx+2LTVXCd yrX7wyj6HsP5WHgQHuLaOI6/hvEwAR5RMRRaBIUWQaFF7Ce4Zx7X36Ztjtpmv8PrdVCp3KAQqSi4 SJC5BZuq3GAz4Th3qaPO3XAPDFODUXaDnft4PV3FnRmQBX9Rek/y+hl4ToRRfGEUXxjFF0bxhVF8 YRRfGMUXRvGFUXxhFF8YxRdG8YVRfGEUXxjFF0bxhVF8YRRfGMUXRvGFUXxhFF8YxRdG8YVRfGEU XxjFF0bxhVF84f+Pii/8N4qvmXhZ3aCNFIO00eIu7QExXfuV+Kk2RtygjRW/1G8Tw/Tx4h45VN0s h6kfyy1qrfxEDZJH1JdowxRJhJPH1QJ5Uu2UpaK1jFFvlanzop14ObFdrFd7xR/VXnq/sf7bYK+h 98vo/TJ6v0kbr86TW0sYhWqOqmyo6s8oAxhlqtymtsqP4ZNEXH6m/kCOOyC/UDvkdvUyoz/NyNWy RJ1g9P6MPo/RJaO/wejbhS13qTUyH5uo5OVeNUYWqM0ywl37VSFZsQidul79Cdv+RMt7yZ27aL2Y 1llybyJB6zdpfTt59A/c8Th3LE1+t2MvrM0mm19K9r5dH0QmH6/G6xOF1Nehk7erX+k71RL9sLha ryQjp4hGspd6S24TYbJ0L2bwHiPtpB6Vci+15j71Plk6QO8JZhQhU2fVZ2pZX5NKZnZCljKrGNfL 1Cntl8JQm0UATLDAhiA4EIIwNICG0EhtFY2hvyoU18Nv1EbxNDwDz8Jz8Ft4Hl6AufAivIwPN6s9 Yovao+mqUJNgQABMsMCGIDgQggbQGC6BJtAUUqAZpEJzaAEtoS20g/bQATpCJ+gMXaArdIOfqyJt CPwC7oK7IRtmwxx4Ap6Ep+A38DQ8A8/Cc/BbmK8OagtgIbwCr8JrsAgWq4N6b7VR7wdpMER9pD+v ovoLKsouH8qqxNlndeyxjaxEnD12J3usTp5PnJRVPBHVypI1iSp5IVEoa5Up6xIn5EWVJhNcV6ql EUicNEx1s2Epy7ATVUYwUWg4yjRCiRNGWKUZDbjekHZT1GZjKkyDx2E6zICZkAWzIBtmwxz4nSo0 VsMaeAvWwtuQA+/AOlgP/wW/h3dhA2yE92AT5ML78Af4SBUZm2ELbIVt8DF8Ap/CZ/A5fAHb4Y+w V200CiAC+2A/HAAXDkIUCuEQFKmNgVq12ZTA/jUDaqvZhGNT6AQ9oQ9cpQrNazm+qIrMRbCEc+Zp vsVr5mMyH5P5mMzH3MC1jbAJcuFD2Mz1LbAVtgG2m9hufsXrr+EbXufBLtgN++GAOmhGee8ElMEZ OAvnoAIqoUoVWQ2hETSGS6CFOmi1hFbQGtpAP1VoXQuT1UbrUXgCnoQFsBLeVHus9Ryr1Ea7myqy L1OF9pUce3McDHfy+l510B7D+2PhQXie60u4/joshWWwHmrVwaBQRcFLOPJ8BXmugq2gjSp0xqio MwEyYCJMginA8+7wvDs87w7Pu8Pz7vC8Oy/ByzAP5gP2OgvhFXgVXoNFsBiWwOuwFJbBclgBbwBz dFbBm/A7WA1r1MbQz1Q0dAcMhEEwGO6En8MQyFIfhWZBNsyGOfAEPAlPwW/gaXgGnoXn4LfwPLwA c+FFeAlehnkwHxbCK/AqvAaLYDEsgdfVR+HL1MaGQfVRQwdC6iNhkCs2Evljcp+4krhcJ14TM9Uy kQWzIBtmQ42KUj9HqZ+j1M9R6uco9bNH/exRP3vUzx71s0f97FE/e9TPHvWzR/3sUT971M8e9bNH /exRP3vUzx71s0f97FE/e9TPHvWzR/3sUT971M8e9bNH/exRP3vUzx71s0f97FE/e9TPHvWzR/3s UT971M8e9bNH/exRP3vUz57/LVzan7Bzp4pTs8apWePUrHFq1jh16BLq0CXUnQXUnQXUnQX6GnUy +feR3//V0Xd6lfqObOaSxZbJ3aId+bKYDPYiNdwyarhl1HDLqOHi1HBxaji/fopSP0Wpn6LUTB41 k0fN5FEzedRMHjWTR420jDpoGXXKMmqSZdQQy6ghPGqEOLWBRx0Qpw6IWz1V1Los+X2ccbS/r+Wj 6Owo2jqKFo6igaPoXw/966F/PfSvh/710L8e+tdD/3roXw/966F/PfSvh/710L8e+tdD/3roXw/9 66FX4+jVOHrVQ6PG7an0/QSv3/a/NU156E0PvRkPpvA8DVNL0JhL0JQFaMqCcLY6GZ4Nc9TJBinq uwbNIBXaQXt4kuur1XdCJ6v8F3kdHSe3iOvkVnG//FT0k5+JFvj3Q/kFSmq76CZ3icH4ejB1fQDF cCO1fRMZEX3x+7coh7bonCNcPSp6ohcGoxe6ypPiFvr9ov6z7MsY6XO1nvavJMfcyHsTUBVbRUOu fcnZbv97Kf/v79LVxou0f/x9utjTh6fjBkYdSD68HRu+v9KHbFnF1ZvJllvJlrHkdxSX+b9GydU2 nN2Y/EyxOW27YIP/WwTHxRW0uJKz3SKNGabwXlvm6n/r2zCVJ6eI/tj/hTEAvaZz5c+cfU1rchOa sJyzIs4yRAPOLnD2Z9FNGCJNBMAEC2wIggMhCEMDaMiIQ0UzORyNNxIymNNWdOBn6MzP1R5jikgz psI0eBymwwyYCVkwC7JhNswRadTyadTsadTsadToadToadTkadTfadTeadTbacnfv2iAuq1gpCJm cVx+ykr6v2byufoAdVvG3Kfgky3Y9TGtmC1zbyCaaPmik7ZH9MYzI/HDT+RwWo0QI+TI5HfMjZAZ 6nP/W4nkNHVELhLXyMXiWsbxWOkuKJl3jetEX6O/6I23Roi23NGWcfqxmlNEe0Y65Y+fHKlB/e+a 7JT3cff9tB/N8QGOU9hh+eogGjmOPq5J7p/9wuYuKUz/l1BonUrLVFoGaenRolykiqNEUTSUKEE3 PcpI/ppOUwXo7jir3oiIuyfZX4QV3Mdd9Okr4kATVUcNX0cNX0eNXEeNXEeNXEeNXEftW8eYQ9VJ /3880WNPnhQr2ds+VSGa/82Y9xGzRkMmc5uCEt+tzmBdOfPw2HHNGLuSu3Ywbohxq//puCHGPeL/ Ngu9NWHcAD1W0mOcHivoMUhvZ+pnUcdzNpSr/vcF3oeSHw2P8s4U0ZI7g1hscud57qzjzgbYkvC9 xp21PBVHxa3iGJRADTv7AtRCHVwkOgylchmmesv7iBb3i1FyNMcHOGZS+zyKPdPUajmLfbFI/Ij9 cAMez2fE/sm12atWJEeLqP08cylUORfq90hfg76NBCjRLdBE3GoNhxEwUnSzFsMaKOb8OzgC2GmV c62C43ls87//sRzLaphzDZb1ZN41WNaTebdi3n7EsJmvw1xPyAOicXLXbeOOL7jjGHe04o5j3NGK O35E68bYfDy58/aqWuyu5s5jybsiyd8lGM54I9jJIzmO4jiVqHhEdCTilRNjHCJjSyLjJcS7bclf 1PHXL0oryZVy1mEor4Ylnw3/2/BS5WPsqsfJd8ex+yQjliovud+Kue8Y9zn0btOzzjtR0VKMVWfE g/AQPMbqD2U9h2PXSJjKzvRbH2WXHMfTJ7CplPoyRi9l5MkBonmgsToTiMMpdcbMgEyYCI/AVJhG vw3rfxPIpecoPUflY8xqKjH/COt4lF10jCcoOVvi8El8VKq+SdbizbGvFvtqsa+2fvb+Z8qH6eUw vej00hMbG9NLFb0k6MX/pnmbHr7zf48I+2qxrxb7arGvFvtqsa8W+2rFFWKsGCgehIdgpkgXWTAL smG2SGfERox4OTErgIeHELMCeHkIMettPL0JT3/MPt3JPr2dfTpQrlMLmNPXZIiu31tD3vKtOYma uE70Z4/2NwYo11gp0o1V8KZIDzQWAwPFHOMcT8FpkW72gGsgQww0M2EiPAK+fTZWna/fN3r9vtGT a+V7sFSdSH4a8S52r61vlVrfKhW7PVr2TX4CUaoK2BkZie3Ugqeo/Yqp9U5R2xUb3RMl7LWMhMfV cq6UG93VjfSakTgsz+PnWu6uIzZcVLuMgKqiLqw2QqqClrtoeUvy3s95dw9X9nDFSd7ryQuMV4tX Lqp91JgJIyhM7k3Qah+1ZIKWacSljMRxRklQpVZgWVzWcKxl1Dp25vd31jFqguq0Aovjhs3RwYoQ 17/vqY4ZVLLrMqhrq4RGL+X0kqAXRQ8nk2ObQuPucu5OcLfizpP1NvTw/ZSYjw1HuLsTdxdy93l5 gSfWt76OfXyRHZdAJyh1EVuO0Fsneiukt/NGUEWSswqxzmHRmEo5Rs8Xsen3fhZVOj1WY0eRTAid u6oZu8howOvuqoPfIrGbFicYz/dUlBYn6NP3UpQ+TuPdv1svVr9+nbj7n6xPsm1yXWj7T9aDOf4v 14F4+i/6nyjzH/Y7c/wf/J185x/6WTQ0UkTQaIZ9LYRjtKK31tzTBs1wKa/b8l473uvIe50578J7 XXmvG/nAMFIZoTXvtufYhTUJGymcUUMYzRm/FSO0ZiS/r7Zcb8f1DlzvzPUuXKcfVsFv7Y/cur6F P5LfVxPs0nm3xEjlSnNoIdpiXxNaltBnW+zTsU/nrhKjPe93gI5c70ybLlzryutu/q+S00sRtvoz 1I2W2NpKBOp78e8uwn5/hrrRifc68973d+vMNwWasfdSsbkF/bZiLq1Z/TaMdak/L95vx/vteb8j 73fmWhfe78r73Zgfs2BtmtFvKlebQwu1HxsSeOeI0Ya1vJQ5t6VNO9q05/0O0JE2nWjTmTZdadON zOavUzjp1xYiBTt8j1VjRwp2hLAjnPRtR847Jz1YjQ0p2BDyV0XI5Nxb1fv5e+t978nkvL+/o7ze al00+nf3BE+th//+bl/wtPcSDf7VvcFdvYX1P+0P3u0imv6n9gi9Xc6s/819wt3dxSX/271CL9f5 M/rP7BdW4qvkOv5beyaZGxr8q/smGdW7y/OJUiLpaCJOG6LaIHkhUU5U+6msS8SIPmOJau2Jav2N QKKUiDqaaNSGqDbICCbKiWo/NUKJGJFpLFGtPVGtv5GSOI9HrsAjPfBID6MF5y3V5XikIVb1wStd 8UoXoy3X29GuPW06QEfOO9GuM+260K4r7bqxa4JUbmFqrjTp/67PdtEUtZuC0u2MqvgRWmEHaq9R 8reFtmgjxfXaaHGL9oCYq/2K4xgq96FqubyHWuSXagvKY3nyl+p6/D9a7Ui28n8D6UDy6l/ONv71 TKeS/0T7TG1MvvJ/3e4IrxpRJV8hhOhPTdpT/Jh/vcUd4i7RR9wjfsnVe9FyN4hfixfFz8TLYp14 RGwRn3D2Gf8WiK/EfrFQuPxbKYqoTlaJE/T4jtZaay32am21K0SBNlAbJI5qd2p3ixJtuHafKNNG aaOEpz2gjRXlWoY2UZzTpmpLxHltKf9aacv511p7g39ttHe0ddql2mfabq2d3lvvq/XS++nXan31 /np/7Rr9Rj1Nu1b/iZ6uXaffot+iXa/fpt+h3aAP0gdpN+lD9Lu0H+v36MO0dH2EPkK7VR+lj9Ju 08fqD2q36+P0cdod+nh9ojZQf1Sfpv1Cn64/p/1Sf15/SRunz9MXaRn6Ev11bYq+Rn9Pm6bn6ju0 p/Wd+n5tse7qR7W39VK9TMvVy/XT2gf6Wb1K+0iv0Wu1T3Qlhfa51KXUtktLNtB2yEayifaNTJEp Wr5Mla20PbKD7Kjtl51lF82V3WQPLSovl1doRbKX7KV9K/vIvlqx7Cev0Y7I/vJ6rUQOkDdqJ+RN 8iatVN4sb9ZiMl2ma2VykLxTi8u75TCtXA6XY7QKmSEztYR8VD6uCzlLztJNOVvO1i25SC7Wbfmu fFd35PvyfT0kP5Qf6mG5WW7XG8hd8oDeQh6RZXpHeV4q/XIjYDTUrzFSjO76TcYAY4A+1JhiPKff Y7xg/EGfYHxkfKIvMvKM3foKY69Roq8yThpKfz/gBBz9m0A4ENbzAo0DTfRdgYLAQX1P4FCgWHcD RwNH9aLA8cBx/XDgZKBU/zZQFjitfxc4GzirnwhUBqr0k4GaQI1eFqgN1OrxwEUzoJ8yLbOhft5s bDbWE2YTs5muzBZmWynNDuZV0jGvNq+Wl5rXmrfKtuad5lDZy7zffEpeYz5tPivvM58358pR5jxz nvyVucBcKMeYr5mvyQfNxeZy+ZC5ylwlM8zV5mqZab5lviUnmuvNXPmI+YG5TU43PzW/kHPMP5k7 5W/ML8198hnzgOnKhWbUjMpXzcPmt/I184QZk4vNM2adXGYJS5dvW5bVXq6zulr95B+t66wBssC6 ybpJutZPrFvlQetn1mB52BpiDZFHrbutu+Ux6x7rHlliDbdGyePWGGusjFvjrfHSsx62pstya6Y1 W160nrCeNHTrWes5w7BesOYapjXPWmLY1lJrqdHEWm4tN5pab1grjRRrjbXGSLXWW1uN5tZ260uj u7XH2m/0sgqts8bVVoV1wRhk1VnKuNvuanc1htnd7Z7GvfaVdi/jPruf3c8YaV9n9zdG2TfYA4wH 7Jvsm4wx9m32z4yx9kB7oDHOHmzfafzavsseakyw77XvNTLtMfY4Y6L9iD3ZeMyeac80ptnZdrbx uP2E/ZQx3X7Oft7IsufaLxqz7Xn2POMJe6G90HjSXmQvM56y37ZzjN/a6+31xgv2u/a7xlz7rH3O eNGutCuNl+1qu9qYFyTwGfODRtAwFgatoGO8EgwHmxuLgy2DLY3VwdbBtsaaYPtgeyPHucsZbrzj jHZGG+85Y52xxibn1854I9d52HnY+IOT6Uw0PnAmOf9N3XfASVHk33+7uru6Z6Z6M7CBJWcQl7Qg GQRUUMGIp6IY8YyIiIoghlNRUVAU8CeS1VMQjCCgoCeYI0iUHCQjOUP9X31ndt11F3YXOL1/z2dq q6srzUzVq/c6vO3pfBTuE+7jTA/3Dfd1ZoT7hQc4M8NPhic5s8Ofhr9y1ocXhJc528MrwuudfeGD kXTnWKRyZIhbIfJCZKz7XGRqZJY7KvJjZJf7hvJUqvutqq3au8vVFeoW94C6TfWUIdVL9Zbxqo+6 XyapvqqvLKX6qcdlaTVQPScrqCFqiKyuXlAvyhpqmBoja6txapzMVhPUJNlYTVEfyNZqmpopO6hP 1Ceyk5qtZsvz1WfqK3mB+k7Nk5epX9Qv8mq1UC2W3dRStVJ2V6vVDnmz2q0OyD7qkDoi+6ljAckB gQiEfDRwAikfC/wgkE8ECUFpOShIDVLl0CA9KCtfDMoFVeTwoFpQTY4KBgQD5OjgkeBxOSYYGDwr XwueD4bKicFLwTA5OXg5eFm+E7wSvCLfDV4Nxsr3gvHBG3JanIiLkx/HJcWVkV/HZcRlyh/j9scd kvNIhMHfiVTbxC5UgyrQadr0DL1W/0ZZeiPivxaa45h+RU/B63f9NPa66KtQZi5iG2PHN+rNCFfH 9vYVKG+ObtZ78PrjmFdIO7vxfrHI/j6I9yf5UlaghdKmleNuUF7It0QfRlxhJb+aAuyvzd/HnE9T SJvf6VV6u/4eNazBp91QVB+LsfmodVis9nV6q56r18f2dhVofQvey/VKPV8f0B0phO+uFlXMc/xY UY3pvfjt9qCGP3qO7x+MJXr0Nf0aKbxzf8M/ld6G93q9FHWswK4LnlWNWiJWno/O0T/ohRg/GDvQ 7YW3/5Yep0fh70C8W+m6+l7dG7E832POp0dsa4HSx/QXegNG0Bf6W/QDv4P59vKXys37XRFfBUGn EsVx7LlYynbU/X3O2Mw7KmIpe/DJd+G7/1XvBt+PR1JD/Aq5rest/AttycldoPxWvQlzbHvON27O jPLfZXnzFNXvWL6l+fbuzrf3VfHqwFaP88dGml6E38/Xi4poeX+euV2PmhSRe5L+t5nR+oti9yl/ +d/M6DBjtsCRBcUojU+mn+DY1D/PZ319McpjjOgPGLdWmN+tpJt+k9H0TXyvBTe/WDX8rmcwahZz XBRSw67ij6pCSscQVs87qdLvcLjIIMdp3xoUo/3fomuZPoxxtLvELagTHq2O98XcSs6Ktzr6ih0v X0iZmniVx6tmvl6+Hvv7Y/R1gvL1Ci0f+3YxSvYCnfYer8PAz216JxBsFc8pM6oPcPpQPlxOf6pn 6V/Min6c8kfyxJ+hNOB/V+psZkgsbTnWhpkFsTi3zOE88SFYeeLpPOqO+ORY2lp8ez8ff1XNaZ9H 9MsoHwL69IohuUl/T08hW087bvk/j0IX7KkH0p+NHf9Kf4nv/5vYXkH8PpQn/jRKp9EFZJhQq1ja J3o6anj7uO2vKzz9GH4xg4/6In2hvlF3juUeXaD8o0Cx1/Tb+if9S55kQd3oMRqE2HM02DwzQ5Mw cifTNLDDmTSL6vNZhWz6nBZSY1pC66kTbbAsusLqbnWne6DoL6beRstTH6Pi6T5xq7iDHoAeX0z9 xa9iLT0kNoqN9KTYLLbQQKPN6WmxT+ynQeKwOEzPGW1Og402p+ehzSM01C5vl6cR9tV2N3rZ7m5f R684U52pZFStplFukptE38kP5Yf0vfxEzqIf5K9yGf0ktdQ0z2g6mm80HS32ungX0XKj6WglNF1X WmU0Ha0xmo42Gk1Hm42moy1G09FBo+noGDTdMxZBzT1vSW+oN8IKGU1nxRtNZyUYTWcleuO9CVay 0XRWKaPprGrQdLusM6DmtNXZt33Xusr3/bB1ja/8OOs6P9FPtm70S/llrB5+ul/WutUv51ew7vAr +1Wtnn5Lv5V1D1TbTda9UGcDrfuhzp6x+hr9ZT1oNJHVz2giq3/kwcgQ6xGjdKzhKkGlWjPVJDXJ mqPWqh3WXKM1rPlGa1hLjNawlhmtYa00WsNaZbSGtdZoDWuT0RrWDqM1rJ1Ga1h7jNawDhsdYR0x OsI6anSEEHGhuIjw4krFlRHhuANxh4S5prCIR4zFI0ZgxAyDohhO/4cx/QpNQMpreHn0Or2FVWoi xpPk8SQxnj7GrPsEoyrMoyqMUfU10r+hXyhCC/ASGGULwaqX0DKwq+W0BnNsLcZcRdpAOzHjd+FV iXbTfqpMB/CqQgfpKFWlYxiRiTwiM3lE2jwiFY9IhRF5OyWIOzAuFY/LJIzL5VRarBArKFmsFKup jFgj1lCqWIvxWpbHawaP11Qer6V4vKbzeE0WWmhKtkH/KQWjViDERqUwdj3E8eNTmh3COE7hcZyB cXw1VbO7YTRXx2jujvh1GNPVeUxnYkwvJ8tZ4awn4fzmbCDpbHS2U8T53dlD5Zy9zj6Kd/Y7R6i8 cxSjvyqP/oo8+jN59Gfy6M/k0Z+J0X82pXjtvHYU8dp77cnxOmA+uJgPHZHSyeuElPO988nzLvAu IN+7EPOkMuZJF5S9CLMlxLMlYs6AUOB1xZyJw5y5iip6V3vdKN67xruGqnrXYhYl8ixK5FlkYRbd hlK3ez2R526vF1Lu8e4h4fX27kUrfbw+qPk+zLQIZtqDKNXP64f0/l5/5H8Icy/guWeZ8ynIM9B7 Cu0+7T2Do4O9wUgZ4g1Bqee955FnqDcMKcO94ejJCG8EUjA/KWzmJ+oZ5Y1CqdHeaKSP98ajngne BOSc6E1EyiRvMspO8abge3jH+wDfzIfedPRzhjcD38lMbyZ69bk3F739wvsadf7sYWR6CzyMSW+R txS1/eqtpAreKm8tvpN13ka0tcnbTJW8Ld5WfJPbvO1Uxfvd+x0t7vB2oc97vD3Iudfbi6P7vH1I 3+/tR08OeAdR/yHvEGo+7B1GzUe8I5TsHfWOovVj3jGU1Z42/1/VdynToAlCoAlCoAlCoAlCoAlC oAlCoAlCoAlCoAlZQJMnEQ70B5IwmEKOwRSyDKaQAqb0Q9g/PIASDLKQDWRZSCqyKLKYgsiSyC5K MChDtkEZSgPKrKVktU6toxS1Xq2nQP2mfqPSaoPagKMb1UZKVZvUJiqrNqttiG9X25H/d/U78uxQ O5Bnt9qN+B61l9LVPrUPefarA8hzSB3C0cPqCEXUMaUpNTDSOtngF0IncBC6gaQkoJhPZYJQEKZS QSSIIKcKAioLXEtGSkpQmtINulFpoFs6woygLPKUC8pTSlAhqIB6KgaVEK8cVEb+KkEVxIF9SAf2 IeXVYBRaGR2MQamxwVjUPD6YgDpfC96gUgYNyTZoSAkGDSkBiPVuDA2H4GUzGrpAwxGIvwIctBkH JVBwEuKT6SOE0wmjDWj4KeL/AQbaNBc4aAMHFwAxFwJfbT5/7zMO2oyDpRgHSzMOhhkHyzAOpjIO pjEOpjMOKiveiqfAutK6EuHt1h0I77J6Iext9Ub4tPU0BUDJi0gwSoaAkjciNCgZYZQMMUrGMSam iK1iKyUyDiYxDiaLo+IoxTMCJtiO7VASsM9HPGyHKdG+0r6SytpX8Z1sBvsyGfvK29fY1yD9Wr67 zeBgJuNgeft6+wbKyMXBDWQDAfeQD+w7QmFGvXRGvdLmrC3mZxuvDWZvW68t2YxxvncOMM4BxnVC 3KCbzegmGd1Svc5eZ6QYdLO9S7xLEF7qXYacBuMcRrfSjG5hRrd0oFt3Ut713vUIb/BuQP6bvJsQ 9vB6IDRI5zPShWNI19vrjZR7gXSSMc73HvAeQNm+Xl/kz0G6AYhHMe5R7zHEDdL5jHQ2I13YG+QN QqlnveeQYlDPZ9RTMdR7wXsB6Qb7fMa+dEY9m1HP8V4F6tkx1BvjjUF8rDcWiDbOG4f8BgdtxsH0 PDhoMw76wMEZiEex72PvM8Q/935CaLDPB/YtRdygXilGvdKMemFGvTKMeqmMemmMeumMesrb7e1G KYN9pRn7Uhn70mPYdwQYZzPGKd/yLbKjaBW+P/wAhcIPhh9E2D/cnyLhAcCmSPiR8CNIeTz8OIUY p0TkhcjLJBhxUtQ2YE2C2ql2URLjSwIjSwqQZT/iB9RBigemHMM8N5iSGNiBTfFAE4/iGEeSGEdS gCBJiBsESQ7KBGWQx2BHSpAZZCK9fAw7KqIGgx1JjB0JjB2JjB1JwI5XUefoYDRKjQ/GI/8EoEYS o4YgUX+HOfPa+Lezs6kjXXE8nv//x6Y36k3mHdtbVZjuMud5+FxfSeteZ85wsfL+lPd/zWmTw59i 6nOr0Z+sRZfqNXpD/jM6Rbebc4ZO9yx5D0/vpjtBeZq/x9XeBUpshNL+8uTPy+TWs/XPe3onh7F0 aMU9+GbX6O14557Zy6NEU/KUXopci8mc9yiDWOwMY466/ou2cG5v8rar6B+ctqWwswt6c8Fzc3qX Xq2X4EiBqxAnu+WcJc+/Z+ZPbFTnOV+Avtu58a3H+5X1yoJnNU/XVvgVnCJLTdBj+e8RPhv+lXmb 80P6TcS+juXJGVlmBu/VP+akl6iddTxG1/yxb86C6eV5cjzL54PMufKVHFuH3uRFqNj3W9zfl89a ryk6X8k3jLQ89ep9+gjeh8y5Ln00X74TXZf6H9v+4jlfjE2PPIXCXQqpbw3VwBgsdwq1nnirQYyt Bk8ZUwvdgA3FvoZ46mvFn+rL16u8c6+Y5d/Ts/Q7sesDKXq0nsWpa83qnnf1Pin+sBjYuIr5wwbm JoxmZk3Sq/B3YizXdr7e9g3ec/HakP/MNSNZGuWcm52DteBr/TPeI5HaUc/X33L6L1EWwVe0/1Hy nhbo+aZ8e7yG6nfzpNyqx+s79FPmLL/ulZvaDGkfmXlX8KojmWuuBa+Fbtaf4rMsPX0zNWc8mHUM CJbDC7+m2PXZvH0ALudeGzHXWIqo+fvT1ceT3fAtBfz3eXO9ucDR3npOvrzRv8uxuq01I+Qk2ltg Rj3zLf6eTAzr26rYt4ZQ/1P/wL/3frILWcMCyipQ53bMg22xq0s2kCPnqtP+6NFTX9/+uA6d/3pl Dksx3IvX7XV4bS/APVcy9yxktmM2n2bsKmz7E57NL3D8yJ9TYul3F55OJbmOXuJN31zCAtF7LAbq x/nv74wA75s3Yv/WU6MxPpbDz/h6J36p6SfRu/f0R0DMD2N7c/RbZO4PmmbieAM5gWJzgBI5LPh3 oO+3MZyIXj+LK1Dnl/pDPTtWZ4rZi6XnQwetS95bLodZqpfk7uVol9UmlqMro0ycEe1rMz6i94jE 5s8uRuRuugvvzSZzNa8n3vchNkSPwFp3X6yWPPe24BuYqfueRG+v0/31OH0HYv/BrB6nezA+PIvV aBy+59l6pL4Fa+vv5hogf7IZerIeE205tmqk6//8qc4NeiFUZXTmNsqNxXinPhh9F58x56t7D8/3 3LuC8q9SvE7nKl9mvqv4voe8d1zUzX/Hyl+15b+Ky3cwbSu6J/yJCtx/9Vds+ZWs+VYxhncXhZ/8 65w2pVuSLS//wGwwKmsR/h7nSnduzs2n3l/9qu6n/6WHc/xHjPex5k6Z2DoU5Yt79Qd4zzq1drim rOidLKdUx1r9G1ZCXh/xm/6GcZjLuaO/ut4BzrGjMAZY4rZOgnPnKf1t9FdFXwwOfh/bWxmbP7Fe /z3zubBN36xv0h/rqSR4r7/uA7TuHmUEepo+gL1B+m59lq4MHG2o79P/PIW2ovyxwin1N4ZJUU2b e7/h2PxHT+emJ5yGOszoXRhFdfDbAr8+H1+j5/2xCv+9G3rzK+Ycn/PEGDZKMVepRJkujn6J93Hu Vf2rN/T3ubwzF/xqxt/Zn+NvmG29DXeK3umq7wE7+gWzL3psNoe/6un6Kv0UYoP1smjaSbb15an3 t4Qt7sl7n9f/7pbLcXed+t2Vhd3rfjq3KDsE/16PVe80nLEo6h7lE5Yt5ojSU/jc/paTbynPlnZa ainWBi50ysxVP386elJEGzGkA7s95fPyp+lXKqqVtWC2/+WZcvo2sJ49p+2bSTqFfpyO+f4XXo84 mdEI3rMmWjL2ZEfOeZEf+DrDDycsfGcs7zslb/ev3k7mGYgCdRz3asgJyvDZenOmKKqEo2d0cq8F h0+kj/ncbhrdQbLk7XL5k3jKS2/gteOPZ8lyzskVV9tF6JySt/q3bqVPtmDJrzyRuavBXJfOVfZ6 JofbgM9FXo34X9vA+/ce/5mJPPkO/Pf7UryteAh5sqt6oc9KFdkW30Hwx7ODfMUid2SFCy2Uk9ec qypLV2HO/Q1bfu4eRQ2opyJwlq/E/A3n+/TO01jXaoqdUS70iaOa/JSTuYL+YyFHi6rbPEe1Oqdk TozP8K+OpeS02Yzb+lO/8uw9+UedOX0xz2sV6JV5KqueuUpzMqpdj9Sv6xm5z4HFYoYRxM5p/pjb j3oF+vt6ydvLV/4k7hTS8/iqxDe5+3wPEPimLPaVvmI8vXectgt9NrmIMr/xWSuzkjMW8N4czL0o MoRPxC95RYmnlsV7XrOQ8idz/8N887wlv/dF9zmMnTU/MTrEPkvZ/PcbYXzt1D/zeySVASfdFLua tCo6p3ms3VrynhbxOaJX2PKodd1d36ff0KPYNyD3nh7dSb9Xwprn/DWM2fTx+O3oY4VdVY5eUfxT 2s6ir+Kc7Mb3yMSQWe8Cn9gFfrRYL/0DifRWpJlrxk305bz/PkbAQt1NzzX7erZ+UX9hzpjzsaH5 6l6ek16iHnXWd+hHdMfYHscwAntw/HU9XvfCOBgJtjYDK6/JMVV/qD+Irdrm7HxpyuJrzvfr2zkt ej/iKPDqV83vYVwScu8CyncuSB/MeZq/RP19Wb8JrfZ/sb0fuO2RjPM/8Hdgrr6+o/fozzhD9Kn9 2B0GsVHcqOSt/l3bf+Vp7IKtrM5BrOh1579rO5nrVPilt1Gesw65DgnFWXuSydy/cwnHy1JDaM8K XHY9WMd6Xk0yqIFegBlqXsv1Cn0W5ksPUjq6rsd0KmZnVFOVie2/F7tSISj3iWlOn3SCz8H3Vui+ WOdiZyB1G30t3p30zZSso2twjodGf7zb62b6Mh17skF/pZfx3RJmxm7GmrQ6pl9rUw1eOWtzrhOf 3Si8X2P1eIRv5u7PMFou350Vl8YiV9HF1ITqs09MVT6S97OHj83TkWP7eaX8WN+m3zdrmH5IP2Zi qPXpfM1G7wG77ST6e7u+C5//Lt7xEbudcfMxXql/xm+54Vj0Sfpp7AqSs/E3q++J1VEMjVdo25uK zlOgzFa+I8DwBB5NPJrnYN/hw+qEfMeUiqfm6L2g+UX42F0Z87F7lM6zhFWKbmR3uvvZnW4gu9M9 bV1pdaMh1j+tf9KL7Ev3knWv9TSNsAZZw2mycaejGcadjmYadzr62LjT0SfWZ9aPNFtkiXr0g2go sukn405H80Ur0Yp+Me50tECcJzrRItFL3ENLxf3iAVomhoihtEJMEBNojXhDTKa1YqqYRlvEdDGd tomPxSzaLuaIubRTfC2+pt3ie/ED7RE/iZ9pn5gv5tMBsVAspIO2sgM6ZCfYSXTEOMyRZoc5Yoc5 165iV7E8dpjz2VUuYmfb2VbArnJx7CqXwK5ySewnl2xfaV9lpdjX2Ndapc2zclaqcX2z0o3rm1XX mebMsq40rm/W9cbpzbrJOL1ZN7sJbqLVw01x06x/Gr836y53mbva6mP83qx+xu/N6m/83qyHjN+b 9bDxe7OecPe6h60njceb9ZzxeLOGG483a7TxeLPGGI83a4LxeLMmGo83a5bxeLNmG4836yfZTT5h LTLubsIy7m7CMe5uwjXubsIz7m7Cl2PkeBFnfN1EkvF1E8nG102UNb5uorLxdRPV5ddysahpHN3E WcbRTTSVG+QW0dw4uok2xtFNXGAc3UQX4+gmbjWObuIB83yceMgXvhADfOl74mE/4kfEo368nyAe 81P8FPG4n+qniSf8TD9TDPQr+pXEU8ZxTTxjHNfEIOO4Jgb79fx64nnjuyZeML5rYqjxXRMv+a39 NmK48V0TLxvfNTHS+K6JV43vmhhtfNfEOP9mv4cYb3zXxGt+b7+3+LdxXxNvGvc18ZZxXxMT/af8 p8Rkf5A/SEzxB/tDxDvGfU28Z9zXxPvGfU1MN+5rYqb/vj9LfOx/6s8XX/kL/UVimb/E/1Ws8Jf7 G8Rqf5O/W2w1rmxiv3FlEwd8HbLEQePKJo4YVzZx1Liy2VYoLVTODowfm50cqhSqYaeEaofq2hmh +qH6dvlQo1Aju0KocaiZXTHUItTWrhZqF2pn1wl1CJ1rnxHqGOpkZ4UuCHW264e6hq6wG4XuDPWy G4crhKvYzY27m93GuLvZ5xm3NrujcWuzexq3NvsB49ZmP2Lc2uynIpdGbrAnmqf27JnGrc3+XHkq 3v7O+LTZC9RV6hZ7h/Fps48ZnzbHMT5tjmd82pyw8WlzIsanzSllfNqcssanzck0Pm1OBePT5tRW E9REp47xaXMaGp82p6nxaXNaGZ82p7XxaXPaGJ825zzj0+Z0MT5tzkXGp825VK1Wa5wrjcuac7Vx WXO6GZc153rjsubcYlzWnNuMy5pzR5yI850741RcnHNvXFJcinO/cVZzHozbH7ffeSie4i1nAAlr DVAvDoovnhLIokS8bErCOuxQKtZuF6t6VaRXw8uj6lgFfaoDlAwBD5uRAh6a//PQkv8DhkHMOEbM eCDm5SjVFa9E4GY31HgN3UCt6UZgaBtgaC8wh3vwaku96X4qRQ/gVZr60kNoeQAQNhUIqyjNCqw4 SucnhDOsBGDuGcDc6kipYdWgLKumVQvpta3aiNcBFqcxFtcDFndG2AWI3J79QtOsbsDl+ozL9RmX GwCX+yG9v/UkNbQGWgNR51NA6gwg9WDKtoZYL1FjaxhQux6jdj1G7XqM2llA7TcRfwvYnQXsnov1 4AvrC2pmfWl9S82t74DmLRjNBdC8IcJGwHTJmJ7AmC4Y0xMY01MY089mTD+TMb0JY3pZYPqbVF68 Jd6iTDFRvE0VxWSgfCVG+UqM8hWA8h8j/ARYX46xvgpjfSaw/nuEPwDxKwDxf0L4M3C/HON+Ocb9 ysB9RVXtAOhfjdG/BqN/daB/KtWy0+w0qm2n2+nUzqwEiGMloJpYCaojrGHXRCmsB1THrAco1dRu irCZ3QxHW9gtELa0WyIP1gaEWBuQYp61PoeftT6Xn68+h5+vPpefqe6AdWIAtXQedp4kC6vFEIp3 nneG0VnOcGcEJTsvO6OoqTPaGUtlnHHO25TmTHY+pHSsKNOovnETpYZmXaHmZl0hZdYVhAluArVx E91EqmdWF6qP1eUXst0F7gKq4C50F1K8u8hdRI672F1CLladZUhZ7i5Hygp3BXnuSncl+e4qdxWV cle7qyli1iQKzJqEnBvdjZTobnI3URJWpi1kuVvdbWhxu/s7Jbs73B1UxqxVaHGvu5dS3X3uPmrh 7nf3o28H3APoz0H3IOKH3EOIH3YPU0v3qHsUNR+TgpKlLR1qKV3pkoUVziMsFtKnQIZkmOJlREbI lkoqSpWBDKiFjJNxyINV0PxXd5mMsimyFMqmyjTkT5cZlCTLykzUXE6WI+OAWhFhJVkJNVSWlZG/ iqyC/FVlDeSvKWtSGVlL1kJ6bVmbHFlH1qE4eYasi/rPlGeibJbMQm31ZD3kqS/ro2wD2YCUWXHR VmPZGOlNZFPkbCaboYbmsjW5so1sj5wdZAfy5DnyHPS5s7wIn+tieRnq7ya7o/Xr5PVo5QZ5M+rp IW+j1vJ2eRe1kT1lb7R4r+xDbeV9EughH5B9qbR8UD6I3vaTD+GzDJAPo55H5COo4VH5KGp4TD5G Efkv+S+08rh8HHmekE+gFTAAyjAMgLLAAJ6nhvIF+QI1MDyA0sADhuPoCDmC0uXLEjggX5GvUHM5 Uo7Etz1GjkE4Vo6j+sYDFvnBFVDDRDkR4SSJUSony8koO0W+Q+3lu/Jd1PyefB9Hp8qpKDtNTkP6 R3IGcs6UHyPnbPkpjn4m/0PZYBhfIP1L+SXVBc/4Gvm/kd8g5Vv5LXJ+J39Ezp/kT+jPz3Ie8syX 89HDX+QC9HmhXEhnyEVyETWWi+VilAVHQakVcgVqXilXotQGuQG1bZSbkX+L3IL8O+Ve5Nkn9+Hb 2C/3o28H5BFKMzyGGoDHBIjHeYnU0EvykinDS/HKULaX6pWlxl6mV4HqgeVUp+ZeDa8mnefV8mpT M6+OVwcpZ3hnUgsvy8tCDfW8eshZ36uPPA28Bjja0IN2BDc6ixp5Tb2maKuZ1wz5m3vNcbSF1wJt GU8By3Amqm84E0JwJoTgTAjBmRCCMyEEZ0IIzoQQnInSDWeiDMOZEIIz0RmGMyEOzkTNDWeiNONV S3X9Nn4blAJzQgqYE/KAOSEEc6Jsw5yoMZgTlIDfw+9BLcCf7qJ4v6d/N/KARaEsWBTSwaKQ82H/ YdTziP8I4o/6jyIdjAr9AaNC/sH+YGroD/GHoBR4FTUArxqGlOE+Rp0/wn8F8Tf8N9DWv/1/03mG aSEFTIvChmkhBNNCCKaFEEwL4SZ/J7Xyd/m70MpufzfqAeuiLMO6ENe+Nv97K0TUPmSFLEozDIwy wMA8hH7Ip0YhbJQVCofCiKtQHML4ENbfUEIogbJDiaEkpCSHkql5KCWUQg1CpUKlqEWodKgM0tNC adQwlB5KpzNCGaEMxMuGyqKVzFAmjpYLlUMKuB3i4HboCbgdQnA7hOB2CMHtEILbIQS3QwhuhxDc DiG4HUJwO4TgdhQ23I5agdtdQgnhS8OXkgxfFr4M8cvDlyPeNdwV8SvCV1KKYX5IeTI8gUT4tfAk xMH/EAf/Qx7wP+Q5GLFIREQknc42LJCaRL0bDAskYVggQrBAhFepqyhTXa2upgqqm+pGieoadQ2V V9eqa6my6q66UyV1nbqObHW9ugnxm9XNyN9D9UCeW9QtyHObug3x29UdVEXdqe5EnrtUT+TppXrh 6D2qN5UDs7wP6fer+5EOfomwn+qHsL96iMqqAephqqgeUY8i52PqMeT8l3ocLQ5UzyBlkHoONYOD opUX1AsIh6oXkWeYGo4+j1AjUM/L6v8Qf0W9gvwj1UjEX1Wvos5RahSOjlajqboao8ZQTcNcqQaY 6wSqrV5Tr1E79bp6E/G31FvIM1FNxNEpagrCd9S7VEe9p97D0ffVBzg6TX1EtdR0NQMpM9VMpIDv IgTfRfiZ+g9VVZ+rOcgzV31B1dSX6kvk/Ep9hVa+Uz8i5Sc1D3WCDaP+hWohwkVqMfIsVb/i6DK1 DPUsVysQX6lWUkOw5NWobY1aQ9UNV6Zy4MqPUtngseBfVCl4PMC3BN48kOoETwX4roJBwSAqHzwb PIuU54MXqHYwNBhK7QyfRgr4NNUxfJpSDJ8mYfg0QvBphODTlGL4NNUHs2vNfLoD82nBTDrKm3MY s+HHccyP4+gfeMUxMz6XmXFHZsZJzIzPZ2ZcmplxGWbGqcyM0/L497js3+Ozf4/L/j0u+/eE2b/H Zf8el/17Avbvcdm/x2X/Hpf9e+LZv8dl/5549u9x2b/nPPbv6cT+Pcns33MB+/dcyP49ndm/pwv7 96SDqUfAmwMrYI6eRo2sdCsdHNow9SZg6p2pKXPxS6zLrH8g3XDxZtbN1s1g2Pda9yLsY/UFb+4H Rt4YjHwgtQAXfwrxZ6xnkN8w8sZg5MOpNbj4SGoDFv4Bwg+tD6mtNdWajaOGhXdlFn42s/B2zMLb g4Vnkc0s3M7Dv23w77OZf58H/t2JWbhxGHLYYSiRHYYS2WGoFDsMJTJHv4g5+lniKfE0tTTO/nRp jKkbXl5bTBFTqKb4CLy8MjPyqszIq4tvxbfg34aLVxTzxDykLwD/rsiuRZliiVgORr5SrERoHIzq sKtbLbFOrEfKBrEBofF2K8fORlXENrEdceNvVE3sFLsQNy5HNcRhcQRx43VUXhwTmsqx41El27IF 4sb3qJrt2i7ixv2oErsfVbEjdgQp8WD/dZn312fe35B5/8V2hl0W6Yb917Urg/2faVcD+6/L7D/L rmXXQryOXQdhPbsBNYASaIx4E7sJnWGfBT1Ql/VAPbs59EBdu5XdCvUbPVCXlcBlrAQuZyVwGSuB y1kDdAD7H0Zx4P2jKIkZfyoz/gxm/E2cqWD8zcD451ALZ67zHbVl3t8ujyeTy55M8ezJlMyeTF1Y CXRkJdCG/Zk6sR5oCj0wnyRrAM9dAg0gWQN4rAHimP17zP5T3XXuOrD839wNSDG8XzLjL8OMvyMz /iRm/KnM+NPcPe4ehIbTd2BO7zGnT2JO34E5vZASnN5jNu8xm09j1t6B+brHTD2JmXoas/MOzMs9 5uWpzMs7gItD98q6YOSSuXgSc/EOMRbeUDZE/myZjfyGi3dgFh7l3B7zbI+59bnMrTsyt05ibn0+ c+vSzK3LMLdOZW6dxuw5TQ6Sg8Apn5XPgk0a9tyUGXNzOUwOQ7phzI2YMbeRo+Qo8EjDlbPlOHDl 5syVM5grt5Cvy7fA4yeCJWcwS76E+XEL+YH8AKUMS85mlnwJWPJHKDsdXDmDuXIT5sot5OdyDmqY K+civ+HK2cySM5glN2GW3IJZcjs5Dyy5ObPkNsySs5klt2CW3JpZcntmyY3kcrkcRw0/jjLjRnKr 3IEUw4+bMD9uyvz4EnlMHgNDNcy4OTPjFmDGZRA3nLg1c+I2XkWvKrVlZtyOmXFXZsZnMw9uwzy4 K/PgdsyDM7zGXmOEhgG3ZwbczmvltUKdxlEsnr3EXPYSi2cXsXh2EXPZRSzMLmIXsouYyy5irnex dzFaN15iLnuJxbOLWCd2EUtmF7Eu7CKWzi5i6ewi5rKLmMsuYi67iMWzi1hyHhexeHYRC7OLWDy7 iKWzi5jLLmLx7CLm5nERc9lFLJ5dxFx2EUtmF7F0dhFz2UUsnl3E0vO4iLnsIhbPLmJd2EXMZf8w N49/mMv+YQH7h8Wzf5jL/mFd8viHuewfFs/+YS77h8Wzf5jL/mEu+4fFs3+Yy/5h57F/WCf2D0tm /7AL2D/sQvYP68z+YV3YPyyd/cNc9g/rxP5hF7J/WJc8/mEu+4els3+YCw2TTE2hWKpSG9Ynbf3q fnVogxp+DXD92n5tauLX8c+A3qjr10V6lp8V0y3Zfn2/AbVn9ZLtZ/tNEBoN085v5jdDPUbDtPU7 +OcgPNfvhNrO9y9Angv9C6mR3xlKpoXfxb8YCqGr3xVHjZ5p7V/rX4v+XO9fj1JRJ0ajcNpB4dyK tozCifPv9nuhnnv8e1DqXv9eOtu/z78PKf39AfgURuc0ZW2Twc6N2axwmvvP+c8hNDqnPeuc5v5L PlCCdU42K5wW/mh/NFLG++PRulE77VjtdPXf9N9CKaN5Wvhv+28jzxT/HYTvQ/lE/BX+WoTroXki rHnOYc3T1t/j70HNRvM09Q/7h/HpjOaJsOa5hDVPG9Y8zVntZLPaacpqJzsUQOE0h8JJpNascNqx wjmbFU57KJzSUEFlQqnImQaF04S1TQbrmbbQM9XRSi3omQj0TEOE2aGmCFtAw0RYw0SgYTojNOol wuolwurlHKiXS2OKxWiVK6BDrmTFcnX4aqTcEL6BWoZvDd+K8Pbw7QjvDN+JsGe4J8Le4d4IjRdd InvRJbIXXSn2oivFXnSJ7EWXyMrHZm1zUSQjUonOinSMXEQtIzdG+tKl7FTnsNpxoHBqQ0UYDVOb NUxNdRM0TEX1T3UrmLrRLRVZsdSGYrkL8Z7qbiiHPqoPUoxWqaweVA8ipb8aAJVi9ElV1ie1WZ/U hD55GinPQKXUZJVSXQ1Wg5Hf6JPa6iU1DEeHQ59Uhz55GbUZfVKV9UlUmVRmZVJXjVVjEY5X4xEa ZdKQlcnF6k0ok3pQJpOQ/raaTFmsTOqxMmnAyqQhlMn7SPlAfUhnqKlqKnJOV9ORbvTJmepj6JO6 apaahaNzoEyyWJM0ZE1ysfpGfYuj36kfkG6USQM1X81HTqNJGqolainSf4UmaQBNshy1rYAyKcfK JEutUqvQrtEn9VmfnKnWKnA8dgesw36ktdRmtRUpximwktqudiBu/AKrsV9gJfYLrMN+gZXYL7A8 +5GWU0fVUYTGO7CO0goMkB0Eq4CYgwGyj2B59iYtx26CmexNWo49Bauxp2Ad9iatFfw/9r4/qI3s zvO1kIWGYIZhGIZjGMIwDCEsyxJCCMcSQghDCGEISwjLEoKEkIRQt1qtVqslhGj9RCYORzGs47A+ 4vhYzucijot1+bwO5zjE5/OyXopQhPVxLo4jLEWIjyIcISxHKHLf9yQxeJxk5qr2v7t69fn08+vX T++9/r7vj+fuJu7si1COvy+Ydfblsy9DCf7KYDb5yuBHzyafTYGz+FuDueRbg1nkW4PZ5FuDmWcz zmbAWfzFwSzyxcEM8sXBzLPGs0b0BonE3oJIzEsiMZCHs+fOnoMIrR+ir7dI9PVJEnc1QNz1Lchf PDuC8kn09cmzl85egjz+cmEW+XLh6+TLhbnky4XZ5MuFWeTLhXJEvbab6gHnNzbqPPofCKlbAGqA HsAAeIDj5EhxE3CUAAHAecAQ4CJgFDAGuAa4AbgFmAJMAx4CZgELgCXACpJ5HhEg9TqBzDMPeAz5 p4AdwD7gCKF2GUAJiAMkAlIA6aE+tGf9nmNuqK32gjDwNcWAMnIOtVcCakL9JdeMhcbYXg9oArSG ysNHmWeZgOImAbchv3ZSFsImYDucfwzYC+cPQ/CiMBSAWEACIBmQFqrrzST1UbsGYAjNUzt7Mueh ujmkHmoXAE6ABxAMj2Eg9Hve/PBYhwEjgMvh8+Ph80VhlEIZ3Md2PJ67gPsnYwmN+TbgLuA+YAYw B1gEPAGsAjbCx61Tx0j9XcBB+PgkfN3BqfPHCGnkgBhAPCAJkPreEd8/TQYg+0MfZd6K9+4VHpsm L3yv/2+R8iyIfJ8P/Q6Rq5RQPfK7p1EIKHnveNJGqF2ZtxrKywFVYfmDc5ra946aBkCz/KW2VVNN 77w6YEaEFYRjgc+bE4CHzMnAF81pwKPmTOAxc07vPL7K3aq+Zs53a9o2TPW9j9u2TE29y+ob5iLC pSf5W+aK3mV81m1o2zW19q6pp8zVvWuhfJgPTJreTfW0uY5wI/BDkn9I8rPmFuAFsxp4yawHXjEz vZv4KjcLbID8sYnt3Vavm3ngp2YH8I5Z6t3G5W5BJTcJvXvqfXMA+Mh83u1UxZicvYftMvMQ4YuE R4GV7ZXAceYx4ETzNeAU8w3gdPOt3kN8ldvTnmWekkZV8SaPBDNrnpaQKskUlBSY3UFVqmlAim0v MD8ELjbPSrG4xD0QKg9zhmlYSlBlm0ak5PYy88IJV5qXpGRc7h4Oc57pspTWXmNeIbwOXE/yTean wK3mHWCNeR/YYD46YZaTuUfaBU7pvqwqNI1Lme1OLk7KJK3lhEs8XGKEcYl7XFVimpDy24NcCuH0 SB6XuydU5aZJqah9gMuSinDePakq53IhX2W6LZW2D3MFhItP8iNcGfBlrhJ4nKsBnuDqgSe5JpJv lUrxte7bqlrTXalC1WC6L1W33+Y0J3yX07jvtt/nDFK1qtk0I9Wp2kxzpA8sYeEkP8M5oSda06LU 2D7HeU54kQtKjSqj6YnU0jXd7SEcJDwA/LB7GHi2ewR4ofsy8FL3OPBK94TUgq/qc3atd0/2eVSc aVVSq0TThqTvetp9G3in+y5hnN/vvi/p8dm+oMpl2pIUXUfdM5LCKDNt9Q2EWOUz7UqMUdk9R3gR OI7k40g+sfsJcEr3KnB69wZwVveWxOCr+oaBDyDfbzqWeGNu9y5wQfcBcHE3lODyvhHVICuXHMYy J+ZKZ0zfZdUFNkaSjDXOeMzGIMknAdc7U4GbnBnArc5sYI0zD9jgLJQkfFXfuJF1lvRNqC6p1qSA UXCWSwHVFTZeOo/Zm6m6yiZJQ0answrY46yVhnBJ32SoPMzX2VTpouommyGNGoPOhhMecDbD2oHy vtthvsNmS2PGYWcbYe1JfsRpBL7s5IDHnSLwhNMFPOn0Ad929vfdNd51Dro1qntsnnTNeN95oe8+ ae1GuGTGeQl4DjMu6ZtRPWALpVvGRecVwlcjeVzeN6d6xJZIU8YnzuvSFM73LRpXnTf7nqjm2XJp 2rgBMw/svHOS33LeA951PgA+cD4CPnbOS9O03PkYOMa5LE3ja/tWVY/ZKumhapmtlWbpeOfa+zjJ uSnNqtbYBmlBtck2S0t0qnOb8N5JPsN5KC2pttk2aYXO7kEnnNejkFZUe6xWWm9/wg0QHgZeJfkN bgR4i7sMvMuNAx9wE8DH3KS0jq9y39fIudvuGdUha5SeqhHLSTuaGO4ucDzhJMKp3H1pB591z6kV rCjtqxXcDGac12Rwc+44dSzrko402dwi4Sfvy+dxq8CF3AZwCbcFXM7tSkf4KveiOoH1uWXqZLbf rdRUcQfAtdwxcINFDtxsiXEr1WnsoDtO00ZYa4l3P1FnshfciRqjJYlwKuEMd6I605INec6SByxa CoFdlhJcDvVXNT5LOZT0W6rcG+oc9pI7RTNoqQW+YGlwp6jz2SvSAmb3luaSpdm9qy5ir0L9K5Y2 aKHIosUMJauh8jCXstfd6eoK9ib07arFCHyd8E0LBzODyw80dywiWE+SV1ezd9xZmnsWF2HfCT+w 9AM/sgwCz1suAD+2XAJetlwBXrNcdR9rNi3XPXJo5547V51muQlcwT4ArmMfQT+3LXeA9zCTklV1 IzvvLtAcWu49y7jcA2Gr5YE7q0NheeSJV7ewj93FHbGWeXcxznuS1C0WKFGr2WUyrhCvRfIdCZZN 4GTLNnCaZQ8403IInMMj4HxeAWPH1x6o9eyau0zNsJvuyo4iPvZ9XMonuCvVPLvtrlE72D13fUcF N4yZTz7haj7NXa+W2EN3U0cdnwncSLiFzwFW8/meVOyTeDI69HwR+CfgG3iyOxi+tHezg+crgB18 dciCe/KwHfQUdkh8nZTWEeAbpTRsiTwlHef5FmyVeDUw2BpPeccQr5eKOi7yDNgXWC+eqo5RnpfW sdx6ajvGeId01HGNl4Bv8IGQjHka8P31NHfc4s+7s9TV/BAwzIOnrWOKv4jnhB8FDo10mh8Dfshf c9cTi7NBF/bEgvXBmn+LLulJkBi6vCcZuKonLayfd7GW6zuga3sypTHVnZ4cYKxnjumGnnysc3qK gEGTBOV0c08paI+2ngppiUj+ascsf8Oj7Vjgb3mMHUv8lIfrWOGnPWLHOv+wd7njKT/bu9axwy94 XFBnCers8yseX8cRv+7p18r4p55BrZLf8VzQxvH7vduqWv5IqtAmWmWeS9oUq9JzRdVsjZPqtOnW RM9VVbY1xXNdlWdNl9K0WdYs94w215rruaktsBZ47oT8DW2xtdhzT1tmLeudxx6F54G20lrpeaSt sdbgu2Ctj1h2bb21iXArcBP0bV7batV4Hms1VoNnWWuwsp41LWsVPJtawer0bGudVo9nL+TTtsus QfDiQn4U8VK0HusA+K7Eb9QGrcPAA9YR8OKwbBy2a6zA2mHruBdpR6wTXoX2snXSG6sdxzVVcuvt 3j3thPWuNyHkualHrfd757WT1hlY48RH1d62zvVutqdYF3sPtXetT+DXDdZVmIf71g3gGeuWlKmd s+6CDzZhPYD+LFqPgZ8Ics+gel+IgfZXhXhvsnZDSPLM4xnwpmm3hNSQbHsztbtCBrRzIGRLRdpj Ic+bo5MLhd78kIepixFKvEW6eKHcW4rXhbdClyRUgZcOvrq3OsS6VKE25IF7605xI+EW8itqwnpd htDQu6nLFpp7t3V5QlvvHvaovYyuUNCG8zxhB15fXik8k+APewOEz+NeeYd0JYLROxTKE76oKxc4 KUFXJYjgD4NX7B3V1QqukA/sHTvF18BTFaRMXYPgA27GjL1W740Q69qE/pCn6r2l0wqDUr7OKFwA hnIo4YRLIa/VU/4ee6fwqvdOE34YYp0oXAFfFDxS76zOJVwFzxP8Uu+Czidcl+p0/cJNYE64Az7n nHAPfEt8X5ZCrBsUHnhXNBnCI1jdWDPH6S4I82A9M4THkL8kLHvX1WnCGrYIwqb3qe6KsO3e1V0V 9rw7uuvCoXdfd9OGvEe6OzaFTxbW7UR7q1tssT6l7p4tAbSxw5bsiwtpQt0DW5ovUffIlulL0c1b qnzpuse2HF9WyAfQGG35YAuIldEtY70dstG6NVuRL1e3aSv1Fei2sbXV7dkqwOqB1vIVa+Zt1b5i 3SG36CvTXLDVuVP0yNboSwnb5au2FnecXmFTY1/CppfW9bE2Btt0Gy8d6RNsDneiPtkmwe8u2wLY ftlAB+rTbENQnmm76E7syLeNRiyFPsc25qvU59uuQd/Al/Am6ItsNzzzeHS+Gn2p7VZI07oX9RW2 KWin2jYNVgBsrq9eX8fe9DVhO+Vr1TfaHvo0+hbbrM+gV9sWfCyeN59A2nHq9bYln0fP2FYgxgEd 7guGvB3MnrYQR7waVvQNYA6V+IYJj+A++C4THtfztnW3TO+wPXUr9RL2RrBn4mnTB2w7oTzYO2C4 CmyBbwJrXd+E/rxtP+RX+CbDDKPwNOiHbEdgL0iejGtCf1GUudP1o6ISPArwK3y39WNiXMiLgF6d sG9Ec1VMdOfqr4kpwDfE9JDFh3aAfXf1t8SskJX33ddPibnuAv20WAAM5VDyUCwOWXnfzCmew3bK t0h4hPAT/axYBrYbLLhvVb8gVoKlBjvu29AviTXuGv2KWA+8LjaBFasTW91NZM63CO+GZ+apqHEX 63dEg7tSvy+y7nr9kShI650y0ek7oLU91cEY2thTF6ijuZ5GYLGnRRqiXT1qSU/7evSSgu7vYYLx UIeHs4M9jmASfaFHgrOXegLBVPpKz/lgBn21ZwiioSs9F6Xz9PWe0WC26kLPmCTRN3uuBfPoOz03 goX0vZ5bwRKwmFPSGP2gZ9rfTz/qeRgsp+d7ZoNVoehA9ahnQZqiH/csBWvpZefNYAO91rMSbKY3 e9YhjtvseXrih2/37ATb6L2efcgf9hz5bzLIJQtqGYVLGTQysa64IMckuBKDIpPsSgm6mDRXetAX ikCNNa4siLlCkQ6JKZhMV26wPxTlMTlQwjP5rgKIucDWBweN467i4CCd7SoLXmCKXJXBS0ypqyZo NObimqpBV73kYCpcTcEroTira9rVGolnQzEmU03iyhrjBo74XJqTX59wGYBJrMTUuViImEIxzjHE mNNMY8+Ot9RY5hKg/RaXM3iVUbs8EGfBDASvM3pXMOyrDDOMa0AaY3jXsLTEOFwjwZuM5LocvBOK B5mAazx4jznvmgg+wH5O8BEz5JqEmBoi6+A84cfMRddtsBoQQYO9AA4uY3aTmDq4hn8luBliZtR1 F0Y0BjEXz1xz3ZccOP4NbjM3XDPh/B7hQ+wvnUPhmYTo9ZwizNCrc7HMLdfcudhQnnACM+ValC4y 064nEL1CDHsumXnoWg1FrOfSTnGmcca1ATM269oCXsCMY0xPc4iZJdduKK48l8OsuA6kW8y66xgY yqHkaa88FGOeyz/FRdiLO1dKuCLEzE5vDESOED+eq2b2e+MhToQo8lwdc9SbJC2YZL2pwMreDGnJ FNebHWzD9+VcI+EW1WBvXnDblNhbKE2ZUnpLpFlTem851MzqrZJaOpWix3dMYgdij4jugpilM04M +uWdieKAP0atEIe9CZ0p4gi2HeJlf3xnOmbIj/uTOrPECX8q8OQJ54q3/RmdBeJdf3ZnMVylDMV0 nWXifX9eZ6U44y/srBHn/CWd9eKiv7wzBetPwgedTeIT7w7Wlv4qwrUan7jqTuxsFTf8DZ0accvf rC4Sd92rnQbxwN/WyYrHfi1hI9aTfi4cWwH7xU7BLve7QnFWp9Me4/d1euzx/v7OoD3JP9g5YE/1 X+gctmcAj9iz/ZewzvRfIXy187I9z38duNAt6xy3l/hvdk7Yy/03Qzalc9Je5b/Tedte67/Xedfe 4H/Qed/e7H/UOWNv85YSLarsnLNrJX3not3on+98Yuf8jztX7aJ/Wc3YXe7Kzg27z13WuWXvl26F LBRm/5paAmsIefugzxny3HTx9gv+zc5d+yX/thrZr/j3Og/sV/2Hncf2677jzlz7TX+GQW6/488z xNjvBZAh3v4goDAk2R8FYg2p9nlpyJAhjgQSTrdmyLY/DiQb8uzLgTRDoX0tkGkosW8Gcgzl9u1A vqHKvhcoMtTaDwOlhgYHClQYmh2KQLWhzREbqDNoHQnARkdyICHMnCNNWjeIjsxAo8HlyPH7DD5H fqDF0O8oCqgNg47SgN5wwVERYAyXHNUB3nDFURdw4PsbkAxX1Y5AwHDd0Rg4b0h1gM433HSoA0Oh e2e449AHLhruORjPoOGBgw+MGh45HMDzDikwZngMl14zLDvO+xLV1Q6IsAxrjovAm47RwA3DtmMs cMuw57gGfGgvCUx1IccN70qXwnFLUnTFOqYC010JjunAw65kx0OJ6UpzzAZmuzIdC4GFrhzHUmCp K5+d95Z2FTlW/CVdpY71wArUfAo1Kxw7gfXQr3RVO/YDT7vqHEee+a7GbllgR60wZEv7XS3dysC+ urQ7zp3epe5ODBx16btT+mRdTHd6n7KLN7j6lOrGbrDOXY7u3D7w5boL3E1dUndxX2JXoLusL6Xr fHdlX3rXUHdNX1ZnQXe9dwdzX24o6u+62N3UV9A12t3aV4y9l74y7KX0VeJdlL6a0IojOxgD4Z2K Z1fHvfBeAdkZ6KvvGuvW+LOxfe9rwjF4XyuWxj5NaHeI6IeDrmviCLRPPLGuG90G92JnVjfrXgzv 3pB9la5bLNdn6NztFvrYUNTfNdXt7BPwvfY0IBl6ldqh/hdC1K+pfSSjDqnfIDn1WxmFFLIzMgV6 QfYRWSz6iCxe9hI6K3tFloRelKXIXkMvyTJkb6KXZdmyj6NXZN+RfQe9GlUd9UWUfKbqzBdQyhn+ jBWlnvnxmR+jtDhI6KNx6XHvoPS4+rhWVBeniutDX4t7N+5HyBc3E7eF/iZuO24fPYbe/BmSk79+ EIdeRC+gl1Aj+ghqQhr0ZaRF30St6N+gQRRAQ+inKIj+Ef0MPUL/RMWg/0rFUmfRb6kXqVcoisLv OCnxc5PUq1QL1UmlUl1UkMqh+qkLVDU1Qn2H+ir1H6mfUF+L+n7U9ylRLshtlF3ukfuobnm//JuU S/6u/F3KI/+2/K8or/y78r+mAvIb8knqG/Lb8h9QA/IfyX9EDcn/i/zvqHfJ+5gX5Avyn1Lflq/I V6m/km/If0GNyn8p/yV1Rf5r+T9T/w4/RUeNn3n5zMvUfzjz0zPH1DXFGUUmtaj4mOJj1J7i44o8 6teKTytKqN/gNzyo3yo+r6iUyRVVindkCsWXFa2yOEW7QitLVegVvCxdYVNIsj9WfEMxKPu0Ykgx KvuM4ruKq7Ia/OaErEFxQ/EPsq8o5hRzMotiXrEk4xXLimVZj2JVsSpzKX6ueCrrxc9jybyKXyn2 ZEHFvuJY1h+Nos/K3o1OiH5F9t3oV6PflP11dFb0p2ST0Z+LZmTT0dboYdlW9LeivxUVG/3t6NGo s9Hfi74R9TL+u6pRr0b/bfSdqNToqegfR6Xh54GisqL/MXopqjD6SfRGVHH0L6L/OeptZZbyZlSj 8lcvvBH1s7jfxP1Gjt+XY1A/cCxKw28bV0yGoQTkoixGU33AGCqrv/i4Mp9hGYFxVq8yHiZYydQP MbeZu8z9yilmhpljFpknzCqzURtTm8EM1IrM8Ns1bxuYEeYyM85MMJO1GW9XglTJQcZ3iIz/GlHU b6nfIhlIdDyKgnOvkydRkex7su8hSvZ92ffh3KTsb1CU7IeyH6Iz5ElUhewnsp8gJXkT7AXZT2WL KIY8gxpLnj49K/uZ7Gcojjx3+qLsl7JfwurAT5YmRFFR1MlfDT4TpUBJ5M2x5KikqCT0r6KSo5JR CnlS9LWo7Khs9Dp5KywtqjSqFKWTd8DeiCqP+hzKIG/FZJJnNt6C/sdSCWTmMCP6AXLRD+hH9Dz9 mF6m1+hNepveow8ZRO8xCiaWSWCSCdKYTCaH3mbymSKmlKlgqpk6ppFpYdSMnmEYnnEwEhNgzjND zEVmlBkjuMbcYG4xU8w085CZZRaYpdPJ1MSsMOvMU2bnJO0zRyaZSXkqxZkSTSmmdCjNeia1mrKg bq6pwFTMHEWSqcxUaaoBxqnepGF2TAaoy5o0JsHkNHlMQdMAtJllGjaNmC6bxmH81AtMWGvgd9Zf InOSDCkKpUKSoyz0MXQG5UKKRn8CSYlKIL2ASiHFoDJIH0GV6G3ydPmXQOvg9y5fRH+BWlA8aoOU AHpHi15GBkiJyIoE8salk7xr6SZPlPtRCuijd9Fr6NuQXkf/FlIa+vfoKvoo+h6kN9ANSBnoB5De RP8JUib6IaS30H9GD6B/jyBlk7+G/XG0hP4bykH/HVIu+idIf4x+DikP7aJfQd8P0P9Gn0DHkD5J yahoVEjFgO4rIc+P/ynovnhUSp4fL6PSqDfQZ6k3qTfR58n7npWgDevJG50tqIr6OqVGX6A0lAZ9 iTxLXkve7nyHYigG1VFmyoy+TNkoEdVTvZQPNYDuDKJm0J7fQH9BfZMaQF+jhqgh9HXydmcbaNI7 SEVNUVOog5qmfoy01EPq75Ce+nvq75GB+gdqFnUR+aVBC2QjRpmjzEFm8nQep/yEsgBZyBN5VmWJ sgQJyjJlGbKRN4lE8vydXalWtqNuZYeyA/XAvd1A+0T2i/CXJYy3AFOAacBDwGwYC2EsAVbQnxun jNPGh8ZZ44JxybhiXDc+Ne4Y94GPaBmthBRHJ9IpdDqdRefSBXQxXUZX0jV0Pd1Et9Ia2kCztEA7 aQ8dpAfoYXqEvkyPQ5qgJ+nb9F36Pj1Dz9GL9BN6ld6gt+hd+oA+ZvoZORPDxDNJTCqTwWQzeUwh U8KUQ6piapkGphlSG6NljAzHiIyL8UEaZC4wl/BfED2jOdMFRvDrcW3k+wpv/4vJ9zuQXiRSHk+k /CUi5S8TKU8kUv4KkfIkIuXJRMpTiJS/RqQ8lUh5GpHyjxIpTydSnkGk/E0i5ZlEyt8iUp5FpPxj RMo/jmYh5RBZ/yMi67lE1vOIrP8JkfV8IuufILL+SSLrnwJZl6EiIt+fJvL9r6nXqTSQeyzZpUSy P0Mku4y8H/FZIs3lRJo/R6S5gkjz50Gae2ENuCk3rAH8lsQXiDRXE2muof6S+ktYD1ima8n7Ee8Q aa4j0lxPzYIcN1Bz1Bz6ivKryq+iRmWLsgV9Vdml7MLva8d74s/DfYqFuf8IoixtIHcFgGJAGaAy XFYDqAc0AVpxmfwlY6GliF74wyB1lvhFY4ml1FhuqaBXngUuM1ZZqul1wFP+CYax1lJH7/xh4DrG BkujsdnSQu+/B/xvY5tFTR9Z1IyMXzVqLXpG+YdB6sTxG0ajhWESLYyRs/AEosXBpADSeZbks/gt JpffNbosktFnCTAF74H8u5g/MPZbzjNlH4BK/pipscqNg5YhgguWi8ZLllGmPgScx2Njmt4DGesV yxjTahnDR4KrlmuM5oOB6xmvW24Yb1puMYZnYbxjmYq0exrGe5Zphn0PxgeWhx8GXJt4yfjIMmuc tyz8Tjy2LGFwWvEKhnHZsvKhsGZZN25anj6HbcsOBme0Dhr3LPsfBhwnXjUeWo4waMTLCBS8EoMT xev4aGZtE7Sa19CxfBydwCe+H5xLvEkn8ykfBM4n3iFtpPHpBJl8Fp3D5z6DfL7gORTxxc+glC/7 0KjgK+lqvuY51PH1dCPf9Bxa+NZngMf9IcAI1hhazxtohmd/J+Ac47TGMx5rEqnH88KHgoN30hLv eQ64vSBgwJpKB/jghwEzbM2gz/MDJxjih0+Az48ALluzSX7cmsdMWAvpi/wI6e/7wExaS0h+lL/8 QWBuW8uZu9aqZ9oY48efwTV+4jnga+9ba+kb/CQzY20gxzlr8+/qz+/FLf42PcXffQ7T/H36IT/z HGb5udNgFq1tEd1+WhdHdOWJjnti1Z7ooFWr8bQeOZGT0/c1cl8ic7Rh5U7mdssqnu4T0SX9oFNg 7XODIR3AXQitX7KuLvEpxG6AvHNXAFfFexF55q7DEX4Hn2d2rS7mwOpjjq39Jrl1ENsXU4z1Ai7H YzPFWy+ZkqxXsH41pVqvYj1pyrBeN2Vbb2IbYMqz3sG6nYwZ5N1UaL0X0c+mEusDU7n1ER63qco6 j+fCVGt9jHUnbpOgwbpsaraumdqsmyatddtktO6ZOOuhSRQQnl9ig/BcwhyaXGAnw/bM5AP7E55n Uz+0MygocBvk3AUh1nRJSMB258TWnrpHJ21ihG1KxBbgPmHbaLoiJJO+XRXSIveZ1Me6H+49sctg 88jYrguZuMx0E2x4SQjYXuP5fQa1IbuM7RWxx/A7EVuMjwQgP2Rs77Ox5LcApjsWCQPb2IhdjcB0 zzKEcWIjsc0M28bTtvIZGxm2kxGYHoAdhHtMbB/YQ9MjyxQGkVts5+6FcKKzAKZ5IYccHwv5pmWh iJSD/jCtCaWmTaHCtC1Um/aEOlKO1zC2JXjdwjrC68l0KDSySGjBuohVCGqyLiLrIKwXiWxBO1jP sbGgm8JrhNwv0Fv4+ogOfG5tvW9dneiXSP+hDaw32QRBj+85mywwJ9fj+rDe2DSBZzMFB+43myNI bL4QIDocjwfGwBYJ59lSYYhc90H6J9wvtiKsxyNrPHiqTrjPZKzv08cn48F6OILf91u/R5+y1eFj HT+Jx3SC9+vJ07oS68eIjjytE6EuaQfXwedgDthGay13U3zA3REfYWDfBt9v4tfcE+dJGegsdsEW xz0QH0f8F+6RuMwGhGmix8Dv4ObFNeJTgE5jbwhPWUmYivgE3GNxk+g0bP+x34B13bK4jW00tybu cZviITstHHHbdsTt2RXcoT3WguwJFoU92RJrTyM+WVhfkmuxbxb2m4jPE/FRcFvhNvA5S4I9E+tL 3K8T3y7ih+29p4MJIj5M2PfAbWF/zJJsz8H+jiXNnh+5ntSH8ZB/w3yRdQJjs2Tai0gZ9hsjCPuJ z+D9vmDY93sG4Xl9v193AuyLRfB+vy7io/0O38ySE8IH+mbY9zrtf2GfK+J3nfKxcF/JtbhOeE6e W1uw/tgW4eJz60otjEZ8LFYvjLGMcA3rokg9lhduYLlmHcItIk8RPYDr4DUH8keO54WH7JAwS/IX hQV2VFjCOL3e2DFhBesI9pqwTuTzlrDznB8DYKeEfQKQRwyyDrHeemiTkeOsTRlZg3hNsEu2RHbF lnKy/rAOWrelE13z1JbF7thy2X1bAbY9EeDx4hiLrD8YM3tkKzbLbGWkbdAfZqWtkowzXN8cZ6sx J9rqzSm2JnO6rRXrInOWTWPOtRnMBTbWXGwTsP0jNhDrJ/AJzGU2p7nS5sH62FxjC5KYBWyhud42 YG6yDZtbbSN4vswa22WzwTaO4wSzYJvE82R22m7j+maP7a45aLtvHrDNYB8Q6/+IbjYP2+bMI7ZF AmgP2xks2+bLtid43s3jtlXzhG0Dy5l50rZFdBjcR/Nt2y45d9d2QNq4bzvGutw8I8rNc2KMeVGM Nz8Rk8yrYqp5Q8wwb4nZ5l0xD8+v+UAsJHoMj/9YLMFHTi6WY3ngYsQqLl6s5ZLEBi5VbD6RH/DB sf/BZYhtXLao5fJEIykP61yuUOS4ElEk9w/WCVcuurgq0cfViv0nshqJAyI2CvJcgziI63DN4gVc hmSIigvGDSH0//8H5f+h/0HZQrvv/T+Adh8xuhRdui5Ll6sr0BXryhrlukpdja4euEnXqt0PJV06 hk6jM2iPQknH6gSdU+fRBXUDumHdiO6yblw3oZtsHNTd1t1tvKe7r5vRzeniwmmYYFH3RJcYTqu6 Dd2Wbld3oDvWy/Ux+nh9kj5Vn6HP1ufpC/Ul+nJ9lU4WSVCjVt+gb9a36ZShpNfqjXoO6omkh7hH uCY+h38PfgHv85+dANn+4r/IPug7sDa+DOklsg+aQPZBXyb7oK+QfdAkZEBG9CpiIKWQ3dDXyG7o 62Q39KNkNzSd7Ia+QXZD3yS7oZlkN/Qtshv6MbIbmk12Qz9OdkNzyG7oH5Hd0FxYc7MoD81B+gTZ DS0gu6GfJLuhnyK7oUXo5+gX6NPof0IqIXuif0r2RD9D9kQ/S/ZEy8me6OfInujnqTQqDVWSPdG3 yZ5oFdkT/QLZE60me6JfJHuiNWRP9EtkT7SW6qXcqI7yUl70Z2RPtIHsiX6F7Il+leyGNsFK/1v0 59QPqB+gFrIn+jWyJ/p1sieqkp+XfxOpyZcGNfI78v/D3rlAWV0c+f/e3+POiHBFMkEYkYwTReSh OCBBZMEQ5DH3ARJUQoiMc99XJAQJImFHJGhGggiuEoKKhBAcJ4CISAABkeUlIQgEAQ0SFgmyQEYi ZCQsDFv16d/AOJITc/b8z/mfs3v61PdXVFfXr7u6urr73uu4wheXdb3Rl3SOOP/pS8v6rRZf+n1j fWUXYzUmI47tju2LHYwdiVVJORU7I44PxBvGm8SbxVtSkvHh8VHxsfEyKZPik+PT4jPiL8Tnxivi iyjXxdvEO8Q7x7tReoJ941HBQfEh8RItGjdWW4mb9l7cNOH9GjGWzNENEj0aK474v0iiR2MlQKzk SKTcKTGkn5lfJtExRGJI4+Ny4qMhn5M3knE9IJGk0dBYYmG6xJPGQROJgvkSTxoBeb7XpHyVCGhK BFwl879e4lY/D28uc/6+RJjO+tXMegs+A79GZv6oryVzXOBvLHN8LbNbyLx+nRm9zj/MX+K7nhm9 QWZ0pK+1f4zMaBs+5W7rnyKz2I5ZbM8s3sRn2jf7f+Nf7uvg8+d2zu1WZz7aOFfG2tQv8XHxCbEO sc61Jd4q1s0rPeuX+BOxvrGoKfEpsUGxQfFnRFKvxGfGZ8eGSCmRktQSn8dzeGxUbYlXxsZ+scQX Y2FsrMwrk0yJL4tNjk2OrxKc9sUSXxebEXvhQpmrul6p8Mqi+iWzKLM0tjS2srYkT8TWemVj/ZJZ Gdta+67M2thOKXNFUq8kOsWqY3ul6Pv2a0m3jgfleYgWlETVF63HNqZ7Y2FjrWdjR03JbIydiJ3I VAhWf7Fktsr4zl4o0bh1oeSacglPbY5viwfjeRfKrng+5YOLnqgt8QPxgnir2sKMH463q1eOC30a L6J0kXLak9ckHMHuF0YUjZUlGsR7fbEkGseLE03jA+L3aEm0iA81JVEYHyGS0nhponW8tI6dCyVx U+xoPH2hjIiPri3G+7H9MiMS34muxG7fxB2J3hpjibB6IjFQ4yMxWLj7GG27RDyRpUdZxmosaaTs ZJa2ZvZm9hMNh/D+UTx9PDFS1k4H8V/nWLfEmFhFYrx4OZiYKP0rT0yVWC5JPCvxPjYxK24l5kgs TystT8yPd5H3TpU4mSS6CxJLEstjZxNrEusTW6THGv/TEtsZZYnM2ObYpMRu0Ygm9iUOii1dtYwI TbNWdHYnxQYljkj/q2TMp0Q+WfQ6y6qbnDgjXIfEfUlfrFsykGyYbJJslmyZvI61PMiUZJtkB12v yc7JblJ6JvvKah1uVmwymhzE2+RNySGxSckSXZNJsSyaw5OjkmOTZclJsRnJyd760xVYkZyWHC6x FiTe8qV2Rrw43iX5Qjw/OTdZkVwUH5pcKvMrs5WYmlyZXJvcKJ5rF+8lfZoR35bcmtwp2nul7I8X JVcSgTpK5kr1pEjEqJeSh4SOxnvJGp6WrBb56OTZlJXcn8pNybtTean8VEGqVaqd+DqbKtJ4T3VJ dU/1ShWnBmiMi2eZ89Q9idYSbV1SQ5PDU6VS0qkR8e5apG50qig1TkZQHL9HaibEh6ae0DgVLE1N ST2TmpmanbwuNS92NFUZT6cWSzyO0LGllqVWyTtLJUJH6/gyJ2JLM9XpuGSGtZmzMj/7ZTy9JF6m Za1srmSBimxQMsXG5IzU8WxerFlsZemW1IBsfrZA17XEjHgr2yrbLluUrMh2yXaXCNXMUS3ZTL1T kVmZWWk0YtPS27O9xJbmOyIYTZNlJILF1s5scWxGdkBsUfae2Ma4JXorpT8nskOFW5oami2NrU10 TRWlu2bT2RHZ0WRBL5Nlx2XIrKkumZ2ZndkJ2Sckzx0yuS47JfsMb5M3ZWfGjmZnazYTPJGdnZ2X rcwuTjfNSkZPDTWZi9yVmzmaXZWdEh+aXac9Sa2TedLYGZranNqm8WNKYqr0e2Nql+ak1Acyxwfi A2R2DktctZN80C51XHw9L/VpvHvqdKomFk07ack7sUPpxummpVtKt6RbyAzOk7g5ERubLky3Tt+U 7pTumr4jXprcr36PLY13SfdOh2Mn0gPTg5OH0vfJ6pksCSYbHyHv3y/74+H0HbKCg5KzSqVmZHpM enw8Pz0xXZ6emn42VhbPTc9Kz0nPj+1ML0gvSS+PB9NrxGowvT69JbZXLO9Pb5c+BaUvu9P70gfT R9JV6VPSx61iOzd2QjTPZHyZQGxypqFkmyaylqISN82kTTuJlS6ZlhK/xzPXxRalW6eOp44npqYO xPYnd2baZDpkrhM/WJnOmW6Znsmtmb6ZaGZQZkimJJPM9I0Xy3N4sjozKjNWtMvSU1PbMpMyk+Oj M9MyMzIvZOamp2YqEnFOU+3/74b5v+iGmfaN5FcNTfX/JlNS4fPfb/nySuZJqZSyWMoyKatKVg2R UrKuZN2wvcP2lmyWsq1kG7JdUj6QorIDUg5LkXaDqwZXlRyX8mmJ3mGtYDTYX97RmBuNjxuNxV3G 5szrcJdxucUEOPPmcIvJ5RZzGTeXy7m5NOTMG+TMewVn3sbcWa7ktvIVn79xvPEIxsTvDks6+fwl YXl2ledA58q+80t6fxkqLpbnAqElf4eWGyoeaqjvmi9J64W2XIK2GyoeLc/dX46KJ8hzn0cHPTpi qN9+8yyeKTRb+CqhU1+k4kp5nvnHVLxMaJXY9XkUEGr4eWJs9ahfk3rU7J+glkLXXYLaXMKuUod6 1PnLUVT83q+bUM+/Q30NRXcb6hf9kjRIaMglqMRQVOatX/LLUVTmtt9wj0Z5NNZQ9Ih5Rg7Ic6dQ mdCkL1JUYqDf5H9M0VOejWkezRB6oR7NvQRV1KNF/wQtFVp5CVortPEStLUe7fxyVHxYnntLWB+X JKkrPi70qad36EvSUaETl6C9ns0aeVZ/OQo58jx7kYqti3RBp7H3bCrUQupyL76rLoUKvfcH/zGF Wgvd9Pn2xXn1KP8SpG07ybNAnl295x2X7s/fo+JWQu0uQUVCXS5B3T9Pod518nfdfFubL708FgqX XMgvoYEln88ftXFSd149f1/w0eA6vr3v8326kFPq5oDaNeytLd0zamO+f7N6MV1t6kNxoazQSJMj dH8JjTdyHVNoolC5ya8lOl+SJ0PPCs0ye0Bojpffz5h4D4lPavNzSPa00BIz3tByzw9iU/Ol2oTU rsxnSPJiSHwXkj6E1O4Rz7+eP7Ut+2TtHnawjp/FTthnbGhdWPaLcEOvX/Xnqd4cXdhTauep3OyN 4Samb+FmddqfMWPh30u8vU/+HW7pyRbUoeWXoPr78vZL0O46+2udPfYCVdWhevvrhf3yf7JPtiz5 /F7YpuTiHlhnv7uQs4TCPb2n7FvhqLfGJH+EZU8Kyx4Ulv0nnPTksoZ1/2Dd9jbrKSz7THiUyUXh sd668NZBbV7U2FI7mufIT7VrpNzkLW1/IQfWX1v11lVtfrmwtsq9/k/y5nzyxfboy3oLy94UnmH6 HZY9Kax70H4vJ+kYZA8KL/La/aMcVD+PX0qnts+XyMcX6nIv0t/Ndf8onxZ8nr6QJ+vmyqI6ObJO PkS3wNPpYnygObq/xE//Nob0bKPzrWea/h08mcRKpJfwmse880t/ORuFq708JnPaX2NrkslnEfW9 +ss7E/Tv6+Uy3f9neHlO40/26P5ir7/Yi0h/+0vc9Bd7/SXO+qtNibH+ZV7+rM2Xi7yzWe25adTF PIotzwZ9nGTyJf2qn4fr5eALZ5jaPKzjVFtaJzHVf1qd9pO98XQ2/uLMJWPrP8OTdatDfS9B9c+C JZcgz6/1z3UXqKwO1T/X1Z7R/idns6Ulnz9/rS25eO6qe8Yq8dqurOOT+mtL1l94a8kX1lV4Z8mF M1ZY1/V+k4su5KtDJq7DR714qpWrTrUXf/qUvBLx1l1E1lgkaKjueovkmRwRyTfxGWl1iXOMUKSd R0WGyINqv4v37H5xDeqaiMheFxlQZ/2JXuQes94iskdHSoXSZu+pJfJRpfGTjjkyQmi0Z1vGERnn jdPTj8idLvKE0BShZ0rIRZGZQnKHi8wTqjT7nxJ5Us4EkcVCy0w+jqwycap7YWSd0GahbZ6/dgl9 YO4JkcPGT5HjRj8ie0fktFCNOQNq/q/NzVHZA6INDKk99hmJ7Whj4/eonEGjLUycRQuNH3Ueo629 ups8G51MLo/KGTEq58Oo5h45j0XlHBaVc1VUzlPRuPFvNOvlMRl/dKT3HGPiISpnoaicgaKyR0Sn Xowfzd16HojKWSgqZ6HoHE/u5dyonAeiC4x9XSdR8VFUzgDRNXVitfYeULtHCR9db3SiW4xMf43R aF2jDf/3a4z/TZ+VOW2c9fqNqrXF96rPl1Mg1EqonVCRUBeh7nWevYSKhQYI3SM0VKhUKC00Qmi0 0DihCUJPCE0RekZoptBsoXlClR4tFlomtEpondBmoW1Cu4Q+EDogdNh75/G/8/xU6LRHql/j8+U6 Rp7bQKix17fj3lPGkNtUqIVQoZFfeLYWusn0NbfTxTHndhW6Q6i3UNjYyR1o3pc7WOg+obgnzwqN FBpj7OaOF5ooVC40VehZoVlCc4TmCy3wnkvqPGv1lwut8Z5zvHZr6tSvF9oitF1ot9A+oYMXn+qf 3CNCVf/Es9YXp4wf/1liDurSAENqn/k64OkeqUdnzP92vvZZ277W7mUBoYbefIv8siYXn5c1E2rp ezXUNxQNDQoNCZWEktDw0KjQ2FBZaFJocmhaaEbohdDcUEVoUWhpaGVobWhjaGtop5S9of2hQ6Gj oROh6tDZsBXODQfDeeF8qCDcin+3k1IU7iLUPdwrXBweEL4nNC08NFQRLg2nwyOg0eFx4QnhJ8JT ws+EZ4Znh+eFK8OL5d/LwqvC68Kbw9vCu8IfhA+ED4ePhz8Nnw7XRJxIg0jjSNNIi0hhpHXkpkin SNfIHZHekbDWi3xgZHDkvkg8ko2MjIyJjI9MhMojUyPPXpJmReZE5oeGRxZ4ZYmUS/HLpayJrI9s EX67V3ZH9kEHpRyRUhU5FTkT9UUDUMNoE9kTml/yLy74vL+4kMtfXGjAX1xoyF9cCPIXFxrzFxea 8BcX8viLC035iwtX8bcWmgcLgrf4rg52DPbytQ/Ggmlfj+Dw4A98dwZHBx/xhYJlwUd9dwUnBR/3 fTs4Pfim7+7g6uAa34Tg5uAx30T++sL8/4975vc38Y/k9yor9f8mX1jkkWSWwu4e9fKouA6vJKum 8B6PV72hHl/qUdojybqFknULJesWStYtfMLTneLpq+yZOv+e6T1nezSvzjsrvX8v9rUt3iJle/Hu 4n3FB6UcAQ8WV0k5VXwm5AsFQg1NKd4SahJqFmoZuk6kbUTeMtQh1Ln4YKhbqKesSVZl8SlZl9FQ iczVFfylDR9/Y8Pib2zYwaJgkc8J3hns7XOD/YIRXw5/b6NhcFiwVOYhE3zAd01wVPAhX0FwXPBf fYXBicEf+1oFVwVX+VoH3wq+5bsxeDx43Nfm/7F1f813nW8JDpHo8NdcDt8A/hb4W+A7On0FO7mj kZci/xn8FMEi9zX4vvCm7S3wA2h7s+BNyDs5I7CjbYuwP9TpqOh+V3/75I4TPs/pqej+UHAJOi/p e8/Bn1tNHyYifwC+I3xH+E6mtx6OA3+Ajtg89x9OW8ED3ojaUvtdesVIndsYV4aep5W398LnUuuj 1StIHqRtCMkV8D1o+zDWrqAnPUAXnc7oJAU7wHeAL3K6Is/Cd8YCcrAjtUXUfsO5XdF9gJ50RVP5 jvan6Bg/TMHaKqzpXNzsVCA32AUciE4cm8uwKd6w7tI3Wu3dEsHHXVnd1hj4HuBed5Rgmer4LfA5 9Omn5VO0k2g+58YE52PzSpX49yjvP0ntdPTvRP9p+DysnQQPoH/G+a3ILWeD4EBnl75Fef8nSJLO HsFuquOrVvQXg38DVyvaNpr9sHO36vs/wkIF/EJq+6B/Hv028IfBdeAb6B9zvi+aYfffhT+tcWsF 3LeEr1G5v9TdInjQkUiw8lXHd8x9TPCviv7DnkTQLsJOPtiCtglwOniVc57a+4V/V9HaB78K3A4+ 5wzVOQocA5eBlWA5WKWY00ze1cnMIJqPB/RvqJTC9wAbeVgJloPa9io011O7GMleJGVI5ph5V15w GVgJloNVoOr3Q3M8rXwG3Z9rVMA/R8/nw68E53uSSrAcrAJ7yVjWuuVEUVqRt+8BT9J2uofLwEqw HFQL0/HG06pjzwSfps8nwQPYOaB99h9ztwqeAo+5L4IjwWEgkeAeFwtXMV+n0TwAHvXwMWJgncYG khos1GChBgs1RMVBag8iOehJVgrajOVadz0xsxUcCQ4DdygSCQdMjCkvkabWdsAfkzO99kEkVlcP ZSzWJo1SqwWSFkhasLpbqGXBDeBKInOBjHGciU8sTwOne211XTxEzF+l/yduedeL4EhwGLgBPA6q zX203Yc3tmNtO/xz8C95qN7bQj/vylFrjQyaSIOfb9B9k5kdyTxq7Un4Y4F/UQ8b1F75kMidVjEf +XZmdjuSJayRVmABWegW8tvjgdaCjyL/mFx0Cv4Z3UH8fyKnNTL5UDX9DdyU4FfIZpPAq/DGInTa sRbeg78LrPByoOwvfuxbOYqBHTr7gZ+qN1xyqVOiPgksVz7QTnn7CLFdQZwUEb1babXcXaJtnUX0 SmuzJp8HNHO2VZS1uYs1tYt1pKvjevjp1P7JG+ND9CdJ21+j/2v8TIZxj6h/FCVXK5r5ah+Q/dEa g34j+PXol3nZo5I8UK67A2swifw58Erwet6yBzyf01dnM2cB79XaO3WWZeUqn+eh2rzVy8mzhW9G TO5AUgB+ELha55d8+xLxfC95e6lmUXcnMbldNd3WxF6uSmTuNIbzNJ/7t5pVLHdl2RGYl53qYckD K4mxlaxKgxtYLyvBDewgmqvzta348y1aPcYKeow41Lf8UHtl99Nau5/JKo6cVfzXsMZ70mp54DPy g+p30d5KJKvksK50ifD3dGeh50Ve/nkMTX3LPHA6uC5wg/KBp1i5/XWXYeXuo3aVh2aFKj8o0Jba 40iO03/1cOfADs119PZF3Q39v2NPzKe355C/hs+vgS9gLAf1pGQNcNT+NicoeERPj1ZzRZmvx8gq OmuzGONsXWv2LeyDNyraBY5IrHew/DyaJ7H8R/g/wvfB/lb1vKBaLqbPIxR9i+GPgve6DXx6rlD7 tzNTbbCwzey/eo6Sc8L9ZD+N8MmcXo46WUah8fZ1amfR8x28azXW8nWkzu/VGy4+cT5jfsfo/m43 VWv2e8o7t8P3ZrxVjOIzcsVnrMR8+km2t1ZpD+1OjP0yr7fak0L4do6cXf2bGPVvHDkN+u+gb5tp S7RbXZ3husZpNUjPwNYg+8+Czzp3iuXuzONSJ67xaT0v/C6sfeyhWnsJO7dis8hxBD9SlKi7xqen MvGAnYMfXqbVKHAaMXDEUe8twkJr8GfYicL/kLG/iJ97MsYsrT4G94EZ9ZicsnQUE/XUKvxlGhXs QQ9irZR+DsJOwJ2hGcCLRh3dm/TnTOA6Rfck+B64GnkhWKw5wZw5VdPqAHZ197CPKN/bnEKxswPc hJ1N2NmEnT+gn0Q/qRJrJJJuSKLm1Kq8r1p7IvgeuBp5IbzqNzInW96y2iDnqH7Y6adtrbvh7za8 2hFcjbwQvAZJC+KH8wY2P8LaKbACXAgucHQH7IPNPtjsg80+2OyDzT54qY9attuopt0GD6zDwjr4 N+Df0FGIV2fTf8XXzXiVl77Nxs5sWp3Egkq60M/PPNzCytI+DHRvZrXq7Dzm6GlzrXc70LdscHaz ZrkdqKbPnOQPcbZvzi2gL/gO1ppjvxrcDS6g7WCwN22XI/8Y3OpIlAYKdVyBSkUnqzrONneFrHTe FRjl6j41FF+NxAN/Qz+oXg1Usq5vobc7iJOPwGnePWUPs7ORmNzDrO3BM8SnrjLxQCudKfcqwRe4 E1lotkRzB/wk3t7NxBtz8YpKbJuZspH3Q/8j8DOwAtzISb4icJi3qOS8zovMr/KHPWSu4ZebyFGJ REIxM1jMjMs92jfJ/r3cK6Pu5YoBubeee1dX4rl3XZll+3lOSlvUJ85tuu84CeXt18B/Q16h5zHn JbIi+nI21nPR12gb4lz0AJpv633T2aRZ2ub+aN+t92WnMbWv0+pXijlXI2+KhbPgAvRLiJMynQv7 DfWtvR++D9hR0SnQOXIKiY1y9N8iot5XdOeh05GoyFdN+0lm9s/wWWpvpLYZ0dILC+auugDsy7t6 cCp4iR2wt3rM/ogdpJzcuJ5dY6OeT+w5nEinsgfN5Xw4HsnjnGqqsLMG3AW+B76PnUPgNvBh9qb3 2WeXK7pvw5eBK8iu1exBP9Hzm9OWU9z7Hr8MrATLwSqt1ZuXexT/90OzIXhb4DuC5kbGDdFe4WEl WA6qhdfQHEurN1QiqJIBKnHvIyqGctZ9GAyBIzkZjuL82Zs7KSdYpxXx8ybvQtMu11zqIBHUURzB 8vUeLgMrwXJQrLk36p008BYxs8ltKq0ux9ocMAZyP3XyGPsj8Ms8XAZWguXU6rgeUV85q5XPuSbw c3Cw2qeV46H6hzuCvUD9YPfg1DfewxfBkeAwkFjSk1ugAfP+PTR7a250r3c3Cf+J+7bgz5Hv9nAk OAzcAN6s8UbtRiQbkTypZ137VV2h/n/lLN0S/BfwYc6WBdyDbuPs2o5T8VQi6mEidqqeA63eWH4d /hFur0vp24fIP1Q7Toj+71eJc7WHL4IjwWGgrq8btFfO1/QOG3jZxLyuCOsQ1i4H53BCmMA6yuP8 8APi/wVq3/fwRXAkOAzcgI7407lW3+K+rZ8rCqrOClqtgM/DA9V46QO3krXQUmsNcmM9rDdW54hK 3NXaE2cZ/CfwDnHioD/ePcYsGNTb67t6exVvaFRscybQN41YH/wKer6CWpNFu4OXu3mCPp0vt3ng LuHnqty9lkj+EHzEy6WaeVaRS6ejMxn9V1hxf2YdXU5G7UIGngX/pmZgiStp5a5lXjZik9ur/QyW H8RaW/hlev+VG67WjkRzlWLuao3wXB+3rZ9hmc9Mcky2/y23m3JW6FFW0BusjltBbsf2Qiy8jDWf 87i0WoWd32jfHD6ncrgRy1zoHprgLvyQ8mKhCtzFuq4Cd7Faq8Bd9PZ14Z/ijcvx0lk9A9jPk502 gQ59e1PvyM4vwdGKNp+c2FsCT+h+xyqeDv8G+i/R9ilWerlKAmnNBoEHkL+N/gHwbnBOoFoxZ4ju dOj8SiMn52r4pmBHrJ1F/1n63EB3B6eJfk7l3OzmEz/KW9o397jOvtOEtTPe3DeJhwXuZo0TlTsf eXdq/cSykjvObazrPrpH5PRl7t5jpm5XPtDAbSS1p9mzVuiNWKJXc0Ivrc3py84yR1eT5KuV4Aby 0kpQ99BiPkdqi3w/8v3IP0F+CPn7yIdi7UPeYm5e49kZd4Er9L3uAR1RgM9j7SXcuOeyx81Ufevf 9X4tWW4YHv6MPmteuk3v2oFGrPoqVvcaRfHkVvLMzfREcRu1l3MuulxPPpIPz7EWXiRjaG0ZWO5l D221h7zxlt67RWcW8ln0n3wVeFT4ZfT5TudqwV8oOgX4fzEj/QOzMwadez1NlbTkHvSOjtG5Uu/I Np8q2+bWtpdb22Zy8o/wQwvmvT33sp8TLc1cyUWBXFp9xgnhVb2Pu1lHbhbOVHLsCNqOoO0U+Ap9 l/UN3ljKvLzErT/OiH7CDXcXK8JB8pTeyp229PO76J/gjfTKnQQ/Xu/m9vfhjc6DWOgMfk/PS3Ju 1FW5wrlK9wV6+DFxbm7T3yQS+jD2m+1VMq4haicwGhyn6MxxFpI5dUV8S3l3rDuWXqk/B6Fjvu9Y TTZztdZ+SHcx14+dxvh/BT38ld677Q/gP9Hbun0LfB+9rdu/ZixXaE9cVpBzr9NcJLPp/wT7E8FH bYkE56h+yxP4JWfC+/W2LqPT/lytd3Z7MjYf8lB92Ai8V+/p7grwO3qPsP9Lxx5oigeKuYMfpFWJ 3tPtr8KvofYU/flPergE+V/4LqNAPRNozdu7g8MY73Cws3e21F21Oa226s3d+r3e3O2f4J/mfH54 gB7eDxYzO08yjyGdNYleQWshkhb0cxa3mOlgD8NzQ5nOWpvOTWe63qqkVm4i7g2cqNei+WPwDfdx 8qHyQTBkEAshLISw0AfNKu56bVXitEWyB8ksR2bcT1vrOvAJ7svf5r78bW5ht3G/+7nelSQSRN9K o/k+b2zK+bM91tprW6cX/GMGkTym1gRXIy8Er2FnF8+4Oxhd1pFbof0CNm/Dvhldd/BHeveU/jMK bLbFZltGWsVIq9RXzr1qOdDL3Qn+WKMIC4sN4p9S+L74oUcgjK8U+3N//0Dv7zKKsH725ezgvWFW 0B+wcBJrYd2ttFeSeRSfd64XvM+ZKPKxZFTuy3K/1tonwRZIujuThB/paN/aIyHfOtcwF38G/6Jo b1F0tyk67cHHtK17E2/5Kjb7gV3BeVgrN77Cwidgazz8CPigZrycTeqB3Cj+PM297wE+pX9Q+ZwA u979WuvegIe3oNkLPqF8zia1lhvVk4lbw33wNsZlYqMLs9yLeXkBPg8L3dD5tX4+YJeo/518ZmEx sXGt7mL2YR2dvRC+MXwZOvvB9rQqBPOYzaba1p2rM+7OQ94RzZeZ5SeVt/6M5LZAZ/BZjTc0m+ts Spw8Tg5U3I7NBfDX0+c8fPgjlYvmaXp7mhXKN/XnX/H5ffb5d+AX6nfZYNH5l+FvBMv1W3Kv9hVw Lvrj4A02A6cjN20XwS/C2gLwQyQfwu9FR+TWXef1E9H24OPgGLAHuBcsU/Rbir5TSIpAn6KdhH8O nA9e6fH6rcEe2p5EMh28k1ZPw+dRewA8g4S3WAORfAJv7Hfj7dXg+9T+DVyNNRudfuDdyD/yeO1D BZKFSPrAn6dVG/jD4DrwDfAYmmH40/AB+BqwGXiwpo2eDOkP+r6/qsQ2nmkB5qvEz6j994LvIt8H vwrcjo7x3l013xQLncxcKG/1AGeDc8wswBeBPvA5cH6Nnk7XGv+rxP8qeJLa32F5phkd/FXG8+jU oHOtGQuSA/TqMPwObyzfZFy50nYcbcerxId//I+iWVQTZRSz6PksejuLvilOR3ISPIbkWkWf4VuA +eAh3tgKLABvAT/mXSYCn4H/E5hf01NwEPxXmNlJJiZVbi2Cb1ejt+/34LsiJyqsHMUAkRZ4WNFZ gYVz6oHAg8q7W5jr+cYz55/XbxvR/6mJDaw9Qx8+Q+dv+OouXZWyppoR/4rTzCyf+1RXHCMd46EF FgheBfYAy6gtw1qZSsSfKu+NvAj0eVig+wL8cx6qZhRv7/E8X8AszAaVv1Pl9tPUnqLVrfTQRPgp RoT//R+YGWGkL5l4ho+jsxQv7TTZQ33l7MJjZv3mwbfAM+vQX1dzh34qBT8GOz+Ef1HRZhXb/YjA 0/htOrXMpv8a5MfUh/6z9DmA9/IZUS5eqlGUuDK8jhFf+X8Kmji838MC2s7Gjuq/i82d1L4C4k/f CUZ9FHwR/N35rwieY4wNkLwGfw18AbM2AH4bPT9CbXPlJWNUiOQOah8CZ1E7Gw8Q7fYt8Gal56vH rBuRmxXxDvg8lhNYSGB5t+cl5U1m28q6Xs9q/ZhZIKv4HTx/O3ZMJtwG/uf5jupJ+C0mB6I5Gc2v mxzIW3YgZ/U5E1g7m+A/O99H+mn2kblkm/fUV87t8L2RV2HnM3gyoXUZ2BYsNGsWnU3gb7zsdKsg O4V/MzpLzYoGyQDWs3ipOzq7QJM3iFuLfUG8KncKm7XvfxkcBZpc0Rr8GfhD5KPhe4JZIvAR5K94 e4HG80SPVw+YvWMo+uQQq9TsKcxmAP83A6eD74KrQPK5/zXm6zz8m+AZ2m438wWPJ/2fwCfBKF6q hm9E7Wr4fuDdNdXaQ+QfYXMauBBc4K1f8y6N/E1EfjUr4m6wD/J18F3Qfwxr7Dv+Dby9hthgZ/ST ye3maK4mWuD91WTj3fALkA+GN3mV2Q9UElGNwR+TYTifBFpizWSku+ntG+df0O+YsHC+5qeMV9C/ ETxDHh5IJlkI3ofmGfJwQ8Zi9qk8L68WENuaGboh6Yb3upFVqpE3wg+rPdTca6PZz0O1UEHtQg8L 2HeG48MC+ql5qYDareAbtB3AZ4yn+Ay/BZ80tgi8LpoNvV/X6K9TuvCbnHN8tnyj/srR/66iVcn3 vxu4e/IJlf9Pjv4yZy03Mr5tsXoFLteVzjc425S33ob/1NnLXZXvvPR87htitdJ50U8k7DZORt/u /FLPGMpbVc5fNBoV7U+d+T79fEk0ffsU/Wla9VV0K/lMIwDe5IzXtYmFCkfOvfZQLJzV2sAgWg0E O/H7hNNgrpOvM27/SD1mr1cd5a0J+l+4WMMV7ZH2fqyJpm+zor/QtEKyU9E5riijUJxrP6WjwE4v /VTB2mjsUDtY0Z2IhdPgfnAyuMTWz3PaKFqrbL3dF+i93jqNpIk7hH7qr8gaqsS3U3nfPkXRV36z 6rvdsFNAqw62/n6vlT1TZ9+eS98W6GfatFoCdkXSWvXdNbQ65PVEawcjmW2P02yDvLuH+jsix7M2 V71E35Yp7z9Af2zLr+ie0r96A29Zlkr8a6jVXyB39B/kF7P6q7YB1mTB9vqpi7XKelqzrvUT7bn1 K13XyltPWE8Illn67bal+v7p4EBF+wF0nrP4raM1TfBm+0nB1+Db2S9jR3j/STRpa91J26fhv4K1 kxql/j/y9jPWV3QtWxoVg61m9LOxxr/Ft/xWQCTftK7QtWzdoGtZ9f1R8C5F318VbRsLfbF2t9Vc c6b1LjaVr7Y+0l0DfgGaYSzU0PZr8IfBt/3q4aX04aj/66J5k18/4ZS8KJKzfv2W+Zz/lO4FVgfN q9YEvrXXvyx7zH9A+6Po/6bVVCXWct25/H/SPRdsAd6kKNYEfR/BTwOb+PejuV9XOvw+/zjdTbD5 rn+e4LP+P+h+pD3xfYyFv2pPrLM+n/4K3TmhGMiD/w/4Rvw6/XL4byB/FYnYcX4REJvOELAXeFzR PgIuVHQbIj+raDngU0hao/M9xcAeNNuAYWoL4UvhB6N5GAlyZ7JiTkv4G6h9CzyFhLfYv4VPwE8A ByCZCI5V9NNbqzu178AfoD8BdKaDldRugH8N/s9gf/A7yBmRfY62xtpW8MdgBnwPzU7wjMv+L974 A/j19Gc3eBTJL7EWp1UXNLcgvxZ+EfyL+GQ5/MPgS+CNtPpFjuw+gavN7CjvHAfPmzlS3m2I5Cz8 HWaOkDxjZkp5+3tgKTgSa/eZ+aJVjpk1eHwS+MTMGvoLwcPUFirmtETyFn27Gc0pYNb4h7d/ix6u NT5RieyJyhuP4WdnLtiNN+Jt/1+oxZPWKiwQde6z4Eb054A7wQjIqB0TaS/SzzL0r8cCPneD9IH4 sVoRe5ehfwidX8P3QNPEWE8wqJj7a22b+1X6aaPTBwu/AfOQX82oW+OZLeg/Ry1rxNlFq+t4F761 nzXrDh/uoS2+dSaDN2DndXQ6YB9/Wt+k7VLkrDLXxGqad5mV2NLEHnZ+B4+m9SStjqHzb6CJELxn jzKRzHuvxVeLFP1/QfI87zJxeCt4O3gXbbfDd8RCEfgx+DfkT/CuGPy3scO4XN7udkZzKnZmwuN5 i/zgzAPHgHejY974e9BEyJvUPgAyL3Zz3vh9EM/nIHFO8sZxyE1OYw06ZnWzct0rkDQByQw2UWFj zTKZiqxinUCfts5o8BWwArnJjfD2u0g2we/n7cSVzdqxPqUVUeea1WRGtBqdBui/gMTM+xrkA8F8 kD7b5MxAOTZNr4gK5w8ga8ohNvz0PPAorX6E/hl4VqIzHtyLnDm18b87FDk5yiFrOcSDRVZ3kuBK 9E8RMxOIH5OvKkFykcs6sn+MxGTOKtqaOWXebWYqQCzZ3wVZa/Y0kOjN2aaYS1S47F8u0R7A2zmM PUCtg75NjrJvA/vr230+vYM4v6jRb4uGgL3A44r2EXChotsQ+VlFywGfQtIane8pBvag2QYMU1sI Xwo/GM3DSJA7kxVzWsLfQO1b4CkkvMX+LXwCfgI4AMlEcKyin95a3al9B/4A/QmgMx2s/G/2vgPK imJbe1dV96kz3X2KAYc0BMmShBkYR5IICEgSAVGQpOTggAjDgIiACBJERJJkEEkqYkJFkmQQSSI5 55yTODAzr+o7rZeZ6/9f7/W+t956666z5qtdu3ZVV+3atXd1nT49KF0H+gvQl4BPA58HHyMSKagb bm0z8E1gZ+AuSMaBxrjEXVzxFdBr0Z/dwPPgfIjW2qFWOUhuAj8/6IWgp0Eni0H3Bs4AFkPdXKib BpkqoMegtDvoVuBLIMYSuAIsjdKRwC7AJ1BrJa6bGz0M9xzjtWYBK6EuRs2uoRQj4stQF7NvjwOu h/xM4A7gU8BwD8MzHh5Xf2BhtICx2wptYh55EdhABORPQuYT0I9DMjzX1YCoFURpMCv6KSDzJFr4 FhiF0vGgYZnWTsgUQsvQjED/xVcojUE70AyvCv4i8GG9dtgGOqG1sIWHbXUL+JDhw8G5gNKxQMwO hx5ED+AUtBaex0eAFYENUboddFnUKgM8A/wV/LfQZlvQz6Ad9NzGVex4SI5COxNBQ1ccK8uaDUwC PguZ8BV/BobndClKXwJCkyInrvgyENqT4Fg3cMW+4Ie9AazXCq8L2LydCZwsQKwpgXkUaI2H1zjW I78KedS1EoEfAeeDH/YqoMU2cDaAPoyrwxIELJxfRy3YiR22+fCIlkPGgfxUcMIzuwL8RsBoIPos 4G0Cw9BmuFeYd+sAEKvAwuwz9DwwALVeg3wyaKwdqx9wL/iYUwH92y3Ax+q2YAkcntDqAFwCGVi1 FfYkl0GHZwqzKaD/ACxENAfC5sVoIGxPboX9Y65t+HMbthqADiVGFECpBXkB/yDKG6QDfB+ZU5Gt urRQ+BxDjNKcWrjv7mBOG8QsnCTURul089tYkc88nyYm4iyFGw4/B/4owzcPWJD5tYXhtDBo7zBo lQL/Jup2R+lZg4EeoDsAa6G1y2FJXLepf5pRiMwZhbk3nA7OEP/EoxR+W2dOUerg/CQZ5yFROBtZ AP5sU5dvB6cDSieA5mjhMjAJOB9j9wzygdBAY3NCwtfj1CIOdJz41tQ1MpSG84oH/PMTjXTMyNhl 0E4j1KqOE5IKhsMesKZqfjb/bGQBzkAW4DxEY+qYNHNO1SBtq/G9oJuae1u+3dCsBuhmKK0Oejno vZDsBzoIugJK16DWeXCyhFsD53iqudMvCZksqBUDbIPS3WFEaTToZJROQguFwJ8Dfjzo4igNgO4I emi4D4Zm+8J9QGkfQ6c2SrutLaEIOF9STo37QU83tMiEe/k0g6Iy8Do4yaAnQvKIQXuHQYuBz4EL UBo0yG6CvgyMgTxBZhSwOHAwSpPQh3Gg24CejytegExf0BtRmoB2HLS/Gjjb77npSRdwFoOzDDgC iJGKWihV4AxMXYr/wm5aXpFqTgLzoeVufh8M/6CZI1HZIB1E3YXA0WgNJx78JDiNjYxVJNU8q/Y4 SqumztOYSvU0PxIysYbDr4b7jJZnmT4E8oCz3NBsNPiNUr8w9mnkrbUo3W1K9djN7HhouRH4OdDm u+h/rrRk3c9B6O0t9G2/qWV3x1hOgz8TVtff1GLxuFZf0AXQTkzqPXyDcM/oEzjCoN5NGTwKTm7I nAadxaB4Ar2Kw6ytx7X6oOUO6OFRgwELui0atpC0Z43VGRmexXDM+3e0h8QqsyLNWAI5IH/a0HZN yHjgNAvbIbSdG1fxoJksRmPsLYy6aao5m01AD+eDdlKbGBtLNaedDwDr4+rroY0aoNsYSXYTtWJA 34bkerQwGvRI8HdDG5vBLwLODZS+B85+tPYeOI9D8opB7XEwX2E7RP/rYSzH0IejsISwJY8zo9Z3 AYehJcw7cCBm6ibkU9FCKVyrAkpjYD9HwS9nUPt3My+1fRmDJ2EDO9Dy9rD+fW2YnlfHWI5CV9nA DwGbQjLBv+49rIt7sL3rsISwpNFbXkNr274OSzYyrYCjwWkCyWhcKxqSW1FrPWQmAxejtL6/fsvo sQTQ50UY4xbwcwO/R386hSUx3m7hURtJbUU4tYZFBXytzoJVQxtGM6wTWp4AP7AC2lvtX8u0UwYz lS3sqVDrMmqthmQqrD0GkotgmVGGDhSgTLC0pZhx0/+p4RXtrxHTWgvMUSHgi+jhRd/j5USsMVfZ 7K/Zibr08/BaNq1pbzkBvSqDWmG/aloejFPiy9QOdtXOxPS0hpp+DlZ3HjLwAyK8jkaibn3+Iyx/ KWbTjHFl2DdCcgD4jaH5cQa1X1oKX2G8SnhG5gODKM2HUVfDeA8DRwHvoeXqmK8qwALAOr6M8XL9 /Xk0nm2s8ZnaHpZiNc2DVdzDN7n3YKv3YM/3MBeGvgO9DfSjWE5wzKgnY6SVwlEMPucyZmeZQQkr kogy4iwk2wER4+iqsUO9Bz4EH3gdPtB4mMboZwVYaQxseDusGr5IS86CpJH/DPwESNYCXRf82ej5 btALwK+ZuhPYHavvutmTm6ukTkw7jvlqZFYr5vQpjKtAOK6lrsH39VlNb9HzQRhLPkg2SsWeB3Vz U17dZrQ/s5pO+dS0TIT3vJFlfqfjnzQaJAd8x/CJDCe1uXnKOrWZeRI+Fb8HSXVAx4KOBV3WPKed Gmeepdf87uB/DPoF8/yYeTJf0+tAXwZ90dDmVzy67hLzlhvw48zTgLqdT/Bullt4v80yg+Z3BETm d+6pUebXHKlR5vcgqV8GEsxbbuQb5i03hk5ZbujUQYF3zVtu5FXTfuCkQXkF9AHTvjwL+i7osExD YFlItga2M++9MX1LORruc+B9yM8CHa51Hn2+CX4h8CMNyioYXSngFYx3MEoXASX4j0KyGq51EfxN aLMMOBWgmTAnGaXNIT8CV9wELSUDB+DqVSFZAnWNZAzoGNBlAhvBvwO6BNoJ84ugJ8+BLgb6ebSz x2BQgsabfIJBlDYHZzha+868AwctPIoWYkHHgi5rfi+v5X8CnQ2YFbVqoM9l0Oc2mOVpGOktlKJv gbngvABcB7yJ0uwaS8vPQH+ONleAHgmZr4BjwV8EegfoG6aH5i0curfGDsvie3mRkgYaejPfpKfG ppwz/UnBXJhv3jXnuilNWW40GeakDgDmA6IWWohNWQtJ1E3BqFOmgT6JNteA3g36MkphUSn7wDmD dswTOEQOGxY8T6Ltqz0SKKpjj/YvUf+E1ond6EvSd37PNKqWj/SdRVoaZSWPApSbClIWKkWPUHmq QnWoCbXUbTSk1+gNakud6WXqRUN9+RBJykOF6AEqTfG6lapUl5pSK33VRtSPBmnP0YW6UxINw/8Y DNdRFNQ+ozBFUQw9ShWpmvbOz9MLxOkZep3epPb0Er1CvWk4ZSNRu0GDWlSn0dNP5aM2jRvVzUcT 0Up2vDP0Qe2bi+gWY6kSPUFP0lPUjF4kQcWpMfWnwdSBEqgH9aERqBNB+eghMpHuMapO9akEvQ1+ DorUeshP0VRUt1uWylFlqkG16GlqTq11v0vSszSAhlBH6ko96VUa6fcgM7lUgHJRMd1CHD1ONak2 NaAW1IZsepieo4H0FnWibpRIfc27TNuW6dlWPAdsBewA7AZMAvZv2zohUbwFHA2cDJwNXAhc3LZ1 z/ZiNXAjcCtwJ3A/8Gjbtl27i9PAmwYtDowE5gWWBFZol9C5o1UTWA/YqF23l7taTYGtgO2AXYDd gUnAfh16tG5rDQKOBE4AzgR+DFwEXKEbbm1tBG4F7gTuT+jWq6t1FHgaeBF4HXgHmGrQthJebptg O8BIYA5gXl3Ywy4ELA6MAcYDKwGrAWu9bNqpD2wMbAZ8EdgBmADs8XKPdt3sPsD+wMHdDX8EcDRw AnAqcBZwPnBhTz1H9iLgEuBq4EbgVuDunp27dbAPAo8DzwIvA28Ck3t2bds9QEAHGAXMCywKLNOz Z0xsoBKwOrAesDGwBbCdxjKBBGAisB9wMHAkcJzGsoGpwNnABcBFwGXAtRrjApuBO4B7gYeBJ4Hn e/Zq0zNwFXgbeM+g5MAgUPXs1b2njAJGA/MBiwBLAsskak3KcsDKwOrAOsAGwOeAZjfOte+J+idS odd5Lsr9L1EMLw79/6OtPYatvaik4L8tZyEXppn2ehkx9CdRaD/n4p3Lf4Vi2nv/MWb508gxI1y3 anI47THxwewS/zRm/tOY5+8w8k9jPvRUIGX3oRnB/Tz1D1HoSJWNcvyTVHZQXMenAv9UWpAK/VNp YSryT6RMR9J/jP9YJ0xH8H+Mmf4UxurdRqKO+uNoNi2itbSTTtJNZrEoVojFseqsMWvHEtlgNo7N ZovYWraTnWQ3ucXz8nq8Lx/BJ/OP+RK+ie/n53mycES0KC4qiDqimegi+ooRYrL4WK9Bc61g2GZF /Qz5NhnyIzPkR92XtzKUB/Qy30uS3Zd34tLnvVnp66vb6duPapY+n5XSt581KkO+SAb5WhnyLTLk M4wn6/70+WxFM+QbZMj3Sd//3DPTl+dZlj5fuGSGfKn78nr9FY7JUD4Iea79Q5bwCB9qEE6Lhkdu aZvLpn1VEZ+73U/3++lJP736R9LF4/y0sp/W8tPG6XtRfET6UZaIT58vlZpevnTT9PnYDLNQpkyG fFyG/PYM+R0Z8hcz5C+nz5fNcp+VaSI+KkM+Pr18fLkM+YzldTLk62XI108/i+XraFRaM23ZeOrA psLbttEf0it1HDE70s6MWJGFAl5ttd6rpdaqlWq15gTYJXZJy11lV4mx6+w6cXaL3SKhqqqqZKkn 1BM6bhp74KKGMPPFeRaeVXPML4iU6Y8I6ZqldD6bvhvpQVNpPR2lZBal+xDUvYryGhL3anmNNNb2 ntFoRhepfXI+fbcQo+95KqmzJHik7tM5pOuVvtPiWXX+AtL1ajdxndurcb3ar3GjHqux0GgqoI7q vq7UpceQrlfHdbpa508gXX+f5Elf8pQvedqXPONL/tbfuuhvPfT3KfT3t5L6KHkaJQ3uL1Gb0MPN 6OFW9PC3ku0o2YGSnSjhJLn+6GXmcvPkdiSP1FrNqrUqvJrek1rrK9VKCug+rdaaEmQiPhM4YdJ/ RXX9QXpUg3Q2E8tEA1g0y0MD8f8sB7NmrAUNYQmsKw3D/7AcwV5hifQ2G8FG0LtsIptEo9k1do3G sNvsNo1ld9ldGmdMg8bzAA/QBO5xj97nmXlmmsiz8Ww0iefiuWgyL8gL0hRejBejqTyGN6BpPJH3 ohW8N+9NK7X370ur+Ou8P63mg/lgWsuH8qG0jo/j42g9f5+/Txv4bL6HNoqQtpp7Ik7EUaqoJqpT mqgtajMupolpTFiJ1gfMstvabVkZu73dnpW1O9odWZzd2e7MHrF72j1ZvN3L7sUetXvbvVk5++fA MFbeecZpza44Q13GUr1IrwZ/1WvuTeefhdqFuvAboQGhkTxZcRUUQZVf5ReZVEFVUESqwqqwyKwe Ug+JLKqYKiYeUCVUCRGlHlYPi6yqtCotsqlYFSuyqzgVJ3KoeBUvcqpyqpyIVhVUBZFLVVKVRG5V WVUWeVQVVUXkVdVUNfGgqq6qi3yqlqol8qtWqpUoYP6lsCioOqgOopDqpDqJwqqr6iqKqJfVy+Ih 9Yp6RRRVvVQvUUz1Vr1FcfWqelWUUAPUAFFSvaHeEA+rIWqIKKWGqWGitBqhRogY9Y56R8Sqd9W7 oowao8aIsmqcGifi1AQ1QTyiJqqJIl5NVpPFo2qqmirKqelquiivZqqZooKapWaJimq2mi0qqblq rnhMzVfzRWX1sfpYPK4WqAWiilqoFoqq6gv1haimvlJfiSfU1+prUV19q74VNdR36jtRUy1VS8WT aoVaIWqpVWqVqK3WqDWijlqn1om6aoPaIOqpH9QP4in1o/pR1Fdb1BbxtNqmtokG6if1k2ioflY/ i0Zql9olnlF71B7RWO1T+8Sz6oA6IJ5TR9QR0URdUpdEU3VVXRXPq+vqumimbqqborm6rX4RLbTx tob/InguxpJZsvZiaSxNew+b6/sArDMb6yyAdSZ5NI+mIC/AC1AEL8qLkiNqae/m2m3sNuTZ7ex2 FLI72B1I2Z3sTpTJ7mH3oEg70U6kzHaSnURZVD6Vjx5QBVQBvcYLqUKUVRVRRSibKqqKUnZVXBWn HKqkKkk5VSlViqJVjIrBe+rLUm71iHqE8qhH1aOUV5VX5elBVVFVpHzqMfUY5VePq8e1tzL+tyD8 byH1pHqSCquWqiUVUW1VW3pItVftqajqqDpSMZWgEqi46qa6UQnVXXWnkipRJdLDKkklUSnVR/Wh 0qq/6k8xaqAaSLFqsBpMZdRQNZTKquFqOMWpkWokPaJGqVEUr95T79GjaqwaS+XUeDWeyqv31ftU QU1Sk6iimqKmaH89TU2jx9QMNYMqqw/UB/S4+lB9SFXUHDWHqqp5ah5VUx+pj+gJ9Yn6hKqrT9Wn VEN9rj6nmupL9SU9qRapRVRLfaO+odpqsVpMddQStYTqquVqOdWD/3sK/q++9p1r6WntO9dTA7VR e8+GapP2to3UZu1tn1FbtbdtrLZrL/us2qG97HNqp/ayTdRuHTOaqr06Zjyv9uuY0UwdVoepOd4R 30JdUVeopbqmrlErdUPdoBfULXUL517h+ytGcfC1xbRt2awla6nZ7Vl7Yta31rfEAymBFBLBysHK 2g//e6xP+8D/WN9/rM+3vmhYX3Gz22KdAwf+Y2P/sbF/k40xu4vez0eyAjxO1LSaUm6qQNWoDjWi Zvp+oYvev/fVO8sRNIYm0yz6mL6kJbSaNtEO2k/H6Txd1zt7YgHmRfQhEdEzIjHiVaS9IvoiTYp4 DWnviNd1mqip/kgTIwYg7RUxEGlSxBtIe0e8qdNeWm4w0sSIIUh7RbyFNCliKNLeEcN1mqTlRiBN jHgbaa+IkUiTIt5B2jviXZ321nKjkSZGvIe0V8QYpEkRY5H2juhHXJcO0tgrYpjGpIhRGnv/BY2M x8h7RkzwNfO+r5mJvmYm+ZqZ7Gtmiq+Rqb5GpvkameFrZKavkQ98jczyNfKhr5E5vkbm+hqZ52tk vq+Rj3yNfOJrZIGvkU99jSz0NfKZr5Fxevw9I6ZDI7OhkY//oka+8DXypa+Rr3yNLPI18rWvkW99 jSz2beU7XzNLfM0s9TWzzNfMcl8zK3yNfO9rZJWvkdW+Rtb4Glnra2Sdr5ENvkY2+hr5wdfIJl8j P/oa+Rwa+QaWshIaWf8XNbLF18hWXyPbfI1s9zXyk6+Rn32N7PQ1ssvXyG5fI3t8jezzNbLf18gB 31YO+po55GvmsK+ZI75mjvqaOeZr5ISvkZO+Rk75Gjnta+SMr5HN0MgOaGQvLOX4X9TIOV8j532N XPA1ctHXyCVfI1d8jVz1NXLN18h1XyM3fI3c8jVy29fIL75G7vga+dXXyF1fI/d8jaT4Gkn1bSUt rBmHwppxWFgzDg9rxhG+Zs5CI5ehkZvQSLKxFPN/Gk2/cZrWlIqxHXyGqCeeFh1ER9FFvCR6il6i t3hVvC6GieFihHhbjBTv6Lvg4+KEOClOidPijDgrzonz4oK4KC6Jy+KKuCquievihrgpboXizf9R YtvZdn2B6ebXuaKuqEtc1Bf1SYh2oj1ZopPoTAHRQ/SgoEgUiRQhkkSS3gn0EX3IFf1EP/JEf/Em hcQUMYUeEEvEFooKPRJ6BKcM0eRYea0HrXxWfquAVdAqZBW2ilgPmZHpHt3C6Xp4v5LbP5soYcp0 nfDZNRMJv0sU9SVKmrMpkaBLyIqyzBvAilpFyb2vXvi6UVZWK5uV3cph5bSizbvvtOzfrsupEGWy slgPWLYVsKQVtCIsx3ItzwpZyspkRVrmvMvSYxugO2nqcOsxqzJ5VlWrKildFk85xFwxXywQn4m1 Yp1YLzaIjeIHsUn8KDaLLX+kcXNaJuaIObrFeeZ3zeIT8YnW90Kh/ajW3Bp9vePiwu+tz9FSn+jS JWKpWCaWixXie7FSrBKrxZo/mmO0PlfM1a3PF/PNE5ligW79M6G9s+7hFt26GYdpvRRF/WGrfzAO 6Oy4rzNT709aF+oZa9D17G58Eb1Jg2kIvUVDaRgN1+v6bRqJ/y76Lo2m9/QqH0vjaDxNoPdpIk3S a34KTaVpNJ1m0Ez6QHuAD2k2zaG5NI/m00faH3xCC+hTWkif0ef0hfYOX9Ei+pq+oW9pMX2nfcVS WkbLaQV9TytplfYca2gtraP1tIE20g/aj/xIm2kLbaVttJ1+0l7lZ9pJu2g37aG9tE/7mAN0kA7R YTpCR+mY9jgn6CSdotN0hs7SOe1/LtBFukSX6QpdpWvaG92gm3SLbtMvdId+pWS6S/cohVIpTZsx 4w15I/4Mb8yf5c/xJrwpf5434815C96St+Iv8Bd5a96Gt+XteHvegXfknXhn3oW/xBN4V96Nv8y7 81f4TL6X7+P7+QF+kB/ih/kRfpQf48f5CX6Sn+Kn+Rl+lp/j5/kFflE4/BK/LFx+hV/l1/h1foPf 5Lf4bf4Lv8N/5cn8Lr/HU3gqT9MuyDxtL4QlbBEQUgRFhGgoGolnRGPRQrQUL4rWoqt4RQwWQ8Rb YqgYKyaJqeJz8YX4SiwSi8V3YqvYJraLn8QO8bPYKXaJ3WKP2Cv2if3igDgoDonD4og4Ko5ZFa1K 5v+2WjutXdZua4+119pn7bcOWAetQ9Zh64h11DpmHbdOWCetU9Zp64x11jpnnbcuWBetS9Zl64p1 1bpmXbduWDetW9Zt6xfrjvWrlWzdte5ZKVaqlWaH7Cyyqqwmn5DVZQ1ZUz4pa8naso6sK+vJp2R9 +bRsIBvKRvIZ2Vg+K5+TTWRT+bxsJpvLFrKlbCVfkC/K1rKNbKs/7fWno/50ll3kSzJBdpXd5Muy u3xF9pA9ZaLsJZNkb9lHvir76k8/+brsLwfIgfINOUi+KQfLIfItOVQOk8PlCPm2HCnfkaPku3K0 fE+OkWPlODleTpDvy4lykpwsp8ipcpqcLmfImfIDOUt+KGfLT+QC+alcKD+Tn8sv5JfyK7lIfi2/ Mf/7VX4nl8ilcplcLlfI7+VKuUqulmvkWrlOrpcb5Eb5g9wkf5Sb5Ra5VW6T2+VPcof8We6Uu+Ru uUfulfvkfnlAHpSH5GF5RB6Vx+RxeUKelKfkaXlGnpXn5Hl5QV6Ul+RleUVeldfkdXlH/iqT5V15 T6bIVJkWpCCTc+RcOU/Olx/Jj+UNeVPekrflL04f51Wnr/Oa08953envDHAGOm84g5w3ncHOEOct 9zW3n/u6298d4A5033AHuW+6g9233KHuMHe4O8J92x3pvuOOct91R7uT3SnuVHeaO92d4c50P3Bn uR+6s9057lx3njvf/cj92P3E/dRd6H7mfu5+4X7pfuUucr92v3dXuqvc1e4ad627zl3vbnJ/dLe4 W91t7nb3J3eH+7O7093l7nb3usfcE+4p94x7zr3gXnGvuTfcm+4t97b7i3vH/dVNdu+699xUN80j j3ncE57l2V7AO+Gd9E55p70z3lnvnHfeu+Bd9C55l70r3lXvmnfdu+Hd9G55t71fvDver16yd9e7 56V4qV5aiEIsxEMiZIXsUCAkQ8FQRMgJuSEvFAqpUKZQZChzKEvogVBUKGsoWyh7KEcoZyg6lCuU O5QnlDf0YChfKH+oQKhgqFCocKhIaEpoamhaaHpoRmhm6IPQrNCHodmhOaG5oXmh+fj2GWf7OGMf wGdw7UFxcv6BqKPj+y7xlI7ve0Qz0Zz2iVbiBTqAaHpIdBfd6bCOeG/QETFGjKETYqKYSCcR2U8h bp1G3DqDuHUWceuc+EZ8S+cRIS5a5a0KjHACz23HdliMHWlHslicsZcJHAucZmdljIxjl3HefsMZ 6kzh3JnjfM+zOz84d3gZnLq3wXn7XB3tr1ME5aACOubX1zugyToCrNDeWV/CHUJc/QBqASjzHU0k ZaPc7gad3+Nu1LjP/UHjAXfz77J7NLWKgno/kYPy6h1A8fC3R+4+w3cPaPzRPaRxi3tE4zb3kqmp spoWVTbTospuWkRbKWj1t+9oInRunXI0blBuupJMKIlESeZ0JTlQkhMl0SjhFKFnLUbPXTlu/ltS RV6ROK/Ja5LgtXltsvjT/GmynbHOWAo43zrfknSuOld1e9yez3/6b4qx6SPs/+34+j8TYU0M/bNx 878zZmaR7WQH2Um+piOQiZw1dMysh2jWUEemUYiTTXWMNNExHBvb/8mo2O8fxMO/j4aTdBz8WwS8 P7r8b4uGv0c7HRcn6vh9f1SsqncfZu8R3nmYfUcDvfP41d933NW7juf1jmM69hwz9I4jWVvtc9pS XzB2+Vvs5F3Tx00v0svsZfEe8KK8rF42L7uXw8vpRXu5vNxeHi+v96CXz8vvFfAKeoW8wl4R7yGv qFfMK/6H0XbIH8dbFaEc5f6pqLvg7+OuyqQiVea/i74b3I3uD4jBm/8wCu/RcXife8A95B75LR6r bCo7YvKl/2dUTvn7uKxyqJwq+l+Kzulis5fyPxCd6zPOsupb2WhWlKJYA9aYCuI796KsFWtPJVhH 1pHKss6sM8Wxl1hXeoS9zPpSOdaPjafqbDKbRq3Y12wbteE9eCK9zpP46zSQD+Bv0DD+Jh9Kb/Ph /B0azd/lY2g8vj2fxCdw7e1xjz9deCILzRBRIormimyiOM0TJUVpWiZiRXVaiYi/ExF/F+7edluz rG103s5sZ2Y57Nv2bZbTvmPfYdF2sp3McgW0uljuwPDAOyxP4N3AWFYgMD4wkT0UmByYxkoEZgQ+ ZqUDCwKLWMXAN4H1rHpgY2A7ezawO7CbtQrsCxxgLwQOBY6wNnpvkMLaB9L03mCQjJcV2WL5mHyc rQgWCxZnq4Ilg6XZmmBsMJZtCMYH49nGYPlgefaD+f6MbQpWCVZhPwarBauxzcGawZpsS7B2sDbb GqwXrMe2BRsHG7PtwSbBJuynYLNgM7Yj+EKwLfs52DnYme2N0Lf9bJ/TxmnL9jvtnU7soNPFSWRH nSQniV3QcXYKu6jj7Pfslo6zd1iqy93mXLot3b68tTfDO84HhN4JTeZrws+36LvRhfjGpSXr4HO+ uY/DqAIF/L1HEb2nidPlc/TH4EK9K5iD1OSW+7nlOndIf8xTNiVYCW01pVgpHe7KsXK6zSfZkzq4 1GV1yWIT2UQ8ZbORWtvRdi47t53Hzms/aOez89sF7IJ2IbuwXcR+yC5qF7OL2yXskvbDdim7tB1j x9pl7LLsZ7aT7WK72R62l+1j+9kBdpAdYofZEXaUHWPH2Ql2kp1ip9kZdpadY+fZBXbREpYlbotf xB3xq0gWd8U9kSJSRdpf4Vl6KBbHSYOFXytkxtlPDv0RlFt/LK25h/RIS5J5Lq20/gS1VivofWIl /XGosv64VJ1qkEd19UdRE/3JRM9TM70/bKU/Waid/jxAnfQninpSImWlV6kvZacB+pNTr05O0SwT i6Rceo1GUx6Wl+WlvHg65kG9XhtQPr1em1F+fKtbACu1IEtgCVQIz8sUZr1YEhVhr7PX9ZoezoZT MfY2G0nF2Wg2mkrqFTyZHtYr+GsqxVayVVSarWcbKJZtZpupLM6b4rDy4rGnroNTp1Y4dXrx97Ow tf5Z2MNaU3l4LI/VO8Z4Hm9+G8ar6x1jHV5H7xgb8UZ6x9iENyFb73vaU0DveF7SO8ZhzggKOiOd 0eQ6c515FOl85CygLM5uZw9lc/Y5BymHc8Q5offS/dz+lF9Hj8FUyEQGKqYjwwdUwvhxKq39+G6K 1d77ED2iPfgRitc+/AQ9qv34KSqn763OUHnty89RBe3PL1BF7dMv6Tkyz39V5C1+H8smfyyl9Fjy phtLeV5ey5oRCd5A38tYGJGNEQX0/q4ZSYwrqHdvr1AExuVgXCGMKwvGFeUsdD7XI/rS+YZyYYz5 MMYCzhnnHBVxLjhX9LjMSEthpLEYaTxGWk7Hvzn6/mCevst4HKOugVE/qePSbaqro1KKvjMxI6rN u/jfvppfObbDiEqbMbJGWPf0O4dwlslZJ1bldx5njVlJnYv6XU6vgD/QRSVeSevCaMTCHNvQSwB6 kdBLEHqJ0PveluRAOy5m3YOOQs7zzvOk9J15f8qk777G6Lkf50yh3Poe7Bsq5Cx2vqd4fSd2hSo7 15w71F7vIYZSV71bGE199e5gAQ3Ssf9rGq9j/T6ahrlfjLn/TkfwY7QEFrAUFrAMFrAcFrACFvA9 LGCljuxXaJWO7tdotY7wKbRGx/MAbdV7nBy0W+9r8tNhvZcpTqf1rsSly3p3kZmu6Rgfre8AtCfU d0ivEJk7SKpmThmooXlui55xX/Nq0FZdJw+bhKccxd9mhNpArzGwugb3zUjM32aEGlPl33mcquDb 86jf5TgJZ6ozW195pbNRW9uvrrFfzcV9drg/+dGTGP/qXF8l+l/xrLpmVvghgh9i8EPiv9q7Dqgo kq3d1RMYZoYiDDknRZDQQ1ZBBARRFJRBUMRAFiSJCKKyKgoqK+oqkkWCKCpJQTFhZlcUc8CEATEr ZlEQ+KsLcdHnvt33zv/+Pf8579ShbnX30NN1763vfreqpxvjEBPjEAvjEBvjkBjGIQ7GIXGMQ1yM QzyMQ3yMQxDjkCTGISmMQzIYhwQYh2QxDslhHFLAOET/rvgY6gGfdGHsR5r4s3UYEnCBDLpKbWAA TMFQ4ADGAA90df4gDESDOMRdksAKsBqko28tAFtAGdgF9oJD4AQ4Bc4j3dxCengM2sA70IHAn03y SRlSkVQndUkDpF1LYIB6PwjpwghLHxT9aDkVDMFyGhiK5XQwDMsZwAZLP2CLpT8YjmUAsMMyEI08 WgYBeyyDwUgsQ4EzluEootIyCrhjmcNSoCVzD0sRy1qWEi1hJ4dHS5aAw6clezNHAss6DsTyEEcS yy6OFJbdHGksezgytETsRYClnSTA3xMG9BESSKI4T6ItQ1T7oGhPcweEB6iXyAdRH4WongFMUe0H zFDtDxCPQH2zQHUgsER1ELBCdTBwoO/9AI6ongWcUB2O+AKJeuWC6mgwGtWzwRhUx4CxqM4B41Cd B9xQncuSJUjUXzlU17LomY9ODjIM6inyatRPJqrrOIhvoD6y6buZOGKo7uZwUN3DESdI1DfEfjh2 hD4aVb4o3oajOLuQWEasItKJPGIzUUbUEAdRHGskLhO3UOb/HI3tL+t5yJMUka/rIl+igCWwQd7k AtwQQvqgfgejXmxH2spBGtqB5VRQhuU0UI7ldFCB5QxQiaU/qMIyAOzE0g/swjIQVGMZBGqwDOao 0RL1UZ2WqJcaWNZxNLE8xNHCsoujjWU3RwfLHo4uLVGPB2BpB/Kx/TZhyxVgyxViyxVhyxVjm23G NivBVtyCLbcVW64UW24bbQ+OLNa4HNa4PNa4Ata4Ita4Eta4Mta4Cta4KtY4IJiSBL6rm4GxgsAj HUjSP9Ggn+Trhu+pH0SYolj8ZSYKyGNfU8A+okh/N30WoPS1NZP2JBp7EZ5kYF/BNb1CBqQQQhFA DuU0ACMRifGFjmmKxEowEXiDyWAS8AIzuZNQ9PHpnRcm55I/kSvIDYwcxjbGLvgZdsFu2IPwdSM3 n7uJW8At5BZxi7mbEdYe5R7jHuee4NZzf+X+xj0J2yEJGZAJWZANxSCH+4nbwe3kfuZ2cbu5PTwE e7xfeOt463npvA28DF4mL4uXzdvDq+Xt5e3j7ecd4B3k1fEO8W7wbvFu8+7yWnitvIe8x7ynvOe8 Nt4r3hu+GJ/DF+dz+Tw+ny/Bh3xJ/mC+Id+Ib8w34VN8Id+Ub8Y351vwLflWfGv+EP5Q/jC+Dd+W P5xvxx/Bt+c78B35I/lOkA8lIIQyUABl4Uf4CXZAFagK6TXIgTjrI3Cmx0LMwRXFtDAyHEXtWJTR 8clElNFJ4LufIc7fJHFWJoXnXqUZOxk7CRl2JbuKELBr2bWEHLud3Y54G8pVCAU6V0H85jb3AaFP ZyyIzaxAsXsoytl3E44o275OjEUZ901iHI7dbjh2u+PYPR7H7gk4dnvg2C3CsdsTx+6JOHZ74djt jWP3JF43itqT+VIoUvvjSJ2II/ViKIci9VLUz/2Ez1+x6L9nwf+InfosxMXaJLA2xbEeZbAeVbAe dXHPjXDPLXHPJ+Cee2KO4t2b+bHwm/5QewxBz+s6EOr9/f97L/5jf+z1HXQGaewpBPYUBrYwG9sT YntKYntKYXtKY3vKYHsKsD1lsT3lsD3lsT0VsD0VsT2VsD2Vkd0UCJUvV89jwX5XDxHf/DJi6TGP /ZTAfgqwn5LYTxlf/pfPkuz3v4qIlXxFgb6RjpEDjwLsySzsyWLYkzm9WSx4DT6Azi9sQJqUJ1VI HVKfMZoVwApihbBCWXNYc1nxUAvqwAFQD+rDwdAImkAhNIeW0BoOhTZwOBwBHeBI6AKnwUAYDGfC CBgFZ8O5MB4mwEVwCUyGK2AqTINr4DqYDjNgFsyBeTAfFsAiuBlugaVwOyyDFXAnrIa7YS3cBw/A Q/AoPA7r4W+wAZ6GZ+A5eAFegldgE7wOb8I78AV8Bd/Ad/DDf+8q/+89l/9L91yShBTi/MEsAexE Md/uL91TjkYiCGPf6ncHMIe+V+bLXTX/9B6Zr/fRoHOQtuS0rzl77x5XhEB9OS8J3hHtiKNbkNbo E45onzs5gfQiJ5O+ZCDCqmiEeon0mtaPCr2O1b+gs3xbrP+x0Kte/Qu9RvbD4vhdcaZX0L4p7v9Y 6NW0/gX15Q8KigffFNTnb8vkHxUUP74pSEvflmm4/L4d+F0JQSXsD0r0jwqv+9uCota3Rem7ov1t +dK/3uvFZ/jv3MQfzE0A4jaKnzYo1rsglu2Jn4PS9/QT+kkoqcRaIgNlP0VEKVGB8p/9xBHiV5QB XSSuIf1ReK33X62t/63a/d+pfzj/0Ts7wkcig857CHs6F0CxTh5nD/QaBwD6KI8mUbTfgNoZIBO1 swD99u58lHmRYDd4ST8BFrxG+cob/A6M9+ADareDTzhmdqL2Z9CN2j0k/QYSkmQin2ORbNQWI+mn pvJIlH+TEvh9HlIkyrFJGVIWteVIedRWoN/PgeKqCmqrklqorU2izI3Upd/8gWKsPmobkAaoPZgc jNqGpCFBv9HECLWNSfpNPLlkLmrnkXmovZHciNr5jFH4Ka6jCQZjDEtAPyeOhfrLUmY50U82ZI0i GCwXlh/9nG5WKGqH0W8FRrE6HrXn0U+MYiWzklE7hXWEoN9wfBS1j3EQMnNIlEWSnIHiswggHi6O mJ54hMQ2Akhsl0BZr8QOiaOofUyiHrV/RUwVQHXEMxiITfbgDA+hsiQpOaD3N87YMiTh/+WXub9z EIA5CMAcBPT7BSnAHARgDgIwBwGYgwD8uw+AOQjAHARgDgIwBwGYgwDMQQDmIL1XSGImAjATAZiJ AMxEAGYiADMRgJkIwEwEYCYCMBMBmIkAzEQAZiIAMxGAmQjATARgJgIwEwGYiQDMRABmIgAzEYCZ CMBMBGAmAjATAZiJAMxEAGYiADMRgJkIwEwEYCYCMBMBmIkAzEQAZiIAMxGAmQjATARgJgIwEwGY iQDMRABmIgAzEYCZCMBMBGAmAjATAZiJAMxEAGYiADMRgJkIwEwEYCYCMBMBmIkAzEQAZiIAMxGA mQjATARgJgIwEwGYiQDMRABmIgAzEYCZCMBMBGAmAjATAZiJAMxEAGYiADORvueDfH1aiPI0JGXx XkLZi0pS9mCLG6S4pLRLADGyIEnZEe2yIwEQ8ihxNmswZJDKLILyY3MHswETJFmRgFkgoiZQhv32 qBapL1bFyzk2hDvhT8whohCIBhGx6I9e3hlOafU7GVN2UI9gVL6rQ84atZBW3sIo81KJ4MsFSXJG VBKzgEpirChgkIAkuX5KjevxZQdTEl8vErDQ5STgq2NMZLIF5ESRUEBJ0xscAdfbb87M0MiQ2KhI oRQF6Z1iAjGPoMCIqMhAoTqlSu/hCuTGhQbERM2JCo7VdIyKiY6K8YsNRf+hQ2nRxxkC5f7HA4M0 RaEhkeismuMd7Sl1BQmhUEgJKVPKzNTUwgdtmlHCr5vUkqX/kWuToHj0cZ6AOc59vEffxxl/8HEq CWj31xn99qgkBDdoP5dMAoBom3IoUVr3fgr7bnCPy26FOrK1hm/6KmZ4ovHyJrfCnVsdTdqD8oX3 TIVOFU1HdZdpNRnvXvZTh8UlkWrTngnq7meD9z2r5ZNd+r7lpcs/nNKuuXKYM/d9avSagKaXqepP 1jjqBvpcWp64NmJYWdwZb8vExwelvMqyXq2cahz4a+VA8WnqAXKvbQ/Lr8leQR6nao/yZmhIxjRe rS21kEnJLeRxH66fsrrDM+/oW6XpDmkym9Ts1tbqCZYqmSapvb2+/LLWLpuiPWLuTbrb29LeV1/v +DTEfeuTN5WTPd7dss81kY4OaH56e/vrCC2mlMjswC73+nuiXfZBoyKtPhx8kitv/8ss4ynUcZKB BkRxElBDGlGiBEiXagOYfIrL5iCnZrHEGAxKjd4JEdmWVfGAb6UNao+sPC69xPZyxqR9xaJIbEA1 SfqFa0wU1RZTGvS2DlORkl8se1r68amLNfKTQIOVsZm8/L6xOVwNyov+gAbTnRpHuRaMLhiV4jQz NjZ6qIlJQEy4cUSfFY0DoiJMomeF0ntNomOiAucGxM4xQUZGjojcEHngdMrayExoZIpc0Bh9iPLp u2YAmG7UWGpM3zZFpgz/8hXx8fE/+oqgmH967tjvhh2D9pySKZbh5W65oTL3o1LJ3ND44+GBMYNW XLd1ijBUXHB5kImgZXKYyjGeeW1q19N96c/FhA/D3s1lXtp6Y9pQdr5U1zaJurwJjlE9Iel5984t fKVbZdG4dGrbjSNRlqOP+HC9P8y5l//2PmfssOEmjRfPtLlrR7czNcgtrrl71/iugJbp4WZie7eV Tyg4f+zWam2ZuuN3kpq8CtubX5VoektJbWwrS4kNn5179NWbY9HTtt6MGGc1KXtcwojz5lN9BlSE PFNxc2ZXrdLXKJZaU2K2SefKx93OiXfbArLWug5nlZpUKVZP3lxpL1rNYUkZGTQMZY9VNd4mnOAV WJbTWJaZpZ+auXb50417EEbtRxhV1IdRLKUMjKUq32NU/H8EB7Swo6GBr/j7cc/QiCAjUaxfRPTv CEVZmVqYUuamwiE0QpkifOrbpJZU/18glB41oHdTPdIxNHpmUIzmSJGTppPIbegQJytrI2tLcwcj ymzISOEASqe3R6o/7JEoKCYuNCDoTxHt0ulhoqJNI4vn7xjnNVuUGr/dav1PYHjXDrJYtK3nwk7t emLto7mRbYqPl0BB/TU/4pBGQdwwpgSznllQ+tlRxC5kMvfx1mWR/tYvL5vJtA+2XfCy3Mk7eYPm pqYA8zx/59WHKu5ezx/yYdvErnOP4h9aCF76Pj7sst5d2VFsknXqomTZ8KcN513nJ0WeviQ3gyO7 Mr10it3QBjvNxAiTScqJp1KtDx4/NmTmNaNJyjovDKQ4PpqrkkpeXMh0WpfceNxq6R2JrIX1l/bc zRZdm8d5/0BHS8w/xScsVKkr+pPIfEn7AKFSyvKfj0zM6do+1kKua8qTDQ07RFn60w1L7g2QDKx/ U6U3tw/RxJFGWP3AK0HnUaHEoYmGMxX1/ZNCrr69Z2nt8w1Y6Zh/vO7hHM19MaIzrrN6cNVxi2pJ yrMXrBBUUQiqCpxSHP8lsOo9TFsRGxF5JYaqSf2gCgEV5dIPqmz+GlT98MyxP0Jwzo/Qa9SxuCVT hM1Rl2yy38wP/ylTMN6QpaAitXdk4e5V77zO1VVp1QRG+Klea3v87P26NscixZHHOzpelu/xXZQZ 4brbsVPPbx7Hc+HOT5VZ3JrYE9sfG40/kdid6FaYfVVvUG3FtTs71yzVXn32bcJnP9mIw88al1Xd KT4whVX71PO9v1q43pYA1477hR0H7iRnBIWKqvbMzgocGFxX/9rX/+Av72zzXB0IiXPWLNmBPrcM WK6LwrKtrzXPyS46u2q8bv7mZ+/tUuc1emZPHRC82Z49qHL0iRqP9Oe3yaWB3eMu97gWfdZffLPN bofNC7MVpw5rzzjvO4xZxa3JirDZOtQ95wKQl/ZPtY9D7Ip1EKHX5j70MhuojNFL+D16TcewwBVf N3Dl+jeGgUBJnoFsIVSiFL7ZKf7VVEIjanDvONb9fRx7REUhkEC2Cw0ODfCLDdK0nxs7MyomNDYB oxRFWZsJTREomZkilDL9smlKb/6dFO/PoGZXzGRfJSrwsFrODE1Nh+w4UfhwlatRjadfP53VnSkv dffO0NilyrUmBabPe24fc3DTuRJD3LTw5q48VaE5+t2rmWXjXNNK6hJcZ+eOErvRNeDOxrkrzm2f M3JR05Kbb+veWG5u8HW6VVlue3fQzEzlrSUxc7xeK6S3dlmkxxRcjZuuHu+0NNla/vycKaz9IR5p JbtCTW4o8brXxeq3xJl4NstSkz9eTPPvOt0w3Vk4fp+eoHUEdS5GX2qQ9m9WbrYFprZrzxRas5N9 3bySBhmwTGtdm9wDHl008n/tZPuojEN8cC7MvzBl1UDR4/nbx7xxPmdlY51fE+9bopCfdlp6jZfN 0TLx6YxLfVAzDWnEh5Kkh56AJkIsioFEP+z5IQ/iYeJEsyaQQsmwxb9kEXKAycInRuHg6z6SPkvX BaHbpYGpG+5lzRhWKozaYnPwmhGl9PVDsiSTr84lRMRclHk4EvbfgBssS5oxwksv88EAwWeDe1zR hsmtm6nxveA2mhpFORU4Ftin2P11cPt6OAa5No1KGNg8+wGbC+VMjewHbNb/CrDRA8ax96z/yL5I QEweMnzRQOfKZ1EjdpruDnsGTSJLR7c/mz73xdhhRk2O5bzu00+MhMU6jQvHZy3WmlpmazJ2f1Gp V9796AN7az4m7B4d0z78qf2iU/f4CqGnS/I0jTp44094nTG6P+biwehHpRJFjBKvu3tTXb3fbHDI e/32Zdv9FA1zm71eOa9EOskGm5NU17eki6m9aXH7uKrw1GNByS9uJ1UuronZYDA7Ilf5o+or0dWQ Ru0eX7UzRavq9HYlBHiNLJpw5tOT4klezbmk00iT6e9uVFxOMo38vHmDoPVZ6KNtRYaHTg6WgkGr s2++L+qQGSgeZJ3+er7GmAMX7nk9Pj8vQ9G3wUJ+evN6tdGrjQ6Vm49UbZOSUyamNltM0Tqb9Zt4 WzJc5R4BBW62C/Vd8mIuvA0/dfR5dLH3Ou/E9LQCFReGT/u54hBubInlCyMThZMPY6xk3kXttAlJ +uSxK81MPkgdpjZL3Q58F3XW+fIlhScJJ5g1lzoN72ik5pdxOwV6I8pbP93btsj5gNiMUUEzRrhV OTx3e1Edl3CNay4eobpYqNECPZsfFHY+GCVVHpjVM17eeOFhltb8lg32eqHH16/Z0JB2LVerQsI3 71VRRcrMpfwwowNxswi1jPI38gs+yC/V3bfiXFjpKKFJzq37s22biJ/8R104u6Jhr2IHjEk7Wmxb SY4I6wnNzWiRKpWqsRrPuXrclkpiiyH8ftmH3/IzzTF+q/4d+E1ZUeYUQmwLM4pmmYhk0ptmFL35 99HfP0PvTYXhO+/cdFlnsHCWsdK9upb79dkTdMaXn21WdNOVbLuw9cLY8lhKU/qZ2BXPDXKj01Uc 1lVk+VIDbxCzHi+oe75STLIdMlEq26hx2kx3+cY370JUDT8veLRC7ekjt+LCozqiU2kdTufEz0+r PF/lwCz6tCV8fUjToFvOoqqU8w8GORvrlaW4T/TgtzIMO8PWrqUil7+dTG3s+OlqZvVjrcyfPl4U vOXUiiI8apzWbnIhxowKltbTDy7NbL3EXjKm6NOyrdKjZMWTNi17MXFeN8hRG89JJqQo5xe1t3Wc D5ww8txUqT7PXhjfmHtn2NL1hX7kbjWJnZ/bc3eBs9qunj2fWMePafL60HsH0sjWf4bePySG36C3 VH/0pt9DTS3J6gXfJWupJWk/ht/CgM1+/3H3TJJKKJcvHFNQUj52zqR3YgLjoP83qP+XqCzStVRm 6nFfxkjL5ic15fE3zyZMGAd2GsfOnhLBF+w4e2jBmr3Gl2WKVkX47/UmT7tpCsZnN88f0eJ9oHJS juo9NZBSdmDem5/PPx8G2loOreGyTqa5tLwSyTW771jX+igt7Mriow/T37BNkhlPfjHQ1Y7u/PC5 dV62sUS7WEv0QUW3jatncWM27C0ckhdiVD8BPvX3tZPP+lnTrkVM2fRTo3BMnNB2cAzv5NNo255k ruDOMa7f6ldNexWeuf28qN5i8LTiw88OJvIcFlwWxWi1UacOzAvynQIUuLLw4g3ZrPc2+4InVRuZ PPqUnNI4wevxxuj08LIhYy9/SDi8XXG+v/7Lolx9c3a8sn+DrXqERtIr3m+GB845Vj/49Dxx9/3N pbEWe93qZ+vIDIzj2Xismu3j7Ch7sLq6alzIyU0OPYsTtBbny1HBjx1kpimfzNfWOu/4ZPCTA+9c Gg0vXzNdPHaggYvudJ+nXi+33M7eeGpoVN0SvVi2dFuc1uHcpKN6nnt2htmuLIzzq4ksFGw5vH3U K5morlTT8F3ddyacXKXTEFy3UW25TCBpa1Q5ec3eVq0Hu6tOBdTM82RdtjceX5ZeVTJvR3VBxlzl 6+uWC+Zqm5iWciILpqwacLjg5bJTWlefqbs35LSNvtsOgqJW8hJPhp58GPl0a+ZZoX4PrJ/ie22c SuG1DpN8O+OJ8rMaBMVdwiRmJpXEXE8CQC1Z/jfy5W8man+f5i1YcoJmaV/cVpwh5PefQ0bf+/sW Twip/kflaA7Y949MIcIicLndyGsM98OIi8n19dL5qlOycg9Sgf3+hS/0ojwLDBYPIsYRoUQAEUNE 4WnoYCKW0CQ8iQQiGm2FoP1+qDWTSCgcuFj3D8dobEJ0VEiMX/TMBM3vYgkzCRCC9lYnw4A91TU1 rGZ/7Y6bi8V50+MFmQtG+VWELxJbxj4z56ZJx/3Iuy+T9+zb8nKk9X7FFdz3ndump731PBM/M3eQ tZnMjrztLyQ+aDxYGch9rrS4asTFQbZmuxTftpxZn1JRPnLHtpZIi12COomyzH0XveO11m20M6w9 dKyBeK++8+D1m21HzZkB9quCf3ulcbTTYVlrpa+H5JMjPicuJP9S2KJ+0jq77QrVvNZzXkh1JTnx 4fAd3XM67LOnRD0LgPMjnwra5eQmvR8XfWmC8lP50u76EUnZEnNfPp59O0OxQ+70R/L1zymrtnjv GZvzPnia3bQjpFHbK++CAPPWNVesIqPbL9ePXWZZmESqUUlkP+OyhUkkF+1iY2dM/tuC/zfzcWJf XLFgKqXY3w95vy94APSNX4+whJL0VBllIbRCOamlGSIx37thu1DNrGR5uuYRjW3mT8S8I15YHT73 HTbTDuK0+1bw9U8v4q6pqQSHOcwae/Q3TdhwbdntWR+3MrY+/c3OcN+xA4J1U2/dqjytMrw408L1 +dq0eVOvWtx/1qR3sM7Ah7qbzN3e3Rm8t3Lea86kghX2KanapvtFu3knqysurjnpelAnOr+5mOFS dUXdcaHmwxtyGftHc5oTgg1URA9bx4TMWZ51dsth/xnVN4Y/EL9V0R2bx5AoXb8gjvXRtbXiw/X3 dzN65j59m1FTUKc7HdyvODX/XMKZyl+zenRTz+hsIyhXKut5Q+xhJ+eL3spiXoNVnnnYJv7MG1I8 p8R99LbUyGsOyYmU0ed1js/DoL/S/verJg5suD4k5mabmXCtpFjgtKY5pwnifwC0gVuXDQplbmRz dHJlYW0NCmVuZG9iag0KMTIyNiAwIG9iag0KWyAwWyA1MDddICAzWyAyMjZdICAyOFsgNDg4XSAg NDdbIDI1Ml0gIDg3WyA1MTddICAxMDBbIDQ4N10gIDExNlsgODkwXSAgMTI3WyA0NjhdICAyNThb IDQ3OV0gIDI3MVsgNTI1IDQyM10gIDI4MlsgNTI1XSAgMjg2WyA0OThdICAyOTZbIDMwNV0gIDMz NlsgNDcxXSAgMzQ2WyA1MjVdICAzNDlbIDIzMF0gIDM2NFsgNDU1XSAgMzY3WyAyMzBdICAzNzNb IDc5OSA1MjVdICAzODFbIDUyN10gIDM5M1sgNTI1XSAgMzk2WyAzNDldICA0MDBbIDM5MV0gIDQx MFsgMzM1XSAgNDM3WyA1MjVdICA0NDhbIDQ1Ml0gIDQ1NFsgNDMzIDQ1M10gIDg0MlsgMzI2XSAg ODU3WyA2OTAgMjUwIDI1MF0gIDg2MlsgNDE4IDQxOF0gIDEwMTBbIDUwN10gXSANCmVuZG9iag0K MTIyNyAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAzMDYgMjUyIDM4NiA1 MDcgNTA3IDAgNTA3IDUwNyAwIDUwNyAwIDAgMCAwIDAgMCAwIDAgNDYzIDAgNTc5IDU0NCA1MzMg NjE1IDQ4OCA0NTkgNjMxIDYyMyAyNTIgMCA1MjAgNDIwIDg1NSA2NDYgNjYyIDUxNyAwIDU0MyA0 NTkgNDg3IDY0MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUg NDcxIDUyNSAyMzAgMCA0NTUgMjMwIDc5OSA1MjUgNTI3IDUyNSA1MjUgMzQ5IDM5MSAzMzUgNTI1 IDQ1MiA3MTUgNDMzIDQ1M10gDQplbmRvYmoNCjEyMjggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggOTA2NTAvTGVuZ3RoMSAxOTEzNzI+Pg0Kc3RyZWFtDQp4nOx8B3hUx9n1zL3b tEW7q91V2ZW0Ky2SAAkEiCKK0YIKvagsSIBAQqIZML0XE/cI4xLj3u24gu3VYmxhXLCDe9ydOLET B6c6Cdg4LrHBkr4z970jBHb8ON+X50/y/Brp7DnzTrkz75T7yhJmnDHmw4eBTS+rnjDutc39ZjLl jVTG/GvLx5bVWNMmNzL2jp0xz6DysZNLxye1nmTs9QLGTEfGlZVX/OknnzGmvNKbMfWjcdOnVS9p HnkeY3+JMH6TfVx1dKyq9vmKKRdNZqzi3WnVhYO++tU7HzLGf4GnNjQtb1zZcuOLHzPWexnaf9m0 fm0oduPhNxmru4IxY/rClYuWf/HFFDy7oJmxBP+ixjUrWToL4/npaO9atGzTwqy6ySpjc/cydlbS 4gWNzUffH3QE/c9B+dDFMDgeMA9BfjfyvRYvX7vx/bfSqjDgYsZyBy9dsPqcAwffmsrYYy7GLHuX rWhq3Dv21t8xduMhxjKnLm/cuDJrcK+/on0b2ofOaVy+IO3+VVsYe+ZxxhyjV65Ys7YzwC5i7LWv RfnK1QtWLn1I6WBsyA48zsWEb41tVXccrXp2nnPU5yzNwkQ6+NetPxX88rv7zj95on1nwlHzI8gm MIVRQjsT62D8sPW2kydO3JZwVOupW1I/ExZnLmtgRjYB7RTmYoVsAWPuK7TncqYa8vkVKLUYrzcW octMYvV1dpHCLExxGhVFMaiK4QhTOiNsbyc9l7Ep1aEQi2A6LhqD+RYlN8T4rdpzHzUmipmi98RT o+GvYfvcLtbln0uGWWyvoYw1fmvZUbb3tBl/eHr+HyX1AbbXaGezv9Hf16faK4bv19dp7XtTG7X+ 29ua3sFz+357mXEya/qnnpV9qh9D7Rl+eICN+7Y26h+Z87RnZrP7/5ln9qSe9L9J6s/YnH+2jWEw u16dz2Z9z7oNpz3vJKv/Pu2UVSznnx3X/8ukHmZDvk894Sup+c/Zhf/r5915Wj/Xf1sdUzO7vvvz vjGW4u+3Zl319b7EGiovnd6vmsUqv08fyoMs65955v8lYZy7v29d9WaWbWz75hqqG1gf9VaW/a8d WU/qST2pJ/Wk/7ak3MitUqv7v/v9zTtZ3652Rnbtv3IcasqZP0Pqz1nDyv+Vz/lXJHUI2/nvHsO/ KuHn5KX/7jGIhHGMBx7U9SJggK7/I8bXk3pST+pJPakn9aSe1JN6Uk/qST2pJ/WkntSTelJP6kk9 6b86qTrS6bcR3Isc10wG9iUTf1kWghLJwbLZQDaYDWUlbAKbzqJsCdvEbmMPhFydnXqNECtgRVqN MWwSq2KNbGlXDd75ufbAx/HV7W/VOpuUZ383X/9dSDp6oNQLTxrNyljNqZGqE9Vr1ai6Wq1Vl6lH 1WMYl5slsVS0ymV5eHIhG6W1KcezZ7JZbC5rZou5wp3cxf08k/fm0/ksXs+X8RV8HV/Pt/Ef8p38 Un4Fv4Hv54f40/w5/jwz8aPa8z75xu9nuPZ3fSIp7LsTPzXib3F59zkw9WP1OD7/9o1aUxj7lhmy 0+bI5Cz/wTC+MXfYvnv2/+lJ/Zf29v/pHo+Ma543t37O7Fl1tdGa6qrK6dOmTpk8aeKE8eMqystK x46JlIw+a9TIEcOLhw0dUti/X0Hv3Jxe4exgqtftcjps1gSL2WQ0qApnBeXhioZQLLchZsgNjx/f T+TDjTA0djM0xEIwVZxeJxZq0KqFTq8ZQc2FZ9SMUM1IV03uCo1io/oVhMrDodgrZeFQG59VWQu9 qyxcF4od0/QUTRtytYwDmawstAiVpy4uC8V4Q6g8VrF+cUt5Qxn6a7VZS8OlC6z9Clir1QZpg4r1 Dq9s5b1Hc00ovctHtCrM4hCPjak55Y3NsemVteVlgaysOs3GSrW+YqbSmFnrK7REjJntDLUWHGq5 tM3F5jfk25vDzY1zamNqIxq1qOUtLRfH3PmxPuGyWJ/Nv0/FlBfECsJl5bH8MDqbVNX1AB4z5rjC oZbPGQYfPnb0dEujbjHluD5nQoopdrkJ5VIzjA0jxPyyssRYdrZF2HxkYjsqaykfYvMDcRYpzK+L KQ2i5JAs8UVFyQ5Z0tW8IZwllqq8Qf9evzg1tmN+qF8BvK995+Ab5aGYmtswv2mx4MYFLeGyMvJb TW0sUgYRadTnWt46oBD1GxswiSXCDZW1scLwypg3PJYqwBASa7CkulZrojeLeUtjrKFJbxUrLC8T 4wqVtzSU0QBFX+HK2gOsqPNI6+BQYF8RTmCdGEcsuRSLklveUtu8MBZsCDRjfy4M1QayYpE6uK8u XLugTqxS2BXrcwSPy9KeqLXC3M6oLSuLmZtzLKFaJaDWidWCIVSBj/DYUShwYbm0rFjRsaNCtTzA ZDU8Ra8h1Gn9IKPmlI4XRapoWjo+kFWXRek7hhTQx2TMiVm69eWCoWtM9Jx/ODSqLQbUJ1S+oKzb AE/r1KgPUO/t28epCF/oD0YLi1jO8bJIzcHJhU1BN5pJrGJqKMamh2rDC8J1YeyhyPRaMTfha219 J1WHJ1XOqtVWW98lNaflqLyYcjGWhWKZUUqxByvyA3JZtfw4Ld+VHX9G8QRZHGqxhCdVt4jOw3qH LIQThEmbcic07ixOGoyjWYHbLVzRGA65QhUtjW2dO+a3tEYiLSvLGxaPEH2EJzS3hKtrRwW0sVbV bgtsFo9KYpP4pJqx/Qpw94xtDfNLKlsj/JLqWbUHXHhvXVJTG1e4Utowtq61F8pqD+DVEtGsirAK o8iEREb0VIWMRasfOBBhbIdWatAMWr6pjTPNZpE2zpraFLK5pE2BzUC2iGYTCYuUuhguxnVbHmoW y7O1bnFLQ504XCwZS4lvHuPh0SymhEe3csVkj1nDC8bGbOGxwl4i7CVkNwm7GRuDJ3M4R9xJLQ1h 3FPYULUswGkrqqLLUFtnZ01t1iuBY3VZ2GpzgFm1sYR83P3GnImoN06gAeZxsR1NjWIcLFor2ppz JjTVYdvKDlFlQiwBPSToPaBGhdZGbEc0asLaYAG19juQie2oi9Xli4fWLqnTtrMrxsaHR2DZqU9j rnhQYV1LUniQdjZxFKw5FwtKwNhYdS1ZAsjiYXXkJLMdI28Ko6ipIQRvG1hTNbY63aXWAFkW4Eo0 5C7QYA3ohUxMS82xOayxhP7oEN9C2/qLI2nMMdfV0eC13MV6BTzbFbNhRLndXKk3gHdQNEGMBd8X Y6ii6tOim8o2VhXeiJtFDFrryYzimCNnQiMuf2pvgyVcLBtbxB1h0/s4TFazmLkdfldzato67wlv yuqW+hWExctBbEwWOICNzepazjTEZuf3K7CcaXVo5pYWi+PbG5C/LI4uFsZQOd4ajMUT1FCbcsHD Cal8IsT5UpwnxQ+k2CHFuVJsl2KbFFul2CLFZik2SbFRig1SrJdinRRrpVgjxSopVkqxQopzpFgu xTIplkpxthRLpFgsxSIpFkqxQIpmKZqkmC9FoxQNUsyTYq4U9VLMkWK2FLOkqJOiVoqZUsyQIipF jRTVUlRJUSnFdCmmSTFViilSTJZikhQTpZggxXgpxklRIUW5FGVSlEoxVooxUkSkKJFitBRnSTFK ipFSjJBiuBTFUgyTYqgUQ6QYLEWRFIOkGCjFACkKpegvRT8pCqTIl6KvFH2k6C1FnhS5UuRI0UuK sBTZUmRJEZIiKEWmFBlSpEsRkMIvRZoUqVKkSJEshU8KrxQeKZKkcEvhksIpRaIUDinsUtiksEqR IIVFCrMUJimMUhikUKVQpOBSMF3wTik6pGiX4mspTkpxQoqvpPhSir9L8YUUn0vxmRSfSvE3KT6R 4rgUH0vxkRTHpDgqxV+l+IsUf5biQyn+JMUfpfiDFL+X4ndS/FaKD6Q4IsVvpHhfil9L8Ssp3pPi XSl+KcUvpHhHip9L8TMp3pbiLSnelOINKV6X4jUpXpXiFSl+KsXLUrwkxYtSvCDF81I8J8WzUhyW 4idSPCPF01IckuIpKZ6U4gkpHpfioBSPSXFAijYpHpXiESn2S/GwFPukiEvRKkVMioekeFCKB6TY K8UeKe6X4j4p7pXiHinuluIuKX4sxZ1S3CHF7VLcJsWtUtwixc1S3CTFjVLcIMX1UlwnxbVSXCPF 1VLsluIqKX4kxZVSXCHF5VJcJsUuKS6VYqcULVL8UIpLpLhYioukuFAKGfZwGfZwGfZwGfZwGfZw GfZwGfZwGfZwGfZwGfZwGfZwGfZwGfZwGfZwGfZwGfZwGfZwGfbw1VLI+IfL+IfL+IfL+IfL+IfL +IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfL +IfL+IfL+IfL+IfL+IfL+IfL+IfL+IfLsIfLsIfLsIfLaIfLaIfLaIfLaIfLaIfLaIfLaIfLaIfL aIeX7hMCUXM8c3QQMXM80wc6j3I/iGeOAO2g3LlE2+OZdtA2ym0l2kK0mWhTPGMMaGM8oxS0gWg9 0ToqW0u5NUSrybgqnjEWtJJoBdE5VGU50TKipfH0ctDZREuIFhMtIloYTy8DLaBcM1ET0XyiRqIG onlEc6ldPeXmEM0mmkVUR1RLNJNoBlGUqIaomqiKqJJoOtE0oqlEU4gmE00imhgPTABNIBofD0wE jSOqiAcmgcrjgcmgMqJSorFUNobaRYhKqN1oorOIRlHNkUQjqPlwomKiYURDiYZQZ4OJiqiXQUQD iQZQZ4VE/aldP6IConyivkR9iHoT5VHXuUQ51GcvojBRNnWdRRSidkGiTKIMonSiAJE/7p8KSiNK jfungVKIksnoI/KS0UOUROSmMheRk4yJRA4iO5XZiKxECVRmITITmeJp00HGeFolyECkklGhHCdi GvFOog6tCm+n3NdEJ4lOUNlXlPuS6O9EXxB9Hk+tAX0WT60GfUq5vxF9QnScyj6m3EdEx4iOUtlf if5Cxj8TfUj0J6I/UpU/UO73lPsd5X5L9AHRESr7DdH7ZPw10a+I3iN6l6r8knK/IHonnjIT9PN4 ygzQz4jeJuNbRG8SvUH0OlV5jehVMr5C9FOil4leoiovEr1AxueJniN6lugw0U+o5jOUe5roENFT VPYk0RNkfJzoINFjRAeI2qjmo5R7hGg/0cNE++LJJaB4PHk2qJUoRvQQ0YNEDxDtJdpDdH88Gfc1 v496uZfoHiq7m+guoh8T3Ul0B9HtRLcR3Uqd3UK93Ex0E5XdSHQD0fVE11GDayl3DdHVRLup7Crq 5UdEV1LZFUSXE11GtIvoUqq5k3ItRD8kuoToYqKL4r5G0IVx33zQBUTnx30LQecR/SDui4J2xH24 jPm5cd9Q0HaibdR8K7XbQrQ57msGbaLmG4k2EK0nWke0lmgNdb2amq8iWhn3NYFWUGfnUM3lRMuI lhKdTbSE2i0mWkQjW0jNFxA1U80movlEjUQNRPOI5tKk62lkc4hm06RnUdd19KBaopk03Bn0oCj1 UkNUTVRFVBn3RkDT417xhGlxr9jeU+Pe80FT4t5+oMlUZRLRxLgXcQGfQLnxROPIWBH3bgeVx70X g8ri3nNBpXHvDtDYeFIFaAxRhKiEaHQ8Ce93fhblRsXddaCRRCPibrE1hhMVx93jQMPi7lrQ0Lh7 FmgIlQ0mKoq7C0CDqObAuFtMbEDcLc5mIVF/at6PnlBAlE+d9SXqQ531JsojyiXKibuFl3oRhanP bOozizoLUS9Bokxql0GUThQg8hOlxV31oNS4ay4oJe6aB0om8hF5iTxESdTATQ1cZHQSJRI5iOxU 00Y1rWRMILIQmYlMVNNINQ1kVIkUIk7EIp3O+UGBDmdTsN3ZHPwa+iRwAvgKti9h+zvwBfA58Bns nwJ/Q9knyB8HPgY+Ao7BfhT4K8r+gvyfgQ+BPwF/TFwU/EPi4uDvgd8BvwU+gO0I+DfA+8Cvkf8V +D3gXeCXwC8cS4PvOAYGfw7+mWNZ8G1HbvAt4E3oNxz5wdeB14BXUf4KbD91LA++DP0S9IvQLzjO Dj7vWBJ8zrE4+KxjUfAw2v4E/T0DPA1EOg/h8yngSeAJ+6rg4/bVwYP2NcHH7GuDB4A24FHYHwH2 o+xhlO2DLQ60AjHgIdum4IO2zcEHbFuDe23bgnts24P3A/cB9wL3AHcDd9n6BX8MvhO4A21uB99m Wxq8FfoW6JuBm6BvRF83oK/r0dd1sF0LXANcDewGrgJ+hHZXor8rrFODl1unBS+zLgrust4VvNR6 T/BCNSd4gVocPJ8XB8+L7oj+YM+O6LnRbdHte7ZFbdu4bVtg26RtW7bt2fbetkiSybo1ujm6Zc/m 6KbohujGPRuijykXsYXKhZFR0fV71kUN67zr1q5TP1vH96zjZev4gHVcYetc60LrVPva6Oromj2r o2z19NU7VsdWG0bGVh9ZrbDV3NrWeWjf6kBmBTiydbXDVbEquiK6cs+K6DkLl0fPxgCXFC+KLt6z KLqwuDm6YE9ztKl4frSxuCE6r7g+OndPfXRO8azo7D2zonXFtdGZqD+juCYa3VMTrS6ujFbtqYxO K54anQr7lOJJ0cl7JkUnFo+PTtgzPjquuCJajsmzdFd6KF11iQFMTcdIWICPHRCIBI4EjgcMLBAL HAqoSU5/0K/0cabx0mlpfEXauWmXp6nO1NdSlUhqn4IKZ8prKb9J+TjF4Imk9OlfwZJdyaFk1Sfm ljylpkLjkjLigUO0uU5JDudWOH3c6Qv6lPKgjzP3Efdxt+p7yvWaS3E6udPZ6VQiTlR3JgYTFfHR mahGEgcOq3A6gg5FfHQ61OSIAxbRY559ek2F0xa0KdES2zSbErGVlFZEbP0GVDCVhzhn3AVSLWIU 3BeswLnel8yNHO/z1prq/PxJbRZWNSlmmT47xi+J5VSLz0jlrJjpkhiLzppd28r5ZXWtXCmtiXnF b2y1/IW7drGxGZNiGdW1sdsy6ibFdkBEhOiEYBmtyWxsXf7cNevW5OevnYuPuWvW5mvfyPF1Ipcv jOJ7zVrkxdc6Lc/yvzNRNdC8NUhrpXHtd7f6T0/83z2A//7UysQfGYzpVC5gzcr5wHnAD4AdwLnA dmAbsBXYAmwGNgEbgQ3AemAdsBZYA6wCVgIrgHOA5cAyYClwNrAEWAwsAhYCC4BmoAmYDzQCDcA8 YC5QD8wBZgOzgDqgFpgJzACiQA1QDVQBlcB0YBowFZgCTAYmAROBCcB4YBxQAZQDZUApMBYYA0SA EmA0cBYwChgJjACGA8XAMGAoMAQYDBQBg4CBwACgEOgP9AMKgHygL9AH6A3kAblADtALCAPZQBYQ AoJAJpABpAMBwA+kAalACpAM+AAv4AGSADfgApxAIuAA7IANsAIJgAUwAybACBjGdOJTBRSAA4w1 c9h4B9AOfA2cBE4AXwFfAn8HvgA+Bz4DPgX+BnwCHAc+Bj4CjgFHgb8CfwH+DHwI/An4I/AH4PfA 74DfAh8AR4DfAO8DvwZ+BbwHvAv8EvgF8A7wc+BnwNvAW8CbwBvA68BrwKvAK8BPgZeBl4AXgReA 54HngGeBw8BPgGeAp4FDwFPAk8ATwOPAQeAx4ADQBjwKPALsBx4G9gFxoBWIAQ8BDwIPAHuBPcD9 wH3AvcA9wN3AXcCPgTuBO4DbgduAW4FbgJuBm4AbgRuA64HrgGuBa4Crgd3AVcCPgCuBK4DLgcuA XcClwE6gBfghcAlwMXARcCFrHrOD4/xznH+O889x/jnOP8f55zj/HOef4/xznH+O889x/jnOP8f5 5zj/HOef4/xznH++GsAdwHEHcNwBHHcAxx3AcQdw3AEcdwDHHcBxB3DcARx3AMcdwHEHcNwBHHcA xx3AcQdw3AEcdwDHHcBxB3DcARx3AMcdwHEHcNwBHHcAxx3AcQdw3AEcdwDH+ec4/xznn+Psc5x9 jrPPcfY5zj7H2ec4+xxnn+Psc5z9f/c9/F+e6v7dA/gvT6nz5jJmvoWxjqtO+7vx6exstobtwNdF bBe7ij3F3mPz2flQ17Pb2N3sPhZjT7MX2Tv/x79PPy11bDIuZ3b1UWZiHsY6T3Qe67gbaDMmdrNc hZzHEDpl6XR1fnSG7aOOqzpdHW2mJGbV2jqUN2H9lLd3nsD7FfnOoSKvXAzt1Fp8Yr6l46GOe87w QSWbxWazOayeNbBGzF/8O4Ql8MxStowtZ+douXNQtgifC5Gbh1q4SzR9qtYKthJYzdaydWw9vlZC r9FzomyVll/HNuBrI9vENrMtbCvbpn9u0CxbUbJZy28EtrNzsTI/YOdpSjJZzmcXsAuxahezS9gP vzP3wy7VwnayS7HOl7HL/6HedVruCnxdyX6E/bCbXc2uYddhX9zIbjrDeq1mv4Hdwm7FnhFlV8Ny q6ZE6ePsObafPcgeYo9ovmyC18gj0i8LNR+uhA+2Yobndxsx+W9Dl7e2Y+5ibi36TDfCfl63Fut1 P4qa56Mm9ULrIHrZdoYnrsAcSJ+aEeWu1uZ/ytrdK99llf64qZtnbtRyQp1p/Uf6GnYzTuDt+BRe FeoOaFK3arq7/Zauurdp+TvZj9ldWIt7NCWZLHdD38Puxdm+n+1he/F1SndXxA+yB7SVi7FWFmf7 2MNYyUfYo6xNs39X2bfZ9+n2eJflAHuMHcQOeZIdwk3zDL6k5QnYntKthzUb5Z9hP0Fe1KLcc+x5 3FAvsZfZT9lr7FnkXtU+X0DudfYme4u9wx1Qb7A/47OdvW78PUtkYxgzPgY/38Tm4suIW2mN+iZu EZWZ2XA2hU1lsx9nDrzuk9kIvn+/r6zM0s/8JF7lCgshGLAwzksjToPieNTvLwk/OsS0S3VPaOP9 Hi4x70KYW9L+fvurhe3vH0saXniMF/76g/c/cH3yqnt4YdEHb38wcAB3Z7k1eBMVs9lrCmf3V4bk 5Q4tKho0WhkyODecnahotsFDh41WiwZlKqpXWkYrIs/VN7+epU5rNynbwyUzioyZfqfXYTIq6alJ /UbluKpn54zqn2FWzSbVaDH3HjY2e9Ky8ux3ze4MX3JGksWSlJHsy3Cb298zJp74mzHxZKlh2cnd qmnknJJe6nVWi2IwmdoyU9P6jsyaMMPpcRlsHpc72WJOctt7l81pv8iXLvpI9/mor/YpcEu484Rh u9HLslkuu/kA69X54cN2F58cbtNFblvn8YdtEDYprBARv1A5LvHp0D7t2mekN88RxQU2PqVXODfn M7vNnpqdEbY6eLLBzuwuu/JQ+Knwa2E1bA/bkzKqkqLGKCspKUkaPrywsL7enTLcDekuch0b5C6C x/Pr6VXI8vNzkpNNmsvz1Cw1UQ1n5+YOHcbJzynmsJplWGfhrpxgMMeTYFjR/sezVasnnJ6R4+QW Hjc40vIyQ339iYYt/Df8mbOSA4kG1WxP4CM7XkxwJBiMiYFkQ9yWaFFVi9O2q32L+LdeexkzcOyu TJbPitkLEX8w1cWnBF1O8eHAR6odHyHMVfyOONLb74ug3BdBuc9nKxCVC0TlAlG5QFQuEJULHsPP hKzz0H5ollsET+9DTfDxfU6dHRp/sc+u8Yf7bIIVV8Rxm+2QTbH58z4bONDcS/uv0pWD27it1VzD So6VaPt2OC+s/0Bz2qC380nAnJ8/nDSc6k00hLOyc4e4Bw8tyoL3fGI/Z6p8cH8lHHaLzew5JQ08 WDytadWEjgdT+vRJ4blrdzcNSs4f03fInPLeHe3+4lkT44dLq4amTc0Zt7Ty1RMja0tz+ZqzFlWN 7usL5hnOywsW1Gye0r9mXHGSdUjVOQovnDwkvaM+PHJa+69H1I4KdhSnD6tinDV2HjfYjZk4xfP3 pbOR+bpX8nWvgI8Kr4A/El7J172S/yR+xk5kqbyQZbFcXhD3VBsO8r5sCBvA+7cmzMCRfvuYAC+k 6bt+fnjggBxvoqnbsTT59GMqDrDPm6mIeYttZbArRos3Mm/LhO0vXz6l+po3zi0+e1ZFwGJUDRab JXHQtFXTZuxqHjak6YrZU9ZUDnaarSb1UVdqUqK3T16g5sef3Hz71w/N8YX6BhI9/iRvuichrzCv /KKnt2554twxuYW5JncmTqDYZZdjlyWxINsQySjJ4h6xczxi53i8mLMnCRP2pGK2noNi5zA/+cav +8av7xi/vmP8um/8B/FzfwJ8Y48nVgbaeG6rkXaJ9MXbckfUixvttC1h7rYBLp9x1/G7Oz7Slj/n 3g9vrtw/eMX9Fz3UuvX+1cOVG+49eVcVLfTMOz+8fsn+CyZ+7R6942nxr1AxM3UrZlbA1rf68/QV zdNHnaePOk8fdZ4+6rw2xR1JSPCEPCEM3t/GLRHHjlx+KJe/nstzc01p4hc0jso8UKupa9fXr1qN aRVq14hL3/3aOivf2OnhLPcZUt1qsDos7VeJGSoLLQ6L0YiPDhOPW3A1GBKgpyrc4rAaxiUFkiw0 W0tSwJsUcFs6zk5wpXuS/C5zx0CLO6DNu/OEWoN557E5rWaPPm+PPm+PPm+PPm+PPm8P5r3fkcEy M8yY2j6PJ83Uxnvvy65MExek/kYqPOwe3jU7/o3JyLeNnK5ag4mZO+A9Mwav6YjFG/KnZnstmGqF Zj3sSccsxptdAZ8n4E5o/4PZYTYa8WF4UMwyQ8xodudHho3GECthd0Qy0tOdqWKHpoodmirutlSr XSjMIlWsnoM9lcdDeZG8hjw1z6nP36nP36mfZKd+kp36/J3ir8MLB/PBqW3c+nB29vDC0Qe5Fe94 K+8TH17tbeMFrYUzxHrjNLvJHfo993Z9/eGui073y2mneegwt9gF4rRr3nKLG/DU+TcYNhosdrO9 eO75s5bev76kfPN9C0ZtGdLxttttSMA74kZbcpI1acSc+c0Drzl654z6+45dMfG8BeV+q2GuJ8Nj ye2fO7XlyRVbD11QlpHBN2X3ghstFld6UofHn5uRnWqv33t89w0nYo3+cB9/Nu0Pw3S8cwtZ28Ml A3nYrrvIrrvIrm8Ru75F7LqL7MK56Sm9bML7NuF9m/C+TXjfJu4Hm3hHpLCIDy+WiEd8uNx8Moug nKWIX1qgQPAjKEvpW4UXSEHEecjOX7dz++lvYxyoYyUcb423hVv1LXfqYNXndG217ruObk0fbFIa plu8Wan+kNfSvg8qTew8izc7NS3La1GmaHsRyg/vY8vZLcro9mekNrwrVfsJxSS1fr54LfznY9Mf LUmZlvJQisp0FzLdhUx3IdNdyHQXssdwJ1o7Dz0KT1hdVdp0Mc2uizDnG5PhtXLcCb6slLTuoz01 Qnnqv8Soitj8iHugOAwDxJoUCpVl1cdn1cdn1cdn1cdn1cdnFUts9+VVZVldgSrXqeioRF7a8D4+ aZy5uXn8W9yvB0U+r8nMeXKy+qXZmx0IFySbO3qduQb8JZMrJcvvD3nMjqSOav6q25wuLkCTy6pc 3L6p6yo4tRZPKyUJdrPBCIPDn9Le2X6D36Pf9ZMwez8bf4D5aLI+fbI+fbI+fbI+fbI+8e8cWIKz ytfG8/XLnBe+Ihej2+3dtbHEpTYJN3JC++GUPl2TeF2EcJO8AU8C7uYH5VBP3p7gTtdXxpSP+3gU 2xtxNYxeOVpxDBiQUlho7Z+a6m/7ni9TsTCZvQba7VZx+qzi9FnF6bOK02cVK20VewtxXSRNbLRe QyttqSmOwtSB/U3B3pXBqDxcJUkIcoswURmdIdJ1dSn38LMKi4pE7NttL4a5iHcR+fLwaXe8Fvry IrHemn9M+RZvMC0ly2NROopUmy/D68v02pSOcRwnLS0Vi1wQWBwa0Cs1gW8w8ots/mBu2nJnwGM/ taUXndxttppVA0IZ/HBxfZf97r697P7ega9nqndn9k2zJXgyfPpNtt3oZmexC/flOZ1e3ZkaO3V2 aHxcONOrO9OrOTPT2r//IOHMQalO8YGKg1x2oVBlkKjiYpnFVdb+zjxDmngPih2iuU847xu+KyzS twx5CmcjnJzs+xZ/ZaopRbnddpVhu8Pndwzz54XDvo7FoTHpiqJYPMHU1GCSpcBflZEXzHDzERlD Bw1M5QgDPMG05FCSZZwXP03ZMgblKUeGbxs5/pqJX3/adVru751tTekTbH9hcFNDfeG0PdOUJ/Gz BiIJu1n83zuaOo8ZPjRmMQ8ihK0Rv1f4wCs2lFeEe14R7nlTyU1FkYQQG8B24KeRTN25mfpOzdRf pJn6izRTd27mQYTEVpaG16azOixOlnHG6WFffbefBE778VSL+rrFwIYPJ171/u4f/Wxn2cTd7+++ /O1d5fvzZl+3cuV18/rkzrp29aob5vZWrrn569Z5M+/+4rbrTzw0b8Zdn953zhM7p9ZcenDR6kM7 p9Rc/riIcHEzPo/zl876sI2tvUz6REz6REz6kTPpR86kT8QktkCKO0O4J0O4J8Nld/DJGeJnqAzx B7vMnYNYYZ/JZMc0bft8lfZuoRJtENfp0VL4zBDJ0C3QVZ+PbHhg41UJnqw0cav09XNf3ylLlk/u s3/kzPqCW2+cuqiil3pV403njOro33UusNTmlJI5m2ZOO3twYvtXvcc1MZqxwYYZD2Vl7MpIpqu/ e5gFox4mZjFMm8UwMathYpX/h71vD4+juPLt6p73s2dG85ZmejSjGY1GmtFb1sPSyJIt62XLNrJl YwmPJdkW1st62BhweLNxTC6GC7sXJ9+G7OYGkt0lGGwwj2zke4kVsmuWDa+EACEhBHDWyZJNMASs vudU94zGryS7N9/958pl/7qmprqqzqlTp845XeOugVl+MoqeY7TJgqyAnEVmjUVmjUVmjUVmjQUP 8ubGebCOn5hMkmTSuRw4cDywzikrGWoToyt4iSdYK68S6kjHuUtY4nD6ONkhdNocDlIZjoTDaVdA r8oJ+TyBHL1in72k8ar66TSzwDWwlTV7OqfXRIIrttYKlSWFOTMmzcL51h53U8U9D7cOrvCDktHA GoAlXla5qSl4/kcZJoKhqeSMyzZOtDTvXFuXY4o1rClbeCeUx93RNeJUqxa6AvU9oG3axLPcIKyb dua9p5hm8f1jZp50NcssapZZ1yzrmmaZVc0n2OJkrDxpyyFd5UkL6Q6Vh8oNXhfe60UF7uV5BLjF i9PhfZotQy3+uJdaDXOPu+VrjnR9wowmlSH+DIkwNWCchpN6i1BDapJ6A+my4CkSHeZqLDUWRwNY 8sebvcroBscJEpXXIUzBWQv6KbFYP3+WR1FdtLGs0hcXLVBFeoFKgaa46gqOq4obbNn31f7miU31 Tj2YtBpTRc+ejmX9LaHy9SPju9ZX1I/cc1VsU3eDTaVgOZVerU+09tdV91R6yjdcO37thgqy++r/ Bu69kO8q8DvyrOr8wqCvpqeiZk19WUXjVXvWrrtpY4nZ7bfpLS6bFfzZ3GBeXumKguo1DeUVyzfs gTkyw1p/DSQ/nxl+0pVE38CCXDuGttifvPBxI7WIc8dR8lVWdIPy5LVdDsbah5Q5343xz8UyTtCi OZpWZ9RUeI06b/elrR7Iyc4ddzt17ajv8+lfZwRxu8aSa7NJ4TG0HL4Jmno/WDUx5oFk3rYSIuCq FXAVCyg6Au79AkoN/lIzacm2vEHSGIdMsEMm2CET7JAJdsgEO55mebRK0T7H41xJLTShC6/n13sX 5Yaa47IGjy2KSD+51ACU1XfWFrd/5c0nZnc/+rlWyf2zaYo3zLZ3zq6LUdYEbFry1t6nbl7RuP+J fVwwzY7PfrPlzs0lxX23buKci5Yuy2yFddjEfR8s3STzaFIwr/CvSKzg9FpnpQGIqkTOVCJTKnlc ZJUnyLkkOMMRM0MMDPKOqZPXaJ1sH9TJfMArXdR1J1hNMsfi/C5TyVey9XOVhAHPsDLeXHSCeJPm F/NJfr4i70y8Y/kbhm4Fk0hHAahj2L9noD+92T0XG+ivlSMC5aD6BsCqwigi7P9VqsUYUEWVvPPJ JQrKNbW0rBzoQHJNfK7X4zfV37OubXpdSePMwyM3OsrW1C5PtZcZNLC5q70rNu6oTH3+qvDXvtg6 tMK/uad5YrnLYIDdybClaVXBqh3NXZMdBasqe6q8ecE8De82u/M8wTxbce/nrnrOWdIUXbVhRStw 9wHg7ivKPUwRWlXHYdp1gWpZXqpl+amW+YWfKb+qT5CPk157DE2HmIBxMuR/DKU1xtPwGatLahm7 rroqoFCWniDKJ8Id3lV8Vy1kjyq7qXwBC521GctqkWcZCYvYLxU1ydVIGw5qi8NBt9JXKgYP98fa V62KaKxeO5hKKrVNcLnBbirsXL26cPuhTYWP2Cs3JoXG5MpI640tjX01bvLe7DO3r7KE66LjIG0K BUibchndMwDOvxtdFuTX3Pbo7Mpbh5Zbi1aULzywYVPD4A2wSrcAxwTueaaKOXg0l+pqyRN8W/YA 3z+GBvllAlC/ujDwJJ6RAlKsPmlMmIjJ/Z4/qTOu9oOfzB6zdXC/LENNpjWuLis+QVRHtd0YXYyd pZAJRjyXCT1dFGJUSYpalR1g5ARWqXY3dPYlUn85XNW854HNsXWtVS6tirUazZGG3rp9NwWS/Q21 G5tiBjTL/8bithjdBXnW5A2Pz97xnevreU++y2RzWSP+QGHgyUc23dYXC8WCGlsertNtwJcvK8eY MFPLHEr6m+qJ3luLq7MW9VYt7nu1KB21KCy1z5BPGIZJSFxLyMxKyMxKyCs2ITMrgQKlswVW6Wsj XoWpCA9BuzpgqSseN3Uru1BVU3FquijWSOUp49hkL0EwPDJSxYXD2WZoDfdltSU3Bx9ftD1w9eBd mwrLt99zzdrbkuocP8qU9ustB1qbQIJAopoDy5OrIu60AO3r3th929HtM8/c3rayhdWnLfTzK0F2 tt+YbL11GGSppQy51Q/cegC0WoypZB5JFiWqm6onqjkbriabgIE7W6AYrYRi5JYU0qf6DWThk+Ot sa/FWAxWH8fVVqmQhU8hyxj9rKdXScEpkH+BQPH8zYrDCnZOQV5UEIUiN/FGuMN1Zptp0sSatGdy qYD1Z0c4pUX5ZkwSNhrXpwtUFQxkiZX9QuFj7ZFqylA190DEff4x36rJdcmh9oRBrVdxLKfWV2/c k5x4aKquYc+Dg9fev63k69z+fcu3NuaDIxQJdF63MW732NUmt9VoMxv0bpet8foT1888dcvK1ukv 9dluvS/eNVyDu2WB+Hv2TuV14GcPPebgcQHSheeVtZY3ra28sjrzysLkxZ97lRYVnBBfTFoxYlWg O1vd5gmfLV0tdPGrqT1bjv5L7LmKD6U1VvHcRXE+uxzxyLZng3LMryId52PvVCg1KrXdF/UWVAqm 5zV6rdJqfl4DqgmcY81NPI+q5qbg6rGO4IqQQcMpzTanSanVa10V6+q2qy0eW0j47JcaPeokvYaz CyGbx6LuH/iLjVGj2WDz4lOjqoX/zh3kvsc0MmuYa5gXk3ZrSRuusjYNkNwm8DbS1VbRdEL8GFnQ JK8vuL79BH7VpF4L2aTRbCVda70KcylXoVaj9PCUX3NJI2RKKtRer7qiRIE8TlYik/uwiz6Bh9v6 igqSergWmEvV3LKO1w0b3rfbty3jPmhYXSSs+NGyjqt/JKyVA+dNUij1VUn1xypOI3OdYIOiFWqB Qv50DP7G0oBcBx6DYy0FoCIq0GcOp+wzpGWuBrbXymqK0soGt4JUhjPbKT5gCkciJk7+xB20mW8J 5pb337ymZtBrdTZX/7Jlcn28cvfX94w9sL2YD5QJZYnyAn+ocustXdE2P+EtloWF4f7StoRz+Oqy 1QnnhmvWfSBEXdrb93YON3q5maA/tCmx5roNxXkOa9wXjLM6NrB8c33jZG9ZQXJzZaBxWYXb3VW8 fFu4oH9F9/VXlWg1gYUPt+4UlrUXbt7hr1l9fqCuidW4S6KF9uaWvNJGlO8HwLZ9EHbmcmb/saZK UrQYupcFOyumL8f4YVt2+qQALQ3V0igtVRt6/E4nxWZ9RW5w5VRPlnSEVrm7qPqkLhxJyKFJaTOu vTBASXcT9WXif9XVkhZ9UGOV9lxXvL208cZW+EiDQOmtuO1w+5YbugLutDyz5u6B1lBf7/lD6ZLs /bezffmOgynUlHeIvyfrlAnGzgSYu55sCq4NTgQ5h2zLXWDb2uj17YtsYMnmfYbdw+Qy9iuFBmWW 2oFNT+j8+EwVf/h0zM23U/68ejYma0N5Z7l89NaG2y4KI0ghabyYAbbi+roY/suwgLtdLRGsJqV1 RdFa+Jee+Rth5iuZ+5OGpmoSLSNlSSvpBoPgRTrMMlnhl6ERYaBXqvDLnmEj4AsZZGquHNkHYfA4 SkoYJFQSCke+XlnYnrvKkhYI8A1JAswLsGepFix/O013hvA/KRx8o8aW7/EGXWbVwu0Xc4RcpbG6 813ufLvWaF54mowb9dRt59RGLfnNgvFSwfjsB2SvzqjlYBvRGlz8wtMLBRa7zDPSCDyzM0kapZ+g UfrLR+XTs83gfwyj41dRiuX5vXxU/pK5dF86NHkUyhdhV+9hziS9VozF0yepYR6d9IgLcXI9WXXp 0zgpmpD11O5MZkX7fA6Mu/nKpdgvjQLTADBd2DrYzZ7sQf+vp/HSh5tSs5c8BH2GfAxqhSeqxzo7 wNxUJY3NHY2rSpa1l3S5s+Y/O4xXK8d0LLXp5xeoH+hPPv6QkriS1rBLWsMpC4vyRUl52DQ5xa3x 2umVuEk6Aza1o7glXjuT0SUqa67Tkceru+5uX7a5tZQvWdfZFtq0t92/qFWCtRdplUtLwB3Xgwhp 9Zp9vWs9iebCstYiG6ibrrTWhRksZ+5LmqUZRJAV8MWzdIVnq+ge+fQ8n9bD9OFZ1nMz8vGTsipG RZzUlXQUuUPtadbjPpnRxemYosztP0Eh2/+YQs4w8a+6/4hCvoBRwKBtqI/R/3kLOITx5IeTuU1R UmglUQsJG0nYQMIaElaTIo5EWXKZGPLbl40ho3nqS+iILis4LVwYnH6a1WGc7Ekz0z0J0+TG3zqa O4LgK8kOJfpEMssSmZBzf/rPH4s9c2/VTf/D1MT/HK+unf77abjWPOJtvHZt+0hrwNt07drV17YK 5N3xp+7sXPG5Y1Nw7YDrje23bq+tvObW7o5bU7WVA7eiN71wH/cK8Aa96ZvRmw5UX+bZm6R9Fh/C 4bZtlxxp6lLTaKHkU1/Wk27n117Rk76cI30ZGbmyI33vQGFrczKUJSw5dq9VHe3qXley/QvoSFdQ R3pVpPX6lsbNNR7ywd5nb2vj8yuDC41pXaj4AGSG40B69hc1Ru1dt39rduUtQw22aEvZwpENfQ1D N1KPEbj1ZZlbdya9wC6/PoYLJqYzpIMKVMnF0FssYioksck6u3RGPruUPtOUPrsE3qK9oF2/POZX 8HH0Fj0dy9Bb5LuVa6/kLV7AsyqL9AwsLS/Oqit7i1pcZv4cdbRjdXsEWVQ+eM81hatWthXh8bec XIv6Eo9x4ViaU+R0tDZoTnuNloL66FiadQu/k9xGKQQBbiPVTuxDNBY2eGyyioTNslAtHmuQhcss S50ZhcuaFSREKWM8IHMFSW2sI2y2C+121DpU3dMNP5ax/rJdnsspGipEKvYhVqXVaJx5Ibu7tKou eLGaKWiuq80zBkJ5BgVHuO0On0Wr1Wpy4l015x+9VNHcVt0aMXManU5roqdb1oln2ReA4nbmhaQh 0dnUubbzps5vdSqzAvEfyQF4KhTNGJCxXRSgp4F58kbSL0XjaRweRUwOxqNTiDrH+zT5iD5S1aFZ ZEhSUwk+hqG9JsO3DKwh/maN7peWHss2y6SFk4LuP8aIe4fjfWkxZsLtcrC9H8OnWcH2RevxPxts Z1+oGLh1TemmlaUOnQKD6bGmjcuKWsu9kWRP77pkJLr+hvWh1XVRu5oD60in0uZXtyeKklF7YXJ9 74ZkhJhWjsJ8O905Ib/Nw6u9gtcarC4IVxb682ONGxuqUu3FBqudN5gdvMXNqx1uhy1YmhupKhTy ixquwrkIiL9mxxT/wNQxW49FGUuwROZ5iTwXJfJclMgLskSWyhIUQoPTWHI2uDrPeNa5ugzW4lG1 pLZPo9hVyPGa089JwSzF5V3qCx1vRzoAwY5peCEad64aSuZ9zmzFiPuBtKH2HkZLreb3atqcodwc jVKrVFydl8+btKqCzuk1rEnyqV9NPzB9VfK6F3T912h1WqXJhXTfh5Et7lmwCe5N+sES0EdQgiIo QRF80BahSirCU5OLfPKEtNL8Mlf8Mlfg+jFdm5h5nB7jlBerX5ZRcDk+SWptJe0RvdLdDoaZcjG8 lX0oIyNSlw1vXRSYr65ZDHR9WW3NszvzLKruv6RbvzpHCkU4E6tLG29Yqc7xw8q1ajMWwb7eNQ07 D25n89Or8/xv117TUtDXy86mS5A/+WAz3QD8KWbeeYoJirCboaHr1yAW+IlPyviIQ6bTLl9zFs1f erVmnjeK/56swYeVYFVYSIQnhUqSXwgFy/NJKJ8EMNsUIKEAEWipQEICiZjJ3gAJYFhHa7GvDgiw auHT+0ktiGIAY2r4CWcigO0b8KBMYXtA72nXSwqQPvKI4enffmo5xKS/BO0Hie/9eECYnsfOHJHI 2iJszhqbfBD7BsJy7MJphdFT6PMVuk2KhRcUSnyY78wL2rSKBQX3KauzBbxOn0XNfUWh1RnUn30D zwMrNCYdt8lg1XLgFLIA2vMeg4H9hdag4ViNHrldBT7G7cDtlcxbTzFtoJ6WA2nLMNwTXUZq8FoQ J+EACQsk7CdhHwnnkUguKVSQKEfq6kl9HakvIQ34ZgE76eZlhxmvSR2IKy9AC7xZLsZr0oAbCRab m9tpPWRmE7+Wn+Bv4hV80upYzVe0F7TXHS4mxfhdMWpN3uZYvbN4XzG7EkqdXVpk8ivIyf7nmppO AyclfickfchQKy1jr0mMVmX4zEXUXJrl6UDPBSzPyipvVygXznFGZ6HPX+Q2cN9m2W9xRk/U54/A p4VPlArwLpy5+VYN9yOWnWe1VhB7v1XDvsaSV1mtLeBx5eG0qHPMi5PCflGrPT+9OEXmHLVWDzME nup5j1YLM2QExYtHllzpT6xGh/MVhdXRCfOVYO58iikDxlgwoo16I44aoz5OXCCPT+ATLBdxyrrB kS5yEC1KaxH6rXhPA0OWBUm1nugFdC9wVvT6stJoe1BvyWu3ZFyI2iaLlUgBWwYZi8IryW+swJGT Ptq+eLIduCq7ZDbKRocDmM+1aGwRvy9o1yt++JpCb8/PzSuwEC1xLZzTEFtEyAvm6BSnX1ToLH5v XoGV1S58UmyyGZTgnavJ8MKX4MIpDTYTeZI8ZLIZFZxKp144Staq8MyPPse8MIDaA6zAG4E/IWb9 U4wXaK3Cle8lUS9xUefZRcKmahMb0RIPbsl1HuJehoxzE3+7W2dr13Uq1jKdstPaBEs3Ji1aXLwB TiK1xoan18KVMo2kwkZDhY4cNVtxnaqs3CNYWNWNWp5b+I6GD/l8+TlaJSHcxypLvpAbsqgWjvMW pSHHRGoVVh231e4yKTmN2Xg+zr5q0ythn7AyLNGJH5E3lAOMnYkypuPKAm83vwqG9eYLWWdfuHAm VnTRjzW+rcYfS+Ra1RaisQdzvUG7xqR1F/r9UZAoV9TvL3RryWzabuSeNlgNSpXBYvi0NhDz6vXe WCBQ4tbr3SU0ZvYRtwlGUsmsZsJJUyjk1+Y8rlSWalvrcJchR0tX4eb7Jv7ahMZkpRFmfmZCRylb JJc8qbzYl+I2lW/5XLc6GLH7rBoV0VpzrY7mrbUeIZlaUbcpGdWpYTtR5dSuS1XuPjJUuvAcUOMT gBqgTvABddxP+j6/rVr5odmMC4jADmVTR1u3ltdeszLs9rlUljyHy23ze6zLd931Wf3F1BKmaOEt Ms28zXgZ3WN6Zy7Dv3xaOnaiVks6o8aW4fK0yuS0HFQabW6bxakjijv0rpDHHXLq7/ZXxkvcL6h1 GrqMie1mr8CrVLyAa/ivxHNkHHrQM86jeLBg7gk8QKDlYLGdBi12ErvLCv2NJxob4vhvrC0RXwn/ sA2y8B6nU/4jSIfmKK9kEsBzpzw8OWamflhhzMmzuwNWhYrtVxhtPjuYMArlh0azRqE22oyqG4xm LYwuxwjtrSTH2Di7nDEzpmOMWn9WweBBJDlmHpDGgscS2LjVsjBghT/kbzRGEOtPIj5/OOxTWTwg KYe4HewR5WxaZr3hNr4NZPZ0ebbMpp3mi0ocdvY2Fe+0Wl1mlVOXE3C6AjlasvAXF5SVhrk7M87O v6RzC2UXlvE8jGU32FnfVgpUah94iukAXek0s93bOkhstonsaCItTaSyiYSaSNMJtiWZY8jNNVxf Ra6tIp1VpK6KxKpIFXzxxCRDBGAQbmHS4dz3n4RmmFIDAXP+92Dds92GOrG0VBk+QZjHbJtbTxD7 UeU1md+0wIz2vwzasv+ndC+y4iN9msOzyLEsw11xsaGuvsivTkcXvl05+vU9627curyAt8bX7vv6 eEFXstikVrBErdfqw9XdFf139kY5T3P3xrKRw5vDjzirt6wo6FjZ5Ak0DTQlBxrzyN/2fmV/e2HH 6Be+NrDhm399aGeD1mzVG802k9XDa0wWU9fN39hq9rnMtcMHt9VdsyJkdPqttzwyUlK6bhh97dXA 23l6CjDGnEm6LwrZFKRDNiW4cxcg00tIVjAGI5A5aO/m4HG4HPxxUc4zbAnDMIJk6guyKyDIPrkg G71wfR/XCthn+H+sJ7U6PGCYZDj6uy4tPuvVrdWxDLXa6CFXnCl6rgkzOkZXUuzF/xbLvAFP36UP F+LeRo8u4ZYGk5MdKYvRHeDKcR9Flvuu4OYTY4/ecv1DO2Klo4/efANcHzV5Yw3dpb3XLnf4modX L+tdXujSsl+4/6OjqU3fOPfgfefo9e9TR/b21rh77np29J5/urku1DIwdQeI3CMMw31F6WTizLvJ UMhHQnkklEuCXhLykJCb4FbmJFHKeyvu36X0GRuyu5QwyFomKvtOUZmhUdmLiMoMjcoGQhSPK5p8 LrzJpUfUW2SBh+vLj0ObFvlsQlb5nHysD1gPdzxoIRab9QRpejy4PsqfIGrpVHR50/nT1HPFP6fx 8Wf6DBRyloktWmn98qHp9CEoi1qlkqyzmgI5smuhO8RXVDqj+vxWtUGvUmmNGmL6PT7p5FR6LSlS GKwuK7gdqjOw3ylb0TdV8x6b1WPRcj+8X6cw+pwWF29QfYdTKIhCrVd9ercWVBdweyfI9L0g031E +RSzBTiZi5zcQso0QHUZCm4ZPf1YhuwpO8FWJXVrNoTXrHGBZ5BEzyAMVcJosCahNJzkTF4Nn44F 0Du9An1gLLHcCwJ8nBph9JQHyqdJZq1Jni0TzqcNeGyqx0cr9Wg6dyXqCWW9PAVJHRbWW+otjuoT RJ/UtW8o/g9BULbjsT195the4mwtnzm5B8ZwQjqJJccS6ENTDMdba/n0c4u0ZlLRXSgTUZCOKEt+ 9KU7uqoi/ZM8u4/j7m2c+ebu5j19dWaNijMZtVUbJlpXDLXmxzbs775BY9arVXqTds+KkfaIp3Jd VV2qq1yHNh6r0tjqeieSWz5/dYnQuKW+ZaKnhExtvntHjT3PbzLBnhbKFQqE/Mbe8pq+ZD5Mr93m Nqvzk5trCtur/cHCoNLsdZidFpMtFHTFr5ptWz6yrlbPqqt6doPuKgUL+iVlDlME6+rTZB26NyUk UkxCERIKk4JcEvaSIF1gBS5S4CRhBwnbSTiHhHkCUxxSkpCCxLyErjartNpKHC7IOARefmYoPSt8 +0l8lpgbj4Ob81kyD2rwqAR5lAgenX4elSCPdjuPv3eLMApprSlAgaWPXiR1ePZCUZqIeON0ghWx AM/rAut1vdTPTFhrK86Wl8v2eUyOfeDh8tMx6TgPrLIsXygriH3BgYP0ukubD7jWHCRIAtxLOdZ7 02fwz58x8EYlCyY3+YHS5iv2Bcp8/L0W+8JX2YWryUNkMhBe+Pe0w094Fe9z2Xxup5GzopWpBIvh s1NB9oPzdYwopndoVsV9X/6fEb4qJZK4YnqX3Z6V/kVK4BFdmo4prs6kTzEpV10xfVf5XZUtK82p r85KL10+abpoOicl7fOLSVcqp2eW0n826a+9UjJwhrsvTcawnOYvTaaOP28y11wmPYOJr/yD6QVM luw/v7Help1sliukh20P5zTnPC0l+82XSZ/9V5LjrsslZ4vLm0l/5+aX0lL6/z710vTPF6XzmDz+ PzG1ZaVr/2zp0f8XyTvwf59yLbnfy/1e3rO+WyAdXEpLaSktpaW0lJbSUlpKS2kpLaWltJSW0lJa SktpKS2lpbSU/uuJPk8mDKN5mCFkQgUZ9gijYKzih4ARip3iB4BD4jbAXeLbjIIcEf8ZcE58HXBe fI1RcN3is4C9jBmwjzEATsG9FkYh/hvgkPgiYyGFmId7EeconsI60ALkuV7x54wVevwVYCfFIUbH WKH8HOOCdn4GOAQjcUHJ84B90GYulJ8BtIrvA0YodsIIc5kBaDOXsOJbgDy0nEs80EIu8Yk/BiwU 5wAP0PwhWn4E74VRQZvkJL1rHvNAxbtMGHr5IqAVRhWmIwzTEYahl3eYMPTyPCD2EoZe/g3QB22G oX0sOURLDotvMmEYeSVgn9gEOCp+h4kARR8xEej3HcCTQEsEePIbwHlooQF6fAwwIj4K2Cl+BXAA +m2AWXiHaaDUNUC/PwT0iD8BROoagLr3AGeBDw1kL8UDtPwgzR+iNe+i+cPYGtD+OuBxWjInfgnw pPhVwHnx75gG4MBbTCOM5AxgRPxXwE7xJcAh8VrAXeLLTCP0+AEgttMILTwGeFI8ATgvHmUaQSos TCfw8APAIeBVJ9D4W6YTuPEiYB9Qugm+HQEcgrneBHS9DMiLrwB6oPdNQNdrgIUgV5uAFswfouWH YcybyBFaPo8IbbKAfQufAo6K9wFOif+b2ULnbguM/yxgJ8zIFuDku4BDmIf23wA8IL4KOCf+AvAk cGkLjB8Q5FnHDMAIPwQcgtkZgDofAJ4Ufw04D9wegF7OgbwqYI0MQV+vAkbE7wJ2iqcAB2CWhyDl MkNAHb7hhhfxPTUeEd+Q4xPxHTU9Ir4dZ1bEd/DspXiAlh+k+UO05l00f1jE9+ccp/k5Ed8gdFLE 9wudEvGtQvPi3zJDwIc4YJ9YBTgq3g84Bf3ughG+xOyia20XfPsGYWHufgt4RDwLOCe+BXhS/A3g KVoyL75OzFDn14CHxY8Aj4jnAOdo/iTFU+JrgPOQ54G6XwMeAPTBXb8CPCL+DhDr+2h9H9T/KeC8 +B+kEOr/EJAXXwL0iP8E6BNPA4KuAOwRnwM8IL4CeIh+e1h8F3COMQKeZFSA84yOFAJFtwL2idcB TonPkx5o+XVAHqjrgZbPAvpgVD2kh7EBHgAae6BNLD8C4+kBKXUCjjLtZAvlyRbKky2UJ1soT7ZQ nmyhPBmF9t8E5MUXAT3i9wB94j8CHhCfATxESw5D/VFo5yPA4+IvyCiM7XEyS9ufpe3P0vZnafuz tP1Z2v5eWmcvrbOX1tlL6+yldfbSOgeg/BzgSfFjwFPAyQNQ/jtyALjxY3KQztpBOmsH6awdpLNw kM7CQTprB+msHQKe6MhdQNGrgLz4M0CP+HNAH3D7LpgFzB8QfwJ4iOZBmwHOASfvglnQA+Is3AX9 9gD2ieWAUzB3h2EMZwGPiB8AzgGfD9PeD0PvZwDnYZxHoN/3AHmKHqh5BPo9A3gAZOAI9IglR8R3 yBFo8ySZg/o/A8T6c6hvAX0UC2Ekc3S0c3DvWcBDtPww0D4HWkIHOMcYAE9SnEeEMacA+8Q+wCnx X8lJaP8DQB7uPQnt/wrQR7EQ5O0ktI95bP8ktI/5wxRh1wTE9k9C+xpAbP8k5clJaB/mCdp/hZyC 9n8MyIs/APSILwP6xO8DHgC5PQVtYslhmP1T0KYK8DiM5BTc+7/IPNz7U0AeZGke7n0f0Ad8mIex 6QB7aPkBWn6IIkrgPKV9no5tno5tns7XPIxtHLBP3A84Jb4Ea0CBOzFouRu4XuD5K6D7FIwB0Cq+ Dhih2CmeARwSdwLuEn/F9cEs/xCwh3EAHhFfBpwTHwc8KT4LOI95aP9uWF0K8SkO186POVw7iD6K PeKbHK4dxMPij7gp1B6AcxRPQb9T1E5gmBI2n8H/gwf/DFHkqAVjop8wzzImTiHnOSbEWeW8IquO EiyIajmvyipXM3u5NXJewxTBN1Jeywjcc3Jexz6Yqa9nNnI/l/MGpkhRJ+eN7P9QpOuYmFHVZ2hj 0T/l6l1ynjBq9RE5zzJqzRk5zzFWzYdyXpFVR8kYtJycV2WVq5l6rVnOaxi7ekLOaxle2yHndaQn U1/PxLRb5LyBsWvvkPNG0qVN1zEx1bpfwEiIQivzWcpLfJbyEp+lvMRnKa/IqiPxWcqrssolPkt5 ic9SXuKzlJf4LOUlPkt5ic9SXuKzlJf4/A1GYMqZUqYMUGC66VuNppgJZhr+7WBmoKyFvg1KeidU CkpGIDfOxOGbZmYUksCsh7KdsFvOwF34aRiuw1B7L+AQ1GyB+0ahznYoG4EaI7ReCv6NQVtDtO44 fJqGsnH6nXT/CIxAgH8pqDcCLeyHT/sgNwN9CfQdVNshPwp1BTrmWbh7iL7jaidtZUJudQZqjMl9 Yg0BaJygfQ7Td1khLe2U1h1QkqLvWJqiVAj0mqJUYr8SHYPwTTFteYyWjNIWU8AjqTzdyxi0M0o5 NimPchxKxmivUptI50zWCLDHSUpL+h1cErelsWNPE8ABgb59aiflwgh93xS+x2uGfkKKZzLzIfFM 6kWgYx+X6ZqgvN1Oay6OOJsi5Np19D6J6t3wOU7lIXs2I7S1MdrCfsqHWXnms/mNMybRP0zHj/RL 8zJFpQGvUo841wK0MZmhRhrjTrnONHy6Xm59BqiQZmhvZpZSVEZSUDp2AV1paR6EkaRo/4Ny/3Eq sTvpXOE3l66Bukuo3ihLzogsY1XQSg2soCtL+gztc4hKIvayOzMHad5cbu3tlOV6MlMbJVea8XGo P0xlpwtqDDKFlKdRqDNE22uj907Q9mcgTQIdCUj7aIrTNXVhf3G59QTk91MJ3ElHPQkt7IdS5NgO SjFK6oWtpst30DfPTVF5Sbe3mdIgScl+OrvTdIQzVI6n6bqT7hYoDbgGhukMjtA+hukcbqf3prm1 kukFupvle6eyvpHWzxDlyeKa2Ce/sW3XFfqVPmPdQZjBWcrDoYyMDdHvJ6mE7M+Sq0lK6bgsWVJb wxRxpVxMN34vrchCuAtnCqVhe6any41q/JKW/3QeLbae1oqCrNdm6LgHL9Avl9Ke1iYXj6s+iwNI iUSLpGXT+8RURmMPUZ01TnVX6oqUSnxOXcBTacVPyChRJeVnqeTN0juH6PpHaoYz7WDNUbpq/tAM /bnWxeKaSNDR4BqQNH+cztUkc903hPLSsnKhe2RwamJ6YseM0DIxNTkxlZoZmRiPC82jo8L6kZ27 ZqaF9cPTw1N7h4fiLanRke1TI8LItJASxiaGhqfGhenU+LQA34/sEHakxkZG9wv7RmZ2CdOz22dG h4WpidnxoZHxndPCBFSdGR6DO8eHhMGJqfHhqem40D4j7BhOzcxODU8LU8OpUWFkBvoYnC4WpsdS MILB1CTk8Zax2dGZkUlocnx2bHgKak4Pz9AGpoXJqQkYNw4bWh8dndgn7IKBCyNjk6nBGWFkXJhB OmBkcIswOjIOfU3sELaP7KQNSx3NDF83AzeP7B6OCzKZkWlhLDW+XxicBeKlcc/sgv6H9wlTKaBl agTIhhtTY8LsJHYDLe6EkumR66H6zAQQtBdJSgn7UlNjUl/I5sFdqSkY2PBUfP3wztnR1FRmBurS XW8E5gA5QlW8pvwCps9MpYaGx1JTu5ECHM3i7O0EXk9i8eAEED4+Mjwd75odLExNR4WhYaFtamJi ZtfMzGRdIrFv3774WPq+OFRPzOyfnNg5lZrctT8xOLNjYnxmWq6K+R0p6H431ts8MQss2S/MTg9D 5zAg/FpIwQwMT42NzMwMDwnb99NhreztaoZvp+gHmJ+h2f9D3JnAR1Wd/f/cuZM7d5aEEBACREnY DIsYlgqFCAGjYsAQUZTiNqwyihhWw36JiAGpBmsRlyqgRaoWl1j32oGkEYQiYoiRoEI0WGmQlDIh r83Lfb/nzCSZROxr3/f/fv5z+M7ce89yn99znrNMApdwT9w7KzBtVlRdPgNzps1eOJ2qeGx6YH7u bG4gfZU7L0CBaZSaMWdB/+TGe98zh45MDfROnnH3VFmpuak5jYXPa5EqLkORbpm/YF5gWjhemu4u w6SxreHKgNQAdyFk5ZiYJwN7+j33zpl9z5Tom2LzlLCldDxy8bE8WLggd+EC3L4oMG2GLDNrxuzc VoJ+Sl+onrh0+oyZUwj+/lPm5+Y1fW8SdqJYI8730ijBzlu0Ey7bFm3Y44e/bQi+YQpxJvyz4n/x cuqnfT6NMo6kn1o+NlaW1+N/avk2bWR5p/Onlo+PV+Xrf2r5tm1l+Zian1q+XTvK8ynkty+nKi9t G6Le24pYkSA6i0T2lUlisOjFCn+xyGZXfTNz6yyRzrw6QuSLTPEwO4CnxFi+v9wk3hCTRbG4TRxg 9v2cUic0h5A/dXNo8bx3Jl2kXaylagO1HG2kNlkbp92q/UKbrc3U7tHmaws1S1ukPagt1zZqa7Ut HO3Q1mvvyp+6aE9oH2t/0D7XgtpftZ3aP7RSh1P7wNFGz3Ik6dc6eusTHZfpkxwj9NmOTH2e4wb9 McdkvcYxVT/puEc/5Vim1zrW6qcdG+nfZ1tqdjz/P9T8HJpfRfP7aN6L5go0V1PqNJpt1HrQnIji 7mgegOZ0NGeh+SY0z0DzPDRbaH4IzY+j+Tk0v4zm99C8B81laP4SzfInQWe1nQ4Hmtuh+SI090Xz z9F8NZrHo3kimmeg+S40z0ezheZfovkJNKPP8XpLzTE3R2nuiOaeaB6E5lFoHo/mW9F8F5oXo/kB NP8azc+i+R0070ZzOZq/RvNpMZ3mZmlx9HCS/Hkrmoeg+Qo0T+DsNjTfjeZlaH4QzY+jeTua30Tz h2guR3MVOX/X1juEVujwaU84ErU/OHppQcdANI9A83VovhXNs9G8FM3r0PwrND+B5pfQ/Bqa30Xz HjR/iuZqNP+Dcdkqts1bojR3QnMqmoeg+So0T5S/0UCz3Dfko3kDmjej+WU070bzp2iuRbMtbtPi 0HwhmvuheTiar0bzTWiehub5aF6J5ofR/DSad6D5PTTvQ/MRNJ9C8z+1tQ6X9qCjA5p7onkAmi9H 81g034TmaWhehOZ8NG9A8xY0v4rmd9C8E82foPkzNFeh+e/6KV3otXob/bR+EZovaanZuzZKcxc0 90XzcPm7JjTfjOa70LwGzVvQ/Cqad6L5YzTXiLGaS9ykdROTtYFoHq3+n/pZ2lQ0L0fzOjQ/iebt aH4bzaVo/hTN36C5XpuNvnvox4WO3toi+nA52tY6JqF5Fprz0Hw/mh9B8xY070Dzu2g+gObP0XwS zef0iWiapCfqs/Wu+jx9oP6YPlSv0UfpJ/Xr0DwFzXPRvArNG1pqbtM5SvOFaO6P5rFonoXmxWhe h+bn0VyC5kNoPo7ms+JKrT2aB6A5G823o3kZmn+J5qfR/C6a96C5Es3fovmfWqrDreU4umiTHf20 W9E425GD5qloXoBm5jDH42h+Hs1voZnx7PgUzdVoDmlBXdd26p21Un2A9oE+Us/Sb9Gv1eeg2ULz OjRvQPPzaP49mt9E8240f4bmE/ppp4tpOlGub6aLP/HxqamZy/LzzRjNdB0tLKwtKCiolSdGboHF qyDXNDTTrC1YzYscJzm1lsUfq8WJpYoNzbSsp1ZnDlUnVGiQtUxNM51W5KWaLijcHNxcWFggG4iJ ZNSapmZ6iot/y+vxx1UDJSXPPffoo+vXq5O81eqVpxpQVkZac6mTwgLVmuEvtDKS4wv9Zowwjfrk 8KvRHNWAEaMZrlozr6BAteXi1gWyBcOpGTG50pRcdd2URSikyucW1FtWnukUpjMtozZDvihkGHmF hX4rN+wxWnplt6wSFiwigqVVliUVby5s4QrD1AzPG3vW8lL3CFeO3I6XNMNwhY1TUg1X2CLTNHTN cB4Nt4LZRq4VTIs/6nIKlzNsXZpqRpbeNMuIEUZMQUFOTnKy4RaGu8AqsCYyZXUjhfPIySkwm4sh rtlQEZZwND7en5EhMnQmWj0jw9J46ZY3RrhjTDM+PlnWsixNZ4NylPg0YzZv3qw6QWlRajjxb1Yd Uh/JMXNNM5KTlpaTU1gfH69OhmaoTsn9FyFKl7pkuFlWJNz+n4ao6/wh6tZM705rp7WV9ChJurJl qLo00z00M58Xt2iKzv99qLpjNLfLio5VIxyrKsNsClaZ4S+slRlO4SZYzxetjY2dJ1zdTs1NuEbi 1a1p7ia//K8CVg6uV4KtAlaNp4zzR6zxLyLWaI5YozFio00VYRn+wn8vZt3hmKWfmmOWk+aYVTmN MctJc8zKYIzErNst3G5TtBftlb2jxErlWrehuU1ZoJ6erXe7OEsfrawdnS7P3PWrZdTkkyd7p94K B23zWb1qRZaU9R7Kz4/Uk5XOybeWnaXutzocxgWrZStGY1a926O5fUFeWzK2ZDyi0nqS29Tcnp1b tmxYu/b+++9TZ+mjV8kXt5LNKdObGldnBYw6ZaJcLpRn3C7hdp2Lj7yaTFQjwhWjuaQL8+hkj6F5 TNp6q4R2St6SWeE1pyBXZTmdzgXryVq/wGVoLjn/N1jWMo9TeGKaojqDki7XMul2iwJ5LdrEMOWR SGRbnhjNI6M+4hOPpnma3WW53JrLVyT2qTEdTuq+kaYabVgdvkvkeslbsl15GjEVo11OzRUJdUse y3Hqj48/KsdjTKPhaao91Rz6pFdkHBPILo9weTMzMjP6WDK1ZRMSziYzJ6fAE1WU4PVoDk/j7CQi CnGvmZacLJKTnQ7hYHhlWA5NcyA11hBew+lsEfqaM+ao06l5jEJekY6MBL86iwR/cn0kzwyHvwwA V2Jq6pgxBQ2mqfKI//AA8PA9mgHQPARWMghUB7g0j1tFjQz1Bo/J6YhRYetHjZCnnoZ8FW+ryJVd 2dAY9w1KWtMwsFRhVffhVasidWU9W9Vu1bWqqdWNM/pqeepqymzweDVPbNAf9DP4N29I3pC8jrSa pBqVwyE8HjxuzeMdEZHS+BrFBlA1L2WFx0aTSgbH6tX5kT6RMSAd53EJj9k0OuKbDA+PskiUOZcR FV5D88pYjh4grsgAUXnO848Qr1N45QhpGiIu8lbIuLVYRJe1bLb1GPHGaF7lm8gg8WqaN8qT/0ej RCrLU9NH7f/FKPFqDm/jKJFKlUgZyv/+OPGqcaJ6PLIhlUpjHB4zuWmkRHLl/7ztdEbmpMSmsaJO 0zMi/s/zeoTX4+NrhkwppAxrpUVuhpXhdWneSCCp8eI1Ob9oSoaSkTHlInnuqV8THjH5a+pVzzZY TUOm+bwh3LduzevtKvxWhsAL4uFwO5bf6ipUVnMv21E93joClFX5TQtLvrxL82jirrGat00wMZi4 OXVzauGYwjFyLrnfvN/MN9VdgtZmUiGpwFpNyietCtuWJKa1GF6jOE8SETeopbHJAHkeHl/KANyN lDRT+tvrEt6oERbfSlv0yI18sWC4EV8+l+ZzhweGXKxK3mqxxVS5Dl7DrpK5Vw2LbCblkCM3Rvhi hjaPOdl3ZvOgy1/WqvH8/PAU1STWZ2g+M2rcrfZpmi/a7Zbp1cy4t4OlampqTGq72dhki72ntzlH DT913mi7/E+A5Q40Mv6syM5GTlHMUExYRkZGfVjIUNVq+AaIZj9u0nxmaiq7Hq8wfdKKrIysjMZh GN48y4HHOPRGF2cs+TSHr2kXIsUr2bkFjJMfGYpxLuFzORyNgzEyFmPUWPS55FhU4RBW3Sjc607L KYz0/jl1nreaNvKcDgfhIUeRr337HpmZq21urPLD41HV93mFzxsn4kQXlQZYAyx/cCXrg1wifKbm 8zSUlpaWNJQWFxeXNvjcXOgqci2/CEYlP1e6Cp9H8/nOiWK+MASjXjutYuucUBFxTp43qKvnmi+c C5dT1btauRnhtj+IVPcHc4NdLZXZ3KYdfYOgz4GfW1yQdheX7ttXUVtRsa+0tFjezIwqcM4Xp/ni jyYdTapNP9CvYnbF7N3j9u0rWf/B+mJfsU/d7GiwNnggWEHaRyol7QoWB3cGfV7NF9tVzI24qDH5 g3ODuCDsMOWrsCXSYQ2iVBSrVCrkcfhsp6VckD4zGDyalxRnGPvyfKbwue3E5lcr2c2vKdZIofaa y0oNY0Vp6f5FsaYW65FZR44Xy9fxI+FN90xVfma6ytd5Db9D5d8xXO54uX1pKR0wNT3W0GKNdL/f X++PvHwyfyW9X7osuIIaK1rforg41qHFOoNBIZoMi3VpsW55UIrzayv27SuNlIl6uX2au82Ro9+k lbZIagfe1HR4Pz5THc9M90XlHT8S7mK3p0kKstSmrOJo4y3kjj2vRHrWtz5ProBGs7Khqu3IffCD /AYjv+ZOEzJdRkoiueP4I8NhWuIdm6ZvGvxKem2iP9HPVs9tFs+cmZ6YPnNmse/8dRNJaSLW4YiN iksR8U7eesMwfEPT0tJEWlqMrjlisCloydk2Jhhs6xJxLvk/jfrof8qkycyg5tRijNoY+sjcJ18q 0CLeaXSQzzM0r6Ixcmx1YVmprhvpBu4pXaZCMU5cJDpgZC8xU1xFINqWIWRSpS/iXkEVvTPTI78R 8YitjklCn7Z43mzR/o55M+4Sw2ZPWTBHjCNHu37C6GSEymfXyZ8fGiKWHXD4TBPIEBeo6+ErDnbI bbh3B6Ffk5MzRvSYMP7aZJF2w4SxySxN4TLyd1LxoqM607lD26bW2eSxYegUOWP5Ee1EZ9FlWu78 XPGcen9Bvb+i3t9Q7++p9113zZg3R+xW7/vVe5l6P6zej6r34+q9Rv7KVJyW75qh3jur9/7qfbR6 v1G933n3XXffpa1Q72vU+0PqfaN6f1q9b1PvO5p+s/TfvWs/8d3Ek3yDl38zkGP5N+b+/11z0A+x //anjEH5d5fk37bJF4+IreI1sUscFFXqd0FupdSMqK0R8u8N6tRrz7DS5M9xtWHhz4I14c/f1EfV Id6+29riXPM1tDyP69XyvG1Cy/N2T7Q873mu5Xlqq/w+nVueD04Tbkf0+ZmofENoV6e3PB+3jk8P MZ0qcuTftaROPq5Kc+SIlY7nHJ+Kzfpv9N+IMucC5xZxKOYTo0DTPdd7pmhvex5gt7rbF++70nGF 72bf047FsdNj73T8MXZl7HpHSZwjznQcjDsbd9bxmdCsOukbozz2jfOmA6TDsV9HpRORdOA86Uxc t6aUShpGyiTdqdKm1in2QNzWuNfjN0bS5qj0gkxyI3We5Gmb05TWtX20KdWFU0LSeVJ/0uD2T0Sl 58JJ5bRK7V9rv7sp7b/gKOm4TB2c50sJ/TskdEjtuC4qParSrvOmAx2/b0yJ7RM7N6XMSMo6b8pR 6cbIZ8tkRd5luVKVyppSuPYXibWd+nSa3unpTttlat16px3nS+HWO73VqSqSzjQneZdO36t7WZIL x3Uf1pTGdZ/QlKZH0p0kq/ud8r8C6pHRs3/PzO538t6/565euy8uV+lM6mRSbu9epH69q3rXQ1Xv c312931apt5Vfd/re6LviX7OfnH92vd7h1TWfwQpp//kS5+KpPcHWIN6Dfrr4EcuG0waMSRxyOQh eUNfi6T3hpYOLRvWhzR02JrhRy43VCq8fJdKDSMuG/FSJL1xeQPnL42oVWe1Ix0jHSNeGtkv46GM 90b1v3IS6YurZ11eGC7NZ2241DUjZLlrxmV1y0rLGpG1fWwvlXLG3qlS3tg1Y5/iPW/sh6Sj45aM s8Z9cW0uaWO2n1I52fuz94/9kPcj8ohUlV2T/f14S6Vt4/ep9MX4GvhifF2Oc3wd+TU5k3OO5FRd t4D0yIRkym0bXxfOmbBkfN2Eryd8NzHnxtJJk25NuDXp1l53OO+YfEfFHd83fs7qR3ptTvycbrl5 ufm5wdyq3JrcurnOuQPnZs6dOTd37pK5BXM3zn1p7htzS+YenJc775F52+edni/mJ8wfM3/q/Pfm ly8YvGDqgqcW3riwYOH7C88sMhb1W3TVopcWHb83897v85Lyrsrz583LeypvR17F4m6Lb1n8xuKK xd8v8S3psGToktFLpi/ZtqRiaZ+lmUtvW7pp6QtLjyytW5axbMmy95YbyzOWz1v+yvLS5Q0rOq+Y tWLbipqVw1bmrdxh5fzIXPVG6/mo5WxjLWpOch5RX8AjKTyD/MjYy2o94lqOk3Ckn3fWaZx5olLL ucMqbU5ydrDKmlN4XpBzaPwLiaUdH2UePjyilllTzcHqk/m2bQ7z66a4rfEbYw80zZmUbVvXfbqs G/tG3KbmuTPsJWbnTDX/hkt1i9va6D15Vc7Fquxhma/KRzxIu2/Efs1MvpUah1VrB7BuI5+HVWpe HU60WhUyo9aB5pVgq7T7B7P/Cz+Y/T2ROX+dmu/VLK/aoXZcJsebGmdC+mN7pL+Ym8LzT3h+i/Qj cyIzoOy16U2zY2OPMsclZllVskZzH3efYFVZVbQmS50hL6dTVfcJP4wJ5sGyqBn1PPNs9Lz6wzk1 MnOXqmgKz6LjGudPOa9zhbtaNZ22c2VCYs5lg7P3d3CG1zH1yZrV8fsLjhJVCY2rT+OqkpDUwdm8 AoWjUq5tqrRTlqDurg4JMkdekaXk9YSk2AONkZrYOSGJFTBB1pfH4avN62j0SiptUatmZN2MWjkT aKH1Ovloi9XxQGRlbN9oPfnfh+8u7z8254KjiZnY08L70mvSx/RU1Iht9HF4JEpvhiOl+3T8nSV7 U3oiMaf9E6q/t8u+iRrVwzrtQGvjClsWbtWqSbSsmnCSd5Cf3SfIXpFH4UiTn1ZNz/49BoYJr3A9 BqpVKSrJFS68uqn18X+Y1JoalX5YQq20USmy4jalH9aQK+2/l9Ra/JNT04r9I6m1p2RqWsd/JKmV /Scntdv4iam1d9QeJSr90H9q7xKVZNyHe/rfSz9s+b+37qelsJ/l3iVu6+VGVrfLG2IPy12PSoXq iiF3OuqsMKub3ANF8kjsoIbKXVP4qpz75ZFManc0Se2s5B6qdkSt2h+xO+Jo1+WFandiNe1iZNo2 3so+Mt6SOxh1ti2yzwkfb2MXVCWvyB2NrJcdSWrHs0DtjSircrfJ9047KL1N7qaYLXplH1H7rrxI ylFXesldlzrLyT4i56VIHomdWxp7NblDk/XWqCOS2qflqv0cZdVOrWm/NjZnpEN5pEH64roFYU9c big9WBy2dOyHqm15pzWqLdVuy5H4wx6NjoOLy8NnwpDPXpDPXJBPXJDPW5BPW9DfF0OE/DfcB9RT C+RRjfqX3pp6hoJDPjdBPTXBK160G0SJ3aD5RTttipigTRWdtGkiRZsu2mp3qWcxDJZPKVDPKNDU 0wmclPVRti1lfZT1qPaqKfWdcGu3iSTyu5M/kfwLye9OWz1pK0U+UUA9Q8ArnwwgnwWgL8OO5fab 2DtM/8p+TP9apOnVYqD+jeirf2t/rJ/g265s/YB6NoBT/pt++S/65b/nV/+aP0+0EVkiHoaJ3mI4 TLc/FjNgJsy3vxEL7DNiISyCeyEPFgufWGIfFEthGSyHFXAf9VfD/bAGHoACWAvr4EFYD2+L0eId qOf4HNiityZAgxwxXLsOJsD1cAMExHitVHRFcUC/UaTrNwtTvx1miwJ9pbhIXyWS9fvERc5n7IPO zbAFDorezk+gDA5BOXwKFfAZHIZKOAKfi94x8fbHMUftgzF/E76YGo5PQq190IgRWUZvPgeJ3sZl fM62PzbuhjlwDyy0vzEWAb4x8I2Bb4wlgG+Ml8Vw4xV4E86K4a4+oqurL9wuerv8MBXmwjxYDBas AnzkKoQN8AxsEaNdL/J5Er6DWvg7nIazgA/NaTAdZsBC0dUtxHB3e9FVxe5x9dwFefSterrCBURt EVFbRLT1ItpGEW35RNv1RNtUou0aoi1DPg9BPvtAv9F+SL/JXiKfgCCffyCffqC/b2/TvyLOqoWu HycGvxU3qzj7Wj4JgW1m46i4TVwa1f4Y2l9E+1fS/hBKT6btR2n7TWoNou2NtP0k7b1HezeKOFo5 RSunaCWeVi6mlTm0cimtXEorfWlFPu/jC1pKpSX5jIaBtLBdKd3D0csikTb+RBt/oo1U7Xb7Hdq5 lHZup53BtHM97YzUAvZHtHWptsl+i5rv0p6T9hZh2UzabIdl99Hag3qVfQbrPtT/ymj9Vlyin4iM 2La02odWA7Q6hFavpNUetJhKa5/Ifw2unuryJvHrjcww/8lMImeWx8V9do1YDffDGngACmAtrAP5 zJP18KFdL/bCPvgL7IeP4AB8DAfhEyiDQ1ABn9u2+AK+hKNwDKrgK3uv+Bqq4bRdKf7BOD8DIaiD s1DP7PYf5H8P/4QG+E84hy22XaMJ0NSs+JU+mQi7xT6l38an3z7lPGjXOD+BMjgE5fApVMBncBgq 4Qh8Dn+1653fwgn4G9TASfgOTkEt/B1Owz/gDGCL8xzY9t6YBHuvK8Oud10JWTAWsu1vXDfwOREm k38z3Aa32zUuP0yFu8iby+c8WMDxvZAHizlfxqfF5ypYw/EDQD+4HuazkM8N8CuOH4Vfw0Z4jPaf 4fpWjp/j+EWOX+b4XaCPXPSRiz5y0UeuStt2HQH6yEUfuegj11HqHIMqoI9c39qVrhPwN7TUwEn7 gOs7OEVeLW3/HU7DGc7pO1cdn2c5p4/MaTAdZtBfDvGQaK9WLl08ROxOJIbl6hXD2e85y+LsGqK8 RP9I9BUaV+tEJpFZSWRWEpmVRGYlkVlJZFYSmZVEZiWRWUlkVlL6GyKtnkirJ9LqibR6Iq2eSKsn imqImDoipo6IqSNi6riffEZEpX6riNGnwFQiaJr9FVFTSdRUEjWVRE0lUVNJ1FQSNZVETSVRU0nU VBI1lURNJT1ZR0/W0ZN19GIlvVhJz9XRa5X0WiW9VUdP1dFTlfRKJb1Ridfr8Xo9Xq/H6/V4vR6v 1uDVGjxah0fr8GgdXqzEi3V4sRIvVuLFSjViDwsXvhzFSDZZe//I2vsH/QBr7cesQqw2yr8nUPgx Co8p/y7jTD5hKQn/5tPCp2IS62QK62QK62QK62QK62QK62QK62QK62QK62QK62QKd7qMtbIHa2UP xmwZY7aMMVvGmD3GmA0xZkOM2RBjNsSYDbGeJjBmqxmz1YzZasZsNWOW/hZjWTcHM06PMU6/ZJwe Y5x+qU8VvfRp8vlJYjXraFfW0a6so11YO1NYO1NYO1NYO1NYO1NYO1NYO1NYO1NYO1NYO1NYO1NY O1MYi9WMxWrGYjVjsYyxF2LMlTHmyhhz1axxKaxxKaxvKaxvKaxrKYyVata2FNa2HoyVata3FOK/ jPgvI/7LiP8y4v8Y8X+M+A8R/yHWvwTWvwTiv5qYLyPmQ8R8NWtgCutfCutfCutfiox3+zS+Ps3+ 7CH7fnpgDPP5MebzhfTEGHrit+SuJ9qv1A+ykyqzz+mHxFTVe5WUPkypClbMh+wVnE2l7kHqfsLV DOo+RN0PqJtF3TLq/UIYkXF0EyUPUbKMkllqfyVj5nnV0gzyR5K/n/xy8ofT0lpyX6Gl0bT0IS2l qfKfqX3iF+q9Tni0NqKrNhlmw91wD+TCXJgHC2AdK31b+Swf+fQe+ewe+eQetTfaLDrq74qf6Tvp /yrRnVX7enaJCazcndkldtf/yszwLRac4NrfxM9Yz+fZO6nRgT1lN7mmU3+2uIYVbDIxf7O4Rr9N 7b6uEXFY1gXLumBZFyzrgmVdsKwLlnXBsi5Y1gXLulCzPTXnULM9NeeomrHUjKVmLDVjqRlLzVhq xlIzlpqx1IylZi9qDqBmL2oOUDV91PRR00dNHzV91PRR00dNHzV91PRFag6O1ByMkptFH476KB8X qT3CWfl0H/k8D7gOJsD1cIPwsHfzsHfzsHfzsHfzuOXvaZ3yOT3yKTSRnUaJ6qNjokxLtau03tAH +kI/uAT6w6WQBgNgIAyCwfAzuAyGwFD4OQyD4ZAOl8MIGAkZMApGwxWQCVfCVXA1jIFrIAvGwji4 FrJhPDwBT8JT8DQ8A5thC2yFZ+E5+C1sg+dhO/wOXoAX4SX4PeyAl+EVeBVegyJ4Hf7Abi3I5077 sLYLiqEE/gylXP/APqTthj3wIeyFffZx7S+wHz5iBzGZbyu32Qecf2YnUQofwG7YAx/CXtgHf7EP OffDR/ahmLZ2VUx7uAA6QEdIhE52lfEwPA74wHjaPm5ss08Zz8N2+B28AK9zvZhPdpvGnzk+YB8y PqF8Bcd1dpXrQrgIukIypNinXN2gO/SAntDLPuS6GFLtw67eQCy4iAUX/e4ayPkg8obbx13pfE6w T5kOu8rUwQkxYIALTHCDB7zgg1iIgzYQD+g1E6AdoNtEt4luE90muk10m52hCyQB9pvYb2K/if1m CnSD7tADekIvbBpoHzcHwc/tQ+YwGM61DLgKrobbKTeVz5nk3UG5WRCAO2EhecthBawECx7m+rOU f57y2+3D5u84fwFOcy1kV7k1QKu7nX3IjQ73BfZxdzIxtFQ9mQrvaHhHwzsa3tHwjoZ3NGpoeEfD OxqeUc+vagsJ0A7awwXQATpCInQC+YQr+XyrrpAMKdANukMP6Am94GL5xDS+ZfeGPtAX+sEl0B8u hTQYAANhEAyGn8FlMASGws9hGAyHdLgcRsBIyIBRMBqugEy4Eq6Cq2EMXANZMBbGCfn/dnq1bBgP 8tlc18EEuB5ugInYfSPcBJPgFyCfrrUCVoIFqyAf7oPVcD+sgQegAORzvuRTvjbAI/AreBR+DRtB /k/S8hlYT8JT8DQ8A5thC2yFZ+E5+C1sA1ZAbTv8Dl6AF+El+D3sAOZajblWexVegyJ4XT5jTD71 C3ZBMZTAn+WTt2A37IEPYS+0nkUm2lPkk8hYB9ow86ezDrRh9pfPYPzYyYznZMZzMuM5mfGczHhO ZjwnM56TGc/JjOdkxnMy4zmZ8Zw7+I7yMrwCr8JrUASvwx/gLfuk8214B96F9+CP8D78CYKwE3ZB MZTAX4TPuR8+Er6YtsIT0154Yy6ADtAREqGT8Brr7ZPGL+0a42GON3K8yf7GeJw1iT5Qs9lm8tBi /JY8bDaw2cBmg1naeNn+2ngFXiOvCOQs9wbl3+Ta2+S/A+9y/h5gp4Gdavb7gPMPydvL5z6u/QX2 w0dwQPiMT7g33+0MvtsZ5Vz71D6rZsrD2Mb3OeMb6vKdxajhmN21we7aOAV8ZzH4zmLwncX4B5yB ENSh7az9tSvOPulqA/HQFhLts65O0Bm6QBJcKDyui6ArJEMv4XNdDKnQGwZwbSCfg4BV1sXqGp51 hc90CK+pgxNiwAD5V3tNcIMHvOCDWIiDNhAPbSEB2kF74TEvgA7QERKhE3SGLpAE2Glip4mdJnaa KdANukMP6AkX2yfNvnxH6weXQH/O2SmYAzhunIkHc3wZDIGh8HN0DINxHF8LfM81x1Mvxy4xr4MJ 8Av7rHk7ds6kXOtZmu+7Jt93zXthOTasgJVgUX4t92b8q1l7I5+baPdxeAKehOdpbzs0zuIvco0+ NEPU/ad91i3sr92a/Jcado0bf7o9fLblejvhUzM7K5S7I9cSoRMwH7uT5M8l5UiP7KuWyyf7qT3a rqbrc+Rz9dTPUeR+6zsR4xhj36JfaxezO/XIn22Rd1L0c6TZJxyDYQiMhDH2x45r7L2OsXAtu/KJ 9hfsLo6wuzjimWTv9UyGB+wTngJYC+vgQVgPvwS+y3kehkLYAI/Ar+BR+DVshMdgEzwOT8CT8BT8 Bp6GZ2AzbIGt8Cw8Z5/w9bVPCB1L6xyT+E48j+/Qw7E/hP0hxzC7GvtDjiv4XGsfc6zju8vN4hLm r0souddzvV3tuQFuhFtgmn3McyfMhjmQCwvgATuEthDaQmgLoS2EthDaQmgLoS2EthDaQmgLoS2E thDaQmgLoS2EthDaQmgLoS2EthDaQmgLoS2EthDaQmgLoS2EtpA3yz7mHQvj4FrIhvGQA9fZx9Ae og+H2J/SQ/scqh/t3eonh13Rvh3d2x032zsc0+FuWGsH8YF8puRhtG9H+3a0b0f7drQH0R5EexDt QbQH0R705Nk7PIthKayC++0d2BXEriB2BbEriF1B7ApiVxC7gmIUPRCgBwLY9hU9EMC+s0TQGSLo DHZ+iSUVWFKhTzx3Rp90LsTqEkvPXMrqEkvvXBr5jl9CdJ0hus5gXQXWVWBdBdZVYF0F1lXQMwF6 JkDPBOiZAD0ToGcC9EyAngnQMwF6JkDPBOiZAD0ToGcC9EyAngnQMwF6JkDPBOiZAD0ToGcC9EyA ngnQMwF6JkDPBOiZAD0ToGcCeKACD1TggQo8UIEHKvBABR6owAMV9ExAXIEX/HjBT1/swQt++mOP Y4y4EPXZqM+O/Lz1wcj36T54oQNeGIQXOuCFQZGfEv+CvtpDX+2hr/bQV3vwRjbeyMYb2XgjG29k 441svOHHG3684ccbfrzhxxt+vOHHG3684ccbfrzhxxt+vOHHG3684ccbfrzhxxt+vOHHG3684ccb frzhxxt+vOHHG3684ccbfrzhxxt+vJGNN7LxRjbeyMYb2XgjG29k441svOEXLmLhDIp9KN6A4kUo TkDhChTeKzrhoxL8U4JvyvFNOX5IwAcJ5P4K/SXoL0F/CfpL0F+O/nL0l6O/HP3l6C/HjnLsKMeO cuwox45y7CjHjnLsKGesBOznW813Z8QljuuY4yZBgHnuTua4u2A20DYWH22a65YzZ6y093qX2ie8 y2A5rICVYMEqyIf7YDXcD2uAudHL3OhlbvQyN3qZG73MjV7mRi9zo5e50cvc6GVe9DIvepkXvcyL XuZFL/Oil3nRy7wY5wYPeJnz5Mx+QtkeYoxXM8arGePV+E1+T+9F7kHGbjVjt5qxW83YrWbsVmN7 CNtD2B7C9hC2h7A9hO0hbA9hewjbQ9gewvYQtoewPYTtIWwPYXsI20PYHsL2ELaHsD2E7SFsD2F7 CNtD2B7C9hC2h7A9hO0hbA9hu5yzJtmf4e19eHhn05wlFX0pBqKoiPwq8s/SGw30RgO90UDZLylr UtbLSPGgtD8jxYPa/pGfAZXSQw30UAMqi1BZhMoiVBahsgiVRagsQmURKotQWYTKIlQWobIIlUWo LEJlESqLUFmEyiJUFqGyCJVFqCxCZREqi1BZhMoiVBahsgiVRagsQmURKovEz1ByH32zm77Z7QiI JPpnNwqmMQL+gxFQh5LVKOkY+clMR/mTGZQ8Jn+aRd/tpu9203e76bvd9N1uVN2HqvtQdd9/EXfv 8XHXdb7Hf5lpknYy4U4BAZGLrOgq4gVXEK+VxXVl13VV1BV3V7C2UmkppbS10BqEVS4F5VKUCi61 FrStEotyabgVWwIpSTtpppPQhKYhyfSXaZImk2kKfM9zstWDnnMe5/xzzvnj5WQmM7/f9/t+f27f GFK7qrOrOruqs6s6u6qzqzq7qrOrOruqs6s6u6qzqzq7qrOrOruqs6s6u6qzqzq7qrOrOruqs6s6 u6qzqzq7qrOrOruqs6s6u6qzqzp5fNFEHv+NXbx48P9zOt+qf2TVD0U19ttkv0322mRfR9vT0b5z h/002U+T/TTZT5P9NEVViXl8vSrsT8wPrySuExc3h0LijvJP2r06nrguFKMK/7s/OsM7iomrRcQC XBdaE9dHkxM3+PRNoS9xZ/lvroYDibvDgRrzbY35tuZEvBkn4S04GafgEu+5FN/AdHwTMzAT38Jl mIVv43LMxhxcgbm4EvNwFebjaizAwnBgYj/jVtqdWBx67WV34vawN+GkF305cYVon4t5Xr3aLhfg 2tCcWIKl+C6ui45OXB/WJZZ5362hK3EbfogfYXl4xP4eqUmEF2qSmIRKVKEakzEFKdQgjVocgkNx GA7HETgSR+FoTMUxOBbH4U04PhRoWKBhgYYFGhZoWKBhgYaFmnNCc825+BDOw4fxEXwUH8PH8QlM wydxPv4WF+BTuMQ+LsU3MB3fxAzMxLdwGWbh27gcszEHV2AursQ8XIX5uBoLsDA8Ek0SOTupuI2K LyfuDENi6bowLE7Gon/kQokLJQ6Mc6AcYS/rOEUdp+gdRSqXqFzSYYo6TFGHKeowRR2mqMMUqV+i fon6JeqXqF+ifon6JeqXqF+ifon6JeqXqF+ifon6JeqXqF+ifon6JeqXqF+ifon6JeqXqF+i/jj1 x6k/Tv1x6o9Tf5z649Qf1+WKulxRlyvqckVdrqjLFXW5oi5XpG6JuiXqlqhbom6JuiXqlqhbom6J uiXqlqhbom6JuiXqlqhbom6JuiXqlqhbom6JuiXqluTcVaK7nIuLaXqN6L4uOoTa3dTeRe290Wwa N9C4QaT3eedmWnfTujux0PPFod+nhkV+LPJjkR+L/JgPr/GhgQ8NfBhK3BI2yYA2GdAmA9pkQJtc ekFt+AOPWnnUyqMGHjXwqIFHDTxq4FEDjxp41MCjBh418KiBRw08auBRA48aeNTAowYeNfCogUcN PGrgUQOPGnjUwKMGHjXwqIFHDTxq4FEDjxp41M2jbh5186ibR9086uZRN4+6ZUgsQ2IZEsuQWIbE MiSWIbEMiWVILENiGRLLkFiGxDIkliGxDIl53MDjBh438LiBxw08buBxA48beNzK41Yet/K4lcet PG7lcSuPW3ncyuNWHrfyuJXHrTxu5XErj1t53MrjVh638riVx608buVxazSDgz0c7OHgPn4/zcW9 nMtxbg/nCpwrcK7AuQL/0/x/iHsx9+LEjV67mdPLwhoO9nGwj4N9HOzj4AAHh8TJBi52crGTizEX Yy7GXIy5GHMx5mIPF3u42MPFHi72cLGHiz1c7OFiDxd7uNjDxR4u9nCxh4s9XOzhYg8Xe7jYw8Ue LvZwsYeLPVzs4WIPlwpcKnCpwKUClwpcKnCpwKUClwpcKnCpwKUClwpcKnCpwKUCl2IuxVyKuRRz KeZSzKWYSzGXOrnUyaVOLnVyqZNLnVzq5FInlzq51MmlTi51cqmTS51c6uRSJ5c6udTJpU4udXKp k0udXOqM3s2lIpeKE9n4Xy6McGGIC0McKHKgfG4aou4QdYeoO0TdIeoOUbdI3SJ1i9QtUrdI3SJ1 i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdInSHqDFFniDpD1BmizhB1 hqgzFL1dZXhVZXhV9sf6eSpxo13cZBcTq/f1nViu39+tbx9vqjsBJ+LNOAlvwck4BZd4z6X4Bqbj mzBB0nqM1mO0HqP1GK3HaD1G6zFaj9F6jNZjtB6j9Ritx2g9RusxWo/Reiz6Jq37aN1nxbEVx7Ig LwvysiAvC/IT+v8xA+j+P0S+CT5R/snG/zra+/jRx48+fvTxo48fffzo40cfP/r40cePPn708aOP H3386ONHHz/6+NHHjz5+9PGjjx99/OjjRx8/+igYUzCmYEzBmIIxBWMKxhSMZUNeNuRlQ1425GVD XjbkZUNeNuRlQ1425GVDXjbkZUNeNuRlQ1425P8PsiHPoTyH8hzKcyjPoTyH8hzKcyjPoTyH8hzK cyjPoTyH8hzKcyjPoTyH8hzKcyjPoTyH8hM9fnDi/4U8m1cxr2LVJlZtemgf076scUzjmMYxjWMa xzSOaRzTOKZxTOOYxjGNYxrHNI5pHNM4pnFM45jGMY1jGsc0jmkc0zimcXmPsT3G9hjbY2yPsT3G 9hjbY2yPsT3G9hjbY2yPsT3G9hjbY1xTjoV5uArzId7sMbbHODpMLR7985wRaTdOZHpRTS3+73LE 7H6VGdXJVLalZVuVbHtZph0t01LRhX+qKPN048W4xrn8Ovf6fhgU2YPeXZKbg7rziE+9i8JFCo+8 YWoaFN2DontQdA+K7kHRPfj/qNoMir5B0Tco+gZF36DoGxR9g6Jv8P/qVFQ+rZQotelP55aRKHnw tRKXDkSfp20jbRv5N8C/AdqWTzY5TlTSt5e+vRP1b5nntzsj3GFSWu61u0MvXXvp2kvXXrr20rWX rr10baRrI10b6dpI10a6NtK1ka6NdG2kayNdG+naSNdGujbStZGujXRtpGsjXRvp2kjXRro20rWR ro10bRRTA2JqQEwNiKkBMTUgpgbE1ICYGqB7L9176d5L916699K9l+69dO+ley/de+neS/deuvfS vZfuvXTvpXsv3Xvp3kv3Xrr30r2X7r10760p73MersJ8XI0FWBh6JzTefzATStGRifXR1MRTJs6n xeUzYUliU1id2GfOGA3LEvtDc1LlTL7T6fXMsC75vtDzp99W/kJ0WPKLE/+mTPl3CvvS7WELx1a6 7lo8LQOeCZnERpH+LDa552aPz4f2xBYn3Yy7tXrcjr5oSqJfpo6acYsmoTGMh6FkFLqS1ZiM45z+ zwzdybPCvuR78F68PxST54Zd6X8NcfrS0JT+FtSI9OUeZ4f29ByoCelFHhd7vAZm6HQddMz0zZCV 6WW+/yOvqX3puzxfjntcY2XYn37A9dfh12Ff+jd4yGv1nj/i0Z7SzV5rwVa0eZ5Fu6870OV9A6Er vQ9joav2qFCoPRpT4XRY63RYe5rXZ4amWjN9rXXV3hBGam8O+2rvwN24PxSivzuoao5PJaq2UXWA qgNUfZWqu6mapWobVfdRtY2qbdQsUnOYmsOUHKbkMCWHqbifiqNUHKXiKAUHKJijYBsF2yiYo2Ab BbMUzFIwR8HsXyiYo+AABQcoOEDBLAVzFMxRcICCAxRso94A9QaoN0q9UcoNUGyUYqMUG6XUKKVG KTVAqWFKDVNqmFLDlBqm1DClhik1TKlhSrUdVCpHqQFKjVJqlFKjlBqOTkk8GBYl1odfU6pBDB6g 0Cqq7EnsDNPF2bxEf7hXdH8hMWLS3h8+LM7+kEyGjcmqcEsyHb4t2luTR4WTkydF30i+NVwp8k9J vit8nGr3i/7zxdxPkh8O1yQ/Fr5y8LezOpNfDPclLwozkzPChvLvL9nVo2rSU7rEM9gUXnLHV/ix 0x173KHfVQddcZcr7pVL58ql85wIH+TYU6HFp8r58sJEjvRFb/bprT75nE/utrYea6txhcxEPrwv ZHzyqfCcT73iUw/7xJE+8bL7dU7kr1P1RA6fJE/f6fmZYadPdVnlxuhEkbVv4pMbRdaz2Cxinvfp LaIqY4ps9bg97BYdu0XHbpGxW2S8LDJeFhUvi4p9omKfqNgnIkoioiQiSiLiZZFQEgklkbCbc7s5 t49r5crfFx1iPVVWvtL9HnTf39vrI9gcxunaQc+e9NWh6PrDrj/s+sPpuz3/aSi6znA0yadGrPwK n9hVjnuT8INqyXp7eSY0e7U90aKOlDXcGfJ0a3HdNtdtiy5y12XevUROdU9Ey+/DYndf7JNDlBin xLgrdFMiUGLkYF6NUGIkkQ1rXbFeJDUnYtGTwlHh0uRUbhyDY3FqmJs8DW8Ne5Jv4/MZeCf36J78 iO9/bOJ3l8+ymrPkXjd1R6g7Ive6KTxC4UDhIPe6qbCY0oESyyixjBLL5F83tcepPU7tcWoH+dct /7qpPk71cWotpvwIxRan16hEa/FYmJve6PEFNGELdiCHl3yv0+PLrrErzK2Nwh9qK8Pa2ipU42TP T8dMFWppWCYHu7k5Xntn2FV7F5bjx1gR1kY1InJYNO7i9HtVn9dUn9dUn9e4/gGZ/ppMf02mvyar X4tO4EfZyyLtB2k/6FNVatSQGjWkRg3Z+4i9j9j7iH0P2vegfQ/a66C9DqovQ+rLkNoypLYMqS1D 4ntIbRmy1hHrHFQrhtSKIbViqCLljktFwJ3cf5L7P+T+DxMbONqAp8KmxEZd8VlsCveLggOJrV7P iK1smJfYER5P5NCODryEneGGRKfHXeh2zd0ee9CLvmipaKlP5H29B7HIG/BYwN4wNzGIIV8PY1+Y oTY1q9xZlTsrg7+gRm1JHPC9V/Fa2JB43WPQhSuQQLl+TRJtlb6uUqdSYUmyxtfpMGuinh3q8TAc jiNwVDhXtF4gWi8QrRfordcn3xTmJ4/3vRNwUvSl5MkeT8Gpat5peGv4l+Tpnv8V3ub5GXi7r/8a 7wyfUCP/TWVZw7WlXFvKtaWi/TPq5c3Js73nA/ib8N3kBz2eg3PDtckPeTwPHw5flRUXJD/q64+F K2TGFw7+xuwaGTI/+eXo2OTFmBFeVF9/lZ4RmtMzMTsckCUHZMgPZcgBUbJUlCwVJUvTS33/u/gP fB8/wE3R1PTNuAXLvP8Or92Juzxfjrtd5yee/9TjvWFW+me4HyvD9emfh/m62bXpBz3/JX6FNeF8 WXW+DnetCFwqApeaD67X5a5N/zZ8N70eD3vfI157zPse9/UGNHh9o+ebvL7ZdRu99jxe8FoTtqDZ tVqwFdu8v817s9jhezmo3qJ7qaw9P70zPC5zz9dFr5W9F8je89PdXhODaTGYfgXiMN2H/vBkWhym xWE6hhhM78UghlSAYRR9XQob0vsx7uvXIObSYk5VWFIr7mrFXW0ybKid5LEyzFMl5qkS82onez5F 9UhBDNamw5O1tTjE14fiMK8fjiNwpNePClmdPqvTZ2uPcb1jvec4vAnH4wSc6L0n+f5bcLL7n+I1 FVY1WlJ7bWiW4Utrb4im1vK6lte1vK69ETfhZt/7UZgv85eqVOerVOerVOerAktVq/Nrf+I6K6z7 Xte83/VXev5zrMIvwtzoZFXiClXiNxOd+emJfv6sStAr45fJ7K/K7PWydp2sfU7PHZWxT8jYblnZ IhsbZeEGWbhN1n1SZl0sk9bJmJtlzLMypleW3CFLtsmCBtH/c9H/D6L/SdFf/i8VzhbxL0b/rl49 YCW/0rG2JtbpUuvVhN977RE8rc8943sbw3bVc7vO9aSaNaBzrdcDB6y2X/dar3utV79WWvmz6lS/ lW9RizZadVa92aXe7LLyXvU6Y+V71eyMmp1RTzZa/Rq1YI1asMYqD1jlP5VnHt1ra/rfVNpLw3od bL0OtlUHWy83B+TmgA62VX4+ID8H5OcD8vMB+fmADrY1fZ3PfQ834qawXVXfrqpvl5sDutlW3Wyr Cr9dhd8uNx/QzdbLzQfk0hpxv0acrxHT/fpJRj/JiNt+PSUjVvvF6UZxuVJcrhSXK8Viv1jbJdZ2 ibVdYqtfbPWLq13iape42qgXZcTURh1uvZh6QIfbqnNsFx8rxUe/+NhlgtwgDhrwlAltU/g9pXfr Di1i4eOqeYdq3iEenqdqF1WbqdosJn6ncu+k7GaVuoOymym7WWzsERuvqMbbVONtqvE2MfLXYmRM lc2psjmxskOc9KisTSprk8raJGZaVdMdqmhW5dymIraoiC1U30313dTerQK2qIAtKmCLCtiiArZQ dreq16Lqtah0LSpaVhXLqWI5VSyrijWpYk0qWFYF26GC7VCtdqhWOdUppzrlVKec6tSkOjWpTk2q 0w5VKacq5Q5WpSbVKKcaZVWjbdzZrLJ0qCwdXNrMoc2qy07VZacKslO16FAtOlSGDpWhQ2Xo4FQz p5o51awq7FQBOjjVzKlmmd/Bqc0yv0XGt8j4FhnfIuNbZHyLjG+S7U2yPSfbc7I9J9ubZHtOtndw sVmWd8jyDlneIcs7nIn7TMflufp94dXo/bKsfM76loxaLqOWy6in+bxE1uzn6yq+1vO1Xrbk+drN 17U8XcvTtTKiJAtKvFjCiyUyoMSPJSK+JMqXi/Llonw5L5aI8pIoL4ny5aJ8uWjeT6+1dFormvfT ai2tumnVLar306tbJO+nTz196ulTT59u0bxfNO+nUT2N6umzVvSWRO9ykbvfnuvt8Zlws4gds4MN nu2z9tHwoNjcGb3JzvZ51mNn/XbWb2eDdtWkDuTtrMnOmqxun9U1WV2T1e2zuiar2mdF+6yo34r6 rajfavZZzT6r6beafqtpsoryWbY/OsmdRt1phzv1uFOPO/XRsHxGbXa3EXdrdrdmdxt1t2Z3a3a3 UXdrpsUwLYbddZQWw+486s497tzjzj20GHb3UXcfdfced+9x92Z3L58Pe5wRdqqX+8KLdv2iO4+4 Y4da9oiK26bils8Hv5uouFXeNXLwDJU/+N8wnZm8KHrPhHJdvtPhO10Tz8pnuwMTOlYe/NSwZ7Hr b3f9IdNw1kwbU3jcPlOUiFBpJq1CNU72/HSsCIOusXPCmRbvbtdFymsciU53jWd95/f0G3atR73j lT+e7yf6TaS+VGMyUuFRu/qs3XydjsN03EnHnXQsn6930m/YGh61hmet4VlreJaWf37uPh4nvOH8 fbL3nyYXT/e4wvvv9Vr5zF1hz4XoGOsbsqYha9pjTXsO/gRnr9X3W9de69prHXutY6817HXvIfce cu8h993jvnvcd4/77XG/Pe61132G3GNPdJqrP2b3f7DzzW+oshk6r3Gn4kRVTU38psj3Dnq5w+5n lH+j54/Vx443u+tj7vqYuz72P6085UpzsveVq8zpHssVY4X3/mXFmDLRRfeZA/Y7W1fx9fNh9sHf 7njRnb808Ruj77Hund75O641ORdst/4nqLTuDRWk3BmylFrB63LffYVaK6i1wn6ecNUbXW0tF5vM btspuIKCKzjZRMUVMiIrI7IcbbK/J2RF1h532uNOe9zJ1SYz2HYz2Hbz1va/qBxZLjdxuelPleNk 1zgtrLD3J+x7J5ebJqrH8VRvp3r7xE8jRlWR/eEZqx6gfLsVD1hx+Wc4A9Rup3a7VQ5Y4QCV26nc TuV2KrdTuZ3K7RRud6cBCrdTt5267dRtp267rBpVdcd1P9EjwkbDE1FCFxw3Ke2PkqaRTZ4NedYb nexZwRmmZD4pmE8KOuWYTjmmU44d/Blh3swyaI4v6Xh5nS6v043pdGPm9ZJulzejl8wVBTN5SXcb 093GdLcxc3fJ3F3S2cZ0tjFzR0Fny5s9CjrNmE4zpruMRVP08v1Wco/eXdCzy3PdK+5a4OD9HLx/ oqpM0e1HkkepJO8MsR30e1ecfH90qArjzBOd5T7ZaJLr7Had8s9cS+Ud2HF64icI+fL7KXGUfHp/ KHm9/FNZ7/C5XdHRnpV3P2L3I3Y/MrHzL5sVLg6tb9j5iJ2PTOy62WMLtqIdHbA7OxuxsxE7G4ne 4m5b6DtK3zb6tr3xZO7esbv00HbUHXrcoedPp/GHJn7i10PbUdq20Xb0z07obZ5nJ34KOHFSp22b u/fQtu2Np/Wows5Ho9OStb46KtxrWiqYlgqmpYI1PWxND1Nr1MTUb2Iq/3RtgE57TEYFDrzKgV9y 4JfOkUc4R5Z/O7I89fSbevqt62HTTb/ppt9002+66TfN9Jtm+q3nYZNMvymmYE0Pmyj6TRT9Jop+ 00R/VG01v3Hnfe5Ycsd97rbf3Z53t+ejU333Zbr1WuMOa9zhncWDP8P+7w6932R3rrj+GB1Whl4a jtNw/E8uPeS1es8f8fiYSWuTxze61uZ5Fn907yXv6fL+XWHHn7k4lWpdVOuiWheluijVZd2dB38m 1UWRLop0UaOLGl3U6KJGFzW6qNFFiS5KdFGhiwpdVOiiQlf0Jvt8yR5fsseX7HGvPWbscZs9brPH bSbVctRts59tpsq8qTJvLy+ZLMsRuM1ettnLNpNk3j622cc2+3jJHl6yh232sM0etk38V5SnJr8W nRotjy4Jd0eX4huYG+6LFobbokX4DhbjGnSH5dFu9GDYe/aHW6NxHMCreC3cWvG20FxxBt6Od+Cv 8U68C2fi3TgL78F78T68H2fjA/gbfBDn4Fx8COfhw/gIPoqP4eP4BKbhkzgff4sL8Cn8HT6Nv8dn cCH+ATOiYyqeDE9UPBV+V/E0nsFGPItNYUPFZjyHRjwfNky6N9w26T78DE2eb8GLsNdJryOEWysP C3dXHhGWV5qyK03ZlabsymNwLI5DV7itMvaeAQyG26rOwNm4LNxdNQvfxuWYF+6rugp0r1oWmqua w4YqJ57q08OG6r/C28Lvqs/Ae/Bezz+EL4fl1V/BxeHW6ruwEl2ev4xd4Fl1f7ivOo+9vjfieTHc OjkRmicnMQmVqIJJcbJJcfIUpFCDNGpxCA7FYTgcR+BIfDBsmHwOvubrb3hc4vEXHleH300eDc1T XGvKkebjr0ZHhC3RkVD9oqMxFcfgr/A2nIG34x34NP4en8GF+Af8Iz6Lf8Ln8AV8CZeEe0TuPSL3 HpF7TXRlWBHNw1WYj6uxMKwWzatF82rRvFo0r570g7Bl0o24CTfjFizDrbgNP8SPcDvuwJ241+fu w8/Caq7fU9kWtlR24CV0osvrr3jsRez7Axj02mthS1UVqjEFKRyL4/BWnA46VNFBdKyuep/Hsz2e 6/Fv8VVcjK/hX3FZuEfk3CNy7hE594ica0TONVX2W2W/Imj15MvL2kS3heboh/gRbscduBOr8Aus xgN4EI14Hi+gCVvwIprRgq3YhgxakUV3eEhNeEhNeEhNeC7ahxGMoogx7A/r1Il16sQ6dWKdOrFu Ul9ontSPPPYghtPJpAL2YhBDGIYTy6QRlD/3OkJYJ98eqlYLquV+tVyvluvV8rz6wvBc9T97/Dy+ 7D1fwcVhXfW3PL8S8zAfV+M7uB43QL5V06iaRtU0qqaRfFpX/Z8eV3pc5/Ex0KGaDtV0qKaDXHtI rj0k1x6Saw/Jtefk2nPVexBjr8+OeJ0e8m5dxbuiSdHhUSWqyv8oSflfRMAUlP96dw3SE/9O6OHR ITgnmhqdi0vCIjG+SIwvEuPzxPhMMT5TjM8U4zPF+MxogSssDLPE+SxxPkuczxLns6K66NDoOnwP 1+MG/Ae+jx/gRtyER6I3R4+iOyzk6EKOLuTo7RxdzdHVHF3N0dUcXR2V/4L0/rCYq4u5upiri7m6 uOLHobXiJ7gHP8W9uA8/w3/ifqzEz7EKv8BqPIAH8Uv8CmuwFuvwa/wGD6Eevw2tiXdHhybOiqYm 3ufxI7ggLEp8KsxNfBqf9XxGWJqYGS5LfAuXhcvMbJ9OfiVcaW77dPJrHq8Mjcl5oSXZHFUmW6Kj kttMva1O5dujVLI7rE7uNov0RG9LvuKxt/y3gTzuiY6YdGV0+KR5uArzcTUWYCEW4TtYjGtwLe4N s9SLWerFrElbo0MnbUMGrdiONmSxAzm0owMvgZ6ifbFoX6zWLKo8PLSK+oVqzKzKPVFKfVmkvixS X2ZVHogOr0pCbFUdgSNxKs4Is6re7vEsvDeaqqbMqvqAry8Li9SPRerHIvVjkfoxT/2Yp37MVD9m VomlqoUQS1V3h9aqH0/8F/St1SfizTgJb8FZuDCslmkLZdpCmba4ek50aPUVWIKluA13ef1ejz+L 3iybFlf/0tdd3v8ydkHMyZzbZc7tMme1zFldPRBNqS5gr/eP+L74k0GLq8eiQycfFVonH42pOAbH 4ji8CcfjBFjrZGudbK2TrXXyyTgFp+I0vBVfd61LcCkWe34Nrg2tUypCa+qiMDf1ZSwOl6WuhbxJ yZuUvEnJm5S8Scmb1M24BctwK+w39UP8CLfjDtyJu7Acd+PH+AnuwQr8FPRJ3Yef4T9xP1ZGh9Ys wnewGNfgWtC2hrY134X8rpHfNfK7Rn7XWGeNddZYZ4111lhnjXXWWGeNddZYZ4111lhjjTXWWGON NdZYY4011lhjjTWm3xEdesgUpFBT/hevky/KlG7VqPxV+W+PHJOYr5qlJ/51gSpUYzKmIIUapCf+ gn1aNUubAHImgJwJIGcCyJkAciaAnAkgZwLImQByJoCcCSCn8h2p8h1pEsibBPImgbxJIG8SyJsE 8iaBvEkgbxLImwTyJoG8KjldlZyuSk6PvhkK0QzMxLdwGWbh27gcszEHV2BumKGizlZRZ6uos1XU 2SrqbNV0mmo6TTWdpppOU02nqaYp1TSlmqZU05RqmlJNU6ppSjVNqaYp1TSl73boux36boe+26Hv dui7HfpuR1T+ecdqPIAH8Uh0nMp7nP5b0H8L+m9B/y3ovwX9t6D/FvTfgv5b0H8L+m9B/y3ovwXV eo5qPUe1nhP1Osv2oR957EGMARSwF4MYwnC4S2VfpbKvUtlXqeyrVPZVqvoCVX2Bqr5AVV+gqi8w 02fN9FkzfdZMnzXTZ830WTN91kyfNdNnzfRZM33WTJ8102fN9FkzfdZMnzXTZ830WTN91kyfNdNn zfRZM33WTJ8102fN9FkzfdZMnzXTZ830WTN91kyfNdNnzfRZM33WTJ8102fN9FkzfdZMn634x2hq xWfxT/gc/hk/DhmdKKMTZXSijE6U0YkyOlFGJ8roRBmdKKMTZXSijE6U0YkyOlFGJ8roRBmdKKMT ZXSijE6U0YkyOlFGJ8roRBmdKOMsUe8s8bizxOPOEo87SzzuLPG4s0S9s0S9s0S9s0S9s0R9xQtR qqIJW/BilNLF0rpYWhdLJ84p/zeqHj/h8YJwrW52oW524UQ3+0qIE5dghu72hq6WmBVine08nW2m znaezjbTWXxZcm5Yk3wsPJ1siA5JPqX7veg83+Kcvi06RpfL63LJZJvz/X91ukqd7rSJvzGZ9/oe nefKKK3LpXW5tC6X1uXSulxal0vrcmldLq3LpXW5tC6XNknnTdJ5k3TeJJ03SedN0nmTdN4knTdJ 503SeZN03iSdN0nnJ90VCpOW4278GD/BPViBn+LeME3nnKZzTnPuqnfuqnfuqtdFU7poShdN6aIp XTSli6Z00ZQumtJFU7poShdN6aIpc2bBnFkwZxbMmQVzZsGcWTBnFsyZBXNmwZxZMGcWzJkFc2Zh 0miIJxUxhhL2YxwH8CrkhM68QGdeoDNP15kzOvMc57+s81/W+S/r/Jd1/ss6/2WdEnJOCTmnhLxT Qk4Hn1a5OxScFHJOCjmdfLpOPr3SmiqtSUefpqOnnRpyla97HkKhKkIFEkhGaZ0+7USRc6LIOVHk nChyOn9a5087WeScLHJVJ3jviTjVa2/1/HSotU4ZOZPBNJNBuurdvi8GTQdHOnXkTAjTTAhpJ4+c k0fOySPn5JFz8sg5eeRMDtNNDtNNDtNNDtOr1NEqdbRKHa2aiysxL8wwTcwwTcw2Tcw2RUxzns2a JDImiUzVTyf+ItPUql/jtxN/lWlq1bMem0O9KSNTxUvn3mzVWDTVxJExcWRMHBkTR8ZZuN5ZuN5Z +HFn4cdNIBnn4cedh+urz41SzsT1zgUF54KCc0HBuaDgXNBhSlnlXFBwLiiYVuaYVuZU/0uIq7+K i8MC54NC9WW+llPV38blmI05rnkF7MvZocPZoeDsUHB2KJhwUiaclDNEwRmiUP0D779x4q8KFkw9 KeeJgvNEwXmi4DxRMAUtMAWlTEHHOVcUTEILTEIpZ4uCs0XB2aLgbFFwtig4WxRMSHNMSHNMSHNM SHOqd7t2D16BWl+t1pua7jI13WVqWmVqWmVaWmBammNaWmVaWmBaSjnrZ531s876WWf9rLN+1lk/ 66yfddbPOutnnfWzzvpZZ/2ss37WWT/rrJ911s8662ed9bOmroypK2Pqypi6MqaujKkrY+rKmLoy pq6MqStj6sqYujKmroypK2Pqypi6MqaujKkrM/k91vRefDDUTz4HX3Ptr3t+CS7FN7w23eM3MQMz cXnIm9AyJrSMCS0zeYnPLPP6L7x3dXh88gO+fhCjITsliqaa4DJT7G3KkaF+ytFRKvW50J36Z3wB F4ULTXYXpv7F11eHOLUAi/DHSW+pr7+HG6K0iS9t4kub+NImvrSJL23iS5v40ia+tIkvbeJLm/jS Jr60iS9t4kub+NImvrSJL23iS5v40ia+tIkvbeJLm/jSJr60iS9t4kub+NImvrSJL/3/ceJL/9nE d3R0S/hQxcXRZyr+Nfpcxb9FV1f8e/TJiq9HH6q4JPpi4oLoosSM6AvJz4ePJy8KH0s+GlYlG8Jn krvCc2bDo5IqXPKVcFuyL2xK9kfHJ/POW3tCMTopuuX1Z6Jfhq3RxrDV1T988K/Bnu3q73D1d7j6 RytmhKLe2uMuTnNOZZ8P57jLee4yL/l4eCy5AQ2vx8knw3o9ri35dHg2+Uy4xd2vc+dSsif0uvs5 7r7M3ZPu/lN3fyaanNwSViabrclJPrk1fD25LTySzPjU9tCuK75kTv1l+IO1/cE7v6R3bvHuu7x7 UXLr669798+8+1P66HqfmO8TP574245nWu1i3fxE3ftTic/o5DPCjMS3o2TiQXPyM+HfE5vC8sTO 6P2JUR35qOjQ5Jnh58nHo7QufaYd/MadNjmPJpNbnTVbw2916UpXf92OMjr1ooOdOnnwTJq0s95k v13lvb4nDFR8MZoUHokqUYVqTMYUpFCDNGpxCA4Nj0WH4ZzQHp2LuvDr6Dp8D9fjBvwHvo8f4Ebc hFto+EhoiR4NLRWJ0F6RxCRUogrVmIwpSKEGtTgMh+O/Ufcl8FEU2f+vq3q6OjPdIYQQQrhv1FXB ZT1wNa7r8VNAZBUPbhVlVfBAQOT0WBUR5VJAQQ5BXcVFvLgFD1DxALkhGI4ESIDQ4QgJkDD1/1ZN JyYkkANW99/z+fZUV9fxqvrVt96r7umJBaoBcUB1IB6oASQANYG6QD2gPtAAaAg0AhoDTYCmQDPg VplidAD+AdwG3A4MBYYBw4GngWeAZ4HngH8BzwMvAC8CI4AxcosxFhgHjAdeA14HJgAT5RbWQs5l rYAkoINcwF6SyWykTIaWd8RVyYSe5UPH5uJKZELH2kPH8nlOOIPnYkQck4IfD+fyE+GtPE9aPD+c zk/KJB5GvJQ1zUA4w7TktaaQwrTDuWZUeKsZlJYZCqebjkwyXcRHI10/udDsDwwAngQGAk8Bg4DB wBBgKDAMGA68LbeaM4FZwDvAu8B7wL+B94EPgNnAh8B/gDnAR8Bc4GPgE+BT4DPgc2CBTDEXAouA xcAS4AtgKbAM+BL4Cvga+AZYDqyVc811wHpgA7AR2ARsBrYAycBW4FcgRc4N5MmFFgegv1ZALrZi 8V0NaAScD7QE/iy3Wpfhe5RMsSYAk3CMdlrvIIz2WGiPhfZYaI/1EeLmAp8AnwLzgYWIXwQsBpYA kN2C7NYPCP8I/ITwz8AqYDWwEdgkt1jJOJcO7AcOAYeBI0A2cBTIlSkiGqgCxABVgQS5RdQEEoFa QG2gldwqLgMel3NFX+Bp4BlgLDANmCHXiNn4zpVz7WYyxb5AbrUvwncLfN8CtEf4brnFvg/newL3 Ay8hfhLi3wDeBCYDs4E8uSWKZEpUVXxjfEVhXEUlArXl1uB9Mjn4ENAbeAR4DOgHYLwHMd6DGO9B jPcgxnsQ4z34CvAqMBoYA0De4DhgPPAa8DowAZgITALeAN4EJgNTgLeAqQDaGJwOzADeBmYCs+Tc 0M0yOdQGaAu0A24B2gO3Ah2AwXJBaAgwFBgGDAeeBp4BngWeA/4FPA+8ALwIjABeAkYCLwOjgFeA V4HRwBhgHDAeeA14HZgATAQmAW/IBc4Fcm50lFwQHQRCcgGZmCvmgvn38Q10EXg5n16nQXIyDQaG AEOBYcBxmQz/ORn+czL852T4z8nwnz34zx78Zw/+swf/2YP/7MF/9uA/e/CfPfjPHvxnD/6zB//Z g//swX/24D978J89+M8e/GcP/rMH/9mD/+zBf/bgP3vwnz34zx78Zw/+swf/2YP/7MF/9uA/e/Cf PfjPHvxnD/6zB//Zg//swX/24D976i1cxreQ8zuZCZ81Ez5rJnzWTPismfBDJ8EPnQS/cx38znXw O9exWTJDPx8ZeepoJ8uVOzGbbcYsNpmvpnqYL3dgBhsFH24yfLjJ8OEmw4fLhA+XCR9O+U/J8J+S 4T8lw2fy4DN58Jk8+EwefCYPPpMHH2ky/KDJ8FMmwyeZDB9iMnwIDz5CJnwDD35AJvyATHG+TBYX 6PdxZsL2V7Z8MuzsZNjWybCFk2EDJ8P+9WD/erB/Pdi/HuxfD/avB/vXg/3rwf71YP96sH892L8e 7F8P9q8H+9eD/evB/vVg/3qwVzNhr2bCXvVgo2ba/VH20wi/p96aJj3Ymx7szcyoOIynu+Qk2JiT YFOug025zhkqM5xhwHCZ4cbJnW51IB6oB9QHnkH8TLmTGGaVDzGvw47ji+gKvpi68mXUin9JCejf +fxrWFLfUDO+im5BX98Cvz4Ai+Fq+PaxfD1dgn7fDsuhLuycVMSm0fmwF26BvdCUZ9ANKPdrfy37 AtT0lZyN9ON1nXNx7iFYFYspGnErcbRavZey5Lt0jQcpqfT36UKelhgdf0WtbTEf3gQZIjEtMVvm IvZazJaLMVvu0+8o3q/+jRKxtXF0tV5TrIG0TSCD+i+CPXQhUlyEo9WUhBbG4VxdtFW99e0u+TPv R60h/9fmVbDXGGK+x9GPSI25CTZhFo5ScNSbXBydwNH31IxMSqIAYAECsIEoIAiEAAdwgWjU2JGq 806w8boBvdGmxbADv4Sd+ZVcY/ajJLM/MAB4EhgIPAUMAgYDQ4ChwDBgOCXBl0+Cz54Enz0JPnoS fPQk+ORJ8L+T4Hsnwd9O0v9/4cK6zUZNKWjFHr4MV1L9m8lXch6s2/1oez/0ySLI9QVSobVou0ux xi/UyFhDLdAz3dAPf+edkKozdebd9DvmOvPe8iv1ViI+QKbyCXQpn0iXoR4PV7oJLJk55hV0idma WqC3OlNd5KiLelrhavaj+qjpgKpf1+T6/2vyHe+C3F2Rvge+78F3P2jYL3ILbORM2MfHtf5sJBu5 OFnqn1CQOh4p45EyCik9pMiieEoDi8KGot2wm/qiJnVNB8h1sLszcdWrgHHX6PLW4wpuQC6UqSzi QKzMhw+fDx8+Hz5yPnzkfPjI+fCR8+H75qPOjjJD/eIJJZ6PkSJ0aRtkNtUoVmcXcFYPoA/a1g+W +Gp5CNJloR0eNK466j6KXCtQbwj1Hiuz3hDqTVX/zYLSYlFvACUeRYmZKDEbJUahtEN+K/Ixzjoi Vr0vsAss+R5AX5zpRzWRMwoSW8iZg5z5yOlClrDqNeTMw6hIoxtpF7AbOA7NPgHkAfnASbBDR3gu d8kWvAvYoit15z3wfQ+++8D36Qt5BsiZfAj0YgJdDn34K3r8F9TYWl+btfItXdt6uRFjLg5ezglf Ry4xUbYZBiQ1C8TSjaIT0BnoRs3ERGAWsAPHO4FUAHKKLMRl4zsHsqn3P2ZBsuNo83FIdj7afRyS nY92J6LdijFstDeItqbzTRSjtW4JcnyNHLuQIxE5diFHInJcjtQxkHmP1ry1Mg9yH0POXTrXev2/ BJ1QX2docjd8d8d3f7BiKjUE42WBY4JgxppgxqrguyX6H3XU9UtGKo6YLFyHjgjdpceGehtePH8C WvUk5rs9kDsDNe6Vnta3Hci3C/mCKN1GyQxnkqkm9ZSH6H7gAeAJXP2OuJ6dIFc3oD80U6VOg5bs QU+nQ6a98C/3oZT9mCevohqBGHkokAkckIes3kAf4BHgUaA/MADlRvv/CbQZJSej5GT+BFrVH5yf iuuYBi3ahRGkWwsezkAf7ZU/aV+8BuTLg3x5kC/Pb71aU96GUrahFIZSzoeMMSglF6WEUYp607yN Enaq/yOCfHmQLw/y5UG+PMiXB/nyIF8eXUg9qS3dDzwADKLraDAwBBgKDKPrUGMV1PgncFYAPdwB nBVAL3cAZ72Hnv4EPf0F9PQ76OlN0NO2/AM5Fm36ETNE04g0mLeUNBmwJq6g1tDR1uZVcrM5ja4z pwMz6LpADLUN7MB3Jr4PAAfpOus84FKgN7W1+gCPAI8CSj4bUuX4esN8vWH6Wqke3CvT9WrEHMj9 rp8q3k8VD7k9pLxEr0DsleugGb3D38AXPADfbwd8vQPw7XaYzcO7oWu9wx5isxCTZTaXV6PU3uFt PAf9nIfc+eCGk3KVGZC58AuPmSGZjZSrkPIGnfcrnF2DmDWICeq8Hj+B+vLQKyflBviYYTOKLOQN I9UG+JJhpEwCL/UO70EtYXip2ZAskx/Hdx5qzYdmRnLmo9YwvNNsSJxp2vgOQooQ4iMl5aMFR6F1 veHX5pKBUrJQShilSJSQoeu2yEDuLOQOI7dEzgxfhvNUP4XHQIZU5G6E3FuRO4efwIhV0udDj09C 48KwE6Q8CVlSUVojlLYVpeWYUXK9blUI19mhGHjK+1DyScj0HzWLSoYSj0GOFB4mhlzHUHeK6SLc XDZQKcKrkSId9ameSkaKdJSpeikZZRxE755yvXD1/euE3GVcH51WXxekLeN6oI1neR3ApxXsf7DM Oe53tPE0/a3PlNrPFG3GUZRZHfIlUNBMRGm1kKc2bIY6CNfFuXo41xDnGuO4Cc41xblmmA9MMx41 1MLZ+vhugmvimHE4gg9h1kD9iaihFmpSZdVFfD3EN0B8Y8Q3QTzKwVVQqVXNtfwUqiZVVizkYji7 24xHTA0ggepCvlik3I0y60I+BvkYcu026+N8A6Ah4hsjTRPENUW4mfpXcpSSAllVC5lZE7ImUsAv ReVOgfyqhcxshHONcS6Sm6G9cUB16F48ZE5AuYloSy1c/dqoq45qF87Xw/n6ON8Q5xsjrgnON8X5 ZmgfWoFrUx3lxiO2BpAgN0KGMHon1ayNa1kHba6LNPWQpj7ONwAaIk0jpGmMNE2RphlmNnWdHN2v CRQHOVSPHYMccZAjBDkc3bcNcdxY9+AxyBAHGULqqhDXbU/0+zkiveo9rtsdyZHlS82oSmV1AqPW Q/+dohcY7ReTW1HdQK4WJE6nHzjbhKqdKx1BaX9CqyupJ8jdnKqera6glCtUi86NvuBK/KCvY6V0 Rs8NbkX1RrN6c54T3gsm7QHGqQ1Wa8dPhLPAatfz/PA+sE9PsFp9sFprMxDeC0btATaqDVZrZ0aF s8Bq15uh8D4wU0+wWn2wWmszLpyDHrkQPXIeeuQ8MwHHNeWf0CPRkKoleqUpeqWJWRfx9ZCuPtI0 ABriuBHSNUa6JkjXFOmaQWui4Lk58LmSuPpfn2+oGqzdOFi6jWFVXA5bYQWsvSr6v4UWGd3oSqMH 3WDcQy8b9+L7PnjuHeUUfgd8kTvlIlgeU/Q/1Z13hlQrdCr1H0ibdGzB0dzCIwZPfqnxpZyrQ+rf 7VIRqgIv+UIiag2f9Hz6Gz4tqA3dRi3pDroTsXfDlvsr/ZNG0c30Kn1Aj9IiWoqjL/EZSz/QRhpH m/GZRinwTqZTOkp836hl1KK1Rl3jQlpntDXaUZrR3riddhudjC603+hudCfPuMfoSVlGb+MROmL0 NyZRjvEmPonGFHxqGVPxqW28b3xg1DG+NFYb9VgLdolxMWvFLjMuYa1Za+NSdjVLMi5jf2fXGVew G9gNxpXs/1gb46+sHWtnXMM6sNuMv7E72F3Gdawz62zcyLqz7sb/sZ7sfuMm1ov1MtqwB9kjRlvW lw0w/sEGsheNO9lL7BWjFxvNJhi92ST2htGPzWIfGwPYp2yF8S/2HdtoTGSbWZrxHtvL9hufsix2 0JjHDrNcYwE7zvKMpUxyMr7ijHPjGy64a6zgVXis8ROP43HGLzyeJxpreAPe0NjIG/MmxmbejJ9n JPM/8QuNFH4xv9jYzlvyS4wdvBW/1EjlrfmVxm5+Fb/aSOfX8GuMvfxafq2xj1/HrzP283a8vZHJ b+d3GVm8E7/PyOa9eR8jzPvyJxnxIXwIs/gwPowJPoFPZDafw+ewIP+Mf8ZCfD6fzxy+kH/DXL6K b2IJPJXvZw15DpfsT2bAjGaXmnFmc3aNeZV5Feto9jNfZHeYI83P2UPmAnMpm2D+bK5mb5lrzd1s uplhSvZZIBgIsp8CTsBhPwdiArFsVWBdYAtbE/g1sINtDqQF0lhKYE9gD9sWyAjsZdsD+wMH2c7A 4cBhlh44GshlGYHjgeNsfyAvkMcyAyetADtgCSua5VgxVgwLW7FWdSatBKsu51YD6888aP3F+guv Y11m3cjrWu2tjvxiq6v1LL/U+pf1Au9ivWS9zLtbo63R/F5rrDWO32e9br3O77cmWlP4A9Z0azrv bc20ZvI+1jvWO/wRa7b1KX/Ummct4QOtZdbXfLj1rfUdf85aaW3gz1ubrM18nJVsJfPXrG3Wdv66 lW7t4xOtQ1Y+nyxIMP6eEKI+/0A0Fa34cnGFuIqvE9eIa/hm8XdxI98ibha38G2ig+jA08Tt4na+ S9wh7uC7RSfRne8R94mePFM8KB7knnhYDORZYpAYxk+Kp8UzJhMviBdNU4wUL5uWGC0mmbZ4U7xp xoopYopZTUwV08w4MUvMMuPFbLHYrCG+ESvN5mKN2GheLLaKw+ZfRLY4YbYT+UKat9tN7abmXXZz +3zzbvsi+2Kzi93KbmV2s6+wW5vd7b/aV5n32NfY15j32f9n32z2tNvabc1e9i12e/Of9m12R/Mh +277brOPfZ/dy3zEftR+3HzCHmQPMgfYQ+2h5pP20/az5kD7Rfslc7D9sj3KHGaPtkebT9vj7HHm M/YEe7L5rP2e/W9zhD3bnm2OtOfYc8yX7cP2EXOUfdQ+ar5qH7OPmaOjQHzmmCgzyjTHRYmooDk+ yomqYU6MqhlV05wZVSuqrjkrqn5UffPfwduCncz3gz2CPcyPgz2DPc1Pgv8MPmh+Gnw4+LD5ebBP 8BFzXvCx4GPmguCA4ABzYXBQcJC5KDgkONxcHHwx+KG5LPhl8Htzd3BD8FfTC24L7jZzgsdDiWY4 1Cg0JlA/NC40I/BqaF5oaWBqaHXocOA9RzgJgR+dC5zrAynOXc4/A8ech53HrCinr9PPquIMcAZa sc4gZ5BV3RniPG/FOyOcV636zhhnjNXMGee8ZjV3JjjTrQuct523rUudWc6H1mXOR85n1jXOfGex dYPzhfOF1cZZ5iyz2jpfOd9b7ZyfnLVWR2e9s97q4mx0NltdnWRnu9XD2ekctB5wjjjHrAHOCSff GuKEXbKGu8xl1rOu6VrWc67tutYLbowbb41yE9wEa7yb6Na2XnPruo2tiW5Tt6k11R3uDremuc+4 z1vT3RHuK9Y77lh3vDXbfd2dYM1x33DfsOa6k93J1sfuW+4M6xN3pvueNT+aRUdbS6Jjo2tYK6Nr RdexVkfnRp+w1hILwn4ncq6teis1p/p0jja5SKbJPdRCZiC8tdQUYTlZfoRPlhyJo1tlZ+RZgVCG fz5D7sN+p3+UUyK/OrtPZuPz2zlRSj1HgNfKlHcw8EWxmG2oIV7VctoNnhfSbZF5CDuYybuQi+O0 4jIWtKaUOn+SO6Qnf0YJqWhtelkylmOzUeoEv/RdMlOukLv9o8Mlat8PpMjtcp08Jm+mKPTd+dSg yPlwWZXJo7h22SjhN8nR/7BYImffke+QAxRew1NyHwB2y2SUsQ2HAdhZTelqhOrps8vlKrkR+gPd gd9eev0fyLflVHyPAJLkRbK/7IdQkX4saD1CmSVyh+W3Mh0a9K38EXLgOqjeK56rMO1PZXQFwU8l itahV/0YD2X/XKCbRbXCj8lGyw+j77fKI7D3qyCqFa5CYe1yv75C+wtSl8ifKfdijHkFPa5WRvX3 r0XTlCW3ny652NHjxY6+L18Z2Frq9L6myU24frbcVEbNuUXGdku6vIzUH8p/qxEtvy23TMXz71Ha oXS2xJkN5ciNlskXdGjeqeNZ3luO/NAR+ZnmrW3qulV0k+9rNn0f/Vpys8tVQpZcpFmznHpRSgmH y69VpeT2GVaurVTuuXq/STHHOd/+XI7690TmMpkHPTpS4RqcM55tBvxD11Iw4+2MfPzz9UrJcx4+ 9fA5r5iU7/rfqyOfM+RvWWp+v3ehJUfBTkdPJzD484A8BAbboceU0upjOn68Pl1XfimXyvVqRj9N /vwi4ZepJvj/TmqvRogfl4K5YXFJLi7Mk1ckPAYzTxW6iXogPMePS0PvrTn9rFpQv9boN5A/CuzT 12dyFf+J/Ii4nH/a/KdqYQDWUy/Ev+Kf/15+h/7/wT8qyd8nioRHIndNakfKEkry476QC1HCf05b /67S48O4YoofZQd5i+wp2/upp5XI/yxY7B35H/mLXF8kmlFXeo5GIfQqjVa/maEPoblzaD6sw8W0 lC7RqwqX0je0kS6jLbSb2lC6YdBdRg+jBz0Bj/4f1E/58jRAefH0JHuI9aGn4I9vpqFsK0ujYSyD ZdCLbB/bTyOUb04jWQ7LpVEsj+XRq8o3p9HKN6ex8M1DNJ7X4/VoEu/Cu9IbvAe/hyab88x5pLxa SVMDsYFY+sn63Pqcfra+sJbSKmur9Sv9YklL0lrl09E65dPRZnGr6EApyqej7fDp7qQdyqejVOXT UYby6Wif8ulov/Lp6Ljy6SgMn+5lg+DNjTUsMV5MMqKUT2dUUT6dEaN8OqOqmClmGdWUT2dUVz6d 0RQ+3WHjQnhz0mhvcztgdLZtO2h0sx072rjHrmpXM3ra1e0aRi870a5tPGTXtesbfexGdhPjMftq O8l4Al7b/UZ/eGcjjIHwzl42Bin/yxisfCJjiPKJjKGhwaExxjPK0zEmOjFOgrHY+dD50FjupDkH jRXK1zDWKV/D2KJ8DeNX5WsY25WvYexQvoaRpnwNY6/yNYyDytcwDilfw8hWvoaRp/wII1/5EcZJ 5UcwFh0VHWIiunp0DRaMPhZ9gql7Cpu0xhhaYxg0ZgI8ion0JnR6Ms1CzDv4CHqXPsAsNRv6ZGl9 sqBPSzDqvoBWBbVWBaFVKxH/A62nEG3Ah0HLNsKq3kK/wrpKoVSMsTToXANKp0MY8YfxaUhHKJca 0TF8GtNxOklNKAyNrKo1so7WSK410tEa6UAje1MM6wO9dLRexkIvUyiebWPbqBrbznZSDZbKUimB pUFfa2t9raX1NUHra3Wtr4laX6sxySRV4zD/KQ5ay7DHRtWhuwJhXHyqyaOgx3Faj2tBj7tQU94V 2twM2twD4Xug0820TteBTqeQYW4zdxMz95jpZJkZpkchM8vMprrmUTOHqpi5Zj7VM09C+5to7W+g tb+O1v46WvvraO2vA+3/O8WJ68R1FBLXi+vJFDdgPAQwHm5GTBvRBjFtRVsSop1oR7a4BeOkEcbJ rcjbAaMlSo+WkFoBIVfciTETjTHTmRqILqIrVRHdRDdqIrpjFFXVo6iqHkUGRtHDyNVbPIY0j4u+ iHlCPEFM9BP9UcsAMQAlP4mRFsJIG4xcQ8QQxA8VQ5F+GMaeq8eeodZTkGaEeAn1jhQv4+xoMRox Y8QY5BorxiLNeDEBMRPFREgySUxCDMYnBdX4RDlTxVTkmiamIX6mmIlyZolZSDlbzEbMh2IO8n4k PkI/zBWfoWc+Fwsh5yKxCH2yWCyGVN+IFZD2W7ESZa4R0EyxQUAnxSaRjNK2iu1UX+wQaeiTXSID de0V+6ih2C8y0ZMHhEeNRZbIQo0HxWHInC2ykfKoOIqzOSIH8bkiF5IcE8dR/glxAiXniTyUnC/y qZo4KU6i9rAII68UUv2/qh2gOopNsAebYA82wR5sgj3YBHuwCfZgE+zBJtiDTcgAm7yI/Qh7BDHF KWQqTiFDcQo54JQh2A8NDqcYxSzEwSwbyQltCm0mN7QldJhiFMsQVyxDNcEyaVTN2eXsojhnt7Ob XGePs4finXQnHWcznAxKcPY6e6m2s885gLDneEif5WQhzUHnINIccY4gnO0cpUQnx8lBmlznGNKc cE7gbJ6TTyEn7EhKcJVrXU3xF/ama2IfcC2KBYvZVMONcoNU3Q25IaR0XJdqg9eqISbOjadExW4U D3ZLxL6WWxtp6rr1KM6t79ZHOQ3chgg3chshfWO3McLgPsSD+xDzljsVtUxzpyPXDHcGSp7pzkKZ 77jvUXXFhsQVG1KMYkOKAWN97LPhGHy4ZsMA2HASwpPBg1zzoAUW/BDhObQA+4UEbQMbfonw1+BA TivAgxw8uAGMuRH8yvX6va15kGserK55MF7zYFDzYA3NgwmaB2tqHkzUPOgYVYwq5BqdjE7Y9zb6 YP+o0Rf7fkY/7EcaI8kFS3YgplkyCizZE3vFkiHNklGaJaM1J8axTJZJVTUPxmoerMZOspNURTNg DDe5SbHgPhvhIA9SVd6Jd6LavLN+kk1xXx3NffV4N94N8d31022KB+toHqzH7+X3Ua1CHkwnDgbM Jhvcl09BzXqJmvXi1aotxuffxN8weq8V1xLXHGeLG8FxJjiuDcKK3bhmN0uzW4JoL9ojRrEbF7eJ 27C/XXRESsVxpma3eM1uQc1uiWC3HuSIe8W92N8n7kP6+8X92PcSvbBXTGdrpgv6TNdP9ENMfzCd pTnOFk+Jp5B3kBiE9AVMNxzhCMc9K55DWDGdrZmOa6YLilFiFHK9Il5FjGI9W7Oe47PeODEO8Yr7 bM19iZr1uGY9U7wF1uM+600X0xGeIWaA0d4WbyO94kGueTCxCA9yzYM2eHARwhHuWyK+Qvgb8Qv2 ivtscF8ywor1qmvWi9esF9SsV0OzXoJmvZqa9RI16zniiDiCXIr74jX3JWjuS/S5Lx8cxzXHObZh G8QjbBUcGHyKooKDg4OxHxocSqHgcHBTKPhM8BnEPB98nqI0T7HQuNAbxDTjxDkHwDUxziHnMMVq fonRzBIHZslF+JhznKqAU8IY54pTqrrc5VQFbCIoWvNIrOaRODBILMKKQaq5NdwaSKO4I86t49ZB fD2fOxqgBMUdsZo7YjR3VNXcEQvueAtlTnOnIddMdybSzwJrxGrWYMQuOahWXi/b8/dL6Wa663R2 /v8fm8yQexX8ox2l+V1qnUev9VW07F1qhUt73l/q460Fder9L773man8T+2LJstUmV58RafsegtW 6ORjFZfw3G6yDTxP9X1a37tEjgx42t9Vfl2msJzMU4/kIb334+ErZqNnU6UHFK7sFfFE44rkTkaq zaTWPWog5K8wFnjXv9MWLJSmaL0O3a3j9pe2uiD3lVybk4flTrkFZ0rchajsVrBKXvxIjR9fq4us F0B2XhjOPN1VlttLrmqeq630Ozhl5polZ+jvfL0a/r2CWh+S7yO00k9ToFlqBB+VqwviK1TPLq2j qb8dq1UwmVIkxSt6PUitlW/XoV2QpihD+f1b3uurV61Ty05X8Q2aVqRcmSPzgRNqrUueLJbuTPel /se233nMl2OTU84i862llJdKzaGDdc+i1DNvzUlzq+JTzamlbuCGct9DPPu54pTyiklVdOyVM/8n cqmc698fiJPT5FIdm6Zm96Kzd6Xsh83gxh3afkjXtolmMzUnyR34nu2n8vT9th+AFfikF1+51kxW kwrWZpdjLlgp1wBTEHuzXCd/1PHrI1aEvqN9d8UlLSH53mJHeg6VHxeJeUjOlH3kS2qVX/YtjL0S cQvUuCt515HUPdeS90L3yS/RluRzN1IL9EHNY2CwArtwJfn3Z4vKAF4uvDei7rGUUfLP50rGym7o JVd/j1X3m0uc7SeXF0sb+U7B7JamNKQS9W1QWq/tLd1PKoT5bYffa9jLB+Uqfb1ziZcyh7nUokSZ HsbBAf/uEgdzFNx1yo2cPfv57bf70MXvVxZYKcr20vP2Lny8Erbndm17ljLaMZrPMXeVtp3CZ+tK nM8/NcaPf7z0eKrIffQKb/KBCmaIPGMxQj6vv7M0A3yqgNC/5bxISJ8rsM/0/U5cqYWVkO4TuQCM +bl/tFx+QOr5oPkqDIA5wWLLwRIFVnAW2PdHnyci98+iS5T5nfxcLvPLjFNHfnwxdpCy4tLqfBil ckvhUYHvslOFCvzKiCWuGW2l0o/IMyL++DmsGbmrvFUfLSN1N+8x4EmExshJmOue9Esp8mwLemCx HFQJae+RQ+Xbsg9CX2NUvy17aX54BbPR2+jnZXKK/Cfm1ix1D1C3bJGcI6dHavZnjUT59SllpsuN 8CojI/cvhSHf7pTHIyi/xVys7Gw93gufCio+S+l5utDz1ZbvDv3cQ9EnLi4q/sTK77UVv4urn2A6 ULYkukUlnr/6PbbinqzqVejwkbL4U1+dc+bpVmQran9gNCgvaxO+T3OnuzDlvrOXV74lh8h/yYk6 vBr6PkM9KePPQxF78aj8DFh6dvXoklpEnmQ5qzLS5B7MhHp+xDXdAz0stLkjV10ehM1xsDQLsMJ1 VcLmLpL7x8hVhSyKB3/2j7b748eX+o8Zz6Vt8gF5v1wi5xHTR0PlALB1j4hFIOfLYzgaJR+XV8hG 4NFW8kn54FnUFbEf65+VvD4nRXzawucNZxQ/ey43OesclKG0d2OE1WHflrj6+nyqXPvbLPzHbpBm K8acXvOEDitPsdBTiVi6OPsdcJpnVX/vDfK+WnTkwr5a9EfKc/oNo62fsp0iT7rKJ2Adrcfoi5xb pvdb5ULZWb6E0Gj5aySuknV9d/byVrDG7KLPef3vboU27uGzf7qytGfdz+UWsQ5hf+/GrHcOVizK ekb5jHnLqVHyI722v7/yNRXZap6TUsq1wRY6a8tVjj0XkpRRh890sG7Pel3+HF2lsmpJg2X7Xx4p 526D1ZN9znom9izkOBfj/Xe8H1EZbYTdkxrJ6f+yo2BdZJW+z7DqjJkf8dPOrXi9v/dWmd9AlCjj tHdDzpBHr9arlaKIJxxZ0Sm8Fxw8k3+s13ZrUh+yKl6vzl+JX3nJdD13/PZbsoI1ufL6diG6seK1 /qFbfGUzVvzOE6mnGtR96ULPXi7W+wPg5zLvRvyvbbD7j57+NxNF0h3778tSvq18DFnZWb3U30qV WZd+guC33w7qOxaFmhUsNVNBWrVWVZs6Y8z9AVtx2z3CGvCeyuBZfSfmD1jvk4fOYVk7yV9RLvUX R+fpXzmpO+irSzlbVtnqd1Q7C3IWhPQK/04/pqDOK3Vdp8hV5OjF38oskEX9XquEVOpXWS3VXZrK eO1yinxXLir8HZgfUhaBv6a5ulCOliXkfbfi9RXLX4knheRafVfih8Jj/QwQ7E2r3Hf6yvHrvdPU Xepvk8vIs0evWqmZXHOBPlqOsRdhhuCZ7Es9o1Shq8v3e81S8lfm+Yd16veWGjmRY733V83PzA5+ W2oXf94I+nVIrtGYQjVgk+717ybtiIxprWsPVVzSMtoRucNWxFuXPeST8j05Vb83oPCZHtlGflLB kpf/PhazkvH09chwaXeVI3cUT4k7VPZdnMpu+hkZn5nlYdgTh2EfbZbJvzGRzEScumd8ubxDH38K Ddgou8oV6lguk6/Jb9WKuT43vljZKQXxFZKovewjn5E3+0c6BA3spcPvypmyL/RgCqy1RZh5VYp5 8nP5mT9rq9X5eGqh7zkPlL11XOR5xKmwq99S10O9JaHwKaBia0HyeMGv+Ssk7xvyffhqb/pHq3Td UzTPr9J9oO6+zpXZ8iudIPKrff8JA1+L/1LxWv+o7b/ya+yStewsYKzIfec/aqvMfSpc6QNUZNWh 8A0J5Zl7qpF6fuc2Ha5NreB71td5d8Pq2K1nk1r0Z7kBI1R9UuQ2eQXGSy9yZGRe9/1UjM6IT1XD P/7Ev1PBqPAX0zr+wzO0Qz9bIQdhnvNXIOXfZHegjXyAqsnIHFzwDo2hwPXyStlR+r9skN/LX/XT EmrE7sOctNP3Xy+g5nrmvECnOvPqRulyzZAzsX+/8HiR8uWKPVlxux/oTP+gy+kS/Z6YJvpM0bYH w2tlKJyrZ8ol8mH5qZrD5DD5nAqh1JHFqo08A/ZwJeTtLR9F+x/VBzZCvTVvPqdn6jW4lunhyC/p 5+u3ghRsumflE34Z5fDxSq17b9lpSuTJ1E8EKDtBa5PW5uU4NvVp54z2jspVhf4K6RmtK+M9dp38 99g9SzcZzKhOPfXb6Qbqt9ON0G+nG2l0MrrSGONB40F6Tb+X7nWjvzGSJhmjjIk0R72djhapt9PR YvV2Olqi3k5HXxhfGatpGWvBWtIq1opdSr+ot9PROpbEkmi9ejsdbWA3sTa0ifVlT1AyG8ieol/Z GDaetrFZbBalsvfYHEpj89h82s8WsoV0gC1hS8ljy9kKOsRWspV0hP3MVlE2+4WtoRy2jq2jY2wj 20jHucNdOsFjeCzlqzfMkdRvmCP9hrkAb8wbG0K/Yc7Wb5UL8Uv/H2XnHxbVda/7NXtm79kDmx8i MYBIDCGISAgiQYJokBBijDXUGOOxhhmGYYbAMAzDzCAzw55fMBprjbXWUGuNNdZjiDXWWGut13qs tR7j9XCMNdYaQzweY63Ha6011lp73vUdQj19nvs898Znvaznu9dee2aA7/q8f/BGW65JolS5ZEqV S6VUuTTKkxurXaL9miZd26A1asbxv5XTZPDUN00WT33TFOt+ojuoWcJT3zRmnvSmaeZJbxqrmCqO 0djEdDFT8zrPe9N0iOfFzzRenvemCfC8N00vz3vTqDzvTRPieW+amPgn8S+a5TzjTbOaZ7xp3uIZ b5q3ecabZjPPeNNs5Rlvmvd4xpvmIM940/ycZ7xphqTXpJjmY57uJmh4upug4+lugsjT3QQ9T3cT ZGmz9I6QzHPdhDSe6yaM5bluQjbPdRMe47luwiTpX6WzwmSe6CY8zRPdhErpc+n3QhVPdBNm80Q3 4Ss80U2o54luQitPdBN6+N/HCaosyIIQlCVZL4TkRDlRiMgpcqoQldPldKFfzpAzhZg8QZ4grJAf lXOFN3jimvB1nrgmrOKJa8Kb8lR5qvBNnrsmrOW5a8K3eO6a8G25Wp4tvMVz14Tv8Nw1YSPPXRO+ x3PXhLd57pqwRbbKNuEdnrsm/EB2y25hO09fE97l6WvCIE9fE96T35DfEHbKq+RVwvvym/IaYRdP XxN28/Q14QOevib8lKevCT+TP5APCgfkQ/JHwjH5jPyxcF7+jfxb4YL8ify58Jn8O/mPwjWeyiZ8 wVPZhDvy3wwa4c88lU24x1PZhL/yVDatxpBpyNEm8Tw27VhDrqFAm26YYijWjjeUGkq1jxieMjyl nWiYbpihfdQw01CjzTfUGmq1RYY6wxztE4a5hhe1JYavGF7SlhpeNSzWPmVwGFza6QkTE/K0VTzd TTubp7tpX+Bpbdq5PK1N6+RpbdoentamDfO0Nu0biQsTm7Tv8b/a0/6Mp7Vpf6HolRTtCZ7Tpv21 8jWlRXuD57Rp7/OcNp2O57Tp9DynTZfAc9p0iTynTfcQz2nTZfOcNt0EntOmm8hz2nRTlK3Ke7oi ntOmK+M5bbpKntOme4bntOmqeU6bbjbPadO9wHPadPU8p033VZ7TpluofKZc1C3hKWu6pTxlTfca T1nTmXnKmq6Fp6zp2njKmq49WUiWdY5kJTlZ50lOS07XLePJajp/8hfJX+jUFJai0QWZoLmIrpcM x5fCUpmGjcE/LUvDOaxjGTi7RZzqj6Oej396NgmnoMyK0CUN6IczmIJ+yP8/D7Po/4DBO2YydcwU dMxFuOtV/BuDvvkadmxgTayaWdBDZ6OHukAOXfhXw9xsGXuI9eDfOOZjKp4cRIfNQIdVWKYmSZPM sugvhMdrUtFzn0DPnYRKgaaAlWgmawpRn6KZgnkRenEm9eKp6MUvQevRkZ+jvNBMzWvoy6XUl0up L09DXw6g3qtZzso0KzQrsOcb6NTj0anfZOWaNZpvs+ma9ejaU6lrT6WuPZW6dgm69ruYD6J3l6B3 /xLnwVHNUTZD8yvNh6xKcwLdfCZ1cwHdvAz6FHq6RD09lXq6QD09lXp6OvX0Z6mnP0k9vYJ6ejZ6 +rvsEWFQGGQThPeEH7JHhZ3o8rnU5XOpy09Elz8A/V/o9TnU6/Oo109Ar//f0JPo+BPR8Yeg/46+ n0N9P4f6/mPo+wp7XJuE7p9P3b+Auv8kdP8MVqjN1GayKdosbRar5ScB5jgJ2GScBJOgBdrJuAvn ASvi5wHuqtRWQmdoZ+DqTO1M6CztLKzB2QDF2YAK/1vr5+lvrefQ31c/T39fPYf+proO50SQzdKF dMuZBqfFGpai+6ZuPXta95ZugI3VfUe3iVXq3tZ9nz2s26L7IcvU7dT9mGXhRPkJK+VpoqyMnyus ip8rTOHnCjRVTGWzxTHiGDaVny6sFKfLaaYVfy3+mk0Uz4hnWIr4sfgx04lnxd8wEafOeVQ+ET9B 5YJ4genFT8VPmSwOi8PsIfEz8TOWyM8klsTPJKy8Il5hY8Tfib9jaTiZfs804jXxv/DE6+L/YWPF G+IN9jA/q/DEP4l/YhnibfE2myl+IX6B13ZHvIPX82fxz5jfFe9i/hfxL2yW+Ffxr9j5viSwsZJW 0rFZkiiJTIMTTs9wWEgyS5IMUgJLkRKlRKaVFElhGVKSlMRmSslSMtbgFOT/V3dpLO5Nlx7CvRlS JtZnSeNZmpQtTcDOOVIO4wmoj0JzpVzs8Jj0GNbnSXlY/7hUgPWTpcnsYalQKkR9ijSF6aQiqYgl S09Ixdj/SelJ3FsilWC3qdJUrCmVSnHvNGkaU/iJi2dNl6ajXiFVYuUMaQZ2qJKqmSjNlp7Dyjqp juml56Xn8Zpfkr6K97VAegX7vyaZ8PRGyYynNElW7GOT2li1ZJc62GzJKbnxRI/kZTVSt4TuIfVI PjZO8kt+vNqApOK9BKUQ9glLYewQkSLYISpFWaLUJ/XhKf1SP9bEpBieAgJg4zkBsBIQwDdZmbRW WsumcQ5gmeCAt3B1QBpgWdJ3JPQB6bvSd1mVtFHaiE97s7QZ+n1pCyvlGbBYD1bADu9J70F3SPgp lXZKO3Hv+9Iu9pz0I+lH2Hm39AGu7pX24t6fSD9BfZ+0Hyt/Jh3Ayp9Lh3D1X6TDrByEcRT1X0m/ YsXgjH/F+uPScVQ+lD7EyhPSv2HlkDSE1/Pv0ims+Uj6CK/wtPRrvOYz0hn2hPSx9DGbLp2VzuJe MAruuiBdwM6fSp/irs+lz7HbFekq1v9e+j3W/0H6E9bclm7j0/hC+gKv7Y50j2VyjmHTwDFJmCfr x7AyfZp+LBuvT9c/zMr1GfpsNl0/QT+RTQXlTGJV+gL9ZPaCvlA/hc3QF+mLUHlC/ySbqS/Rl2CH qfqpWFmqL8WaafppuFqmh3cEGz3NntJX6ivxrBn6GVhfpa/C1Zn6mXgWzxTQcGZipZyZoGAmKJgJ CmaCgpmgYCYomAkKZmJZnJnYeM5MUDATe4IzE+ZgJlbFmYll8qxaVizPlmfjLpATKiAnrAE5QUFO rJyTE5sOcoITkG2yjc0EP3WwFNkpd2INKAr3gqJQB0VhZUgOYZ+wHMY8IkdQB1Hh9YCosP5N+U1W Jq+R1+AucBWbBq5aj8pbMn7q5AH5u5j/s/zPeNZ2eTt7gZMWKiAtlsBJCwrSgoK0oCAt6O/kP7Bn 5JvyTTzlj/IfsQ+oi5Vw6sL8b/Lf+P97y8DYcwaNQcMyOYGx8SAwPVQ2yOwpA/5jJYYEQwLmiiEZ mmLA+WtINaSycsMYQxoqYw1jWZUh3ZDOphkeMjzEZhrGGR5GPdOQycoMWYYs9oRhvGE85tmGbDxl gmECruYYclAB22EOtsMrAdtBwXZQsB0UbAcF20HBdlCwHRRsBwXbQcF2ULAdS+Bsx54B273MUhMW JixkUsIrCa9gvihhEeavJryK+eKEJSydkx8qyxO2MiHhBwk7MAf/YQ7+wxrwH9b8OVHDhEQhMYs9 yymQVcSzGzgFMoFTIBQUCP2a8jU2QVmqLGUTldeU19gYpUFpYI8oRsXIHlNMionlKo1KI9MqZqUZ c6tixXqbYsOaFqUFa9qUNsztSjvLUxyKA2s6FCfWuBQXrnYpbpYDsuxGfZmyDHXwJTSgBKC9isqy laASYo8qYSWClVElipV9Sj+euEL5OiqrlNXYGQyKp6xV1kK/pazDmvXKW3jNA8oA9vmOsgHz7yrf xfqNykbMv6d8D3tuUjbh6tvK22ySslnZzCZzcmUFINetbIryA+UHrFbZpryL+aAyiDXvKe/h6vvK +9Bdyo9YkbJb2Y2rHyh7cPUnyj5WqPxU2Y/Kz5SfoQLehYJ3of+iHGaPK79QjmDNL5WjLF/5lfIr rDymHMNTTij/hsqQcgp7goax/xnlDPRj5SzWnFN+i6vnlfPY5xPlAuafKp+yMlDyZ9jtonKRTeKs zHLAyhGWnRRN6mO5Sf1J+JTAzStYUdIbSfisklYlrWKPJH0j6RuofDNpLZuS9K2kb7FaztOogKdZ Eedpls55mgmcp6HgaSh4mqVznmalILtq4uk64mmBSDrOzV8SM+fjZOLjZPZP+JdMZDyHyHgukXEa kfE8IuNxRMYPExlnEBlnPpDfI1J+j0z5PSLl94iU35NA+T0i5feIlN+TRPk9IuX3iJTfI1J+Twrl 94iU35NC+T0i5fe8QPk9L1J+z1jK7/kK5ffMp/yelyi/p57ye7JA6ong5iRNEjF6JntKk6XJAkNz Uq8Aqb/EKonFX9a8ovkn1DmLz9BYNVYQtkfjgXo1PnBzAEQ+HUS+gs0Ei7+B+dc1X8d6TuTTQeRv sWqw+EY2GxS+B/pjzY9ZjWav5ue4yin8VaLwZ4nCa4nCnwOFlzAtUbj2Af7Wgr+fJf5+Afz9IlE4 TxjSUcLQGEoYGkMJQw9RwtAYYvSvEqM/LbwhrGSzeLI/WzhC6pzLpwjvC++zycI+cPljROSPE5FP Ej4UPgR/cxZ/VDglnEL91+DvRym1aILwG+ETEPmnwqdQnmBURKluhcIl4T9R+Vz4HMqz3XIo2ShP +C/hOuY83yhf+INwE3OeclQg/EW4hznPOnpEuC/8jeVQ4lGuVqMVMOe5R/laUStiztOPcin9KE+b qE1EJQX0X0zcX0rcX0bcv0A7XpuNOqf/Yu1joP8ntfmg/2Ki/xJtobYQ8yJtEXSqdhqbBicwHfMK bQV7Qvs0/EAx+YGp2ir4gWLtM9pnsD/3A8XkBF4hJ7CInMAr5AQWkQeoA/2vZ8ng/k0sjYg/g4h/ PBF/hW4viH8GiP8Im6n7pe4EqyHur30gk0mkTKYUymQaS5lM9eQE5pITmE35TC+SH6iEH/iISeQB 9OJv4AEk8gB68gDJRP96ov8M8ZJ4CZR/WfwcFc79EhH/w0T8c4n404j4M4j4M8Vb4i0oZ/o6Yno9 MX0aMX0dMb0gSWB6PdG8nmg+k6i9jnhdT6SeRqSeSXReR1yuJy7PIC6vA4vD90rFIHKJWDyNWLxu hMLLpDKsL5fKsZ6zeB1ReJy59cTZemLrOcTWc4mt04it5xFbjyO2fpjYOoPYOpPoOVNaJa0CU35D +gZoktNzJRFzlbReWo86J+aniJhnS5ukTeBIzsrl0hawchWx8nhi5ZnSNmkQHP8eKHk8UfLLxMcz pT3SHtzFKbmcKPllUPI+3PtTsPJ4YuUKYuWZ0i+kI9jhl9IvsZ6zcjlR8nii5Aqi5JlEybXSKVBy FVHybKLkcqLkmUTJ1UTJzxElPyV9In2Cq5yP42T8lHRNuoEK5+MK4uNK4uOXpfvSfRAqJ+MqIuOZ IOOHMedMXE1MPFv/qP5xVkNkXEtk/CqR8bPEwbOJg18lDq4lDh6vn66fDuUE/BwRcK3+Gf0z2JMn iqVQlphIWWIplCKWQiliIqWIJVCK2HxKERMpRUzUL9AvwNN5lphIWWIplCL2IqWIjaUUsXpKEcui FLEsShETKUVMpBQxkVLEUihFbOwDKWIplCKWQCliKZQilkUpYiKliKVQipj4QIqYSCliKZQiJlKK 2FhKEcuiFDGRUsRSKEUs64EUMZFSxFIoRayeUsREyg8TH8gPEyk/LInyw1IoP0yk/LD6B/LDRMoP S6H8MJHyw1IoP0yk/DCR8sNSKD9MpPywFyg/7EXKDxtL+WFfofyw+ZQf9hLlh9VTflgW5YeJlB/2 IuWHzaf8sPoH8sNEyg/LovwwER5mLKuEY3mczSZ/UiNPkifBGxTIBWD9KfIUViEXyU/AbxTLxaiX yCUjvqVcLpWnsefIvZTL5XIFlHuYWnmGPAP7cA9TI9fJz0PnyC9it3nyV7BmvjyfPSW/BCczU66X F8AhvCq/iqvcz1TLRtmI12OWzbgrnsTIHU4tHE4rnsUdTrLcKbuwT5fchbs8soc9K3fL3aj0ykG8 C+5zKsnbjKfkxnJyOFXyank1lPuc58jnVMnfltElyOeUk8OZKb8tv43KO/I7eDp3O7Xkdl6V35UH cRf3PDPlH8o/xJr35V3QD+B8EuUL8n9A/xOeJ5E8z/PkeWrkW/It7Mw9T6X8F/kveHfc8ySS53mZ PM9s8jxV5HbKye1UktspNyTB4VTB4Yxh1eRwasnhPEsO5zk4nHFwQQ8bMrAyEw6ngrzNePIzNfAz k/CUQviZRPiZMmi5oRI6Ex4mkTxMIjzMS1DuXhLJvSSSe3ke7mXhiGPhXmUxfMgScixLE5ai0pTQ xGYltCa0Qu0JdqgjwQF1Jjih7gQ3lGfRjaEsujGURfcQZdE9RFl0YyiLbgw5Hy15m68mjk/MZU8n zk38KpuVaEn0sYWUVKcjt6ODw5kCF8E9zBTyMJOVZniYR5XXlVaQOvctj5JjmQLH0oG5U+mEc/Aq XlS4V3lM8St+VHqVIFwK9yePkz+ZQv5kMvzJSlS+DpcymVzKJOVN5U2s5/5kivJtZT2uvgV/Mgn+ 5DvYjfuTx8mfxJ3JY+RMipXvK9+HvqO8A+XOpIycyQLlXTiTqXAmO1D/obKTlZAzmUrOZBo5kzI4 kw9Q2aP8mD2h7FX2YuVPlZ+izv3Jk8oB+JNi5aByEFePwJmUkCcpI0+yQDmufIirJ5STqHNnMk35 SPkIK7knKVN+o5xD/bfwJNPgST7BbhfgTHLImZQow8ownsv9SSn5kyeV/1DAeJQOWER5pIXKVeUa KjwpMFe5rtzAnOcF5lNeYC7lBRZRXmAu5QU+QnmkOcpflb9CeXZgkfI3BQRICYJ5AHMQIOUIPkLZ pDmUJjiBsklzKFMwnzIFiyibtDApOSkFdZ4vmJ80NmksKjxlsIBSBh9JykjKwlWeNVhEWYP5lDVY QFmDeUm5Sbm4yhMH8ylxMJcSB/OSWpNa2aPkxB6HEwuTE8PPQ9LypOVwaCvgvh4n9zWNfNcC+K5v Y74+aYCVkPualrQhaQPmPLkwn5ILJ1ByYRElFxZQcmE+JRfqmGb8zewQ4FfRrmSfMmZagmHCsGLY MVwYy0a/apyD+Kpi9GGsxFiDsR5jI8YWjO0YOzH2YOzHOIRxFOMEximMsxgXmBA6ToOZLtEQQkMY ZzC/inED4zbGPcYaBQwZIxkjHSMLY2L8NTTm/1++FsX3aiwdGfyeCoxZdI011mLMjb9eumdL/D02 1mMswlgar498FULnaWicuzD2Yn5xtBYfVzCuj8zPYNwamd+NjzAbGRKGgpGGkYGRE18bzqP1rNGM 0RL/nBodo595fG0hrWONbgwfRggjNvIeVsWfFy4Zea9rMQYwNo1c3zpyvXxkVKGG72Mjfz8HMA6P vpf4e96LcQDjMMYxjJMYpzHOYQxjXB75eu2Br1+uv4lxZ+TruZH77jxw/T5jZh1GAkYqxjiM7L9/ 5d8/cy5Gwf/zVyFc8/fvFX9v5uKR7/X/78j6n4N+vlfGn0M/V1nxdfTcB0cZRuXfv47uEd9XCM9B vRqjbuTnD9fM8/7+1bwAY7FuTMNw+9zeIVNfByOVSBXoyo406JqODOj6jhzoxo486JaOwt4hfldw qWl7R0nQ3HC5vb73TMO19kW95007O8pJq0bnezpqes/zq8GWhpvtS3svmvZ3zOm9GJ+P6J12c+8V 06GO+aQLoUdpfpTmJzqWQE91mKBnO6zQCx323iv8rqAD2oL5/XZH73XTpQ4X9GrHMuiNDrX3Oq8H 3UZdu7v3lul2Rx/0XsfKoM+Y0O7rvdsodKwhXU+6ESo31kKTO7ZA0zu2Q7M6dkInduzpvcvvCoYa 8zv2qxuNqe0hFZ9sxyGVGce1x1SJazBmzG5fpSqNpR1HoRUdJ1SFV4Kr4vURzW1fq6YZC9oH1IzG WR2nRrW246yawevBtSNa3L5JzWmc23GB9BK0nuaLOq5Cl3bcgJo7bkNbOu6NqsMpBAca3U45uMlY 1r5VzWv0OZPVPNqtcKQScqZ/qbwS3GqsbB9USxpjzizSiV/OeT04aKxu36WWN65y5qvlfB7cZax2 FmFe175XrWpc6ywlrRidDzhnQTc5a6FbnXOhg8566C7nIpovVav4vcG9xnntB9Qa44L2w+qcxr1O 86gecJqDBxoPO1vUOcbF7cfU+caG9pP0Ghyk7tH5MacPr8TSflpd2HjSGRrV086YutDY2n5OXfL6 oZ4QaYx0FfRoz1roiZ4B6KmeTdCzPVuhF3oG1SX8rn7f65d6dvWHjM72YdVk9LZfVq2vX+3ZC73R c4CUz2/3HFat/Gp/zBhov6ZKr9/rOaZKrUL7tf5VcTVG2m+q9la55yTpaWgyzZNpnt5zDprVMwyd 2HMZmt9zTbXzu/rXQu9gvqL9vupqLeq5CS3tuQOt6EGF1/sHjKsdOnVZ6ywf11pfQv8m4zpHgqq2 zvWlcm2N0XwctN6XDV3ky4Uu9RVAzb5iaIuvTFX5Xf1bWx2+yv5B4wbjRbWv1e2rVvuMmx2p6kqu 4TzjNsc4dU2rz1cHDfnmqWt4pX9XvD6iOxzZ6nrjbkeuurE15lswqqt8i/G7g3r/3hHd5yhQt7Su 9TWQWkbnA75W6CafE7rV54UO+gLQXb4IdK9vRf+B1gO+1UGz8aCjWN3eeti3rv8w7bZzpHLMtwF6 kiuv9B8zHnGUqXtaT/s2k277cs7r/SeNxx2V6v7Wc74d6n4+7z/dOuzb3X/OOOSoVg+1XsYnD/Xt G51f8x2E3vQdgd7xHYfe9w2ph9p0vjPQBN959RC/t3/YeMZRpx41nnfMU0+0pfou/oOO811RTxgv Ohaop4xXHIvVs23Zvuukt0bnub676lnjdUeDeqGtwM9GtdgvqReMtxwW9VLjOecq0rXQYZpfdg5A rzk3QW86t0LvOAeh95271Ev8ruBhs865N3jMeNfRql41MYdTvWFOcB6AppKOI812HlZv8KvBkybJ 4VVvmyTnMa58bs51ngwmmxRHQL1nLnCeJj33D/Ni5zC0zHkZWum8Bq123lTv8buCp01pjkhQMGU4 VgRlc53zDnSe8z50QacOurgzISibchyrg8nmBlJLZ2rwnCnPsS6Ybm7tHEeaTZobTDfldRZg7uws hno7y6CBzkpex/phc6SzGpUVnXXBy6ZCx4Zglnl15zzous4FwSxTiWOzeopr8Jp5Q+fi4E1TuWMb 1m/ubMAO5Z0WrqgMx+sjWuXYEZxoqnHsxmvb1tkK3UG6u9OJT4bX75j3dXpxetLcNMexL5hvPtgZ II2M6pHOFdDjnauhQ53roGc6N0DPd26GXuzcFrxvvtK5I6TDPgeDRaaczt3QGscR6HzHcbzO6537 oLe4UmXYtNAxFCw13+08+D+V10OwrZ1HgvlNUufxUKppieNMsKJJ6RwKVvB5aJxpSScqJpPjPL2v uF78ct6U1nkFmtF5HZrTeQua13kXWuhi0BKXhPfO771jsjouBmeZ7I4rwdqmcpfyD1rlSgvWmlyO 68G5pmWOW8H6phrnWq6ujFGd48oJ1ptUx93goqb5rjzoQtIlrkKoyVUSyuZMEsptsrrKwSdgg1BB k91V1XulyeWqgS5zzYmf4KFifg6GyppU13w1p6nPtVDN4SdRqLJppWsJP5VcJijOmlB10xqXVS1v Wu+y43zB70uormmjy6Ve4j+3oXlNW1zL1HtN210qdKerL/4zFlrAv7+hxU17XCuD+aY5rjVQfA6h hqb9rvX8M3FthMbf6SHXFuhR1/ZgPZ04l9vK/ApOH975r7VV+tNUe1u1PwNa588Z6c83eZfrv9M2 z5+nbjHu8xdCeZ+537bAX8J7jr8cik4S07Ut9lehezT4a9Sz9JM/3HTCtTNkaTrl2hNqbTrr2h9y Nl1wHQp5my65jvaeb7rqOtF7semG61QogDVnsea260Io0nTPdSm0wiK4roZWW2TXjdA6S7Lrdu91 4zzXPbXGkt4lhDZYsrrk0Gbj4q5kdb5lYld6aJuxoCsrtMNY3DVRzbHkd+UHj1mKuopCuy2lXaWh fXHesFR0VYQOWmZ1zeod4kQROmKp7aoNHbfM7ZrLvwtd9V+e7Jb6rkWkS6GL8NqGLEu7zKEzFnNX S+i8paXLEbpocXS5Q1cs7i5f6LrF1xUK3YozbaPQFQPFxTmKKMUS6loFdiVutMS61kJXdQ2A4vjP xt1GcxfUsrZra5hZBroGw5JlU9eusGLZylcadV17e29ZBrsOhNPi5Gba2HW4d8iyq+sYfseJUS17 u072XmnM6jrde9dyoOscnt7SNYzP4XDXZeixrmtqnuVk100w2GDXHbye0133oefcutBq0213AvYf dqeGMyyX3eNCQ/wTCOdYrrmz4z/b4TzLTXcu9rnjLlDLLffdxeHCZp27LFwSJ8zmBHdluLw51V0d ruK/F+Ga5nHuOlA6WD08J67N2e55cQIPz39AF5IuoaeYSK3Nue4FvVeaC9yLe683F7sbem9xog7b m8vclpG5i3QZ//0KqyOfJHg43Ee6kr+q8JrmSndreE18Trq+udrtVNOa69xe8DCoOLyxeZ47EGfg 8JYHdDtI1a3mNS9wR6CLuXJqDe+Ma3ODe0WcVMN7mi3u1WpJc6t7HRR1VJzuDXFqDVX/XcP7+W99 +BDp0bg2e92bwaIg0vCJ5oB7G8gTXBo+1Rxx71DnN69w74Y63fvAnCfdB8GW/PtyNq7Nq91HwhfM ue7j+O3mnTm5eZ17CKdnrvsM5hvc58OXTDnui/xEcF8JX23e7L4evNm8zX0rfKN5h/tu+Hbzbg8L 32ve55Eiwkhvp+5tWuJRInLzQU8auvEyT0YkOd4Jm494ciLpzcc9eZGs5qHOusjE5jOewkh+nAHM rZ4SnAV0yjSf5307fkY3X/SUR4qar3iqIqXN1/lp23zLU4NTD10rUmEe8syJVDTfdZ6OzDKv88wP ZlmZZ2Eka+Rc3uZZEky2Sh4TZwmPVb1kVTx2fqZ7XOo9a5pnWTDdmuFR8dzznj5+fnnQA605njWo 53nWB9ObSjwbvzwprIWeLZFaa4lnO14bWCKcZi337AwN8XcXmWut8uyJd9rgaWuNZz/2meM5hFMA Z26k3jrfsTuyiJ9TkaXWhZ6jEbN1iedEpMVq8pyKOPjnFnHTPj6r1XM2ErLaPRfgcdDDI7E47XAN NcT1S6pxeCOruMYrkbWkA/w1RDaRbrW6PJeCgnWZ52pQtqqcRjiZhBqsfZ4b8TnOOyjuwlkQGeRd NzJoXem5HeeKyK4RxbsILbCu8dzDeUFzel+D1vVeITjRutErgyjAFZG91i3e5DhF4FWNamTAvM2b HiyybvdmQXd6J8ZPfOwDjRyw7vHmx0/5yGHrfm9RsNR6yFsKRR2Vo96K+CkfOfaAnuTnVOQ06QDp OesJ7yyc3TjBI8PWU95anNQ4xyOXrWe9c4NzrRe89dBL3kU4xeZ7lwYX0Wd+jfTmyCdz1WsOVlhv eFuCtdbbXkew3nrP61Yv2QSvL3KnzeKfE0toa/XP75vf5vQvhHr9S9Q1bQG/SbW2RfxWVWpb4bfH UrHGhaur/cti49rW+VVc3eDvi2W3bfavjOW2bfOvgRva7F+vrmzb4d8YKzCu829R1bbd/u2x4rZ9 /p2xsraD/j2xSpyY+9UtbUf8h6Ir2o77j8aq24b8J2J1cXdgPO4/pe5vO+M/G5vXdt63O7ag7aL/ Qmxx2xX/Jfi4K/6roxx+3X8j1tB2y38b87v+e9HddhYQYha7FJBjrXYlkBxz2tMC6TGvPSOQFQvY cwITY5G4A22dG8iH54o7HfIU9rxAUWxF3OXZC1Fx2UsCpfBcOOtjq1u3Bipiq9sKArNi6+zlgdrY BntVYG6stbWIrzSuDtSry+w1gUWxzXGf9fqhwNIv/WzcY9rnkK+c23qZO76AefTpg4EWKHkl+/yA A44p7nHuw2Mesi/03whXtc4KuLH/koAvts1uCoTgs/AJxHbYrYHYCKustdsDq9QtdldgrXrWviww ENttVwObYvviftDeF9gaO2hfGRiMHeGcEztuXxPYBU8NZx0bIj1jXx/Yi1MDDhrnBTR2nmuQPHXs In9K7Epc7RsDB/COtsBzuezbA4fVZdz/xq7bdwaOjcxvkd7lvLScjXyScK/LpRHFq1qu2PcETi5X 4nPSNPv+wGl1vf1Q4BzcKzzs8gz70cBw3LEuz3lA81qPBS7jEzsRuAY9xZV7zNDiuNrPBm7GfeXy QvuFwB11j/1S4D4UdVSu9uriHnN5yQNazilueRVpTVztN3oT4BzhH5fPsd/uTYVPhItcPt9+r3ec eqpd6M2Gyr256tn25N6CWAP/vixfSLrEuLq3OHa9Pb23TN3fntVbqZ5on9hbjZX5vXXqEpvsDUXu k3eg84h6FzyLLdkbi+ps6d5V0QST5F0bTrNleQf42eHdFE21TeSK+dboOFu+dzCaDd01qkXevdFc W6n3QLTAVoG75Lins83yHo4W22q9x6Jltrnek9FKW733dLTalsX7J+kd2yLvufAN3i2jdaTzzBHv cDDdttR7ObrAZvZeiy42lXtvBodtLd470Qabw3s/aiFt5X0y6hzxVtCo1+bu1kUDcZ9l83UnRCO2 UHdqdIUt1j0uutq2qjs7us62tjsXOtBdEN3Ae2Z0M+k226bu4ugOaFlQsG3trozutg12V0d3x88U 267uuug+297uedGDtgPdC6JHbIe7F0eP2451N4SrqIvKtpPdFtVqO93dGh2ynet2Rs/Yhru90fMm e3cgWGu73B0JzrJd616h7omfUFyjF00qTkPMu1dHfHFya07tXhe9YrvZvSF63cS6N0dv2e50b4ve td3v3hG5byvq3h3NbdF174sWtyR0H+xjLandR/qklnHdx/uUluzuIXVNS653oC/twd1aCrrP9GW0 FHef78tpKeu+2JfXUtn93+x9DXAU15Xu7Z4fjbEYC1kGRZYVWcayLMsEy0TRKopMiMBi/pCJTFis 4ImmZ6anp2c0/4xYIgMZUYrCEsFiQliMWZbl6clESyiWEAVjwmJCFD1FUQjRUjytQlhCsErRw4rC EoLfOad7xCDkmNTuq3pVSZ36Tl/dvn37/pzznduX7uFqolhcuGY0MV9csmY8USZa1txMVIrL4yyx SFwZ1ydqxNXx9IRNFOKZoKV4diJT1YF4XvNlMRafm6gT18WLv7JR3Bifn1gltsbLEnZxS7wy4RK3 xxclZHFXvCYREvfGbYk4zm+iWTxgjycS4sF4XaJNzI0D54uH4/ZEuzJ34rG4K7FDPBGX128RT8dD id1iTzwOuj/enNgnnodLO8SL8baNWfaaODxhiZfiO0Bfje9OdImj8X2JI+J4vAP0zTUViW4Pi3dt GPLo40ea9Z70eHfipCczfjJxxpMdP9Mse/LivYlez9z4QGLAUxwfTAx65vv7N1R6yuJDX6nwVMYv J4ag5DUouSg+lris3MVTE59IXPPY4rfW93vqmvjEmF0vFjVPeFY1GRIT9som42v5HntTVuKWx9WU 08J75Kb8FoMnJK5rMdjrmiA6e+JNJS2wlmsqfW2Fp7mpvCXLk2iqasnxtDVVt+R72ptMLYXu0qba DWOoW0qUp37PjqYVLaWe3U31LeW4emmpwlVKSzXuorSYFI+jHYzN6k7F3d5xQt0roJ2BllrPvqaG rxRhfG9Zgc/gLfVojS0Nyu4Q8cMNT0dsJ9RPKzFPV5P42jl3YZP/tXPq7g3tq3iO+AMtovt6U6TF rzz1e7qb1rZEcK7XL2c8m8ONcf+HMe633ATjuZvc75mW+4DnmJ7X8Xr2AP8gn84e5DP4WWwm/wg/ mz3E5/CPsll8Af8Ee5gv4p9mj/Bv8G+wOZoazVKWrVuie5Hl6EK6MMvVfV/3fZZnBGEfN+YbrSzf WGusZzbjq8YW9opxq/EdttF41jjCvm0cNU6w89Cal5iW/vcDI3uIPcBmsTr2IFvBGtgyJrCvsXr2 t2wLS7B29lO2if2M/YL1sF9yM9jPuXRuJvuAe4h7hOM4/MbJgO9NcnO4VZyby+U83CaumGvltnM1 3E7uDe5l7l+4H3OvaL6l+RYX00a0UW6Ndr12I9ekbdV+jVun3ardyq3XfkP7TW6D9k3tP3IJbZf2 EPdV7VHtd7nN2ne073Dt2ne1P+C20veY27UD2p9y39AOaYe5b2qvaH/N7db+Rvsbbq/2t9rfcf+A b9Fx+3UP6x7m/ofup7rbXIdep5/LndM/pX+KG9c/rZ/H/Vb/KX0F93v8woP7QP85fTWv1S/RW3m9 fpm+njfqv6QX+Fy9Sx/i8/VRfTP/rP6r+i38p/Tt+t38Z/Rv6g/wJvxygl+u79L/iP+8vk/fxwf1 /fpBPqS/qL/I/41+WD/Mr9P/Sn+N/zK+j8Vv0L+vH+c36Sf0t/nWNJY2k9+alpn2CP9m2py0J/h/ TCtM+yR/KO2zaTJ/Mi2cto0fSXs97XVNeto30nZrZqa9ldaleRj/X1XNnLTvpB3T5KZ1p31fk4fv A2kK036WNqhZkHYh7YqmPO3Xab/TLDYUGg5r6gzvP/C45hfG3xt/r8Xv5WTWCjqd5eHXxosOqTAA Slih3FBzQxara5aer54v++WIvLZmWF4vb6qWa9vlo/Jx+VR1t3xW7pPPyRfkYfmKZYalQN5sicnb FpsWi/JOeY+8X+6UD1kKFleDVWnBxsfIxn/LOO4D7gPGg0VnMA2ce4zeRGX8W/xbjOO/xX8Lzh3i v800/Nv820xHb6Lq+R/zP2YG+hLsAf6n/Dk2g95BTae3T2fyv+B/wYz03ulD/G/434B34JulmRpO w03+r8E6jZ7Npi/HsjWzNbPZxzTZmmyWQ2+KPqop0hSxx+irsDxNpaaS5dM3YI9rFmo+ywroq5i5 9M7Gk9D+dC6TRg41855m67ynvT3efu9570XvJe9V76h33HtTZt5xWS+ny5lyNiFPnisXe0fl+XKZ XCkvkmtkm1wnr5LtskuW5ZAcl5vlhNwmt8s75N3yPkKH3CUfkbvlk/IZuVcekAdTxbdCHpIvy9fk sUmZkG/5eJ8hRYy+LF+OLx9yC++Sel8hlC3xlfrK5VtJ8VX5qn0m0Ci1vgZ5zCdCWb+vwRfxrfWt 923ybYY6C33bfDt9e3z7of/cA7LKGvjN+iwak2wQDcsF0bJC9hTTsRKQNPYJEAOrAHmAVYLMYFUg D7JqtpjeLjcD6+B3lw+xv2arWAZbDZIJvCOwh5kIksXCLEJfXK6lby1fozfKv8JygI+2skfZN0Ae Y38Pksf+iR1gH2dvgTzOukAK2HdBnmDfA5nL3gZ5kv0rOw3t6wEpov8N+2k2yP6NFbP/DVLCfgny LPsVyDx2nb0Pbb/B/pM9x26DPM/xXBpbwM0A7qug98c/DdyXwSrp/fEqLo97nL3APcE9wT5H33tW AxvW0hedq9gS7oucnb3INXANzEzvklvo604rJ3Mys3GNXCNbxkW5GKvlvsxtZMuBOzexlcCeX2V/ zX2N28xe4dq5dvZF+rpzNTDpMfYq1811Mwd3kvs+E7gz3A+Yi/sh90Mmcj/iepmH7NcLLFDEZEOx oZg10tt5AcNzhlIWpDfywoYKQwWLGKoMVSxKXxLF6P27NQa74UusyeAwONjfwNxeYRNk+2X4yxLS EUA34CTgDKBXxYCKQcAQ+4LULZ2Uzki90oA0KA1Jl6Vr0pg0AfqWl/caQIzeLG+ON99b6C3xlnrL vVXeaq/JW+td4a33NnhFr98b8a71rvdu8m72bvPu9O7x7gfp9B7yHvUe957ynvX2ec95L3iHvVe8 I97r3hve23KrrJVnyBnybDlXLpCL5HnyArlCXgiyRLbIy+WVIKtlQZbkgByT18kbQbbI2+Vd+D+I 6hp0HgiCXzSupt9XWPzfZt9WkIfIyjPIymeRlT9MVp5FVv4IWflssvJssvIcsvJHycpzycrzyMo/ TlaeT1ZeQFb+BFn5XLLyJ8nKC8nKnyIrf5r1ghSTrT9Dtl5Ctj6PbP0TZOvzydafI1t/nmz9k2Dr PCsj+/4U2fdfcY9xeWD3aNmVZNmfIcuuou8jXiBrXkjW/Fmy5kVkzZ8Da/4y+MBr3GvgA/iVxItk zTVkzSbu77i/A39Am7bQ9xFWsmYbWXMt1wt2vJzr4/rY5w0vG15mdYZVhlXsZYPH4MHvtTPWZ7TB PKXD2D/IuOBqsLtSQDmgClCt5pkAtYAVgHrM086SFgTLvAN/HFRmMHROqghWSguDi7xDdwPzpCXB Gu9lwLXQBYRkCdq8Y38cWEZaHqyTVgZXeSfuAP+WVgft3ltBu8yHhiUh6JINfxxUxhi6IklBWc4K ylIgGCLEgnE5B5Af8lO6MDQil4SuS+uCzdLGYEIuvQP6uzx0Q2oNtslVH4Hq0G3ZFNZKW4LthO3B HdKu4G65VgGmsW/yijugvu4N7pPrg/vwSDgQ7JAbPhpYTjoY7JIOB4/I4t2QjgW7k/WmQjoRPCn7 70A6HTxzPwisju2SeoK9Un9wYFqcDw4iAkJsL0K6GBy6L1wKXpauBq/dg9HgGCIghbdI48GJ+0Eg EDsg3QzeQnhZiCfoQwZEIBY7iMdGf7TTaw81eNNDRm9mKGsqAutih73ZoZyPQmBj7BjVkRfKJ8wN FXqLQyV3YX6o9B6UhcrvQmWo6r6xKFTtrQmZ7oEtVOutC624B6tC9XcB+30fkCPhGV5XSPTKIf+0 gHPy2nCGvD48m8qFQpH7Qjy01tscWn8PsL5NgM3hXG8itOl+IG8LF3jbQpsn0R7aNgk8vxOwJ1xE 6f3heXJneIF3R2gntXcK5EPhCkrvDu35KMhHwwvl4+Eld9WxL7T/LnSEOu8BXnsqbPF2hQ7JZ8PL 6dgXXjldez4UR0JHvd2h4/fgZOiU90zo7D3oDfWlQj4XXp3k9lQuTnLlJMddCAuTHDQcllJ5ZNJO Uuc1OS/JMboSDkyO7Ug4ltom4pJW4BTw/cAWhQMC2xX/Jb/aFcqhuAH2HtgLOBA7kbTnwEE4wn3w vHw9vE6+Ed4o3w63+rThLRhffDPC2zEf++bLCO/yzQ7vRX715YYPIE/6CsIHfUXhwxgDfPPCx5Db qc9g774F4RNJfvZVhE/7FoZ7sN++JeF+HAufJXweuRPrJCwPX/StDF/yrQ5f9QnhUZ8UHvcFwjd9 sQjD8aUYhGMJY+hbB3FSjWe+jRB/1HH2tUI9WyJ6rIPObY+k+3ZFMjHuTMbalDmarBOhxpRkLMA2 YWz07Y1kU9sORPKS80zlkfth7ikuQ8yjvh2MzMU832GI4RUKMF7j+N4FixKXMV5RPIb7JGMxHglg P9S3KTGW7gXwHQs2IzDGJuNqEr4TwXbEZIzEmKnGxtRYeVeMVONkEr7TEAdhjin2QTz09QS7EWS3 GOdOKJjkLICvP1JMx/OR+b6LkTLKB/7wXYpU+q5GFvlGIzW+8YiN8tGHMZag34IfoT/5bkbq/Cyy CrnIr4/YyS+SfqDyItkW1IM8508HblJ9hOYLeAuvT3LgPb41xa8m+SXZfqgDedOfGXHhnPuzI/Lk 9Vge/M2fFwn550bi2G5/caTZPz+SIA7H/kAf/GWRNn9lpJ2u+yj+UdvlX6TyeNLHN6WUUdtMfZ3C x5P9QR5O4sPu9SF86q9Rj7bQIezTJKbyZCpXIj8mOTKVE6Es1YNl8ByMgb8ubAkcjp0OHIv1IHBt g/NN65oTsX7KA87yD0SNgdOx88n1S6AndtGfiJwkHoN1R6A/donWFMBp/q7INX9zpDu5Jgicj10l TsP4j+sG5LqLsVGM0YFLsfHA1dhN/8nIrcDoGhYYX6MP3FyTHmRrMoP6NdnB9DV5tCZT+ZKuxbWZ um6iNU9yjYJ1qXXguWDmmrnIl9iuybVdch02foeDCck1jLr2wLpwPRbMXlOM651g3pr5yeupPPSH /obxIj+BvgXnrimjPFw3JqGuE+/C1LWguva7C+q4Tl3XTQLXYklMXdcl12jTrM2CxQo+cm2Ga6/U 9ReuuZLrrpQ1FraVrsUy6pjc41vgf/5VkR33+JU9sju5xvK7Ivv8cqQDuShZzh+KdKFd++ORI2RP SR7AMuhzYH90bIuc8bdHeim9IzLg3x0ZRKT6m39fZAg5wt8RuUz2eSQyds86BuDvjkwQwB4R5IfI W2eiPB17o4akD6JP+AejWf6haM6k/yEHXY7mE9dcixb6x6Il/oloKcaeJLC/+IxF/gd99t+Kljfy 0SqqG/ij0RCtpn6q5RuNUVNjVrS2MSe6ojE/Wo9c1FgYbWgsiYqNpVF/Y3k0gvGPYiDyE6wJGqui axuro+uRjxtN0U30zAKxsLE2urlxRXRbY310J45XY0N0T6MY3Y/PCY2R6CEcp8a10aNYvnF99Hjj puipxs3Rs7gGRP5PcnPjtmhf487oOQLUh3EGbbtxT/QCjnvj/uhwY2f0CtpZ46HoCHEYzGPj0eh1 Onc8eoPqOBW9jVzeeDambeyLzWg8F8tovBCb3Tgcy228EitoHIkVNV6PzcPxbbwRW0A8hv2/HavA Y0AbW4j2EJgRWxLIiFkCs2PLA7mxlZP2A2twXH8ECmKrA0UxITAvJlG+yrmBBbFAoCIWo/kDPwks jK0LLIltDFhirZO2mnwOSMYoSAeWx7ZgmcDK2HbMYzzjjJuM7Yz95V9Q/oz+BWWEXb/z7wDCBJOd Oc58Z6GzxFnqLHdW1Wmd1U6Tsxb0Cme9MKGIMx/hbHCKwi1FnH5nxLnWud65ybnZuc2507nHud/Z 6TxUt8V51Hm87oTzlPOss89pVGUb4ZzzgjNLlWHnFeeI87rzhvO2S+ua4cpwzXblugpcRa55rgWu CtdC1xInnxQoYXEtd610rXYaFHEJLskVgHIxaiG2CEviObwf3AH3+Wd2gm0v/W/ZB7WCbywDmUX7 oJm0D/ow7YM+Qvugs5nIJDaHySA5tBv6KO2GPka7oR+n3dB82g19nHZDn6Dd0Lm0G/ok7YY+Rbuh RbQb+jTthhbTbugztBtaAj7Xy+axPpDnaDe0lHZDn6fd0E/SbmgZ+xX7NfsUew+kgvZEP017op+h PdEXaE90Ie2Jfpb2RD/H5XF5rJr2RBfTnugS2hN9kfZEa2hPdCntiZpoT9RMe6IW7svca8zGbeA2 sJdoT3Q57Yl+nvZEX6bd0BXg6d9hX+C+y32XraI90VdoT/SLtCf6qrZN+zVmp18abNAe036XCeDX Z5hLe1X7ayaC/07AWHIszprv2KoDeuw477jouOS46hgFGXfchIHXC+lCppAt5JG4BFkICXGhGSQh tAntwg5ht7BP6BC6SOYKxcJ8oUyoJFlEukawga4TVgl2FLQb/hmwm2dVu8mk+6PF8DBHT4H1oK1o YfxLwXrQVvRkK2lgKYvBhnDP/AGwjlVgQ2gfD5J9pNM++UzolxcsCa0hA2xhK9gT2kEmWMEBsCe0 gCz2bZBHyAJmkwXMgfk/DXaL++Efgzn/N7AwnPVHadZzaQ/8MZj5ayyP5jify4A5fpxmt4Dm9Qma 0bncq5ydPUkz+hTMaIAVcTGY0WLa5X6G2wyzWEKz+CzN4jza0/4E9x3uGJvPOEOZoTJlPoq1sxzF U0VYK6x3zHeUJUUodFSqsmiqCJscNQ6bIsJmR52jTtgGOVNE2CnscawCsYO4UIT9dJQdoaQInY74 vSIcohrijmZVEooIRx1tjjbhOOj2e0U45djh2D0p+7CsKh2qdE0VT5fniOOIozsprjHHSVXOTBVP t6M3eS/PSccAyD7ImSLOBY4JxyAI3m8IRSwSjHC8TFeQOEfvrd1xRlxCNZxJjqzjmiKeM44xx5in A/TEveLphf7dmhSbwE+KQZFpRuqs0CcYhaxJOSfkkFy4MxJJEYaFfKEwKTTjV4SSKTICuC6UkpSD 3FDzbzu1oKsme2RzNDtnCNX3ijNDMDlnC7XCChRnrlCviLNA8ENOg9DgLBIaUuqZFOc8xzVBnBS/ EEmKMvqOIZgRsG9nBdlujXOhcwnamNOCI+FcjvbhXAmp1dTbEqfglKhFEvVVqQktZYBmqdcz6Bki a7hMo3+NRnrEGQDfmQ/jV+aodMYcHc51MMpG50ZoX6tzC9iy3bkd7D3u3CXwzr1gy+0Nrc4DQjnc dwvYSQLKHnQedh5z3HKecJ529kCL0f7bnf3USzvM2FlHwnkeSticF52XoC70WuoRlVR8BWc34ahz XoX2j0KfxyG/DcqVgde1OW9Car5ztYs5Kl16V7or05XtynPNJV+uU8RV7JqP/uoqc1WCLHLVgLfK ise6bK46uhvcybXKkXDZ0SddUDOUlF0hV9zV7Eo4drjaVP9DD+xwtbtksDUj2VsOnN0hmIRy124h x7XP1eHqEupdR2B+YbacW1zdrpOuMzByJUI1tGmH0OfqdQ1A6UGQIaHU1U0WiL2kucJyIGAxOEqu y4BrQjX4cLtrAvIjrltu3jXkNrjh3u4sd447313oLoGxltylaO/ucneVu9ptcteijcPI0py7VziL wNrK3fUu2d0AIrr9QhUKnIu4S91roQcmYQWcWS/UuzehnYJucG92b3PvdO9xzXXvd1xzdwqi+xDY ox/75j7qPg73bAALjWD/PGOOI54JUQBmOOm5BfMzBP2pBntpl3jJACzQIRmBKc64drhHpCxHtqO7 ocddK+VI+ejXYDMwWlKhVCKVujqkcqkKLBSZYwLYDEenw9Pt6VZKONrFfqka6kK+IwumkgrLgAVD XQOSybFDqnV0SSscZwQeynVDe8akekgdcddLDY6Tzgp3qVghiZJfihALqkwmrfUQs7rLPQOeAWm9 tAl47rLCddJmaRvdDe4k7XRck/Ygm4Eek/ZI+6VO6ZA4WwJGd9crzEXcZfBck45Lm4V66RS2xH0K 5gltp9591t2H9qOIcwu0+4z7HHKS+wLM8bBQC7NzBeyqBPigxD0CY73ffV2oct9w33bYRK0IvOO4 LGaIsxt6GnrEXJjB/WA3Y464WCAWifPEBWKFuFBocA3huDuOCOXiEtHiGBOXiytdl8XV4D1tQDCS 4If7D0F8vCIuBA82Amc1wJmAGBPXCTniRrFV3CJudzQLBnGXuFc84BgQD4qHxWOCUTwBtRrF02KP YxBqHhL7oU1GaMt58aJ4Sbwqjorj0MZeqNvgGIOSNz3Mo3e0edKBbTLBl2xgN9lwTQnYSrknD+x3 xDPX0SUWuUfcI84t7mHHkGvAU+yZ75kL48B7yjyVnkWuXk+Nx+ap86zy2D0uT41ggqPsmvCEPHEo 3Sxucfd5Ep42IeJp9+zw7PbsE7d4OpwCraae/csT5p/RE6bIAvRWw2z832TsHYz7Es+y7PtBOkEO gRwFOW4/vgrEfsp+6tXBVwftZ0H67H2Udw7kAgjmDYNcAYHrVo6uHLWPgFy34zMsb7QZl8E9MuiJ htETDU/PMhpa82rpWUZHTzF6WvOm0VOMgZ5iHqAnlwfpySWd1rxGWvM+RGveDHpmmUVPKw8zLkPI 8FOf6L1D+wLG2S1wrIDjcu2smgP2JfcDkwmOBwGHPwTHFJjqFdScuE+cBvRMg34Fpggcz98fTOvh eFHFJRVXFSwdUo6mnYA9kB4FjN8LUyccb340TEcBx6FepkIPSL8b1LcpWJo5Bdl/AvIAc6dB8TT1 IuZPQdn9wQbjvrQSsOhDUKPAdl7BUtt9og6wahrYFdhg3pa67g82mNulsoqQirgC21XlaB2G4wCg GZC4FzawgaVtHw3buFpHu4odgN1TsG8adExB15+AI4DuaXAScGYa9E7BwP3BdAWOg3byj2kB50wj gOtqucv3iWuAsWkwqNZ5G44T9wezFo637sDE38FkmQz1OBuQC+cMd+6VCnOBen/jR8NcBJh39/Wm rCnImQZ47QI45sOxQj0unL49HwZTIaBkGpQCyqdB1d0wL0nh71S+TfKlymNmi32SX8zL7XfzR9JO UudVHe/JMVqZMrar727TJKekckDSh1XfwpiRtPll2VNsekI5bxYAEiCgcATGF/M6JR/7ZN4IaFX4 1Y7zBTxp3g7YpcQA816V328q9m6GMUnysxlimvmw0l/zMXUcoE7kS6yTgPXCfJqBF80wdmZogxnr vaqOrzqeeC3FyWQMu5QyzlCPhSl14DkLxAtLutquqfM0ZY4mY0pynlqV2GjJVNpmyU65/qbSF/r7 sBr74G9Lnpp3MAXHpsHUuNw/Dc6nxNeUGDuJ0RRMia+T8fK/Eifz7HfHwmL7nRiYEu8mOQtgWaQe IW5ZbKqPAX9YICZZIAZZIP5YXGo++DDGD/LbJYo/WSDOWEIKF1niql+ofpDkRbQtrAd5jvgp6SOt Cm/h9ZMcONW3pvhVkl8mfatVbX9CnfO2O9dTefA3C8Qmyw6l3RaISRaMQUMqJ2EfIAZZutTrPoqD pvL4dGWSbZ6GjyfPGe7gQ7nuo/g0/27cw5OpXFmawpEpfEhl89Uy5coYIEcvA/tZVqwA1zY437im WTZfzQNbsVZDGnlMXb8sg7WRZULlMZjTZWhbCYXPrDj2OF7qmmBZjcplGP93qDyH9gcxehnUtwzq s0J7l4HdLIP6loGdLcM6wcaWNav8meTLLnVtllw3he7wKNWl1kFtTCh8Se2aysNTOHhyDZPkYewn 1oXnwKaWtadc36b2p0wZL1pzQd+W7VDzKlNQMw2mrgXt00Ad16nrukk0p2Dqui65RvuvrM2O2O9e f52031l3pa6x7Oq13SljMtW3wP8svfZ7/MoyYJ9cY1nQr4cULprkq8uKXVuuqfaUzMcyE6r94RF4 xar6nRV8zGpUkOpv1iyFI6w5in1aC6dZxwCsJSpKFRAPYv3l6rHqjg+iT1gh1llrU/wPyllXKP5m hRhtbQCISuxJgvioUxkn7LPVD4iodUM/rGvVfqrlrfBMZ90E2AzYZicusu4EwDOcdT+gU4l/COJJ WBNYDwGOKnxsPa7YKcZC6ynAWUCfOl7nABeU5wTrFWWcrCNKeSvEDusNwG1lDYj8n+RmG8QA2wwF WB/FGbBtW4Yy7jZYg9pyFTuzFSjjiPNoK1LPzVPrWKBwuQ3WiDZYH9qQe2A9ZoN1mA3WVTZYT9kE ZXxtkspj0H9bQD3GFHuwwVrIBmsgG8QI25Y79oPcjesBG6yFbLAWsu1V81XOtcF6wHZQqR/9xAZj ZIM1gO1Eiq0mnwOSMQrSttNKGVuPkodvY8w8NfPdv7yN8ee0V6Yt1p7Gf1Hle9g/M5aWDygElABK AeWAqpRjNcAEqAWsANQDGgAiwA+IANYC1gM2ATYDtgF2AvYA9gM6VRwCHAUcB5wCnAX0Ac4BLgCG AVfUe458yPE64IYKLH+bMYNWyTfMAGSobRtRj9AHw2xALqBAyZ88FgHmKW01LLjTZ0MFYCFgCcCi 1GNYrtzPsBKwGiCo+RIgAIgp9RrWATYCWgFbANsBuwB7AQcAB9Xj4ZRjsvwxwAn1uFe97kTK+dOA HkA/4DzgIuDSnSOOj+EqYPRPOCbHYlwZxz8VNAepqFWA9dN8Datlr07BTeW/nU8ek9cn631AD0hX 5xvyH8i8c3wgG5DH/tlcY7aZ68yrzHaziyCbQ+a4udmcMLeZ2807zLvN+8wd5i7zEXO3+aT5jLnX PAAyaB4yXzZfM4+ZJ8y3LLzFYDFasiw5hHxLIf1dAlJqKQdUWaotJkutZYW53VJv7rA0WESLnxCx rLWst2yybLZss+y07LHst3RaDsHfRy3HLacsZy19lnOWC5ZhyxXLiOW65YbltlVrnWHNsM625loL rEXWedYF1grrQusSqwXPQ/5y60rraqtglawBa8y6zrqR0GrdYt0+LXZZ91oPmGXrQVUOg0yXPgZy wnra2gPpflXOWy8SLoFcBRm1jltv2phNT0i3ZUJM+Ni0v7jA1F9cMNAvLsygX1xIp19cMNIvLmTQ Ly5k0i8uZNEvLsymX1yYQ7+18DFjvvE59qjxeWM1e9boMIrsBaNsDLLFxoixiZmNzcbX2EvGhLGF fd641fg99rLxbeMJtt541vge20i/vnDg/+OWcVwmF6D3Vbrxf5MvKFUBzFJQpaJahSkljQCvKVih prFcvZpuUCGqANYtANYtANYtANYt2KSW3ayWx7xtKX/vVI97VOxPuWen+vch9oypB6TfdN500XQJ 5CrpS6ZRkHHTTTMz683piph6zJnmbHOeeS7kFkN+nnm+ucx0yVxpXgQ+SV5pGge/tJntMFcP0S9t MPqNDZ5+Y0NjLDWWMq1xsXEJ0xmXGq0sjX5vI934qrEB5sFj9LLHjCFjmOUb1xq/zAqMG41fYYXG 48bjrMj4jvEd9rRxxDjCiv8f187dfkX7OdCrwDq42w9Segaln6P0c5R+XlsDeoEuQvkNlP8NSm8G Xar7NqVrKK1c+xyla+naT4CeR/kLtH6qB68tpfrrtc+j1r2C7z7p1kI6S7sItS4K+jCVeRPv+wdK /+FtasNGyvdS+nlKP0/pBUprVb2WdJDKQJ1/+IX2GdDDao+eobOvUKuop9q/on55qOUipjWDlDbQ WUZX/U/K8dG1Zsp5iNIv0LVrqLaHqCUvkNZRmTIq4wI9n9LzKV2qraB8idJlVAPlk36ezpbS2U9p P41a56WWVFBJTD+vuU5llHHYTLUdp9pwLj6h7aB8RZeTXk5lBKrzKNUJo8G/hHfkn9XZQbfowLv5 GKVfID2oC4FuxjIcT/p1Kk/t5BlqjYtKvq5zgD5Adc7CHO7nmObep7NbqfxiKv91SmdRbe+THqby N7U/gnxe+y7o5dpzeBdMc7+hHJf256ArsQybQM2ZSP8n6bdRazRUcinV8zKW535JNXRQ+lt09kUq /wGVL6b0FdKnSP8LlX9P2wglLbp/hfQNtFter3sH0rcxn2vQ9YC+pAVL4HOwDHtPtwH0b1FzV9Qc 0JpSqieHdC5d6yS9lfQc7Qd09kuQ/jFq/iKlj5PuJ/26th7nSP8e6aOkO0m3kh5FnZYN91qgzCCV bNHjb6g0UPoF0jNV3Um6lTReO4dKnqazhyhnkHKaKWevMu+YBn2UdCfpVtKjpLH8Uiq5jq5iitZ9 E62C0q9Tyw9Qupv0ATWnk3Qr6VHS1dCXk7pWsiIRNd3956Tfp2u3qvoo6U7SraSxhq00Gl/HMpqd pL9ObX6f9DDVM4xt5t7T9YIeJ/2e7g3SAdKvkiZL0I1ADXNovm5QyWHS11S9gWzgFNoG5dymGm5T DbephttkFZfo7CXKuaTmdIPWUF8e150mm+klHSD9KumfoCZLGFZsDNNgaVjbTyj9HqzpsQ2Qw1eo GvrC/wCtlM+lnFzKySXvzsWaQb9Lupss8yD0ca1in1RzO+mt6rXoF2Gy+Tn4P3HDvd4gHSD9Kul3 SY+Qxjov0rUXaTT6qbZ+Sr9O6TdVjaPXQ+18KQ1rm6loxdIofUDRuu/RzAZoHvHs+5R+T/8ZHGFF Y6sY5cAzLeocyu+nme2nnMPkI4Wk84mFniN+a9EXgX6N8n9FXDRO6W0YQbj/IE6bqfAhluRm6Nyg HyY2S5CeQ6PRRWVKyBd+RumXSHeoHAjxhaP6+TTU+p/g7Ou/hqOhIy7V2nFM9McwrS/BtOYq2XYH 2UkpWW8vXXVMdxiv1XZRq/CspPC5HpnzGdTgm+fIp86RH6F3PEnprXT2P9Q+hqk9Lrr2LSr/Fo0z MYzuKo4PauBq1Mp8PauH+MjHqPxMSp+m8s0qe3QSD7RidCAfdFH+66RnkX6S7vJz0h+k1eBsph2k ++LZxTjL4LmYzlI11vlJlZP3QDqbbPInlJNP+oL+UZxf4ts3yZ6/QLx9BFlUN0A22Y8ldUVkewbM gblDG85CPud6FS+GZ2WICDQvAzjCwAPdZGPd5JWKfpf8pZv0uxRBkKtz8FoYz3foqg3kQRvIDvEu UWyVZime1SxVWEULaxXuMfLxRXTVMf3viB+wfDm2FiwZc66gp4OF/wwjC7W8VOWfDVQS77Kf9FbS p/RPYVr/t+S5yzDKkOdepLPHVa14KKbr9M/Q2RHKGaH24wiX6X+CXEetfQOjIfe/KCbmUGv/QPnf pjF/jNL51JdLuFLia7VYf5/WCPoqrh75j6GG+dpArIKztov6uAd9TfMcxcGnUWvytZDD/5Bq/nsq +T7V/O+U/ndKv0j19+LIg8aaTdRmP2p2iNLXSH9BN4PhugLr/zTNVDHV0KfEX1xHwTrhS8R+aOFt tHq5ppWoF2hvT9DZXf+XtXOB86laH/7aa+29Z2Is0hDj0pjcr2MMIbk1zLgkREm6uCahyT05SCoc iVJJSFJJ6EaRSxJDEpKIynHKUUc1xCRH/OZdz3f/zueTef+f93Te9/306TvPftaznnV71rP32r/f DHr+GW1txFuKjNT/XGYjYE7831jfMXJ/N2XFm/lCZP9a5PaMN59R/Eau+I2dmEI/yfZ6g/TQZDL2 y+K9lZ6kIdf13bOrt51Rv+e7p0GvNX3bQV2iXTf3h8oep1YPeQbWPczPjnP9ds5zS9ZxtT9A4lM/ 7+T9ePs+TvH2An4a4zPD9x2/E7qoq6TkqczNgElgHl6l1gg4mxj4wZfZW4WHmvBZ/HRBHs3YFzLP bRnjEGp9D7+G98iMuacsGcUUeWp18mUSFdyDhuGtH/3sgZ8weEYyQDwaZXTr6c/5sKowOAO/gBvR p8GOkhOiZ06x1OmweXCQ+4jI7aOnUPx8BrfjZzt+tuPnK+wHYT9INDoXTQs0XaKnVpHVWemJ4xdw I/o0ZLEvET3Z0srGiDxHdcBPB6mreyL3jGTx47gRfRqshKYi8cPzBj6/w1sBXAZXwhW+3AGz8ZmN z2x8ZuMzG5/ZzFK2eDa1xdLUZga24GEL8hrkNTIKN6uL6L/wnWi8Iru+LcLPImqdwYNomtLP3+Lc yc6SPnQPGrBbZXUe8uVpc3P8dCCtbPMPsGc5HYilip7kj/FsX55TQA78GG/l8X8WHoArqNsLtqfu WvTfw12+i9IwTcYVLhf6Q8TG3x2sczudtsIRgdyn+jBXuczAv7C3MqvhcvZ1Q3r7GXHyHZwdP6cc ZHXyiMmDrNpBZob4lF3mZqC6rFRwpeMCzkQay8pYfoY8ldZbRPHGWrwmGmNYKYO+A/bfwd/gMpjH k/yy8DitiKZQ1sWtr8jH42StkddGkSMaFwkdWcGOrLg7R6up5nN3ruwSFBeG7tx6cY/sxIt7ArfK 5nmelHbKnPjN5L7jDxTZvAWfQr9Mnsf8F8iK2LtnY3kuuoq6nXguuhfLD+W86W+XLG04P5qecl72 S1H6DrVeFiZUQF8WDxfgCuzvIk4mylqYNTK35ghyNmwk9FNljfw0YmMa9h8QUYeEwVJsGhEVKWJp prOyPyMPobQWpeWIliw8RGfVFTCHtlrxVPACd8D2MmPmO+4g08iNW7lr5MnziVnME+ks7kFLeD6c gOYRnmry8bMJ7odfwEP4OQZ3w7Hcmw5xn10rDD5EngjXkV3Pcg96TJ7f/Do8xR2Ky+/C5XAazJdS OXkFJ5j/DlgmwWbhrY7RiYwTolkX53I4DYqHt7AcR601onEUTVfRBHcQFX141h0LO8FcngxH8PzZ njMpT7B+deJnPW1haaZJLvXROMoofsBztTjfhcvhNOi8BbXkTBp+QMxsD8q6WsXxthj2h5xP/WTG /gDyu3G+C5fDaZTKuB6QufI3ipxQKXwO9hL/1PLjlPnhjGBWyDyYVjz1TYhzIcyFd0JiSZ7cwmKs ++1YtpfcGFQLtjv5ZPCh43PoD8SZC++E22ADiTdK89DkoZkuz7rmDdmh3l94lq4Mr4NjebZM5RzU jGfXujwVzyKixhKxs+Q5ULfH8zvID3B6XU3fvkH/jfjxO9H/I6LxK8S5EObCO6HsrxrSK/8qOcOG r0YxLztCH8NbcbiYJ4TJ7KNknh/uJ/4XUHoozoUwF94Jt2Hj5tOvIq0EH8p7RUexWUetdcjJzMBZ ZulwsJy9UFlKI3JiPS4nVv8H0QQbpSf+u8gnkX3ixMd+QvAjqxBRTq975PTqZkOiYrc/mb5JxCrk dfR8HaVRFm0JiwfJjkrWKygfdnPyEtEHVYjkb+AD8VwqmWcDuXQONjOwf40d9zP7qDgZtSkZeD7y esnALq5crWAz65KHT06v5kk8D8NbHeR35fzrTrhSmovlBmHiRonwRMVp61k8884kIcr2n3C6mcYO PcEOWsPuaAw5HZuVeHgVb8p/xNXagJ/3pG8+76l8TsRuLeQeOpCz8EiRnYd8uJ99nQ/3s1vz4X56 +46TH6fFtczSBXkGMM+TnbZDn76tlzOy/xIcJTS8OTE7w0flfscunoO8BvsXqPs4O32aaMLBkg3C e9F/iP1R2BMuDs8KE3rLnQ6blyVyEiogl4WN8HYB+7n0uZjcHfzS8p7KbxCkED8ia+lb8JOsvl+a vTMhOm8SDyuCHRInove/i5+p5Y3lcs44zdjX2XKPSMhh7b5gpa4VOSwWlHCl57hnrZMTsYteyQlZ UpqQw51lsewml6/eh9vIS+9DuYd25D1SHfRH0B9BfxL9MfSH0PfB2ze0Ep28JnBn3A/XSbvBURlR yPtY8zYn7iXc4+aJvf5Iztcuy93JDP9GnyUvNZOzdliCXZ/P7t4kdDO5izzTgJ4Id1NanOei4vLk 4/LhRfbCQjKGlE6E0+LZQ2odJG98IOduZzMf/Xz6T74KJzn5Xfrczq/g+KLQT2X+32SkX7E6Y7C5 JW4pmsqcgz6WMfqXyxnZ8FbZRKe2Lzm17SAnP8g8VGTd63Eue45oKRe4XBQmUus3nhDekPN4MMR3 Jwt/Fjl2OHWHU3cm8jJpS19Di/1Ylxc49Q9gRI9xwt3PjvDRPC6ncr8O/bwN+1O0SK+CqcgT5Gxu 7kOObIbhoQm8XZ6X3HOj7Mp1/pVyX6CH3xPn0Wm6DZGQzdgbmA1uXL3FTzgKjhf6i/2VZE7ZEdeL HIwLxtErmc8e2ESfd2wkmwVSakbKXSzw8FOK+V9HD1+Wc7c5jHxSTuumIXK2nNbN64ylpPQkYAf5 t/jlnWYR/Z9sTjpOMi4S/BPyKU/4Es+EfeW07kYn/akgZ3YzA58j45Q5LAFvkXN6sA7eKucI87uM PSzLDHTkDP4tte6Sc7opg7yJ0gL68096+Db6X/gsI1VmJqxJ6y3hnYx3KGwSf7aUu2p5au2Sk7v+ XE7u5jHmpzzvD4/Sw76wI6sznXXsJKvmotdRr0RTkX7O5xQzB7aKZE4oc9hrczjpzJFTlSt1J5Gg Bk/Um7F8GK4JHiEfimxhp4h46ISHTnjIxjKfs14d0fh10BxEM993K+5RV1eFj3Jevonz8k2cwppx vntOzkouEpy9HozlIVosy/NnPbzVk7p+FvJDEdE8JN4cN6JPg5W4s7uZCT5jdEN8dyo0C/DZDP/R 6FrCB+Xs6frPKPBZB591GGk+I82XufJvEc9hVrAPPixRhIc3IzI//ZBzmIdWYWfmSngj5/fDcn53 o+gs7778z2i3MzvoKzycwVtnuVtJr1zmET7vV3O8w5/i9OPIqJyX3flaSqfDimha+lOdnOtL3+qh Id/6lViLn+EvQrNTGOwW+vXgQ1I3qE8rZfDZATaHS/E2LZorPJyENZnhB+AwyXgJ22UGErswn+c4 993LW/phIieE3PX6SmlQgxneiWUW8kCRE7aLt8Qu8mQSxDgPNmNcUWw0ZZWzWJcFyMl4aIHN6/J+ wNwl8++nsApvEhtV5C5mjsvozErkUsgTsTkC61ErDSazmmWlbrBEVjxYir4Rlq+yytNF1j+jaRY2 gXMl3rAsL6vp4uQRcqBwLz5XIFejz8nM4YOid5bn6O05diif1Be+pjxlCj9GXimfZcOMwleRa8Fp 8il5vPQ1uAT78cgRy8E56KO6q5BX4W0F/AbNN8hfYuP0uluhvBGtBx+BY2Ar+CWcKPS0UBWgyYBK aAYhPw1fgZfHZfnU4CB1z6CZA9tR6wnkZEqPwvNoaEV3R3MSOfLfgtbPwkOU/gtuxJvBpgPsif67 uCx9WIZmJZps5EJq1UY+DrfANfBHLDsjn0MOkWOwHPw2VlueDOkP9upX0ZhoZirCFNF4jNq7Be5B /zXyBrgXm2j2usXaOA+Z0VqIrFvBRXBxtArIGVDBp+ErMXk63RzNv2i8N+AZSj/F87xodMhXRjOP TQybKtFY0BylV8eRP4uPpQ3jSnR1x1N3gmgU8+NNwjIj1oVRzKfn8+ntfPomnIPmDPwRTRWhiuSK MAUeo8XqMBU2hN/TVhSBTyL/A6bE2jr2QL6ClZ0axaTo9SrkujE5fX+B3Bw9UaEThCGRFo4V+uvw cFFmIBwmcrCTtX4lmpnC5+XTRuz/GsUG3p6kD79h8y/mqpvsSrenyhH/wtnRKl88LTuOkY6JU8NU xythKziR0ol4mygaN5+ib48+A6o4U+W+gPx0nGLZhdk+GJ/5VFZhERS5nejNE5QWUKsxPYwivIAR Mf/e4WhFGOkLUTwjD8BmNbO0L8oeMlf+fmYs2r/JyBWZmS3Yb4m1lrdSyGPwMxp5odCwi00HIvAc 8zaHUlbTq4T+R5lD7wJ9Dpm9FEaUyCzFhC6uIlnGyFx5f4VRHPaNM5W6i/Aj9nvwuY/S1yDzqU4x 6hNwIfy08ArHi4yxGJq3kCshp7JqXZF30/MfKC0vsssYy5ymNaUj4XxKFzEDRLtpiBzt9BSZMV0L fbQjPobP43kgHgbi+UB8lkSOMtsu9vVWduv3rAJZxfOZ+WvxE2XC3fCfhY1kJpF3RjkQyxlYXh3l QFr5DD27z5/M3tmO/FthtutndB9ZQrb5QubKvxa5Pfp8/PyGTCbUl8E6MC3as9hsh+/Fs1NjR+4U 3g5sVkc7GpIB9FxmqSU2+2GUN4hbzX3Bzao7Uxj2vvcqHAGjXFETPgtHox+F3BYOIQIfQP9a/F4g 8TwlLssMRPeOPtiTQ3S/6J7CaobMfzk4B+6BGyD53HuL9SpEXg/PU3dvtF7IzKR3EnkQ7MIsnUUu QelG5A6wZ+ys9BD9d/icDVfCFfH9G7Ulkb+dyD/LjugJs9FvQW6K/UN4477jbaP1GLHBndEjk5vy WG4kWpC9s2TjA8gr0PdCjvIqqx8uJ6JKwYfJMDyfhJXxFmWknvR2TeEC+YwJD4WxvzJeRy8PnicP dyeTrIR3YHmePJzEWKL7VHI8r6YS25IZWqBpwey1IKucRV+CedgYp+Reg2WHOMXDMkpXxpnKfWco c5hKPyUvpVK6C66hblfeMRbwDr8ibxorhu84y6T4t2vk2ylN+U7ORd4t15JvOXp7hHo5n/9u4+zJ GyrvH758M2czJzI+bdFZYXHZ6XyCs1tk/SHyaf9Lzqp85iXP56q3ri7rIm8kTG3/Hmndf0meMUTW +f4vEo1Cc9p/Rcn7JWepvhZ6g6mVIwyW804jhPX9CbI38bDMd8+9pg8eLkhp2INa3WEm3084BxP9 FFlx86DMmNkqNiLryfIbLnqo0OSaI3hzlmqH0EuLaqHZJ/R/ErpRCJeYx2UU+MmStwo6L/JDaS9h MAUP5+AROAO+beR9Tm2h3mDkdJ8q53p9Dk3poDf9lG+RJYlG7RNZfS109iLvEPugBX5SqZVu5Pt7 1c08WX2zhL6tkHfa1HobNkdTU+yDTdQ6Fu+JlPZCs8iMl2yDvmWc8j0iP+5ticwSfXtXZO8o/THa EwYF8ldvkLXWovE2USrfQG7kfcs3ZuVbbV31DMd68tZFb9BPSNbVj0nP9cuyr0XWj+pHHSdq+XRb i703B3YXmnuxeVrzXUc927GBme74FnJd8yp+nOydwZK6uh11n0C+Am9nJEq9v9H6eX2F7GUtUdFL l6OfpST+NZ/y69Bp2uiSspd1DdnLYu91gd2E6lehMXjIwVtPXV5ypt6DT5HP6u/kroG8AsvOeIhR 9yrk4/BDT2Z4NX044V3tLOt78obT5UWnueDJp8wXvQK5F+h0yat6Mp/ay1+W/dE7Kv0Rem10WdHo tXLn8v4h91xYEdYXOm+O6jvk2bC0dwTLI7LTkb/2xsvdBJ97vKWOc72v5H4kPVHf4+FX6Ym+oJR8 C90/JQyTkf+OXIJvpxdHvgb9G2icH//F0Pn0e8Ms+JPQ/ABXCoMk9BeE2oePo6mJze3C8CCWtWFn StOQ+yH3wvI4GvT+DGFCZeQalH4AC9DQivkEeSDyZNgVzRQ4TujRW92S0o+Rj9KfEJs5cDml25Df Qv4Z3ghvRc+IzEXqRt52wYfhPfALLDORGZf5nRbvR95Kfw7AE2hewtsAajXFcif6KsirkBcyJ2uR x8IXYC1qvZjg7j5hhWh1RPZ/goXRGokcJKG5gNw6WiM0T0YrJbK5HfaDuXi7I1ovaiVEq4bMnIQn o1XDfiU8TmmaMKEymg/oWwMsZ8Ih0fzQ+vX0cHM0J6Jx90SRoxljnv0lsAUtMtveL5Qyk3oDHoi6 YC7Mw34x3AdvgIzajyJtIf2ciH01PDDngaUPxI+uTuxdhv0xbF5HboVlFGNtoRUmvi51E8vQT4NN Nh7eg8noKzDqmszMTuyfppQ94u+nVlXaYm7N3GjfMYcHqcvc+jNgDfy8g006/plP3Ya6q9Gzy4Io VgfTVrQTK0exh59PkbHU06n1IzZPwShCmD0zIopk2q3CXK0Ser+geZ62ojhsDK+F3ai7F7kRHjLg 9/Bf6B+lrf7IN+GHcQW0HjTBchZ+5iEz85r84C+FY2BPbKIWP4dRhKyn9F7IupjytHgfZOYT0Phn aHE8+iinsQf9aHezc4OSaEpDMoMhKgzedJSpyCr6FPbU9UfB1+Ay9FFuRDZ70GxHPkLrxJVh7+jT 1CLqgmg3RSPaiE0x7BegidZ9E/ruMAXSZ0PODKfhM+oVUeF/BdlTPrHh0fNwErUexP48MjvRnwC/ RM+aGuY/6IOeHOWTtXziQZPV/UHwfewLiJnJxE+Ur5ZDclHAPjIPo4kyZz51ozVl3Q0rFRJL5jbI XjOzIdGbsFuYSFQE3L8Coj1kthMYe0ipj70hR5lm8EZpXSk5g/gvxuTTot4wC/4kND/AlcIgCf0F ofbh42hqYnO7MDyIZW3YmdI05H7IvbA8jga9P0OYUBm5BqUfwAI0tGI+QR6IPBl2RTMFjhN69Fa3 pPRj5KP0J8RmDlxO6Tbkt5B/hjfCW9EzInORupG3XfBheA/8AstMZMZlfqfF+5G30p8D8ASal/A2 gFpNsdyJvgryKuSFzMla5LHwBViLuhWoW4hNa+QnKc1FvgN9AmQs4UnYgNKZcAi8nlqbabciPYx6 znj9JbAFdRm19wuljEhvoC6rH8yFedgvhvvgDTDqYbTi0bgmwmp4YOyBxSfrqKsTA5dhfwyb15Fb YRmtdVtIrURKE8vQT4NNNh7eg8mUPo1MZPr7samKZ2bG0H/zDqXp+GFmdBv0q9ETvUEUA4PxFkV4 FKufosdGT0fzI6VPQVZHMw9mBHweb9E6NobXwm6U7kVuRK0M+D38F/pH8dkf+Sb80POAVoImWM7C zzxk5kqzs/ylcAzsiU3U4ucwWtP1lN4LmUlTnhbvg8xeAhr/DC2ORx9lA6LXj/YFMR+URFMasqcM 62jwpqM9zn7Up7Cnrj8KvgaXoY+yCrLZg2Y78hFaJxIMEa5PU4s4CaKYj0a0EZti2C9AE63sJvTd YQqkz4ZsE07DZ9Qr1t3/CrILfFbfo+fhJGo9iP15ZPaOPwF+iZ41Ncx/0Ac9u9snEjSZ0B8E38eG qPajTJKPHK0Uq2mY/5AIMbdBYt7MhsRewm7in7UOyOcBsRoyhwmMKKTUx96QH0wzofpKH1LyVmS3 K60avccws5wmh3P3IHnbYJbwJqEDpYvkd2NNqnw/zczjXYoWjf4n+lmily9YKPltC9H0EQb7hH59 9AXUzaX0B2E4AnkQzMFbfmRJu73ibzOqKnlHIWfDRWgeib/xqM/v1slblI68PznP+5Bk3o2sQL9U 6uq9aAZR+gyyxkM+HAOXMfYkoZ7MDPSQNyQ6j7cWmciZ5j2pKzaqkPcVV8Tfnziqv4tNkIGf7tTK 4g1Jc9F4V/gLnL5s/N3ICt6BrOB9iGPsyUJ5T9W1cLfkXuRecrbVe0X22iH3pjQLeSPyl1hOQE5E bk7pR9Q6gaZ05A3NtzE56dfFpjS10mE/Sg9EpDQF+Tylz+GhKvqX0TdBrk1piHw38mNRH0T2DkV9 oHScyLHuhWddJFRH87Yq73gYeZHIpiRn+UKhaQlPozmPPA/LvwmDfULfQ6/hCkoThV4Bcj5Mx15h MwvWhlMpHUMf5iL3Q15Giz9iMx55B6VD8VMM/1vg0njPpSdD0KxFswHOgIzU5FBq0UyOredfYRfP m2LyJjAVz8PjfRD917JGpqVQfU3dVXA23njjoY+h6SE2fvWYfFetFaVtYq86xlRnpy+FTUPR6FNR n/G8RPoQVkKzUWRvNvrusbckPsXe30rpASl1Y5fVScJzd/Tl8PkE/a9QeN71cwq9/ZW+HZZaQS5j OY5+MVE3UWp5TWhrPHIaftJjF/gE4YLMJ5whdE9TwqNoKmJzHLm00FxPrzJZtTzaGofnQfTwqDD0 mduaUYQU9pSoExtdWjTy93dchmSX+aVkLGE57I+LHLTHJglN7ygOme2KtJLEzJSWGfMeZdS9YvJu dig9XIZcLHaLxFhM3nZeAbvQeh6z0Q65n1h6BdRKRz6LZR4eZiPPRH+A2diFvjqaM5TOQXMYb3PQ tMLypNBlHNYrikP635mx/J0+HCUSokieK6N2p4AjzBLrDiezUgXYx/BQn7aaU5pO/BxF31To8rus S4e4jfAYMbAPz3uj+Y/PhvQ8i7EcZa7Koi8Be2E5NN7uBfbFBWLvNJEQWcq8VRbZxfZpIlls7oCz 0dyCZQptpWC5m1p52MyHayntEt+/GW4sIX1ezRg/RV8RfkB/BkeWjHd4NGqxdFHEW2siKozP6hKi mtmQmfEG4/kZ8sAmZm9LvC3xk8FKlY0yFbXyqbUFyxjRno7laiIzWeQwTZUk0taz4tL/BdGOju8R 8daHNaoK76KHP8UzXnnuNdLKrvienedK34z2snhz2fIZepVBrSiviuepvCXOVwOIqwFyTy/s5uSb iboT2JAHTLSPZlK3i/6EyF/PasoYN0e5EctJ6Hsw83OFLi+tJ1dIVolWZBlMpDSVUbdlvEfgLHgB z1msV2uYBjvGbSTLTYyvo2S2pyRnunhYz256lai4wCe5F4jVC8TzBdZC5HPM2+T4Xaw8Ghn1fEba IrqLkXPyWZ0NwgSiKIG7jPkBywGQe5w6JXHonoG/IQeeJgdKhulBP5sTpenE8F6imlzkLJdgKfZv oB+KZQ5yJ/RL6fkB5BXo28f2w1x232l5JpdWYvMKv2W9ustuZU1vYFxp0X0t9hGf15eR3tLzKYwl FcvuMZ55qFtRVXY+U+Ir6+SLK8WzUvydN+XL7+nE3zQKVTH0xUSvlGhit8m3rGO95ZvwMX4fJFYM uSFyQ+RG8j3tWKZ8l97pc9EvR75Tvj8m38x38jbkfOSfRJbf4nF135e/coM+U74N6Py8zt9m+ZW/ b7NBKL9HoJT8nnssWX6bI5Ysvw8SezscKn/lJuEh+Ss3Il/cKHJsSviE/JWbhFPiPzwmTDiJ/JX4 T/gB+XfkyKYbbIRlXzhA/u6N9O3i0ajP4bPYL0GOap2gzwXoq6IvJUxozejqw5OMdyqlq2EC+muw bEtbP6Hfic8MNM2ZmUhzntLbsJ9BizuZpfNwEq23wbIOdcUyHTkdOSPcgf4cch38RPrq9ORm5FrI t+LnoDAxAZm/5JOYSOltaKbjbZ38DRw8XIOHhsgNkRvJ78s7+8+Qy8Iy1GpHnzPocz9WeSEj/ZVS +ha+guZOuA0WUHqlY4OEN5DfxOcm5JnYvAOfQr8aeR/yGemh/BUO11uJw0Z8Lm8uFiIzb/JJeqzh xX9Kfy6yFvLJu9OcltKLG2UmI01sEkyF1MJDw4tbsaTuRUZ9cSHyMXx+hHwAOZ9SIuriITTf40e+ gaNUMW9a4gll+j8wYqhKvnvEwHvVxKF9Rw1Xbyt38rupe9tU5U4WhYWqjEpSoaqorlalVX3VWDVT rVVHdYu63fnoph5UD6n+6h51nxqtHovbl1AJqpKqqq5QDVQT56WN6qR6qTtcq93VBDXFZY4hKleN UdP4NwajOlYlupxRTSWrdHWNula1ddn5VnWn0uom9Rf1sBqo7lX3q7FquiqrTIeuXXNUx+433pCq +vXo3ilVzcPLlfzN0Ktcbq7uPDZULdT1KlvdoHqru5RRtVUPNVFNVYPUUDVCjVMzqHOZSlU1lNzp rlNZqouqo/6Kvpwq5eahikpRNZ3fRqqpaqnaqRx1o7pN9XX9rqt6qknqEXW3GqZGqgfUzHgPLlfF VZqqoGo5D5mqlWqvOqiuqo/qpwJVT92sJqtH1WA1XI1S4+VvmfbPGNnf3AzvgIPgcDgGTuzfd+go 8yicDefDpXAVXNu/78iBZgvcAXfD/fAwPNq//7BccxwWCH0NS8HKsC5sPmDoPXf77WFn2H3A8PuG +b3gHXAAHAJz4Rg4YdCIvv39KXAmfAYuhsvharjJOe7r74C74X54eOjw0cP8o/A4/AmehudgTBj4 Q+/rPzQoBkvBcrCyKxwRVIW1YTpsAlvAtjDnPvHTBfaAveFdcBAcCkfcN2LA8GAcnAin5op+BpwN n4EL4BK4DK4a6dYoWA3fh1vgDrgbHhh5z/BBwdfwW/gDzIcF8PzIYf1zQwWLwWRYGdaEGSNHpjcM W8As2Bn2gH3gAMeMcCgcBSfAqXAmnOvYKFwAl8IVcDXcALc6Zoa74D74JTwCj8ETI0f3Gxmegmfh BWGChonQjhydOzIhGabAVFgd1oUZo9xMJjSFLWEW7Ai7wpuhPI1rl3uS/4ufxu3zCqri/5Xk8YdD /88MXMYIXBZNUIn/3658riLZc1mvKEv8SRqX54rzN5f/XyTPZe//maX/NDUrop1XueJtj9wf5Cnx T/PyP81K/xtL/Wmm0lPDT+8PlBH8UWf/I427U5VV5f5L6Uok7e5Paf/Vz6tV1f/qZzVV/b/46bk7 6X/mf54Tz93B/zNL/ik2dE8bo9xdf65aqlarrWq/OqYKPN9L9qp6mV6W18Mb4I3ypnpzvaXeam+r t9875hVoX1fWnfV4PUPP18v1+3qnPqxP6POmmEkxtU1z09H0NkPMeDPDzDfL3R6UthKjmDVdilz3 K3I9s8j1rD9c+0XKQ7fNv1QJ3h+ui2Veep205NL69uyl/pN7X3pdRl3qv0xykevqRexzilz3KXJd ZDxlDl96XbZmkeuuRa7HXdr/iosvLa+04dLranWLXNf/w7Xbf9XSi5RP4Vq7/FA6GmGNrtHPmtHI fRdzZV2uqh7X7o3/PBz/eSz+89T/ZF07M/6zZfxnTvxnj0t7UXvGpaOs0+TS6/qxS+0b9Lr0umGR VcjIKHKdWeR6b5HrfUWufypynX/pdaPSf4gyJzRJLnLd5FL7Jk2LXBct71jkunOR6y6XrmKzjo7W zUx/72k1yFtAtu3n/lNup85VXlAquJx7RWkVJnWweUk5dqvdbLc4Tej97P3s7E55p5TnnfZOK+39 6v2qjG1j2yjfXm+vd/dNiQdt2hlZL61L6zJOI79BZKU/poSrWd9dl3WnkRFqgcpTR9V5L9n1IdH1 Kjmpm9JJOUndHTsk3eQooyvlcnKqOy2kuzNPC/uDMrqU69M/+Zln3UlLl3HXP/Izzx5Q2l196Zhn DzvucGOVCE1Rafao6+tmV/p3fubZb93PLe76O37m/cHyWNzyH3HL43HL7+OW/+5vJ/rbmf7eQH// XdKFkhsp6frHEruTHu6ih7vp4b9L9lKyj5L9lGiVoN1/bpsV1/LN7VK6lJvVMm5WTVL7pGw365vt ZhW6Pm1xM2WU3PE9wxsm939NV3+KG9UUd1nSK6kmeSleJTWZf89yqtfb66Me8YZ6w9Q0/g3LGd79 3ij1V2+GN0M94c3znlOzvV+8X9ST3lnvrHrK+937Xc2V0FBP61CH6hmdpJPUs/pyfbmap8vqsuo5 XUFXUPP11fpq9byupWupBTpdd1UL9Sg9Wm3SY/VYtdll//HqQ/0XPVFt0VP1VLVVP6YfU9v0XD1X 5eln9bNqu16qD6odpoSLmgsm02SqmGlrslSh6WA6eNosNAs944/yX/T8oH/Q38sIBgYDvUbB3cHd XmZwT3CP1zgYGYz0mgSjg9HeNcHYYKzXNPg8nOY1K3ZTsb7eyWKPFfe8WFKppHb6gaTbkhbpN0oM KDFEnykxqcRMfd5qm2gSbRVbxZS0V9urTSlbzVYzl9satoYpbWvZWuYKW8fWMcm2nq1nytgGtoEp axvahuZKm2kzTTnbxDYx5W1T29Sk2Oa2ualgW9gWpqJtaVuaSra1bW0q27a2rbnKZtksk2pzbI6p Yu+wd5g0+SeFzdV2kB1kqtrBdrCpZofZYaa6vc/eZ2rY++39pqYdbUebWnasHWtq2wfsA6aOnWQn mbr2IfuQqWcfsY+Y+naanWYa2Bl2hkm3j9vHTUP7hH3CZNgn7ZOmkZ1r55pM+4x9xjS28+w808TO t/PNNXaBXWCa2kV2kWlmF9vFprldYpeYa+1Su9S0sK/YV8x1dpldZlra5Xa5aWVX2BWmtV1lV5k2 9i37lmlr37HvmOvtGrvGZNn37HumnV1n15n2dr1db7LtJrvJ5NgP7Yemg/3IfmQ62m12m+lkt9vt prP92H5sbrCf2E9MF/up/dTcaPfYPaar/cx+ZrrZz+3nprv9wn5hbrIH7UHTwx6yh0xP+5X9ytxs /2b/Zm6xP9ufTS97yp4yt9rT9rTpbQtsgbnNnrW/mT4uePuSvxSZy/POe+ddFiv0Cl32CLQ7B7DP AvZZyD5L0Ck6RSXqNJ2mLtM1dU1VzOS47FY86Bf0U0nBgGCAKhEMCgYpGwwOBquSwYhghCoVjApG qcuDMcEYVdqm2lR1hU2zaW6PV7VVVRlb3VZXZW1NW1NdaWvb2qqcrWvrqvK2vq2vUmy6Tefv1DdS FW1j21hVstfYa1Rl28w2U1fZa+21KtVeZ69TVWwr28plK8m/V5N/q9psm62q2dvt7aq67W/7qxp2 oB2oatq77d2qlh1qh6radrgdrurYXJur6tpRdpSqZ8fYMaq+HWfHqQZ2op2o0u1kO1k1tFPtVJVh H7OPqUZ2up2uMu1MO1M1trPsLNXEzrFz1DX2KfuUamqftk+rZvZZ+6xqbp+zz6lr7fP2eZevF9qF 6jr7gn1BtbQv2hdVK/uSfUm1ti/bl1Ub+6p9VbW1r9nX1PX2dfu6yrIr7UrVzr5p31Tt7dv2bZVt V9vVKse+a99VHexau1Z1tO/b91Unu9FuVJ3JfzeQ/7q43LlV3ehyZ57qane47NnN7nTZtrvd5bLt TXa3y7Y97F6XZXvafS7L3vy/2PsOqCquru1TZu65d2bugIAI2HtFLqiIvWDHjrFgR1AxIoqI0WhU jDUajRU7FqzYC2rsJfbYxd577x3592xGg4n53rzt+//1r6yzOHvanTv7Ofvs5zlnhjv6CciyzfRT wBnN9dPAGS30s8AZIfpF/SJpib8R30p/pD8irfUn+hPSRn+mPyNt9Rf6C5z3Sh9fUVISc21hiC2Z tqatYXM4DSdUSpaSCbOkWlIJt1a0VoQ8/J+JPsiBf0ff39FnRp8XRl8RQ23RCMu5v2Ps7xj7D8UY lbuAnnemeVhJXkNqTrKRsqQqqUMakxAYL3QB/d4XlOVIMo5MJXPIYrKKbCQ7yH5yjJwlV8ld8hSU PaEWqtm+IdzW0xZj64O2l60v2ljbt2h72/qDjYGl79DG2Aag7WUbiDbWNghtb9tgsL3guO/RxtiG oO1lG4o21jYMbW/bCLCxcNxItDG2H9D2so1CG2sbjba3bQzY3nDcWLQxtp/Q9rKNQxtrG4+2t60f YbA3DupetuFQx9p+hLr3v4HIRPS8p22SicxkE5l4E5kpJjJTTWSmmYhMNxGZYSIyy0QkwURktonI HBORuSYiiSYi801EFpiILDQRWWQissREJMlEZKmJyDITkeUmIhPA/562mYjIPERk8b+JyEoTkVUm IqtNRNaYiKw1EUk2EVlvxsoGE5mNJjI/m8hsMpHZbCKzxURkq4nIdhORHSYiO01EdpmI7DYR2WMi stdEZJ+JyH4TkQMmIisQkXUYKdsQkV/+TUQOmYj8aiJy2ETkiInIUROR4yYiJ0xETpqInDIRSTER OWMictZE5JwZK+dNZC6YyFw0kblkInPZROaKicg1E5HrJiI3TERumojcMhE5iIgcQ0ROY6Rc/TcR uWMictdE5J6JyH0TkQcmIo9MRB6biDwxEXlqIvLMROSFichLE5FXJiKvTUTemIi8MxF5byKSaiLy wYyVtHRkFJKOjELTkVFYOjIKN5G5jYg8RESeIyJvjUgx3tNoXDfOpjUnhekxNovX5Q14R96Jd+Ff 8568F+/N+/D+fDgfwUfyH/goPhpGwVf5NX6d3+A3+S1+m9/hd/k9fp8/4A/5I/6YP+FP+TP+nL+w +xvvUaJH6BH4gpnGf+fyIB5EGK/P6xPOw3g4kXhnHkEsPJpHEyuP4THExmN5LCiBb/g3ROX9eD+i 8e/4YGLn0/g04so38kPEzV7KXgpnGbyIIuWQckq5pNxSHimvlE/KLxWQChqewRW9wNn1dL2SzZyb KGrsg8+kz11T3vXTEYXMI4oZc1O8K+whkptk/AJYIakQUTN8Lv173aTMkruURfKQPCUv47fv4Njf vpeRfMRJcpFcJVmySEKySjZJkVRJk+ySLjlJzpIx3yWBbwPgIo3PMKmCVJFoUhWpCtFhnz/x4PP5 Qp7El/NdfDf/he/he/k+vp8f4Af5oS8hbsyW8USeCGdcYPxfM1/ClwDeyzjkUUBuJ3zfVX7v09kT 4aglsHcj/5lv4pv5Fr6Vb+Pb+Q6+80ttjGefz+fD2RfyhcYTmTwJzr6cQ3aGKzwEZzf8MM5enLh9 8axf8AMxu2piZnzuL0YXfs6IBvic3I2tIYPJ92QIGUqGkeFkBPTrH8gofLvoGDKW/AS9fDyZQCaS SWQyiSdToM9PI9PJDDKTzCIJZDZkgLlkHkkk88kCspAsgnywhCSRpWQZWU5WkJWQHVaTNWQtWUeS yXqyAXLFz2QT2Uy2kK1kG9kOmWMn2UV2k1/IHrKX7IM8coAcJIfIr+QwOUKOQlY5Tk6Qk+QUSSGn yRnIMefIeXKBXCSXyGVyBTLONXKd3CA3yS1ym9yB/HOP3CcPyEPyiDwmTyAbPSPPyQvykrwir8kb 8pa8I+9JKvlA0iCMKWvEGrNg1oR9xZqyZqw5a8FCWEvWirVmbVhb1o61Z6GsAwtj4awj68Q6swjW hX3NurJI1o1Fse6sB0tgp9kZdpadY+fZBXaRXWKX2RV2lV1j19kNdpPdYrfZHXaX3WP3ucIesIdc ZY/YY/aEPWXP2HP2gr1kr9hr9oa9Ze/Ye5bKPrA0SEHG0/acS1zmFi64ldt4I96YB/MmvBVvzdvx 9jyS9+Df8yF8KB/Gx/MpfDpfwVfy1XwNX8838F/5YX6EH+XH+HF+gp/kp3gKP83P8LP8HD/PL/CL /BK/zK9I5aTyxntbpRPSSemUlCKdls5IZ6Vz0nnpgnRRuiRdlq5IV6Vr0nXphnRTuiXdlu5Id6V7 0n3pgfRQeiQ9lp5IT6Vn0nPphfRSeiW9lt5Ib6V30nspVfogpcl22UVUEVVFoKgmqosaoqaoJWqL OiJI1BX1RH3RQDQUjURjESyaiK9EU9FMNBctRIhoKVqJ1qKNaCvaifYiVHSAEg6lE5QI0UV8LbqK SNFNRInuooeIFj1FjOglYkVv8Y3oI/pC6Sf6i+/EADFQDBJxYrD4XgwRQ8UwMVyMECPFD2KUGC1+ FGPEWPGTGCfGiwliopgkJot4MUVMFdPEdDFDzBSzRIKYLeaIuWKeWCKSxFKxTCwXK8RKsUqsFmvE WrHOePer2CA2ip/FJrFZbBFbxTaxXewQO8UusVv8IvaIvWKf2C8OiIPikPhVHBZHxFFxTBwXJ8RJ cUqkiNPijDgrzonz4oK4KC6Jy+KKuCquievihrgpbonb4o64K+6J++KBeCgeicfiiXgqXos34q14 J96LVPFBpFmJlYpEMV8sEAvFIrFYPBPPxQvxUrxSvlH6KH2Vb5V+Sn/lO2WAMlAZpMQpg5XvlSHK UPVbtZ/aX/1OHaAOVAepcepg9Xt1qDpMHa6OUEeqP6ij1NHqj+oYdaw6VZ2mTldnqDPVWWqCOlud o85V56mJ6nx1gbpQXaQuVpeoS9Vl6nJ1hbpSXaWuVteoa9Wt6jZ1u7pD3anuUnerv6j71QPqIfVX 9bB6RD2qHlOPqyfUk+op9bR6Rb2m3lBvqXfUe+oj9Yn6TH2uvlBfqq/U1+ob9a36Tn2vflDTNKJR jWlckzRZs2jXtOvaDe2mdku7rd3R7mr3tPvaA+2h9kh7rD3RnmrPtOfaC+2l9kp7rb3R3mrvtPda qvZBS7MTO7UzO7dLdtlusQu71W6zK3bVrtntdt3uZHe2Z7K72F3tbvbMdnd7FruH3dPuZc9qz2bP bs9hz2nPZc9tz2PPa89nz28vYJ9mn26fYZ9pn2VPsM+2z7HPtc+zJ9rn2xfYF+LdZ5zbxzn2AWwW gwyKM+ezeR3g95O8HvB7Cg/hLckZ3oa3JeeQTS/w7rw7uQiMN4hc4uP4OHKNx/N4ch2Z/Qby1k3k rVvIW7eRt+7wdTyZ3EWGuC+VkcpSgjPwTFZkhTpkZ9mZ+uIcu5/liuUmvS0coiR9iPPtz5RhyjTG lERlK8ui7FNeMz+cdQ/F+fb5wPZPiY14kDzA+fVBAU0FBtgC2Rm+Qh1CmL4Pl5JwybhH40zcSTZ1 D6ynqHuhPqPug/qcevDTsSmwtJ1YQU94kBygAIqk3z1Szxjb1XNQH1AvQH1IvQT1YfWB8Uk9s3FG 3d04o57FOCOeKxXP+vEejQ3WdusK1Ht09bM9TrjHGfdk+myPB+7xxD1euIcRG7SaA9ougBlvSyrH yhHGarAahLParDaRWAPWgMjKeGU8sSjJSjIRymPlMZyPyQvZ0f8Sx37OsP9/8+v/DsMaHPpXefO/ yZkuIkx0FJ3Ft8BABnNWB86si2zWCJjpR+TJ5sCRBjumc2P4X2TFfv+AD//IhlOAB39jwIzs8v8a G35iO+DFeODvjKxYBdSHoT3SlYehOxqC8nhj6o53oDpagOKYiZpjFiiOtxC1TSFS2xpx+ZE7WeTn vKk5a5k0F81Vc9Mya+5aFs1D89S8tKxaNi27lkPLqeXScmt5tLxaPi2/VkArqBXSCmtFvsi2Q77M t7pNV3T1L7Fu0h95V3fSnfVMf2DfPepedR9y8MEvsnAK8PAZ9Zx6Qb30kY91dz0LcvKDP2Xl1D/y su6he+pe/xI7f8bNWur/AjvXp4xmhqGsFy1E3GhD2oTkxXvuhWgbGk6K0k60EylBI2gEKUm/ppGk FI2ifUkA7Ucnkmp0Kp1B2tC19DAJZdEshvRnsaw/GcgGsEFkOBvMhpEf2Ag2moxlY9g4MhHvnk9h kxhkexzjz+QadyGzuBt3I/O5Oy9CFvBi3Ids4r68GtmGjH8CGf8kjt5OSXOkw+SunEnORD3kl/JL 6im/ll9TL/mt/JZmtQBcNJtlhGU0zW4ZYxlP81gmWuJpQctUywxa1DLLspj6WJIsa2g5yzrLL7Sa Za/lCP3KcspyiraxnLGco20tFyyXaChog1QabkkDbRAn/EU5ul5UEJXoFmthaxG63VrM6kN3Wn2t vnSP1d/qT/day1jL0H3G/TO631rZWpkesFa1VqUHrTWsNegha21rbfqrta61Lj1sbWJtQo9Ym1mb 0aPWEGsIPWZta+1Aj1sjrBH0tA2G/fSMEqp0oGeVcKUzPa90UWLoZSVWiaX3gGen0fvAs1vpC+DZ 1/SDytSWTKit1b6svTZLu8oG2Efbp7Kd6c+3wGh0Gd5xaU07mlvWZdhCSVliMbVHAdA0JWF/IhSj XgaqIBGtsbbZXNsMaxegGE/ZFKVFIWqK0+JAdwE0AM5Zk9YEcgmiQUSi8TQen7LZS9rLXnJWOZuc Xc4h55RzybnlPHJeOZ+cXy4gF5QLyYXlInJRuZjsLReXfWSH7Cv7ySXocXqCnqSnaAo9Tc/Qs/Qc PU8v0Iv0Er1Mr9Cr9Bq9Tm/Qm/QWvU3v0Lv0Hr0vcUniL/kr/pq/4W/5O/6ep/IPPO3f2SaBKxLD mQYJ/1shE879eEDhJBsUCZArCJ4WI8ZzaT5QrIBqWdCJ5aEopCIUlVQj1YlGgqDopBkUJ9KChIA+ bAPFhYRBcSWdobiRniSGZCZ9SF+ShQyA4gm9kxEv6kSdSVboo14kO81Bc5Ac+HRMTuivDUku6K8h JDfe1c2DPTUv7Uq7knz4vEx+2ovGkgK0P+0PfXoEHUEK0x/oKFKEjqVjSTHowVOJN/TgtaQ43Ua3 Ex/6C91DfOlBepCUwPmmktjz/FFT18FZpzY469Tu01zYLnMuzBuQys58mS8oRn/mb/xvGKsGirEO qwOKsTFrDIqxGWtGZNA94cQCiudrUIzDlZHEqoxSxhJVma8sIM7KIiWJuCinlBTirpxRzhMP5ZJy DbR0P/U7khvY43uSz2AGUhiYYTYpauRx4gN5/BTxhex9gZSCDH6J+EMOv0ZKQx6/QQJgbHWLlIFc foeUhXx+j5SDnP4A2sh4/qsca/XJl/2mL8XBlxyf+VKGlYFjDY84awhjGQk9ktEjC+i7ECLQLyuo tx7Ehn4p6Jcd/XJBv9yUZcoK8GiVso5kRR9zoY95lFvKHVJAuac8Ar8MT4ujp77oqT96GgD8lwjj gwUwyqiEXldHr2sCL70kQcBKqTAyMTyqzbqYd1+N/3IMQ498DB9pY+z35NMWgnOZjHamlT9tY7QJ LQZrbp+Ogx7wBSzKs/KAhYGIhG0sIy4WxEUgLlbExQa6tzVREB0VW11DjOxKC6UF0WFk/h1xgtHX OGj7Cco0kg3GYOtIPmW9spX4w0jsEamoPFFek3DQEMNIJKiFsaQvqIMkEgfcv5ZMBK4/Q2Zg26/H tt8ADH6FbMQI+BkjYBNGwGaMgC0YAVsxArYBsz8i24Hdn5AdwPCpZCfwuYX8ChrHg5wCXZObXAQt U4TcBFWikoegLjKRJ8DxXjACgEwII6QehBgjSFLVmGUgjYzntkiw+q1WnfwKn8lOp+BTjvy3FiGh iKsDo65hhhZx/NYipAmp+GkbI5Xx7rnbp+MY4cp0ZR588zZlL0TbG9WIX9iK4+z068mNV+Iwv53B t3j9K5kVPpkZ8xDBPEQxD3HMQxLmIRnzkAXzkMA8ZMU8ZMM8pGAeUjEPaZiHdMxDTpiHnDEPuWAe csU85IZ5KDPmoSyYh4z/K94BHmisFt8ISPyj+zCMKtQFrjIPLUL9aFlaldahjeHqQmkX2p3GgnaJ o8Ppj3QCfGsCnU+T6Cq6nm6hu+h+egSwOQ843KYP6XP6FpK/hWnMhXmwHCwfKwLo+tMi4H0hwMIb bQiwn2Fb0zJo29CyaNvScmjb0fJo29MKaENpRbQdaCW0YdDzDBtOq6DtSKuhjaA10HYFRjVsFG2A dqqcxbDSOtkDbbLsaVj9nVU1rOxq1QxrmWe1o91s1dFusTqhTbU6o/1gzYQ2zepiWFAvrmgrOVH8 ni60MGQCJ+B5BmvFoA4Btje0A+QD8BJiEHz0hbod9YO6PS0BdSgFHQG+lYI6jPpDHU5LQ92RVjWe /aCBUH9Nq0PdFfQCA69qQd2d1oa6B60DdTStC/VUWg/q6bQ+1NNkN8LA38xQJ8vGzMc7KzQMeApR DX5KUG+2gt4AHy3G00xWAfUHqxXqNKuNMPAN1I+1EikMvaoV8G1X4Nl+5Hsyikwg08k8kkTWkE3A YwfJCXIeRv73oW+b9/Mgkjwg1vNBLDmoPy0P0VSL1ocMGQJ+dwQvFgNaUwGhJWhb0yS0behStG3p MrTt6HK0oXQF2g50Jdr2dBXaMLoabThdg7ajNbthwccchgUvc6LdbM2Fdos1N9pUax60H6x50aZZ 8xkWPM6PthKdie03C1suAVtuNrbcHGy5udhm87DNErEV52PLLcCWW4gtt8hoD6sbIp4ZEXdHxLMg 4h6IuCci7oWIZ0XEsyHilEhOBJ/q5pgrCPZ06mT8i4bxS7718Zn6QsQPuNiciaLuGGtZMEY8jO82 zkI9Py11NiLJyL2QTyZhrGBt3CGjzpChCM0MYxqKmYhhfjE4zYOMoF/RZrQFbU6b0s5Kc2CfkPR5 YdaLfceGs4l8Kl/EV+nv9VT9g54G+XWGMlOZpSQos5U5ylxlHuTa7coOZaeyS9mt/KLsUfbqr3Sm c13SZd2iC92qvFHeKu+U90qq8kFJUyHtqT+p49Tx6gR1ojpJnazGq1PUdWqyul7doG5Uf1Y3qZvV LepZ9bx6Ub2sXlWvqzfV2+pd9b76UH2sPtWEZtVsmqKpmqbZNV1z0opqxTRvrbjmozk0X81PK6GV 1Epp/lppLUAro5XVymnltQpaRa2SVlmrolXVArVqWnVd0+26rrvorrqb/lp/o7/Vs+rZdOMeZAEc 9REc6cmgHIKA07qwrsDaMTCi01h/GNHZ8elnHcdvTjgqc8a510x8JV9JXCzLLSuIqyXZkkwyW15Z XoFug7EKyWKMVUDfXFRukMLGiAXUzHDg7rIwZl9LAmG0fYbUhRH3OVIPubs+cncD5O6GyN2NkLsb I3cHI3c3Qe7+Crm7KXJ3M+Tu5uoHYO0WmjMwdSgydX9k6oF6ZmDqweDnRhLyV1r0X2vB/0o7fWwh BdEkiKYNcXRBHLMijvnQc2/03B89b4SeN0GN0ix95Cfjm/5guQ4x5nWrkhwZ4//3Ufzn8ZgeO3CG TBgpBCOFYwtbsD11bE8nbE9nbM9M2J4u2J6u2J5u2J6ZsT3dsT2zYHt6YHt6Ynt6QbtlIVnNq1dl PcPV66A3zR5r9HmMU4JxSjFOGcYpNz+ryU4ZPusBquRTFvjY0zFzYC/ASJYxkgVGsjV9FEuf0Jf0 nakGMjF3lpXlZYV5bbmDHC53kiPknnIvubeeW8+r59cL6oX1orq37qP76iV1fz1AL6uX1yvqlfWq ejW9lt5GD9M76p31SD1K76H30nvrffQB+iB9iD5cH6mP1sfo4/QJ+iQ9Xp+qT9dn6gn6HH2ePl9f qC/Wk/Rl+kp9tb5WT9Y36D/rW/Tt+k59t75H36cf0A/ph/Wj+nH9pJ6in9HP6Zf0B/pj/an+XH/5 91Plfz9z+R965pIRZ9D8HWVX/R1wfqW/9Ew59ETaxXI+wxPAVuNZGfOpmv/xGZlPz9HAOVgF1ubT mD19SxBkoI9jXkafk1eg0UuxADgiELY1YI1YU9aCtWJhkKu6Q9brb9zT+lIx7mNlLHCWz0vAH4tx 1ytjMe6RfbEE/q7UMO6gfVYa/LEYd9MyFvDlTwrwwWcFfP68tPhSAf74rABKn5c2WH5bD/td6QSl y5+U7l8q6ofPC7DW58XzdyXP58X0L/168Qx/z038ydwEJReBP8sD19cCld0Efwfl46+fGL+EMpKM JZNg9DOHLCTLYPyzkWwjv8AI6Bg5Dfg58F7vP1sH/Et1g3+l/uL8R/rsiAZmkjHuIVWMsQBwnTuO Hox7HJQWhnE0A7afCMuT6GRYjqfG27tnwsiL0bX0kfELsPQJjFee4jswXtCXsPyKvkHOfAfL7+kH WE5jxhtIGJMg5mRmgWXBjF9NVRmMv5kd3+fhzGCMzVyYGyxnZu6wnMV4PwfwalZYzsZyw3IeBiM3 ls948wdwbGFYLsKKwHJRVhSWi7FixHijiTcsF2fGm3imsWmwPJ1Nh+UZbAYsz+Q18VdcaxPO68iu xu/EyeCv7CVXN37ZUK5JuFxLbm/8TrccActdjLcCA1f3huVvjF+MkofIQ2B5qLyNGG843g7LO6yQ ma0MRpHMWsD2NaG2rjZQerZI+yJC7YvtMOq1L7Fvh+Ud9t2w/AsoVarnAJ3BQU2m4QgPsrITc8qf /j/O2DKMhJr/mfubBqGoQShqEJrhP0gpahCKGoSiBqGoQSj+3wdFDUJRg1DUIBQ1CEUNQlGDUNQg 6VfIUIlQVCIUlQhFJUJRiVBUIhSVCEUlQlGJUFQiFJUIRSVCUYlQVCIUlQhFJUJRiVBUIhSVCEUl QlGJUFQiFJUIRSVCUYlQVCIUlQhFJUJRiVBUIhSVCEUlQlGJUFQiFJUIRSVCUYlQVCIUlQhFJUJR iVBUIhSVCEUlQlGJUFQiFJUIRSVCUYlQVCIUlQhFJUJRiVBUIhSVCEUlQlGJUFQiFJUIRSVCUYlQ VCIUlQhFJUJRiVBUIhSVCEUlQlGJUFQiFJUIRSVCUYlQVCIUlQhFJUJRiVBUIh9/H+TTr4V4tQHr hluJV1NHnFdji63I0FpDX9mpYAlxXoGwqRKj1Fd12CxyUZ0zL5k42luUohYq0bjSjEoJwY5GjmIZ tmSbk2NgNrydU540IKGkJ4mCJBpOYuDPuL1T0ZE7w8kkt0JprjVnBlWdOiZ7p+tqv6iSC+0dTyTE ZfZ2xEkJjjg+PIEzypjS3vPgeLzsjg77p4ukMlxOH7w6/pVkcWVfBfu6OjIZK1ZXpVn7np0junWK ierm6+zQjY3CVTQOD4uM6hbmm8ORzdiiuGauF9EhOqpnVMeYXIFR0d2jotvHRMAn8jpyG/u5q1fG /WHhuYIjOnWDs+ZqGFjFkSOL3dfX1+Hr8HOU8PMrFQKrJRy+n1Ydgwb/V67N7lCN/aqrVK9Bw8Yf D+d/crgjjubJiJnx9qg4SDewXWFxlJKHLbf0z5Tv2lDL5Y5ptdZm2cyur9H8HkdX7F98WEr92SsX BPq8Cp/pe8XPt/qylO35vs+dUnzt99+9LXU8OFvKukY5GvzaccO9ZI2lFm61dOGwl/vzrDm51drr xcjuYzqkPBqZ486YwHxhIceH9R8bWS4p9lAz//63Nzk3TYp/PKJ18bBflhewtcnRIfOTClvdx0wZ znY6krer7XI6RR88lbywlMvQabNV5eb4lj++bTJ9+zPPtlVHu8zKXmlsckHXwZ5+cdmfnRl2Iveq 8nPWiQYp+RY/HP1i9Zm3b8o0WHDn6fIWjZ+frzLNJ1P3DhfuXlz8JDK35Bxc4udVDXZfCV5VJbxm t9IvN92Z5l7lp6+Lt3TsZBw6xNw4mh0Q8XS4ApbZ80uaQ7FYIahlWXDuyG5s1EFsu2VtrD/LVCR5 24idmQZVODGp+Ya5wd2wAbM7GS9ck4DVBjpyGut5JQ+H+0C3A5lu7z+2xr053Ve6eAl39w11pyo5 HU2NA3JKDRz1HEEJtRNqDq3eOSame1kfnw7RXYtHfmzF4h2iIn26fx1hbPXpHh0V1qtDTE8faGQI RAhDiMC2jgDvEr7efhCCxeEgR8jHa6ZUqu+o66jzcd3BhlY0v6J3795f+orw6P/x3DG/63bciJzE lv5dl9afFuFyLWokmxbRe2fXsOhCw89UqB5ZzOPbE4V8XK+26JJ1h1oyeWTq3Q0T7gvfm12e95KO LzjbpqxlpnPqIvvm6Y0Co9I6TZh+5XC/x/lWlDo4uPXDs9ui/GtvC1Gavex5Zeaza9a65Sr6HDx2 6GGDPN1fSTnZ/KBp68e0Gq77T+haQqxftLRRwpEd53/M47J556W4lKazX114nJirmbPzjIdJQ2O6 9pi2/fHTHd3bLDgXWa908yn1+lQ+UrJ1SP5lne5lrV/DsmJU4ZxznccklpiV9+TrtTX6X37YIX5s UEV5oc8Kj9Ut5i2vEvyjVXb2LrKvrKVutuKLfBs1DUuaejBpcnzhkZPHDrs7Yx3kqI2Qo+Z8zFGy 5yTMpVl/n6N6/1fyQG4MNOj4Hr/tbxIRGe4dHNM+svtvGcpR2q+Un6Okn28ZI0P5QX76uOoYtPp/ I0MVdORPX83RLTCie+fw6FzVgqvnqh5cv2yZ6qUDvAP8S1b1dpQoU803vyNvukfZvuhRcHh0bESH 8H+Y0Y4fKBc8Z1a1uX2X1GvaI3hk78Wlx39HK6YuYXODF6UdXZlnNxl7q1e3hx63B+muu0+3J1ty JsSWk+zSbilh4fvAYMtsSdqgjotnoQGPTpRweVW0wrePllZvNmRirlkpHUpOD63x45Zll8/MLPNy 0Veph2/1vlnK9VGr21trjW/gFSiaB4wcMMSt6919R4L6xnU7cDxzO6vbiAkLW1Yqu69Srv6RPs29 +u8fGbBp544ynU97N/fK+6CIszUk16i4xAdHJ1cfN+TgztKDL9nj++0+vu7ylODT31hf3MibW4QO DekS4Zna/U1wyUGv8vt6Dh32w7avpqYurlsqc2rLOxP3LQmOL9y2WOKV/E5hu5+uKNjrY0azASJy huTVJ++t2fYtXxXr7FE4NK7TqWdX/ANCPktWeUu+PtO4RnflQeV3se9WF12xs9RqJ0eT9GQFqcoB qSqh+tDAfypZpe82WhEbEaISU1XzDKkKEpWjVoZUVf6vpaovnjnmSxnc+qXsVXNH7KCWvheijpef 8rRv1+8muzYsJmfJ6ry+2uy1o543Pbx5Re41YZHts51+ePvei3EPA+d4VNv59u2jpetaDZgcGbQ2 8F3B9t9Ym/Rb+WZ5vLImZtfi294Nd/X/0L/+7CmnChZKXnb60soxg/P8+OuzPu/bu0VuvXfw+xWX 5v7cUk6+2+RFaPauBed3CHp7bfbbny8NmRQeEbxiXY/4sAIdN+9+0ip000/PK0wPqkrshwNktwIh 54vIQQO6TAk4faHnlDm/jmqYb+a8ey8qjfzmYJMprfN3nFfFUmh57V1rGk+4f5ENDvtQ70Ra0Jz3 hQeee1hpSfkHJYbv35qn3ZFW5aQVypr4yPILyjaYepS6ZwodWSUW1JW8CbLXvI/Zq0QBL8xevr/P Xm0xLSi2cQVGjH9aLIx6unNoC19PR5bPNto+NZWvt6Noej/O91s/bhwVBUkC2i6iY0SH9jHhuar0 iukcFR0R0wezlMMRUMLXD5JSCT/IUn7mqp+x+n9T4v2jVLMqukUrT0fY1uxT2+XKVXVKbHDXillP RR088OTu1x8muztfvlQ2ZrBXsk+C3/20izuq1s97MpqcK9VMGbF/Wa7azx93TqoXNDpxc5+gHtNq irOp+S/N6DX88OKe1QakDDr3bPNT/3n7WlU/v3xphcuFOk/2WpAY3bPpkywTrqeWmhCdcCq2bY7e 1QcPCXA/0rOlvLFT49GJqyJ8znqqH8bFFL4a69Pkgpujxetjo0NTD+xrW8O34YaCrtcrOw5HF3Yu lGdP6foVEvwqjD00O8AypFX9pnGFish+yUEpDTrcOuYd+qR6hVtJVvKyxuyZR1uOKhB8u+/iOk9r HC5dPmDmmt6tErPMHH0g05im5bcn2dry4x9TTRtAJMThZHQ9V0MIyQ4OJkPu+aIOUlE4GaqJDnW4 WGzmKCIzlWQ8MdDBp23MOEvqUd/6xwuMnHglvl25hb5R88tvOu3t8Px0kBuTtBwKCSa9YOQRSKp8 ltz0pLh2lZsWnHwjv+v7IleU4Iktrs9zNExPbrUdNR3VEwITqgyt9NeT26fd0RDaRlbCxNYkQ2Kr 5ajhqJYhsQX8M4nN6DCB6Wf9o/pilLQoU3FAgRrL70VVXum3tss93afbwtqv7rXt9aBuOe+UwKXq hwN3vH3n5j3Yr2H8wNytkyr41N04Z2HT6de6/7x+zes+a2tHv6p4t8qA/Ve0LBEHEqfn8n6rNtzV 9JD3tTrHNnW/tdA+hyc2vbx+ZFCzpxOrTn/y7NHDa0Nzliy/vunUx8F5hxSZF5dt/NUJIvvTq/Vf j5q9/7Zr4k/192Y9NiZ6YpEekdO8Xmd7HHyq08E8aa2yH5ozanPBVX06NK02p9GhN3fm/p/qzjwc ynaP48+MZZjJkIlkHxzK+owldd4mW5Yk2cIbkW2UdULMkGIySMSLLIlmKEv2hlJIKqcZlS2VYlrG kHUoW+jljM7bSV3vWf45V9f57/nd93Vf93Xdz/f53N/7e//xODsy86Cme7TcZ19V9ZK0gz5fuYBi jx97X1aofoeuJoL0OZ/bP1e4JKos6LMj80OknGVj9zvHkS5CloQrQ0/cnZkhs/e8xp1K3T3SHBEx SeAwU88F3ZHzUJBDRiYfCESirLEnt1lcCumeCWhvncAXOaU7RWemUKQseA4tdBb5wsOubp/U0NpM Hw7RF50Nrt3lS1q0u56iI+4ji0xiirz2ng3uMOt9unmU+IC37umy+hu5pIIK+DJKxbCSvfiu7LRZ I+yIuc8RQ+sa4wnrSVo4sQ+uKxgoHYORYyEdmEPU5SFzkUrvnFUbcc2TLXzoSNYFI5Vj9zNSLzBS +vLQVUKul6YLq+KPntngp9EY7g/IZFV+FI+aFz+jdCux06/UHKN1cWDwOPYFcMrTvLsjkdEgsYQM SWktwlZDDf1Wj+VlsURKRer0bQSe38eCJH4Yl99TX/ktflT3C7+lfwa/QX1QF+QSW08HXHOZXJO5 VuqAa+XPs7//id6XqQG1b/ot0lVP+mtuedfMGmzLtVW0qexgSlgrCXO6S7qtKsNA+Y3jsGcOF8T2 ZkoZp1fluILKrwD/kajmibMw4QUkL/co+1jukY5SQv7HWV9p9c9R7xNlxt5bF1FbFe3bU5ZMOwW7 3Kq7aox5CxeLAzJ8X2wdMLOvie8a2mqmqVIRf+Cg3QY2j/qyX1oaGJQw8yuYv3TqeTZtBJ196lMP akbgpn2gXZ1p2mULwNIct1FlG640m/2UP9aycDGuZKP5JkHS5bjJg4QVyEUZGwEyIAKaTd58rWjW +EDD4XK1LMEIE/E4780vZzKoHtB6GaHazwt51yEdCvscVhf57t+TR3yldzl3RUr+Hb3/1Bh+R2+R 9fRe+w81GJvzD/jGpoGxKX+OX6rXFY//uTxJIsRKcaol5WqlVajzLAyl6fN/Q/3/yspy11okO+m+ K8+e7czRusqI/g6i7X5IrWbYcZfADajyjjtRqQ2avaKFyYGeDU7QR9byKJtcZqQhy6mx2vmi9DsZ SHxFI+Hjua6JXyAc1p1UOB89xYI1bS/GPFCezn6f4vcspnU48yO/Fpln9DdVJQX88vxnNiFXU2gB xsI3SVjnn/eHh1xooO685KvRZosc83Q1EM85J2/AgklqLz7GWIZjsGohCPoYHrtKhqPe3IN7nJ9+ 0bB53Prc6TY9NbeilvGmaIRxVK99CJoDtjcSfFxdIJvhm5A9rzblzO26hXOmaWi9XyTHP7Z1HMnH ZwZU7LTqnSe2XJOI9Nw2VZi3TZc/QtKTgZUNlCNNIx6qN3aa0IYWJ6LrB6+Uhuk1WLcdVxRVDkfs sks+fsjMZFMTjVaz35d+2Xg1hoiOKRADcSPGom6S9AIFdJfJqNpo46zFY/XePu0YK2VVCyX3Q2OO U8Wvc/Pb/xrcHKsSxr+RE45uySO1qjjcqPXDnqWGe9QFUVHFLdfMp0WDf0/SDri+8saWnqzIwDXn yySIekOxGtW/pjaw0UP1Ne1edQQHvl4jTZuKzJqrhHIaJeuE5Mv0BNQJBS3tUoEgikvyX1ooU3Ht 6OfjsgcYFzl73y5AfILPIqLpx+jDQWMl2R2YbavINhfXvv1S1L4lrQIDzYPi/gxU0e8YEm82SOLN gEIgYGzCT/TL3wW132JeSuyDNZf2h2wFeTAb1mfI3Hm/VQgMElzfK7bmAb8O5MVwWQTpXdBwtITP G/aQ29o2Fki75OQ1gd7rhmzAOIIOFNWYrcB+4BjgBYQAwV9iaBwQBsgDDgARwHMrX267B/fpKECk Ksco/ctvNIyID/YN8cAfJcr/sJfwkiAAaoFtqu51g1ZXx8f0VFjqjxFEuEegsqPMPaoCTsPi+J+E 9mstDQa9nSLfuFU8tWfHbYlE+NxymXvKjMOTiKN5W3foiJZfujYpNC83dNYbPrElpsawZytW57rE DOtJRnxV5Z7yMlaQ3nVUs1BF9q0epwh0er6B+s079xjAnGxt08t+Tqsur5dRMu7htFzrsnEcu9rV Tnj07qEH3eTfqCxZ+o5czjOQmeZA8KVVQw8O7y5fCV0yynUJHvdCRgaNoRbExJzn9uOf2kqOiZeu tBmScoVOTI0cf50lsST26BP0w7n45GKnG1YX53BuBm53oRqcaSeKly479Zl+EH6ht80qbjuVBJUB SdB1L5cfQ4LCuU38X8RI/mmb/3d5HOwPKVIOgxLrdYj4duEB4c74zx4+jPBaVAbqYfS5Z9LtOlwT 86MMFzAyOlcTMuXvypXpjsKcAif1Wzp/YPOaQEzrB3AvFyfD+2SkcH7G/latD+WRjL641/6fSnhK xh4aqN+614hKPzwwUP1IandRtt6+ibQUwuHneoPjL1SamlUPgW/J8Gsry7iGasIHAWdKolF8koL2 bft6BJ1W1ZNK39ekiC9gFvFY1DyTNTkpP/xKLOv2XgEmEacqZT/MtvQNTcjpKG7xPEJ7tXtIcKBq JewSj1BpRlQ436d97Kr5l3Nvs1ZPjM1k1VGaldwhg1XtkZ3EJ9V/y1lVSnqiWAaA+8CcCUZYi6lZ j5MkzFFNatwOG30OsbMo9OqBvWVJQX3G5GhQ43O6yYQf0nPL7bnkg8qMlztD+jk6mDRhmLfbi9BH APB3v0zBRw0KZW5kc3RyZWFtDQplbmRvYmoNCjEyMjkgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMjMyPj4NCnN0cmVhbQ0KeJxdkE1qxDAMhfc+hZbTxeAkhUIhGNoZCln0h6Y9 gGMrqWFiG8VZ5PaVnWEKFdjw0PvEk+SpO3feJZAfFEyPCUbnLeESVjIIA07Oi7oC60y6qvKbWUch Ge63JeHc+TGItgX5yc0l0QaHJxsGvBPynSyS8xMcvk89636N8YIz+gSVUAosjjzoVcc3PSPIgh07 y32XtiMzf46vLSI0Rdd7GBMsLlEbJO0nFG3FpaB94VICvf3Xb3ZqGM2Ppux+rtndVPW9KuphV4+F vbrylLzsLaJZiThduUiJlQM5j7ejxRAzld8vjyZx7g0KZW5kc3RyZWFtDQplbmRvYmoNCjEyMzAg MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjUwODcvTGVuZ3RoMSA1NjU4OD4+ DQpzdHJlYW0NCnic7Hx7fIzX1v9a+3kmGbnIRRCJSWaMXJhE3EUMmUjiliIIEtVKQgjq0AZVStL2 6CW06FXLwem9TTEJrQQlDr1X9eLSi3PQUj1V1Rvn9JA873fvmYnQ9rTv73f+eD/v22dlffd+9n2v vfbaa48ZxETUCqBT16wxQwcHVfWuJdpTShT95OCs7EERAcFjiW76hkhcMzh35Jioh7ddJJrnJEod PXjM2IF+pt0/EG1ciUYOjxyT0j0kaeEmIkYbVDgua3h+95rhCWirgijswcmziuZsiMn4B1FyBMrU TJ4/1/p8yxLE0/OI/JdPnTNtVnV47+5EXV4nMn04rahsDjmoBfo/jvZCp91wy9SQ1y39iAbh3dy9 tKRoygef+81AWxgP9S5FQsAmgTjPxXvH0llzF3Q62+pxjD2SqN3UG2ZPLrqj/rYXiUaiz3bFs4oW zAn9MTAa5VejvPUPRbNK7vnwmmCi0gVEAdlzZpfNbYwnOf96mT/nppI5OzesiCXquQH51SRlZ2rf qebwtMpJIc7z5hZmks8TcaOKZPjKulEJhv+/VuoXzQ68tlDl5YPQ77mGRyH0/Ya/8b5+sSnH92gy JchNfUmod0GhlCJHop1AvypF388ryURm02OmHmjS4gm1Ipoqwk0m4a+1EMIkdP04dTbqaUGmGgGe vOGZVnKRzdpOP924RI5ETHMRG4aB2sX6/XKmpOv7aZosjVAO+AwH0A46CW7kE+I6TqZPaSU7aDvv p8/pFHKqaC8dpn0cTh/QaW7F+zmViqmEHuRWdITCaDyV0zrKp/VUQTNRo4oKEIukLlRKW8D5VEcr aAzmGUe5NJkOif70Gdb1JHrfSSspGTWWoMYRWgw5vExbaTdG05puoFXIq0DuAbqfrqV+lIpeH6Kz /JBw8oMoEwYqR/uypzFo6TJVoZ6HtntJtuaja710iUdhFLfSCp6tRq3Ewjs4Hf2EY6yz0FIxPQie QG7oa296hk5wIsdTf8xmDn3OZzDPe6gaYxmDmZWjnhxTKTicVhnfYv6fcAPHoZ01GPlkSN6fZoo8 akmt6CIk6aDjaCsMc5CcD+l5qFTRGEXb2Yk+nZwmiKt5O/fjg5DeOPRZB8kcorPCaTTQbWj9IfSX jNVryfN5LE/2apxcl8VoU5YuxzwlLzFOiX3oc6XidXhvQO8ViivQso+7QG6SSyG1fNSTLNtZgRWR PAZSlIxRKC7HDCdAXi9yNK2md2mRcYrDEW9Jghf7WCI9B1k9SiuFRW4QYREWiR72PbwYubK0Z1v8 QvyXHzHNFwGFeHkT1jseu1DDSDKoFrMUmN96DsG4W2BVkIz12oE8wdN5Om2CbkgZ+STnk5JHUoub eCZ0dyYNgJx3NOOXUWMrNGs3ZOWTZ4VXnj6ZeuS5sEmWPo6Dvss1PaL6D4fG5dIc7EqZ7mPkQ7+c dDdGH4RygRQtzNCPHWwml3EJ88kwLsBMHKTv1E4tQY+H1C4tgDTkHn0A45gCvdmHMUxGDxZyIncy FWPVlvEOGs86DeJxtIy2iBBoSgbl0TDOxtjfxLjHYw2zaR4nIrYKPE9pcjmoTulxFdkh/zC6mZLQ ixyBtBbDKN+4SDdRIuhmlIjEiDyjKMcoktQ4CqgTTi5drd14aHcbjHclZLcIejUBYQTe0kALqAfF ov4qsLQkT2P8N2Oew2kQ2UA5aP1pup060h2odR9qS3vyMizCVuphfI0VW4AaM9HzauzwblQq4ngY D+WhoiNvA63m1YjliI6iN7R6tXBqy6iO34Zur+PW9ARt4Jt5KFa3lMuwVlupHlZjKfZfexqJ+Hf0 L/obPU6v0Av0Nm3AKi9F7m76B9b3C5R/SOlnPfLqFL+ryNdyCSzt5XaXqjZli03t8c1Yka1IeUFk 8nIu5I78Gr9GFwU2FR/lR8BH+Qnwm/wJf8RTYNl+4HLO4z5sZn9OoIdR+nMxjN/j7zmYEzgMK3t5 /70pNMFC48f5Sa7iWTwaaWu5mAuhe3GqSCD5qZKhGId8VkLycm/JJwAkn+dhKb+hR8DfoNQ67AUQ RiLttCf9Eb6DD2Hkz/KbKG/BOjiaQl/8P/Bg7GvVCUcUgV0eQG9BQo9A8+t5J/9TjVMZC8S98+PX +Y9Nc/Wleef6k3Adj5KsZCDZzyObpvDqJ8grH2/IUVjfZqFPttDewyrciv0u8810owpruEalN0Kr 5fv3GKt8MB81l+dpvnqfhj16O/2Z1sKSgEU7rDb0goroGkjkE+hGMDTgCUjiOvgHJqzDm6BDWI07 kCt7WUtr+Us+z+exv2fyi/wDf8bxYjKk5sa+yaB4Po6Uz/hr3oMWX4MU1qGvI/Ab3qH9PAM+2320 n3Yqb+4hugcaGEZfQ9t3gl6jx2A/7uTrQLtAO/kxPnZZ2k1SkJoi5WxR+kA8GJRP39PH/E+s1ztI kvYUdhNjeBS7dh+/xfWwg69Ac+vYgZ0RyddzlraYXlf11/PL/BTvVXvcoShRkdFE+yCB5u+XaSBK g5vOz9/Kzc+On+NTsEryzPCdDr+Vrz45mvNk5Xd4WI5B9vELdTiFI+g8GLYQ9jkCdnSB4pmgYtSX nAvN7gTbKs+7gRgz2oI+LOdreQjvBg1RdLPaRVITfdp41S76reEv7rZf2YU/y4+A1zTbob/EV+/c X9nBP9mxvxbKHe1jE0g+Pqvp3eU/CX3W9FfCJuvwC6HPWvxa2CRPWBV4nd+rOELw603r+kscgl3q tabe9fdYIhlO8JA8cXCbyMepUs8bRABOuQgKENGiPc9EShm/zXNBG6mbtAoimuuvXgWf1GHJa5T0 NJz0a2mbz841Z7SXBl9uqQgX0RjDffQjBytf5BHlq7SGHxQOfRsF70MHSy+6DXKTFcsSVfCPZUoF vYidehO6rcB9pDV202fKu9sBK9gaqdKzc2J3tUG9Lcqz2wff6X5YVukvO7HL+qOU9JT/rOgTeCP7 oHP3UzLuNKepBDcKMygA4zFjv/qDAtAXdi6nNPmBPp9T9uyzAX+m5dAVT12ZF4ARSG/zatvjsTHb r/BAJfvsgM+7rwJ5fNo76bQasa8VueMTr7A/0raU4g7XWXlgMxCT97kR6oQvpbtAi0FV9CTKjsV5 NI1ehi8pPeQduFWGQXKtvdJLQ4kROGVWUZmiKkjoKPA+0AHcsyS9h9HJ+2At1kPeCTPwdhY3s+W0 ERq2FVyFXhehVzmDOvoDPLsKlRPgpeKm2HO4TYaDZnEydwYl0xc4DRm+EW5t3CBaipa4b7nULXAh LRS9caLsBDpxTu2UZ4EqsVqRkzfg5tWDh3MB92IX3p24/QFxB5J3t3TsnX7sRO1DCNNAso84rZ1q y9PC6cutybnKOvDnt/NB1adNtqZqJsrPRTz3QsjtGfhwLfH2PMfwXkHobyfGmYjWzbIetOoQWvSc bzN4m3cDJeCtK+dyPLflvqxhJd6DFPrhBOjlmSU0eDC8WQKvou44q+VaL8c6rAe5cCNYjlNZrpxH V+ZB1nW4iexVd/bboDU7VWwr6lXRj9CdRLynYZ8/DL+8r7KfYfLGBQvYCeeKDG/BjrTgRiF7isLq So6Bf++iSagXgZnK2uVocyuk7BTBIpgYlIh2x9NUtXPjqCd26Ep1crWF3y9v5AHYR+Oxv+UNbgXs bhBInmIm2CrJp5rOOzvuEzO9JEtEUiynNe0iufvkHsDJp2rIfvZCDrJ/yb4dcRs8riTsCh/LlgTa moudEYoZyV09CnYwQO3XCCUnjAu+Sg4fxQ2kFr7Jh9wfeBL8lDaUPqUIHsdLsI5IoRPwtp7CexXe VuOd+BvcUlJAco3/you81sJnwzx2rEre9H/CP+eJrIfdvHyrvZKlhyItiLQ+Pm7+mYHkSGiFj32f ITT/LKE5b1G2MrnJEjX/nOFq9n3ucPXnD805FDoj2XdHlh6LZGmlfJ9TSB6L+qlIW4m5Fl9FzR4j 2ojmZtQ8D3vgSrqqngjmU7AKDysOuOqjQKm3q5qRrLMWtM/Yp86m5kTGXFA09tiVRMZXxjjQElC0 4S/HrsaIsXAFV6l2x6t7+bxfm+OvzeW39N2M5K6Td/cw7NHekAP0slnbwkszlc+fCAscoaQrPxyV nxsgz5PTJIE3QTKcDJI14dHAuiU2G4+vTadIhFV4FLrqe+RnivGwb2n0ufxMAPfZx7FvTsIe74Ql 7of+9/PfvSQt7FA+CXuahhuCLBUpWnrbkVraD/ePOGii/BRB0kraxox9dABWSp5et4OroG127qik /zTdAXqaxmFEkTiF5Il1FrXcyFuNt5nIs8DmnKDDuH2HcRtY47bqdj4VnvhFbksH6Vt4SuGwDNdw b7ZzIP1V7XKN3qdG2O2usNfdQBpseSJseD9YdCc4Hrn90NY10O/zqFlADfDMrTjlcmHn2yJNpnST KZdXWrPCr7qT7+dbUPc63At3iSj49r57re9Jo2DYrRic+Bb4OjHIO0Y1GJEDMkpvKiU90nJpQeH5 DgaFKRtUgZ17ADJYoC3DOkTzBpSyKy9L0mpobR1s2c28mo7iLvipulXshy58jHH+p24Rze/qXr/y 6vv3L3r1Pk/9qtB3H7/6Xv4Tz9rniV992yCce7uA8kRfg/OuANp+lkZwO/icBD/zJLRvHPUGLsGK hjR9Sp6sdLEaulSC8hOwJkuwBqlo2199/ij/VWE5tKMvh+AW3I2ngDR4CrmiK88DFcM7dmL99sGz OoT0COhOBOfxCKU9Q7gVbuvn+UZFPTlTahZ/BQ3br/yHeGhfL6ypPBfLcSpcZWXQkoeCPHS1ZWMT qHm69Nhfxu7oDFseos4i6UHkIQxBTNrwKkU71Cd2Ptsuz2Gc3DzeQ7SH9mB9sXcxd7lX56L8HPgm +crXlqeYPLXkKeC53S7iV/k4bh5O5bVV4Jyq4HLPp+i8gEthSxeAKjgOJ1aFOlXm4UQuhcxNFAVJ JPMJ0GLQGUVOn2awfEyaxnAqKdL0VWA9/dNs4NT3MxqpBbXAvSJAYSAFAuGXAIOBl6glBQNDFIZS S2AYhcDrCFfYikKVBxIGbA38F/ZhOLAttQJGUoTxI7WjNsAohdHUFtge+E/s2UhgDLUDxiq0UrTx D9hGiR2oPdBOFuMCvCeJcQrjKQaYQLHGefg6EjuRDdgZ+AN2fgdgEtmByQq7UEfje0qhOGBXhd0o HtidEozvYPE6A3uSA9gL+C00OwnYh5KBqQr7UhfjG9gaif0oBeikbsD+wHM0gLoD06kH0KU+y82g nsCB1AuYqTCLehtnsa/6AAdRKnAw9QUOAX5FQykNOIz6AXOAZ+gacgKHKxxBA4AjKd34EjomcRS5 gKMpAzgG+Hfo5UDgWIXjKNv4Aho8GJivsICGACfQUOM0/BKJE2kY8DqF11OO8Tn2+TXAQhoOLKIR xinsmpGG/ARe4hTKBZbQKOMkvFuJ02g0sFThdMozPsN9ayxwpsIbaJzxKfz18cA/KJxN+cA5wBOw OwXAm+haYBnwOPbFROA8ug44X+HNdL1xDLuiEHgLFQEXUjFwEU02/ka30hTgYioBLgH+FbtwKrCC pgFvU3g7lRpHceZJ/CPNAC6lmcA7gZ/gVnYD8G6aBbwH+DFV0h+AyxQup9nAe2mO8RGs5Y3AFXQT cCWVAXErND7E/p0LfEDhgzTPOAKbMB/4sMJHaAFwNd1iHMaJK/ExuhW4RuFaWmwcoj/REuA6heup 3DhIG+g24J8VPk63A5+gO4wPcGOV+BT9Efi0wmdoqfE+PUt3Ap+ju4DP093Ge7Ax9wBfULiRKoGb gO/SZloGdNNyYLXCGrrPOIBzcgVwq8IXaaXxDr2kcButAtbS/cA64H7Y1AeAO+ghQ36G+ojxNuzj auAuehS4W2E9PWa8Basn8S+0BriX1gL30Z+MN+kVWgd8ldYDXwO+Qa/TBuAbCt+kPwPfoseN1+lt hfvpSeA79BTwAPA1epeeBr6n8H16xniVPqBngQcVHqLngIepyngF1lvih/QC8COFH9NGeLSf0Cbg UYV/pc3GXvob1QCP0RbgcdoKPEEvGn+BXZX4Gb0EPKnwFG0z9sB3qwWeVvgF1Rn19HfaAfxS4Rna CfwKuBtW/WXg17QLeE7hN7Tb2AU/qh74He0Bfk9/MV6mHxSep73AC7QP+A/gTvonvQL8kV4H/kvh RXrD2EGXFDbQm8BGesvYTobC5jY9QNn0gP+TNj3xd5v+u03/3ab/f9j01b/b9N9t+v8om/6/yU/P +m/a9Jzfbfq/tek3/m7Tf/fT/61N3/4/yqaT+qxOcnvvN3OneL6RyzNIh7UhWHMzCfKDdR2OvJus razt5PdnYXObvRufeej4uuN/+sk3fIn96PIXgoUg7zd9mxUA66arq/3y0/Xnkwdf8Tb2t7f3//Co rya/9N+o8B+Tpisjz5U+oL+zX1rf1D69evbo3q1rSpfkJEfnTokJ8XEd7R1s1tgYS/voqHaRbdu0 jmgVHhYa0jI4KDCghdnfz6Rrgikp2z6o0OqOL3Tr8fYhQ5Llu70ICUXNEgrdViQNurKM21qoilmv LOlCyalXlXR5SrqaSnKo1UnO5CRrtt3q3p9lt9byhFH5iN+bZS+wus+q+HAVX6niwYjbbKhgzY4s zbK6udCa7R40v7QyuzALzVUHBmTaM0sCkpOoOiAQ0UDE3G3tc6q57QBWEdE2O61akDkYg3JH2bOy 3e3sWXIEbi0uu2iKO3dUfnZWtM1WkJzk5szJ9mI32Qe6QxyqCGWqbtx+mW5/1Y11upwNLbNWJ9VX Lq8NpeJCR9AU+5SiiflurahA9hHmQL9Z7rYLT0ZefkXj4Zn5dzXPjdYqsyOnW+VrZeVdVveGUfnN c20SCwrQBuqKuEGFlYPQ9XIIMWeMFb2JpQX5bl6KLq1yJnJWnvmV2LNlSuEMq7uFfaC9tHJGIZYm qtJNo2+x1URFuepwVEZlWyvz8u02d3q0vaAoq311BFWOvmVLO5e13ZU5yUnVoWEewVa3DPFGgoKb R0qa8lRMFZexnNFNkmU5IvtQKITbOtmKkeTbMadUCSWpVDk5FcXwFDBquadgRaa7W2QWVoamyXRZ 322KC7VbK88TNMB+9qsrU4q8KX5xoedJRqWeNKka8n1xt8Ph7txZqoh/JtYUYxyg3nslJ82vFdPt c0KtCCA+yoVsiwrSUiB+m00u8LJaFxXjxV0xKt/zbqXi6BpypTgK3KJQ5tT7clqPlTkVvpym6oV2 aPJWtZ1bu83xTX8hoW1aZZemubnNv8ku8eTnjLHnjJqQb82uLPTKNifvijdPfmpTnjfmbpWZr0UL b0xEayoXSjmxqbB8yQ9y63H481NKPaXW3wytVClsHeQOLRziwYIAm+03Vqo1vpG1VHC5mneY7jTH le/9rni/YnhBlRoGrMeLnLwJlZUBV+QNggWqrBxktw6qLKwsqjUqiu3WUHtlnRavxVfOyS70rWit sX1ZtHvQ8gJMopTToK2CBlbb+e5R1S6+e8yE/LpQIuvdefk1gkVm4cCC6o7Iy6+zwuaqVNGUKt+s 8o1yGJpeI8wqK7rORVShcnWVoN4n1zKpNLMvjWlyrfCkhao0PMnb4RTXa/U1Y3u4ahGkqWBLy47d K2QYGKzCmhY90jNStHqaA94MPgDWaRKw3JuiUSwwHSxTV6j8DdoOcoPrwe+CZcp2pGxHynakbEdK ulZLrG3TXqrpGIuut25p17H7uYwobQsZYKGt0pbhmIrVrveGk7zhCoSdEa70hvdqy2r6xYZktMA7 0zmgARaY29qawSO716lIH6eKrPGlrNmClNiMdtpajGotRrUWo1qLUZ0DMlpdg/Q1SF+D9DUqfQ2x asrWyduUN7K2JqSNNwWRjACtQBuHu1uslu8Nx2vjarrH7s4o1Mai6c0KN2h5wBUKJykcqbBc5Zar +GwVn63i6Sqe7o1LTGmGsQpDJGqjtTG4b8Zqo7RhKszVsnEvjdVG4l2GI7ShKhyuDVbhNUiPRJiD cuEIh2nqOzfaULxnIRyCdxkO1gbVZMV2zZiD90nIE+hPpmdhDFkYUxaEJFNWgDeAj6mUScBy8AGw pkqylgXKBGVoGajhQhsu5LhI01ygdNAAbQBy+qNsf6BLc6o5OlHKiZ6ckJUTLTuxPE4sj5P8NSfQ qvWirmAXOBdcCDahnSTUS8K4ktBDkpaMu3qsZhPLKQKh1RvGimXye05ajFhWExPrymghtlIuuBA8 B1whttaYwkMyIlBOlk0BjwRPApeD14M3g82U7slxBYp0ka6NFCM1HdrdaYvT2V2FPXp7wvYWTxgU 1T0k4yatE8TUidaDNQy5E4bcCVP1vcWCBVQngXaDD4CPgaXAEyCMBAgjARNMQP0EVcpPlTsHNsAa lCgB7V9ZxqRqx4JTmrUiUxORkoi3RNRJRNlEpB4Dsqoh83PBK8C7vXkdlDJ3UMrZAW11wGhTgOkq FgKM1TrUiBYhtZAvp4Vk9IHcR4KRKe6FNO+F3O6VGiLkJk5BTrq3xArwZrBJqwN1AiWAEkEdQDaQ FYQV1GKweitBK0D3ge4FLQctw2pEbHbsdohJvWb3Ku+1otf6Xpt77e7lv0MUgQpFoSuA2rTBSRge Zo7KCBU6TaRg/pfCjQpvUuhS2NYVNTH45MTg1ycGPzox+KGJwfkTg0dMDB40MThlYnAtF7vaOoI/ cQSvdASPcwT3dgT3cgT3cAR3cgRnhHEBj6dg2qVwoMLuCjsotPD4mmBqsZOvJZsZGs8JW223xZ6y 1epcE3uHrdaM4HbP27WeoJ9MfCm2q21abJInJd4TdLS9rKMFGssvkD87XEn+b/hP8nf59/Xv4p/s n+if4G/3j/WPMIebQ80tzUHmALPZ7GfWzcJM5oha47jLIW9JEX6hMvDTJeoqHiq/+aMuVCy/+msW NIzcrbQckTNmIOe46ydTTrHVfWGMvZYDcKaa7APZHZ5DOXkDI919HDm1/sZod6ojx90i99r8aub7 CvDmFnfjyMrLr2VDJi2Nlu5rHTEnLb032hsWFMg6+dU633tvAbWZnx6ZHj4grO+grJ+BQi86Lj+R juYvGInF/XDOmHz385YCd3cZMSwFOZCc9HbrRKronZ1VJ/rIoCC/LqBCpGaPlukBFVkFl8uRFelZ dWSTgSpHVlmOrFeVixF9ZLk4GXjKxahyMVeUq+5vy86qttl8ZfqrMv2vLDPtyjLTVJlp3jKap4yt WRn/42RTZWz+x39SJuY3lIn72TLNpFky0PFvHq6jYXy4OnOhvCoU2rNLwIXuZfNLI90VxVZrHWXy Ye8tIr6weHKpDItKavmwvSTLnWnPslYPW/jTfPdCmT3MnlVNC7Pz8qsXukqyaoa5hmXbi7IKtgwu 6rzxiu7u8XVX3bnoZxorko11ln0N3vgz2Rtl9mDZ10bZ10bZ12DXYNWX0nqopZkGFsA3VeEWERgA BS6MthUMbBM6Z4DS5n62yCXR23XiZykQrnoQrn3BYJmVnJGcIbOwy2RWS3kj9GZFLulni97Oz3qz QpEcZh9IkdnTs/BXVuaN/Ma/srKyudeXXV8mQ/VXNnceWC6T/LL3XMIMMoLU+RYLayxt8zLwcmWj tbKygrmk1rRsHsnW5kq43HhTbB5a5rLmSkBlVz9SMxzkYTRXNo9RShac51WbMvmTIDRDcpDeVoj0 0+D7KRphjFaME5uMY17+VP7iWuY3NhiGOILCeV72PHmghxTm8XBPSFPooPpu9SNI68Hv0HPkohCk HySNifPJSQ/QzXSIxhrfItVGT9A5SqK+VGo0qu/SNfJieoI9v25NpQ/k98mEU3PoZ2AcO3NXrYpv p2S0kkcPU1s6gBY7GwF43yIswolaefSWNsmcZHQ1vuN6/Q2jmB5npzisb6K36Sx30KnxDmOZscZY Sy3pB83SsNfoZsxCrbFUSPPoVoyggtbRfi4Q/cVu4x71G+YSpG6jt9gBhSqERzcapf9Iq6mOdtEB +pBOMXMIJ3IFf8AHTdSwr3GfMdQoNmZTNo2gXKpAroXjOENM0CZoG7UjDZ81Hjdi0HYezacFtIhW qN93H6GP6BPWRIDIE2O1jRRN/dUvj1dBZusgyTfoGJu5J6exi+/kF8R8XWvYhxNep9aQ4BAl/VW0 BjJ9ijbTPnqX3kOb36pvVLbD4o/libyYl/J9/CA/xS/wJj4jTOJDTdNu01/VzzQeNgKMx4zn0G80 tScrfN0krME1WM/99CXm15mTOJ3fFw6RpLEe1NDY2MMYbJQbrxhHyE4JKNsffm02DafxGPUtdAft oFdRdz+9Q5/TPyAljQM4HLKwsp1H8xieh1Fs5HPcINpg/VLFDaJGHNQc2n59vL6pYWtj68aaxnON hlFluI29xttqfXujn0yswHU0B1tMrtiL6OcVOkl/p/Pow49jMdYhnIP5rkb7x/gS1MkslogXhAHv d6X2ht5OX904onFW4+rGLUZPYzh0S4PT1Y56gtKgTfK7dGXqe69PqN9ebIH2HKavOZJjuCsP5XGc z4VcyrN5Dt/Ii/hWSPU53so7+DB/wl/j6ugnWkNODjFZ3C4eEFvFPnFYnNRIG4M7zI3aIu0Bbav2 rvaFHqon6V314Xqhfou+0ASXzK+N+e1LbS/NaihueKxhb2OXxqzGmY3LGvc0Hm781Ag0dhun4Ip2 xRgLaBrGuBjzv5Puo/XQj+cxxhN0ms5gzb+DLDRuwVEYcaxat0yMezhGPh4u01RQKc+A/Cu4imt4 J9fzHn6D3+L3+Sifw+W5tegC6oddMFZMxRweE1XCLT4CnRc/4lqepHXXeuBWUYjZ3KXdjfk8oh3V TulCb61308fo5fprJs00xfSwaY1pn+l105d+oX7Xem3EZQuCR3tb7NEHaDfQBtwONO1L8b5w8mJx kZ8RFt6D3iy4b+WKTNEPvtEOaPksivBf42fzs4kICvUvlG2IR0WyNl6P14JorvzVhZgg7hSF9DTv pItiCDRtvrZfbBCTtDX6/foAPoL7xR6dRDBfoAzK4AFYuw/oRqxQsrZZl7+7JJNZu2SaJYKNu/TT JqG9DzvYn4X2Jk/gs5wr2kBa/cR9ZMd7KJ9FOBQ78CNofh3czlT9uLZcDBOfIO0GeoD3YI476Aax gx/HuqRiP97EubxW60ZL+EZIoy/NEA9SBzFHdIA+j6Xv+XZujZ17EWvTUUwlXQsWk+mgKMCqv8vh ogsvgZ7OomVcSUncwPX0tlhFvblE23WpXUOi4EtnuVobQtV8UX9DfwPO90VI0gLNNcPhPgGdXoNe XiWbFg+tSSWTwD0O+6kQez1MnOdbxQ00nVdrf+enRAaNpBKtTAzihxvP6xlaD0hsO6xJpl9fM5mc JoveEyt+mgao30CRX6l+zHS7jGsfaD8YBYatcZKpZeNRWgjpDIF1W4a9NIQ+5jZ8PY/SDZGjG8Y4 qhKb9aNGWw5iG71nYIc1vshO7mhY+UYjkEdBw6+X/weJvkxfqs/Tb8XZdBFW8066nx6jv+A0eRLn VgLkeA2kORG2ZzrOiK7UnXphdgNoIKzSUOTl0jjY00JYyan0B7oRlvdP9AJV44TKgTyuR72pNAPp ZTihFtES7P+7aDlswMP0NL0nnhfrcce9W7wi5ovp9DF9rL2muXgcHdTv0ctpDO7Ao7gVeu6DVYpF veXGB+itE0XD+vfELoXeG2eMw8azDQfQ3tPyF19+A+mMXyYl0ki+oEexCfYNMtSnmeS/5/jToGo/ /1oO2iqYTLqMaBTgZ0LkJU0TUS38ZdpLTO3MIxdFOkaE/uAc3uAcEXrBOTy0AZd6Z4NTcreuPcJs YXG2MNs0nS5ZtfpLLhNdJKtej/10xvhUfGoy4SSKpZGukMOBpwKF2T+AQrnV3Cg0v83VKpiiAtts Ch3AAQMsm3CN8mf/nWIoTodGHkGRjtAL1509eTL05ElKTz8bepbDwvvir1tXmEXNz8/eIT5Bi+/V s3eP7m1aR2gK/exIRZLYFi/ahoW3FXEixW7vUpLg6D+gswT9/oYJ1qgoq3g6MrBDly72gEvm/o4k Z//OyU55PwoQz2h79PfVbwkLq1uaasWdrgAOaCH/x5qAIy22iycpUOxyBVnDdocdCDsWdi7MFLad 25AQu7aYsfdrxZMvdjXPxr1sp3gUp/m3nOuZxw9nQxswmx/OQnbOUCfkiWnYvLO4HEFfg/ys7dpZ /XiaikZGWU36+41R8bGx8fy5J8RYIrGS9fCsUkWCK+1Ty+cxYhANS63HqfwBf9j+PcsFusAXLAFx lGBJiIlPHdx+fPtnY+piDtJBPmj5kr+wBOfHcFA4hutqtT6EQ0JiQ0RIp1YhIeGtLEGxcTI9lDrk dhAdOsV36BAXb4lN6SUTA7v36N29e6/elpRAk3o399DNZpNuCYxu7WkskkMiYyNFZKeIyMjWEZbo LokyvSU5cnFidUpwOBITLF1qjWWu9hYma3uLJYZFBEuMSSWKscREIAlytLgCY+Iw25iY9pZ4lu/D 2rePTu0jtNbx0aJLSkLv+JSUwMAgvVV8kDk+ITXVEhNj6dM7JsEFxy02YVLC7ITNCbsTTAmuhE49 E1zhvUISViS8m3A84Ruk1YoTrtaWWJ7EYgUf+C/2vgc+qurYf+4999xsckMIScg/QnLZJJsIm91A IgKiRkVEIYCINCIgIQkQCEkI4a8UEVGRhxgRKCJSRKRIERGVIg9RKdJUKUWKlFKkSCkixb9FS3kQ 3vfM3SQb/vjU2trf7wOHmTNn7pw5/2bmnnOzd1d91txISjJ03Wi9UZ+cFxttCyPGSO4T/dvoP0V/ Gm1EJ3TeWsFeMDj/Y6xeYkLkx/EtOvud/4PHoji4Xbux8ZFHE+EdDjcSXnJWrXTXSJWB7soLf/Zj 5sGcH5K+dg/9eNtDLl98O/njyG3t4iny7DVRnf3xWuSXg09uCy6NbVK8dOHCajCzqrGDaSw2Rakt Aj7Shn0kJ6dFaoDQtHrvuVBEXzq07rXIJ5MTE5Pr3lb45isV3ok7W+edKYmJKbndFa57J7lVYsqT Udrd+p/OxMZFR8XHR0XHieNx0dFxZ736HpUH89Vfeaed+5Pxc3U2oLb0wYZb2o5si63URn0tzEVq 0q9JqWtuV3K8YkW28se1ahUf504Oi3Vnhg4O26gVvZTZJjwWeZ7tbhOTTOFWTIh60BGXEmpPV7tm TUv0preZHqlFbtTmvNSu7fT4jZr3Abjj2I8RygaPRUjrqtbpuuvUihzB/5OIL50vPbfts3uui729 57q02wYWvBThinJ16nQn9VwXHmC9ivPCifV2TMamc6fIc+7Dl1JdaQmd+N+dNFirn9vUK5Wzq/lF 6IqrX4ToXE+q22wZE5vToaOhV6o5fWveB1XvTp787rgDC7lcuW/Bwn37Fi7YZ3z4P2PUVP6sdvKh iZP+NKVW2x+P4pnaZQcOLPvp++8jQvwcEWKgmIjzWsu8mKkRmje0T9ioqMlRD0ctNJ+KDklyq0m1 UmpTU1Lcqe6kVi036WspXsvLC2XHdbdql64k+mT2TsvMTE9zt7MiYviPxDKkGW5FMRGRYWnpV1M7 M+y6yDZGSMurW7mvhoOGNQ/5LEQPScyiGDuteWrf1OmpNanLUj9LNVMTvGfnOk7k3EuODkYszFee cN3HH6u7iRPeAXGdtRadO38jgz+57UVTv7G/evx07o2XWqXlahvPHVrfIjEXp9M722djcVoEFueV 6JiI2KgkXgv1ak7Ljh0D64HA61FzH9KizcX9Q9dXPHNTz/sSosMiolNzE6568nWtWq3H2THJiQkp 7zypsBi2Z/4dJYnRCSHRqYkFP6/LVesTF9UiTt+slka9u6inGF31cYSbXl54SBpZic2NhIi+96k5 ORJ5lPz5H6t7gtOk0xPDOPOWcjZxNbCeonxIAWxcS9cf0d+B74RSl7w4L7Z2OoUYG7TQN3Var/2t uZ6i6/pGrfylMI1WvKq1xl2IrtMiz6ob0ccU+XHgNtpGM3mMV2mbtBZ1v2/lSUgVxodn93VITQgL 5y30VYH0WMN3bX2vSe/xrdJXl07i9f9H09H6hJPj5XQ5XU6X0+V0OV1Ol9PldDldTpfT5XQ5XU6X 0+V0OV1Ol9PldDldTv8fJP4bSxddfY+d8+14o5wPLvEHtmO5pGidIrRsqn8bd6B2bYA2gmQkxfOv 9yjapCRtXYAOoe0NMi7KppUBOhQyOwJ0M32xdqzhXdIrjRkBWiPL+EWA1ilEJgZoQVmyTYA2gmQk hcveAdqkCDkwQIdQUYOMi+KN9wJ0KGRGBuhmWr6coN4uNgTaCjd/ybT63Eqk+TumTeb/mekQ5n/K tIvpc0yHBubQoZ05dGhnDh3amUOHNoJknDl0aGcOHdqZQ4d25tChnTl0aGcOFR0W1H9L9S2kOdPh QfwIRYekMB2p+hbiZzoadFTINUzHBMm35DE6dGwQP4Hr9mG6Fbfl6GwdJJMSRKex/GCm2zI9muks picr2hXUf1dQW+FB/PD6sTxHNnXAjGRTJ1D9aSSVIM+nCioHVNNkqmTOjShVgVa4EPxSlvDhyvVU hmRTP/BGoH41jeNSCXL1TYUTgIshqTSMR7mUuTb1Rj4ReSnLFwKqWXcx+GOQV9Fo8Cpo+Hfol9Ja zhqdenegVIqS6olNt4Mq5JLTcjm4ftZgs+6RgR4WcY/LuV+lLO3jcY0At4x7eH5/ulxilF14Fqqg ob5/V0JXeySbMqGlFG1V4co4Hm81XUEDLiHfVL+jvS9GpD5j3QPXJnK/1Ch74lo1UhlL3sn1bJ7Z ycjH8+o4M+SswHBuqZpnRJUrud4Ynrf6mRvGdetn9SbMay+sv1O3KuhKJY+mGK0UsUZnNSZyW0XA F2/XKSvZIvR6PFtCMctWABfz9Uqe+ckN6+a0VRrQUBTQVcJYWad9wciVRBlTmah3BXJlb8Ma2rpY v8ov0P3NZ6lRezFrGgFeFVuTY1dFDVZ78dE3WnLTfl0dNAdqJM5Yqrm9en9Q+p2xFrNtqJFXsI9d fKTOTBc2mdWSgF+c7x1qVqshN55rqt5O4NGUNOhRkmWQ+No1es7ukJ3dye4/ssTOryivqJ5cWWLf WFFVWVFVWF1aUe6zry8rs/uVjhhZPc7uVzKupGpCSbHvxorxVaUlVXbvkol26Ti70K6uKiwuGVNY NdquGH5JXXZpuV2Na3eUl1aXFNu3VxdWl6ByebG/osquwJUqu6hifHk1VI/z9SsZMb6ssKpeT5eg JrtMKKkap/Rd6Wvf3s7MLy2qqhhXMbz6igFB/IA8xPvent+/R8XEwqpiu2dJdXVZSdWdFePtMYWT 7fHjStAhDGB4RXm1XTjOriypGlNarTo3bDJ39aY7el2Pq1VcqKyqKB5fVK2GMXFkadHIoLrIS8uL ysYXo2p1hV1cOq6yDA1gbKhVCoEiSJWUV/tsu77xivKyyXZm6RV2yZhhqlajrvJ66Yt2icWLS8tH 2FUl4zBXRWpqg5rnSQ7oupp7kFmKVqpLxqh1qCpFq8UVE8vLKgqDG0WnC52uYo4blqNifHXl+Gq7 uGRCaVGJkhlZUlZ53ogQBCvYBQthbOUw9grlgFozGNgolD/iAF1/3Qn9ymk4TIrF4kXxmngd8KrY JNYE6VLSpQ3lD1h3SZO2SppoY31GstHe6GncbFwD3BnShXAK5W7OTWKktk57Gvs1FQSuh3xV4PZS WL9nxL+6VP4M/AXfC8ISaqeUpn7i0PkWFwrHtq4b7+2GAO8FT/0OkaB9+hzS9Ef0J0joi/XFoJ/U nwS9RF8C+il9Keif6p+B/lw/BfofQpImTBFCQriEC3SowC5LhIlw0M1EC9JFlIgFJ07EgRMvEkG3 Eq1AJ4kk0K1FR9BXie6QvFn0BKeXuAf0VPFj8KeJe0FPFydBfynOgD5rYDyGZuhqv6h2dEaY2l8Z zbBTEkasEQc63kArRisjCXRrIxV0muEBnWFgr2VkG+1BdzByQV9pdAR9lYF9l3GtkQf6euMW0Lca PUH3MnqD7mP0Ad3X+BFaLDCGgx5hlIEeY9yDq1ONe0FPN54GvVxmkCYzZTsS0mteT5p5g9mDhHmL eSvonubtoPub/UHfYRaAvtPEHtgsNUeRbo42sR8zy8wy0GPMMaDLzQmgJ5oTITPJnATOZHM66PvM GeDfbz4Kusb8CfiLXG9jx/aO6yMSruNWM9KsCAtzbsVZ6I+VabUF3c5qD7qDlUO6lWvdDLqHhb5Z t1i9QOdb2Elafa2+oG+zbgPdz7oddH/rTtADw3ti59crPJ/08N7hL6iXTAOWpiAM7rKHRGFV4TCK GVkyrIo6lBVWl9O1uKLd0a+bTTFEsDzdsVWmNP7NOuKSxr/tqffq38Om2H598m1KYj41wVIFabIZ t2WcO2b0mNE0kPGwhrOT3oRqgZ29iV28S303HVmw+2YUQc3RnvrlyWj0rCV7geDeOHkyet4dLjgA vqE+0z+BpvHbMAtpKa2hLbSDDtJR+oS+0sI1r5arddW6ab20/togrVgrc2ZF6wg9GvJTaB95uI1e II/o6uSRznlKi1zlyLXIQw+RR8WgHII8z+FHDQ3ku508ZhPLGXFlcdPj5set4pIZfzD+iwQzITHB l3CDcz1xa+LexOOJdc71VutabWu1r9WJJEqKcfS0nu/kydOdPGUgS7rsXLuHPcSutmfby+wN9g7m NkvbnLYr7UjaqfTwdDs9N71H+qD0yvSZ6YvS1zi99hTzbzRontmONs88J88oc/Irpjh523WOnHdL IN/OlqB56/i3JQ3q8D85//rE70uq6EUct1wcscIQpaLJ4gjUzDBx4oyCH2dSNHtwDHy3D7Uy+8GD bfjuAHKbBfDgNPhZS0qHlwygLKsAvpJNWmi30OXqjISo2oHI2x0AD/PtRN4PUAB6D3LEXW8xYAJg FmALUTYioW8/6MrA9S6AvADgbJtzA/KpgLmA+YAZgMWAZYCVgXwNYD1gI3QdQr4NgOjgO4p8F/IT 0LMK0APQG4B7Rg5O6zlDkQ8HlAHWAl4GbAK8Adiut/KG+zKzlvqHe9N8Poa2vjxvW3+V9wZfsX+S f1qWy3fae9B3OivRN0SBt8w3wzuUYb53qH+m92XfFgVZHXyfMET4hvhnO7JZHsBR3+GsPf4bvMnQ rSA+AGtRT0GUrwsgN+sQ5PZDbiDq16CdKMhE1ffH1wv9GeKf5CvOWg2dm3E929edoQf4C1HuCFpB b5SXNOnnLPRzeVB5LkMV6OEMc727AdN8axhm+tZkbUC+Cn1bFejjG4Dtvm0BeJthB2gFu0HvZt4B hoOgDwaVj4BW8Nn/AQd9xwLwNtp92zsJtIIzoNeyDmcdML9ZMRjfEfTpIOY9sC5Z3vPmf4A/KmsQ oNqfnDUF5aX+bIYVvrf90J+12t/Ru9a/1tvfmb+sdcHgD68ff9ZRfw+1fsh78zo6dvEy1qQ7w8FA v2zUAzSsr7OuXRrWMXg+1zbq9Xb1dfdvClq389dRrb2z/qPQ7htY834M/X2V/u0ony9/Yf0C2PMO 1J+A+rsxpzMCMDcATcuNdrKYQZWruLwMsDJYHjYbLL+S5WfDdhTU+NYHYCPD7AAsxLWFfN3hL/Gt 8e9DeTnyJYH8IPJNmKdNAdt7IzB3Xwf1cgF/bLDPfb5dgL1B9ruXodF+9zJs9x1mOAh5BfX2exy2 dzzITr9imzyWpYM+w3bbdP2PsE10Z5uELV5w/ThoxBSODR6+znbcYM8uh4Y9n2Q4P67U2/m1KB9B GbT/OMrdUP5MXfdTVgf/V1kR/nD/bP8Zlu0EqI9HoLN1lG/1Dcl2qbLfzNb9ZlaiPzzLA+jkp2w9 O8KRV+WAfF/Iw++yhvmjshPhV9PhV/NQHomyjfKDKC9CuRxlD8pz/MnZndgP4+GH8fDDtKwp/raO 32V7Yb9T/duzO8DXOnpX+ddmbfB3zNqJfLW/a+N1xF/mo9wYrxbD7harGMiwFW01+m2UggtsY+3F Iav2PNgZgHqfP4H8C47Jxf4a9KVe7qgvD9f7Q24g8qFZpzB/CuocCLKtXU1s6wjKCupjG9YNNnuS 41InZ5067OuwUPkD+0T9vWUnxrYBaxHIvW1zPAw3+Kf5FyK2d0R8UNA7xwsfKnZiRk4HjlUL/dMQ L3p5s1HujzLmNKeTr1dOp4byyxfIq5hUAzuuvxcND8z9RWME7oGzc64FdMu5Nacv8gEN837+PeKM 4zv1PpUzzHeMYRDoQY3XA/SFvnVe+WK+wFDvC8oP2BdyRvpn55TnTPdnM1SjvSm4BzS9J5zO2pDz YNbOnAfr5yVnjr9jzrxsNadDclYAFqG8tLF8/j2mIfacH4MC4/8X79B0itM/xRmWcPZESeTgBBor 7sMZMxGnvNtortEfZ70a6ZXP0Hy5Uj6nhcu1cpsWKbfL7VqGrDU1LRMdkNow02U204rNSDNWG2XG m4naWDPJTNKqzWTzKm282cW8TnsUp7xibYE53BypPR02NmystgLnsmTtWesuq1Z7HmeEdXpE437R HQtIIi1tKXI3IBP0CuQ+QC4A+0l3AQB7QA/OEmmrQecFrocBIgOAveMVUch7AbCXdGOv6cb+0419 pBv7S/eEQI79pBv7SPcs6FqHHPtKN879aRuQL0O+GXomAeIByYA0QFvs6bORdwR0BUwDzATMBtQA FuJs5cFMd6FuOEcV4HRWhlPUdJpN83GGWkXraTNtp12ke85kuDL0DIw/I8xTlxGZYYAK95zMiPKc BqV7jmdEeD6D3KmMMFyNBfWJZ29GVEY8qCOeHZ4znt2g9nu2onYYapiejZ5jni1cd63nuOcrXK3z rPDs8awGddqz2LPXcxjUV54azxuehaC+8DyI2jtBzYfuNR6crT2zUXOtZxOo6Z6RnkWeclATPENQ e+W/3DYFP+cgswKnfxefuSNhI1HaVJyUwmmT+lXnlC8A6EFKHZGNc6uNdbex5jbsxYaN2Fjj1MPI k5xrKdj7p5xwwIZ9eT5BngmAjdiwHRu2Y8OubNiK3S+Qw8Zs2I0Nu7FhJzbsxYatZOC84DkJOA0a R9gMEwA7w4pQxkAAzhEZOEfg7EcZVdQufUX66vR16RvSN6dvTa9N35m+J31/+qH0o+kngDekf+GZ AIlT6XXpKzyGwoC69HWeME+kJxbwtmeqZ4ZnlmcuVmexZxdW74DnsOcY/17e5zrmQT+pf0m6/nes iMErYvKKuLAiURTKKxLGK9KcVySSV6QFVqQ3xfOKJJkDsCLJWIsoSrFisCJpvCIeXpEr/o0tafy7 mGqV21IIZhueaON0Z+NUZ+N0Z+NkZ+Nkl+6hkLTtaTvSdqftSzuYdiQ9Uf2FVv+b/jf08Sv9K9JE NKxRN/vA6gTs7Q4y2N6kFW1Fk/mtpXvgZG5/D6fuCP0RfQFa/Yn+BIXyc8Vwfq7VzLXD9VuKcL3r 2k1Rrr2uvRTj2uf6A7V0/dH1R4pzfeD6gOJdR1x/oQTXMdcxasVPtJL4OVUK5mstvcyzFqWeqSBm 5rvd7ky3z53r7uKe785zd3f3Au7nLmizwj3EXewe5a50T3BPbbOzzU73jDbr3LParEOqcy92F7jn updBsl+bFUjrHHA7/4I1NuorVrqUpiA983G9ANQ8cOY1Tepph75QfdOzvkx/DXPxpv4WJeu/0o9S qjnFnEI3qjsEdbNSLA/dxM9q1RukUYEnbbEN9Q3Ux11BX6lvIqlvhq5ErqO+rTuR3Dwf6i+4lBYO GE6aPU09EeMnuNCBNpS15TXOmz2Uou2BSLvtfYCDKqVNR7o1rW/agLRBacPSRqaVp1WnTeE+LILu UP1n+s/Qh+d13MX0F/QXoH+9vp6E/or+Cnr43+iVxNhqycWjCuMeWohms7RavuP1oxaB6PTdQUt9 m/JTliGtBKxhyknB9MXKKq0/j7/+IjIqbbwE/9umr+vj+f27VF8u1p+V374vWIEw9kJiL9TYC3X2 QpO90MVeGMpeaLEXhrMXNoMXfkTNv7EVa3p3fR5sORx7gESi1og5QUAXgUvxLyUbrEtvc4jz/NZz LkirkerpdUgXSsxpPQ9pTusNrQ9d9KqTNrc+CrwIqSl/a+udDXRt6xNBV75gzqmv0Rncq52t64D3 MP7n09eP2hmv0+L+Jj2Zc94Yg0f3bcf1TycVLxruHz9B7HkCd5Ew1zuud2Cbu1y7YJvvud6DbR5w HcK95M+uP1M03ydirHwrn+KsPlYfiud7RsK3ir8FgL6Aco7AcaQ+o7SC5qLUNRCV41huG6lf19Zo f6OcFkmnUYppkFMR+En4GnZ5TvvcWjK3pj6r42IfJPZBg33QZB8MYR8MZR8MYx+0+E7Y7HvWpGaD eDYkz0b6D6xJzav6WwGiE+3hOYxnnvrEmvqbQ10jTzOdddKSgnjJvEqalhvE6+isk9YriNefV0nT RgV4Oln/lK0pK4u/5NqYrIlYk8aadNYkWJOLdYResrahvi8XPXsM/dO4Zya3F3LJGkKfq9cExiK4 n8Yl1+jbyH59Ty5W45uNXHnYYprJ6+l4TgKvuuNzGryvnqdj77eI1zNYbrmzmrQxwPv+/Orr/Tf4 6oWj/2ZX1Zj2BGzeGVMi876gA2zzQTwtjE4GzZHDyw3YfDCvV8Dmg3mjAjZfz/vXWvz3Z7P/nD/9 p1q8RhtoB+/F1epQPM7a8Thrt9xC+THb/1OTGrPrd67fYXSHXYcxug9dH5L+zXeFtJ42NZ5TorFr i5tK+dF7kQ4oHNef6YY8cOVAUOm81CgZc4MDQfUargfpu1BXECdmU9OkfNT1e9f+7zrCqDqG/Nhp SDORpkVHRUepUvQ+xkMZZzt5gEaKnV1fVjUcyUaZhjQzeke9xkZ99XKsJ0hD7LSok1Eno6c1TTzC Pa6j32J/pGtpfPpeE4gkrfi3vJdrSzQvyouCubpL1zV1Ap7RhFuuj9ROoVzWhLtH36kPQXlAMFd0 Ebm62mflNeEuE4tFW5TbBnF1g0RNUIRrFTS2KH25/gzG9qy+ElH3Of05+PUafQ3Oquv0dRj5Rn0j hWDkb5JL34bxh+q/1XchPu7Wf0fN9Pf096i5vk/fR5H6fn0/tdAP6Yeg88+6iom2ZSMmplqp1NJK t9J55b8uavx7+6JO7o8wfuwHbPuJH6Ttx37Atuf9gG3P/wHbXvADtv0ER6cOKg5p9Z9WS2JeW8Qs jT5rwnPzueFAE16ipnaRtU14UVo4Si834YVp6tNNy5rwdDqD0pxgHs6CJ4P2dUmBfd2JoH2dwztO R4L2dQ7vMO//ujbh7eczUWYT3m7eR8Q08FQkVxGHeB+i8T5E532IwD7kIHbDh7AbCWniIQ0W6zrQ xHoVfjyI79B7Gq1M7XEaVv2RIPqxRjpYJlB3QZBOh36/ifWocWWS+oGSWPXJQB5Z60Y5jELJrSfn 2ahGYfyt22EN5SZ34YgjRM07Ub5V/p+agk4K33Cfoa3SPuHnqVUYN7bnpEVENIAqnw8OXw+CQeeV hzXQWsRIQDnnDs9F+WHZP2A6+IO2/p3T93bG+qa7z8NaLNt9d8Jqh/sAuUShlReH8LAAXdAI4bGU 7+r+3VM4/TO1/6/0Hc/138mnQtaSFjKtAVT5fGjKH3qhjCuxURZ0PdTz8s0D/8HpcAD+w9K/3afU 551PB50l1F/nXHWVZ48Ep29x11U7DI29VN3Has91qr+v6YWyJeNk4GLG42Q20xrzM4FHMb9AvZGr u4185mcAl8oi4DyjEHiD0Yv5zVVd4zbgQUY/vqpkxvDVu4z5fFXRVxl3MX1E0ay/H0veFZBXV7eK 1cDZ6i1fPdvcyvRnTA9RWOxR2OjEeBtfRW9FuOKLcGOJwnIOY2KsnsduFYsUNoYyncv4DHOUhs2s rUDV0k7KWkUHOJOAPYoD/gFFc+seruWRxYznMFafyx+irmpDVB+AtzF2WtzDbXVSmCW3Gl8xPYkx 95Bb36rq6t1YfzdVV+/Ga9GN6x5iyRqmvQG8hPlKZw1rWCGXAU9VWJ9p3A9sM54iDwOfks8Ar5Nn MTOVEvahz1bzLPaYXoXVPIOuUXzFwVU18y4e9WbGs7lvsx2a+zabZ2C2vopnZijPBvdTcbQaUcl9 3sb0HqbXMR2u+s8yXtZ297n2jJWNVZ3rDDzh3O3AI8+pde937jngT849qVZcWbI+/+x+RStMp+vU c9nTbOG1TNfWqf3fQoX1KMXX1iq+HlW3gfExtaYBjupV1VlYqRahrmpVLB9RV8n4WsVhvpfrFnDr BVy3QLWubQ30wVY01x3CrZ/m1jez/hrWs5Vb8bJMjSPJfT5dt0bxeURRDlbyoJXv7OcWo1gmXmHd w3qG1PEcKkynmVOjeqXVKBo6oYGO8mysZm0u1lMsE3hmlORJXpFbAzOmeniIV+okr+BJtq6TbFcR zngdC+dRe1nDDpa8lefnpLJDmsPjjXf0swcVKN/R4vlqrbJbOqB0osU13Nv9zF/C/GXqGY7i08ts yTvlr6DhfvkK8BXKbjHS/TxStkBlq6T+aeeWMF7He/gOTG9j2jlj8Unm3CgdGs5FMr1PYZzgFD2L cbVT69zfgU0lWcdPnrQVrME5R51mmV4KowdUf27C3KloUMCcLxm/znWrmH6e8R+YM5Vp5zTonOt+ xng9498y3s2SNYwPMWchYz5XavFMH2f8ksK683zrtQCN04m4iWd4O3t37rkBqLVRYfD7Mj9G0Uat ok03c7aomKBkaLuBU5medHY7071UXUVDA862+gdmAeM8hdXKilgVIYWt3jcDLlB6lLxYpLBebPZh /BLbXi3TK9RccYTpbU5VnJA4jvAq8nQzI9TVkALm72LMtLmD4+EkpmtYG1sXa+gW4Bzgq6zzrLrL FNeNBl58VsXVCWd/oe4yZ3/NVxV9i3E734Pq+B70PN+blI8/JnH/1O899xSwz/iSNV/DdR9n/cPV VfNZpcFU2iYwfsW8T937mF/MdD81w3o/6ea727usfz/jWm7xS8avq6vqUxL6BKl6fpfZk/ENwNHm H5UGsyX7LMcE9tZl7I/Z7KH31bUAzmO8g+9W0Sp20e85gm1V9ylgdfb7jGPCHNazWcVh3OkUdilM texZQ5RH02n26yFqhkGr+1S0sii0quzfZJvv4fhU4NScpfyd7XMI460sY7NNehh3Yz4/X3WemiAe KZm5jKcojB4ofITxZtbcQ2kmOhfLrWxhjN3CuSF1HynMet5m/CbjTwj7ENRR9Aus4TrGq504Qeqd wge1cgp+p7AHv1M4oOGdwmR+L1D97oOJXVlzaoErBvPUHi2EQrGniqQoskg2vGmo87OEpu8aJge9 ZajhhODkERRdVDSmkqoZT2E8vbisdATNGl5aXkhzGc8vLS+tpsWMl5WOqyijlYzXQLCQ1jPeWFZR VEZbGG9j/PaYkuJS2sV4b5XSeYDxYR673oB1fmeReHeosAzCIUHYCMJWEBaBuSTeYSpsBmFXAEdg Bjzko44XfevRqVcZyCc47/HRHGfXqg0CDkU+IZDXOLm528nDvJBH3my7Uy/iRODtx7UOv0XgbcQW gfcEW6gfM8Dqhfdm/dXqM4NkhISHNAuJCGnOf1v6h4ruWopm85uDW6ElntzkRe/z6Fbqjx4rLzFE lPqkJlM3N1A9GqhbGqhbG6ieTJloMYYSycaceFnL56zhC679N655kmt9yTW+Ut98AyuLxyymCZwk 9FMijmslcq1Ylk9Q8upUQOGiJeuJ4brqr4afo1USISKEQviTmC4+dQpzunmvzhYrnC//CRNhvIcO 53mAhPjIjBGPKwkz1oyFGySaOFGqz58rCW0ArRLJwhZpIlN4hU90EB3FDDFTPChmidlirqgR88VC sVgsFcvFSrFarBFrxTqxXmwQm8QWsVVsF2+LnWK32Cv2i4PisDgqjosT4hPxmfjCuM24Q2ZJv2wv c+SV8irZWV4jr5c3yVvkbTJf3iHvlINloSyRpXKMrJBj5Tg5Xk6Uk+U98sfyXnmfvF8+IB+SD8v/ ko/IR+Xj8ifySflT+Yz8mXxBviR/If9bvi7flL+Ub8la+Rv5rnxP/kG+Lz+Qf5EfyY/l5/JL+Q95 1tRMaYaazcwWZkszxWxjpprpZoZ5hdnOzDL9ZnvzSvMq82rzGvM6c6A5xBxmjrTirUQryRpkDbWK rZFWmVVpVVuTrKnWdGum9aA125przbMWWoutpdZya6W12lprrbc2WJusLdZWa5ul/uK5SrQWrbEa KSIFq5EqUklXv3OM1Wgn2sGKskQWSdFetCdTXCmuxJreJ+4jl7hf3E+h4gHxAIWJh8RDZImHxcOw hkfEI9RMPCoepQjxOFazuVggFlCkeEI8QS3EU+IpihJPi6cpWjwrnqUY8Zx4jlqKn4ufU6x4XjxP ceIF8QLFixfFi5QgXhGvUKL6/WVqJV4Tr1GSeFO8Sa3FWwKnWvFr8WtKEb8RvyFbvCvepTbiPfEe ucUfxB8oVbwv3ocFfyA+oHTxF/EX8oiPxEeUIf4q/kqZ4mPxMV0hPhWfUlvxufic2hl9jb7kNfob /SlLeqWXfBKJ/DIbp9Rs2UF2oPYyV+ZSB9lRdqQc2Ul2olzZVXalK2WezKOOspvsRlfJHrIHdZK9 ZC/qLPti59NF9pf96WpZIAuoqxwkB9E1cqgcStfKYtwlr5Mj5UjKk2WyjK6X5bhj3iArZSXdKKtk FXWT1bKabpIT5ATqLifhnniznCKnUA85FXftW+Q0OY1uldPldOopZ8gZ1EvOlDMpXz4oH6Tecpac RX3kbDmb+so5uJPeJufKudRPzpPz6Ha5UC6k/nKxXEx3yKVyKQ2Qy+Vy+pFcKVdSgVwr19Kdcr1c TwPlBrmB7pKb5CYaJLdgzzZYviHfoCFyq9xKd8ttchsNhV3XUqHcIXfQMLlL7qIiuUfuoWK5T+6j EnkAe6Th8pA8RCPkEXmERspj8hiVyhPyBI2Sn+HEN1qelCepTJ6Sp2iMPCPPULmpAnuFaZgGVZou 00VjzXAznKrMSDOSxpkxZgyp91KSabxpmzZNMN3YVU4008w0mmR6TA9NNjPNTJpitjXb0j2mF3u/ qabP9NGPzWwzm6aZuWYu3Wt2NDvSdLOL2YXuM7uaXWmGea15Ld1v3mneSTPNweZgesAsNAvpQXOE OYIesuKsOJplJVgJ9LDV2mpNs627rLvov6y7rbtpjlVkFdEj1ghrBM21Rluj6VGrwqqgGmucNY4e syZaE2medY91Dz1u3WvdS/Ot+637aYH1gPUALbQeth6mn1iPWI/QIusx6zF6wlpgLaDF1hPWE/Sk 9ZT1FC2xnraepqesZ61naan1nPUc/dR63nqellkvWi/S09Yr1iu03HrVepWesV6zXqMV1pvWm/Ss 9Uvrl7TSest6C/t+HeeA0cItPKKtyBa54qSYI+aJRWKJWCZWiFXiZbFRbBZviG2iVuwQu8QesU8c EIfEEXEM8fKEOGncbvxIXi2vkzfKm2VPebvsI38k75J3yyI5Qo6Wj8kF8gn5lHxaPidflK/IV+Vr 0OGRv5LvyN/K38nfyz/KP8k/yw/lX+Wn8m/y7/J/5DlxzLSE24w2E8wO5iBzqFlsJVtDrGHWcGuU VW5VWROsKdY0a5Y1x6qx5luLrCXWMmuFtcpaY62zXrY2WputNyz1GezRHMmII5nGkUznGCY4hhkc wyTHKpOjVAjHJxfHp1COT2EcnyyOT+Ech5pxHIrgONSc41Akx6EWHIeiOA5FcxyK4TjUkuNQLMeh OI5D8RyHEjgOJXIcasVxKIljT2uOPckce1I4rtgcV9pwXHFzXEnluJLGcSWd44qH40oGx5VMjitX cFxpy3GlHccVL3v8/1Z3HlBRJN0e7+meHsKQBESQnGRI0jPkLCCISAZBCUrOYciCSBhJBsQAqEgS VgHBsIKAIoIRBUSBFSNBMSdcUBFReD0ljrqf+/ad8977PB9z6LnVXX071e9ft6q7a1QB8YsB8WqA eAwQTwWs0wDr6oB1DcC6JmBdC1CuDSjXAZTrAsr1AOX6gHIDQLkhoNwIUG4MKF8CKDcBlJsCys0A 5UsB5eaAcgtA+TJAuSXgezng2wrwvQLEANaAVBvAoi1g0Q6waA/IcwDkOQLynAB5zoC8lYA8F0Ce KyBvFSBvNSDPDdDmDmjzALR5AtrWANrWAtq8AG3egDYfQJsvoM0P0OYPaAsAtAUC2oIAbcGAsBC8 FL6EYhBpRB5RRNQQdWQC2YLsQHYj+5AypBKpQuqRJqQFaUPOIx1IF3IN6UduIneRYWQUecIsFURH ZILoSHRBtqB6qBFqilqgVqgjaou6oG7oGtQHDUBD0O1oProHLUbLcdWuRo+hDWgzehpfpx+RRy+h nWgP2ocOoHfQIfQB+hh9jr5Gx9H36Ed0BnmC6pE4EWkSP0mYRENNccudtJbki/aRRcmeZG+yPzmY HE6OIseRE8kbyNnkLeQ88i7ybvI+chm5klxFriUfJdeTm8gt5DZyB36sMf9hxDHrfHHAnQTgThJw JwVqdWlAnwygTxbQJwfokwf0LQL0KQD6KIA+RUCfEqBPGdCnAuhTBfQtBvSpAfowQB8V0EcD9KmD +lYDMKgJGNQCDGoDBnUAg7qgvtUDJOoDEg0AiYaARCNAojEgcQkg0QSQaApINAMkLgUkmgMSLQCJ ywCJloDE5YBEK0DiCkCiNahvbQCPtoBHO8CjPeDRAfDoCOpMJ1BnOgM2VwI2XQCbrqCeXAUIXQ0I dQOEugNCPQChnoDQNYDQtYBQL0CoNyDUBxDqCwj1A4T6A0IDAKGBgNAgQGgwIDQEEBoKCA0DhIYD QiMAoZGAUDogNAoQGg2erubCWzheUAVUBzVC7VAn9Ac0BD2FxqFPeItlrv0DKUEY3hIzQPC2Dt7W mMSnGcgUPs1BpvHpNlI6PpUgBUMwqkoKxadqpHB8Sv2Jh/fAwwfg4SPw8Al4YAAPIcBDGPAQATzg LThSJDMHsOgsK4plRbOsGJYVy7LiWFb8V4vLmmXZAAtvv+GqMwJBuDqM4VsdRycgIq4SeKsRV4pp iB0nvJ3ZP0EohkQgHcgUssZb0164wsXibekc1rm7Az1kvoJFECRIECgEGsGAYEGwB0/GEckUvF24 F1iKLEvpqwVfxa09wOphWddY1nWW1QssBLTuBeE+Zgo+C8FkW3gUtwtBnn5W7j9Y1o0f1hsA653D p7nweXxaAPLc/C6PEHyB6Q++iLdj9+Dft1iebrOsOyzrLsu6x7IGWdYQyxpmWSPAYoP48NIhNddL YQBfwbdWgm/vCthqCdwB3mvrxFOleLoTzC2F8egGn95n+XoALOa7j1+e9y2HD+I5q+E6iBM+Ah+B eOFj8O8QH1wPN0D8cCN8ChKcG4FXkDmqD3hXDgJ3kJnv3u3HF9TCtbjPBjw/ArfCreC5YRjOB3cj me9VMdvpbBACemw4Idm5EdXEwVhqEriPNkgS3F00BncXmf6twFtSiyAN0FfAR6bh9QFe4pDnXy2S ECgR6nhqAm/DD4J8PEgqXnvgy758I89BrwGzZQmBNiIBX3MY9JfwQ1/uYBLhJ/ieMnvwCXA52C6K n+Ov/SignwLuAsfSzbruD5lPpQDrEct6/NUiJTFz/7fn5ms/1NyoYaLMHkVBMBcSzcIYogwSh1KW ZdYkN4ENLmeIxuCzImECgUrGOEioMg8CL0QhzJvEqUwiEAkMbZhALHfCHDCV7+aIVUikiUEG4GMH +YBBUcPAYKb+kBHzg0l/54woaJ1SnSryIlAm6sSDlVWDhzq7tVeElDOElmEMIj/GgD+WIzABhnmh s9AWA4Oceb1G731fDi/BuFl7yhylGKNTlTFFErKSSBaQMYukJ0Yzh5yUovgqSlF1dbWlWIM8ggEl F1MlMLEvmef/uGRuqEmqNCbJXI4ICH9b7hgZGStlEhcbFBkdHJuISSzg1tXGqFQM08bwP7cF3DSM SlOnziV/wR4xCDLfnxYCCiEMAi+Ez+eEGQQCVAO3nqU/1h+3FaWU7V63BnteUZMrv/bDTIF1ZdNM SYWUUbJDxb6KPC9aaK+pX+LruvgrznfGXxRnieWVZQTUXwxN8pEdEDcY4iXsfFp4oU01oKgoaNHe 63oqbVwnVi06a/GE00inUKWGolv9cvlG09EM3paisJXedYzk/V6qCdbP9jb46RfZi1HZ5QTLap7s UBZ+bLjHV9BrFepfJq7tmD1ZNZYPXxLtb1tpXr8prU3vpXO+7ZHPVUnhsbZHhbsLOSjSkOt2r2Dt lhX8bAYus+7TvwVwsh/sS3dxHWvUXyOUnkC88/7MkbSCmWNXUweqFkZ7GHSefsNeKYPVkzKv1Esl CGQOwwhe8CvTq7H0A1h6BX42xQnE9CIsfXcan/t1+lhwdKmsQ4rgcZtts137o//914/xD2UcYV7D gqfk9tyJ3cKar5oJcrcS5k14eNHKSsldRuiOnLwreo+lx9+47lI5Ub7sss/Yp5vd+vpuNVrOwTNy 4cZXug8NocmD1FzDMj56SMsMv51wcPun62aj89yk7J77rD96SOSysra86hn//fyb5Xl9Kyedxaak rwzMn3CsizCjsX1mLPjwKDCM2+F965+OHa1PLmCfpKgcOeIFigttbojDB/5MG0Ea3N/+PnjZ9bX/ 8g5H58YGhMI/u33gDXteSvPui7XaKg+THlYnjMaXQ9dDjM/2aW0eMeGv1gwRDbmref8PMeLDanPi ZTd1nQgbMW6fJs6Krf03nI0troqtPEi/y6+XvSuurKqvHFcFL4yBWH9RBc7FtfPu2c96lHS1f9UU 8V8lBjj3OjT8D1cAGi4GVBqe1PwqBolAQXEnJAF4pRNVAJvHTLALcLp6xwQFRwTG4pvhw3iYM9kE 2Bz9/cIjI/y+7hjn3+2YLCb9ZccWfr/cz1/KKTgwgjnEq72ZyT+qQlPihgHPenPdao066p0pec3l Ce3TkqUd5lFjvRZP/9h6PtTa0eftXvi8za3lYWpyRv5tPbJNZMum1LhB89ZDeTz2F+WVx8ufcMtK 9prIffTZe03E/MAuK8m9V+vVZM5bqSZH3p4vob9Vl093sFXxbYC+KoE2O6NgefBEGCG7ePrUcd9U xpRHeXpG5rZj4835ldd0DtpnLlDIth3E3kOGby9NGaafyXoVplu1WON9w+KjnBt8dqwLKN4Tw511 dPzChNRJO/5c3y6V2zRzkdctVoX69k7CPQEOiYcOZ192MSpj2OdEoL9rnl0v1+oYYLjXtls5RT0i Yxmpt/S6VRYckQX91p497DSnCh+x9ElMgCkK8kQujJPEjldoKMqGIP8ZUsHL3EcBAmGWiGII/oWJ M2fwEIWIgt3iPfEQ3f3on3cu2BY5LF1cudT3DUZmLuYlEnGMsr5DB2jM+tojKVaLxntO28ZWrFKI VYqrz/pca52/DrJ51vlC+F7wRZ6K5AnY7FJndvcHp+5zZa0ukW98l9YshV4XXi66IdZMLhPhzr95 R+Kw4oaxVwdj6vKGdLcZ7gk5rRPel3NU9vPws4Fgjh05rTP3oRaNicnkKT7+xegLxcJdpqGUqCad vBE27iueQVdb00xCA6pbmlq2aXSOI3zJSe/6RkyH18/cv1838374Bnc9fWDnqF2jTkWy6h+GdzXI PtpwWXqI7Kb3Hr55x9xadG96bV2ZsVD9nf6ecgZXxdot9SpN+w901d6RamzDRDKlBLmVTju+NRlZ g43upARnn6U/mKiq7UkzjY7nwTUmCdcYnzmN8SYppIMIif17jlBcZ34h1UzB0cGVhkaj0jQ0NZmC g+HhB55UZyax9I3/L/vGDQoOXnSJNnb2jl+zI3+T/R+1pzW6YdMTsbLMjthmLw9Ey7D4896kIkUL mWNV2U6vXlvodbijZNfqpk60u986YRk9s/5R13Dgk8rPsQq7AstubkaWYpcmr5y6oifO7rLUbgE7 91SDSNAhObFp1DXz2UVbNmntqhc9KmqNplel0aqBx/0U1w7RpB5FLbarpSu7W/6UeVEt+xu34rnp 6+fdjHwNO1SWk9cnZr7JGYtqNXMbraznnlg5LT/yQKr/SdGa/APqqpRUV9GVIVy0pWMBYZFvdIrH 4MNF+wf3sPHxGAgHP0i0tRAcObn1elx4cR1UrGr6zqHZ7e06843PFicrt3heFfGmHM4347wYYjp7 gnbkN0WZIaGn/XPa8wFLf/dz7flGsWxvjJJ16/Qj6Y9REnvn9y6YunBwM7h84rxM6nGQ2dKAbojL EoUxobSfY7+UmUGSaIjpY7rl2uWaWepBsbF0PTU13+iwxeFfr+Fi38hwNXpoMHOu2tyw5TFqZk54 wVuMz8Isv+4hHpcYYHqYztc0BmepzDlMSEj4mUP/6O88xf4FKKA+ZorXfFvDRmPCz++9Gc6Vo3/J MiZJvkflgfb6Eo2yVtmeM8O3PBLnhQo4SBF8T0ZPso9e2uCgJET5o/fJPqVrwtx9AlE7FF+6tE4N XORWO+qvGm5jrugSnWFn3BcibuJTk+ix7U1HwuYumLK4pKNY+dFJJY7Bl7sfPErKXcOX47R/0Msu YU+UV7W77o7+Wn5J9Nl585r+cw4njzbf+0TKgN7GVt6d7RYvl0XZHipontu9XeQQw0vh6XSGskQv sWvbNQb3zWobsyVxfUODCWObPUJ5s/3yGk41naoNdJY2P2QV9MR5zRZBj8B1L7d7IHw72EvkpHY/ HYbm0WumjkfTm448OFcmBOPqU4KrT+YX9eELIe+1a4fka+fdNZdclRRY8VcN+jWxjhamS9XCqJiG hjZTenTx5C+IdZyDw/1jYr3D6f/TWOeedsT00cumVlHCl3ssjZzaP9YKnlKhtfDbOV7e+MpI/fZy 6k5K4w6/EUn7jFPnVvSmoh/G4s5s6ai+cSSYHrBOIeBpY9NY5smrrw995v+NvFpGUe3aktsuRNH4 E+F+4VbOdwf/HGor29iRNpxqDWvnv2svZXeRCFp29XZ7vIfahkZ5YoOLe4iY72xassHrG0R5G92E WDbPcx63srRV4q7wPJfQ5UiOnykJi0gaeWmUt7s0imetkp2wjxettG+jrbKMR5D5liG1DD7741Mn FuaGvZbfJ/Chi+9mJs9bRnyM1qWCpIpuL9JL9FiWetOHfPcMk4xVmfkRxyRVLLsji81GQp6mLtoW +kVvGAQKfkbkfqY47P8Z0Q4fiWOuv2E+gRnCQN8JZeRTW+PdJzVqV2TlnS5+XqdvYnbpOibCWkEQ JnJJcEJOUBzkA5lBJj9GQv8SRv1EoPJt5lHPJdu3zNu235uNwLOVbp47FuPcasyBqs42Ozhlir3S 3dFU6UIe2tqoL9o7XVd1pel3B2nRSPbglFCkQsbiVVhDeLJMs0V/xkQu7xm2zVpnX6Q8o3ual+3s 6+4Z3NZ+v03pavLLK0doN7JPdvle0OoVlm6LH9IvqheNKZXOudXQwO+89W3xOX+rIsqiYq/NvPod Av7rLFuuHd6oZ3fMZ9UQ9uyZrvjopvE7uulTAtJb/dJ8ScTC8SLYTG29Rc6pWfi2/5TV0B0kdlc9 GsHVXXKP4p1s+eeC4nnSOrBYdh3pYiGt+dGSS06GrTWbhp4GaOe+lSks7j6W4OygNxC99Ljse1yg DuECtZMVHuWrgvCI49eFR/8iBCA8wrRpmrg00ahAo9S/JKnMJJZe/+8IjxQw+S9JiQizYDrzFzGW OplLmTvZ6mmb6NBUtXR0TFR1LXRpVHlM9ssxif14TKpOzIOScvKPZv6Cxj/KW0E6p5SpsEPS7YJX +z7fy+6d5skTeH5Im8IfP2NjXxu/W2nXspEal2D4UX6KTebd1KixOOhui1nYdGRd1Bvl3uSdPfkL SvZfPDU1mTLofV8VkyhepBpv/NiicNuRW5u0b3WPTVxzP/8paGTcL2/f0/P8U5VnMj4NbOlBDVsJ 8fYKyIeMJqGsXK8znooqBtcOfN7jpiluJ9Suc0vC29hQq95FcH5CgT7fR+jYrgee2rUKLb4qloLp K0fDntcoF+Tm8KRUQgcS5Nj2KNGRZiW57UVDFytkVrRZryYlOEebHTPyG9yVwb6qceZZ9nIOrfr6 D+o1KdYViam01Yo8pSfejRiUGr+00P8+nPomCJSCnDZY/8Wd/FMbLHg/dr1NKZnt/SFS+qli/G8i pdgYuq/3/0mk9NVT7M/F+of4j9T+M7WCXtd9etCXE9CpOOp28irESFngcVFuNX9L9WTozeyZ3K4T 8ZKiMu8n73c2nDQhLNQ+bKldSP/YrV5F2dpMbowVoDTVx91X4niwxW54j/HuJg3+9Od8g+L3Tvld s7XXt978WWRQ/siNwuznKy48ejNlssCT8MI1Z0N80qPImWypul3FW4va1i4sn4/JjVSkeO8QV1Q8 v3y7ntnGTa+HbmwctFPR1H9iYkI4BHGRxweWi/aY5q4/NqGa66l4/0xu6o758Q1e04IKhyL5fU0p q/Q2629Z8rDpYvdOVzELl9C8rp02LijU+QFbYm47LJLT+o7vzeDCYYpEg8N4wsii0RaOdP57EnrX zakM4mFcsWpgAgFLz/6FTbYfGpLfOsDL029hgqzaiUKgsiEouOXBrLPmLiYHQuX6vs8d35tvKTKV B/t+6XxcS1grEqk4AEFRzuN2Q55FJDFBI+HtlJwS/sP5mM93q3BRnTHHckraor/9lbcffjdt/6I0 ub8tu7GJ9MjAaG96UKLUX7SKyCBARuNsl1ONEdrxUQf5yfPPnT927nLa7jyl21xC4PzYprO6TEQx NWFi5y2jMqsknpOPFS89c4hTyHplLhu7OZFDViatj9FyMZ8/r+i03LKgIx18HwLf7zquda45JS3u 0VEHTiHi436L5tLZJIttS59Wtzt/FHItCG2Rj99mU7A4HypetGZAIXy5+rID+TGcVree7JmJs+MS TZqk3M70HzB7T93g4db/bpIoI8c5s4R+8ALteSfJMrv6pUCtAf3Dhsqb4V5RktPyxufCqxwEt4Qb H1Vav6ixwaFAz3xM0XKy8ME5B+jK5zJGBt2uPndCYdWy9q0nhd+aGJtUfB6wEQqyur90ltv98MR+ BiyJMWDRb1eIRGXAXPgs9n97Af1rpflDVc42V0DLPTHh78sh+dsNIgK+TdYSlMqLV7m6zDsg+L+W hqbbvxTDVXudApujdueuvBem0JygXWW9/OWFvygWs4gE7GfLTNrX8fvbPKqaTeym0hd+dqeO7xMP 2fkpsrMnuKd3+I73jKVr4LS0T/uwzEJ+4lqHLVaxukKXiBdc5HRsjQN0BfJNTrT3qWQX3pMv6LeM KCqbijxw7JLlZuViuSmYdp57UsTC7YX1u+3+R+vdBXZR/HNHN7xkMz2VrRV7/m4jNKa7KWbioVzC dCMl3vxRLnz7jTp3Yjd9ndC1mQbHV6Mcngvj5U/VJIrw3LRpookkFsCeNsOf7dZHMCK3cpSwiUsm j/Kdvc0fH5ku6YblOthe6MpZP79t9jBhx5lPnO6PEk3MuBCLnq6YscfLV3Vs8CmQDxKRPRu8LDXI 4l1weNSftRcOQtB/ASRCNwANCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMjMxIDAgb2JqDQpbIDBbIDYw MF0gIDRbIDYwMF0gIDE3N1sgNjAwXSAgMTgyWyA2MDBdIF0gDQplbmRvYmoNCjEyMzIgMCBvYmoN Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjI0Pj4NCnN0cmVhbQ0KeJxdkMFqwzAMhu9+ Ch27Q3FadgyB0jLIodtotgdwbCUzNLJRnEPefrIbOpjABvn/P/Fb+txeWvIJ9CcH22GCwZNjnMPC FqHH0ZM6VOC8TVtXbjuZqLTA3TonnFoagqpr0DcR58Qr7E4u9Pii9Ac7ZE8j7L7PnfTdEuMdJ6QE lWoacDjIoKuJ72ZC0AXbt050n9a9MH+OrzUiHEt/eISxweEcjUU2NKKqK6kG6jepRiG5f/pG9YP9 MZzdx0t2V6+n4t7eM5e/9wxlF2bJU3ZQguQInvC5phhipvL5BRUdb1MNCmVuZHN0cmVhbQ0KZW5k b2JqDQoxMjMzIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyMDE5L0xlbmd0 aDEgMjcwMTI+Pg0Kc3RyZWFtDQp4nOx8C1xUVdvvs/dcucn9oqO4YQRRBhjAG4qKAt41BVQwS4aZ DTMxzEwzA4j6GmKpoaZlatpF0iw1s1GzNEutLC9pZZmvZmmlqZWUXcysZM6z1t4Dg5f35Zzz8b19 v3P2cv3X2ms9+1nPde01AwgMAIQgSIHLyR85fPDxj0MAxmkAVIVjCvJHsCzzNU52Q6oLd+WnpKV+ cO5TAGYD3k+alDO2sOL9ykkAMn+sX+ordLYuk3/dA8AVIM1QfZWT25KycSNAjzE437/UVlax/9cB LoCYJ5DntDKdw6ZUgy+uF4X8wsrMNaVvb9i4FSB5AYAEjIaK6ZuvfJ4K4HsZINxo5HWGU8yBS8gb 5YM+ZCAk1Oc03hvwvpuxwjk96gbDAbB4y8aarXrdaueqEwCpyI95r0I33SaJlh7BPt4DZ9FV8BOL pn0AkD4eoNMLNqvD6R4AyGvs72TeZudtdx3oPg0gDu8lBUBsJQOYmMI8MC0w86pSpQRyrX9pWRNp 3xr6rRGgabzvWQXKDP6UnlzYKlKbcA2/RQDuD33PNs94rhQ68jVkgpzesxCEYxn46GXpNIGHIppZ iqsrpR9IUWJJhKcFg4TzJ2Ld4Rqbz3GQdYW7MkqeyDwHqYpUxlXbPCsFoDdy8V45CEbdkdXf5JLv hUn/aRn+H7u+ZhjmlqC949Vmwr/dhUqSC3P3d6UblKBwN4EPKBF9wcd9A/zAF/v+4If9APBH7EAx EAIQg6ADYjAEuv+CEAhCDIVgxDAIQQyHUMQICHP/CZEQjhhFsSNEIHaCSEQVRLn/gM7QEbELdEKM BhViV+jsvg4cdEGMoRgL0Yhq6IrYDTj37xAHMYjxEIvYHdSICdANsQfEua9BT4qJEI+oge6ISZCA mAw93L/hXtMTUQuJiKmgQUyDJPdVSKfYC5IRe0MKYh/QIvaFVPev0A/SEDMgHbE/9EIcAL0RM6GP +xcYSHEQ9EUcDP0QsyDD/TMMgf6IQ2EAYjZkIubAQMRcGOT+CYZRHA6DEUdAFuJIGII4Coa6r8Bo yEYcAzmIY2EY4jiKdyH+CONhOOIEGIGYByMR82GU+wcogNGIE2EM4iQYizgZxiEWIjZCEdyFOAXG I94NExCnQh7iPZDvvgz3QgHiNJiIWAyTEHUUS2Cy+3vQQyGiAYoQeZiCWAp3u7+DMpiKaIR7EE1w L+J9MA2xHPFbMEMxYgXoEC1QgmgFPaINDO5LcD/wiHYoRXRAGaKTYiUY3RehCkyI1XAf4nQoR6wB s/sCzIAKxJlgQZwFVsR/UJwNNvc38ADcj1gLdsQ54ECsAyfiXKh0n4cHoQrxIahGnEdxPkxHXAA1 7nPwMMxArIeZiAthFuIi+If7a1gMsxEfgQcQl0At4lKKj8Ic91fwGNQhLoO5iI/DQ4jLKa6Aee4v YSXMR3wCFiCuorgaHkZ8EurdZ+EpWIj4NCxCfAYWI66BR9xnoAGWID4LSxHXUlwHjyI+B4+5v4D1 sAzxeXgc8QVYjrgBViBuhJXuz2ETPIH4IsXNsArxJXgKcQviaXgZnkZ0wTOIW2EN4jZocH8G2+FZ xFdgLeIOWIf4KjyH+Bqsd5+CnRR3wfOIr8MLiLthA+IbsNF9Et6ETYh74EXEvbAZcR+85P4nvAVb EN+m+A68jLgfXIjvwlb3CXgPtiEegO2IB+EVxEOwA/EwvOr+FN6neAReQzwKOxE/gF2IH8Lr7uPw EexGPAZvIH4MbyJ+Anvcn8Bx2Iv4KcUTsA8RpUA8CW+7P4ZT8A7iZ7Af8TS8h/g5xS/ggPsYnIGD iGcpfgmHEL+Cw4hfw/vuj+AcHEE8D0cRv4EPEC/Ah+4P4SJ8hHgJjiF+S/E7+Bjxe/jE/QFchuOI jfAp4g9wAvFH+CfiFTjpPgo/wSnEn+EzxF8o/gqnEa/C5+4j8Bt8gXgNziD+DmcRr8OX7vfhD/gK 8U/4GvEvOId4g2ITnHcfBjd8gwhAzpnn/fzkuLX7tfWd4NN+r5v2u/z95Si4f1vJfdtTlva6AgIU KHhAW8nb7PC/0xUYSCI1sK3kbTbG3+kKClJipAa1lbxDO4rSbldwiA86J6St5P8jdQwN80XBw9pK HtSOorTbFR7hh4JHtJW8zQ7/O11RHf1R8I5tJW+zw/9Ol6ozidTObSWPbE9Z2uvqEh2IkRrdVvKo 9pSlvS4uJggFj2kruao9ZWmvKyY2GLMxtq3kbQ7qv9MVFx+Kgse3lbxre8rSXlfPxHDgILGt5Or2 lKW9ruSUSBQ8pa3k3dtTlva60np1xEjt1Vbynu0pS3tdffqpoAf0ayt5cnvK0l5X/8wuoIHMtpKn tqcs7XVl58ZCGuS2lTyjPWVpr2v02HiM1LFtJR/cnrK015U/qScMavuPvYa1pyztdU2dloyROq2t 5OPaU5b2ugxlaTAaytpKXtCesrTjxYo/AwwDCWmYTljl4P0D8Vt/SkjupW1dIOn/Xsb/xCWFBCA/ bJeituyVmCuj3G4AoQ08F3iuxSZZffv17ZWelqpNSU7SJPbskdA9Pq6bOjaG6xrdpbOqU8eoyIjw sNCQ4KDADgH+fr4+SoVcJpWwDGhy1cOKOVd8sUsarx4xIoncq3U4oPMaKHZxODSsNY2LK6ZkXGvK LKQsvYkyS6DMaqZkgrhMyEzScLlqznU0R83tZKZMKMT+4hx1EedqpP2xtC+NpzcBeBMTg09wuVHG HM7FFHO5rmFVxvrc4hzkt9XPN1udzfsmaWCrrx92/bDnGqa2bWWGDWJohx2W238rC8oAlMo1Sp2T 6xqpziEiuCRxuTqDa/yEwtwcVUxMUZLGxWTr1SUuUA91BSZSEsimy7jk2S4FXYYzEXVgIbdVs69+ 0c4gKClO9DeoDbqphS6JroisEZzoGq7OcQ2fcT4qSbOTeb6g0OWTvZOBgsJdMMpdu3VkbU5OEVkt JLtwPiWPRPLIGedVkvrcKBNHbuvr53OuhgmF3rMxBIuKkGmSZnReYQxKrc5dxBE18gqpBsiUiUpB IckYUVNQmFfnkpHi+ziXj3qo2lh/XzE6q1O9C/JqYrZ1GpW1y/0ljMrl6gsK1TGuwSp1kS6n89Yw qM+r2T4yixvZeiZJszUoWLD01g6BYsc/wLvDN8/RHiUnPZTaY2qGSKQeiSHi4vQcSlKodrFx/Qjw /aBe3w/J8Cpi0KImtF9xfVB/4ghZXJCaq78KGAjqxsutR3TiiDwu6CqQLgmX5pDDeU/flZjo6tmT RIoiG12Lkg2i972TNFWu0WpbEOcajSaD8YX4UFH/FDR5TAzx8sKdWVCCN67aCYXCPQclqm2QlZJY 5GKLycw+z0z4RDJT65lpfrxYjeH8Ck3hcJcyvvlfYFBEaK6xv4uJ+BfTvDCP6ZPLbZXK4urHF8br 6heq4ovrFxWha4ZhKtbXD1Nzw+qL63U73bUlai5IXb919Oh6W26xR6Wd7n0LVa6sRUVGBo3qShes 4QrNLpSo2CKhx6okRUmQ5Q/DyCEhJFiZNYLbyfbZNiINm7m0YTYLzYtCs1FoNgjNC0KzTmieFZo1 QjNSaEYIzXChGSo0WUIzSGgyhSZDaORCIxUaidAwWXdh+znW01g/w3oC6ztYX8W6A+vLWF/Cuhnr BqwvYF2D9RmsT2NdhHUuVj3WaZTnywLrl4Rmk9A8LzTrheY5oXlGaHKEZojQDBSafkKjEBqZ0LBC A1lZ2J7C+inWg1gPYH0P67tYX8P6CtbtWLdgbcD6GNYarIYRaWE+YT59l+5kqrJGKpY+q1i6TLF0 sWKpVbHUrFhaqljKK5ZOVSydolhapFhaqOimjFVyymhlZ2UnZZQyQhmmDFEGKTso/ZW+SqVSrpQq WSUowRUqGc2Ozh/KjHbt08PoEs71W756J+M7YYpLph7KuEJGw+iCoVGufokudgHdzXYy7q0M88hD KrKR7QKGcT+0WCW2RUUQkXjrFdXqbvT4mjegK9MXFIjp2xVd9yvIaD6OLqWjS8noUjoaxWwbD2mj dQuLu8BtGLdczL+cbUWZayLqji/cqoShRdlThXY76+eL+hSrYoqGRgTZBlHlBsREzVa9LiW/0OiH +eyPL4gArGQqaUjSEDKFRxIy1YG8O8SpqNkDYlSvMxvEqSAcDkZT/ofOFHe+jt1xJhWLnilk57BT sPcklCCuxmrAugoeh8fZ7QINpGN1YW8UXJQdxI+SdjqeDrMQc+B3NNw8OpIJJThfgtTvYjsI5/TY MpTH48wi2v4DHkTeP7Hb2bfZt+nsYOQ7ilAIhd0uO4jjhN9c2AJnmH1IMxOW4dwuOEaeQs6Pw0tw jUnAspD5hmlkx+MoQ9ZHPuVI/TjKuwdOwS9MGDOIqWfeQJoQdg6VRVitFmnexXKMciFlLGNmrIyd eRh5nmclbG/kamUXsA2si31bUiQdJDsoD5H3VZjJb4jh6VYCwagh4TYO8nHlEri/matQPmJYZgJT wBiZFUwDyvAu04jlVzaJHYxWJ2W5pFjqL70kK5etxXJQPlHxtFKOvGV4PuwEHMRBL9QqF9eYgDIb 4D6YQctMLLPQlnWwBhrgWdgIW+F1eIusCafhDFxD6wRiIXr1ZTKYyViKsNiZ2cyDaI+FXmUx8xSz nXkd5Xuf+ZTtiloLxYzaC1LOZVezr7Dvs0fYs+x59jv2JwlIfCTTJCUSh2S9ZJPkQ8mH0hHSBumz 0s+ln8sYmYtaKkQeJr9HvhDLIoWPolzxoOJRxdOKV32TIRL1Il+6jILJqFUNajILFkA99dpWLK/A DiwH4TuiBxa3qAkpGUwOM4yZiKWImYIngArGwUxv1ug55nlmA/MK6vIplpPMaeYr5nvmB1qusXI2 gk1s1m88m89OZsvZFewq9in2RYzI7ewb7En2DOp4nr2KOvpJQiThkmhJrmQYlgLJ3ZLpkrmSlyRv S05LGtFv/tKB0kHSidJ7UPf3pOell9CTrEwii5P1lvXHYpRZZLNlC2XPYEQ3yhrl/tQqIfJQ+QD5 fPka+Xb5KfkNRbgiQhGLJVmRqshXmBVVik2K84qLys0+Q3xMPnZfDWwCLbx2U/buIL+zw94jT4FO zGmMhvslgUjFkdxj/RVmHxO7nUinyGcS0FNfwDWJD4yWvgeTJXeDWVYi8VNchg2MQzqHeVEyDDbD ekUV84akWNIoWS+Lkw8Q7MmulmxS1CiKFRdR0l8ly2RGRTIzRLaQ2cAOxoy2MxPgN+Yq3IsrO9me 8B48DAuYKnzhPK7czARgrr3LdmUWytZKtkkbJLmy2UwP9KBKdlDyEPSGcPDHT0KxGOsy/IxIfnmZ Jb+HLKnF7JfgC0KdFag4zkiPM+vwM5MbZG7JLuYbgJSmxqBGGPwDYqo2PTgmOC4mOKZWAjdqWWgC 2cE/+tVKD5LPV6PcpxW/yhqRsx/y7wRqGADPZSVI5Uofv5CwqE4xaj+2Q3D4AElGpKqXJE3GdYuL T5InQlqdP5Nh7LCT7b0tMZHdyTyUpQHW6yFpdHx4ShDj3y2u1wB5H+BUCc7opOAgZx9ZpDNlSfRO tte2Pn2kuxgOZW3MSLlxozEjqDGD1uCQSKxCK0ziYCMdjcygc5EZqdpIhokIxRoZF9+d6ZOeFq5g sBMRThE/8tHbyLg+vXvFq2MVrZtRzCjZtMvhfzwtqVgZxzDqJ/8MDvZLYCQDY7gbMcmSIYGqG/LQ kABJpn+HPwMzmL45AR26DM8Mj4gcPtg/ICk9jvlTGjm86Y8/v5WWj9/yzs7sv4ZK433ZmR073Ojn p2Vnx3S6wTHBQR1UbE0i99fXI6ZmdvH3U2fEh4bG9unh59ed/G78JPdpuRHt7gfCjwEGQMVrUV26 RKn6aLvtZjZBT1CxA7J8Y/zrIKRO3jNGjiZ+DTpOj+oyPTppN7MRukM6szErICN8iSRwiU9U94xo qc8uNgQkKY2RaMagxhSxEBM2D6BVMzJSUlK1Mg6CgyCGYpxXX5IeEsOFpsvl6tj40Nj43r3QtGhN eYxXXzKtaU9TBnOAGYrlQFNG0x6mI7O4ydF0EYuDWfzywJFkauSgyF/27v359fQRI9J7jRjJ7E4f OTIdb+K8nySc9Li7dsTySJNdYMHObNrLDPno8mWmegR5wquSrI4Xy9f/1YWp/f/lv6fQ3TmOebv5 e5w08HzPxYAP9BH7LChkl8S+BFSyM2Jf6kUjA3/ZdbEvh2C5TOwroFYeIfaVECZfIfZ9ZZtxNaHv B2nyTWI/gBkr/5x8CyclZwt/ZQ/aV5C/MFH2pn3y+40GZa7YZyBEuVXss9AhLFzsS6BPGCP2pV40 MogK6yv25RAbdpfYVzAQdr/YV0JCuKfv61eo3Cj2/cAQvkrsB7Crw2/Qvi+RM2ol7fsROaPW076/ 13gQkU3sh2I/JGoH7Yd50ajoswdov4vXeDf67D9JXxnRMu4vrruRS9Nq+3BjTXq71WEtdXLZVrvN atc5TVZLMjfEbObyTGVGp4PL4x28vYo3JBcYeW6yyVJmwOrgSq0WnKzm7Txn4B2mMgtv4EpquNF2 k4MbYTVX8A5OZzFw2Uad3Yz9oaYy3myt5kwWLjUjQ0vnsJOazAX4BvgS1l4MrXZTmcmiM5tr6B8v GbgxlXqTQceN1FstDg03xG63VmNLeOQ7dXYH57RyemuFzcxX8BYn50Ru4hNOfrqTcuZKdRUm5Ici kmkHsvXIbXcko5J0IQ1n5632Mp3FNIPckAXsvJnXOVAGQfI0TufwMlqzPTSUrdNo5z2a2OzWKpOB 53QcmqDCajFZKx0oQLOxHLyTs5ZyJqITrmKzo50tTuRFOaE6+AzVymrhCT+ktaGsVrQLHa508nbO UeNw8hWCqcljvGACSl1m19mMJj2SV6IHUX58oFSn5x3NNkdT67AKIpRa7dz4bA1HRHVa7RqunK8p sersBjKEHFBDu05fXoJu0RCVDJzBbqrCYYPJUc47nYRAZ0PJdQ6HcGuz0zU1aPvpGo536pM1xHrV PAYXti3LlprMxGpmA+qH/Kz6SqoELqwzmQUssU7ncaDaZDFQ3+vNJpsoHdG9Wod2KNERQZK5kRZO ZzCYSCRrvCLWZNGbK9H84sLVJqeRK7EioF4CNZqKMGuxLnrKVIomtOhRHUel3kjlt5sEN1mtZsHy RgQHiR0dWYkrMxMTiELayIhDb3I4rES5Ep6Yr8RaUYLTRl5fzomaeRmmwopO8RbKVKErQ7mbBeB1 6GtBPLqsGdMFXYTRUFGCMhFmTrvVbC2j3hfJeIveZNebMfIsaF67jtJhFJp5PVmGRIyugkQYUYaq Rb1nt5boaHzbzLgCUmN2YDZhLiMpJcN+JWa90RNY460mIY4FHgYUQrhFrUrt/P2VJEdLKy10WeIW r0htCVK0t5XMeTxJclyHTsOMaiWzzbOa6ATnbXYp1NWKtKVoMx3dOwhjPcpTWmkmixt0gijIrpon ux4V3WAiTxBhDSY7L0pLJhzOGjNRdhiGbpXObuKdNYKuFTad3kk8VFJpNvNOwRE82qZc3K2sdrLN 0NCeTCxDRGwRDvsCv+bNoYy3VvBOu0nPCb4jVrm/EgUn/rCaa8rofohbYJmwGhUON8TkFgvk8WWV Zp29Pzc2vz/d8ifhQsR2vZO12mayJJHMK1vQ2SYaZjqMsDITUQQFI2HJV+js5agLznjdlt7+XUJM TXwyEXcVnu7XTuHVkIIMrHQBvbXSgkoSk7awKKixWWlc1BidTlv/lJTq6urkCs90MuZoitNeiaa3 8SnUyynVHtlTiqyVuGnUkH0P1zYJYUD8guFdYXI6hVcVkSp34pghdAsiN7hjGyrRgShxNYaj0etZ U/P2YSCBiFuezawTvE53OdQBI9eCmw/nWdxqwd0+wdSD4ytKyFMtvCwe6tuKRMnpPoJuJr73pIm4 PLWnyGsAlSDBhKvga4CY3E5ecrhFWsxWnfeiNHvEDZlrtry10ok7Hb6Tqkx6ntAYebPtJo3AAlaw kz/jAjPkgxNbCxgQ7Ygb8eN4Gn401uKBjoOxYMIP53akd2AtRVoOsunTNoo6HDFhzwLJODME+Zmx zcOxMjDinIPe8djySF2FaEDKApzjcWYy0lmQ0iC2hLqUchOerKZPEUoD5UG4WigPDkqgBnE0zpso 7Qh8zow68fRO0IjIaqR6mcXxoZQHj/dW5M7RdTn8yJ+BRev1nDCSSrUKoH+r4dss9e0ltFJJyihH HbUDkY/0K0SJx0Al2tJELc3BSOwTPg7QUMvZqZWrxXuPHIJ37HQtJ85z9KkKtD7RiHC2UJ84Rdla r+HEsel03iMz6RGJTKJ8ghU9TztEaW+2N1k/WfRki0ZETqI70byMSmyCGc0zHg3s1No83jtEO3jb PI1SOu4QabfGh8ZLWtIS7jf7xEa5VFEr8JQ/J0ZBBaUi8VqJlIIFbo0sIqeTerSUSuvxk6CLjaJD tLwgV4tMgneEdVp8ZaW8PfIJfG2iXa1ivLRQV1K/2akkNVid1NPeUe1ZjW8VBS28y2hm2pCKSC9w rxRzULC/sAKJBT3V5tY4t4u2E1pvK5RSj3MwHrOL+MNjVScdJyPl+EwNxpZV3FM8VIIMgg/tdO1y pBKyRdPsJQP1CsmmKpHaQHO8nPrF2cxBR23IUQ0dotc8szb6vEdPjRj302mP0OlRY01z7FVTS5qb 72+nbSnNGU+smWnc2MWINJA/g0XtWjwhaKyjz3j3iU2mU4tr6Lom6tGWvNcjjQmlb207j9+rqXxE pxLaEyySTHcTC6UzUFt59mTNHfZY0iMrVYrR31rjasrBSHcHq9gT/OXNWyfaS5DsdrEr5JSJWk5P KfWidxx0lzJ62d8ucvZkk5Xa2DvmjWLP0bzv6Jp1IhFvbo6C1pa0NdM46M7ooDnn8VyJ6HmNqG0F ovA0yQESn9xNPrt9xFRQnvy/sJSJxkCZaO9bLcDTd6nxJuu1aGsW3y5CFgl7QwWVzewlmZPufeTt VuaV+6258dQTJqTU04g20PeUEL12+oSHn7AXmqklPNp49hgd9beQAx7PtHirJfeIPCV03LN/22jk OZr3L+HdIbybhPcyL77xPNyE8UrxXW+8Zccaj7OmVvuxtxwG0RLes3Yxk0l7P3LmmyWopNbxaOvJ ltvvqbfbSYX4tjY/d3NOet7jOjHTDOKb9052tt2iW+tMcLbxLCX41SryLRXjTOd17vBIrBftQ2xh btbc4HXWa3nTEF95znotVjfQrC8V3yKCZQ004vibbOt5gkRujXhKI54dJu66VVQWE93nalr5lUSf jnLz5FAJlddMab0zghfjpvymsxVZwXOaadm1JzfHjMeKt7OcQ/Rgi3y3nhzK6Nmogo7ZadRwrfLO Eysk/nTiqUIjepycTcq8zofCKbCslW4tltOJJ7TbxUAezbBKuj/aoT+Qk1Y+bT2n/EmiRp64642c yMyt3JJu4nb7d4uQ2Sav3Uwn7mFldNYpxoXBa7fk6e5op/uttfmZ28+Wwv/O5xJPVHvyZKJ4VuG9 ztdO8P7UkCJKYPXSQE/3H4voSU+U3k6KAvScje6/nv2ihmaHE/v9kXcK5gwpyfQU3vrpZPE9mkLX qRSjnuyyKV65nCKeG7ztngJFVELhpEEyRThrCXqbWu0GnnwRdu8Kag2PPVp/Hsgl//UIfjZpOQV5 ZoQztoG+xZzNNq4Wd0fjHdY13eb0YWjeEYVTno3Glneut5zlOPGU4hQzlviAu0VzQiGc7RPwuR40 Givom95wR7kst/Buu5VauLecR4Rs9uT9zW+T1tq3xGdruQZ42YBoIugifBrwRLm9+ZOccIq00Del 7o6atrx7Wp+QudvEvJWe5oQznfA5qYpqwzfzMdK3lu3f+GgctHzbwHvd6eiZxvv7B+HE66H4Cuct 9Akd3WcNQL63EH4vG8Ddj/x/Z7e9pKAEFjoDo0Rq8nvK9KdYwn8DhVWVA81/+6vK1Nap+sl9es4b Me9aAKNgG+pUPXAojmWYVD+tj1yW2EHCdpKBVif3TZQzUqauL8tIG/K1E7Qar5HOa6NrO0MmLXdh NDjoHs5TKwwiRRvjxUwaNnFTzWvfrFzFvJjwmnZT6ZMPx848pWyoCz+rrZPsx5rUIGEZlg0avrfj 8rOL84ZlXztdMSIg9TltQLOojAyFmrOQCimZKJWHslOGpIZrQ8mNMtR/Mk++3rNw2TobnxqmDSHD ilC/nEp7ic5SZTKb+dRA5IajvqHyAqOu2smndtGqyIBfaJgwwGXzdif9tpx8YZXaVduFTEtCI8Tp AlMFrqKroF+IZw/RRkcGaNNT07S9tPSaEhmQSm7T09J7Z/TOmKLN9xJ2Yn5qpDZcWL/DJN5uyjeV WTTcSIs+OTVR20NYKNYzQZci3zQKa+XzdvL1loMsWsfEeluFkYGkjgkEHPdl6xgGNh7e9tyRo9zL vv94ePP8yiuvjPvp7FuBe8t0b64zdP5s9/XD6S8+qH24cPai0+Vf9HkmcO+xy9N/rn5+tjVz77KX A143/mp+/PCbeUkvjhh49dVP75mmYtf8kVIe/dy1dauf73SQ/eqBMXnnOhRfzuo8e1fAmcEHXjk7 /81pM+5LTZasmhO6YTj3QaojYHLS0em90peHrArZdcaYsunCubfrF/V8Z2HM/NI35xZOtlbuzdwU P/+ew0HhmWse/K7gLV/L/qZ3R32xSxG8MnbW6UHdj0VPv7wm9dBPF2I7nt6/fXj26k7TGqKXnr/3 6g+zfvrHiyXMkqtj/c58FDtpw/KjWxZUbfnh9YBfzo891fCnsWFL2IDt89/azUow8NfNOa2dc1Lb S67EiJXJFAwjTdDGa7t57rXMvCjxS1mr3mFLriJfcaPdyZeyNHa6hDKMW6rUyrFhGdAOIWNdpf21 /bR9Gno1pM3Tio/r7eZWT6cIseIdKtlDkpGKRmqXOKm/1tcjhUSp7UAGA8la5G8C5Cgh3gdLMTKf 66iN9MS3JNS/IH8IBlq/pNSk3uk3ZYVkzhwYVX79u8K3czqnPlyzKnHF3rrNzInOY4666gstZ5U9 1t178PCy0IvSvIAfh3dPgX6u84eWjVt9PLYk/NrgvjF32VJrf1rYb/72S5dWQtOHE1eM6/bxxu7j Zmx5TTfkl54fXDx06t4vdic+NGjH0ztOfTXZveeVd2df/dD/mSsrmxI/GZCnUvXrfm3wKMxht7aO vSjmccC3iVeOn+yxICpN5nPv6qoFN+dxu2TGremo7eedjpPbuGiKNklYNP7fLZpPf/j6b1Ny2/iE EV98YpzxYFROaeU9s/fvXKOPdw/MfmpWcL+guImOU5XdTTfG7eKmfuJ7vUHVs3HipBjdyejT599I Lz/w4xfr+vKPqJb5v5ofPXVWae9psvrcpqpxZ/Nr187hnt6yYOpa5bVvtNd/iO07ZqjvB2ff67r/ xMRv5wzekbdOs4mZ8fPaTYt7N625cM99sjUDy8/tXbGv6Ujx9ayLioac7+dMsKzv+fOr9UEJjUs+ lzfMG7965ihlgLbL4aBnyq99W7hFujFr1baES0siNmeey7eO/qT30zushi7bV2h2D7xY833FjOsR F+JfevnHVfmvZWmW76zZ1HQ878UeztlDL2dEr70v4kLR7m7Gk1CbHTS/tlxMycPaOQf+D1PSvzkl WTyppwvJqNH21CY0xDd0mxd7p2R0OhxJeh1NvwiafoTFv8hA+b42ZWCvmzOQeHn+dNtn4/IY7u4v aw7Vafff2NVxxZuPwjtvHj363q8dTrqvj92XXqINfveqU3X8sTPTnuJCt87K3TP+6NyLtZFzX+i+ rCx02J+Hdz4xRHLkyQl3yxY+sMH6i2q8qlvyz6bF5thruw9HLG/0d+4zVp/6flXJ/LccS39/2DlD /eK6J2au3HptSY/7xyZXqkYM+ezKjgCu4ER1w8o6vemGz4f1Vyp3+zx56nrwxPjVurQ9M1jXzHl7 1r6zMFYz/Vjvqjcec0y9vuvCmHBf9ZHzHx/vlTwyKzwzsHhGt/fWl/644kPb94Mu/how+/Njs9ZV 3W9666m7hmt7x2xd+3KnkszEU49s6qmYeTJq+9SZXz+93tqU+fBL2jppCG4BfwhbQCC8BQszMxcE Hxv0m/7y2Sxvi0lxB7B5ctsvNDbbaqux0x9aJuh7kF9R6HvTD+KSU6O1nQXi8Nv+iC41RttVcFNU y3ye1erkhlQ6jVa7yVlDtoeMvtrUVK22r7g9pGlT09JTxdv/gET/9lXOvvmW7cKAn8epEtasnH6v 9ru1GxfHTfu9afmYda81Pb2WGzRrwton1y4pTis/NtRQ88PmqkMFn/38/VPzOi9Z82Dp9nfLZ5So T3TJPBPIPHZpxf69SaWrVxvjV33UX7PXf0dh/FvDLvoO6rdCszEhY8PlkXOHnnswcPdq80Td5rpZ zxYnVY/5dtUrhgGrx3dOVXYLW7Px4qOJURcGPqEPKy6U8Wu69M2bf+2FHx9n31N9sndi7vaHa/f2 v1zw+LgtN16YUeEc93LUkRU+CTEweWmxqe/u0SGKzEnuu/98rtRX+fzHcyZN/vHVAfdGzKmWfvbb ni21y5tcRx848UIn+9TMw29cUa6L1W6XP3RoO1cd+tBZcd/YoJ2zXjtnLclLRjpntXbOytqguz+y /WiyP6OeMDts29hH3O8/a//v91/dv4lxuissv+S3b/EvK6N6N+5kup2sDv5lanHammf83h8ke3TB kkP9L8T8fGXyMs2OhuEHS378659HBgyYsrFPgampW8XgQ0c2nZHN+iJ18cA1Qbb7djeF3BVl2vfX R9nngqdwd31XMvPlTR0PJvaNS9rDPxtSHxeoX3etoPP1mEMnwn/J22zJTlPcqIv8/Zsyc8CE3978 Ke/Amxf3a//iUn0WdFne439Vb+bxUG5/HB9m7CSD7LJO/Sx5hsHUT3YiV9bslGXKchOJUFmmsiVC U5bSDAYTkm0odA0RIrJmKRVTxpWy3jKV+1ChX7x+f93XffXXvM5zXud5znme73mfz+d7zgib9oox EqcjXkDLHedKnjXbTmGMH1pak8uhO+FLl/vesyaGVV1rLFBXGAsdyz81GoSHdHprUbrU4l7owPNV vUW8h1Rf9ojCxvINYM0OKmhfU1Eut0r2rPjuXmstw3bRg7l+Q/A90SmBN/O68CAVGkBxUPxNGHhz pJnVQcQKeAYfMBKO7Lj33SSI/VtIANRAvYBCqqNQSNSygAcRr6z2HQmRuT9KBl6A56vdYLd1DfAE pcBJ8DlbV5YQ0GywWGI8jh339fjeM/bNerbZMJXBh/40TGlA8uswhNfXeGBWxMeyGjFfMQUSP5OE a5kkrCskaWiTuFQzsqRpPhVa3yMjuxD0WHKpXc7mQOv1Smypaogi5EE+a697SyVxgUah9JXEX81i WeQmYy3T/8Q21W5tzK+b8jmfYCVSbb7owRBL2daD9YRoB+vPw9EH6O4WLxb33qWql4y4s0j/118b tW/O57bh/I4AcalHukLiFmTL9O7sTt4mIS1/5mMzOEn9Q7pv61rSPCSqKKhPWfqvT5eKKVXlPp8j jGRIcn+xQ+ocRIcV270Zm7QPkS34S06JRwsdrKkbnuc5FiblKfB6f/KDYH3LfQSz87EpGXVHT0+w 0aOgZxfS/DXk846kto0ovpJnFOZGGWHmNeDF09GiYgjL421g7EGzsQxy4PtAbKTDob8GXuDMbN8M OD/IF0YoFAJbsahiW2DbYHyyH+RNnJtPWBdRF/ByAtvolI9WkYDQahM+RhinODvEChII2nU9iA7A sSJ8VnyHIcC9KrCYACj4s25ermDMffTFLFPVnQkODtQTLFIz1s2glzXvoyumeRd0EW2k01Exs+Nc 92ijjVV+hdDjttfT+I82ZKMr+2SopO3DoT0L20LhQ7OXRSZZncsuXL4bb1ct2obrxl1RmUt6vhST 4WJibL4bsUdCxFr901kn/pSGYdGE966WGlSWt0fehUwmPrZ1x+AEjfGhI5jKEcTtL81wclNWW9Oh i36zrUMFWF+WYYzQ3fyFqHo23dRpRKFXaAlFPu/Oke3E4mhWn2u8VXfU0sSZsnnR2XWFgOY9yX4g t9UNLlpse4k6Hcpzz0WDU306hZIccwDmwOT0sKOPNPDybFLwDnq5LzGRWcWuxEWOhxvAMqmAKBP5 ijF2V8PMRyt/gcf8lKH4VZCxxr7dKBWU2rJbUge1EVhUXS4CJ/+RcXyrh25S/38lUXvkVfRtp6wZ ysjzzgLcpT6NG9svNjhH7XJ+X3JivqAwxrtisETqNEdzM9EkyUWKl/ZxXvpGxZxv0O13UzkaDx/U 2TtpFZQFqCBy3SJdQwhuc74xuE7fZw9vduVY8AS53vOLwxCubovNc47s1D9CHbLJ1G79NBwks0sf gFD7zp7G8fTaiWWPm3G0xAxn9Vml/d7q3prmnZ7s8pspz7hSt6OjyyHL7ABFYvV5A654If6gR6yD 6bl+/OOmk16fnUt9Et/+x0IdfbHJ0Jj/innqnTnPnP7nbP5HT2aeihe74HNt4s0hg7YXr/25nrhD Uk4jUxM4ynlryzqnpkckp0iHXafU9fY2fJVEWIZk8I0k/ORd1mAwNeBDCrRqN5sSOSDELJ59vaDj yudNyEdavioNiyQAkZkRG1KEcDLn3+Dfz2LB5Kvx0wd0AW28Jl4jas864/fjyTo/H6/lq0rfTsQF KC1PgOX4B2NfecUQmq1zonqADqC16kQZo1Q2PbG3cl/MiZ9veHIjT4geeIdDZzil8jlb+3qNMDa/ KaN315sWKRWEW3MNKpM/eL/moksKn9IkeoaW48LinGb0HpzLwJyNMbc4g+WbPxfQn3XfqZXR7zHi d4EaSz5ibF3lGKGNEHgjyX+vSJ0NxKbiw3nEoIsKvU821CV9MJc+N6MjXHjQsMhoOAnNa8dmPD2L jN5eA0twhGOgNA6LTgJnXFrtACW/k5VfVrKCbBsr+sQxSpXY+vlW9CRJXatSz2dUYtqgJuw2bfpg KcGoBnPfCjXQMs7sDmMO9jVfMqrOmNBziB4qYo+Yt29UGKOGO+6nKodMSV1I5lQsM3dsqte2syvo ah9VorRPHrupHoLEwh6B2HzIyMAARFb8MnD8AfBraWx85DjAt7qg7mRAskCZVtLzy8vst0/PBkVy rs+cg11fK3EgtwDra/kB6bWGMCQ4b1G4Uq+I8FkzQmpHi7Z8pE4NObcOOLGuCSfSA3DDoyPUNtyM M1zd+Nhkk5OAiJDZ/DTq6oHV/1WTMCwDBEDv6Rqyv7zX3CsuyVai2HWgjwbpduW7IU1p17Z57hLs Zl3/RI920jaP/cuWP2j2R69zR9//4G/3tClHPH9YyvWcxMOEEhLP+e1GDgvn2kxyyAoIh/QkGYXq 44uNzwj4W1C+bH+eeUOJtu06VDeiYe/kEltwl0D0mcaZ8bcx9LDGIyX6C5m/KaRmx6XSRgVP/XW3 +m1aelnxhOktUTPfYgmtO/0Widx/yAoqFh2vGY+5ZZ78pjD+Hfae4KEQ2rWocmRdGNkA81G3jsTM 6lhoeFDJ1/q5EDWsuDdTvfk2QDqckur/mRb/BcOQFf/YVmapx3ssqlL+7GM1C7J3S/+g4MuGxiQC FpRFWAb62hdjRmIZJsFL48vhffQfSWpukErlZGb92gFGkDJ4e0BwfexxrG3tMICht1rDhOReXu/B BV5ZWUUZqbzbAeTvutCDw7ZSi4j4/bysezxygslOfi9RG4SAv8fiNoHFWSoVylusOaPfEaw4ep8o 6TDxij5uYaBC9CGfqR9OPV/+YSe/MektTdl8rko709gEGwHPLrnYTTThPBqfSBN00xrDzY7V2k70 4wRUCbtrP6qLEwbHZw7Z459OUDKvw7k8UIElpxIUygYTe+a8Y8cx4+9IxwsdiFwpnoje3NGSgiXs yF6xxjaz2mHJeJEghKXAXQdeTl37ZNmqwC/CC4W23EH0w7SkP1vCeVyEspoEBuLea7wkGhsEjDGS Hil6FhQbS3K6kzuaE9ovXE+Tm2TQd9uf2hNY+qoHnZCQfhAx2SQEdXra0nyZOZxWMVfT+eDaxSK6 LC8pIV0r42+yv8VdDQplbmRzdHJlYW0NCmVuZG9iag0KMTIzNCAwIG9iag0KWyAwWyA1MDBdICA0 WyAxMDMwXSAgNDVbIDg0M10gXSANCmVuZG9iag0KMTIzNSAwIG9iag0KPDwvVHlwZS9YUmVmL1Np emUgMTIzNS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyA2MiAwIFIvSURbPDVCMkMzQkMxMEE0 QTQ4NEJCRjJFRTBGMUIzODU5Njc3Pjw1QjJDM0JDMTBBNEE0ODRCQkYyRUUwRjFCMzg1OTY3Nz5d IC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIzOTI+Pg0Kc3RyZWFtDQp4nDXadZSVVRuH4fmR Cqh0KAoGFiIGJiigpGDRotiEYCKhYqGChYrY3d1id3d3YLfY3XzDvt5v/phrPXudMzNrZvbc66xn ampq3xYtSu37ZjU1izmskG6FOj0KTRcUms0pNJ9ZaNG10LITrsVThVYTcVuh9ZWFNkMKbfsU2q1X 6DCm0HFQYc0Ghc4NC5v2LnT3ifr/URhYpzD8psKImwvjlytM8LVMm1+Y/nJhztuFk8bi6MLJnTG1 cMok/FyY6zsx93YsKpz6XWGeL+KqyYWrdyvcel1h/p2Fx4YVHh9ReHV84TXT+yMLH/QrfO2DLfyr 8Peswj9TFpN6owv1BxaWnFZoNK7QeHDtT6ampl7vmmMwC7NxdC01ff//kGNrn9BkaJlqD4M6qIt6 qO8Jx5kaoKHD401LYEmHJ5gaobHDE01NsJTDOaalTSeZlkFThyebmqG5w1NMLdDS4VxTK7R2eKqp DdqiHZb1kHmm5dDe4Wmm5bECOqAjVvTI000rYWWHZ5hWMZ1p6oRVHZ5lWh2rYQ2s6SFnmzpjLYfn mLpgbXTFOlgX62F9dMMG2BAbYWNsgk3RHT2wGTZHT/RCb2yBLdEHfdEP/TEAA7EVBmEwtsY22Bbb YXsMwVAMw3CMwEiMwg4YjR2xE8ZgZ+yCXbEbdsce2BNjMQ7jMQF7YSImYW/sg32xH/bHAZiMAzEF UzEN03EQDsYhmIFDcRgOxxE4EjNxFKq/E8dgFmbjWFR/C6rbX9336oZXd7q6zNX1rS5sdUWrS1ld vOqqVfeoujnVlakuSXURql/9c3EezscFuBAX4WJcgktxGS7HFbgSV+FqXINrcR2uxw24ETfhZtyC WzEft+F23IE7cRfuxj24F/fhfjyAB/EQHsYjeBSP4XE8gSfxFJ7GM3gWz+F5vIAX8RJexit4Fa/h dbyBN/EW3sY7eBcL8B7exwf4EB/hY3yCT/EZPscX+BJf4WssxDf4Ft/he/yAH/ETfsYv+BW/4Xf8 gT/xF/7GP/gX/2FRIbIbEY76Rn2jvqkP2U1D6G2WhNCmMRQ2S2FpaGqaQkzTHCqalpDPtIZuRjej m1kWgpn2UMooZZQySpkVIZFZGatAFLMqZDCiGDXMmpDBrAX9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/ 0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F /yJ8kcHoX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9 i/5F/6J/0b/oX/Qv+hf9i/5F/6JxkcHIYPQvahj9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv +hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/o X/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/ 0b/oX/Qv+hf9i/BFBqN/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F/6J/0b/oX/Qv+hf9i/5F /6J/0b/oXxb3r87g8gqz/YzygrF2CpqgDuqiHuqjMRqgIZbAkmiEpbA0lkFTNENztEBLtEJrtEFb tMOyWA7tsTxWQAd0xIpYCStjFXTCqlgNq2MNrInOWAtdsDa6Yh2si/WwPrphA2yIjbAxNsGm6I4e 2Ayboyd6oTe2wJbog77oh/4YgIHYCoMwDIOxNYZiG2yL7bA9hmA4RmAkRmEHjMaO2AljsDN2wa7Y DbtjD+yJsRiH8ZiAvTARk7A39sG+2A/74wBMxoGYgqmYhuk4CAfjEMzAoTgMh+MIHImZOApH4xjM wmwci+NwPE7AiZiDk3AyTsFcnIp5OA2n4wycibNwNs7BuTgP5+MCXIiLcDEuwaW4DJfjClyJq3A1 rsG1uA7X4wbciJtwM27BrZiP23A77sCduAt34x7ci/twPx7Ag3gID+MRPIrH8DiewJN4Ck/jGTyL 5/A8XsCLeAkv4xW8itfwOt7Am3gLb+MdvIsFeA8f4318gI/wIT7Bp/gMn+MLfImv8DUW4ht8i+/w PX7Aj/gJVbJ+wa/4Db/jD/yJv/A3/sG/+A+LCtG/6F+EL8IX4YvwRfGieFG8KF4UL9oYFY3+Rf+i f9G/6F/0L/oX4YsMRv+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+ Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX 4YvwRfGieFG8KF4UL9oY3Yz+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0 L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/ 6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+i f9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+ Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0L8IXGYz+RfgifFG86F+0MfoX /Yv+Rf+if9G/6F/0L/oX/Yv+Rf+if9G/6F/0r7xkq1e2pOkytaba+AV1UBf1UO34GqBa7i2BaqvX CNU6rwmqPV61wFsG1eauGaqVXQtUu7pWqJZ0bdAW7VBt55ZDtZZbHiugAzqi2sethGoRV23gOqFa va2G1bEGqp1bZ1TLti5YG12xDtbFelgf3bABNsRG2BibYFN0Rw9shs3RE73QG1tgS/RBX/RDfwzA QGyFQRiMrbENtsV22B5DMBTDMBwjMBKjsANGY0fshDHYGbtgV+yG3bEH9sRYjMN4TMBemIhJ2Bv7 YF/sh/1xACbjQEzBVEzDdByEg3EIZuBQHIbDcQSOxEwcVXspe5ZFf3qVfxDItwsL372zmDqnnV84 Y95i6n4yvPDp64XPl15M/QGzCwPvLVzfBqMKN5R/F6i/oPYJ/wMkh7JlDQplbmRzdHJlYW0NCmVu ZG9iag0KeHJlZg0KMCAxMjM2DQowMDAwMDAwMDYzIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAg bg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMzA4IDAwMDAwIG4NCjAwMDAwMDA1NzIgMDAw MDAgbg0KMDAwMDAwNDMxNiAwMDAwMCBuDQowMDAwMDA0NDkyIDAwMDAwIG4NCjAwMDAwMDQ3Mzcg MDAwMDAgbg0KMDAwMDAwNDkxMSAwMDAwMCBuDQowMDAwMDA1MTU3IDAwMDAwIG4NCjAwMDAwMDUy OTAgMDAwMDAgbg0KMDAwMDAwNTMyMCAwMDAwMCBuDQowMDAwMDA1NDgyIDAwMDAwIG4NCjAwMDAw MDU1NTYgMDAwMDAgbg0KMDAwMDAwNTc5OCAwMDAwMCBuDQowMDAwMDA1OTcwIDAwMDAwIG4NCjAw MDAwMDYyMTIgMDAwMDAgbg0KMDAwMDAwNjQ1MCAwMDAwMCBuDQowMDAwMDA4MDI5IDAwMDAwIG4N CjAwMDAwMDgyNjcgMDAwMDAgbg0KMDAwMDAxMDc1OCAwMDAwMCBuDQowMDAwMDExMDE1IDAwMDAw IG4NCjAwMDAwMTQ5MTMgMDAwMDAgbg0KMDAwMDAxNTE1MSAwMDAwMCBuDQowMDAwMDE4NDI0IDAw MDAwIG4NCjAwMDAwMTg2OTAgMDAwMDAgbg0KMDAwMDAyMTkzNSAwMDAwMCBuDQowMDAwMDIyMTky IDAwMDAwIG4NCjAwMDAwMjYzOTUgMDAwMDAgbg0KMDAwMDAyNjY2MSAwMDAwMCBuDQowMDAwMDMw Mzg3IDAwMDAwIG4NCjAwMDAwMzA2NzMgMDAwMDAgbg0KMDAwMDAzNjA1NyAwMDAwMCBuDQowMDAw MDM2MTk3IDAwMDAwIG4NCjAwMDAwMzYyMjcgMDAwMDAgbg0KMDAwMDAzNjM5NSAwMDAwMCBuDQow MDAwMDM2NDY5IDAwMDAwIG4NCjAwMDAwMzY3MTUgMDAwMDAgbg0KMDAwMDAzNjg1MSAwMDAwMCBu DQowMDAwMDM2ODgxIDAwMDAwIG4NCjAwMDAwMzcwNDUgMDAwMDAgbg0KMDAwMDAzNzExOSAwMDAw MCBuDQowMDAwMDM3MzU4IDAwMDAwIG4NCjAwMDAwMzc2MjQgMDAwMDAgbg0KMDAwMDA0Mjg2NiAw MDAwMCBuDQowMDAwMDQzMTA1IDAwMDAwIG4NCjAwMDAwNDU3MzkgMDAwMDAgbg0KMDAwMDA0NjAw NyAwMDAwMCBuDQowMDAwMDUwMjYwIDAwMDAwIG4NCjAwMDAwNTA1MTggMDAwMDAgbg0KMDAwMDA1 NDExOSAwMDAwMCBuDQowMDAwMDU0MzU4IDAwMDAwIG4NCjAwMDAwNTY5MTkgMDAwMDAgbg0KMDAw MDA1NzE1OCAwMDAwMCBuDQowMDAwMDYwMTUyIDAwMDAwIG4NCjAwMDAwNjA0MTAgMDAwMDAgbg0K MDAwMDA2NDM4OSAwMDAwMCBuDQowMDAwMDY0NjI4IDAwMDAwIG4NCjAwMDAwNjY2NTAgMDAwMDAg bg0KMDAwMDA2Njg4OSAwMDAwMCBuDQowMDAwMDY3OTU4IDAwMDAwIG4NCjAwMDAwNjgxOTggMDAw MDAgbg0KMDAwMDA2ODQyOCAwMDAwMCBuDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUg NjU1MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAw NjggNjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAw MDAwNzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAw MDAwMDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYN CjAwMDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1 IGYNCjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1 NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1 IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAw MDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAw MDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQow MDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBm DQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUz NSBmDQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2 NTUzNSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEw NSA2NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAw MDEwOCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAw MDAwMDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0K MDAwMDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUg Zg0KMDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1 MzUgZg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIg NjU1MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAx MjUgNjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAw MDAxMjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAw MDAwMDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYN CjAwMDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1NTM1 IGYNCjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAwMTM5IDY1 NTM1IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQowMDAwMDAwMTQy IDY1NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBmDQowMDAwMDAw MTQ1IDY1NTM1IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAwMDAwMDE0NyA2NTUzNSBmDQowMDAw MDAwMTQ4IDY1NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0KMDAwMDAwMDE1MCA2NTUzNSBmDQow MDAwMDAwMTUxIDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUgZg0KMDAwMDAwMDE1MyA2NTUzNSBm DQowMDAwMDAwMTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUgNjU1MzUgZg0KMDAwMDAwMDE1NiA2NTUz NSBmDQowMDAwMDAwMTU3IDY1NTM1IGYNCjAwMDAwMDAxNTggNjU1MzUgZg0KMDAwMDAwMDE1OSA2 NTUzNSBmDQowMDAwMDAwMTYwIDY1NTM1IGYNCjAwMDAwMDAxNjEgNjU1MzUgZg0KMDAwMDAwMDE2 MiA2NTUzNSBmDQowMDAwMDAwMTYzIDY1NTM1IGYNCjAwMDAwMDAxNjQgNjU1MzUgZg0KMDAwMDAw MDE2NSA2NTUzNSBmDQowMDAwMDAwMTY2IDY1NTM1IGYNCjAwMDAwMDAxNjcgNjU1MzUgZg0KMDAw MDAwMDE2OCA2NTUzNSBmDQowMDAwMDAwMTY5IDY1NTM1IGYNCjAwMDAwMDAxNzAgNjU1MzUgZg0K MDAwMDAwMDE3MSA2NTUzNSBmDQowMDAwMDAwMTcyIDY1NTM1IGYNCjAwMDAwMDAxNzMgNjU1MzUg Zg0KMDAwMDAwMDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1NTM1IGYNCjAwMDAwMDAxNzYgNjU1 MzUgZg0KMDAwMDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4IDY1NTM1IGYNCjAwMDAwMDAxNzkg NjU1MzUgZg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAwMTgxIDY1NTM1IGYNCjAwMDAwMDAx ODIgNjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAwMDAwMTg0IDY1NTM1IGYNCjAwMDAw MDAxODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQowMDAwMDAwMTg3IDY1NTM1IGYNCjAw MDAwMDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBmDQowMDAwMDAwMTkwIDY1NTM1IGYN CjAwMDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUzNSBmDQowMDAwMDAwMTkzIDY1NTM1 IGYNCjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2NTUzNSBmDQowMDAwMDAwMTk2IDY1 NTM1IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5OCA2NTUzNSBmDQowMDAwMDAwMTk5 IDY1NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAwMDIwMSA2NTUzNSBmDQowMDAwMDAw MjAyIDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAwMDAwMDIwNCA2NTUzNSBmDQowMDAw MDAwMjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0KMDAwMDAwMDIwNyA2NTUzNSBmDQow MDAwMDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkgNjU1MzUgZg0KMDAwMDAwMDIxMCA2NTUzNSBm DQowMDAwMDAwMjExIDY1NTM1IGYNCjAwMDAwMDAyMTIgNjU1MzUgZg0KMDAwMDAwMDIxMyA2NTUz NSBmDQowMDAwMDAwMjE0IDY1NTM1IGYNCjAwMDAwMDAyMTUgNjU1MzUgZg0KMDAwMDAwMDIxNiA2 NTUzNSBmDQowMDAwMDAwMjE3IDY1NTM1IGYNCjAwMDAwMDAyMTggNjU1MzUgZg0KMDAwMDAwMDIx OSA2NTUzNSBmDQowMDAwMDAwMjIwIDY1NTM1IGYNCjAwMDAwMDAyMjEgNjU1MzUgZg0KMDAwMDAw MDIyMiA2NTUzNSBmDQowMDAwMDAwMjIzIDY1NTM1IGYNCjAwMDAwMDAyMjQgNjU1MzUgZg0KMDAw MDAwMDIyNSA2NTUzNSBmDQowMDAwMDAwMjI2IDY1NTM1IGYNCjAwMDAwMDAyMjcgNjU1MzUgZg0K MDAwMDAwMDIyOCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1IGYNCjAwMDAwMDAyMzAgNjU1MzUg Zg0KMDAwMDAwMDIzMSA2NTUzNSBmDQowMDAwMDAwMjMyIDY1NTM1IGYNCjAwMDAwMDAyMzMgNjU1 MzUgZg0KMDAwMDAwMDIzNCA2NTUzNSBmDQowMDAwMDAwMjM1IDY1NTM1IGYNCjAwMDAwMDAyMzYg NjU1MzUgZg0KMDAwMDAwMDIzNyA2NTUzNSBmDQowMDAwMDAwMjM4IDY1NTM1IGYNCjAwMDAwMDAy MzkgNjU1MzUgZg0KMDAwMDAwMDI0MCA2NTUzNSBmDQowMDAwMDAwMjQxIDY1NTM1IGYNCjAwMDAw MDAyNDIgNjU1MzUgZg0KMDAwMDAwMDI0MyA2NTUzNSBmDQowMDAwMDAwMjQ0IDY1NTM1IGYNCjAw MDAwMDAyNDUgNjU1MzUgZg0KMDAwMDAwMDI0NiA2NTUzNSBmDQowMDAwMDAwMjQ3IDY1NTM1IGYN CjAwMDAwMDAyNDggNjU1MzUgZg0KMDAwMDAwMDI0OSA2NTUzNSBmDQowMDAwMDAwMjUwIDY1NTM1 IGYNCjAwMDAwMDAyNTEgNjU1MzUgZg0KMDAwMDAwMDI1MiA2NTUzNSBmDQowMDAwMDAwMjUzIDY1 NTM1IGYNCjAwMDAwMDAyNTQgNjU1MzUgZg0KMDAwMDAwMDI1NSA2NTUzNSBmDQowMDAwMDAwMjU2 IDY1NTM1IGYNCjAwMDAwMDAyNTcgNjU1MzUgZg0KMDAwMDAwMDI1OCA2NTUzNSBmDQowMDAwMDAw MjU5IDY1NTM1IGYNCjAwMDAwMDAyNjAgNjU1MzUgZg0KMDAwMDAwMDI2MSA2NTUzNSBmDQowMDAw MDAwMjYyIDY1NTM1IGYNCjAwMDAwMDAyNjMgNjU1MzUgZg0KMDAwMDAwMDI2NCA2NTUzNSBmDQow MDAwMDAwMjY1IDY1NTM1IGYNCjAwMDAwMDAyNjYgNjU1MzUgZg0KMDAwMDAwMDI2NyA2NTUzNSBm DQowMDAwMDAwMjY4IDY1NTM1IGYNCjAwMDAwMDAyNjkgNjU1MzUgZg0KMDAwMDAwMDI3MCA2NTUz NSBmDQowMDAwMDAwMjcxIDY1NTM1IGYNCjAwMDAwMDAyNzIgNjU1MzUgZg0KMDAwMDAwMDI3MyA2 NTUzNSBmDQowMDAwMDAwMjc0IDY1NTM1IGYNCjAwMDAwMDAyNzUgNjU1MzUgZg0KMDAwMDAwMDI3 NiA2NTUzNSBmDQowMDAwMDAwMjc3IDY1NTM1IGYNCjAwMDAwMDAyNzggNjU1MzUgZg0KMDAwMDAw MDI3OSA2NTUzNSBmDQowMDAwMDAwMjgwIDY1NTM1IGYNCjAwMDAwMDAyODEgNjU1MzUgZg0KMDAw MDAwMDI4MiA2NTUzNSBmDQowMDAwMDAwMjgzIDY1NTM1IGYNCjAwMDAwMDAyODQgNjU1MzUgZg0K MDAwMDAwMDI4NSA2NTUzNSBmDQowMDAwMDAwMjg2IDY1NTM1IGYNCjAwMDAwMDAyODcgNjU1MzUg Zg0KMDAwMDAwMDI4OCA2NTUzNSBmDQowMDAwMDAwMjg5IDY1NTM1IGYNCjAwMDAwMDAyOTAgNjU1 MzUgZg0KMDAwMDAwMDI5MSA2NTUzNSBmDQowMDAwMDAwMjkyIDY1NTM1IGYNCjAwMDAwMDAyOTMg NjU1MzUgZg0KMDAwMDAwMDI5NCA2NTUzNSBmDQowMDAwMDAwMjk1IDY1NTM1IGYNCjAwMDAwMDAy OTYgNjU1MzUgZg0KMDAwMDAwMDI5NyA2NTUzNSBmDQowMDAwMDAwMjk4IDY1NTM1IGYNCjAwMDAw MDAyOTkgNjU1MzUgZg0KMDAwMDAwMDMwMCA2NTUzNSBmDQowMDAwMDAwMzAxIDY1NTM1IGYNCjAw MDAwMDAzMDIgNjU1MzUgZg0KMDAwMDAwMDMwMyA2NTUzNSBmDQowMDAwMDAwMzA0IDY1NTM1IGYN CjAwMDAwMDAzMDUgNjU1MzUgZg0KMDAwMDAwMDMwNiA2NTUzNSBmDQowMDAwMDAwMzA3IDY1NTM1 IGYNCjAwMDAwMDAzMDggNjU1MzUgZg0KMDAwMDAwMDMwOSA2NTUzNSBmDQowMDAwMDAwMzEwIDY1 NTM1IGYNCjAwMDAwMDAzMTEgNjU1MzUgZg0KMDAwMDAwMDMxMiA2NTUzNSBmDQowMDAwMDAwMzEz IDY1NTM1IGYNCjAwMDAwMDAzMTQgNjU1MzUgZg0KMDAwMDAwMDMxNSA2NTUzNSBmDQowMDAwMDAw MzE2IDY1NTM1IGYNCjAwMDAwMDAzMTcgNjU1MzUgZg0KMDAwMDAwMDMxOCA2NTUzNSBmDQowMDAw MDAwMzE5IDY1NTM1IGYNCjAwMDAwMDAzMjAgNjU1MzUgZg0KMDAwMDAwMDMyMSA2NTUzNSBmDQow MDAwMDAwMzIyIDY1NTM1IGYNCjAwMDAwMDAzMjMgNjU1MzUgZg0KMDAwMDAwMDMyNCA2NTUzNSBm DQowMDAwMDAwMzI1IDY1NTM1IGYNCjAwMDAwMDAzMjYgNjU1MzUgZg0KMDAwMDAwMDMyNyA2NTUz NSBmDQowMDAwMDAwMzI4IDY1NTM1IGYNCjAwMDAwMDAzMjkgNjU1MzUgZg0KMDAwMDAwMDMzMCA2 NTUzNSBmDQowMDAwMDAwMzMxIDY1NTM1IGYNCjAwMDAwMDAzMzIgNjU1MzUgZg0KMDAwMDAwMDMz MyA2NTUzNSBmDQowMDAwMDAwMzM0IDY1NTM1IGYNCjAwMDAwMDAzMzUgNjU1MzUgZg0KMDAwMDAw MDMzNiA2NTUzNSBmDQowMDAwMDAwMzM3IDY1NTM1IGYNCjAwMDAwMDAzMzggNjU1MzUgZg0KMDAw MDAwMDMzOSA2NTUzNSBmDQowMDAwMDAwMzQwIDY1NTM1IGYNCjAwMDAwMDAzNDEgNjU1MzUgZg0K MDAwMDAwMDM0MiA2NTUzNSBmDQowMDAwMDAwMzQzIDY1NTM1IGYNCjAwMDAwMDAzNDQgNjU1MzUg Zg0KMDAwMDAwMDM0NSA2NTUzNSBmDQowMDAwMDAwMzQ2IDY1NTM1IGYNCjAwMDAwMDAzNDcgNjU1 MzUgZg0KMDAwMDAwMDM0OCA2NTUzNSBmDQowMDAwMDAwMzQ5IDY1NTM1IGYNCjAwMDAwMDAzNTAg NjU1MzUgZg0KMDAwMDAwMDM1MSA2NTUzNSBmDQowMDAwMDAwMzUyIDY1NTM1IGYNCjAwMDAwMDAz NTMgNjU1MzUgZg0KMDAwMDAwMDM1NCA2NTUzNSBmDQowMDAwMDAwMzU1IDY1NTM1IGYNCjAwMDAw MDAzNTYgNjU1MzUgZg0KMDAwMDAwMDM1NyA2NTUzNSBmDQowMDAwMDAwMzU4IDY1NTM1IGYNCjAw MDAwMDAzNTkgNjU1MzUgZg0KMDAwMDAwMDM2MCA2NTUzNSBmDQowMDAwMDAwMzYxIDY1NTM1IGYN CjAwMDAwMDAzNjIgNjU1MzUgZg0KMDAwMDAwMDM2MyA2NTUzNSBmDQowMDAwMDAwMzY0IDY1NTM1 IGYNCjAwMDAwMDAzNjUgNjU1MzUgZg0KMDAwMDAwMDM2NiA2NTUzNSBmDQowMDAwMDAwMzY3IDY1 NTM1IGYNCjAwMDAwMDAzNjggNjU1MzUgZg0KMDAwMDAwMDM2OSA2NTUzNSBmDQowMDAwMDAwMzcw IDY1NTM1IGYNCjAwMDAwMDAzNzEgNjU1MzUgZg0KMDAwMDAwMDM3MiA2NTUzNSBmDQowMDAwMDAw MzczIDY1NTM1IGYNCjAwMDAwMDAzNzQgNjU1MzUgZg0KMDAwMDAwMDM3NSA2NTUzNSBmDQowMDAw MDAwMzc2IDY1NTM1IGYNCjAwMDAwMDAzNzcgNjU1MzUgZg0KMDAwMDAwMDM3OCA2NTUzNSBmDQow MDAwMDAwMzc5IDY1NTM1IGYNCjAwMDAwMDAzODAgNjU1MzUgZg0KMDAwMDAwMDM4MSA2NTUzNSBm DQowMDAwMDAwMzgyIDY1NTM1IGYNCjAwMDAwMDAzODMgNjU1MzUgZg0KMDAwMDAwMDM4NCA2NTUz NSBmDQowMDAwMDAwMzg1IDY1NTM1IGYNCjAwMDAwMDAzODYgNjU1MzUgZg0KMDAwMDAwMDM4NyA2 NTUzNSBmDQowMDAwMDAwMzg4IDY1NTM1IGYNCjAwMDAwMDAzODkgNjU1MzUgZg0KMDAwMDAwMDM5 MCA2NTUzNSBmDQowMDAwMDAwMzkxIDY1NTM1IGYNCjAwMDAwMDAzOTIgNjU1MzUgZg0KMDAwMDAw MDM5MyA2NTUzNSBmDQowMDAwMDAwMzk0IDY1NTM1IGYNCjAwMDAwMDAzOTUgNjU1MzUgZg0KMDAw MDAwMDM5NiA2NTUzNSBmDQowMDAwMDAwMzk3IDY1NTM1IGYNCjAwMDAwMDAzOTggNjU1MzUgZg0K MDAwMDAwMDM5OSA2NTUzNSBmDQowMDAwMDAwNDAwIDY1NTM1IGYNCjAwMDAwMDA0MDEgNjU1MzUg Zg0KMDAwMDAwMDQwMiA2NTUzNSBmDQowMDAwMDAwNDAzIDY1NTM1IGYNCjAwMDAwMDA0MDQgNjU1 MzUgZg0KMDAwMDAwMDQwNSA2NTUzNSBmDQowMDAwMDAwNDA2IDY1NTM1IGYNCjAwMDAwMDA0MDcg NjU1MzUgZg0KMDAwMDAwMDQwOCA2NTUzNSBmDQowMDAwMDAwNDA5IDY1NTM1IGYNCjAwMDAwMDA0 MTAgNjU1MzUgZg0KMDAwMDAwMDQxMSA2NTUzNSBmDQowMDAwMDAwNDEyIDY1NTM1IGYNCjAwMDAw MDA0MTMgNjU1MzUgZg0KMDAwMDAwMDQxNCA2NTUzNSBmDQowMDAwMDAwNDE1IDY1NTM1IGYNCjAw MDAwMDA0MTYgNjU1MzUgZg0KMDAwMDAwMDQxNyA2NTUzNSBmDQowMDAwMDAwNDE4IDY1NTM1IGYN CjAwMDAwMDA0MTkgNjU1MzUgZg0KMDAwMDAwMDQyMCA2NTUzNSBmDQowMDAwMDAwNDIxIDY1NTM1 IGYNCjAwMDAwMDA0MjIgNjU1MzUgZg0KMDAwMDAwMDQyMyA2NTUzNSBmDQowMDAwMDAwNDI0IDY1 NTM1IGYNCjAwMDAwMDA0MjUgNjU1MzUgZg0KMDAwMDAwMDQyNiA2NTUzNSBmDQowMDAwMDAwNDI3 IDY1NTM1IGYNCjAwMDAwMDA0MjggNjU1MzUgZg0KMDAwMDAwMDQyOSA2NTUzNSBmDQowMDAwMDAw NDMwIDY1NTM1IGYNCjAwMDAwMDA0MzEgNjU1MzUgZg0KMDAwMDAwMDQzMiA2NTUzNSBmDQowMDAw MDAwNDMzIDY1NTM1IGYNCjAwMDAwMDA0MzQgNjU1MzUgZg0KMDAwMDAwMDQzNSA2NTUzNSBmDQow MDAwMDAwNDM2IDY1NTM1IGYNCjAwMDAwMDA0MzcgNjU1MzUgZg0KMDAwMDAwMDQzOCA2NTUzNSBm DQowMDAwMDAwNDM5IDY1NTM1IGYNCjAwMDAwMDA0NDAgNjU1MzUgZg0KMDAwMDAwMDQ0MSA2NTUz NSBmDQowMDAwMDAwNDQyIDY1NTM1IGYNCjAwMDAwMDA0NDMgNjU1MzUgZg0KMDAwMDAwMDQ0NCA2 NTUzNSBmDQowMDAwMDAwNDQ1IDY1NTM1IGYNCjAwMDAwMDA0NDYgNjU1MzUgZg0KMDAwMDAwMDQ0 NyA2NTUzNSBmDQowMDAwMDAwNDQ4IDY1NTM1IGYNCjAwMDAwMDA0NDkgNjU1MzUgZg0KMDAwMDAw MDQ1MCA2NTUzNSBmDQowMDAwMDAwNDUxIDY1NTM1IGYNCjAwMDAwMDA0NTIgNjU1MzUgZg0KMDAw MDAwMDQ1MyA2NTUzNSBmDQowMDAwMDAwNDU0IDY1NTM1IGYNCjAwMDAwMDA0NTUgNjU1MzUgZg0K MDAwMDAwMDQ1NiA2NTUzNSBmDQowMDAwMDAwNDU3IDY1NTM1IGYNCjAwMDAwMDA0NTggNjU1MzUg Zg0KMDAwMDAwMDQ1OSA2NTUzNSBmDQowMDAwMDAwNDYwIDY1NTM1IGYNCjAwMDAwMDA0NjEgNjU1 MzUgZg0KMDAwMDAwMDQ2MiA2NTUzNSBmDQowMDAwMDAwNDYzIDY1NTM1IGYNCjAwMDAwMDA0NjQg NjU1MzUgZg0KMDAwMDAwMDQ2NSA2NTUzNSBmDQowMDAwMDAwNDY2IDY1NTM1IGYNCjAwMDAwMDA0 NjcgNjU1MzUgZg0KMDAwMDAwMDQ2OCA2NTUzNSBmDQowMDAwMDAwNDY5IDY1NTM1IGYNCjAwMDAw MDA0NzAgNjU1MzUgZg0KMDAwMDAwMDQ3MSA2NTUzNSBmDQowMDAwMDAwNDcyIDY1NTM1IGYNCjAw MDAwMDA0NzMgNjU1MzUgZg0KMDAwMDAwMDQ3NCA2NTUzNSBmDQowMDAwMDAwNDc1IDY1NTM1IGYN CjAwMDAwMDA0NzYgNjU1MzUgZg0KMDAwMDAwMDQ3NyA2NTUzNSBmDQowMDAwMDAwNDc4IDY1NTM1 IGYNCjAwMDAwMDA0NzkgNjU1MzUgZg0KMDAwMDAwMDQ4MCA2NTUzNSBmDQowMDAwMDAwNDgxIDY1 NTM1IGYNCjAwMDAwMDA0ODIgNjU1MzUgZg0KMDAwMDAwMDQ4MyA2NTUzNSBmDQowMDAwMDAwNDg0 IDY1NTM1IGYNCjAwMDAwMDA0ODUgNjU1MzUgZg0KMDAwMDAwMDQ4NiA2NTUzNSBmDQowMDAwMDAw NDg3IDY1NTM1IGYNCjAwMDAwMDA0ODggNjU1MzUgZg0KMDAwMDAwMDQ4OSA2NTUzNSBmDQowMDAw MDAwNDkwIDY1NTM1IGYNCjAwMDAwMDA0OTEgNjU1MzUgZg0KMDAwMDAwMDQ5MiA2NTUzNSBmDQow MDAwMDAwNDkzIDY1NTM1IGYNCjAwMDAwMDA0OTQgNjU1MzUgZg0KMDAwMDAwMDQ5NSA2NTUzNSBm DQowMDAwMDAwNDk2IDY1NTM1IGYNCjAwMDAwMDA0OTcgNjU1MzUgZg0KMDAwMDAwMDQ5OCA2NTUz NSBmDQowMDAwMDAwNDk5IDY1NTM1IGYNCjAwMDAwMDA1MDAgNjU1MzUgZg0KMDAwMDAwMDUwMSA2 NTUzNSBmDQowMDAwMDAwNTAyIDY1NTM1IGYNCjAwMDAwMDA1MDMgNjU1MzUgZg0KMDAwMDAwMDUw NCA2NTUzNSBmDQowMDAwMDAwNTA1IDY1NTM1IGYNCjAwMDAwMDA1MDYgNjU1MzUgZg0KMDAwMDAw MDUwNyA2NTUzNSBmDQowMDAwMDAwNTA4IDY1NTM1IGYNCjAwMDAwMDA1MDkgNjU1MzUgZg0KMDAw MDAwMDUxMCA2NTUzNSBmDQowMDAwMDAwNTExIDY1NTM1IGYNCjAwMDAwMDA1MTIgNjU1MzUgZg0K MDAwMDAwMDUxMyA2NTUzNSBmDQowMDAwMDAwNTE0IDY1NTM1IGYNCjAwMDAwMDA1MTUgNjU1MzUg Zg0KMDAwMDAwMDUxNiA2NTUzNSBmDQowMDAwMDAwNTE3IDY1NTM1IGYNCjAwMDAwMDA1MTggNjU1 MzUgZg0KMDAwMDAwMDUxOSA2NTUzNSBmDQowMDAwMDAwNTIwIDY1NTM1IGYNCjAwMDAwMDA1MjEg NjU1MzUgZg0KMDAwMDAwMDUyMiA2NTUzNSBmDQowMDAwMDAwNTIzIDY1NTM1IGYNCjAwMDAwMDA1 MjQgNjU1MzUgZg0KMDAwMDAwMDUyNSA2NTUzNSBmDQowMDAwMDAwNTI2IDY1NTM1IGYNCjAwMDAw MDA1MjcgNjU1MzUgZg0KMDAwMDAwMDUyOCA2NTUzNSBmDQowMDAwMDAwNTI5IDY1NTM1IGYNCjAw MDAwMDA1MzAgNjU1MzUgZg0KMDAwMDAwMDUzMSA2NTUzNSBmDQowMDAwMDAwNTMyIDY1NTM1IGYN CjAwMDAwMDA1MzMgNjU1MzUgZg0KMDAwMDAwMDUzNCA2NTUzNSBmDQowMDAwMDAwNTM1IDY1NTM1 IGYNCjAwMDAwMDA1MzYgNjU1MzUgZg0KMDAwMDAwMDUzNyA2NTUzNSBmDQowMDAwMDAwNTM4IDY1 NTM1IGYNCjAwMDAwMDA1MzkgNjU1MzUgZg0KMDAwMDAwMDU0MCA2NTUzNSBmDQowMDAwMDAwNTQx IDY1NTM1IGYNCjAwMDAwMDA1NDIgNjU1MzUgZg0KMDAwMDAwMDU0MyA2NTUzNSBmDQowMDAwMDAw NTQ0IDY1NTM1IGYNCjAwMDAwMDA1NDUgNjU1MzUgZg0KMDAwMDAwMDU0NiA2NTUzNSBmDQowMDAw MDAwNTQ3IDY1NTM1IGYNCjAwMDAwMDA1NDggNjU1MzUgZg0KMDAwMDAwMDU0OSA2NTUzNSBmDQow MDAwMDAwNTUwIDY1NTM1IGYNCjAwMDAwMDA1NTEgNjU1MzUgZg0KMDAwMDAwMDU1MiA2NTUzNSBm DQowMDAwMDAwNTUzIDY1NTM1IGYNCjAwMDAwMDA1NTQgNjU1MzUgZg0KMDAwMDAwMDU1NSA2NTUz NSBmDQowMDAwMDAwNTU2IDY1NTM1IGYNCjAwMDAwMDA1NTcgNjU1MzUgZg0KMDAwMDAwMDU1OCA2 NTUzNSBmDQowMDAwMDAwNTU5IDY1NTM1IGYNCjAwMDAwMDA1NjAgNjU1MzUgZg0KMDAwMDAwMDU2 MSA2NTUzNSBmDQowMDAwMDAwNTYyIDY1NTM1IGYNCjAwMDAwMDA1NjMgNjU1MzUgZg0KMDAwMDAw MDU2NCA2NTUzNSBmDQowMDAwMDAwNTY1IDY1NTM1IGYNCjAwMDAwMDA1NjYgNjU1MzUgZg0KMDAw MDAwMDU2NyA2NTUzNSBmDQowMDAwMDAwNTY4IDY1NTM1IGYNCjAwMDAwMDA1NjkgNjU1MzUgZg0K MDAwMDAwMDU3MCA2NTUzNSBmDQowMDAwMDAwNTcxIDY1NTM1IGYNCjAwMDAwMDA1NzIgNjU1MzUg Zg0KMDAwMDAwMDU3MyA2NTUzNSBmDQowMDAwMDAwNTc0IDY1NTM1IGYNCjAwMDAwMDA1NzUgNjU1 MzUgZg0KMDAwMDAwMDU3NiA2NTUzNSBmDQowMDAwMDAwNTc3IDY1NTM1IGYNCjAwMDAwMDA1Nzgg NjU1MzUgZg0KMDAwMDAwMDU3OSA2NTUzNSBmDQowMDAwMDAwNTgwIDY1NTM1IGYNCjAwMDAwMDA1 ODEgNjU1MzUgZg0KMDAwMDAwMDU4MiA2NTUzNSBmDQowMDAwMDAwNTgzIDY1NTM1IGYNCjAwMDAw MDA1ODQgNjU1MzUgZg0KMDAwMDAwMDU4NSA2NTUzNSBmDQowMDAwMDAwNTg2IDY1NTM1IGYNCjAw MDAwMDA1ODcgNjU1MzUgZg0KMDAwMDAwMDU4OCA2NTUzNSBmDQowMDAwMDAwNTg5IDY1NTM1IGYN CjAwMDAwMDA1OTAgNjU1MzUgZg0KMDAwMDAwMDU5MSA2NTUzNSBmDQowMDAwMDAwNTkyIDY1NTM1 IGYNCjAwMDAwMDA1OTMgNjU1MzUgZg0KMDAwMDAwMDU5NCA2NTUzNSBmDQowMDAwMDAwNTk1IDY1 NTM1IGYNCjAwMDAwMDA1OTYgNjU1MzUgZg0KMDAwMDAwMDU5NyA2NTUzNSBmDQowMDAwMDAwNTk4 IDY1NTM1IGYNCjAwMDAwMDA1OTkgNjU1MzUgZg0KMDAwMDAwMDYwMCA2NTUzNSBmDQowMDAwMDAw NjAxIDY1NTM1IGYNCjAwMDAwMDA2MDIgNjU1MzUgZg0KMDAwMDAwMDYwMyA2NTUzNSBmDQowMDAw MDAwNjA0IDY1NTM1IGYNCjAwMDAwMDA2MDUgNjU1MzUgZg0KMDAwMDAwMDYwNiA2NTUzNSBmDQow MDAwMDAwNjA3IDY1NTM1IGYNCjAwMDAwMDA2MDggNjU1MzUgZg0KMDAwMDAwMDYwOSA2NTUzNSBm DQowMDAwMDAwNjEwIDY1NTM1IGYNCjAwMDAwMDA2MTEgNjU1MzUgZg0KMDAwMDAwMDYxMiA2NTUz NSBmDQowMDAwMDAwNjEzIDY1NTM1IGYNCjAwMDAwMDA2MTQgNjU1MzUgZg0KMDAwMDAwMDYxNSA2 NTUzNSBmDQowMDAwMDAwNjE2IDY1NTM1IGYNCjAwMDAwMDA2MTcgNjU1MzUgZg0KMDAwMDAwMDYx OCA2NTUzNSBmDQowMDAwMDAwNjE5IDY1NTM1IGYNCjAwMDAwMDA2MjAgNjU1MzUgZg0KMDAwMDAw MDYyMSA2NTUzNSBmDQowMDAwMDAwNjIyIDY1NTM1IGYNCjAwMDAwMDA2MjMgNjU1MzUgZg0KMDAw MDAwMDYyNCA2NTUzNSBmDQowMDAwMDAwNjI1IDY1NTM1IGYNCjAwMDAwMDA2MjYgNjU1MzUgZg0K MDAwMDAwMDYyNyA2NTUzNSBmDQowMDAwMDAwNjI4IDY1NTM1IGYNCjAwMDAwMDA2MjkgNjU1MzUg Zg0KMDAwMDAwMDYzMCA2NTUzNSBmDQowMDAwMDAwNjMxIDY1NTM1IGYNCjAwMDAwMDA2MzIgNjU1 MzUgZg0KMDAwMDAwMDYzMyA2NTUzNSBmDQowMDAwMDAwNjM0IDY1NTM1IGYNCjAwMDAwMDA2MzUg NjU1MzUgZg0KMDAwMDAwMDYzNiA2NTUzNSBmDQowMDAwMDAwNjM3IDY1NTM1IGYNCjAwMDAwMDA2 MzggNjU1MzUgZg0KMDAwMDAwMDYzOSA2NTUzNSBmDQowMDAwMDAwNjQwIDY1NTM1IGYNCjAwMDAw MDA2NDEgNjU1MzUgZg0KMDAwMDAwMDY0MiA2NTUzNSBmDQowMDAwMDAwNjQzIDY1NTM1IGYNCjAw MDAwMDA2NDQgNjU1MzUgZg0KMDAwMDAwMDY0NSA2NTUzNSBmDQowMDAwMDAwNjQ2IDY1NTM1IGYN CjAwMDAwMDA2NDcgNjU1MzUgZg0KMDAwMDAwMDY0OCA2NTUzNSBmDQowMDAwMDAwNjQ5IDY1NTM1 IGYNCjAwMDAwMDA2NTAgNjU1MzUgZg0KMDAwMDAwMDY1MSA2NTUzNSBmDQowMDAwMDAwNjUyIDY1 NTM1IGYNCjAwMDAwMDA2NTMgNjU1MzUgZg0KMDAwMDAwMDY1NCA2NTUzNSBmDQowMDAwMDAwNjU1 IDY1NTM1IGYNCjAwMDAwMDA2NTYgNjU1MzUgZg0KMDAwMDAwMDY1NyA2NTUzNSBmDQowMDAwMDAw NjU4IDY1NTM1IGYNCjAwMDAwMDA2NTkgNjU1MzUgZg0KMDAwMDAwMDY2MCA2NTUzNSBmDQowMDAw MDAwNjYxIDY1NTM1IGYNCjAwMDAwMDA2NjIgNjU1MzUgZg0KMDAwMDAwMDY2MyA2NTUzNSBmDQow MDAwMDAwNjY0IDY1NTM1IGYNCjAwMDAwMDA2NjUgNjU1MzUgZg0KMDAwMDAwMDY2NiA2NTUzNSBm DQowMDAwMDAwNjY3IDY1NTM1IGYNCjAwMDAwMDA2NjggNjU1MzUgZg0KMDAwMDAwMDY2OSA2NTUz NSBmDQowMDAwMDAwNjcwIDY1NTM1IGYNCjAwMDAwMDA2NzEgNjU1MzUgZg0KMDAwMDAwMDY3MiA2 NTUzNSBmDQowMDAwMDAwNjczIDY1NTM1IGYNCjAwMDAwMDA2NzQgNjU1MzUgZg0KMDAwMDAwMDY3 NSA2NTUzNSBmDQowMDAwMDAwNjc2IDY1NTM1IGYNCjAwMDAwMDA2NzcgNjU1MzUgZg0KMDAwMDAw MDY3OCA2NTUzNSBmDQowMDAwMDAwNjc5IDY1NTM1IGYNCjAwMDAwMDA2ODAgNjU1MzUgZg0KMDAw MDAwMDY4MSA2NTUzNSBmDQowMDAwMDAwNjgyIDY1NTM1IGYNCjAwMDAwMDA2ODMgNjU1MzUgZg0K MDAwMDAwMDY4NCA2NTUzNSBmDQowMDAwMDAwNjg1IDY1NTM1IGYNCjAwMDAwMDA2ODYgNjU1MzUg Zg0KMDAwMDAwMDY4NyA2NTUzNSBmDQowMDAwMDAwNjg4IDY1NTM1IGYNCjAwMDAwMDA2ODkgNjU1 MzUgZg0KMDAwMDAwMDY5MCA2NTUzNSBmDQowMDAwMDAwNjkxIDY1NTM1IGYNCjAwMDAwMDA2OTIg NjU1MzUgZg0KMDAwMDAwMDY5MyA2NTUzNSBmDQowMDAwMDAwNjk0IDY1NTM1IGYNCjAwMDAwMDA2 OTUgNjU1MzUgZg0KMDAwMDAwMDY5NiA2NTUzNSBmDQowMDAwMDAwNjk3IDY1NTM1IGYNCjAwMDAw MDA2OTggNjU1MzUgZg0KMDAwMDAwMDY5OSA2NTUzNSBmDQowMDAwMDAwNzAwIDY1NTM1IGYNCjAw MDAwMDA3MDEgNjU1MzUgZg0KMDAwMDAwMDcwMiA2NTUzNSBmDQowMDAwMDAwNzAzIDY1NTM1IGYN CjAwMDAwMDA3MDQgNjU1MzUgZg0KMDAwMDAwMDcwNSA2NTUzNSBmDQowMDAwMDAwNzA2IDY1NTM1 IGYNCjAwMDAwMDA3MDcgNjU1MzUgZg0KMDAwMDAwMDcwOCA2NTUzNSBmDQowMDAwMDAwNzA5IDY1 NTM1IGYNCjAwMDAwMDA3MTAgNjU1MzUgZg0KMDAwMDAwMDcxMSA2NTUzNSBmDQowMDAwMDAwNzEy IDY1NTM1IGYNCjAwMDAwMDA3MTMgNjU1MzUgZg0KMDAwMDAwMDcxNCA2NTUzNSBmDQowMDAwMDAw NzE1IDY1NTM1IGYNCjAwMDAwMDA3MTYgNjU1MzUgZg0KMDAwMDAwMDcxNyA2NTUzNSBmDQowMDAw MDAwNzE4IDY1NTM1IGYNCjAwMDAwMDA3MTkgNjU1MzUgZg0KMDAwMDAwMDcyMCA2NTUzNSBmDQow MDAwMDAwNzIxIDY1NTM1IGYNCjAwMDAwMDA3MjIgNjU1MzUgZg0KMDAwMDAwMDcyMyA2NTUzNSBm DQowMDAwMDAwNzI0IDY1NTM1IGYNCjAwMDAwMDA3MjUgNjU1MzUgZg0KMDAwMDAwMDcyNiA2NTUz NSBmDQowMDAwMDAwNzI3IDY1NTM1IGYNCjAwMDAwMDA3MjggNjU1MzUgZg0KMDAwMDAwMDcyOSA2 NTUzNSBmDQowMDAwMDAwNzMwIDY1NTM1IGYNCjAwMDAwMDA3MzEgNjU1MzUgZg0KMDAwMDAwMDcz MiA2NTUzNSBmDQowMDAwMDAwNzMzIDY1NTM1IGYNCjAwMDAwMDA3MzQgNjU1MzUgZg0KMDAwMDAw MDczNSA2NTUzNSBmDQowMDAwMDAwNzM2IDY1NTM1IGYNCjAwMDAwMDA3MzcgNjU1MzUgZg0KMDAw MDAwMDczOCA2NTUzNSBmDQowMDAwMDAwNzM5IDY1NTM1IGYNCjAwMDAwMDA3NDAgNjU1MzUgZg0K MDAwMDAwMDc0MSA2NTUzNSBmDQowMDAwMDAwNzQyIDY1NTM1IGYNCjAwMDAwMDA3NDMgNjU1MzUg Zg0KMDAwMDAwMDc0NCA2NTUzNSBmDQowMDAwMDAwNzQ1IDY1NTM1IGYNCjAwMDAwMDA3NDYgNjU1 MzUgZg0KMDAwMDAwMDc0NyA2NTUzNSBmDQowMDAwMDAwNzQ4IDY1NTM1IGYNCjAwMDAwMDA3NDkg NjU1MzUgZg0KMDAwMDAwMDc1MCA2NTUzNSBmDQowMDAwMDAwNzUxIDY1NTM1IGYNCjAwMDAwMDA3 NTIgNjU1MzUgZg0KMDAwMDAwMDc1MyA2NTUzNSBmDQowMDAwMDAwNzU0IDY1NTM1IGYNCjAwMDAw MDA3NTUgNjU1MzUgZg0KMDAwMDAwMDc1NiA2NTUzNSBmDQowMDAwMDAwNzU3IDY1NTM1IGYNCjAw MDAwMDA3NTggNjU1MzUgZg0KMDAwMDAwMDc1OSA2NTUzNSBmDQowMDAwMDAwNzYwIDY1NTM1IGYN CjAwMDAwMDA3NjEgNjU1MzUgZg0KMDAwMDAwMDc2MiA2NTUzNSBmDQowMDAwMDAwNzYzIDY1NTM1 IGYNCjAwMDAwMDA3NjQgNjU1MzUgZg0KMDAwMDAwMDc2NSA2NTUzNSBmDQowMDAwMDAwNzY2IDY1 NTM1IGYNCjAwMDAwMDA3NjcgNjU1MzUgZg0KMDAwMDAwMDc2OCA2NTUzNSBmDQowMDAwMDAwNzY5 IDY1NTM1IGYNCjAwMDAwMDA3NzAgNjU1MzUgZg0KMDAwMDAwMDc3MSA2NTUzNSBmDQowMDAwMDAw NzcyIDY1NTM1IGYNCjAwMDAwMDA3NzMgNjU1MzUgZg0KMDAwMDAwMDc3NCA2NTUzNSBmDQowMDAw MDAwNzc1IDY1NTM1IGYNCjAwMDAwMDA3NzYgNjU1MzUgZg0KMDAwMDAwMDc3NyA2NTUzNSBmDQow MDAwMDAwNzc4IDY1NTM1IGYNCjAwMDAwMDA3NzkgNjU1MzUgZg0KMDAwMDAwMDc4MCA2NTUzNSBm DQowMDAwMDAwNzgxIDY1NTM1IGYNCjAwMDAwMDA3ODIgNjU1MzUgZg0KMDAwMDAwMDc4MyA2NTUz NSBmDQowMDAwMDAwNzg0IDY1NTM1IGYNCjAwMDAwMDA3ODUgNjU1MzUgZg0KMDAwMDAwMDc4NiA2 NTUzNSBmDQowMDAwMDAwNzg3IDY1NTM1IGYNCjAwMDAwMDA3ODggNjU1MzUgZg0KMDAwMDAwMDc4 OSA2NTUzNSBmDQowMDAwMDAwNzkwIDY1NTM1IGYNCjAwMDAwMDA3OTEgNjU1MzUgZg0KMDAwMDAw MDc5MiA2NTUzNSBmDQowMDAwMDAwNzkzIDY1NTM1IGYNCjAwMDAwMDA3OTQgNjU1MzUgZg0KMDAw MDAwMDc5NSA2NTUzNSBmDQowMDAwMDAwNzk2IDY1NTM1IGYNCjAwMDAwMDA3OTcgNjU1MzUgZg0K MDAwMDAwMDc5OCA2NTUzNSBmDQowMDAwMDAwNzk5IDY1NTM1IGYNCjAwMDAwMDA4MDAgNjU1MzUg Zg0KMDAwMDAwMDgwMSA2NTUzNSBmDQowMDAwMDAwODAyIDY1NTM1IGYNCjAwMDAwMDA4MDMgNjU1 MzUgZg0KMDAwMDAwMDgwNCA2NTUzNSBmDQowMDAwMDAwODA1IDY1NTM1IGYNCjAwMDAwMDA4MDYg NjU1MzUgZg0KMDAwMDAwMDgwNyA2NTUzNSBmDQowMDAwMDAwODA4IDY1NTM1IGYNCjAwMDAwMDA4 MDkgNjU1MzUgZg0KMDAwMDAwMDgxMCA2NTUzNSBmDQowMDAwMDAwODExIDY1NTM1IGYNCjAwMDAw MDA4MTIgNjU1MzUgZg0KMDAwMDAwMDgxMyA2NTUzNSBmDQowMDAwMDAwODE0IDY1NTM1IGYNCjAw MDAwMDA4MTUgNjU1MzUgZg0KMDAwMDAwMDgxNiA2NTUzNSBmDQowMDAwMDAwODE3IDY1NTM1IGYN CjAwMDAwMDA4MTggNjU1MzUgZg0KMDAwMDAwMDgxOSA2NTUzNSBmDQowMDAwMDAwODIwIDY1NTM1 IGYNCjAwMDAwMDA4MjEgNjU1MzUgZg0KMDAwMDAwMDgyMiA2NTUzNSBmDQowMDAwMDAwODIzIDY1 NTM1IGYNCjAwMDAwMDA4MjQgNjU1MzUgZg0KMDAwMDAwMDgyNSA2NTUzNSBmDQowMDAwMDAwODI2 IDY1NTM1IGYNCjAwMDAwMDA4MjcgNjU1MzUgZg0KMDAwMDAwMDgyOCA2NTUzNSBmDQowMDAwMDAw ODI5IDY1NTM1IGYNCjAwMDAwMDA4MzAgNjU1MzUgZg0KMDAwMDAwMDgzMSA2NTUzNSBmDQowMDAw MDAwODMyIDY1NTM1IGYNCjAwMDAwMDA4MzMgNjU1MzUgZg0KMDAwMDAwMDgzNCA2NTUzNSBmDQow MDAwMDAwODM1IDY1NTM1IGYNCjAwMDAwMDA4MzYgNjU1MzUgZg0KMDAwMDAwMDgzNyA2NTUzNSBm DQowMDAwMDAwODM4IDY1NTM1IGYNCjAwMDAwMDA4MzkgNjU1MzUgZg0KMDAwMDAwMDg0MCA2NTUz NSBmDQowMDAwMDAwODQxIDY1NTM1IGYNCjAwMDAwMDA4NDIgNjU1MzUgZg0KMDAwMDAwMDg0MyA2 NTUzNSBmDQowMDAwMDAwODQ0IDY1NTM1IGYNCjAwMDAwMDA4NDUgNjU1MzUgZg0KMDAwMDAwMDg0 NiA2NTUzNSBmDQowMDAwMDAwODQ3IDY1NTM1IGYNCjAwMDAwMDA4NDggNjU1MzUgZg0KMDAwMDAw MDg0OSA2NTUzNSBmDQowMDAwMDAwODUwIDY1NTM1IGYNCjAwMDAwMDA4NTEgNjU1MzUgZg0KMDAw MDAwMDg1MiA2NTUzNSBmDQowMDAwMDAwODUzIDY1NTM1IGYNCjAwMDAwMDA4NTQgNjU1MzUgZg0K MDAwMDAwMDg1NSA2NTUzNSBmDQowMDAwMDAwODU2IDY1NTM1IGYNCjAwMDAwMDA4NTcgNjU1MzUg Zg0KMDAwMDAwMDg1OCA2NTUzNSBmDQowMDAwMDAwODU5IDY1NTM1IGYNCjAwMDAwMDA4NjAgNjU1 MzUgZg0KMDAwMDAwMDg2MSA2NTUzNSBmDQowMDAwMDAwODYyIDY1NTM1IGYNCjAwMDAwMDA4NjMg NjU1MzUgZg0KMDAwMDAwMDg2NCA2NTUzNSBmDQowMDAwMDAwODY1IDY1NTM1IGYNCjAwMDAwMDA4 NjYgNjU1MzUgZg0KMDAwMDAwMDg2NyA2NTUzNSBmDQowMDAwMDAwODY4IDY1NTM1IGYNCjAwMDAw MDA4NjkgNjU1MzUgZg0KMDAwMDAwMDg3MCA2NTUzNSBmDQowMDAwMDAwODcxIDY1NTM1IGYNCjAw MDAwMDA4NzIgNjU1MzUgZg0KMDAwMDAwMDg3MyA2NTUzNSBmDQowMDAwMDAwODc0IDY1NTM1IGYN CjAwMDAwMDA4NzUgNjU1MzUgZg0KMDAwMDAwMDg3NiA2NTUzNSBmDQowMDAwMDAwODc3IDY1NTM1 IGYNCjAwMDAwMDA4NzggNjU1MzUgZg0KMDAwMDAwMDg3OSA2NTUzNSBmDQowMDAwMDAwODgwIDY1 NTM1IGYNCjAwMDAwMDA4ODEgNjU1MzUgZg0KMDAwMDAwMDg4MiA2NTUzNSBmDQowMDAwMDAwODgz IDY1NTM1IGYNCjAwMDAwMDA4ODQgNjU1MzUgZg0KMDAwMDAwMDg4NSA2NTUzNSBmDQowMDAwMDAw ODg2IDY1NTM1IGYNCjAwMDAwMDA4ODcgNjU1MzUgZg0KMDAwMDAwMDg4OCA2NTUzNSBmDQowMDAw MDAwODg5IDY1NTM1IGYNCjAwMDAwMDA4OTAgNjU1MzUgZg0KMDAwMDAwMDg5MSA2NTUzNSBmDQow MDAwMDAwODkyIDY1NTM1IGYNCjAwMDAwMDA4OTMgNjU1MzUgZg0KMDAwMDAwMDg5NCA2NTUzNSBm DQowMDAwMDAwODk1IDY1NTM1IGYNCjAwMDAwMDA4OTYgNjU1MzUgZg0KMDAwMDAwMDg5NyA2NTUz NSBmDQowMDAwMDAwODk4IDY1NTM1IGYNCjAwMDAwMDA4OTkgNjU1MzUgZg0KMDAwMDAwMDkwMCA2 NTUzNSBmDQowMDAwMDAwOTAxIDY1NTM1IGYNCjAwMDAwMDA5MDIgNjU1MzUgZg0KMDAwMDAwMDkw MyA2NTUzNSBmDQowMDAwMDAwOTA0IDY1NTM1IGYNCjAwMDAwMDA5MDUgNjU1MzUgZg0KMDAwMDAw MDkwNiA2NTUzNSBmDQowMDAwMDAwOTA3IDY1NTM1IGYNCjAwMDAwMDA5MDggNjU1MzUgZg0KMDAw MDAwMDkwOSA2NTUzNSBmDQowMDAwMDAwOTEwIDY1NTM1IGYNCjAwMDAwMDA5MTEgNjU1MzUgZg0K MDAwMDAwMDkxMiA2NTUzNSBmDQowMDAwMDAwOTEzIDY1NTM1IGYNCjAwMDAwMDA5MTQgNjU1MzUg Zg0KMDAwMDAwMDkxNSA2NTUzNSBmDQowMDAwMDAwOTE2IDY1NTM1IGYNCjAwMDAwMDA5MTcgNjU1 MzUgZg0KMDAwMDAwMDkxOCA2NTUzNSBmDQowMDAwMDAwOTE5IDY1NTM1IGYNCjAwMDAwMDA5MjAg NjU1MzUgZg0KMDAwMDAwMDkyMSA2NTUzNSBmDQowMDAwMDAwOTIyIDY1NTM1IGYNCjAwMDAwMDA5 MjMgNjU1MzUgZg0KMDAwMDAwMDkyNCA2NTUzNSBmDQowMDAwMDAwOTI1IDY1NTM1IGYNCjAwMDAw MDA5MjYgNjU1MzUgZg0KMDAwMDAwMDkyNyA2NTUzNSBmDQowMDAwMDAwOTI4IDY1NTM1IGYNCjAw MDAwMDA5MjkgNjU1MzUgZg0KMDAwMDAwMDkzMCA2NTUzNSBmDQowMDAwMDAwOTMxIDY1NTM1IGYN CjAwMDAwMDA5MzIgNjU1MzUgZg0KMDAwMDAwMDkzMyA2NTUzNSBmDQowMDAwMDAwOTM0IDY1NTM1 IGYNCjAwMDAwMDA5MzUgNjU1MzUgZg0KMDAwMDAwMDkzNiA2NTUzNSBmDQowMDAwMDAwOTM3IDY1 NTM1IGYNCjAwMDAwMDA5MzggNjU1MzUgZg0KMDAwMDAwMDkzOSA2NTUzNSBmDQowMDAwMDAwOTQw IDY1NTM1IGYNCjAwMDAwMDA5NDEgNjU1MzUgZg0KMDAwMDAwMDk0MiA2NTUzNSBmDQowMDAwMDAw OTQzIDY1NTM1IGYNCjAwMDAwMDA5NDQgNjU1MzUgZg0KMDAwMDAwMDk0NSA2NTUzNSBmDQowMDAw MDAwOTQ2IDY1NTM1IGYNCjAwMDAwMDA5NDcgNjU1MzUgZg0KMDAwMDAwMDk0OCA2NTUzNSBmDQow MDAwMDAwOTQ5IDY1NTM1IGYNCjAwMDAwMDA5NTAgNjU1MzUgZg0KMDAwMDAwMDk1MSA2NTUzNSBm DQowMDAwMDAwOTUyIDY1NTM1IGYNCjAwMDAwMDA5NTMgNjU1MzUgZg0KMDAwMDAwMDk1NCA2NTUz NSBmDQowMDAwMDAwOTU1IDY1NTM1IGYNCjAwMDAwMDA5NTYgNjU1MzUgZg0KMDAwMDAwMDk1NyA2 NTUzNSBmDQowMDAwMDAwOTU4IDY1NTM1IGYNCjAwMDAwMDA5NTkgNjU1MzUgZg0KMDAwMDAwMDk2 MCA2NTUzNSBmDQowMDAwMDAwOTYxIDY1NTM1IGYNCjAwMDAwMDA5NjIgNjU1MzUgZg0KMDAwMDAw MDk2MyA2NTUzNSBmDQowMDAwMDAwOTY0IDY1NTM1IGYNCjAwMDAwMDA5NjUgNjU1MzUgZg0KMDAw MDAwMDk2NiA2NTUzNSBmDQowMDAwMDAwOTY3IDY1NTM1IGYNCjAwMDAwMDA5NjggNjU1MzUgZg0K MDAwMDAwMDk2OSA2NTUzNSBmDQowMDAwMDAwOTcwIDY1NTM1IGYNCjAwMDAwMDA5NzEgNjU1MzUg Zg0KMDAwMDAwMDk3MiA2NTUzNSBmDQowMDAwMDAwOTczIDY1NTM1IGYNCjAwMDAwMDA5NzQgNjU1 MzUgZg0KMDAwMDAwMDk3NSA2NTUzNSBmDQowMDAwMDAwOTc2IDY1NTM1IGYNCjAwMDAwMDA5Nzcg NjU1MzUgZg0KMDAwMDAwMDk3OCA2NTUzNSBmDQowMDAwMDAwOTc5IDY1NTM1IGYNCjAwMDAwMDA5 ODAgNjU1MzUgZg0KMDAwMDAwMDk4MSA2NTUzNSBmDQowMDAwMDAwOTgyIDY1NTM1IGYNCjAwMDAw MDA5ODMgNjU1MzUgZg0KMDAwMDAwMDk4NCA2NTUzNSBmDQowMDAwMDAwOTg1IDY1NTM1IGYNCjAw MDAwMDA5ODYgNjU1MzUgZg0KMDAwMDAwMDk4NyA2NTUzNSBmDQowMDAwMDAwOTg4IDY1NTM1IGYN CjAwMDAwMDA5ODkgNjU1MzUgZg0KMDAwMDAwMDk5MCA2NTUzNSBmDQowMDAwMDAwOTkxIDY1NTM1 IGYNCjAwMDAwMDA5OTIgNjU1MzUgZg0KMDAwMDAwMDk5MyA2NTUzNSBmDQowMDAwMDAwOTk0IDY1 NTM1IGYNCjAwMDAwMDA5OTUgNjU1MzUgZg0KMDAwMDAwMDk5NiA2NTUzNSBmDQowMDAwMDAwOTk3 IDY1NTM1IGYNCjAwMDAwMDA5OTggNjU1MzUgZg0KMDAwMDAwMDk5OSA2NTUzNSBmDQowMDAwMDAx MDAwIDY1NTM1IGYNCjAwMDAwMDEwMDEgNjU1MzUgZg0KMDAwMDAwMTAwMiA2NTUzNSBmDQowMDAw MDAxMDAzIDY1NTM1IGYNCjAwMDAwMDEwMDQgNjU1MzUgZg0KMDAwMDAwMTAwNSA2NTUzNSBmDQow MDAwMDAxMDA2IDY1NTM1IGYNCjAwMDAwMDEwMDcgNjU1MzUgZg0KMDAwMDAwMTAwOCA2NTUzNSBm DQowMDAwMDAxMDA5IDY1NTM1IGYNCjAwMDAwMDEwMTAgNjU1MzUgZg0KMDAwMDAwMTAxMSA2NTUz NSBmDQowMDAwMDAxMDEyIDY1NTM1IGYNCjAwMDAwMDEwMTMgNjU1MzUgZg0KMDAwMDAwMTAxNCA2 NTUzNSBmDQowMDAwMDAxMDE1IDY1NTM1IGYNCjAwMDAwMDEwMTYgNjU1MzUgZg0KMDAwMDAwMTAx NyA2NTUzNSBmDQowMDAwMDAxMDE4IDY1NTM1IGYNCjAwMDAwMDEwMTkgNjU1MzUgZg0KMDAwMDAw MTAyMCA2NTUzNSBmDQowMDAwMDAxMDIxIDY1NTM1IGYNCjAwMDAwMDEwMjIgNjU1MzUgZg0KMDAw MDAwMTAyMyA2NTUzNSBmDQowMDAwMDAxMDI0IDY1NTM1IGYNCjAwMDAwMDEwMjUgNjU1MzUgZg0K MDAwMDAwMTAyNiA2NTUzNSBmDQowMDAwMDAxMDI3IDY1NTM1IGYNCjAwMDAwMDEwMjggNjU1MzUg Zg0KMDAwMDAwMTAyOSA2NTUzNSBmDQowMDAwMDAxMDMwIDY1NTM1IGYNCjAwMDAwMDEwMzEgNjU1 MzUgZg0KMDAwMDAwMTAzMiA2NTUzNSBmDQowMDAwMDAxMDMzIDY1NTM1IGYNCjAwMDAwMDEwMzQg NjU1MzUgZg0KMDAwMDAwMTAzNSA2NTUzNSBmDQowMDAwMDAxMDM2IDY1NTM1IGYNCjAwMDAwMDEw MzcgNjU1MzUgZg0KMDAwMDAwMTAzOCA2NTUzNSBmDQowMDAwMDAxMDM5IDY1NTM1IGYNCjAwMDAw MDEwNDAgNjU1MzUgZg0KMDAwMDAwMTA0MSA2NTUzNSBmDQowMDAwMDAxMDQyIDY1NTM1IGYNCjAw MDAwMDEwNDMgNjU1MzUgZg0KMDAwMDAwMTA0NCA2NTUzNSBmDQowMDAwMDAxMDQ1IDY1NTM1IGYN CjAwMDAwMDEwNDYgNjU1MzUgZg0KMDAwMDAwMTA0NyA2NTUzNSBmDQowMDAwMDAxMDQ4IDY1NTM1 IGYNCjAwMDAwMDEwNDkgNjU1MzUgZg0KMDAwMDAwMTA1MCA2NTUzNSBmDQowMDAwMDAxMDUxIDY1 NTM1IGYNCjAwMDAwMDEwNTIgNjU1MzUgZg0KMDAwMDAwMTA1MyA2NTUzNSBmDQowMDAwMDAxMDU0 IDY1NTM1IGYNCjAwMDAwMDEwNTUgNjU1MzUgZg0KMDAwMDAwMTA1NiA2NTUzNSBmDQowMDAwMDAx MDU3IDY1NTM1IGYNCjAwMDAwMDEwNTggNjU1MzUgZg0KMDAwMDAwMTA1OSA2NTUzNSBmDQowMDAw MDAxMDYwIDY1NTM1IGYNCjAwMDAwMDEwNjEgNjU1MzUgZg0KMDAwMDAwMTA2MiA2NTUzNSBmDQow MDAwMDAxMDYzIDY1NTM1IGYNCjAwMDAwMDEwNjQgNjU1MzUgZg0KMDAwMDAwMTA2NSA2NTUzNSBm DQowMDAwMDAxMDY2IDY1NTM1IGYNCjAwMDAwMDEwNjcgNjU1MzUgZg0KMDAwMDAwMTA2OCA2NTUz NSBmDQowMDAwMDAxMDY5IDY1NTM1IGYNCjAwMDAwMDEwNzAgNjU1MzUgZg0KMDAwMDAwMTA3MSA2 NTUzNSBmDQowMDAwMDAxMDcyIDY1NTM1IGYNCjAwMDAwMDEwNzMgNjU1MzUgZg0KMDAwMDAwMTA3 NCA2NTUzNSBmDQowMDAwMDAxMDc1IDY1NTM1IGYNCjAwMDAwMDEwNzYgNjU1MzUgZg0KMDAwMDAw MTA3NyA2NTUzNSBmDQowMDAwMDAxMDc4IDY1NTM1IGYNCjAwMDAwMDEwNzkgNjU1MzUgZg0KMDAw MDAwMTA4MCA2NTUzNSBmDQowMDAwMDAxMDgxIDY1NTM1IGYNCjAwMDAwMDEwODIgNjU1MzUgZg0K MDAwMDAwMTA4MyA2NTUzNSBmDQowMDAwMDAxMDg0IDY1NTM1IGYNCjAwMDAwMDEwODUgNjU1MzUg Zg0KMDAwMDAwMTA4NiA2NTUzNSBmDQowMDAwMDAxMDg3IDY1NTM1IGYNCjAwMDAwMDEwODggNjU1 MzUgZg0KMDAwMDAwMTA4OSA2NTUzNSBmDQowMDAwMDAxMDkwIDY1NTM1IGYNCjAwMDAwMDEwOTEg NjU1MzUgZg0KMDAwMDAwMTA5MiA2NTUzNSBmDQowMDAwMDAxMDkzIDY1NTM1IGYNCjAwMDAwMDEw OTQgNjU1MzUgZg0KMDAwMDAwMTA5NSA2NTUzNSBmDQowMDAwMDAxMDk2IDY1NTM1IGYNCjAwMDAw MDEwOTcgNjU1MzUgZg0KMDAwMDAwMTA5OCA2NTUzNSBmDQowMDAwMDAxMDk5IDY1NTM1IGYNCjAw MDAwMDExMDAgNjU1MzUgZg0KMDAwMDAwMTEwMSA2NTUzNSBmDQowMDAwMDAxMTAyIDY1NTM1IGYN CjAwMDAwMDExMDMgNjU1MzUgZg0KMDAwMDAwMTEwNCA2NTUzNSBmDQowMDAwMDAxMTA1IDY1NTM1 IGYNCjAwMDAwMDExMDYgNjU1MzUgZg0KMDAwMDAwMTEwNyA2NTUzNSBmDQowMDAwMDAxMTA4IDY1 NTM1IGYNCjAwMDAwMDExMDkgNjU1MzUgZg0KMDAwMDAwMTExMCA2NTUzNSBmDQowMDAwMDAxMTEx IDY1NTM1IGYNCjAwMDAwMDExMTIgNjU1MzUgZg0KMDAwMDAwMTExMyA2NTUzNSBmDQowMDAwMDAx MTE0IDY1NTM1IGYNCjAwMDAwMDExMTUgNjU1MzUgZg0KMDAwMDAwMTExNiA2NTUzNSBmDQowMDAw MDAxMTE3IDY1NTM1IGYNCjAwMDAwMDExMTggNjU1MzUgZg0KMDAwMDAwMTExOSA2NTUzNSBmDQow MDAwMDAxMTIwIDY1NTM1IGYNCjAwMDAwMDExMjEgNjU1MzUgZg0KMDAwMDAwMTEyMiA2NTUzNSBm DQowMDAwMDAxMTIzIDY1NTM1IGYNCjAwMDAwMDExMjQgNjU1MzUgZg0KMDAwMDAwMTEyNSA2NTUz NSBmDQowMDAwMDAxMTI2IDY1NTM1IGYNCjAwMDAwMDExMjcgNjU1MzUgZg0KMDAwMDAwMTEyOCA2 NTUzNSBmDQowMDAwMDAxMTI5IDY1NTM1IGYNCjAwMDAwMDExMzAgNjU1MzUgZg0KMDAwMDAwMTEz MSA2NTUzNSBmDQowMDAwMDAxMTMyIDY1NTM1IGYNCjAwMDAwMDExMzMgNjU1MzUgZg0KMDAwMDAw MTEzNCA2NTUzNSBmDQowMDAwMDAxMTM1IDY1NTM1IGYNCjAwMDAwMDExMzYgNjU1MzUgZg0KMDAw MDAwMTEzNyA2NTUzNSBmDQowMDAwMDAxMTM4IDY1NTM1IGYNCjAwMDAwMDExMzkgNjU1MzUgZg0K MDAwMDAwMTE0MCA2NTUzNSBmDQowMDAwMDAxMTQxIDY1NTM1IGYNCjAwMDAwMDExNDIgNjU1MzUg Zg0KMDAwMDAwMTE0MyA2NTUzNSBmDQowMDAwMDAxMTQ0IDY1NTM1IGYNCjAwMDAwMDExNDUgNjU1 MzUgZg0KMDAwMDAwMTE0NiA2NTUzNSBmDQowMDAwMDAxMTQ3IDY1NTM1IGYNCjAwMDAwMDExNDgg NjU1MzUgZg0KMDAwMDAwMTE0OSA2NTUzNSBmDQowMDAwMDAxMTUwIDY1NTM1IGYNCjAwMDAwMDEx NTEgNjU1MzUgZg0KMDAwMDAwMTE1MiA2NTUzNSBmDQowMDAwMDAxMTUzIDY1NTM1IGYNCjAwMDAw MDExNTQgNjU1MzUgZg0KMDAwMDAwMTE1NSA2NTUzNSBmDQowMDAwMDAxMTU2IDY1NTM1IGYNCjAw MDAwMDExNTcgNjU1MzUgZg0KMDAwMDAwMTE1OCA2NTUzNSBmDQowMDAwMDAxMTU5IDY1NTM1IGYN CjAwMDAwMDExNjAgNjU1MzUgZg0KMDAwMDAwMTE2MSA2NTUzNSBmDQowMDAwMDAxMTYyIDY1NTM1 IGYNCjAwMDAwMDExNjMgNjU1MzUgZg0KMDAwMDAwMTE2NCA2NTUzNSBmDQowMDAwMDAxMTY1IDY1 NTM1IGYNCjAwMDAwMDExNjYgNjU1MzUgZg0KMDAwMDAwMTE2NyA2NTUzNSBmDQowMDAwMDAxMTY4 IDY1NTM1IGYNCjAwMDAwMDExNjkgNjU1MzUgZg0KMDAwMDAwMTE3MCA2NTUzNSBmDQowMDAwMDAx MTcxIDY1NTM1IGYNCjAwMDAwMDExNzIgNjU1MzUgZg0KMDAwMDAwMTE3MyA2NTUzNSBmDQowMDAw MDAxMTc0IDY1NTM1IGYNCjAwMDAwMDExNzUgNjU1MzUgZg0KMDAwMDAwMTE3NiA2NTUzNSBmDQow MDAwMDAxMTc3IDY1NTM1IGYNCjAwMDAwMDExNzggNjU1MzUgZg0KMDAwMDAwMTE3OSA2NTUzNSBm DQowMDAwMDAxMTgwIDY1NTM1IGYNCjAwMDAwMDExODEgNjU1MzUgZg0KMDAwMDAwMTE4MiA2NTUz NSBmDQowMDAwMDAxMTgzIDY1NTM1IGYNCjAwMDAwMDExODQgNjU1MzUgZg0KMDAwMDAwMTE4NSA2 NTUzNSBmDQowMDAwMDAxMTg2IDY1NTM1IGYNCjAwMDAwMDExODcgNjU1MzUgZg0KMDAwMDAwMTE4 OCA2NTUzNSBmDQowMDAwMDAxMTg5IDY1NTM1IGYNCjAwMDAwMDExOTAgNjU1MzUgZg0KMDAwMDAw MTE5MSA2NTUzNSBmDQowMDAwMDAxMTkyIDY1NTM1IGYNCjAwMDAwMDExOTMgNjU1MzUgZg0KMDAw MDAwMTE5NCA2NTUzNSBmDQowMDAwMDAxMTk1IDY1NTM1IGYNCjAwMDAwMDExOTYgNjU1MzUgZg0K MDAwMDAwMTE5NyA2NTUzNSBmDQowMDAwMDAxMTk4IDY1NTM1IGYNCjAwMDAwMDExOTkgNjU1MzUg Zg0KMDAwMDAwMTIwMCA2NTUzNSBmDQowMDAwMDAxMjAxIDY1NTM1IGYNCjAwMDAwMDEyMDIgNjU1 MzUgZg0KMDAwMDAwMTIwMyA2NTUzNSBmDQowMDAwMDAxMjA0IDY1NTM1IGYNCjAwMDAwMDEyMDUg NjU1MzUgZg0KMDAwMDAwMTIwNiA2NTUzNSBmDQowMDAwMDAxMjA3IDY1NTM1IGYNCjAwMDAwMDEy MDggNjU1MzUgZg0KMDAwMDAwMTIwOSA2NTUzNSBmDQowMDAwMDAxMjEwIDY1NTM1IGYNCjAwMDAw MDEyMTEgNjU1MzUgZg0KMDAwMDAwMTIxMiA2NTUzNSBmDQowMDAwMDAxMjEzIDY1NTM1IGYNCjAw MDAwMDEyMTQgNjU1MzUgZg0KMDAwMDAwMTIxNSA2NTUzNSBmDQowMDAwMDAxMjE2IDY1NTM1IGYN CjAwMDAwMDEyMTcgNjU1MzUgZg0KMDAwMDAwMTIxOCA2NTUzNSBmDQowMDAwMDAxMjE5IDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA4MTczNCAwMDAwMCBuDQowMDAwMDgyMDkxIDAw MDAwIG4NCjAwMDAxMjY0NDMgMDAwMDAgbg0KMDAwMDEyNjY4MiAwMDAwMCBuDQowMDAwMTY4ODYw IDAwMDAwIG4NCjAwMDAxNjkzNjIgMDAwMDAgbg0KMDAwMDI1NDgwNSAwMDAwMCBuDQowMDAwMjU1 MTg5IDAwMDAwIG4NCjAwMDAyNTU1MDIgMDAwMDAgbg0KMDAwMDM0NjI0NiAwMDAwMCBuDQowMDAw MzQ2NTU1IDAwMDAwIG4NCjAwMDAzNzE3MzUgMDAwMDAgbg0KMDAwMDM3MTgwMCAwMDAwMCBuDQow MDAwMzcyMTAxIDAwMDAwIG4NCjAwMDAzODQyMTMgMDAwMDAgbg0KMDAwMDM4NDI2NyAwMDAwMCBu DQp0cmFpbGVyDQo8PC9TaXplIDEyMzYvUm9vdCAxIDAgUi9JbmZvIDYyIDAgUi9JRFs8NUIyQzNC QzEwQTRBNDg0QkJGMkVFMEYxQjM4NTk2Nzc+PDVCMkMzQkMxMEE0QTQ4NEJCRjJFRTBGMUIzODU5 Njc3Pl0gPj4NCnN0YXJ0eHJlZg0KMzg2ODY1DQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8 PC9TaXplIDEyMzYvUm9vdCAxIDAgUi9JbmZvIDYyIDAgUi9JRFs8NUIyQzNCQzEwQTRBNDg0QkJG MkVFMEYxQjM4NTk2Nzc+PDVCMkMzQkMxMEE0QTQ4NEJCRjJFRTBGMUIzODU5Njc3Pl0gL1ByZXYg Mzg2ODY1L1hSZWZTdG0gMzg0MjY3Pj4NCnN0YXJ0eHJlZg0KNDExNzQ3DQolJUVPRg== --_002_1808340F7EC362469DDFFB112B37E2FCC895C718C4SRVHKE02rdmcz_-- From v6ops@globis.net Mon May 13 23:55:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A228C21F8FE8 for ; Mon, 13 May 2013 23:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GipmY+nFXhBy for ; Mon, 13 May 2013 23:55:26 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6065F21F8FE3 for ; Mon, 13 May 2013 23:55:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A3DE1870056; Tue, 14 May 2013 08:55:09 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw300PkMCscQ; Tue, 14 May 2013 08:55:09 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2D0A9870002; Tue, 14 May 2013 08:55:09 +0200 (CEST) Message-ID: <5191DFC6.4050903@globis.net> Date: Tue, 14 May 2013 08:55:02 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Jouni References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> In-Reply-To: <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 06:55:27 -0000 > Jouni > 14 May 2013 00:30 > Ray, > > Thanks for putting effort to read the document. Some initial comments inline. > > On May 14, 2013, at 1:00 AM, Ray Hunter wrote: > >> I have read this document. I cant say that I support it. >> >> IMHO it's too time specific and too version specific, without proving >> added value and general guidance. > > Reason being quite simple. When describing what a 3GPP UE can do, we cannot > really go beyond what has been specified so far. > Right. And that's my basic problem with the IETF producing such a document. > We can point out some > stuff that would make sense but not really anything beyond that. And we > have tried to be pedantic on that. I'll hold you to that ;) > > I somewhat disagree about the lack general guidance. Experience has shown > that it usually takes real effort explaining some of the weird details of > the 3GPP link and how corners have been cut there. Take the NDP details > as an example. Right. But then I humbly suggest that the document just covers the "weird details". Forgive my apparent frustration. In my very simple mind, 3gpp "blew it big time" at the architecture level. Quote "If a cellular host has additional interfaces on which IP is used, (such as Ethernet, WLAN, Bluetooth, etc.) then there may be additional requirements for the device, beyond what is discussed in this document." The starting point for 3gpp in the IETF should have been how to transport packets over the basic link technology, and then looking at how the ecosystem of end user devices an individual owned could collectively connect to the Internet, rather than the end user device being relegated to nothing more than a dedicated handset on the end of a single radio link with no alternate paths. Following comments from "my very simple mind," which might equate to how some developers will read this document. Please forgive me /indulge me, as I feel it will improve the quality of the draft. We're basically talking about a dedicated point to point link between a piece of provider equipment (GGSN/PGW) and a piece of consumer equipment (TE). Quote draft-ietf-v6ops-rfc3316bis: "The Router Advertisement contains a maximum of one prefix information option and the advertised prefix cannot ever be used for on-link determination (see [RFC6459], Section 5.2)." Quote RFC4862: Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. What breaks if an end device supports receiving more than one PIO in an RA? Advising implementers of cellular hosts to box themselves into a corner based on the current implementation of the network equipment would seem to me to be a bad idea if it isn't absolutely necessary. Section 2.6. "Consequently, sending MLD reports for link-local addresses in a 3GPP environment may not always be necessary" What does this tell me as a developer? How do I discover this? Is it harmful to never send MLD? Is it harmful to always send MLD? That I need to try once and see if sending MLD is necessary (to avoid unnecessary 3gpp traffic)? Section 2.7 What has RFC 4941 got to do with 3gpp link technology and corner cases? 6459 says "RFC 4941 or other similar types of mechanisms." draft-ietf-v6ops-rfc3316bis says "Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] should be supported." What breaks if other privacy mechanisms are used, so that draft-ietf-v6ops-rfc3316bis has been sharpened to SHOULD support 4941? Or none? Quote "At the time this document has been written, there is no experience on how long-lived cellular network address assignments (i.e., attachments to the network) are. " Again, what is this draft telling me as a developer? Section 2.9 Is this kludge forever? What is fundamentally wrong in the long term with unnumbered links? What is fundamentally wrong in the long term with the radio provider using their own IPv6 space for the radio link, and delegating an entire contiguous block to the user to allocate. (which is what the majority of other IP networks do AFAIK). Section 2,10 "The cellular host should implement the Default Router Preferences and More-Specific Routes extension to extension to Router Advertisement messages [RFC4191]. These options me be useful for cellular hosts that also have additional interfaces on which IPv6 is used." Wasn't this specifically declared out of scope in Section 1.1? "If a cellular host has additional interfaces on which IP is used, (such as Ethernet, WLAN, Bluetooth, etc.) then there may be additional requirements for the device, beyond what is discussed in this document." >> On the one hand there are requirements to implement a kludge to cope >> with historical limitations in mobile networks and the fact the gateway >> could only handle a single prefix route (RFC6603), whereas every other >> network I know of easily handles numbering of the link "to the site" >> without this. >> >> On the other hand there isn't a requirement for something really basic >> in the IPv6 vision, like BCP 157, so that a device can always be >> provided with enough addresses/prefixes to properly number all of its >> interfaces using SLAAC without resorting to workarounds like >> draft-ietf-v6ops-64share-04. > > Something we have to live with at the moment. RFC3314 tried to recommend > otherwise but what was recommend did not materialize. Even if I really > wanted to recommend support for multiple prefixes on a 3GPP link, this > document is not a recommendation document but what has to be there for > an IPv6 enabled UE. > >> I therefore question what this document adds above and beyond reading >> the detailed 3gpp version releases/ specs, and why the IETF should >> publish this document at all. > > The original RFC3316 still gets referenced and that somewhat needed a > facelift. Quote draft-ietf-v6ops-rfc3316bis: "Future changes in 3GPP networks that impact host implementations may result in updates to this document." I don't see the fact that RFC3316 is still referenced as a reason to repeat the same mistake of having a specific IETF document that needs to then somehow synchronise with the work of another standards body that operates completely outside the IETF's scope of influence. Thanks for your patience, RayH > Mostly because when RFC3316 came out we did not even have > the node requirements document, and a lot of stuff that really belongs > to the node requirements document is duplicated (and now outdated) in > RFC3316. > > - Jouni > > >> regards, >> RayH >> >> Fred Baker (fred) wrote: >>> This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. >>> >>> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make >>> >>> draft-ietf-v6ops-rfc3316bis idnits >>> >>> >>> >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From jouni.nospam@gmail.com Wed May 15 00:33:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9300521F8E99 for ; Wed, 15 May 2013 00:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr2WDdq65Q9i for ; Wed, 15 May 2013 00:33:27 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E621F8E56 for ; Wed, 15 May 2013 00:33:26 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so1530878lbd.20 for ; Wed, 15 May 2013 00:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=vMe+IRmnwrtfCIv9RjQYihIjp2OZsNCIkPcMfRj5Eik=; b=UEcC8vcHpJXkUl6pzKJHesK0Cu4ZWjyamhLsUugWbtDUULvebkjADANrFi4aL9+Glp 6Jdp7tS4LQtZ3OGLDjwAokiug2rM4Q/HSdTvEn37j82Ica2PIEU/AafXkHZz8bYjsa99 zQYgzgGRd48B0CM0m2xp9d47j6u0yxfiIdeBJXZrSiLxIm1rFAggOKsAfUjqKY7JJ/Mx lyiXv/XAj21fqBR4irELl0sZKua/TTGnLH9vNsigVtSUckLwIugqX3QXn9ivZioHhdFH +D5FFc9yGH5hEf83GoGwRUzSOFpk5NlOt2YKLHIhK5zstSN5gAKTMXF8om1c5F90SQ+Q mQgA== X-Received: by 10.112.148.166 with SMTP id tt6mr16389832lbb.129.1368603205793; Wed, 15 May 2013 00:33:25 -0700 (PDT) Received: from [192.168.250.182] ([194.100.71.98]) by mx.google.com with ESMTPSA id pm9sm801320lbb.8.2013.05.15.00.33.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 00:33:24 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Jouni Korhonen In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC895C718C4@SRVHKE02.rdm.cz> Date: Wed, 15 May 2013 10:33:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <049B0E2D-4A58-4468-8042-D0B14BEB4D26@gmail.com> References: <20130506081341.9763.24469.idtracker@ietfa.amsl.com> <08ADEA85-6632-4D23-8998-1D16ED2DE43E@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC895C718C4@SRVHKE02.rdm.cz> To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-rfc3316bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 07:33:33 -0000 Ales, THank you for the review.. It might sound boring but I more or less = agree with all your comments :) Few specific discussion points you had in the review: * "Would it make sense to mention that the cellular network may be = sending RAs every 4 hours to save air resources as hinted in the 3GPP = spec?" I can mention the 29.061 suggested time. So implementations seem to use = much longer RA intervals. I have seen intervals up to 18 hours. * "It could be mentioned that the assigned IPv6 prefix is valid for the = lifetime of a PDP context and cannot be changed without tearing down the = cellular link/connection." Hmm.. I though I had this mentioned. Maybe it was in some other text I = wrote recently. Will add this note. * Comment VA9:=20 Agree with the comment. Specifically with "MiFi" use cases the same = prefix may be used for days or even longer. I'll reword this towards = more "privacy friendly". * Comment VA10: The PD is discussed in more detail in the following section. I would not = implement this comment as such. * Comment VA11: There is the other I-D that can discuss PCOs. I would not add those here = :) * Comment VA12: Alas 3GPP specs are still silent about RFC6106. In that sense maybe = changing should to may would suffice. Indeed the split-UE use case is = where RFC6106 is useful. There is a lot of weird stuff in USB stick / = MiFi front.. like the one your referred to. Some of those did not = support SLAAC but only DHCPv6 ;) Obviously those do not really adhere to = 3GPP link model.. * Comment VA15: IMEI. - Jouni On May 14, 2013, at 2:14 AM, V=EDzdal Ale=B9 = wrote: > <3316bis-review.pdf> From jouni.nospam@gmail.com Wed May 15 00:59:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976521F8F24 for ; Wed, 15 May 2013 00:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFFEUT0geR3R for ; Wed, 15 May 2013 00:59:09 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5003921F8E9E for ; Wed, 15 May 2013 00:59:09 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so1566641lbf.28 for ; Wed, 15 May 2013 00:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=JVRPYQIAcgQKuKEaIJdjfPTq4dPABXUJWVuuxujJ/yY=; b=ut4M6Vwu+2OPjY03MhYQApr6CjD+f9FdqKpCkL5nSDbX729H8mGerElgAk4dxRPzrv cXMedVXr5ce7DJtYNm+2kRGXGrL52wOHT48wMt2xaZmeFQblairWjagWkrfJFD9Wif8s pf7T/4OTOc5PgkGihhCzXlZFVpJ8iMO3LTJPbKqMs61pJ3ReCceR2YsSWF/WXrjrtnLg rtgWrBVwM43KTCBJpH8nvlrEUdqyOUZ9ZRvuaJGFzPS8Yc1Lz2U1SqmKMXCuB97Ub7Wu E15sBteByc7D8AG1Hq+Y5kwMuQjJ4hX3dTZJuyjV5SZxseNH6hSWWyYQgZznJinQrAK4 9RaQ== X-Received: by 10.112.169.72 with SMTP id ac8mr16662031lbc.115.1368604748249; Wed, 15 May 2013 00:59:08 -0700 (PDT) Received: from [192.168.250.182] ([194.100.71.98]) by mx.google.com with ESMTPSA id y1sm692075lay.3.2013.05.15.00.59.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 00:59:06 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Jouni Korhonen In-Reply-To: <5191DFC6.4050903@globis.net> Date: Wed, 15 May 2013 10:59:04 +0300 Content-Transfer-Encoding: 7bit Message-Id: <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com> References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> <5191DFC6.4050903@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 07:59:21 -0000 RAy, On May 14, 2013, at 9:55 AM, Ray Hunter wrote: > Quote draft-ietf-v6ops-rfc3316bis: > "The Router Advertisement contains a maximum > of one prefix information option and the advertised prefix cannot > ever be used for on-link determination (see [RFC6459], Section 5.2)." > > Quote RFC4862: > Router Advertisements also contain zero or more Prefix Information > options that contain information used by stateless address > autoconfiguration to generate global addresses. > > What breaks if an end device supports receiving more than one PIO in an RA? Probably nothing. There just are no gateways that would put more than one PIO in an RA. The language is there just because 3GPP specs are explicit on stating it as a restriction to SLAAC. > Advising implementers of cellular hosts to box themselves into a corner > based on the current implementation of the network equipment would seem > to me to be a bad idea if it isn't absolutely necessary. Well.. I do not disagree here :) > Section 2.6. "Consequently, sending MLD reports for link-local addresses > in a 3GPP environment may not always be necessary" > > What does this tell me as a developer? How do I discover this? > Is it harmful to never send MLD? Is it harmful to always send MLD? > That I need to try once and see if sending MLD is necessary (to avoid > unnecessary 3gpp traffic)? Right. I could say "Consequently, sending MLD reports for link-local addresses in a 3GPP environment is not necessary" That would be more explicit? > Section 2.7 > What has RFC 4941 got to do with 3gpp link technology and corner cases? > > 6459 says "RFC 4941 or other similar types of mechanisms." > draft-ietf-v6ops-rfc3316bis says "Privacy Extensions for Stateless > Address Autoconfiguration [RFC4941] should be supported." > > What breaks if other privacy mechanisms are used, so that > draft-ietf-v6ops-rfc3316bis has been sharpened to SHOULD support 4941? > Or none? Right. I can reword this similar to RFC6459. > Section 2.9 Is this kludge forever? Dunno. > What is fundamentally wrong in the long term with unnumbered links? Nothing. It is just not an option with 3GPP link model (and do not refer here to 64share that shows what one do with a host implementation). > What is fundamentally wrong in the long term with the radio provider > using their own IPv6 space for the radio link, and delegating an entire > contiguous block to the user to allocate. Nothing. Just to point out that "we tried we failed". I am actually happy that we even got DHCPv6 PD into specs instead of something more "ingenious". > (which is what the majority of other IP networks do AFAIK). > > > Section 2,10 > > "The cellular host should implement the Default Router Preferences and > More-Specific Routes extension to extension to Router Advertisement > messages [RFC4191]. These options me be useful for cellular hosts > that also have additional interfaces on which IPv6 is used." > > Wasn't this specifically declared out of scope in Section 1.1? "If a > cellular host has additional interfaces on which IP is used, (such as > Ethernet, WLAN, Bluetooth, etc.) then there may be additional > requirements for the device, beyond what is discussed in this document." Right. So you want that removed? - JOuni From owen@delong.com Wed May 15 10:12:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A6621F8E8F for ; Wed, 15 May 2013 10:12:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quQRcgr26rwN for ; Wed, 15 May 2013 10:12:23 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BA70D21F8517 for ; Wed, 15 May 2013 10:12:22 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4FHAr0Q022555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 May 2013 10:10:53 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4FHAr0Q022555 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1368637853; bh=ZJJx7oFWzafDyjLqCONAOi7Cqck=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fuBAqp7NUaqppi1TG/K+auH8Wcgt3OS4O3wZ6W5CZnafAg47y0SVXZSTDRCnTXkgf 2Yf+h5JSir7LCcJnQWl2Q3RHRR7IgEaIre9qI8IR3bvb269K/OlA2GPTjtwPXhaUWf MWWecypwQQa/Tbx9Yp8Ry1o+w/FcmmifUE5uGNdo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com> Date: Wed, 15 May 2013 10:13:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> <5191DFC6.4050903@globis.net> <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 15 May 2013 10:10:53 -0700 (PDT) Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 17:12:24 -0000 On May 15, 2013, at 00:59 , Jouni Korhonen = wrote: >=20 > RAy, >=20 > On May 14, 2013, at 9:55 AM, Ray Hunter wrote: >=20 >> Quote draft-ietf-v6ops-rfc3316bis: >> "The Router Advertisement contains a maximum >> of one prefix information option and the advertised prefix cannot >> ever be used for on-link determination (see [RFC6459], Section = 5.2)." >>=20 >> Quote RFC4862: >> Router Advertisements also contain zero or more Prefix Information >> options that contain information used by stateless address >> autoconfiguration to generate global addresses. >>=20 >> What breaks if an end device supports receiving more than one PIO in = an RA? >=20 > Probably nothing. There just are no gateways that would put more than = one > PIO in an RA. >=20 > The language is there just because 3GPP specs are explicit on stating = it=20 > as a restriction to SLAAC. It's kind of a dumb restriction IMHO. I don't think it is valuable to = bring dumb restrictions from 3GPP over to IETF unless it is necessary to avoid = incompatibility. >=20 >> Advising implementers of cellular hosts to box themselves into a = corner >> based on the current implementation of the network equipment would = seem >> to me to be a bad idea if it isn't absolutely necessary. >=20 > Well.. I do not disagree here :) >=20 +1 >> Section 2.6. "Consequently, sending MLD reports for link-local = addresses >> in a 3GPP environment may not always be necessary" >>=20 >> What does this tell me as a developer? How do I discover this? >> Is it harmful to never send MLD? Is it harmful to always send MLD? >> That I need to try once and see if sending MLD is necessary (to avoid >> unnecessary 3gpp traffic)? >=20 > Right. I could say "Consequently, sending MLD reports for link-local > addresses in a 3GPP environment is not necessary" That would be more > explicit? It would be more explicit. Would it be correct? If so, then it should be = stated this way. >> Section 2,10 >>=20 >> "The cellular host should implement the Default Router Preferences = and >> More-Specific Routes extension to extension to Router Advertisement >> messages [RFC4191]. These options me be useful for cellular hosts >> that also have additional interfaces on which IPv6 is used." >>=20 >> Wasn't this specifically declared out of scope in Section 1.1? "If a >> cellular host has additional interfaces on which IP is used, (such as >> Ethernet, WLAN, Bluetooth, etc.) then there may be additional >> requirements for the device, beyond what is discussed in this = document." >=20 > Right. So you want that removed? I don't support removal. If anything, I would suggest that more explicit = information about the various scenarios and their considerations is required. If not = in this document, then somewhere else that is referenced by this document. Instead, I think an update to 1.1 mentioning that the treatment in 2.10 = is not complete rather than out of scope might be worth while. Owen From jouni.nospam@gmail.com Thu May 16 00:35:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3976821F85D1 for ; Thu, 16 May 2013 00:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfMbf0PV4I-z for ; Thu, 16 May 2013 00:35:44 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id EF12221F8F4A for ; Thu, 16 May 2013 00:35:38 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id c41so1607988eek.37 for ; Thu, 16 May 2013 00:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=rCpr9pcJVo1XKB80yrEDkOt86/ZVbjloELEmsxNrTAk=; b=b88kVjT4Kton1k6pflk4FcUen5oQIl3fvjef40nQ3IvmThFGV/HRgRNt/5pVd/Y0hc Yelu20JoiUW0lWHeIbS4VSWLC0boRqpyUM0weKsxkReZn/Nsuy+kuZc9RqCMqhbFuZAr ZDsCoXu0bGM5CS0yYFrwUWNV6yP0bXWGE9URQ975DoMjbNwWi305q2z447w8xicGX1xL sYt8em/htTtsHjM0seYjFgT54DVzDed8cwV8QN8H+7kresrLzJfEjnmtBM4CTHYrRG2q CLBCEprTew4hTu21GiTmC0l7YhzAPLDJKTJtJIvnjMWbN5ktpNkS4HdZUbb3ejJ5CvrM VmEw== X-Received: by 10.14.38.198 with SMTP id a46mr113519275eeb.11.1368689738099; Thu, 16 May 2013 00:35:38 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:853d:c84e:2840:1026? ([2001:1bc8:101:f101:853d:c84e:2840:1026]) by mx.google.com with ESMTPSA id q1sm8752752eez.6.2013.05.16.00.35.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 00:35:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Jouni Korhonen In-Reply-To: Date: Thu, 16 May 2013 10:35:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> <5191DFC6.4050903@globis.net> <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com> To: Owen DeLong X-Mailer: Apple Mail (2.1503) Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 07:35:49 -0000 On May 15, 2013, at 8:13 PM, Owen DeLong wrote: >>>=20 >>> What breaks if an end device supports receiving more than one PIO in = an RA? >>=20 >> Probably nothing. There just are no gateways that would put more than = one >> PIO in an RA. >>=20 >> The language is there just because 3GPP specs are explicit on stating = it=20 >> as a restriction to SLAAC. >=20 > It's kind of a dumb restriction IMHO. I don't think it is valuable to = bring dumb > restrictions from 3GPP over to IETF unless it is necessary to avoid = incompatibility. I don't disagree about the "dumbness".. However, that is a restriction = of the=20 link itself and buried pretty deep in the architecture. So, if the UE = receives an RA with multiple PIOs a) someone is goofing around or b) the network = side is broken. In that regard, I would still like to keep some text around = this peculiarity in the document. Would it be acceptable to state the fact = and say something along the lines that changing the UE stack implementation to = meet this link requirement is not really needed? - Jouni From v6ops@globis.net Thu May 16 03:31:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEFC21F8FD0 for ; Thu, 16 May 2013 03:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSFzrrZCI2EH for ; Thu, 16 May 2013 03:31:52 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 12FCE21F8F69 for ; Thu, 16 May 2013 03:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BA19E8700E0; Thu, 16 May 2013 12:31:35 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A25JQykFj47l; Thu, 16 May 2013 12:31:35 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8C79D8700B0; Thu, 16 May 2013 12:31:35 +0200 (CEST) Message-ID: <5194B581.6030001@globis.net> Date: Thu, 16 May 2013 12:31:29 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Jouni Korhonen References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> <5191DFC6.4050903@globis.net> <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 10:31:53 -0000 > Jouni Korhonen > 16 May 2013 09:35 > > I don't disagree about the "dumbness".. However, that is a restriction > of the > link itself and buried pretty deep in the architecture. So, if the UE > receives > an RA with multiple PIOs a) someone is goofing around or b) the > network side > is broken. In that regard, I would still like to keep some text around > this > peculiarity in the document. Would it be acceptable to state the fact > and say > something along the lines that changing the UE stack implementation to > meet > this link requirement is not really needed? > > - Jouni > > ------------------------------------------------------------------------ IMHO This is symptomatic of the poor relationship between IETF standards and 3gpp standards. 3gpp has limited something gratuitously that wasn't limited in the referenced IETF standard. And it didn't need limiting at standards level anyway: it's a network equipment end implementation decision. It may be buried in the 3gpp architecture, but it's certainly NOT buried deep in the IETF architecture. So you could indeed mention that current versions of 3gpp network equipment send exactly one PIO, but IMHO the IETF standard should be kept as intended and unmodified: the TE should accept zero or more PIO options. Unless it truly breaks something in 3gpp. That way you have guaranteed interop with 3gpp, without limiting flexibility, or having to implement unnecessary changes to existing generic running code on a device that runs IPv6 and also happens to be a 3gpp TE. This is basic Postel's law. Futher I cross checked draft-ietf-v6ops-rfc3316bis against rfc6459 (IPv6 in 3rd Generation Partnership Project) I'm certainly not an expert in this field (just another dumb reader), but I do like to read consistent and maintainable standards. AFAICS & IMVHO Section 2.1 doesn't tell me anything that isn't obvious. Section 2.2 is mostly covered in rfc6459 section 5.4. Only new material is regarding [RFC4861], Section 7.3.1, but again that should be pretty obvious to stack implementers, or could simply be a reference. Section 2.3 is covered in rfc6459 section 5.2 Section 2.4 is covered in rfc6459 section 5.2 Section 2.5 looks like new information to me and provides actionable advice. Section 2.6 looks like new information to me but does not tell me any actionable advice. Section 2.7 has nothing to do specifically with 3gpp links and could be better handled elsewhere as a generic IPv6 privacy issue as AFAICS there are no interop issues specific to 3gpp, and no need to quote 4941 specifically. Section 2.8 is covered in rfc6459 section 5.2 Section 2.9 is covered in rfc6459 section 5.3 Section 2.10 looks like new information to me, but only contains partial advice on handling multiple interfaces, so it could do with fleshing out, or removal [I have no strong opinion either way] Section 2.11looks like new information regarding handling the MTU option and looks actionable Section 3 looks redundant or incomplete. Section 4 is redundant: an end node may still want to support mobile IPv6 for e.g. wifi or other purposes: end nodes are not just TE's. So in summary: I'm seeing an awful lot of unnecessary duplication/overlap of text with an existing RFC that could be simply referenced as a whole, and the areas that are providing new information to me seem to require either more fleshing out, or additional actionable advice. I hope you can do something positive with this critique from a dumb reader. Security considerations quote "In some cases, users are billed according to the amount of data they transfer to and from their host. It is crucial for both the network and the users that the airtime is used correctly and no extra charges are applied to users due to misbehaving third parties." This is not a technical issue, and the criticism is not directed at the authors, but I find this outrageous. Why do end users have to pay for control traffic that doesn't directly benefit them or provide them a service they've requested? Users don't pay for call set up traffic on the voice bearers until the call is actually established and answered. Nor do they pay for maintaining time or other network management information like establishing network credentials and cell hand off. So why does the IETF have to put in place a load of technical kludges at the IPv6 layer to cover something that is fundamentally a billing issue? If the providers just didn't bill for traffic with a destination address of the internal network control devices, there'd be no need for any of this. best regards, RayH From fred@cisco.com Thu May 16 12:08:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05811E80A6 for ; Thu, 16 May 2013 12:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.987 X-Spam-Level: X-Spam-Status: No, score=-109.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keKWNI7HlAPs for ; Thu, 16 May 2013 12:08:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B416D21F8E3C for ; Thu, 16 May 2013 12:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1161; q=dns/txt; s=iport; t=1368731323; x=1369940923; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RNpruMdxbWfm2YguQG7nkE1ADzDml/lNk6hCJHdvYCU=; b=RaUcVN4n0pn1jaetKHs6pLuWSbVuq3DwqyiuGU+p9jofv5eEfm8T4o4p qf7nLcAogjqpSAVPQ5BI8nFqG83mQmmuKc4ANDg3AOYp6axqthp5sbrhh ufP+sMgKCSDW4heOE2n98JWMoq5DUXbktWKyLWTXUyql3nXbrSVrPqeRn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABMulVGtJV2Y/2dsb2JhbABbgwfCA30WdIIfAQEBAwE6PwULAgEIEhAUECERFw4CBA4FCIdyAwkGs1ENiE+MSIIkAjEHgnRhA5VSjgOFI4MQgiY X-IronPort-AV: E=Sophos;i="4.87,685,1363132800"; d="scan'208";a="208455237" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 16 May 2013 19:08:43 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4GJ8hd9020211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 19:08:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 16 May 2013 14:08:42 -0500 From: "Fred Baker (fred)" To: Jouni Korhonen Thread-Topic: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC Thread-Index: AQHOUmjHnjaky0w5lku9hVnCVzjKeA== Date: Thu, 16 May 2013 19:08:42 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8EA56B@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B859B35@xmb-rcd-x09.cisco.com> <51916286.9070101@globis.net> <038302EE-DAE7-4722-B2A6-5F65F789F959@gmail.com> <5191DFC6.4050903@globis.net> <30285AC2-5365-4353-9465-5D42D5AFEA1F@gmail.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , "v6ops@ietf.org"

--20cf3074b52a02e87304dd36068e-- From leo.liubing@huawei.com Tue May 21 02:35:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FF621F97DA for ; Tue, 21 May 2013 02:35:14 -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.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gby8Jj9oSvP1 for ; Tue, 21 May 2013 02:35:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED1E421F97D4 for ; Tue, 21 May 2013 02:35:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASZ66527; Tue, 21 May 2013 09:35:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 21 May 2013 10:34:41 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 21 May 2013 10:34:48 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Tue, 21 May 2013 17:34:44 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHOVS+HyCM8E5Dr9EyOxCY462I/kZkO8esQ///To4CAAIuHsA== Date: Tue, 21 May 2013 09:34:44 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D726B3Enkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:35:14 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D726B3Enkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Lorenzo From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Tuesday, May 21, 2013 4:13 PM To: Liubing (Leo) Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.o= rg Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-us= age-recommendations On Tue, May 21, 2013 at 4:13 PM, Liubing (Leo) > wrote: 1. "In practice, applications may treat ULAs like global-scope addresses" i= s incorrect. ULAs are global-scope addresses, and we should state that they= are. [Bing] They are designed intended to be globally unique, but they are clear= ly defined as "local IPv6 addresses". And the sentence actually comes from = RFC4193, see section 1. Ah, I see. So the problem here is that even though you copied and pasted th= e sentence, the difference in context makes the word "may" have two differe= nt meanings. When RFC 4193 says "In practice, applications may treat these addresses lik= e global scoped addresses", what it means is that applications *are permitt= ed* to treat these addresses as global addresses. This is because RFC 4193 = is the specification that is defining these addresses, is therefore normati= ve, and is saying what applications are allowed to do. However, in this draft, which is not normative and is intended to describe = usage of these addresses, saying "may treat these addresses like global sco= pe addresses" suggests that applications "may" treat them like global scope= addresses, but may also treat them differently. So basically, since this d= ocument is not normative, saying "may" is ambiguous. I suggest resolving the ambiguity by saying something that is more precise = - i.e., that ULAs are global-scope addresses. This is explicitly addressed = in RFC 4193 section 3.3 ("by default, the scope of these addresses is globa= l") and RFC 6724 section 3.1 ("note that ULAs are considered as global [...= ] scope"). As for them being defined as "local IPv6 addresses", RFC 4193 does not defi= ne them as "local IPv6 addresses". "Local IPv6 addresses" is just an abbrev= iation used in RFC 4193, which says "These addresses are called Unique Loca= l IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6= addresses." [Bing] Will update accordingly. Thanks. Suggested replacement text: "Note that, while ULAs are global-scope address= es, they do not have global reachability. Therefore, address selection algo= rithms distinguish between ULAs and GUA (Global Unicast Address) [RFC 6724]= ". [Bing] As said above, I think the sentence would be good if delete "while U= LAs are global-scope addresses". Why are you suggesting deleting that text? Do you disagree that ULAs have g= lobal scope? They do have global scope, as specified by both RFC 4193 and R= FC 6724. [Bing] It was my misunderstanding of it, as explained to Erik. IV. "Alternatively, it could be regenerated regularly, if desired for some = reason." Can it? How regularly? If it is regenerated your ULA once a second= , how soon before collisions become likely? What about 100, 1000 or 1000000= times per second? You probably want to qualify "regularly". [Bing] Generally, "regularly regenerated" on-demand. Say, upper layer wants= a new ULA for a new session id. I think maybe we don't need to worry about= the regeneration rate that might increase the collision probability signif= icantly. That might only concern in a scientific research of collision. No, the probability is much higher than you think. See RFC 4193 section 3.2= .3. If I'm reading that section correctly, if you generate 10000 ULAs you'l= l get a collision 1 in 500k times. If you generate 100000 (e.g., if you reg= enerate them once a second, for one day) you'll get a collision once in 100= 0 times. And so on. [Bing] In theory, I agree with you. But the point here is where do we need = to change the ULA so frequently? For random draw? I can hardly imagine a us= e case of that. V. "the network needs ULA as the on-demand and stable addressing which doe= sn't need much code to support address assignment mechanisms like DHCP or N= D." I don't think this makes sense. Are you saying such nodes only support = manual address assignment? How is it possible that a sensor doesn't support= automatic address assignment due to lack of resources, but has enough reso= urces to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, ther= e might not be a comprehensive network provisioning environment for the nod= es. If they can be pre-configured with ULA, say, hard-coded in the embedded= system, like the MAC addresses in every single NIC or self-generating a UL= A, then they could make ad-hoc networking without address provisioning proc= edures. How are those nodes going to find the MAC address of the link router to com= municate off-link? If they can't do this, then you don't need ULA, you can = just use link-local. If they can do this, then they must support router adv= ertisements or similar. If they support router advertisements, then they ca= n use autoconfiguration. [Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the = draft specifically noted this point. But if the sensors are in a MANET, th= en the autoconfiguration is different with the traditional wired SLAAC, sin= ce MANET is based on a multi hop topology. ULA is suitable for this scenari= o, however, current text seems not sufficient/clear, will modify later. VI. "there always be some argument that in practice the ULA+PA makes terrib= le operational complexity. But it is not a ULA-specific problem; the multip= le- addresses-per-interface is an important feature of IPv6 protocol. Runni= ng multiple prefixes in IPv6 might be very common, and we need to adapt thi= s new operational model than that in IPv4." This text does not make sense. = Just because having multiple global-scope addresses is a feature of IPv6 do= esn't mean that you must have multiple global-scope addresses. For example,= you can use only global addresses and have no routing complexity. [Bing] The ULA+PA operational complexity contains two aspect. One is the common issue as described in the texts, running multiple prefixe= s in a network is new to the traditional IPv4 model, the admins need to be = familiar with it in the future. No, because having multiple prefixes introduces operational complexity even= if the admins understand multiple prefixes. All things being equal, having= only one prefix (e.g., a global prefix) is always going to be simpler than= having two. In other words: what you're saying is "let's create complexity, because adm= ins will need to understand the complexity anyway". What I'm saying is that= while they need to understand the complexity, we don't have to create the = complexity if we don't need it. [Bing] No, I'm not say that. ULA+PA is identified as beneficial use case in= 6renum and Homenet. So the admins need to adapt the complexity if they wan= t the benefit. The other is about the address selection, without the new rules in RFC6724,= it might be problematic to run ULA+PA, when we discuss this in 6renum, Eri= c Vyncke reported they had a terrible experience of using this mode several= years ago. In last IETF, we briefly discussed this issue again, and we th= ought it was probably because of the old address selection algorithms that = didn't distinguish ULA from GUA. Then this section needs to be worded more clearly once the cause is clearly= determined and the problem clearly documented. [Bing] Sure, agree. B.R. Bing --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D726B3Enkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Lorenz= o

= ;

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Tuesday, May 21, 2013 4:13 PM
To: Liubing (Leo)
Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools= .ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

On Tue, May 21, 2013 at 4:13 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:

1. "In practice, applications may treat UL= As like global-scope addresses" is incorrect. ULAs are global-scope ad= dresses, and we should state that they are.

[Bing] They are designed inten= ded to be globally unique, but they are clearly defined as “local IPv6 addresses”. And the sentence actually comes from RFC4193, see section 1.=

Ah, I see. So the problem here = is that even though you copied and pasted the sentence, the difference in c= ontext makes the word "may" have two different meanings.

When RFC 4193 says "In pra= ctice, applications may treat these addresses like global scoped addresses&= quot;, what it means is that applications *are permitted* to treat these ad= dresses as global addresses. This is because RFC 4193 is the specification that is defining these addresses, is therefore n= ormative, and is saying what applications are allowed to do.

However, in this draft, which i= s not normative and is intended to describe usage of these addresses, sayin= g "may treat these addresses like global scope addresses" suggest= s that applications "may" treat them like global scope addresses, but may also treat them differently. So basically, since = this document is not normative, saying "may" is ambiguous.

I suggest resolving the ambigui= ty by saying something that is more precise - i.e., that ULAs are global-sc= ope addresses. This is explicitly addressed in RFC 4193 section 3.3 ("= by default, the scope of these addresses is global") and RFC 6724 section 3.1 ("note that ULAs are consid= ered as global [...] scope").

As for them being defined as &q= uot;local IPv6 addresses", RFC 4193 does not define them as "loca= l IPv6 addresses". "Local IPv6 addresses" is just an abbrevi= ation used in RFC 4193, which says "These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local= IPv6 addresses."

= ;

[Bing] = Will update accordingly. Thanks.

Suggested replacement= text: "Note that, while ULAs are global-scope addresses, they do not = have global reachability. Therefore, address selection algorithms distinguish between ULAs and GUA (Global Unicast Addr= ess) [RFC 6724]".

[Bing] As said above, I think = the sentence would be good if delete “while ULAs are global-scope address= es”.

Why are you suggesting deleting= that text? Do you disagree that ULAs have global scope? They do have globa= l scope, as specified by both RFC 4193 and RFC 6724.

[Bing] It was my misunderstanding of it, as explained to Erik.<= o:p>

IV. "Alternative= ly, it could be regenerated regularly, if desired for some reason." Ca= n it? How regularly? If it is regenerated your ULA once a second, how soon before collisions become likely? What about 100, 1= 000 or 1000000 times per second? You probably want to qualify "regular= ly".

[Bing] Generally, “regularly regenerated” on-demand. Say, upper layer wants a new ULA for a new session id. I think maybe we don’t need to worry about the regeneration rate that might i= ncrease the collision probability significantly. That might only concern in a scientific research of collision.

No, the probability is much hig= her than you think. See RFC 4193 section 3.2.3. If I'm reading that section= correctly, if you generate 10000 ULAs you'll get a collision 1 in 500k tim= es. If you generate 100000 (e.g., if you regenerate them once a second, for one day) you'll get a collision onc= e in 1000 times. And so on.

[Bing] = In theory, I agree with you. But the point here is where do we need to chan= ge the ULA so frequently? For random draw? I can hardly imagine a use case = of that.

V. "the network needs ULA as the o= n-demand and stable addressing which doesn't need much code to support addr= ess assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automatic = address assignment due to lack of resources, but has enough resources to im= plement a UI for manual address assignment?

[Bing] The lack of re= sources mainly regarding the network environment, there might not be a comp= rehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to fi= nd the MAC address of the link router to communicate off-link? If they can'= t do this, then you don't need ULA, you can just use link-local. If they ca= n do this, then they must support router advertisements or similar. If they support router advertisements, then the= y can use autoconfiguration.

[Bing] = Surely they need to support SLAAC, it’s a basic IPv6 function , the d= raft specifically noted this point. But if the sensors are in a MANET= , then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA= is suitable for this scenario, however, current text seems not sufficient/= clear, will modify later.

VI. "there alway= s be some argument that in practice the ULA+PA makes terrible operation= al complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 prot= ocol. Running multiple prefixes in IPv6 might be very common, and we need t= o adapt this new operational model than that in IPv4." This text does = not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must hav= e multiple global-scope addresses. For example, you can use only global add= resses and have no routing complexity.

[Bing] The ULA+PA= operational complexity contains two aspect.

One is the common iss= ue as described in the texts, running multiple prefixes in a network is new= to the traditional IPv4 model, the admins need to be familiar with it in the future.

No, because having multiple pre= fixes introduces operational complexity even if the admins understand multi= ple prefixes. All things being equal, having only one prefix (e.g., a globa= l prefix) is always going to be simpler than having two.

In other words: what you're say= ing is "let's create complexity, because admins will need to understan= d the complexity anyway". What I'm saying is that while they need to u= nderstand the complexity, we don't have to create the complexity if we don't need it.

[Bing] = No, I’m not say that. ULA+PA is identified as beneficial use case= in 6renum and Homenet. So the admins need to adapt the complexity if they = want the benefit.

The other is about th= e address selection, without the new rules in RFC6724, it might be problema= tic to run ULA+PA, when we discuss this in 6renum, Eric Vyncke reported they had a terrible experience of using th= is mode several years ago. In last IETF, we briefly discussed this issue ag= ain, and we thought it was probably because of the old address select= ion algorithms that didn’t distinguish ULA from GUA.

Then this section needs to be w= orded more clearly once the cause is clearly determined and the problem cle= arly documented.

[Bing] = Sure, agree.

&n= bsp;

B.R.

Bing

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D726B3Enkgeml506mbxchi_-- From tjc@ecs.soton.ac.uk Tue May 21 02:54:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A3521F8952 for ; Tue, 21 May 2013 02:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfbJv90vQWye for ; Tue, 21 May 2013 02:54:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 251DA21F8930 for ; Tue, 21 May 2013 02:54:31 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4L9sRNN029488; Tue, 21 May 2013 10:54:27 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4L9sRNN029488 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369130067; bh=cjFkBaXR8+7L2DoLOcBF/rVV0F8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=xdWaIhlbHVgzibbURBdihqIsQkdLZ1tL0mdgf2PZ3JrK//GZO1NkOHY1zj0Jlh/uc qWbOh7l/GdP5Zt4JHt/bIzRrI86TnlmGxug0FXtdXPod0WaFciN2ZrbzqbbiFlc8Bl YSkxNNWCf2vCK9PmyHSJFaua/iCn/fw6MzsGy6JU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p4KAsR0430639479K0 ret-id none; Tue, 21 May 2013 10:54:27 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4L9sP6o014683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 10:54:25 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2623307F-BEF7-4283-A509-7C7718DFE528" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: Date: Tue, 21 May 2013 10:54:25 +0100 Message-ID: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <97F7691B-F6A0-49A5-90AC-1A9CDAA50BD3@ecs.soton.ac.uk> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4KAsR043063947900; tid=p4KAsR0430639479K0; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4L9sRNN029488 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:54:33 -0000 --Apple-Mail=_2623307F-BEF7-4283-A509-7C7718DFE528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 May 2013, at 09:13, Lorenzo Colitti wrote: > On Tue, May 21, 2013 at 4:13 PM, Liubing (Leo) = wrote: > [Bing] The ULA+PA operational complexity contains two aspect. >=20 > One is the common issue as described in the texts, running multiple = prefixes in a network is new to the traditional IPv4 model, the admins = need to be familiar with it in the future. >=20 > No, because having multiple prefixes introduces operational complexity = even if the admins understand multiple prefixes. All things being equal, = having only one prefix (e.g., a global prefix) is always going to be = simpler than having two. It will of course be simpler, the open question being what is meant by = "all things being equal". In a homenet, there may be cases where there is no external = connectivity, in some cases where none has yet been established (rather = than it having been there and gone away). There may be devices that have = ULAs "burnt in", for which those ULAs need to be routed around the scope = of the homenet. And there is an argument for ULAs for stable = connectivity internally in the face of whatever happens to external = prefix(es)/connectivity. In a dual-stack homenet, there will be at least two prefixes, one IPv4, = one IPv6. Which reminds me, I would like to see this document do some deeper = analysis of the issue raised after IETF86, regarding "ULAs on by = default" alongside IPv4/NAT. That thread, discussing the practical = issues, ran to 150+ emails before fizzling out without any specific = proposed text, either for Bing's draft or the homenet arch. I recall = that Ole's point on this was that *if* hosts supported RFC4191 RIO, then = ULA routes could be added without a default route, and = dependencies/timeouts on ICMPv6 redirects avoided. And RFC6204bis ULA-5 = recommends that behaviour (along with L-3). The little snag is that = current OSes certainly don't all support RFC4191. > In other words: what you're saying is "let's create complexity, = because admins will need to understand the complexity anyway". What I'm = saying is that while they need to understand the complexity, we don't = have to create the complexity if we don't need it. Well, in a home network there will be no admins. Plug and play is what = we want. But connection timeouts are equally what we do not want. Tim --Apple-Mail=_2623307F-BEF7-4283-A509-7C7718DFE528 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 lorenzo@google.com> = wrote:

On Tue, May 21, 2013 at 4:13 PM, Liubing = (Leo) <leo.liubing@huawei.com> wrote:
[Bing] The ULA+PA = operational complexity contains two aspect.
One is = the common issue as described in the texts, running multiple prefixes in = a network is new to the traditional IPv4 model, the admins need to be = familiar with it in the future.

No, because having = multiple prefixes introduces operational complexity even if the admins = understand multiple prefixes. All things being equal, having only one = prefix (e.g., a global prefix) is always going to be simpler than having = two.

It will of = course be simpler, the open question being what is meant by "all things = being equal".

In a homenet, there may be cases = where there is no external connectivity, in some cases where none has = yet been established (rather than it having been there and gone away). = There may be devices that have ULAs "burnt in", for which those ULAs = need to be routed around the scope of the homenet. And there is an = argument for ULAs for stable connectivity internally in the face of = whatever happens to external = prefix(es)/connectivity.

In a dual-stack = homenet, there will be at least two prefixes, one IPv4, one = IPv6.

Which reminds me, I would like to see = this document do some deeper analysis of the issue raised after IETF86, = regarding "ULAs on by default" alongside IPv4/NAT. That thread, = discussing the practical issues, ran to 150+ emails before fizzling out = without any specific proposed text, either for Bing's draft or the = homenet arch. I recall that Ole's point on this was that *if* hosts = supported RFC4191 RIO, then ULA routes could be added without a default = route, and dependencies/timeouts on ICMPv6 redirects avoided. And = RFC6204bis ULA-5 recommends that behaviour (along with L-3). The little = snag is that current OSes certainly don't all support = RFC4191.

In other words: what you're saying is "let's create = complexity, because admins will need to understand the complexity = anyway". What I'm saying is that while they need to understand the = complexity, we don't have to create the complexity if we don't need = it.

Well, in a home = network there will be no admins. Plug and play is what we want. But = connection timeouts are equally what we do not = want.

Tim

= --Apple-Mail=_2623307F-BEF7-4283-A509-7C7718DFE528-- From alexandru.petrescu@gmail.com Tue May 21 04:22:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA921F9622 for ; Tue, 21 May 2013 04:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6n3L-eKdfBQ for ; Tue, 21 May 2013 04:22:05 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B29A521F93D7 for ; Tue, 21 May 2013 04:21:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4LBLmO5016592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 May 2013 13:21:48 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4LBLm0R016652 for ; Tue, 21 May 2013 13:21:48 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.11]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4LBLcXs005674 for ; Tue, 21 May 2013 13:21:47 +0200 Message-ID: <519B58C1.5050201@gmail.com> Date: Tue, 21 May 2013 13:21:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:22:13 -0000 Le 21/05/2013 09:38, Erik Kline a écrit : >> I. "Notice that, as described in [RFC4864], in practice, >> applications may treat ULAs like global-scope addresses, but >> address selection algorithms may need to distinguish between ULAs >> and ordinary GUA Global-scope Unicast Address) to ensure >> bidirectional communications." >> >> >> >> 1. "In practice, applications may treat ULAs like global-scope >> addresses" is incorrect. ULAs are global-scope addresses, and we >> should state that they are. >> >> [Bing] They are designed intended to be globally unique, but they >> are clearly defined as “local IPv6 addresses”. And the sentence >> actually comes from RFC4193, see section 1. > > No, they are global addresses. Quoting from section 3.3 of 4193 > (the very first sentence): "By default, the scope of these addresses > is global." > > >> 3. Why are you citing RFC4864? That is about firewalling, not >> uniqueness. >> >> [Bing] RFC4864 is meaningful in the use case discuss, but indeed >> not necessary here, will update. Thanks. >> >> >> >> Suggested replacement text: "Note that, while ULAs are >> global-scope addresses, they do not have global reachability. >> Therefore, address selection algorithms distinguish between ULAs >> and GUA (Global Unicast Address) [RFC 6724]". >> >> [Bing] As said above, I think the sentence would be good if delete >> “while ULAs are global-scope addresses”. > > Reminder: they are global addresses. ULAs are: - globaly unique to the extent their automatic generation guarantees that. - globally scoped, have scope == global. - not routable in the public domain, non publicly routable, not public, not routable in the DFZ (default free zone). Alex > See 4193#section-3.3 (quoted above) and 6724#section-3.1: > > "Also, note that ULAs are considered as global, not site-local, > scope but are handled via the prefix policy table as discussed in > Section 10.6." > > > Let's not try to remake ULAs into IPv6 RFC1918 space. > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Tue May 21 04:36:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22621F96BC for ; Tue, 21 May 2013 04:36:28 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwanCVhUcl3H for ; Tue, 21 May 2013 04:36:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D94E421F969C for ; Tue, 21 May 2013 04:36:26 -0700 (PDT) Received: from [172.20.10.4] (75.sub-70-192-4.myvzw.com [70.192.4.75]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4LBXCOM032615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 May 2013 04:33:14 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4LBXCOM032615 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369135996; bh=XEw+2PQNCEqA7w3+A+Gyt9T+WEI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=vKVpSJo7RcI4FDf6NpXu6j8BfSYD+NfeK13V/HC55IgNvKCmgy7z4yKqG3oBgLvTn aj5jJKnOvTcF9DF+R5wGUEHhY9rDIDOvZ2fdQ8RYDiCq2f/Y2D5kb9Wyc4I/60401I V3Z/XmfeIdjs2ZEK1CZusvSh8mA0AhQY96yGGaIk= Content-Type: multipart/alternative; boundary="Apple-Mail=_609335F1-1EB1-46C2-BC01-36BE0A16A53D" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> Date: Tue, 21 May 2013 04:33:12 -0700 Message-Id: <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> To: Liubing (Leo) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 21 May 2013 04:33:16 -0700 (PDT) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:36:28 -0000 --Apple-Mail=_609335F1-1EB1-46C2-BC01-36BE0A16A53D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 21, 2013, at 12:13 AM, Liubing (Leo) = wrote: > Hi, Lorenzo > =20 > Thanks for your careful review and comments. Please see replies = inline. > =20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Monday, May 20, 2013 3:50 PM > To: Liubing (Leo) > Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > Subject: Re: [v6ops] A brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations > =20 > Bing, > =20 > a few comments: > =20 > I. "Notice that, as described in [RFC4864], in practice, applications = may treat ULAs like global-scope addresses, but address selection = algorithms may need to distinguish between ULAs and ordinary GUA = Global-scope Unicast Address) to ensure bidirectional communications." > =20 > 1. "In practice, applications may treat ULAs like global-scope = addresses" is incorrect. ULAs are global-scope addresses, and we should = state that they are.=20 > [Bing] They are designed intended to be globally unique, but they are = clearly defined as =93local IPv6 addresses=94. And the sentence actually = comes from RFC4193, see section 1. > =20 There is a subtlety to the language here that is important. SCOPE has a specific meaning WRT IPv6 addresses. While ULAs are "Local" = USE addresses, they are not Local SCOPE addresses. They are most = definitely global scope addresses as that is meant in IPv6. I don't see a reference to "local scope" in RFC 4193 section 1. However, = even if there is, we should not duplicate that error here. > Suggested replacement text: "Note that, while ULAs are global-scope = addresses, they do not have global reachability. Therefore, address = selection algorithms distinguish between ULAs and GUA (Global Unicast = Address) [RFC 6724]". > [Bing] As said above, I think the sentence would be good if delete = =93while ULAs are global-scope addresses=94. Why? ULAs ARE global scope addresses. While they are not globally = routed, they are of global scope. Currently there are only two defined = scopes in IPv6=85 { Global , Link-Local }. There was a third scope = (Site-Local), but those were deprecated prior to the creation of ULA. > IV. "Alternatively, it could be regenerated regularly, if desired for = some reason." Can it? How regularly? If it is regenerated your ULA once = a second, how soon before collisions become likely? What about 100, 1000 = or 1000000 times per second? You probably want to qualify "regularly". > [Bing] Generally, =93regularly regenerated=94 on-demand. Say, upper = layer wants a new ULA for a new session id. I think maybe we don=92t = need to worry about the regeneration rate that might increase the = collision probability significantly. That might only concern in a = scientific research of collision. That really depends on whether or not there is a bound on regeneration = rate. I'll leave out the obvious questions about dubious nature of rapid = regeneration. > V. "the network needs ULA as the on-demand and stable addressing which = doesn't need much code to support address assignment mechanisms like = DHCP or ND." I don't think this makes sense. Are you saying such nodes = only support manual address assignment? How is it possible that a sensor = doesn't support automatic address assignment due to lack of resources, = but has enough resources to implement a UI for manual address = assignment? > [Bing] The lack of resources mainly regarding the network environment, = there might not be a comprehensive network provisioning environment for = the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or = self-generating a ULA, then they could make ad-hoc networking without = address provisioning procedures. > And if they need to connect outside, then just add a NPTv6 gateway and = make it as the default gateway. This is to achieve a minimal network = environment/management burden. I'm sorry, but this is just silly. SLAAC is extremely lightweight in its = minimal implementation and if they self-generate a ULA, your "ad-hoc" = network is going to need something (probably heavier) to allow the nodes = to find each other. Indeed, once you implement enough of the ND process = for two nodes to find each other even for link-local addressing, there's = really not much left to complete the minimal implementation of SLAAC. I = think this is an extremely poor use case and not one which should be = deemed acceptable. Sensors are getting smarter and more capable. = Existing sensors can and do (in many cases) implement SLAAC. > VI. "there always be some argument that in practice the ULA+PA makes = terrible operational complexity. But it is not a ULA-specific problem; = the multiple- addresses-per-interface is an important feature of IPv6 = protocol. Running multiple prefixes in IPv6 might be very common, and we = need to adapt this new operational model than that in IPv4." This text = does not make sense. Just because having multiple global-scope addresses = is a feature of IPv6 doesn't mean that you must have multiple = global-scope addresses. For example, you can use only global addresses = and have no routing complexity. > [Bing] The ULA+PA operational complexity contains two aspect. > One is the common issue as described in the texts, running multiple = prefixes in a network is new to the traditional IPv4 model, the admins = need to be familiar with it in the future. This is only a minor complexity and, frankly, is not new. It happens in = IPv4. If both prefixes are, in fact, globally routable and/or have = similar reachability profiles, then there is usually no issue. What is unique to ULA is that it is a globally scoped address without = global reachability. Now software must account for the fact that these = global scope addresses are special and have an undefined limitation = compared to other global scope addresses. (One of the many reasons I think ULA is of dubious value at best). > The other is about the address selection, without the new rules in = RFC6724, it might be problematic to run ULA+PA, when we discuss this in = 6renum, Eric Vyncke reported they had a terrible experience of using = this mode several years ago. In last IETF, we briefly discussed this = issue again, and we thought it was probably because of the old address = selection algorithms that didn=92t distinguish ULA from GUA. Right=85 As near as I can tell, this statement pretty much makes = Lorenzo's point. >=20 Owen --Apple-Mail=_609335F1-1EB1-46C2-BC01-36BE0A16A53D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On May 21, 2013, = at 12:13 AM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:

Hi, = Lorenzo

Thanks for = your careful review and comments. Please see replies = inline.

Lorenzo Colitti = [mailto:lorenzo@google.com]
Sent: Monday, May 20, 2013 3:50 = PM
To: Liubing= (Leo)
Cc: v6ops@ietf.org; Re: [v6ops] A = brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations

Bing,

a few = comments:

I. "Notice that, as described in = [RFC4864], in practice, applications may treat ULAs like global-scope = addresses, but address selection algorithms may need to distinguish = between ULAs and ordinary GUA Global-scope Unicast Address) to ensure = bidirectional communications."

"In practice, applications may treat ULAs like = global-scope addresses" is incorrect. ULAs are global-scope addresses, = and we should state that they are.
[Bing] They are designed intended to be globally unique, but = they are clearly defined as =93local IPv6 addresses=94. And the sentence = actually comes from RFC4193, see section 1.

I don't see a reference to = "local scope" in RFC 4193 section 1. However, even if there is, we = should not duplicate that error = here.

Suggested replacement text: "Note that, while ULAs are = global-scope addresses, they do not have global reachability. Therefore, = address selection algorithms distinguish between ULAs and GUA (Global = Unicast Address) [RFC 6724]".
IV. "Alternatively, it could be = regenerated regularly, if desired for some reason." Can it? How = regularly? If it is regenerated your ULA once a second, how soon before = collisions become likely? What about 100, 1000 or 1000000 times per = second? You probably want to qualify = "regularly".
[Bing] = Generally, =93regularly regenerated=94 on-demand. Say, upper layer wants = a new ULA for a new session id. I think maybe we don=92t need to worry = about the regeneration rate that might increase the collision = probability significantly. That might only concern in a scientific = research of = collision.
That really depends on whether or not there is a bound on = regeneration rate. I'll leave out the obvious questions about dubious = nature of rapid regeneration.

V. "the network needs ULA as the on-demand = and stable addressing which doesn't need much code to support address = assignment mechanisms like DHCP or ND." I don't think this makes sense. = Are you saying such nodes only support manual address assignment? How is = it possible that a sensor doesn't support automatic address assignment = due to lack of resources, but has enough resources to implement a UI for = manual address assignment?
[Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning = procedures.
And if they = need to connect outside, then just add a NPTv6 gateway and make it as = the default gateway. This is to achieve a minimal network = environment/management = burden.

I'm sorry, but this is just silly. SLAAC is extremely lightweight in = its minimal implementation and if they self-generate a ULA, your = "ad-hoc" network is going to need something (probably heavier) to allow = the nodes to find each other. Indeed, once you implement enough of the = ND process for two nodes to find each other even for link-local = addressing, there's really not much left to complete the minimal = implementation of SLAAC. I think this is an extremely poor use case and = not one which should be deemed acceptable. Sensors are getting smarter = and more capable. Existing sensors can and do (in many cases) implement = SLAAC.

VI. "there always be some argument = that in practice the ULA+PA makes terrible operational complexity. But = it is not a ULA-specific problem; the multiple- addresses-per-interface = is an important feature of IPv6 protocol. Running multiple prefixes in = IPv6 might be very common, and we need to adapt this new operational = model than that in IPv4." This text does not make sense. Just because = having multiple global-scope addresses is a feature of IPv6 doesn't mean = that you must have multiple global-scope addresses. For example, you can = use only global addresses and have no routing = complexity.
[Bing] The = ULA+PA operational complexity contains two = aspect.
One is the common = issue as described in the texts, running multiple prefixes in a network = is new to the traditional IPv4 model, the admins need to be familiar = with it in the = future.

This is only a minor complexity and, frankly, is not new. It happens = in IPv4. If both prefixes are, in fact, globally routable and/or have = similar reachability profiles, then there is usually no = issue.

What is unique to ULA is that it is a = globally scoped address without global reachability. Now software must = account for the fact that these global scope addresses are special and = have an undefined limitation compared to other global scope = addresses.

(One of the many reasons I think ULA = is of dubious value at best).

The other is about = the address selection, without the new rules in RFC6724, it might be = problematic to run ULA+PA, when we discuss this in 6renum, Eric Vyncke = reported they had a terrible experience of using this mode several years = ago. In last IETF, we briefly discussed this issue again, and we = thought it was probably because of the old address selection algorithms = that didn=92t distinguish ULA from = GUA.

Right=85 As near as I can tell, this statement pretty much makes = Lorenzo's point.

Owen

= --Apple-Mail=_609335F1-1EB1-46C2-BC01-36BE0A16A53D-- From rajiva@cisco.com Tue May 21 06:07:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336DC21F972D for ; Tue, 21 May 2013 06:07: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbbE-eGbGZ9U for ; Tue, 21 May 2013 06:07:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9C21F9725 for ; Tue, 21 May 2013 06:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=124; q=dns/txt; s=iport; t=1369141651; x=1370351251; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lwjhAN0+cVsMUpKio2jq+GuDtPYtkLhqdK1Rrmo6UpU=; b=QTJ693NREurYg5rqEII1/gN1dicq40ZVajMjrx13j6t5oWQ1RFo+k4Lt PRsECfhTgPG2K5thTaxHgAESH51CHfz6m0sDJfYIbX8hYfmyEmKElPylY 3G3Qt21UlfNlvBzTb2/wwdx8+sQeGqAu0MXPCaRoVKbpZc51uhEP/oBQW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIMAHdwm1GtJV2b/2dsb2JhbABZgwgwgnS+VgQEAYEJFm0HgiEBBDpRASoUQicEG4gFDJpjoQCOD2GDK2EDmGGQF4MPgiY X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208";a="213066950" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 21 May 2013 13:07:31 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4LD7UYq029952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 May 2013 13:07:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 21 May 2013 08:07:30 -0500 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" Thread-Topic: DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vg== Date: Tue, 21 May 2013 13:07:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.82.233.176] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:07:36 -0000 I just realized that neither http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#section- 5.1 Nit: From rajiva@cisco.com Tue May 21 06:14:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECB821F8609 for ; Tue, 21 May 2013 06:14:33 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zkDv0QvQ+2N for ; Tue, 21 May 2013 06:14:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE121F9772 for ; Tue, 21 May 2013 06:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=910; q=dns/txt; s=iport; t=1369142067; x=1370351667; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4WCmGo1IGrB1uu2H+3tIr4KvfcLASEIa1J0UMlZ9WoQ=; b=kJQ92nJnvT0h15CGxkqAH4GoAq9DvghYyg/cRxK9E9tSB1UnqiMGtUdC VkC2KE/PBIyTIK2Aw9Mp3jqtUqU16C53ry8OwS8IC4ZPhybhC0NFtDVpp gk1TX7E97Ng55MjUNEzZzk3BnmapEa6He2eAMVZEhKxAP8LTcfUeTqTkW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMGABtym1GtJXHA/2dsb2JhbABZgwgwgnS+X4EIFm0HgiEBBDpRASoUQiUCBBuIBQyaZKEAjV+BETiCc2EDmGGQF4MPgXE1 X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208";a="213109600" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 21 May 2013 13:14:26 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4LDEQ2t023594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 May 2013 13:14:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 21 May 2013 08:14:26 -0500 From: "Rajiv Asati (rajiva)" To: "v6ops@ietf.org" Thread-Topic: DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGA Date: Tue, 21 May 2013 13:14:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.82.233.176] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BB20D99A449AB468C5ADD9AEA14F5BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:14:33 -0000 I just realized that neither RFC6204, nor the bis draft (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#section -5.1) have added any specifics for what IPv6 address should the CPE router use while executing the DNS proxy function (if enabled). Should it use the IPv6 address assigned to its WAN interface (which is to be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the address assigned to its LAN interface via DHCPv6 PD ? I happen to have an affinity to using the latter. Perhaps, a discussion is worth here. (Please ignore the previous email, which was a premature send) Cheers, Rajiv PS: Just noticed a nit in the section 5.1, btw: //If the service provider specifies one or more DNS resolvers in DHCP configuration options, the CE router SHOULD forward all non-local DNS queries unchanged to those servers. // s/server/resolver From bs7652@att.com Tue May 21 06:53:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A2921F9715 for ; Tue, 21 May 2013 06:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5D-pXRysD0N for ; Tue, 21 May 2013 06:52:50 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 85E2121F85E0 for ; Tue, 21 May 2013 06:52:40 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id c2c7b915.722c9940.97704.00-533.274180.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 21 May 2013 13:52:44 +0000 (UTC) X-MXL-Hash: 519b7c2c1bfbc238-5b1bb1dc78254219da11dffc26bcd3f85ea815ec Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 72c7b915.0.97699.00-415.274101.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 21 May 2013 13:52:40 +0000 (UTC) X-MXL-Hash: 519b7c287f743b7f-6d32707e5e6d2d98cb0ed386f64b2e6bf11aa9af Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4LDqdnL004632; Tue, 21 May 2013 09:52:39 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4LDqReY004459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 09:52:36 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 21 May 2013 13:52:10 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Tue, 21 May 2013 09:52:09 -0400 From: "STARK, BARBARA H" To: "Rajiv Asati (rajiva)" , "v6ops@ietf.org" Thread-Topic: DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGA///ybgA= Date: Tue, 21 May 2013 13:52:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=KuX6LxqN c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=rB15-6yAj] X-AnalysisOut: [iMA:10 a=48vgC7mUAAAA:8 a=5nl7HtzNx8stdIbQ9n8A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=FrOj9zBXoPdd9TYA:21 a=vD-XKe1xVZyUY9pv:21] Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:53:00 -0000 > I just realized that neither RFC6204, nor the bis draft > (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#secti= on > -5.1) have added any specifics for what IPv6 address should the CPE route= r > use while executing the DNS proxy function (if enabled). >=20 > Should it use the IPv6 address assigned to its WAN interface (which is to= be > used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the > address assigned to its LAN interface via DHCPv6 PD ? IMO, the default behavior of the CE router would be to use default address = selection as described in RFC 6724. Since 6204bis (and RFC 6204) requires t= he CE router to be an IPv6 node per RFC 6434, RFC 6434 requires address sel= ection per RFC 3484, and RFC 6724 obsoletes RFC 3484, I think this is cover= ed. Since the DNSv6 query is being sent out the WAN interface, I would expect t= he CE router to select an address from among those it considers appropriate= for traffic that it originates and sends out over that WAN interface. I wo= uld hope that access providers would not be surprised by a CE router consid= ering a globally scoped, preferred, and valid address assigned to its WAN i= nterface as being appropriate for traffic that the CE router sends out over= the WAN interface. The idea that a CE router is supposed to interpret such= an address assigned to its WAN interface as being reserved for a special p= urpose (CPE management) strikes me as odd. If the access provider wants to = assign a special management address to the WAN interface, it would probably= be best to assign an address that would not end up being the CE router's f= irst pick for other traffic, per RFC 6724 guidance. Barbara From jared@puck.nether.net Tue May 21 06:53:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930C021F96A0 for ; Tue, 21 May 2013 06:53:26 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l99YvLaboOeU for ; Tue, 21 May 2013 06:53:25 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 489E221F9512 for ; Tue, 21 May 2013 06:53:25 -0700 (PDT) Received: from [10.0.0.129] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r4LDrBbg026485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 09:53:11 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 21 May 2013 09:53:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> References: To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (puck.nether.net [204.42.254.5]); Tue, 21 May 2013 09:53:11 -0400 (EDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:53:27 -0000 On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) = wrote: >=20 > //If the service provider specifies one > or more DNS resolvers in DHCP configuration options, the CE > router SHOULD forward all non-local DNS queries unchanged to > those servers. >=20 > // >=20 > s/server/resolver One more nit here, a CPE device providing DNS proxy MUST NOT listen to = the WAN interface by default. This poses a risk for DNS amplification = attacks. Right now about 46% of the IPs listed in the = OpenResolverProject are CPE devices that respond on the WAN interface. - Jared= From owen@delong.com Tue May 21 07:27:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A2621F97E9 for ; Tue, 21 May 2013 07:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzWkui2vGTMp for ; Tue, 21 May 2013 07:27:03 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E721F97E8 for ; Tue, 21 May 2013 07:27:03 -0700 (PDT) Received: from [172.20.10.2] (75.sub-70-192-4.myvzw.com [70.192.4.75]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4LEOaCN008265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 May 2013 07:24:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4LEOaCN008265 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369146285; bh=gKChbZs6geYl9lND9oyqp7vsFAQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c1eyballYtef1L0iHvDw9lkT+rIIg2hVGflthq3B99QAg9Sl0YxeQJt6E/JQEW0s1 HOzRT7FLxcDphAdAfWWuyqHMedKO5ypVNIhIcSrcfcMEM6yCF8IEay+gLRw6/xYJgR EbxL6/vrACdpmBJNhqpLDH6hc2rxfV25C2JxiJJU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Tue, 21 May 2013 07:24:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <583A07B7-AF3F-4DA5-B76C-E827B0A80CDD@delong.com> References: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 21 May 2013 07:24:45 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:27:05 -0000 On May 21, 2013, at 6:52 AM, "STARK, BARBARA H" wrote: >> I just realized that neither RFC6204, nor the bis draft >> = (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#sectio= n >> -5.1) have added any specifics for what IPv6 address should the CPE = router >> use while executing the DNS proxy function (if enabled). >>=20 >> Should it use the IPv6 address assigned to its WAN interface (which = is to be >> used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the >> address assigned to its LAN interface via DHCPv6 PD ? >=20 > IMO, the default behavior of the CE router would be to use default = address selection as described in RFC 6724. Since 6204bis (and RFC 6204) = requires the CE router to be an IPv6 node per RFC 6434, RFC 6434 = requires address selection per RFC 3484, and RFC 6724 obsoletes RFC = 3484, I think this is covered. >=20 Technically true, but given the chain of RFCs you had to put together to = make that point, restating it clearly here might not be such a bad = thing, no? > Since the DNSv6 query is being sent out the WAN interface, I would = expect the CE router to select an address from among those it considers = appropriate for traffic that it originates and sends out over that WAN = interface. I would hope that access providers would not be surprised by = a CE router considering a globally scoped, preferred, and valid address = assigned to its WAN interface as being appropriate for traffic that the = CE router sends out over the WAN interface. The idea that a CE router is = supposed to interpret such an address assigned to its WAN interface as = being reserved for a special purpose (CPE management) strikes me as odd. = If the access provider wants to assign a special management address to = the WAN interface, it would probably be best to assign an address that = would not end up being the CE router's first pick for other traffic, per = RFC 6724 guidance. This incorporates a number of (not necessarily correct) assumptions = about how things happen in the real world. It is not at all unlikely that a provider would, e.g. design their = network with one subset of their allocation used for management of CPE = devices while using another subset for assigning customer addresses for = general customer use. My understanding of RFC 6724 is that if the CPE = were assigned (e.g.) 2001:db8:1234::2 as a management address and 2001:db8:9876::/48 for subscriber usage with the WAN link = getting 2001:db8:9876::2 with default gateway 2001:db8:9876::1, then It would be ambiguous as to which of 2001:db8:1234::2 or = 2001:db8:9876::2 would be used to source traffic by default. Owen From Ted.Lemon@nominum.com Tue May 21 07:36:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB321F97BD for ; Tue, 21 May 2013 07:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UounkqIhmSAw for ; Tue, 21 May 2013 07:36:04 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9DF21F97C3 for ; Tue, 21 May 2013 07:35:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUZuGSPzqcBoKwVDqDarR4dVefMEglUhm@postini.com; Tue, 21 May 2013 07:35:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 583311B818C for ; Tue, 21 May 2013 07:35:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3F4DD19005D; Tue, 21 May 2013 07:35:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 21 May 2013 07:35:52 -0700 From: Ted Lemon To: "Rajiv Asati (rajiva)" Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGAgAB7XYA= Date: Tue, 21 May 2013 14:35:51 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AAD43@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E3D16451FBC5C409553AF02F339C086@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:36:11 -0000 On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) wrote: > Should it use the IPv6 address assigned to its WAN interface (which is to > be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the > address assigned to its LAN interface via DHCPv6 PD ? This doesn't make a lot of sense to me. Why wouldn't it always use a sour= ce address that's configured on the interface on which it is transmitting t= he packet? From ek@google.com Tue May 21 07:40:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CDF21F97B5 for ; Tue, 21 May 2013 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7YQyyYuquwY for ; Tue, 21 May 2013 07:39:57 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3D41721F8FD0 for ; Tue, 21 May 2013 07:39:57 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id f4so885195oah.24 for ; Tue, 21 May 2013 07:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vDyameGvbJj8iQrayHvgZ50TAl7SudEh/V0EMWEZ0NA=; b=O/tUCaJZc2qeloKLRCZrUr74MG//xJleOFqmlaR+lCfhTuWNc6dy1tbodpTf1A10F0 rKJp+DyoMn7O8HkBz+r5ungvfys5Pnz3Pzs9rMRpo79K4niRNSroYlOyA4JtEisneBzG ZQibyiBsacTSRjfqgcWkTwNWibUKk38J7PgD9f7b6E+KckKWD4tSuqHZyAkRVXi1BxFS DMHNpKf9EQyqPQgqeiqX/SxxDc6u97WcBRuPgy+e8FFiCAFNrV9QLiAUQJNmd3bOK2d4 mUj2ZTqqYFnFsDocqLeqphUPBhYi3YcbYC+cB1II6uPcvLKVupfeL0E2AGjm5Hd/jjC+ +7Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=vDyameGvbJj8iQrayHvgZ50TAl7SudEh/V0EMWEZ0NA=; b=G+HKtEE0e/OYYVFd/Rjwdtp6jY8fUlbmGXuo0pWacqZA7j+eXYbm455cg4cq34/ThQ 4LLVHwys4bPRhtHaXQn+O6uu9uZ0A/sUUTY7HIyanD+KeHVoW7KV1EqSUVIaDAbJo+0v 06l5VpOtVIlxMSr355cfWY6neScG5TwZkQtMhtvPnyzTyIVQuQE1n1SW4mOzC8Ts0Q5o /grwVhD8MxW+5MZshj7XG9r1bPGjfUbIcRQLFpVlQa/QAojS1Nu1piUjGFyqVwSU58Qs LFc+NAXYORY6zonxLy4oKFUkI8Rdrm7oaJNSxUvDJwLEKSMqVuFsIOlCZj1PtsGdzmDx E3pA== X-Received: by 10.60.155.209 with SMTP id vy17mr1669052oeb.83.1369147196728; Tue, 21 May 2013 07:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.44.169 with HTTP; Tue, 21 May 2013 07:39:36 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Tue, 21 May 2013 23:39:36 +0900 Message-ID: To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlT1oLQyCIU/OS33cxVXqwEG/XYPy1ue23sH7YOECeJBxT+qymz93oHpjkI7plMm8aSl4yJaUoBECn1XjGEaExEkhQgY7va4iBV2xLtd5G7fl8ykzn7YMP+kSTwIRDKqoXyeTPGeh533cdUmd78dvA495qdFcVF9U2cQsHDNQWVCOP6pjbbxX6rR64R8SGBmsAh4YOb Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:40:03 -0000 > Should it use the IPv6 address assigned to its WAN interface (which is to > be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the > address assigned to its LAN interface via DHCPv6 PD ? If I were implementing one, I would do the following: [1] reserve one /64 from the PD for internal use by the resolver [2] the DNS proxy would maintain a small set of keys, rotating periodically [3] when generating/forwarding a request, take an HMAC(Key_current, "normalized query parameters") [4] extract 64bits from a consistent portion of the HMAC, and use that as the lower 64 if the upstream request [5] when a response arrives, compute: (a) HMAC(Key_current, "normalized query parameters"), and (b) HMAC(Key_previous, "normalized query parameters") and verify that the destination address (that reaches the dns proxy in the CPE) matches the reserved prefix in [1] plus the consistently extracted 64bits from either [5a] or [5b]. You could even pull 16 more bits from the HMAC to use as the source port of the query (and hence destination port of the reponse) and validate that as well. From v6ops@globis.net Tue May 21 08:10:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857021F9816 for ; Tue, 21 May 2013 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi66EzFkVpXN for ; Tue, 21 May 2013 08:10:27 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3962C21F8DFC for ; Tue, 21 May 2013 08:10:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3F0938700E4; Tue, 21 May 2013 17:10:11 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEVlWtmYGYad; Tue, 21 May 2013 17:10:11 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1E5498700BD; Tue, 21 May 2013 17:10:11 +0200 (CEST) Message-ID: <519B8E4D.6000703@globis.net> Date: Tue, 21 May 2013 17:10:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Jared Mauch References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> In-Reply-To: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:10:27 -0000 Jared Mauch wrote: > On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) wrote: > >> //If the service provider specifies one >> or more DNS resolvers in DHCP configuration options, the CE >> router SHOULD forward all non-local DNS queries unchanged to >> those servers. >> >> // >> >> s/server/resolver > > > One more nit here, a CPE device providing DNS proxy MUST NOT listen to the WAN interface by default. This poses a risk for DNS amplification attacks. Right now about 46% of the IPs listed in the OpenResolverProject are CPE devices that respond on the WAN interface. > > - Jared Rather than simply not binding to the WAN interface, shouldn't any CPE hosting a DNS server or any other process providing services intended for use exclusively by local nodes really be checking the sanity of the source address AND the interface on which the request packet is arriving ("inside" or "outside")? I don't see any requirements text in Section 4.5 of draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled by default, so the inside address of the CPE might also be addressable and reachable from off-site hosts. The text does say "ought to" and "expected to" but that ain't a requirement. regards, RayH From bs7652@att.com Tue May 21 08:31:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5221F89E1 for ; Tue, 21 May 2013 08:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C9sOtN6MEPt for ; Tue, 21 May 2013 08:31:49 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id AA45521F922A for ; Tue, 21 May 2013 08:31:45 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 1639b915.4e9a0940.139287.00-561.394363.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 21 May 2013 15:31:45 +0000 (UTC) X-MXL-Hash: 519b93614324911e-77adef467a3a00db4dc1d6ef3eae3b0f1ab9ef4d Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0639b915.0.139265.00-320.394319.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 21 May 2013 15:31:45 +0000 (UTC) X-MXL-Hash: 519b936129a89c1f-95c4d8372b71c98cad06eec2021ea15d5dff5e2b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4LFVhbq006721; Tue, 21 May 2013 11:31:43 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4LFVZmK006535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 11:31:40 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 21 May 2013 15:31:19 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Tue, 21 May 2013 11:31:18 -0400 From: "STARK, BARBARA H" To: Owen DeLong Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGA///ybgCAAFN7AP//wLPA Date: Tue, 21 May 2013 15:31:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302C636B@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com> <583A07B7-AF3F-4DA5-B76C-E827B0A80CDD@delong.com> In-Reply-To: <583A07B7-AF3F-4DA5-B76C-E827B0A80CDD@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=NfxRIR/4 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=NgxfmeI1H] X-AnalysisOut: [pAA:10 a=M6vMRD0eH8w95JU3WCoA:9 a=CjuIK1q_8ugA:10 a=D_clHl] X-AnalysisOut: [t_y5ypkA7B:21 a=kDX_v4jA6ThyGdSv:21] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:31:56 -0000 > > IMO, the default behavior of the CE router would be to use default addr= ess > > selection as described in RFC 6724. Since 6204bis (and RFC 6204) requir= es the > > CE router to be an IPv6 node per RFC 6434, RFC 6434 requires address > > selection per RFC 3484, and RFC 6724 obsoletes RFC 3484, I think this i= s > > covered. > > >=20 > Technically true, but given the chain of RFCs you had to put together to = make > that point, restating it clearly here might not be such a bad thing, no? There are many, many cases where restating the obvious could be done. But d= oing so would result in a very long and effectively unusable RFC.=20 In the absence of requirements that suggest otherwise, address selection pe= r RFC 6724 from among addresses available for the interface that will be us= ed to send the packet is pretty obvious, in my book. I only provided the ch= ain to show that it was indeed covered by existing requirements. >=20 > > Since the DNSv6 query is being sent out the WAN interface, I would expe= ct > > the CE router to select an address from among those it considers approp= riate > > for traffic that it originates and sends out over that WAN interface. I= would > > hope that access providers would not be surprised by a CE router consid= ering > > a globally scoped, preferred, and valid address assigned to its WAN int= erface > > as being appropriate for traffic that the CE router sends out over the = WAN > > interface. The idea that a CE router is supposed to interpret such an a= ddress > > assigned to its WAN interface as being reserved for a special purpose (= CPE > > management) strikes me as odd. If the access provider wants to assign a > > special management address to the WAN interface, it would probably be > > best to assign an address that would not end up being the CE router's f= irst > > pick for other traffic, per RFC 6724 guidance. > This incorporates a number of (not necessarily correct) assumptions about > how things happen in the real world. >=20 > It is not at all unlikely that a provider would, e.g. design their networ= k with > one subset of their allocation used for management of CPE devices while > using another subset for assigning customer addresses for general custome= r > use. My understanding of RFC 6724 is that if the CPE were assigned (e.g.) > 2001:db8:1234::2 as a management address and > 2001:db8:9876::/48 for subscriber usage with the WAN link getting > 2001:db8:9876::2 with default gateway 2001:db8:9876::1, then It > would be ambiguous as to which of 2001:db8:1234::2 or 2001:db8:9876::2 > would be used to source traffic by default. >=20 > Owen >From the perspective of the access network, the dangerous assumption would = be to think that a generic "RFC 6204" or "6204bis" CE router device (i.e., = no affiliation with any access provider, not designed per eRouter requireme= nts, BBF TR-124, HGI home gateway requirements, or any other such org's req= uirements), would treat a globally scoped, preferred, and valid IPv6 addres= s assigned to its WAN interface as anything other than fair game for all tr= affic that the CE router originates and sends out that WAN interface. To th= ink that such an IPv6 address could be provided to a generic CE router, and= the CE router would treat it as some sort of special "for management purpo= ses only" address is a really, really, bad assumption. IMO, my assumption t= hat this is a bad assumption is very well-grounded in how things happen in = the real world. If an access provider wants to be sure of what a CE router will do with add= resses that it is given, then that access provider had better have some way= of making sure that CE router meets additional requirements specified exte= rnal to IETF. If the provider you describe has some idea of what they're do= ing, they will have specified requirements for CPE they want to manage; req= uirements would include such details as protocol for management, how to set= up a management interface, credentials for management, etc. If the access = provider you describe above is assigning all those addresses to some generi= c RFC 6204 / 6204bis CE router, that can have no assumed knowledge of manag= ement interfaces or protocols, and the provider is expecting those addresse= s to be used for the purposes you describe... well, that's just too bad. IE= TF RFCs are not cures for stupidity. An access provider who allows subscribers to use generic, unidentified "620= 4/6204bis" CE routers also cannot assume that DNS queries coming from that = subscriber's link will originate from an address assigned to the CE router'= s WAN interface. If the access provider consciously allows for such routers= , I don't see why the access provider would care whether DNS queries origin= ate from an address of a delegated prefix or an address assigned to the CE = router's WAN interface. Barbara From owen@delong.com Tue May 21 12:31:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E02211E80E8 for ; Tue, 21 May 2013 12:31:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5YCFX+wx5o5 for ; Tue, 21 May 2013 12:31:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 45DF811E80D2 for ; Tue, 21 May 2013 12:31:45 -0700 (PDT) Received: from [172.20.10.4] (76.sub-70-215-15.myvzw.com [70.215.15.76]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4LJSvnc020258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 May 2013 12:29:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4LJSvnc020258 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369164559; bh=3rmWXwPcP7NtHi3eTUsoFBCB49s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gI7TCXb0RymXu2Es9C0HVpb+TkpwxOx62illSnccGzsRpCpsmbZyVrxyu6QUj92m5 bv/S79zOCkRUuzfHt+/w5vd5DLOt9E8xxPyT/I5Mcc0jKzEAx3YkknZHJrNVhOZu4Y Y4CWyZard1NeCzFFKQpDhmJGyPH3yK5urWRobdL4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: Date: Tue, 21 May 2013 12:28:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> References: To: Erik Kline X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 21 May 2013 12:29:19 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:31:47 -0000 On May 21, 2013, at 7:39 AM, Erik Kline wrote: >> Should it use the IPv6 address assigned to its WAN interface (which = is to >> be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the >> address assigned to its LAN interface via DHCPv6 PD ? >=20 > If I were implementing one, I would do the following: >=20 > [1] reserve one /64 from the PD for internal use by the resolver >=20 The problem with this approach is that you are assuming that the = provider always grants at least n+1 /64s in the PD where n is the number = of subnets needed on the client side. Given that some ISPs are so misguided as to dole out /60s (or even = less), I don't think you can take that for granted. > [2] the DNS proxy would maintain a small set of keys, rotating = periodically >=20 > [3] when generating/forwarding a request, take an > HMAC(Key_current, "normalized query parameters") >=20 > [4] extract 64bits from a consistent portion of the HMAC, and use > that as the lower 64 if the upstream request >=20 > [5] when a response arrives, compute: >=20 > (a) HMAC(Key_current, "normalized query parameters"), = and > (b) HMAC(Key_previous, "normalized query parameters") >=20 > and verify that the destination address (that reaches the > dns proxy in the CPE) matches the reserved prefix in [1] plus the > consistently extracted 64bits from either [5a] or [5b]. >=20 > You could even pull 16 more bits from the HMAC to use as the source > port of the query (and hence destination port of the reponse) and > validate that as well. What do you gain from all this extra complexity that you don't get from = DNSSEC? Owen From owen@delong.com Tue May 21 12:42:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757AD21F9590 for ; Tue, 21 May 2013 12:42:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6yjUFIeeC5E for ; Tue, 21 May 2013 12:42:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5E21F940B for ; Tue, 21 May 2013 12:42:05 -0700 (PDT) Received: from [172.20.10.4] (76.sub-70-215-15.myvzw.com [70.215.15.76]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4LJbrGh020617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 May 2013 12:37:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4LJbrGh020617 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369165076; bh=dejR+eNd7fA8DxUvPbWSYNVFnK0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d3BYt2KHUDhwm75XsWquiw3DvojPvHLcBqgF0h3t3eUUGlkCAVNj+NJ0qYW1t84Or iTt8zZLeS9XnN8MH2mtBqoVkVbvl+iORRBYTqRHveBck6iNfXlqoRwdywf0TmL7kbQ 7YpjYS73ZASj7hrbnaFyUWyCKq4BOJYTbkxqcHQQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302C636B@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Tue, 21 May 2013 12:37:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <315CEAF0-F89B-43CE-A116-4F5501ACF464@delong.com> References: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com> <583A07B7-AF3F-4DA5-B76C-E827B0A80CDD@delong.com> <2D09D61DDFA73D4C884805CC7865E611302C636B@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 21 May 2013 12:37:56 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:42:06 -0000 On May 21, 2013, at 8:31 AM, "STARK, BARBARA H" wrote: >=20 >=20 >>> IMO, the default behavior of the CE router would be to use default = address >>> selection as described in RFC 6724. Since 6204bis (and RFC 6204) = requires the >>> CE router to be an IPv6 node per RFC 6434, RFC 6434 requires address >>> selection per RFC 3484, and RFC 6724 obsoletes RFC 3484, I think = this is >>> covered. >>>=20 >>=20 >> Technically true, but given the chain of RFCs you had to put together = to make >> that point, restating it clearly here might not be such a bad thing, = no? >=20 > There are many, many cases where restating the obvious could be done. = But doing so would result in a very long and effectively unusable RFC.=20= True, but this isn't one of those cases. This is a case where the required chain of RFCs to arrive at the = "obvious" is non-obvious and where restatement of the non-obvious = (ideally with appropriate referential footnotes to the original RFCs) is = brief and helpful. > In the absence of requirements that suggest otherwise, address = selection per RFC 6724 from among addresses available for the interface = that will be used to send the packet is pretty obvious, in my book. I = only provided the chain to show that it was indeed covered by existing = requirements. While I would agree with you, that statement doesn't actually address at = least one aspect of the question. >>> Since the DNSv6 query is being sent out the WAN interface, I would = expect >>> the CE router to select an address from among those it considers = appropriate >>> for traffic that it originates and sends out over that WAN = interface. I would >>> hope that access providers would not be surprised by a CE router = considering >>> a globally scoped, preferred, and valid address assigned to its WAN = interface >>> as being appropriate for traffic that the CE router sends out over = the WAN >>> interface. The idea that a CE router is supposed to interpret such = an address >>> assigned to its WAN interface as being reserved for a special = purpose (CPE >>> management) strikes me as odd. If the access provider wants to = assign a >>> special management address to the WAN interface, it would probably = be >>> best to assign an address that would not end up being the CE = router's first >>> pick for other traffic, per RFC 6724 guidance. >=20 >> This incorporates a number of (not necessarily correct) assumptions = about >> how things happen in the real world. >>=20 >> It is not at all unlikely that a provider would, e.g. design their = network with >> one subset of their allocation used for management of CPE devices = while >> using another subset for assigning customer addresses for general = customer >> use. My understanding of RFC 6724 is that if the CPE were assigned = (e.g.) >> 2001:db8:1234::2 as a management address and >> 2001:db8:9876::/48 for subscriber usage with the WAN link = getting >> 2001:db8:9876::2 with default gateway 2001:db8:9876::1, then It >> would be ambiguous as to which of 2001:db8:1234::2 or = 2001:db8:9876::2 >> would be used to source traffic by default. >>=20 >> Owen >=20 [quote level error corrected on the next paragraph, I believe this came = from Barbara Stark] but it was quoted at the level to suggest I said it. > =46rom the perspective of the access network, the dangerous assumption = would be to think that a generic "RFC 6204" or "6204bis" CE router = device (i.e., no affiliation with any access provider, not designed per = eRouter requirements, BBF TR-124, HGI home gateway requirements, or any = other such org's requirements), would treat a globally scoped, = preferred, and valid IPv6 address assigned to its WAN interface as = anything other than fair game for all traffic that the CE router = originates and sends out that WAN interface. To think that such an IPv6 = address could be provided to a generic CE router, and the CE router = would treat it as some sort of special "for management purposes only" = address is a really, really, bad assumption. IMO, my assumption that = this is a bad assumption is very well-grounded in how things happen in = the real world. In the case of a generic router, I'm inclined to agree with you. = However, that doesn't mean that such will not happen. In fact, the way this will most likely happen is an SP that mostly = provides routers to customers and forgets that the customer routers that they didn't provide may not behave in this = particular way or even remember after a few years that this behavior is peculiar. > If an access provider wants to be sure of what a CE router will do = with addresses that it is given, then that access provider had better = have some way of making sure that CE router meets additional = requirements specified external to IETF. If the provider you describe = has some idea of what they're doing, they will have specified = requirements for CPE they want to manage; requirements would include = such details as protocol for management, how to set up a management = interface, credentials for management, etc. If the access provider you = describe above is assigning all those addresses to some generic RFC 6204 = / 6204bis CE router, that can have no assumed knowledge of management = interfaces or protocols, and the provider is expecting those addresses = to be used for the purposes you describe... well, that's just too bad. = IETF RFCs are not cures for stupidity. >=20 > An access provider who allows subscribers to use generic, unidentified = "6204/6204bis" CE routers also cannot assume that DNS queries coming = from that subscriber's link will originate from an address assigned to = the CE router's WAN interface. If the access provider consciously allows = for such routers, I don't see why the access provider would care whether = DNS queries originate from an address of a delegated prefix or an = address assigned to the CE router's WAN interface. Allows is always an interesting term in this context. Owen From jared@puck.nether.net Tue May 21 13:06:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF73D11E80DC for ; Tue, 21 May 2013 13:06:04 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sJRnbLe8FqK for ; Tue, 21 May 2013 13:06:04 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2612B21F8528 for ; Tue, 21 May 2013 13:06:04 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r4LK5V6r005944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 16:05:32 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: <519B8E4D.6000703@globis.net> Date: Tue, 21 May 2013 16:05:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> <519B8E4D.6000703@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (puck.nether.net [204.42.254.5]); Tue, 21 May 2013 16:05:32 -0400 (EDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:06:04 -0000 On May 21, 2013, at 11:10 AM, Ray Hunter wrote: >=20 >=20 > Jared Mauch wrote: >> On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) = wrote: >>=20 >>> //If the service provider specifies one >>> or more DNS resolvers in DHCP configuration options, the CE >>> router SHOULD forward all non-local DNS queries unchanged to >>> those servers. >>>=20 >>> // >>>=20 >>> s/server/resolver >>=20 >>=20 >> One more nit here, a CPE device providing DNS proxy MUST NOT listen = to the WAN interface by default. This poses a risk for DNS = amplification attacks. Right now about 46% of the IPs listed in the = OpenResolverProject are CPE devices that respond on the WAN interface. >>=20 >> - Jared > Rather than simply not binding to the WAN interface, shouldn't any CPE > hosting a DNS server or any other process providing services intended > for use exclusively by local nodes really be checking the sanity of = the > source address AND the interface on which the request packet is = arriving > ("inside" or "outside")? If it's doing DNS PROXY, it should only listen to the address it's = advertising to the hosts that it routes on behalf of, and not those that = are part of a ::/0 default range. > I don't see any requirements text in Section 4.5 of > draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled = by > default, so the inside address of the CPE might also be addressable = and > reachable from off-site hosts. The text does say "ought to" and > "expected to" but that ain't a requirement. Perhaps that needs to be fixed. I'm seeing about 14 million CPE devices = (at least) that are open resolvers in the IPv4 universe. I want to make = sure we are setting and specifying appropriate defaults instead of = listening on [*:53] - Jared= From sthaug@nethelp.no Tue May 21 13:15:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D91A21F92BB for ; Tue, 21 May 2013 13:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V62RIt3L1Gh for ; Tue, 21 May 2013 13:15:22 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BB72121F8F87 for ; Tue, 21 May 2013 13:15:21 -0700 (PDT) Received: (qmail 79436 invoked from network); 21 May 2013 20:15:18 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 May 2013 20:15:18 -0000 Date: Tue, 21 May 2013 22:15:18 +0200 (CEST) Message-Id: <20130521.221518.74691221.sthaug@nethelp.no> To: jared@puck.nether.net From: sthaug@nethelp.no In-Reply-To: <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> <519B8E4D.6000703@globis.net> <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@globis.net, v6ops@ietf.org Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:15:27 -0000 > > I don't see any requirements text in Section 4.5 of > > draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled by > > default, so the inside address of the CPE might also be addressable and > > reachable from off-site hosts. The text does say "ought to" and > > "expected to" but that ain't a requirement. > > Perhaps that needs to be fixed. I'm seeing about 14 million CPE devices (at least) that are open resolvers in the IPv4 universe. I want to make sure we are setting and specifying appropriate defaults instead of listening on [*:53] Yes, this needs to be fixed. In the meantime, some of us are putting such a requirement (both for IPv4 and IPv6) into our RFQs etc. Steinar Haug, AS 2116 From v6ops@globis.net Tue May 21 13:20:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758C821F9579 for ; Tue, 21 May 2013 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qii3DCHVMe-E for ; Tue, 21 May 2013 13:20:03 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id CF73921F937B for ; Tue, 21 May 2013 13:20:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D97848700EA; Tue, 21 May 2013 22:19:22 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpYtxTGMxSz3; Tue, 21 May 2013 22:19:22 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B4FC58700E3; Tue, 21 May 2013 22:19:22 +0200 (CEST) Message-ID: <519BD6C4.6050303@globis.net> Date: Tue, 21 May 2013 22:19:16 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Jared Mauch References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> <519B8E4D.6000703@globis.net> <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> In-Reply-To: <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:20:09 -0000 > Jared Mauch > 21 May 2013 22:05 > On May 21, 2013, at 11:10 AM, Ray Hunter wrote: > >> Jared Mauch wrote: >>> On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) wrote: >>> >>>> //If the service provider specifies one >>>> or more DNS resolvers in DHCP configuration options, the CE >>>> router SHOULD forward all non-local DNS queries unchanged to >>>> those servers. >>>> >>>> // >>>> >>>> s/server/resolver >>> One more nit here, a CPE device providing DNS proxy MUST NOT listen to the WAN interface by default. This poses a risk for DNS amplification attacks. Right now about 46% of the IPs listed in the OpenResolverProject are CPE devices that respond on the WAN interface. >>> >>> - Jared >> Rather than simply not binding to the WAN interface, shouldn't any CPE >> hosting a DNS server or any other process providing services intended >> for use exclusively by local nodes really be checking the sanity of the >> source address AND the interface on which the request packet is arriving >> ("inside" or "outside")? > > If it's doing DNS PROXY, it should only listen to the address it's advertising to the hosts that it routes on behalf of, and not those that are part of a ::/0 default range. The point is that your suggested mitigation measure is not enough on its own. If I'm an attacker performing an amplification attack, I don't care about receiving the responses. It's simple enough to inject UDP packets with spoofed source addresses. Not everyone on every remote site has effective uRPF or ingress filters deployed, so IMHO the service/CPE must also perform this uRPF type function itself locally. >> I don't see any requirements text in Section 4.5 of >> draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled by >> default, so the inside address of the CPE might also be addressable and >> reachable from off-site hosts. The text does say "ought to" and >> "expected to" but that ain't a requirement. > > Perhaps that needs to be fixed. I'm seeing about 14 million CPE devices (at least) that are open resolvers in the IPv4 universe. I want to make sure we are setting and specifying appropriate defaults instead of listening on [*:53] > > - Jared Agree entirely with the goal of closing down open resolvers, but mandating a default blanket inbound firewall is a separate discussion IMHO. Mandating that services intended for local use must perform uRPF-like checks and only accept connections from local addresses would solve the problem without having to mandate a firewall. regards, RayH From brian.e.carpenter@gmail.com Tue May 21 13:21:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EE911E80B8 for ; Tue, 21 May 2013 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.185 X-Spam-Level: X-Spam-Status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx1t24cs2ro4 for ; Tue, 21 May 2013 13:21:17 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4250F21F95EF for ; Tue, 21 May 2013 13:21:17 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r11so980753pdi.35 for ; Tue, 21 May 2013 13:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AeNeb0pZlO1UrjN/rVi/30vmHi6dGHah93OQ+/Xz8xY=; b=m2rmxAabIpfzQvwhJ2C95flzYSdbm0K+OpRMnn2Q7d0K/RnyeKnhiXE/gkNYWwtSPZ usyLGNJcnyKEm84ViZefeuVBdllw2i+yBzmLrrLUyXsxxL9txG+Fqlxl9ENfP83dJK6D Aeyk3DadCDb5QW9RgCPVSQf5x7Ni2k64+SXn4D5dXEbNJ6OdbJBZydJiLmgGyOQBLYta uz8n6IBebWj4UAv6YK7ELFpjsJ/6DFYzjPUxDDwvmTg+JyUHwYMpEgsBt135eoDAhUCD VTdFldWidQaZP9nJPSJWLJ3GTvaN8j0Qfj+EtVQbxmNRJ3WLCXfI39v+qk8OWIn0o3D7 ZqNg== X-Received: by 10.66.20.234 with SMTP id q10mr4942081pae.201.1369167677006; Tue, 21 May 2013 13:21:17 -0700 (PDT) Received: from [192.168.1.4] (103.201.252.27.dyn.cust.vf.net.nz. [27.252.201.103]) by mx.google.com with ESMTPSA id j10sm3964013pbh.23.2013.05.21.13.21.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 13:21:15 -0700 (PDT) Message-ID: <519BD73B.50200@gmail.com> Date: Wed, 22 May 2013 08:21:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> In-Reply-To: <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 20:21:22 -0000 On 21/05/2013 23:33, Owen DeLong wrote: > On May 21, 2013, at 12:13 AM, Liubing (Leo) wr= ote: >=20 >> Hi, Lorenzo >> =20 >> Thanks for your careful review and comments. Please see replies inline= =2E >> =20 >> From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 >> Sent: Monday, May 20, 2013 3:50 PM >> To: Liubing (Leo) >> Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools.i= etf.org >> Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-u= la-usage-recommendations >> =20 >> Bing, >> =20 >> a few comments: >> =20 >> I. "Notice that, as described in [RFC4864], in practice, applications = may treat ULAs like global-scope addresses, but address selection algorit= hms may need to distinguish between ULAs and ordinary GUA Global-scope Un= icast Address) to ensure bidirectional communications." >> =20 >> 1. "In practice, applications may treat ULAs like global-scope address= es" is incorrect. ULAs are global-scope addresses, and we should state th= at they are.=20 >> [Bing] They are designed intended to be globally unique, but they are = clearly defined as =E2=80=9Clocal IPv6 addresses=E2=80=9D. And the senten= ce actually comes from RFC4193, see section 1. >> =20 >=20 > There is a subtlety to the language here that is important. >=20 > SCOPE has a specific meaning WRT IPv6 addresses. While ULAs are "Local"= USE addresses, they are not Local SCOPE addresses. They are most definit= ely global scope addresses as that is meant in IPv6. That's correct, of course. The underlying problem here is that the notion of concentric circles of scope that was originally described for IPv6 is simply broken. We can't fix that in the context of describing ULA usage scenarios, so let's not try. (For further thoughts on this see draft-carpenter-referral-ps-02 or even draft-carpenter-behave-referral-object-01.) Brian > I don't see a reference to "local scope" in RFC 4193 section 1. However= , even if there is, we should not duplicate that error here. >=20 >=20 >> Suggested replacement text: "Note that, while ULAs are global-scope ad= dresses, they do not have global reachability. Therefore, address selecti= on algorithms distinguish between ULAs and GUA (Global Unicast Address) [= RFC 6724]". >> [Bing] As said above, I think the sentence would be good if delete =E2= =80=9Cwhile ULAs are global-scope addresses=E2=80=9D. >=20 > Why? ULAs ARE global scope addresses. While they are not globally route= d, they are of global scope. Currently there are only two defined scopes = in IPv6=E2=80=A6 { Global , Link-Local }. There was a third scope (Site-L= ocal), but those were deprecated prior to the creation of ULA. >=20 >> IV. "Alternatively, it could be regenerated regularly, if desired for = some reason." Can it? How regularly? If it is regenerated your ULA once a= second, how soon before collisions become likely? What about 100, 1000 o= r 1000000 times per second? You probably want to qualify "regularly". >> [Bing] Generally, =E2=80=9Cregularly regenerated=E2=80=9D on-demand. S= ay, upper layer wants a new ULA for a new session id. I think maybe we do= n=E2=80=99t need to worry about the regeneration rate that might increase= the collision probability significantly. That might only concern in a s= cientific research of collision. >=20 > That really depends on whether or not there is a bound on regeneration = rate. I'll leave out the obvious questions about dubious nature of rapid = regeneration. >=20 >> V. "the network needs ULA as the on-demand and stable addressing which= doesn't need much code to support address assignment mechanisms like DHC= P or ND." I don't think this makes sense. Are you saying such nodes only = support manual address assignment? How is it possible that a sensor doesn= 't support automatic address assignment due to lack of resources, but has= enough resources to implement a UI for manual address assignment? >> [Bing] The lack of resources mainly regarding the network environment,= there might not be a comprehensive network provisioning environment for = the nodes. If they can be pre-configured with ULA, say, hard-coded in the= embedded system, like the MAC addresses in every single NIC or self-gene= rating a ULA, then they could make ad-hoc networking without address prov= isioning procedures. >> And if they need to connect outside, then just add a NPTv6 gateway and= make it as the default gateway. This is to achieve a minimal network env= ironment/management burden. >=20 > I'm sorry, but this is just silly. SLAAC is extremely lightweight in it= s minimal implementation and if they self-generate a ULA, your "ad-hoc" n= etwork is going to need something (probably heavier) to allow the nodes t= o find each other. Indeed, once you implement enough of the ND process fo= r two nodes to find each other even for link-local addressing, there's re= ally not much left to complete the minimal implementation of SLAAC. I thi= nk this is an extremely poor use case and not one which should be deemed = acceptable. Sensors are getting smarter and more capable. Existing sensor= s can and do (in many cases) implement SLAAC. >=20 >> VI. "there always be some argument that in practice the ULA+PA makes t= errible operational complexity. But it is not a ULA-specific problem; the= multiple- addresses-per-interface is an important feature of IPv6 protoc= ol. Running multiple prefixes in IPv6 might be very common, and we need t= o adapt this new operational model than that in IPv4." This text does not= make sense. Just because having multiple global-scope addresses is a fea= ture of IPv6 doesn't mean that you must have multiple global-scope addres= ses. For example, you can use only global addresses and have no routing c= omplexity. >> [Bing] The ULA+PA operational complexity contains two aspect. >> One is the common issue as described in the texts, running multiple pr= efixes in a network is new to the traditional IPv4 model, the admins need= to be familiar with it in the future. >=20 > This is only a minor complexity and, frankly, is not new. It happens in= IPv4. If both prefixes are, in fact, globally routable and/or have simil= ar reachability profiles, then there is usually no issue. >=20 > What is unique to ULA is that it is a globally scoped address without g= lobal reachability. Now software must account for the fact that these glo= bal scope addresses are special and have an undefined limitation compared= to other global scope addresses. >=20 > (One of the many reasons I think ULA is of dubious value at best). >=20 >> The other is about the address selection, without the new rules in RFC= 6724, it might be problematic to run ULA+PA, when we discuss this in 6ren= um, Eric Vyncke reported they had a terrible experience of using this mod= e several years ago. In last IETF, we briefly discussed this issue again,= and we thought it was probably because of the old address selection alg= orithms that didn=E2=80=99t distinguish ULA from GUA. >=20 > Right=E2=80=A6 As near as I can tell, this statement pretty much makes = Lorenzo's point. >=20 > Owen >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Tue May 21 14:25:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1692711E80E6 for ; Tue, 21 May 2013 14:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF8QB7Kg-D-e for ; Tue, 21 May 2013 14:25:20 -0700 (PDT) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id 7C59C21F9501 for ; Tue, 21 May 2013 14:25:20 -0700 (PDT) Received: from [98.139.212.150] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 21 May 2013 21:25:19 -0000 Received: from [98.139.212.237] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 21 May 2013 21:25:19 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 21 May 2013 21:25:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880855.58776.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 67044 invoked by uid 60001); 21 May 2013 21:25:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369171519; bh=EYNbmtF7te2eACeYJHNhYZMl7GhO08Ajth8GsmigKWg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PWys0Fpo/EqVfV1WUyLv34cXu6fkf/Jq9AZ8F3H48nsiYITN0Wrsn7rkxQUNwpYHpehHFcuJw5cxCX7cPNMQElLDIECoZP5cVUxTcgGeyDuPlRHTH/gAGSZ3B97TNZLUyV9tPwxrUkhXE8L3vu+lLcyh6n/qd5FY2R98bJm8biw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gU4QfyzQgNTqQP2Oi18Ko4uC3ejzB2qSXPaJjhCS8ZB3OuaG3F8KbQG9+mgAgJoGippV+24kbeGolwXl1NlHwXOZX6wJbUNWRGu+0SCiCkeDiXB1DoBXFg+VuRk6IYz4LEZEJ2fJDRfA/XYMo7zgka+Mt7opp0rrgIziZBhvqAU=; X-YMail-OSG: eCd7qxwVM1m8i8PQ.hapDINqg3ALkA4JuhTFPjdyqz5N.M1 myKLVAA.aaKbAPCnz9kmvuslDbrOhpl9dsorb.boP8OltwemlpjnkQG1PcH_ n0xsb3N7rr1gmk26T_Jrvi8ZhxW2KnM7ydrWVmA6ttABTpPp2dGILZgXIIoZ Rzwinr0Ug3EoifGAE7EntstJ3IbUT1ByeWNvAxkmpu2EDP5iGl1mt6o6IhyY jDNGsVEjr8VG2fcK8QWLV7aXgjRCCy8rKsgkkJkz5ryI1VAEEazc5Lm9YD1v SzpjLsLwMkHhSKyfUoDKnx1E7EQ0rQe7MlHrFIgq_HMya.zACOVZY.HCUMmm CdiWvc3ovZqUX9l6xK_oCc.J9xmGdU9rPPRa.lGz3rqnIA8RsuHM.VVbH_4q BWb65EOwBqBLnedMxHPt4i6QSL0ha5ZZvVpoPneukDBMIyeTlbW1CePct6gZ Gcpl_PqrYSBPDgIx1Kyty1FTcmD1Olq0iFzOzI8v2FQ.Faq_jd_ekXORsZXJ gboiQ4mU9lOjTc047ErvCLswNQ3u_p43gwWpZL.Rpyw-- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Tue, 21 May 2013 14:25:19 PDT X-Rocket-MIMEInfo: 002.001, CgoKCjxzbmlwPgo.PiAgUGVyaGFwcyB0aGF0IG5lZWRzIHRvIGJlIGZpeGVkLsKgIEknbSBzZWVpbmcgYWJvdXQgMTQgbWlsbGlvbiBDUEUgCj4gZGV2aWNlcyAoYXQgbGVhc3QpIHRoYXQgYXJlIG9wZW4gcmVzb2x2ZXJzIGluIHRoZSBJUHY0IHVuaXZlcnNlLsKgIEkgd2FudCB0byBtYWtlIAo.IHN1cmUgd2UgYXJlIHNldHRpbmcgYW5kIHNwZWNpZnlpbmcgYXBwcm9wcmlhdGUgZGVmYXVsdHMgaW5zdGVhZCBvZiBsaXN0ZW5pbmcgb24gCj4gWyo6NTNdCj4.IAo.PiAgLSBKYXJlZAo.IEFncmVlIGVudGlyZWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.142.542 References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> <519B8E4D.6000703@globis.net> <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> <519BD6C4.6050303@globis.net> Message-ID: <1369171519.61017.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 21 May 2013 14:25:19 -0700 (PDT) From: Mark Smith To: Ray Hunter , Jared Mauch In-Reply-To: <519BD6C4.6050303@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 21:25:26 -0000 =0A=0A=0A=0A=0A>> Perhaps that needs to be fixed.=A0 I'm seeing abou= t 14 million CPE =0A> devices (at least) that are open resolvers in the IPv= 4 universe.=A0 I want to make =0A> sure we are setting and specifying appro= priate defaults instead of listening on =0A> [*:53]=0A>> =0A>> - Jared=0A>= Agree entirely with the goal of closing down open resolvers, but=0A> manda= ting a default blanket inbound firewall is a separate discussion IMHO.=0A> = Mandating that services intended for local use must perform uRPF-like=0A> c= hecks and only accept connections from local addresses would solve the=0A> = problem without having to mandate a firewall.=0A>=A0=0A=0A+1=0A=0AThe CPE s= hould definitely protect itself and the services it provides from abuse (i.= e. the CPE is a host in this capacity, and is implementing host based firew= alling). I think trying to protect downstream hosts or not is a different i= ssue (when the CPE is performing routing functions).=0A=0ARegards,=0AMark. From rajiva@cisco.com Tue May 21 14:29:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604BB21F9501 for ; Tue, 21 May 2013 14:29:03 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtdB+cb+Lk-K for ; Tue, 21 May 2013 14:28:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B932D21F90CD for ; Tue, 21 May 2013 14:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3614; q=dns/txt; s=iport; t=1369171737; x=1370381337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zKYaWRffy1MRXO81/dQTAzzNnoOtX4w3Tjvxz88cbHw=; b=E+2Bwp1wlcTB+mYIIe/Ny28PeE0sZbmkTMRZ3OUrkndyWOfVHMTUz7yj zkw1nEhbUrZcYk4xCaeM+MCjhXj0WJcygTmDm7CpI314iHc3OvzhUUZIC IR5vleVeuVappjCzwxvJ8I1xeIWM7v6SSkox+D02sIBK4AZ6dhav2eTp/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEjmm1GtJXG8/2dsb2JhbABagwjCFYELFnSCIwEBAQQ6PwwEAgEIDgMEAQEBChQJBzIUCQgCBAENBQiIBbtsjViBETEHBoJtYQOoeIMPgXE1 X-IronPort-AV: E=Sophos;i="4.87,716,1363132800"; d="scan'208";a="213133452" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 21 May 2013 21:28:57 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4LLSu17009032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 21:28:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 21 May 2013 16:28:56 -0500 From: "Rajiv Asati (rajiva)" To: Ray Hunter , Jared Mauch Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOVl6PXrEmNrImuUWwWnq0QiCiSZkQaAMA//++cjA= Date: Tue, 21 May 2013 21:28:56 +0000 Message-ID: References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> <519B8E4D.6000703@globis.net> <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> <519BD6C4.6050303@globis.net> In-Reply-To: <519BD6C4.6050303@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 21:29:03 -0000 Perhaps, we want to phrase it like this - By default, DNS Query should only= be processed, if received on the LAN-side interfaces. In other words, DNS = Query should be ignored, if received on the WAN interface. This doesn't necessarily mean 'firewalling', but can be done via 'firewalli= ng'. Incidentily, I didn't realize (until Jared's email went out) that my CPE ro= uter was an open resolver, despite the firewall being enabled (on LAN and W= AN interafces), and I had to explicitly put an ACL to drop any TCP/UDP port= =3D53 packets coming on the WAN interface. =20 Cheers, Rajiv > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Tuesday, May 21, 2013 4:19 PM > To: Jared Mauch > Cc: Rajiv Asati (rajiva); v6ops@ietf.org > Subject: Re: [v6ops] DNSv6 Proxy ! >=20 > > Jared Mauch > > 21 May 2013 22:05 > > On May 21, 2013, at 11:10 AM, Ray Hunter wrote: > > > >> Jared Mauch wrote: > >>> On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) > wrote: > >>> > >>>> //If the service provider specifies one or more DNS resolvers in > >>>> DHCP configuration options, the CE router SHOULD forward all > >>>> non-local DNS queries unchanged to those servers. > >>>> > >>>> // > >>>> > >>>> s/server/resolver > >>> One more nit here, a CPE device providing DNS proxy MUST NOT listen > to the WAN interface by default. This poses a risk for DNS amplification > attacks. Right now about 46% of the IPs listed in the OpenResolverProjec= t > are CPE devices that respond on the WAN interface. > >>> > >>> - Jared > >> Rather than simply not binding to the WAN interface, shouldn't any > >> CPE hosting a DNS server or any other process providing services > >> intended for use exclusively by local nodes really be checking the > >> sanity of the source address AND the interface on which the request > >> packet is arriving ("inside" or "outside")? > > > > If it's doing DNS PROXY, it should only listen to the address it's adve= rtising > to the hosts that it routes on behalf of, and not those that are part of = a ::/0 > default range. > The point is that your suggested mitigation measure is not enough on its > own. If I'm an attacker performing an amplification attack, I don't care = about > receiving the responses. It's simple enough to inject UDP packets with > spoofed source addresses. Not everyone on every remote site has effective > uRPF or ingress filters deployed, so IMHO the service/CPE must also > perform this uRPF type function itself locally. > >> I don't see any requirements text in Section 4.5 of > >> draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled > >> by default, so the inside address of the CPE might also be > >> addressable and reachable from off-site hosts. The text does say > >> "ought to" and "expected to" but that ain't a requirement. > > > > Perhaps that needs to be fixed. I'm seeing about 14 million CPE > > devices (at least) that are open resolvers in the IPv4 universe. I > > want to make sure we are setting and specifying appropriate defaults > > instead of listening on [*:53] > > > > - Jared > Agree entirely with the goal of closing down open resolvers, but mandatin= g > a default blanket inbound firewall is a separate discussion IMHO. > Mandating that services intended for local use must perform uRPF-like > checks and only accept connections from local addresses would solve the > problem without having to mandate a firewall. >=20 > regards, > RayH From rajiva@cisco.com Tue May 21 14:36:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C216B21F91B0 for ; Tue, 21 May 2013 14:36:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-kRr++6NBQt for ; Tue, 21 May 2013 14:36:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2508721F9128 for ; Tue, 21 May 2013 14:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1033; q=dns/txt; s=iport; t=1369172186; x=1370381786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=D2blbKaIdfBtTCGy13dUfAOWbnk0o/+Iq2saVSDb10o=; b=VvY5zH8OTYT2VMrGgIDQf3VawHDqzI/mCRrWob8Uuk0Pn4kMPXO997gc wpuRKIH2l5+A2JQNaeMRmLnnwMAF382fxTSFd7RNrCJdm0KJQbX9nB3rd w2foUgDbV2SmAvRoce0qC9/sFxdNP71f6b5OLYqhQ+FnXipBTnf0dEzEV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJLom1GtJV2Y/2dsb2JhbABagwjCFoELFnSCIwEBAQQ6PwwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIiAW7ZI5pJgsHBoJtYQOoeIMPgiY X-IronPort-AV: E=Sophos;i="4.87,716,1363132800"; d="scan'208";a="213325188" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 21 May 2013 21:36:05 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4LLa5CH002289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 21:36:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 21 May 2013 16:36:05 -0500 From: "Rajiv Asati (rajiva)" To: Ted Lemon Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGAgAB7XYD///8ZcA== Date: Tue, 21 May 2013 21:36:04 +0000 Message-ID: References: <8D23D4052ABE7A4490E77B1A012B6307751AAD43@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AAD43@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 21:36:31 -0000 Ted, Good Q. The answer is - it is valid to have just LLA only on WAN interface = or IP unnumbered WAN interface of the CPE router.=20 Also, it is possible that a broadband network design may have the GUA assig= ned on the WAN interface is not part of the subscriber/BNG session. But th= is is a corner case. Cheers, Rajiv > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, May 21, 2013 10:36 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DNSv6 Proxy ! >=20 > On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) wrot= e: > > Should it use the IPv6 address assigned to its WAN interface (which is > > to be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or > > the address assigned to its LAN interface via DHCPv6 PD ? >=20 > This doesn't make a lot of sense to me. Why wouldn't it always use a so= urce > address that's configured on the interface on which it is transmitting th= e > packet? From rajiva@cisco.com Tue May 21 14:59:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D72A1F0D2E for ; Tue, 21 May 2013 14:59:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHt5aFSCT-3A for ; Tue, 21 May 2013 14:59:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B7EE721F95FD for ; Tue, 21 May 2013 14:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8269; q=dns/txt; s=iport; t=1369173559; x=1370383159; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Nayv4V6JRg/k35Qigp3UpTZao9FLdqj9lBCc6CNl8Ko=; b=Ebg/TRtN1Q4NxRf1g5FXbvs2kRw0vSBT7bDTT97OcJhGpv888jFHRuY1 90L4zuIrgsYV5GgPobGf2LCt5OsMtFbkm4X2FwQxiX3cd+6x+2DhKaxzS VLP0Sd7v9jHm1DxRoLxrrZBYldzpe57uMe2cK+aYxsTJF3qCXXazD1cgY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADrtm1GtJV2c/2dsb2JhbABagwjCFoELFnSCIwEBAQMBOj8MBAIBCBEEAQEBChQJBzIUCQgCBA4FCId/Brt6jmkxBwaCbWEDkyyVTIMPgiY X-IronPort-AV: E=Sophos;i="4.87,716,1363132800"; d="scan'208";a="213350314" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 21 May 2013 21:59:18 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4LLxHNc026807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 21:59:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 21 May 2013 16:59:17 -0500 From: "Rajiv Asati (rajiva)" To: Owen DeLong , "STARK, BARBARA H" Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGA///ybgCAAGQ/AIAAEqOAgABE5QD//9B7AA== Date: Tue, 21 May 2013 21:59:17 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com> <583A07B7-AF3F-4DA5-B76C-E827B0A80CDD@delong.com> <2D09D61DDFA73D4C884805CC7865E611302C636B@GAALPA1MSGUSR9L.ITServices.sbc.com> <315CEAF0-F89B-43CE-A116-4F5501ACF464@delong.com> In-Reply-To: <315CEAF0-F89B-43CE-A116-4F5501ACF464@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 21:59:25 -0000 First, it is important to specify the DNSv6 behavior in the rfc6204bis draf= t.=20 Second,=20 > >>> IMO, the default behavior of the CE router would be to use default > >>> address selection as described in RFC 6724. Since 6204bis (and RFC > >>> 6204) requires the CE router to be an IPv6 node per RFC 6434, RFC > >>> 6434 requires address selection per RFC 3484, and RFC 6724 obsoletes > >>> RFC 3484, I think this is covered. I don't think it is.=20 Neither RFC6204 nor 6204bis include RFC 6434 as a normative or informative = reference.=20 Moreover, RFC6724 wouldn't provide a deterministic behavior to select one o= r the other address in case of DNS proxy. Additionally, it gets murky since= the CPE WAN IPv6 address may or may not be part of BNG session.=20 > >> It is not at all unlikely that a provider would, e.g. design their > >> network with one subset of their allocation used for management of > >> CPE devices while using another subset for assigning customer > >> addresses for general customer use. My understanding of RFC 6724 is th= at > if the CPE were assigned (e.g.) > >> 2001:db8:1234::2 as a management address and > >> 2001:db8:9876::/48 for subscriber usage with the WAN link getting > >> 2001:db8:9876::2 with default gateway 2001:db8:9876::1, then It > >> would be ambiguous as to which of 2001:db8:1234::2 or > >> 2001:db8:9876::2 would be used to source traffic by default. I agree with Owen. IMO, specifying the DNS proxy to use an address (it may = well be the CPE router address on the LAN interface) from the DHCP-PD block= would provide a deterministic behavior. And DNS messages would certainly g= et accounted for in the BNG subscriber session (as it should be).. =20 Cheers, Rajiv > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Tuesday, May 21, 2013 3:38 PM > To: STARK, BARBARA H > Cc: Rajiv Asati (rajiva); v6ops@ietf.org > Subject: Re: [v6ops] DNSv6 Proxy ! >=20 >=20 > On May 21, 2013, at 8:31 AM, "STARK, BARBARA H" wrote: >=20 > > > > > >>> IMO, the default behavior of the CE router would be to use default > >>> address selection as described in RFC 6724. Since 6204bis (and RFC > >>> 6204) requires the CE router to be an IPv6 node per RFC 6434, RFC > >>> 6434 requires address selection per RFC 3484, and RFC 6724 obsoletes > >>> RFC 3484, I think this is covered. > >>> > >> > >> Technically true, but given the chain of RFCs you had to put together > >> to make that point, restating it clearly here might not be such a bad = thing, > no? > > > > There are many, many cases where restating the obvious could be done. > But doing so would result in a very long and effectively unusable RFC. >=20 > True, but this isn't one of those cases. >=20 > This is a case where the required chain of RFCs to arrive at the "obvious= " is > non-obvious and where restatement of the non-obvious (ideally with > appropriate referential footnotes to the original RFCs) is brief and help= ful. >=20 > > In the absence of requirements that suggest otherwise, address selectio= n > per RFC 6724 from among addresses available for the interface that will b= e > used to send the packet is pretty obvious, in my book. I only provided th= e > chain to show that it was indeed covered by existing requirements. >=20 > While I would agree with you, that statement doesn't actually address at > least one aspect of the question. >=20 > >>> Since the DNSv6 query is being sent out the WAN interface, I would > >>> expect the CE router to select an address from among those it > >>> considers appropriate for traffic that it originates and sends out > >>> over that WAN interface. I would hope that access providers would > >>> not be surprised by a CE router considering a globally scoped, > >>> preferred, and valid address assigned to its WAN interface as being > >>> appropriate for traffic that the CE router sends out over the WAN > >>> interface. The idea that a CE router is supposed to interpret such > >>> an address assigned to its WAN interface as being reserved for a > >>> special purpose (CPE > >>> management) strikes me as odd. If the access provider wants to > >>> assign a special management address to the WAN interface, it would > >>> probably be best to assign an address that would not end up being > >>> the CE router's first pick for other traffic, per RFC 6724 guidance. > > > >> This incorporates a number of (not necessarily correct) assumptions > >> about how things happen in the real world. > >> > >> It is not at all unlikely that a provider would, e.g. design their > >> network with one subset of their allocation used for management of > >> CPE devices while using another subset for assigning customer > >> addresses for general customer use. My understanding of RFC 6724 is th= at > if the CPE were assigned (e.g.) > >> 2001:db8:1234::2 as a management address and > >> 2001:db8:9876::/48 for subscriber usage with the WAN link getting > >> 2001:db8:9876::2 with default gateway 2001:db8:9876::1, then It > >> would be ambiguous as to which of 2001:db8:1234::2 or > >> 2001:db8:9876::2 would be used to source traffic by default. > >> > >> Owen > > >=20 > [quote level error corrected on the next paragraph, I believe this came f= rom > Barbara Stark] but it was quoted at the level to suggest I said it. >=20 > > From the perspective of the access network, the dangerous assumption > would be to think that a generic "RFC 6204" or "6204bis" CE router device > (i.e., no affiliation with any access provider, not designed per eRouter > requirements, BBF TR-124, HGI home gateway requirements, or any other > such org's requirements), would treat a globally scoped, preferred, and > valid IPv6 address assigned to its WAN interface as anything other than f= air > game for all traffic that the CE router originates and sends out that WAN > interface. To think that such an IPv6 address could be provided to a gene= ric > CE router, and the CE router would treat it as some sort of special "for > management purposes only" address is a really, really, bad assumption. > IMO, my assumption that this is a bad assumption is very well-grounded in > how things happen in the real world. >=20 > In the case of a generic router, I'm inclined to agree with you. However,= that > doesn't mean that such will not happen. > In fact, the way this will most likely happen is an SP that mostly provid= es > routers to customers and forgets that the customer routers that they didn= 't > provide may not behave in this particular way or even remember after a fe= w > years that this behavior is peculiar. >=20 > > If an access provider wants to be sure of what a CE router will do with > addresses that it is given, then that access provider had better have som= e > way of making sure that CE router meets additional requirements specified > external to IETF. If the provider you describe has some idea of what they= 're > doing, they will have specified requirements for CPE they want to manage; > requirements would include such details as protocol for management, how > to set up a management interface, credentials for management, etc. If the > access provider you describe above is assigning all those addresses to so= me > generic RFC 6204 / 6204bis CE router, that can have no assumed knowledge > of management interfaces or protocols, and the provider is expecting thos= e > addresses to be used for the purposes you describe... well, that's just t= oo > bad. IETF RFCs are not cures for stupidity. > > > > An access provider who allows subscribers to use generic, unidentified > "6204/6204bis" CE routers also cannot assume that DNS queries coming from > that subscriber's link will originate from an address assigned to the CE > router's WAN interface. If the access provider consciously allows for suc= h > routers, I don't see why the access provider would care whether DNS > queries originate from an address of a delegated prefix or an address > assigned to the CE router's WAN interface. >=20 > Allows is always an interesting term in this context. >=20 > Owen From rajiva@cisco.com Tue May 21 15:11:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621FB21F8F12 for ; Tue, 21 May 2013 15:11:41 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAMLXrkpNdNh for ; Tue, 21 May 2013 15:11:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C726421F9118 for ; Tue, 21 May 2013 15:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2990; q=dns/txt; s=iport; t=1369174295; x=1370383895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yxmoj4A89b9qcqTw9uE81QufuM1obicNIhKOXVYlPio=; b=LUiPBdGDpcnsNFTcJiijXIu7V4Fsqv/a2/eV77DzTYVbTJUUqFbhJdwM rW/ppCT5suIiycO05TxMUhHUEzJ9xTIwD6SYEOLZ1wEL11FqNtVRUvifP XOb77I8VJCIEftfJNOEg5JFcfhte/BmtVb1c+9gnKMstF1HTZ0pBv0CLb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMLwm1GtJXHB/2dsb2JhbABagwjCF4ELFnSCIwEBAQMBOjIKAwUHBAIBCBEEAQEBChQJBzIUCQgCBAENBQiHfwa7fI5pJgsHBoJtYQOoeIMPgWokGA X-IronPort-AV: E=Sophos;i="4.87,716,1363132800"; d="scan'208";a="213335936" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 21 May 2013 22:11:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4LMBZEu012390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 22:11:35 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 21 May 2013 17:11:34 -0500 From: "Rajiv Asati (rajiva)" To: Owen DeLong , Erik Kline Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGAgABa4ACAAFDUAP//1mAA Date: Tue, 21 May 2013 22:11:34 +0000 Message-ID: References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> In-Reply-To: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 22:11:41 -0000 I like Erik's proposal, since it would nicely plug the hole that Jared poin= ted out and also provide the source address to be used > The problem with this approach is that you are assuming that the provider > always grants at least n+1 /64s in the PD where n is the number of subnet= s > needed on the client side. >=20 > Given that some ISPs are so misguided as to dole out /60s (or even less),= I > don't think you can take that for granted. I don't see a non-trivial issue with applying Erik's proposal even if /64 w= as provided as DHCP-PD. After all, the CPE router must have to assign at le= ast one IP address on its LAN interface.=20 > What do you gain from all this extra complexity that you don't get from > DNSSEC? I see DNSSEC being orthogonal since it is not about specifying which IP add= ress to use as the source address, or whether or not to process the incomin= g DNS messages. =20 Cheers, Rajiv > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Tuesday, May 21, 2013 3:29 PM > To: Erik Kline > Cc: Rajiv Asati (rajiva); v6ops@ietf.org > Subject: Re: [v6ops] DNSv6 Proxy ! >=20 >=20 > On May 21, 2013, at 7:39 AM, Erik Kline wrote: >=20 > >> Should it use the IPv6 address assigned to its WAN interface (which > >> is to be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, > >> or the address assigned to its LAN interface via DHCPv6 PD ? > > > > If I were implementing one, I would do the following: > > > > [1] reserve one /64 from the PD for internal use by the resolver > > >=20 > The problem with this approach is that you are assuming that the provider > always grants at least n+1 /64s in the PD where n is the number of subnet= s > needed on the client side. >=20 > Given that some ISPs are so misguided as to dole out /60s (or even less),= I > don't think you can take that for granted. >=20 > > [2] the DNS proxy would maintain a small set of keys, rotating > > periodically > > > > [3] when generating/forwarding a request, take an > > HMAC(Key_current, "normalized query parameters") > > > > [4] extract 64bits from a consistent portion of the HMAC, and use > > that as the lower 64 if the upstream request > > > > [5] when a response arrives, compute: > > > > (a) HMAC(Key_current, "normalized query parameters"), an= d > > (b) HMAC(Key_previous, "normalized query parameters") > > > > and verify that the destination address (that reaches the dns > > proxy in the CPE) matches the reserved prefix in [1] plus the > > consistently extracted 64bits from either [5a] or [5b]. > > > > You could even pull 16 more bits from the HMAC to use as the source > > port of the query (and hence destination port of the reponse) and > > validate that as well. >=20 > What do you gain from all this extra complexity that you don't get from > DNSSEC? >=20 > Owen From marka@isc.org Tue May 21 17:55:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7801521F93C8 for ; Tue, 21 May 2013 17:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiXkeRHMgNfo for ; Tue, 21 May 2013 17:55:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CF1B921F871D for ; Tue, 21 May 2013 17:55:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2EBFAC9427; Wed, 22 May 2013 00:55:37 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369184142; bh=52oHP6kT+hMS4GZ5mYl0eTiccYFp6X+b6ekW4qUis+E=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=NT408jgINeuwGSCgiW8KMglCpSS70vtwhx4OXKxSEjsCysQFgJ0WkIIfjD6SSgcRV LFsKLksmnCyy9r9/X4rsvXpn80WHkG0/cLOsbhBZSb8GYJuaAwX3S7iPGDsGQWT1d6 6HWdNXrGpEk/EvmMPJxA1qZ2+zaigfhBkinCL6ak= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 22 May 2013 00:55:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C63CB216C40; Wed, 22 May 2013 00:55:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2733D3496A36; Wed, 22 May 2013 10:55:33 +1000 (EST) To: "Rajiv Asati (rajiva)" From: Mark Andrews References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> In-reply-to: Your message of "Tue, 21 May 2013 22:11:34 +0000." Date: Wed, 22 May 2013 10:55:33 +1000 Message-Id: <20130522005533.2733D3496A36@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 00:55:47 -0000 By default it offers recursion to local clients and returns REFUSED to remote clients that it can't answer from local zone content. If a CPE is proxying then it need to present as many address to the internal clients as is proxing external nameservers. It is long past the time when a CPE can offer a single address for address family. DNS clients need to be able to actuately determine the capabilities of the servers being proxied. The applies to both IPv4 and IPv6. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From leo.liubing@huawei.com Tue May 21 18:32:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8D421F9374 for ; Tue, 21 May 2013 18:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY28hESrv3Vv for ; Tue, 21 May 2013 18:32:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3621F936D for ; Tue, 21 May 2013 18:32:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA25616; Wed, 22 May 2013 01:32:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 02:32:12 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 02:32:20 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Wed, 22 May 2013 09:32:16 +0800 From: "Liubing (Leo)" To: Owen DeLong Thread-Topic: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHOVS+HyCM8E5Dr9EyOxCY462I/kZkO8esQgAALjQCAAW5fUA== Date: Wed, 22 May 2013 01:32:15 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D728171@nkgeml506-mbx.china.huawei.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> In-Reply-To: <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D728171nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 01:32:29 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D728171nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Owen There is a subtlety to the language here that is important. SCOPE has a specific meaning WRT IPv6 addresses. While ULAs are "Local" USE= addresses, they are not Local SCOPE addresses. They are most definitely gl= obal scope addresses as that is meant in IPv6. I don't see a reference to "local scope" in RFC 4193 section 1. However, ev= en if there is, we should not duplicate that error here. [Bing] As replied to Lorenzo and Erik. I'll update this accordingly. Thanks= for your explanation. Suggested replacement text: "Note that, while ULAs are global-scope address= es, they do not have global reachability. Therefore, address selection algo= rithms distinguish between ULAs and GUA (Global Unicast Address) [RFC 6724]= ". [Bing] As said above, I think the sentence would be good if delete "while U= LAs are global-scope addresses". Why? ULAs ARE global scope addresses. While they are not globally routed, t= hey are of global scope. Currently there are only two defined scopes in IPv= 6... { Global , Link-Local }. There was a third scope (Site-Local), but tho= se were deprecated prior to the creation of ULA. [Bing] That was my misunderstanding, I've replied to Lorenzo. I'm sorry, but this is just silly. SLAAC is extremely lightweight in its mi= nimal implementation and if they self-generate a ULA, your "ad-hoc" network= is going to need something (probably heavier) to allow the nodes to find e= ach other. Indeed, once you implement enough of the ND process for two node= s to find each other even for link-local addressing, there's really not muc= h left to complete the minimal implementation of SLAAC. I think this is an = extremely poor use case and not one which should be deemed acceptable. Sens= ors are getting smarter and more capable. Existing sensors can and do (in m= any cases) implement SLAAC. [Bing] Please see the last mail to Lorenzo. Surely it should support SLAAC,= and the draft clearly stated that. Best regards, Bing --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D728171nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Owen

= ;

There is a subtlety to the lang= uage here that is important.

SCOPE has a specific meaning WR= T IPv6 addresses. While ULAs are "Local" USE addresses, they are = not Local SCOPE addresses. They are most definitely global scope addresses = as that is meant in IPv6.

I don't see a reference to &quo= t;local scope" in RFC 4193 section 1. However, even if there is, we sh= ould not duplicate that error here.

[Bing] = As replied to Lorenzo and Erik. I’ll update this accordingly. Thanks = for your explanation.

= ;

Suggested replacement text: &qu= ot;Note that, while ULAs are global-scope addresses, they do not have globa= l reachability. Therefore, address selection algorithms distinguish between= ULAs and GUA (Global Unicast Address) [RFC 6724]".

[Bing] = As said above, I think the sentence would be good if delete “while UL= As are global-scope addresses”.

Why? ULAs ARE global scope addr= esses. While they are not globally routed, they are of global scope. Curren= tly there are only two defined scopes in IPv6… { Global , Link-Local = }. There was a third scope (Site-Local), but those were deprecated prior to the creation of ULA.

[Bing] = That was my misunderstanding, I’ve replied to Lorenzo.

I'm sorry, but this is just sil= ly. SLAAC is extremely lightweight in its minimal implementation and if the= y self-generate a ULA, your "ad-hoc" network is going to need som= ething (probably heavier) to allow the nodes to find each other. Indeed, once you implement enough of the ND process for t= wo nodes to find each other even for link-local addressing, there's really = not much left to complete the minimal implementation of SLAAC. I think this= is an extremely poor use case and not one which should be deemed acceptable. Sensors are getting smarter and= more capable. Existing sensors can and do (in many cases) implement SLAAC.=

[Bing] = Please see the last mail to Lorenzo. Surely it should support SLAAC, and th= e draft clearly stated that.

Best re= gards,

Bing

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D728171nkgeml506mbxchi_-- From tjc@ecs.soton.ac.uk Tue May 21 23:08:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737C121F9318 for ; Tue, 21 May 2013 23:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1nWuzNBXBE9 for ; Tue, 21 May 2013 23:08:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 6998421F930C for ; Tue, 21 May 2013 23:08:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4M685Uu027321; Wed, 22 May 2013 07:08:05 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4M685Uu027321 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369202886; bh=8rEWLBtI5Em2xwSa1Pl3GmmmvYE=; h=References:Mime-Version:In-Reply-To:Cc:From:Subject:Date:To; b=DRN5N1dLMdplSQlZNMeMn9qBupIksfcWvk/bxgdQSRG8oodMJfCJbK/XACPTnaAQi s7j62505Nyqr6s1c3SwEXGdLQIGV6Gh2NdNp5xhnelvVyF4R/1nbrgT0LBLGzoUPDl kIpxprBYoU04OXeCSm8nbnY9PBshOhZyFDBtwDtE= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p4L7850430650359aI ret-id none; Wed, 22 May 2013 07:08:05 +0100 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4M66gbb014957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 07:06:45 +0100 References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> <20130522005533.2733D3496A36@drugs.dv.isc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20130522005533.2733D3496A36@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPad Mail (10B329) From: Tim Chown Date: Wed, 22 May 2013 07:06:42 +0100 To: Mark Andrews X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4L785043065035900; tid=p4L7850430650359aI; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4M685Uu027321 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 06:08:14 -0000 On 22 May 2013, at 01:55, Mark Andrews wrote: >=20 > By default it offers recursion to local clients and returns REFUSED > to remote clients that it can't answer from local zone content. >=20 > If a CPE is proxying then it need to present as many address to the > internal clients as is proxing external nameservers. It is long > past the time when a CPE can offer a single address for address > family. DNS clients need to be able to actuately determine the > capabilities of the servers being proxied. The applies to both > IPv4 and IPv6. If adding text for this, is it also worth nothing that future CPE's may act a= s authoritative name servers for domains used to refer to devices in the hom= e? If so, the configuration advice wrt DNS amplification attacks is more lik= ely to need to be similar to that of an enterprise. Tim= From Carl.Wuyts@technicolor.com Wed May 22 02:24:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819A621F89FF for ; Wed, 22 May 2013 02:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xj8RPPebeBc for ; Wed, 22 May 2013 02:24:45 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1821F962A for ; Wed, 22 May 2013 02:24:16 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUZyOvoJtQ8I2WKqAHrUULVPe7AijdG74@postini.com; Wed, 22 May 2013 02:24:44 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 22 May 2013 11:23:49 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.119]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 22 May 2013 11:23:57 +0200 From: Wuyts Carl To: Mark Smith , Ray Hunter , Jared Mauch Date: Wed, 22 May 2013 11:23:55 +0200 Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: Ac5Wab9RMbsQyAEkQgKoN910nzYgQQAZBb1g Message-ID: <3135C2851EB6764BACEF35D8B495596806E76E4E02@MOPESMBX01.eu.thmulti.com> References: <0176352E-5A18-4B4F-A4AB-4A4FEE792C17@puck.nether.net> <519B8E4D.6000703@globis.net> <1E0C817F-8933-4369-9144-7CB11F213D00@puck.nether.net> <519BD6C4.6050303@globis.net> <1369171519.61017.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1369171519.61017.YahooMailNeo@web142504.mail.bf1.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:24:50 -0000 Well, I wouldn't be too sure about the presence of firewall on the CPE.=20 At the last IPv6 congress in Paris (March 2013), one of the vendors on stag= e was promoting a more "open" approach, so no stateful firewall on it. regs Carl Wuyts -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ark Smith Sent: dinsdag 21 mei 2013 23:25 To: Ray Hunter; Jared Mauch Cc: v6ops@ietf.org Subject: Re: [v6ops] DNSv6 Proxy ! >> Perhaps that needs to be fixed.=A0 I'm seeing about 14 million CPE > devices (at least) that are open resolvers in the IPv4 universe.=A0 I=20 > want to make sure we are setting and specifying appropriate defaults=20 > instead of listening on [*:53] >>=20 >> - Jared > Agree entirely with the goal of closing down open resolvers, but=20 > mandating a default blanket inbound firewall is a separate discussion IMH= O. > Mandating that services intended for local use must perform uRPF-like=20 > checks and only accept connections from local addresses would solve=20 > the problem without having to mandate a firewall. >=A0 +1 The CPE should definitely protect itself and the services it provides from = abuse (i.e. the CPE is a host in this capacity, and is implementing host ba= sed firewalling). I think trying to protect downstream hosts or not is a di= fferent issue (when the CPE is performing routing functions). Regards, Mark. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Wed May 22 02:28:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5AB21F962A for ; Wed, 22 May 2013 02:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTwPuk44linX for ; Wed, 22 May 2013 02:28:16 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 353C321F89FF for ; Wed, 22 May 2013 02:28:14 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUZyPraHsp/RpkKnB+bhH41/DyY4JeYTt@postini.com; Wed, 22 May 2013 02:28:15 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 22 May 2013 11:26:56 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.119]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 22 May 2013 11:27:04 +0200 From: Wuyts Carl To: "Rajiv Asati (rajiva)" , Ted Lemon Date: Wed, 22 May 2013 11:27:01 +0200 Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGAgAB7XYD///8ZcIAAxuuQ Message-ID: <3135C2851EB6764BACEF35D8B495596806E76E4E24@MOPESMBX01.eu.thmulti.com> References: <8D23D4052ABE7A4490E77B1A012B6307751AAD43@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:28:21 -0000 Yes, it is valid to have LLA only on WAN interface, in fact, often used wit= h e.g. PPP deployments. Depending on what you'd like to do with WAN management, you might want to i= ntroduce unnumbered indeed, but as some (lots of in fact) customers still r= ely on IPv4 for management purposes, there's often no need to have IPv6 on = WAN or unnumbered WAN. Carl Wuyts -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= ajiv Asati (rajiva) Sent: dinsdag 21 mei 2013 23:36 To: Ted Lemon Cc: v6ops@ietf.org Subject: Re: [v6ops] DNSv6 Proxy ! Ted, Good Q. The answer is - it is valid to have just LLA only on WAN interface = or IP unnumbered WAN interface of the CPE router.=20 Also, it is possible that a broadband network design may have the GUA assig= ned on the WAN interface is not part of the subscriber/BNG session. But th= is is a corner case. Cheers, Rajiv > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, May 21, 2013 10:36 AM > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] DNSv6 Proxy ! >=20 > On May 21, 2013, at 9:14 AM, Rajiv Asati (rajiva) wrot= e: > > Should it use the IPv6 address assigned to its WAN interface (which=20 > > is to be used for CPE management, really) via DHCPv6 IA_NA or SLAAC,=20 > > or the address assigned to its LAN interface via DHCPv6 PD ? >=20 > This doesn't make a lot of sense to me. Why wouldn't it always use a so= urce > address that's configured on the interface on which it is transmitting=20 > the packet? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Wed May 22 02:29:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9459E21F8A7B for ; Wed, 22 May 2013 02:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx6AkDG4k49r for ; Wed, 22 May 2013 02:29:43 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F74921F8619 for ; Wed, 22 May 2013 02:29:41 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUZyQBIkyRcrJhj66SAoUIL5HYrbUrt+Y@postini.com; Wed, 22 May 2013 02:29:43 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 22 May 2013 11:28:33 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.119]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 22 May 2013 11:28:41 +0200 From: Wuyts Carl To: "Rajiv Asati (rajiva)" , Owen DeLong , Erik Kline Date: Wed, 22 May 2013 11:28:38 +0200 Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: AQHOViQm+Pd3mqdCS0GWLskNYM77vpkPrrGAgABa4ACAAFDUAP//1mAAgADAH2A= Message-ID: <3135C2851EB6764BACEF35D8B495596806E76E4E30@MOPESMBX01.eu.thmulti.com> References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:29:48 -0000 Whatever is being decided here, take into account that all variants between= /64 and /48 as ia_pd length exist in the real world. And yes, I know, /64 is not ideal, but it is in place today so should not i= gnored. Carl Wuyts -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= ajiv Asati (rajiva) Sent: woensdag 22 mei 2013 0:12 To: Owen DeLong; Erik Kline Cc: v6ops@ietf.org Subject: Re: [v6ops] DNSv6 Proxy ! I like Erik's proposal, since it would nicely plug the hole that Jared poin= ted out and also provide the source address to be used > The problem with this approach is that you are assuming that the=20 > provider always grants at least n+1 /64s in the PD where n is the=20 > number of subnets needed on the client side. >=20 > Given that some ISPs are so misguided as to dole out /60s (or even=20 > less), I don't think you can take that for granted. I don't see a non-trivial issue with applying Erik's proposal even if /64 w= as provided as DHCP-PD. After all, the CPE router must have to assign at le= ast one IP address on its LAN interface.=20 > What do you gain from all this extra complexity that you don't get=20 > from DNSSEC? I see DNSSEC being orthogonal since it is not about specifying which IP add= ress to use as the source address, or whether or not to process the incomin= g DNS messages. =20 Cheers, Rajiv > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Tuesday, May 21, 2013 3:29 PM > To: Erik Kline > Cc: Rajiv Asati (rajiva); v6ops@ietf.org > Subject: Re: [v6ops] DNSv6 Proxy ! >=20 >=20 > On May 21, 2013, at 7:39 AM, Erik Kline wrote: >=20 > >> Should it use the IPv6 address assigned to its WAN interface (which=20 > >> is to be used for CPE management, really) via DHCPv6 IA_NA or=20 > >> SLAAC, or the address assigned to its LAN interface via DHCPv6 PD ? > > > > If I were implementing one, I would do the following: > > > > [1] reserve one /64 from the PD for internal use by the resolver > > >=20 > The problem with this approach is that you are assuming that the=20 > provider always grants at least n+1 /64s in the PD where n is the=20 > number of subnets needed on the client side. >=20 > Given that some ISPs are so misguided as to dole out /60s (or even=20 > less), I don't think you can take that for granted. >=20 > > [2] the DNS proxy would maintain a small set of keys, rotating=20 > > periodically > > > > [3] when generating/forwarding a request, take an=20 > > HMAC(Key_current, "normalized query parameters") > > > > [4] extract 64bits from a consistent portion of the HMAC, and=20 > > use that as the lower 64 if the upstream request > > > > [5] when a response arrives, compute: > > > > (a) HMAC(Key_current, "normalized query parameters"), an= d > > (b) HMAC(Key_previous, "normalized query parameters") > > > > and verify that the destination address (that reaches the=20 > > dns proxy in the CPE) matches the reserved prefix in [1] plus the=20 > > consistently extracted 64bits from either [5a] or [5b]. > > > > You could even pull 16 more bits from the HMAC to use as the source=20 > > port of the query (and hence destination port of the reponse) and=20 > > validate that as well. >=20 > What do you gain from all this extra complexity that you don't get=20 > from DNSSEC? >=20 > Owen _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Wed May 22 09:02:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E1B21F9060 for ; Wed, 22 May 2013 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvUjblcjfhrn for ; Wed, 22 May 2013 09:02:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD121F8916 for ; Wed, 22 May 2013 09:02:49 -0700 (PDT) Received: from [172.20.10.4] (78.sub-70-192-1.myvzw.com [70.192.1.78]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4MFw7rr026202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 May 2013 08:58:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4MFw7rr026202 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369238290; bh=ltHLWIMGbPSLMr3s2sAssIladG0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XrHrPDMNCo24DrYemSw2UUoxOR/lxfFyKTeIzQHLx4QPNdfKq5j3O2WSFywfSGATN qKtGJUPGqKFEJTDjmas/vwqelF7zVQ/FrYjbKIziLGv3Dk3ziCNPZjjYgKbDTjzoHA 4XXsPsHctYpNBQStMym2+l7u39IDp1lBYvzku7kM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: Date: Wed, 22 May 2013 11:58:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39EB9868-F5E5-4FE9-B8B9-9A8D52EA8B5F@delong.com> References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 22 May 2013 08:58:10 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 16:02:52 -0000 On May 21, 2013, at 6:11 PM, Rajiv Asati (rajiva) = wrote: > I like Erik's proposal, since it would nicely plug the hole that Jared = pointed out and also provide the source address to be used >=20 It goes well beyond the simplest and ideal solution to the stated = problem=85 >> The problem with this approach is that you are assuming that the = provider >> always grants at least n+1 /64s in the PD where n is the number of = subnets >> needed on the client side. >>=20 >> Given that some ISPs are so misguided as to dole out /60s (or even = less), I >> don't think you can take that for granted. >=20 > I don't see a non-trivial issue with applying Erik's proposal even if = /64 was provided as DHCP-PD. After all, the CPE router must have to = assign at least one IP address on its LAN interface.=20 >=20 But it is frequently rotating that address and requires that the entire = /64 be available for cryptographic hashing of the request in question. = It makes no allowance for collision with an address in use for another = host. As such, his proposal requires the dedication of an entire /64 = that doesn't actually have any addresses devoted to other purposes. >> What do you gain from all this extra complexity that you don't get = from >> DNSSEC? >=20 > I see DNSSEC being orthogonal since it is not about specifying which = IP address to use as the source address, or whether or not to process = the incoming DNS messages. But the whole point of his crypto-munging of the source address is to = confirm that the reply is associated with an actual pending request and = to make it difficult to guess the right address to send a forged reply = to. Since DNSSEC eliminates the possibility of a forged reply, I don't = see a benefit to all the introduced complexity. Owen >=20 >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com] >> Sent: Tuesday, May 21, 2013 3:29 PM >> To: Erik Kline >> Cc: Rajiv Asati (rajiva); v6ops@ietf.org >> Subject: Re: [v6ops] DNSv6 Proxy ! >>=20 >>=20 >> On May 21, 2013, at 7:39 AM, Erik Kline wrote: >>=20 >>>> Should it use the IPv6 address assigned to its WAN interface (which >>>> is to be used for CPE management, really) via DHCPv6 IA_NA or = SLAAC, >>>> or the address assigned to its LAN interface via DHCPv6 PD ? >>>=20 >>> If I were implementing one, I would do the following: >>>=20 >>> [1] reserve one /64 from the PD for internal use by the resolver >>>=20 >>=20 >> The problem with this approach is that you are assuming that the = provider >> always grants at least n+1 /64s in the PD where n is the number of = subnets >> needed on the client side. >>=20 >> Given that some ISPs are so misguided as to dole out /60s (or even = less), I >> don't think you can take that for granted. >>=20 >>> [2] the DNS proxy would maintain a small set of keys, rotating >>> periodically >>>=20 >>> [3] when generating/forwarding a request, take an >>> HMAC(Key_current, "normalized query parameters") >>>=20 >>> [4] extract 64bits from a consistent portion of the HMAC, and use >>> that as the lower 64 if the upstream request >>>=20 >>> [5] when a response arrives, compute: >>>=20 >>> (a) HMAC(Key_current, "normalized query parameters"), = and >>> (b) HMAC(Key_previous, "normalized query parameters") >>>=20 >>> and verify that the destination address (that reaches the = dns >>> proxy in the CPE) matches the reserved prefix in [1] plus the >>> consistently extracted 64bits from either [5a] or [5b]. >>>=20 >>> You could even pull 16 more bits from the HMAC to use as the source >>> port of the query (and hence destination port of the reponse) and >>> validate that as well. >>=20 >> What do you gain from all this extra complexity that you don't get = from >> DNSSEC? >>=20 >> Owen From bs7652@att.com Wed May 22 12:11:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDEE11E80FB for ; Wed, 22 May 2013 12:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaXy09Zu0DHZ for ; Wed, 22 May 2013 12:11:43 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id B478611E812E for ; Wed, 22 May 2013 12:11:43 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id f681d915.2aab03c65940.259152.00-500.734567.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 22 May 2013 19:11:43 +0000 (UTC) X-MXL-Hash: 519d186f50b1a6a8-66d0af9dfa778efda0f82c63690fd9a102df8d3a Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e681d915.0.259139.00-173.734533.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 22 May 2013 19:11:43 +0000 (UTC) X-MXL-Hash: 519d186f3fadb0ff-057dcc996b12c302c44eaafccbc04c42462a6058 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4MJBgYs004763; Wed, 22 May 2013 15:11:42 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4MJBX7R004658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 May 2013 15:11:38 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 22 May 2013 19:11:19 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Wed, 22 May 2013 15:11:18 -0400 From: "STARK, BARBARA H" To: "Rajiv Asati (rajiva)" , Owen DeLong Thread-Topic: [v6ops] DNSv6 Proxy ! Thread-Index: Ac5XIB0lWumo6T4vR7GSS3bZhtkY4g== Date: Wed, 22 May 2013 19:11:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302C72FE@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=IvuphsDg c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=FGV4xj8q1lcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=NgxfmeI1H] X-AnalysisOut: [pAA:10 a=48vgC7mUAAAA:8 a=qgk8bVh7SWmb9_MIBegA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=09VoiNMWIAlq1/rT4SmQvWluioQ=:19 a=6mxoKjchuuffW] X-AnalysisOut: [AUx:21 a=sKY0w2f8nsa4PhsS:21] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 19:11:49 -0000 > First, it is important to specify the DNSv6 behavior in the rfc6204bis dr= aft. [This is wrt specifying which address the CE router chooses to use to origi= nate DNSv6 messages to some DNS server out in the great wide WAN.] I disagree. But clearly, I haven't done a good job at explaining why, so le= t me try again. First of all, let me start by making sure we're all working from the same, = most recent draft, and not the several-year-old version the original email = of this thread provided a link to. Please refer to: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis=20 Please particularly note: "G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node Requ= irements [RFC6434] specification." My basic premise is that the access provider who wants to allow a generic, = unidentified 6204/6204bis CE router to get IPv6 connectivity from their acc= ess network cannot assume that they know what IPv6 address the CE router wi= ll use to source any particular message to "Internet" destinations. If this= access provider throws half a dozen IA_NA addresses, multiple IA_PD, and s= everal A=3D1 prefixes in RA messages at this CE router, with all marked as = "preferred" and "valid" with no "more specific routes", then that access pr= ovider cannot expect to have any knowledge of what IP address the CE router= will use to source messages to DNS servers, NTP servers, or most anything = else. Even if the access network provides just one IA_NA and one /56 IA_PD = (for example), the access provider cannot expect to have knowledge of what = IP address the CE router will use as a source address for any particular me= ssage. This CE router may be provided by an enterprise for work-at-home and= have all sorts of special stuff in it (special DNS server, enterprise-spec= ified management interface, etc.). The access provider has no clue about an= y special behavior of the CE router.=20 If an ISP tells its users that a generic 6204bis-compliant CE router (IPv6 = Ready) can be used to connect through it to the Internet, that ISP is impli= citly saying that any "preferred" and "valid" A=3D1 RA prefixes, IA_NA addr= esses, and IA_PD prefixes that the access network supplies and that don't h= ave "more specific routes" associated with them, will connect to the Intern= et. If this isn't true, then the ISP has no business telling their users th= at generic CE routers (off-the-shelf D-Link, Belkin, Linksys, etc.) will wo= rk on the ISP's network. If the ISP wants to care whether the CE router uses an IA_NA address vs an = address from the IA_PD for connecting to DNS, NTP, SIP, Dynamic DNS, or any= thing else out on the Internet, then 6204 and 6204bis (as currently written= ) CE routers cannot be expected to work on that ISP's network. If there is = some huge ISP (or group of ISPs) who wants to care what address is selected= and knows exactly what it is they need and want, then let that ISP come fo= rward and say so. And say exactly what they want and why they need to be sp= ecial and why they need IETF RFCs with requirements written just for their = network. [Note the work being done in v6ops to specify what 3GPP devices ne= ed to do -- this is an example of a set of ISPs who made the case for speci= al requirements; RFC 6204 could also be considered such a case, since it wa= s written to describe devices that could connect to either CableLabs-define= d or BBF-defined access networks; other ISPs have chosen to provide additiv= e-to-RFC6204 requirements external to IETF, such as CableLabs eRouter specs= , BBF TR-124 Issue 3, and RFPs issued by ISPs -- but they do not expect the= generic CE router vendors of the world to follow these more specific requi= rements which were written more for devices procured by ISPs.]=20 I truly do not care whether the 6204bis-defined CE router that has an IA_NA= (preferred and valid) address and IA_PD (preferred and valid) uses one or = the other of these to source DNS queries (or NTP, or connect to a SIP serve= r, or Dynamic DNS, or...). If an ISP wants to supply preferred and valid IA= _NA addresses to a generic CE router bought off the shelf at a local electr= onics store, and then not allow that IA_NA address to be used to query a DN= S server... well, I do not support such an ISP's attempts to add complexity= to these off-the-shelf devices by trying to give that IA_NA special meanin= g specific only to that ISP's network.=20 Again, I disagree that any language needs to be added to 6204bis to force s= ource address selection.=20 Barbara From phdgang@gmail.com Wed May 22 23:29:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673EE11E8191 for ; Wed, 22 May 2013 23:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcI41IT3GNB4 for ; Wed, 22 May 2013 23:29:29 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A911E8193 for ; Wed, 22 May 2013 23:29:29 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id j11so1446833qag.8 for ; Wed, 22 May 2013 23:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bTC9QxS98C0cqc+Xw4dYXuOnLOjSORbj+QpsBhAF7FE=; b=y7fTzd/DCp2CRDXwzJl4dvBPy5Y/HaYgwbLEJ19VI7XUTndpdb0U3AEz5h2o7qJ/j5 OIDWWtvp/WNpdw1IdZAtoQSMmvZjU6l0fEApUqyKwk6/R87PtNfE3nQPGzxs6Bk1eECG 3stsJ5hpGtRTLSW9DBFGFHyp4pRmkMDjZXYZcOEb/0iQ4QEd4ckPcXUYBuEHqOwL28p8 KUXlwVIQi+Rt5Qq9XJHcW/yfjw/Y8fd4QgNbaFkOEL1XI82+l7T1el45sI9wDbFhZtoM 1X+ipzk0kIele5ZcsH9xsiwPiZ2sOg19uNfQi6jL8HoSD3umkUUMZfjWGlUvCCUomER7 uJ7g== MIME-Version: 1.0 X-Received: by 10.229.165.144 with SMTP id i16mr3795526qcy.156.1369290569016; Wed, 22 May 2013 23:29:29 -0700 (PDT) Received: by 10.49.94.39 with HTTP; Wed, 22 May 2013 23:29:28 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B8EE5DB@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B8EE5DB@xmb-rcd-x09.cisco.com> Date: Thu, 23 May 2013 14:29:28 +0800 Message-ID: From: GangChen To: "Fred Baker (fred)" , "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 06:29:30 -0000 wg, The draft contains useful discussions to help shaping IPv6 profile on mobile phone. I support WGLC. The below comments are only for discussion/consult/clarification. 1) section 2.2 Neighbor Discovery Once we discuss NS/NA, I'm struggling with the usage of those two messages. The draft has very good description about notes on point-to-point interface. The texts teach me that neighbor discovery and NUD may be unnecessary, beacause the mobile phone doesn't rely on NS/NA to discover neighbor and NUD is desirable to be achieved through uppper layer guarantee. In some degree, audience may have impressions mobile phones can eliminate NS/NA to reduce additional signalling. I'm not sure if we could give those recommendations. Otherwise, it maybe helpful if the draft can clarify the usages of NS/NA to a mobile phone. In regard to NUD using upper layer protocol, I have observed some apps normally do keepalive/beacon message to fresh the link. Could those messages be a tool to maintain NUD? 2) I guess both section 2.3 and 2.4 cover SLACC. Reading the contents, I feel section 2.4 seems a sub-section of 2.3. It may be good to assign a proper section number. In section 2.4, there is texts "as each delegated prefix is unique". May I suggest to reword "delegated" to "advertised/configured/assigned" to avoid the ambiguity with DHCP-PD 3) section 2.5 It described the case of split mobile station. I guess it may help if the draft adds a example for MT. USB dongle can be a MT.You may add "(MT, e.g., a USB dongle)", like you did for TE. That also reminds me "a mobile phone handset" used in the section of Abbreviations. Should it be proper to use a USB dongle for the example. A mobile phone handset seems like a mobile station, which is comprised of MT and TE. 4)section 2.7 If i remember coorectly, 3GPP label Privacy Extensions as the level of "MAY". This section use "should" and "may" in the same paragraph. I guess we may could align the statement(even that not have normative meaning) 5)section 2.10 One typo maybe there. "me" should be corrected. These options me be useful for cellular ^^ 6)section 2.11 DNS server address can also be provisioned through PCO option. Should it be mentioned in this section? Best Regards Gang 2013/5/20, Fred Baker (fred) : > The working group last call for this draft-ietf-v6ops-rfc3316bis announced > last week continues for another week. Please feel free to comment on it. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jouni.nospam@gmail.com Thu May 23 00:15:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5818011E81A6 for ; Thu, 23 May 2013 00:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqTCd1yey3c5 for ; Thu, 23 May 2013 00:15:51 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id A79F711E81A1 for ; Thu, 23 May 2013 00:15:49 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id c50so1577059eek.1 for ; Thu, 23 May 2013 00:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=57xZm44TDP9Ec3HxvqTOf02HzuthSblE/DnUB0hpB3w=; b=c1m03mvrGd+XVUtzgpWG9KdUh7kHEPI9EhZSI7iiojXn/iN6FFjP2bJeaAz1TUK9T6 rq27PH8yYH26T7aXsKPq3n+NNi2ys4JVJ4GkFDX3chgzLsyPC5mHBG+zSCA25Y2kcVXR jxNhGhxjBOfIRtBhrcH/ZDb75mr+KycrFIBKH0X6+d6LJ+jmlNuU6WbQhG0JsrO6UtZt wJPy75peLguqO1O7cT0TXc6kCrjHrpo9J7wh/nEuto4qpTN2r4/s/XsENR8rhsS1MJRR 9NYBuidLpZq/Is7IPAoHL/Vy64ZDzcma1sZKW3WuYUtOkRdRpjilkOf6KNZ7xYLqfZmR FCvA== X-Received: by 10.14.95.4 with SMTP id o4mr23837699eef.2.1369293348550; Thu, 23 May 2013 00:15:48 -0700 (PDT) Received: from [192.168.1.169] (hd5b9120a.seluldx.sta.perspektivbredband.net. [213.185.18.10]) by mx.google.com with ESMTPSA id x41sm14836692eey.17.2013.05.23.00.15.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 00:15:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Jouni Korhonen In-Reply-To: Date: Thu, 23 May 2013 10:15:45 +0300 Content-Transfer-Encoding: 7bit Message-Id: <0E843E14-A844-4B87-8965-816CB963331A@gmail.com> References: <8C48B86A895913448548E6D15DA7553B8EE5DB@xmb-rcd-x09.cisco.com> To: GangChen X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 07:15:56 -0000 Hi Gang, Thanks for the review. See my initial comments inline. On May 23, 2013, at 9:29 AM, GangChen wrote: > wg, > > The draft contains useful discussions to help shaping IPv6 profile on > mobile phone. I support WGLC. The below comments are only for > discussion/consult/clarification. > > 1) section 2.2 Neighbor Discovery > > Once we discuss NS/NA, I'm struggling with the usage of those two > messages. The draft has very good description about notes on > point-to-point interface. The texts teach me that neighbor discovery > and NUD may be unnecessary, beacause the mobile phone doesn't rely on > NS/NA to discover neighbor and NUD is desirable to be achieved through > uppper layer guarantee. In some degree, audience may have impressions > mobile phones can eliminate NS/NA to reduce additional signalling. I'm > not sure if we could give those recommendations. Otherwise, it maybe > helpful if the draft can clarify the usages of NS/NA to a mobile > phone. So you want even more NS/NA text? What else needs to be added? So far we got the following: o no address resolution.. due no link-layer addresses o cellular host must support NUD (which then includes both upper layer mechanisms and the unicast NS/NA one) o DAD is not needed (and can be turned off using RFC4861 configuration mechanisms) but causes no harm either if done. You can skip periodic unicast NS/NA NUD whenever you get the reachability confirmation from the upper layers. I do not see how this leads to possible elimination of NS/NA? > In regard to NUD using upper layer protocol, I have observed some apps > normally do keepalive/beacon message to fresh the link. Could those > messages be a tool to maintain NUD? Yes.. assuming the upper layer traffic is there all the time and bidirectional. That does not justify removal of explicit NUD using unicast NS/NA. > 2) I guess both section 2.3 and 2.4 cover SLACC. Reading the contents, > I feel section 2.4 seems a sub-section of 2.3. It may be good to > assign a proper section number. Ok. I'll give this a though. > In section 2.4, there is texts "as each delegated prefix is unique". > May I suggest to reword "delegated" to > "advertised/configured/assigned" to avoid the ambiguity with DHCP-PD Right. This was already agreed after Ales' review. > 3) section 2.5 > It described the case of split mobile station. I guess it may help if > the draft adds a example for MT. USB dongle can be a MT.You may add > "(MT, e.g., a USB dongle)", like you did for TE. That also reminds me > "a mobile phone handset" used in the section of Abbreviations. Should > it be proper to use a USB dongle for the example. A mobile phone > handset seems like a mobile station, which is comprised of MT and TE. Ok. I'll draft something around this. > > 4)section 2.7 > > If i remember coorectly, 3GPP label Privacy Extensions as the level of > "MAY". This section use "should" and "may" in the same paragraph. I > guess we may could align the statement(even that not have normative > meaning) Right. 3GPP has both "may" and "can" for privacy extensions, depending on the specification (i.e. 23401 say may use mechanism defined in 23221, which then says can use rfc4941). OK to lower the requirement language here. > 5)section 2.10 > > One typo maybe there. "me" should be corrected. > > These options me be useful for cellular > ^^ Ack. > 6)section 2.11 > > DNS server address can also be provisioned through PCO option. Should > it be mentioned in this section? We say that the host may learn the DNS server address by lower layer means.. the IP stack has no idea of PCOs and we have on purpose kept the term PCO out of the document. Thanks. - Jouni > > Best Regards > > Gang > > > 2013/5/20, Fred Baker (fred) : >> The working group last call for this draft-ietf-v6ops-rfc3316bis announced >> last week continues for another week. Please feel free to comment on it. >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Thu May 23 01:10:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489F321F955C for ; Thu, 23 May 2013 01:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ltBAEonatcb for ; Thu, 23 May 2013 01:10:15 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 995B021F8C20 for ; Thu, 23 May 2013 01:10:05 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so1728980qeb.3 for ; Thu, 23 May 2013 01:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jjgpI+SsVKzXqPkXkaYY0uJcXiG4+80uNvKmoT3ZNVY=; b=tFG6KvC9xZUf5mxZw3m097JPv201lL6Qby+doyiSZUN2HPPR0us9UcVA33/GKBfIYq CsdZMj0v5K9gGgPUeNqKi6bI5b3Be1J0D4HuyTPJemeetFNdc7/ySNLK51YlDqsTPhDg XMtkLIHXK7r+Alb37NKLVmmlH5QlDVJ3N5xwFZ9aiw87X//YPvW3OlfR/wge/JmgFfvB VI1GBbN+kUhUufrkHLoRUIHtQtagN+fpAEzFHkc7Z52r+9Ro8zOViQZ3nyQEiHt7JfLo 7Hx9XNPX9pFZEoZURCbZ/oJ6FelM8lEg954H/u+GXrPUoBdfX4l236qowhFsau6hDgl4 pi6Q== MIME-Version: 1.0 X-Received: by 10.49.98.198 with SMTP id ek6mr10414168qeb.23.1369296605019; Thu, 23 May 2013 01:10:05 -0700 (PDT) Received: by 10.49.94.39 with HTTP; Thu, 23 May 2013 01:10:04 -0700 (PDT) In-Reply-To: <0E843E14-A844-4B87-8965-816CB963331A@gmail.com> References: <8C48B86A895913448548E6D15DA7553B8EE5DB@xmb-rcd-x09.cisco.com> <0E843E14-A844-4B87-8965-816CB963331A@gmail.com> Date: Thu, 23 May 2013 16:10:04 +0800 Message-ID: From: GangChen To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 08:10:21 -0000 2013/5/23, Jouni Korhonen : > > Hi Gang, > > Thanks for the review. See my initial comments inline. > > On May 23, 2013, at 9:29 AM, GangChen wrote: > >> wg, >> >> The draft contains useful discussions to help shaping IPv6 profile on >> mobile phone. I support WGLC. The below comments are only for >> discussion/consult/clarification. >> >> 1) section 2.2 Neighbor Discovery >> >> Once we discuss NS/NA, I'm struggling with the usage of those two >> messages. The draft has very good description about notes on >> point-to-point interface. The texts teach me that neighbor discovery >> and NUD may be unnecessary, beacause the mobile phone doesn't rely on >> NS/NA to discover neighbor and NUD is desirable to be achieved through >> uppper layer guarantee. In some degree, audience may have impressions >> mobile phones can eliminate NS/NA to reduce additional signalling. I'm >> not sure if we could give those recommendations. Otherwise, it maybe >> helpful if the draft can clarify the usages of NS/NA to a mobile >> phone. > > So you want even more NS/NA text? What else needs to be added? So far we > got the following: > > o no address resolution.. due no link-layer addresses > o cellular host must support NUD (which then includes both > upper layer mechanisms and the unicast NS/NA one) > o DAD is not needed (and can be turned off using RFC4861 configuration > mechanisms) but causes no harm either if done. > > You can skip periodic unicast NS/NA NUD whenever you get the reachability > confirmation from the upper layers. I do not see how this leads to possible > elimination of NS/NA? I don't see the necessity to eliminate NS/NS messages as well. Whereas, it may desirable to mitigate the messages transmission on the air. The draft may clarify: 1. no address resolution(already in the section) 2. no DAD(shift the texts to the section) 3. restrain periodic NUD if there is upper-layer indication available (clarify the point in the section) BRs Gang >> In regard to NUD using upper layer protocol, I have observed some apps >> normally do keepalive/beacon message to fresh the link. Could those >> messages be a tool to maintain NUD? > > Yes.. assuming the upper layer traffic is there all the time and > bidirectional. That does not justify removal of explicit NUD using > unicast NS/NA. > >> 2) I guess both section 2.3 and 2.4 cover SLACC. Reading the contents, >> I feel section 2.4 seems a sub-section of 2.3. It may be good to >> assign a proper section number. > > Ok. I'll give this a though. > >> In section 2.4, there is texts "as each delegated prefix is unique". >> May I suggest to reword "delegated" to >> "advertised/configured/assigned" to avoid the ambiguity with DHCP-PD > > Right. This was already agreed after Ales' review. > >> 3) section 2.5 >> It described the case of split mobile station. I guess it may help if >> the draft adds a example for MT. USB dongle can be a MT.You may add >> "(MT, e.g., a USB dongle)", like you did for TE. That also reminds me >> "a mobile phone handset" used in the section of Abbreviations. Should >> it be proper to use a USB dongle for the example. A mobile phone >> handset seems like a mobile station, which is comprised of MT and TE. > > Ok. I'll draft something around this. > >> >> 4)section 2.7 >> >> If i remember coorectly, 3GPP label Privacy Extensions as the level of >> "MAY". This section use "should" and "may" in the same paragraph. I >> guess we may could align the statement(even that not have normative >> meaning) > > Right. 3GPP has both "may" and "can" for privacy extensions, depending > on the specification (i.e. 23401 say may use mechanism defined in 23221, > which then says can use rfc4941). OK to lower the requirement language > here. > >> 5)section 2.10 >> >> One typo maybe there. "me" should be corrected. >> >> These options me be useful for cellular >> ^^ > > Ack. > >> 6)section 2.11 >> >> DNS server address can also be provisioned through PCO option. Should >> it be mentioned in this section? > > We say that the host may learn the DNS server address by lower layer > means.. the IP stack has no idea of PCOs and we have on purpose kept > the term PCO out of the document. > > Thanks. > > - Jouni > > > >> >> Best Regards >> >> Gang >> >> >> 2013/5/20, Fred Baker (fred) : >>> The working group last call for this draft-ietf-v6ops-rfc3316bis >>> announced >>> last week continues for another week. Please feel free to comment on it. >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From bs7652@att.com Thu May 23 05:23:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405F721F91A0 for ; Thu, 23 May 2013 05:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG858JJ1cZ1k for ; Thu, 23 May 2013 05:23:10 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6521F9104 for ; Thu, 23 May 2013 05:23:10 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id e2a0e915.5e541940.70717.00-585.189218.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 23 May 2013 12:23:10 +0000 (UTC) X-MXL-Hash: 519e0a2e0cc9d7be-6e65cb4714f4dbc581d6bf1e0eea5a3e1343249c Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id d2a0e915.0.70715.00-485.189204.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 23 May 2013 12:23:09 +0000 (UTC) X-MXL-Hash: 519e0a2d482ac14d-b44af27a2277688d2e541e5d80a0aed9f369cb1d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4NCN8Dd012396; Thu, 23 May 2013 08:23:09 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4NCN4YI012346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 08:23:06 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 23 May 2013 12:22:47 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0342.003; Thu, 23 May 2013 08:22:48 -0400 From: "STARK, BARBARA H" To: "Rajiv Asati (rajiva)" , "v6ops@ietf.org" Thread-Topic: DNSv6 Proxy ! - the other "nit" Thread-Index: Ac5XsDvIQRcMA7k8SeKgjWFboRkLZQ== Date: Thu, 23 May 2013 12:22:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302C77E6@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.223.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=QO3fsH3L c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=M98xKWB5TfEA:10 a=pALKn4IXnOAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=yCneS-kRcFUA:10 a=48vgC7mUAAAA:8 a=wALUtABZd7pI-A] X-AnalysisOut: [hiiRcA:9 a=CjuIK1q_8ugA:10] Subject: Re: [v6ops] DNSv6 Proxy ! - the other "nit" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:23:16 -0000 > PS: Just noticed a nit in the section 5.1, btw: >=20 > //If the service provider specifies one > or more DNS resolvers in DHCP configuration options, the CE router SHOULD > forward all non-local DNS queries unchanged to those servers. I am not finding this in the most recent version of the 6204bis draft. http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-12 Barbara From rajiva@cisco.com Thu May 23 07:04:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B221F95D7 for ; Thu, 23 May 2013 07:04:00 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zni-xURm+2OL for ; Thu, 23 May 2013 07:03:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F40821F9497 for ; Thu, 23 May 2013 07:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=728; q=dns/txt; s=iport; t=1369317835; x=1370527435; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6A5IAUb8AzA2Troala6emTEolLuAOO+4pW2FV2+GSrQ=; b=FjfWXxmLbupPfzqw/AFI7ECzH+YoiKFThN6keNJKVrhMBidFO0nGGZcS I0+QSna3609zEbPunoZk2mxeY6VMGAJw++gVYbVxvqV8ynZQIPnF2fvJx H+EtPU3QVP1iksly3tmMHlA/LwurG4G+9GsCM5CaiBSNBEKoHzI+kfxHt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0FALggnlGtJV2Z/2dsb2JhbABagwgwgnS/N4EJFnSCIwEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgBAQQBEgiIBQy6VI5sOAaCbWEDmGGQF4MPgiY X-IronPort-AV: E=Sophos;i="4.87,728,1363132800"; d="scan'208";a="213928571" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 23 May 2013 14:03:55 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4NE3sXs002786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 14:03:54 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 23 May 2013 09:03:54 -0500 From: "Rajiv Asati (rajiva)" To: "STARK, BARBARA H" , "v6ops@ietf.org" Thread-Topic: DNSv6 Proxy ! - the other "nit" Thread-Index: Ac5XsDvIQRcMA7k8SeKgjWFboRkLZQADgq8Q Date: Thu, 23 May 2013 14:03:54 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302C77E6@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302C77E6@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.233.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] DNSv6 Proxy ! - the other "nit" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 14:04:00 -0000 Hi Barbara, You are right. I was looking at an ancient version of the document. Cheers, Rajiv > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Thursday, May 23, 2013 8:23 AM > To: Rajiv Asati (rajiva); v6ops@ietf.org > Subject: RE: DNSv6 Proxy ! - the other "nit" >=20 > > PS: Just noticed a nit in the section 5.1, btw: > > > > //If the service provider specifies one or more DNS resolvers in DHCP > > configuration options, the CE router SHOULD forward all non-local DNS > > queries unchanged to those servers. >=20 > I am not finding this in the most recent version of the 6204bis draft. > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-12 >=20 > Barbara From markzzzsmith@yahoo.com.au Thu May 23 14:56:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A309321F9875 for ; Thu, 23 May 2013 14:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcJx0NyeUzZQ for ; Thu, 23 May 2013 14:56:05 -0700 (PDT) Received: from nm26.bullet.mail.bf1.yahoo.com (nm26.bullet.mail.bf1.yahoo.com [98.139.212.185]) by ietfa.amsl.com (Postfix) with ESMTP id F147E21F976C for ; Thu, 23 May 2013 14:08:36 -0700 (PDT) Received: from [98.139.215.140] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 23 May 2013 21:08:36 -0000 Received: from [98.139.215.230] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 23 May 2013 21:08:36 -0000 Received: from [127.0.0.1] by omp1070.mail.bf1.yahoo.com with NNFMP; 23 May 2013 21:08:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 374304.64772.bm@omp1070.mail.bf1.yahoo.com Received: (qmail 76141 invoked by uid 60001); 23 May 2013 21:08:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369343316; bh=BBj0/kbN4GjCLTUAZ/Mn5oVKNluoGukOl02YNo6aN9g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tNuOZnfXthjGI80reTwceBPfhqKLkFrcHx0jus4tdKGktb3uX151K2xwEuClXz2wV5kYDGXzKAtzE3zudZYWwsXJ18vHjbrd7tH+Pu+fUvakX6UE0G1iez+LVNWGmDCc8Rt1TaJSQnQ7Wf2pPrtqYNt5aRIgOfGpcc2r27Tzk38= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s5xSBDYBAFgSbRZKgvkaajqt0u6UMjySGDSYuAAo93Hw5BYRA7EDHqBcgTiQx/di6AWwNdG3sBjsRfNy7WPq58HtkQPLAHoG4xZM+fJyPUOJTqJSSMRHwygsNa7Ri/LHqtK/76MyXFrsn8gxE15RbyH1YH2tgaI3I+paiIXXj0Y=; X-YMail-OSG: TUpf7N4VM1kcmXls4NSZMIW7jaV2TMTvVFsDV68hlXdUPr. raEGBfR4PBhnfER1kHKwbhclb987Ldy4TKykZlKzC.M7dsolK.A_d6uXBp4m 3RtAUTAilyV5GEn4Ojcye370kTPCfw1b.Bo5p7yrgnrksI6M9uY9pfjv74ds KJNS2dhMYJk7TVkQt7zPNhG68nuTxH8NjNHDYdkC8LaT0KqvtUMvLEC3HwJC WKk0Ki4LKNXbRVbt4xEbQtv7TfZBipdesx7VsnEIm6h1ZmvBxjex7S5qsQ0h OaLvEWg7fsgtxSy2sPjAkBvBX.TNHhNAnHzgmlCn0JrRuJqv082UHbKLFxt9 0oQF_GeVgkJCsIluu.H.5pmIPf7vhuTBf0.rPdxjdIx.3Unavpx_Syl8OcW3 XBF5I6_c2ayj_A88mFOQsVZiyx.dhNa2HscxR4UOMXJkfp9B.4gcfwEJMPDM bDOo8S4Yte1MUpMk2PzpA2o22i7KjqXibvAU7AxlTppCZhpHspGjbYzRfDe3 sKzKlvdYp2ytbZtcobjy7ihdg6S19rwV.CyGr0kAabg-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Thu, 23 May 2013 14:08:36 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKU3VnZ2VzdGVkIGNoYW5nZXM6CgoKCjEuIEludHJvZHVjdGlvbgoKIi4uLiBmb3IgZGVsZWdhdGluZyBJUHY2IHByZWZpeGVzIHRvIGEgTEFOLiIKCgp0byAKCiIiLi4uIGZvciBkZWxlZ2F0aW5nIElQdjYgcHJlZml4ZXMgdG8gYSBzaW5nbGUgTEFOIGludGVyZmFjZS4iCgpHZW5lcmFsbHkgSSB0aGluayB0aGlzIGludHJvIHRleHQgc2hvdWxkIG1ha2UgaXQgYSBiaXQgY2xlYXJlciB0aGF0IHRoZXNlIG1ldGhvZHMgYXJlIG9ubHkgZXh0ZW5kaW5nIHRoZSAvNjQgdG8gYSBzaW5nbGUgTEFOIGludGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> Message-ID: <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 23 May 2013 14:08:36 -0700 (PDT) From: Mark Smith To: "cb.list6" , "draft-ietf-v6ops-64share@tools.ietf.org" , "v6ops@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:56:20 -0000 Hi,=0A=0A=0ASuggested changes:=0A=0A=0A=0A1. Introduction=0A=0A"... for del= egating IPv6 prefixes to a LAN."=0A=0A=0Ato =0A=0A""... for delegating IPv6= prefixes to a single LAN interface."=0A=0AGenerally I think this intro tex= t should make it a bit clearer that these methods are only extending the /6= 4 to a single LAN interface.=0A=0A=0A3.1 Scenario 1: No Global Address on t= he UE=0A=0A"traffic destine"=0A=0A=0A- missing "d" on destined.=0A=0A=0A"th= e UE (e.g. DNS caching that requires global connectivity) and prevent prope= r Path MTU Discovery [RFC1981] to occur on the UE providing an IPv6 router = function."=0A=0A=0ARegarding breaking PMTUD, I wonder if it might be worth = requiring that the MTU of the LAN interface is made the same as that of the= 3GPP interface, and if it isn't the default for the LAN interface (i.e., 1= 500 for ethernet), then the LAN interface RAs have the MTU option set to th= e size of the 3GPP interface. I think that would prevent the UE needing to = participate in PMTUD.=0A=0A=0A"The UE copies the prefix 2001:db8:ac10:f002:= :/64 from the 3GPP interface to the LAN interface,"=0A=0A=0AI think it woul= d be clearer if this text specified that this copying of the /64 prefix was= indicating the prefix was on-link, by adding the prefix to the Prefix List= , as per RFC5942, "IPv6 Subnet Model: The Relationship between Links and Su= bnet Prefixes"=0A=0A=0A3.2 Scenario 2: Global Address Only Assigned to LAN= =0A=0A"The movement of the IPv6 prefix from the 3GPP radio interface to the= LAN interface may result in long-lived data connections being terminated d= uring the transition from a host-only mode to router-and-host mode."=0A=0A= =0AI'd suggest adding something like:=0A=0A"Connections which are likely to= be effected are ones that have been specifically bound to the 3GPP radio i= nterface."=0A=0A=0A3.3 Scenario 3: A Single Global Address Assigned to 3GPP= Radio and LAN Interface=0A=0A=0A=0A"This method also creates complications= for ensuring uniqueness for Privacy Extensions [RFC4941]. Privacy Extensi= ons should be disabled on the 3GPP radio interface while this method is ena= bled."=0A=0A=0AI think it would be better to advise that when privacy exten= sions are in use, a single privacy address is generated, and then used as t= he anycast address on both interfaces, and the preferred and valid lifetime= s are synchronised, such that the anycast addresses on both interfaces expi= res at the exact same moment.=0A=0AHmm, actually, there might be another mo= re broader issue to consider (broader than this specific scenario), regardi= ng preferred and valid lifetimes of the /64. What preferred and valid lifet= imes are supplied in the RAs by the 3G network, and should they be copied t= o the LAN interface RAs? Another issue related to this is the synchronised = aging of the prefix on the 3GPP and LAN interfaces. In the case of DHCPv6 P= D, the preferred and valid lifetimes announced in the LAN RAs are to be syn= chronised with the aging of the DHCPv6-PD prefix, so that when the PD prefi= x expires, the addresses on the hosts on the LAN expire at the same time.= =0A=0A=0AHTH,=0AMark. From ek@google.com Thu May 23 19:15:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB321F90AC for ; Thu, 23 May 2013 19:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8tWUOnyCBlk for ; Thu, 23 May 2013 19:15:35 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E173721F8F20 for ; Thu, 23 May 2013 19:15:34 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id ef5so4880776obb.2 for ; Thu, 23 May 2013 19:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=fsldp+oTH1Tant44lKxZJ8MwB7MxiLysyhfDtJOox8k=; b=cTcxhQOqxRyoUcnIPzZJqbcu+WXSuCCivCOhBQACrdqfP4kOgbtdBfWqf5g6Q6KE4X 8Zaw0LOfUoNReZSSP+ND4lKuyqCCrwMJbgPpS9Cy+5OY9D/PdPr5Q2xPbtE2M4mHmZKk 2oAzSuR1u6c1VLg3oKDA9R+/1xoaoDh1VyThKw1azq/vg9NHaF7uFuAvTvBtnKd9onnk iEXw+TQtrNepOs7PWY9mcvW9kp1t0snQs5oJ4dCJLgEdiLRFc97g6/euNVDyjKuMIGlW Pf7gMkoA8VLlu5m2LYThK+PLwbYNscD2PqQveewPqTakJMowRHeMJuLWtHUovHTf1/TQ Xaow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fsldp+oTH1Tant44lKxZJ8MwB7MxiLysyhfDtJOox8k=; b=h+BuyUMfptVVLzSIq4XkKCcJNtc4hAUjYEOhKZXzsvRfck3wUa0N9CfMxLV+URlHgS CaA5Nv+nfphAAPVBM7M3KJ/AczGgha79v8RW7NE7E0R38ChgJfoK8EDLWKmz7JM4+lXx e/NhNKBI83PHCJWsz6KgWLR2C0j+2owu8pQZcUPMbZOwLqPty6Jt/J3+ebqoK/F/aIUK prmBKyFm+zoTt8DywoT5v6t712DPlH/wBGffb2ztuI8IR103+DxhgPXvlugX5BIkLdOd OrZeGm6DxR+QFpse2dfDeasMLe0BYxwp+piwuyPU8Z8PNp/m5Up3kh2YZsyGBhjeKvC5 KVXA== X-Received: by 10.182.102.234 with SMTP id fr10mr10144912obb.85.1369361734204; Thu, 23 May 2013 19:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.44.169 with HTTP; Thu, 23 May 2013 19:15:13 -0700 (PDT) In-Reply-To: <39EB9868-F5E5-4FE9-B8B9-9A8D52EA8B5F@delong.com> References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> <39EB9868-F5E5-4FE9-B8B9-9A8D52EA8B5F@delong.com> From: Erik Kline Date: Fri, 24 May 2013 11:15:13 +0900 Message-ID: To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkWl1KQRqwHoqBQ180B95PMIqT2Ag64pdDD6JKrOFzC7Cu4leCJqSU889ykIFBaZ0KMhPFnypvb9vbUDsyz0SmW7H7/UA4QgFRkUuqFMvECChdf84CBL5HaYyzLD95sgJtUfNenkhC9Im+SYVvQINbxlfEOlgetVsdS+jaXOEKLA0FMI+pgt5WZCFZ5nQZnqhkeblJB Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 02:15:35 -0000 On 23 May 2013 00:58, Owen DeLong wrote: > > On May 21, 2013, at 6:11 PM, Rajiv Asati (rajiva) wrot= e: > >> I like Erik's proposal, since it would nicely plug the hole that Jared p= ointed out and also provide the source address to be used >> > > It goes well beyond the simplest and ideal solution to the stated problem= =E2=80=A6 > >>> The problem with this approach is that you are assuming that the provid= er >>> always grants at least n+1 /64s in the PD where n is the number of subn= ets >>> needed on the client side. >>> >>> Given that some ISPs are so misguided as to dole out /60s (or even less= ), I >>> don't think you can take that for granted. >> >> I don't see a non-trivial issue with applying Erik's proposal even if /6= 4 was provided as DHCP-PD. After all, the CPE router must have to assign at= least one IP address on its LAN interface. >> > > But it is frequently rotating that address and requires that the entire /= 64 be available for cryptographic hashing of the request in question. It ma= kes no allowance for collision with an address in use for another host. As = such, his proposal requires the dedication of an entire /64 that doesn't ac= tually have any addresses devoted to other purposes. Well in my original thesis you wouldn't want to use a per-request IPv6 address unless you be sure you avoided the DAD penalty. If a CPE had only a single /64, or suspected that it could not allocated a /64 for its own uses and have sufficient left-over space for customer use then I would not recommend trying this scheme. >>> What do you gain from all this extra complexity that you don't get from >>> DNSSEC? >> >> I see DNSSEC being orthogonal since it is not about specifying which IP = address to use as the source address, or whether or not to process the inco= ming DNS messages. > > But the whole point of his crypto-munging of the source address is to con= firm that the reply is associated with an actual pending request and to mak= e it difficult to guess the right address to send a forged reply to. Since = DNSSEC eliminates the possibility of a forged reply, I don't see a benefit = to all the introduced complexity. This statement seems kinda weird to me. You seem to be saying that we don't need source port randomization, or case randomization, or any other mitigation technique against domain hijacking protection ("Kaminsky attack") because, hey, we have DNSSEC. Either I've misread you, or perhaps we really don't need such defensive tactics (I would not claim to be a DNS expert)? My proposal was just that we could add 64bits of more randomness to the 16bits of the port and whatever bits of case-randomization, for resolver self-defense. To me, this is like wearing a seat belt and having side impact cushions and daytime running lights. Of course a resolver could do DNSSEC on behalf of its clients (even when they don't do it themselves). But something like <5% of queries through Google Public DNS are for hostnames/records/zones that have correctly validating DNSSEC set up. Just saying "DNSSEC", to me is like waiting for the rest of the world to learn how to drive safely. (Apologies to Rajiv for distracting from his original point.) From owen@delong.com Thu May 23 23:33:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCF221F92CB for ; Thu, 23 May 2013 23:33:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpz09GOEuWU4 for ; Thu, 23 May 2013 23:33:04 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id F216A21F92C5 for ; Thu, 23 May 2013 23:33:03 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4O6UNtK014203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 May 2013 23:30:23 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4O6UNtK014203 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369377024; bh=4nd3QluaOWicc7nnqBH+gloXDV8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IsTZxe6rQzGgcgWuo/4WN9ihHbnax4vPPYWRbh9YXix6AUxp3n6/hGe2E7DKYL/Hy 6vexebleQZReIjfPx2yWzCF6Lmsgyzkn0UiaMa1/XXLKo3Rz0tzrDjpqGkSsWkhGk4 noKgkDZh177hVXSfbkNkLTf8tv8W8Wj5Oxc6n8p4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: Date: Thu, 23 May 2013 23:30:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55BF669B-A2A6-41C3-B520-D039FF8C8EA2@delong.com> <39EB9868-F5E5-4FE9-B8B9-9A8D52EA8B5F@delong.com> To: Erik Kline X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 23 May 2013 23:30:24 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DNSv6 Proxy ! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 06:33:04 -0000 On May 23, 2013, at 19:15 , Erik Kline wrote: > On 23 May 2013 00:58, Owen DeLong wrote: >>=20 >> On May 21, 2013, at 6:11 PM, Rajiv Asati (rajiva) = wrote: >>=20 >>> I like Erik's proposal, since it would nicely plug the hole that = Jared pointed out and also provide the source address to be used >>>=20 >>=20 >> It goes well beyond the simplest and ideal solution to the stated = problem=85 >>=20 >>>> The problem with this approach is that you are assuming that the = provider >>>> always grants at least n+1 /64s in the PD where n is the number of = subnets >>>> needed on the client side. >>>>=20 >>>> Given that some ISPs are so misguided as to dole out /60s (or even = less), I >>>> don't think you can take that for granted. >>>=20 >>> I don't see a non-trivial issue with applying Erik's proposal even = if /64 was provided as DHCP-PD. After all, the CPE router must have to = assign at least one IP address on its LAN interface. >>>=20 >>=20 >> But it is frequently rotating that address and requires that the = entire /64 be available for cryptographic hashing of the request in = question. It makes no allowance for collision with an address in use for = another host. As such, his proposal requires the dedication of an entire = /64 that doesn't actually have any addresses devoted to other purposes. >=20 > Well in my original thesis you wouldn't want to use a per-request IPv6 > address unless you be sure you avoided the DAD penalty. If a CPE had > only a single /64, or suspected that it could not allocated a /64 for > its own uses and have sufficient left-over space for customer use then > I would not recommend trying this scheme. >=20 Which makes it inappropriate for the draft under discussion which was my = original point. >>>> What do you gain from all this extra complexity that you don't get = from >>>> DNSSEC? >>>=20 >>> I see DNSSEC being orthogonal since it is not about specifying which = IP address to use as the source address, or whether or not to process = the incoming DNS messages. >>=20 >> But the whole point of his crypto-munging of the source address is to = confirm that the reply is associated with an actual pending request and = to make it difficult to guess the right address to send a forged reply = to. Since DNSSEC eliminates the possibility of a forged reply, I don't = see a benefit to all the introduced complexity. >=20 > This statement seems kinda weird to me. You seem to be saying that we > don't need source port randomization, or case randomization, or any > other mitigation technique against domain hijacking protection > ("Kaminsky attack") because, hey, we have DNSSEC. Either I've misread > you, or perhaps we really don't need such defensive tactics (I would > not claim to be a DNS expert)? >=20 If we implement DNSSEC, we don't need those tactics. Correct. > My proposal was just that we could add 64bits of more randomness to > the 16bits of the port and whatever bits of case-randomization, for > resolver self-defense. To me, this is like wearing a seat belt and > having side impact cushions and daytime running lights. DNSSEC is like a seatbelt and airbags. Port randomization is like adding a helmet. Case randomization is akin to a fire suit. Port randomization is a reasonable mitigation. Case randomization has some level of diminishing returns, but it's mostly harmless. Especially in an environment where DNSSEC is implemented. Port and Case randomizations were primarily developed as stop-gaps to get by while DNSSEC awaited broader deployment. Your proposal would, in this particular situation, best be compared to tearing the entire car apart to install a roll cage, active independent suspension, and 5-point harnesses... Just to drive to a short distance to work and back on low-speed lightly travelled streets. In other words, it's way way way beyond the diminishing returns point in my opinion. > Of course a resolver could do DNSSEC on behalf of its clients (even > when they don't do it themselves). But something like <5% of queries > through Google Public DNS are for hostnames/records/zones that have > correctly validating DNSSEC set up. Just saying "DNSSEC", to me is > like waiting for the rest of the world to learn how to drive safely. While there's truth in that, remember, we're talking in the context of an ID that's purporting to be about requirements for residential CPE. In that context, by the time anything in this ID gets deployed into = actual CPE, most likely, DNSSEC will be much more widely deployed. DNSSEC is growing fairly rapidly. However, even without it, your added 64 bits of randomness comes at a cost which vastly exceeds its benefit IMHO. Owen From lorenzo@google.com Fri May 24 02:44:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E58E21F933B for ; Fri, 24 May 2013 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.227 X-Spam-Level: X-Spam-Status: No, score=-101.227 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HaQlKn3X5AY for ; Fri, 24 May 2013 02:44:47 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7B21F9058 for ; Fri, 24 May 2013 02:44:47 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id bs12so2150584qab.5 for ; Fri, 24 May 2013 02:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z+/5D7X0oOjGKAcr6QSdTKoyEsy08NbUx595dCnBaPs=; b=QizkjEzU1Z63Prr1nNw6fRgO1NL9zmGPKJkPPNlwEp1Ud7+XUW+9EbOKLkwxWUwZjX 9AMiZeqKiqywpnhZyeAu49RNAHMHmTot6iKnQXBDbdRlJF5OZwn0C6V7U0M/gqA8INbW G6F0frAILv8Yhj372vZjHKO9MnEzbYnikc6IBr036zj7G5MuqdyKjOZlWTgmeG22Kisf w5fcFX11xHsIhLa/RFPEwTN/St9qy+yQu7G2S8T/Q8a9YWxTLr9rQsglnvpxsUT3WXkX wgZq5++HgLvCa3+burhg8QKoQZXoyKYrXtG8Pi2xD1LVrh111BrhWQMRlxsA38TEl9TI h5AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Z+/5D7X0oOjGKAcr6QSdTKoyEsy08NbUx595dCnBaPs=; b=fuv98t4uR/jN9gvn3J13tPe3S71tZItXAx+vN0fSb+sUgF17zLSY1MOPQARn8xgetm N0gQKQHr4stjKYXQRUODy5sKm1kRJ1jyi+mDCJLu++v81w9BO/poqhuLg+QRvz1K4MI/ MqgeF0Vl93O6Yd7NWXjoXH6umg6aO6WFeLK1WKgpQwMvSx+nQ28+OX5dkRrfiF775eeM I3o8qs9ivVuCeAop51gkUGe19f4kLAEs5W0Wzg2wNHYlbOcF1dP9rb1rtVfGK3Nty2QJ vCDNeQuhwlpmC6W+3KFT2cvbxF9wYCpZ2y2zIDhSEd55Af6Ck4ktrbbdIozr5RI1s2ff w7DA== X-Received: by 10.49.84.42 with SMTP id v10mr17691746qey.60.1369388686529; Fri, 24 May 2013 02:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Fri, 24 May 2013 02:44:26 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Fri, 24 May 2013 18:44:26 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=047d7bb0431638711404dd73a6fa X-Gm-Message-State: ALoCoQkLHMmHb7+xMuowWB2jQRx/7LV8g4gk71J9zkgBmM9KrMDT6AKf+UDuIi7cAv4bD+P/SazIPNma6gzjfj6H/9KZTiA/yMXq3Ildogluz6q6kqDveTqC8xErdSTAu+QA2lkQ65u7Xjjv3vK2vf1YrOtW4zX8WPmHREMnUQsEwCTUWS4VSHE0u6a0tnS0LnvzHYyf7FZy Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:44:48 -0000 --047d7bb0431638711404dd73a6fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) wrot= e: > No, the probability is much higher than you think. See RFC 4193 section > 3.2.3. If I'm reading that section correctly, if you generate 10000 ULAs > you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if > you regenerate them once a second, for one day) you'll get a collision on= ce > in 1000 times. And so on.**** > > [Bing] In theory, I agree with you. But the point here is where do we nee= d > to change the ULA so frequently? For random draw? I can hardly imagine a > use case of that. > This is a technical document meant to provide guidance, so I'd say that it's not appropriate to use vague words like regularly "regularly", without stating what they mean to state what it means. Can I generate 10000 ULAs per second, as long as I do it "regularly"? Likely not. So you either remove the text, or state that if ULAs are generated regularly, then collisions are possible, and perhaps provide provide an example that calculates the probability of collision with some reasonal value of the regeneration interval. **** > > V. "the network needs ULA as the on-demand and stable addressing > which doesn't need much code to support address assignment mechanisms lik= e > DHCP or ND." I don't think this makes sense. Are you saying such nodes on= ly > support manual address assignment? How is it possible that a sensor doesn= 't > support automatic address assignment due to lack of resources, but has > enough resources to implement a UI for manual address assignment?**** > > [Bing] The lack of resources mainly regarding the network environment, > there might not be a comprehensive network provisioning environment for t= he > nodes. If they can be pre-configured with ULA, say, hard-coded in the > embedded system, like the MAC addresses in every single NIC or > self-generating a ULA, then they could make ad-hoc networking without > address provisioning procedures.**** > > How are those nodes going to find the MAC address of the link router to > communicate off-link? If they can't do this, then you don't need ULA, you > can just use link-local. If they can do this, then they must support rout= er > advertisements or similar. If they support router advertisements, then th= ey > can use autoconfiguration. **** > > [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 function , = the > draft specifically noted this point. But if the sensors are in a MANET, > then the autoconfiguration is different with the traditional wired SLAAC, > since MANET is based on a multi hop topology. ULA is suitable for this > scenario, however, current text seems not sufficient/clear, will modify > later. > If they support SLAAC, then they don't need to be pre-configured, because they can just use SLAAC to autoconfigure addresses. And if they can autoconfigure an address, they can use a global address. So there is no need to use ULA. **** > > VI. "there always be some argument that in practice the ULA+PA makes > terrible operational complexity. But it is not a ULA-specific problem; th= e > multiple- addresses-per-interface is an important feature of IPv6 protoco= l. > Running multiple prefixes in IPv6 might be very common, and we need to > adapt this new operational model than that in IPv4." This text does not > make sense. Just because having multiple global-scope addresses is a > feature of IPv6 doesn't mean that you must have multiple global-scope > addresses. For example, you can use only global addresses and have no > routing complexity.**** > > [Bing] The ULA+PA operational complexity contains two aspect.**** > > One is the common issue as described in the texts, running multiple > prefixes in a network is new to the traditional IPv4 model, the admins ne= ed > to be familiar with it in the future.**** > > No, because having multiple prefixes introduces operational complexity > even if the admins understand multiple prefixes. All things being equal, > having only one prefix (e.g., a global prefix) is always going to be > simpler than having two.**** > > ** ** > > In other words: what you're saying is "let's create complexity, because > admins will need to understand the complexity anyway". What I'm saying is > that while they need to understand the complexity, we don't have to creat= e > the complexity if we don't need it.**** > > [Bing] No, I=92m not say that. ULA+PA is identified as beneficial use cas= e > in 6renum and Homenet. So the admins need to adapt the complexity if they > want the benefit. > Ok, so then just cite those documents, say that there is a trade off between complexity and functionality, and leave it at that? --047d7bb0431638711404dd73a6fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) <le= o.liubing@huawei.com> wrote:

No, the probability is much higher than you think. See RFC 41= 93 section 3.2.3. If I'm reading that section correctly, if you generat= e 10000 ULAs you'll get a collision 1 in 500k times. If you generate 10= 0000 (e.g., if you regenerate them once a second, for one day) you'll get a collision= once in 1000 times. And so on.

[= Bing] In theory, I agree with you. But the point here is where do we need t= o change the ULA so frequently? For random draw? I can hardly imagine a use= case of that.

This is a technical document meant to provide guidance, so I'd sa= y that it's not appropriate to use vague words like regularly "reg= ularly", without stating what they mean to state what it means. Can I = generate 10000 ULAs per second, as long as I do it "regularly"? L= ikely not.

So you either remove the text, or state tha= t if ULAs are generated regularly, then collisions are possible, and perhap= s provide provide an example that calculates the probability of collision w= ith some reasonal value of the regeneration interval.

=A0V. "the network needs U= LA as the on-demand and stable addressing which doesn't need much code = to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automa= tic address assignment due to lack of resources, but has enough resources t= o implement a UI for manual address assignment?

[Bing] = The lack of resources mainly regarding the network environment, there might= not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to fi= nd the MAC address of the link router to communicate off-link? If they can&= #39;t do this, then you don't need ULA, you can just use link-local. If= they can do this, then they must support router advertisements or similar. If they support router advertisements, then the= y can use autoconfiguration.=A0

[= Bing] Surely they need to support SLAAC, it=92s a basic IPv6 function , the= draft specifically noted this point. =A0But if the sensors are in a MANET,= then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA= is suitable for this scenario, however, current text seems not sufficient/= clear, will modify later.

If they support SLAAC, then th= ey don't need to be pre-configured, because they can just use SLAAC to = autoconfigure addresses. And if they can autoconfigure an address, they can= use a global address. So there is no need to use ULA.

VI. &qu= ot;there always be some argument that in practice the ULA+PA makes terrible= operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 prot= ocol. Running multiple prefixes in IPv6 might be very common, and we need t= o adapt this new operational model than that in IPv4." This text does = not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must= have multiple global-scope addresses. For example, you can use only global= addresses and have no routing complexity.

[Bing] = The ULA+PA operational complexity contains two aspect.

One is = the common issue as described in the texts, running multiple prefixes in a = network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.<= /u>

No, because having multiple pre= fixes introduces operational complexity even if the admins understand multi= ple prefixes. All things being equal, having only one prefix (e.g., a globa= l prefix) is always going to be simpler than having two.

=A0

In other words: what you're= saying is "let's create complexity, because admins will need to u= nderstand the complexity anyway". What I'm saying is that while th= ey need to understand the complexity, we don't have to create the complexity if we don't need it.

[= Bing] No, I=92m not say that. ULA+PA is identified as beneficial use case i= n 6renum and Homenet. So the admins need to adapt the complexity if they wa= nt the benefit.

Ok, so then just cite those documents, say that there is a trade off = between complexity and functionality, and leave it at that?

--047d7bb0431638711404dd73a6fa-- From lorenzo@google.com Fri May 24 02:47:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1621F95F2 for ; Fri, 24 May 2013 02:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np7i2YhYFHRz for ; Fri, 24 May 2013 02:47:00 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB2921F96C0 for ; Fri, 24 May 2013 02:47:00 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id s14so2441488qeb.26 for ; Fri, 24 May 2013 02:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SmCpEjY3ZPJQXP/Q/cIy6JmG4cTzd3Gpd/hIRMdx+5U=; b=iLoZqqcJADhknNaOP+BEW1fumG1pNW3f3Mb9z0TessnWK7gq+HwogVBUbW6pGatFbQ GiTnFb8HuuxoqpDSshNmM/HXNfPKkowsS7VsusrU8O7EqECFVQEpX1M0NXVMO4FBc92+ +lWp+NnlwyGwBtX9/m8S9hom0kpjmeAlOZtB3nIBiEdRjS1feTMQM4rPj9+lUIdspCo1 klOfwhTTHm0VI/dX4yG3IGSEX1oX75CQPdV+tiPbkLkpsA+sm8QY14sW1RghUOvb151q WHI0Fjd3V1gGOo7YJhKXb+ArFLMjtTvjZwd2k5KavtsoErTvrkJUi/NcKcvCjPZKn1bW ZXFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=SmCpEjY3ZPJQXP/Q/cIy6JmG4cTzd3Gpd/hIRMdx+5U=; b=Bz7KGHXoUqNh3HaX7gzH6Jl85DKDNq0nffMVJ3CZxwl6bGNSvxpKIyhQysUP5zQcR6 4mRCrgdcPg8NgwKLCTo+xeVIhcpkXY8hlIGMxK+/ZcojwSNRqH6+9PH9PiRG/ujGr6w5 FeG3yiN975a+xHCaGmtsUF8GtHLGksbhvD5+kuIkIS9ibOKH0YlPZN/RsTEAENunJPEF 8iwjKL+7zSfKFVV0c94StYMrJDWsm83zKlrkV1QgcSi3j/RdHLQ43nPcybG0J3qD9fGC CbMQb8o11fff/vbUew/yqnk00lEEBHddaIi+44/7+Ol5opJMYSaDMgd3fQQiMyv8kVWt kUjg== X-Received: by 10.229.17.10 with SMTP id q10mr6031468qca.21.1369388819533; Fri, 24 May 2013 02:46:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Fri, 24 May 2013 02:46:38 -0700 (PDT) In-Reply-To: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <97F7691B-F6A0-49A5-90AC-1A9CDAA50BD3@ecs.soton.ac.uk> From: Lorenzo Colitti Date: Fri, 24 May 2013 18:46:38 +0900 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=0015175cf92a2605f804dd73aed0 X-Gm-Message-State: ALoCoQlQfEnikte1KBvnjWvfNw2cnTSoEprPa0U8zgPctJ+ZezazlvdVi7LZTQTTeJXrQzqJSKbnhHxLlWR3J4BhvCKL/4CCQPEKNN5ngxvm1YlIpWsIENgOIbGj23mtBTZ4cLRSf9w53Lfe/J0jDTXXSXwxVACjGB+S0XNXtBrwkiwo1loGPcLDr9kGJ/TyeMqi8yXaBVAp Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:47:11 -0000 --0015175cf92a2605f804dd73aed0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 21, 2013 at 6:54 PM, Tim Chown wrote: > Which reminds me, I would like to see this document do some deeper > analysis of the issue raised after IETF86, regarding "ULAs on by default" > alongside IPv4/NAT. That thread, discussing the practical issues, ran to > 150+ emails before fizzling out without any specific proposed text, either > for Bing's draft or the homenet arch. I recall that Ole's point on this was > that *if* hosts supported RFC4191 RIO, then ULA routes could be added > without a default route, and dependencies/timeouts on ICMPv6 redirects > avoided. And RFC6204bis ULA-5 recommends that behaviour (along with L-3). > The little snag is that current OSes certainly don't all support RFC4191. > Agreed. Though since this document is about usage guidelines, then there is nothing much it can do except saying "currently, ULA+IPv4 or ULA+IPv4+IPv6 GUA doesn't work in the general case because OSes don't all support RFC 4191 and RFC 6724". Right? --0015175cf92a2605f804dd73aed0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 21, 2013 at 6:54 PM, Tim Chown <tjc@ecs.sot= on.ac.uk> wrote:

Which reminds me, I= would like to see this document do some deeper analysis of the issue raise= d after IETF86, regarding "ULAs on by default" alongside IPv4/NAT= . That thread, discussing the practical issues, ran to 150+ emails before f= izzling out without any specific proposed text, either for Bing's draft= or the homenet arch. I recall that Ole's point on this was that *if* h= osts supported RFC4191 RIO, then ULA routes could be added without a defaul= t route, and dependencies/timeouts on ICMPv6 redirects avoided. And RFC6204= bis ULA-5 recommends that behaviour (along with L-3). The little snag is th= at current OSes certainly don't all support RFC4191.

Agreed. Though sin= ce this document is about usage guidelines, then there is nothing much it c= an do except saying "currently, ULA+IPv4 or ULA+IPv4+IPv6 GUA doesn= 9;t work in the general case because OSes don't all support RFC 4191 an= d RFC 6724". Right?

--0015175cf92a2605f804dd73aed0-- From lorenzo@google.com Fri May 24 02:53:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D880321F96CC for ; Fri, 24 May 2013 02:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EaV+e9oomta for ; Fri, 24 May 2013 02:53:09 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8B21F96C2 for ; Fri, 24 May 2013 02:53:09 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ii15so2169405qab.10 for ; Fri, 24 May 2013 02:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8Rq9L4NQjqOcRCnkJMJjATB/3h+iT/2VkisHedHBUbU=; b=R8vdFYlAxQ0v3WDR7mg9LWqAPyG+eQWbHxxUndGQF8aAewzwXRdmLMtJr7gwV3iXbu 5Gpda240DlO/EFhjgTqHxxPRJNZZCB+2Y2nRD5UuWbAy43Xl/GZzpL5aIcUd8saCa8pG G25M6R66V5++VJ58aTlcGRSGnbolNBgOpOZMwo4LtecQdP29lhYn67IuBydWgVwDDZ1K nPB8twn7CFaSZnJdpyKUYw1fWbg65sGJhBUVLLocfrkZqaJOfM28XcQaYmp6dJ1ndDjf /Cwh+oeiUFH+/irQiCQaEceKsUncKlgziN6KwFv8snrpgVhezl1x6rnliIjDDKiqEyCk tTaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=8Rq9L4NQjqOcRCnkJMJjATB/3h+iT/2VkisHedHBUbU=; b=cAu92vx4drdwICAMzjKsYx3W6lbiAQb+V+zNJ1idu8h3p3Q/AfNU/Ge4wmj+T3B8BR x6ZMYerViOkHPfFvjHCErpcYBW+0CJU1tPMlJMAaa5YiAODhAWpMUTsxxlmrqfJ/Klq6 PEqllRmyCo/9/sr/PlLm3GkqY5iz2k62glHCtOYfNJP4WusYKkvX5eLflfSdCu3rYCBl Y9BYhxSBXtW8M6YfVi/QluA1QR8tNy1drLUo5xlpWc+fHEPpqMt537Hyv0ydHupsiNRH VHpw65K7cBGp4zrlqYcqoSLuVl8xMzljEPaa2PCzm3RAc691cX8Apj0pqzkcPIsVDVPH +h/A== X-Received: by 10.49.35.49 with SMTP id e17mr17851215qej.61.1369389188567; Fri, 24 May 2013 02:53:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Fri, 24 May 2013 02:52:48 -0700 (PDT) In-Reply-To: <519BD73B.50200@gmail.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> From: Lorenzo Colitti Date: Fri, 24 May 2013 18:52:48 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b6da83224f34204dd73c4c0 X-Gm-Message-State: ALoCoQmNr3Jf+Uqcf5TFL1yO8NmAfqgZxgOJegQYLrWRV3SnsQKfgQM1Ut3N+DKa200VShtPgSlgaXgXB+RWzLUs3AZlMQwAc446aM3NEJLGbiKK/lSXw+X1pxY5NJxUeqqn7P7Yyw6YfJsG5jWG1eQcigTeyGlww8HuQdfvmZPOcQDyzw1LbyaSoQ9aZtH6/FTraDT0OToz Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:53:10 -0000 --047d7b6da83224f34204dd73c4c0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > That's correct, of course. The underlying problem here is that the > notion of concentric circles of scope that was originally described > for IPv6 is simply broken. We can't fix that in the context of > describing ULA usage scenarios, so let's not try. > Actually, I think the underlying problem as regards this specific draft is that ULAs were not well thought-out. They came out of a compromise where no side got what it wanted and what we got was a poorly-understood, possibly unusable hybrid. Obviously that ship has sailed, but still, what we're doing here might be putting lipstick on a pig. --047d7b6da83224f34204dd73c4c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

That's correct, of course. The underlying prob= lem here is that the

notion of concentric circles of scope that was originally described
for IPv6 is simply broken. We can't fix that in the context of
describing ULA usage scenarios, so let's not try.
=
Actually, I think the underlying problem as regards this spe= cific draft is that ULAs were not well thought-out. They came out of a comp= romise where no side got what it wanted and what we got was a poorly-unders= tood, possibly unusable hybrid.

Obviously that ship has sailed, but still, what we'= re doing here might be putting lipstick on a pig.

--047d7b6da83224f34204dd73c4c0-- From tjc@ecs.soton.ac.uk Fri May 24 03:34:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D4821F8F00 for ; Fri, 24 May 2013 03:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87I2Ot8NqVTz for ; Fri, 24 May 2013 03:34:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 958D721F8EFE for ; Fri, 24 May 2013 03:34:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OAYmYw023752; Fri, 24 May 2013 11:34:48 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4OAYmYw023752 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369391688; bh=S2roSbph9Lj8QLRmcvqh2zrQm30=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=aWn7HfA4Ila72a99ZHqRRtiwfxLI/isuBH3A0Oyh+eDit98WG5qrwoZdfE8ISC/IU bTfoZRIdf0EG7TcqSgUdAaiNjIScebWtp35/JwlnlPwcH+NXq7/AI9pMQR0+0/OyWn UWt2MNIFxJvp3llbB6gJARrm3oZ5uvdF3/ZAgNDY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p4NBYm043061950614 ret-id none; Fri, 24 May 2013 11:34:48 +0100 Received: from dhcp-205-236.wireless.soton.ac.uk (dhcp-205-236.wireless.soton.ac.uk [152.78.205.236]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OAYkHs009798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 11:34:46 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_22C5A69E-2877-4E23-B13D-8E2A16164FD2" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: Date: Fri, 24 May 2013 11:34:46 +0100 Message-ID: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <97F7691B-F6A0-49A5-90AC-1A9CDAA50BD3@ecs.soton.ac.uk> <6333B7CA-3CE2-4595-BEC5-CFB1ED70A38A@ecs.soton.ac.uk> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4NBYm043061950600; tid=p4NBYm043061950614; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4OAYmYw023752 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:34:51 -0000 --Apple-Mail=_22C5A69E-2877-4E23-B13D-8E2A16164FD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 24 May 2013, at 10:46, Lorenzo Colitti wrote: > On Tue, May 21, 2013 at 6:54 PM, Tim Chown = wrote: > Which reminds me, I would like to see this document do some deeper = analysis of the issue raised after IETF86, regarding "ULAs on by = default" alongside IPv4/NAT. That thread, discussing the practical = issues, ran to 150+ emails before fizzling out without any specific = proposed text, either for Bing's draft or the homenet arch. I recall = that Ole's point on this was that *if* hosts supported RFC4191 RIO, then = ULA routes could be added without a default route, and = dependencies/timeouts on ICMPv6 redirects avoided. And RFC6204bis ULA-5 = recommends that behaviour (along with L-3). The little snag is that = current OSes certainly don't all support RFC4191. >=20 > Agreed. Though since this document is about usage guidelines, then = there is nothing much it can do except saying "currently, ULA+IPv4 or = ULA+IPv4+IPv6 GUA doesn't work in the general case because OSes don't = all support RFC 4191 and RFC 6724". Right? Sounds fine to me. In my view, that's the type of analysis, and the type = of implicit recommendations that this type of document can usefully = make. i.e. If you are thinking about using ULAs for a specific use case, = these are the considerations. If that can be used as some extra = encouragement for vendors to support 4191 and 6724, that's a bonus. I must admit that I had thought there was wider implementation of 4191 = than it seems there is. Tim --Apple-Mail=_22C5A69E-2877-4E23-B13D-8E2A16164FD2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 24 May 2013, at 10:46, Lorenzo Colitti <lorenzo@google.com> wrote:

On Tue, May 21, 2013 at 6:54 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:

Which reminds me, I would like to see this document do some deeper analysis of the issue raised after IETF86, regarding "ULAs on by default" alongside IPv4/NAT. That thread, discussing the practical issues, ran to 150+ emails before fizzling out without any specific proposed text, either for Bing's draft or the homenet arch. I recall that Ole's point on this was that *if* hosts supported RFC4191 RIO, then ULA routes could be added without a default route, and dependencies/timeouts on ICMPv6 redirects avoided. And RFC6204bis ULA-5 recommends that behaviour (along with L-3). The little snag is that current OSes certainly don't all support RFC4191.

Agreed. Though since this document is about usage guidelines, then there is nothing much it can do except saying "currently, ULA+IPv4 or ULA+IPv4+IPv6 GUA doesn't work in the general case because OSes don't all support RFC 4191 and RFC 6724". Right?

Sounds fine to me. In my view, that's the type of analysis, and the type of implicit recommendations that this type of document can usefully make. i.e. If you are thinking about using ULAs for a specific use case, these are the considerations. If that can be used as some extra encouragement for vendors to support 4191 and 6724, that's a bonus.

I must admit that I had thought there was wider implementation of 4191 than it seems there is.

Tim

--Apple-Mail=_22C5A69E-2877-4E23-B13D-8E2A16164FD2-- From tjc@ecs.soton.ac.uk Fri May 24 03:50:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8475521F928C for ; Fri, 24 May 2013 03:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4vab9v5Bkll for ; Fri, 24 May 2013 03:50:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 61CC721F8B98 for ; Fri, 24 May 2013 03:50:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OAoIIT028972; Fri, 24 May 2013 11:50:18 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4OAoIIT028972 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369392618; bh=AlWKvW32LVciJvl9fIhcsCYlWzE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=eSufUbrjqkw0I14R+/7NE0CHKPl1OI69inBmBCw87GbyCE5R8IzAfOb/mbqdYEB9l tvnLHpIo3dC7jzvI8MsZKde60oGQi59VWblPxeQHnFoL6vg73G2YflxHOKVz3fkE4T 7r0LMNV5jmSWfzI72MOigcByhnhld2NLqRQoh5HE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p4NBoI0430619796O3 ret-id none; Fri, 24 May 2013 11:50:18 +0100 Received: from dhcp-205-236.wireless.soton.ac.uk (dhcp-205-236.wireless.soton.ac.uk [152.78.205.236]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OAoFSk014246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 11:50:16 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_73333D5E-1BC1-49C7-B27E-FD7A35FBCFB7" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: Date: Fri, 24 May 2013 11:50:15 +0100 Message-ID: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <35FED34A-B1E0-4CC6-982F-D89671AE0198@ecs.soton.ac.uk> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4NBoH043061979600; tid=p4NBoI0430619796O3; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4OAoIIT028972 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:50:20 -0000 --Apple-Mail=_73333D5E-1BC1-49C7-B27E-FD7A35FBCFB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 24 May 2013, at 10:52, Lorenzo Colitti wrote: > On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter = wrote: > That's correct, of course. The underlying problem here is that the > notion of concentric circles of scope that was originally described > for IPv6 is simply broken. We can't fix that in the context of > describing ULA usage scenarios, so let's not try. >=20 > Actually, I think the underlying problem as regards this specific = draft is that ULAs were not well thought-out. They came out of a = compromise where no side got what it wanted and what we got was a = poorly-understood, possibly unusable hybrid. >=20 > Obviously that ship has sailed, but still, what we're doing here might = be putting lipstick on a pig. Well, the homenet ship is just sounding its horn, with Mark and Ray = about to toss the ropes to shore, weigh anchor and sail off. If you disagree with the rationale for ULA usage in homenet, now's a = good time to shout. The argument in favour includes constrained devices (perhaps with ULAs = "burnt in"), connectivity inside routed homenets prior to external ISP = connectivity, internal connectivity during sustained ISP outages, and = internal connectivity stability when external prefixes change. An argument against is the ULA (no IPv6 GUA) + IPv4/NAT scenario. But = wider implementation of 4191/6724, to enable support of the = recommendations in 6204/6204-bis, would help address that concern. Tim --Apple-Mail=_73333D5E-1BC1-49C7-B27E-FD7A35FBCFB7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 24 May 2013, at 10:52, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

That's correct, of course. The underlying problem here is that the

notion of concentric circles of scope that was originally described
for IPv6 is simply broken. We can't fix that in the context of
describing ULA usage scenarios, so let's not try.

Actually, I think the underlying problem as regards this specific draft is that ULAs were not well thought-out. They came out of a compromise where no side got what it wanted and what we got was a poorly-understood, possibly unusable hybrid.

Obviously that ship has sailed, but still, what we're doing here might be putting lipstick on a pig.

Well, the homenet ship is just sounding its horn, with Mark and Ray about to toss the ropes to shore, weigh anchor and sail off.

If you disagree with the rationale for ULA usage in homenet, now's a good time to shout.

The argument in favour includes constrained devices (perhaps with ULAs "burnt in"), connectivity inside routed homenets prior to external ISP connectivity, internal connectivity during sustained ISP outages, and internal connectivity stability when external prefixes change.

An argument against is the ULA (no IPv6 GUA) + IPv4/NAT scenario. But wider implementation of 4191/6724, to enable support of the recommendations in 6204/6204-bis, would help address that concern.

Tim

--Apple-Mail=_73333D5E-1BC1-49C7-B27E-FD7A35FBCFB7-- From leo.liubing@huawei.com Fri May 24 04:01:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E668621F95DC for ; Fri, 24 May 2013 04:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCZNcFyJ3JFK for ; Fri, 24 May 2013 04:01:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 976F721F9588 for ; Fri, 24 May 2013 04:01:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATD11974; Fri, 24 May 2013 11:01:28 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 12:01:03 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 19:01:19 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Fri, 24 May 2013 19:01:14 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHOVS+HyCM8E5Dr9EyOxCY462I/kZkO8esQ///To4CAAIuHsIAERP4AgACGzxA= Date: Fri, 24 May 2013 11:01:13 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D729249nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 11:01:35 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D729249nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Lorenzo From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Friday, May 24, 2013 5:44 PM To: Liubing (Leo) Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.o= rg Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-us= age-recommendations On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > wrote: No, the probability is much higher than you think. See RFC 4193 section 3.2= .3. If I'm reading that section correctly, if you generate 10000 ULAs you'l= l get a collision 1 in 500k times. If you generate 100000 (e.g., if you reg= enerate them once a second, for one day) you'll get a collision once in 100= 0 times. And so on. [Bing] In theory, I agree with you. But the point here is where do we need = to change the ULA so frequently? For random draw? I can hardly imagine a us= e case of that. This is a technical document meant to provide guidance, so I'd say that it'= s not appropriate to use vague words like regularly "regularly", without st= ating what they mean to state what it means. Can I generate 10000 ULAs per = second, as long as I do it "regularly"? Likely not. So you either remove the text, or state that if ULAs are generated regularl= y, then collisions are possible, and perhaps provide provide an example tha= t calculates the probability of collision with some reasonal value of the r= egeneration interval. [Bing] OK, I'll refine the word. V. "the network needs ULA as the on-demand and stable addressing which doe= sn't need much code to support address assignment mechanisms like DHCP or N= D." I don't think this makes sense. Are you saying such nodes only support = manual address assignment? How is it possible that a sensor doesn't support= automatic address assignment due to lack of resources, but has enough reso= urces to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, ther= e might not be a comprehensive network provisioning environment for the nod= es. If they can be pre-configured with ULA, say, hard-coded in the embedded= system, like the MAC addresses in every single NIC or self-generating a UL= A, then they could make ad-hoc networking without address provisioning proc= edures. How are those nodes going to find the MAC address of the link router to com= municate off-link? If they can't do this, then you don't need ULA, you can = just use link-local. If they can do this, then they must support router adv= ertisements or similar. If they support router advertisements, then they ca= n use autoconfiguration. [Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the = draft specifically noted this point. But if the sensors are in a MANET, th= en the autoconfiguration is different with the traditional wired SLAAC, sin= ce MANET is based on a multi hop topology. ULA is suitable for this scenari= o, however, current text seems not sufficient/clear, will modify later. If they support SLAAC, then they don't need to be pre-configured, because t= hey can just use SLAAC to autoconfigure addresses. And if they can autoconf= igure an address, they can use a global address. So there is no need to use= ULA. [Bing] The reasoning is flawed. Let's do not mix the concepts of global add= r-provisioning and autoconfiguration together. And in MANET, the SLAAC is n= ot (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-st= atement-04.html#section-5.2 VI. "there always be some argument that in practice the ULA+PA makes terrib= le operational complexity. But it is not a ULA-specific problem; the multip= le- addresses-per-interface is an important feature of IPv6 protocol. Runni= ng multiple prefixes in IPv6 might be very common, and we need to adapt thi= s new operational model than that in IPv4." This text does not make sense. = Just because having multiple global-scope addresses is a feature of IPv6 do= esn't mean that you must have multiple global-scope addresses. For example,= you can use only global addresses and have no routing complexity. [Bing] The ULA+PA operational complexity contains two aspect. One is the common issue as described in the texts, running multiple prefixe= s in a network is new to the traditional IPv4 model, the admins need to be = familiar with it in the future. No, because having multiple prefixes introduces operational complexity even= if the admins understand multiple prefixes. All things being equal, having= only one prefix (e.g., a global prefix) is always going to be simpler than= having two. In other words: what you're saying is "let's create complexity, because adm= ins will need to understand the complexity anyway". What I'm saying is that= while they need to understand the complexity, we don't have to create the = complexity if we don't need it. [Bing] No, I'm not say that. ULA+PA is identified as beneficial use case in= 6renum and Homenet. So the admins need to adapt the complexity if they wan= t the benefit. Ok, so then just cite those documents, say that there is a trade off betwee= n complexity and functionality, and leave it at that? [Bing] A brief complexity hint would be valuable. Thanks. B.R. Bing --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D729249nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Lorenz= o

= ;

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, May 24, 2013 5:44 PM
To: Liubing (Leo)
Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools= .ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

On Tue, May 21, 2013 at 6:34 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:

No, the probability is much higher than you t= hink. See RFC 4193 section 3.2.3. If I'm reading that section correctly, if= you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if you regenerate= them once a second, for one day) you'll get a collision once in 1000 times= . And so on.

[Bing] In theory, I a= gree with you. But the point here is where do we need to change the ULA so = frequently? For random draw? I can hardly imagine a use case of that.<= /p>

This is a technical document me= ant to provide guidance, so I'd say that it's not appropriate to use vague = words like regularly "regularly", without stating what they mean = to state what it means. Can I generate 10000 ULAs per second, as long as I do it "regularly"? Likely not.

So you either remove the text, = or state that if ULAs are generated regularly, then collisions are possible= , and perhaps provide provide an example that calculates the probability of= collision with some reasonal value of the regeneration interval.

= ;

[Bing] = OK, I’ll refine the word.

V. "the network needs ULA as the o= n-demand and stable addressing which doesn't need much code to support addr= ess assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automatic = address assignment due to lack of resources, but has enough resources to im= plement a UI for manual address assignment?

[Bing] The lack of re= sources mainly regarding the network environment, there might not be a comp= rehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to find the MAC add= ress of the link router to communicate off-link? If they can't do this, the= n you don't need ULA, you can just use link-local. If they can do this, then they must support router advertiseme= nts or similar. If they support router advertisements, then they can use au= toconfiguration.

[Bing] Surely they ne= ed to support SLAAC, it’s a basic IPv6 function , the draft specifica= lly noted this point. But if the sensors are in a MANET, then the autoconfiguration is different with the traditional w= ired SLAAC, since MANET is based on a multi hop topology. ULA is suitable f= or this scenario, however, current text seems not sufficient/clear, will mo= dify later.

If they support SLAAC, then the= y don't need to be pre-configured, because they can just use SLAAC to autoc= onfigure addresses. And if they can autoconfigure an address, they can use = a global address. So there is no need to use ULA.

= ;

[Bing] = The reasoning is flawed. Let’s do not mix the concepts of global addr= -provisioning and autoconfiguration together. And in MANET, the SLAAC is no= t (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-sta= tement-04.html#section-5.2

VI. "there alway= s be some argument that in practice the ULA+PA makes terrible operation= al complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 prot= ocol. Running multiple prefixes in IPv6 might be very common, and we need t= o adapt this new operational model than that in IPv4." This text does = not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must hav= e multiple global-scope addresses. For example, you can use only global add= resses and have no routing complexity.

[Bing] The ULA+PA= operational complexity contains two aspect.

One is the common iss= ue as described in the texts, running multiple prefixes in a network is new= to the traditional IPv4 model, the admins need to be familiar with it in the future.

No, because having multiple prefixes introduc= es operational complexity even if the admins understand multiple prefixes. = All things being equal, having only one prefix (e.g., a global prefix) is always going to be simpler than having t= wo.

In other words: what you're saying is "l= et's create complexity, because admins will need to understand the complexi= ty anyway". What I'm saying is that while they need to understand the complexity, we don't have to create the complexity = if we don't need it.

[Bing] No, I’m = not say that. ULA+PA is identified as beneficial use case in 6renum and= Homenet. So the admins need to adapt the complexity if they want the benefit.

Ok, so then just cite those doc= uments, say that there is a trade off between complexity and functionality,= and leave it at that?

[Bing] = A brief complexity hint would be valuable. Thanks.

&n= bsp;

B.R.

Bing

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D729249nkgeml506mbxchi_-- From lorenzo@google.com Fri May 24 04:42:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1941D21F89A6 for ; Fri, 24 May 2013 04:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8dNgeFu+LC8 for ; Fri, 24 May 2013 04:42:40 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E1E9A21F8EEA for ; Fri, 24 May 2013 04:42:35 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id e1so2303222qcy.8 for ; Fri, 24 May 2013 04:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bj1LM2vsEwpXl5NYkxyRSPcLX38ZTcoElRwWXZnGLcI=; b=fRaLtejbKWJN3v4sLINpwfx0QzOgRm0wzGILLXkcZ4QOAqLe/f9Rk9ihLESezqVKbf PCiuubTCKK+N7PwneKvGb2PD795cJqmtvGp3x73rM5UJOQSgRs5v9AFnYlL9KTYethlH j+iWwWE37qSEPCSDDLhu+EJMaLT0fx5eere2SbR5heBw+jZU4R1S2PfSqzEM474uh/4a +GrKPSpBnpg4oRt8GkryhclM5mvithn+VIqwssnEYfAdlPsX+5Eq3rr5x4Hpc4hxV45v HXpDFrh4DjUVVDFhVYLobjSz3x039ufHryo/Z41aIODKLnuFynUxhwsavlcnbl0mf3Rv W/Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Bj1LM2vsEwpXl5NYkxyRSPcLX38ZTcoElRwWXZnGLcI=; b=NAlm81JpbGWSUSCl4wTJEKv844yNcFmKl84epqcp/fNyty/FFUqaC63UuYZ7GP6oIR 1KlMviY6owTRWzNOjzq5CCPEU7FgniVTvBrom2g3dHU2lxO4nWk04a6A6SBv98+F68/T PIxBmn6LySG+i3I0b9NQoICBA7etzNB4rTONswc+4Cyl0iiqOKE9jn8L0+1Q80M99MtV KoDWtA4T1gCDVQrqFvL1tI1uBk8Vmpfp5gWpB7cZiJ01sYIk4uIXEWCqZjIDKF5Mnrir VegX5YVglXSXOJp3lkGyJ+84Yv+AHTwrhluAfReWLU3cWpDD3OAJKXopMjxbzVOe90ha wEcw== X-Received: by 10.49.84.42 with SMTP id v10mr18171179qey.60.1369395750074; Fri, 24 May 2013 04:42:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Fri, 24 May 2013 04:42:09 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Fri, 24 May 2013 20:42:09 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=047d7bb043163da89d04dd754b50 X-Gm-Message-State: ALoCoQmRM/dKBFQsLweduX/Kf2CT/eNgAS1qV6MQJzpoc4pFcb2xeZz3y16XzInfCmni9dSprJVBoMQaLb7K1P01M31hhZV87jbl9nNbrP/EQLezbpDvFCwZFvcDRnK/3M5rbzY3qlm6vPxAbypr3IXNGzwVeveZJ9P9aSUyp6Eal+9UmkbRg4SuuPq+yB7lCm0U48H5c+EE Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 11:42:42 -0000 --047d7bb043163da89d04dd754b50 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) wrot= e: > V. "the network needs ULA as the on-demand and stable addressing which > doesn't need much code to support address assignment mechanisms like DHCP > or ND." I don't think this makes sense. Are you saying such nodes only > support manual address assignment? How is it possible that a sensor doesn= 't > support automatic address assignment due to lack of resources, but has > enough resources to implement a UI for manual address assignment?**** > > [Bing] The lack of resources mainly regarding the network environment, > there might not be a comprehensive network provisioning environment for t= he > nodes. If they can be pre-configured with ULA, say, hard-coded in the > embedded system, like the MAC addresses in every single NIC or > self-generating a ULA, then they could make ad-hoc networking without > address provisioning procedures.**** > > How are those nodes going to find the MAC address of the link router to > communicate off-link? If they can't do this, then you don't need ULA, you > can just use link-local. If they can do this, then they must support rout= er > advertisements or similar. If they support router advertisements, then th= ey > can use autoconfiguration. **** > > [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 function , = the > draft specifically noted this point. But if the sensors are in a MANET, > then the autoconfiguration is different with the traditional wired SLAAC, > since MANET is based on a multi hop topology. ULA is suitable for this > scenario, however, current text seems not sufficient/clear, will modify > later.**** > > ** ** > > If they support SLAAC, then they don't need to be pre-configured, because > they can just use SLAAC to autoconfigure addresses. And if they can > autoconfigure an address, they can use a global address. So there is no > need to use ULA.**** > > ** ** > > [Bing] The reasoning is flawed. Let=92s do not mix the concepts of global > addr-provisioning and autoconfiguration together. > Why is it flawed? You said that a use case for ULA is resource-constrained nodes, because you can pre-assign addresses to them, and that this simplifies the nodes. But it doesn't simplify the nodes, because even if you pre-assign addresses, the nodes still need some mechanism (e.g., RA) in order to find out who you can communicate to. So the nodes have to support RAs. And if the nodes support RA, you can use autoconfiguration and you don't need to pre-assign addresses. So you can use any type of address, not only ULA. So this is not a use case for ULA. > And in MANET, the SLAAC is not (fully)applicable, see > http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-= 5.2 > That draft expired in 2008, so it's not really relevant. Do you have a more up-to-date document? On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) wrot= e: > Hi, Lorenzo**** > > ** ** > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Friday, May 24, 2013 5:44 PM > > *To:* Liubing (Leo) > *Cc:* v6ops@ietf.org; > draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > *Subject:* Re: [v6ops] A brief intro-//RE: new draft: > draft-ietf-v6ops-ula-usage-recommendations**** > > ** ** > > On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > wrote:**** > > No, the probability is much higher than you think. See RFC 4193 > section 3.2.3. If I'm reading that section correctly, if you generate 100= 00 > ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g.= , > if you regenerate them once a second, for one day) you'll get a collision > once in 1000 times. And so on.**** > > [Bing] In theory, I agree with you. But the point here is where do we nee= d > to change the ULA so frequently? For random draw? I can hardly imagine a > use case of that.**** > > ** ** > > This is a technical document meant to provide guidance, so I'd say that > it's not appropriate to use vague words like regularly "regularly", witho= ut > stating what they mean to state what it means. Can I generate 10000 ULAs > per second, as long as I do it "regularly"? Likely not.**** > > ** ** > > So you either remove the text, or state that if ULAs are generated > regularly, then collisions are possible, and perhaps provide provide an > example that calculates the probability of collision with some reasonal > value of the regeneration interval.**** > > ** ** > > [Bing] OK, I=92ll refine the word.**** > > ** ** > > V. "the network needs ULA as the on-demand and stable addressing > which doesn't need much code to support address assignment mechanisms lik= e > DHCP or ND." I don't think this makes sense. Are you saying such nodes on= ly > support manual address assignment? How is it possible that a sensor doesn= 't > support automatic address assignment due to lack of resources, but has > enough resources to implement a UI for manual address assignment?**** > > [Bing] The lack of resources mainly regarding the network environment, > there might not be a comprehensive network provisioning environment for t= he > nodes. If they can be pre-configured with ULA, say, hard-coded in the > embedded system, like the MAC addresses in every single NIC or > self-generating a ULA, then they could make ad-hoc networking without > address provisioning procedures.**** > > How are those nodes going to find the MAC address of the link router to > communicate off-link? If they can't do this, then you don't need ULA, you > can just use link-local. If they can do this, then they must support rout= er > advertisements or similar. If they support router advertisements, then th= ey > can use autoconfiguration. **** > > [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 function , = the > draft specifically noted this point. But if the sensors are in a MANET, > then the autoconfiguration is different with the traditional wired SLAAC, > since MANET is based on a multi hop topology. ULA is suitable for this > scenario, however, current text seems not sufficient/clear, will modify > later.**** > > ** ** > > If they support SLAAC, then they don't need to be pre-configured, because > they can just use SLAAC to autoconfigure addresses. And if they can > autoconfigure an address, they can use a global address. So there is no > need to use ULA.**** > > ** ** > > [Bing] The reasoning is flawed. Let=92s do not mix the concepts of global > addr-provisioning and autoconfiguration together. And in MANET, the SLAAC > is not (fully)applicable, see > http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-= 5.2 > **** > > ** ** > > VI. "there always be some argument that in practice the ULA+PA > makes terrible operational complexity. But it is not a ULA-specific > problem; the multiple- addresses-per-interface is an important feature of > IPv6 protocol. Running multiple prefixes in IPv6 might be very common, an= d > we need to adapt this new operational model than that in IPv4." This text > does not make sense. Just because having multiple global-scope addresses = is > a feature of IPv6 doesn't mean that you must have multiple global-scope > addresses. For example, you can use only global addresses and have no > routing complexity.**** > > [Bing] The ULA+PA operational complexity contains two aspect.**** > > One is the common issue as described in the texts, running multiple > prefixes in a network is new to the traditional IPv4 model, the admins ne= ed > to be familiar with it in the future.**** > > No, because having multiple prefixes introduces operational complexity > even if the admins understand multiple prefixes. All things being equal, > having only one prefix (e.g., a global prefix) is always going to be > simpler than having two.**** > > **** > > In other words: what you're saying is "let's create complexity, because > admins will need to understand the complexity anyway". What I'm saying is > that while they need to understand the complexity, we don't have to creat= e > the complexity if we don't need it.**** > > [Bing] No, I=92m not say that. ULA+PA is identified as beneficial use cas= e > in 6renum and Homenet. So the admins need to adapt the complexity if they > want the benefit.**** > > ** ** > > Ok, so then just cite those documents, say that there is a trade off > between complexity and functionality, and leave it at that?**** > > [Bing] A brief complexity hint would be valuable. Thanks.**** > > ** ** > > B.R.**** > > Bing**** > --047d7bb043163da89d04dd754b50 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <le= o.liubing@huawei.com> wrote:

=A0V. "the = network needs ULA as the on-demand and stable addressing which doesn't = need much code to support address assignment mechanisms like DHCP or ND.&qu= ot; I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automa= tic address assignment due to lack of resources, but has enough resources t= o implement a UI for manual address assignment?

[Bing] = The lack of resources mainly regarding the network environment, there might= not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to fi= nd the MAC address of the link router to communicate off-link? If they can&= #39;t do this, then you don't need ULA, you can just use link-local. If they can do this, then they must support router advertiseme= nts or similar. If they support router advertisements, then they can use au= toconfiguration.=A0

[Bing] = Surely they need to support SLAAC, it=92s a basic IPv6 function , the draft= specifically noted this point. =A0But if the sensors are in a MANET, then the autoconfiguration is different with the traditional w= ired SLAAC, since MANET is based on a multi hop topology. ULA is suitable f= or this scenario, however, current text seems not sufficient/clear, will mo= dify later.

=A0

If they support SLAAC, then the= y don't need to be pre-configured, because they can just use SLAAC to a= utoconfigure addresses. And if they can autoconfigure an address, they can = use a global address. So there is no need to use ULA.

=A0=

[= Bing] The reasoning is flawed. Let=92s do not mix the concepts of global ad= dr-provisioning and autoconfiguration together.

Why is it flawed? = You said that a use case for ULA is resource-constrained nodes, because you= can pre-assign addresses to them, and that this simplifies the nodes. But = it doesn't simplify the nodes, because even if you pre-assign addresses= , the nodes still need some mechanism (e.g., RA) in order to find out who y= ou can communicate to. So the nodes have to support RAs. And if the nodes s= upport RA, you can use autoconfiguration and you don't need to pre-assi= gn addresses. So you can use any type of address, not only ULA. So this is = not a use case for ULA.

=A0

And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-sta= tement-04.html#section-5.2

That draft expired in 2008, so it's not really relevant. Do you h= ave a more up-to-date document?

On Fri, May 24, 2013 at 8:01 PM, Liubing= (Leo) <leo.liubing@huawei.com> wrote:

Hi, Lorenz= o

=A0=

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, May 24, 2013 5:44 PM

To: Liubing (Leo)
Cc: v6ops@ietf.o= rg; draft-ietf-v6ops-ula-usage-recommendations@tool= s.ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

=A0

On Tue, May 21, 2013 at 6:34 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:

No, the probability is much hig= her than you think. See RFC 4193 section 3.2.3. If I'm reading that sec= tion correctly, if you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if you regenerate= them once a second, for one day) you'll get a collision once in 1000 t= imes. And so on.

[Bing] = In theory, I agree with you. But the point here is where do we need to chan= ge the ULA so frequently? For random draw? I can hardly imagine a use case of that.

=A0

This is a technical document me= ant to provide guidance, so I'd say that it's not appropriate to us= e vague words like regularly "regularly", without stating what th= ey mean to state what it means. Can I generate 10000 ULAs per second, as long as I do it "regularly"? Likely not.

=A0

So you either remove the text, = or state that if ULAs are generated regularly, then collisions are possible= , and perhaps provide provide an example that calculates the probability of= collision with some reasonal value of the regeneration interval.

=A0=

[= Bing] OK, I=92ll refine the word.

=A0

=A0V. "the network needs U= LA as the on-demand and stable addressing which doesn't need much code = to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automa= tic address assignment due to lack of resources, but has enough resources t= o implement a UI for manual address assignment?

[Bing] = The lack of resources mainly regarding the network environment, there might= not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to fi= nd the MAC address of the link router to communicate off-link? If they can&= #39;t do this, then you don't need ULA, you can just use link-local. If they can do this, then they must support router advertiseme= nts or similar. If they support router advertisements, then they can use au= toconfiguration.=A0

[Bing] = Surely they need to support SLAAC, it=92s a basic IPv6 function , the draft= specifically noted this point. =A0But if the sensors are in a MANET, then the autoconfiguration is different with the traditional w= ired SLAAC, since MANET is based on a multi hop topology. ULA is suitable f= or this scenario, however, current text seems not sufficient/clear, will mo= dify later.

=A0

If they support SLAAC, then the= y don't need to be pre-configured, because they can just use SLAAC to a= utoconfigure addresses. And if they can autoconfigure an address, they can = use a global address. So there is no need to use ULA.

=A0=

[= Bing] The reasoning is flawed. Let=92s do not mix the concepts of global ad= dr-provisioning and autoconfiguration together. And in MANET, the SLAAC is = not (fully)applicable, see http://tools.iet= f.org/html/draft-ietf-autoconf-statement-04.html#section-5.2<= /u>

=A0

VI. &qu= ot;there always be some argument that in practice the ULA+PA makes terrible= operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 prot= ocol. Running multiple prefixes in IPv6 might be very common, and we need t= o adapt this new operational model than that in IPv4." This text does = not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must= have multiple global-scope addresses. For example, you can use only global= addresses and have no routing complexity.

[Bing] = The ULA+PA operational complexity contains two aspect.

One is = the common issue as described in the texts, running multiple prefixes in a = network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.<= /u>

No, because having multiple pre= fixes introduces operational complexity even if the admins understand multi= ple prefixes. All things being equal, having only one prefix (e.g., a global prefix) is always going to be simpler than having t= wo.

=A0

In other words: what you're= saying is "let's create complexity, because admins will need to u= nderstand the complexity anyway". What I'm saying is that while th= ey need to understand the complexity, we don't have to create the complex= ity if we don't need it.

[Bing] = No, I=92m not say that. ULA+PA is identified as beneficial use case in 6ren= um and Homenet. So the admins need to adapt the complexity if they want the benefit.=

=A0

Ok, so then just cite those doc= uments, say that there is a trade off between complexity and functionality,= and leave it at that?

[= Bing] A brief complexity hint would be valuable. Thanks.

= =A0

B.R.=

Bing=

--047d7bb043163da89d04dd754b50-- From Anders_Brandt@sigmadesigns.com Fri May 24 05:32:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D0B21F8F2C for ; Fri, 24 May 2013 05:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbxi+pPjknkM for ; Fri, 24 May 2013 05:31:40 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3321F8F24 for ; Fri, 24 May 2013 05:31:40 -0700 (PDT) From: Anders Brandt To: Lorenzo Colitti , "Liubing (Leo)" Thread-Topic: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHOWHPdN5wnXH1O0UyYc4I8AGIPVZkUOQLQ Date: Fri, 24 May 2013 12:30:49 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.52] Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13cphex1_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:32:03 -0000 --_000_03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13cphex1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lorenzo > So you can use any type of address, not only ULA. So this is not a use ca= se for ULA. The ULA reasoning starts elsewhere. It is tied to a deployment use case: When nodes are installed in a new house, there may be no internet connectiv= ity - and even more importantly: Even if there is internet connectivity, then you can be certain that at som= e time, the ISP will change your assigned prefix. This is critical to certain 6LoWPAN applications such as home automation. Remote controls, sensors and wall controllers are spread all over the house= . They control lights, garage doors and aircon devices. The addresses of the lights, garage doors and aircon devices MUST NOT chang= e since the remote controls, sensors and wall controllers are permanently paired to the= IPv6 addresses of lights, garage doors and aircon devices on the application level. Only ULA prefixes provide that stability, yet ability to route within the h= ome. The lights, garage doors and aircon devices MAY also have global prefixes f= or external use by portals and advanced clients. Thanks, Anders From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: 24. maj 2013 13:42 To: Liubing (Leo) Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.o= rg Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-us= age-recommendations On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > wrote: V. "the network needs ULA as the on-demand and stable addressing which doe= sn't need much code to support address assignment mechanisms like DHCP or N= D." I don't think this makes sense. Are you saying such nodes only support = manual address assignment? How is it possible that a sensor doesn't support= automatic address assignment due to lack of resources, but has enough reso= urces to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, ther= e might not be a comprehensive network provisioning environment for the nod= es. If they can be pre-configured with ULA, say, hard-coded in the embedded= system, like the MAC addresses in every single NIC or self-generating a UL= A, then they could make ad-hoc networking without address provisioning proc= edures. How are those nodes going to find the MAC address of the link router to com= municate off-link? If they can't do this, then you don't need ULA, you can = just use link-local. If they can do this, then they must support router adv= ertisements or similar. If they support router advertisements, then they ca= n use autoconfiguration. [Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the = draft specifically noted this point. But if the sensors are in a MANET, th= en the autoconfiguration is different with the traditional wired SLAAC, sin= ce MANET is based on a multi hop topology. ULA is suitable for this scenari= o, however, current text seems not sufficient/clear, will modify later. If they support SLAAC, then they don't need to be pre-configured, because t= hey can just use SLAAC to autoconfigure addresses. And if they can autoconf= igure an address, they can use a global address. So there is no need to use= ULA. [Bing] The reasoning is flawed. Let's do not mix the concepts of global add= r-provisioning and autoconfiguration together. Why is it flawed? You said that a use case for ULA is resource-constrained = nodes, because you can pre-assign addresses to them, and that this simplifi= es the nodes. But it doesn't simplify the nodes, because even if you pre-as= sign addresses, the nodes still need some mechanism (e.g., RA) in order to = find out who you can communicate to. So the nodes have to support RAs. And = if the nodes support RA, you can use autoconfiguration and you don't need t= o pre-assign addresses. So you can use any type of address, not only ULA. S= o this is not a use case for ULA. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org= /html/draft-ietf-autoconf-statement-04.html#section-5.2 That draft expired in 2008, so it's not really relevant. Do you have a more= up-to-date document? On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > wrote: Hi, Lorenzo From: Lorenzo Colitti [mailto:lorenzo@google.com= ] Sent: Friday, May 24, 2013 5:44 PM To: Liubing (Leo) Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recom= mendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-us= age-recommendations On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > wrote: No, the probability is much higher than you think. See RFC 4193 section 3.2= .3. If I'm reading that section correctly, if you generate 10000 ULAs you'l= l get a collision 1 in 500k times. If you generate 100000 (e.g., if you reg= enerate them once a second, for one day) you'll get a collision once in 100= 0 times. And so on. [Bing] In theory, I agree with you. But the point here is where do we need = to change the ULA so frequently? For random draw? I can hardly imagine a us= e case of that. This is a technical document meant to provide guidance, so I'd say that it'= s not appropriate to use vague words like regularly "regularly", without st= ating what they mean to state what it means. Can I generate 10000 ULAs per = second, as long as I do it "regularly"? Likely not. So you either remove the text, or state that if ULAs are generated regularl= y, then collisions are possible, and perhaps provide provide an example tha= t calculates the probability of collision with some reasonal value of the r= egeneration interval. [Bing] OK, I'll refine the word. V. "the network needs ULA as the on-demand and stable addressing which doe= sn't need much code to support address assignment mechanisms like DHCP or N= D." I don't think this makes sense. Are you saying such nodes only support = manual address assignment? How is it possible that a sensor doesn't support= automatic address assignment due to lack of resources, but has enough reso= urces to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, ther= e might not be a comprehensive network provisioning environment for the nod= es. If they can be pre-configured with ULA, say, hard-coded in the embedded= system, like the MAC addresses in every single NIC or self-generating a UL= A, then they could make ad-hoc networking without address provisioning proc= edures. How are those nodes going to find the MAC address of the link router to com= municate off-link? If they can't do this, then you don't need ULA, you can = just use link-local. If they can do this, then they must support router adv= ertisements or similar. If they support router advertisements, then they ca= n use autoconfiguration. [Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the = draft specifically noted this point. But if the sensors are in a MANET, th= en the autoconfiguration is different with the traditional wired SLAAC, sin= ce MANET is based on a multi hop topology. ULA is suitable for this scenari= o, however, current text seems not sufficient/clear, will modify later. If they support SLAAC, then they don't need to be pre-configured, because t= hey can just use SLAAC to autoconfigure addresses. And if they can autoconf= igure an address, they can use a global address. So there is no need to use= ULA. [Bing] The reasoning is flawed. Let's do not mix the concepts of global add= r-provisioning and autoconfiguration together. And in MANET, the SLAAC is n= ot (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-st= atement-04.html#section-5.2 VI. "there always be some argument that in practice the ULA+PA makes terrib= le operational complexity. But it is not a ULA-specific problem; the multip= le- addresses-per-interface is an important feature of IPv6 protocol. Runni= ng multiple prefixes in IPv6 might be very common, and we need to adapt thi= s new operational model than that in IPv4." This text does not make sense. = Just because having multiple global-scope addresses is a feature of IPv6 do= esn't mean that you must have multiple global-scope addresses. For example,= you can use only global addresses and have no routing complexity. [Bing] The ULA+PA operational complexity contains two aspect. One is the common issue as described in the texts, running multiple prefixe= s in a network is new to the traditional IPv4 model, the admins need to be = familiar with it in the future. No, because having multiple prefixes introduces operational complexity even= if the admins understand multiple prefixes. All things being equal, having= only one prefix (e.g., a global prefix) is always going to be simpler than= having two. In other words: what you're saying is "let's create complexity, because adm= ins will need to understand the complexity anyway". What I'm saying is that= while they need to understand the complexity, we don't have to create the = complexity if we don't need it. [Bing] No, I'm not say that. ULA+PA is identified as beneficial use case in= 6renum and Homenet. So the admins need to adapt the complexity if they wan= t the benefit. Ok, so then just cite those documents, say that there is a trade off betwee= n complexity and functionality, and leave it at that? [Bing] A brief complexity hint would be valuable. Thanks. B.R. Bing --_000_03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13cphex1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lorenzo

<= /p>
> So you can use any type of= address, not only ULA. So this is not a use case for ULA.

The ULA reasoning starts elsewh= ere. It is tied to a deployment use case:

When nodes are installed in a n= ew house, there may be no internet connectivity - and even more importantly= :
Even if there is internet connectivity, then you can be certain that at som= e time, the ISP will change your
assigned prefix.

This is critical to certain 6Lo= WPAN applications such as home automation.

Remote controls, sensors and wa= ll controllers are spread all over the house.
They control lights, garage doors and aircon devices.

The addresses of the lights, ga= rage doors and aircon devices MUST NOT change since the
remote controls, sensors and wall controllers are permanently paired to the= IPv6 addresses of
lights, garage doors and aircon devices on the application level.

Only ULA prefixes provide that = stability, yet ability to route within the home.

The lights, garage doors and ai= rcon devices MAY also have global prefixes for external use by
portals and advanced clients.

Thanks,

Anders=

= ;

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org= ] On Behalf Of Lorenzo Colitti
Sent: 24. maj 2013 13:42
To: Liubing (Leo)
Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools= .ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <<= a href=3D"mailto:leo.liubing@huawei.com" target=3D"_blank">leo.liubing@huaw= ei.com> wrote:

V.= "the network needs ULA as the on-demand and stable addressing which d= oesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you = saying such nodes only support manual address assignment? How is it possibl= e that a sensor doesn't support automatic address assignment due to lack of= resources, but has enough resources to implement a UI for manual address assignment?

[Bing] The lack of resources mainly regarding the network environment= , there might not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with= ULA, say, hard-coded in the embedded system, like the MAC addresses in eve= ry single NIC or self-generating a ULA, then they could make ad-hoc network= ing without address provisioning procedures.

How are = those nodes going to find the MAC address of the link router to communicate= off-link? If they can't do this, then you don't need ULA, you can just use link-local. If they can do this, then the= y must support router advertisements or similar. If they support router adv= ertisements, then they can use autoconfiguration.

[Bing] Surely they need to support SLAAC, it’s a basic IPv6 fun= ction , the draft specifically noted this point. But if the sensors are in a MANET, then the autoconfiguration is dif= ferent with the traditional wired SLAAC, since MANET is based on a multi ho= p topology. ULA is suitable for this scenario, however, current text seems = not sufficient/clear, will modify later.

If they = support SLAAC, then they don't need to be pre-configured, because they can = just use SLAAC to autoconfigure addresses. And if they can autoconfigure an address, they can use a global address. S= o there is no need to use ULA.

[Bing] The reasoning is flawed. Let’s do not mix the concepts o= f global addr-provisioning and autoconfiguration together.

Why is it flawed? You said that a use case for ULA i= s resource-constrained nodes, because you can pre-assign addresses to them,= and that this simplifies the nodes. But it doesn't simplify the nodes, bec= ause even if you pre-assign addresses, the nodes still need some mechanism (e.g., RA) in order to find out who yo= u can communicate to. So the nodes have to support RAs. And if the nodes su= pport RA, you can use autoconfiguration and you don't need to pre-assign ad= dresses. So you can use any type of address, not only ULA. So this is not a use case for ULA.

And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.= 2

That draft expired in 2008, so it's not really relev= ant. Do you have a more up-to-date document?

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <<= a href=3D"mailto:leo.liubing@huawei.com" target=3D"_blank">leo.liubing@huaw= ei.com> wrote:

Hi, Lorenzo=

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, May 24, 2013 5:44 PM

To: Liubing (Leo)
Cc: v6ops@ietf.o= rg; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

On Tue, = May 21, 2013 at 6:34 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:=

No, the = probability is much higher than you think. See RFC 4193 section 3.2.3. If I= 'm reading that section correctly, if you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generat= e 100000 (e.g., if you regenerate them once a second, for one day) you'll g= et a collision once in 1000 times. And so on.

[Bing] In theory, I agree with you. But the point here is where do we= need to change the ULA so frequently? For random draw? I can hardly imagine a use case of that.

This is = a technical document meant to provide guidance, so I'd say that it's not ap= propriate to use vague words like regularly "regularly", without stating what they mean to state what it mea= ns. Can I generate 10000 ULAs per second, as long as I do it "regularl= y"? Likely not.=

So you e= ither remove the text, or state that if ULAs are generated regularly, then = collisions are possible, and perhaps provide provide an example that calculates the probability of collision with some = reasonal value of the regeneration interval.

[Bing] OK, I’ll refine the word.

V.= "the network needs ULA as the on-demand and stable addressing which d= oesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you = saying such nodes only support manual address assignment? How is it possibl= e that a sensor doesn't support automatic address assignment due to lack of= resources, but has enough resources to implement a UI for manual address assignment?

[Bing] The lack of resources mainly regarding the network environment= , there might not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with= ULA, say, hard-coded in the embedded system, like the MAC addresses in eve= ry single NIC or self-generating a ULA, then they could make ad-hoc network= ing without address provisioning procedures.

How are = those nodes going to find the MAC address of the link router to communicate= off-link? If they can't do this, then you don't need ULA, you can just use link-local. If they can do this, then the= y must support router advertisements or similar. If they support router adv= ertisements, then they can use autoconfiguration.

[Bing] Surely they need to support SLAAC, it’s a basic IPv6 fun= ction , the draft specifically noted this point. But if the sensors are in a MANET, then the autoconfiguration is dif= ferent with the traditional wired SLAAC, since MANET is based on a multi ho= p topology. ULA is suitable for this scenario, however, current text seems = not sufficient/clear, will modify later.

If they = support SLAAC, then they don't need to be pre-configured, because they can = just use SLAAC to autoconfigure addresses. And if they can autoconfigure an address, they can use a global address. S= o there is no need to use ULA.

[Bing] The reasoning is flawed. Let’s do not mix the concepts o= f global addr-provisioning and autoconfiguration together. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.= 2

VI. "there always be some argument that in practice the ULA+= PA makes terrible operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an= important feature of IPv6 protocol. Running multiple prefixes in IPv6 migh= t be very common, and we need to adapt this new operational model than that= in IPv4." This text does not make sense. Just because having multiple global-scope addresses is a feature of= IPv6 doesn't mean that you must have multiple global-scope addresses. For = example, you can use only global addresses and have no routing complexity.<= /span>

[Bing] The ULA+PA operational complexity contains two aspect.

One is the common issue as described in the texts, running multiple p= refixes in a network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.

No, beca= use having multiple prefixes introduces operational complexity even if the = admins understand multiple prefixes. All things being equal, having only one prefix (e.g., a global prefix) is alwa= ys going to be simpler than having two.

In other= words: what you're saying is "let's create complexity, because admins= will need to understand the complexity anyway". What I'm saying is that while they need to understand the complexity, we d= on't have to create the complexity if we don't need it.

[Bing] No, I’m not say that. ULA+PA is identified as benefi= cial use case in 6renum and Homenet. So the admins need to adapt the complexity if they want the benefit.

Ok, so t= hen just cite those documents, say that there is a trade off between comple= xity and functionality, and leave it at that?<= /p>

[Bing] A brief complexity hint would be valuable. Thanks.

B.R.

Bing

--_000_03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13cphex1_-- From owen@delong.com Fri May 24 08:59:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1F221F8709 for ; Fri, 24 May 2013 08:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOYl05nDWh3p for ; Fri, 24 May 2013 08:59:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1C321F8618 for ; Fri, 24 May 2013 08:59:48 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4OFr3AT027683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 May 2013 08:53:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4OFr3AT027683 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369410785; bh=IzKHucgzHv/3tt1SNFPnPwnXUUQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Bc3S8uM4qagaDpnn2bNazZQ3b1ogzVVoERgxg/rQl3KwU+/ij2bgRplglMFYQKfrh iEr2Ipqq8yP9v0FHFg4RoLPsKqUC6TEEDqQRWj9Akx5DwCTcCz2cLLMSvBSVtD4vAJ uBLzMND4Ro9i7jduwkg0AsUo3LtHEK1QApBQ7fJc= Content-Type: multipart/alternative; boundary="Apple-Mail=_EB881A61-2E45-4B02-8D29-702602FFC7BE" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> Date: Fri, 24 May 2013 08:53:03 -0700 Message-Id: <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> To: Anders Brandt X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 24 May 2013 08:53:05 -0700 (PDT) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:59:51 -0000 --Apple-Mail=_EB881A61-2E45-4B02-8D29-702602FFC7BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 24, 2013, at 05:30 , Anders Brandt = wrote: > Hi Lorenzo > =20 > > So you can use any type of address, not only ULA. So this is not a = use case for ULA. > =20 > The ULA reasoning starts elsewhere. It is tied to a deployment use = case: > =20 > When nodes are installed in a new house, there may be no internet = connectivity - and even more importantly: > Even if there is internet connectivity, then you can be certain that = at some time, the ISP will change your > assigned prefix. Why can you be certain of that? I understand why you cannot be certain = that they won't. But I do not understand or believe that you can be = certain that they will. However, even in such a case, the router should provide the ULA in an = RA. There is no need to preconfigure ULA into the node in question = rather than use autoconfiguration. > This is critical to certain 6LoWPAN applications such as home = automation. > Remote controls, sensors and wall controllers are spread all over the = house. > They control lights, garage doors and aircon devices. That doesn't mean that they don't need to support RA or that they cannot = autoconfigure an address. There is no valid reason these devices should = have burned-in ULA. Such an addressing scheme would, in fact, be quite = dysfunctional. > The addresses of the lights, garage doors and aircon devices MUST NOT = change since the > remote controls, sensors and wall controllers are permanently paired = to the IPv6 addresses of > lights, garage doors and aircon devices on the application level. That's just really, REALLY bad application design. How do all of these = ULA prefixes get properly routed when the devices are moved from one = segment in the home to another? Do you add a giant layer of MIP = complexity to the ULA in order to make that all work? The smaller devices need to be paired with the oversight application(s). = Those application(s) should provide the required directory services for = them to obtain the IPv6 address(es) of other devices they need to = communicate with. (The oversight application could be as simple as a = dynamic DNS server or as complex as a centralized home automation = management application. Whether support for pairing with more than one = oversight application is required is left as an exercise for the device = manufacturers. > Only ULA prefixes provide that stability, yet ability to route within = the home. > The lights, garage doors and aircon devices MAY also have global = prefixes for external use by > portals and advanced clients. ULA prefixes can't provide that stability, either. Burning a prefix into = a device is just bad juju from start to end. It will lead to some of the same problems we have with similar systems = in IPv4 where applications have built-in assumption that the network is = not segmented and therefore do not function in environments where it is. If you burn a pre-determined ULA prefix into devices, then you either: 1) a) Presume all devices that should talk to each = other are on the same link. b) Presume that all devices on the same link should = talk to each other. c) Break installations where multiple parts of the = system are on different segments. or 2) a) Require significant overhead and additional = facilities (such as MIP) to make communication possible. b) Create unnecessary external dependencies c) Complicate and expand the codebase on resource = constrained nodes. Owen > =20 > Thanks, > Anders > =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Lorenzo Colitti > Sent: 24. maj 2013 13:42 > To: Liubing (Leo) > Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > Subject: Re: [v6ops] A brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations > =20 > On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) = wrote: > V. "the network needs ULA as the on-demand and stable addressing = which doesn't need much code to support address assignment mechanisms = like DHCP or ND." I don't think this makes sense. Are you saying such = nodes only support manual address assignment? How is it possible that a = sensor doesn't support automatic address assignment due to lack of = resources, but has enough resources to implement a UI for manual address = assignment? > [Bing] The lack of resources mainly regarding the network environment, = there might not be a comprehensive network provisioning environment for = the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or = self-generating a ULA, then they could make ad-hoc networking without = address provisioning procedures. > How are those nodes going to find the MAC address of the link router = to communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use autoconfiguration.=20 > [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 function = , the draft specifically noted this point. But if the sensors are in a = MANET, then the autoconfiguration is different with the traditional = wired SLAAC, since MANET is based on a multi hop topology. ULA is = suitable for this scenario, however, current text seems not = sufficient/clear, will modify later. > =20 > If they support SLAAC, then they don't need to be pre-configured, = because they can just use SLAAC to autoconfigure addresses. And if they = can autoconfigure an address, they can use a global address. So there is = no need to use ULA. > =20 > [Bing] The reasoning is flawed. Let=92s do not mix the concepts of = global addr-provisioning and autoconfiguration together. > =20 > Why is it flawed? You said that a use case for ULA is = resource-constrained nodes, because you can pre-assign addresses to = them, and that this simplifies the nodes. But it doesn't simplify the = nodes, because even if you pre-assign addresses, the nodes still need = some mechanism (e.g., RA) in order to find out who you can communicate = to. So the nodes have to support RAs. And if the nodes support RA, you = can use autoconfiguration and you don't need to pre-assign addresses. So = you can use any type of address, not only ULA. So this is not a use case = for ULA. > =20 > And in MANET, the SLAAC is not (fully)applicable, see = http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5= .2 > =20 > That draft expired in 2008, so it's not really relevant. Do you have a = more up-to-date document? > =20 >=20 > On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) = wrote: > Hi, Lorenzo > =20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Friday, May 24, 2013 5:44 PM >=20 > To: Liubing (Leo) > Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > Subject: Re: [v6ops] A brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations > =20 > On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) = wrote: > No, the probability is much higher than you think. See RFC 4193 = section 3.2.3. If I'm reading that section correctly, if you generate = 10000 ULAs you'll get a collision 1 in 500k times. If you generate = 100000 (e.g., if you regenerate them once a second, for one day) you'll = get a collision once in 1000 times. And so on. > [Bing] In theory, I agree with you. But the point here is where do we = need to change the ULA so frequently? For random draw? I can hardly = imagine a use case of that. > =20 > This is a technical document meant to provide guidance, so I'd say = that it's not appropriate to use vague words like regularly "regularly", = without stating what they mean to state what it means. Can I generate = 10000 ULAs per second, as long as I do it "regularly"? Likely not. > =20 > So you either remove the text, or state that if ULAs are generated = regularly, then collisions are possible, and perhaps provide provide an = example that calculates the probability of collision with some reasonal = value of the regeneration interval. > =20 > [Bing] OK, I=92ll refine the word. > =20 > V. "the network needs ULA as the on-demand and stable addressing = which doesn't need much code to support address assignment mechanisms = like DHCP or ND." I don't think this makes sense. Are you saying such = nodes only support manual address assignment? How is it possible that a = sensor doesn't support automatic address assignment due to lack of = resources, but has enough resources to implement a UI for manual address = assignment? > [Bing] The lack of resources mainly regarding the network environment, = there might not be a comprehensive network provisioning environment for = the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or = self-generating a ULA, then they could make ad-hoc networking without = address provisioning procedures. > How are those nodes going to find the MAC address of the link router = to communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use autoconfiguration.=20 > [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 function = , the draft specifically noted this point. But if the sensors are in a = MANET, then the autoconfiguration is different with the traditional = wired SLAAC, since MANET is based on a multi hop topology. ULA is = suitable for this scenario, however, current text seems not = sufficient/clear, will modify later. > =20 > If they support SLAAC, then they don't need to be pre-configured, = because they can just use SLAAC to autoconfigure addresses. And if they = can autoconfigure an address, they can use a global address. So there is = no need to use ULA. > =20 > [Bing] The reasoning is flawed. Let=92s do not mix the concepts of = global addr-provisioning and autoconfiguration together. And in MANET, = the SLAAC is not (fully)applicable, see = http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5= .2 > =20 > VI. "there always be some argument that in practice the ULA+PA makes = terrible operational complexity. But it is not a ULA-specific problem; = the multiple- addresses-per-interface is an important feature of IPv6 = protocol. Running multiple prefixes in IPv6 might be very common, and we = need to adapt this new operational model than that in IPv4." This text = does not make sense. Just because having multiple global-scope addresses = is a feature of IPv6 doesn't mean that you must have multiple = global-scope addresses. For example, you can use only global addresses = and have no routing complexity. > [Bing] The ULA+PA operational complexity contains two aspect. > One is the common issue as described in the texts, running multiple = prefixes in a network is new to the traditional IPv4 model, the admins = need to be familiar with it in the future. > No, because having multiple prefixes introduces operational complexity = even if the admins understand multiple prefixes. All things being equal, = having only one prefix (e.g., a global prefix) is always going to be = simpler than having two. > =20 > In other words: what you're saying is "let's create complexity, = because admins will need to understand the complexity anyway". What I'm = saying is that while they need to understand the complexity, we don't = have to create the complexity if we don't need it. > [Bing] No, I=92m not say that. ULA+PA is identified as beneficial use = case in 6renum and Homenet. So the admins need to adapt the complexity = if they want the benefit. > =20 > Ok, so then just cite those documents, say that there is a trade off = between complexity and functionality, and leave it at that? > [Bing] A brief complexity hint would be valuable. Thanks. > =20 > B.R. > Bing > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_EB881A61-2E45-4B02-8D29-702602FFC7BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Anders_Brandt@sigmadesigns.= com> wrote:
Hi = Lorenzo

> So you can use any type of address, not only = ULA. So this is not a use case for ULA.

The ULA reasoning starts = elsewhere. It is tied to a deployment use = case:

When nodes are installed in a new house, there = may be no internet connectivity - and even more importantly:
Even if = there is internet connectivity, then you can be certain that at some = time, the ISP will change your
assigned = prefix.

Why can you = be certain of that? I understand why you cannot be certain that they = won't. But I do not understand or believe that you can be certain that = they will.

However, even in such a case, the = router should provide the ULA in an RA. There is no need to preconfigure = ULA into the node in question rather than use = autoconfiguration.

This is critical to certain = 6LoWPAN applications such as home = automation.
Remote controls, sensors and wall controllers are = spread all over the house.
They control lights, garage doors and = aircon = devices.

That = doesn't mean that they don't need to support RA or that they cannot = autoconfigure an address. There is no valid reason these devices should = have burned-in ULA. Such an addressing scheme would, in fact, be quite = dysfunctional.

The addresses of = the lights, garage doors and aircon devices MUST NOT change since = the
remote = controls, sensors and wall controllers are permanently paired to the = IPv6 addresses of
lights, garage doors and aircon devices on the = application = level.

That's just = really, REALLY bad application design. How do all of these ULA prefixes = get properly routed when the devices are moved from one segment in the = home to another? Do you add a giant layer of MIP complexity to the ULA = in order to make that all work?

The smaller = devices need to be paired with the oversight application(s). Those = application(s) should provide the required directory services for them = to obtain the IPv6 address(es) of other devices they need to communicate = with. (The oversight application could be as simple as a dynamic DNS = server or as complex as a centralized home automation management = application. Whether support for pairing with more than one oversight = application is required is left as an exercise for the device = manufacturers.

Only ULA prefixes provide that = stability, yet ability to route within the = home.
The lights, garage doors and aircon devices MAY also have = global prefixes for external use by
portals and advanced = clients.

ULA = prefixes can't provide that stability, either. Burning a prefix into a = device is just bad juju from start to end.

It = will lead to some of the same problems we have with similar systems in = IPv4 where applications have built-in assumption that the network is not = segmented and therefore do not function in environments where it = is.

If you burn a pre-determined ULA prefix = into devices, then you either:
1)
= a) = Presume all devices that should talk to each other are on the = same link.
b) Presume = that all devices on the same link should talk to each = other.
= c) Break installations where = multiple parts of the system are on different = segments.
or
2)
= a) = Require significant overhead and additional facilities (such as = MIP) to make communication possible.
= b) = Create unnecessary external dependencies
= c) = Complicate and expand the codebase on resource constrained = nodes.

Owen

Thanks,
Anders

v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti
Sent: 24. maj 2013 = 13:42
To: Liubing = (Leo)
Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org
Subjec= t: Re: [v6ops] A = brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations

On = Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:
V. "the network needs = ULA as the on-demand and stable addressing which doesn't need much code = to support address assignment mechanisms like DHCP or ND." I don't think = this makes sense. Are you saying such nodes only support manual address = assignment? How is it possible that a sensor doesn't support automatic = address assignment due to lack of resources, but has enough resources to = implement a UI for manual address = assignment?
[Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning = procedures.
<= /div>
How are = those nodes going to find the MAC address of the link router to = communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use = autoconfiguration.
[Bing] Surely they need to support SLAAC, it=92s a basic IPv6 = function , the draft specifically noted this point. But if the = sensors are in a MANET, then the autoconfiguration is different with the = traditional wired SLAAC, since MANET is based on a multi hop topology. = ULA is suitable for this scenario, however, current text seems not = sufficient/clear, will modify = later.
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif; ">
If they = support SLAAC, then they don't need to be pre-configured, because they = can just use SLAAC to autoconfigure addresses. And if they can = autoconfigure an address, they can use a global address. So there is no = need to use ULA.
[Bing] = The reasoning is flawed. Let=92s do not mix the concepts of global = addr-provisioning and autoconfiguration = together.

Why is it flawed? You said that a use case for ULA = is resource-constrained nodes, because you can pre-assign addresses to = them, and that this simplifies the nodes. But it doesn't simplify the = nodes, because even if you pre-assign addresses, the nodes still need = some mechanism (e.g., RA) in order to find out who you can communicate = to. So the nodes have to support RAs. And if the nodes support RA, you = can use autoconfiguration and you don't need to pre-assign addresses. So = you can use any type of address, not only ULA. So this is not a use case = for ULA.
And in MANET, the SLAAC is not = (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section= -5.2

That draft expired in 2008, so it's not really = relevant. Do you have a more up-to-date = document?

On = Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:
Hi, = Lorenzo
From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, May 24, 2013 5:44 = PM
Liubing = (Leo)
Cc: v6ops@ietf.org; Re: [v6ops] A = brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations

On Tue, May 21, 2013 at 6:34 = PM, Liubing (Leo) <
No, the = probability is much higher than you think. See RFC 4193 section 3.2.3. = If I'm reading that section correctly, if you generate 10000 ULAs you'll = get a collision 1 in 500k times. If you generate 100000 (e.g., if you = regenerate them once a second, for one day) you'll get a collision once = in 1000 times. And so on.
[Bing] In theory, I agree with you. But the point here is where = do we need to change the ULA so frequently? For random draw? I can = hardly imagine a use case of = that.

This is a technical document = meant to provide guidance, so I'd say that it's not appropriate to use = vague words like regularly "regularly", without stating what they mean = to state what it means. Can I generate 10000 ULAs per second, as long as = I do it "regularly"? Likely = not.

So you = either remove the text, or state that if ULAs are generated regularly, = then collisions are possible, and perhaps provide provide an example = that calculates the probability of collision with some reasonal value of = the regeneration interval.
[Bing] = OK, I=92ll refine the = word.

V. "the network needs ULA as the on-demand and = stable addressing which doesn't need much code to support address = assignment mechanisms like DHCP or ND." I don't think this makes sense. = Are you saying such nodes only support manual address assignment? How is = it possible that a sensor doesn't support automatic address assignment = due to lack of resources, but has enough resources to implement a UI for = manual address = assignment?
[Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning = procedures.
<= /div>
How are = those nodes going to find the MAC address of the link router to = communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use = autoconfiguration.
[Bing] Surely they need to support SLAAC, it=92s a basic IPv6 = function , the draft specifically noted this point. But if the = sensors are in a MANET, then the autoconfiguration is different with the = traditional wired SLAAC, since MANET is based on a multi hop topology. = ULA is suitable for this scenario, however, current text seems not = sufficient/clear, will modify = later.
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif; ">
If they = support SLAAC, then they don't need to be pre-configured, because they = can just use SLAAC to autoconfigure addresses. And if they can = autoconfigure an address, they can use a global address. So there is no = need to use ULA.
[Bing] = The reasoning is flawed. Let=92s do not mix the concepts of global = addr-provisioning and autoconfiguration together. And in MANET, the = SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section= -5.2

VI. "there always be = some argument that in practice the ULA+PA makes terrible operational = complexity. But it is not a ULA-specific problem; the multiple- = addresses-per-interface is an important feature of IPv6 protocol. = Running multiple prefixes in IPv6 might be very common, and we need to = adapt this new operational model than that in IPv4." This text does not = make sense. Just because having multiple global-scope addresses is a = feature of IPv6 doesn't mean that you must have multiple global-scope = addresses. For example, you can use only global addresses and have no = routing complexity.
[Bing] The ULA+PA operational complexity contains two = aspect.
One is the = common issue as described in the texts, running multiple prefixes in a = network is new to the traditional IPv4 model, the admins need to be = familiar with it in the = future.
=
No, because having = multiple prefixes introduces operational complexity even if the admins = understand multiple prefixes. All things being equal, having only one = prefix (e.g., a global prefix) is always going to be simpler than having = two.

In other = words: what you're saying is "let's create complexity, because admins = will need to understand the complexity anyway". What I'm saying is that = while they need to understand the complexity, we don't have to create = the complexity if we don't need = it.
[Bing] No, = I=92m not say that. ULA+PA is identified as beneficial use case in = 6renum and Homenet. So the admins need to adapt the complexity if they = want the = benefit.

Ok, so = then just cite those documents, say that there is a trade off between = complexity and functionality, and leave it at = that?
[Bing] = A brief complexity hint would be valuable. = Thanks.
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_EB881A61-2E45-4B02-8D29-702602FFC7BE-- From tjc@ecs.soton.ac.uk Fri May 24 11:23:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2AE11E80A5 for ; Fri, 24 May 2013 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-ceoJu+WMTS for ; Fri, 24 May 2013 11:23:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 337C611E80A2 for ; Fri, 24 May 2013 11:23:15 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OINCaY029265; Fri, 24 May 2013 19:23:12 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4OINCaY029265 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369419792; bh=8by73aTJeNtO5xpMpxm351bZKLs=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=jFBECf23DMTGTW/vdS4JCnGP3UGV/Pl0TyX7pfYmTw6itjfF/tDpg+xFO4bUGOMOa s9crRTHDb2qYLOQH1JLrP+K4suwaFH1D+/hcHlDSRqQTknbaEDLJCJhrDk9U2kDFUD Y8RXkg6Pe0V3baRN/LvahVklQaBHAX9F31+XOD/c= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p4NJNC0430626078pU ret-id none; Fri, 24 May 2013 19:23:12 +0100 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OILool026652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 19:21:51 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4B9FF892-D27E-45A3-80AE-A7BBD59F550A" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> Date: Fri, 24 May 2013 19:21:52 +0100 Message-ID: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4NJNC043062607800; tid=p4NJNC0430626078pU; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4OINCaY029265 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:23:19 -0000 --Apple-Mail=_4B9FF892-D27E-45A3-80AE-A7BBD59F550A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In-line... On 24 May 2013, at 16:53, Owen DeLong wrote: >=20 > On May 24, 2013, at 05:30 , Anders Brandt = wrote: >=20 >> Hi Lorenzo >> =20 >> > So you can use any type of address, not only ULA. So this is not a = use case for ULA. >> =20 >> The ULA reasoning starts elsewhere. It is tied to a deployment use = case: >> =20 >> When nodes are installed in a new house, there may be no internet = connectivity - and even more importantly: >> Even if there is internet connectivity, then you can be certain that = at some time, the ISP will change your >> assigned prefix. >=20 > Why can you be certain of that? I understand why you cannot be certain = that they won't. But I do not understand or believe that you can be = certain that they will. >=20 > However, even in such a case, the router should provide the ULA in an = RA. There is no need to preconfigure ULA into the node in question = rather than use autoconfiguration. So in the homenet context we're listening to what the people building = the constrained devices are telling us. The ISPs are saying that it is very unlikely that the homenet's prefix = will be persistent. Certainly not in all cases. The homenet arch assumes the use of ULAs for internal communications and = stablity, and that ULA prefixes will be used in RAs. Alongside GUA = prefixes where they are also in use. It may be that certain home gateways generate their own ULA /48's. The = homenet arch talks about multiple ULA /48's potentially being in use. >> This is critical to certain 6LoWPAN applications such as home = automation. >> Remote controls, sensors and wall controllers are spread all over the = house. >> They control lights, garage doors and aircon devices. >=20 > That doesn't mean that they don't need to support RA or that they = cannot autoconfigure an address. There is no valid reason these devices = should have burned-in ULA. Such an addressing scheme would, in fact, be = quite dysfunctional. Do all 6lowpan devices support RA in the conventional sense? Or when = sleeping? >> The addresses of the lights, garage doors and aircon devices MUST NOT = change since the >> remote controls, sensors and wall controllers are permanently paired = to the IPv6 addresses of >> lights, garage doors and aircon devices on the application level. >=20 > That's just really, REALLY bad application design. How do all of these = ULA prefixes get properly routed when the devices are moved from one = segment in the home to another? Do you add a giant layer of MIP = complexity to the ULA in order to make that all work? >=20 > The smaller devices need to be paired with the oversight = application(s). Those application(s) should provide the required = directory services for them to obtain the IPv6 address(es) of other = devices they need to communicate with. (The oversight application could = be as simple as a dynamic DNS server or as complex as a centralized home = automation management application. Whether support for pairing with more = than one oversight application is required is left as an exercise for = the device manufacturers. So this would be the desired model of course, but what are the actual = constraints? >> Only ULA prefixes provide that stability, yet ability to route within = the home. >> The lights, garage doors and aircon devices MAY also have global = prefixes for external use by >> portals and advanced clients. >=20 > ULA prefixes can't provide that stability, either. Burning a prefix = into a device is just bad juju from start to end. >=20 > It will lead to some of the same problems we have with similar systems = in IPv4 where applications have built-in assumption that the network is = not segmented and therefore do not function in environments where it is. >=20 > If you burn a pre-determined ULA prefix into devices, then you either: > 1) > a) Presume all devices that should talk to each = other are on the same link. > b) Presume that all devices on the same link should = talk to each other. > c) Break installations where multiple parts of the = system are on different segments. > or > 2) > a) Require significant overhead and additional = facilities (such as MIP) to make communication possible. > b) Create unnecessary external dependencies > c) Complicate and expand the codebase on resource = constrained nodes. In case 1) above the "burnt in" ULA could potentially still communicate = across routers. I believe that's the case Anders refers to. But again, I agree that "burnt in" addresses are highly undesirable, but = are there scenarios where they are unavoidable? Perhaps we're asking in = the wrong list. Tim >=20 > Owen >=20 >> =20 >> Thanks, >> Anders >> =20 >> =20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Lorenzo Colitti >> Sent: 24. maj 2013 13:42 >> To: Liubing (Leo) >> Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org >> Subject: Re: [v6ops] A brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations >> =20 >> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) = wrote: >> V. "the network needs ULA as the on-demand and stable addressing = which doesn't need much code to support address assignment mechanisms = like DHCP or ND." I don't think this makes sense. Are you saying such = nodes only support manual address assignment? How is it possible that a = sensor doesn't support automatic address assignment due to lack of = resources, but has enough resources to implement a UI for manual address = assignment? >> [Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning procedures. >> How are those nodes going to find the MAC address of the link router = to communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use autoconfiguration.=20 >> [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 = function , the draft specifically noted this point. But if the sensors = are in a MANET, then the autoconfiguration is different with the = traditional wired SLAAC, since MANET is based on a multi hop topology. = ULA is suitable for this scenario, however, current text seems not = sufficient/clear, will modify later. >> =20 >> If they support SLAAC, then they don't need to be pre-configured, = because they can just use SLAAC to autoconfigure addresses. And if they = can autoconfigure an address, they can use a global address. So there is = no need to use ULA. >> =20 >> [Bing] The reasoning is flawed. Let=92s do not mix the concepts of = global addr-provisioning and autoconfiguration together. >> =20 >> Why is it flawed? You said that a use case for ULA is = resource-constrained nodes, because you can pre-assign addresses to = them, and that this simplifies the nodes. But it doesn't simplify the = nodes, because even if you pre-assign addresses, the nodes still need = some mechanism (e.g., RA) in order to find out who you can communicate = to. So the nodes have to support RAs. And if the nodes support RA, you = can use autoconfiguration and you don't need to pre-assign addresses. So = you can use any type of address, not only ULA. So this is not a use case = for ULA. >> =20 >> And in MANET, the SLAAC is not (fully)applicable, see = http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5= .2 >> =20 >> That draft expired in 2008, so it's not really relevant. Do you have = a more up-to-date document? >> =20 >>=20 >> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) = wrote: >> Hi, Lorenzo >> =20 >> From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 >> Sent: Friday, May 24, 2013 5:44 PM >>=20 >> To: Liubing (Leo) >> Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org >> Subject: Re: [v6ops] A brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations >> =20 >> On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) = wrote: >> No, the probability is much higher than you think. See RFC 4193 = section 3.2.3. If I'm reading that section correctly, if you generate = 10000 ULAs you'll get a collision 1 in 500k times. If you generate = 100000 (e.g., if you regenerate them once a second, for one day) you'll = get a collision once in 1000 times. And so on. >> [Bing] In theory, I agree with you. But the point here is where do we = need to change the ULA so frequently? For random draw? I can hardly = imagine a use case of that. >> =20 >> This is a technical document meant to provide guidance, so I'd say = that it's not appropriate to use vague words like regularly "regularly", = without stating what they mean to state what it means. Can I generate = 10000 ULAs per second, as long as I do it "regularly"? Likely not. >> =20 >> So you either remove the text, or state that if ULAs are generated = regularly, then collisions are possible, and perhaps provide provide an = example that calculates the probability of collision with some reasonal = value of the regeneration interval. >> =20 >> [Bing] OK, I=92ll refine the word. >> =20 >> V. "the network needs ULA as the on-demand and stable addressing = which doesn't need much code to support address assignment mechanisms = like DHCP or ND." I don't think this makes sense. Are you saying such = nodes only support manual address assignment? How is it possible that a = sensor doesn't support automatic address assignment due to lack of = resources, but has enough resources to implement a UI for manual address = assignment? >> [Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning procedures. >> How are those nodes going to find the MAC address of the link router = to communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use autoconfiguration.=20 >> [Bing] Surely they need to support SLAAC, it=92s a basic IPv6 = function , the draft specifically noted this point. But if the sensors = are in a MANET, then the autoconfiguration is different with the = traditional wired SLAAC, since MANET is based on a multi hop topology. = ULA is suitable for this scenario, however, current text seems not = sufficient/clear, will modify later. >> =20 >> If they support SLAAC, then they don't need to be pre-configured, = because they can just use SLAAC to autoconfigure addresses. And if they = can autoconfigure an address, they can use a global address. So there is = no need to use ULA. >> =20 >> [Bing] The reasoning is flawed. Let=92s do not mix the concepts of = global addr-provisioning and autoconfiguration together. And in MANET, = the SLAAC is not (fully)applicable, see = http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5= .2 >> =20 >> VI. "there always be some argument that in practice the ULA+PA makes = terrible operational complexity. But it is not a ULA-specific problem; = the multiple- addresses-per-interface is an important feature of IPv6 = protocol. Running multiple prefixes in IPv6 might be very common, and we = need to adapt this new operational model than that in IPv4." This text = does not make sense. Just because having multiple global-scope addresses = is a feature of IPv6 doesn't mean that you must have multiple = global-scope addresses. For example, you can use only global addresses = and have no routing complexity. >> [Bing] The ULA+PA operational complexity contains two aspect. >> One is the common issue as described in the texts, running multiple = prefixes in a network is new to the traditional IPv4 model, the admins = need to be familiar with it in the future. >> No, because having multiple prefixes introduces operational = complexity even if the admins understand multiple prefixes. All things = being equal, having only one prefix (e.g., a global prefix) is always = going to be simpler than having two. >> =20 >> In other words: what you're saying is "let's create complexity, = because admins will need to understand the complexity anyway". What I'm = saying is that while they need to understand the complexity, we don't = have to create the complexity if we don't need it. >> [Bing] No, I=92m not say that. ULA+PA is identified as beneficial use = case in 6renum and Homenet. So the admins need to adapt the complexity = if they want the benefit. >> =20 >> Ok, so then just cite those documents, say that there is a trade off = between complexity and functionality, and leave it at that? >> [Bing] A brief complexity hint would be valuable. Thanks. >> =20 >> B.R. >> Bing >> =20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_4B9FF892-D27E-45A3-80AE-A7BBD59F550A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 owen@delong.com> wrote:

Anders_Brandt@sigmadesigns.= com> wrote:

Hi = Lorenzo

> So you can use any type of address, not only = ULA. So this is not a use case for ULA.

The ULA reasoning starts = elsewhere. It is tied to a deployment use = case:

When nodes are installed in a new house, there = may be no internet connectivity - and even more importantly:
Even if = there is internet connectivity, then you can be certain that at some = time, the ISP will change your
assigned = prefix.

Why can you = be certain of that? I understand why you cannot be certain that they = won't. But I do not understand or believe that you can be certain that = they will.

However, even in such a case, the = router should provide the ULA in an RA. There is no need to preconfigure = ULA into the node in question rather than use = autoconfiguration.

So in the = homenet context we're listening to what the people building the = constrained devices are telling us.

The ISPs = are saying that it is very unlikely that the homenet's prefix will be = persistent. Certainly not in all = cases.

The homenet arch assumes the use of ULAs = for internal communications and stablity, and that ULA prefixes will be = used in RAs. Alongside GUA prefixes where they are also in = use.

It may be that certain home gateways = generate their own ULA /48's. The homenet arch talks about multiple ULA = /48's potentially being in use.

This is critical to certain = 6LoWPAN applications such as home = automation.
Remote controls, sensors and wall controllers are = spread all over the house.
They control lights, garage doors and = aircon = devices.

That = doesn't mean that they don't need to support RA or that they cannot = autoconfigure an address. There is no valid reason these devices should = have burned-in ULA. Such an addressing scheme would, in fact, be quite = dysfunctional.

Do all 6lowpan = devices support RA in the conventional sense? Or when = sleeping?

The addresses of = the lights, garage doors and aircon devices MUST NOT change since = the
remote = controls, sensors and wall controllers are permanently paired to the = IPv6 addresses of
lights, garage doors and aircon devices on the = application = level.

That's just = really, REALLY bad application design. How do all of these ULA prefixes = get properly routed when the devices are moved from one segment in the = home to another? Do you add a giant layer of MIP complexity to the ULA = in order to make that all work?

The smaller = devices need to be paired with the oversight application(s). Those = application(s) should provide the required directory services for them = to obtain the IPv6 address(es) of other devices they need to communicate = with. (The oversight application could be as simple as a dynamic DNS = server or as complex as a centralized home automation management = application. Whether support for pairing with more than one oversight = application is required is left as an exercise for the device = manufacturers.

So this would be = the desired model of course, but what are the actual = constraints?

Only ULA prefixes provide that = stability, yet ability to route within the = home.
The lights, garage doors and aircon devices MAY also have = global prefixes for external use by
portals and advanced = clients.

ULA = prefixes can't provide that stability, either. Burning a prefix into a = device is just bad juju from start to end.

It = will lead to some of the same problems we have with similar systems in = IPv4 where applications have built-in assumption that the network is not = segmented and therefore do not function in environments where it = is.

If you burn a pre-determined ULA prefix = into devices, then you either:
1)
= a) = Presume all devices that should talk to each other are on the = same link.
b) Presume = that all devices on the same link should talk to each = other.
= c) Break installations where = multiple parts of the system are on different = segments.
or
2)
= a) = Require significant overhead and additional facilities (such as = MIP) to make communication possible.
= b) = Create unnecessary external dependencies
= c) = Complicate and expand the codebase on resource constrained = nodes.

In case 1) above the = "burnt in" ULA could potentially still communicate across routers. I = believe that's the case Anders refers to.

But again, = I agree that "burnt in" addresses are highly undesirable, but are there = scenarios where they are unavoidable? Perhaps we're asking in the wrong = list.

Tim

Thanks,
Anders

v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti
Sent: 24. maj 2013 = 13:42
To: Liubing = (Leo)
Cc: v6ops@ietf.org; = draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org
Subjec= t: Re: [v6ops] A = brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations

On = Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:
V. "the network needs = ULA as the on-demand and stable addressing which doesn't need much code = to support address assignment mechanisms like DHCP or ND." I don't think = this makes sense. Are you saying such nodes only support manual address = assignment? How is it possible that a sensor doesn't support automatic = address assignment due to lack of resources, but has enough resources to = implement a UI for manual address = assignment?
[Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning = procedures.
<= /div>
How are = those nodes going to find the MAC address of the link router to = communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use = autoconfiguration.
[Bing] Surely they need to support SLAAC, it=92s a basic IPv6 = function , the draft specifically noted this point. But if the = sensors are in a MANET, then the autoconfiguration is different with the = traditional wired SLAAC, since MANET is based on a multi hop topology. = ULA is suitable for this scenario, however, current text seems not = sufficient/clear, will modify = later.
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif; ">
If they = support SLAAC, then they don't need to be pre-configured, because they = can just use SLAAC to autoconfigure addresses. And if they can = autoconfigure an address, they can use a global address. So there is no = need to use ULA.
[Bing] = The reasoning is flawed. Let=92s do not mix the concepts of global = addr-provisioning and autoconfiguration = together.

Why is it flawed? You said that a use case for ULA = is resource-constrained nodes, because you can pre-assign addresses to = them, and that this simplifies the nodes. But it doesn't simplify the = nodes, because even if you pre-assign addresses, the nodes still need = some mechanism (e.g., RA) in order to find out who you can communicate = to. So the nodes have to support RAs. And if the nodes support RA, you = can use autoconfiguration and you don't need to pre-assign addresses. So = you can use any type of address, not only ULA. So this is not a use case = for ULA.
And in MANET, the SLAAC is not = (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section= -5.2

That draft expired in 2008, so it's not really = relevant. Do you have a more up-to-date = document?

On = Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <leo.liubing@huawei.com> = wrote:
Hi, = Lorenzo
From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, May 24, 2013 5:44 = PM
Liubing = (Leo)
Cc: v6ops@ietf.org; Re: [v6ops] A = brief intro-//RE: new draft: = draft-ietf-v6ops-ula-usage-recommendations

On Tue, May 21, 2013 at 6:34 = PM, Liubing (Leo) <
No, the = probability is much higher than you think. See RFC 4193 section 3.2.3. = If I'm reading that section correctly, if you generate 10000 ULAs you'll = get a collision 1 in 500k times. If you generate 100000 (e.g., if you = regenerate them once a second, for one day) you'll get a collision once = in 1000 times. And so on.
[Bing] In theory, I agree with you. But the point here is where = do we need to change the ULA so frequently? For random draw? I can = hardly imagine a use case of = that.

This is a technical document = meant to provide guidance, so I'd say that it's not appropriate to use = vague words like regularly "regularly", without stating what they mean = to state what it means. Can I generate 10000 ULAs per second, as long as = I do it "regularly"? Likely = not.

So you = either remove the text, or state that if ULAs are generated regularly, = then collisions are possible, and perhaps provide provide an example = that calculates the probability of collision with some reasonal value of = the regeneration interval.
[Bing] = OK, I=92ll refine the = word.

V. "the network needs ULA as the on-demand and = stable addressing which doesn't need much code to support address = assignment mechanisms like DHCP or ND." I don't think this makes sense. = Are you saying such nodes only support manual address assignment? How is = it possible that a sensor doesn't support automatic address assignment = due to lack of resources, but has enough resources to implement a UI for = manual address = assignment?
[Bing] The lack of resources mainly regarding the network = environment, there might not be a comprehensive network provisioning = environment for the nodes. If they can be pre-configured with ULA, say, = hard-coded in the embedded system, like the MAC addresses in every = single NIC or self-generating a ULA, then they could make ad-hoc = networking without address provisioning = procedures.
<= /div>
How are = those nodes going to find the MAC address of the link router to = communicate off-link? If they can't do this, then you don't need ULA, = you can just use link-local. If they can do this, then they must support = router advertisements or similar. If they support router advertisements, = then they can use = autoconfiguration.
[Bing] Surely they need to support SLAAC, it=92s a basic IPv6 = function , the draft specifically noted this point. But if the = sensors are in a MANET, then the autoconfiguration is different with the = traditional wired SLAAC, since MANET is based on a multi hop topology. = ULA is suitable for this scenario, however, current text seems not = sufficient/clear, will modify = later.
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif; ">
If they = support SLAAC, then they don't need to be pre-configured, because they = can just use SLAAC to autoconfigure addresses. And if they can = autoconfigure an address, they can use a global address. So there is no = need to use ULA.
[Bing] = The reasoning is flawed. Let=92s do not mix the concepts of global = addr-provisioning and autoconfiguration together. And in MANET, the = SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section= -5.2

VI. "there always be = some argument that in practice the ULA+PA makes terrible operational = complexity. But it is not a ULA-specific problem; the multiple- = addresses-per-interface is an important feature of IPv6 protocol. = Running multiple prefixes in IPv6 might be very common, and we need to = adapt this new operational model than that in IPv4." This text does not = make sense. Just because having multiple global-scope addresses is a = feature of IPv6 doesn't mean that you must have multiple global-scope = addresses. For example, you can use only global addresses and have no = routing complexity.
[Bing] The ULA+PA operational complexity contains two = aspect.
One is the = common issue as described in the texts, running multiple prefixes in a = network is new to the traditional IPv4 model, the admins need to be = familiar with it in the = future.
=
No, because having = multiple prefixes introduces operational complexity even if the admins = understand multiple prefixes. All things being equal, having only one = prefix (e.g., a global prefix) is always going to be simpler than having = two.

In other = words: what you're saying is "let's create complexity, because admins = will need to understand the complexity anyway". What I'm saying is that = while they need to understand the complexity, we don't have to create = the complexity if we don't need = it.
[Bing] No, = I=92m not say that. ULA+PA is identified as beneficial use case in = 6renum and Homenet. So the admins need to adapt the complexity if they = want the = benefit.

Ok, so = then just cite those documents, say that there is a trade off between = complexity and functionality, and leave it at = that?
[Bing] = A brief complexity hint would be valuable. = Thanks.
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

_____________= __________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_4B9FF892-D27E-45A3-80AE-A7BBD59F550A-- From joelja@bogus.com Fri May 24 11:28:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4911E80A5 for ; Fri, 24 May 2013 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx1FctCG5wOe for ; Fri, 24 May 2013 11:28:16 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B492321F93E1 for ; Fri, 24 May 2013 11:28:16 -0700 (PDT) Received: from joels-MacBook-Air.local (214.sub-70-197-12.myvzw.com [70.197.12.214]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4OIRgKw051171 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 24 May 2013 18:27:44 GMT (envelope-from joelja@bogus.com) Message-ID: <519FB11A.5060805@bogus.com> Date: Fri, 24 May 2013 11:27:38 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Tim Chown , v6ops@ietf.org References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 24 May 2013 18:27:44 +0000 (UTC) Cc: draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:28:18 -0000 On 5/24/13 11:21 AM, Tim Chown wrote: > In-line... > > On 24 May 2013, at 16:53, Owen DeLong > wrote: > >> >> On May 24, 2013, at 05:30 , Anders Brandt >> > > wrote: >> >>> Hi Lorenzo >>> > So you can use any type of address, not only ULA. So this is not a use case for ULA. >>> The ULA reasoning starts elsewhere. It is tied to a deployment use case: >>> When nodes are installed in a new house, there may be no internet >>> connectivity - and even more importantly: >>> Even if there is internet connectivity, then you can be certain that >>> at some time, the ISP will change your >>> assigned prefix. >> >> Why can you be certain of that? I understand why you cannot be >> certain that they won't. But I do not understand or believe that you >> can be certain that they will. >> >> However, even in such a case, the router should provide the ULA in an >> RA. There is no need to preconfigure ULA into the node in question >> rather than use autoconfiguration. > > So in the homenet context we're listening to what the people building > the constrained devices are telling us. > > The ISPs are saying that it is very unlikely that the homenet's prefix > will be persistent. Certainly not in all cases. > Even if the happen to be, from one ISP they certainly are not when you change providers. whether that is because your other one is down, or becasue you got $29 a month deal from at&t as an inducement to move from comcast doesn't seem relevant. > The homenet arch assumes the use of ULAs for internal communications > and stablity, and that ULA prefixes will be used in RAs. Alongside GUA > prefixes where they are also in use. > > It may be that certain home gateways generate their own ULA /48's. The > homenet arch talks about multiple ULA /48's potentially being in use. > >>> This is critical to certain 6LoWPAN applications such as home >>> automation. >>> Remote controls, sensors and wall controllers are spread all over >>> the house. >>> They control lights, garage doors and aircon devices. >> >> That doesn't mean that they don't need to support RA or that they >> cannot autoconfigure an address. There is no valid reason these >> devices should have burned-in ULA. Such an addressing scheme would, >> in fact, be quite dysfunctional. > > Do all 6lowpan devices support RA in the conventional sense? Or when > sleeping? > >>> The addresses of the lights, garage doors and aircon devices MUST >>> NOT change since the >>> remote controls, sensors and wall controllers are permanently paired >>> to the IPv6 addresses of >>> lights, garage doors and aircon devices on the application level. >> >> That's just really, REALLY bad application design. How do all of >> these ULA prefixes get properly routed when the devices are moved >> from one segment in the home to another? Do you add a giant layer of >> MIP complexity to the ULA in order to make that all work? >> >> The smaller devices need to be paired with the oversight >> application(s). Those application(s) should provide the required >> directory services for them to obtain the IPv6 address(es) of other >> devices they need to communicate with. (The oversight application >> could be as simple as a dynamic DNS server or as complex as a >> centralized home automation management application. Whether support >> for pairing with more than one oversight application is required is >> left as an exercise for the device manufacturers. > > So this would be the desired model of course, but what are the actual > constraints? > >>> Only ULA prefixes provide that stability, yet ability to route >>> within the home. >>> The lights, garage doors and aircon devices MAY also have global >>> prefixes for external use by >>> portals and advanced clients. >> >> ULA prefixes can't provide that stability, either. Burning a prefix >> into a device is just bad juju from start to end. >> >> It will lead to some of the same problems we have with similar >> systems in IPv4 where applications have built-in assumption that the >> network is not segmented and therefore do not function in >> environments where it is. >> >> If you burn a pre-determined ULA prefix into devices, then you either: >> 1) >> a)Presume all devices that should talk to each other are on the same >> link. >> b)Presume that all devices on the same link should talk to each other. >> c)Break installations where multiple parts of the system are on >> different segments. >> or >> 2) >> a)Require significant overhead and additional facilities (such as >> MIP) to make communication possible. >> b)Create unnecessary external dependencies >> c)Complicate and expand the codebase on resource constrained nodes. > > In case 1) above the "burnt in" ULA could potentially still > communicate across routers. I believe that's the case Anders refers to. > > But again, I agree that "burnt in" addresses are highly undesirable, > but are there scenarios where they are unavoidable? Perhaps we're > asking in the wrong list. > > Tim > >> >> Owen >> >>> Thanks, >>> Anders >>> *From:*v6ops-bounces@ietf.org >>> [mailto:v6ops-bounces@ietf.org ]*On Behalf >>> Of*Lorenzo Colitti >>> *Sent:*24. maj 2013 13:42 >>> *To:*Liubing (Leo) >>> *Cc:*v6ops@ietf.org ; >>> draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org >>> >>> *Subject:*Re: [v6ops] A brief intro-//RE: new draft: >>> draft-ietf-v6ops-ula-usage-recommendations >>> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) >>> > wrote: >>> >>> V. "the network needs ULA as the on-demand and stable >>> addressing which doesn't need much code to support >>> address assignment mechanisms like DHCP or ND." I don't >>> think this makes sense. Are you saying such nodes only >>> support manual address assignment? How is it possible >>> that a sensor doesn't support automatic address >>> assignment due to lack of resources, but has enough >>> resources to implement a UI for manual address assignment? >>> [Bing] The lack of resources mainly regarding the >>> network environment, there might not be a comprehensive >>> network provisioning environment for the nodes. If they >>> can be pre-configured with ULA, say, hard-coded in the >>> embedded system, like the MAC addresses in every single >>> NIC or self-generating a ULA, then they could make >>> ad-hoc networking without address provisioning procedures. >>> >>> How are those nodes going to find the MAC address of the >>> link router to communicate off-link? If they can't do this, >>> then you don't need ULA, you can just use link-local. If >>> they can do this, then they must support router >>> advertisements or similar. If they support router >>> advertisements, then they can use autoconfiguration. >>> [Bing] Surely they need to support SLAAC, it�s a basic IPv6 >>> function , the draft specifically noted this point. But if >>> the sensors are in a MANET, then the autoconfiguration is >>> different with the traditional wired SLAAC, since MANET is >>> based on a multi hop topology. ULA is suitable for this >>> scenario, however, current text seems not sufficient/clear, >>> will modify later. >>> >>> If they support SLAAC, then they don't need to be >>> pre-configured, because they can just use SLAAC to autoconfigure >>> addresses. And if they can autoconfigure an address, they can >>> use a global address. So there is no need to use ULA. >>> [Bing] The reasoning is flawed. Let�s do not mix the concepts of >>> global addr-provisioning and autoconfiguration together. >>> >>> Why is it flawed? You said that a use case for ULA is >>> resource-constrained nodes, because you can pre-assign addresses to >>> them, and that this simplifies the nodes. But it doesn't simplify >>> the nodes, because even if you pre-assign addresses, the nodes still >>> need some mechanism (e.g., RA) in order to find out who you can >>> communicate to. So the nodes have to support RAs. And if the nodes >>> support RA, you can use autoconfiguration and you don't need to >>> pre-assign addresses. So you can use any type of address, not only >>> ULA. So this is not a use case for ULA. >>> >>> And in MANET, the SLAAC is not (fully)applicable, >>> seehttp://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 >>> >>> That draft expired in 2008, so it's not really relevant. Do you have >>> a more up-to-date document? >>> >>> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) >>> > wrote: >>> Hi, Lorenzo >>> *From:*Lorenzo Colitti [mailto:lorenzo@google.com >>> ] >>> *Sent:*Friday, May 24, 2013 5:44 PM >>> >>> *To:*Liubing (Leo) >>> *Cc:*v6ops@ietf.org >>> ;draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org >>> >>> *Subject:*Re: [v6ops] A brief intro-//RE: new draft: >>> draft-ietf-v6ops-ula-usage-recommendations >>> On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) >>> > wrote: >>> >>> No, the probability is much higher than you think. See RFC 4193 >>> section 3.2.3. If I'm reading that section correctly, if you >>> generate 10000 ULAs you'll get a collision 1 in 500k times. If >>> you generate 100000 (e.g., if you regenerate them once a second, >>> for one day) you'll get a collision once in 1000 times. And so on. >>> [Bing] In theory, I agree with you. But the point here is where >>> do we need to change the ULA so frequently? For random draw? I >>> can hardly imagine a use case of that. >>> >>> This is a technical document meant to provide guidance, so I'd say >>> that it's not appropriate to use vague words like regularly >>> "regularly", without stating what they mean to state what it means. >>> Can I generate 10000 ULAs per second, as long as I do it >>> "regularly"? Likely not. >>> So you either remove the text, or state that if ULAs are generated >>> regularly, then collisions are possible, and perhaps provide provide >>> an example that calculates the probability of collision with some >>> reasonal value of the regeneration interval. >>> [Bing] OK, I�ll refine the word. >>> >>> V. "the network needs ULA as the on-demand and stable >>> addressing which doesn't need much code to support address >>> assignment mechanisms like DHCP or ND." I don't think this >>> makes sense. Are you saying such nodes only support manual >>> address assignment? How is it possible that a sensor doesn't >>> support automatic address assignment due to lack of >>> resources, but has enough resources to implement a UI for >>> manual address assignment? >>> [Bing] The lack of resources mainly regarding the network >>> environment, there might not be a comprehensive network >>> provisioning environment for the nodes. If they can be >>> pre-configured with ULA, say, hard-coded in the embedded >>> system, like the MAC addresses in every single NIC or >>> self-generating a ULA, then they could make ad-hoc >>> networking without address provisioning procedures. >>> >>> How are those nodes going to find the MAC address of the link >>> router to communicate off-link? If they can't do this, then you >>> don't need ULA, you can just use link-local. If they can do >>> this, then they must support router advertisements or similar. >>> If they support router advertisements, then they can use >>> autoconfiguration. >>> [Bing] Surely they need to support SLAAC, it�s a basic IPv6 >>> function , the draft specifically noted this point. But if the >>> sensors are in a MANET, then the autoconfiguration is different >>> with the traditional wired SLAAC, since MANET is based on a >>> multi hop topology. ULA is suitable for this scenario, however, >>> current text seems not sufficient/clear, will modify later. >>> >>> If they support SLAAC, then they don't need to be pre-configured, >>> because they can just use SLAAC to autoconfigure addresses. And if >>> they can autoconfigure an address, they can use a global address. So >>> there is no need to use ULA. >>> [Bing] The reasoning is flawed. Let�s do not mix the concepts of >>> global addr-provisioning and autoconfiguration together. And in >>> MANET, the SLAAC is not (fully)applicable, >>> seehttp://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 >>> >>> VI. "there always be some argument that in practice the >>> ULA+PA makes terrible operational complexity. But it is not >>> a ULA-specific problem; the multiple- >>> addresses-per-interface is an important feature of IPv6 >>> protocol. Running multiple prefixes in IPv6 might be very >>> common, and we need to adapt this new operational model than >>> that in IPv4." This text does not make sense. Just because >>> having multiple global-scope addresses is a feature of IPv6 >>> doesn't mean that you must have multiple global-scope >>> addresses. For example, you can use only global addresses >>> and have no routing complexity. >>> [Bing] The ULA+PA operational complexity contains two aspect. >>> One is the common issue as described in the texts, running >>> multiple prefixes in a network is new to the traditional >>> IPv4 model, the admins need to be familiar with it in the >>> future. >>> >>> No, because having multiple prefixes introduces operational >>> complexity even if the admins understand multiple prefixes. All >>> things being equal, having only one prefix (e.g., a global >>> prefix) is always going to be simpler than having two. >>> In other words: what you're saying is "let's create complexity, >>> because admins will need to understand the complexity anyway". >>> What I'm saying is that while they need to understand the >>> complexity, we don't have to create the complexity if we don't >>> need it. >>> [Bing] No, I�m not say that. ULA+PA is identified as beneficial >>> use case in 6renum and Homenet. So the admins need to adapt the >>> complexity if they want the benefit. >>> >>> Ok, so then just cite those documents, say that there is a trade off >>> between complexity and functionality, and leave it at that? >>> [Bing] A brief complexity hint would be valuable. Thanks. >>> B.R. >>> Bing >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Fri May 24 11:45:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE6A11E80E0 for ; Fri, 24 May 2013 11:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkLcs7eIJeUd for ; Fri, 24 May 2013 11:45:12 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6A98121F9051 for ; Fri, 24 May 2013 11:45:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4OIj9og001553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 May 2013 20:45:09 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4OIj9fv018029 for ; Fri, 24 May 2013 20:45:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4OIj5vB031940 for ; Fri, 24 May 2013 20:45:08 +0200 Message-ID: <519FB531.9050304@gmail.com> Date: Fri, 24 May 2013 20:45:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:45:17 -0000 Le 23/05/2013 23:08, Mark Smith a �crit : > Hi, > > > Suggested changes: > > > > 1. Introduction > > "... for delegating IPv6 prefixes to a LAN." > > > to > > ""... for delegating IPv6 prefixes to a single LAN interface." > > Generally I think this intro text should make it a bit clearer that > these methods are only extending the /64 to a single LAN interface. Yes. Moreover, it should be clear that this extension only works with only one level of extension (one cant have 64share-64share-... indefinitely, not even twice). > 3.1 Scenario 1: No Global Address on the UE > > "traffic destine" > > > - missing "d" on destined. Better say 'targeted' or 'addressed to'. Exchanged with peers addressable by. > "the UE (e.g. DNS caching that requires global connectivity) and > prevent proper Path MTU Discovery [RFC1981] to occur on the UE > providing an IPv6 router function." > > > Regarding breaking PMTUD, I wonder if it might be worth requiring > that the MTU of the LAN interface is made the same as that of the > 3GPP interface, and if it isn't the default for the LAN interface > (i.e., 1500 for ethernet), then the LAN interface RAs have the MTU > option set to the size of the 3GPP interface. I think that would > prevent the UE needing to participate in PMTUD. > > > "The UE copies the prefix 2001:db8:ac10:f002::/64 from the 3GPP > interface to the LAN interface," > > > I think it would be clearer if this text specified that this copying > of the /64 prefix was indicating the prefix was on-link, by adding > the prefix to the Prefix List, as per RFC5942, "IPv6 Subnet Model: > The Relationship between Links and Subnet Prefixes" > > > 3.2 Scenario 2: Global Address Only Assigned to LAN > > "The movement of the IPv6 prefix from the 3GPP radio interface to > the LAN interface may result in long-lived data connections being > terminated during the transition from a host-only mode to > router-and-host mode." > > > I'd suggest adding something like: > > "Connections which are likely to be effected are ones that have been > specifically bound to the 3GPP radio interface." One other way to think about this is the follozing: If for any reason the 3GPP UE changes its IPv6 address (disconnect and reconnect, because of short transitions, or other error) then it is highly likely that the IPv6 address changes, and its first 64 bits may change as well. At that point, it should be clear than any other address on the LAN that is formed by prefixing with these 64bits, as well as the address itself attached on UE's LAN interface, will change. This will certainly incur disruption in communication. This could go as far as to say that the 64share method works only for static UEs. It sounds negative, I know, but the reliability of this should be acknowledged. Yours, Alex > 3.3 Scenario 3: A Single Global Address Assigned to 3GPP Radio and > LAN Interface > > > > "This method also creates complications for ensuring uniqueness for > Privacy Extensions [RFC4941]. Privacy Extensions should be disabled > on the 3GPP radio interface while this method is enabled." > > > I think it would be better to advise that when privacy extensions > are in use, a single privacy address is generated, and then used as > the anycast address on both interfaces, and the preferred and valid > lifetimes are synchronised, such that the anycast addresses on both > interfaces expires at the exact same moment. > > Hmm, actually, there might be another more broader issue to consider > (broader than this specific scenario), regarding preferred and valid > lifetimes of the /64. What preferred and valid lifetimes are > supplied in the RAs by the 3G network, and should they be copied to > the LAN interface RAs? Another issue related to this is the > synchronised aging of the prefix on the 3GPP and LAN interfaces. In > the case of DHCPv6 PD, the preferred and valid lifetimes announced in > the LAN RAs are to be synchronised with the aging of the DHCPv6-PD > prefix, so that when the PD prefix expires, the addresses on the > hosts on the LAN expire at the same time. > > > HTH, Mark. _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Fri May 24 11:48:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E975D11E80F4 for ; Fri, 24 May 2013 11:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.349 X-Spam-Level: X-Spam-Status: No, score=-9.349 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBK04SBLsNzC for ; Fri, 24 May 2013 11:48:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 03C0821F949A for ; Fri, 24 May 2013 11:48:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4OImNhv006308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 May 2013 20:48:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4OImNYe018366 for ; Fri, 24 May 2013 20:48:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4OImMwX032547 for ; Fri, 24 May 2013 20:48:23 +0200 Message-ID: <519FB5F6.6010103@gmail.com> Date: Fri, 24 May 2013 20:48:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:48:33 -0000 Le 24/05/2013 13:42, Lorenzo Colitti a �crit : > On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > wrote: > > V. "the network needs ULA as the on-demand and stable > addressing which doesn't need much code to support address > assignment mechanisms like DHCP or ND." I don't think this > makes sense. Are you saying such nodes only support manual > address assignment? How is it possible that a sensor doesn't > support automatic address assignment due to lack of > resources, but has enough resources to implement a UI for > manual address assignment?____ > > [Bing] The lack of resources mainly regarding the network > environment, there might not be a comprehensive network > provisioning environment for the nodes. If they can be > pre-configured with ULA, say, hard-coded in the embedded > system, like the MAC addresses in every single NIC or > self-generating a ULA, then they could make ad-hoc > networking without address provisioning procedures.____ > > How are those nodes going to find the MAC address of the link > router to communicate off-link? If they can't do this, then you > don't need ULA, you can just use link-local. If they can do > this, then they must support router advertisements or similar. > If they support router advertisements, then they can use > autoconfiguration. ____ > > [Bing] Surely they need to support SLAAC, it�s a basic IPv6 > function , the draft specifically noted this point. But if the > sensors are in a MANET, then the autoconfiguration is different > with the traditional wired SLAAC, since MANET is based on a > multi hop topology. ULA is suitable for this scenario, however, > current text seems not sufficient/clear, will modify later.____ > > __ __ > > If they support SLAAC, then they don't need to be pre-configured, > because they can just use SLAAC to autoconfigure addresses. And if > they can autoconfigure an address, they can use a global address. So > there is no need to use ULA.____ > > __ __ > > [Bing] The reasoning is flawed. Let�s do not mix the concepts of > global addr-provisioning and autoconfiguration together. > > > Why is it flawed? You said that a use case for ULA is > resource-constrained nodes, because you can pre-assign addresses to > them, and that this simplifies the nodes. But it doesn't simplify the > nodes, because even if you pre-assign addresses, the nodes still need > some mechanism (e.g., RA) in order to find out who you can communicate > to. So the nodes have to support RAs. And if the nodes support RA, you > can use autoconfiguration and you don't need to pre-assign addresses. So > you can use any type of address, not only ULA. So this is not a use case > for ULA. RA could be used to just communicate the default route, not the link prefix - that makes for a smaller RA which is ok for constrained devices. Actually, RA may not be needed at all for a constrained device. You could have a constrained device that just knows its default route. Alex > > And in MANET, the SLAAC is not (fully)applicable, see > http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 > > > That draft expired in 2008, so it's not really relevant. Do you have a > more up-to-date document? > > > On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > wrote: > > Hi, Lorenzo____ > > __ __ > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com > ] > *Sent:* Friday, May 24, 2013 5:44 PM > > > *To:* Liubing (Leo) > *Cc:* v6ops@ietf.org ; > draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > > *Subject:* Re: [v6ops] A brief intro-//RE: new draft: > draft-ietf-v6ops-ula-usage-recommendations____ > > __ __ > > On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > > wrote:____ > > No, the probability is much higher than you think. See RFC 4193 > section 3.2.3. If I'm reading that section correctly, if you > generate 10000 ULAs you'll get a collision 1 in 500k times. If > you generate 100000 (e.g., if you regenerate them once a second, > for one day) you'll get a collision once in 1000 times. And so > on.____ > > [Bing] In theory, I agree with you. But the point here is where > do we need to change the ULA so frequently? For random draw? I > can hardly imagine a use case of that.____ > > __ __ > > This is a technical document meant to provide guidance, so I'd say > that it's not appropriate to use vague words like regularly > "regularly", without stating what they mean to state what it means. > Can I generate 10000 ULAs per second, as long as I do it > "regularly"? Likely not.____ > > __ __ > > So you either remove the text, or state that if ULAs are generated > regularly, then collisions are possible, and perhaps provide provide > an example that calculates the probability of collision with some > reasonal value of the regeneration interval.____ > > __ __ > > [Bing] OK, I�ll refine the word.____ > > __ __ > > V. "the network needs ULA as the on-demand and stable > addressing which doesn't need much code to support address > assignment mechanisms like DHCP or ND." I don't think this > makes sense. Are you saying such nodes only support manual > address assignment? How is it possible that a sensor doesn't > support automatic address assignment due to lack of > resources, but has enough resources to implement a UI for > manual address assignment?____ > > [Bing] The lack of resources mainly regarding the network > environment, there might not be a comprehensive network > provisioning environment for the nodes. If they can be > pre-configured with ULA, say, hard-coded in the embedded > system, like the MAC addresses in every single NIC or > self-generating a ULA, then they could make ad-hoc > networking without address provisioning procedures.____ > > How are those nodes going to find the MAC address of the link > router to communicate off-link? If they can't do this, then you > don't need ULA, you can just use link-local. If they can do > this, then they must support router advertisements or similar. > If they support router advertisements, then they can use > autoconfiguration. ____ > > [Bing] Surely they need to support SLAAC, it�s a basic IPv6 > function , the draft specifically noted this point. But if the > sensors are in a MANET, then the autoconfiguration is different > with the traditional wired SLAAC, since MANET is based on a > multi hop topology. ULA is suitable for this scenario, however, > current text seems not sufficient/clear, will modify later.____ > > __ __ > > If they support SLAAC, then they don't need to be pre-configured, > because they can just use SLAAC to autoconfigure addresses. And if > they can autoconfigure an address, they can use a global address. So > there is no need to use ULA.____ > > __ __ > > [Bing] The reasoning is flawed. Let�s do not mix the concepts of > global addr-provisioning and autoconfiguration together. And in > MANET, the SLAAC is not (fully)applicable, see > http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2____ > > __ __ > > VI. "there always be some argument that in practice the > ULA+PA makes terrible operational complexity. But it is not > a ULA-specific problem; the multiple- > addresses-per-interface is an important feature of IPv6 > protocol. Running multiple prefixes in IPv6 might be very > common, and we need to adapt this new operational model than > that in IPv4." This text does not make sense. Just because > having multiple global-scope addresses is a feature of IPv6 > doesn't mean that you must have multiple global-scope > addresses. For example, you can use only global addresses > and have no routing complexity.____ > > [Bing] The ULA+PA operational complexity contains two > aspect.____ > > One is the common issue as described in the texts, running > multiple prefixes in a network is new to the traditional > IPv4 model, the admins need to be familiar with it in the > future.____ > > No, because having multiple prefixes introduces operational > complexity even if the admins understand multiple prefixes. All > things being equal, having only one prefix (e.g., a global > prefix) is always going to be simpler than having two.____ > > ____ > > In other words: what you're saying is "let's create complexity, > because admins will need to understand the complexity anyway". > What I'm saying is that while they need to understand the > complexity, we don't have to create the complexity if we don't > need it.____ > > [Bing] No, I�m not say that. ULA+PA is identified as beneficial > use case in 6renum and Homenet. So the admins need to adapt the > complexity if they want the benefit.____ > > __ __ > > Ok, so then just cite those documents, say that there is a trade off > between complexity and functionality, and leave it at that?____ > > [Bing] A brief complexity hint would be valuable. Thanks.____ > > __ __ > > B.R.____ > > Bing____ > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Fri May 24 11:49:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4006511E8103 for ; Fri, 24 May 2013 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ranGNeGuWuBe for ; Fri, 24 May 2013 11:49:23 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C46BE11E8100 for ; Fri, 24 May 2013 11:49:23 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4OIjx3u008832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 May 2013 11:46:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4OIjx3u008832 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369421160; bh=RaCJ8qAiOBvrG3LuT4ATowdlTFw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=rz0yUeUwXJ/8WcYgH+5wf7C+DyVPOfqk/qgESgPP2JJ0GmFXb3I9JECix/k87G015 aL5FyARtDcmx6Gximr+MCnjuyAewCTWkLUx7QdfDaf2DEuiUPk1cS4mt4SpXGJ1qvu 7oMJY5Hfv2Oyfa0x90oqun7fuInFrOut4ZZKXJuU= Content-Type: multipart/alternative; boundary="Apple-Mail=_2DD8BB2D-1603-4D7B-9B0B-E79782AE375A" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: Date: Fri, 24 May 2013 11:45:59 -0700 Message-Id: <5FBB6723-BAB6-4345-9822-8B638E27CBE0@delong.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> To: Tim Chown X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 24 May 2013 11:46:00 -0700 (PDT) Cc: v6ops@ietf.org, draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:49:25 -0000 --Apple-Mail=_2DD8BB2D-1603-4D7B-9B0B-E79782AE375A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 24, 2013, at 11:21 , Tim Chown wrote: > In-line... >=20 > On 24 May 2013, at 16:53, Owen DeLong wrote: >=20 >>=20 >> On May 24, 2013, at 05:30 , Anders Brandt = wrote: >>=20 >>> Hi Lorenzo >>> =20 >>> > So you can use any type of address, not only ULA. So this is not a = use case for ULA. >>> =20 >>> The ULA reasoning starts elsewhere. It is tied to a deployment use = case: >>> =20 >>> When nodes are installed in a new house, there may be no internet = connectivity - and even more importantly: >>> Even if there is internet connectivity, then you can be certain that = at some time, the ISP will change your >>> assigned prefix. >>=20 >> Why can you be certain of that? I understand why you cannot be = certain that they won't. But I do not understand or believe that you can = be certain that they will. >>=20 >> However, even in such a case, the router should provide the ULA in an = RA. There is no need to preconfigure ULA into the node in question = rather than use autoconfiguration. >=20 > So in the homenet context we're listening to what the people building = the constrained devices are telling us. >=20 > The ISPs are saying that it is very unlikely that the homenet's prefix = will be persistent. Certainly not in all cases. >=20 Correct... This means that you cannot count on it persisting. I agree. That is not the same as being able to count on it changing. There will = be cases where it does not change. For example, my home has a direct = ARIN IPv6 assignment. I realize this is not necessarily the norm, but = it's also not out of the question. Many other homes I know of subscribe = to business class services in order to get persistent addressing. I have = no reason to believe this practice will be less common in the future. > The homenet arch assumes the use of ULAs for internal communications = and stablity, and that ULA prefixes will be used in RAs. Alongside GUA = prefixes where they are also in use. Understood. I think it's a horrible assumption (per my previous = example), but I understand the reasoning behind it. > It may be that certain home gateways generate their own ULA /48's. The = homenet arch talks about multiple ULA /48's potentially being in use. >=20 Sure. >>> This is critical to certain 6LoWPAN applications such as home = automation. >>> Remote controls, sensors and wall controllers are spread all over = the house. >>> They control lights, garage doors and aircon devices. >>=20 >> That doesn't mean that they don't need to support RA or that they = cannot autoconfigure an address. There is no valid reason these devices = should have burned-in ULA. Such an addressing scheme would, in fact, be = quite dysfunctional. >=20 > Do all 6lowpan devices support RA in the conventional sense? Or when = sleeping? >=20 I don't know. Certainly, they should support RA. They don't really need = to do so when sleeping as they can send an RS when they wake up if = necessary. >>> The addresses of the lights, garage doors and aircon devices MUST = NOT change since the >>> remote controls, sensors and wall controllers are permanently paired = to the IPv6 addresses of >>> lights, garage doors and aircon devices on the application level. >>=20 >> That's just really, REALLY bad application design. How do all of = these ULA prefixes get properly routed when the devices are moved from = one segment in the home to another? Do you add a giant layer of MIP = complexity to the ULA in order to make that all work? >>=20 >> The smaller devices need to be paired with the oversight = application(s). Those application(s) should provide the required = directory services for them to obtain the IPv6 address(es) of other = devices they need to communicate with. (The oversight application could = be as simple as a dynamic DNS server or as complex as a centralized home = automation management application. Whether support for pairing with more = than one oversight application is required is left as an exercise for = the device manufacturers. >=20 > So this would be the desired model of course, but what are the actual = constraints? >=20 I don't know. My point is that I don't believe the IETF should be = designing RFCs around the brokenness of current designs. Rather we = should document the reasons such designs are broken and encourage the = vendors to make appropriate changes. >>> Only ULA prefixes provide that stability, yet ability to route = within the home. >>> The lights, garage doors and aircon devices MAY also have global = prefixes for external use by >>> portals and advanced clients. >>=20 >> ULA prefixes can't provide that stability, either. Burning a prefix = into a device is just bad juju from start to end. >>=20 >> It will lead to some of the same problems we have with similar = systems in IPv4 where applications have built-in assumption that the = network is not segmented and therefore do not function in environments = where it is. >>=20 >> If you burn a pre-determined ULA prefix into devices, then you = either: >> 1) >> a) Presume all devices that should talk to each = other are on the same link. >> b) Presume that all devices on the same link should = talk to each other. >> c) Break installations where multiple parts of the = system are on different segments. >> or >> 2) >> a) Require significant overhead and additional = facilities (such as MIP) to make communication possible. >> b) Create unnecessary external dependencies >> c) Complicate and expand the codebase on resource = constrained nodes. >=20 > In case 1) above the "burnt in" ULA could potentially still = communicate across routers. I believe that's the case Anders refers to. >=20 Only if the ULA is different on each device and the router somehow = learns how to route all those prefixes. Otherwise, you run into the following two problems: 1. Multiple devices with the same prefix not on the same = network. 2. Multiple devices with different prefixes unable to = recognize each other on the same network. > But again, I agree that "burnt in" addresses are highly undesirable, = but are there scenarios where they are unavoidable? Perhaps we're asking = in the wrong list. No, there are no scenarios where they are legitimately unavoidable if = routing is required. If you have a device that needs to have a BIA, then the BIA should be = link-local only and the device should either use RA or some other = mechanism to learn how to communicate off-link if necessary. Owen --Apple-Mail=_2DD8BB2D-1603-4D7B-9B0B-E79782AE375A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 tjc@ecs.soton.ac.uk> = wrote:

owen@delong.com> wrote:

Anders_Brandt@sigmadesigns.= com> wrote:

Hi = Lorenzo

> So you can use any type of address, not only = ULA. So this is not a use case for ULA.

The ULA reasoning starts = elsewhere. It is tied to a deployment use = case:

When nodes are installed in a new house, there = may be no internet connectivity - and even more importantly:
Even if = there is internet connectivity, then you can be certain that at some = time, the ISP will change your
assigned = prefix.

Why can you = be certain of that? I understand why you cannot be certain that they = won't. But I do not understand or believe that you can be certain that = they will.

However, even in such a case, the = router should provide the ULA in an RA. There is no need to preconfigure = ULA into the node in question rather than use = autoconfiguration.

So in the = homenet context we're listening to what the people building the = constrained devices are telling us.

The ISPs = are saying that it is very unlikely that the homenet's prefix will be = persistent. Certainly not in all = cases.

Correct... This means that = you cannot count on it persisting. I = agree.

That is not the same as being able to = count on it changing. There will be cases where it does not change. For = example, my home has a direct ARIN IPv6 assignment. I realize this is = not necessarily the norm, but it's also not out of the question. Many = other homes I know of subscribe to business class services in order to = get persistent addressing. I have no reason to believe this practice = will be less common in the future.

The homenet arch = assumes the use of ULAs for internal communications and stablity, and = that ULA prefixes will be used in RAs. Alongside GUA prefixes = where they are also in = use.

Understood. I think it's a = horrible assumption (per my previous example), but I understand the = reasoning behind it.

It may be that certain = home gateways generate their own ULA /48's. The homenet arch talks about = multiple ULA /48's potentially being in = use.

Sure.

This is critical to certain 6LoWPAN applications = such as home automation.
Remote controls, sensors and wall = controllers are spread all over the house.
They control lights, = garage doors and aircon = devices.

That = doesn't mean that they don't need to support RA or that they cannot = autoconfigure an address. There is no valid reason these devices should = have burned-in ULA. Such an addressing scheme would, in fact, be quite = dysfunctional.

Do all 6lowpan devices = support RA in the conventional sense? Or when = sleeping?

I don't = know. Certainly, they should support RA. They don't really need to do so = when sleeping as they can send an RS when they wake up if = necessary.

The addresses of = the lights, garage doors and aircon devices MUST NOT change since = the
remote = controls, sensors and wall controllers are permanently paired to the = IPv6 addresses of
lights, garage doors and aircon devices on the = application = level.

That's just = really, REALLY bad application design. How do all of these ULA prefixes = get properly routed when the devices are moved from one segment in the = home to another? Do you add a giant layer of MIP complexity to the ULA = in order to make that all work?

The smaller = devices need to be paired with the oversight application(s). Those = application(s) should provide the required directory services for them = to obtain the IPv6 address(es) of other devices they need to communicate = with. (The oversight application could be as simple as a dynamic DNS = server or as complex as a centralized home automation management = application. Whether support for pairing with more than one oversight = application is required is left as an exercise for the device = manufacturers.

So this would be = the desired model of course, but what are the actual = constraints?

I = don't know. My point is that I don't believe the IETF should be = designing RFCs around the brokenness of current designs. Rather we = should document the reasons such designs are broken and encourage the = vendors to make appropriate changes.

Only ULA prefixes provide that = stability, yet ability to route within the = home.
The lights, garage doors and aircon devices MAY also have = global prefixes for external use by
portals and advanced = clients.

ULA = prefixes can't provide that stability, either. Burning a prefix into a = device is just bad juju from start to end.

It = will lead to some of the same problems we have with similar systems in = IPv4 where applications have built-in assumption that the network is not = segmented and therefore do not function in environments where it = is.

If you burn a pre-determined ULA prefix = into devices, then you either:
1)
= a) = Presume all devices that should talk to each other are on the = same link.
b) Presume = that all devices on the same link should talk to each = other.
= c) Break installations where = multiple parts of the system are on different = segments.
or
2)
= a) = Require significant overhead and additional facilities (such as = MIP) to make communication possible.
= b) = Create unnecessary external dependencies
= c) = Complicate and expand the codebase on resource constrained = nodes.

In case 1) above the = "burnt in" ULA could potentially still communicate across routers. I = believe that's the case Anders refers = to.

Only if = the ULA is different on each device and the router somehow learns how to = route all those prefixes.

Otherwise, you run = into the following two problems:

1. Multiple = devices with the same prefix not on the same network.
2. Multiple = devices with different prefixes unable to recognize each other on the = same network.

But again, I agree that = "burnt in" addresses are highly undesirable, but are there scenarios = where they are unavoidable? Perhaps we're asking in the wrong = list.

No, there are no scenarios = where they are legitimately unavoidable if routing is = required.

If you have a device that needs to = have a BIA, then the BIA should be link-local only and the device should = either use RA or some other mechanism to learn how to communicate = off-link if = necessary.

Owen

= --Apple-Mail=_2DD8BB2D-1603-4D7B-9B0B-E79782AE375A-- From alexandru.petrescu@gmail.com Fri May 24 11:51:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613FB21F9601 for ; Fri, 24 May 2013 11:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.749 X-Spam-Level: X-Spam-Status: No, score=-7.749 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kysj-qYW0VNk for ; Fri, 24 May 2013 11:51:20 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id DA64021F95FB for ; Fri, 24 May 2013 11:51:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4OIp7uN002753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 May 2013 20:51:07 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4OIp66q018651 for ; Fri, 24 May 2013 20:51:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4OIp5NF018515 for ; Fri, 24 May 2013 20:51:06 +0200 Message-ID: <519FB699.6060708@gmail.com> Date: Fri, 24 May 2013 20:51:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> In-Reply-To: <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:51:26 -0000 Le 24/05/2013 17:53, Owen DeLong a �crit : > > On May 24, 2013, at 05:30 , Anders Brandt > > > wrote: > >> Hi Lorenzo >> > So you can use any type of address, not only ULA. So this is not a use case for ULA. >> The ULA reasoning starts elsewhere. It is tied to a deployment use case: >> When nodes are installed in a new house, there may be no internet >> connectivity - and even more importantly: >> Even if there is internet connectivity, then you can be certain that >> at some time, the ISP will change your >> assigned prefix. > > Why can you be certain of that? I understand why you cannot be certain > that they won't. But I do not understand or believe that you can be > certain that they will. > > However, even in such a case, the router should provide the ULA in an > RA. There is no need to preconfigure ULA into the node in question > rather than use autoconfiguration. > >> This is critical to certain 6LoWPAN applications such as home automation. >> Remote controls, sensors and wall controllers are spread all over the >> house. >> They control lights, garage doors and aircon devices. > > That doesn't mean that they don't need to support RA or that they cannot > autoconfigure an address. There is no valid reason these devices should > have burned-in ULA. Such an addressing scheme would, in fact, be quite > dysfunctional. Not sure what you mean. But sure a device which has its address pre-configured could go very far in reducing its memory/cpu print. Alex > >> The addresses of the lights, garage doors and aircon devices MUST NOT >> change since the >> remote controls, sensors and wall controllers are permanently paired >> to the IPv6 addresses of >> lights, garage doors and aircon devices on the application level. > > That's just really, REALLY bad application design. How do all of these > ULA prefixes get properly routed when the devices are moved from one > segment in the home to another? Do you add a giant layer of MIP > complexity to the ULA in order to make that all work? > > The smaller devices need to be paired with the oversight application(s). ? Its sufficient for the remote apps to be preconfigured with the devices' addresses, no need to preconfigure the other way around. > Those application(s) should provide the required directory services for > them to obtain the IPv6 address(es) of other devices they need to > communicate with. (The oversight application could be as simple as a > dynamic DNS server or as complex as a centralized home automation > management application. Whether support for pairing with more than one > oversight application is required is left as an exercise for the device > manufacturers. Its a way of doing it. And there are other simpler ways. Alex > >> Only ULA prefixes provide that stability, yet ability to route within >> the home. >> The lights, garage doors and aircon devices MAY also have global >> prefixes for external use by >> portals and advanced clients. > > ULA prefixes can't provide that stability, either. Burning a prefix into > a device is just bad juju from start to end. > > It will lead to some of the same problems we have with similar systems > in IPv4 where applications have built-in assumption that the network is > not segmented and therefore do not function in environments where it is. > > If you burn a pre-determined ULA prefix into devices, then you either: > 1) > a)Presume all devices that should talk to each other are on the same link. > b)Presume that all devices on the same link should talk to each other. > c)Break installations where multiple parts of the system are on > different segments. > or > 2) > a)Require significant overhead and additional facilities (such as MIP) > to make communication possible. > b)Create unnecessary external dependencies > c)Complicate and expand the codebase on resource constrained nodes. > > Owen > >> Thanks, >> Anders >> *From:*v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org ]*On Behalf >> Of*Lorenzo Colitti >> *Sent:*24. maj 2013 13:42 >> *To:*Liubing (Leo) >> *Cc:*v6ops@ietf.org ; >> draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org >> >> *Subject:*Re: [v6ops] A brief intro-//RE: new draft: >> draft-ietf-v6ops-ula-usage-recommendations >> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > > wrote: >> >> V. "the network needs ULA as the on-demand and stable >> addressing which doesn't need much code to support address >> assignment mechanisms like DHCP or ND." I don't think this >> makes sense. Are you saying such nodes only support manual >> address assignment? How is it possible that a sensor >> doesn't support automatic address assignment due to lack >> of resources, but has enough resources to implement a UI >> for manual address assignment? >> [Bing] The lack of resources mainly regarding the network >> environment, there might not be a comprehensive network >> provisioning environment for the nodes. If they can be >> pre-configured with ULA, say, hard-coded in the embedded >> system, like the MAC addresses in every single NIC or >> self-generating a ULA, then they could make ad-hoc >> networking without address provisioning procedures. >> >> How are those nodes going to find the MAC address of the link >> router to communicate off-link? If they can't do this, then >> you don't need ULA, you can just use link-local. If they can >> do this, then they must support router advertisements or >> similar. If they support router advertisements, then they can >> use autoconfiguration. >> [Bing] Surely they need to support SLAAC, it�s a basic IPv6 >> function , the draft specifically noted this point. But if >> the sensors are in a MANET, then the autoconfiguration is >> different with the traditional wired SLAAC, since MANET is >> based on a multi hop topology. ULA is suitable for this >> scenario, however, current text seems not sufficient/clear, >> will modify later. >> >> If they support SLAAC, then they don't need to be pre-configured, >> because they can just use SLAAC to autoconfigure addresses. And if >> they can autoconfigure an address, they can use a global address. >> So there is no need to use ULA. >> [Bing] The reasoning is flawed. Let�s do not mix the concepts of >> global addr-provisioning and autoconfiguration together. >> >> Why is it flawed? You said that a use case for ULA is >> resource-constrained nodes, because you can pre-assign addresses to >> them, and that this simplifies the nodes. But it doesn't simplify the >> nodes, because even if you pre-assign addresses, the nodes still need >> some mechanism (e.g., RA) in order to find out who you can communicate >> to. So the nodes have to support RAs. And if the nodes support RA, you >> can use autoconfiguration and you don't need to pre-assign addresses. >> So you can use any type of address, not only ULA. So this is not a use >> case for ULA. >> >> And in MANET, the SLAAC is not (fully)applicable, >> seehttp://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 >> >> That draft expired in 2008, so it's not really relevant. Do you have a >> more up-to-date document? >> >> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > > wrote: >> Hi, Lorenzo >> *From:*Lorenzo Colitti [mailto:lorenzo@google.com >> ] >> *Sent:*Friday, May 24, 2013 5:44 PM >> >> *To:*Liubing (Leo) >> *Cc:*v6ops@ietf.org >> ;draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org >> >> *Subject:*Re: [v6ops] A brief intro-//RE: new draft: >> draft-ietf-v6ops-ula-usage-recommendations >> On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > > wrote: >> >> No, the probability is much higher than you think. See RFC 4193 >> section 3.2.3. If I'm reading that section correctly, if you >> generate 10000 ULAs you'll get a collision 1 in 500k times. If you >> generate 100000 (e.g., if you regenerate them once a second, for >> one day) you'll get a collision once in 1000 times. And so on. >> [Bing] In theory, I agree with you. But the point here is where do >> we need to change the ULA so frequently? For random draw? I can >> hardly imagine a use case of that. >> >> This is a technical document meant to provide guidance, so I'd say >> that it's not appropriate to use vague words like regularly >> "regularly", without stating what they mean to state what it means. >> Can I generate 10000 ULAs per second, as long as I do it "regularly"? >> Likely not. >> So you either remove the text, or state that if ULAs are generated >> regularly, then collisions are possible, and perhaps provide provide >> an example that calculates the probability of collision with some >> reasonal value of the regeneration interval. >> [Bing] OK, I�ll refine the word. >> >> V. "the network needs ULA as the on-demand and stable >> addressing which doesn't need much code to support address >> assignment mechanisms like DHCP or ND." I don't think this >> makes sense. Are you saying such nodes only support manual >> address assignment? How is it possible that a sensor doesn't >> support automatic address assignment due to lack of resources, >> but has enough resources to implement a UI for manual address >> assignment? >> [Bing] The lack of resources mainly regarding the network >> environment, there might not be a comprehensive network >> provisioning environment for the nodes. If they can be >> pre-configured with ULA, say, hard-coded in the embedded >> system, like the MAC addresses in every single NIC or >> self-generating a ULA, then they could make ad-hoc networking >> without address provisioning procedures. >> >> How are those nodes going to find the MAC address of the link >> router to communicate off-link? If they can't do this, then you >> don't need ULA, you can just use link-local. If they can do this, >> then they must support router advertisements or similar. If they >> support router advertisements, then they can use autoconfiguration. >> [Bing] Surely they need to support SLAAC, it�s a basic IPv6 >> function , the draft specifically noted this point. But if the >> sensors are in a MANET, then the autoconfiguration is different >> with the traditional wired SLAAC, since MANET is based on a multi >> hop topology. ULA is suitable for this scenario, however, current >> text seems not sufficient/clear, will modify later. >> >> If they support SLAAC, then they don't need to be pre-configured, >> because they can just use SLAAC to autoconfigure addresses. And if >> they can autoconfigure an address, they can use a global address. So >> there is no need to use ULA. >> [Bing] The reasoning is flawed. Let�s do not mix the concepts of >> global addr-provisioning and autoconfiguration together. And in MANET, >> the SLAAC is not (fully)applicable, >> seehttp://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 >> >> VI. "there always be some argument that in practice the ULA+PA >> makes terrible operational complexity. But it is not a >> ULA-specific problem; the multiple- addresses-per-interface is >> an important feature of IPv6 protocol. Running multiple >> prefixes in IPv6 might be very common, and we need to adapt >> this new operational model than that in IPv4." This text does >> not make sense. Just because having multiple global-scope >> addresses is a feature of IPv6 doesn't mean that you must have >> multiple global-scope addresses. For example, you can use only >> global addresses and have no routing complexity. >> [Bing] The ULA+PA operational complexity contains two aspect. >> One is the common issue as described in the texts, running >> multiple prefixes in a network is new to the traditional IPv4 >> model, the admins need to be familiar with it in the future. >> >> No, because having multiple prefixes introduces operational >> complexity even if the admins understand multiple prefixes. All >> things being equal, having only one prefix (e.g., a global prefix) >> is always going to be simpler than having two. >> In other words: what you're saying is "let's create complexity, >> because admins will need to understand the complexity anyway". >> What I'm saying is that while they need to understand the >> complexity, we don't have to create the complexity if we don't >> need it. >> [Bing] No, I�m not say that. ULA+PA is identified as beneficial >> use case in 6renum and Homenet. So the admins need to adapt the >> complexity if they want the benefit. >> >> Ok, so then just cite those documents, say that there is a trade off >> between complexity and functionality, and leave it at that? >> [Bing] A brief complexity hint would be valuable. Thanks. >> B.R. >> Bing >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From gert@space.net Fri May 24 13:36:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1642511E8121 for ; Fri, 24 May 2013 13:36:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QArEi6QEjZtQ for ; Fri, 24 May 2013 13:36:18 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1EA11E811F for ; Fri, 24 May 2013 13:36:17 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9209E60708 for ; Fri, 24 May 2013 22:36:15 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5DC94606F6 for ; Fri, 24 May 2013 22:36:15 +0200 (CEST) Received: (qmail 81643 invoked by uid 1007); 24 May 2013 22:36:15 +0200 Date: Fri, 24 May 2013 22:36:15 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20130524203615.GW2504@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519FB699.6060708@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 20:36:19 -0000 Hi, On Fri, May 24, 2013 at 08:51:05PM +0200, Alexandru Petrescu wrote: > > That doesn't mean that they don't need to support RA or that they cannot > > autoconfigure an address. There is no valid reason these devices should > > have burned-in ULA. Such an addressing scheme would, in fact, be quite > > dysfunctional. > > Not sure what you mean. > > But sure a device which has its address pre-configured could go very far > in reducing its memory/cpu print. As could a device without a network stack. Your point being? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From alexandru.petrescu@gmail.com Fri May 24 13:39:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EF411E8121 for ; Fri, 24 May 2013 13:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.424 X-Spam-Level: X-Spam-Status: No, score=-9.424 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPSZefBTxVwy for ; Fri, 24 May 2013 13:39:19 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 73F7811E811F for ; Fri, 24 May 2013 13:39:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4OKdHxg004334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 22:39:17 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4OKdHL3030609; Fri, 24 May 2013 22:39:17 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4OKdAO2023087; Fri, 24 May 2013 22:39:17 +0200 Message-ID: <519FCFEE.5030308@gmail.com> Date: Fri, 24 May 2013 22:39:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> <20130524203615.GW2504@Space.Net> In-Reply-To: <20130524203615.GW2504@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 20:39:26 -0000 Le 24/05/2013 22:36, Gert Doering a �crit : > Hi, > > On Fri, May 24, 2013 at 08:51:05PM +0200, Alexandru Petrescu wrote: >>> That doesn't mean that they don't need to support RA or that they >>> cannot autoconfigure an address. There is no valid reason these >>> devices should have burned-in ULA. Such an addressing scheme >>> would, in fact, be quite dysfunctional. >> >> Not sure what you mean. >> >> But sure a device which has its address pre-configured could go >> very far in reducing its memory/cpu print. > > As could a device without a network stack. > > Your point being? My point being that ULA could be very much appropriated for constrained devices (without SLAAC) - and yet have a network stack. Alex > > Gert Doering -- NetMaster > From joelja@bogus.com Fri May 24 14:11:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7F11E80C5 for ; Fri, 24 May 2013 14:11:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP-3ZkHT+Ukc for ; Fri, 24 May 2013 14:11:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4C211E80AD for ; Fri, 24 May 2013 14:11:28 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4OLBPvC053268 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 24 May 2013 21:11:26 GMT (envelope-from joelja@bogus.com) Message-ID: <519FD778.7060807@bogus.com> Date: Fri, 24 May 2013 14:11:20 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Gert Doering , Alexandru Petrescu References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> <20130524203615.GW2504@Space.Net> In-Reply-To: <20130524203615.GW2504@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 24 May 2013 21:11:26 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:11:29 -0000 On 5/24/13 1:36 PM, Gert Doering wrote: > Hi, > > On Fri, May 24, 2013 at 08:51:05PM +0200, Alexandru Petrescu wrote: >>> That doesn't mean that they don't need to support RA or that they cannot >>> autoconfigure an address. There is no valid reason these devices should >>> have burned-in ULA. Such an addressing scheme would, in fact, be quite >>> dysfunctional. >> Not sure what you mean. >> >> But sure a device which has its address pre-configured could go very far >> in reducing its memory/cpu print. A decade ago dallas-semiconductor had a working v6 stack on a 8051 based 8 bit microcontroller with 64k of rom... There seems to be small but quite persistent faction that insists on the notion that functionally limited systems are incapable of operating around the incredibly basic set of functional building blocks for an ipv6 network on their link-layer of choice. Frankly I don't see it. IETF participants have invested a lot of productive time and energy in low-power/low signalling/low bandwidth embedded networking, stripping out the things that make it flexible robust and easy to deploy in the interest of something that might notionally be more compact then the toolkit we have at present, seems incredibly limiting. Can you do it? Sure. In fact, nobody is going to stop you. Is it an "improvement"? Maybe by some measure, but I kind of doubt it. > As could a device without a network stack. > > Your point being? > > Gert Doering > -- NetMaster From alexandru.petrescu@gmail.com Fri May 24 14:20:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A143E11E80F6 for ; Fri, 24 May 2013 14:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJuCn6tKUPoR for ; Fri, 24 May 2013 14:19:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id CC40921F9446 for ; Fri, 24 May 2013 14:19:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4OLJmv5032440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 May 2013 23:19:49 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4OLJmdI002707; Fri, 24 May 2013 23:19:48 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4OLJjxh028587; Fri, 24 May 2013 23:19:48 +0200 Message-ID: <519FD971.7040608@gmail.com> Date: Fri, 24 May 2013 23:19:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: joel jaeggli References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> <20130524203615.GW2504@Space.Net> <519FD778.7060807@bogus.com> In-Reply-To: <519FD778.7060807@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:20:01 -0000 Le 24/05/2013 23:11, joel jaeggli a �crit : > On 5/24/13 1:36 PM, Gert Doering wrote: >> Hi, >> >> On Fri, May 24, 2013 at 08:51:05PM +0200, Alexandru Petrescu wrote: >>>> That doesn't mean that they don't need to support RA or that they >>>> cannot >>>> autoconfigure an address. There is no valid reason these devices should >>>> have burned-in ULA. Such an addressing scheme would, in fact, be quite >>>> dysfunctional. >>> Not sure what you mean. >>> >>> But sure a device which has its address pre-configured could go very far >>> in reducing its memory/cpu print. > A decade ago dallas-semiconductor had a working v6 stack on a 8051 based > 8 bit microcontroller with 64k of rom... That was then. Since then even smaller platforms are tried. > There seems to be small but quite persistent faction that insists on the > notion that functionally limited systems are incapable of operating > around the incredibly basic set of functional building blocks for an > ipv6 network on their link-layer of choice. An autoconfiguration feature is a functionality, and compares badly to whatever static preconfiguration, in terms of memory/cpu constraints. I really dont see why arguing against this, it's simply basics. Alex Frankly I don't see it. IETF > participants have invested a lot of productive time and energy in > low-power/low signalling/low bandwidth embedded networking, stripping > out the things that make it flexible robust and easy to deploy in the > interest of something that might notionally be more compact then the > toolkit we have at present, seems incredibly limiting. > > Can you do it? Sure. In fact, nobody is going to stop you. > > Is it an "improvement"? Maybe by some measure, but I kind of doubt it. >> As could a device without a network stack. >> >> Your point being? >> >> Gert Doering >> -- NetMaster > > > From joelja@bogus.com Fri May 24 15:10:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAD321F8A74 for ; Fri, 24 May 2013 15:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OocBoEokFSQB for ; Fri, 24 May 2013 15:09:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A686721F89FF for ; Fri, 24 May 2013 15:09:59 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4OM9qSa053947 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 24 May 2013 22:09:52 GMT (envelope-from joelja@bogus.com) Message-ID: <519FE52B.6000006@bogus.com> Date: Fri, 24 May 2013 15:09:47 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Anders Brandt , Lorenzo Colitti , "Liubing (Leo)" References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 24 May 2013 22:09:54 +0000 (UTC) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 22:10:00 -0000 On 5/24/13 5:30 AM, Anders Brandt wrote: > > Hi Lorenzo > > > >> So you can use any type of address, not only ULA. So this is not a >> use case for ULA. > > > > The ULA reasoning starts elsewhere. It is tied to a deployment use > case: > > > > When nodes are installed in a new house, there may be no internet > connectivity - and even more importantly: Even if there is internet > connectivity, then you can be certain that at some time, the ISP will > change your assigned prefix. > > This is critical to certain 6LoWPAN applications such as home > automation. > > Remote controls, sensors and wall controllers are spread all over the > house. They control lights, garage doors and aircon devices. > > The addresses of the lights, garage doors and aircon devices MUST NOT > change since the remote controls, sensors and wall controllers are > permanently paired to the IPv6 addresses of lights, garage doors and > aircon devices on the application level. > If we look at how these things are done today, I think it's pretty rare to see consumer oriented devices that are bound by ip address. rather that binding is some kind of upper layer activity. I can swap out my router or change my numbering plan and to consumer devices in my house will accommodate that without configuration change. certainly ipso/coap devices do not envision permenent ip bindings and likewise callout static assignment as fragile, e.g. https://datatracker.ietf.org/doc/draft-ietf-core-coap/ 7.2. Resource Discovery The discovery of resources offered by a CoAP endpoint is extremely important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. you may consider 6lowpan wifi enabled lightbulbs to be something of a gimmick (I doubt philips/nxp does) but they're certainly not sensitive to renumbering and nor should other devices. > Only ULA prefixes provide that stability, yet ability to route within > the home. > > The lights, garage doors and aircon devices MAY also have global > prefixes for external use by portals and advanced clients. > > > > Thanks, > > Anders > > > > > > *From:*v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On > Behalf Of *Lorenzo Colitti *Sent:* 24. maj 2013 13:42 *To:* Liubing > (Leo) *Cc:* v6ops@ietf.org; > draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org *Subject:* > Re: [v6ops] A brief intro-//RE: new draft: > draft-ietf-v6ops-ula-usage-recommendations > > > > On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > > wrote: > > V. "the network needs ULA as the on-demand and stable addressing > which doesn't need much code to support address assignment mechanisms > like DHCP or ND." I don't think this makes sense. Are you saying such > nodes only support manual address assignment? How is it possible that > a sensor doesn't support automatic address assignment due to lack of > resources, but has enough resources to implement a UI for manual > address assignment? > > [Bing] The lack of resources mainly regarding the network > environment, there might not be a comprehensive network provisioning > environment for the nodes. If they can be pre-configured with ULA, > say, hard-coded in the embedded system, like the MAC addresses in > every single NIC or self-generating a ULA, then they could make > ad-hoc networking without address provisioning procedures. > > How are those nodes going to find the MAC address of the link router > to communicate off-link? If they can't do this, then you don't need > ULA, you can just use link-local. If they can do this, then they must > support router advertisements or similar. If they support router > advertisements, then they can use autoconfiguration. > > [Bing] Surely they need to support SLAAC, it�s a basic IPv6 function > , the draft specifically noted this point. But if the sensors are in > a MANET, then the autoconfiguration is different with the traditional > wired SLAAC, since MANET is based on a multi hop topology. ULA is > suitable for this scenario, however, current text seems not > sufficient/clear, will modify later. > > > > If they support SLAAC, then they don't need to be pre-configured, > because they can just use SLAAC to autoconfigure addresses. And if > they can autoconfigure an address, they can use a global address. So > there is no need to use ULA. > > > > [Bing] The reasoning is flawed. Let�s do not mix the concepts of > global addr-provisioning and autoconfiguration together. > > > > Why is it flawed? You said that a use case for ULA is > resource-constrained nodes, because you can pre-assign addresses to > them, and that this simplifies the nodes. But it doesn't simplify the > nodes, because even if you pre-assign addresses, the nodes still need > some mechanism (e.g., RA) in order to find out who you can > communicate to. So the nodes have to support RAs. And if the nodes > support RA, you can use autoconfiguration and you don't need to > pre-assign addresses. So you can use any type of address, not only > ULA. So this is not a use case for ULA. > > > > And in MANET, the SLAAC is not (fully)applicable, see > http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 > > > > > That draft expired in 2008, so it's not really relevant. Do you have > a more up-to-date document? > > > > On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > > wrote: > > Hi, Lorenzo > > > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com > ] *Sent:* Friday, May 24, 2013 5:44 PM > > > *To:* Liubing (Leo) *Cc:* v6ops@ietf.org ; > draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org > > *Subject:* Re: [v6ops] A brief intro-//RE: new draft: > draft-ietf-v6ops-ula-usage-recommendations > > > > On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > > wrote: > > No, the probability is much higher than you think. See RFC 4193 > section 3.2.3. If I'm reading that section correctly, if you generate > 10000 ULAs you'll get a collision 1 in 500k times. If you generate > 100000 (e.g., if you regenerate them once a second, for one day) > you'll get a collision once in 1000 times. And so on. > > [Bing] In theory, I agree with you. But the point here is where do we > need to change the ULA so frequently? For random draw? I can hardly > imagine a use case of that. > > > > This is a technical document meant to provide guidance, so I'd say > that it's not appropriate to use vague words like regularly > "regularly", without stating what they mean to state what it means. > Can I generate 10000 ULAs per second, as long as I do it "regularly"? > Likely not. > > > > So you either remove the text, or state that if ULAs are generated > regularly, then collisions are possible, and perhaps provide provide > an example that calculates the probability of collision with some > reasonal value of the regeneration interval. > > > > [Bing] OK, I�ll refine the word. > > > > V. "the network needs ULA as the on-demand and stable addressing > which doesn't need much code to support address assignment mechanisms > like DHCP or ND." I don't think this makes sense. Are you saying such > nodes only support manual address assignment? How is it possible that > a sensor doesn't support automatic address assignment due to lack of > resources, but has enough resources to implement a UI for manual > address assignment? > > [Bing] The lack of resources mainly regarding the network > environment, there might not be a comprehensive network provisioning > environment for the nodes. If they can be pre-configured with ULA, > say, hard-coded in the embedded system, like the MAC addresses in > every single NIC or self-generating a ULA, then they could make > ad-hoc networking without address provisioning procedures. > > How are those nodes going to find the MAC address of the link router > to communicate off-link? If they can't do this, then you don't need > ULA, you can just use link-local. If they can do this, then they must > support router advertisements or similar. If they support router > advertisements, then they can use autoconfiguration. > > [Bing] Surely they need to support SLAAC, it�s a basic IPv6 function > , the draft specifically noted this point. But if the sensors are in > a MANET, then the autoconfiguration is different with the traditional > wired SLAAC, since MANET is based on a multi hop topology. ULA is > suitable for this scenario, however, current text seems not > sufficient/clear, will modify later. > > > > If they support SLAAC, then they don't need to be pre-configured, > because they can just use SLAAC to autoconfigure addresses. And if > they can autoconfigure an address, they can use a global address. So > there is no need to use ULA. > > > > [Bing] The reasoning is flawed. Let�s do not mix the concepts of > global addr-provisioning and autoconfiguration together. And in > MANET, the SLAAC is not (fully)applicable, see > http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2 > > > > > VI. "there always be some argument that in practice the ULA+PA makes > terrible operational complexity. But it is not a ULA-specific > problem; the multiple- addresses-per-interface is an important > feature of IPv6 protocol. Running multiple prefixes in IPv6 might be > very common, and we need to adapt this new operational model than > that in IPv4." This text does not make sense. Just because having > multiple global-scope addresses is a feature of IPv6 doesn't mean > that you must have multiple global-scope addresses. For example, you > can use only global addresses and have no routing complexity. > > [Bing] The ULA+PA operational complexity contains two aspect. > > One is the common issue as described in the texts, running multiple > prefixes in a network is new to the traditional IPv4 model, the > admins need to be familiar with it in the future. > > No, because having multiple prefixes introduces operational > complexity even if the admins understand multiple prefixes. All > things being equal, having only one prefix (e.g., a global prefix) is > always going to be simpler than having two. > > > > In other words: what you're saying is "let's create complexity, > because admins will need to understand the complexity anyway". What > I'm saying is that while they need to understand the complexity, we > don't have to create the complexity if we don't need it. > > [Bing] No, I�m not say that. ULA+PA is identified as beneficial use > case in 6renum and Homenet. So the admins need to adapt the > complexity if they want the benefit. > > > > Ok, so then just cite those documents, say that there is a trade off > between complexity and functionality, and leave it at that? > > [Bing] A brief complexity hint would be valuable. Thanks. > > > > B.R. > > Bing > > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Fri May 24 15:48:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D917211E813D for ; Fri, 24 May 2013 15:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.707 X-Spam-Level: X-Spam-Status: No, score=-102.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djbl0iMt7zZf for ; Fri, 24 May 2013 15:48:23 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 74ADD11E8134 for ; Fri, 24 May 2013 15:48:23 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so4757655pbb.13 for ; Fri, 24 May 2013 15:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5L52k4xVu8gnMLukb6xtsjf1hf0wM9xZc1BaJBnTpUA=; b=0Ret7xqRZ79vr/gKISHJ5n6m+EAH6asAv0kfUro1WMtSUYa9wWD6Q5mZaY/n8m7KM4 gI9DCsI/eZBi5Ik70SYJV5YQ4gCObmfLQ6QAly7q89YRM9/dHeLRdPbowsnrqdzJY8A2 cSOk2CwAf9FG6ExRnxNiTmJD2PiPp6p17rjbmQoVISiiNBp3mpwLQ/fRbvfKw8Ay32oe 75AaWOoUjJeRC794Sm4+h7dqdZp3qms9WxV0xfOYW5l4oAdlbj8aB0LPto3EIiWayEHw fEOcoBuqTQLAAelVvqNio3G9GWe5j75yqwJ+Bg1SkrdQqFzMvkBF2kINKBIaqBT9ZiwX lAYQ== X-Received: by 10.66.230.228 with SMTP id tb4mr19893854pac.160.1369435702055; Fri, 24 May 2013 15:48:22 -0700 (PDT) Received: from [192.168.1.2] (229.187.252.27.dyn.cust.vf.net.nz. [27.252.187.229]) by mx.google.com with ESMTPSA id 3sm17773300pbj.46.2013.05.24.15.48.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 15:48:20 -0700 (PDT) Message-ID: <519FEE3D.5000905@gmail.com> Date: Sat, 25 May 2013 10:48:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <519FE52B.6000006@bogus.com> In-Reply-To: <519FE52B.6000006@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 22:48:24 -0000 On 25/05/2013 10:09, joel jaeggli wrote: ... > If we look at how these things are done today, I think it's pretty rare > to see consumer oriented devices that are bound by ip address. rather > that binding is some kind of upper layer activity. I can swap out my > router or change my numbering plan and to consumer devices in my house > will accommodate that without configuration change. Well, I dunno. I am currently living in someone else's house for a few weeks, and only yesterday, I had to reboot the ADSL box, after which I could no longer print. Guess what? The printer's IPv4 address had changed. Since the Bonjour mechanism provided for the printer had already collapsed a couple of days earlier, the fix was to log into the ADSL box, force DHCP to give the previous IPv4 address to the printer's MAC address, and reboot everything again. Of course I'd love to get away from that, but I suspect that the ability to force the printer address to ::6 instead of 192.168.1.6 would have been handy if this house had IPv6. Brian From joelja@bogus.com Fri May 24 16:03:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2711E8144 for ; Fri, 24 May 2013 16:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvMAxfEPXLSA for ; Fri, 24 May 2013 16:03:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 84E2111E8135 for ; Fri, 24 May 2013 16:03:55 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4ON3mW5054519 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 24 May 2013 23:03:48 GMT (envelope-from joelja@bogus.com) Message-ID: <519FF1CE.4080507@bogus.com> Date: Fri, 24 May 2013 16:03:42 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Brian E Carpenter References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <519FE52B.6000006@bogus.com> <519FEE3D.5000905@gmail.com> In-Reply-To: <519FEE3D.5000905@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 24 May 2013 23:03:49 +0000 (UTC) Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 23:03:56 -0000 On 5/24/13 3:48 PM, Brian E Carpenter wrote: > On 25/05/2013 10:09, joel jaeggli wrote: > ... >> If we look at how these things are done today, I think it's pretty rare >> to see consumer oriented devices that are bound by ip address. rather >> that binding is some kind of upper layer activity. I can swap out my >> router or change my numbering plan and to consumer devices in my house >> will accommodate that without configuration change. > Well, I dunno. I am currently living in someone else's house for > a few weeks, and only yesterday, I had to reboot the ADSL box, > after which I could no longer print. Guess what? The printer's > IPv4 address had changed. Since the Bonjour mechanism provided > for the printer had already collapsed a couple of days earlier, > the fix was to log into the ADSL box, force DHCP to give the > previous IPv4 address to the printer's MAC address, and reboot > everything again. > > Of course I'd love to get away from that, I'd love to get away from non-working devices too... but the printer didn't have a static address assignment until you programmed the dhcp server. and if you connect it to a different network it will get a new address (which it will helpfully share). > but I suspect that > the ability to force the printer address to ::6 > instead of 192.168.1.6 would have been handy if this house > had IPv6. And then you'll change out the adsl modem. the next one, will assuming it assigns itself a ula pick a different one, and the printer will either have two or more ips,forget about the old one, be more conveniently addressed using link-local (different dicussion) or stop being accessible because it's only on the old subnet for which there's no RA and which your laptop will never discover. the consumer is going to push the reset button or cycle the power when it doesn't work, and things are going to have sort themselves out. > > Brian > From ales.vizdal@t-mobile.cz Fri May 24 16:18:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D076211E812B for ; Fri, 24 May 2013 16:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvyLqqAvOOCQ for ; Fri, 24 May 2013 16:18:34 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 9508721F94A6 for ; Fri, 24 May 2013 16:18:34 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id EE61F2E0873; Sat, 25 May 2013 01:18:11 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Sat, 25 May 2013 01:18:31 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "v6ops@ietf.org" Date: Sat, 25 May 2013 01:18:30 +0200 Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt Thread-Index: Ac5YshkiCDJB6394QbCzC2PsAnb05wAIUjmA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895D5E133@SRVHKE02.rdm.cz> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> In-Reply-To: <519FB531.9050304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 23:18:39 -0000 Hi Alex, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Friday, May 24, 2013 8:45 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt > > 3.1 Scenario 1: No Global Address on the UE > > > > "traffic destine" > > > > > > - missing "d" on destined. >=20 > Better say 'targeted' or 'addressed to'. Exchanged with peers addressabl= e by. As a packet has its destination it is 'destined to' an address ... Let's ke= ep it as is to avoid confusion. > > 3.2 Scenario 2: Global Address Only Assigned to LAN > > > > "The movement of the IPv6 prefix from the 3GPP radio interface to the > > LAN interface may result in long-lived data connections being > > terminated during the transition from a host-only mode to > > router-and-host mode." > > > > > > I'd suggest adding something like: > > > > "Connections which are likely to be effected are ones that have been > > specifically bound to the 3GPP radio interface." >=20 > One other way to think about this is the follozing: >=20 > If for any reason the 3GPP UE changes its IPv6 address (disconnect and re= connect, > because of short transitions, or other error) then it is highly likely th= at the IPv6 > address changes, and its first 64 bits may change as well. At that point= , it should be > clear than any other address on the LAN that is formed by prefixing with = these 64bits, > as well as the address itself attached on UE's LAN interface, will change= . > This will certainly incur disruption in communication. >=20 > This could go as far as to say that the 64share method works only for sta= tic UEs. It > sounds negative, I know, but the reliability of this should be acknowledg= ed. Section 3.0 General Behavior for All Scenarios clearly states:=20 "If the 3GPP interface goes down or changes the IPv6 prefix, that state sho= uld be reflected=20 in the LAN IPv6 configuration." So the solution is not limited to UEs with a static IPv6 prefix. Any change= s on the 3GPP link shall be propagated to the LAN. (the old IPv6 prefix to be deprecated = and the new one=20 to be advertised to the LAN) > Yours, >=20 > Alex Cheers, Ales From dougb@dougbarton.us Fri May 24 20:16:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF9821E8085 for ; Fri, 24 May 2013 20:16:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BATMbBQvOfMl for ; Fri, 24 May 2013 20:16:52 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id D617421E8050 for ; Fri, 24 May 2013 20:16:52 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:1d98:49ee:73d0:a532] (unknown [IPv6:2001:470:d:5e7:1d98:49ee:73d0:a532]) by dougbarton.us (Postfix) with ESMTPSA id 2C08322B42 for ; Sat, 25 May 2013 03:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1369451812; bh=31wwZcuZWeGexOtNo6adCQd1NXx8OfPFUE9E7XCeIbU=; h=Date:From:To:Subject:References:In-Reply-To; b=ZfQYv0hKKnc+7giPmIvqLGPDepqx6ovA4joPRq9LyyeKavnFc6F+wNzml9ypWY1jV 3x63M/oNXlyRwLPv1p8KVWOddUN20skM2zEbDC8C4EsGa3xeSkGwV8zSz+Vl87OjGy AESxymOoVrOmkUHPJUpsNgXRdPXewQGeI0HVhgcY= Message-ID: <51A02D23.6080101@dougbarton.us> Date: Fri, 24 May 2013 20:16:51 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 03:16:57 -0000 On 05/24/2013 02:52 AM, Lorenzo Colitti wrote: > On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter > > wrote: > > That's correct, of course. The underlying problem here is that the > notion of concentric circles of scope that was originally described > for IPv6 is simply broken. We can't fix that in the context of > describing ULA usage scenarios, so let's not try. > > > Actually, I think the underlying problem as regards this specific draft > is that ULAs were not well thought-out. They came out of a compromise > where no side got what it wanted and what we got was a > poorly-understood, possibly unusable hybrid. Or, ULAs are just fine for their intended purpose, it's just that you don't like the purpose. :) From leo.liubing@huawei.com Fri May 24 23:16:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D278C21F9428 for ; Fri, 24 May 2013 23:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKeia+zIzASO for ; Fri, 24 May 2013 23:16:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22D1421F9425 for ; Fri, 24 May 2013 23:16:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARS36273; Sat, 25 May 2013 06:16:29 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 25 May 2013 07:16:08 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 25 May 2013 07:16:24 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Sat, 25 May 2013 14:16:17 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHOVS+HyCM8E5Dr9EyOxCY462I/kZkO8esQ///To4CAAIuHsIAERP4AgACGzxD//5oUgIABuHjw Date: Sat, 25 May 2013 06:16:16 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D72970B@nkgeml506-mbx.china.huawei.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D72970Bnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 06:16:36 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D72970Bnkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Friday, May 24, 2013 7:42 PM To: Liubing (Leo) Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.o= rg Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-us= age-recommendations On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > wrote: V. "the network needs ULA as the on-demand and stable addressing which doe= sn't need much code to support address assignment mechanisms like DHCP or N= D." I don't think this makes sense. Are you saying such nodes only support = manual address assignment? How is it possible that a sensor doesn't support= automatic address assignment due to lack of resources, but has enough reso= urces to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, ther= e might not be a comprehensive network provisioning environment for the nod= es. If they can be pre-configured with ULA, say, hard-coded in the embedded= system, like the MAC addresses in every single NIC or self-generating a UL= A, then they could make ad-hoc networking without address provisioning proc= edures. How are those nodes going to find the MAC address of the link router to com= municate off-link? If they can't do this, then you don't need ULA, you can = just use link-local. If they can do this, then they must support router adv= ertisements or similar. If they support router advertisements, then they ca= n use autoconfiguration. [Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the = draft specifically noted this point. But if the sensors are in a MANET, th= en the autoconfiguration is different with the traditional wired SLAAC, sin= ce MANET is based on a multi hop topology. ULA is suitable for this scenari= o, however, current text seems not sufficient/clear, will modify later. If they support SLAAC, then they don't need to be pre-configured, because t= hey can just use SLAAC to autoconfigure addresses. And if they can autoconf= igure an address, they can use a global address. So there is no need to use= ULA. [Bing] The reasoning is flawed. Let's do not mix the concepts of global add= r-provisioning and autoconfiguration together. Why is it flawed? You said that a use case for ULA is resource-constrained = nodes, because you can pre-assign addresses to them, and that this simplifi= es the nodes. But it doesn't simplify the nodes, because even if you pre-as= sign addresses, the nodes still need some mechanism (e.g., RA) in order to = find out who you can communicate to. So the nodes have to support RAs. And = if the nodes support RA, you can use autoconfiguration and you don't need t= o pre-assign addresses. So you can use any type of address, not only ULA. S= o this is not a use case for ULA. [Bing] The flaw is mainly regarding with your argument that if we can make= autoconfiguration then we can make global prefix. As said in last mail, I = don't think autoconfiguration necessarily means global provisioning, they a= re two perspectives. Another point I want to argue is, not only simplify the nodes themselves, b= ut also simplify the network provisioning/management. As discussed below, M= ANET currently could not do well with SLAAC. But anyway, I think the current texts need to be updated to be more suffici= ent and accurate. Thanks. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org= /html/draft-ietf-autoconf-statement-04.html#section-5.2 That draft expired in 2008, so it's not really relevant. Do you have a more= up-to-date document? [Bing] Sorry, I haven't be aware of a more up-to-date document. But I thin= k the issue is still valid. B.R. Bing On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) > wrote: Hi, Lorenzo From: Lorenzo Colitti [mailto:lorenzo@google.com= ] Sent: Friday, May 24, 2013 5:44 PM To: Liubing (Leo) Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recom= mendations@tools.ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-us= age-recommendations On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) > wrote: No, the probability is much higher than you think. See RFC 4193 section 3.2= .3. If I'm reading that section correctly, if you generate 10000 ULAs you'l= l get a collision 1 in 500k times. If you generate 100000 (e.g., if you reg= enerate them once a second, for one day) you'll get a collision once in 100= 0 times. And so on. [Bing] In theory, I agree with you. But the point here is where do we need = to change the ULA so frequently? For random draw? I can hardly imagine a us= e case of that. This is a technical document meant to provide guidance, so I'd say that it'= s not appropriate to use vague words like regularly "regularly", without st= ating what they mean to state what it means. Can I generate 10000 ULAs per = second, as long as I do it "regularly"? Likely not. So you either remove the text, or state that if ULAs are generated regularl= y, then collisions are possible, and perhaps provide provide an example tha= t calculates the probability of collision with some reasonal value of the r= egeneration interval. [Bing] OK, I'll refine the word. V. "the network needs ULA as the on-demand and stable addressing which doe= sn't need much code to support address assignment mechanisms like DHCP or N= D." I don't think this makes sense. Are you saying such nodes only support = manual address assignment? How is it possible that a sensor doesn't support= automatic address assignment due to lack of resources, but has enough reso= urces to implement a UI for manual address assignment? [Bing] The lack of resources mainly regarding the network environment, ther= e might not be a comprehensive network provisioning environment for the nod= es. If they can be pre-configured with ULA, say, hard-coded in the embedded= system, like the MAC addresses in every single NIC or self-generating a UL= A, then they could make ad-hoc networking without address provisioning proc= edures. How are those nodes going to find the MAC address of the link router to com= municate off-link? If they can't do this, then you don't need ULA, you can = just use link-local. If they can do this, then they must support router adv= ertisements or similar. If they support router advertisements, then they ca= n use autoconfiguration. [Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the = draft specifically noted this point. But if the sensors are in a MANET, th= en the autoconfiguration is different with the traditional wired SLAAC, sin= ce MANET is based on a multi hop topology. ULA is suitable for this scenari= o, however, current text seems not sufficient/clear, will modify later. If they support SLAAC, then they don't need to be pre-configured, because t= hey can just use SLAAC to autoconfigure addresses. And if they can autoconf= igure an address, they can use a global address. So there is no need to use= ULA. [Bing] The reasoning is flawed. Let's do not mix the concepts of global add= r-provisioning and autoconfiguration together. And in MANET, the SLAAC is n= ot (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-st= atement-04.html#section-5.2 VI. "there always be some argument that in practice the ULA+PA makes terrib= le operational complexity. But it is not a ULA-specific problem; the multip= le- addresses-per-interface is an important feature of IPv6 protocol. Runni= ng multiple prefixes in IPv6 might be very common, and we need to adapt thi= s new operational model than that in IPv4." This text does not make sense. = Just because having multiple global-scope addresses is a feature of IPv6 do= esn't mean that you must have multiple global-scope addresses. For example,= you can use only global addresses and have no routing complexity. [Bing] The ULA+PA operational complexity contains two aspect. One is the common issue as described in the texts, running multiple prefixe= s in a network is new to the traditional IPv4 model, the admins need to be = familiar with it in the future. No, because having multiple prefixes introduces operational complexity even= if the admins understand multiple prefixes. All things being equal, having= only one prefix (e.g., a global prefix) is always going to be simpler than= having two. In other words: what you're saying is "let's create complexity, because adm= ins will need to understand the complexity anyway". What I'm saying is that= while they need to understand the complexity, we don't have to create the = complexity if we don't need it. [Bing] No, I'm not say that. ULA+PA is identified as beneficial use case in= 6renum and Homenet. So the admins need to adapt the complexity if they wan= t the benefit. Ok, so then just cite those documents, say that there is a trade off betwee= n complexity and functionality, and leave it at that? [Bing] A brief complexity hint would be valuable. Thanks. B.R. Bing --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D72970Bnkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= ;

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, May 24, 2013 7:42 PM
To: Liubing (Leo)
Cc: v6ops@ietf.org; draft-ietf-v6ops-ula-usage-recommendations@tools= .ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

On Fri, May 24, 2013 at 8:01 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:

V. "the network needs ULA as the o= n-demand and stable addressing which doesn't need much code to support addr= ess assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automatic = address assignment due to lack of resources, but has enough resources to im= plement a UI for manual address assignment?

[Bing] The lack of re= sources mainly regarding the network environment, there might not be a comp= rehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to find the MAC add= ress of the link router to communicate off-link? If they can't do this, the= n you don't need ULA, you can just use link-local. If they can do this, then they must support router advertiseme= nts or similar. If they support router advertisements, then they can use au= toconfiguration.

[Bing] Surely they ne= ed to support SLAAC, it’s a basic IPv6 function , the draft specifica= lly noted this point. But if the sensors are in a MANET, then the autoconfiguration is different with the traditional w= ired SLAAC, since MANET is based on a multi hop topology. ULA is suitable f= or this scenario, however, current text seems not sufficient/clear, will mo= dify later.

If they support SLAAC, then they don't need t= o be pre-configured, because they can just use SLAAC to autoconfigure addre= sses. And if they can autoconfigure an address, they can use a global address. So there is no need to use ULA.

[Bing] The reasoning = is flawed. Let’s do not mix the concepts of global addr-provisioning = and autoconfiguration together.

Why is it flawed? You said that= a use case for ULA is resource-constrained nodes, because you can pre-assi= gn addresses to them, and that this simplifies the nodes. But it doesn't si= mplify the nodes, because even if you pre-assign addresses, the nodes still need some mechanism (e.g., RA) in or= der to find out who you can communicate to. So the nodes have to support RA= s. And if the nodes support RA, you can use autoconfiguration and you don't= need to pre-assign addresses. So you can use any type of address, not only ULA. So this is not a use case f= or ULA.

= ;

[Bing] The flaw is mainly regarding with your argument that if we can = make autoconfiguration then we can make global prefix. As said in last mail= , I don’t think autoconfiguration necessarily means global provisioning, they are two perspectives.

Another= point I want to argue is, not only simplify the nodes themselves, but also= simplify the network provisioning/management. As discussed below, MANET cu= rrently could not do well with SLAAC.

But any= way, I think the current texts need to be updated to be more sufficient and= accurate. Thanks.

And in MANET, the SLA= AC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.= 2

That draft expired in 2008, so = it's not really relevant. Do you have a more up-to-date document?

= [Bing] Sorry, I haven’t be aware = of a more up-to-date document. But I think the issue is still valid.

B.R.

Bing

On Fri, May 24, 2013 at 8:01 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi, Lorenzo

From: Lorenzo Colitti [mailto:lo= renzo@google.com]
Sent: Friday, May 24, 2013 5:44 PM<= /o:p>

To: Liubing (Leo)
Cc: v6ops@ietf.o= rg; draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops= -ula-usage-recommendations

On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo= ) <leo.liubi= ng@huawei.com> wrote:

No, the probability is much higher than you t= hink. See RFC 4193 section 3.2.3. If I'm reading that section correctly, if= you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if you regenerate= them once a second, for one day) you'll get a collision once in 1000 times= . And so on.

[Bing] In theory, I a= gree with you. But the point here is where do we need to change the ULA so = frequently? For random draw? I can hardly imagine a use case of that.<= /p>

This is a technical document meant to provide= guidance, so I'd say that it's not appropriate to use vague words like reg= ularly "regularly", without stating what they mean to state what it means. Can I generate 10000 ULAs per second, as= long as I do it "regularly"? Likely not.

So you either remove the text, or state that = if ULAs are generated regularly, then collisions are possible, and perhaps = provide provide an example that calculates the probability of collision with some reasonal value of the regeneration = interval.

[Bing] OK, I’ll= refine the word.

V. "the network needs ULA as the o= n-demand and stable addressing which doesn't need much code to support addr= ess assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual addr= ess assignment? How is it possible that a sensor doesn't support automatic = address assignment due to lack of resources, but has enough resources to im= plement a UI for manual address assignment?

[Bing] The lack of re= sources mainly regarding the network environment, there might not be a comp= rehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in = the embedded system, like the MAC addresses in every single NIC or self-gen= erating a ULA, then they could make ad-hoc networking without address provi= sioning procedures.

How are those nodes going to find the MAC add= ress of the link router to communicate off-link? If they can't do this, the= n you don't need ULA, you can just use link-local. If they can do this, then they must support router advertiseme= nts or similar. If they support router advertisements, then they can use au= toconfiguration.

[Bing] Surely they ne= ed to support SLAAC, it’s a basic IPv6 function , the draft specifica= lly noted this point. But if the sensors are in a MANET, then the autoconfiguration is different with the traditional w= ired SLAAC, since MANET is based on a multi hop topology. ULA is suitable f= or this scenario, however, current text seems not sufficient/clear, will mo= dify later.

If they support SLAAC, then they don't need t= o be pre-configured, because they can just use SLAAC to autoconfigure addre= sses. And if they can autoconfigure an address, they can use a global address. So there is no need to use ULA.

[Bing] The reasoning = is flawed. Let’s do not mix the concepts of global addr-provisioning = and autoconfiguration together. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.= 2

VI. "there alway= s be some argument that in practice the ULA+PA makes terrible operation= al complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 prot= ocol. Running multiple prefixes in IPv6 might be very common, and we need t= o adapt this new operational model than that in IPv4." This text does = not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must hav= e multiple global-scope addresses. For example, you can use only global add= resses and have no routing complexity.

[Bing] The ULA+PA= operational complexity contains two aspect.

One is the common iss= ue as described in the texts, running multiple prefixes in a network is new= to the traditional IPv4 model, the admins need to be familiar with it in the future.

No, because having multiple prefixes introduc= es operational complexity even if the admins understand multiple prefixes. = All things being equal, having only one prefix (e.g., a global prefix) is always going to be simpler than having t= wo.

In other words: what you're saying is "l= et's create complexity, because admins will need to understand the complexi= ty anyway". What I'm saying is that while they need to understand the complexity, we don't have to create the complexity = if we don't need it.

[Bing] No, I’m = not say that. ULA+PA is identified as beneficial use case in 6renum and= Homenet. So the admins need to adapt the complexity if they want the benefit.

Ok, so then just cite those documents, say th= at there is a trade off between complexity and functionality, and leave it = at that?

[Bing] A brief comple= xity hint would be valuable. Thanks.=

B.R.

Bing

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D72970Bnkgeml506mbxchi_-- From sander@steffann.nl Sat May 25 04:28:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF83721F9509 for ; Sat, 25 May 2013 04:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+ZMYuSvIhkj for ; Sat, 25 May 2013 04:28:53 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4401221F9080 for ; Sat, 25 May 2013 04:28:49 -0700 (PDT) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 39655202E; Sat, 25 May 2013 13:28:47 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Sander Steffann In-Reply-To: <519FD971.7040608@gmail.com> Date: Sat, 25 May 2013 13:28:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <441D689C-93E2-4F88-A73D-BE1408510A6B@steffann.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> <20130524203615.GW2504@Space.Net> <519FD778.7060807@bogus.com> <519FD971.7040608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 11:28:58 -0000 Hi, >> There seems to be small but quite persistent faction that insists on = the >> notion that functionally limited systems are incapable of operating >> around the incredibly basic set of functional building blocks for an >> ipv6 network on their link-layer of choice. >=20 > An autoconfiguration feature is a functionality, and compares badly to = whatever static preconfiguration, in terms of memory/cpu constraints. >=20 > I really dont see why arguing against this, it's simply basics. I think what everybody is trying to tell you is that using a networking = protocol only works if you follow the protocol's rules. IPv6 networks = are divided into subnets, usually a /64 net network. Devices on the = network need to know (a) which network they are on (prefix) and (b) what = the gateway to other networks is. Depending on the setup and additional = rules defined by the environment you might be able to hard-code (b). Hard-coding (a) is the problem that everybody is pointing at: there will = be >1 networks so you don't know up front which network the device will = be connected to. Now you can pretend that there is only 1 network and = hard-code all addresses from the same /64 prefix (ULA or global, doesn't = matter, it's just a number) but then devices from other networks will = have no way of communicating with them (because the rest of the world = can't distinguish between the different instances of that 'one' = network). This is scenario 1 that Owen described: "Multiple devices with = the same prefix not on the same network". You might as well use = link-local addresses in that case... If you use multiple /64s then you = run into scenario 2: "Multiple devices with different prefixes unable to = recognize each other on the same network". The problem is not in which set of addresses you use but the fact that = your device will be less flexible in its behaviour than the environment = it is supposed to work in. It won't adapt to its environment and will = not work properly. The only thing you might do is to let the users 'burn in' the addresses = themselves when installing the device. The user is then responsible for = adapting the device to the environment (network) it is going to be used = on. I just don't see why you would want to force such an user-unfriendly = and error-prone task task on the user/installer when with a tiny bit of = extra code you could make the device auto-configure itself by listening = to Router Advertisements... Cheers, Sander From rdroms.ietf@gmail.com Sat May 25 07:06:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD6A21F896B for ; Sat, 25 May 2013 07:06:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg9EVC2Rl1-0 for ; Sat, 25 May 2013 07:06:04 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F1CCD21F8916 for ; Sat, 25 May 2013 07:06:03 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so2871489qcx.16 for ; Sat, 25 May 2013 07:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=jL++H/fAAD7ptsMsJIn55gQU5jdB69UEUifojsidmVI=; b=IVW06TEvoBs9TvxN6ziTuuirHXN13wSBixvtx6ApR4n7MOgR9yAl1x3QOILgJ2J8SB s8leX2FzfOl60xJZbNrIbZb93nuwPNueVSy6vfTSSrkFds2f2RyovLf0vxJpuTRRHsx6 KqBYKK4njN8sp7kh9tozJ/WSaecVAI3OUqmgrmT5fn6WX0yZtv6KORtqI/Qjk4afA09X 8T/kJ6czzT6cvqE7YBWF5cq9GDZr8fyva0bT0g5OtbchYFqPcweK4UZSzMy+pacGeAqO MiIsrIkSnFUnEnmrMJZ9ilXkodpyXAYLUZDdCyltxnjvFI85GMxQ9R747ugZOJS3VZEM ou5Q== X-Received: by 10.229.13.165 with SMTP id c37mr4253269qca.34.1369490763332; Sat, 25 May 2013 07:06:03 -0700 (PDT) Received: from rtp-rdroms-8915.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id j10sm17960743qeh.0.2013.05.25.07.06.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 May 2013 07:06:02 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 25 May 2013 10:06:00 -0400 References: <20130522191522.2297.24938.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org Operations" Message-Id: <69F0099D-A7A6-4725-9719-7B3B54C45EFD@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) X-Mailer: Apple Mail (2.1503) Subject: [v6ops] Fwd: New Version Notification for draft-droms-6man-multicast-scopes-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 14:06:04 -0000 This draft proposes to redefine IPv6 multicast scope 0x03 from = "reserved" to "Network-Specific scope, greater than Link-Local scope, = defined automatically from the network topology". The expectation is = that mesh trickle multicast, as defined in = draft-ietf-roll-trickle-mcast, will define multicast scope 0x03 as "all = interfaces attached to links in the mesh", for use in multicast = delivery. I've requested a slot on the 6man agenda in Berlin to discuss the draft. - Ralph Begin forwarded message: > From: > Subject: New Version Notification for = draft-droms-6man-multicast-scopes-00.txt > Date: May 22, 2013 3:15:22 PM EDT > To: Ralph Droms >=20 >=20 > A new version of I-D, draft-droms-6man-multicast-scopes-00.txt > has been successfully submitted by Ralph Droms and posted to the > IETF repository. >=20 > Filename: draft-droms-6man-multicast-scopes > Revision: 00 > Title: IPv6 Multicast Address Scopes > Creation date: 2013-05-22 > Group: Individual Submission > Number of pages: 3 > URL: = http://www.ietf.org/internet-drafts/draft-droms-6man-multicast-scopes-00.t= xt > Status: = http://datatracker.ietf.org/doc/draft-droms-6man-multicast-scopes > Htmlized: = http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-00 >=20 >=20 > Abstract: > This document updates the definitions of IPv6 multicast scopes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From owen@delong.com Sat May 25 11:43:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56E221F8A54 for ; Sat, 25 May 2013 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OywMpDV9tzr for ; Sat, 25 May 2013 11:43:16 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 935B121F89D5 for ; Sat, 25 May 2013 11:43:16 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4PIgRNK011521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 11:42:27 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4PIgRNK011521 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369507347; bh=a9SEbmuIOs31pxPzd8LhvqV+ffo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZWk3/+odTA5jOsKuIKDOaUH8erpBSifg9GMPLW0dnSYZkSOcrV3UuAz5y5R22u/yW WZ6OiU2cLhb7KLeHihlCMJGs5EbbScvSa/UWuRzxi73Exuon6M05zpoj0eyMPtDgr+ Z1bqgRbDqSZLLfPHgaWmJXGARgUGG9a07TxVzLKo= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <519FB531.9050304@gmail.com> Date: Sat, 25 May 2013 11:42:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 25 May 2013 11:42:27 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 18:43:25 -0000 On May 24, 2013, at 11:45 , Alexandru Petrescu = wrote: > Le 23/05/2013 23:08, Mark Smith a =E9crit : >> Hi, >>=20 >>=20 >> Suggested changes: >>=20 >>=20 >>=20 >> 1. Introduction >>=20 >> "... for delegating IPv6 prefixes to a LAN." >>=20 >>=20 >> to >>=20 >> ""... for delegating IPv6 prefixes to a single LAN interface." >>=20 >> Generally I think this intro text should make it a bit clearer that >> these methods are only extending the /64 to a single LAN interface. >=20 How can that work in the real world? For example, with my iPhone 5 running on VZW, I seem to get the same /64 over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actual cellular interface), BlueTooth (mobile hotspot), and USB (mobile = hotspot). =46rom my perspective that's 3 LAN interfaces and a WAN interface = sharing the same /64. > Yes. >=20 > Moreover, it should be clear that this extension only works with only > one level of extension (one cant have 64share-64share-... = indefinitely, > not even twice). >=20 This part makes sense to me. But bridging the 64share prefix across multiple LAN interfaces on the device (or even extending it via bridges on the LAN side) does not seem to be a problem IMHO. > This could go as far as to say that the 64share method works only for > static UEs. It sounds negative, I know, but the reliability of this > should be acknowledged. I wouldn't go quite that far. Acknowledging the limitations makes sense = to me. Expanding upon those limitations to say that nobody can make a decision = to accept them and deploy anyway is not correct, IMHO. Owen From cb.list6@gmail.com Sat May 25 13:26:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764AC21F8A14 for ; Sat, 25 May 2013 13:26:37 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRKtLK716Mk2 for ; Sat, 25 May 2013 13:26:36 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C033621F8B33 for ; Sat, 25 May 2013 13:26:36 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so15449306iea.18 for ; Sat, 25 May 2013 13:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=axaIAvoA6ywKhYiXwYRTFnkm4hRSeGlduzKu+tTp2VE=; b=EqQOlb9kGGyAPgKUlzVCFYf88nUx7yRQ/SumHaRI7NlHd8yoE//gUnbsNpQiwOjkTk vI4AtoffjSag4HYxmz4p7tLeiOkuOSvwD3Oo4gRbdE/AKKdn+JnTgGRv2MSJ98Z/OKQp e1DVV6nHuuy/b8HK8YQLIx6WFUvHN5D5zxbPd5fM6gU+TMI4hWXUeWQUxwV8L5ifI/qd K3gD4rUal0OJCtVgr6Z8QBWgIYtG35/zf9Q5c0mSh2DFvjU1QtJerG9IcnM03XA5dMKS 9D+/E5OKkbXK9NVluuV2Lbq8LlF7B3TlHVod+5A5ZCwTy5LSePTLrSVdL3/kCdYzmM8x TTaQ== MIME-Version: 1.0 X-Received: by 10.50.30.2 with SMTP id o2mr2221817igh.12.1369513596232; Sat, 25 May 2013 13:26:36 -0700 (PDT) Received: by 10.64.78.134 with HTTP; Sat, 25 May 2013 13:26:36 -0700 (PDT) Received: by 10.64.78.134 with HTTP; Sat, 25 May 2013 13:26:36 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> Date: Sat, 25 May 2013 13:26:36 -0700 Message-ID: From: "cb.list6" To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7bdc12ee6b4bd704dd90bb82 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 20:26:37 -0000 --047d7bdc12ee6b4bd704dd90bb82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On May 25, 2013 11:43 AM, "Owen DeLong" wrote: > > > On May 24, 2013, at 11:45 , Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > > > Le 23/05/2013 23:08, Mark Smith a =E9crit : > >> Hi, > >> > >> > >> Suggested changes: > >> > >> > >> > >> 1. Introduction > >> > >> "... for delegating IPv6 prefixes to a LAN." > >> > >> > >> to > >> > >> ""... for delegating IPv6 prefixes to a single LAN interface." > >> > >> Generally I think this intro text should make it a bit clearer that > >> these methods are only extending the /64 to a single LAN interface. > > > > How can that work in the real world? > > For example, with my iPhone 5 running on VZW, I seem to get the same /64 > over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actual > cellular interface), BlueTooth (mobile hotspot), and USB (mobile hotspot)= . > > From my perspective that's 3 LAN interfaces and a WAN interface sharing the > same /64. > At the same time? In any event, that implementation you mentioned is not publicly documented. The folks at Apple and Verizon are welcome to share their wisdom on this topic. In any event, the work of this draft is to use the open ietf process to get folks on the same page so the wheel does not get reinvented several times in a vacume. CB > > Yes. > > > > Moreover, it should be clear that this extension only works with only > > one level of extension (one cant have 64share-64share-... indefinitely, > > not even twice). > > > > This part makes sense to me. > > But bridging the 64share prefix across multiple LAN interfaces on the > device (or even extending it via bridges on the LAN side) does not seem > to be a problem IMHO. > > > This could go as far as to say that the 64share method works only for > > static UEs. It sounds negative, I know, but the reliability of this > > should be acknowledged. > > I wouldn't go quite that far. Acknowledging the limitations makes sense to me. > Expanding upon those limitations to say that nobody can make a decision t= o > accept them and deploy anyway is not correct, IMHO. > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7bdc12ee6b4bd704dd90bb82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 25, 2013 11:43 AM, "Owen DeLong" <owen@delong.com> wrote:
>
>
> On May 24, 2013, at 11:45 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote: >
> > Le 23/05/2013 23:08, Mark Smith a =E9crit :
> >> Hi,
> >>
> >>
> >> Suggested changes:
> >>
> >>
> >>
> >> 1. Introduction
> >>
> >> "... for delegating IPv6 prefixes to a LAN."
> >>
> >>
> >> to
> >>
> >> ""... for delegating IPv6 prefixes to a single LAN = interface."
> >>
> >> Generally I think this intro text should make it a bit cleare= r that
> >> these methods are only extending the /64 to a single LAN inte= rface.
> >
>
> How can that work in the real world?
>
> For example, with my iPhone 5 running on VZW, I seem to get the same /= 64
> over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actua= l
> cellular interface), BlueTooth (mobile hotspot), and USB (mobile hotsp= ot).
>
> From my perspective that's 3 LAN interfaces and a WAN interface sh= aring the
> same /64.
>

At the same time?

In any event, that implementation you mentioned is not publi= cly documented. The folks at Apple and Verizon are welcome to share their w= isdom on this topic.

In any event, the work of this draft is to=A0 use the open i= etf process to get folks on the same page so the wheel does not get reinven= ted several times in a vacume.

CB

> > Yes.
> >
> > Moreover, it should be clear that this extension only works with = only
> > one level of extension (one cant have 64share-64share-... indefin= itely,
> > not even twice).
> >
>
> This part makes sense to me.
>
> But bridging the 64share prefix across multiple LAN interfaces on the<= br> > device (or even extending it via bridges on the LAN side) does not see= m
> to be a problem IMHO.
>
> > This could go as far as to say that the 64share method works only= for
> > static UEs. =A0It sounds negative, I know, but the reliability of= this
> > should be acknowledged.
>
> I wouldn't go quite that far. Acknowledging the limitations makes = sense to me.
> Expanding upon those limitations to say that nobody can make a decisio= n to
> accept them and deploy anyway is not correct, IMHO.
>
> Owen
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7bdc12ee6b4bd704dd90bb82-- From owen@delong.com Sat May 25 18:58:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0833521F8EA8 for ; Sat, 25 May 2013 18:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EVplS6hDY0C for ; Sat, 25 May 2013 18:58:03 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 56D1F21F8E37 for ; Sat, 25 May 2013 18:58:02 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4Q1rWs7021207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 18:53:32 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4Q1rWs7021207 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369533212; bh=m1Z+10J+37BO01QWN4U66mYSLc8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=0inOpUlxAwW+hBwFxi9lcH++weJ5MWgkthpcKupinDg02uc9eEi8U8qndefOhYZKV 2ldXfzv8AXN1nTFviObVCFh4cuVpgY7Gc4Sj5YZDWpnmgOvGhJIpmPanRQfEPQ7aLQ GBW+n3wFnOWvpWqwaOhESuYpetvvyqZMcOA7mRFE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <519FB699.6060708@gmail.com> Date: Sat, 25 May 2013 18:53:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <272EFA57-BD3D-463B-B2B8-23F83CD6277A@delong.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 25 May 2013 18:53:32 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 01:58:04 -0000 >> That doesn't mean that they don't need to support RA or that they = cannot >> autoconfigure an address. There is no valid reason these devices = should >> have burned-in ULA. Such an addressing scheme would, in fact, be = quite >> dysfunctional. >=20 > Not sure what you mean. >=20 > But sure a device which has its address pre-configured could go very = far in reducing its memory/cpu print. >=20 You can go even further if you take out the IP stack altogether. At some = point, there's diminishing returns. Failure to support RA and SLAAC at a minimum is, IMHO, below that = threshold. >>> The addresses of the lights, garage doors and aircon devices MUST = NOT >>> change since the >>> remote controls, sensors and wall controllers are permanently paired >>> to the IPv6 addresses of >>> lights, garage doors and aircon devices on the application level. >>=20 >> That's just really, REALLY bad application design. How do all of = these >> ULA prefixes get properly routed when the devices are moved from one >> segment in the home to another? Do you add a giant layer of MIP >> complexity to the ULA in order to make that all work? >>=20 >> The smaller devices need to be paired with the oversight = application(s). >=20 > ? >=20 > Its sufficient for the remote apps to be preconfigured with the = devices' addresses, no need to preconfigure the other way around. How does one reach the other? How do these preconfigured addresses find = each other? If you're proposing building in a limitation that they all have to be on = the same link, then there's no reason to use ULA, you can just use link = local. If not, you have some 'splaining to do in answering the above question. >> Those application(s) should provide the required directory services = for >> them to obtain the IPv6 address(es) of other devices they need to >> communicate with. (The oversight application could be as simple as a >> dynamic DNS server or as complex as a centralized home automation >> management application. Whether support for pairing with more than = one >> oversight application is required is left as an exercise for the = device >> manufacturers. >=20 > Its a way of doing it. >=20 > And there are other simpler ways. Such as? Note, ways which require all devices to be on the same link are = not a valid answer as such ways do not need ULA and can use LL instead. Owen From owen@delong.com Sat May 25 19:02:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6294121F8E9D for ; Sat, 25 May 2013 19:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZlRk4HI6tv5 for ; Sat, 25 May 2013 19:02:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C569F21F8E9A for ; Sat, 25 May 2013 19:02:49 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4Q1w4QF021262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 18:58:04 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4Q1w4QF021262 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369533484; bh=vc7c1RRnH00K1cr/kzkGvnX40lM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fVq/4FzsLY4+gR3Hrjhw3LEuYCTzfvFIRpi0OVARC+KRs7+uRgavYb00nXA8l929y F1QtgZ0WlaS3Zf/vYEI7zDN2ySW7OPGHxHT4cJ6EtrCKtgYlx1qQQiQDwEArY7k12j hQLRqZc9yvd2HFIrgegfoqWxHVO4yks4OWsFWw0I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <51A02D23.6080101@dougbarton.us> Date: Sat, 25 May 2013 18:58:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 25 May 2013 18:58:04 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 02:02:50 -0000 On May 24, 2013, at 20:16 , Doug Barton wrote: > On 05/24/2013 02:52 AM, Lorenzo Colitti wrote: >> On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter >> > = wrote: >>=20 >> That's correct, of course. The underlying problem here is that the >> notion of concentric circles of scope that was originally = described >> for IPv6 is simply broken. We can't fix that in the context of >> describing ULA usage scenarios, so let's not try. >>=20 >>=20 >> Actually, I think the underlying problem as regards this specific = draft >> is that ULAs were not well thought-out. They came out of a compromise >> where no side got what it wanted and what we got was a >> poorly-understood, possibly unusable hybrid. >=20 > Or, ULAs are just fine for their intended purpose, it's just that you = don't like the purpose. :) I'm still waiting for someone to clearly state what that purpose is. Owen From markzzzsmith@yahoo.com.au Sat May 25 19:08:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1E21F8EBC for ; Sat, 25 May 2013 19:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8c4cUcdcGKl for ; Sat, 25 May 2013 19:08:33 -0700 (PDT) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) by ietfa.amsl.com (Postfix) with SMTP id 6037821F8EBB for ; Sat, 25 May 2013 19:08:33 -0700 (PDT) Received: from [98.139.215.143] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2013 02:08:32 -0000 Received: from [98.139.215.249] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2013 02:08:32 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 26 May 2013 02:08:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 801726.93771.bm@omp1062.mail.bf1.yahoo.com Received: (qmail 78052 invoked by uid 60001); 26 May 2013 02:08:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369534112; bh=KoVL/xCmy8GsynXp1mJfNL6JJVYRrte+dJN6gOj3YJg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LMgGddX/6eMhFtRZxl0P1QUgzXILPYWdPh4m6Un/T7gO+t9MYD62PhntIrVM+NhQHwAAu6NjEs8SAwJwaRVh0yCkw81bCEDiVlriP3/AsHzLMrUz8SLVZoXim4zGiRso6u/AzqwYE+4JmHzUV+tjHmByjCcCjEYAgwarN7pO1ws= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iqmNKjHuUIOY/h4QD59FuNGOtSn7HjqGOzoW40FWBvEs0pk7SB0LMFwqCbROeusK2tB9r4/7//sdMA91Iw7WdpERdP5JHTDVkIBSje1i+6dW7jWasoOcVUF8LUE501gJfFGQQwYUEuStPnOzgD2YVeda9ytToGnsINF071txuXE=; X-YMail-OSG: mxQEQwAVM1n9Yon.2QvVAMy3zFFne2wdgtGvWW.qkeWWlHW 0D2st36LvE_K8ZvOqdQqGKG9sx12wfJk2oMUfOHuYnXhrpGz9PGxmd8h0ef. Tfyz5u.FfRByNMo7IEYBw7b4llSic87yJeUD.zOk0YM01MzMARuV0Tq3fMog GI4Sf6OQsEU0pDFrnHOItxNHIoI8sqefYJBhdaPp9tGuoNnu.cwTN_bP9BOj MaSV6jNAufwENOj58V6UBOxhFNab5NWbn6svDSG7LTVujaxaIorox8SBqcZt q8c0UD8ai4srF9vuUySy16uTMZgnz56W9MnfcC85QGjPw6OI0u3Wpot6WT.0 bhIuIV8vZREDQPqhwLKxwdFQAGlxw06Z35Uxjy.xy0QbFbeQwefpOMbN8VIm JklaKqq4Vz0KJVXkNdyIrn1gAyNq.kHnq2hAggxG0ZpHAgcQwpHWhbfhdnAc LicvBFbIOzjTGoSnZkf8Saq7KsM69H9bZQnKlR3u_Xl0Z.lCxkAoIy7iBAQq 8OB2HXkAtrpLx0N9X75RTQhcrP1pzbRWYhbkxmg-- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Sat, 25 May 2013 19:08:32 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gQ2M6IHY2b3BzQGlldGYub3JnCj4gU2VudDogU3VuZGF5LCAyNiBNYXkgMjAxMyA0OjQyIEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRndkOiAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJlLTA3LnR4dAo.IAo.IAo.IE9uIE1heSAyNCwgMjAxMywgYXQgMTE6NDUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> Message-ID: <1369534112.63504.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Sat, 25 May 2013 19:08:32 -0700 (PDT) From: Mark Smith To: Owen DeLong , Alexandru Petrescu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 02:08:38 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: Alexandru Petrescu =0A> Cc: v6o= ps@ietf.org=0A> Sent: Sunday, 26 May 2013 4:42 AM=0A> Subject: Re: [v6ops] = Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt=0A> =0A> =0A> On May 24, = 2013, at 11:45 , Alexandru Petrescu =0A> wro= te:=0A> =0A>> Le 23/05/2013 23:08, Mark Smith a =E9crit :=0A>>> Hi,=0A>>>= =0A>>> =0A>>> Suggested changes:=0A>>> =0A>>> =0A>>> =0A>>> 1. Introduct= ion=0A>>> =0A>>> "... for delegating IPv6 prefixes to a LAN."=0A>>> =0A>>>= =0A>>> to=0A>>> =0A>>> ""... for delegating IPv6 prefixes to a single LA= N =0A> interface."=0A>>> =0A>>> Generally I think this intro text should m= ake it a bit clearer that=0A>>> these methods are only extending the /64 t= o a single LAN interface.=0A>> =0A> =0A> How can that work in the real worl= d?=0A> =0A> For example, with my iPhone 5 running on VZW, I seem to get the= same /64=0A> over the WiFi (mobile hotspot), the Cellular_PDP0 interface (= the actual=0A> cellular interface), BlueTooth (mobile hotspot), and USB (mo= bile hotspot).=0A>=A0=0A=0AI think the "LAN interface" in this draft is fro= m the perspective of IPv6, and in your scenario, all those interfaces, if t= hey're all using the same /64, are a single LAN (perhaps they're bridged or= some similar trick below IPv6).=0A=0AHowever, maybe it would be better to = adopt the IPv6 RFC2461 "Link" terminology i.e. this draft is extending the = use of the 3GPP /64 prefix onto another link available on the UE, such as a= Wifi interface etc.=0A=0A> From my perspective that's 3 LAN interfaces and= a WAN interface sharing the=0A> same /64.=0A> =0A>> Yes.=0A>> =0A>> More= over, it should be clear that this extension only works with only=0A>> one= level of extension (one cant have 64share-64share-... indefinitely,=0A>> = not even twice).=0A>> =0A> =0A> This part makes sense to me.=0A> =0A> But b= ridging the 64share prefix across multiple LAN interfaces on the=0A> device= (or even extending it via bridges on the LAN side) does not seem=0A> to be= a problem IMHO.=0A> =0A>> This could go as far as to say that the 64share= method works only for=0A>> static UEs.=A0 It sounds negative, I know, but= the reliability of this=0A>> should be acknowledged.=0A> =0A> I wouldn't = go quite that far. Acknowledging the limitations makes sense to =0A> me.=0A= > Expanding upon those limitations to say that nobody can make a decision t= o=0A> accept them and deploy anyway is not correct, IMHO.=0A> =0A> Owen=0A>= =0A> _______________________________________________=0A> v6ops mailing lis= t=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From brian.e.carpenter@gmail.com Sat May 25 19:48:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE3D21F8EB2 for ; Sat, 25 May 2013 19:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd+xHJYkbAlV for ; Sat, 25 May 2013 19:48:47 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id DE11021F8EAF for ; Sat, 25 May 2013 19:48:47 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so2415466pde.9 for ; Sat, 25 May 2013 19:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4R/D1c07Rsg8A71hOs6yIUotP6C/SMF6zHmXYEnUnNY=; b=DsDVGW2PQsp/501oMvIPdJrEkL/H6BRKZBhx3G4uqXrbR560gFCjo3VpVKhmyAv8Kp nj+PP1GDNKZ9JOilksgSACtdvpZEMs1eGPcXzJQ1yZyk+2IC8TfH3PEQruxDOndXS8M9 Y2vJfbpNf4uG1fbbtN2+f90Wk3wufk4DOhCPWxvdpEt1qiBrcWut9WiwCMY+VHDWCzsq 924aX57PKiu0IIRRth3mPvZ36ETMX/TiGLmvY7N8gX3Fvbzz7qtG5Ee2iJ6+eEyrLxhT BOtOEfKyclorZE8cELUgdWqN7ClTg+irCJ8zDw3sfikb0yBJTCFCsE6ZvYTzIydH82x0 A8Bg== X-Received: by 10.68.103.194 with SMTP id fy2mr23787432pbb.158.1369536527658; Sat, 25 May 2013 19:48:47 -0700 (PDT) Received: from [192.168.1.2] (82.252.252.27.dyn.cust.vf.net.nz. [27.252.252.82]) by mx.google.com with ESMTPSA id vv6sm24298008pab.6.2013.05.25.19.48.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 May 2013 19:48:45 -0700 (PDT) Message-ID: <51A1781A.3040903@gmail.com> Date: Sun, 26 May 2013 14:48:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 02:48:53 -0000 On 26/05/2013 13:58, Owen DeLong wrote: > On May 24, 2013, at 20:16 , Doug Barton wrote: > >> On 05/24/2013 02:52 AM, Lorenzo Colitti wrote: >>> On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter >>> > wrote: >>> >>> That's correct, of course. The underlying problem here is that the >>> notion of concentric circles of scope that was originally described >>> for IPv6 is simply broken. We can't fix that in the context of >>> describing ULA usage scenarios, so let's not try. >>> >>> >>> Actually, I think the underlying problem as regards this specific draft >>> is that ULAs were not well thought-out. They came out of a compromise >>> where no side got what it wanted and what we got was a >>> poorly-understood, possibly unusable hybrid. >> Or, ULAs are just fine for their intended purpose, it's just that you don't like the purpose. :) > > I'm still waiting for someone to clearly state what that purpose is. I really don't see what's wrong with the Abstract of RFC 4193. If you don't see a need personally or for your customers, that's fine. All the IETF does is provide mechanisms; users decide which ones to use. Brian From owen@delong.com Sat May 25 22:37:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3046821F8F11 for ; Sat, 25 May 2013 22:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozeY8eq85giU for ; Sat, 25 May 2013 22:37:45 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A638B21F8EEC for ; Sat, 25 May 2013 22:37:45 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4Q5Yish024026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 22:34:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4Q5Yish024026 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369546484; bh=AtadjP+NXNHwTWStW7LbVkljZi0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KSGcutayNXIYJrTo/Pp+apHv47rFdGHwBu1hNjiMI9cV07YumTJCm6WTYAZSkplg3 hQFA358xn+90Rw6/iVgbEz3VvJNOa8ZOTyzmHpZIOuIgivlFbFgpdVJh0hvP8fe87s NZ3lkLI9BRcgGLLxVQJS5c6AO+azBWBMKRZumpjk= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <1369534112.63504.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Sat, 25 May 2013 22:34:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7278B90C-991D-4A85-A562-D8BF116DCFF8@delong.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <1369534112.63504.YahooMailNeo@web142504.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 25 May 2013 22:34:44 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 05:37:47 -0000 >>>>=20 >>>> Generally I think this intro text should make it a bit clearer that >>>> these methods are only extending the /64 to a single LAN interface. >>>=20 >>=20 >> How can that work in the real world? >>=20 >> For example, with my iPhone 5 running on VZW, I seem to get the same = /64 >> over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the = actual >> cellular interface), BlueTooth (mobile hotspot), and USB (mobile = hotspot). >> =20 >=20 > I think the "LAN interface" in this draft is from the perspective of = IPv6, and in your scenario, all those interfaces, if they're all using = the same /64, are a single LAN (perhaps they're bridged or some similar = trick below IPv6). >=20 > However, maybe it would be better to adopt the IPv6 RFC2461 "Link" = terminology i.e. this draft is extending the use of the 3GPP /64 prefix = onto another link available on the UE, such as a Wifi interface etc. >=20 Agreed... If the terminology were changed form interface (which has a = vague meaning in IPv6) to link (which is more specific and more = appropriate), then I would agree. Owen From owen@delong.com Sat May 25 22:37:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0C21F8FDC for ; Sat, 25 May 2013 22:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQnOvnH97ko4 for ; Sat, 25 May 2013 22:37:51 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB8F21F8FBE for ; Sat, 25 May 2013 22:37:51 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4Q5b7o3024054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 22:37:07 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4Q5b7o3024054 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369546627; bh=uqEPufxfTk0ePO5mIo4pqE2Rnks=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nA0n5bDBn6fZjO6sg5i0LejQ1rBXGZ9qicqF1wwGHHuPRAfXhc7A8m+NNmoAskjKz u0lVb6KnklhkZM4JeH+z3ynBla/SLTuka8oB37khqSh/46T09VmRkhn6aq+2wOeqmn 3JKP047mJQNso5aTCgLjVBabHuWIWvIx/S2RxRs8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <51A1781A.3040903@gmail.com> Date: Sat, 25 May 2013 22:37:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 25 May 2013 22:37:07 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 05:37:52 -0000 On May 25, 2013, at 19:48 , Brian E Carpenter = wrote: > On 26/05/2013 13:58, Owen DeLong wrote: >> On May 24, 2013, at 20:16 , Doug Barton wrote: >>=20 >>> On 05/24/2013 02:52 AM, Lorenzo Colitti wrote: >>>> On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter >>>> > = wrote: >>>>=20 >>>> That's correct, of course. The underlying problem here is that = the >>>> notion of concentric circles of scope that was originally = described >>>> for IPv6 is simply broken. We can't fix that in the context of >>>> describing ULA usage scenarios, so let's not try. >>>>=20 >>>>=20 >>>> Actually, I think the underlying problem as regards this specific = draft >>>> is that ULAs were not well thought-out. They came out of a = compromise >>>> where no side got what it wanted and what we got was a >>>> poorly-understood, possibly unusable hybrid. >>> Or, ULAs are just fine for their intended purpose, it's just that = you don't like the purpose. :) >>=20 >> I'm still waiting for someone to clearly state what that purpose is. >=20 > I really don't see what's wrong with the Abstract of RFC 4193. >=20 The abstract is fine. However, it doesn't answer the question asked. The = abstract does a great job of describing what ULA does. It does nothing to explain what problem that solves or what purpose it = serves in doing so. > If you don't see a need personally or for your customers, that's > fine. All the IETF does is provide mechanisms; users decide which > ones to use. Ideally, it would be nice if the IETF focused on mechanisms that had a = real world purpose. Solutions looking for a problem tend to create more = problems than they solve. In many ways, ULA seems to fit that = definition. Owen From owen@delong.com Sat May 25 22:37:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4921F8FE9 for ; Sat, 25 May 2013 22:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AotrUW-c8u+V for ; Sat, 25 May 2013 22:37:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0176C21F8FBE for ; Sat, 25 May 2013 22:37:52 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4Q5XK9K024016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 May 2013 22:33:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4Q5XK9K024016 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369546400; bh=lc+9TeTYsn2Zn5Fmb3S5AUEnGP8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=PcMmKCQ0cbet2xqCmd76U3LNvctL2qcMm8fYyX3nMdXMcLDznemcmIARIGgdAKEey ZzF2WnU8eLm+phumGuDGnQnEscaC+H7AJ7mnHeqU0gmImDWgvxj/4xTEeLtUbOJkTJ 7/eTyy/hTiFR/WVMZQWhgn0TW5scqx84JLrOtVYE= Content-Type: multipart/alternative; boundary="Apple-Mail=_5511B82A-42C3-4976-8A91-66D1E81ACF83" Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: Date: Sat, 25 May 2013 22:33:19 -0700 Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> To: "cb.list6" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 25 May 2013 22:33:20 -0700 (PDT) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 05:37:53 -0000 --Apple-Mail=_5511B82A-42C3-4976-8A91-66D1E81ACF83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 25, 2013, at 13:26 , cb.list6 wrote: >=20 > On May 25, 2013 11:43 AM, "Owen DeLong" wrote: > > > > > > On May 24, 2013, at 11:45 , Alexandru Petrescu = wrote: > > > > > Le 23/05/2013 23:08, Mark Smith a =E9crit : > > >> Hi, > > >> > > >> > > >> Suggested changes: > > >> > > >> > > >> > > >> 1. Introduction > > >> > > >> "... for delegating IPv6 prefixes to a LAN." > > >> > > >> > > >> to > > >> > > >> ""... for delegating IPv6 prefixes to a single LAN interface." > > >> > > >> Generally I think this intro text should make it a bit clearer = that > > >> these methods are only extending the /64 to a single LAN = interface. > > > > > > > How can that work in the real world? > > > > For example, with my iPhone 5 running on VZW, I seem to get the same = /64 > > over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the = actual > > cellular interface), BlueTooth (mobile hotspot), and USB (mobile = hotspot). > > > > =46rom my perspective that's 3 LAN interfaces and a WAN interface = sharing the > > same /64. > > >=20 > At the same time? >=20 >=20 Yes.. > In any event, that implementation you mentioned is not publicly = documented. The folks at Apple and Verizon are welcome to share their = wisdom on this topic. >=20 Agreed. I wish they would/hope they do. However, bottom line, it's = running code today. > In any event, the work of this draft is to use the open ietf process = to get folks on the same page so the wheel does not get reinvented = several times in a vacume. >=20 Agreed. However, that doesn't mean we need to invent an inferior wheel. Owen --Apple-Mail=_5511B82A-42C3-4976-8A91-66D1E81ACF83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 cb.list6@gmail.com> = wrote:

On May 25, 2013 11:43 AM, "Owen DeLong" <owen@delong.com> wrote:
>
>
> On May 24, 2013, at 11:45 , Alexandru Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:
>
> > Le 23/05/2013 23:08, Mark Smith a =E9crit :
> >> Hi,
> >>
> >>
> >> Suggested changes:
> >>
> >>
> >>
> >> 1. Introduction
> >>
> >> "... for delegating IPv6 prefixes to a LAN."
> >>
> >>
> >> to
> >>
> >> ""... for delegating IPv6 prefixes to a single LAN = interface."
> >>
> >> Generally I think this intro text should make it a bit = clearer that
> >> these methods are only extending the /64 to a single LAN = interface.
> >
>
> How can that work in the real world?
>
> For example, with my iPhone 5 running on VZW, I seem to get the = same /64
> over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the = actual
> cellular interface), BlueTooth (mobile hotspot), and USB (mobile = hotspot).
>
> =46rom my perspective that's 3 LAN interfaces and a WAN interface = sharing the
> same /64.
>
At the same = time?

Yes..

In any event, that implementation you = mentioned is not publicly documented. The folks at Apple and Verizon are = welcome to share their wisdom on this topic. =
Agreed. I wish they would/hope they do. However, = bottom line, it's running code today.
In any event, the work of this draft is to use the = open ietf process to get folks on the same page so the wheel does not = get reinvented several times in a vacume.

Agreed. = However, that doesn't mean we need to invent an inferior = wheel.

Owen

= --Apple-Mail=_5511B82A-42C3-4976-8A91-66D1E81ACF83-- From fred@cisco.com Sun May 26 13:05:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AFB21F8F7A for ; Sun, 26 May 2013 13:05:10 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id systw0EZLPTs for ; Sun, 26 May 2013 13:05:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40921F8825 for ; Sun, 26 May 2013 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=645; q=dns/txt; s=iport; t=1369598705; x=1370808305; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R/rYE/tFa33aL7TVjkbK2WlcvqmEGk53KkChra2EI/k=; b=HPxxjeDPYv9Ak+20AlLfcljTg1IAmcg/OoCiviXaT0DmuRKxPo/nBKRZ Ro3RRIuu6Fw/vzTw97W1jjjVwawenvcXzpD/SbHAJ/b6M3AHDY1QF9CLj IfoUFXGYcTU4zP/zPxJf9RPa9e2zIetGprLk9iBZZ3T5wXr74KhakTa0y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAIlqolGtJV2c/2dsb2JhbABZgwgwwgCBBBZtB4IlAQQ6PxIBKhRCJwQODYgFvF+ObDGCemEDqHuDD4In X-IronPort-AV: E=Sophos;i="4.87,746,1363132800"; d="scan'208";a="215188781" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 26 May 2013 20:05:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4QK54jx008455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 May 2013 20:05:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sun, 26 May 2013 15:05:04 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-mobile-device-profile WGLC Thread-Index: AQHOWkxPOY3nGImAE0StxUmg6GAnag== Date: Sun, 26 May 2013 20:05:03 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8F7D7B@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-mobile-device-profile WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:05:10 -0000 This is to initiate a two week working group last call of http://tools.ietf= .org/html/draft-ietf-v6ops-mobile-device-profile. Please read it now. If yo= u find nits (spelling errors, minor suggested wording changes, etc), commen= t to the authors; if you find greater issues, such as disagreeing with a st= atement or finding additional issues that need to be addressed, please post= your comments to the list. We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make. From marka@isc.org Sun May 26 15:09:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B575921F930A for ; Sun, 26 May 2013 15:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOusrY+VtAru for ; Sun, 26 May 2013 15:09:07 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1995621F92F5 for ; Sun, 26 May 2013 15:09:06 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0EEC35F98CB; Sun, 26 May 2013 22:08:55 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369606146; bh=OOsrpya6Cd/lbpscYL+1+Lognty0rAyP4BvIHkf9aDI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ZNXJ+nnw5BKCtgmwHecqCFCumn1VfSRFr2ixWVaPf0zjpogKF8r/h+Mvosc5/HKma fQlPxXqoMgNP4QrlsA6uxShz6YYZgtRDwyrmZRlGxLTmRzZ1TTTGg3B7MGiIirU+yJ EXG1nHqqkMOYEtCYeaUSSRnAEiZe0uJCMx0vGvlE= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2B838216C43; Sun, 26 May 2013 22:08:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7BF0D34B09F4; Mon, 27 May 2013 08:08:44 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> In-reply-to: Your message of "Sat, 25 May 2013 22:37:07 -0700." <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> Date: Mon, 27 May 2013 08:08:44 +1000 Message-Id: <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 22:09:07 -0000 > Ideally, it would be nice if the IETF focused on mechanisms that had a real world purpose. Solutions > looking for a problem tend to create more problems than they solve. In many ways, ULA seems to fit > that definition. > > Owen Owen, there is no perfect solution to numbering residential networks. * getting addresses from a RIR works worse than ULA as you can't get them routed and RIR address are not in a well defined range. * getting addresses from a ISP doesn't work as you need addresses before your initial connection. Additionally they require full renumbering when switching providers or when the ISP decides to rejig their address plan. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Sun May 26 15:27:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D056E21F9418 for ; Sun, 26 May 2013 15:27:23 -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, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr82Y8qwmLJ0 for ; Sun, 26 May 2013 15:27:23 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 139A721F9416 for ; Sun, 26 May 2013 15:27:22 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id t60so2976387wes.11 for ; Sun, 26 May 2013 15:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LqefYmkMnaAHKNP/83+v7tccHXw5yvMrRvSRL/tRjEk=; b=CgddPwRb0aasLcZntEhSSV3aslJeO5sHaLvTUOcTrcfowMdnx7LQeU1YjBAob9JthL LzMD1iebnH6rIjrcZh01GEyLalQ7x3FXxwK/Njx2pGyztVj2E4KQE0CiV/FYTnKE60KE 1OS5MD609hn1nMyKjXkndhY/B8kgwa8eWvbgbcrze+PmN6fkDMA5fwvX9Sgfb3PW9+1z y9heloLKzcJztym5TCf/drmeLNdbD+bXOE4tqAgLFAGF8bV4DPXC3ZnuYYC0d3gjJZe0 KmpHjRcyoQhnHa6ARviM8RiIokNKifaXuWLebBWrBm3yvQyEqscnevxZIb7pW9s4iIdg UrPg== MIME-Version: 1.0 X-Received: by 10.194.179.198 with SMTP id di6mr6717783wjc.10.1369607242218; Sun, 26 May 2013 15:27:22 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Sun, 26 May 2013 15:27:22 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> Date: Sun, 26 May 2013 15:27:22 -0700 Message-ID: From: "cb.list6" To: Owen DeLong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 22:27:23 -0000 On Sat, May 25, 2013 at 10:33 PM, Owen DeLong wrote: > > On May 25, 2013, at 13:26 , cb.list6 wrote: > > > On May 25, 2013 11:43 AM, "Owen DeLong" wrote: >> >> >> On May 24, 2013, at 11:45 , Alexandru Petrescu >> wrote: >> >> > Le 23/05/2013 23:08, Mark Smith a =E9crit : >> >> Hi, >> >> >> >> >> >> Suggested changes: >> >> >> >> >> >> >> >> 1. Introduction >> >> >> >> "... for delegating IPv6 prefixes to a LAN." >> >> >> >> >> >> to >> >> >> >> ""... for delegating IPv6 prefixes to a single LAN interface." >> >> >> >> Generally I think this intro text should make it a bit clearer that >> >> these methods are only extending the /64 to a single LAN interface. >> > >> >> How can that work in the real world? >> >> For example, with my iPhone 5 running on VZW, I seem to get the same /64 >> over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actual >> cellular interface), BlueTooth (mobile hotspot), and USB (mobile hotspot= ). >> >> From my perspective that's 3 LAN interfaces and a WAN interface sharing >> the >> same /64. >> > > At the same time? > > > Yes.. > > In any event, that implementation you mentioned is not publicly documente= d. > The folks at Apple and Verizon are welcome to share their wisdom on this > topic. > > Agreed. I wish they would/hope they do. However, bottom line, it's runnin= g > code today. > > In any event, the work of this draft is to use the open ietf process to = get > folks on the same page so the wheel does not get reinvented several times= in > a vacume. > > > Agreed. However, that doesn't mean we need to invent an inferior wheel. > > Owen > well, we ship what gets rough consensus, not what is "best" for some value of "best" Back in the archives, we scoped the scenario to be one routed down-link due to folks concerns about loops that would result from having multiple interfaces up with the same prefix. i think the discussion was somewhere around here and how NDproxy was not acceptable http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html CB > From internet-drafts@ietf.org Sun May 26 23:24:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E3821F95EC; Sun, 26 May 2013 23:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW91MLALtkYW; Sun, 26 May 2013 23:24:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A621F9609; Sun, 26 May 2013 23:24:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527062419.26358.63084.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 23:24:19 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 06:24:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-03.txt Pages : 19 Date : 2013-05-26 Abstract: As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gert@space.net Mon May 27 03:24:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF421F90FD for ; Mon, 27 May 2013 03:24:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TgnBrZqu-7Z for ; Mon, 27 May 2013 03:24:55 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6421F8E12 for ; Mon, 27 May 2013 03:24:51 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5DD8360768 for ; Mon, 27 May 2013 12:24:50 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 397EB60735 for ; Mon, 27 May 2013 12:24:50 +0200 (CEST) Received: (qmail 16671 invoked by uid 1007); 27 May 2013 12:24:50 +0200 Date: Mon, 27 May 2013 12:24:50 +0200 From: Gert Doering To: Mark Andrews Message-ID: <20130527102450.GF2504@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:24:56 -0000 Hi, On Mon, May 27, 2013 at 08:08:44AM +1000, Mark Andrews wrote: > Owen, there is no perfect solution to numbering residential networks. > > * getting addresses from a RIR works worse than ULA as you can't get > them routed and RIR address are not in a well defined range. > > * getting addresses from a ISP doesn't work as you need addresses > before your initial connection. Additionally they require > full renumbering when switching providers or when the ISP decides > to rejig their address plan. Maybe it really should be stated twice per mail that this is talking about "large scale residentical ISPs" I can already see Owen speak up "of course my ISP is routing my IPv6 PI space". Yes, some will, and will take extra money for it (and that is all fine), but the vast majority of users will not go there. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From joelja@bogus.com Mon May 27 07:57:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D421F968E for ; Mon, 27 May 2013 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chrjdGi-YX8g for ; Mon, 27 May 2013 07:57:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D831E21F966B for ; Mon, 27 May 2013 07:57:14 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4REvAMY089675 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 27 May 2013 14:57:10 GMT (envelope-from joelja@bogus.com) Message-ID: <51A37445.4080802@bogus.com> Date: Mon, 27 May 2013 07:57:09 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Alexandru Petrescu References: <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726B3E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D729249@nkgeml506-mbx.china.huawei.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E1EE13@cph-ex1> <38AF7ABF-9A6A-41E0-82DB-17D38A281379@delong.com> <519FB699.6060708@gmail.com> <20130524203615.GW2504@Space.Net> <519FD778.7060807@bogus.com> <519FD971.7040608@gmail.com> In-Reply-To: <519FD971.7040608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 27 May 2013 14:57:11 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:57:24 -0000 On 5/24/13 2:19 PM, Alexandru Petrescu wrote: > Le 24/05/2013 23:11, joel jaeggli a �crit : >> On 5/24/13 1:36 PM, Gert Doering wrote: >>> Hi, >>> >>> On Fri, May 24, 2013 at 08:51:05PM +0200, Alexandru Petrescu wrote: >>>>> That doesn't mean that they don't need to support RA or that they >>>>> cannot >>>>> autoconfigure an address. There is no valid reason these devices >>>>> should >>>>> have burned-in ULA. Such an addressing scheme would, in fact, be >>>>> quite >>>>> dysfunctional. >>>> Not sure what you mean. >>>> >>>> But sure a device which has its address pre-configured could go >>>> very far >>>> in reducing its memory/cpu print. >> A decade ago dallas-semiconductor had a working v6 stack on a 8051 based >> 8 bit microcontroller with 64k of rom... > > That was then. > > Since then even smaller platforms are tried. > >> There seems to be small but quite persistent faction that insists on the >> notion that functionally limited systems are incapable of operating >> around the incredibly basic set of functional building blocks for an >> ipv6 network on their link-layer of choice. > > An autoconfiguration feature is a functionality, and compares badly to > whatever static preconfiguration, in terms of memory/cpu constraints. > > I really dont see why arguing against this, it's simply basics. A dynamically configured system may be dramatically less costly to setup and intergrate. it may be signficantly less brittle in the face of change and fail (on in fact not fail) a lot more gracefully. A statically configured system still has to employ NDP and unless you want really ugly failures in the face of misconfiguration, guard against duplicates so the dynamic code path remains. it is being discussed because you bring up the question the context of ula usage recommendations draft. > > Alex > > > Frankly I don't see it. IETF >> participants have invested a lot of productive time and energy in >> low-power/low signalling/low bandwidth embedded networking, stripping >> out the things that make it flexible robust and easy to deploy in the >> interest of something that might notionally be more compact then the >> toolkit we have at present, seems incredibly limiting. >> >> Can you do it? Sure. In fact, nobody is going to stop you. >> >> Is it an "improvement"? Maybe by some measure, but I kind of doubt it. >>> As could a device without a network stack. >>> >>> Your point being? >>> >>> Gert Doering >>> -- NetMaster >> >> >> > > From lorenzo@google.com Mon May 27 08:45:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBA621F8F7A for ; Mon, 27 May 2013 08:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fiqVkhoYy4X for ; Mon, 27 May 2013 08:45:58 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5CA21F8F44 for ; Mon, 27 May 2013 08:45:58 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ii15so1036730qab.3 for ; Mon, 27 May 2013 08:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lEn9JkM0qvKbCznchc5cj/ytPP1vFhDiV7x3bq78634=; b=K9GtyQS4JBrZv6vuTmBaPbTPNjcQMtkNTAjGWxP/tUYs1a/WeOdDvOMc68CoM/SgPM FLU3TUu1UGsvlNtagV3e+SCwMVHgs8vYawVa6fm+NQPpOA6sFk07UTmRaSEj956SWm4O 7rOU1SRsu7iM8wB9Uoy6423UqEun3cUnsMmvNWlSOjdCuqTftFE1e9vFju7zpXQjlu8/ 7kpmu/YrkcOaocYFtA+R5HklnyTEeDBD4OTDyR8dvFzTQuw/cnCg7oaSmipmrICyO1Qj IMLM04OwkoYfE+Krhyta4JTW6b7ZhZcAhjjyaeJXsqR+F21AqlhqgqWXgjWoZmOfEn9J /1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=lEn9JkM0qvKbCznchc5cj/ytPP1vFhDiV7x3bq78634=; b=egnrbrIjnuLTFVhgOnKWekXkITMS7bVK1zZnf+Hwt8LCfyiRsGMJvqLv1eDj40PsFP Kjvvu6/F5X43pDANVCRBX7+RRBdOoAQD4NkN74bmmi8ISrdxzaIaTsPLloOCJwLzQpv6 8yt66SfIYruCbxSNy3uXotwgPQR3uS0HCxZ+icuJyDJxXc8IWeXZDXwl/T8hVPhNQ9zK 3Hz1APZsjL/7jOL/A7BJy8MYP3Du2JC0B1qDNH/xoBrPWrn5GAsJdMjmmiP0Tv9Aa+Mh 79AaiThK/CMND/z0jUiihYwlTgHzfZiMNgDhaLo3a8p+cB5lTV+PbeoiQMsXbNHtaVb9 QSFA== X-Received: by 10.229.196.200 with SMTP id eh8mr10740087qcb.96.1369669557496; Mon, 27 May 2013 08:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Mon, 27 May 2013 08:45:36 -0700 (PDT) In-Reply-To: <51A02D23.6080101@dougbarton.us> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> From: Lorenzo Colitti Date: Tue, 28 May 2013 00:45:36 +0900 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=001a11c357c46f739a04ddb50b60 X-Gm-Message-State: ALoCoQnrPzmFOWg4ueKJQoIDvqLoxRHEdlh9tpb/D2Wj0zFbgTW3f7Hctms7f2/303QDYqcggSZZEbURUC9iaLyJ8fO32fUz04O8nFGegHu77uM08cV3kaaArkO+y/qxFjh3G2gGD0bq55b4jbWwQjggjjqxAxUa6sUPSO7rco2o6wOaYCNlLHSm3DGkraSTQRm1x6uyVJ2u Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 15:45:58 -0000 --001a11c357c46f739a04ddb50b60 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 25, 2013 at 12:16 PM, Doug Barton wrote: > Or, ULAs are just fine for their intended purpose, it's just that you > don't like the purpose. :) > I don't feed trolls unless they tell me what to eat :-) --001a11c357c46f739a04ddb50b60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 25, 2013 at 12:16 PM, Doug Barton <dougb@do= ugbarton.us> wrote:

Or, ULAs are just fine for their intended purpose, it's just = that you don't like the purpose. :)

I don't feed trolls unless they tell me wha= t to eat :-)
--001a11c357c46f739a04ddb50b60-- From lorenzo@google.com Mon May 27 08:48:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6F21F96B1 for ; Mon, 27 May 2013 08:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id The6kAvR4oOz for ; Mon, 27 May 2013 08:48:19 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id A192E21F96B0 for ; Mon, 27 May 2013 08:48:19 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id bn16so1041311qab.16 for ; Mon, 27 May 2013 08:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MzoRCa+27eT+3gcD+RpicXQv2Q7FGUQwGGRrg1OUZEA=; b=OB9CfgvdjW/Hx/34Gk2Tz0LR9Ifb7kTgV1jIcX+xqyU77WmTh7KFsYdnE7wljCo0Aw XS5wOmwvH6FfnPKLqj3QQ8VslgAZelWRPdbAasUNQ7AMeHbaOt+2J7jnsPO325ZLUIgy oF48B8IujExffMQLBpoRaSbWAKOwOo8yX0vGzAv9XqKvDpYzIRKQsxYanCGAVL7NJ950 UjGZSNRgPZj9375cnuD6ogRdz4YLXD0m6ayqFIiIJ7KEuCATWsmH5pXCIN0GaK3lrq4N evJeHFBTVLQXBJ9k5TGDxp3ApC76vQS7DkOk1Piutkb5Jv1yBfXceLL9tGSe8yUn6pOY 41qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=MzoRCa+27eT+3gcD+RpicXQv2Q7FGUQwGGRrg1OUZEA=; b=cNN5vVxnUNfBvgymMCgRb0YLgmXj2kvMqKvtaVrYKo5AJD8y3FDPIimjMaX4eL1dwq VM3mkyYIeCq/xCEU9IElqkMwnAbkjOXhx7AdRkheH/uRPZETfXyJrR/B26cw7Civh1Ds jqSPW8wHmzSzVsvfvVaQ7GE/sfcHqO8oyCqfPh/hs0pH7tw1ZuSGwzONvSEIYVbNlzz1 25Ae2msZ0GgBqiO44Y9yY8G6iOtfTl4VultbINwIElGzrazWsyMgforb6srQHTNvBenz /BbIaXv5bpXXuy+48zcQaFf/GKhGRiihGKfTpXamQndGK0WqFTOJowoySQu5g5BF/rWl whpA== X-Received: by 10.224.214.134 with SMTP id ha6mr28256734qab.77.1369669699092; Mon, 27 May 2013 08:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Mon, 27 May 2013 08:47:58 -0700 (PDT) In-Reply-To: <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> From: Lorenzo Colitti Date: Tue, 28 May 2013 00:47:58 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=20cf300fb23de007fd04ddb513ff X-Gm-Message-State: ALoCoQlMMDkiJvxTgkyQVwsUQWZBcjVBpgdJzsC8UoIHD/5hmMqhamUbYmBdOe5r6qCk7/eMtdscW/4xcS3mXsVgx6SDyhwYZ/F0lKsXUzhbYwujXUUhv9xbcs7CVRH8+YKVJWtk83Bn6g1ItD2McYdk3MbZUgDo3yPCeLiFXlFWKpBRn23OE3SeLMCz7h8EkNAPONa6LnoX Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 15:48:20 -0000 --20cf300fb23de007fd04ddb513ff Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 27, 2013 at 7:08 AM, Mark Andrews wrote: > > > Ideally, it would be nice if the IETF focused on mechanisms that had a > real world purpose. Solutions > > looking for a problem tend to create more problems than they solve. In > many ways, ULA seems to fit > > that definition. > > Owen, there is no perfect solution to numbering residential networks. > > * getting addresses from a RIR works worse than ULA as you can't get > them routed and RIR address are not in a well defined range. > You can't get ULAs routed either. > * getting addresses from a ISP doesn't work as you need addresses > before your initial connection. Additionally they require > full renumbering when switching providers or when the ISP decides > to rejig their address plan. > Agreed, ULA gives you stable addresses for a disconnected network. --20cf300fb23de007fd04ddb513ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 27, 2013 at 7:08 AM, Mark Andrews <marka@isc.org<= /a>> wrote:

> Ideally, it would be nice if the IETF focused on mechanisms that had a= real world purpose. Solutions
> =A0looking for a problem tend to create more problems than they solve.= In many ways, ULA seems to fit
> that definition.

Owen, there is no perfect solution to numbering residential networks.=

* getting addresses from a RIR works worse than ULA as you can't get =A0 them routed and RIR address are not in a well defined range.

You can't get ULAs routed either.
=
=A0
* getting addresses from a ISP doesn't work as you need addresses
=A0 before your initial connection. =A0Additionally they require
=A0 full renumbering when switching providers or when the ISP decides
=A0 to rejig their address plan.

= Agreed, ULA gives you stable addresses for a disconnected network.
--20cf300fb23de007fd04ddb513ff-- From owen@delong.com Mon May 27 10:04:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FCB21F9720 for ; Mon, 27 May 2013 10:04:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZYRI0VE-2tH for ; Mon, 27 May 2013 10:04:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A93521F971B for ; Mon, 27 May 2013 10:04:24 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4RH22C2001205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 May 2013 10:02:02 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4RH22C2001205 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369674123; bh=/jazubyk85muR1xXzEHMiY9s8+w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ym4pzsyMErO1sQE3It5efhEVuYnEzrD2Yhum5aykZKbeRU/SmJNbVV3usZzRHmi4+ jGViuGHUD8NJ/v1gC9HygJFG9qjWhB7o5EDcl0Bf7NGZJR0UJNTw+K1JNIwz5b9Yle mVsOl7MYv73C20hGdTG3ZT5bjEMCfHtMnEibrHUI= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: Date: Mon, 27 May 2013 10:02:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> To: "cb.list6" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 27 May 2013 10:02:03 -0700 (PDT) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:04:26 -0000 >> Agreed. However, that doesn't mean we need to invent an inferior = wheel. >>=20 >> Owen >>=20 >=20 > well, we ship what gets rough consensus, not what is "best" for some > value of "best" >=20 Unless there is a reason to do so, I cannot imagine that rational = individuals would come to consensus on an inferior choice. > Back in the archives, we scoped the scenario to be one routed > down-link due to folks concerns about loops that would result from > having multiple interfaces up with the same prefix. Ah, but as was described earlier, interface !=3D link and if we simply = move to the term link, the problem is resolved. The use of the term = interface is what is problematic here. Multiple interfaces which are = bridged together at layer 2 constitute a single link from an IPv6 = perspective. > i think the discussion was somewhere around here and how NDproxy was > not acceptable >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and > http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html Which only applies in the case of multiple links with the same prefix, = not multiple interfaces within the same link. Owen From owen@delong.com Mon May 27 10:19:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E919921F96B8 for ; Mon, 27 May 2013 10:19:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzt951iaPE4j for ; Mon, 27 May 2013 10:19:32 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4352521F9699 for ; Mon, 27 May 2013 10:19:32 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4RHE038004145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 May 2013 10:14:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4RHE038004145 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369674840; bh=qH1X5oPEsRpnBbEqIIFLVmLcOW8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IKjDoy1yQa1xKLwEQWqWuZ5N42Kdg12u2TmZLDV6rPQFtU6435KK945hl6amcpzxq ZnjNdDZuREE7ByGz6Z2Pyv7xSP2SjxmPskOZfYH8suF17ETIWExkxAFq4gTvDcB+px BcGt9PQzB6HDRY5jta8lpqySRxnGbwutjUqjRO4w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Owen DeLong In-Reply-To: <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> Date: Mon, 27 May 2013 10:14:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 27 May 2013 10:14:00 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:19:33 -0000 On May 26, 2013, at 15:08 , Mark Andrews wrote: >=20 >> Ideally, it would be nice if the IETF focused on mechanisms that had = a real world purpose. Solutions >> looking for a problem tend to create more problems than they solve. = In many ways, ULA seems to fit=20 >> that definition. >>=20 >> Owen >=20 > Owen, there is no perfect solution to numbering residential networks. >=20 > * getting addresses from a RIR works worse than ULA as you can't get > them routed and RIR address are not in a well defined range. >=20 False... http://www.tunnelbroker.net Q.E.D. > * getting addresses from a ISP doesn't work as you need addresses > before your initial connection. Additionally they require > full renumbering when switching providers or when the ISP decides > to rejig their address plan. Arguable, but not completely unreasonable. Though I question what value = these unroutable addresses provide that are not available from RIR = addresses which you may be unable to route. Owen From cb.list6@gmail.com Mon May 27 10:35:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C706321F8DFC for ; Mon, 27 May 2013 10:35: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3WWXjW6oSNa for ; Mon, 27 May 2013 10:35:02 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34021F8F87 for ; Mon, 27 May 2013 10:35:01 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p60so4689972wes.34 for ; Mon, 27 May 2013 10:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVv+5ZfdBrj0eVGe8X6b/ZqcCa1pn+JS7NDSWIrAgiA=; b=rKQZwAR41x5GDbz8CAHZZLpFF6UL9wfSDH5S8Lptc/j3oNcsfo4xblk5QopDSQuf8p yl9UYA3hJ5/nZ6UBAt0+TqAn1Ru+gd5vQfgybleRpfaesRGvM5fzb/CX6j9RoENia51q kBXGcMOVvysz56ujDSxnY+PW+uUFZuBSWcGNkScleWnNVlipbY0v0iimN7dLQIpe2sPG C+VkF8ClWwu69lCPafSzISD6fGbNAawQ7RXOnrcu5u6oYjoLKlUzYwHIyg/uAQ7boXEq 6K/MU4ZUQm4U7AJj0+r1BgAq7rE89Mk4VuRJ6xRCgkeDrNtYR5iQaSK4IXxQzAryCr+z JF6g== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr9077651wic.7.1369676100767; Mon, 27 May 2013 10:35:00 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 27 May 2013 10:35:00 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 27 May 2013 10:35:00 -0700 (PDT) In-Reply-To: <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> Date: Mon, 27 May 2013 10:35:00 -0700 Message-ID: From: "cb.list6" To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c2257471946a04ddb69155 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:35:02 -0000 --001a11c2257471946a04ddb69155 Content-Type: text/plain; charset=ISO-8859-1 On May 27, 2013 10:04 AM, "Owen DeLong" wrote: > > >> Agreed. However, that doesn't mean we need to invent an inferior wheel. > >> > >> Owen > >> > > > > well, we ship what gets rough consensus, not what is "best" for some > > value of "best" > > > > Unless there is a reason to do so, I cannot imagine that rational individuals would come to consensus on an inferior choice. > > > Back in the archives, we scoped the scenario to be one routed > > down-link due to folks concerns about loops that would result from > > having multiple interfaces up with the same prefix. > > Ah, but as was described earlier, interface != link and if we simply move to the term link, the problem is resolved. The use of the term interface is what is problematic here. Multiple interfaces which are bridged together at layer 2 constitute a single link from an IPv6 perspective. > > > i think the discussion was somewhere around here and how NDproxy was > > not acceptable > > > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and > > http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html > > Which only applies in the case of multiple links with the same prefix, not multiple interfaces within the same link. > > Owen > Ok, so in the draft we change interface to link and the magic of how loops and so on are prevented is out of scope since it is in the domain of "link"? I am fine with that. Is that "one word" change that is needed to close this particular topic? CB --001a11c2257471946a04ddb69155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On May 27, 2013 10:04 AM, "Owen DeLong" <owen@delong.com> wrote:
>
> >> Agreed. However, that doesn't mean we need to invent an i= nferior wheel.
> >>
> >> Owen
> >>
> >
> > well, we ship what gets rough consensus, not what is "best&q= uot; for some
> > value of "best"
> >
>
> Unless there is a reason to do so, I cannot imagine that rational indi= viduals would come to consensus on an inferior choice.
>
> > Back in the archives, we scoped the scenario to be one routed
> > down-link due to folks concerns about loops that would result fro= m
> > having multiple interfaces up with the same prefix.
>
> Ah, but as was described earlier, interface !=3D link and if we simply= move to the term link, the problem is resolved. The use of the term interf= ace is what is problematic here. Multiple interfaces which are bridged toge= ther at layer 2 constitute a single link from an IPv6 perspective.
>
> > i think the discussion was somewhere around here and how NDproxy = was
> > not acceptable
> >
> > http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.htm= l and
> > http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.htm= l
>
> Which only applies in the case of multiple links with the same prefix,= not multiple interfaces within the same link.
>
> Owen
>

Ok, so in the draft we change interface to link and the magi= c of how loops and so on are prevented is out of scope since it is in the d= omain of "link"?

I am fine with that.

Is that "one word" change that is=A0 needed to clo= se this particular topic?

CB
--001a11c2257471946a04ddb69155-- From marka@isc.org Mon May 27 16:07:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310A821F9080 for ; Mon, 27 May 2013 16:07:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPQWZLqDXdLM for ; Mon, 27 May 2013 16:07:49 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6F58721F9003 for ; Mon, 27 May 2013 16:07:49 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 80D4DC9465; Mon, 27 May 2013 23:07:42 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369696068; bh=XAVcAcimZxkPudulNiGEQa+7NKjsaH7frUeHCt/w9/Q=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=tLyOjtBSNB1WPgs3gtcXMySJnfWTCA7K5hVqWAAx4iafIPf67ECZEwnSa1YGvnYCu 3oRZg/ZgWmEvWSo7Sq1maWhlv5slaTzPA8ovE2lP5aT8VmhuZzSnY3wMiW7UQiFdWC He3u0r0FhC5l6ZXIMaPg8fWdCi6hd6h+5NBGGU0g= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 27 May 2013 23:07:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8840:f6d4:24ed:35b8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3DF76216C40; Mon, 27 May 2013 23:07:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3930534B6070; Tue, 28 May 2013 09:07:40 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> In-reply-to: Your message of "Mon, 27 May 2013 10:14:00 -0700." Date: Tue, 28 May 2013 09:07:40 +1000 Message-Id: <20130527230740.3930534B6070@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: v6ops@ietf.org Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 23:07:50 -0000 In message , Owen DeLong write s: > > On May 26, 2013, at 15:08 , Mark Andrews wrote: > > > > >> Ideally, it would be nice if the IETF focused on mechanisms that had a > real world purpose. Solutions > >> looking for a problem tend to create more problems than they solve. In > many ways, ULA seems to fit > >> that definition. > >> > >> Owen > > > > Owen, there is no perfect solution to numbering residential networks. > > > > * getting addresses from a RIR works worse than ULA as you can't get > > them routed and RIR address are not in a well defined range. > > > > False... http://www.tunnelbroker.net Q.E.D. And the number of untunneled residential customers HE have is what now? > > * getting addresses from a ISP doesn't work as you need addresses > > before your initial connection. Additionally they require > > full renumbering when switching providers or when the ISP decides > > to rejig their address plan. > > Arguable, but not completely unreasonable. Though I question what value > these unroutable addresses provide that are not available from RIR > addresses which you may be unable to route. > > Owen Owen go and try and bring up a new IPv6 only home network with two broadcast domains with no current external connectivity and see how far you get. Printer in one broadcast domain and a PC in the other. Now try to print a test page from that PC. This isn't (or won't be) a uncommon senario. This is what we are designing to support. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sander@steffann.nl Mon May 27 16:18:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6D021F8F11 for ; Mon, 27 May 2013 16:18:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnVLVIiLgRLb for ; Mon, 27 May 2013 16:18:11 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4021F8F00 for ; Mon, 27 May 2013 16:18:10 -0700 (PDT) Received: from [IPv6:2a00:8640:1::395d:c7bf:e0c0:4979] (unknown [IPv6:2a00:8640:1:0:395d:c7bf:e0c0:4979]) by mail.sintact.nl (Postfix) with ESMTP id 1562D2063; Tue, 28 May 2013 01:18:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Sander Steffann In-Reply-To: <20130527230740.3930534B6070@drugs.dv.isc.org> Date: Tue, 28 May 2013 01:18:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> <20130527230740.3930534B6070@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 23:18:12 -0000 Hi Mark, > go and try and bring up a new IPv6 only home network with two > broadcast domains with no current external connectivity and see how > far you get. Printer in one broadcast domain and a PC in the other. > Now try to print a test page from that PC. This isn't (or won't > be) a uncommon senario. This is what we are designing to support. +1 Sander From marka@isc.org Mon May 27 17:00:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A621F9128 for ; Mon, 27 May 2013 17:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kb8TKBucXky for ; Mon, 27 May 2013 17:00:08 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B9F6E21F90E0 for ; Mon, 27 May 2013 17:00:07 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 00E7F5F98B7; Mon, 27 May 2013 23:59:56 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369699206; bh=S+gT1UZvrZblbuYnvzJYZAfmq9AcQPBJikXAK2GB7KY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ohjqXX+Fi87iQmA4wTTM60lf11FaFVzSgTaOqQYxoBArd1E/i7LO6lfYFo/E42Cwu iAxZjzPl8+7Q5lr05+cDlRDHDDise+R9lQzWgi+6Z2gBAPxs22JmN1dQKjpimbiwoc i307rDAIbY0lJZ9ELNdNporFuEQZqkkjERY4NNrk= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DDE7B216C40; Mon, 27 May 2013 23:59:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E373534B6442; Tue, 28 May 2013 09:59:50 +1000 (EST) To: Lorenzo Colitti From: Mark Andrews References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 28 May 2013 00:47:58 +0900." Date: Tue, 28 May 2013 09:59:50 +1000 Message-Id: <20130527235950.E373534B6442@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 00:00:08 -0000 In message , Lorenzo Colitti writes: > On Mon, May 27, 2013 at 7:08 AM, Mark Andrews wrote: > > > > > > Ideally, it would be nice if the IETF focused on mechanisms that had a > > real world purpose. Solutions > > > looking for a problem tend to create more problems than they solve. In > > many ways, ULA seems to fit > > > that definition. > > > > Owen, there is no perfect solution to numbering residential networks. > > > > * getting addresses from a RIR works worse than ULA as you can't get > > them routed and RIR address are not in a well defined range. > You can't get ULAs routed either. I didn't say you could. ULA however are better than a generic prefix from a RIR in that the software knows (or will know) that they are not globally routable and can make sensible default decisions when presented with a mixture of ULA and GUA addresses. The alternative to ULA + GUA is non-routed GUA + PA GUA and unless the home network is pushing around address selection tables there is nothing to tell the two addresses apart. This will lead to the wrong source address being choosen. > > * getting addresses from a ISP doesn't work as you need addresses > > before your initial connection. Additionally they require > > full renumbering when switching providers or when the ISP decides > > to rejig their address plan. > > > > Agreed, ULA gives you stable addresses for a disconnected network. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Mon May 27 18:39:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78A21F920B for ; Mon, 27 May 2013 18:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAOiZiCOgj73 for ; Mon, 27 May 2013 18:39:48 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A20AB21F91A5 for ; Mon, 27 May 2013 18:39:48 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u11so3728104qcx.26 for ; Mon, 27 May 2013 18:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XUJujGWRoORdD0N7p/EG/P1+edCQkNhcsFvdMGVASG0=; b=TVI3VB476EmATE4O8mtcN1cZuCbYXfvPCtGBDBQ6Q6Ri9ZzLMX6yMdpb7aYxgZfSCq A9CyRUrQFk6QCBH0PqdPLwi7OJ66QfaILt2N5COHY1DWFLkfvkWh7ilWsu82Rtdtos6n quurm+isAkQrD3036JuYC+Lj8WLxmJVjmOlt0Vm6DOH+EYmkM4NpF1QFfDQghv+9/KGI AWoY0sPJawACn8od36JI8KkwQDroiygVv5gVQdYme3UUsLlcIM/gx+r4edcctkiU2cZd NV2OnBclJgE3FL+LqhpR+jedzzlTyIO4X3azr9IynPdFQ+aSJupjHj/aEi2Be2ptM5yR tU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=XUJujGWRoORdD0N7p/EG/P1+edCQkNhcsFvdMGVASG0=; b=g8+arwRhxMrvykhkJrDoUONcO+KS0kzPgNdX1g19Kls4GC+4cCCLdYUfONhLLS8aNr YIVaBRG/EwpGbdjgQrJjJ5iOJuXKLSiKtw7dEOay39oyrfAP5h2ejwtJbH1E37LUh1um hJVMPoL2S0ai3U97wGv69dug3sPJPhMgAz1hmnkRK7op/NxAA4hAc807//5lQmOGCmFc EOc9eC1itl1a5dM4py9JcBTlIIQ0F88uHi8OcQmBK2R351C01lGB/RXo8LWDNCKL9pyW G8mQRN615XecAT5VnohrwUIVfqaSoCZust579GBrcODatEPP8/RXS59NzvBbidLxqfVm vBqw== X-Received: by 10.229.17.10 with SMTP id q10mr4492316qca.21.1369705187772; Mon, 27 May 2013 18:39:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Mon, 27 May 2013 18:39:27 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> From: Lorenzo Colitti Date: Tue, 28 May 2013 10:39:27 +0900 Message-ID: To: "cb.list6" Content-Type: multipart/alternative; boundary=0015175cf92a2a81ba04ddbd57ce X-Gm-Message-State: ALoCoQnRsSKxthqxyvCx1eNtkSx1dYZzKMp03OfG+hH92YXlsazNaYZYx1tY696nUQGTvXCXy7ZtQbcVqd+oA4Y/237cav2tX5O4D/7GSxdIyZF9vQ+EkJeZZdbbeJnKBjwqyujzAjsZJiX/8Y+m1WiO+W+6nSs94ILAR38qbHQf2Sdm9jC/f76vR/v5wURcGufwNL4EBjRb Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 01:39:49 -0000 --0015175cf92a2a81ba04ddbd57ce Content-Type: text/plain; charset=ISO-8859-1 I'm not sure, but I think the fundamental problem is the same as it has always been: "if you ND proxy a downstream interface to an upstream interface, you're gonna have a bad time" - because that can create loops. However, I think that doing proxy ND between multiple downstream subnets would work fine. As Owen says, we should not document an inferior wheel. So we should not finalize this document if we do not know the answer to this question. Does anyone know the answer? On Tue, May 28, 2013 at 2:35 AM, cb.list6 wrote: > > On May 27, 2013 10:04 AM, "Owen DeLong" wrote: > > > > >> Agreed. However, that doesn't mean we need to invent an inferior > wheel. > > >> > > >> Owen > > >> > > > > > > well, we ship what gets rough consensus, not what is "best" for some > > > value of "best" > > > > > > > Unless there is a reason to do so, I cannot imagine that rational > individuals would come to consensus on an inferior choice. > > > > > Back in the archives, we scoped the scenario to be one routed > > > down-link due to folks concerns about loops that would result from > > > having multiple interfaces up with the same prefix. > > > > Ah, but as was described earlier, interface != link and if we simply > move to the term link, the problem is resolved. The use of the term > interface is what is problematic here. Multiple interfaces which are > bridged together at layer 2 constitute a single link from an IPv6 > perspective. > > > > > i think the discussion was somewhere around here and how NDproxy was > > > not acceptable > > > > > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and > > > http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html > > > > Which only applies in the case of multiple links with the same prefix, > not multiple interfaces within the same link. > > > > Owen > > > > Ok, so in the draft we change interface to link and the magic of how loops > and so on are prevented is out of scope since it is in the domain of "link"? > > I am fine with that. > > Is that "one word" change that is needed to close this particular topic? > > CB > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --0015175cf92a2a81ba04ddbd57ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not sure, but I think the fundamental problem is t= he same as it has always been: "if you ND proxy a downstream interface= to an upstream interface, you're gonna have a bad time" - because= that can create loops.

However, I think that doing proxy ND between multiple = downstream subnets would work fine.

As= Owen says, we should not document an inferior wheel. So we should not fina= lize this document if we do not know the answer to this question. Does anyo= ne know the answer?

On Tue,= May 28, 2013 at 2:35 AM, cb.list6 <cb.list6@gmail.com> wro= te:

On May 27, 2013 10:04 AM, "Owen DeLong" <owen@delong.com> wrote:
>
> >> Agreed. However, that doesn't mean we need to invent an i= nferior wheel.
> >>
> >> Owen
> >>
> >
> > well, we ship what gets rough consensus, not what is "best&q= uot; for some
> > value of "best"
> >
>
> Unless there is a reason to do so, I cannot imagine that rational indi= viduals would come to consensus on an inferior choice.
>
> > Back in the archives, we scoped the scenario to be one routed
> > down-link due to folks concerns about loops that would result fro= m
> > having multiple interfaces up with the same prefix.
>
> Ah, but as was described earlier, interface !=3D link and if we simply= move to the term link, the problem is resolved. The use of the term interf= ace is what is problematic here. Multiple interfaces which are bridged toge= ther at layer 2 constitute a single link from an IPv6 perspective.
>
> > i think the discussion was somewhere around here and how NDproxy = was
> > not acceptable
> >
> > http://www.ietf.org/mail-archive/web/v6ops/cu= rrent/msg13954.html and
> > http://www.ietf.org/mail-archive/web/v6ops/cu= rrent/msg15020.html
>
> Which only applies in the case of multiple links with the same prefix,= not multiple interfaces within the same link.
>
> Owen
>

Ok, so in the draft we change interface to link = and the magic of how loops and so on are prevented is out of scope since it= is in the domain of "link"?

I am fine with that.

Is that "one word" change that is=A0 needed to clo= se this particular topic?

CB

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--0015175cf92a2a81ba04ddbd57ce-- From cb.list6@gmail.com Mon May 27 18:57:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E3F21F8EE8 for ; Mon, 27 May 2013 18:57:15 -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_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTRyMK2EUNT6 for ; Mon, 27 May 2013 18:57:14 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5015621F8E49 for ; Mon, 27 May 2013 18:57:14 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t59so4799828wes.2 for ; Mon, 27 May 2013 18:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4K7G3BmGPHhqpv+oUvaopjju6exluxc8ZFmRoz1FNg8=; b=fai9m8sz2enMCLkL3dLKhmHIFn0d4/M+p0GUCWiLdWYWnw7rxY7H5VHWzkMbhVlwNq aVJwroJZ7k08Z4SR3d0lXBfSUHMdD6ZzcIALQudtekIkHeSYR/2gubvHDWwjxMz/X0FH HDb0a4xvZ2DupsIXrp2hAvMRkL30KkzJcBnkH9fxMjLNsz2IUBCObIbfl7Go7vsKGchU yNPiQV8YQ/Vu0zPBNSQEKF/H2NkS4f3xXoKpWeHtdoD2ODbrB+T8pII+nPUVn0nKGCLc euGpLNBQ1YD6SGgmUVqAoWxzm5XkTHK0OypN57nx8nVWYBDz4wxme6nDyMKytl/Qs5vF o9Lw== MIME-Version: 1.0 X-Received: by 10.181.13.42 with SMTP id ev10mr10113043wid.1.1369706233374; Mon, 27 May 2013 18:57:13 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 27 May 2013 18:57:13 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> Date: Mon, 27 May 2013 18:57:13 -0700 Message-ID: From: "cb.list6" To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 01:57:15 -0000 On Mon, May 27, 2013 at 6:39 PM, Lorenzo Colitti wrote: > I'm not sure, but I think the fundamental problem is the same as it has > always been: "if you ND proxy a downstream interface to an upstream > interface, you're gonna have a bad time" - because that can create loops. > > However, I think that doing proxy ND between multiple downstream subnets > would work fine. > Right, and previous discussion on this topic says their is no way to prevent it from happening without some heavy-lifting to change ND or otherwise accepting risks that have been deemed unacceptable > As Owen says, we should not document an inferior wheel. So we should not > finalize this document if we do not know the answer to this question. Does > anyone know the answer? > The previous answer was to scope the wheel to be one link / interface. I would like to not let perfect be the enemy of good, and... also call out that there are shipping implementations that are undocumented because the need arose before the IETF was willing to discuss it. It reminds me of how the IETF denied the existence of NAT and therefore there was a cornucopia of implementation variations. This draft introduces a handful of scenarios that have been reviewed by the IETF, it is "only" informational, and my goal is to limit that cornucopia to a safe set of simple vetted solutions Alternatively, we can put our heads back in the sand and tell everyone DHCP-PD is the only way forward and watch that be ignored while off-the-cuff implementations roll out (this is, in fact, the current state with Apple (iPhone), ZTE (4G router), and Samsung (Android phones) all shipping prefix sharing implementations.) CB > > On Tue, May 28, 2013 at 2:35 AM, cb.list6 wrote: >> >> >> On May 27, 2013 10:04 AM, "Owen DeLong" wrote: >> > >> > >> Agreed. However, that doesn't mean we need to invent an inferior >> > >> wheel. >> > >> >> > >> Owen >> > >> >> > > >> > > well, we ship what gets rough consensus, not what is "best" for some >> > > value of "best" >> > > >> > >> > Unless there is a reason to do so, I cannot imagine that rational >> > individuals would come to consensus on an inferior choice. >> > >> > > Back in the archives, we scoped the scenario to be one routed >> > > down-link due to folks concerns about loops that would result from >> > > having multiple interfaces up with the same prefix. >> > >> > Ah, but as was described earlier, interface != link and if we simply >> > move to the term link, the problem is resolved. The use of the term >> > interface is what is problematic here. Multiple interfaces which are bridged >> > together at layer 2 constitute a single link from an IPv6 perspective. >> > >> > > i think the discussion was somewhere around here and how NDproxy was >> > > not acceptable >> > > >> > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and >> > > http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html >> > >> > Which only applies in the case of multiple links with the same prefix, >> > not multiple interfaces within the same link. >> > >> > Owen >> > >> >> Ok, so in the draft we change interface to link and the magic of how loops >> and so on are prevented is out of scope since it is in the domain of "link"? >> >> I am fine with that. >> >> Is that "one word" change that is needed to close this particular topic? >> >> CB >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From lorenzo@google.com Mon May 27 19:17:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAC921F9058 for ; Mon, 27 May 2013 19:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvRtTCte1qS8 for ; Mon, 27 May 2013 19:17:05 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0439A21F919D for ; Mon, 27 May 2013 19:17:04 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id i11so4084052qej.27 for ; Mon, 27 May 2013 19:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zr9goq21G9s+5FyBFl+7URHrZJpLQBwzdrQBxAnE8SA=; b=irIvLTJc+5GpMheXRArn3Eczayj6+JB2XPWjsvMO6pkVYR6REPKgYhWPDzjR+oI7am u6WJTuS52Mje3GoQbX0u4sMyRVPbUXtrdliGrk695zi90lPn1HStSu+UEKlHENAlIyL/ 6oGEIVaDzJ72DxD+c++un+lDL19oQCQ1BUbdOTAOfnxrZF6JTNDKA1IhWtvHqZ+ldyjr QwedA8eAseB/LXg+qoy49VDuvVaUnUDOeYxay0wukKWCU4otsHdzZi0/yeIOpPwgGzdB 5ODIPvqBgYyf/3SGI9Jx5+3hDSd9O2EvKzurJ+3fbJ8jQ/1WtA5wVOOoZHd7uq3Q5vxj RGXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Zr9goq21G9s+5FyBFl+7URHrZJpLQBwzdrQBxAnE8SA=; b=ODr7HH0yaL6bUjHMnI/3C3h47RZb+j6wMBwAd3naaRn/JR6KAy5ZgE0GSjU7SWXsCQ xbmOptiAN8eptfqpgSE940/VmvKkqpUZXBDfXihUnJojKzu84hgFKMYtKNZ+Vwn8Tj0a +LUlthwoIX+9hD6V6c5FhHFWcbMUxA7G/r6rFo8LsD6KYpU08jjdT5/D/AvYKKiBTPEo DgDMlD8mooZ7ctNxsOcBVRGjaA5ccxT5MYCJXVZsecjkIygVLVMslET75/gD6kCfgK4G PIj+kjZBpw5bRxH8qZByNKk08VlSL/Kee3rxYh5EW1nsBNPiZdp7gBvaPgntsHV2bKfu swIg== X-Received: by 10.229.196.200 with SMTP id eh8mr11404149qcb.96.1369707424333; Mon, 27 May 2013 19:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Mon, 27 May 2013 19:16:44 -0700 (PDT) In-Reply-To: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 28 May 2013 11:16:44 +0900 Message-ID: To: "cb.list6" , "draft-ietf-v6ops-64share@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c357c479784d04ddbddc47 X-Gm-Message-State: ALoCoQlRC/ksMF1J6VpTtxdW1LYpJ9LlRfPTttiSbScvJ4jP1y3JaKTYDcWx+7yq1iPArlM48fw2Rln9jIk79ACQbPYXCSekmEpBTwCM7fwFKs6A+n3Wt3kE5rNWxXhiX9OKtTjK7DTpoJoeIQgWejxRDl+x86iMGO5YSUc8Q3azOIXe2rysMwAINACRU2Dz/4APtLZRl/MZ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 02:17:10 -0000 --001a11c357c479784d04ddbddc47 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 3:54 AM, wrote: > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile > Interface to a LAN > Author(s) : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-07.txt > Substantive comments: 1. The introduction needlessly limits the scope of this document to 3GPP devices. This scheme works anywhere the uplink is a point-to-point interface. 3GPP devices happen to fall into that category, and the fact that 3GPP currently only a /64 is a use case for this document, but it's not the only one. So I think this scheme should be documented in the more general case and the 3GPP use case should be documented as a use case. 2. I think scenario #1 should be removed. An IPv6 router without a global scope IPv6 address? First of all, why? There are plenty of addresses in the /64. Second, how is the router going to fulfill the router requirements that require it, for example, to send ICMP error messages? We can't say that it's OK for a router not to be able to support PMTUd, send unreachables, support traceroute, etc. for transit traffic. Third, this mode doesn't even simplify implementation, because the sharing device has to do autoconf on the uplink anyway to get the prefix to share. Fourth, disabling autoconf once sharing is enabled means that this method will not work on any network where the upstream prefix can change. Why was this mode included? 3. Scenarios #2 and #3 are underspecified. For example, what does the RA on the LAN look like? Is it a copy of the RA from the WAN? Presumably not, since we'd want to include the link-layer address of the router in it. Does the sharing device decrement the TTL? And so on. Instead of putting these as details in the scenarios, they should probably be put in a more general requirements section whose job it is to explain what the sharing device must do in order for the IPv6 protocol to work correctly when sharing a /64. The scenarios would then become examples of ways you can do this. 4. Some of the language is inappropriately vague. For example, what does "defends its LAN IPv6 address with DAD" mean? 5. It's not OK to say that privacy extensions should be disabled. I think the document should say that if the sharing device has privacy addresses, it should maintain them, and if it does maintain them, it must support DAD for those addresses on its downstream interface(s). 6. The document should say that said neighbor advertisements are proxy neighbour advertisements per RFC 4861 section 7.2.8. Note that this is different from ND proxy (RFC 4389), which is experimental. Cheers, Lorenzo --001a11c357c479784d04ddbddc47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2013 at 3:54 AM, <internet-drafts= @ietf.org> wrote:

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Extending an I= Pv6 /64 Prefix from a 3GPP Mobile Interface to a LAN
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Cameron Byrne
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dan Drown
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ales Vizdal
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-64share-07.txt

Substantive comments:

1. The introduction needlessly limits the scope of= this document to 3GPP devices. This scheme works anywhere the uplink is a = point-to-point interface. 3GPP devices happen to fall into that category, a= nd the fact that 3GPP currently only a /64 is a use case for this document,= but it's not the only one. So I think this scheme should be documented= in the more general case and the 3GPP use case should be documented as a u= se case.

2. I think scenario #1 should be removed. A= n IPv6 router without a global scope IPv6 address? First of all, why? There= are plenty of addresses in the /64. Second, how is the router going to ful= fill the router requirements that require it, for example, to send ICMP err= or messages? We can't say that it's OK for a router not to be able = to support PMTUd, send unreachables, support traceroute, etc. =A0for transi= t traffic. Third, this mode doesn't even simplify implementation, becau= se the sharing device has to do autoconf on the uplink anyway to get the pr= efix to share. Fourth, disabling autoconf once sharing is enabled means tha= t this method will not work on any network where the upstream prefix can ch= ange. Why was this mode included?

3. Scenarios #2 and #3 are underspecified. = For example, what does the RA on the LAN look like? Is it a copy of the RA = from the WAN? Presumably not, since we'd want to include the link-layer= address of the router in it. Does the sharing device decrement the TTL? An= d so on. Instead of putting these as details in the scenarios, they should = probably be put in a more general requirements section whose job it is to e= xplain what the sharing device must do in order for the IPv6 protocol to wo= rk correctly when sharing a /64. The scenarios would then become examples o= f ways you can do this.

4. Some of the language is inappropriately = vague. For example, what does "defends its LAN IPv6 address with DAD&q= uot; mean?

5. It's not OK to say t= hat privacy extensions should be disabled. I think the document should say = that if the sharing device has privacy addresses, it should maintain them, = and if it does maintain them, it must support DAD for those addresses on it= s downstream interface(s).

6. The document should say that said neighb= or advertisements are proxy neighbour advertisements per RFC 4861 section 7= .2.8. Note that this is different from ND proxy (RFC 4389), which is experi= mental.

Cheers,
Lorenzo
=
--001a11c357c479784d04ddbddc47-- From lorenzo@google.com Mon May 27 19:22:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B2721F92E7 for ; Mon, 27 May 2013 19:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWkjbmZWPEFa for ; Mon, 27 May 2013 19:22:58 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDDA21F9294 for ; Mon, 27 May 2013 19:22:58 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ii15so1250806qab.4 for ; Mon, 27 May 2013 19:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=o0D7WZwnjPN46s4I1yb0MYF5lqLyG+ComFY2Inz5o5Q=; b=o0k0Y9BvNYjl46Pg5CXzk83ryHNL3C4eXLNbLqzIAlgZffzZcHqESylZIhwTFtc+dn 6Vb5SjDLPdfYepMNr1yblkppmj4axSp2fYwQzKelqOR4Qkj7gDwtgjyYcGZ6jwQFa/9/ TfpijRwsGrxUGQkTo+495s20sSsRyASMfjN0+w+5QyPHF6JVwBcUThBBb+dMbVb7I6LI yBSu+wZ5cYrz+CO3WfQOSB9JXC5l5aj+ly5lXFvNZ/KBoFCX2iPuSEdrwQ5uxht+1hWM PeLgcQ0Gpdur3uf/1Ts5oBprYowuEo6DvHcOoptStss9BA0jYZzEcpC9cCXxwEkCyBO8 sBxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=o0D7WZwnjPN46s4I1yb0MYF5lqLyG+ComFY2Inz5o5Q=; b=Lcqot+neMuGdiY/QJ9WxjOoxy2uHYTnN+hFhhWBZ+3CHcx9FHWIsRhYuEYNd0lCdw7 bsTAJidPtH5D+eac5BykDZIs6OvefvqFMdUG1MyUiHR/+q6ClZPUIhlPDGxtdS8Rhw4v otBXRbgUW2ubbGWididmuPrYHvxH3myjntMaiYHky+rWnHDY6VJC48ZgjfhrVnt6IyQb wlMoZAkmhZCWBFAE5Kpeizn283akSMndK7gJfTNV13Z5C4ukci+HwhBHaHQF6VxySL8R S5P04dHNFCvEr+6K/AHaDRLBcM/U54KI6FdCNxRdNuHdi+qOf6IEOAKkHWA4HIFGg9Hx e8Dg== X-Received: by 10.229.17.10 with SMTP id q10mr4534337qca.21.1369707777740; Mon, 27 May 2013 19:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Mon, 27 May 2013 19:22:37 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> From: Lorenzo Colitti Date: Tue, 28 May 2013 11:22:37 +0900 Message-ID: To: "cb.list6" Content-Type: multipart/alternative; boundary=0015175cf92a8a27db04ddbdf111 X-Gm-Message-State: ALoCoQlXp+57vqXEZ8TnbPXc9qvSP3n0YzBmFaXAcsc4J0Ped4+kTqrVQMfb4zj1d846Syu2ft8i4YgDWkA6aG9Y+V3wWBK/zNJDTXedqbsaUbao5XKfz/VImw+XY6e+0qOijYqOBjXj2Lyv9Tzx+IWgEzgPas5sYLrcKsLtJo9TIadzML/eaCW0mVtHT1cOVXsyb0hHSxzP Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 02:22:59 -0000 --0015175cf92a8a27db04ddbdf111 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 10:57 AM, cb.list6 wrote: > > However, I think that doing proxy ND between multiple downstream subnets > > would work fine. > > Right, and previous discussion on this topic says their is no way to > prevent it from happening without some heavy-lifting to change ND or > otherwise accepting risks that have been deemed unacceptable > Actually, I don't believe the question of how this would work with multiple downstream interfaces has been explored before in this group. > > As Owen says, we should not document an inferior wheel. So we should not > > finalize this document if we do not know the answer to this question. > Does > > anyone know the answer? > > > > The previous answer was to scope the wheel to be one link / interface. > Is there a solid technical reason for doing so? Have we even discussed if this is possible or not, and whether it would work? > I would like to not let perfect be the enemy of good, and... also > call out that there are shipping implementations that are undocumented > because the need arose before the IETF was willing to discuss it. It > reminds me of how the IETF denied the existence of NAT and therefore > there was a cornucopia of implementation variations. > > This draft introduces a handful of scenarios that have been reviewed > by the IETF, it is "only" informational, and my goal is to limit that > cornucopia to a safe set of simple vetted solutions > > Alternatively, we can put our heads back in the sand and tell everyone > DHCP-PD is the only way forward and watch that be ignored while > off-the-cuff implementations roll out (this is, in fact, the current > state with Apple (iPhone), ZTE (4G router), and Samsung (Android > phones) all shipping prefix sharing implementations.) > I'm not saying that we should not publish this document. I am saying that we should do the due diligence to inform implementers of how to do this properly, so that we don't end up with broken (e.g., no global address on the sharing device? How are you going to connect to it, via link-local?) or suboptimal (e.g., only one interface) implementations. This is the IETF. We should not simply describe the implementations that are out there, we should do the due diligence of thinking through how things should work, and publish a document accordingly. This is useful even if the the current implementers know all these things, and the current implementations do everything right, because it ensures that future implementations behave in a sane way as well. --0015175cf92a8a27db04ddbdf111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 28, 2013 at 10:57 AM, cb.list6 <cb.list6@gma= il.com> wrote:

> However, I think that= doing proxy ND between multiple downstream subnets
> would work fine.

Right, and previous discussion on this topic says their is no way to<= br> prevent it from happening without some heavy-lifting to change ND or
otherwise accepting risks that have been deemed unacceptable

Actually, I don't believe the question of h= ow this would work with multiple downstream interfaces has been explored be= fore in this group.

=A0

> As Owen says, we should not document an inferior whe= el. So we should not
> finalize this document if we do not know the answer to this question. = Does
> anyone know the answer?
>

The previous answer was to scope the wheel to be one link / interface= .

Is there a solid technical reas= on for doing so? Have we even discussed if this is possible or not, and whe= ther it would work?

=A0
I would like to not let = perfect be the enemy of good, and... =A0also
call out that there are shipping implementations that are undocumented
because the need arose before the IETF was willing to discuss it. =A0It
reminds me of how the IETF denied the existence of NAT and therefore
there was a =A0cornucopia of implementation variations.

This draft introduces a handful of scenarios that have been reviewed
by the IETF, it is "only" informational, and my goal is to limit = that
cornucopia to a safe set of simple vetted solutions

Alternatively, we can put our heads back in the sand and tell everyone
DHCP-PD is the only way forward and watch that be ignored =A0while
off-the-cuff implementations roll out (this is, in fact, the current
state with Apple (iPhone), ZTE (4G router), and Samsung (Android
phones) all shipping prefix sharing implementations.)
=
I'm not saying that we should not publish this doc= ument. I am saying that we should do the due diligence to inform implemente= rs of how to do this properly, so that we don't end up with broken (e.g= ., no global address on the sharing device? How are you going to connect to= it, via link-local?) or suboptimal (e.g., only one interface) implementati= ons.

This is the IETF. We should not simply desc= ribe the implementations that are out there, we should do the due diligence= of thinking through how things should work, and publish a document accordi= ngly. This is useful even if the the current implementers know all these th= ings, and the current implementations do everything right, because it ensur= es that future implementations behave in a sane way as well.

--0015175cf92a8a27db04ddbdf111-- From markzzzsmith@yahoo.com.au Mon May 27 20:45:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5FC21F9413 for ; Mon, 27 May 2013 20:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTIQgGQvV6aX for ; Mon, 27 May 2013 20:45:05 -0700 (PDT) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) by ietfa.amsl.com (Postfix) with SMTP id 1AFA421F9410 for ; Mon, 27 May 2013 20:45:04 -0700 (PDT) Received: from [98.139.212.146] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2013 03:45:04 -0000 Received: from [98.139.212.233] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2013 03:45:04 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 28 May 2013 03:45:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 140858.97687.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 5090 invoked by uid 60001); 28 May 2013 03:45:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369712704; bh=434qBy+h65nh6srqf0UUFhLthCZ5E8/RDsZaSnnRvy0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jlcyv9zel6J0AWLZv7/cduu9asouVnS03cmDccCZCCvXC0CIjWcMXkne+pDjbS7Mc/JxHl98qSNhLZdhh8didtJshkomeRx+QrPWzY++AuUzEMqC2UrjBJwn9Ly2aYod6B0DoT1cyWVA90Hfkk+6rcpCbaQbE3gPfwmMLLzMPnE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b/VomOGhBChfQ1ZxQ1CFhmNpanY/5kvLTkE6EcJGpxtSWhW87svP9grIUJM+cLxP91QuEGp9ppVyvfUZ/T99YCbnAXyRQABtZf49PCYkQ/3IAaUZkW9JzqIn58jWXoph0tXeE2a0orK/HiGSwr6L+aUHTJL/xpho5HW4moRYFZY=; X-YMail-OSG: 16sEvyQVM1m9NSe_IdhuTAWxo1qq44solBQ674wYTe6hfKn k25xtQXX4oiU4ofLYXcHSVqxi2pcwDJRUfebB3GHUEZDS0G6QCedKP0Kir3L p0Lvp9sH0IuUHdLC7p.Rw.MHUTtjv53Qv3bt0SsKhO6x1N0sxmFXCsOh77Rs muwM_EHlu7RoXLzGQSIgoP4JMHkaP5bWl3CX4fdR_zQf.TfKlr1EXOtncr6f PQC6UgRdADvqO9xT1t8DAptM7ZM2G6lLRBPKQhvXjLHXk.nPUHmx1FqKY.L8 5l5LALAlJ35MpQYHSw0bnF_E8lQ_tz7wmHEFE66UtpO7yokfbSonGa0du97f QqjcD3FloEwwJCeU3tyMXu3_nrfxrfzdmW2FY1zq.ccdTzDQmw5CrtTF4938 uZ2nlpkTFNoxH2Ty07_zQh.f2TsNVLXQHV9MVKZh2T5OQLDBANqKVU25oBhS l4cjSTzOttVAG1nj_he42RCithYeE5MdJEFdN65Pm2HHBckij_swc6JXRg7D esOyEQHXJVjsVP4j397uT9xc9Y4eCQmS7tZ.M Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Mon, 27 May 2013 20:45:03 PDT X-Rocket-MIMEInfo: 002.001, SGksCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBjYi5saXN0NiA8Y2IubGlzdDZAZ21haWwuY29tPjsgImRyYWZ0LWlldGYtdjZvcHMtNjRzaGFyZUB0b29scy5pZXRmLm9yZyIgPGRyYWZ0LWlldGYtdjZvcHMtNjRzaGFyZUB0b29scy5pZXRmLm9yZz4gCj5DYzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.IAo.U2VudDogVHVlc2RheSwgMjggTWF5IDIwMTMgMTI6MTYgUE0KPlN1YmoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> Message-ID: <1369712703.3030.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Mon, 27 May 2013 20:45:03 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti , "cb.list6" , "draft-ietf-v6ops-64share@tools.ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 03:45:10 -0000 Hi,=0A=0A>________________________________=0A> From: Lorenzo Colitti =0A>To: cb.list6 ; "draft-ietf-v6ops-64sh= are@tools.ietf.org" =0A>Cc: "v6op= s@ietf.org WG" =0A>Sent: Tuesday, 28 May 2013 12:16 PM=0A>= Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt=0A> =0A>= =0A>=0A>On Sat, May 18, 2013 at 3:54 AM, wrote:= =0A>=0A>=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Extending an IPv6 /64 P= refix from a 3GPP Mobile Interface to a LAN=0A>>=A0 =A0 =A0 =A0 Author(s) = =A0 =A0 =A0 : Cameron Byrne=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Dan Drown=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Ales Vizdal=0A>>=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-= 64share-07.txt=0A>>=0A>=0A>=0A>Substantive comments:=0A>=0A>=0A>1. The intr= oduction needlessly limits the scope of this document to 3GPP devices. This= scheme works anywhere the uplink is a point-to-point interface. 3GPP devic= es happen to fall into that category, and the fact that 3GPP currently only= a /64 is a use case for this document, but it's not the only one. So I thi= nk this scheme should be documented in the more general case and the 3GPP u= se case should be documented as a use case.=0A>=0A=0AI was sort of hoping n= obody would open that can of worms, as the same thing occurred to me previo= usly. I fear that doing this would provide an excuse to some ISPs not to gi= ve out more than a single /64 if these methods are more generally adopted, = contrary to the advice in RFC3177/6177. I think clearly presenting it as a = work around to the limitations of the 3GPP architecture revision mentioned = would be better.=0A=0A=0A=0ARegards,=0AMark. From jiangsheng@huawei.com Mon May 27 23:03:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6891821F9350 for ; Mon, 27 May 2013 23:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDydo-Rx0X09 for ; Mon, 27 May 2013 23:03:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C8CF621F871D for ; Mon, 27 May 2013 23:03:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATF85531; Tue, 28 May 2013 06:03:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 28 May 2013 07:02:39 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 28 May 2013 07:03:04 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Tue, 28 May 2013 14:02:58 +0800 From: Sheng Jiang To: "" Thread-Topic: New Version Notification for draft-jiang-v6ops-semantic-prefix-03.txt Thread-Index: AQHOW0sBJ9A9F/P8TUiLxRA74FrSbJkaGCYA Date: Tue, 28 May 2013 06:02:57 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9873D@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] FW: New Version Notification for draft-jiang-v6ops-semantic-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 06:03:12 -0000 SGksIHY2b3BzLA0KDQpUaGUgYXV0aG9ycyBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHZlcnNp b24gb2Ygc2VtYW50aWMgcHJlZml4IGZyYW1ld29yayBkcmFmdC4gVGhlIG1ham9yIGNoYW5nZXMg YXJlIHN1bW1hcml6ZWQgYmVsb3c6DQoNCmEpIHJld29yZCB0byBlbXBoYXNpcyB0aGlzIG1lY2hh bmlzbSBpcyBhIChub3QgdGhlKSBtZXRob2QgdGhhdCBuZXR3b3JrIG9wZXJhdG9ycyB1c2UgdGhl aXIgYWRkcmVzc2VzOw0KDQpiKSBhZGQgdGV4dCB0byBjbGFyaWZ5IHRoZSBpbmNyZWFzZWQgdHJ1 c3QgaXMgYWN0dWFsbHkgZnJvbSB0aGUgZGVwbG95bWVudCBvZiBzb3VyY2UgYWRkcmVzcyBmaWx0 ZXIsIHdoaWNoIGlzIGEgY29tcGxpYW5jZSByZXF1aXJlbWVudCBieSBzZW1hbnRpYyBwcmVmaXg7 DQoNCmMpIHJlc3RydWN0dXJlIHRoZSBkb2N1bWVudCwgbW92ZSBleGFtcGxlcyBhbmQgZ2FwIGFu YWx5c2lzIGludG8gYXBwZW5kaXhlcywgcmVvcmdhbml6ZSBtb3N0IGNvbnRlbnQgaW50byBhIGZy YW1lIHNlY3Rpb24gKHNlY3Rpb24gNCk7DQoNCmQpIGFkZCBzdW1tYXJpemVkIGRlc2NyaXB0aW9u IGZvciBmcmFtZXdvcmsgYXQgdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDQ7DQoNCmUpIGFkZCBk ZXNjcmlwdGlvbiBmb3IgbmV0d29yayBvcGVyYXRpb25zIGJhc2VkIG9uIHNlbWFudGljIHByZWZp eCwgbmV3IHNlY3Rpb24gNC40Ow0KDQpmKSBhZGQgYSBuZXcgY29hdXRob3Igd2hvIGNvbnRyaWJ1 dGVzIGFuIGVudGVycHJpc2Ugc2VtYW50aWMgcHJlZml4IG5ldHdvcmsgZXhhbXBsZTsNCg0KZykg Y29tYmluZSBtb3N0IG9mIGRyYWZ0LXN1bi12Nm9wcy1zZW1hbnRpYy11c2VjYXNlIGludG8gdGhl IGRyYWZ0IGFzIElTUCBleGFtcGxlIGluIGFwcGVuZGl4Lg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBu ZXcgdmVyc2lvbiBhbmQgY29tbWVudHMuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPlNlbnQ6IFR1ZXNkYXksIE1heSAy OCwgMjAxMyAxMDoyOCBBTQ0KPlRvOiBRaW9uZyBTdW47IElhbiBGYXJyZXI7IFNoZW5nIEppYW5n OyBCb3lhbmcNCj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQt amlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzLnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMudHh0DQo+aGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaGVuZyBKaWFuZyBhbmQgcG9zdGVkIHRvIHRo ZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5GaWxlbmFtZToJIGRyYWZ0LWppYW5nLXY2b3BzLXNl bWFudGljLXByZWZpeA0KPlJldmlzaW9uOgkgMDMNCj5UaXRsZToJCSBBIEZyYW1ld29yayBmb3Ig U2VtYW50aWMgSVB2NiBQcmVmaXgNCj5DcmVhdGlvbiBkYXRlOgkgMjAxMy0wNS0yOA0KPkdyb3Vw OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPk51bWJlciBvZiBwYWdlczogMTkNCj5VUkw6DQo+ aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmctdjZvcHMtc2Vt YW50aWMtcHJlZml4LTAzLnR4dA0KPlN0YXR1czoNCj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeA0KPkh0bWxpemVkOg0KPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZp eC0wMw0KPkRpZmY6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamlh bmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgbWV0aG9kIHRoYXQgbmV0d29yayBvcGVyYXRpb25z DQo+ICAgbWF5IHVzZSB0aGVpciBhZGRyZXNzZXMuICBOZXR3b3JrIG9wZXJhdG9ycywgd2hvIGhh dmUgbGFyZ2UgSVB2Ng0KPiAgIGFkZHJlc3Mgc3BhY2UsIG1heSBjaG9vc2UgdG8gZW1iZWRkZWQg c29tZSBzZW1hbnRpY3MgaW50byBJUHY2DQo+ICAgYWRkcmVzc2VzIGJ5IGFzc2lnbmluZyBhZGRp dGlvbmFsIHNpZ25pZmljYW5jZSB0byBzcGVjaWZpYyBiaXRzDQo+ICAgd2l0aGluIHRoZSBwcmVm aXguICBCeSBlbWJlZGRlZCBzZW1hbnRpY3MgaW50byBJUHY2IHByZWZpeGVzLCB0aGUNCj4gICBz ZW1hbnRpY3Mgb2YgcGFja2V0cyBjYW4gYmUgaW5zcGVjdGVkIGVhc2lseS4gIFJvdXRlcnMgYW5k IG90aGVyDQo+ICAgaW50ZXJtZWRpYXJ5IGRldmljZXMgY2FuIGVhc2lseSBhcHBseSByZWxldmFu dCBwb2xpY2llcyBhcyByZXF1aXJlZC4NCj4gICBQYWNrZXQtbGV2ZWwgZGlmZmVyZW50aWF0aW9u IGNhbiBhbHNvIGVuYWJsZSBmbG93LWxldmVsIGFuZCB1c2VyLQ0KPiAgIGxldmVsIGRpZmZlcmVu dGlhdGlvbi4gIENvbnNlcXVlbnRseSwgdGhlIG5ldHdvcmsgb3BlcmF0b3JzIGNhbg0KPiAgIGFj Y29yZGluZ2x5IHRyZWF0IG5ldHdvcmsgcGFja2V0cyBkaWZmZXJlbnRseSBhbmQgZWZmaWNpZW50 bHkuICBUaGUNCj4gICBtYW5hZ2VtZW50IGFuZCBtYWludGVuYW5jZSBvZiBuZXR3b3JrcyBjYW4g YmUgbXVjaCBzaW1wbGVyLg0KPg0KPg0KPg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From otroan@employees.org Tue May 28 01:00:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A2D21F9294 for ; Tue, 28 May 2013 01:00:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1snhHY94vx6y for ; Tue, 28 May 2013 00:59:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 378C821F9285 for ; Tue, 28 May 2013 00:59:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgKAGRjpFGQ/khL/2dsb2JhbABZgwjCOAEDAQMBgQQWdIIjAQEEAXkQC0ZXBogaBrwTjmozB4JzYQOoe4MROg X-IronPort-AV: E=Sophos;i="4.87,756,1363132800"; d="scan'208";a="154623983" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 28 May 2013 07:59:35 +0000 Received: from dhcp-lys01-vla250-10-147-112-22.cisco.com (dhcp-lys01-vla250-10-147-112-22.cisco.com [10.147.112.22]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4S7xXaa004441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 07:59:33 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: Date: Tue, 28 May 2013 09:59:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> To: Owen DeLong X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 08:00:07 -0000 >> In any event, the work of this draft is to use the open ietf process = to get folks on the same page so the wheel does not get reinvented = several times in a vacume. >>=20 >=20 > Agreed. However, that doesn't mean we need to invent an inferior = wheel. haven't we invented the wheel, aka multilink subnet routing (also see = RFC4903) and the inferior wheel, RFC4389 already? what does this document add? cheers, Ole From ales.vizdal@t-mobile.cz Tue May 28 02:41:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD8E21F930A for ; Tue, 28 May 2013 02:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npPhbYgU3zJH for ; Tue, 28 May 2013 02:41:38 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6157921F8F41 for ; Tue, 28 May 2013 02:41:38 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id 768A72E08B2; Tue, 28 May 2013 11:41:16 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 28 May 2013 11:41:36 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Ole Troan , Owen DeLong Date: Tue, 28 May 2013 11:41:36 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt Thread-Index: Ac5becMaOQxnBCejRo6FQxvCPKmVgQADKrmQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> In-Reply-To: <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 09:41:43 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Ole > Troan > Sent: Tuesday, May 28, 2013 10:00 AM > To: Owen DeLong > Cc: IPv6 Ops WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt >=20 > >> In any event, the work of this draft is to use the open ietf process = to get folks on > the same page so the wheel does not get reinvented several times in a vac= ume. > >> > > > > Agreed. However, that doesn't mean we need to invent an inferior wheel. >=20 > haven't we invented the wheel, aka multilink subnet routing (also see RFC= 4903) and > the inferior wheel, > RFC4389 already? >=20 > what does this document add? It describes how to overcome the limitations of the 3GPP architecture until= the DHCP-PD will be available. So it adds (provides) a solution to this 3GPP specific issue. > cheers, > Ole Cheers, Ales From otroan@employees.org Tue May 28 02:47:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3CC21F8651 for ; Tue, 28 May 2013 02:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZshNvy9qmNu for ; Tue, 28 May 2013 02:47:15 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28B21F9403 for ; Tue, 28 May 2013 02:47:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicKALt8pFGQ/khL/2dsb2JhbABZgwjCOgQDAYEFFnSCJAEFeRALEjRJDgYuh3K7eI5qMweCc2EDqHuDETo X-IronPort-AV: E=Sophos;i="4.87,757,1363132800"; d="scan'208";a="13780152" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 28 May 2013 09:47:14 +0000 Received: from dhcp-lys01-vla250-10-147-112-22.cisco.com (dhcp-lys01-vla250-10-147-112-22.cisco.com [10.147.112.22]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4S9lBeW001872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 09:47:12 GMT Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> Date: Tue, 28 May 2013 11:47:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 09:47:21 -0000 Vizdal, >>=20 >> haven't we invented the wheel, aka multilink subnet routing (also see = RFC4903) and >> the inferior wheel, >> RFC4389 already? >>=20 >> what does this document add? >=20 > It describes how to overcome the limitations of the 3GPP architecture = until the DHCP-PD will be available. > So it adds (provides) a solution to this 3GPP specific issue. how is that different from the RA proxy? cheers, Ole From lorenzo@google.com Tue May 28 04:06:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABAD21F8F4A for ; Tue, 28 May 2013 04:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YilmK8SwehZ for ; Tue, 28 May 2013 04:06:16 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDF621F90EE for ; Tue, 28 May 2013 04:06:11 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id z1so3976038qcx.31 for ; Tue, 28 May 2013 04:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=B4JrtOyl8mUwiuueMbLGQ0+Gf6snlWr1q8BzIK3acYM=; b=TjKvRMLv5E+5YSbpQ0nEW/HNKagXMbXtZ865456/NaR9gwR3scuiiC1IRRjOZC2V/y 2MDRAqYSf5+6TQrQoFxaan5ol8Mj9oB+1SgjnPeaue29jIJb6oxwuYf00boBQRrrFdSD Pn/JWoeEwWjAhW53erjmFJxFs8FWUWb68SqiNhUkSxUHVLxxPgn3XG+hMhc+h9DFgTQV 64R+G3y5f6wqa9sQK3jdlCLgZ0nqXSnJkfL11mbKsd1TG0zrmbYRNcK0OREMzHCku1ZS TQqmSKARaTQE8cVDYZAjcXf2ey3/RRYbkwYF/q2hV+QwxDNNShCn0I5EYrHH6RNZ9gaG +6Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=B4JrtOyl8mUwiuueMbLGQ0+Gf6snlWr1q8BzIK3acYM=; b=ocz8qekz20JUr3v1HPiBF1UA2o61M0S86M3K27+EhbToUe3mAOi4bQgazNgY7wqXGw NitcxD81AMiDEPpbvBDP+Bd7rDbCB8S6KhxVlmPJYLmX5wjq6Ir0jRgJ2x5tnWpJS7J7 rgjgGp8mbZQA6CCc0W945pAPbHoy4DpvsX4sCc3D3D/kfG9KhILchuBgeFZ0tyi1RMwx z48BROGgaiYimrVl4GToLQnkysC+f3HPpSvB12ahltDXyG0GNzru4kyVJh5Jj6HazZzj WzhwBh42ZMtEJirbnJlQamcWYgDtgqSB8x7VX9pZ24Uh2gcmv5HuQyk2wwd78gxCBsyu qa2A== X-Received: by 10.224.214.134 with SMTP id ha6mr31277100qab.77.1369739170881; Tue, 28 May 2013 04:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Tue, 28 May 2013 04:05:50 -0700 (PDT) In-Reply-To: <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> From: Lorenzo Colitti Date: Tue, 28 May 2013 20:05:50 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=20cf300fb23db763db04ddc540dd X-Gm-Message-State: ALoCoQlsFKwRwzoykOKzZ9lAActd1GoeBdZCZKJPVFMNC0UzrM66AUj1XE/Yarzc1ZYoc/AlaaADi0JadTIkOxMoApDmxvpOz9FDbH7FxIuWAruJ4JVq0v2GEylAzVmfLleOjLQWKWTd7cR/cE/QyzKyCjtOpm7vPT571sm9Uzdh2sa38GgB+9YxR4ZnmpQUWIWzLF8a29j7 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 11:06:16 -0000 --20cf300fb23db763db04ddc540dd Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 6:47 PM, Ole Troan wrote: > > So it adds (provides) a solution to this 3GPP specific issue. > > how is that different from the RA proxy? Define "RA proxy"? --20cf300fb23db763db04ddc540dd Content-Type: text/html; charset=ISO-8859-1
On Tue, May 28, 2013 at 6:47 PM, Ole Troan <otroan@employees.org> wrote:

> So it adds (provides) a solution to this 3GPP specific issue.

how is that different from the RA proxy?

Define "RA proxy"?
--20cf300fb23db763db04ddc540dd-- From otroan@employees.org Tue May 28 04:22:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0D221F96A1 for ; Tue, 28 May 2013 04:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOUVlkLA6weO for ; Tue, 28 May 2013 04:22:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A695B21F94E1 for ; Tue, 28 May 2013 04:22:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoPAHySpFGQ/khL/2dsb2JhbABZgwgwgnSJI7VzAQECAQECAYEEFnSCIwEBBAF5EAtGVwYuh2wGDLtzjx0HgnNhA5hkkBeDETo X-IronPort-AV: E=Sophos;i="4.87,757,1363132800"; d="scan'208";a="82903688" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 May 2013 11:22:13 +0000 Received: from dhcp-lys01-vla250-10-147-112-22.cisco.com (dhcp-lys01-vla250-10-147-112-22.cisco.com [10.147.112.22]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4SBMB1x026031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 11:22:11 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: Date: Tue, 28 May 2013 13:22:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 11:22:20 -0000 Lorenzo, > > So it adds (provides) a solution to this 3GPP specific issue. > > how is that different from the RA proxy? > > Define "RA proxy"? http://tools.ietf.org/html/rfc4389#appendix-A cheers, Ole From lorenzo@google.com Tue May 28 07:30:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BD221F8450 for ; Tue, 28 May 2013 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sSlJ2FoP4-f for ; Tue, 28 May 2013 07:30:46 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id C500D21F9524 for ; Tue, 28 May 2013 07:30:41 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id a11so4313138qen.22 for ; Tue, 28 May 2013 07:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6svpvjNlJl+KMeo9wWVG/Xoltxk7px/SJBETVM90tzc=; b=mkSHKX+lFZbRezWZyFDUuV7a1J8T0R5NepFi2vi6lC9x/ThhasqmjthYECA11IvJGI 3t6lBTLSCBsYCN73vJArha8zLqhQVMpYq8BrEi8kwLy7k0oFmX0D6jSMV/bNQa2nEGk3 ZYp5xv9Pmj8cdi4JKoDe15goHUKWH8mhvqhZgRKReg6JHvlthTAnEXE0L5igVCMqFKXe /I1Ys34ngjwG/P/Krv/eQQ+PMicCRvqXwFS+HOPy+pM3xaCkKGj2ZBUMCtAtoH8ZwZpN 1HThS0Rlo14vhBir61uJfIHjhZsY6EI6qsRg6vxdpIeoNkUjc2JJxGrkGk0QhOAEMxrj s5jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=6svpvjNlJl+KMeo9wWVG/Xoltxk7px/SJBETVM90tzc=; b=YTOJcYFJ3xlmd2pj4CaDSWV19RBonPQOiQXXHMaWGQmuwRXNbKUNdBoWCH6UMAlNAi OwuG1pM+kv1qWQSg94MXYZiuPysBt3OTPvzeTzAzSqlhjehtVXo5v0Ep2L68x0cFIHfv 25ZoeyZwsiDpQqWfoL7qCfxOv7w/WdTxwKD+RfhYEBzyYPR5a4eUPupgUG7TOIAYsJWm NyCimleKLoqZAlvXG65v8EHK6j/NNtndXQtupYHkjkWFK1qt/DJ7z2VhP66G17hLZCM+ yHykmIRmNl8E14o6SlxO9Gk9TtL5lbViEAS7P9Ppu/sLVupoYBZ09KRP2SiL9ZxTLII8 3h8Q== X-Received: by 10.49.104.147 with SMTP id ge19mr26056025qeb.6.1369751441126; Tue, 28 May 2013 07:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Tue, 28 May 2013 07:30:20 -0700 (PDT) In-Reply-To: <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> From: Lorenzo Colitti Date: Tue, 28 May 2013 23:30:20 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=047d7b5da795149b0604ddc81cc3 X-Gm-Message-State: ALoCoQle5aRMXiLAKOJGV6bHcxWvilFCxj+BHJQobTGWxV+F7wsQJjrtlY3xdYeb7DmpehIe1iaAYOKUDb1WK7+v54X3GVOmOOG1IXbPVZlHr9TWUak2Flfj0PJIbykpMYRmRktLxhXmTh981XjtGZFAisNwwjc+m7uOZR3IKk/SnUmTPqjOEDgJo/GUDWQHpVqotLibWUJn Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 14:30:54 -0000 --047d7b5da795149b0604ddc81cc3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 6:47 PM, Ole Troan wrote: > > It describes how to overcome the limitations of the 3GPP architecture > until the DHCP-PD will be available. > > So it adds (provides) a solution to this 3GPP specific issue. > > how is that different from the RA proxy? > Not much, but it's more detailed. For example, it document notes that care must be taken to avoid breaking DAD. It's also its own informational document rather than an appendix in a different experimental RFC. --047d7b5da795149b0604ddc81cc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 28, 2013 at 6:47 PM, Ole Troan <otroan@emp= loyees.org> wrote:

> It describes how to overcome the li= mitations of the 3GPP architecture until the DHCP-PD will be available.
> So it adds (provides) a solution to this 3GPP specific issue.

how is that different from the RA proxy?

Not much, but it's more detailed. For example, it documen= t notes that care must be taken to avoid breaking DAD. It's also its ow= n informational document rather than an appendix in a different experimenta= l RFC.

--047d7b5da795149b0604ddc81cc3-- From alexandru.petrescu@gmail.com Tue May 28 07:34:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D849521F9781 for ; Tue, 28 May 2013 07:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjHwDziNXd15 for ; Tue, 28 May 2013 07:34:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 84D5C21F977C for ; Tue, 28 May 2013 07:34:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4SEYfGK005636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 May 2013 16:34:41 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4SEYew7030709 for ; Tue, 28 May 2013 16:34:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4SEYaXK006955 for ; Tue, 28 May 2013 16:34:40 +0200 Message-ID: <51A4C07C.7020903@gmail.com> Date: Tue, 28 May 2013 16:34:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 14:34:48 -0000 Le 28/05/2013 16:30, Lorenzo Colitti a �crit : > On Tue, May 28, 2013 at 6:47 PM, Ole Troan > wrote: > > > It describes how to overcome the limitations of the 3GPP > architecture until the DHCP-PD will be available. > > So it adds (provides) a solution to this 3GPP specific issue. > > how is that different from the RA proxy? > > > Not much, but it's more detailed. For example, it document notes that > care must be taken to avoid breaking DAD. It's also its own > informational document rather than an appendix in a different > experimental RFC. I would like this to be no proxy at all. Actually our implementation (which is actually simply configuration) does not do any form of proxying. Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Tue May 28 08:11:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3B21F901F for ; Tue, 28 May 2013 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoafV8y6PoH4 for ; Tue, 28 May 2013 08:11:32 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C926121F8F41 for ; Tue, 28 May 2013 08:11:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4SFBTp8025521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 May 2013 17:11:30 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4SFBTsa014211 for ; Tue, 28 May 2013 17:11:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4SFBQRf013323 for ; Tue, 28 May 2013 17:11:29 +0200 Message-ID: <51A4C91E.7000504@gmail.com> Date: Tue, 28 May 2013 17:11:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:11:37 -0000 Lorenzo, I have some viewpoints about this, which I hope reasonable. Le 28/05/2013 04:16, Lorenzo Colitti a �crit : > On Sat, May 18, 2013 at 3:54 AM, > wrote: > > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile > Interface to a LAN Author(s) : Cameron Byrne Dan Drown Ales > Vizdal Filename : draft-ietf-v6ops-64share-07.txt > > > Substantive comments: > > 1. The introduction needlessly limits the scope of this document to > 3GPP devices. This scheme works anywhere the uplink is a > point-to-point interface. 3GPP devices happen to fall into that > category, and the fact that 3GPP currently only a /64 is a use case > for this document, but it's not the only one. So I think this scheme > should be documented in the more general case and the 3GPP use case > should be documented as a use case. > > 2. I think scenario #1 should be removed. No, it works. > An IPv6 router without a global scope IPv6 address? YEs. There are many cases where an IPv6 router could do only with its link-local address. > First of all, why? Because, in this particular case, if it removes its globally-scoped IPv6 address then somebody else in the LAN could use it. This avoids all the proxy and DAD worries. > There are plenty of addresses in the /64. YEs, there are. But SLAAC on Ethernet requires all be in one subnet, and not route between one and the other of same /64. > Second, how is the router going to fulfill the router requirements > that require it, I am not sure how strong these requirements are and whether they can be modified. Besides, this link-local address only (not global address) router behaviour could be INFORMATIONAL, for this particular case, rather than seeing the behaviour largely deployed but not documented at all. > for example, to send ICMP error messages? Well, the many of the events which would provoke these ICMP error messages needing global-scoped instead of link-scoped addresses are actually never happening because the Gateway in the fixed infrastructure takes care to generate them. > We can't say that it's OK for a router not to be able to support > PMTUd, send unreachables, support traceroute, etc. for transit > traffic. Well we could, if somebody else takes care to support these anyways (as is the case today). E.g., the cellular network does not allow any traceroute nor PMTUd down to the User Equipment, regardless of it being a Host or a Router. > Third, this mode doesn't even simplify implementation, because the > sharing device has to do autoconf on the uplink anyway to get the > prefix to share. It does simplify implementation because it avoids proxy behaviour on the Mobile Router. > Fourth, disabling autoconf once sharing is enabled means that this > method will not work on any network where the upstream prefix can > change. Well, look at it another way. A Router does not use autoconf anyways. So it is actually a bad behaviour to allow the Host to become a Router and subsequently autoconf an address from the RA it receives. In theory. > Why was this mode included? BEcause it helps avoid the duplicate address of a node in the LAN. The bad situation could be the following: Router auto-configures an address from the RA received on the cellular, and then a Host in its LAN auto-configures the same address from the RA this Router advertises on this LAN (it's same prefix). Two equal globally-scoped addresses on two different interfaces of different machines is not good. > 3. Scenarios #2 and #3 are underspecified. For example, what does > the RA on the LAN look like? Is it a copy of the RA from the WAN? > Presumably not, since we'd want to include the link-layer address of > the router in it. Does the sharing device decrement the TTL? And so > on. I agree, this could be better described. > Instead of putting these as details in the scenarios, they should > probably be put in a more general requirements section whose job it > is to explain what the sharing device must do in order for the IPv6 > protocol to work correctly when sharing a /64. The scenarios would > then become examples of ways you can do this. > > 4. Some of the language is inappropriately vague. For example, what > does "defends its LAN IPv6 address with DAD" mean? I agree, it could say: send 3 NAs upon startup for this address and reply to NSs about that address, on the LAN. Or similar. > 5. It's not OK to say that privacy extensions should be disabled. I > think the document should say that if the sharing device has privacy > addresses, it should maintain them, and if it does maintain them, it > must support DAD for those addresses on its downstream interface(s). > > 6. The document should say that said neighbor advertisements are > proxy neighbour advertisements per RFC 4861 section 7.2.8. Note that > this is different from ND proxy (RFC 4389), which is experimental. I am not sure whether implementations already do proxy ND, ours doesnt. I am not sure there is a need to do it either. Alex > > Cheers, Lorenzo > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From ales.vizdal@t-mobile.cz Tue May 28 08:14:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3114F21F96A9 for ; Tue, 28 May 2013 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOz3X9zjcmew for ; Tue, 28 May 2013 08:14:09 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id B0E3D21F9418 for ; Tue, 28 May 2013 08:14:09 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id 555332E0925; Tue, 28 May 2013 17:13:47 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Tue, 28 May 2013 17:14:07 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Ole Troan , Lorenzo Colitti Date: Tue, 28 May 2013 17:14:06 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt Thread-Index: Ac5btaKf8yythpSYT6iAYdoLgF6AwAAABfgw Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895D5E7E7@SRVHKE02.rdm.cz> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:14:26 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Ole > Troan > Sent: Tuesday, May 28, 2013 1:22 PM > To: Lorenzo Colitti > Cc: IPv6 Ops WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt >=20 > Lorenzo, >=20 > > > So it adds (provides) a solution to this 3GPP specific issue. > > > > how is that different from the RA proxy? > > > > Define "RA proxy"? >=20 > http://tools.ietf.org/html/rfc4389#appendix-A It addresses the open points discussed in the above mentioned appendix, so = the IPv6 prefix can be 'safely' shared. It leaves any proxying out as it is fully L3 routing based. Have a read if = you want. =20 > cheers, > Ole Cheers, Ales From owen@delong.com Tue May 28 11:43:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEC921F9617 for ; Tue, 28 May 2013 11:43:14 -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_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJJVBA89UN7E for ; Tue, 28 May 2013 11:43:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 324FC21F94BA for ; Tue, 28 May 2013 11:43:12 -0700 (PDT) Received: from tc01-dhcp158.delong.com (delong-tc02-dhcp08 [192.159.10.158]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4SIf5Su017339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 May 2013 11:41:05 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4SIf5Su017339 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369766466; bh=rXvciA2Otg/pMI2uzprTM9kqEno=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=0GQS1WeqJ/L6IogU4WZsW9L3+Kcp4C0exLtUSWSkzwYHXNSkWAxlxeoyhvQLTv33b K/SdZqdX/cfoW6WHoxuHied+bHxsJwt/QetyLF3V6P21tiB2UmxZQtrpImbTriA1m3 zC+x+wkzWQyOt0kmmkXhtRKSsDCMA9VufH3gAJQw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <20130527235950.E373534B6442@drugs.dv.isc.org> Date: Tue, 28 May 2013 11:41:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CAA83C0-B786-4AC1-B31F-E75D5A7F2E4C@delong.com> References: <201305181245.r4ICj0i04824@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D722B0E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D726A66@nkgeml506-mbx.china.huawei.com> <719D38CF-F3CD-4BB3-85DC-B7811AC81891@delong.com> <519BD73B.50200@gmail.com> <51A02D23.6080101@dougbarton.us> <51A1781A.3040903@gmail.com> <8E61CD47-B0CC-44E3-A253-38087E72DBF1@delong.com> <20130526220844.7BF0D34B09F4@drugs.dv.isc.org> <20130527235950.E373534B6442@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 28 May 2013 11:41:06 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 18:43:14 -0000 On May 27, 2013, at 4:59 PM, Mark Andrews wrote: >> You can't get ULAs routed either. >=20 > I didn't say you could. >=20 > ULA however are better than a generic prefix from a RIR in that the > software knows (or will know) that they are not globally routable > and can make sensible default decisions when presented with a mixture > of ULA and GUA addresses. Maybe, maybe not. Dual GUA with RIOs to aid local traffic SAS could be just as effective = as GUA+ULA. >=20 > The alternative to ULA + GUA is non-routed GUA + PA GUA and unless > the home network is pushing around address selection tables there is > nothing to tell the two addresses apart. This will lead to the wrong > source address being chosen. Agreed. Where we disagree is in that you seem to expect that SAS will = actually end up working correctly on at least a semi-consistent basis in the = ULA+GUA scenario. Of that, I remain very skeptical. Owen From owen@delong.com Tue May 28 11:58:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27F21F96DF for ; Tue, 28 May 2013 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYuIph6dB4yD for ; Tue, 28 May 2013 11:58:33 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DB88821F96DE for ; Tue, 28 May 2013 11:58:32 -0700 (PDT) Received: from tc01-dhcp158.delong.com (delong-tc02-dhcp08 [192.159.10.158]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4SIrBaS017839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 May 2013 11:53:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4SIrBaS017839 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369767191; bh=S9FjKcPqyqQq1LYMkRkRayRRc0I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dPkFqKvfHNQE0pmlkJrD2M7h47xdA/WvoPUNXoli7Wv3uLpr7ya6D6s+ezYqbZtT4 aHdrkJqTlOf0sRxDeQDSriv0k2Bw9mzSmVHvtfy8vvnPL94BbReGzibj9ymHDK/TQE L906USFA6rgqtgOj0Y6+4gVnvlWhD9WWuj/2sfew= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: Date: Tue, 28 May 2013 11:53:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <2A883F6C-4486-4309-8D4D-22E80DD6B516@delong.com> To: "cb.list6" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 28 May 2013 11:53:11 -0700 (PDT) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 18:58:34 -0000 On May 27, 2013, at 6:57 PM, cb.list6 wrote: > On Mon, May 27, 2013 at 6:39 PM, Lorenzo Colitti = wrote: >> I'm not sure, but I think the fundamental problem is the same as it = has >> always been: "if you ND proxy a downstream interface to an upstream >> interface, you're gonna have a bad time" - because that can create = loops. >>=20 >> However, I think that doing proxy ND between multiple downstream = subnets >> would work fine. >>=20 >=20 > Right, and previous discussion on this topic says their is no way to > prevent it from happening without some heavy-lifting to change ND or > otherwise accepting risks that have been deemed unacceptable >=20 >> As Owen says, we should not document an inferior wheel. So we should = not >> finalize this document if we do not know the answer to this question. = Does >> anyone know the answer? >>=20 >=20 > The previous answer was to scope the wheel to be one link / interface. >=20 > I would like to not let perfect be the enemy of good, and... also > call out that there are shipping implementations that are undocumented > because the need arose before the IETF was willing to discuss it. It > reminds me of how the IETF denied the existence of NAT and therefore > there was a cornucopia of implementation variations. >=20 The IETF did not deny the existence of NAT=85 They decried it as a bad = idea. History has shown that they were correct in this claim. > This draft introduces a handful of scenarios that have been reviewed > by the IETF, it is "only" informational, and my goal is to limit that > cornucopia to a safe set of simple vetted solutions >=20 > Alternatively, we can put our heads back in the sand and tell everyone > DHCP-PD is the only way forward and watch that be ignored while > off-the-cuff implementations roll out (this is, in fact, the current > state with Apple (iPhone), ZTE (4G router), and Samsung (Android > phones) all shipping prefix sharing implementations.) I don't think it's as bad or as dramatic as you make it out to be. There's a working implementation that meets a need. All Lorenzo is = suggesting is that we take the time to understand that working implementation and = document it. Does not seem unreasonable to me. Owen >=20 > CB >=20 >>=20 >> On Tue, May 28, 2013 at 2:35 AM, cb.list6 wrote: >>>=20 >>>=20 >>> On May 27, 2013 10:04 AM, "Owen DeLong" wrote: >>>>=20 >>>>>> Agreed. However, that doesn't mean we need to invent an inferior >>>>>> wheel. >>>>>>=20 >>>>>> Owen >>>>>>=20 >>>>>=20 >>>>> well, we ship what gets rough consensus, not what is "best" for = some >>>>> value of "best" >>>>>=20 >>>>=20 >>>> Unless there is a reason to do so, I cannot imagine that rational >>>> individuals would come to consensus on an inferior choice. >>>>=20 >>>>> Back in the archives, we scoped the scenario to be one routed >>>>> down-link due to folks concerns about loops that would result from >>>>> having multiple interfaces up with the same prefix. >>>>=20 >>>> Ah, but as was described earlier, interface !=3D link and if we = simply >>>> move to the term link, the problem is resolved. The use of the term >>>> interface is what is problematic here. Multiple interfaces which = are bridged >>>> together at layer 2 constitute a single link from an IPv6 = perspective. >>>>=20 >>>>> i think the discussion was somewhere around here and how NDproxy = was >>>>> not acceptable >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html = and >>>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html >>>>=20 >>>> Which only applies in the case of multiple links with the same = prefix, >>>> not multiple interfaces within the same link. >>>>=20 >>>> Owen >>>>=20 >>>=20 >>> Ok, so in the draft we change interface to link and the magic of how = loops >>> and so on are prevented is out of scope since it is in the domain of = "link"? >>>=20 >>> I am fine with that. >>>=20 >>> Is that "one word" change that is needed to close this particular = topic? >>>=20 >>> CB >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 From owen@delong.com Tue May 28 11:58:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C521E8092 for ; Tue, 28 May 2013 11:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnde5hFWfRhz for ; Tue, 28 May 2013 11:58:36 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 076F821F96DE for ; Tue, 28 May 2013 11:58:35 -0700 (PDT) Received: from tc01-dhcp158.delong.com (delong-tc02-dhcp08 [192.159.10.158]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4SIt98p017886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 May 2013 11:55:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4SIt98p017886 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369767310; bh=OAzWMmHySdEKKoKulrmmstAWEHo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qpIbtxq+LCZNVlWUqDMlxZHQ09t+u/FYaogt68m5U+iPTvASnIOyj/leMxtNsqd3C XzBcWDNVNipAY1TC2/gXjtqOPldsWu9+w8lBJxKvT/EeZuaKf94IOmTIEhyJwPLSMw MS7/5uquvZZIgk4b0y6V7TWI/lTB+mJ03Nk4vfbI= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <1369712703.3030.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Tue, 28 May 2013 11:55:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369712703.3030.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 28 May 2013 11:55:10 -0700 (PDT) Cc: "draft-ietf-v6ops-64share@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 18:58:37 -0000 On May 27, 2013, at 8:45 PM, Mark Smith = wrote: > Hi, >=20 >> ________________________________ >> From: Lorenzo Colitti >> To: cb.list6 ; = "draft-ietf-v6ops-64share@tools.ietf.org" = =20 >> Cc: "v6ops@ietf.org WG" =20 >> Sent: Tuesday, 28 May 2013 12:16 PM >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt >>=20 >>=20 >>=20 >> On Sat, May 18, 2013 at 3:54 AM, wrote: >>=20 >> Title : Extending an IPv6 /64 Prefix from a 3GPP = Mobile Interface to a LAN >>> Author(s) : Cameron Byrne >>> Dan Drown >>> Ales Vizdal >>> Filename : draft-ietf-v6ops-64share-07.txt >>>=20 >>=20 >>=20 >> Substantive comments: >>=20 >>=20 >> 1. The introduction needlessly limits the scope of this document to = 3GPP devices. This scheme works anywhere the uplink is a point-to-point = interface. 3GPP devices happen to fall into that category, and the fact = that 3GPP currently only a /64 is a use case for this document, but it's = not the only one. So I think this scheme should be documented in the = more general case and the 3GPP use case should be documented as a use = case. >>=20 >=20 > I was sort of hoping nobody would open that can of worms, as the same = thing occurred to me previously. I fear that doing this would provide an = excuse to some ISPs not to give out more than a single /64 if these = methods are more generally adopted, contrary to the advice in = RFC3177/6177. I think clearly presenting it as a work around to the = limitations of the 3GPP architecture revision mentioned would be better. >=20 +1 Owen From fred@cisco.com Tue May 28 14:46:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332F811E80FA for ; Tue, 28 May 2013 14:46:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIo2L+gALu8Q for ; Tue, 28 May 2013 14:46:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9E111E80A5 for ; Tue, 28 May 2013 14:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1219; q=dns/txt; s=iport; t=1369777597; x=1370987197; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=L4aWiS4xelz2OuWhNW07VmhWbLvPysraJ6UN7lY9bMs=; b=aeXN5fjgCOi3pJhkmu4xtKlHl9aIPFjQAm/KW4IkB91kRDZcCzFZpEzy EP5KC6Osq4+eVzevbbSy7Qj779QZShd/JgkGgJGc89RvpS3RiX5ags6m9 ART3kHyJubvBv9yiFm+akc7nLZ+HwkpeCj9JqHyilqEZI7sW10FmXyGrO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAHAGIkpVGtJXHB/2dsb2JhbABZgwgwwiKBBhZtB4IjAQEBAwF+CwIBGQMBAgskMhQHAggBAQQTCAGHfgYMu3CNW4ERPoJtYQOoe4MPgXE2 X-IronPort-AV: E=Sophos;i="4.87,760,1363132800"; d="scan'208";a="216022854" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 28 May 2013 21:46:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4SLkakD026181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 May 2013 21:46:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 28 May 2013 16:46:36 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: When to adopt a WG I-D Thread-Index: Ac5bhk7NZ1bJ2lzKSk+IVhI2yJUoXQ== Date: Tue, 28 May 2013 21:46:36 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B8FB1A3@xmb-rcd-x09.cisco.com> References: <014801ce5b86$55a476b0$00ed6410$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.122] Content-Type: text/plain; charset="Windows-1252" Content-ID: <11F98B4267148B429D030FDADCFA51DD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: When to adopt a WG I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:46:42 -0000 There is a thread in progress on the IETF list that you may be interested t= o comment in. Begin forwarded message: > From: Adrian Farrel > Subject: When to adopt a WG I-D > Date: May 28, 2013 2:32:50 AM MST > To: > Reply-To: >=20 > Hi, >=20 > Dave Crocker and I have this little draft [1] discussing the process and = considerations for creating formal working group drafts that are targeted f= or publication. >=20 > We believe that this may help clarify some of the issues and concerns ass= ociated with this part of the process. We are targeting this as Information= al (i.e. commentary on existing process, not new normative definition of pr= ocess) and would like your input. >=20 > What is not clear? > What have we got wrong? > How should we resolve the remaining editor notes? >=20 > Thanks, > Adrian > (per pro Dave) >=20 > [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt >=20 >=20 As I wrote this email, my random signature generator added the following. I= started to delete it. I then decided not to... =95 Make things as simple as possible, but not simpler. Albert Einstein From lorenzo@google.com Tue May 28 21:34:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1420F21E804D for ; Tue, 28 May 2013 21:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm2Hxc27Ii-t for ; Tue, 28 May 2013 21:34:15 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7915411E80D2 for ; Tue, 28 May 2013 21:34:15 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so11109740oag.13 for ; Tue, 28 May 2013 21:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZB1185/6lWP5VGci4ayokQBzDz/izMRtV4vvGo2BELU=; b=lkzdwUKfSnienPnkkC9aUG4syWc2SejpKd+3fpswhIXNUFjKtNSXg8ns6nqk/3RXyG 8qERtP5WsL5zjGOOgCcanepSkd0d4wYZx2b8dBOrF/L8hKUbpaLJikJa+8y29PrCR1YR qY6pPaO5eq9ouoo0dFzyEOlkQYj/ovNGmaG+zmZZVsP5Tp0/woUrKoeoII9+0rX2KWb+ AyahNTK2W1exPtesUvye0Co+xT7CyGspQONCEtO+KOMWmNQBivhCjnuQGDhCSq8VC2GO X5eofx91l4x96v4gkyXjkCrhgGdc/DLwjyZ/hAkviO+dNRLdIPVr8hc/Ais7IcwNknzt Kj0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ZB1185/6lWP5VGci4ayokQBzDz/izMRtV4vvGo2BELU=; b=HcI353bifmABq218cQbZlHpIqmy5nZRtqh3Z2VGCEyhLkFnAEf/aOufO/5I2uCpG5Y Oyn9feL3BEd+VwLiHt6JJIT9yTWTYeNYiQ6JCn8Yf8FqPwmAenN8PSJNJqHvU7LWpiVx 139uZb1YSrOVFsGbTT2zsFcn+IQeF595TwbuwvX2KwVM2nM3Q4y6f5Co4ArtxExtsqz0 3yMchJbNn6u1f3QLnnWGA0Sg8ljIi0B8gDJUc6JorHvwYCWygAVcHoVF5kkVAKe6xUeV prALbSgZ4dfCklUu8Dd9bzC07+rpEuTrzCp2/MC8V4CY7IiLr33nBYBustIL/CtkcVZa ZcAw== X-Received: by 10.182.224.162 with SMTP id rd2mr511640obc.95.1369802054925; Tue, 28 May 2013 21:34:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.146.47 with HTTP; Tue, 28 May 2013 21:33:54 -0700 (PDT) In-Reply-To: <51A4C91E.7000504@gmail.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> From: Lorenzo Colitti Date: Wed, 29 May 2013 13:33:54 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=089e01536db4e5aa0404ddd3e4aa X-Gm-Message-State: ALoCoQl7g2E3NJFnLQJlDPHsxLO1s6Wwfvt4AUVEUFK81PISCwzwmillxIb5Ub+iXfwGJA/m7GURbjEGAVe1AxG/w5b+OvVEGdCFxErfktvBTfdWsCYXKNnQVaUw5GEXG/kuDOutWwAn7LJA0WX+gcke6MlMK/RW3J0YIjvr8aCx7swt0QQRt0+uZmfofrqL15s5XqnGhAFr Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 04:34:21 -0000 --089e01536db4e5aa0404ddd3e4aa Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 12:11 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > 2. I think scenario #1 should be removed. >> > > No, it works. Sorry, but no, it doesn't "work". It doesn't support PMTUd and or ICMP errors, which are non-optional parts of the IPv6 specifications. > First of all, why? >> > > Because, in this particular case, if it removes its globally-scoped IPv6 > address then somebody else in the LAN could use it. This avoids all the > proxy and DAD worries. "Because we're lazy and don't want to take the time to understand and document how things should work"? We can't say that it's OK for a router not to be able to support > >> PMTUd, send unreachables, support traceroute, etc. for transit >> traffic. >> > > Well we could, if somebody else takes care to support these anyways (as > is the case today). > No - at the very minimum, you have to at least handle the case where the sharing device's uplink MTU (e.g., 3G) is lower than the MTU on the shared link (e.g., wifi). This cannot be supported by the network, it must be supported by the sharing device. > E.g., the cellular network does not allow any traceroute nor PMTUd down > to the User Equipment, regardless of it being a Host or a Router. If PMTUd is not allowed, then IPv6 doesn't work. It's not an optional part of the spec. Fourth, disabling autoconf once sharing is enabled means that this > >> method will not work on any network where the upstream prefix can >> change. >> > > Well, look at it another way. A Router does not use autoconf anyways. > So it is actually a bad behaviour to allow the Host to become a Router > and subsequently autoconf an address from the RA it receives. In theory. RFC 6204 specifies that IPv6 CE routers use autoconf. > The bad situation could be the following: Router auto-configures an > address from the RA received on the cellular, and then a Host in its LAN > auto-configures the same address from the RA this Router advertises on > this LAN (it's same prefix). Two equal globally-scoped addresses on two > different interfaces of different machines is not good. That's why this draft should say that the sharing device must do DAD. > I am not sure whether implementations already do proxy ND, ours doesnt. > I am not sure there is a need to do it either. > It doesn't need to if you don't care if it works well or not :) --089e01536db4e5aa0404ddd3e4aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2013 at 12:11 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

2. I think scenario #1 should be removed.

No, it works.

Sorry, but no, it doesn= 't "work". It doesn't support PMTUd and or ICMP errors, w= hich are non-optional parts of the IPv6 specifications.

First of all, why?

Because, in this particular case, if it removes its globally-scoped IPv6 address then somebody else in the LAN could use it. =A0This avoids all the<= br> proxy and DAD worries.

"Because = we're lazy and don't want to take the time to understand and docume= nt how things should work"?

We can't say that it's OK for a router not to be = able to support
PMTUd, send unreachables, support traceroute, etc. =A0for transit
traffic.

Well we could, if somebody else takes care to support these anyways (as
is the case today).

No - at the v= ery minimum, you have to at least handle the case where the sharing device&= #39;s uplink MTU (e.g., 3G) is lower than the MTU on the shared link (e.g.,= wifi). This cannot be supported by the network, it must be supported by th= e sharing device.

=A0
E.g., the cellular network doe= s not allow any traceroute nor PMTUd down
to the User Equipment, regardless of it being a Host or a Router.

If PMTUd is not allowed, then IPv6 doesn't= work. It's not an optional part of the spec.

Fourth, disabling au= toconf once sharing is enabled means that this
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> method will not work on any network where the upstream prefix can
change.

Well, look at it another way. =A0A Router does not use autoconf anyways. So it is actually a bad behaviour to allow the Host to become a Router
and subsequently autoconf an address from the RA it receives. =A0In theory.=

RFC 6204 specifies that IPv6 CE rout= ers use autoconf.
=A0

The bad situation cou= ld be the following: Router auto-configures an
address from the RA received on the cellular, and then a Host in its LAN auto-configures the same address from the RA this Router advertises on
this LAN (it's same prefix). =A0Two equal globally-scoped addresses on = two
different interfaces of different machines is not good.
That's why this draft should say that the sharing de= vice must do DAD.
=A0
I am not sure whether implementations already do proxy ND, ours doesnt.
=A0I am not sure there is a need to do it either.

=
It doesn't need to if you don't care if it works w= ell or not :)
--089e01536db4e5aa0404ddd3e4aa-- From alexandru.petrescu@gmail.com Tue May 28 22:55:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CC021F8F83 for ; Tue, 28 May 2013 22:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWcjEJkMpJBM for ; Tue, 28 May 2013 22:54:59 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9860321F8F7B for ; Tue, 28 May 2013 22:54:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4T5svf1004981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 07:54:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4T5sukp014429; Wed, 29 May 2013 07:54:57 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4T5srEx018829; Wed, 29 May 2013 07:54:56 +0200 Message-ID: <51A5982D.8010204@gmail.com> Date: Wed, 29 May 2013 07:54:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Lorenzo Colitti References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 05:55:06 -0000 Le 29/05/2013 06:33, Lorenzo Colitti a �crit : > On Wed, May 29, 2013 at 12:11 AM, Alexandru Petrescu > > wrote: > > 2. I think scenario #1 should be removed. > > > No, it works. > > > Sorry, but no, it doesn't "work". It doesn't support PMTUd and or ICMP > errors, which are non-optional parts of the IPv6 specifications. > > > First of all, why? > > > Because, in this particular case, if it removes its globally-scoped IPv6 > address then somebody else in the LAN could use it. This avoids all the > proxy and DAD worries. > > > "Because we're lazy and don't want to take the time to understand and > document how things should work"? > > We can't say that it's OK for a router not to be able to support > > PMTUd, send unreachables, support traceroute, etc. for transit > traffic. > > > Well we could, if somebody else takes care to support these anyways (as > is the case today). > > > No - at the very minimum, you have to at least handle the case where the > sharing device's uplink MTU (e.g., 3G) is lower than the MTU on the > shared link (e.g., wifi). This cannot be supported by the network, it > must be supported by the sharing device. Yes, MTU is an issue that should be considered and maybe the IPv6 UE being a Router would not do the automatic fragmentation, but the node in the LAN would. > > E.g., the cellular network does not allow any traceroute nor PMTUd down > to the User Equipment, regardless of it being a Host or a Router. > > > If PMTUd is not allowed, then IPv6 doesn't work. It's not an optional > part of the spec. But by this logic no existing IPv6 cellular host (leaving aside the 64share) would work on IPv6 because none does PMTUd. I mean I havent seen these messages. I note we talk two different things: MTU and PMTUd. One could deal with MTU discepancies by setting right MTU manually on interfaces on UE and Host on LAN. More automatically by running PMTUd. The first is easier to deal with both in impl and in spec, but the second assumes not only the Host or the UE does it but also the Correspondent Node. I am not sure many such end nodes are able to do it. > > Fourth, disabling autoconf once sharing is enabled means that this > > method will not work on any network where the upstream prefix can > change. > > > Well, look at it another way. A Router does not use autoconf anyways. > So it is actually a bad behaviour to allow the Host to become a Router > and subsequently autoconf an address from the RA it receives. In > theory. > > > RFC 6204 specifies that IPv6 CE routers use autoconf. And that is not a cellular router. > > The bad situation could be the following: Router auto-configures an > address from the RA received on the cellular, and then a Host in its LAN > auto-configures the same address from the RA this Router advertises on > this LAN (it's same prefix). Two equal globally-scoped addresses on two > different interfaces of different machines is not good. > > > That's why this draft should say that the sharing device must do DAD. YEs, that is right. The UE must do DAD on the LAN, just in case. > I am not sure whether implementations already do proxy ND, ours doesnt. > I am not sure there is a need to do it either. > > > It doesn't need to if you don't care if it works well or not :) Ok. Alex From otroan@employees.org Tue May 28 23:58:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E9F21F9051 for ; Tue, 28 May 2013 23:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.864 X-Spam-Level: X-Spam-Status: No, score=-9.864 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAalaBTZLTld for ; Tue, 28 May 2013 23:58:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7F68821F904B for ; Tue, 28 May 2013 23:58:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloNANSmpVGQ/khM/2dsb2JhbABZJ4JiMIJ0vz6BBxZ0giMBAQQBOj8QC0ZXBi6HbAYMumuOYjMHgnNhA5hkkBeDETo X-IronPort-AV: E=Sophos;i="4.87,763,1363132800"; d="scan'208";a="82933705" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 29 May 2013 06:58:49 +0000 Received: from dhcp-lys01-vla250-10-147-112-52.cisco.com (dhcp-lys01-vla250-10-147-112-52.cisco.com [10.147.112.52]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4T6wY8N000814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 May 2013 06:58:47 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC895D5E7E7@SRVHKE02.rdm.cz> Date: Tue, 28 May 2013 22:33:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <1369343316.67639.YahooMailNeo@web142501.mail.bf1.yahoo.com> <519FB531.9050304@gmail.com> <786EEFCD-B038-451D-ABF6-1E10BFBD2BD6@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E5CB@SRVHKE02.rdm.cz> <48215516-40C2-4731-AB7E-B9AA5F18AD04@employees.org> <1808340F7EC362469DDFFB112B37E2FCC895D5E7E7@SRVHKE02.rdm.cz> To: =?windows-1252?Q?V=EDzdal_Ale=9A?= X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 06:58:56 -0000 Vizdal, >>> Define "RA proxy"? >>=20 >> http://tools.ietf.org/html/rfc4389#appendix-A >=20 > It addresses the open points discussed in the above mentioned = appendix, so the IPv6 prefix can be 'safely' shared. > It leaves any proxying out as it is fully L3 routing based. Have a = read if you want. have now read, thanks. ;-) I don't quite see where "safely" comes into the picture. I think the second paragraph in appendix A, still applies to the = solution in this draft. I would recommend a strong applicability statement. cheers, Ole From otroan@employees.org Tue May 28 23:59:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89821F90FD for ; Tue, 28 May 2013 23:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdbuchZN+kGP for ; Tue, 28 May 2013 23:58:59 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4FB21F90EB for ; Tue, 28 May 2013 23:58:59 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-52.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 5734F5F1D; Tue, 28 May 2013 23:58:57 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: <51A5982D.8010204@gmail.com> Date: Wed, 29 May 2013 08:53:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 06:59:10 -0000 >> No - at the very minimum, you have to at least handle the case where = the >> sharing device's uplink MTU (e.g., 3G) is lower than the MTU on the >> shared link (e.g., wifi). This cannot be supported by the network, it >> must be supported by the sharing device. >=20 > Yes, MTU is an issue that should be considered and maybe the IPv6 UE = being a Router would not do the automatic fragmentation, but the node in = the LAN would. the host in the LAN would, but only if the first-hop router supported = PMTUD. and no, it doesn't strictly speaking need a global address to do = that for a directly connected host. >> E.g., the cellular network does not allow any traceroute nor PMTUd = down >> to the User Equipment, regardless of it being a Host or a Router. >>=20 >>=20 >> If PMTUd is not allowed, then IPv6 doesn't work. It's not an optional >> part of the spec. >=20 > But by this logic no existing IPv6 cellular host (leaving aside the = 64share) would work on IPv6 because none does PMTUd. I mean I havent = seen these messages. I have no idea what an IPv6 cellular host is. I connect my host to a = phone via WIFI, where the phone acts as a router with a cellular uplink. > I note we talk two different things: MTU and PMTUd. >=20 > One could deal with MTU discepancies by setting right MTU manually on = interfaces on UE and Host on LAN. More automatically by running PMTUd. I'm not going to manually adjust anything. forget it. > The first is easier to deal with both in impl and in spec, but the = second assumes not only the Host or the UE does it but also the = Correspondent Node. I am not sure many such end nodes are able to do = it. every IPv6 node I'm aware of supports pmtud. >> Fourth, disabling autoconf once sharing is enabled means that this >>=20 >> method will not work on any network where the upstream prefix = can >> change. >>=20 >>=20 >> Well, look at it another way. A Router does not use autoconf = anyways. >> So it is actually a bad behaviour to allow the Host to become a = Router >> and subsequently autoconf an address from the RA it receives. In >> theory. >>=20 >>=20 >> RFC 6204 specifies that IPv6 CE routers use autoconf. >=20 > And that is not a cellular router. oh please. a cellular router is a router. an RFC6204 is a subset of a = router, that has a certain interface with a dual host/router function. that's exactly what your cellular router does. let us now fall back into = the trap of designing different L3 functionality for all different L2s. = like e.g. what we did with PPP for IPv4 vs DHCP for Ethernet. >> The bad situation could be the following: Router auto-configures = an >> address from the RA received on the cellular, and then a Host in = its LAN >> auto-configures the same address from the RA this Router = advertises on >> this LAN (it's same prefix). Two equal globally-scoped addresses = on two >> different interfaces of different machines is not good. >>=20 >>=20 >> That's why this draft should say that the sharing device must do DAD. >=20 > YEs, that is right. The UE must do DAD on the LAN, just in case. obviously. you would do yourself a favour not trying to redesign the = base IPv6 functionality. >> I am not sure whether implementations already do proxy ND, ours = doesnt. >> I am not sure there is a need to do it either. >>=20 >>=20 >> It doesn't need to if you don't care if it works well or not :) >=20 > Ok. cheers, Ole From jiangsheng@huawei.com Wed May 29 00:07:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28B121F9195; Wed, 29 May 2013 00:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3053boJLw0+K; Wed, 29 May 2013 00:07:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D168B21F85B4; Wed, 29 May 2013 00:07:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATG86921; Wed, 29 May 2013 07:07:03 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 29 May 2013 08:06:30 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 29 May 2013 08:07:00 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 29 May 2013 15:06:54 +0800 From: Sheng Jiang To: "" , "ipv6@ietf.org" Thread-Topic: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV98w== Date: Wed, 29 May 2013 07:06:54 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:07:19 -0000 SVAgYWRkcmVzc2VzIGFyZSBkZXNpZ25lZCBhcyB0b3BvbG9neSBsb2NhdG9yLCBzbyB0aGF0IGV2 ZXJ5IHBhY2tldCBjYW4gYmUgcm91dGVkIHRvIGl0cyBuZXR3b3JrIGRlc3RpbmF0aW9uLg0KDQpI b3dldmVyLCBldmVuIGluIElQdjQgZXJhLCBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFw cGVkIHRoZWlyIElQIGFkZHJlc3Mgd2l0aCBjZXJ0YWluIHNlbWFudGljIGxvY2FsbHkuIFRoZXNl IGtpbmQgb2YgbWVjaGFuaXNtIGV4cGxpY2l0bHkgZXhwcmVzcyB0aGUgc2VtYW50aWMgcHJvcGVy dGllcyBvZiBldmVyeSBwYWNrZXQuIENvbnNlcXVlbnRseSwgdGhlc2UgbmV0d29yayBvcGVyYXRv cnMgY2FuIGluc3BlY3QgdGhlIHByb3BlcnRpZXMgb2YgcGFja2V0cyBlYXNpbHkgYnkgbWFwcGlu ZyB0aGUgYWRkcmVzc2VzIGJhY2sgdG8gc2VtYW50aWMuDQoNCk5ldHdvcmsgb3BlcmF0b3JzLCB3 aG8gaGF2ZSBsYXJnZSBJUHY2IGFkZHJlc3Mgc3BhY2UsIG1heSBhbHNvIGNob29zZSB0byBlbWJl ZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYgYWRkcmVzc2VzIGJ5IGFzc2lnbmluZyBhZGRp dGlvbmFsIHNpZ25pZmljYW5jZSB0byBzcGVjaWZpYyBiaXRzIHdpdGhpbiB0aGUgcHJlZml4LiBk cmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXggZG9jdW1lbnRzIGEgZnJhbWV3b3JrIG1l dGhvZCB0aGF0IG5ldHdvcmsgb3BlcmF0aW9ucyBtYXkgdXNlIHRoZWlyIGFkZHJlc3NlcyB3aXRo IGVtYmVkZGVkIHNlbWFudGljcy4gVGhlc2Ugc2VtYW50aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmlu Z2Z1bCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yaywgb3IgZ3JvdXAgb2YgaW50ZXJjb25uZWN0ZWQg bmV0d29ya3Mgd2hpY2ggc2hhcmUgYSBjb21tb24gYWRkcmVzc2luZyBwb2xpY3kuIEJhc2VkIG9u IHRoZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMgaW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJl c3NlcywgdGhlIG5ldHdvcmsgb3BlcmF0b3JzIGNhbiBhY2NvcmRpbmdseSB0cmVhdCBuZXR3b3Jr IHBhY2tldHMgZGlmZmVyZW50bHkgYW5kIGVmZmljaWVudGx5Lg0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMNCg0KQ291bGQg eW91IHBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCBhbmQgY29tbWVudHM/IEl0IHdpbGwgaGVscCB0 aGUgZG9jdW1lbnQgYmVjb21lIG1vcmUgdXNlZnVsIGluZm9ybWF0aW9uIHRvIGJlIHNoYXJlZC4N Cg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+U2VudDogVHVlc2RheSwgTWF5IDI4LCAyMDEzIDEwOjI4IEFNDQo+VG86IFFp b25nIFN1bjsgSWFuIEZhcnJlcjsgU2hlbmcgSmlhbmc7IEJveWFuZw0KPlN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVm aXgtMDMudHh0DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWppYW5nLXY2b3Bz LXNlbWFudGljLXByZWZpeC0wMy50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0K PkZpbGVuYW1lOgkgZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4DQo+UmV2aXNpb246 CSAwMw0KPlRpdGxlOgkJIEEgRnJhbWV3b3JrIGZvciBTZW1hbnRpYyBJUHY2IFByZWZpeA0KPkNy ZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTI4DQo+R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+TnVtYmVyIG9mIHBhZ2VzOiAxOQ0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMudHh0DQo+U3Rh dHVzOg0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctdjZvcHMt c2VtYW50aWMtcHJlZml4DQo+SHRtbGl6ZWQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+RGlmZjoNCj5odHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgt MDMNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGZyYW1ld29y ayBtZXRob2QgdGhhdCBuZXR3b3JrIG9wZXJhdGlvbnMNCj4gICBtYXkgdXNlIHRoZWlyIGFkZHJl c3Nlcy4gIE5ldHdvcmsgb3BlcmF0b3JzLCB3aG8gaGF2ZSBsYXJnZSBJUHY2DQo+ICAgYWRkcmVz cyBzcGFjZSwgbWF5IGNob29zZSB0byBlbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYN Cj4gICBhZGRyZXNzZXMgYnkgYXNzaWduaW5nIGFkZGl0aW9uYWwgc2lnbmlmaWNhbmNlIHRvIHNw ZWNpZmljIGJpdHMNCj4gICB3aXRoaW4gdGhlIHByZWZpeC4gIEJ5IGVtYmVkZGVkIHNlbWFudGlj cyBpbnRvIElQdjYgcHJlZml4ZXMsIHRoZQ0KPiAgIHNlbWFudGljcyBvZiBwYWNrZXRzIGNhbiBi ZSBpbnNwZWN0ZWQgZWFzaWx5LiAgUm91dGVycyBhbmQgb3RoZXINCj4gICBpbnRlcm1lZGlhcnkg ZGV2aWNlcyBjYW4gZWFzaWx5IGFwcGx5IHJlbGV2YW50IHBvbGljaWVzIGFzIHJlcXVpcmVkLg0K PiAgIFBhY2tldC1sZXZlbCBkaWZmZXJlbnRpYXRpb24gY2FuIGFsc28gZW5hYmxlIGZsb3ctbGV2 ZWwgYW5kIHVzZXItDQo+ICAgbGV2ZWwgZGlmZmVyZW50aWF0aW9uLiAgQ29uc2VxdWVudGx5LCB0 aGUgbmV0d29yayBvcGVyYXRvcnMgY2FuDQo+ICAgYWNjb3JkaW5nbHkgdHJlYXQgbmV0d29yayBw YWNrZXRzIGRpZmZlcmVudGx5IGFuZCBlZmZpY2llbnRseS4gIFRoZQ0KPiAgIG1hbmFnZW1lbnQg YW5kIG1haW50ZW5hbmNlIG9mIG5ldHdvcmtzIGNhbiBiZSBtdWNoIHNpbXBsZXIuDQo+DQo+DQo+ DQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From lorenzo@google.com Wed May 29 00:14:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8945621F9128 for ; Wed, 29 May 2013 00:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYXUldDGPE4Z for ; Wed, 29 May 2013 00:14:20 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE2121F9123 for ; Wed, 29 May 2013 00:14:20 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id s14so4905705qeb.12 for ; Wed, 29 May 2013 00:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HlzM9vKWflKPRIF0KjRlK2V+XecZ4Qq6QnqDcpXHbac=; b=czj29Be6hteXiqvUK0I2QS9w01cn91oT6ir6GeojRMPYY5Kqjh4DSk/Qkit0V2tKUY +wr+o0MSSG2TXiLbP7bPnga1/+aGyTo45x1ciYJQhE4s6IKYo0FdXwLbR9OGfFQv+YcO i/Q4Sc4liMA+CfdM4adhj5na0vcl+BMT5PjJ0cmQdV5aoqNwe1Lxafq0fnblMbeZzjn7 WUXAhIdpNWDaN/BXOylZbeiipVEAHGkQjppANWAFt+0ozw+6NQv/VupsZBv3QemOR35h 3C1/yyykPeqn69x+HRg4mdEMsHdTA8bwSWDlFDv1CTtK25mx7pPH+WEfXAfvEU58mVQe lAiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=HlzM9vKWflKPRIF0KjRlK2V+XecZ4Qq6QnqDcpXHbac=; b=hBczBSu1PLasguWCkXOJk9VMFc4r7xqzCYAKQwJyoq7Z4zWFnmRw6Ep3LZGB4C2Wly VcG6qdgjCWcJLUhpaqKkEfsgjAluJomevnYUEOj8x9N2gsU96/ep0Ly1n3+Crs7qfywb x3vONG73/qCYtCbnC9f/UoqFwDps8sFScu5EkzsRYzKsH1GC5ecrXO5BNavTBYkZG3wC 8czJ3+aotyqb4vybhCh6YJpPyUQGj/Siwf/j057MoJ+TDfkqhmEHBcBZb/SLuxwCUoaX Co490b2AiVpi7AGYKhlxtHVfD8v4YhnqXSqNGruwxWOVP0bM7+fBsdnk8uIT644v3AX5 K5kA== X-Received: by 10.224.187.67 with SMTP id cv3mr1831809qab.20.1369811659601; Wed, 29 May 2013 00:14:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Wed, 29 May 2013 00:13:59 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> From: Lorenzo Colitti Date: Wed, 29 May 2013 16:13:59 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=485b397dd4f56189de04ddd621ee X-Gm-Message-State: ALoCoQlhljuJYyITkqsEWIQI+s1z/QTETqqauIzE8/ITP+tzW5FG+6ddoj3wEfQ2JM2cTDYD/YVLvYEPa4WOaRicB7PsCkdOCRQNUb0R84r6LJ+aD06IcSRMRa/zCFoJbnqeu5tnHzeGfjgFvJRsSljkcbqozdF12tk93KqmuiCxYZf3eLKlzzNzj1lWRQmrMOLCH1N4yGTc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:14:25 -0000 --485b397dd4f56189de04ddd621ee Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 3:53 PM, Ole Troan wrote: > the host in the LAN would, but only if the first-hop router supported > PMTUD. and no, it doesn't strictly speaking need a global address to do > that for a directly connected host. > But it does need a global address to send ICMP errors to off-link destinations (i.e., everywhere else on the Internet). --485b397dd4f56189de04ddd621ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2013 at 3:53 PM, Ole Troan <otroan@emp= loyees.org> wrote:

the host in the LAN would, but only if the first-hop router suppo= rted PMTUD. and no, it doesn't strictly speaking need a global address = to do that for a directly connected host.

But it does need a global address to= send ICMP errors to off-link destinations (i.e., everywhere else on the In= ternet).
--485b397dd4f56189de04ddd621ee-- From otroan@employees.org Wed May 29 00:21:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A3221F8D2B for ; Wed, 29 May 2013 00:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jss5zdUbZz1u for ; Wed, 29 May 2013 00:21:18 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 72F8C21F896D for ; Wed, 29 May 2013 00:21:13 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-52.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 39A055E95; Wed, 29 May 2013 00:21:12 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: Date: Wed, 29 May 2013 09:21:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:21:24 -0000 Lorenzo, > the host in the LAN would, but only if the first-hop router supported = PMTUD. and no, it doesn't strictly speaking need a global address to do = that for a directly connected host. >=20 > But it does need a global address to send ICMP errors to off-link = destinations (i.e., everywhere else on the Internet). absolutely. I think the draft should only describe scenario 2, and be explicit about = the router using the weak host model. it should also have a normative reference to RFC6204 making it clear = that this device is a CE router, with some short term hack for this particular link-type. cheers, Ole From alexandru.petrescu@gmail.com Wed May 29 02:21:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3654B21F8EEC for ; Wed, 29 May 2013 02:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNXi6mO2Xz6I for ; Wed, 29 May 2013 02:21:29 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9662321F8F00 for ; Wed, 29 May 2013 02:21:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4T9LG34004457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 11:21:16 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4T9LFmM008086; Wed, 29 May 2013 11:21:16 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4T9LFCK020554; Wed, 29 May 2013 11:21:15 +0200 Message-ID: <51A5C88B.1020903@gmail.com> Date: Wed, 29 May 2013 11:21:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Lorenzo Colitti References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 09:21:37 -0000 Le 29/05/2013 09:13, Lorenzo Colitti a �crit : > On Wed, May 29, 2013 at 3:53 PM, Ole Troan > wrote: > > the host in the LAN would, but only if the first-hop router > supported PMTUD. and no, it doesn't strictly speaking need a global > address to do that for a directly connected host. > > > But it does need a global address to send ICMP errors to off-link > destinations (i.e., everywhere else on the Internet). I think this is a breaking point. I dont think a Router must have a globally scoped unicast address always. I think one goes too far in interpreting that as being a strong requirement. I think this neglects what is already happening with many specs at IETF, at various maturity levels, and which dont assume every other RFC out there is a must. Alex From lorenzo@google.com Wed May 29 02:29:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4B21F8F3E for ; Wed, 29 May 2013 02:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjaYGLVJ5yx7 for ; Wed, 29 May 2013 02:29:40 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8890E21F8E6E for ; Wed, 29 May 2013 02:29:40 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ci6so195763qab.9 for ; Wed, 29 May 2013 02:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vmhI4svi4Dp3Um38K/Azo1e9RxBdCXt42F80GbUVAYE=; b=L8Pfsr7xy9fPgH1wlzYTbixzjt0Q8sscyEwCLLHSmaKu4yjecO7CV1NtYWrArumFsp prUG/82/3X7ilSs0gTfa03MO9yGQI7TI4NcpOBP945+zUhfvXvHScyHGFpExWSetU0Vj 4iT6VYNISmauDgMHT7lNl3XHR3w5FPPCekSj+IstSBExt1wUSD2DrWZemNAN9//bpor+ mnyBdp20Ddmg9kYKMUFEIsOGiJEtGTshI/XHYf7E5nnM8gdjqEXmztTPJ2iR5g0B6NHl 10RBsLI8dXoNpsZrU3lxZCTw6p9qC3NqUe+Q9DYZKi9TZqvO5FgYF4Tns2HMa/w82Ebk Fhrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=vmhI4svi4Dp3Um38K/Azo1e9RxBdCXt42F80GbUVAYE=; b=h6MSdfMq6gRU5j1d+JhAGLU61rJZhQp8pLkJIkck48bwyqfWYHLesGHmQuYISE5WPO iXV7ZyBdPguqoOGpvT4mCWaevum3GS5wlkQFiYUffXZcW6uvihR8cDzPuX5jVjw2ZtiC x0CcEJdRSn5zCWrN8oYf7+y3gpohePmd2oVI4k3Z+eFvPSKuxXekSM24aZIgJFWG885h +fnNFhP25UWC4Xt2f1/2ZR3P6jGMovn/F+5pP0JNA3qU+HzMoVeP+4Uc4DIH33AB2PqF qZddHzxZPLlLw7PRcynBRgeuTCCwDyOB14FGIljNnyFDX62G2sF4bxkr83SapE67/CAO QOtg== X-Received: by 10.49.104.147 with SMTP id ge19mr1929267qeb.6.1369819779934; Wed, 29 May 2013 02:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.21 with HTTP; Wed, 29 May 2013 02:29:19 -0700 (PDT) In-Reply-To: <51A5C88B.1020903@gmail.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> From: Lorenzo Colitti Date: Wed, 29 May 2013 18:29:19 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b5da79563f1d804ddd8054a X-Gm-Message-State: ALoCoQmSNIFXCltfwMeW/lCktu6LARunkk3kwyQseIrxWc78qfaYiY/LiBOaXalNq7PaYaJQ+66AJhVnvSNEMWrOiA37mMvh001QlacekkSE+PjC4P+Xu5ULgg1macCvoTXvGT2lotI3q3pw0c66Vf5vpgBZK7OQGJSYQOXvPJw40dH7hnkjNixdF4e7E1sQtR7zVCUTJ7CG Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 09:29:41 -0000 --047d7b5da79563f1d804ddd8054a Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > I dont think a Router must have a globally scoped unicast address always. > > I think one goes too far in interpreting that as being a strong > requirement. > > I think this neglects what is already happening with many specs at IETF, > at various maturity levels, and which dont assume every other RFC out there > is a must. > I think that "routers forwarding packets to and from global addresses should have global addresses" is pretty clearly a must-have because it's the only way to implement various non-optional parts of ICMPv6 in a way that works. But even if you disagree that it's a must, it's at least operational good practice, and I think we need a better reason to recommend violating this operational good practice than "we want to allow implementations not to implement DAD". --047d7b5da79563f1d804ddd8054a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

I dont think a Router must have= a globally scoped unicast address always.

I think one goes too far in interpreting that as being a strong requirement= .

I think this neglects what is already happening with many specs at IETF, at= various maturity levels, and which dont assume every other RFC out there i= s a must.

I think that "rout= ers forwarding packets to and from global addresses should have global addr= esses" is pretty clearly a must-have because it's the only way to = implement various non-optional parts of ICMPv6 in a way that works.

But even if you disagree that it's a mu= st, it's at least operational good practice, and I think we need a bett= er reason to recommend violating this operational good practice than "= we want to allow implementations not to implement DAD".

--047d7b5da79563f1d804ddd8054a-- From alexandru.petrescu@gmail.com Wed May 29 03:00:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F423E21F9234 for ; Wed, 29 May 2013 03:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXaijacbL+ec for ; Wed, 29 May 2013 03:00:16 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id D385C21F9263 for ; Wed, 29 May 2013 03:00:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4TA06V9007483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 12:00:06 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4TA0506027298; Wed, 29 May 2013 12:00:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4TA02PM027868; Wed, 29 May 2013 12:00:05 +0200 Message-ID: <51A5D1A2.3000304@gmail.com> Date: Wed, 29 May 2013 12:00:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Lorenzo Colitti References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 10:00:23 -0000 Le 29/05/2013 11:29, Lorenzo Colitti a �crit : > On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu > > > wrote: > > I dont think a Router must have a globally scoped unicast address > always. > > I think one goes too far in interpreting that as being a strong > requirement. > > I think this neglects what is already happening with many specs at > IETF, at various maturity levels, and which dont assume every other > RFC out there is a must. > > > I think that "routers forwarding packets to and from global addresses > should have global addresses" is pretty clearly a must-have because > it's the only way to implement various non-optional parts of ICMPv6 > in a way that works. > > But even if you disagree that it's a must, it's at least operational > good practice, and I think we need a better reason to recommend > violating this operational good practice than "we want to allow > implementations not to implement DAD". Routers can forward packets between globally-scoped addresses without needing such for self. Small routers at the edge of the network with 1-2 routing table entries are less likely to break something, much less than core network routers which better had ICMP Redirect, Packet Too Big. DAD is good to do, but DAD wont offer uniqueness, wont fix the duplication problem. Should the UE Router keep its global address to maybe one day respond with a Packet Too Big? Or should the UE Router delete its global address to avoid one day a duplicate situation with a Host in the LAN? Alex From ichiroumakino@gmail.com Wed May 29 03:36:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9521F86F4 for ; Wed, 29 May 2013 03:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19pwCW8fn3R2 for ; Wed, 29 May 2013 03:36:07 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1AF21F86DD for ; Wed, 29 May 2013 03:36:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAFvZpVGQ/khM/2dsb2JhbABagwnCK4EIFnSCIwEBBAFcHRALCw0nByECIxEGE4d6AQMJBqh0iBgKGScNWIgFjD6CVweCc2EDlVWBZowdhSODETo X-IronPort-AV: E=Sophos;i="4.87,763,1363132800"; d="scan'208";a="14290233" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 29 May 2013 10:36:04 +0000 Received: from dhcp-lys01-vla250-10-147-112-52.cisco.com (dhcp-lys01-vla250-10-147-112-52.cisco.com [10.147.112.52]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4TAa1RM003194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 May 2013 10:36:01 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: <51A5D1A2.3000304@gmail.com> Date: Wed, 29 May 2013 12:36:01 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A5D1A2.3000304@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 10:36:13 -0000 Alexandru, >> On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu >> > >> wrote: >> >> I dont think a Router must have a globally scoped unicast address >> always. >> >> I think one goes too far in interpreting that as being a strong >> requirement. >> >> I think this neglects what is already happening with many specs at >> IETF, at various maturity levels, and which dont assume every other >> RFC out there is a must. >> >> >> I think that "routers forwarding packets to and from global addresses >> should have global addresses" is pretty clearly a must-have because >> it's the only way to implement various non-optional parts of ICMPv6 >> in a way that works. >> >> But even if you disagree that it's a must, it's at least operational >> good practice, and I think we need a better reason to recommend >> violating this operational good practice than "we want to allow >> implementations not to implement DAD". > > Routers can forward packets between globally-scoped addresses without > needing such for self. Small routers at the edge of the network with > 1-2 routing table entries are less likely to break something, much less > than core network routers which better had ICMP Redirect, Packet Too Big. > > DAD is good to do, but DAD wont offer uniqueness, wont fix the > duplication problem. > > Should the UE Router keep its global address to maybe one day respond > with a Packet Too Big? > > Or should the UE Router delete its global address to avoid one day a > duplicate situation with a Host in the LAN? I thought redesign of IPv6 was outside of the scope of v6ops. cheers, Ole From alexandru.petrescu@gmail.com Wed May 29 05:07:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74B421F9273 for ; Wed, 29 May 2013 05:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.829 X-Spam-Level: X-Spam-Status: No, score=-9.829 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRE9LhgflME6 for ; Wed, 29 May 2013 05:07:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CD25521F928C for ; Wed, 29 May 2013 05:07:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4TC7gJr032215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 14:07:42 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4TC7fp3000989; Wed, 29 May 2013 14:07:41 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4TC7clJ024553; Wed, 29 May 2013 14:07:41 +0200 Message-ID: <51A5EF8A.2040008@gmail.com> Date: Wed, 29 May 2013 14:07:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A5D1A2.3000304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:07:52 -0000 Le 29/05/2013 12:36, Ole Troan a �crit : > Alexandru, > >>> On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu >>> > >>> wrote: >>> >>> I dont think a Router must have a globally scoped unicast address >>> always. >>> >>> I think one goes too far in interpreting that as being a strong >>> requirement. >>> >>> I think this neglects what is already happening with many specs at >>> IETF, at various maturity levels, and which dont assume every other >>> RFC out there is a must. >>> >>> >>> I think that "routers forwarding packets to and from global addresses >>> should have global addresses" is pretty clearly a must-have because >>> it's the only way to implement various non-optional parts of ICMPv6 >>> in a way that works. >>> >>> But even if you disagree that it's a must, it's at least operational >>> good practice, and I think we need a better reason to recommend >>> violating this operational good practice than "we want to allow >>> implementations not to implement DAD". >> >> Routers can forward packets between globally-scoped addresses without >> needing such for self. Small routers at the edge of the network with >> 1-2 routing table entries are less likely to break something, much less >> than core network routers which better had ICMP Redirect, Packet Too Big. >> >> DAD is good to do, but DAD wont offer uniqueness, wont fix the >> duplication problem. >> >> Should the UE Router keep its global address to maybe one day respond >> with a Packet Too Big? >> >> Or should the UE Router delete its global address to avoid one day a >> duplicate situation with a Host in the LAN? > > I thought redesign of IPv6 was outside of the scope of v6ops. I thought operational experience of IPv6 deployments were relevant. Alex > > cheers, > Ole > > > From ichiroumakino@gmail.com Wed May 29 05:13:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E708621F9347 for ; Wed, 29 May 2013 05:13:29 -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_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT2-ZQAPQttt for ; Wed, 29 May 2013 05:13:29 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 409C021F930C for ; Wed, 29 May 2013 05:13:27 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-52.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4AB335E85; Wed, 29 May 2013 05:13:26 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Ole Troan In-Reply-To: <51A5EF8A.2040008@gmail.com> Date: Wed, 29 May 2013 14:13:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2130E743-6863-4AF3-9CAB-E79C5FE2CD9E@gmail.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A5D1A2.3000304@gmail.com> <51A5EF8A.2040008@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:13:30 -0000 >>>=20 >>> Or should the UE Router delete its global address to avoid one day a >>> duplicate situation with a Host in the LAN? >>=20 >> I thought redesign of IPv6 was outside of the scope of v6ops. >=20 > I thought operational experience of IPv6 deployments were relevant. do you have operational experience showing: - there is no consequence of a router not being able to send ICMPs - duplicate addresses is a bigger problem between hosts and the router = than between a host and other hosts, justifying that the router shouldn't have a global address on the = link? if so, please share. cheers, Ole= From gert@space.net Wed May 29 06:20:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F142221F8F33 for ; Wed, 29 May 2013 06:20:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJDmoNe039yi for ; Wed, 29 May 2013 06:20:04 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 4E80121F8F2C for ; Wed, 29 May 2013 06:20:03 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0DD7C60853 for ; Wed, 29 May 2013 15:20:02 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CF6466083D for ; Wed, 29 May 2013 15:20:01 +0200 (CEST) Received: (qmail 88659 invoked by uid 1007); 29 May 2013 15:20:01 +0200 Date: Wed, 29 May 2013 15:20:01 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20130529132001.GE2504@Space.Net> References: <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A5D1A2.3000304@gmail.com> <51A5EF8A.2040008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A5EF8A.2040008@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:20:05 -0000 Hi, On Wed, May 29, 2013 at 02:07:38PM +0200, Alexandru Petrescu wrote: > I thought operational experience of IPv6 deployments were relevant. Then you should try to get some. Really: the amount of noise you are contributing to this discussion is unbearable. I'm all for a good discussion, but not based on "well, I don't really care about all these bits everybody and the standards are agreeing on, so let's do it all differently now". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From rajiva@cisco.com Wed May 29 06:32:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35D321F8F0A for ; Wed, 29 May 2013 06:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.759 X-Spam-Level: X-Spam-Status: No, score=-8.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6F7XULmJVMZ for ; Wed, 29 May 2013 06:32:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 268DD21F91CA for ; Wed, 29 May 2013 06:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1247; q=dns/txt; s=iport; t=1369834325; x=1371043925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C/RA5DY2T6D2Pz2VvTzlpGKW8JxVWRvJ98FhCYFgZ+4=; b=cAPpw4G9JYBizjJepZCfmeXs2fAnoHkBqvKZmHaK4aMPlN/8hFUmT/J8 TaxAX8RppHnFCAKWIuMuXBWlG13HMuK6azdRpb5PL+hFVMiDfzXwQYuLk pt1QXeH9wyMa0zMwRWW99f2Bbo7wT9jXmPScI8lR98XffjjrLN0wpjl7s E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAD0CplGtJXG9/2dsb2JhbABagwkwwXuBChZ0giMBAQEDAQEBATc0CwUHBAIBCA4DBAEBCxQJBycLFAkIAgQBDQUIh38GDLpNBI5kMQcGgm1hA6h7gw+CJw X-IronPort-AV: E=Sophos;i="4.87,764,1363132800"; d="scan'208";a="216225710" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 29 May 2013 13:32:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4TDW3Ex026573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 13:32:03 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 29 May 2013 08:32:02 -0500 From: "Rajiv Asati (rajiva)" To: Ole Troan , Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt Thread-Index: AQHOW0llJXOvSiBFNE6ojEcZrYeE0ZkbCH0AgADgNQCAABaggIAAEFUAgAAFxYCAAAICAIAAE7Og Date: Wed, 29 May 2013 13:32:01 +0000 Message-ID: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.255.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:32:14 -0000 > it should also have a normative reference to RFC6204 making it clear that > this device is a CE router,=20 +1. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Ole Troan > Sent: Wednesday, May 29, 2013 3:21 AM > To: Lorenzo Colitti > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt >=20 > Lorenzo, >=20 > > the host in the LAN would, but only if the first-hop router supported > PMTUD. and no, it doesn't strictly speaking need a global address to do t= hat > for a directly connected host. > > > > But it does need a global address to send ICMP errors to off-link > destinations (i.e., everywhere else on the Internet). >=20 > absolutely. > I think the draft should only describe scenario 2, and be explicit about = the > router using the weak host model. > it should also have a normative reference to RFC6204 making it clear that > this device is a CE router, with some short term hack for this particular= link- > type. >=20 > cheers, > Ole >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From bs7652@att.com Wed May 29 08:16:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0CD21F8F87 for ; Wed, 29 May 2013 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+vn7OA0pK0D for ; Wed, 29 May 2013 08:15:55 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9990D21F8F0E for ; Wed, 29 May 2013 08:15:52 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8ab16a15.2aaad7017940.205137.00-514.577379.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 29 May 2013 15:15:52 +0000 (UTC) X-MXL-Hash: 51a61ba82b568ba3-3a55628afd1da87075944ba89eeb8d5795818adb Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4ab16a15.0.205086.00-450.577243.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 29 May 2013 15:15:49 +0000 (UTC) X-MXL-Hash: 51a61ba529cf792c-e747a631e3640010a906ea73f0dd5024d6f7403a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4TFFlPd011050; Wed, 29 May 2013 11:15:48 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4TFFdGD010880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 11:15:47 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 29 May 2013 15:15:32 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Wed, 29 May 2013 11:15:32 -0400 From: "STARK, BARBARA H" To: Alexandru Petrescu , Ole Troan Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt Thread-Index: AQHOW0lluUFyJ2vJskGb3C5g315Mkpka97kAgADgNQCAABahgIAAEFQAgAAFxYCAACOPgIAAAkGAgAAIlQCAAAoOgIAAGZkA///O3XA= Date: Wed, 29 May 2013 15:15:31 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302CA6DC@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A5D1A2.3000304@gmail.com> <51A5EF8A.2040008@gmail.com> In-Reply-To: <51A5EF8A.2040008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.199.78.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=S61uNvQP c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=XF2aQeIDtRMA:10 a=qkDxVxExbkUA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jJkZAp68P1sA:10 a=I7YuFmY9oboKAAvPNL8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=xzbILLHXy35mJfDF:21 a=TIXdHry0JDOmN3c4:21] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:16:02 -0000 > I thought operational experience of IPv6 deployments were relevant. My operational experience of CE routers and IP deployments (v4 and v6) sugg= ests that a CE router that can't at the very least do diagnostics and troub= leshooting against Internet destinations is a bad idea. Being able to launc= h various simple tests from the router is critical when troubleshooting, so= that the LAN can be properly dismissed as the cause of a problem.=20 Therefore, I would never recommend that anyone get a CE router that can sup= port a 3GPP IPv6 WAN interface (directly or via USB modem), but doesn't try= to assign itself a GUA that can be used to source traffic that gets sent o= ut the WAN interface. That is, I would never recommend a "Scenario 1" IPv6 = router to anyone. When working with "wireline" CE router vendors to define the "unnumbered" m= odel (where the CE router is expected to take its addresses from a prefix i= t has been delegated via IA_PD), the router vendors said it wasn't a proble= m to do this. They did ask us not to try to be specific about what interfac= e the addresses got attached to. Some only had a single WAN and LAN interfa= ce, in which case they intended to attach the addresses to the LAN interfac= e. Others had a variety of internal interfaces, as well. This was especiall= y true of the CE routers that supported multiple LAN networking technologie= s (e.g., Ethernet and Wi-Fi), and those that could support multiple WAN int= erfaces. The router vendors asked that we just describe the externally dete= ctable behavior (treat it like a black box) and let them figure out how to = do things internal to their products. This is reflected in the RFC 6204 req= uirement: WAA-8: If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces. If I were to translate that experience to this case, I would prefer to expe= ct the following of an IPv6 CE router capable of a 3GPP interface: If the WAN interface is a 3GPP interface, and there is an RA message with a= n "A=3D1" prefix and flags M=3DO=3D0, treat the "A=3D1" prefix in the RA me= ssage as if it were a /64 delegated prefix, and operate per RFC 6204 WAA-8 = and WAA-9 (do weak host model). Do not do SLAAC on the WAN interface (i.e.,= there will be no DAD messages seen coming out the WAN interface). If LAN i= nterface is active, advertise the /64 prefix on the LAN with A=3D1 and do D= AD (to the LAN) for all self-assigned addresses from that prefix. Or, bette= r yet, do RFC 6204 LAN-Side Configuration (Section 4.3). I don't know if al= l of the WAN-Side Configuration requirements (Section 4.2 of RFC 6204) shou= ld be applied to a 3GPP interface, so I'm hesitant about suggesting RFC 620= 4 be made normative in its entirety. This is effectively Scenario 2, where the UE always considers its router fu= nctionality to be enabled (because it was designed to primarily be a router= ), so it never does SLAAC on the WAN interface (unless M or O indicate the = presence of a DHCPv6 server) and doesn't move its addresses around based on= the state of router functionality. Anyway, that's my 2 cents, as someone who deals a lot with CE routers in ma= ss market environments. UEs that do tethering are a whole different world, = and I don't pretend to provide advice to them. Barbara From cb.list6@gmail.com Wed May 29 09:14:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57AA21F9080 for ; Wed, 29 May 2013 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7-hTTDRpRyj for ; Wed, 29 May 2013 09:14:44 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA2121F8ED8 for ; Wed, 29 May 2013 09:14:35 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z11so6683616wgg.7 for ; Wed, 29 May 2013 09:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3+NI3F4GTz3nAgY29yx/ZNNR7Mf7s+GThEJts7l2IFA=; b=Q6oJ4EyKybvNGB216wywwU292PaL7tnloZ6s5uS1dNrylW6eoS6rwAFHHYq1gvx4a2 zpiWt0+/gL342y5bKgElpUDH4apBIlWbq8LSzckyObtFTyWLl0zgVTuNgDo6MP+GeqS/ iHbuMrMXP2emg9cneALVJOkYckLSyaPbD9a1fI6Byy8niSw/KvaoLxS/KTHPLBR4zMNA mRaXEgk4Nzi8JB+pl1+5hlelHxMMQ4C3wBR9T1ltIG27OEUT9910XXMw9oyE8Or1CowU 3po/swpFkZ5nunIJV6KRYY/GPjox0mfKILHHzr2J0aL26hHnDIuJQ2P2esloQpydKLza j60A== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr1941132wic.7.1369844075179; Wed, 29 May 2013 09:14:35 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Wed, 29 May 2013 09:14:35 -0700 (PDT) In-Reply-To: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> Date: Wed, 29 May 2013 09:14:35 -0700 Message-ID: From: "cb.list6" To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:14:44 -0000 On Wed, May 29, 2013 at 2:29 AM, Lorenzo Colitti wrote: > On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu > wrote: >> >> I dont think a Router must have a globally scoped unicast address always. >> >> I think one goes too far in interpreting that as being a strong >> requirement. >> >> I think this neglects what is already happening with many specs at IETF, >> at various maturity levels, and which dont assume every other RFC out there >> is a must. > > I agree, it is not OK to break PMTU I will remove scenario 1. CB > I think that "routers forwarding packets to and from global addresses should > have global addresses" is pretty clearly a must-have because it's the only > way to implement various non-optional parts of ICMPv6 in a way that works. > > But even if you disagree that it's a must, it's at least operational good > practice, and I think we need a better reason to recommend violating this > operational good practice than "we want to allow implementations not to > implement DAD". > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Wed May 29 09:41:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7921F90C3 for ; Wed, 29 May 2013 09:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.816 X-Spam-Level: X-Spam-Status: No, score=-9.816 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEg+s0Yw4r1W for ; Wed, 29 May 2013 09:41:02 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2FB21F8FF3 for ; Wed, 29 May 2013 09:41:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4TGewR8025078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 18:40:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4TGewPB012701; Wed, 29 May 2013 18:40:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4TGett3022275; Wed, 29 May 2013 18:40:58 +0200 Message-ID: <51A62F97.8070802@gmail.com> Date: Wed, 29 May 2013 18:40:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "cb.list6" References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:41:07 -0000 Le 29/05/2013 18:14, cb.list6 a �crit : > On Wed, May 29, 2013 at 2:29 AM, Lorenzo Colitti wrote: >> On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu >> wrote: >>> >>> I dont think a Router must have a globally scoped unicast address always. >>> >>> I think one goes too far in interpreting that as being a strong >>> requirement. >>> >>> I think this neglects what is already happening with many specs at IETF, >>> at various maturity levels, and which dont assume every other RFC out there >>> is a must. >> >> > > > I agree, it is not OK to break PMTU I am happy somebody agrees with me, and I must say I smile :-) > I will remove scenario 1. Yet I dont understand what's going on. Breaking PMTUd (Path MTU Discovery) on UE IPv6 Router happens if that Router did receive some larger-than-1280 packets on the cellular interface and its WiFi were 1280. I havent seen such packets. Maybe they exist, maybe not. One could go get some more operational experience, or someone else could try it if not done already. Or one would look at the specs: RFC1981 PMTUv6 "As discussed in section 1, IPv6 nodes are not required to implement Path MTU Discovery. The requirements in this section apply only to those implementations that include Path MTU Discovery." RFC6434 IPv6 Node Requirements about PMTUd: "5.6. Path MTU Discovery and Packet Size 5.6.1. Path MTU Discovery - RFC 1981 "Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported." It's a SHOULD not a MUST. " From [RFC2460]: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery." ... sending packets no larger than 1280 and omit PMTUd... 'break PMTU' - means to me to have a link in the middle that is lower MTU than 1280. That is ok to break, because PMTUd will signal it and that's it. (as DAD signals duplicates and that's it). 'break PMTUd' - means to me to eliminate the PMTUd(iscovery) functionality from some node. That is ok to break as well, because it is not mandatory. Alex > > CB > >> I think that "routers forwarding packets to and from global addresses should >> have global addresses" is pretty clearly a must-have because it's the only >> way to implement various non-optional parts of ICMPv6 in a way that works. >> >> But even if you disagree that it's a must, it's at least operational good >> practice, and I think we need a better reason to recommend violating this >> operational good practice than "we want to allow implementations not to >> implement DAD". >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From marka@isc.org Wed May 29 15:21:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B6621F8CA5 for ; Wed, 29 May 2013 15:21:24 -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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tLi55yBnVl7 for ; Wed, 29 May 2013 15:21:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9347C21F8FDD for ; Wed, 29 May 2013 15:21:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4AADD5F98F2; Wed, 29 May 2013 22:21:13 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369866081; bh=njYeE3ZKNmIzX2FOsYCC9Ls4mt9GOW/iaqZGZuuwNzE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=vHGFCDgCl58+pl5LqwHZPNsM7i+c8vhtBQpj2nW4KHMGFHKpcu7uqJ+D/W142eZa5 yT6olh8mg5jIn6mLNM8jSF5a7XGJo5z2JqVaHnFcS4WXHOMvytxxbGT+FbjuXxhRPr aT0sWkn5KVgsGM2q0KePg3kjEATNOI2wBo3UkbMY= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4d9f:af8e:ad79:c073]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 66F9D216C40; Wed, 29 May 2013 22:21:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6272E34DC1B2; Thu, 30 May 2013 08:21:09 +1000 (EST) To: Alexandru Petrescu From: Mark Andrews References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A62F97.8070802@gmail.com> In-reply-to: Your message of "Wed, 29 May 2013 18:40:55 +0200." <51A62F97.8070802@gmail.com> Date: Thu, 30 May 2013 08:21:09 +1000 Message-Id: <20130529222109.6272E34DC1B2@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:21:24 -0000 It's not just PMTUD. It's any ICMPv6 message. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owen@delong.com Wed May 29 16:04:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B4A21F96D2; Wed, 29 May 2013 16:04:03 -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_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pswECC7jYog; Wed, 29 May 2013 16:04:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1357A21F9677; Wed, 29 May 2013 16:04:01 -0700 (PDT) Received: from [172.19.131.173] ([199.108.68.10]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4TN2NdX003797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 May 2013 16:02:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4TN2NdX003797 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369868560; bh=JreFYMlSPem26IEHEOTWatzqEQA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yVndiO/26qw3isrewtwAonZbdSKi6Y8G8fI+JCPpVu6dEs0PFiC2ykvss3+fTSOQY tRY2bJlGPpyQHRlGpq5h3gNYFDP3mEURVdT2NemomjfzHcGjZqcIKtTUEiD93M3pnY fXm3hEIJMkfPMyYu/PAb1gl+N9kvr7brkig3MMgk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> Date: Wed, 29 May 2013 16:02:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 29 May 2013 16:02:40 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 23:04:03 -0000 Personally, I think this is an inherently bad idea. IP addresses need less overloading of semantics, not more. We already use IP addresses for two conflicting purposes=85 Topology = locator and End System Identifier. This overloading is at the heart of our current scaling issues with = respect to the routing table. While these issues are currently less = critical than they have been in the past and will likely get quite a bit = less critical in IPv6, that is only because we have given up a fair = amount of functionality to preserve scalability in this regard. If we did not have this overloading, then an entity could obtain a set = of end-system identifiers and keep them throughout their lifetime, = regardless of topological changes. Today, where the addresses are = overloaded with both semantics, we either have to force most entities to = change their numbers when they change topology or we face unsustainable = growth in the routing tables. The idea of adding more semantics to addressing rather than seeking to = reduce this overloading seems a step in the wrong direction, IMHO. Owen On May 29, 2013, at 12:06 AM, Sheng Jiang wrote: > IP addresses are designed as topology locator, so that every packet = can be routed to its network destination. >=20 > However, even in IPv4 era, some network operators have mapped their IP = address with certain semantic locally. These kind of mechanism = explicitly express the semantic properties of every packet. = Consequently, these network operators can inspect the properties of = packets easily by mapping the addresses back to semantic. >=20 > Network operators, who have large IPv6 address space, may also choose = to embedded some semantics into IPv6 addresses by assigning additional = significance to specific bits within the prefix. = draft-jiang-v6ops-semantic-prefix documents a framework method that = network operations may use their addresses with embedded semantics. = These semantics bits are only meaningful within a single network, or = group of interconnected networks which share a common addressing policy. = Based on these embedded semantic bits in source/destination addresses, = the network operators can accordingly treat network packets differently = and efficiently. >=20 > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >=20 > Could you please review this draft and comments? It will help the = document become more useful information to be shared. >=20 > Best regards, >=20 > Sheng >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, May 28, 2013 10:28 AM >> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang >> Subject: New Version Notification for >> draft-jiang-v6ops-semantic-prefix-03.txt >>=20 >>=20 >> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt >> has been successfully submitted by Sheng Jiang and posted to the >> IETF repository. >>=20 >> Filename: draft-jiang-v6ops-semantic-prefix >> Revision: 03 >> Title: A Framework for Semantic IPv6 Prefix >> Creation date: 2013-05-28 >> Group: Individual Submission >> Number of pages: 19 >> URL: >> = http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.t= xt >> Status: >> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix >> Htmlized: >> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-v6ops-semantic-prefix-03= >>=20 >> Abstract: >> This document describes a framework method that network operations >> may use their addresses. Network operators, who have large IPv6 >> address space, may choose to embedded some semantics into IPv6 >> addresses by assigning additional significance to specific bits >> within the prefix. By embedded semantics into IPv6 prefixes, the >> semantics of packets can be inspected easily. Routers and other >> intermediary devices can easily apply relevant policies as required. >> Packet-level differentiation can also enable flow-level and user- >> level differentiation. Consequently, the network operators can >> accordingly treat network packets differently and efficiently. The >> management and maintenance of networks can be much simpler. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Wed May 29 16:38:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B243C21F93BF for ; Wed, 29 May 2013 16:38:54 -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_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpbB-3FzVigm for ; Wed, 29 May 2013 16:38:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A521F93B7 for ; Wed, 29 May 2013 16:38:53 -0700 (PDT) Received: from [172.19.131.173] ([199.108.68.10]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4TNYXnA006614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 May 2013 16:34:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4TNYXnA006614 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369870498; bh=HAvs5HATNlrwgb2J6DjPBdS3Uf0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=5ci9mR1P4O4QvCGwuVO8DNdyukHbKqC3Qbg350GFv6riXmTLt6MzoAWi0segAPajK uROeEN54YnRPTgmHDupC82mV9EJp7IDsIcmzlk+mvSfjtW1LqfqLaRZECRTGO6payv zG+yoKYZd7AQbjl2td4vxGFH24j6an5PfM/xSxLE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <51A62F97.8070802@gmail.com> Date: Wed, 29 May 2013 16:34:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A62F97.8070802@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 29 May 2013 16:34:58 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 23:38:54 -0000 Alex, An end-node which does not support PMTUd and only sends =E2=89=A41280 = octet datagrams is fine. A router which is not an end-node and does not have the ability to send = PTB notifications back, on the other hand, is an entirely different = creature. Since we are talking about a UE acting as a router in this case, we = cannot ignore the need for routers to implement PMTUd which means that = the router MUST have a global address from which it can source PTB = messages. Yes, it is possible for a UE to have a larger cellular MTU and a = downstream link which has a smaller MTU. Whether such exists in the wild = today or not, it is permitted in a variety of standards that already = exist and therefore must be considered in developing further standards = as it is a valid scenario. Owen On May 29, 2013, at 9:40 AM, Alexandru Petrescu = wrote: > Le 29/05/2013 18:14, cb.list6 a =C3=A9crit : >> On Wed, May 29, 2013 at 2:29 AM, Lorenzo Colitti = wrote: >>> On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu >>> wrote: >>>>=20 >>>> I dont think a Router must have a globally scoped unicast address = always. >>>>=20 >>>> I think one goes too far in interpreting that as being a strong >>>> requirement. >>>>=20 >>>> I think this neglects what is already happening with many specs at = IETF, >>>> at various maturity levels, and which dont assume every other RFC = out there >>>> is a must. >>>=20 >>>=20 >>=20 >>=20 >> I agree, it is not OK to break PMTU >=20 > I am happy somebody agrees with me, and I must say I smile :-) >=20 >> I will remove scenario 1. >=20 > Yet I dont understand what's going on. >=20 > Breaking PMTUd (Path MTU Discovery) on UE IPv6 Router happens if that = Router did receive some larger-than-1280 packets on the cellular = interface and its WiFi were 1280. I havent seen such packets. Maybe = they exist, maybe not. >=20 > One could go get some more operational experience, or someone else = could try it if not done already. >=20 > Or one would look at the specs: >=20 > RFC1981 PMTUv6 "As discussed in section 1, IPv6 nodes are not required = to implement Path MTU Discovery. The requirements in this section apply = only to those implementations that include Path MTU Discovery." >=20 > RFC6434 IPv6 Node Requirements about PMTUd: > "5.6. Path MTU Discovery and Packet Size > 5.6.1. Path MTU Discovery - RFC 1981 > "Path MTU Discovery for IP version 6" [RFC1981] SHOULD be = supported." >=20 > It's a SHOULD not a MUST. >=20 > " =46rom [RFC2460]: >=20 > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC1981], in order to discover and take advantage of > path MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself = to > sending packets no larger than 1280 octets, and omit > implementation of Path MTU Discovery." >=20 > ... sending packets no larger than 1280 and omit PMTUd... >=20 > 'break PMTU' - means to me to have a link in the middle that is lower = MTU than 1280. That is ok to break, because PMTUd will signal it and = that's it. (as DAD signals duplicates and that's it). >=20 > 'break PMTUd' - means to me to eliminate the PMTUd(iscovery) = functionality from some node. That is ok to break as well, because it = is not mandatory. >=20 > Alex >=20 >>=20 >> CB >>=20 >>> I think that "routers forwarding packets to and from global = addresses should >>> have global addresses" is pretty clearly a must-have because it's = the only >>> way to implement various non-optional parts of ICMPv6 in a way that = works. >>>=20 >>> But even if you disagree that it's a must, it's at least operational = good >>> practice, and I think we need a better reason to recommend violating = this >>> operational good practice than "we want to allow implementations not = to >>> implement DAD". >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Wed May 29 22:06:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25ED21F8EC2 for ; Wed, 29 May 2013 22:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZut+je66hPF for ; Wed, 29 May 2013 22:06:31 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id EFD8221F8956 for ; Wed, 29 May 2013 22:06:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r4U56Se6004267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 May 2013 07:06:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r4U56SE3004489; Thu, 30 May 2013 07:06:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.5]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r4U56OMt017820; Thu, 30 May 2013 07:06:28 +0200 Message-ID: <51A6DE4F.5040708@gmail.com> Date: Thu, 30 May 2013 07:06:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mark Andrews References: <20130517185457.27784.24568.idtracker@ietfa.amsl.com> <51A4C91E.7000504@gmail.com> <51A5982D.8010204@gmail.com> <51A5C88B.1020903@gmail.com> <51A62F97.8070802@gmail.com> <20130529222109.6272E34DC1B2@drugs.dv.isc.org> In-Reply-To: <20130529222109.6272E34DC1B2@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 05:06:37 -0000 Le 30/05/2013 00:21, Mark Andrews a �crit : > > It's not just PMTUD. It's any ICMPv6 message. Put that way I tend to agree. But one would need to look at the detail of all such messages. Or only the ICMPv6 messages in RFC4443 ICMPv6? I mean: ok for EchoReq, ParameterProblem, TimeExceeded. However, DestUnreachable I dont think is valid. This Gateway thinks there is a single address to the link, not the entire set of addresses. As such it would be not quite good to say that a Dest is unreachable since the Gateway didnt pretend to either, or did it. The many other ICMPv6 messages in other RFCs: eg Redirect of ND, or the ICMPv6 RPL control message, or the DHAAD. I doubt they're all supported or needed. But yes, I tend to agree that many ICMPv6 messages may need that GUA and is good. Alex > From jiangsheng@huawei.com Wed May 29 23:34:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755D721F9473; Wed, 29 May 2013 23:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujQ4Ee0T7to7; Wed, 29 May 2013 23:34:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8059721F9485; Wed, 29 May 2013 23:34:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH76785; Thu, 30 May 2013 06:34:44 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 07:34:10 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 14:34:43 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 30 May 2013 14:34:38 +0800 From: Sheng Jiang To: Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAEA7rA= Date: Thu, 30 May 2013 06:34:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9924F@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> In-Reply-To: <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:34:52 -0000 SGksIE93ZW4sDQoNClRoZXNlIGVtYmVkZGVkIHNlbWFudGljcyBhcmUgdmVyeSBkaWZmZXJlbnQg ZnJvbSBFbmQgU3lzdGVtIElkZW50aWZpZXIuIFRoZSBlbmQgc3lzdGVtIGlkZW50aWZpZXIgZnVu Y3Rpb25zIHdhcyBwcm9ibGVtIGJlY2F1c2UgaXQgdmlvbGVudHMgdGhlIGxheWVyIG1vZGVsLiBN YW55IEFQUHMgb3IgdHJhbnNwb3J0IGxheWVyIHVzZSBJUCBhZGRyZXNzIGFzIHRoZWlyIGlkZW50 aWZpZXIuIEFuZCB0aGUgZW5kIHN5c3RlbSBpZGVudGlmaWVyIGJyZWFrcyBpbiBhdCBsZWFzdCB0 d28gc2NlbmFyaW9zOiB3aGVuIGVuZCBkZXZpY2VzIGNoYW5nZSB0aGUgYWNjZXNzIHBvaW50cyBv ciB3aGVuIElQIGxheWVyIHRyYW5zbGF0aW9uIChOQVQ0NCBvciBOQVQ2NCkgaGFwcGVucy4NCg0K VGhlIHByb3Bvc2VkIGVtYmVkZGVkIHNlbWFudGljcyBpcyBzdGlsbCBsYXllciAzLiBUaGV5IGFy ZSB1c2VkIGZvciByb3V0ZXIncyBwYWNrZXQgcHJvY2Vzc2luZy4gVGhlc2UgZW1iZWRkZWQgc2Vt YW50aWNzIGlzIG9ubHkgbWVhbmluZ2Z1bCBsb2NhbGx5IHdpdGhpbiBJU1Agb3duZXIgbmV0d29y ay4gQWZ0ZXIgbGVhdmluZyB0aGUgSVNQIG5ldHdvcmssIElQIGFkZHJlc3NlcyBhcmUgb25seSBs b2NhdG9yLCBub3RoaW5nIG1vcmUuIFRoZSBib3R0b20gbGluZSBpcyBhIG5ldHdvcmsgb3BlcmF0 b3IgY2FuIGNob29zZSB0byBlbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYgYWRkcmVz c2VzIGFzc2lnbm1lbnQuIFdlLCBhcyBJRVRGLCBtYXkgbm90IGVuY291cmFnZSBzdWNoIHVzYWdl LCBidXQgc2hvdWxkIGRvY3VtZW50IGl0IGFuZCBtYXkgZ2l2ZSBzb21lIGd1aWRhbmNlIG9yIGFu YWx5c2lzIG9mIGl0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IE93ZW4gRGVMb25nIFttYWlsdG86b3dlbkBkZWxvbmcuY29t XQ0KPlNlbnQ6IFRodXJzZGF5LCBNYXkgMzAsIDIwMTMgNzowMiBBTQ0KPlRvOiBTaGVuZyBKaWFu Zw0KPkNjOiA8djZvcHNAaWV0Zi5vcmc+OyBpcHY2QGlldGYub3JnOw0KPmRyYWZ0LWppYW5nLXY2 b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbdjZvcHNd IENvdWxkIElQdjYgYWRkcmVzcyBiZSBtb3JlIHRoYW4NCj5sb2NhdG9yPy8vZHJhZnQtamlhbmct djZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+DQo+UGVyc29uYWxseSwgSSB0aGluayB0aGlzIGlz IGFuIGluaGVyZW50bHkgYmFkIGlkZWEuDQo+DQo+SVAgYWRkcmVzc2VzIG5lZWQgbGVzcyBvdmVy bG9hZGluZyBvZiBzZW1hbnRpY3MsIG5vdCBtb3JlLg0KPg0KPldlIGFscmVhZHkgdXNlIElQIGFk ZHJlc3NlcyBmb3IgdHdvIGNvbmZsaWN0aW5nIHB1cnBvc2Vz4oCmIFRvcG9sb2d5IGxvY2F0b3IN Cj5hbmQgRW5kIFN5c3RlbSBJZGVudGlmaWVyLg0KPg0KPlRoaXMgb3ZlcmxvYWRpbmcgaXMgYXQg dGhlIGhlYXJ0IG9mIG91ciBjdXJyZW50IHNjYWxpbmcgaXNzdWVzIHdpdGggcmVzcGVjdCB0bw0K PnRoZSByb3V0aW5nIHRhYmxlLiBXaGlsZSB0aGVzZSBpc3N1ZXMgYXJlIGN1cnJlbnRseSBsZXNz IGNyaXRpY2FsIHRoYW4gdGhleSBoYXZlDQo+YmVlbiBpbiB0aGUgcGFzdCBhbmQgd2lsbCBsaWtl bHkgZ2V0IHF1aXRlIGEgYml0IGxlc3MgY3JpdGljYWwgaW4gSVB2NiwgdGhhdCBpcyBvbmx5DQo+ YmVjYXVzZSB3ZSBoYXZlIGdpdmVuIHVwIGEgZmFpciBhbW91bnQgb2YgZnVuY3Rpb25hbGl0eSB0 byBwcmVzZXJ2ZQ0KPnNjYWxhYmlsaXR5IGluIHRoaXMgcmVnYXJkLg0KPg0KPklmIHdlIGRpZCBu b3QgaGF2ZSB0aGlzIG92ZXJsb2FkaW5nLCB0aGVuIGFuIGVudGl0eSBjb3VsZCBvYnRhaW4gYSBz ZXQgb2YNCj5lbmQtc3lzdGVtIGlkZW50aWZpZXJzIGFuZCBrZWVwIHRoZW0gdGhyb3VnaG91dCB0 aGVpciBsaWZldGltZSwgcmVnYXJkbGVzcyBvZg0KPnRvcG9sb2dpY2FsIGNoYW5nZXMuIFRvZGF5 LCB3aGVyZSB0aGUgYWRkcmVzc2VzIGFyZSBvdmVybG9hZGVkIHdpdGggYm90aA0KPnNlbWFudGlj cywgd2UgZWl0aGVyIGhhdmUgdG8gZm9yY2UgbW9zdCBlbnRpdGllcyB0byBjaGFuZ2UgdGhlaXIg bnVtYmVycw0KPndoZW4gdGhleSBjaGFuZ2UgdG9wb2xvZ3kgb3Igd2UgZmFjZSB1bnN1c3RhaW5h YmxlIGdyb3d0aCBpbiB0aGUgcm91dGluZw0KPnRhYmxlcy4NCj4NCj5UaGUgaWRlYSBvZiBhZGRp bmcgbW9yZSBzZW1hbnRpY3MgdG8gYWRkcmVzc2luZyByYXRoZXIgdGhhbiBzZWVraW5nIHRvDQo+ cmVkdWNlIHRoaXMgb3ZlcmxvYWRpbmcgc2VlbXMgYSBzdGVwIGluIHRoZSB3cm9uZyBkaXJlY3Rp b24sIElNSE8uDQo+DQo+T3dlbg0KPg0KPk9uIE1heSAyOSwgMjAxMywgYXQgMTI6MDYgQU0sIFNo ZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+DQo+d3JvdGU6DQo+DQo+PiBJUCBhZGRy ZXNzZXMgYXJlIGRlc2lnbmVkIGFzIHRvcG9sb2d5IGxvY2F0b3IsIHNvIHRoYXQgZXZlcnkgcGFj a2V0IGNhbiBiZQ0KPnJvdXRlZCB0byBpdHMgbmV0d29yayBkZXN0aW5hdGlvbi4NCj4+DQo+PiBI b3dldmVyLCBldmVuIGluIElQdjQgZXJhLCBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFw cGVkIHRoZWlyIElQDQo+YWRkcmVzcyB3aXRoIGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhl c2Uga2luZCBvZiBtZWNoYW5pc20gZXhwbGljaXRseQ0KPmV4cHJlc3MgdGhlIHNlbWFudGljIHBy b3BlcnRpZXMgb2YgZXZlcnkgcGFja2V0LiBDb25zZXF1ZW50bHksIHRoZXNlIG5ldHdvcmsNCj5v cGVyYXRvcnMgY2FuIGluc3BlY3QgdGhlIHByb3BlcnRpZXMgb2YgcGFja2V0cyBlYXNpbHkgYnkg bWFwcGluZyB0aGUNCj5hZGRyZXNzZXMgYmFjayB0byBzZW1hbnRpYy4NCj4+DQo+PiBOZXR3b3Jr IG9wZXJhdG9ycywgd2hvIGhhdmUgbGFyZ2UgSVB2NiBhZGRyZXNzIHNwYWNlLCBtYXkgYWxzbyBj aG9vc2UgdG8NCj5lbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYgYWRkcmVzc2VzIGJ5 IGFzc2lnbmluZyBhZGRpdGlvbmFsDQo+c2lnbmlmaWNhbmNlIHRvIHNwZWNpZmljIGJpdHMgd2l0 aGluIHRoZSBwcmVmaXguDQo+ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4IGRvY3Vt ZW50cyBhIGZyYW1ld29yayBtZXRob2QgdGhhdA0KPm5ldHdvcmsgb3BlcmF0aW9ucyBtYXkgdXNl IHRoZWlyIGFkZHJlc3NlcyB3aXRoIGVtYmVkZGVkIHNlbWFudGljcy4gVGhlc2UNCj5zZW1hbnRp Y3MgYml0cyBhcmUgb25seSBtZWFuaW5nZnVsIHdpdGhpbiBhIHNpbmdsZSBuZXR3b3JrLCBvciBn cm91cCBvZg0KPmludGVyY29ubmVjdGVkIG5ldHdvcmtzIHdoaWNoIHNoYXJlIGEgY29tbW9uIGFk ZHJlc3NpbmcgcG9saWN5LiBCYXNlZCBvbg0KPnRoZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMg aW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3NlcywgdGhlIG5ldHdvcmsNCj5vcGVyYXRvcnMg Y2FuIGFjY29yZGluZ2x5IHRyZWF0IG5ldHdvcmsgcGFja2V0cyBkaWZmZXJlbnRseSBhbmQgZWZm aWNpZW50bHkuDQo+Pg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmct djZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pg0KPj4gQ291bGQgeW91IHBsZWFzZSByZXZpZXcg dGhpcyBkcmFmdCBhbmQgY29tbWVudHM/IEl0IHdpbGwgaGVscCB0aGUgZG9jdW1lbnQNCj5iZWNv bWUgbW9yZSB1c2VmdWwgaW5mb3JtYXRpb24gdG8gYmUgc2hhcmVkLg0KPj4NCj4+IEJlc3QgcmVn YXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4+PiBTZW50OiBUdWVzZGF5LCBNYXkgMjgsIDIwMTMgMTA6MjggQU0NCj4+ PiBUbzogUWlvbmcgU3VuOyBJYW4gRmFycmVyOyBTaGVuZyBKaWFuZzsgQm95YW5nDQo+Pj4gU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4+IGRyYWZ0LWppYW5nLXY2b3Bz LXNlbWFudGljLXByZWZpeC0wMy50eHQNCj4+Pg0KPj4+DQo+Pj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMy50eHQNCj4+PiBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhl DQo+Pj4gSUVURiByZXBvc2l0b3J5Lg0KPj4+DQo+Pj4gRmlsZW5hbWU6CSBkcmFmdC1qaWFuZy12 Nm9wcy1zZW1hbnRpYy1wcmVmaXgNCj4+PiBSZXZpc2lvbjoJIDAzDQo+Pj4gVGl0bGU6CQkgQSBG cmFtZXdvcmsgZm9yIFNlbWFudGljIElQdjYgUHJlZml4DQo+Pj4gQ3JlYXRpb24gZGF0ZToJIDIw MTMtMDUtMjgNCj4+PiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+PiBOdW1iZXIg b2YgcGFnZXM6IDE5DQo+Pj4gVVJMOg0KPj4+DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzLnR4dA0KPj4+IFN0 YXR1czoNCj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppYW5nLXY2 b3BzLXNlbWFudGljLXByZWZpeA0KPj4+IEh0bWxpemVkOg0KPj4+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMw0KPj4+IERpZmY6 DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamlhbmctdjZvcHMt c2VtYW50aWMtcHJlZml4LTAzDQo+Pj4NCj4+PiBBYnN0cmFjdDoNCj4+PiAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgbWV0aG9kIHRoYXQgbmV0d29yayBvcGVyYXRpb25zDQo+ Pj4gIG1heSB1c2UgdGhlaXIgYWRkcmVzc2VzLiAgTmV0d29yayBvcGVyYXRvcnMsIHdobyBoYXZl IGxhcmdlIElQdjYNCj4+PiAgYWRkcmVzcyBzcGFjZSwgbWF5IGNob29zZSB0byBlbWJlZGRlZCBz b21lIHNlbWFudGljcyBpbnRvIElQdjYNCj4+PiAgYWRkcmVzc2VzIGJ5IGFzc2lnbmluZyBhZGRp dGlvbmFsIHNpZ25pZmljYW5jZSB0byBzcGVjaWZpYyBiaXRzDQo+Pj4gIHdpdGhpbiB0aGUgcHJl Zml4LiAgQnkgZW1iZWRkZWQgc2VtYW50aWNzIGludG8gSVB2NiBwcmVmaXhlcywgdGhlDQo+Pj4g IHNlbWFudGljcyBvZiBwYWNrZXRzIGNhbiBiZSBpbnNwZWN0ZWQgZWFzaWx5LiAgUm91dGVycyBh bmQgb3RoZXINCj4+PiAgaW50ZXJtZWRpYXJ5IGRldmljZXMgY2FuIGVhc2lseSBhcHBseSByZWxl dmFudCBwb2xpY2llcyBhcyByZXF1aXJlZC4NCj4+PiAgUGFja2V0LWxldmVsIGRpZmZlcmVudGlh dGlvbiBjYW4gYWxzbyBlbmFibGUgZmxvdy1sZXZlbCBhbmQgdXNlci0NCj4+PiAgbGV2ZWwgZGlm ZmVyZW50aWF0aW9uLiAgQ29uc2VxdWVudGx5LCB0aGUgbmV0d29yayBvcGVyYXRvcnMgY2FuDQo+ Pj4gIGFjY29yZGluZ2x5IHRyZWF0IG5ldHdvcmsgcGFja2V0cyBkaWZmZXJlbnRseSBhbmQgZWZm aWNpZW50bHkuICBUaGUNCj4+PiAgbWFuYWdlbWVudCBhbmQgbWFpbnRlbmFuY2Ugb2YgbmV0d29y a3MgY2FuIGJlIG11Y2ggc2ltcGxlci4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFRoZSBJRVRG IFNlY3JldGFyaWF0DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From tjc@ecs.soton.ac.uk Wed May 29 23:40:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB37B21F9485; Wed, 29 May 2013 23:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjJ4ATH9+k6V; Wed, 29 May 2013 23:40:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id B819C21F940D; Wed, 29 May 2013 23:40:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4U6YePM004727; Thu, 30 May 2013 07:34:40 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4U6YePM004727 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369895681; bh=WGxpwHSirCteWOy01LYNFQrGRKE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=Wl5PPwrbrsiAfVkXWKgHF1eb7b6Ee5ebHITX2X/BQCSwHyc/6qlDF+RIYabRv4feO l8tXK1CF2zqDkn8WI/SgOW3zx1uBZX8N7UgFoUFoBv/UiAFj3FfkAqUNLpUzmHqAl7 HwY75X4m2h9JYO4JlZi0/vDgTdMzyZ/erMeEA3DM= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p4Y7Ye0430616311ed ret-id none; Thu, 30 May 2013 07:34:41 +0100 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4U6XFXP017497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 May 2013 07:33:16 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> Date: Thu, 30 May 2013 07:33:18 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> To: Owen DeLong X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4Y7Ye043061631100; tid=p4Y7Ye0430616311ed; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4U6YePM004727 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:40:28 -0000 On 30 May 2013, at 00:02, Owen DeLong wrote: > Personally, I think this is an inherently bad idea. >=20 > IP addresses need less overloading of semantics, not more. >=20 > We already use IP addresses for two conflicting purposes=85 Topology = locator and End System Identifier. >=20 > This overloading is at the heart of our current scaling issues with = respect to the routing table. While these issues are currently less = critical than they have been in the past and will likely get quite a bit = less critical in IPv6, that is only because we have given up a fair = amount of functionality to preserve scalability in this regard. >=20 > If we did not have this overloading, then an entity could obtain a set = of end-system identifiers and keep them throughout their lifetime, = regardless of topological changes. Today, where the addresses are = overloaded with both semantics, we either have to force most entities to = change their numbers when they change topology or we face unsustainable = growth in the routing tables. >=20 > The idea of adding more semantics to addressing rather than seeking to = reduce this overloading seems a step in the wrong direction, IMHO. I agree. That said, an ISP, enterprise or group of organisations can = follow whatever semantics they wish within their own borders. Just don't = expect anyone else to follow or use those semantics. What Sheng is = proposing is clearly stated as only being for interpretation between = agreeing organisations. There are examples of organisations or protocols already doing this, be = it embedding VLAN IDs or port number representations in addresses. And = of protocols - in particular 6rd comes to mind as an example of an IPv6 = addressing scheme with embedded semantics, which only has meaning within = one ISP. It's not that different to DSCP semantics, which for example have been = widely applied across academic networks, except of course the DSCP can = be rewritten in transit. Whether someone outside the organisation can = infer "private" information from the semantics may be an open question. I think people will do this type of thing, so an Informational document = discussing the pros and cons, and how semantics can be used, is probably = a good thing. Perhaps a "Potential Pitfalls" type section after the = "Potential Benefits" section would balance the document a little better? Tim > Owen >=20 > On May 29, 2013, at 12:06 AM, Sheng Jiang = wrote: >=20 >> IP addresses are designed as topology locator, so that every packet = can be routed to its network destination. >>=20 >> However, even in IPv4 era, some network operators have mapped their = IP address with certain semantic locally. These kind of mechanism = explicitly express the semantic properties of every packet. = Consequently, these network operators can inspect the properties of = packets easily by mapping the addresses back to semantic. >>=20 >> Network operators, who have large IPv6 address space, may also choose = to embedded some semantics into IPv6 addresses by assigning additional = significance to specific bits within the prefix. = draft-jiang-v6ops-semantic-prefix documents a framework method that = network operations may use their addresses with embedded semantics. = These semantics bits are only meaningful within a single network, or = group of interconnected networks which share a common addressing policy. = Based on these embedded semantic bits in source/destination addresses, = the network operators can accordingly treat network packets differently = and efficiently. >>=20 >> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>=20 >> Could you please review this draft and comments? It will help the = document become more useful information to be shared. >>=20 >> Best regards, >>=20 >> Sheng >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, May 28, 2013 10:28 AM >>> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang >>> Subject: New Version Notification for >>> draft-jiang-v6ops-semantic-prefix-03.txt >>>=20 >>>=20 >>> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt >>> has been successfully submitted by Sheng Jiang and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-jiang-v6ops-semantic-prefix >>> Revision: 03 >>> Title: A Framework for Semantic IPv6 Prefix >>> Creation date: 2013-05-28 >>> Group: Individual Submission >>> Number of pages: 19 >>> URL: >>> = http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.t= xt >>> Status: >>> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix >>> Htmlized: >>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>> Diff: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-v6ops-semantic-prefix-03 >>>=20 >>> Abstract: >>> This document describes a framework method that network operations >>> may use their addresses. Network operators, who have large IPv6 >>> address space, may choose to embedded some semantics into IPv6 >>> addresses by assigning additional significance to specific bits >>> within the prefix. By embedded semantics into IPv6 prefixes, the >>> semantics of packets can be inspected easily. Routers and other >>> intermediary devices can easily apply relevant policies as required. >>> Packet-level differentiation can also enable flow-level and user- >>> level differentiation. Consequently, the network operators can >>> accordingly treat network packets differently and efficiently. The >>> management and maintenance of networks can be much simpler. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Wed May 29 23:41:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7FF21F8629 for ; Wed, 29 May 2013 23:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5YEFs8dd7bC for ; Wed, 29 May 2013 23:41:23 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFC721F8521 for ; Wed, 29 May 2013 23:41:23 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so5834734obb.19 for ; Wed, 29 May 2013 23:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=G9x6HlhCyHQpeR6VfixhaEKGcXps0KxObZ9BFhGKtlc=; b=e5nfHwESSabTWMNxc2f9EitNQa11mwjGJFCeikN0CiZI8s4q/DU2tT8fsw0K7Syr5V C8Ukc1pWtamYmGkv9Mg0xtE9NBNU+8RY2hpSsMGmigoj5pUuS3D5PwWoZIB3yWJOWcig DZrysxfd6AeFnJ/iZwXoB+dZk5sU4MLFzHWiq0YDgBe5QImI6VGzGx7C07/tqVAWqzFM jqZKo8H9i8d7pVbLrmoId5elPH4+vOHAUM2+L+MsvBcYEj7TUobsTFi1c79kheN/3MW0 W8NJ3QLs96uCLQ3IafMsppQVCeV7oSqsqcaMOpeWfzyQRpnpFa71NQAayiGLpQMRUgml 70qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=G9x6HlhCyHQpeR6VfixhaEKGcXps0KxObZ9BFhGKtlc=; b=A8wa/0gmhokjybm/mWioKo2OhklfH8xH/wULCMGMX2sQWN3RWpXTE2Sa250Npwo5NE AURUUQJWAIlyr73W5f5AZnXCu8YwrcHQ+f9/F3G/4UGljdrTIJpu4jDQykeripChQuEj YGkDtxVndv9G/xL3np+/TqpNBXvsVZzd2skRdhR96YAZ5UTgy2bESNoAuYuDHcSd5mMG QqSzwZ9EiSLCFQoRACcxT+NJ9RErshT5Xq7sgYkQbG3ox0b6o77B4gIztxNeWnFJ6u6Q u1tSo/6VkgU/P8bXhpquOLK0J2c6pH7Zi+acPcePzYtiWslAksJEg2ZnF+brNOZ7i7yd TRwQ== X-Received: by 10.182.108.132 with SMTP id hk4mr3640448obb.14.1369896082581; Wed, 29 May 2013 23:41:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.146.47 with HTTP; Wed, 29 May 2013 23:41:02 -0700 (PDT) From: Lorenzo Colitti Date: Thu, 30 May 2013 15:41:02 +0900 Message-ID: To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=089e0149d22061d2c804dde9c9b7 X-Gm-Message-State: ALoCoQkJ3U3VtMBMgPcmDbuA/Gk9UUN8KgnbxR9iDcFIt2i5muoTg0lmklGc4cto/cplxsc1nZ0dkNCKE6NEfl1W+Z8MisMeUlRwnidVPu4lGi9R4nD7uv280lyJI34P78tjinIm+5vSWuPrtr0XHJKwtu1WRZ3uvDXjKlQ6dXK9tBd9gPf+vXH49Y5EM5exAvvfS+06twS4 Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:41:23 -0000 --089e0149d22061d2c804dde9c9b7 Content-Type: text/plain; charset=ISO-8859-1 News at 11: 1. ULAs leak. 2. People assign ULAs by hand. Yes, both of these a violation of IETF guidance. I don't think that matters much, though - while we can always claim that the implementer/operator is "holding it wrong", we should be careful that what we design/standardize is hard to misconfigure and possibly robust in the face of misconfiguration. Subtle nuances like "these addresses are global scope, but not globally routable" tend to get lost very easily. Of course, in the case of ULAs, there's not much that can be done about the design at this point, but we should make an effort to make it clear that the potential for misconfiguration exists and provide clear guidance on how not to misconfigure them. Personally, I think that providing said guidance is much more useful and important than enumerating scenarios that aren't widely, if at all, implemented, and I hope that the authors of draft-ietf-v6ops-ula-usage-recommendations will agree. Cheers, Lorenzo ---------- Forwarded message ---------- From: Jeroen Massar Date: Thu, May 30, 2013 at 4:59 AM Subject: Usage of fd00::/8 on the Interwebz - something with filters and uRPF To: ipv6-ops@lists.cluenet.de ... 4 2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) 20.755 ms 20.763 ms 20.784 ms 5 fd00:3303::1 (fd00:3303::1) 22.010 ms 21.984 ms 21.986 ms 6 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 17.806 ms 17.889 ms 17.842 ms 7 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 18.720 ms 18.593 ms 18.617 ms ... Hmmmm fd00::/8, that really should never ever be visible on the Internet, being Unique *LOCAL* Addresses. And it does not look like they applied the randomness bit for picking a prefix either. You would also almost think that a /28 is more than enough address space to put a few router loopbacks in. It is apparently time for people to start checking their filters again because it seems that these packets leak into other ASNs too... More generally, do recheck your network for BCP38 compliance, please do apply it and require your peers to do the same! Greets, Jeroen --089e0149d22061d2c804dde9c9b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
News at 11:

1. ULAs leak.
2. People assign ULAs by hand.

Yes, both of these a violation of IETF guidanc= e. I don't think that matters much, though - while we can always claim = that the implementer/operator is "holding it wrong", we should be= careful that what we design/standardize is hard to misconfigure and possib= ly robust in the face of misconfiguration. Subtle nuances like "these = addresses are global scope, but not globally routable" tend to get los= t very easily.

Of course, in the case of ULAs, there's= not much that can be done about the design at this point, but we should ma= ke an effort to make it clear that the potential for misconfiguration exist= s and provide clear guidance on how not to misconfigure them.

Personally, I think that providing said gui= dance is much more useful and important than enumerating scenarios that are= n't widely, if at all, implemented, and I hope that the authors of=A0dr= aft-ietf-v6ops-ula-usage-recommendations will agree.

Cheers,
Lorenzo

---------- Forwarded message= ----------
From: Jeroen Massar <jeroen@massar.ch>= ;
Date: Thu, May 30, 2013 at 4:59 AM
Subject: Usage of fd00::/8 on the Int= erwebz - something with filters and uRPF
To: ipv6-ops@lists.cluenet.de

...
=A04 =A02001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) =A020.755 ms =A02= 0.763 ms =A020.784 ms
=A05 =A0fd00:3303::1 (fd00:3303::1) =A022.010 ms =A021.984 ms =A021.986 ms<= br> =A06 =A02a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) =A017.806 ms =A017.= 889 ms =A017.842 ms
=A07 =A02a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) =A018.720 ms =A018.= 593 ms =A018.617 ms
...

Hmmmm fd00::/8, that really should never ever be visible on the Internet, b= eing Unique *LOCAL* Addresses.
And it does not look like they applied the randomness bit for picking a pre= fix either.
You would also almost think that a /28 is more than enough address space to= put a few router loopbacks in.

It is apparently time for people to start checking their filters again beca= use it seems that these packets leak into other ASNs too...

More generally, do recheck your network for BCP38 compliance, please do app= ly it and require your peers to do the same!

Greets,
=A0Jeroen

--089e0149d22061d2c804dde9c9b7-- From jiangsheng@huawei.com Wed May 29 23:45:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1A21F9590; Wed, 29 May 2013 23:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XINh+ru8ZDwT; Wed, 29 May 2013 23:45:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F06A21F95F9; Wed, 29 May 2013 23:45:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH77537; Thu, 30 May 2013 06:45:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 07:44:40 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 14:45:13 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Thu, 30 May 2013 14:45:10 +0800 From: Sheng Jiang To: "Duncan, Richard (Jeremy)" , Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXNw0JNfUIpIfbEiqc0a18kokB5kdRjJg Date: Thu, 30 May 2013 06:45:09 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9927B@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com>, <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:45:30 -0000 SGksIER1bmNhbiwNCg0KQWN0dWFsbHksIHlvdSBxdWVzdGlvbiBpcyB2ZXJ5IGRldGFpbGVkIHNj ZW5hcmlvIGluIHRoZSBhcHByb2FjaC4gVGhlIGFuc3dlciBpcyB0aGUgcHJvdmlkZXIgc3RpbGwg YXNzaWduIGEgLzQ4IHRvIGFuIG9yZ2FuaXphdGlvbi4gQnV0IHdpdGhpbiB0aGUgYXNzaWduZWQg LzQ4LCBzb21lIGJpdCAoZm9yIGV4YW1wbGUsIGJpdCBuby4gMzB+MzIpIGhhcyBzb21lIHNlbWFu dGljIChmb3IgZXhhbXBsZSwgbmVlZCBleHRyYSBzZWN1cml0eSBwcm9jZXNzaW5nKSBmb3IgdGhl IGFzc2lnbmluZyBwcm92aWRlci4gVGhlbiwgd2hlbiB0aGUgcHJvdmlkZXIgcmVjZWl2ZWQgcGFj a2V0cyBmcm9tIHN1Y2ggb3JnYW5pemF0aW9ucyAodGhlcmUgYXJlIG11bHRpcGxlIGVudGVycHJp c2UgaGFzIHRoZSBzYW1lIHNlbWFudGljIGFuZCB0aGUgc2FtZSBiaXQgbm8uIDMwfjMyKSwgaXQg Y2FuIHRyZWF0IGFjY29yZGluZ2x5Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IER1bmNhbiwgUmljaGFyZCAoSmVyZW15KSBb bWFpbHRvOmplcmVteS5kdW5jYW5Ac2FsaWVudGZlZC5jb21dDQo+U2VudDogVGh1cnNkYXksIE1h eSAzMCwgMjAxMyAxMDoyMCBBTQ0KPlRvOiBPd2VuIERlTG9uZw0KPkNjOiBTaGVuZyBKaWFuZzsg PHY2b3BzQGlldGYub3JnPjsNCj5kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9v bHMuaWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBDb3VsZCBJ UHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuDQo+bG9jYXRvcj8vL2RyYWZ0LWppYW5nLXY2b3BzLXNl bWFudGljLXByZWZpeC0wMw0KPg0KPkkgdGVuZCB0byBhZ3JlZSB3aXRoIE93ZW4gaGVyZS4gIElu IGZhY3QsIEkgYW0gY3VyaW91cyBob3cgYW4gYWxsb2NhdGlvbg0KPmZyb20gYSBwcm92aWRlciB0 byBhIG9yZ2FuaXphdGlvbiB3b3VsZCBsb29rPyAgSW5zdGVhZCBvZiBmb2xsb3dpbmcgc3RhbmRh cmQNCj5pc3N1aW5nIHByYWN0aWNlcyBvZiBhIC80OCwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoZSBw cm92aWRlciB3b3VsZCBpc3N1ZQ0KPm11bHRpcGxlIC81MnMgdGhhdCBmb2xsb3cgZnVuY3Rpb25h bCBjYXRlZ29yaWVzIChWb0lQLCBtYW5hZ2VtZW50LCBldGMpPyAgT3INCj5tYXliZSBJIG1pc3Nl ZCBzb21ldGhpbmc/DQo+DQo+DQo+MDEwMTAwMTEwMTEwMDEwMTAxMTAxMTAxMDExMTAwMDAwMTEw MDEwMTAxMTEwMDEwMDAxMDAwMDAwMTAwMDExDQo+MDAxMTAxMDAxDQo+DQo+SmVyZW15IER1bmNh bg0KPlNlbmlvciBEaXJlY3RvciwgSVB2NiBOZXR3b3JrIEFyY2hpdGVjdA0KPlNhbGllbnQgRmVk ZXJhbCBTb2x1dGlvbnMsIEluYy4gKE5vdyBpbmNsdWRpbmcgU0dJUyAmIENvbW1hbmQgSW5mb3Jt YXRpb24NCj5JbmMuKQ0KPjQwMDAgTGVnYXRvIFJvYWQsIFN1aXRlIDYwMA0KPkZhaXJmYXgsIFZB IDIyMDMzDQo+R29vZ2xlIFZvaWNlOiA1NDAuNDQwLjExOTMNCj5qZXJlbXkuZHVuY2FuQHNhbGll bnRmZWQuY29tDQo+DQo+T3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4gd3JvdGU6DQo+DQo+ DQo+UGVyc29uYWxseSwgSSB0aGluayB0aGlzIGlzIGFuIGluaGVyZW50bHkgYmFkIGlkZWEuDQo+ DQo+SVAgYWRkcmVzc2VzIG5lZWQgbGVzcyBvdmVybG9hZGluZyBvZiBzZW1hbnRpY3MsIG5vdCBt b3JlLg0KPg0KPldlIGFscmVhZHkgdXNlIElQIGFkZHJlc3NlcyBmb3IgdHdvIGNvbmZsaWN0aW5n IHB1cnBvc2Vz4oCmIFRvcG9sb2d5IGxvY2F0b3INCj5hbmQgRW5kIFN5c3RlbSBJZGVudGlmaWVy Lg0KPg0KPlRoaXMgb3ZlcmxvYWRpbmcgaXMgYXQgdGhlIGhlYXJ0IG9mIG91ciBjdXJyZW50IHNj YWxpbmcgaXNzdWVzIHdpdGggcmVzcGVjdCB0bw0KPnRoZSByb3V0aW5nIHRhYmxlLiBXaGlsZSB0 aGVzZSBpc3N1ZXMgYXJlIGN1cnJlbnRseSBsZXNzIGNyaXRpY2FsIHRoYW4gdGhleSBoYXZlDQo+ YmVlbiBpbiB0aGUgcGFzdCBhbmQgd2lsbCBsaWtlbHkgZ2V0IHF1aXRlIGEgYml0IGxlc3MgY3Jp dGljYWwgaW4gSVB2NiwgdGhhdCBpcyBvbmx5DQo+YmVjYXVzZSB3ZSBoYXZlIGdpdmVuIHVwIGEg ZmFpciBhbW91bnQgb2YgZnVuY3Rpb25hbGl0eSB0byBwcmVzZXJ2ZQ0KPnNjYWxhYmlsaXR5IGlu IHRoaXMgcmVnYXJkLg0KPg0KPklmIHdlIGRpZCBub3QgaGF2ZSB0aGlzIG92ZXJsb2FkaW5nLCB0 aGVuIGFuIGVudGl0eSBjb3VsZCBvYnRhaW4gYSBzZXQgb2YNCj5lbmQtc3lzdGVtIGlkZW50aWZp ZXJzIGFuZCBrZWVwIHRoZW0gdGhyb3VnaG91dCB0aGVpciBsaWZldGltZSwgcmVnYXJkbGVzcyBv Zg0KPnRvcG9sb2dpY2FsIGNoYW5nZXMuIFRvZGF5LCB3aGVyZSB0aGUgYWRkcmVzc2VzIGFyZSBv dmVybG9hZGVkIHdpdGggYm90aA0KPnNlbWFudGljcywgd2UgZWl0aGVyIGhhdmUgdG8gZm9yY2Ug bW9zdCBlbnRpdGllcyB0byBjaGFuZ2UgdGhlaXIgbnVtYmVycw0KPndoZW4gdGhleSBjaGFuZ2Ug dG9wb2xvZ3kgb3Igd2UgZmFjZSB1bnN1c3RhaW5hYmxlIGdyb3d0aCBpbiB0aGUgcm91dGluZw0K PnRhYmxlcy4NCj4NCj5UaGUgaWRlYSBvZiBhZGRpbmcgbW9yZSBzZW1hbnRpY3MgdG8gYWRkcmVz c2luZyByYXRoZXIgdGhhbiBzZWVraW5nIHRvDQo+cmVkdWNlIHRoaXMgb3ZlcmxvYWRpbmcgc2Vl bXMgYSBzdGVwIGluIHRoZSB3cm9uZyBkaXJlY3Rpb24sIElNSE8uDQo+DQo+T3dlbg0KPg0KPk9u IE1heSAyOSwgMjAxMywgYXQgMTI6MDYgQU0sIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdl aS5jb20+DQo+d3JvdGU6DQo+DQo+PiBJUCBhZGRyZXNzZXMgYXJlIGRlc2lnbmVkIGFzIHRvcG9s b2d5IGxvY2F0b3IsIHNvIHRoYXQgZXZlcnkgcGFja2V0IGNhbiBiZQ0KPnJvdXRlZCB0byBpdHMg bmV0d29yayBkZXN0aW5hdGlvbi4NCj4+DQo+PiBIb3dldmVyLCBldmVuIGluIElQdjQgZXJhLCBz b21lIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFwcGVkIHRoZWlyIElQDQo+YWRkcmVzcyB3aXRo IGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhlc2Uga2luZCBvZiBtZWNoYW5pc20gZXhwbGlj aXRseQ0KPmV4cHJlc3MgdGhlIHNlbWFudGljIHByb3BlcnRpZXMgb2YgZXZlcnkgcGFja2V0LiBD b25zZXF1ZW50bHksIHRoZXNlIG5ldHdvcmsNCj5vcGVyYXRvcnMgY2FuIGluc3BlY3QgdGhlIHBy b3BlcnRpZXMgb2YgcGFja2V0cyBlYXNpbHkgYnkgbWFwcGluZyB0aGUNCj5hZGRyZXNzZXMgYmFj ayB0byBzZW1hbnRpYy4NCj4+DQo+PiBOZXR3b3JrIG9wZXJhdG9ycywgd2hvIGhhdmUgbGFyZ2Ug SVB2NiBhZGRyZXNzIHNwYWNlLCBtYXkgYWxzbyBjaG9vc2UgdG8NCj5lbWJlZGRlZCBzb21lIHNl bWFudGljcyBpbnRvIElQdjYgYWRkcmVzc2VzIGJ5IGFzc2lnbmluZyBhZGRpdGlvbmFsDQo+c2ln bmlmaWNhbmNlIHRvIHNwZWNpZmljIGJpdHMgd2l0aGluIHRoZSBwcmVmaXguDQo+ZHJhZnQtamlh bmctdjZvcHMtc2VtYW50aWMtcHJlZml4IGRvY3VtZW50cyBhIGZyYW1ld29yayBtZXRob2QgdGhh dA0KPm5ldHdvcmsgb3BlcmF0aW9ucyBtYXkgdXNlIHRoZWlyIGFkZHJlc3NlcyB3aXRoIGVtYmVk ZGVkIHNlbWFudGljcy4gVGhlc2UNCj5zZW1hbnRpY3MgYml0cyBhcmUgb25seSBtZWFuaW5nZnVs IHdpdGhpbiBhIHNpbmdsZSBuZXR3b3JrLCBvciBncm91cCBvZg0KPmludGVyY29ubmVjdGVkIG5l dHdvcmtzIHdoaWNoIHNoYXJlIGEgY29tbW9uIGFkZHJlc3NpbmcgcG9saWN5LiBCYXNlZCBvbg0K PnRoZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMgaW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJl c3NlcywgdGhlIG5ldHdvcmsNCj5vcGVyYXRvcnMgY2FuIGFjY29yZGluZ2x5IHRyZWF0IG5ldHdv cmsgcGFja2V0cyBkaWZmZXJlbnRseSBhbmQgZWZmaWNpZW50bHkuDQo+Pg0KPj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+ Pg0KPj4gQ291bGQgeW91IHBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCBhbmQgY29tbWVudHM/IEl0 IHdpbGwgaGVscCB0aGUgZG9jdW1lbnQNCj5iZWNvbWUgbW9yZSB1c2VmdWwgaW5mb3JtYXRpb24g dG8gYmUgc2hhcmVkLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+PiBTZW50OiBUdWVz ZGF5LCBNYXkgMjgsIDIwMTMgMTA6MjggQU0NCj4+PiBUbzogUWlvbmcgU3VuOyBJYW4gRmFycmVy OyBTaGVuZyBKaWFuZzsgQm95YW5nDQo+Pj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPj4+IGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMy50eHQNCj4+ Pg0KPj4+DQo+Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFu dGljLXByZWZpeC0wMy50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+Pj4gSUVURiByZXBvc2l0b3J5Lg0KPj4+ DQo+Pj4gRmlsZW5hbWU6ICAgICBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgNCj4+ PiBSZXZpc2lvbjogICAgIDAzDQo+Pj4gVGl0bGU6ICAgICAgICAgICAgICAgIEEgRnJhbWV3b3Jr IGZvciBTZW1hbnRpYyBJUHY2IFByZWZpeA0KPj4+IENyZWF0aW9uIGRhdGU6ICAgICAgICAyMDEz LTA1LTI4DQo+Pj4gR3JvdXA6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K Pj4+IE51bWJlciBvZiBwYWdlczogMTkNCj4+PiBVUkw6DQo+Pj4NCj5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMu dHh0DQo+Pj4gU3RhdHVzOg0KPj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4DQo+Pj4gSHRtbGl6ZWQ6DQo+Pj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAz DQo+Pj4gRGlmZjoNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1q aWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMNCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGZyYW1ld29yayBtZXRob2QgdGhhdCBuZXR3b3JrIG9w ZXJhdGlvbnMNCj4+PiAgbWF5IHVzZSB0aGVpciBhZGRyZXNzZXMuICBOZXR3b3JrIG9wZXJhdG9y cywgd2hvIGhhdmUgbGFyZ2UgSVB2Ng0KPj4+ICBhZGRyZXNzIHNwYWNlLCBtYXkgY2hvb3NlIHRv IGVtYmVkZGVkIHNvbWUgc2VtYW50aWNzIGludG8gSVB2Ng0KPj4+ICBhZGRyZXNzZXMgYnkgYXNz aWduaW5nIGFkZGl0aW9uYWwgc2lnbmlmaWNhbmNlIHRvIHNwZWNpZmljIGJpdHMNCj4+PiAgd2l0 aGluIHRoZSBwcmVmaXguICBCeSBlbWJlZGRlZCBzZW1hbnRpY3MgaW50byBJUHY2IHByZWZpeGVz LCB0aGUNCj4+PiAgc2VtYW50aWNzIG9mIHBhY2tldHMgY2FuIGJlIGluc3BlY3RlZCBlYXNpbHku ICBSb3V0ZXJzIGFuZCBvdGhlcg0KPj4+ICBpbnRlcm1lZGlhcnkgZGV2aWNlcyBjYW4gZWFzaWx5 IGFwcGx5IHJlbGV2YW50IHBvbGljaWVzIGFzIHJlcXVpcmVkLg0KPj4+ICBQYWNrZXQtbGV2ZWwg ZGlmZmVyZW50aWF0aW9uIGNhbiBhbHNvIGVuYWJsZSBmbG93LWxldmVsIGFuZCB1c2VyLQ0KPj4+ ICBsZXZlbCBkaWZmZXJlbnRpYXRpb24uICBDb25zZXF1ZW50bHksIHRoZSBuZXR3b3JrIG9wZXJh dG9ycyBjYW4NCj4+PiAgYWNjb3JkaW5nbHkgdHJlYXQgbmV0d29yayBwYWNrZXRzIGRpZmZlcmVu dGx5IGFuZCBlZmZpY2llbnRseS4gIFRoZQ0KPj4+ICBtYW5hZ2VtZW50IGFuZCBtYWludGVuYW5j ZSBvZiBuZXR3b3JrcyBjYW4gYmUgbXVjaCBzaW1wbGVyLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+ Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiB2Nm9wc0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K Pg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ aXB2NkBpZXRmLm9yZw0KPkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KDQo= From lorenzo@google.com Wed May 29 23:47:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA321F9552 for ; Wed, 29 May 2013 23:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgSwOoyu-kwB for ; Wed, 29 May 2013 23:47:58 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 09DD821F94BA for ; Wed, 29 May 2013 23:47:57 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so5157920obc.41 for ; Wed, 29 May 2013 23:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zqkpCqqa2dBuyl9d+q6N4iR+cg85d9vMFhTSZeVaUCM=; b=UogYVuPKMbMWOSp5bs3HFEZfYpGmiIIY8T4srgzp6I0107HlCVrF7/Aw5Xf8D2k9vW NuOdDkUBFuXwDt8NA1hic1FRLpOseecx7yvRdPP2cMiZiD+7UZYF4N43qABbE9Y7nRAV Ykd4N1uC+ffLnspPov+/Ovf8uCUwdtLCpvuK4TlGC1RoxnCzlwBOKiNVablowprd6bd+ qEk2v8SCRw8m329lCcDrkFLqmvGGVIMCvXoxfr2KWrKIjBRYhy7DbKmcTyStYCzx5AcT 3E+SbchtIYMagSv8OFModEf5TCtkPGqI/7XqXs6QveTIWbWNTqkhRgSvhDrYsHo4xoyU WvVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=zqkpCqqa2dBuyl9d+q6N4iR+cg85d9vMFhTSZeVaUCM=; b=J0dwZM4LyOQ9XudYKWGHCZDFWFEUHL1+nuYV0X4kfUyB07R8WbhkAOime59hw6HaJe DXYVwsodzkA5bbMXNADtFqOw7ybvy7tcUbxaLl90trPjtNTbQBVsYUUjWxw7eocT4OJc ywDTJjkZcCX8vHRDJHJaOIcPGTx7AcLceNBIH4yI7OKy2Pu+i75nLXyskFjj1e+IeFAH b8aTyJo3I4KgXvUr3WSUvOf6LPDYCmDi9l50n8/h0DQbj4g3fqsPndrVNKWH+X61MAXm qaiO4oPX6LL71PluKH8R73UpLLEDx3eo8+psrRq5z1upE3BYtfJz2C4bZDjvtP1YHMBy 8cSw== X-Received: by 10.60.141.231 with SMTP id rr7mr3451249oeb.77.1369896477565; Wed, 29 May 2013 23:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.146.47 with HTTP; Wed, 29 May 2013 23:47:37 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> From: Lorenzo Colitti Date: Thu, 30 May 2013 15:47:37 +0900 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=047d7b339a3fecc88304dde9e074 X-Gm-Message-State: ALoCoQkypoxubHpl8WIltj/60QxL7NG91W+Rggjdmco6bLIwe2ZhjSUegqkNPulhyE0+HhAqusNDTOv93qCpfTbiTDLbcW/ed6qq0CyhqGC01EPNdXg7FofXIeeGy6G25+hoHfVnNuHzlRUwgTmNz7q2pw04lcxHWDbOyJN5825CRPcNmD/pIxLEDKXKre8PbNUYXYFRW4/G Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:47:59 -0000 --047d7b339a3fecc88304dde9e074 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 30, 2013 at 3:33 PM, Tim Chown wrote: > I agree. That said, an ISP, enterprise or group of organisations can > follow whatever semantics they wish within their own borders. > As long as the RIRs are willing to give them enough address space to do so. If an ISP requested an IPv6 /10 from ARIN because they wanted to give every customer a /48 and wanted to geocode the customer's subscriber ID into the /48, then ARIN would do well to say, "no, sorry, that doesn't make sense". Lest someone not realize this, the draft should clearly state that embedding N bits of semantics into IPv6 addresses causes the network to use 2^N times the address space that it normally would. IMO I think it should also state that although it is an IETF RFC, this model is not necessarily a recommended model, and that RIRs are not obliged to accept this type of address allocation as a justification for obtaining larger address blocks than they would normally be able to obtain. --047d7b339a3fecc88304dde9e074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2013 at 3:33 PM, Tim Chown <tjc@ecs.sot= on.ac.uk> wrote:

I agree. That said, an ISP, enterprise or group of organisations = can follow whatever semantics they wish within their own borders.

As long as the RIRs are willing to g= ive them enough address space to do so.

If an ISP requested an IPv6 /10 from ARIN because they wanted to give eve= ry customer a /48 and wanted to geocode the customer's subscriber ID in= to the /48, then ARIN would do well to say, "no, sorry, that doesn'= ;t make sense".

Lest someone not realize this, the draft sh= ould clearly state that embedding N bits of semantics into IPv6 addresses c= auses the network to use 2^N times the address space that it normally would= .

IMO I think it should also state that altho= ugh it is an IETF RFC, this model is not necessarily a recommended model, a= nd that RIRs are not obliged to accept this type of address allocation as a= justification for obtaining larger address blocks than they would normally= be able to obtain.

--047d7b339a3fecc88304dde9e074-- From ggm@algebras.org Wed May 29 23:55:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00ACF21F963A for ; Wed, 29 May 2013 23:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DbcAQ8b29ua for ; Wed, 29 May 2013 23:55:45 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E55DC21F939E for ; Wed, 29 May 2013 23:55:44 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so10508474pbb.27 for ; Wed, 29 May 2013 23:55:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=yu4fFl1x0mPnM1BdW6vtZsZGrkn07Wwnent5354ZMPc=; b=ewLYYTVsiugOXa4ACfpFShAdZKCiC0Vu59TFssBFKODhjZ+hLprjyMHNOwck+YpvBC r88h71/L2XQkU4QhEPtaw8s6/h7UMsMYmViKV0Rkgoy0ERWm0dIWKdSDjif4O9OMWwNV ds+hhCrEx8tkaYZ6DtQV/vmMEfmoXE6PbvP/YB5zoVAnGTAV/wWVvIQn6aqVToO25v84 lj3vxBeQK0pAATkfokoHbMIHRXRjSkHdKqu5Fm/wdVCLvHu8IEdCowllo1M79N//Qz57 2qQ2Z+XbmHhWgJzjPRLkUN3UYr8lfbKbIb93aeXLOAbwcStCUljWvC4sKVlp6KZh2d42 m8qg== MIME-Version: 1.0 X-Received: by 10.68.212.196 with SMTP id nm4mr6506931pbc.216.1369896941634; Wed, 29 May 2013 23:55:41 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Wed, 29 May 2013 23:55:41 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:8d02:94ac:45f4:abe8] In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> Date: Thu, 30 May 2013 16:55:41 +1000 Message-ID: From: George Michaelson To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=e89a8ff1c13a95d89c04dde9fc2a X-Gm-Message-State: ALoCoQnHOxcKt9bwqx/SpqnM7WWxycpiOVAReAKXEqXVSek7/VbcRiHeC/0qqUVEwvoABkfiA3Fk Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:55:46 -0000 --e89a8ff1c13a95d89c04dde9fc2a Content-Type: text/plain; charset=ISO-8859-1 Which is pretty much what was said to mike, when this came up in the WG 2 IETFs ago. Overloading parts of the allocation space under your /32 makes a complete mockery of the process model which justified the /32 based on /56 or /48 consumption plans, and while the H/D ratio is a somewhat rei-fied number, this kind of scheme will alter consumption of the address space massively. That some large ISPs and network operators *want* to overload bits in the address to have meaning? Sure. I can believe that. That vendors, knowing this, *want* to encode logic into sold routers, devices, to exploit this? Sure. I can believe that. is it a good architecture? No. I cannot currently believe that. -george On Thu, May 30, 2013 at 4:47 PM, Lorenzo Colitti wrote: > On Thu, May 30, 2013 at 3:33 PM, Tim Chown wrote: > >> I agree. That said, an ISP, enterprise or group of organisations can >> follow whatever semantics they wish within their own borders. >> > > As long as the RIRs are willing to give them enough address space to do so. > > If an ISP requested an IPv6 /10 from ARIN because they wanted to give > every customer a /48 and wanted to geocode the customer's subscriber ID > into the /48, then ARIN would do well to say, "no, sorry, that doesn't make > sense". > > Lest someone not realize this, the draft should clearly state that > embedding N bits of semantics into IPv6 addresses causes the network to use > 2^N times the address space that it normally would. > > IMO I think it should also state that although it is an IETF RFC, this > model is not necessarily a recommended model, and that RIRs are not obliged > to accept this type of address allocation as a justification for obtaining > larger address blocks than they would normally be able to obtain. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --e89a8ff1c13a95d89c04dde9fc2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Which is pretty much what was said to mike, when this came= up in the WG 2 IETFs ago. Overloading parts of the allocation space under = your /32 makes a complete mockery of the process model which justified the = /32 based on /56 or /48 consumption plans, and while the H/D ratio is a som= ewhat rei-fied number, this kind of scheme will alter consumption of the ad= dress space massively.

That some large ISPs and network operators *want* to o= verload bits in the address to have meaning? Sure. I can believe that. That= vendors, knowing this, *want* to encode logic into sold routers, devices, = to exploit this? Sure. I can believe that.

is it a good architecture? No. I cannot cur= rently believe that.

-george

On Thu, May= 30, 2013 at 4:47 PM, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Thu, M= ay 30, 2013 at 3:33 PM, Tim Chown <tjc@ecs.soton.ac.uk> wr= ote:

I a= gree. That said, an ISP, enterprise or group of organisations can follow wh= atever semantics they wish within their own borders.

As long as the RIRs are willing to g= ive them enough address space to do so.

If an ISP = requested an IPv6 /10 from ARIN because they wanted to give every customer = a /48 and wanted to geocode the customer's subscriber ID into the /48, = then ARIN would do well to say, "no, sorry, that doesn't make sens= e".

Lest someone not realize this, the draft should clearly= state that embedding N bits of semantics into IPv6 addresses causes the ne= twork to use 2^N times the address space that it normally would.

IMO I think it should also state that although it is an= IETF RFC, this model is not necessarily a recommended model, and that RIRs= are not obliged to accept this type of address allocation as a justificati= on for obtaining larger address blocks than they would normally be able to = obtain.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8ff1c13a95d89c04dde9fc2a-- From jiangsheng@huawei.com Thu May 30 00:01:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9B521F96AC; Thu, 30 May 2013 00:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMcWd25OrXMC; Thu, 30 May 2013 00:01:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48F9221F96AA; Thu, 30 May 2013 00:01:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH78915; Thu, 30 May 2013 07:01:04 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:00:30 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 15:01:03 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 30 May 2013 15:01:00 +0800 From: Sheng Jiang To: Tim Chown , Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAIm9sA== Date: Thu, 30 May 2013 07:00:59 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:01:11 -0000 Pj4gSVAgYWRkcmVzc2VzIG5lZWQgbGVzcyBvdmVybG9hZGluZyBvZiBzZW1hbnRpY3MsIG5vdCBt b3JlLg0KPj4NCj4+IFdlIGFscmVhZHkgdXNlIElQIGFkZHJlc3NlcyBmb3IgdHdvIGNvbmZsaWN0 aW5nIHB1cnBvc2Vz4oCmIFRvcG9sb2d5IGxvY2F0b3INCj5hbmQgRW5kIFN5c3RlbSBJZGVudGlm aWVyLg0KPj4NCj4+IFRoaXMgb3ZlcmxvYWRpbmcgaXMgYXQgdGhlIGhlYXJ0IG9mIG91ciBjdXJy ZW50IHNjYWxpbmcgaXNzdWVzIHdpdGggcmVzcGVjdCB0bw0KPnRoZSByb3V0aW5nIHRhYmxlLiBX aGlsZSB0aGVzZSBpc3N1ZXMgYXJlIGN1cnJlbnRseSBsZXNzIGNyaXRpY2FsIHRoYW4gdGhleSBo YXZlDQo+YmVlbiBpbiB0aGUgcGFzdCBhbmQgd2lsbCBsaWtlbHkgZ2V0IHF1aXRlIGEgYml0IGxl c3MgY3JpdGljYWwgaW4gSVB2NiwgdGhhdCBpcyBvbmx5DQo+YmVjYXVzZSB3ZSBoYXZlIGdpdmVu IHVwIGEgZmFpciBhbW91bnQgb2YgZnVuY3Rpb25hbGl0eSB0byBwcmVzZXJ2ZQ0KPnNjYWxhYmls aXR5IGluIHRoaXMgcmVnYXJkLg0KPj4NCj4+IElmIHdlIGRpZCBub3QgaGF2ZSB0aGlzIG92ZXJs b2FkaW5nLCB0aGVuIGFuIGVudGl0eSBjb3VsZCBvYnRhaW4gYSBzZXQgb2YNCj5lbmQtc3lzdGVt IGlkZW50aWZpZXJzIGFuZCBrZWVwIHRoZW0gdGhyb3VnaG91dCB0aGVpciBsaWZldGltZSwgcmVn YXJkbGVzcyBvZg0KPnRvcG9sb2dpY2FsIGNoYW5nZXMuIFRvZGF5LCB3aGVyZSB0aGUgYWRkcmVz c2VzIGFyZSBvdmVybG9hZGVkIHdpdGggYm90aA0KPnNlbWFudGljcywgd2UgZWl0aGVyIGhhdmUg dG8gZm9yY2UgbW9zdCBlbnRpdGllcyB0byBjaGFuZ2UgdGhlaXIgbnVtYmVycw0KPndoZW4gdGhl eSBjaGFuZ2UgdG9wb2xvZ3kgb3Igd2UgZmFjZSB1bnN1c3RhaW5hYmxlIGdyb3d0aCBpbiB0aGUg cm91dGluZw0KPnRhYmxlcy4NCj4+DQo+PiBUaGUgaWRlYSBvZiBhZGRpbmcgbW9yZSBzZW1hbnRp Y3MgdG8gYWRkcmVzc2luZyByYXRoZXIgdGhhbiBzZWVraW5nIHRvDQo+cmVkdWNlIHRoaXMgb3Zl cmxvYWRpbmcgc2VlbXMgYSBzdGVwIGluIHRoZSB3cm9uZyBkaXJlY3Rpb24sIElNSE8uDQo+DQo+ SSBhZ3JlZS4gVGhhdCBzYWlkLCBhbiBJU1AsIGVudGVycHJpc2Ugb3IgZ3JvdXAgb2Ygb3JnYW5p c2F0aW9ucyBjYW4gZm9sbG93DQo+d2hhdGV2ZXIgc2VtYW50aWNzIHRoZXkgd2lzaCB3aXRoaW4g dGhlaXIgb3duIGJvcmRlcnMuIEp1c3QgZG9uJ3QgZXhwZWN0DQo+YW55b25lIGVsc2UgdG8gZm9s bG93IG9yIHVzZSB0aG9zZSBzZW1hbnRpY3MuICBXaGF0IFNoZW5nIGlzIHByb3Bvc2luZyBpcw0K PmNsZWFybHkgc3RhdGVkIGFzIG9ubHkgYmVpbmcgZm9yIGludGVycHJldGF0aW9uIGJldHdlZW4g YWdyZWVpbmcNCj5vcmdhbmlzYXRpb25zLg0KDQpIaSwgVGltLA0KDQpJdCBpcyBleGFjdGx5IHdo YXQgdGhlIGRyYWZ0IGRvY3VtZW50LiBUaGVzZSBzZW1hbnRpY3MgaXMgb25seSBtZWFuaW5nZnVs IGxvY2FsbHkgd2l0aGluIHRoZSBhc3NpZ25pbmcgcHJvdmlkZXIgbmV0d29yay4gSXQgbWF5IG9u bHkgYmUgaW50ZXJwcmV0YXRpb24gYmV0d2VlbiBhZ3JlZWluZyBwcm92aWRlcnMuDQoNCkFueSBl ZmZvcnRzIHRvIGFkZCBnbG9iYWwgb3IgZ2VuZXJpYyBzZW1hbnRpY3MgdG8gSVAgYWRkcmVzcyBp cyBvdmVybG9hZCB0aGUgSVAgYXJjaGl0ZWN0dXJlIGFuZCBpdCBiYWQgZGlyZWN0aW9uLCBJIGFn cmVlLg0KDQo+SSB0aGluayBwZW9wbGUgd2lsbCBkbyB0aGlzIHR5cGUgb2YgdGhpbmcsIHNvIGFu IEluZm9ybWF0aW9uYWwgZG9jdW1lbnQNCj5kaXNjdXNzaW5nIHRoZSBwcm9zIGFuZCBjb25zLCBh bmQgaG93IHNlbWFudGljcyBjYW4gYmUgdXNlZCwgaXMgcHJvYmFibHkgYQ0KPmdvb2QgdGhpbmcu ICBQZXJoYXBzIGEgIlBvdGVudGlhbCBQaXRmYWxscyIgdHlwZSBzZWN0aW9uIGFmdGVyIHRoZSAi UG90ZW50aWFsDQo+QmVuZWZpdHMiIHNlY3Rpb24gd291bGQgYmFsYW5jZSB0aGUgZG9jdW1lbnQg YSBsaXR0bGUgYmV0dGVyPw0KDQpZZXMuIFdlIHdpbGwgZG8gc28gaW4gdGhlIGZ1dHVyZSB2ZXJz aW9uLiANCg0KQ2hlZXJzLA0KDQpTaGVuZw0KDQo+VGltDQo+DQo+PiBPd2VuDQo+Pg0KPj4gT24g TWF5IDI5LCAyMDEzLCBhdCAxMjowNiBBTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2Vp LmNvbT4NCj53cm90ZToNCj4+DQo+Pj4gSVAgYWRkcmVzc2VzIGFyZSBkZXNpZ25lZCBhcyB0b3Bv bG9neSBsb2NhdG9yLCBzbyB0aGF0IGV2ZXJ5IHBhY2tldCBjYW4gYmUNCj5yb3V0ZWQgdG8gaXRz IG5ldHdvcmsgZGVzdGluYXRpb24uDQo+Pj4NCj4+PiBIb3dldmVyLCBldmVuIGluIElQdjQgZXJh LCBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFwcGVkIHRoZWlyIElQDQo+YWRkcmVzcyB3 aXRoIGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhlc2Uga2luZCBvZiBtZWNoYW5pc20gZXhw bGljaXRseQ0KPmV4cHJlc3MgdGhlIHNlbWFudGljIHByb3BlcnRpZXMgb2YgZXZlcnkgcGFja2V0 LiBDb25zZXF1ZW50bHksIHRoZXNlIG5ldHdvcmsNCj5vcGVyYXRvcnMgY2FuIGluc3BlY3QgdGhl IHByb3BlcnRpZXMgb2YgcGFja2V0cyBlYXNpbHkgYnkgbWFwcGluZyB0aGUNCj5hZGRyZXNzZXMg YmFjayB0byBzZW1hbnRpYy4NCj4+Pg0KPj4+IE5ldHdvcmsgb3BlcmF0b3JzLCB3aG8gaGF2ZSBs YXJnZSBJUHY2IGFkZHJlc3Mgc3BhY2UsIG1heSBhbHNvIGNob29zZQ0KPnRvIGVtYmVkZGVkIHNv bWUgc2VtYW50aWNzIGludG8gSVB2NiBhZGRyZXNzZXMgYnkgYXNzaWduaW5nIGFkZGl0aW9uYWwN Cj5zaWduaWZpY2FuY2UgdG8gc3BlY2lmaWMgYml0cyB3aXRoaW4gdGhlIHByZWZpeC4NCj5kcmFm dC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXggZG9jdW1lbnRzIGEgZnJhbWV3b3JrIG1ldGhv ZCB0aGF0DQo+bmV0d29yayBvcGVyYXRpb25zIG1heSB1c2UgdGhlaXIgYWRkcmVzc2VzIHdpdGgg ZW1iZWRkZWQgc2VtYW50aWNzLiBUaGVzZQ0KPnNlbWFudGljcyBiaXRzIGFyZSBvbmx5IG1lYW5p bmdmdWwgd2l0aGluIGEgc2luZ2xlIG5ldHdvcmssIG9yIGdyb3VwIG9mDQo+aW50ZXJjb25uZWN0 ZWQgbmV0d29ya3Mgd2hpY2ggc2hhcmUgYSBjb21tb24gYWRkcmVzc2luZyBwb2xpY3kuIEJhc2Vk IG9uDQo+dGhlc2UgZW1iZWRkZWQgc2VtYW50aWMgYml0cyBpbiBzb3VyY2UvZGVzdGluYXRpb24g YWRkcmVzc2VzLCB0aGUgbmV0d29yaw0KPm9wZXJhdG9ycyBjYW4gYWNjb3JkaW5nbHkgdHJlYXQg bmV0d29yayBwYWNrZXRzIGRpZmZlcmVudGx5IGFuZCBlZmZpY2llbnRseS4NCj4+Pg0KPj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZp eC0wMw0KPj4+DQo+Pj4gQ291bGQgeW91IHBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCBhbmQgY29t bWVudHM/IEl0IHdpbGwgaGVscCB0aGUNCj5kb2N1bWVudCBiZWNvbWUgbW9yZSB1c2VmdWwgaW5m b3JtYXRpb24gdG8gYmUgc2hhcmVkLg0KPj4+DQo+Pj4gQmVzdCByZWdhcmRzLA0KPj4+DQo+Pj4g U2hlbmcNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd DQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIE1heSAyOCwgMjAxMyAxMDoyOCBBTQ0KPj4+PiBUbzogUWlv bmcgU3VuOyBJYW4gRmFycmVyOyBTaGVuZyBKaWFuZzsgQm95YW5nDQo+Pj4+IFN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+Pj4gZHJhZnQtamlhbmctdjZvcHMtc2VtYW50 aWMtcHJlZml4LTAzLnR4dA0KPj4+Pg0KPj4+Pg0KPj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzLnR4dA0KPj4+PiBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ Pj4+IElFVEYgcmVwb3NpdG9yeS4NCj4+Pj4NCj4+Pj4gRmlsZW5hbWU6CSBkcmFmdC1qaWFuZy12 Nm9wcy1zZW1hbnRpYy1wcmVmaXgNCj4+Pj4gUmV2aXNpb246CSAwMw0KPj4+PiBUaXRsZToJCSBB IEZyYW1ld29yayBmb3IgU2VtYW50aWMgSVB2NiBQcmVmaXgNCj4+Pj4gQ3JlYXRpb24gZGF0ZToJ IDIwMTMtMDUtMjgNCj4+Pj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4+IE51 bWJlciBvZiBwYWdlczogMTkNCj4+Pj4gVVJMOg0KPj4+Pg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMy50eHQN Cj4+Pj4gU3RhdHVzOg0KPj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeA0KPj4+PiBIdG1saXplZDoNCj4+Pj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAz DQo+Pj4+IERpZmY6DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMw0KPj4+Pg0KPj4+PiBBYnN0cmFjdDoNCj4+ Pj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgbWV0aG9kIHRoYXQgbmV0d29y ayBvcGVyYXRpb25zDQo+Pj4+IG1heSB1c2UgdGhlaXIgYWRkcmVzc2VzLiAgTmV0d29yayBvcGVy YXRvcnMsIHdobyBoYXZlIGxhcmdlIElQdjYNCj4+Pj4gYWRkcmVzcyBzcGFjZSwgbWF5IGNob29z ZSB0byBlbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYNCj4+Pj4gYWRkcmVzc2VzIGJ5 IGFzc2lnbmluZyBhZGRpdGlvbmFsIHNpZ25pZmljYW5jZSB0byBzcGVjaWZpYyBiaXRzDQo+Pj4+ IHdpdGhpbiB0aGUgcHJlZml4LiAgQnkgZW1iZWRkZWQgc2VtYW50aWNzIGludG8gSVB2NiBwcmVm aXhlcywgdGhlDQo+Pj4+IHNlbWFudGljcyBvZiBwYWNrZXRzIGNhbiBiZSBpbnNwZWN0ZWQgZWFz aWx5LiAgUm91dGVycyBhbmQgb3RoZXINCj4+Pj4gaW50ZXJtZWRpYXJ5IGRldmljZXMgY2FuIGVh c2lseSBhcHBseSByZWxldmFudCBwb2xpY2llcyBhcyByZXF1aXJlZC4NCj4+Pj4gUGFja2V0LWxl dmVsIGRpZmZlcmVudGlhdGlvbiBjYW4gYWxzbyBlbmFibGUgZmxvdy1sZXZlbCBhbmQgdXNlci0N Cj4+Pj4gbGV2ZWwgZGlmZmVyZW50aWF0aW9uLiAgQ29uc2VxdWVudGx5LCB0aGUgbmV0d29yayBv cGVyYXRvcnMgY2FuDQo+Pj4+IGFjY29yZGluZ2x5IHRyZWF0IG5ldHdvcmsgcGFja2V0cyBkaWZm ZXJlbnRseSBhbmQgZWZmaWNpZW50bHkuICBUaGUNCj4+Pj4gbWFuYWdlbWVudCBhbmQgbWFpbnRl bmFuY2Ugb2YgbmV0d29ya3MgY2FuIGJlIG11Y2ggc2ltcGxlci4NCj4+Pj4NCj4+Pj4NCj4+Pj4N Cj4+Pj4NCj4+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+Pg0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdjZvcHMgbWFpbGluZyBsaXN0 DQo+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From tjc@ecs.soton.ac.uk Thu May 30 00:12:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFFD21F9695; Thu, 30 May 2013 00:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC8xRMtes56E; Thu, 30 May 2013 00:12:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D687921F972B; Thu, 30 May 2013 00:12:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4U7BcVS012759; Thu, 30 May 2013 08:11:38 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4U7BcVS012759 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369897898; bh=D2wyjBRWrZdA8kQame64PK+VAtI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=uyZirk8kEmlFkL8O16f7ccfCMXYHUsQ2JR9dDeAW1wo46XrkQ3x9ZeIpBFbMcLJ2o vFpIXkYS+TzFHeCLNlr4uJCCbTTGaQQf77Yfd5tx2dxl3DSWZ2EXMkP0VsBqvPUUJU enOv4PhsJQrIY0XN7yE6ZpWvurJHyeYaiOdByxCU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p4Y8Bc04306166134K ret-id none; Thu, 30 May 2013 08:11:38 +0100 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4U7B9xM002129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 May 2013 08:11:10 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> Date: Thu, 30 May 2013 08:11:12 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4Y8Bc043061661300; tid=p4Y8Bc04306166134K; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4U7BcVS012759 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:12:20 -0000 On 30 May 2013, at 08:00, Sheng Jiang wrote: >>=20 >> I agree. That said, an ISP, enterprise or group of organisations can = follow >> whatever semantics they wish within their own borders. Just don't = expect >> anyone else to follow or use those semantics. What Sheng is = proposing is >> clearly stated as only being for interpretation between agreeing >> organisations. >=20 > Hi, Tim, >=20 > It is exactly what the draft document. These semantics is only = meaningful locally within the assigning provider network. It may only be = interpretation between agreeing providers. >=20 > Any efforts to add global or generic semantics to IP address is = overload the IP architecture and it bad direction, I agree. >=20 >> I think people will do this type of thing, so an Informational = document >> discussing the pros and cons, and how semantics can be used, is = probably a >> good thing. Perhaps a "Potential Pitfalls" type section after the = "Potential >> Benefits" section would balance the document a little better? >=20 > Yes. We will do so in the future version.=20 Good, and I think it's important to do so. George and Lorenzo's comments = are good starting points for that section. The potential = privacy/information leakage aspect is also worth capturing, should those = addresses be seen outside the organisation. 6rd is a good example of a scheme that typically requires a larger = allocation from the RIR purely because of the semantics used. But in = some cases the semantics need not require a larger allocation; we could = include semantics in a campus /48 for example. Tim= From jiangsheng@huawei.com Thu May 30 00:13:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9021F9729; Thu, 30 May 2013 00:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjAd1rDB0E-g; Thu, 30 May 2013 00:13:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B44AF21F9726; Thu, 30 May 2013 00:13:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARX97033; Thu, 30 May 2013 07:13:37 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:12:34 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:13:07 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Thu, 30 May 2013 15:13:02 +0800 From: Sheng Jiang To: Lorenzo Colitti , Tim Chown Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAAQAgIAAioBg Date: Thu, 30 May 2013 07:13:01 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC992D2nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:13:48 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC992D2nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIExvcmVuem8sDQoNCj5BcyBsb25nIGFzIHRoZSBSSVJzIGFyZSB3aWxsaW5nIHRvIGdpdmUg dGhlbSBlbm91Z2ggYWRkcmVzcyBzcGFjZSB0byBkbyBzby4NCg0KPklmIGFuIElTUCByZXF1ZXN0 ZWQgYW4gSVB2NiAvMTAgZnJvbSBBUklOIGJlY2F1c2UgdGhleSB3YW50ZWQgdG8gZ2l2ZSBldmVy eSBjdXN0b21lciBhIC80OCBhbmQgd2FudGVkIHRvIGdlb2NvZGUgdGhlIGN1c3RvbWVyJ3Mgc3Vi c2NyaWJlciBJRCBpbnRvIHRoZSAvNDgsIHRoZW4gQVJJTiB3b3VsZCBkbyB3ZWxsIHRvIHNheSwg Im5vLCBzb3JyeSwgdGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UiLg0KDQo+IElNTyBJIHRoaW5rIGl0 IHNob3VsZCBhbHNvIHN0YXRlIHRoYXQgYWx0aG91Z2ggaXQgaXMgYW4gSUVURiBSRkMsIHRoaXMg bW9kZWwgaXMgbm90IG5lY2Vzc2FyaWx5IGEgcmVjb21tZW5kZWQgbW9kZWwsIGFuZCB0aGF0IFJJ UnMgYXJlIG5vdCBvYmxpZ2VkIHRvIGFjY2VwdCB0aGlzIHR5cGUgb2YgYWRkcmVzcyBhbGxvY2F0 aW9uIGFzIGEganVzdGlmaWNhdGlvbiBmb3Igb2J0YWluaW5nIGxhcmdlciBhZGRyZXNzIGJsb2Nr cyB0aGFuIHRoZXkgd291bGQgbm9ybWFsbHkgYmUgYWJsZSB0byBvYnRhaW4uDQoNClllcywgdGhl cmUgaXMgbm8gaW50ZW5zaW9uIHRvIGNoYW5nZSBBUklO4oCZcyBwb2xpY3kgYXQgYWxsLiBBUklO IHNob3VsZCByZW1haW4gdGhlIGN1cnJlbnQgcG9saWN5IG9mIGFzc2lnbiBJUHY2IGFkZHJlc3Mg YmxvY2suIEJ1dCB0aGUgbmV0d29yayBwcm92aWRlcnMsIHdobyBoYXMgYWxyZWFkeSBnZXQgYWRk cmVzcyBibG9jaywgY2FuIGNob29zZSB0byB1c2UgdGhlIGFkZHJlc3NlcyB3aXRoIGNlcnRhaW4g c2VtYW50aWNzLiBBbmQgbm8gb25lLCBpbmNsdWRpbmcgQVJJTiBjYW4gc3RvcCB0aGlzLiBUaGlz IGlzIGp1c3Qgb25lIG9mIHRoZSBtYW55IHdheXMgcHJvdmlkZXJzIG1heSB1dGlsaXR5IHRoZWly IGFkZHJlc3Nlcy4NCg0KPkxlc3Qgc29tZW9uZSBub3QgcmVhbGl6ZSB0aGlzLCB0aGUgZHJhZnQg c2hvdWxkIGNsZWFybHkgc3RhdGUgdGhhdCBlbWJlZGRpbmcgTiBiaXRzIG9mIHNlbWFudGljcyBp bnRvIElQdjYgYWRkcmVzc2VzIGNhdXNlcyB0aGUgbmV0d29yayB0byB1c2UgMl5OIHRpbWVzIHRo ZSBhZGRyZXNzIHNwYWNlIHRoYXQgaXQgbm9ybWFsbHkgd291bGQuDQoNClllcywgd2Ugd2lsbCBz dGF0ZSB0aGUgc2VtYW50aWNzIHdpbGwgbG93ZXIgdGhlIGFkZHJlc3MgdXRpbGl6YXRpb24gcmF0 aW8gaW4gdGhlIGZ1dHVyZSB1cGRhdGUuIEhvd2V2ZXIsIGl0IGlzIG5vdCBuZWNlc3NhcnkgYXMg d29yc2UgYXMgMl5OIHRpbWVzLiBGb3IgZXhhbXBsZSwgaXQgdGhlcmUgYXJlIDIgYml0cyB0byBz ZXBhcmF0ZSBkaWZmZXJlbnQgdXNlIHR5cGVzIChzYXkgNCBkaWZmZXJlbnQgdHlwZXMpLCBpdCBh Y3R1YWxseSBvbmx5IHNlcGFyYXRlIHVzZSBhZGRyZXNzIHNwYWNlcyBpbnRvIGZvdXIgZGlmZmVy ZW50IHNwYWNlcy4gSXQgZG9lcyBub3QgbGltaXQgdGhlIGFkZHJlc3Mgc3BhY2UgdG8gYmUgMS80 IG9mIG9yaWdpbmFsIHNwYWNlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCkZyb206IExv cmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBNYXkgMzAsIDIwMTMgMjo0OCBQTQ0KVG86IFRpbSBDaG93bg0KQ2M6IE93ZW4gRGVMb25nOyA8 djZvcHNAaWV0Zi5vcmc+OyBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9vbHMu aWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIENvdWxkIElQdjYg YWRkcmVzcyBiZSBtb3JlIHRoYW4gbG9jYXRvcj8vL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGlj LXByZWZpeC0wMw0KDQpPbiBUaHUsIE1heSAzMCwgMjAxMyBhdCAzOjMzIFBNLCBUaW0gQ2hvd24g PHRqY0BlY3Muc290b24uYWMudWs8bWFpbHRvOnRqY0BlY3Muc290b24uYWMudWs+PiB3cm90ZToN CkkgYWdyZWUuIFRoYXQgc2FpZCwgYW4gSVNQLCBlbnRlcnByaXNlIG9yIGdyb3VwIG9mIG9yZ2Fu aXNhdGlvbnMgY2FuIGZvbGxvdyB3aGF0ZXZlciBzZW1hbnRpY3MgdGhleSB3aXNoIHdpdGhpbiB0 aGVpciBvd24gYm9yZGVycy4NCg0KQXMgbG9uZyBhcyB0aGUgUklScyBhcmUgd2lsbGluZyB0byBn aXZlIHRoZW0gZW5vdWdoIGFkZHJlc3Mgc3BhY2UgdG8gZG8gc28uDQoNCklmIGFuIElTUCByZXF1 ZXN0ZWQgYW4gSVB2NiAvMTAgZnJvbSBBUklOIGJlY2F1c2UgdGhleSB3YW50ZWQgdG8gZ2l2ZSBl dmVyeSBjdXN0b21lciBhIC80OCBhbmQgd2FudGVkIHRvIGdlb2NvZGUgdGhlIGN1c3RvbWVyJ3Mg c3Vic2NyaWJlciBJRCBpbnRvIHRoZSAvNDgsIHRoZW4gQVJJTiB3b3VsZCBkbyB3ZWxsIHRvIHNh eSwgIm5vLCBzb3JyeSwgdGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UiLg0KDQpMZXN0IHNvbWVvbmUg bm90IHJlYWxpemUgdGhpcywgdGhlIGRyYWZ0IHNob3VsZCBjbGVhcmx5IHN0YXRlIHRoYXQgZW1i ZWRkaW5nIE4gYml0cyBvZiBzZW1hbnRpY3MgaW50byBJUHY2IGFkZHJlc3NlcyBjYXVzZXMgdGhl IG5ldHdvcmsgdG8gdXNlIDJeTiB0aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGF0IGl0IG5vcm1h bGx5IHdvdWxkLg0KDQpJTU8gSSB0aGluayBpdCBzaG91bGQgYWxzbyBzdGF0ZSB0aGF0IGFsdGhv dWdoIGl0IGlzIGFuIElFVEYgUkZDLCB0aGlzIG1vZGVsIGlzIG5vdCBuZWNlc3NhcmlseSBhIHJl Y29tbWVuZGVkIG1vZGVsLCBhbmQgdGhhdCBSSVJzIGFyZSBub3Qgb2JsaWdlZCB0byBhY2NlcHQg dGhpcyB0eXBlIG9mIGFkZHJlc3MgYWxsb2NhdGlvbiBhcyBhIGp1c3RpZmljYXRpb24gZm9yIG9i dGFpbmluZyBsYXJnZXIgYWRkcmVzcyBibG9ja3MgdGhhbiB0aGV5IHdvdWxkIG5vcm1hbGx5IGJl IGFibGUgdG8gb2J0YWluLg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AC992D2nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMi Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpLCBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDtBcyBsb25nIGFzIHRoZSBSSVJzIGFyZSB3aWxsaW5nIHRvIGdp dmUgdGhlbSBlbm91Z2ggYWRkcmVzcyBzcGFjZSB0byBkbyBzby48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDtJZiBhbiBJU1AgcmVxdWVzdGVkIGFuIElQdjYgLzEwIGZyb20gQVJJTiBiZWNhdXNlIHRo ZXkgd2FudGVkIHRvIGdpdmUgZXZlcnkgY3VzdG9tZXIgYSAvNDggYW5kIHdhbnRlZCB0byBnZW9j b2RlIHRoZSBjdXN0b21lcidzIHN1YnNjcmliZXIgSUQgaW50byB0aGUgLzQ4LCB0aGVuIEFSSU4g d291bGQgZG8gd2VsbCB0byBzYXksICZxdW90O25vLCBzb3JyeSwgdGhhdCBkb2Vzbid0IG1ha2UN CiBzZW5zZSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgSU1PIEkgdGhpbmsgaXQgc2hv dWxkIGFsc28gc3RhdGUgdGhhdCBhbHRob3VnaCBpdCBpcyBhbiBJRVRGIFJGQywgdGhpcyBtb2Rl bCBpcyBub3QgbmVjZXNzYXJpbHkgYSByZWNvbW1lbmRlZCBtb2RlbCwgYW5kIHRoYXQgUklScyBh cmUgbm90IG9ibGlnZWQgdG8gYWNjZXB0IHRoaXMgdHlwZSBvZiBhZGRyZXNzIGFsbG9jYXRpb24g YXMgYSBqdXN0aWZpY2F0aW9uIGZvciBvYnRhaW5pbmcNCiBsYXJnZXIgYWRkcmVzcyBibG9ja3Mg dGhhbiB0aGV5IHdvdWxkIG5vcm1hbGx5IGJlIGFibGUgdG8gb2J0YWluLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIHRoZXJlIGlzIG5vIGludGVuc2lvbiB0byBjaGFu Z2UgQVJJTuKAmXMgcG9saWN5IGF0IGFsbC4gQVJJTiBzaG91bGQgcmVtYWluIHRoZSBjdXJyZW50 IHBvbGljeSBvZiBhc3NpZ24gSVB2NiBhZGRyZXNzIGJsb2NrLiBCdXQgdGhlIG5ldHdvcmsNCiBw cm92aWRlcnMsIHdobyBoYXMgYWxyZWFkeSBnZXQgYWRkcmVzcyBibG9jaywgY2FuIGNob29zZSB0 byB1c2UgdGhlIGFkZHJlc3NlcyB3aXRoIGNlcnRhaW4gc2VtYW50aWNzLiBBbmQgbm8gb25lLCBp bmNsdWRpbmcgQVJJTiBjYW4gc3RvcCB0aGlzLiBUaGlzIGlzIGp1c3Qgb25lIG9mIHRoZSBtYW55 IHdheXMgcHJvdmlkZXJzIG1heSB1dGlsaXR5IHRoZWlyIGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7TGVzdCBzb21l b25lIG5vdCByZWFsaXplIHRoaXMsIHRoZSBkcmFmdCBzaG91bGQgY2xlYXJseSBzdGF0ZSB0aGF0 IGVtYmVkZGluZyBOIGJpdHMgb2Ygc2VtYW50aWNzIGludG8gSVB2NiBhZGRyZXNzZXMgY2F1c2Vz IHRoZSBuZXR3b3JrIHRvIHVzZSAyXk4gdGltZXMgdGhlIGFkZHJlc3Mgc3BhY2UgdGhhdCBpdCBu b3JtYWxseSB3b3VsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB3 ZSB3aWxsIHN0YXRlIHRoZSBzZW1hbnRpY3Mgd2lsbCBsb3dlciB0aGUgYWRkcmVzcyB1dGlsaXph dGlvbiByYXRpbyBpbiB0aGUgZnV0dXJlIHVwZGF0ZS4gSG93ZXZlciwgaXQgaXMgbm90IG5lY2Vz c2FyeSBhcyB3b3JzZSBhcyAyXk4gdGltZXMuDQogRm9yIGV4YW1wbGUsIGl0IHRoZXJlIGFyZSAy IGJpdHMgdG8gc2VwYXJhdGUgZGlmZmVyZW50IHVzZSB0eXBlcyAoc2F5IDQgZGlmZmVyZW50IHR5 cGVzKSwgaXQgYWN0dWFsbHkgb25seSBzZXBhcmF0ZSB1c2UgYWRkcmVzcyBzcGFjZXMgaW50byBm b3VyIGRpZmZlcmVudCBzcGFjZXMuIEl0IGRvZXMgbm90IGxpbWl0IHRoZSBhZGRyZXNzIHNwYWNl IHRvIGJlIDEvNCBvZiBvcmlnaW5hbCBzcGFjZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFp bHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5 IDMwLCAyMDEzIDI6NDggUE08YnI+DQo8Yj5Ubzo8L2I+IFRpbSBDaG93bjxicj4NCjxiPkNjOjwv Yj4gT3dlbiBEZUxvbmc7ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWppYW5nLXY2b3Bz LXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuIGxv Y2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXkgMzAsIDIwMTMgYXQgMzoz MyBQTSwgVGltIENob3duICZsdDs8YSBocmVmPSJtYWlsdG86dGpjQGVjcy5zb3Rvbi5hYy51ayIg dGFyZ2V0PSJfYmxhbmsiPnRqY0BlY3Muc290b24uYWMudWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMjIyMjIyIj5J IGFncmVlLiBUaGF0IHNhaWQsIGFuIElTUCwgZW50ZXJwcmlzZSBvciBncm91cCBvZiBvcmdhbmlz YXRpb25zIGNhbiBmb2xsb3cgd2hhdGV2ZXIgc2VtYW50aWNzIHRoZXkgd2lzaCB3aXRoaW4gdGhl aXIgb3duIGJvcmRlcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGxvbmcg YXMgdGhlIFJJUnMgYXJlIHdpbGxpbmcgdG8gZ2l2ZSB0aGVtIGVub3VnaCBhZGRyZXNzIHNwYWNl IHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SWYgYW4gSVNQIHJlcXVlc3RlZCBhbiBJUHY2IC8xMCBmcm9tIEFSSU4gYmVjYXVzZSB0aGV5 IHdhbnRlZCB0byBnaXZlIGV2ZXJ5IGN1c3RvbWVyIGEgLzQ4IGFuZCB3YW50ZWQgdG8gZ2VvY29k ZSB0aGUgY3VzdG9tZXIncyBzdWJzY3JpYmVyIElEIGludG8gdGhlIC80OCwgdGhlbiBBUklOIHdv dWxkIGRvIHdlbGwgdG8gc2F5LCAmcXVvdDtubywgc29ycnksIHRoYXQgZG9lc24ndCBtYWtlDQog c2Vuc2UmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5MZXN0IHNvbWVvbmUgbm90IHJlYWxpemUgdGhpcywgdGhlIGRyYWZ0IHNob3VsZCBjbGVh cmx5IHN0YXRlIHRoYXQgZW1iZWRkaW5nIE4gYml0cyBvZiBzZW1hbnRpY3MgaW50byBJUHY2IGFk ZHJlc3NlcyBjYXVzZXMgdGhlIG5ldHdvcmsgdG8gdXNlIDJeTiB0aW1lcyB0aGUgYWRkcmVzcyBz cGFjZSB0aGF0IGl0IG5vcm1hbGx5IHdvdWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SU1PIEkgdGhpbmsgaXQgc2hvdWxkIGFsc28gc3RhdGUgdGhh dCBhbHRob3VnaCBpdCBpcyBhbiBJRVRGIFJGQywgdGhpcyBtb2RlbCBpcyBub3QgbmVjZXNzYXJp bHkgYSByZWNvbW1lbmRlZCBtb2RlbCwgYW5kIHRoYXQgUklScyBhcmUgbm90IG9ibGlnZWQgdG8g YWNjZXB0IHRoaXMgdHlwZSBvZiBhZGRyZXNzIGFsbG9jYXRpb24gYXMgYSBqdXN0aWZpY2F0aW9u IGZvciBvYnRhaW5pbmcNCiBsYXJnZXIgYWRkcmVzcyBibG9ja3MgdGhhbiB0aGV5IHdvdWxkIG5v cm1hbGx5IGJlIGFibGUgdG8gb2J0YWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AC992D2nkgeml512mbxchi_-- From lorenzo@google.com Thu May 30 00:19:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC0D21F978E for ; Thu, 30 May 2013 00:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBNFQ-AgF-pa for ; Thu, 30 May 2013 00:19:19 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED421F978B for ; Thu, 30 May 2013 00:19:19 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so9037114obc.34 for ; Thu, 30 May 2013 00:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zRsoECF5LwpYV4GdY53AX2spNEic1hNSP5Dx2UHIHAI=; b=he66ESO6kwAAVtnIpyMX5pepny1oAIWb1Cy2sIHJAmJzX8P5/o28F4gHa/taWQKi8J teRQOWlWpS5xqS8+IMOLH+BSTL8wkbHqyROtdvTxb/DYl/1MhKqHljvsdDQCgLP6LVQr EkNFUQICbRMjSC7jrt8XEzKRQtcuB6aXIFIwIRVW5EUu3I+gvCjXS+7kZYGIEVkSkF/B qVC+S74Tp5SZCn3zoinoS5n6FN8oqRJ+w4fEWLrMW9FxLnP3DiYHUv8XnTsaTUFYoUYa hIXrHBrpRE8xWtjX80Z+rFsdTJuqT7YACLSJldFJnSsJGa7jgnJl/TRgPmeXA6juwi4f pvOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=zRsoECF5LwpYV4GdY53AX2spNEic1hNSP5Dx2UHIHAI=; b=cjvH4/H95uKvHKKcXcud+0W/mgBDQTNljVMwLp1zpI8aoSRRJK39F8Z3a9UMSBrNpL DdAy5ET0bOjrxtnq6BKRTMbCP4nMsYmKz8V3QYaIhbslf8CyXGOc5B3MZRdk7WTFsy+/ 7PYawWNSPbKWFr19MJBr/jPgxTup15fCqCD4vE9AkHt5rVobv4ZDs7TcZbak7PyV39gQ /TNhvUFy4JD70U00RfDPsTu+/bYmquAv11cK9WOdLajUw1KwByCgFXhFstac1yYZtvMF t8DBqJuJqpRtGDCZFdfMBffdPOm69jDtZubPOhZlLy0a6hDGnUlwQ7V5elAm9xM5/8oU alOQ== X-Received: by 10.60.115.73 with SMTP id jm9mr3501783oeb.126.1369898358739; Thu, 30 May 2013 00:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.146.47 with HTTP; Thu, 30 May 2013 00:18:58 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 30 May 2013 16:18:58 +0900 Message-ID: To: Sheng Jiang Content-Type: multipart/alternative; boundary=089e0115ec300d36dc04ddea51e3 X-Gm-Message-State: ALoCoQnlmHQwfk3ANtXVa0lPRTu/5NryVWP+sBl0o8Zk6rsCmy5kf+7wafeS4AcALacSh1v/mGY5Pets6HvGFo2uHtY+NR/ifKwU9+Jyy7CQyqxiOxtV2ZQng8wn6cpRYsizCZHlPthTnHeF+6DA0NHgjzlMkY+Qhz/ESWXYDwy26wXoJ02XZfNzS+ostQwMQ7IkCuA8zYP+ Cc: "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:19:20 -0000 --089e0115ec300d36dc04ddea51e3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 30, 2013 at 4:13 PM, Sheng Jiang wrote: > Yes, there is no intension to change ARIN=92s policy at all. ARIN should > remain the current policy of assign IPv6 address block. But the network > providers, who has already get address block, can choose to use the > addresses with certain semantics. And no one, including ARIN can stop thi= s. > Agreed, but even for network providers that already have blocks, this will be an issue if they ever need another block. But I do think you should write this in the draft. > However, it is not necessary as worse as 2^N times. For example, it there > are 2 bits to separate different use types (say 4 different types), it > actually only separate use address spaces into four different spaces. It > does not limit the address space to be 1/4 of original space. > How is that different from saying "by adding two bits of semantics in the prefix, the network will use 4 times the address space than it would otherwise"? --089e0115ec300d36dc04ddea51e3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2013 at 4:13 PM, Sheng Jiang <jiangsh= eng@huawei.com> wrote:

Yes, there is no intension to change ARIN= =92s policy at all. ARIN should remain the current policy of assign IPv6 ad= dress block. But the network providers, who has already get address block, can choose to use the addres= ses with certain semantics. And no one, including ARIN can stop this.

Agreed, but even fo= r network providers that already have blocks, this will be an issue if they= ever need another block. But I do think you should write this in the draft= .

=A0
However, it is n= ot necessary as worse as 2^N times. For example, it there are 2 bits to separate different use types (say 4 di= fferent types), it actually only separate use address spaces into four diff= erent spaces. It does not limit the address space to be 1/4 of original spa= ce.

How is that different fr= om saying "by adding two bits of semantics in the prefix, the network = will use 4 times the address space than it would otherwise"?

--089e0115ec300d36dc04ddea51e3-- From jiangsheng@huawei.com Thu May 30 00:39:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8252821F96E9; Thu, 30 May 2013 00:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0R702HYh6ZZ; Thu, 30 May 2013 00:39:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 223A921F96EA; Thu, 30 May 2013 00:38:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH82157; Thu, 30 May 2013 07:38:45 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:38:03 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:38:33 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Thu, 30 May 2013 15:38:28 +0800 From: Sheng Jiang To: George Michaelson , Lorenzo Colitti Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAAQAgIAAAkGAgACOuhA= Date: Thu, 30 May 2013 07:38:28 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9933F@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC9933Fnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:39:05 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC9933Fnkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEdlb3JnZSwNCg0KSSB0aGluayB3ZSBzaGFyZSB0aGUgc2FtZSB2aWV3IGhlcmUuIEFjdHVh bGx5LCBJIG5ldmVyIHRyeSB0byByZWNvbW1lbmQgdGhpcyBhcyBhIGdvb2QgYXJjaGl0ZWN0dXJl LiBXaGF0IEkgYW0gdHJ5aW5nIHRvIGRvIGlzIHR3byB0aGluZ3M6IGEpIGRvY3VtZW50IHN1Y2gg bWVjaGFuaXNtIGFzIHdlIGFyZSBzdXJlIHRoaXMgaXMgaGFwcGVuaW5nIG9yIG1lYW50IHRvIGhh cHBlbiwgYikgZ2l2aW5nIGFuYWx5c2lzIG9mIHRoaXMgbWVjaGFuaXNtLg0KDQpJIGd1ZXNzIEkg c2hvdWxkIGFsc28gY2xlYXIgc3RhdGUgdGhhdCB0aGUgcHJvdmlkZXIsIHdobyBjaG9vc2Ugc3Vj aCBzY2hlbWEsIHNob3VsZCBiZSB3YXJlIHRoYXQgdGhleSBjYW5ub3QgZ2V0IG5ldyBhZGRyZXNz IGJsb2NrIHNpbmNlIHRoZXkgY29uc3VtZSB0aGVpciBhZGRyZXNzIGluIGEgbG93IHV0aWxpdHkg cmF0ZS4NCg0KQ2hlZXJzLA0KDQpTaGVuZw0KDQpGcm9tOiBHZW9yZ2UgTWljaGFlbHNvbiBbbWFp bHRvOmdnbUBhbGdlYnJhcy5vcmddDQpTZW50OiBUaHVyc2RheSwgTWF5IDMwLCAyMDEzIDI6NTYg UE0NClRvOiBMb3JlbnpvIENvbGl0dGkNCkNjOiBUaW0gQ2hvd247IGlwdjZAaWV0Zi5vcmc7IDx2 Nm9wc0BpZXRmLm9yZz47IGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5p ZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gQ291bGQgSVB2NiBhZGRyZXNzIGJlIG1vcmUg dGhhbiBsb2NhdG9yPy8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQoNCldo aWNoIGlzIHByZXR0eSBtdWNoIHdoYXQgd2FzIHNhaWQgdG8gbWlrZSwgd2hlbiB0aGlzIGNhbWUg dXAgaW4gdGhlIFdHIDIgSUVURnMgYWdvLiBPdmVybG9hZGluZyBwYXJ0cyBvZiB0aGUgYWxsb2Nh dGlvbiBzcGFjZSB1bmRlciB5b3VyIC8zMiBtYWtlcyBhIGNvbXBsZXRlIG1vY2tlcnkgb2YgdGhl IHByb2Nlc3MgbW9kZWwgd2hpY2gganVzdGlmaWVkIHRoZSAvMzIgYmFzZWQgb24gLzU2IG9yIC80 OCBjb25zdW1wdGlvbiBwbGFucywgYW5kIHdoaWxlIHRoZSBIL0QgcmF0aW8gaXMgYSBzb21ld2hh dCByZWktZmllZCBudW1iZXIsIHRoaXMga2luZCBvZiBzY2hlbWUgd2lsbCBhbHRlciBjb25zdW1w dGlvbiBvZiB0aGUgYWRkcmVzcyBzcGFjZSBtYXNzaXZlbHkuDQoNClRoYXQgc29tZSBsYXJnZSBJ U1BzIGFuZCBuZXR3b3JrIG9wZXJhdG9ycyAqd2FudCogdG8gb3ZlcmxvYWQgYml0cyBpbiB0aGUg YWRkcmVzcyB0byBoYXZlIG1lYW5pbmc/IFN1cmUuIEkgY2FuIGJlbGlldmUgdGhhdC4gVGhhdCB2 ZW5kb3JzLCBrbm93aW5nIHRoaXMsICp3YW50KiB0byBlbmNvZGUgbG9naWMgaW50byBzb2xkIHJv dXRlcnMsIGRldmljZXMsIHRvIGV4cGxvaXQgdGhpcz8gU3VyZS4gSSBjYW4gYmVsaWV2ZSB0aGF0 Lg0KDQppcyBpdCBhIGdvb2QgYXJjaGl0ZWN0dXJlPyBOby4gSSBjYW5ub3QgY3VycmVudGx5IGJl bGlldmUgdGhhdC4NCg0KLWdlb3JnZQ0KDQpPbiBUaHUsIE1heSAzMCwgMjAxMyBhdCA0OjQ3IFBN LCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29n bGUuY29tPj4gd3JvdGU6DQpPbiBUaHUsIE1heSAzMCwgMjAxMyBhdCAzOjMzIFBNLCBUaW0gQ2hv d24gPHRqY0BlY3Muc290b24uYWMudWs8bWFpbHRvOnRqY0BlY3Muc290b24uYWMudWs+PiB3cm90 ZToNCkkgYWdyZWUuIFRoYXQgc2FpZCwgYW4gSVNQLCBlbnRlcnByaXNlIG9yIGdyb3VwIG9mIG9y Z2FuaXNhdGlvbnMgY2FuIGZvbGxvdyB3aGF0ZXZlciBzZW1hbnRpY3MgdGhleSB3aXNoIHdpdGhp biB0aGVpciBvd24gYm9yZGVycy4NCg0KQXMgbG9uZyBhcyB0aGUgUklScyBhcmUgd2lsbGluZyB0 byBnaXZlIHRoZW0gZW5vdWdoIGFkZHJlc3Mgc3BhY2UgdG8gZG8gc28uDQoNCklmIGFuIElTUCBy ZXF1ZXN0ZWQgYW4gSVB2NiAvMTAgZnJvbSBBUklOIGJlY2F1c2UgdGhleSB3YW50ZWQgdG8gZ2l2 ZSBldmVyeSBjdXN0b21lciBhIC80OCBhbmQgd2FudGVkIHRvIGdlb2NvZGUgdGhlIGN1c3RvbWVy J3Mgc3Vic2NyaWJlciBJRCBpbnRvIHRoZSAvNDgsIHRoZW4gQVJJTiB3b3VsZCBkbyB3ZWxsIHRv IHNheSwgIm5vLCBzb3JyeSwgdGhhdCBkb2Vzbid0IG1ha2Ugc2Vuc2UiLg0KDQpMZXN0IHNvbWVv bmUgbm90IHJlYWxpemUgdGhpcywgdGhlIGRyYWZ0IHNob3VsZCBjbGVhcmx5IHN0YXRlIHRoYXQg ZW1iZWRkaW5nIE4gYml0cyBvZiBzZW1hbnRpY3MgaW50byBJUHY2IGFkZHJlc3NlcyBjYXVzZXMg dGhlIG5ldHdvcmsgdG8gdXNlIDJeTiB0aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGF0IGl0IG5v cm1hbGx5IHdvdWxkLg0KDQpJTU8gSSB0aGluayBpdCBzaG91bGQgYWxzbyBzdGF0ZSB0aGF0IGFs dGhvdWdoIGl0IGlzIGFuIElFVEYgUkZDLCB0aGlzIG1vZGVsIGlzIG5vdCBuZWNlc3NhcmlseSBh IHJlY29tbWVuZGVkIG1vZGVsLCBhbmQgdGhhdCBSSVJzIGFyZSBub3Qgb2JsaWdlZCB0byBhY2Nl cHQgdGhpcyB0eXBlIG9mIGFkZHJlc3MgYWxsb2NhdGlvbiBhcyBhIGp1c3RpZmljYXRpb24gZm9y IG9idGFpbmluZyBsYXJnZXIgYWRkcmVzcyBibG9ja3MgdGhhbiB0aGV5IHdvdWxkIG5vcm1hbGx5 IGJlIGFibGUgdG8gb2J0YWluLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQoNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AC9933Fnkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksIEdlb3JnZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayB3ZSBzaGFyZSB0aGUgc2FtZSB2aWV3IGhlcmUuIEFjdHVhbGx5LCBJIG5ldmVy IHRyeSB0byByZWNvbW1lbmQgdGhpcyBhcyBhIGdvb2QgYXJjaGl0ZWN0dXJlLiBXaGF0IEkgYW0g dHJ5aW5nIHRvIGRvIGlzIHR3byB0aGluZ3M6IGEpIGRvY3VtZW50DQogc3VjaCBtZWNoYW5pc20g YXMgd2UgYXJlIHN1cmUgdGhpcyBpcyBoYXBwZW5pbmcgb3IgbWVhbnQgdG8gaGFwcGVuLCBiKSBn aXZpbmcgYW5hbHlzaXMgb2YgdGhpcyBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgSSBzaG91bGQgYWxzbyBjbGVhciBzdGF0ZSB0aGF0IHRoZSBw cm92aWRlciwgd2hvIGNob29zZSBzdWNoIHNjaGVtYSwgc2hvdWxkIGJlIHdhcmUgdGhhdCB0aGV5 IGNhbm5vdCBnZXQgbmV3IGFkZHJlc3MgYmxvY2sgc2luY2UgdGhleSBjb25zdW1lDQogdGhlaXIg YWRkcmVzcyBpbiBhIGxvdyB1dGlsaXR5IHJhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2hl bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gR2VvcmdlIE1pY2hhZWxzb24gW21haWx0bzpn Z21AYWxnZWJyYXMub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMzAsIDIw MTMgMjo1NiBQTTxicj4NCjxiPlRvOjwvYj4gTG9yZW56byBDb2xpdHRpPGJyPg0KPGI+Q2M6PC9i PiBUaW0gQ2hvd247IGlwdjZAaWV0Zi5vcmc7ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRyYWZ0 LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuIGxvY2F0 b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hpY2ggaXMgcHJldHR5IG11Y2ggd2hhdCB3YXMg c2FpZCB0byBtaWtlLCB3aGVuIHRoaXMgY2FtZSB1cCBpbiB0aGUgV0cgMiBJRVRGcyBhZ28uIE92 ZXJsb2FkaW5nIHBhcnRzIG9mIHRoZSBhbGxvY2F0aW9uIHNwYWNlIHVuZGVyIHlvdXIgLzMyIG1h a2VzIGEgY29tcGxldGUgbW9ja2VyeSBvZiB0aGUgcHJvY2VzcyBtb2RlbCB3aGljaCBqdXN0aWZp ZWQgdGhlIC8zMiBiYXNlZA0KIG9uIC81NiBvciAvNDggY29uc3VtcHRpb24gcGxhbnMsIGFuZCB3 aGlsZSB0aGUgSC9EIHJhdGlvIGlzIGEgc29tZXdoYXQgcmVpLWZpZWQgbnVtYmVyLCB0aGlzIGtp bmQgb2Ygc2NoZW1lIHdpbGwgYWx0ZXIgY29uc3VtcHRpb24gb2YgdGhlIGFkZHJlc3Mgc3BhY2Ug bWFzc2l2ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYXQg c29tZSBsYXJnZSBJU1BzIGFuZCBuZXR3b3JrIG9wZXJhdG9ycyAqd2FudCogdG8gb3ZlcmxvYWQg Yml0cyBpbiB0aGUgYWRkcmVzcyB0byBoYXZlIG1lYW5pbmc/IFN1cmUuIEkgY2FuIGJlbGlldmUg dGhhdC4gVGhhdCB2ZW5kb3JzLCBrbm93aW5nIHRoaXMsICp3YW50KiB0byBlbmNvZGUgbG9naWMg aW50byBzb2xkIHJvdXRlcnMsIGRldmljZXMsIHRvIGV4cGxvaXQgdGhpcz8NCiBTdXJlLiBJIGNh biBiZWxpZXZlIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5pcyBpdCBhIGdvb2QgYXJjaGl0ZWN0dXJlPyBOby4gSSBjYW5ub3QgY3VycmVudGx5 IGJlbGlldmUgdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPi1nZW9yZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXkgMzAsIDIwMTMg YXQgNDo0NyBQTSwgTG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXkgMzAsIDIwMTMgYXQgMzozMyBQTSwg VGltIENob3duICZsdDs8YSBocmVmPSJtYWlsdG86dGpjQGVjcy5zb3Rvbi5hYy51ayIgdGFyZ2V0 PSJfYmxhbmsiPnRqY0BlY3Muc290b24uYWMudWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MjIyMjIyIj5JIGFncmVlLiBUaGF0IHNhaWQsIGFuIElTUCwgZW50ZXJwcmlzZSBvciBncm91cCBv ZiBvcmdhbmlzYXRpb25zIGNhbiBmb2xsb3cgd2hhdGV2ZXIgc2VtYW50aWNzIHRoZXkgd2lzaCB3 aXRoaW4gdGhlaXIgb3duIGJvcmRlcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+QXMgbG9uZyBhcyB0aGUgUklScyBhcmUgd2lsbGluZyB0byBnaXZlIHRoZW0gZW5v dWdoIGFkZHJlc3Mgc3BhY2UgdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JZiBhbiBJU1AgcmVxdWVzdGVkIGFuIElQdjYgLzEwIGZyb20g QVJJTiBiZWNhdXNlIHRoZXkgd2FudGVkIHRvIGdpdmUgZXZlcnkgY3VzdG9tZXIgYSAvNDggYW5k IHdhbnRlZCB0byBnZW9jb2RlIHRoZSBjdXN0b21lcidzIHN1YnNjcmliZXIgSUQgaW50byB0aGUg LzQ4LCB0aGVuIEFSSU4gd291bGQgZG8gd2VsbCB0byBzYXksICZxdW90O25vLCBzb3JyeSwgdGhh dCBkb2Vzbid0IG1ha2UNCiBzZW5zZSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxlc3Qgc29tZW9uZSBub3QgcmVhbGl6ZSB0aGlzLCB0aGUg ZHJhZnQgc2hvdWxkIGNsZWFybHkgc3RhdGUgdGhhdCBlbWJlZGRpbmcgTiBiaXRzIG9mIHNlbWFu dGljcyBpbnRvIElQdjYgYWRkcmVzc2VzIGNhdXNlcyB0aGUgbmV0d29yayB0byB1c2UgMl5OIHRp bWVzIHRoZSBhZGRyZXNzIHNwYWNlIHRoYXQgaXQgbm9ybWFsbHkgd291bGQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JTU8gSSB0aGluayBpdCBzaG91 bGQgYWxzbyBzdGF0ZSB0aGF0IGFsdGhvdWdoIGl0IGlzIGFuIElFVEYgUkZDLCB0aGlzIG1vZGVs IGlzIG5vdCBuZWNlc3NhcmlseSBhIHJlY29tbWVuZGVkIG1vZGVsLCBhbmQgdGhhdCBSSVJzIGFy ZSBub3Qgb2JsaWdlZCB0byBhY2NlcHQgdGhpcyB0eXBlIG9mIGFkZHJlc3MgYWxsb2NhdGlvbiBh cyBhIGp1c3RpZmljYXRpb24gZm9yIG9idGFpbmluZw0KIGxhcmdlciBhZGRyZXNzIGJsb2NrcyB0 aGFuIHRoZXkgd291bGQgbm9ybWFsbHkgYmUgYWJsZSB0byBvYnRhaW4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2 b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZv cHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AC9933Fnkgeml512mbxchi_-- From jiangsheng@huawei.com Thu May 30 00:56:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB80C21F974A; Thu, 30 May 2013 00:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LseThAxJPE56; Thu, 30 May 2013 00:56:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C86E21F8825; Thu, 30 May 2013 00:56:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY01020; Thu, 30 May 2013 07:56:33 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:55:58 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 08:56:29 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 30 May 2013 15:56:25 +0800 From: Sheng Jiang To: Lorenzo Colitti Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAAQAgIAAioBg//9+QwCAAIvnkA== Date: Thu, 30 May 2013 07:56:24 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC99354nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:56:44 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99354nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj5ZZXMsIHRoZXJlIGlzIG5vIGludGVuc2lvbiB0byBjaGFuZ2UgQVJJTuKAmXMgcG9saWN5IGF0 IGFsbC4gQVJJTiBzaG91bGQgcmVtYWluIHRoZSBjdXJyZW50IHBvbGljeSBvZiBhc3NpZ24gSVB2 NiBhZGRyZXNzIGJsb2NrLiBCdXQgdGhlIG5ldHdvcmsgcHJvdmlkZXJzLCB3aG8gaGFzIGFscmVh ZHkgZ2V0IGFkZHJlc3MgYmxvY2ssIGNhbiBjaG9vc2UgdG8gdXNlIHRoZSBhZGRyZXNzZXMgd2l0 aCBjZXJ0YWluIHNlbWFudGljcy4gQW5kIG5vIG9uZSwgaW5jbHVkaW5nIEFSSU4gY2FuIHN0b3Ag dGhpcy4NCj5BZ3JlZWQsIGJ1dCBldmVuIGZvciBuZXR3b3JrIHByb3ZpZGVycyB0aGF0IGFscmVh ZHkgaGF2ZSBibG9ja3MsIHRoaXMgd2lsbCBiZSBhbiBpc3N1ZSBpZiB0aGV5IGV2ZXIgbmVlZCBh bm90aGVyIGJsb2NrLiBCdXQgSSBkbyB0aGluayB5b3Ugc2hvdWxkIHdyaXRlIHRoaXMgaW4gdGhl IGRyYWZ0Lg0KV2lsbCBkby4gVGhlIHByb3ZpZGVyLCB3aG8gY2hvb3NlIHN1Y2ggc2NoZW1hLCBz aG91bGQgYmUgYXdhcmUgdGhhdCB0aGV5IGNhbm5vdCBnZXQgbmV3IGFkZHJlc3MgYmxvY2sgb25s eSBiZWNhdXNlIHRoZXkgY29uc3VtZSB0aGVpciBhZGRyZXNzIHNwYWNlIGluIGEgbG93IHV0aWxp dHkgcmF0ZS4NCj4+SG93ZXZlciwgaXQgaXMgbm90IG5lY2Vzc2FyeSBhcyB3b3JzZSBhcyAyXk4g dGltZXMuIEZvciBleGFtcGxlLCBpdCB0aGVyZSBhcmUgMiBiaXRzIHRvIHNlcGFyYXRlIGRpZmZl cmVudCB1c2UgdHlwZXMgKHNheSA0IGRpZmZlcmVudCB0eXBlcyksIGl0IGFjdHVhbGx5IG9ubHkg c2VwYXJhdGUgdXNlIGFkZHJlc3Mgc3BhY2VzIGludG8gZm91ciBkaWZmZXJlbnQgc3BhY2VzLiBJ dCBkb2VzIG5vdCBsaW1pdCB0aGUgYWRkcmVzcyBzcGFjZSB0byBiZSAxLzQgb2Ygb3JpZ2luYWwg c3BhY2UuDQpIb3cgaXMgdGhhdCBkaWZmZXJlbnQgZnJvbSBzYXlpbmcgImJ5IGFkZGluZyB0d28g Yml0cyBvZiBzZW1hbnRpY3MgaW4gdGhlIHByZWZpeCwgdGhlIG5ldHdvcmsgd2lsbCB1c2UgNCB0 aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGFuIGl0IHdvdWxkIG90aGVyd2lzZSI/DQpOby4gVGhp cyBpcyB2ZXJ5IGRpZmZlcmVudC4gUHV0dGluZyB0aGUgZXhhbXBsZSBpbnRvIG51bWJlcnMgbWF5 IGJlIG1vcmUgaW50dWl0aW9uaXN0aWMuIFNheSBhbiBJU1AgaGFzIDQgbWlsbGlvbiBzdWJzY3Jp YmVycywgaXQgbmVlZHMgNCBtaWxsaW9uIC81NiAoYXNzdW1pbmcgZXZlcnkgdXNlciBnZXQgYSAv NTYpLiBCeSBzZXBhcmF0aW5nIHRoZW0gaW50byA0IGRpZmZlcmVudCB0eXBlcywgdGhlIGFkZHJl c3MgY29uc3VtcHRpb24gaXMgc3RpbGwgNCBtaWxsaW9uIC81NiBpZiB0aGUgc2VwYXJhdGlvbiBp cyBleGFjdGx5IGV2ZW4uIEhvd2V2ZXIsIHRoZSBtb3JlIGFkZHJlc3MgbWF5IG5lZWQgd2hlbiB0 aGUgc2VwYXJhdGlvbiBpcyBub3QgZXZlbi4gRm9yIGV4YW1wbGUsIGlmIHRoZSBiaWdnZXN0IHVz ZXIgdHlwZSBoYXMgMiBtaWxsaW9uIHVzZXJzLCB0aGVuIHRoZSB0b3RhbCBhZGRyZXNzIHNwYWNl IG1heSBiZWNvbWUgOCBtaWxsaW9uIC81NiDigJMgdHdvIHRpbWVzIG9mIG9yaWdpbmFsLiBJdCBj b21lcyBmcm9tIGFsaWduLiBUaGUgaW5jcmVhc2VkIHNlbWFudGljcyBiaXQgYXJlIGFsc28gaW5j cmVhc2luZyB0aGUgYWRkcmVzcyBzcGFjZSBhbHRob3VnaCBub3QgaW5jcmVhc2luZyBsaW5lYXJs eS4gU28sIGF0IHRoZSBlbmQsIGl0IGlzIG5vdCB0b3RhbGx5IHdhc3RlLg0KQmVzdCByZWdhcmRz LA0KU2hlbmcNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bV0NClNlbnQ6IFRodXJzZGF5LCBNYXkgMzAsIDIwMTMgMzoxOSBQTQ0KVG86IFNoZW5nIEppYW5n DQpDYzogVGltIENob3duOyBPd2VuIERlTG9uZzsgPHY2b3BzQGlldGYub3JnPjsgZHJhZnQtamlh bmctdjZvcHMtc2VtYW50aWMtcHJlZml4QHRvb2xzLmlldGYub3JnOyBpcHY2QGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuIGxvY2F0 b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMNCg0KT24gVGh1LCBNYXkg MzAsIDIwMTMgYXQgNDoxMyBQTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbTxt YWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpZZXMsIHRoZXJlIGlzIG5vIGlu dGVuc2lvbiB0byBjaGFuZ2UgQVJJTuKAmXMgcG9saWN5IGF0IGFsbC4gQVJJTiBzaG91bGQgcmVt YWluIHRoZSBjdXJyZW50IHBvbGljeSBvZiBhc3NpZ24gSVB2NiBhZGRyZXNzIGJsb2NrLiBCdXQg dGhlIG5ldHdvcmsgcHJvdmlkZXJzLCB3aG8gaGFzIGFscmVhZHkgZ2V0IGFkZHJlc3MgYmxvY2ss IGNhbiBjaG9vc2UgdG8gdXNlIHRoZSBhZGRyZXNzZXMgd2l0aCBjZXJ0YWluIHNlbWFudGljcy4g QW5kIG5vIG9uZSwgaW5jbHVkaW5nIEFSSU4gY2FuIHN0b3AgdGhpcy4NCg0KQWdyZWVkLCBidXQg ZXZlbiBmb3IgbmV0d29yayBwcm92aWRlcnMgdGhhdCBhbHJlYWR5IGhhdmUgYmxvY2tzLCB0aGlz IHdpbGwgYmUgYW4gaXNzdWUgaWYgdGhleSBldmVyIG5lZWQgYW5vdGhlciBibG9jay4gQnV0IEkg ZG8gdGhpbmsgeW91IHNob3VsZCB3cml0ZSB0aGlzIGluIHRoZSBkcmFmdC4NCg0KSG93ZXZlciwg aXQgaXMgbm90IG5lY2Vzc2FyeSBhcyB3b3JzZSBhcyAyXk4gdGltZXMuIEZvciBleGFtcGxlLCBp dCB0aGVyZSBhcmUgMiBiaXRzIHRvIHNlcGFyYXRlIGRpZmZlcmVudCB1c2UgdHlwZXMgKHNheSA0 IGRpZmZlcmVudCB0eXBlcyksIGl0IGFjdHVhbGx5IG9ubHkgc2VwYXJhdGUgdXNlIGFkZHJlc3Mg c3BhY2VzIGludG8gZm91ciBkaWZmZXJlbnQgc3BhY2VzLiBJdCBkb2VzIG5vdCBsaW1pdCB0aGUg YWRkcmVzcyBzcGFjZSB0byBiZSAxLzQgb2Ygb3JpZ2luYWwgc3BhY2UuDQoNCkhvdyBpcyB0aGF0 IGRpZmZlcmVudCBmcm9tIHNheWluZyAiYnkgYWRkaW5nIHR3byBiaXRzIG9mIHNlbWFudGljcyBp biB0aGUgcHJlZml4LCB0aGUgbmV0d29yayB3aWxsIHVzZSA0IHRpbWVzIHRoZSBhZGRyZXNzIHNw YWNlIHRoYW4gaXQgd291bGQgb3RoZXJ3aXNlIj8NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99354nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMi Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jmd0OyZndDtZZXMsIHRoZXJlIGlzIG5vIGludGVuc2lvbiB0byBjaGFuZ2UgQVJJTuKA mXMgcG9saWN5IGF0IGFsbC4gQVJJTiBzaG91bGQgcmVtYWluIHRoZQ0KIGN1cnJlbnQgcG9saWN5 IG9mIGFzc2lnbiBJUHY2IGFkZHJlc3MgYmxvY2suIEJ1dCB0aGUgbmV0d29yayBwcm92aWRlcnMs IHdobyBoYXMgYWxyZWFkeSBnZXQgYWRkcmVzcyBibG9jaywgY2FuIGNob29zZSB0byB1c2UgdGhl IGFkZHJlc3NlcyB3aXRoIGNlcnRhaW4gc2VtYW50aWNzLiBBbmQgbm8gb25lLCBpbmNsdWRpbmcg QVJJTiBjYW4gc3RvcCB0aGlzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtB Z3JlZWQsIGJ1dCBldmVuIGZvciBuZXR3b3JrIHByb3ZpZGVycyB0aGF0IGFscmVhZHkgaGF2ZSBi bG9ja3MsIHRoaXMgd2lsbCBiZSBhbiBpc3N1ZSBpZiB0aGV5IGV2ZXIgbmVlZCBhbm90aGVyIGJs b2NrLiBCdXQgSSBkbyB0aGluayB5b3Ugc2hvdWxkIHdyaXRlIHRoaXMgaW4gdGhlIGRyYWZ0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2lsbCBkby4gVDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmhlIHByb3ZpZGVyLCB3aG8gY2hvb3NlIHN1Y2ggc2NoZW1hLA0KIHNob3VsZCBiZSBhd2FyZSB0 aGF0IHRoZXkgY2Fubm90IGdldCBuZXcgYWRkcmVzcyBibG9jayBvbmx5IGJlY2F1c2UgdGhleSBj b25zdW1lIHRoZWlyIGFkZHJlc3Mgc3BhY2UgaW4gYSBsb3cgdXRpbGl0eSByYXRlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0O0hvd2V2ZXIsIGl0 IGlzIG5vdCBuZWNlc3NhcnkgYXMgd29yc2UgYXMgMl5OIHRpbWVzLiBGb3IgZXhhbXBsZSwgaXQg dGhlcmUgYXJlIDIgYml0cw0KIHRvIHNlcGFyYXRlIGRpZmZlcmVudCB1c2UgdHlwZXMgKHNheSA0 IGRpZmZlcmVudCB0eXBlcyksIGl0IGFjdHVhbGx5IG9ubHkgc2VwYXJhdGUgdXNlIGFkZHJlc3Mg c3BhY2VzIGludG8gZm91ciBkaWZmZXJlbnQgc3BhY2VzLiBJdCBkb2VzIG5vdCBsaW1pdCB0aGUg YWRkcmVzcyBzcGFjZSB0byBiZSAxLzQgb2Ygb3JpZ2luYWwgc3BhY2UuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SG93IGlzIHRoYXQgZGlmZmVyZW50IGZyb20gc2F5aW5nICZxdW90 O2J5IGFkZGluZyB0d28gYml0cyBvZiBzZW1hbnRpY3MgaW4gdGhlIHByZWZpeCwgdGhlIG5ldHdv cmsgd2lsbCB1c2UgNCB0aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGFuIGl0IHdvdWxkIG90aGVy d2lzZSZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Tm8uIFRoaXMgaXMgdmVyeSBkaWZmZXJlbnQuIFB1dHRpbmcgdGhlIGV4YW1wbGUgaW50byBudW1i ZXJzIG1heSBiZSBtb3JlIGludHVpdGlvbmlzdGljLg0KIFNheSBhbiBJU1AgaGFzIDQgbWlsbGlv biBzdWJzY3JpYmVycywgaXQgbmVlZHMgNCBtaWxsaW9uIC81NiAoYXNzdW1pbmcgZXZlcnkgdXNl ciBnZXQgYSAvNTYpLiBCeSBzZXBhcmF0aW5nIHRoZW0gaW50byA0IGRpZmZlcmVudCB0eXBlcywg dGhlIGFkZHJlc3MgY29uc3VtcHRpb24gaXMgc3RpbGwgNCBtaWxsaW9uIC81NiBpZiB0aGUgc2Vw YXJhdGlvbiBpcyBleGFjdGx5IGV2ZW4uIEhvd2V2ZXIsIHRoZSBtb3JlIGFkZHJlc3MgbWF5IG5l ZWQgd2hlbg0KIHRoZSBzZXBhcmF0aW9uIGlzIG5vdCBldmVuLiBGb3IgZXhhbXBsZSwgaWYgdGhl IGJpZ2dlc3QgdXNlciB0eXBlIGhhcyAyIG1pbGxpb24gdXNlcnMsIHRoZW4gdGhlIHRvdGFsIGFk ZHJlc3Mgc3BhY2UgbWF5IGJlY29tZSA4IG1pbGxpb24gLzU2IOKAkyB0d28gdGltZXMgb2Ygb3Jp Z2luYWwuIEl0IGNvbWVzIGZyb20gYWxpZ24uIFRoZSBpbmNyZWFzZWQgc2VtYW50aWNzIGJpdCBh cmUgYWxzbyBpbmNyZWFzaW5nIHRoZSBhZGRyZXNzIHNwYWNlIGFsdGhvdWdoDQogbm90IGluY3Jl YXNpbmcgbGluZWFybHkuIFNvLCBhdCB0aGUgZW5kLCBpdCBpcyBub3QgdG90YWxseSB3YXN0ZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGVuZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9y ZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMzAsIDIw MTMgMzoxOSBQTTxicj4NCjxiPlRvOjwvYj4gU2hlbmcgSmlhbmc8YnI+DQo8Yj5DYzo8L2I+IFRp bSBDaG93bjsgT3dlbiBEZUxvbmc7ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWppYW5n LXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0 aGFuIGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXkgMzAsIDIwMTMg YXQgNDoxMyBQTSwgU2hlbmcgSmlhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpqaWFuZ3NoZW5nQGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5qaWFuZ3NoZW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIHRoZXJlIGlzIG5vIGludGVu c2lvbiB0byBjaGFuZ2UgQVJJTuKAmXMgcG9saWN5IGF0IGFsbC4gQVJJTiBzaG91bGQgcmVtYWlu IHRoZSBjdXJyZW50DQogcG9saWN5IG9mIGFzc2lnbiBJUHY2IGFkZHJlc3MgYmxvY2suIEJ1dCB0 aGUgbmV0d29yayBwcm92aWRlcnMsIHdobyBoYXMgYWxyZWFkeSBnZXQgYWRkcmVzcyBibG9jaywg Y2FuIGNob29zZSB0byB1c2UgdGhlIGFkZHJlc3NlcyB3aXRoIGNlcnRhaW4gc2VtYW50aWNzLiBB bmQgbm8gb25lLCBpbmNsdWRpbmcgQVJJTiBjYW4gc3RvcCB0aGlzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFncmVlZCwgYnV0IGV2ZW4gZm9yIG5ldHdvcmsgcHJv dmlkZXJzIHRoYXQgYWxyZWFkeSBoYXZlIGJsb2NrcywgdGhpcyB3aWxsIGJlIGFuIGlzc3VlIGlm IHRoZXkgZXZlciBuZWVkIGFub3RoZXIgYmxvY2suIEJ1dCBJIGRvIHRoaW5rIHlvdSBzaG91bGQg d3JpdGUgdGhpcyBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGl0IGlzIG5vdCBuZWNlc3NhcnkgYXMgd29yc2Ug YXMgMl5OIHRpbWVzLiBGb3IgZXhhbXBsZSwgaXQgdGhlcmUgYXJlIDIgYml0cw0KIHRvIHNlcGFy YXRlIGRpZmZlcmVudCB1c2UgdHlwZXMgKHNheSA0IGRpZmZlcmVudCB0eXBlcyksIGl0IGFjdHVh bGx5IG9ubHkgc2VwYXJhdGUgdXNlIGFkZHJlc3Mgc3BhY2VzIGludG8gZm91ciBkaWZmZXJlbnQg c3BhY2VzLiBJdCBkb2VzIG5vdCBsaW1pdCB0aGUgYWRkcmVzcyBzcGFjZSB0byBiZSAxLzQgb2Yg b3JpZ2luYWwgc3BhY2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SG93IGlzIHRoYXQgZGlmZmVyZW50IGZyb20gc2F5aW5nICZxdW90O2J5IGFkZGluZyB0d28gYml0 cyBvZiBzZW1hbnRpY3MgaW4gdGhlIHByZWZpeCwgdGhlIG5ldHdvcmsgd2lsbCB1c2UgNCB0aW1l cyB0aGUgYWRkcmVzcyBzcGFjZSB0aGFuIGl0IHdvdWxkIG90aGVyd2lzZSZxdW90Oz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99354nkgeml512mbxchi_-- From markzzzsmith@yahoo.com.au Thu May 30 01:11:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120C521F9467 for ; Thu, 30 May 2013 01:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OivAgwomooMp for ; Thu, 30 May 2013 01:11:09 -0700 (PDT) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) by ietfa.amsl.com (Postfix) with ESMTP id A783B21F97FC for ; Thu, 30 May 2013 01:11:08 -0700 (PDT) Received: from [98.139.215.140] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 08:11:07 -0000 Received: from [98.139.212.231] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 08:11:07 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 30 May 2013 08:11:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 472294.83888.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 78158 invoked by uid 60001); 30 May 2013 08:11:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369901467; bh=y2Xu8fbvHVVC4ZsQekLOr8EIYFKjHAIUhAHQhvAgk48=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WBMV6j3ajqTQvv9GToAKvmIIBJ0GDh39opWOT29JlDvqFF9doL4wCBzrMNuxnyORDMgWW9Eee9Mqv0od3U89pqIfehSXXHyHQaWxQH/PYfrxbeF88Kgbp51d/d35z8Uf0xlm+pl7pZNlGUYnL8t4POncRnSK1NC/Q7GIeyIW8p8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VUiqSOl/OMzUGPwWq8qu0CJCFsQgiBnfmXN/VDAhwy7YZrdKYzsnchv2yjdc0J7PkUzcU5Q3sfz3xbnVPSz5RBzeAWX8+1i62F3ddQQzxkgO2uK36zKK8AFz4leDAbWrUwiVDRyEWm15fAjEvdHiUAnO+lQ/tCMnHR6rP0/IzzQ=; X-YMail-OSG: eYiPTN8VM1lEdRhvJYOMBatmuUWXEr3wt8fd7_ZyopfH7nn skwbg3SsmyIs_c2lPML.MkBei8zzODyUAzWApSfyN55wKMj9r_4ASbkZfMRK 0daULEXfu5llS5pOjsLHp8RC9l1Xb8aHdAQ.h71ugqcemWEnpBBXurEgPbGU i2hJLCcFSgg.1x3zMKb3BVmTatLgK8kEaPdqfkcqrJOTDOOSTfBK13iVPtO_ Dj3TC59vn9VTRySSLAY3Q7EhjI5KG2XDcZjhmeMz_wJF1I.Ed3EMbhfjVHhQ PgrBZzUo3sKibn_Auf.J1sNJgHukDBOtgln2G.b86fiF2J6KQ8Svc2GVMJb7 37dguivYAZnCYBTAnfUcEqgvogFAN7XD5v.KtJgzZoqu3D7it8.pqKjpuJVe rqFlJRGWCSqKNfhJYaXaIP7Nsxh2eo27jvO_D2qRa91mpOPUUQi1CUPR3jzk qSH7LZVEd3FU3FI13nSsXTnISl5M2_tQDesB0cq9zoiXGGiMUae_yHhES32D dmv451IALiXSvLOexmELpFCO0K_al0BHiMXqy2AL2YAtqTJxbK74kQnbW60K fhbOqLGec Received: from [121.200.231.211] by web142506.mail.bf1.yahoo.com via HTTP; Thu, 30 May 2013 01:11:07 PDT X-Rocket-MIMEInfo: 002.001, Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20.Cj5UbzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.IAo.Q2M6ICJkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnNAdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnNAdG9vbHMuaWV0Zi5vcmc.IAo.U2VudDogVGh1cnNkYXksIDMwIE1heSAyMDEzIDQ6NDEgUE0KPlN1YmoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: Message-ID: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Thu, 30 May 2013 01:11:07 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti , "v6ops@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:11:18 -0000 >________________________________=0A> From: Lorenzo Colitti =0A>To: "v6ops@ietf.org WG" =0A>Cc: "draft-ietf-v6ops= -ula-usage-recommendations@tools.ietf.org" =0A>Sent: Thursday, 30 May 2013 4:41 PM=0A>Subj= ect: [v6ops] A good example of why we need to careful about ULAs=0A> =0A>= =0A>=0A>News at 11:=0A>=0A>=0A>1. ULAs leak.=0A>=0A>2. People assign ULAs b= y hand.=0A>=0A=0AIn the early news, not really a new problem.=0A=0ARFC1918 = and 100.64/10 leak too, and what is worse, I've seen people intentionally e= xpose RFC1918s to other networks - the largest carrier here in .au uses RFC= 1918 addresses for their wholesale ADSL L2TP LACs (from memory, at least 20= to 30, spread across multiple /16s within 172.16/12) and then expect their= many wholesale ADSL customers' to just accept those addresses and make the= m work within their own networks, despite their own, quite legitimate inter= nal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that add= ress space from your own). So we can't pretend that RFC1918s have been perf= ectly used, and therefore ULAs being less private than intended is going to= be new problem and experience. At least properly formed ULAs are unlikely = to conflict with other network's ones, even if the other network has used f= d00::/8, and if the two interconnecting parties have both been lazy and use= d fd00::/8, they'll both be victims of theirs and the other party's laziness (which they'll be used to, since they've probably experie= nced it with RFC1918). They'll probably resort to NPTv6 to fix it, because = that is what they're used to, rather than using IPv6's address aging mechan= isms to renumber to a properly formed ULA. Good luck to them, as long as it= doesn't effect the rest of us.=0A=0A=0A>=0A=0A>Yes, both of these a violat= ion of IETF guidance. I don't think that matters much, though - while we ca= n always claim that the implementer/operator is "holding it wrong", we shou= ld be careful that what we design/standardize is hard to misconfigure and p= ossibly robust in the face of misconfiguration. Subtle nuances like "these = addresses are global scope, but not globally routable" tend to get lost ver= y easily.=0A>=0A=0AI think recommending against ULAs is just going to resul= t in people stealing other address spaces for devices that don't need globa= l reachability - like 2001:db8::/32, or unused global address space (as we = saw with 1/8, 5/8 and other IPv4 prefixes).=0A=0AI think global address spa= ce comes with and implies a default assumption of global reachability, and = you'll therefore have to actively take measures to ensure they don't provid= e global reachability if you don't want it. Link-locals don't cut it becaus= e they're not routable. The need ULAs fulfils is the gap in between global = space and link-locals, and the one which RFC1918 generally fulfils in IPv4,= except that the likelyhood of address space collision is reduced.=0A=0A>= =0A>Of course, in the case of ULAs, there's not much that can be done about= the design at this point, but we should make an effort to make it clear th= at the potential for misconfiguration exists and provide clear guidance on = how not to misconfigure them.=0A>=0A>=0A=0A>Personally, I think that provid= ing said guidance is much more useful and important than enumerating scenar= ios that aren't widely, if at all, implemented, and I hope that the authors= of=A0draft-ietf-v6ops-ula-usage-recommendations will agree.=0A>=0A=0ASo is= this draft aiming for BCP status and therefore should only reflect best co= mmon practice? If not, I think it is reasonable to present scenarios where = ULAs could be useful.=A0We've got a lot of experience with private address = spaces from IPv4 (the=A0Deprecating Site Local Addresses RFC3879 is also a = pretty complete list of the problems with RFC1918 addresses), so the only r= eal difference is scenarios where concurrent global and private address spa= ces could be useful. In some cases, they'll just be more capable versions o= f what we've already doing in IPv4 e.g. private addressed loopbacks on rout= ers, global addresses on the links, in a ULA environment you would add ULAs= to the links too, which could make troubleshooting and other OAM less depe= ndent on the global address space.=0A=0ARegards,=0AMark.=0A=0A>=0A>Cheers,= =0A>Lorenzo=0A>=0A>=0A>---------- Forwarded message ----------=0A>From: Jer= oen Massar =0A>Date: Thu, May 30, 2013 at 4:59 AM=0A>Subj= ect: Usage of fd00::/8 on the Interwebz - something with filters and uRPF= =0A>To: ipv6-ops@lists.cluenet.de=0A>=0A>=0A>...=0A>=A04 =A02001:7f8:1::a50= 0:3303:1 (2001:7f8:1::a500:3303:1) =A020.755 ms =A020.763 ms =A020.784 ms= =0A>=A05 =A0fd00:3303::1 (fd00:3303::1) =A022.010 ms =A021.984 ms =A021.986= ms=0A>=A06 =A02a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) =A017.806 ms= =A017.889 ms =A017.842 ms=0A>=A07 =A02a02:120c:1051:d010::1 (2a02:120c:105= 1:d010::1) =A018.720 ms =A018.593 ms =A018.617 ms=0A>...=0A>=0A>Hmmmm fd00:= :/8, that really should never ever be visible on the Internet, being Unique= *LOCAL* Addresses.=0A>And it does not look like they applied the randomnes= s bit for picking a prefix either.=0A>You would also almost think that a /2= 8 is more than enough address space to put a few router loopbacks in.=0A>= =0A>It is apparently time for people to start checking their filters again = because it seems that these packets leak into other ASNs too...=0A>=0A>More= generally, do recheck your network for BCP38 compliance, please do apply i= t and require your peers to do the same!=0A>=0A>Greets,=0A>=A0Jeroen=0A>=0A= >=0A>_______________________________________________=0A>v6ops mailing list= =0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>= =0A> From jiangsheng@huawei.com Thu May 30 01:47:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD6821F975C; Thu, 30 May 2013 01:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 287gIDM5VIfw; Thu, 30 May 2013 01:46:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3225D21F9758; Thu, 30 May 2013 01:46:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH88660; Thu, 30 May 2013 08:46:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 09:46:15 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 09:46:48 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Thu, 30 May 2013 16:46:42 +0800 From: Sheng Jiang To: Tim Chown Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAIm9sP//gNoAgACfxeA= Date: Thu, 30 May 2013 08:46:41 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9940B@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:47:01 -0000 DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFRpbSBDaG93biBbbWFpbHRv OnRqY0BlY3Muc290b24uYWMudWtdDQo+U2VudDogVGh1cnNkYXksIE1heSAzMCwgMjAxMyAzOjEx IFBNDQo+VG86IFNoZW5nIEppYW5nDQo+Q2M6IE93ZW4gRGVMb25nOyA8djZvcHNAaWV0Zi5vcmc+ Ow0KPmRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2 NkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIENvdWxkIElQdjYgYWRkcmVzcyBiZSBt b3JlIHRoYW4NCj5sb2NhdG9yPy8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAz DQo+DQo+T24gMzAgTWF5IDIwMTMsIGF0IDA4OjAwLCBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0Bo dWF3ZWkuY29tPiB3cm90ZToNCj4+Pg0KPj4+IEkgYWdyZWUuIFRoYXQgc2FpZCwgYW4gSVNQLCBl bnRlcnByaXNlIG9yIGdyb3VwIG9mIG9yZ2FuaXNhdGlvbnMgY2FuIGZvbGxvdw0KPj4+IHdoYXRl dmVyIHNlbWFudGljcyB0aGV5IHdpc2ggd2l0aGluIHRoZWlyIG93biBib3JkZXJzLiBKdXN0IGRv bid0IGV4cGVjdA0KPj4+IGFueW9uZSBlbHNlIHRvIGZvbGxvdyBvciB1c2UgdGhvc2Ugc2VtYW50 aWNzLiAgV2hhdCBTaGVuZyBpcyBwcm9wb3NpbmcgaXMNCj4+PiBjbGVhcmx5IHN0YXRlZCBhcyBv bmx5IGJlaW5nIGZvciBpbnRlcnByZXRhdGlvbiBiZXR3ZWVuIGFncmVlaW5nDQo+Pj4gb3JnYW5p c2F0aW9ucy4NCj4+DQo+PiBIaSwgVGltLA0KPj4NCj4+IEl0IGlzIGV4YWN0bHkgd2hhdCB0aGUg ZHJhZnQgZG9jdW1lbnQuIFRoZXNlIHNlbWFudGljcyBpcyBvbmx5IG1lYW5pbmdmdWwNCj5sb2Nh bGx5IHdpdGhpbiB0aGUgYXNzaWduaW5nIHByb3ZpZGVyIG5ldHdvcmsuIEl0IG1heSBvbmx5IGJl IGludGVycHJldGF0aW9uDQo+YmV0d2VlbiBhZ3JlZWluZyBwcm92aWRlcnMuDQo+Pg0KPj4gQW55 IGVmZm9ydHMgdG8gYWRkIGdsb2JhbCBvciBnZW5lcmljIHNlbWFudGljcyB0byBJUCBhZGRyZXNz IGlzIG92ZXJsb2FkIHRoZQ0KPklQIGFyY2hpdGVjdHVyZSBhbmQgaXQgYmFkIGRpcmVjdGlvbiwg SSBhZ3JlZS4NCj4+DQo+Pj4gSSB0aGluayBwZW9wbGUgd2lsbCBkbyB0aGlzIHR5cGUgb2YgdGhp bmcsIHNvIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQNCj4+PiBkaXNjdXNzaW5nIHRoZSBwcm9z IGFuZCBjb25zLCBhbmQgaG93IHNlbWFudGljcyBjYW4gYmUgdXNlZCwgaXMgcHJvYmFibHkgYQ0K Pj4+IGdvb2QgdGhpbmcuICBQZXJoYXBzIGEgIlBvdGVudGlhbCBQaXRmYWxscyIgdHlwZSBzZWN0 aW9uIGFmdGVyIHRoZQ0KPiJQb3RlbnRpYWwNCj4+PiBCZW5lZml0cyIgc2VjdGlvbiB3b3VsZCBi YWxhbmNlIHRoZSBkb2N1bWVudCBhIGxpdHRsZSBiZXR0ZXI/DQo+Pg0KPj4gWWVzLiBXZSB3aWxs IGRvIHNvIGluIHRoZSBmdXR1cmUgdmVyc2lvbi4NCj4NCj5Hb29kLCBhbmQgSSB0aGluayBpdCdz IGltcG9ydGFudCB0byBkbyBzby4gR2VvcmdlIGFuZCBMb3JlbnpvJ3MgY29tbWVudHMgYXJlDQo+ Z29vZCBzdGFydGluZyBwb2ludHMgZm9yIHRoYXQgc2VjdGlvbi4gVGhlIHBvdGVudGlhbCBwcml2 YWN5L2luZm9ybWF0aW9uDQo+bGVha2FnZSBhc3BlY3QgaXMgYWxzbyB3b3J0aCBjYXB0dXJpbmcs IHNob3VsZCB0aG9zZSBhZGRyZXNzZXMgYmUgc2Vlbg0KPm91dHNpZGUgdGhlIG9yZ2FuaXNhdGlv bi4NCg0KVGhhbmtzLCBUaW0uIFRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgbm90IHJl Y29tbWVuZCBvciBwcm9wb3NlIGEgZ29vZCBhcmNoaXRlY3R1cmUuIEl0IGlzIHRvIGRvY3VtZW50 IHNvbWV0aGluZyB0aGF0IGlzIGdvaW5nIHRvIGV4aXN0IGFuZCBhbmFseXplIGl0LiBUaGUgcGl0 ZmFsbHMgaXMgdmVyeSBpbXBvcnRhbnQgZm9yIGEgbmV1dHJhbCBhbmFseXNpcw0KDQpDaGVlcnMs DQoNClNoZW5nDQoNCj42cmQgaXMgYSBnb29kIGV4YW1wbGUgb2YgYSBzY2hlbWUgdGhhdCB0eXBp Y2FsbHkgcmVxdWlyZXMgYSBsYXJnZXIgYWxsb2NhdGlvbg0KPmZyb20gdGhlIFJJUiBwdXJlbHkg YmVjYXVzZSBvZiB0aGUgc2VtYW50aWNzIHVzZWQuICBCdXQgaW4gc29tZSBjYXNlcyB0aGUNCj5z ZW1hbnRpY3MgbmVlZCBub3QgcmVxdWlyZSBhIGxhcmdlciBhbGxvY2F0aW9uOyB3ZSBjb3VsZCBp bmNsdWRlIHNlbWFudGljcyBpbg0KPmEgY2FtcHVzIC80OCBmb3IgZXhhbXBsZS4NCj4NCj5UaW0N Cg== From lorenzo@google.com Thu May 30 02:07:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262CF21F9814 for ; Thu, 30 May 2013 02:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzt0ApMReCVO for ; Thu, 30 May 2013 02:07:34 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id D30ED21F97EC for ; Thu, 30 May 2013 02:07:33 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so5778794qeb.31 for ; Thu, 30 May 2013 02:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Op3IgcaXQHW6N2N4+nyQa97vrB90EDRQ3Xj6xEgi1UA=; b=VZl24QFAMm7Se4dEsUsLowoWyQMIOh4sPcrL+SUUfIwjooxKQCqLxpB85omq1EOpVE 3jlSRWxyAjKMU4vshA/JwYEwAaLUwcKMat67IdM29Rc0tXMj2cQ+enjvtVR1npZSqByJ Ph+xP9rZJrSvL4ilBq1UDdUKP14GRnWaSwszler4BWwRkRbe21puips+MdnSwBOjIkid BVdXMGXE9DkpKyrx1jw4t4O/NFtdr1zoY/B0h7Rhadcdzf/ekorJV7/OeuZQd/5F/lk5 wfqalRaBECwllC7kGCiGbhWiEyjFj1J0ndo7bV2myIEPghDl6LKyMl0p6VbznO2icIjN Ndjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Op3IgcaXQHW6N2N4+nyQa97vrB90EDRQ3Xj6xEgi1UA=; b=HYrQjQnCc0mJl/EZf0x5qHsV8tAnX4gAiMBjVeImE1XmcbqfPwgdftprXAPY7kSF8+ 3vJIr5eY2Ey0Hw+vxgLtawq+pdQLOEsKUd/Ix235MiT0f9qo0zHApgdUVWIE3P7D/9MW rmYxYe37QFsCs53yLh3wXkH1jXEJ1TMQ0nmoUzmRq5AR/UyS2uwe1rw0Kwf9FT53yoJk TGvjmA6iqrCSRfW6w+P05luvsIItZT4d7JYLZNNSbycAc7xhrOeKW/hIsDvwLKF6q2pV xSYGu7/QHDVBWmIyIC3vjxF9cJ1Q6mbXmaOG6dpA+aOj2mP8ZhnSkPJvN9mqACwoDyWb zZIw== X-Received: by 10.224.38.133 with SMTP id b5mr6008273qae.78.1369904853226; Thu, 30 May 2013 02:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Thu, 30 May 2013 02:07:12 -0700 (PDT) In-Reply-To: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Thu, 30 May 2013 18:07:12 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a11c29f6027702b04ddebd4a6 X-Gm-Message-State: ALoCoQkhF/fP685qejF9VCuqbVNA4YZA7x9uPUhMQiFKZfBq2nMhl022bh5lODOFqIYYTiIaR/rHkjmioquDV2r661aHuyIjxeTmd/XaNIRcmCQwClCZvGIPwZJvM6oh8bKnrvoobnf6Ejy1k+I7n4kYbhS0uOnDq6TQ0lEEkDRb4wBm94SWEq3CFrx1YTLYUMTOQGvdve1U Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 09:07:39 -0000 --001a11c29f6027702b04ddebd4a6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 30, 2013 at 5:11 PM, Mark Smith wrote: > In the early news, not really a new problem. > The part where an RFC asserts says that we can generate globally unique addresses with no global coordination is a new problem. Yes, in theory it works, but in practice it doesn't, because everyone ends up using fd00:: - because that's the way it worked in IPv4, and ULA is just RFC1918 all over again, right? The key point here is that people are going to assume is that ULA is like RFC1918 and we should carefully document all the ways in which it isn't. So is this draft aiming for BCP status and therefore should only reflect > best common practice? > I think documents coming out of v6ops should reflect scenarios where there is operational experience. I don't think v6ops is the place to say "here's what we could build". It's the place to say "here's what we've built; here's what works, and here's what doesn't". As an example: we've already discovered one of the use cases in this draft (the "use ULA as a pref64") is not a use case after all, because it causes devices to prefer IPv4 transition technologies like 464xlat over NAT64. We didn't know this because nobody had actually tried to *operate a network* in such a use case. I happened to catch that one because I wrote and tested an implementation, but who knows if there are caveats in any of the others? If as an operational group we publish guidance to operators that doesn't work in the real world (like the pref64 case above), it will be embarrassing for us and wasteful of operators' time. We should strive to do better than that. --001a11c29f6027702b04ddebd4a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2013 at 5:11 PM, Mark Smith <mark= zzzsmith@yahoo.com.au> wrote:
=

In the early news, not really a new problem.=

The part where an RFC asserts sa= ys that we can generate globally unique addresses with no global coordinati= on is a new problem. Yes, in theory it works, but in practice it doesn'= t, because everyone ends up using fd00:: - because that's the way it wo= rked in IPv4, and ULA is just RFC1918 all over again, right?

The key point here is that people are going= to assume is that ULA is like RFC1918 and we should carefully document all= the ways in which it isn't.

So is this draft aimi= ng for BCP status and therefore should only reflect best common practice?

I think documents coming = out of v6ops should reflect scenarios where there is operational experience= . I don't think v6ops is the place to say "here's what we coul= d build". It's the place to say "here's what we've bu= ilt; here's what works, and here's what doesn't".

As an example: we've already discovered= one of the use cases in this draft (the "use ULA as a pref64") i= s not a use case after all, because it causes devices to prefer IPv4 transi= tion technologies like 464xlat over NAT64. We didn't know this because = nobody had actually tried to *operate a network* in such a use case. I happ= ened to catch that one because I wrote and tested an implementation, but wh= o knows if there are caveats in any of the others?

If as an operational group we publish guida= nce to operators that doesn't work in the real world (like the pref64 c= ase above), it will be embarrassing for us and wasteful of operators' t= ime. We should strive to do better than that.

--001a11c29f6027702b04ddebd4a6-- From v6ops@globis.net Thu May 30 02:24:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1392B21F97B7; Thu, 30 May 2013 02:24:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7H1gG-Nw2Ql; Thu, 30 May 2013 02:24:49 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78621F97B3; Thu, 30 May 2013 02:24:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A2EFF8700E7; Thu, 30 May 2013 11:24:33 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8rxElZdLc9R; Thu, 30 May 2013 11:24:33 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 30C3F870077; Thu, 30 May 2013 11:24:33 +0200 (CEST) Message-ID: <51A71ACA.3000608@globis.net> Date: Thu, 30 May 2013 11:24:26 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 09:24:50 -0000 Sheng Jiang wrote: > IP addresses are designed as topology locator, so that every packet can be routed to its network destination. > > However, even in IPv4 era, some network operators have mapped their IP address with certain semantic locally. These kind of mechanism explicitly express the semantic properties of every packet. Consequently, these network operators can inspect the properties of packets easily by mapping the addresses back to semantic. > > Network operators, who have large IPv6 address space, may also choose to embedded some semantics into IPv6 addresses by assigning additional significance to specific bits within the prefix. draft-jiang-v6ops-semantic-prefix documents a framework method that network operations may use their addresses with embedded semantics. These semantics bits are only meaningful within a single network, or group of interconnected networks which share a common addressing policy. Based on these embedded semantic bits in source/destination addresses, the network operators can accordingly treat network packets differently and efficiently. > > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 > > Could you please review this draft and comments? It will help the document become more useful information to be shared. > > Best regards, > > Sheng > I completely understand the desire for operators to have additional semantics available for customized packet processing. Flow label now has very limited properties optimised for load balancers. DSCP only has a few bits (way less than the number of customers' policies). ACLs are heavy to process at each hop.... But wouldn't this information be better off encoded as tags in one or more hop-by-hop header options (that could be re-written on the fly), rather than encoded in the IPv6 address space? regards, RayH From jiangsheng@huawei.com Thu May 30 02:58:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0265A21F9590; Thu, 30 May 2013 02:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah1P33S+2hpl; Thu, 30 May 2013 02:58:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DB5DA21F8F0C; Thu, 30 May 2013 02:58:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY12916; Thu, 30 May 2013 09:58:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 10:58:06 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 10:58:36 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Thu, 30 May 2013 17:58:30 +0800 From: Sheng Jiang To: Ray Hunter Thread-Topic: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kc8GIAgACHYyA= Date: Thu, 30 May 2013 09:58:29 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> In-Reply-To: <51A71ACA.3000608@globis.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 09:58:50 -0000 Pj4gSVAgYWRkcmVzc2VzIGFyZSBkZXNpZ25lZCBhcyB0b3BvbG9neSBsb2NhdG9yLCBzbyB0aGF0 IGV2ZXJ5IHBhY2tldCBjYW4gYmUNCj5yb3V0ZWQgdG8gaXRzIG5ldHdvcmsgZGVzdGluYXRpb24u DQo+Pg0KPj4gSG93ZXZlciwgZXZlbiBpbiBJUHY0IGVyYSwgc29tZSBuZXR3b3JrIG9wZXJhdG9y cyBoYXZlIG1hcHBlZCB0aGVpciBJUA0KPmFkZHJlc3Mgd2l0aCBjZXJ0YWluIHNlbWFudGljIGxv Y2FsbHkuIFRoZXNlIGtpbmQgb2YgbWVjaGFuaXNtIGV4cGxpY2l0bHkNCj5leHByZXNzIHRoZSBz ZW1hbnRpYyBwcm9wZXJ0aWVzIG9mIGV2ZXJ5IHBhY2tldC4gQ29uc2VxdWVudGx5LCB0aGVzZSBu ZXR3b3JrDQo+b3BlcmF0b3JzIGNhbiBpbnNwZWN0IHRoZSBwcm9wZXJ0aWVzIG9mIHBhY2tldHMg ZWFzaWx5IGJ5IG1hcHBpbmcgdGhlDQo+YWRkcmVzc2VzIGJhY2sgdG8gc2VtYW50aWMuDQo+Pg0K Pj4gTmV0d29yayBvcGVyYXRvcnMsIHdobyBoYXZlIGxhcmdlIElQdjYgYWRkcmVzcyBzcGFjZSwg bWF5IGFsc28gY2hvb3NlIHRvDQo+ZW1iZWRkZWQgc29tZSBzZW1hbnRpY3MgaW50byBJUHY2IGFk ZHJlc3NlcyBieSBhc3NpZ25pbmcgYWRkaXRpb25hbA0KPnNpZ25pZmljYW5jZSB0byBzcGVjaWZp YyBiaXRzIHdpdGhpbiB0aGUgcHJlZml4Lg0KPmRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXBy ZWZpeCBkb2N1bWVudHMgYSBmcmFtZXdvcmsgbWV0aG9kIHRoYXQNCj5uZXR3b3JrIG9wZXJhdGlv bnMgbWF5IHVzZSB0aGVpciBhZGRyZXNzZXMgd2l0aCBlbWJlZGRlZCBzZW1hbnRpY3MuIFRoZXNl DQo+c2VtYW50aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aXRoaW4gYSBzaW5nbGUgbmV0 d29yaywgb3IgZ3JvdXAgb2YNCj5pbnRlcmNvbm5lY3RlZCBuZXR3b3JrcyB3aGljaCBzaGFyZSBh IGNvbW1vbiBhZGRyZXNzaW5nIHBvbGljeS4gQmFzZWQgb24NCj50aGVzZSBlbWJlZGRlZCBzZW1h bnRpYyBiaXRzIGluIHNvdXJjZS9kZXN0aW5hdGlvbiBhZGRyZXNzZXMsIHRoZSBuZXR3b3JrDQo+ b3BlcmF0b3JzIGNhbiBhY2NvcmRpbmdseSB0cmVhdCBuZXR3b3JrIHBhY2tldHMgZGlmZmVyZW50 bHkgYW5kIGVmZmljaWVudGx5Lg0KPj4NCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMw0KPj4NCj4+IENvdWxkIHlvdSBwbGVh c2UgcmV2aWV3IHRoaXMgZHJhZnQgYW5kIGNvbW1lbnRzPyBJdCB3aWxsIGhlbHAgdGhlIGRvY3Vt ZW50DQo+YmVjb21lIG1vcmUgdXNlZnVsIGluZm9ybWF0aW9uIHRvIGJlIHNoYXJlZC4NCj4+DQo+ PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gU2hlbmcNCj4+DQo+SSBjb21wbGV0ZWx5IHVuZGVyc3Rh bmQgdGhlIGRlc2lyZSBmb3Igb3BlcmF0b3JzIHRvIGhhdmUgYWRkaXRpb25hbA0KPnNlbWFudGlj cyBhdmFpbGFibGUgZm9yIGN1c3RvbWl6ZWQgcGFja2V0IHByb2Nlc3NpbmcuIEZsb3cgbGFiZWwg bm93IGhhcw0KPnZlcnkgbGltaXRlZCBwcm9wZXJ0aWVzIG9wdGltaXNlZCBmb3IgbG9hZCBiYWxh bmNlcnMuIERTQ1Agb25seSBoYXMgYQ0KPmZldyBiaXRzICh3YXkgbGVzcyB0aGFuIHRoZSBudW1i ZXIgb2YgY3VzdG9tZXJzJyBwb2xpY2llcykuIEFDTHMgYXJlDQo+aGVhdnkgdG8gcHJvY2VzcyBh dCBlYWNoIGhvcC4uLi4NCj4NCj5CdXQgd291bGRuJ3QgdGhpcyBpbmZvcm1hdGlvbiBiZSBiZXR0 ZXIgb2ZmIGVuY29kZWQgYXMgdGFncyBpbiBvbmUgb3INCj5tb3JlIGhvcC1ieS1ob3AgaGVhZGVy IG9wdGlvbnMgKHRoYXQgY291bGQgYmUgcmUtd3JpdHRlbiBvbiB0aGUgZmx5KSwNCj5yYXRoZXIg dGhhbiBlbmNvZGVkIGluIHRoZSBJUHY2IGFkZHJlc3Mgc3BhY2U/DQoNClRoZSBzZWN0aW9uIDQu MSAiSnVzdGlmY2F0aW9uIGZvciBTZW1hbnRpY3Mgd2l0aCB0aGUgSVB2NiBQcmVmaXgiIGRlc2Ny aWJlcyB0aGUgcmVhc29ucy4NCg0KVXNlcnMgbWF5IGVhc2lseSBjaGFuZ2UgdGhlIHNldHRpbmcg b2YgZXh0ZW5zaW9uIGhlYWRlciBpbiBvcmRlciB0byBvYnRhaW4gdW5kZXNlcnZlZCBwcmlvcml0 aWVzL3ByaXZpbGVnZXMuIFNlbWFudGljIHByZWZpeCBhcHByb2FjaCBkb2VzIHJlcXVpcmUgdGhl IGRlcGxveW1lbnQgb2YgYWNjZXNzIGNvbnRyb2wgZmlsdGVycy4gVGhlIHBhY2tldHMgd2l0aCB0 aGUgbm9uY29tcGxpYW5jZSBzb3VyY2UgYWRkcmVzc2VzIHNob3VsZCBiZSBmaWx0ZXJlZC4gVGhl IHByZWZpeCBpcyBkZWxlZ2F0ZWQgYnkgdGhlIG5ldHdvcmsuIFRoZXJlZm9yZSB0aGUgbmV0d29y ayBpcyBhYmxlIHRvIGRldGVjdCBhbnkgdW5kZXNpcmVkIG1vZGlmaWNhdGlvbnMgYW5kIGZpbHRl ciB0aGUgcGFja2V0IGFjY29yZGluZ2x5Lg0KDQpDaGVlcnMsDQoNClNoZW5nDQoNCj5yZWdhcmRz LA0KPlJheUgNCg== From aservin@lacnic.net Thu May 30 03:52:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6962E21F8F7A for ; Thu, 30 May 2013 03:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=1.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q3BcozI1+5U for ; Thu, 30 May 2013 03:51:44 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0B55821F8B05 for ; Thu, 30 May 2013 03:51:42 -0700 (PDT) Received: from www.lacnic.net.uy (micron [200.7.84.3]) by mail.lacnic.net.uy (Postfix) with ESMTP id B8B7B308432 for ; Thu, 30 May 2013 07:51:26 -0300 (UYT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 May 2013 07:51:26 -0300 From: aservin To: Mail-Reply-To: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> Message-ID: <5f5db848326ae00c249cff068956b4fc@mail.lacnic.net.uy> X-Sender: aservin@lacnic.net User-Agent: RoundCube Webmail/0.5 X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] =?utf-8?q?Could_IPv6_address_be_more_than_locator=3F//dra?= =?utf-8?q?ft-jiang-v6ops-semantic-prefix-03?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aservin@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 10:52:26 -0000 >>> Sheng >>> >>I completely understand the desire for operators to have additional >>semantics available for customized packet processing. Flow label now >> has >>very limited properties optimised for load balancers. DSCP only has a >>few bits (way less than the number of customers' policies). ACLs are >>heavy to process at each hop.... >> >>But wouldn't this information be better off encoded as tags in one or >>more hop-by-hop header options (that could be re-written on the fly), >>rather than encoded in the IPv6 address space? > > The section 4.1 "Justifcation for Semantics with the IPv6 Prefix" > describes the reasons. > > Users may easily change the setting of extension header in order to > obtain undeserved priorities/privileges. Semantic prefix approach > does > require the deployment of access control filters. The packets with > the > noncompliance source addresses should be filtered. The prefix is > delegated by the network. Therefore the network is able to detect any > undesired modifications and filter the packet accordingly. > > Cheers, > > Sheng > >>regards, >>RayH I think the user can play the system too with IP addresses. It may be more complicated but it may be possible with the enough motivation to do so. /as From v6ops@globis.net Thu May 30 04:11:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055F621F9133; Thu, 30 May 2013 04:11:53 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZLbd9fBukyt; Thu, 30 May 2013 04:11:52 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF61021F9121; Thu, 30 May 2013 04:11:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0F214870077; Thu, 30 May 2013 13:11:36 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMPUWCgNYgFd; Thu, 30 May 2013 13:11:35 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E3CF287002E; Thu, 30 May 2013 13:11:35 +0200 (CEST) Message-ID: <51A733E1.7040008@globis.net> Date: Thu, 30 May 2013 13:11:29 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 11:11:53 -0000 > Sheng Jiang > 30 May 2013 11:58 >>> IP addresses are designed as topology locator, so that every packet can be >> routed to its network destination. >>> However, even in IPv4 era, some network operators have mapped their IP >> address with certain semantic locally. These kind of mechanism explicitly >> express the semantic properties of every packet. Consequently, these network >> operators can inspect the properties of packets easily by mapping the >> addresses back to semantic. >>> Network operators, who have large IPv6 address space, may also choose to >> embedded some semantics into IPv6 addresses by assigning additional >> significance to specific bits within the prefix. >> draft-jiang-v6ops-semantic-prefix documents a framework method that >> network operations may use their addresses with embedded semantics. These >> semantics bits are only meaningful within a single network, or group of >> interconnected networks which share a common addressing policy. Based on >> these embedded semantic bits in source/destination addresses, the network >> operators can accordingly treat network packets differently and efficiently. >>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>> >>> Could you please review this draft and comments? It will help the document >> become more useful information to be shared. >>> Best regards, >>> >>> Sheng >>> >> I completely understand the desire for operators to have additional >> semantics available for customized packet processing. Flow label now has >> very limited properties optimised for load balancers. DSCP only has a >> few bits (way less than the number of customers' policies). ACLs are >> heavy to process at each hop.... >> >> But wouldn't this information be better off encoded as tags in one or >> more hop-by-hop header options (that could be re-written on the fly), >> rather than encoded in the IPv6 address space? > > The section 4.1 "Justifcation for Semantics with the IPv6 Prefix" describes the reasons. > > Users may easily change the setting of extension header in order to obtain undeserved priorities/privileges. Semantic prefix approach does require the deployment of access control filters. The packets with the noncompliance source addresses should be filtered. The prefix is delegated by the network. Therefore the network is able to detect any undesired modifications and filter the packet accordingly. > > Cheers, > > Sheng > > I don't buy your justification. Whether an operator filters on authorised address range or re-writes/filters an unauthorised hop-by-hop tag is effectively the same IMHO. We have exactly the same issues of potential theft of service with DSCP today, and the solution is equally simple: DSCP markdown at the ingress port. regards, RayH From arturo.servin@gmail.com Thu May 30 05:46:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF55D21F86AE; Thu, 30 May 2013 05:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mytzptSRA+LC; Thu, 30 May 2013 05:46:16 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB621F93E8; Thu, 30 May 2013 05:46:13 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id nd7so88425qeb.24 for ; Thu, 30 May 2013 05:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w82eZ54PnVjN8Sg2z5ff7RsZSsbXEWB7udOI966ibCE=; b=GJBpNWfwavGqAt6whgQSdN8T/J2Jxyk4oLbzolb4ky32guBHWTjBT+Bmejqo6hM++H XVDCeFp6tHr92nb/ZIAxOLyqqqFWseDKc/14Nq9raPuPKvBKzMk3HPOG4K+8bMKSAR7o 06lAE5+UvtolTFN55b0uPQhGl+Rq62Jb2XTXZ0piVhKZQdLfr5zZBr3ruWtFeqE9wOzE Wifvk2OE6yO0Q/6kiUjW+hl4S/b9khCj41/1mWsr6Obe4pzJls1AnmBbdnp3OqXOX1ns jugPL1yxLOn2oZ11pLmG2VZ6gTl3F9P1u4juvMAzQllaVJqfs+JaZzdt3/DT2pdjjH39 Jbvw== X-Received: by 10.229.11.7 with SMTP id r7mr2380203qcr.61.1369917972726; Thu, 30 May 2013 05:46:12 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([200.7.87.33]) by mx.google.com with ESMTPSA id hs4sm35202977qeb.8.2013.05.30.05.46.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 05:46:11 -0700 (PDT) Message-ID: <51A74A18.3060600@gmail.com> Date: Thu, 30 May 2013 09:46:16 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9940B@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC9940B@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-jiang-v6ops-semantic-prefix@tools.ietf.org, ipv6@ietf.org, v6ops@ietf.org Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Arturo Servin List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 12:46:21 -0000 >>> Yes. We will do so in the future version. >> >>Good, and I think it's important to do so. George and Lorenzo's >> comments are >>good starting points for that section. The potential >> privacy/information >>leakage aspect is also worth capturing, should those addresses be >> seen >>outside the organisation. > > Thanks, Tim. The purpose of this document is not recommend or propose > a good architecture. It is to document something that is going to > exist and analyze it. The pitfalls is very important for a neutral > analysis > > Cheers, > > Sheng Sheng, Yes please do this. To me it now it reads more like "you can do this, we recommend you to do it" when it should say "you can do this, it is bad for this, it is good for this" and even you could include something like "we do not recommend you do it but if you want to shoot you in the foot you are free to do so." /as From jmh@joelhalpern.com Thu May 30 08:17:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC721F8FCB; Thu, 30 May 2013 08:17: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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcu4BNRy9+OS; Thu, 30 May 2013 08:17:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D50EB21F8F62; Thu, 30 May 2013 08:17:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 533671C0704; Thu, 30 May 2013 08:17:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-119.clppva.east.verizon.net [70.106.134.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2A4AE1C06A2; Thu, 30 May 2013 08:17:28 -0700 (PDT) Message-ID: <51A76D81.9020504@joelhalpern.com> Date: Thu, 30 May 2013 11:17:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:17:42 -0000 While it is true that any operator can do whatever they want, this proposal is architecturally a bad way to achieve the kind of goals you outline. So I would oppose publishing even an informational RFC on how one might do this. As an example of the problems with this, you suggested that allocations to enterprise would not change with this approach. That the enterprise would receive a certain semantic, and would be allocated a certain /48 to match that. While this sounds attractive and harmless: 1) It is extremely unlike that a customer will fall into a single "semantic" with any useful definition of semantic 2) You have argued that you can not use DSCP because they are not fine enough grained. This means that you want to increase the routing complexity by more than a factor of 64, which seems to be a VERY bad idea for any operator infrastructure. So even from a simple analysis, this seems somewhere between useless and extremely dangerous. Yours, Joel M. Halpern On 5/30/2013 3:00 AM, Sheng Jiang wrote: ... > Hi, Tim, > > It is exactly what the draft document. These semantics is only meaningful locally within the assigning provider network. It may only be interpretation between agreeing providers. > > Any efforts to add global or generic semantics to IP address is overload the IP architecture and it bad direction, I agree. > >> I think people will do this type of thing, so an Informational document >> discussing the pros and cons, and how semantics can be used, is probably a >> good thing. Perhaps a "Potential Pitfalls" type section after the "Potential >> Benefits" section would balance the document a little better? > > Yes. We will do so in the future version. > > Cheers, > > Sheng ... From arturo.servin@gmail.com Thu May 30 08:40:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D352321F9401; Thu, 30 May 2013 08:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKG2XalCCMto; Thu, 30 May 2013 08:40:33 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0521F9421; Thu, 30 May 2013 08:40:31 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bs12so2937169qab.8 for ; Thu, 30 May 2013 08:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f37kS6cNRG6AibkCKIgfmH3DrCXLsda5OlDkohgBEwQ=; b=LYhRLsfWQGLOuGrA6iS/tSY4KHlKBIIufe28IiYbt4R1pjr1CnLULGzkjXh+DdiWzt T//LV1c0CZGxxs8pVPSCTIiCWfkkVAxww5NYIemO792XjpK1BY+07zSAjJFzY/5oz5c6 2N6AN/QC9iFV6O+Ix+0wu75HNpZdI1Rk7KSdOloDswSAtVKETfps6L/Ha4ykaxQTHTJU aecOAS10zWM6Wai7SNnbJYo64aAOjoFANV6WKSJeG7h7lzMZnIiEPcFulGmNaNFpK2Uv Zi7n+3uCciN1e07oCTWVrIDeYh1qKmKsqaMc55+SA8LvQ+x3mvyfrirmbiNKhDYpyEVa Zkvg== X-Received: by 10.229.138.2 with SMTP id y2mr2612648qct.124.1369928430560; Thu, 30 May 2013 08:40:30 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2001:13c7:7001:7000:a937:ede1:dd66:aaad]) by mx.google.com with ESMTPSA id u14sm37208154qao.6.2013.05.30.08.40.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 08:40:29 -0700 (PDT) Message-ID: <51A772EF.60408@gmail.com> Date: Thu, 30 May 2013 12:40:31 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Joel M. Halpern" References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> <51A76D81.9020504@joelhalpern.com> In-Reply-To: <51A76D81.9020504@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:40:35 -0000 Probably this could be a good opportunity to publish a document "do not do this". /as On 5/30/13 12:17 PM, Joel M. Halpern wrote: > While it is true that any operator can do whatever they want, this > proposal is architecturally a bad way to achieve the kind of goals you > outline. > So I would oppose publishing even an informational RFC on how one might > do this. > > As an example of the problems with this, you suggested that allocations > to enterprise would not change with this approach. That the enterprise > would receive a certain semantic, and would be allocated a certain /48 > to match that. While this sounds attractive and harmless: > 1) It is extremely unlike that a customer will fall into a single > "semantic" with any useful definition of semantic > 2) You have argued that you can not use DSCP because they are not fine > enough grained. This means that you want to increase the routing > complexity by more than a factor of 64, which seems to be a VERY bad > idea for any operator infrastructure. > > So even from a simple analysis, this seems somewhere between useless and > extremely dangerous. > > Yours, > Joel M. Halpern > > On 5/30/2013 3:00 AM, Sheng Jiang wrote: > ... >> Hi, Tim, >> >> It is exactly what the draft document. These semantics is only >> meaningful locally within the assigning provider network. It may only >> be interpretation between agreeing providers. >> >> Any efforts to add global or generic semantics to IP address is >> overload the IP architecture and it bad direction, I agree. >> >>> I think people will do this type of thing, so an Informational document >>> discussing the pros and cons, and how semantics can be used, is >>> probably a >>> good thing. Perhaps a "Potential Pitfalls" type section after the >>> "Potential >>> Benefits" section would balance the document a little better? >> >> Yes. We will do so in the future version. >> >> Cheers, >> >> Sheng > ... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Thu May 30 08:43:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD621F9509 for ; Thu, 30 May 2013 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuhwSE5BFb-6 for ; Thu, 30 May 2013 08:43:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 74F3F21F955C for ; Thu, 30 May 2013 08:43:44 -0700 (PDT) Received: from [10.26.83.252] (mobile-198-228-194-095.mycingular.net [198.228.194.95]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4UFcfV4004860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 May 2013 08:38:43 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4UFcfV4004860 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369928324; bh=RpOlSOH6GfKChBp/QJ88kUrK2I4=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=VQAq3CdIPtv8ffLoMG0TNOQ0YzPas6UX/gGB4UMNlWBj17grlmS8VtX8w4DPOxVMp TvVRgur7ixdmeKvNOFs9dm8bUCVlU3oTzGNHw/nZ6HUsU2BPo2vF5Gg5K1VttLqS7r s5gyDFjrEtVUwNHe5AvzrBa2iFNlwEuAeQAm44nc= References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Owen DeLong Date: Thu, 30 May 2013 11:38:40 -0400 To: Mark Smith X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 30 May 2013 08:38:44 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:43:46 -0000 Sent from my iPad On May 30, 2013, at 4:11 AM, Mark Smith wrote: >> ________________________________ >> From: Lorenzo Colitti >> To: "v6ops@ietf.org WG" =20 >> Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" =20 >> Sent: Thursday, 30 May 2013 4:41 PM >> Subject: [v6ops] A good example of why we need to careful about ULAs >>=20 >>=20 >>=20 >> News at 11: >>=20 >>=20 >> 1. ULAs leak. >>=20 >> 2. People assign ULAs by hand. >>=20 >=20 > In the early news, not really a new problem. >=20 > RFC1918 and 100.64/10 leak too, and what is worse, I've seen people intent= ionally expose RFC1918s to other networks - the largest carrier here in .au u= ses RFC1918 addresses for their wholesale ADSL L2TP LACs (from memory, at le= ast 20 to 30, spread across multiple /16s within 172.16/12) and then expect t= heir many wholesale ADSL customers' to just accept those addresses and make t= hem work within their own networks, despite their own, quite legitimate inte= rnal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that add= ress space from your own). So we can't pretend that RFC1918s have been perfe= ctly used, and therefore ULAs being less private than intended is going to b= e new problem and experience. At least properly formed ULAs are unlikely to c= onflict with other network's ones, even if the other network has used fd00::= /8, and if the two interconnecting parties have both been lazy and used fd00= ::/8, they'll both be victims of theirs and the other Actually, as I understand it, part of the reason for making ULA different fr= om RFC-1918 and wasting such a large amount of address space on said boondog= gle was to address exactly the situation you describe and allow said telecom= to have IPv6 addresses that didn't conflict with their wholesale customers.= Thus, while the above scenario is problematic in RFC-1918 IPv4 land, it's s= upposed to be one of the intended uses of ULA as I understand it. Of course, GUA avoids these issues altogether, but apparently that's not goo= d enough for reasons passing understanding. > party's laziness (which they'll be used to, since they've probably experie= nced it with RFC1918). They'll probably resort to NPTv6 to fix it, because t= hat is what they're used to, rather than using IPv6's address aging mechanis= ms to renumber to a properly formed ULA. Good luck to them, as long as it do= esn't effect the rest of us. Ah, but eventually, it will. Owen >=20 >=20 >>=20 >=20 >> Yes, both of these a violation of IETF guidance. I don't think that matte= rs much, though - while we can always claim that the implementer/operator is= "holding it wrong", we should be careful that what we design/standardize is= hard to misconfigure and possibly robust in the face of misconfiguration. S= ubtle nuances like "these addresses are global scope, but not globally routa= ble" tend to get lost very easily. >>=20 >=20 > I think recommending against ULAs is just going to result in people steali= ng other address spaces for devices that don't need global reachability - li= ke 2001:db8::/32, or unused global address space (as we saw with 1/8, 5/8 an= d other IPv4 prefixes). I don't think it was recommending against the use of RFC-1918 that led to th= e above hijackings. > I think global address space comes with and implies a default assumption o= f global reachability, and you'll therefore have to actively take measures t= o ensure they don't provide global reachability if you don't want it. Link-l= ocals don't cut it because they're not routable. The need ULAs fulfils is th= e gap in between global space and link-locals, and the one which RFC1918 gen= erally fulfils in IPv4, except that the likelyhood of address space collisio= n is reduced. 99.99+% of RFC-1918 is to provide for GUA conservation through overloaded NA= T. That being not only unnecessary, but very undesirable in IPv6... As to a "default assumption of global reachability", this is a very harmful a= nd very incorrect assumption. IPv6 GUA provides for global uniqueness. It ma= y or may not be globally routable and even if routed may or may not be reach= able. > So is this draft aiming for BCP status and therefore should only reflect b= est common practice? If not, I think it is reasonable to present scenarios w= here ULAs could be useful. We've got a lot of experience with private addres= s spaces from IPv4 (the Deprecating Site Local Addresses RFC3879 is also a p= retty complete list of the problems with RFC1918 addresses), so the only rea= l difference is scenarios where concurrent global and private address spaces= could be useful. In some cases, they'll just be more capable versions of wh= at we've already doing in IPv4 e.g. private addressed loopbacks on routers, g= lobal addresses on the links, in a ULA environment you would add ULAs to the= links too, which could make troubleshooting and other OAM less dependent on= the global address space. You say that as if dependency on the global address space is a bad thing. IMNSHO, dependency on non-global addresses is where things get unnecessarily= complicated. Owen From owen@delong.com Thu May 30 09:04:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9D421F96D9; Thu, 30 May 2013 09:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whEGMOPS3QaK; Thu, 30 May 2013 09:04:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 109E621F96EB; Thu, 30 May 2013 09:03:37 -0700 (PDT) Received: from [10.26.83.252] (mobile-198-228-194-095.mycingular.net [198.228.194.95]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4UFvgGq005530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 May 2013 08:57:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4UFvgGq005530 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369929465; bh=5dmYaWdz9xHNf9g/4gp4C2SNdBY=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=RPgWo6FZDcoZcZgGdZN8bdSmjAKHjwYy41o+PNnPiWPDO3GvB+mrKm5zj7FxC03hc ueFuXlu6ayoKjHtWWn+wjVmF2KtOCEsZ35oDOpoYFDq6fOR36PPBLWra0FnYdGoPFE nAyK7aiGj4KyT8UAJIFl5VUoVCI1UqLYCpioz0jo= References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9924F@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC9924F@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5B817425-B386-4D9F-AD4C-DF69718411EE@delong.com> X-Mailer: iPad Mail (10B329) From: Owen DeLong Date: Thu, 30 May 2013 11:57:34 -0400 To: Sheng Jiang X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 30 May 2013 08:57:45 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:04:11 -0000 Sent from my iPad On May 30, 2013, at 2:34 AM, Sheng Jiang wrote: > Hi, Owen, >=20 > These embedded semantics are very different from End System Identifier. Th= e end system identifier functions was problem because it violents the layer m= odel. Many APPs or transport layer use IP address as their identifier. And t= he end system identifier breaks in at least two scenarios: when end devices c= hange the access points or when IP layer translation (NAT44 or NAT64) happen= s. I'm not sure how that's relevant to this discussion. It does not change the fact that overloading semantics onto addresses is an i= nherently bad idea. > The proposed embedded semantics is still layer 3. They are used for router= 's packet processing. These embedded semantics is only meaningful locally wi= thin ISP owner network. After leaving the ISP network, IP addresses are only= locator, nothing more. The bottom line is a network operator can choose to e= mbedded some semantics into IPv6 addresses assignment. We, as IETF, may not e= ncourage such usage, but should document it and may give some guidance or an= alysis of it. The problem with overloading semantics can occur regardless of whether or no= t you cross layer boundaries. You are creating artificial partitions of address space which creates the po= ssibility of filling up one partition while space remains in another. This m= ay create a situation where you are unable to get more space from the RIR or= upstream due to inefficient utilization and you are then forced to violate y= our semantic boundaries just to keep the network running. Unfortunately, sin= ce you've cultivated all these semantic assumptions in peoples heads (if not= running code), now you've got additional problems which last a very long ti= me and don't necessarily appear right away. It's a really great way to install time bombs in to operational systems. I d= o not recommend it. Owen >=20 > Best regards, >=20 > Sheng >=20 >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com] >> Sent: Thursday, May 30, 2013 7:02 AM >> To: Sheng Jiang >> Cc: ; ipv6@ietf.org; >> draft-jiang-v6ops-semantic-prefix@tools.ietf.org >> Subject: Re: [v6ops] Could IPv6 address be more than >> locator?//draft-jiang-v6ops-semantic-prefix-03 >>=20 >> Personally, I think this is an inherently bad idea. >>=20 >> IP addresses need less overloading of semantics, not more. >>=20 >> We already use IP addresses for two conflicting purposes=E2=80=A6 Topolog= y locator >> and End System Identifier. >>=20 >> This overloading is at the heart of our current scaling issues with respe= ct to >> the routing table. While these issues are currently less critical than th= ey have >> been in the past and will likely get quite a bit less critical in IPv6, t= hat is only >> because we have given up a fair amount of functionality to preserve >> scalability in this regard. >>=20 >> If we did not have this overloading, then an entity could obtain a set of= >> end-system identifiers and keep them throughout their lifetime, regardles= s of >> topological changes. Today, where the addresses are overloaded with both >> semantics, we either have to force most entities to change their numbers >> when they change topology or we face unsustainable growth in the routing >> tables. >>=20 >> The idea of adding more semantics to addressing rather than seeking to >> reduce this overloading seems a step in the wrong direction, IMHO. >>=20 >> Owen >>=20 >> On May 29, 2013, at 12:06 AM, Sheng Jiang >> wrote: >>=20 >>> IP addresses are designed as topology locator, so that every packet can b= e >> routed to its network destination. >>>=20 >>> However, even in IPv4 era, some network operators have mapped their IP >> address with certain semantic locally. These kind of mechanism explicitly= >> express the semantic properties of every packet. Consequently, these netw= ork >> operators can inspect the properties of packets easily by mapping the >> addresses back to semantic. >>>=20 >>> Network operators, who have large IPv6 address space, may also choose to= >> embedded some semantics into IPv6 addresses by assigning additional >> significance to specific bits within the prefix. >> draft-jiang-v6ops-semantic-prefix documents a framework method that >> network operations may use their addresses with embedded semantics. These= >> semantics bits are only meaningful within a single network, or group of >> interconnected networks which share a common addressing policy. Based on >> these embedded semantic bits in source/destination addresses, the network= >> operators can accordingly treat network packets differently and efficient= ly. >>>=20 >>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>>=20 >>> Could you please review this draft and comments? It will help the docume= nt >> become more useful information to be shared. >>>=20 >>> Best regards, >>>=20 >>> Sheng >>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Tuesday, May 28, 2013 10:28 AM >>>> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang >>>> Subject: New Version Notification for >>>> draft-jiang-v6ops-semantic-prefix-03.txt >>>>=20 >>>>=20 >>>> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt >>>> has been successfully submitted by Sheng Jiang and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-jiang-v6ops-semantic-prefix >>>> Revision: 03 >>>> Title: A Framework for Semantic IPv6 Prefix >>>> Creation date: 2013-05-28 >>>> Group: Individual Submission >>>> Number of pages: 19 >>>> URL: >> http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.= txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-v6ops-semantic-prefix-03= >>>>=20 >>>> Abstract: >>>> This document describes a framework method that network operations >>>> may use their addresses. Network operators, who have large IPv6 >>>> address space, may choose to embedded some semantics into IPv6 >>>> addresses by assigning additional significance to specific bits >>>> within the prefix. By embedded semantics into IPv6 prefixes, the >>>> semantics of packets can be inspected easily. Routers and other >>>> intermediary devices can easily apply relevant policies as required. >>>> Packet-level differentiation can also enable flow-level and user- >>>> level differentiation. Consequently, the network operators can >>>> accordingly treat network packets differently and efficiently. The >>>> management and maintenance of networks can be much simpler. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From owen@delong.com Thu May 30 09:14:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0634621F936E; Thu, 30 May 2013 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTuer0C-5W-x; Thu, 30 May 2013 09:14:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B62E21F9347; Thu, 30 May 2013 09:14:14 -0700 (PDT) Received: from [10.26.83.252] (mobile-198-228-194-095.mycingular.net [198.228.194.95]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4UG8StT006049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 May 2013 09:08:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4UG8StT006049 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369930112; bh=gfqnnu8Nd0HwdJH49AgH/HRIYho=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=pIyILrsByk5bP1o/qrItvNNujiGdy63RPAqzuugglsf8a6z9H7Z16rO/A1jlFIfYK yvIaw7Lu2NiphMROOr5TnBe18QFTyKIKK3bSiGLhRqRUoL3DQd/iyy2peT9lrh05xU 3wPrlxJpOl39ODFLK8ll35Btlco8W3uYsDcZ9L3g= References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2400563C-E085-4E7B-9E6A-8DBA89C6A4F4 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10B329) From: Owen DeLong Date: Thu, 30 May 2013 12:08:28 -0400 To: Sheng Jiang X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 30 May 2013 09:08:32 -0700 (PDT) Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:14:16 -0000 --Apple-Mail-2400563C-E085-4E7B-9E6A-8DBA89C6A4F4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > >>However, it is not necessary as worse as 2^N times. For example, it ther= e are 2 bits to separate different use types (say 4 different types), it act= ually only separate use address spaces into four different spaces. It does n= ot limit the address space to be 1/4 of original space. >=20 > How is that different from saying "by adding two bits of semantics in the p= refix, the network will use 4 times the address space than it would otherwis= e"? >=20 > No. This is very different. Putting the example into numbers may be more i= ntuitionistic. Say an ISP has 4 million subscribers, it needs 4 million /56 (= assuming every user get a /56). By separating them into 4 different types, t= he address consumption is still 4 million /56 if the separation is exactly e= ven. However, the more >=20 Not a great assumption... They should need 4 million or more /48s since ever= y subscriber is at least one end site and every subscriber end site should r= eceive a /48. Assuming that you will get 4 million subscribers that conveniently divide in= to buckets of 1 million per bucket is absurd. More likely, you'll get 500,00= 0, 750,000, 2,000,000, and 750,000, or other similarly skewed distribution. I= t might even be 3,500,000, 125,000, 125,000, 250,000. > address may need when the separation is not even. For example, if the bigg= est user type has 2 million users, then the total address space may become 8= million /56 =E2=80=93 two times of original. It comes from align. The incre= ased semantics bit are also increasing the address space although not increa= sing linearly. So, at the end, it is not totally waste. >=20 If you get extraordinarily lucky, it's no waste. Otherwise, it's at least 50= % waste and can easily reach 75% waste (4x space utilization, as Lorenzo sai= d). For example, if you have 4,000,000 end sites and you get as little as 2,097,= 153 subscribers in one of the buckets, you have to go to 4x your address spa= ce to preserve the semantics. Owen > Best regards, >=20 > Sheng >=20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Thursday, May 30, 2013 3:19 PM > To: Sheng Jiang > Cc: Tim Chown; Owen DeLong; ; draft-jiang-v6ops-semantic-p= refix@tools.ietf.org; ipv6@ietf.org > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang= -v6ops-semantic-prefix-03 >=20 > =20 >=20 > On Thu, May 30, 2013 at 4:13 PM, Sheng Jiang wrote= : >=20 > Yes, there is no intension to change ARIN=E2=80=99s policy at all. ARIN sh= ould remain the current policy of assign IPv6 address block. But the network= providers, who has already get address block, can choose to use the address= es with certain semantics. And no one, including ARIN can stop this. >=20 > =20 >=20 > Agreed, but even for network providers that already have blocks, this will= be an issue if they ever need another block. But I do think you should writ= e this in the draft. >=20 > =20 >=20 > However, it is not necessary as worse as 2^N times. For example, it there a= re 2 bits to separate different use types (say 4 different types), it actual= ly only separate use address spaces into four different spaces. It does not l= imit the address space to be 1/4 of original space. >=20 > =20 >=20 > How is that different from saying "by adding two bits of semantics in the p= refix, the network will use 4 times the address space than it would otherwis= e"? --Apple-Mail-2400563C-E085-4E7B-9E6A-8DBA89C6A4F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
>>Howe= ver, it is not necessary as worse as 2^N times. For example, it there are 2 b= its to separate different use types (say 4 different types), it actually only s= eparate use address spaces into four different spaces. It does not limit the= address space to be 1/4 of original space.=

How is that different from sayin= g "by adding two bits of semantics in the prefix, the network will use 4 tim= es the address space than it would otherwise"?

No. This is very different.= Putting the example into numbers may be more intuitionistic. Say an ISP has 4 million subscribers, it needs 4 million /56 (assuming ever= y user get a /56). By separating them into 4 different types, the address co= nsumption is still 4 million /56 if the separation is exactly even. However,= the more
Not a great assumption... T= hey should need 4 million or more /48s since every subscriber is at least on= e end site and every subscriber end site should receive a /48.
Assuming that you will get 4 million subscribers that convenient= ly divide into buckets of 1 million per bucket is absurd. More likely, you'l= l get 500,000, 750,000, 2,000,000, and 750,000, or other similarly skewed di= stribution. It might even be 3,500,000, 125,000, 125,000, 250,000.
address may need when the separation is not even. For example, if the biggest user type has 2 mil= lion users, then the total address space may become 8 million /56 =E2=80=93 t= wo times of original. It comes from align. The increased semantics bit are a= lso increasing the address space although not increasing linearly. So, at the end, it is not totally waste.
If you get extraordinarily lucky, it's no was= te. Otherwise, it's at least 50% waste and can easily reach 75% waste (4x sp= ace utilization, as Lorenzo said).

For example, if y= ou have 4,000,000 end sites and you get as little as 2,097,153 subscribers i= n one of the buckets, you have to go to 4x your address space to preserve th= e semantics.

Owen

Best regards,

Sheng
=

From: Lorenzo Colitti [ma= ilto:lorenzo@google.com]
Sent: Thursday, May 30, 2013 3:19 PM
To: Sheng Jiang
Cc: Tim Chown; Owen DeLong; <v6o= ps@ietf.org>; draft-jiang-v6ops-semantic-prefix@tools.ietf.org; ipv6@ietf.org
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-= jiang-v6ops-semantic-prefix-03

On Thu, May 30, 2013 at 4:13 PM,= Sheng Jiang <= jiangsheng@huawei.com> wrote:

Yes, there is no intension t= o change ARIN=E2=80=99s policy at all. ARIN should remain the current policy of assign IPv6 address block. But the network providers, who has alr= eady get address block, can choose to use the addresses with certain semanti= cs. And no one, including ARIN can stop this.

Agreed, but even for network pro= viders that already have blocks, this will be an issue if they ever need ano= ther block. But I do think you should write this in the draft.

However, it is not necessar= y as worse as 2^N times. For example, it there are 2 bits to separate different use types (say 4 different types), it actually only s= eparate use address spaces into four different spaces. It does not limit the= address space to be 1/4 of original space.=

How is that different from sayin= g "by adding two bits of semantics in the prefix, the network will use 4 tim= es the address space than it would otherwise"?

= --Apple-Mail-2400563C-E085-4E7B-9E6A-8DBA89C6A4F4-- From joelja@bogus.com Thu May 30 12:18:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D541B21F92BB; Thu, 30 May 2013 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbSo3HY2xzMi; Thu, 30 May 2013 12:18:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8221F8F11; Thu, 30 May 2013 12:17:48 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4UJHAa4039626 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 30 May 2013 19:17:11 GMT (envelope-from joelja@bogus.com) Message-ID: <51A7A5B1.3050709@bogus.com> Date: Thu, 30 May 2013 12:17:05 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Lorenzo Colitti , Tim Chown References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 30 May 2013 19:17:11 +0000 (UTC) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:18:06 -0000 On 5/29/13 11:47 PM, Lorenzo Colitti wrote: > On Thu, May 30, 2013 at 3:33 PM, Tim Chown > wrote: > > I agree. That said, an ISP, enterprise or group of organisations > can follow whatever semantics they wish within their own borders. > > > As long as the RIRs are willing to give them enough address space to > do so. > > If an ISP requested an IPv6 /10 from ARIN because they wanted to give > every customer a /48 and wanted to geocode the customer's subscriber > ID into the /48, then ARIN would do well to say, "no, sorry, that > doesn't make sense". > > Lest someone not realize this, the draft should clearly state that > embedding N bits of semantics into IPv6 addresses causes the network > to use 2^N times the address space that it normally would. > pretty much what I said at the mic... If this ever shows up in a jsutification for a /18 or /24 vs a /26 at an RIR that's a really bad thing imho. > IMO I think it should also state that although it is an IETF RFC, this > model is not necessarily a recommended model, and that RIRs are not > obliged to accept this type of address allocation as a justification > for obtaining larger address blocks than they would normally be able > to obtain. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Thu May 30 12:29:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52C721F922A; Thu, 30 May 2013 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF24QxfjBlBd; Thu, 30 May 2013 12:29:09 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 10EB821F911B; Thu, 30 May 2013 12:29:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUaeogzki/uaMjGxg8eDTuDg0ZOuDZyo9@postini.com; Thu, 30 May 2013 12:29:09 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 888F21B81BF; Thu, 30 May 2013 12:29:07 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7D350190052; Thu, 30 May 2013 12:29:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:29:07 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXVDE6lnGpdObXU2opXguZDBozpkekp0A Date: Thu, 30 May 2013 19:29:07 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751BD21Embx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:29:16 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751BD21Embx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 30, 2013, at 12:08 PM, Owen DeLong > wrote: Not a great assumption... They should need 4 million or more /48s since eve= ry subscriber is at least one end site and every subscriber end site should= receive a /48. I am not in love with using bits from prefixes as semantic tags. However,= having said that, I think it's a bit ironic that you're talking about wast= ing space with semantic bits, on the one hand, and talking about the need f= or a /48 in every home on the other. It would be perfectly reasonable for= the ISP to specify that some of the bits in the /48 have semantic meaning,= for example, and given that we think it's okay to give the home network a = /48, we are hardly in a position to quibble about how the bits in that /48 = are used. --_000_8D23D4052ABE7A4490E77B1A012B6307751BD21Embx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

On May 30, 2013, at 12:08 PM, Owen DeLong <owen@delong.com> wrote:

Not a great assumption... They should need 4 million or more /48s since eve= ry subscriber is at least one end site and every subscriber end site should= receive a /48.

I am not in love with using bits from prefixes as semantic tags. = ; However, having said that, I think it's a bit ironic that you're talking = about wasting space with semantic bits, on the one hand, and talking about = the need for a /48 in every home on the other. It would be perfectly reasonable for the ISP to specify that= some of the bits in the /48 have semantic meaning, for example, and given = that we think it's okay to give the home network a /48, we are hardly in a = position to quibble about how the bits in that /48 are used.

--_000_8D23D4052ABE7A4490E77B1A012B6307751BD21Embx01winnominum_-- From brian.e.carpenter@gmail.com Thu May 30 13:37:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3599921F8F87 for ; Thu, 30 May 2013 13:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-YALitaWWLP for ; Thu, 30 May 2013 13:37:38 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2D21F885A for ; Thu, 30 May 2013 13:37:38 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id rp8so992094pbb.22 for ; Thu, 30 May 2013 13:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=oRSNIweKTHno28yRevaeq8Hz3QRbKffflM3LewXIsvo=; b=zSnE04WL5R3/P4qT1biLAZnXLHQhNYmBvbKeQ98Y19UU8PY1JyCUDVPfG2lvIAyZBN BGuqlXPxhgtmxGDJE9S+3zGs7vRREmxoXw4sUZ0g/aQzWTg77WTBeHGxZP8A1tEC+Flq ceSS+EqtzSwO6Rng2wZWx3GfVdoUH84fFwv6MPN4El+4p3z7MV3KLLQlo/1m5/k6/XSG xm1L/6BI2KCXynt5ZkH+kaRNuoS8F0E9P4OO+NRLGFnsoUjYsoqWQ2FGeJW+G43f6l0Z ZERBqisCyxaRWoryyDHs9bDLCM83dWOurH6yUHY/fQKbtfcPXiCzcnvIJ8LaPxjuwqN8 BIfg== X-Received: by 10.66.49.104 with SMTP id t8mr10111271pan.65.1369946258639; Thu, 30 May 2013 13:37:38 -0700 (PDT) Received: from [192.168.1.2] (166.193.252.27.dyn.cust.vf.net.nz. [27.252.193.166]) by mx.google.com with ESMTPSA id sg4sm43383725pbc.7.2013.05.30.13.37.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 13:37:37 -0700 (PDT) Message-ID: <51A7B898.3080100@gmail.com> Date: Fri, 31 May 2013 08:37:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-taylor-v6ops-fragdrop? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:37:39 -0000 Hi, Is there any plan to refresh and publish draft-taylor-v6ops-fragdrop? It's useful information. Regards Brian From markzzzsmith@yahoo.com.au Thu May 30 14:23:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEF721F9003 for ; Thu, 30 May 2013 14:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcE0smXtEou8 for ; Thu, 30 May 2013 14:23:18 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0E76821F8B98 for ; Thu, 30 May 2013 14:23:16 -0700 (PDT) Received: from [98.139.214.32] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 21:23:16 -0000 Received: from [98.139.212.204] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2013 21:23:16 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 30 May 2013 21:23:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 304880.97478.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 93731 invoked by uid 60001); 30 May 2013 21:23:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1369948996; bh=olmKm6REyXGXr+MID7OAMOhAPz7poZIBuK8/ah6iIbM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BQVNG1lWuFs6Ophu3QGWSf5GeMGrwM0e2V2DgpM7aOsQvlXRGi+cmUJ9b+Eutdz1J/ogsVAcU0qzy28ZgCZt0TuW3JuZMhB7YhDxEV32WWiYFZmRhCAGwZRbcfSrit6BmKcj31gn7XkzyjYTwC9XweNOJRbxU3n2F7PEvDXUfbA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kToXvWgh2PQZrvcFf10bkygzsPCzXFNuKR348r44YP4Zvr6GetJ5CvaD9UCjG91VVLK0a5JtdPtVn6oqAXp8DS37sHRv+037NkiGstev1upJrh8e0cKQG7bDWw/XRXhYJPH0K2lOXHHOATzULMg0eXXtfYNtVkYJv6H/5Z2F8JM=; X-YMail-OSG: 3yU4t_AVM1m_y2fQoBVAZphcT1CrJCPCDdN.F4icFsu14eS 2vHYKdp5YYJBvrpkoIyKhwDXxUyeKsrG.Od.HTr9WkhmZZ.dNMsZLoK8P9Og lPk8paUUsK5CuQbeSjz4G.FDfcciHX3roGWmpretaMe9ei37Ns11JyUYMKtQ VBmEW7JAezVBfhfUsSVHdfnG7bOoorYVINRWL2IhjkKIBM0SsToxBYELw74X SoFCNNGCueb_XqoIS3TAhSepxs4wu_mqLrcRUufeCTM.cqKSZatYLGx9DEu0 0gNCRHQLRjM3gMz5EAh5Q185mY8fUF5T9Y.VO8YRx.WHShwFfn9YbFrQf.Y7 WtzI6AcYlGLQcRuYEWWJiqn7Wcn7pJtQfcpvOTkEY5rvj5lkaesS4pXuBxiY dX56QzlNpNKiwHvl20xaWiNPJsCzcOhu_bFaYvudbxLTqHE_gsWbOeXNCZzp 2QOeEGqN05NiM4.rb6s0Q4COYhIvi7yELMAVn11YSN.oEulk2l59KXI_BB02 q.3JXWQfEh35nRUPVAI7ZDt4vIQ2jQGO2gdtSsKg0ROi534U3ezZWrj2IUCu 20iZINnQtqk4X6AnxgBolmuVbxcyBJgOW.Gqbiq.Bn3QA4O4- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 30 May 2013 14:23:15 PDT X-Rocket-MIMEInfo: 002.001, Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPgo.VG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.IAo.Q2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPjsgImRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aW9uc0B0b29scy5pZXRmLm9yZyIgPGRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aW9uc0B0b29scy5pZXRmLm9yZz4gCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> Message-ID: <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 30 May 2013 14:23:15 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:23:25 -0000 =0A>________________________________=0A> From: Lorenzo Colitti =0A>To: Mark Smith =0A>Cc: "v6ops@ietf.= org WG" ; "draft-ietf-v6ops-ula-usage-recommendations@tools= .ietf.org" =0A>= Sent: Thursday, 30 May 2013 7:07 PM=0A>Subject: Re: [v6ops] A good example = of why we need to careful about ULAs=0A> =0A>=0A>=0A>On Thu, May 30, 2013 a= t 5:11 PM, Mark Smith wrote:=0A>In the early ne= ws, not really a new problem.=0A>>=0A>=0A>=0A>The part where an RFC asserts= says that we can generate globally unique addresses with no global coordin= ation is a new problem. Yes, in theory it works, but in practice it doesn't= , because everyone ends up using fd00:: - because that's the way it worked = in IPv4, and ULA is just RFC1918 all over again, right?=0A>=0A=0AI don't ag= ree with trying to create a registry for the non-centrally assigned ULAs (b= ecause I think those people probably think they now own that prefix), howev= er here is quite a list to show that a lot of people from a variety of orga= nisations get that ULAs aren't set to fd00::/8=0A=0Ahttp://www.sixxs.net/to= ols/grh/ula/list/=0A=0A=0A>=0A>The key point here is that people are going = to assume is that ULA is like RFC1918 and we should carefully document all = the ways in which it isn't.=0A>=0A=0AAgree with documenting it. Site-locals= were "fd00::". The site-local deprecation RFC is pretty much the inverse o= f all the ways ULAs aren't site-locals and RFC1918s.=0A=0A>=0A>So is this d= raft aiming for BCP status and therefore should only reflect best common pr= actice?=0A>=0A>=0A>I think documents coming out of v6ops should reflect sce= narios where there is operational experience. I don't think v6ops is the pl= ace to say "here's what we could build". It's the place to say "here's what= we've built; here's what works, and here's what doesn't".=0A>=0A>=0A=0A>As= an example: we've already discovered one of the use cases in this draft (t= he "use ULA as a pref64") is not a use case after all, because it causes de= vices to prefer IPv4 transition technologies like 464xlat over NAT64. We di= dn't know this because nobody had actually tried to *operate a network* in = such a use case. I happened to catch that one because I wrote and tested an= implementation, but who knows if there are caveats in any of the others?= =0A>=0A>=0A>If as an operational group we publish guidance to operators tha= t doesn't work in the real world (like the pref64 case above), it will be e= mbarrassing for us and wasteful of operators' time. We should strive to do = better than that.=0A>=0A>=0A=0AOk. So then a follow up question is how to p= rovide perhaps more tutorial oriented information? RFCs, quite reasonably, = provide enough information to justify what is=A0proposed, and usually one u= se case, but not all of them. That may not be enough information for more o= f a novice fully understand the problem that is being solved, the variety o= f opportunities to use it, and the pros and cons of the use of what is prop= osed in those scenarios. I haven't thought v6ops was just a place to docume= nt what has been done, but rather to document any topics related to operati= ons, including advice and more information on how things invented here and = in other IPv6 working groups could be used.=0A=0ARegards,=0AMark. From tom.taylor.stds@gmail.com Thu May 30 14:27:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65521F9307 for ; Thu, 30 May 2013 14:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXD4uBwbxI-C for ; Thu, 30 May 2013 14:27:44 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B7D5121F9008 for ; Thu, 30 May 2013 14:27:44 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so1647424obc.17 for ; Thu, 30 May 2013 14:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AxkN9AzKJGLz598xaYvUM5CkjQ68c8QUfi8OffsTx2Y=; b=JLq2QT3r1PDj+stjVrIeFKWtQ1ovN/PvHRgULX7xeROH0dYV6NqR6tu9RNr+5tyiUW m9dQWyCeG0hHavxxQddcHamJuMGdosQNyDz0Xw5Ls1khe3G/C4oHQoS4Q3P2JG0bvRfh dMRj9c8mnjV5J2wqhTTj5htG9kXWeSyS/AyUAqEMGraRBoFtgB0jbQbQPhCe7s4FM7fE +aAPyfp07Y7d8X6rdvvmPr92p7VeVZ1gV2WnGBT0ZNUtPoh+DiUFXZ9492GDlTCAfbfa BDE6rzRFNUlJ0ahhnQHKdUT07pNv7CkQWEUZBbgEgtCDcJRzPLQh3lLWUulEXOq+p5rY wsew== X-Received: by 10.182.171.9 with SMTP id aq9mr4883190obc.16.1369949264329; Thu, 30 May 2013 14:27:44 -0700 (PDT) Received: from [192.168.1.64] (dsl-173-206-2-36.tor.primus.ca. [173.206.2.36]) by mx.google.com with ESMTPSA id z5sm43423892obw.4.2013.05.30.14.27.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 14:27:43 -0700 (PDT) Message-ID: <51A7C44E.4010604@gmail.com> Date: Thu, 30 May 2013 17:27:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian E Carpenter References: <51A7B898.3080100@gmail.com> In-Reply-To: <51A7B898.3080100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] draft-taylor-v6ops-fragdrop? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:27:45 -0000 Yes, the various authors have been taking a whack at it. I imagine we'll have an update out shortly. On 30/05/2013 4:37 PM, Brian E Carpenter wrote: > Hi, > > Is there any plan to refresh and publish draft-taylor-v6ops-fragdrop? > > It's useful information. > > Regards > Brian > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Thu May 30 14:45:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD3221F9273 for ; Thu, 30 May 2013 14:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxXWaX-yJWCJ for ; Thu, 30 May 2013 14:45:12 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6037D21F8B5F for ; Thu, 30 May 2013 14:45:12 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 3so1075313pdj.33 for ; Thu, 30 May 2013 14:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=y8pf5JOGLD4bJqptR85oECom7axMJNLHeOuVUJAOP5E=; b=tHeIXFztXbr/f1NKlxZyAZgasy0D0EytYXVCoJiXhqwHDRLuKCnGvcwnrsc88VAThe L7YoKKTOzCo39067Vc2wFhGDilqunw9hahLLpQ9RAItcU3yOhsupDnRWPiKpa3ZltNlk f/M/yNDvIVT1Z1OcYQTCen9HXcHdCva+wGJooINVzQI5+nGL/WRXkfpFnqvQS5TZmT4k SlPvtS89Zm0wYiiZ4etvZFek/iSBygIvawztZqgmBVVRFiDed+HHS9ieIm9BgzEpSAIQ AdZTddH/TAb8re/M15g4lx9dD/p6A7bvlEToXgOt5/EcYuWeErj0Hu3u0lrhzafffol/ cl5A== X-Received: by 10.66.4.10 with SMTP id g10mr10536632pag.217.1369950312056; Thu, 30 May 2013 14:45:12 -0700 (PDT) Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id uv1sm43539979pbc.16.2013.05.30.14.45.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 14:45:10 -0700 (PDT) Message-ID: <51A7C86B.3020808@gmail.com> Date: Fri, 31 May 2013 09:45:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:45:17 -0000 On 30/05/2013 20:11, Mark Smith wrote: >> ________________________________ >> From: Lorenzo Colitti >> To: "v6ops@ietf.org WG" >> Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" >> Sent: Thursday, 30 May 2013 4:41 PM >> Subject: [v6ops] A good example of why we need to careful about ULAs >> >> >> >> News at 11: >> >> >> 1. ULAs leak. >> >> 2. People assign ULAs by hand. >> > > In the early news, not really a new problem. > > RFC1918 and 100.64/10 leak too, In traceroutes, link-locals sometimes leak too. All these are confusing and make the traceroute hard to interpret, but they don't actually *matter*. What matters is if they leak in actual traffic such as attempted TCP connections. Does that happen? Brian > and what is worse, I've seen people intentionally expose RFC1918s to other networks - the largest carrier here in .au uses RFC1918 addresses for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, spread across multiple /16s within 172.16/12) and then expect their many wholesale ADSL customers' to just accept those addresses and make them work within their own networks, despite their own, quite legitimate internal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that address space from your own). So we can't pretend that RFC1918s have been perfectly used, and therefore ULAs being less private than intended is going to be new problem and experience. At least properly formed ULAs are unlikely to conflict with other network's ones, even if the other network has used fd00::/8, and if the two interconnecting parties have both been lazy and used fd00::/8, they'll both be victims of theirs and the other > party's laziness (which they'll be used to, since they've probably experienced it with RFC1918). They'll probably resort to NPTv6 to fix it, because that is what they're used to, rather than using IPv6's address aging mechanisms to renumber to a properly formed ULA. Good luck to them, as long as it doesn't effect the rest of us. > > > >> Yes, both of these a violation of IETF guidance. I don't think that matters much, though - while we can always claim that the implementer/operator is "holding it wrong", we should be careful that what we design/standardize is hard to misconfigure and possibly robust in the face of misconfiguration. Subtle nuances like "these addresses are global scope, but not globally routable" tend to get lost very easily. >> > > I think recommending against ULAs is just going to result in people stealing other address spaces for devices that don't need global reachability - like 2001:db8::/32, or unused global address space (as we saw with 1/8, 5/8 and other IPv4 prefixes). > > I think global address space comes with and implies a default assumption of global reachability, and you'll therefore have to actively take measures to ensure they don't provide global reachability if you don't want it. Link-locals don't cut it because they're not routable. The need ULAs fulfils is the gap in between global space and link-locals, and the one which RFC1918 generally fulfils in IPv4, except that the likelyhood of address space collision is reduced. > >> Of course, in the case of ULAs, there's not much that can be done about the design at this point, but we should make an effort to make it clear that the potential for misconfiguration exists and provide clear guidance on how not to misconfigure them. >> >> > >> Personally, I think that providing said guidance is much more useful and important than enumerating scenarios that aren't widely, if at all, implemented, and I hope that the authors of draft-ietf-v6ops-ula-usage-recommendations will agree. >> > > So is this draft aiming for BCP status and therefore should only reflect best common practice? If not, I think it is reasonable to present scenarios where ULAs could be useful. We've got a lot of experience with private address spaces from IPv4 (the Deprecating Site Local Addresses RFC3879 is also a pretty complete list of the problems with RFC1918 addresses), so the only real difference is scenarios where concurrent global and private address spaces could be useful. In some cases, they'll just be more capable versions of what we've already doing in IPv4 e.g. private addressed loopbacks on routers, global addresses on the links, in a ULA environment you would add ULAs to the links too, which could make troubleshooting and other OAM less dependent on the global address space. > > Regards, > Mark. > >> Cheers, >> Lorenzo >> >> >> ---------- Forwarded message ---------- >> From: Jeroen Massar >> Date: Thu, May 30, 2013 at 4:59 AM >> Subject: Usage of fd00::/8 on the Interwebz - something with filters and uRPF >> To: ipv6-ops@lists.cluenet.de >> >> >> ... >> 4 2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) 20.755 ms 20.763 ms 20.784 ms >> 5 fd00:3303::1 (fd00:3303::1) 22.010 ms 21.984 ms 21.986 ms >> 6 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 17.806 ms 17.889 ms 17.842 ms >> 7 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 18.720 ms 18.593 ms 18.617 ms >> ... >> >> Hmmmm fd00::/8, that really should never ever be visible on the Internet, being Unique *LOCAL* Addresses. >> And it does not look like they applied the randomness bit for picking a prefix either. >> You would also almost think that a /28 is more than enough address space to put a few router loopbacks in. >> >> It is apparently time for people to start checking their filters again because it seems that these packets leak into other ASNs too... >> >> More generally, do recheck your network for BCP38 compliance, please do apply it and require your peers to do the same! >> >> Greets, >> Jeroen >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jeroen@massar.ch Thu May 30 15:07:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B4E21F9289 for ; Thu, 30 May 2013 15:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxD8lgjLzs+o for ; Thu, 30 May 2013 15:07:47 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id E91E521F86F0 for ; Thu, 30 May 2013 15:07:42 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [149.20.50.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 27ECF801C2BA; Fri, 31 May 2013 00:07:37 +0200 (CEST) Message-ID: <51A7CDA9.4090304@massar.ch> Date: Thu, 30 May 2013 15:07:37 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> In-Reply-To: <51A7C86B.3020808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 22:07:53 -0000 On 2013-05-30 14:45, Brian E Carpenter wrote: [..] >> In the early news, not really a new problem. >> >> RFC1918 and 100.64/10 leak too, > > In traceroutes, link-locals sometimes leak too. I have never come across that; except maybe when tracerouting to a link-local, and then, that would only be one hop anyway. If you know how to replicate it, I am very interested in a packet dump or what is involved to cause it. > All these are confusing and make the traceroute hard to interpret, > but they don't actually *matter*. What matters is if they leak in > actual traffic such as attempted TCP connections. Does that happen? One should only see a link-local when: - the source packet is link-local - the destination host only has a link-local and replies (TTL or so) But that should never cross more than one (1) hop as link-locals should not be forwarded. Greets, Jeroen From joelja@bogus.com Thu May 30 15:08:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C37821F86CA for ; Thu, 30 May 2013 15:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6sTpdF5FN5R for ; Thu, 30 May 2013 15:08:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8021F92F4 for ; Thu, 30 May 2013 15:08:42 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r4UM8dJG041477 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 30 May 2013 22:08:40 GMT (envelope-from joelja@bogus.com) Message-ID: <51A7CDE2.7050306@bogus.com> Date: Thu, 30 May 2013 15:08:34 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Brian E Carpenter , Mark Smith References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> In-Reply-To: <51A7C86B.3020808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 30 May 2013 22:08:40 +0000 (UTC) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 22:08:44 -0000 On 5/30/13 2:45 PM, Brian E Carpenter wrote: > On 30/05/2013 20:11, Mark Smith wrote: >>> ________________________________ >>> From: Lorenzo Colitti >>> To: "v6ops@ietf.org WG" >>> Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" >>> Sent: Thursday, 30 May 2013 4:41 PM >>> Subject: [v6ops] A good example of why we need to careful about ULAs >>> >>> >>> >>> News at 11: >>> >>> >>> 1. ULAs leak. >>> >>> 2. People assign ULAs by hand. >>> >> In the early news, not really a new problem. >> >> RFC1918 and 100.64/10 leak too, > In traceroutes, link-locals sometimes leak too. > > All these are confusing and make the traceroute hard to interpret, > but they don't actually *matter*. What matters is if they leak in > actual traffic such as attempted TCP connections. Does that happen? there's leaking and then there's leaking... if nobody accepts the route bi-directional leakage is hard... and even=20 loose rpf checks will discard traffic from sources like that real providers on the internet are still accepting 100.100.0.0/24=20 from as4847 so that's an example=20 of the other kind. > Brian > >> and what is worse, I've seen people intentionally expose RFC1918s to= other networks - the largest carrier here in .au uses RFC1918 addresses = for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, sprea= d across multiple /16s within 172.16/12) and then expect their many whole= sale ADSL customers' to just accept those addresses and make them work wi= thin their own networks, despite their own, quite legitimate internal use= of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that address = space from your own). So we can't pretend that RFC1918s have been perfect= ly used, and therefore ULAs being less private than intended is going to = be new problem and experience. At least properly formed ULAs are unlikely= to conflict with other network's ones, even if the other network has use= d fd00::/8, and if the two interconnecting parties have both been lazy an= d used fd00::/8, they'll both be victims of theirs and the other >> party's laziness (which they'll be used to, since they've probably e= xperienced it with RFC1918). They'll probably resort to NPTv6 to fix it, = because that is what they're used to, rather than using IPv6's address ag= ing mechanisms to renumber to a properly formed ULA. Good luck to them, a= s long as it doesn't effect the rest of us. >> >> >> >>> Yes, both of these a violation of IETF guidance. I don't think that m= atters much, though - while we can always claim that the implementer/oper= ator is "holding it wrong", we should be careful that what we design/stan= dardize is hard to misconfigure and possibly robust in the face of miscon= figuration. Subtle nuances like "these addresses are global scope, but no= t globally routable" tend to get lost very easily. >>> >> I think recommending against ULAs is just going to result in people st= ealing other address spaces for devices that don't need global reachabili= ty - like 2001:db8::/32, or unused global address space (as we saw with 1= /8, 5/8 and other IPv4 prefixes). >> >> I think global address space comes with and implies a default assumpti= on of global reachability, and you'll therefore have to actively take mea= sures to ensure they don't provide global reachability if you don't want = it. Link-locals don't cut it because they're not routable. The need ULAs = fulfils is the gap in between global space and link-locals, and the one w= hich RFC1918 generally fulfils in IPv4, except that the likelyhood of add= ress space collision is reduced. >> >>> Of course, in the case of ULAs, there's not much that can be done abo= ut the design at this point, but we should make an effort to make it clea= r that the potential for misconfiguration exists and provide clear guidan= ce on how not to misconfigure them. >>> >>> >>> Personally, I think that providing said guidance is much more useful = and important than enumerating scenarios that aren't widely, if at all, i= mplemented, and I hope that the authors of draft-ietf-v6ops-ula-usage-rec= ommendations will agree. >>> >> So is this draft aiming for BCP status and therefore should only refle= ct best common practice? If not, I think it is reasonable to present scen= arios where ULAs could be useful. We've got a lot of experience with priv= ate address spaces from IPv4 (the Deprecating Site Local Addresses RFC387= 9 is also a pretty complete list of the problems with RFC1918 addresses),= so the only real difference is scenarios where concurrent global and pri= vate address spaces could be useful. In some cases, they'll just be more = capable versions of what we've already doing in IPv4 e.g. private address= ed loopbacks on routers, global addresses on the links, in a ULA environm= ent you would add ULAs to the links too, which could make troubleshooting= and other OAM less dependent on the global address space. >> >> Regards, >> Mark. >> >>> Cheers, >>> Lorenzo >>> >>> >>> ---------- Forwarded message ---------- >>> From: Jeroen Massar >>> Date: Thu, May 30, 2013 at 4:59 AM >>> Subject: Usage of fd00::/8 on the Interwebz - something with filters = and uRPF >>> To: ipv6-ops@lists.cluenet.de >>> >>> >>> ... >>> 4 2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) 20.755 ms 20= =2E763 ms 20.784 ms >>> 5 fd00:3303::1 (fd00:3303::1) 22.010 ms 21.984 ms 21.986 ms >>> 6 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 17.806 ms 17.8= 89 ms 17.842 ms >>> 7 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 18.720 ms 18.5= 93 ms 18.617 ms >>> ... >>> >>> Hmmmm fd00::/8, that really should never ever be visible on the Inter= net, being Unique *LOCAL* Addresses. >>> And it does not look like they applied the randomness bit for picking= a prefix either. >>> You would also almost think that a /28 is more than enough address sp= ace to put a few router loopbacks in. >>> >>> It is apparently time for people to start checking their filters agai= n because it seems that these packets leak into other ASNs too... >>> >>> More generally, do recheck your network for BCP38 compliance, please = do apply it and require your peers to do the same! >>> >>> Greets, >>> Jeroen >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From marka@isc.org Thu May 30 16:54:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C7921F9920 for ; Thu, 30 May 2013 16:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_BEST=2.3, MANGLED_WORKS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROnDhdS8qFL5 for ; Thu, 30 May 2013 16:54:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7700621F9698 for ; Thu, 30 May 2013 16:54:57 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 72AC4C9427; Thu, 30 May 2013 23:54:48 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369958097; bh=I5rY8fVJyXRtE7LVmi/tJ+YWhM9QFto5X9oPKcyEw48=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=VIjo6VF3ovpGrq+ID6AB/WHFSAgwKYIlTxA6MO6YGnMaqQwKq8NsfXCwl505Lv7JS sgQHDSvdgYMMm8OQB9zdw0pNLPCDXr+G8J/FDxYy7fb+xrKggeBvN3BQ0RW4i4GPPA L7QuzblCZBcpIcbt/Z/7MMP6CvoWx7DC9MHvy28Q= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 30 May 2013 23:54:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AC177216C40; Thu, 30 May 2013 23:54:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id BD66034F6EDB; Fri, 31 May 2013 09:54:42 +1000 (EST) To: Mark Smith From: Mark Andrews References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-reply-to: Your message of "Thu, 30 May 2013 14:23:15 -0700." <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 31 May 2013 09:54:42 +1000 Message-Id: <20130530235442.BD66034F6EDB@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 23:54:59 -0000 In message <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com>, Mark S mith writes: > > >Cc: "v6ops@ietf.org WG" ; "draft-ietf-v6ops-ula-usage-reco= > mmendations@tools.ietf.org" ls.ietf.org> = > > >Sent: Thursday, 30 May 2013 7:07 PM > >Subject: Re: [v6ops] A good example of why we need to careful about ULAs > > = > > > > > > >On Thu, May 30, 2013 at 5:11 PM, Mark Smith wr= > ote: > >In the early news, not really a new problem. > >> > > > > > >The part where an RFC asserts says that we can generate globally unique ad= > dresses with no global coordination is a new problem. Yes, in theory it wor= > ks, but in practice it doesn't, because everyone ends up using fd00:: - bec= > ause that's the way it worked in IPv4, and ULA is just RFC1918 all over aga= > in, right? > > > > I don't agree with trying to create a registry for the non-centrally assign= > ed ULAs (because I think those people probably think they now own that pref= > ix), however here is quite a list to show that a lot of people from a varie= > ty of organisations get that ULAs aren't set to fd00::/8 All locally assigned ULA are in fd00::/8. I think you meant fd00:0000:0000::/48. Yes I deliberatly added the extra zeros make it clearer. The example that started this thread was not in fd00:0000:0000::/48. They may not have configured their border routers to block traffic to/from fc00::/7 and their router may not have appropriate source address selection rules for the reply. Both of those are correctable. fd00:3303:0000::/48 may not *look* random but it may well be random. > http://www.sixxs.net/tools/grh/ula/list/ > > > > > >The key point here is that people are going to assume is that ULA is like = > RFC1918 and we should carefully document all the ways in which it isn't. > > > > Agree with documenting it. Site-locals were "fd00::". The site-local deprec= > ation RFC is pretty much the inverse of all the ways ULAs aren't site-local= > s and RFC1918s. > > > > >So is this draft aiming for BCP status and therefore should only reflect b= > est common practice? > > > > > >I think documents coming out of v6ops should reflect scenarios where there= > is operational experience. I don't think v6ops is the place to say "here's= > what we could build". It's the place to say "here's what we've built; here= > 's what works, and here's what doesn't". > > > > > > >As an example: we've already discovered one of the use cases in this draft= > (the "use ULA as a pref64") is not a use case after all, because it causes= > devices to prefer IPv4 transition technologies like 464xlat over NAT64. We= > didn't know this because nobody had actually tried to *operate a network* = > in such a use case. I happened to catch that one because I wrote and tested= > an implementation, but who knows if there are caveats in any of the others? > > > > > >If as an operational group we publish guidance to operators that doesn't w= > ork in the real world (like the pref64 case above), it will be embarrassing= > for us and wasteful of operators' time. We should strive to do better than= > that. > > > > > > Ok. So then a follow up question is how to provide perhaps more tutorial or= > iented information? RFCs, quite reasonably, provide enough information to j= > ustify what is=A0proposed, and usually one use case, but not all of them. T= > hat may not be enough information for more of a novice fully understand the= > problem that is being solved, the variety of opportunities to use it, and = > the pros and cons of the use of what is proposed in those scenarios. I have= > n't thought v6ops was just a place to document what has been done, but rath= > er to document any topics related to operations, including advice and more = > information on how things invented here and in other IPv6 working groups co= > uld be used. > > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jiangsheng@huawei.com Thu May 30 18:32:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5586B21F901A for ; Thu, 30 May 2013 18:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dr4mOn7HmOy for ; Thu, 30 May 2013 18:32:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96A7621F8F6D for ; Thu, 30 May 2013 18:32:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ01766; Fri, 31 May 2013 01:32:33 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:30:52 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:31:28 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Fri, 31 May 2013 09:31:23 +0800 From: Sheng Jiang To: "aservin@lacnic.net" , "v6ops@ietf.org" Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kc8GIAgACHYyD//5DsAIABe6Gg Date: Fri, 31 May 2013 01:31:22 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC999EF@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <5f5db848326ae00c249cff068956b4fc@mail.lacnic.net.uy> In-Reply-To: <5f5db848326ae00c249cff068956b4fc@mail.lacnic.net.uy> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:32:39 -0000 Pj4+SSBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3Igb3BlcmF0b3JzIHRvIGhh dmUgYWRkaXRpb25hbA0KPj4+c2VtYW50aWNzIGF2YWlsYWJsZSBmb3IgY3VzdG9taXplZCBwYWNr ZXQgcHJvY2Vzc2luZy4gRmxvdyBsYWJlbCBub3cNCj4+PiBoYXMNCj4+PnZlcnkgbGltaXRlZCBw cm9wZXJ0aWVzIG9wdGltaXNlZCBmb3IgbG9hZCBiYWxhbmNlcnMuIERTQ1Agb25seSBoYXMgYQ0K Pj4+ZmV3IGJpdHMgKHdheSBsZXNzIHRoYW4gdGhlIG51bWJlciBvZiBjdXN0b21lcnMnIHBvbGlj aWVzKS4gQUNMcyBhcmUNCj4+PmhlYXZ5IHRvIHByb2Nlc3MgYXQgZWFjaCBob3AuLi4uDQo+Pj4N Cj4+PkJ1dCB3b3VsZG4ndCB0aGlzIGluZm9ybWF0aW9uIGJlIGJldHRlciBvZmYgZW5jb2RlZCBh cyB0YWdzIGluIG9uZSBvcg0KPj4+bW9yZSBob3AtYnktaG9wIGhlYWRlciBvcHRpb25zICh0aGF0 IGNvdWxkIGJlIHJlLXdyaXR0ZW4gb24gdGhlIGZseSksDQo+Pj5yYXRoZXIgdGhhbiBlbmNvZGVk IGluIHRoZSBJUHY2IGFkZHJlc3Mgc3BhY2U/DQo+Pg0KPj4gVGhlIHNlY3Rpb24gNC4xICJKdXN0 aWZjYXRpb24gZm9yIFNlbWFudGljcyB3aXRoIHRoZSBJUHY2IFByZWZpeCINCj4+IGRlc2NyaWJl cyB0aGUgcmVhc29ucy4NCj4+DQo+PiBVc2VycyBtYXkgZWFzaWx5IGNoYW5nZSB0aGUgc2V0dGlu ZyBvZiBleHRlbnNpb24gaGVhZGVyIGluIG9yZGVyIHRvDQo+PiBvYnRhaW4gdW5kZXNlcnZlZCBw cmlvcml0aWVzL3ByaXZpbGVnZXMuIFNlbWFudGljIHByZWZpeCBhcHByb2FjaA0KPj4gZG9lcw0K Pj4gcmVxdWlyZSB0aGUgZGVwbG95bWVudCBvZiBhY2Nlc3MgY29udHJvbCBmaWx0ZXJzLiBUaGUg cGFja2V0cyB3aXRoDQo+PiB0aGUNCj4+IG5vbmNvbXBsaWFuY2Ugc291cmNlIGFkZHJlc3NlcyBz aG91bGQgYmUgZmlsdGVyZWQuIFRoZSBwcmVmaXggaXMNCj4+IGRlbGVnYXRlZCBieSB0aGUgbmV0 d29yay4gVGhlcmVmb3JlIHRoZSBuZXR3b3JrIGlzIGFibGUgdG8gZGV0ZWN0IGFueQ0KPj4gdW5k ZXNpcmVkIG1vZGlmaWNhdGlvbnMgYW5kIGZpbHRlciB0aGUgcGFja2V0IGFjY29yZGluZ2x5Lg0K Pj4NCj4+IENoZWVycywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+PnJlZ2FyZHMsDQo+Pj5SYXlIDQo+ DQo+ICAgIEkgdGhpbmsgdGhlIHVzZXIgY2FuIHBsYXkgdGhlIHN5c3RlbSB0b28gd2l0aCBJUCBh ZGRyZXNzZXMuIEl0IG1heQ0KPmJlIG1vcmUgY29tcGxpY2F0ZWQgYnV0IGl0IG1heSBiZSBwb3Nz aWJsZSB3aXRoIHRoZSBlbm91Z2ggbW90aXZhdGlvbiB0bw0KPmRvIHNvLg0KDQpZZXMuIEV2ZW4g SUVURiBzaG91bGQgbm90IHJlY29tbWVuZCB0aGlzLiBXZSBjYW5ub3Qgc3RvcCBpdC4gU28gaXQg aXMgYmV0dGVyIHRvIGRvY3VtZW50IGl0IGFuZCBnaXZpbmcgYW5hbHl6ZSBvbiBpdHMgYmFkIGFu ZCBnb29kLg0KDQpTaGVuZw0KDQo+L2FzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0K Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From jiangsheng@huawei.com Thu May 30 18:39:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E6221F86DD; Thu, 30 May 2013 18:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofKDyxnDqh5W; Thu, 30 May 2013 18:39:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B844421F8FAF; Thu, 30 May 2013 18:39:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ02100; Fri, 31 May 2013 01:38:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:38:26 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 09:38:58 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Fri, 31 May 2013 09:38:55 +0800 From: Sheng Jiang To: Ray Hunter Thread-Topic: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kc8GIAgACHYyD//5aGgIABdpag Date: Fri, 31 May 2013 01:38:55 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> In-Reply-To: <51A733E1.7040008@globis.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:39:06 -0000 Pj4gU2hlbmcgSmlhbmcgPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20+DQo+PiAzMCBNYXkg MjAxMyAxMTo1OA0KPj4+PiBJUCBhZGRyZXNzZXMgYXJlIGRlc2lnbmVkIGFzIHRvcG9sb2d5IGxv Y2F0b3IsIHNvIHRoYXQgZXZlcnkgcGFja2V0IGNhbg0KPmJlDQo+Pj4gcm91dGVkIHRvIGl0cyBu ZXR3b3JrIGRlc3RpbmF0aW9uLg0KPj4+PiBIb3dldmVyLCBldmVuIGluIElQdjQgZXJhLCBzb21l IG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFwcGVkIHRoZWlyIElQDQo+Pj4gYWRkcmVzcyB3aXRo IGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhlc2Uga2luZCBvZiBtZWNoYW5pc20gZXhwbGlj aXRseQ0KPj4+IGV4cHJlc3MgdGhlIHNlbWFudGljIHByb3BlcnRpZXMgb2YgZXZlcnkgcGFja2V0 LiBDb25zZXF1ZW50bHksIHRoZXNlDQo+bmV0d29yaw0KPj4+IG9wZXJhdG9ycyBjYW4gaW5zcGVj dCB0aGUgcHJvcGVydGllcyBvZiBwYWNrZXRzIGVhc2lseSBieSBtYXBwaW5nIHRoZQ0KPj4+IGFk ZHJlc3NlcyBiYWNrIHRvIHNlbWFudGljLg0KPj4+PiBOZXR3b3JrIG9wZXJhdG9ycywgd2hvIGhh dmUgbGFyZ2UgSVB2NiBhZGRyZXNzIHNwYWNlLCBtYXkgYWxzbyBjaG9vc2UNCj50bw0KPj4+IGVt YmVkZGVkIHNvbWUgc2VtYW50aWNzIGludG8gSVB2NiBhZGRyZXNzZXMgYnkgYXNzaWduaW5nIGFk ZGl0aW9uYWwNCj4+PiBzaWduaWZpY2FuY2UgdG8gc3BlY2lmaWMgYml0cyB3aXRoaW4gdGhlIHBy ZWZpeC4NCj4+PiBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXggZG9jdW1lbnRzIGEg ZnJhbWV3b3JrIG1ldGhvZCB0aGF0DQo+Pj4gbmV0d29yayBvcGVyYXRpb25zIG1heSB1c2UgdGhl aXIgYWRkcmVzc2VzIHdpdGggZW1iZWRkZWQgc2VtYW50aWNzLg0KPlRoZXNlDQo+Pj4gc2VtYW50 aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yaywgb3Ig Z3JvdXAgb2YNCj4+PiBpbnRlcmNvbm5lY3RlZCBuZXR3b3JrcyB3aGljaCBzaGFyZSBhIGNvbW1v biBhZGRyZXNzaW5nIHBvbGljeS4gQmFzZWQNCj5vbg0KPj4+IHRoZXNlIGVtYmVkZGVkIHNlbWFu dGljIGJpdHMgaW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3NlcywgdGhlDQo+bmV0d29yaw0K Pj4+IG9wZXJhdG9ycyBjYW4gYWNjb3JkaW5nbHkgdHJlYXQgbmV0d29yayBwYWNrZXRzIGRpZmZl cmVudGx5IGFuZCBlZmZpY2llbnRseS4NCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4+DQo+Pj4+IENvdWxkIHlv dSBwbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgYW5kIGNvbW1lbnRzPyBJdCB3aWxsIGhlbHAgdGhl DQo+ZG9jdW1lbnQNCj4+PiBiZWNvbWUgbW9yZSB1c2VmdWwgaW5mb3JtYXRpb24gdG8gYmUgc2hh cmVkLg0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IFNoZW5nDQo+Pj4+DQo+Pj4gSSBj b21wbGV0ZWx5IHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3Igb3BlcmF0b3JzIHRvIGhhdmUgYWRk aXRpb25hbA0KPj4+IHNlbWFudGljcyBhdmFpbGFibGUgZm9yIGN1c3RvbWl6ZWQgcGFja2V0IHBy b2Nlc3NpbmcuIEZsb3cgbGFiZWwgbm93IGhhcw0KPj4+IHZlcnkgbGltaXRlZCBwcm9wZXJ0aWVz IG9wdGltaXNlZCBmb3IgbG9hZCBiYWxhbmNlcnMuIERTQ1Agb25seSBoYXMgYQ0KPj4+IGZldyBi aXRzICh3YXkgbGVzcyB0aGFuIHRoZSBudW1iZXIgb2YgY3VzdG9tZXJzJyBwb2xpY2llcykuIEFD THMgYXJlDQo+Pj4gaGVhdnkgdG8gcHJvY2VzcyBhdCBlYWNoIGhvcC4uLi4NCj4+Pg0KPj4+IEJ1 dCB3b3VsZG4ndCB0aGlzIGluZm9ybWF0aW9uIGJlIGJldHRlciBvZmYgZW5jb2RlZCBhcyB0YWdz IGluIG9uZSBvcg0KPj4+IG1vcmUgaG9wLWJ5LWhvcCBoZWFkZXIgb3B0aW9ucyAodGhhdCBjb3Vs ZCBiZSByZS13cml0dGVuIG9uIHRoZSBmbHkpLA0KPj4+IHJhdGhlciB0aGFuIGVuY29kZWQgaW4g dGhlIElQdjYgYWRkcmVzcyBzcGFjZT8NCj4+DQo+PiBUaGUgc2VjdGlvbiA0LjEgIkp1c3RpZmNh dGlvbiBmb3IgU2VtYW50aWNzIHdpdGggdGhlIElQdjYgUHJlZml4IiBkZXNjcmliZXMNCj50aGUg cmVhc29ucy4NCj4+DQo+PiBVc2VycyBtYXkgZWFzaWx5IGNoYW5nZSB0aGUgc2V0dGluZyBvZiBl eHRlbnNpb24gaGVhZGVyIGluIG9yZGVyIHRvIG9idGFpbg0KPnVuZGVzZXJ2ZWQgcHJpb3JpdGll cy9wcml2aWxlZ2VzLiBTZW1hbnRpYyBwcmVmaXggYXBwcm9hY2ggZG9lcyByZXF1aXJlIHRoZQ0K PmRlcGxveW1lbnQgb2YgYWNjZXNzIGNvbnRyb2wgZmlsdGVycy4gVGhlIHBhY2tldHMgd2l0aCB0 aGUgbm9uY29tcGxpYW5jZQ0KPnNvdXJjZSBhZGRyZXNzZXMgc2hvdWxkIGJlIGZpbHRlcmVkLiBU aGUgcHJlZml4IGlzIGRlbGVnYXRlZCBieSB0aGUgbmV0d29yay4NCj5UaGVyZWZvcmUgdGhlIG5l dHdvcmsgaXMgYWJsZSB0byBkZXRlY3QgYW55IHVuZGVzaXJlZCBtb2RpZmljYXRpb25zIGFuZCBm aWx0ZXINCj50aGUgcGFja2V0IGFjY29yZGluZ2x5Lg0KPj4NCj4+IENoZWVycywNCj4+DQo+PiBT aGVuZw0KPj4NCj4+DQo+SSBkb24ndCBidXkgeW91ciBqdXN0aWZpY2F0aW9uLiBXaGV0aGVyIGFu IG9wZXJhdG9yIGZpbHRlcnMgb24NCj5hdXRob3Jpc2VkIGFkZHJlc3MgcmFuZ2Ugb3IgcmUtd3Jp dGVzL2ZpbHRlcnMgYW4gdW5hdXRob3Jpc2VkIGhvcC1ieS1ob3ANCj50YWcgaXMgZWZmZWN0aXZl bHkgdGhlIHNhbWUgSU1ITy4gV2UgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIGlzc3VlcyBvZg0KPnBv dGVudGlhbCB0aGVmdCBvZiBzZXJ2aWNlIHdpdGggRFNDUCB0b2RheSwgYW5kIHRoZSBzb2x1dGlv biBpcyBlcXVhbGx5DQo+c2ltcGxlOiBEU0NQIG1hcmtkb3duIGF0IHRoZSBpbmdyZXNzIHBvcnQu DQoNClllcywgdGhlIHRydXN0IGlzc3VlIGlzIHRoZSBzYW1lIHdpdGggRFNDUC4gSG93ZXZlciwg dGhlIERTQ1AgYWJzdHJhY3QgYWxsIHRoZSBzZW1hbnRpY3MgaW50byBzZXJ2aWNlIGNsYXNzZXMs IHdoaWNoIGlzIG9uZSBzaW5nbGUgZGltZW5zaW9uLiBUaGlzIGFic3RyYWN0IHByb2Nlc3Npbmcg aGFzIGxvc3QgYSBsb3Qgb2YgaW5mb3JtYXRpb24sIHdoaWNoIHByb3ZpZGVycyB3YW50IHRvIGlu c3BlY3QgZm9yIGV2ZXJ5IHBhY2tldCwgdGhlbiBwcm9jZXNzIHRoZSBwYWNrZXQgYWNjb3JkaW5n bHkuIFRoZSBleHBsaWNpdGx5IGV4cHJlc3NlZCBzZW1hbnRpY3MgaW4gcHJlZml4IHByb3ZpZGVz IG11Y2ggbW9yZSBpbmZvcm1hdGlvbnMNCg0KU2hlbmcNCg0KPnJlZ2FyZHMsDQo+UmF5SA0K From ggm@algebras.org Thu May 30 18:40:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EE321F96E0 for ; Thu, 30 May 2013 18:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SJIbbIY3wjG for ; Thu, 30 May 2013 18:40:35 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id D11BA21F86DD for ; Thu, 30 May 2013 18:40:34 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 3so1349247pdj.19 for ; Thu, 30 May 2013 18:40:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KYTz0TL6NWBHgH++oTG6OPnPH9CEKUvjjRiPwPLw+BM=; b=WHpGRm34pjz0mzT9k7AFsgT7VYdOFG//g8fR8fxaTGh9Ok49NdMHqBh0SyDb5aTir8 7loPVsamu1LqUQjyoemyY4wPt5WeVt+HGFU3Dj2JfexJXsxuWfvboNsRJ8o0CI/182Ae qGg+qMh8HbxMoAVo0Fkgh8pup1w2Fw7RL4P8/Qd8KRbX7OI2rPabsu7MyylTZ3MyjU6N QA/dbBmN+NRnda6CXwo+NvFznjwP8+WgJACoUrB9w12vWnyjuMnOVDecLmJAYzleATPK rpPk0rRygGAR/1u3lOuO0dwoh4sYfStVlk6rBB+YqbkyeFHPR8og9lvPDGQ2esMpIhR2 fiHg== MIME-Version: 1.0 X-Received: by 10.68.253.230 with SMTP id ad6mr10359108pbd.182.1369964434632; Thu, 30 May 2013 18:40:34 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Thu, 30 May 2013 18:40:34 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:2471:ba1a:be48:1771] In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> Date: Fri, 31 May 2013 11:40:34 +1000 Message-ID: From: George Michaelson To: Sheng Jiang Content-Type: multipart/alternative; boundary=047d7b2e0bff7b43ae04ddf9b325 X-Gm-Message-State: ALoCoQnfctRnvBtaXDmjEeqN2mqfxmDD62kfwzhsJbGoIZkwj/wR9zajUGCL0bAJRMKcXyTNcssr Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:40:40 -0000 --047d7b2e0bff7b43ae04ddf9b325 Content-Type: text/plain; charset=ISO-8859-1 why on address and not per flow? you already have ASICS/FPGA which do flow discrimination, is a packet classifier on src,dst really better, when you cannot actually trust it? On Fri, May 31, 2013 at 11:38 AM, Sheng Jiang wrote: > >> Sheng Jiang > >> 30 May 2013 11:58 > >>>> IP addresses are designed as topology locator, so that every packet > can > >be > >>> routed to its network destination. > >>>> However, even in IPv4 era, some network operators have mapped their IP > >>> address with certain semantic locally. These kind of mechanism > explicitly > >>> express the semantic properties of every packet. Consequently, these > >network > >>> operators can inspect the properties of packets easily by mapping the > >>> addresses back to semantic. > >>>> Network operators, who have large IPv6 address space, may also choose > >to > >>> embedded some semantics into IPv6 addresses by assigning additional > >>> significance to specific bits within the prefix. > >>> draft-jiang-v6ops-semantic-prefix documents a framework method that > >>> network operations may use their addresses with embedded semantics. > >These > >>> semantics bits are only meaningful within a single network, or group of > >>> interconnected networks which share a common addressing policy. Based > >on > >>> these embedded semantic bits in source/destination addresses, the > >network > >>> operators can accordingly treat network packets differently and > efficiently. > >>>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 > >>>> > >>>> Could you please review this draft and comments? It will help the > >document > >>> become more useful information to be shared. > >>>> Best regards, > >>>> > >>>> Sheng > >>>> > >>> I completely understand the desire for operators to have additional > >>> semantics available for customized packet processing. Flow label now > has > >>> very limited properties optimised for load balancers. DSCP only has a > >>> few bits (way less than the number of customers' policies). ACLs are > >>> heavy to process at each hop.... > >>> > >>> But wouldn't this information be better off encoded as tags in one or > >>> more hop-by-hop header options (that could be re-written on the fly), > >>> rather than encoded in the IPv6 address space? > >> > >> The section 4.1 "Justifcation for Semantics with the IPv6 Prefix" > describes > >the reasons. > >> > >> Users may easily change the setting of extension header in order to > obtain > >undeserved priorities/privileges. Semantic prefix approach does require > the > >deployment of access control filters. The packets with the noncompliance > >source addresses should be filtered. The prefix is delegated by the > network. > >Therefore the network is able to detect any undesired modifications and > filter > >the packet accordingly. > >> > >> Cheers, > >> > >> Sheng > >> > >> > >I don't buy your justification. Whether an operator filters on > >authorised address range or re-writes/filters an unauthorised hop-by-hop > >tag is effectively the same IMHO. We have exactly the same issues of > >potential theft of service with DSCP today, and the solution is equally > >simple: DSCP markdown at the ingress port. > > Yes, the trust issue is the same with DSCP. However, the DSCP abstract all > the semantics into service classes, which is one single dimension. This > abstract processing has lost a lot of information, which providers want to > inspect for every packet, then process the packet accordingly. The > explicitly expressed semantics in prefix provides much more informations > > Sheng > > >regards, > >RayH > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b2e0bff7b43ae04ddf9b325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
why on address and not per flow? you already have ASICS/FP= GA which do flow discrimination, is a packet classifier on src,dst really b= etter, when you cannot actually trust it?=A0

On Fri, May 31, 2013 at 11:38 AM, Sheng Jian= g <jiangsheng@huawei.com> wrote:

>> Sheng Jiang <mailto:jiangsheng@huawei.com>
>> 30 May 2013 11:58
>>>> IP addresses are designed as topology locator, so that eve= ry packet can
>be
>>> routed to its network destination.
>>>> However, even in IPv4 era, some network operators have map= ped their IP
>>> address with certain semantic locally. These kind of mechanism= explicitly
>>> express the semantic properties of every packet. Consequently,= these
>network
>>> operators can inspect the properties of packets easily by mapp= ing the
>>> addresses back to semantic.
>>>> Network operators, who have large IPv6 address space, may = also choose
>to
>>> embedded some semantics into IPv6 addresses by assigning addit= ional
>>> significance to specific bits within the prefix.
>>> draft-jiang-v6ops-semantic-prefix documents a framework method= that
>>> network operations may use their addresses with embedded seman= tics.
>These
>>> semantics bits are only meaningful within a single network, or= group of
>>> interconnected networks which share a common addressing policy= . Based
>on
>>> these embedded semantic bits in source/destination addresses, = the
>network
>>> operators can accordingly treat network packets differently an= d efficiently.
>>>> http://tools.ietf.org/html/draft-jiang-= v6ops-semantic-prefix-03
>>>>
>>>> Could you please review this draft and comments? It will h= elp the
>document
>>> become more useful information to be shared.
>>>> Best regards,
>>>>
>>>> Sheng
>>>>
>>> I completely understand the desire for operators to have addit= ional
>>> semantics available for customized packet processing. Flow lab= el now has
>>> very limited properties optimised for load balancers. DSCP onl= y has a
>>> few bits (way less than the number of customers' policies)= . ACLs are
>>> heavy to process at each hop....
>>>
>>> But wouldn't this information be better off encoded as tag= s in one or
>>> more hop-by-hop header options (that could be re-written on th= e fly),
>>> rather than encoded in the IPv6 address space?
>>
>> The section 4.1 "Justifcation for Semantics with the IPv6 Pre= fix" describes
>the reasons.
>>
>> Users may easily change the setting of extension header in order t= o obtain
>undeserved priorities/privileges. Semantic prefix approach does require= the
>deployment of access control filters. The packets with the noncomplianc= e
>source addresses should be filtered. The prefix is delegated by the net= work.
>Therefore the network is able to detect any undesired modifications and= filter
>the packet accordingly.
>>
>> Cheers,
>>
>> Sheng
>>
>>
>I don't buy your justification. Whether an operator filters on
>authorised address range or re-writes/filters an unauthorised hop-by-ho= p
>tag is effectively the same IMHO. We have exactly the same issues of >potential theft of service with DSCP today, and the solution is equally=
>simple: DSCP markdown at the ingress port.

Yes, the trust issue is the same with DSCP. However, the DSCP a= bstract all the semantics into service classes, which is one single dimensi= on. This abstract processing has lost a lot of information, which providers= want to inspect for every packet, then process the packet accordingly. The= explicitly expressed semantics in prefix provides much more informations

Sheng

>regards,
>RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--047d7b2e0bff7b43ae04ddf9b325-- From jiangsheng@huawei.com Thu May 30 18:45:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D621F922A; Thu, 30 May 2013 18:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+MgI6YoKubY; Thu, 30 May 2013 18:45:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E60A521F9123; Thu, 30 May 2013 18:45:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ02380; Fri, 31 May 2013 01:45:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:44:31 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:45:04 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Fri, 31 May 2013 09:44:57 +0800 From: Sheng Jiang To: Arturo Servin Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAIm9sP//gNoAgACfxeD//73ZAIABXijQ Date: Fri, 31 May 2013 01:44:57 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99A22@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9940B@nkgeml512-mbx.china.huawei.com> <51A74A18.3060600@gmail.com> In-Reply-To: <51A74A18.3060600@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:45:12 -0000 Pj4+PiBZZXMuIFdlIHdpbGwgZG8gc28gaW4gdGhlIGZ1dHVyZSB2ZXJzaW9uLg0KPj4+DQo+Pj5H b29kLCBhbmQgSSB0aGluayBpdCdzIGltcG9ydGFudCB0byBkbyBzby4gR2VvcmdlIGFuZCBMb3Jl bnpvJ3MNCj4+PiBjb21tZW50cyBhcmUNCj4+Pmdvb2Qgc3RhcnRpbmcgcG9pbnRzIGZvciB0aGF0 IHNlY3Rpb24uIFRoZSBwb3RlbnRpYWwNCj4+PiBwcml2YWN5L2luZm9ybWF0aW9uDQo+Pj5sZWFr YWdlIGFzcGVjdCBpcyBhbHNvIHdvcnRoIGNhcHR1cmluZywgc2hvdWxkIHRob3NlIGFkZHJlc3Nl cyBiZQ0KPj4+IHNlZW4NCj4+Pm91dHNpZGUgdGhlIG9yZ2FuaXNhdGlvbi4NCj4+DQo+PiBUaGFu a3MsIFRpbS4gVGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyBub3QgcmVjb21tZW5kIG9y IHByb3Bvc2UNCj4+IGEgZ29vZCBhcmNoaXRlY3R1cmUuIEl0IGlzIHRvIGRvY3VtZW50IHNvbWV0 aGluZyB0aGF0IGlzIGdvaW5nIHRvDQo+PiBleGlzdCBhbmQgYW5hbHl6ZSBpdC4gVGhlIHBpdGZh bGxzIGlzIHZlcnkgaW1wb3J0YW50IGZvciBhIG5ldXRyYWwNCj4+IGFuYWx5c2lzDQo+Pg0KPj4g Q2hlZXJzLA0KPj4NCj4+IFNoZW5nDQo+DQo+U2hlbmcsDQo+DQo+ICBZZXMgcGxlYXNlIGRvIHRo aXMuIFRvIG1lIGl0IG5vdyBpdCByZWFkcyBtb3JlIGxpa2UgInlvdSBjYW4gZG8gdGhpcywNCj53 ZSByZWNvbW1lbmQgeW91IHRvIGRvIGl0IiB3aGVuIGl0IHNob3VsZCBzYXkgInlvdSBjYW4gZG8g dGhpcywgaXQgaXMNCj5iYWQgZm9yIHRoaXMsIGl0IGlzIGdvb2QgZm9yIHRoaXMiIGFuZCBldmVu IHlvdSBjb3VsZCBpbmNsdWRlIHNvbWV0aGluZw0KPmxpa2UgIndlIGRvIG5vdCByZWNvbW1lbmQg eW91IGRvIGl0IGJ1dCBpZiB5b3Ugd2FudCB0byBzaG9vdCB5b3UgaW4gdGhlDQo+Zm9vdCB5b3Ug YXJlIGZyZWUgdG8gZG8gc28uIg0KDQpJIHdpbGwgZG8gdGhpcyBmb3Igc3VyZS4gSXQgc2VlbXMg dGhlIGN1cnJlbnQgZm9ybSBnaXZpbmcgcGVvcGxlIHRoZSBleHByZXNzaW9uIHRoYXQgSSBhbSAn c2VsbGluZycgdGhpcyAnZ29vZCcgYXBwcm9hY2guIEkgYW0gbm90LiBJIGp1c3Qgd2FudCB0byBj YWxsIHBlb3BsZSdzIGF0dGVudGlvbiAtIHRoaXMgaXMgc29tZSB3YXkgc29tZSBwcm92aWRlcnMg d291bGQgdXNlIHRoZWlyIGFkZHJlc3Nlcy4gV2UsIGFzIElFVEYsIHNob3VsZCBkb2N1bWVudCBp dCBhbmQgZ2l2ZSBhbmFseXNpcyBvbiBpdC4gSSB3aWxsIG1ha2UgdGhpcyBtdWNoIGNsZWFyZXIg aW4gdGhlIGZ1dHVyZSB2ZXJzaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4vYXMN Cg== From brian.e.carpenter@gmail.com Thu May 30 18:52:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D3D21F9678 for ; Thu, 30 May 2013 18:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzX6BBgKbPK1 for ; Thu, 30 May 2013 18:52:08 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9664621F967F for ; Thu, 30 May 2013 18:52:08 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id g10so1361958pdj.13 for ; Thu, 30 May 2013 18:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WspbAyXHWngrXFNlkPiVU/GhDzf+A7f9Crdx8A/Dtmw=; b=ZOzpxHa4Q3BJ7eJl0hIf8nn0UHs+qjaW3ZgOf/9j+/6lIFa/t0+U7qi587XOSX+88L 1xlWvT0fAD8sebcOHfDkxSEUoRAhClEZ4tfDuGqvxcw7mgwI/r64Rdcq5dfZ+FV+wH9a lQDhDkuLs9+tqfIxYxwOdA/83rVTPMKowABCoSZkH2J9zwyfdj6HRQBDmPOTs1UwImnt KOowae9QWjnC3jyyaKmSA935wBKllXXONILz8NDKJqQqHxM0wswkYPI3FkMKRbDEdjan SjlDXwVhaElVyvGKzch/J287QjjKjdCdMs9niLaxc7vdDJ8zp1irz7RgkBoaw/q1R84g n4YQ== X-Received: by 10.68.204.196 with SMTP id la4mr10563010pbc.190.1369965127457; Thu, 30 May 2013 18:52:07 -0700 (PDT) Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id ue8sm47236068pac.14.2013.05.30.18.52.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 18:52:06 -0700 (PDT) Message-ID: <51A8024D.7080200@gmail.com> Date: Fri, 31 May 2013 13:52:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <51A7CDA9.4090304@massar.ch> In-Reply-To: <51A7CDA9.4090304@massar.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:52:13 -0000 On 31/05/2013 10:07, Jeroen Massar wrote: > On 2013-05-30 14:45, Brian E Carpenter wrote: > [..] >>> In the early news, not really a new problem. >>> >>> RFC1918 and 100.64/10 leak too, >> In traceroutes, link-locals sometimes leak too. > > I have never come across that; except maybe when tracerouting to a > link-local, and then, that would only be one hop anyway. > > If you know how to replicate it, I am very interested in a packet dump > or what is involved to cause it. I understand it happens when the router in question has a next-hop that is link-local and it has been set to use that address as the default source address for ICMP replies, *and* there is no source address filter along the path that blocks it. This is not new; there's a thread starting at: http://www.ietf.org/mail-archive/web/v6ops/current/msg11277.html >> All these are confusing and make the traceroute hard to interpret, >> but they don't actually *matter*. What matters is if they leak in >> actual traffic such as attempted TCP connections. Does that happen? > > One should only see a link-local when: > - the source packet is link-local > - the destination host only has a link-local and replies (TTL or so) > > But that should never cross more than one (1) hop as link-locals should > not be forwarded. True, although in the specific case of traceroute you get a bit of useful information from the illegal forwarding (whether it's link-local or ULA). Brian > > Greets, > Jeroen > > . > From jiangsheng@huawei.com Thu May 30 18:58:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B495C21F96FE; Thu, 30 May 2013 18:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yllBOloQeHw0; Thu, 30 May 2013 18:58:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22E5521F96FF; Thu, 30 May 2013 18:58:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ03001; Fri, 31 May 2013 01:58:50 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:58:16 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:58:48 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 31 May 2013 09:58:45 +0800 From: Sheng Jiang To: "Joel M. Halpern" Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAIm9sIAACK6AgAE2CUA= Date: Fri, 31 May 2013 01:58:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99A45@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <5D36713D8A4E7348A7E10DF7437A4B923AC992AE@nkgeml512-mbx.china.huawei.com> <51A76D81.9020504@joelhalpern.com> In-Reply-To: <51A76D81.9020504@joelhalpern.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:58:59 -0000 PldoaWxlIGl0IGlzIHRydWUgdGhhdCBhbnkgb3BlcmF0b3IgY2FuIGRvIHdoYXRldmVyIHRoZXkg d2FudCwgdGhpcw0KPnByb3Bvc2FsIGlzIGFyY2hpdGVjdHVyYWxseSBhIGJhZCB3YXkgdG8gYWNo aWV2ZSB0aGUga2luZCBvZiBnb2FscyB5b3UNCj5vdXRsaW5lLg0KDQpXaWxsIGltcHJvdmUgdGhl IGV4cHJlc3Npb24gdG8gcmVtb3ZlIHRoZSBtaXNsZWFkIHRoYXQgd2UgYXJlICdzZWxsaW5nJyBp dC4NCg0KPlNvIEkgd291bGQgb3Bwb3NlIHB1Ymxpc2hpbmcgZXZlbiBhbiBpbmZvcm1hdGlvbmFs IFJGQyBvbiBob3cgb25lIG1pZ2h0DQo+ZG8gdGhpcy4NCj4NCj5BcyBhbiBleGFtcGxlIG9mIHRo ZSBwcm9ibGVtcyB3aXRoIHRoaXMsIHlvdSBzdWdnZXN0ZWQgdGhhdCBhbGxvY2F0aW9ucw0KPnRv IGVudGVycHJpc2Ugd291bGQgbm90IGNoYW5nZSB3aXRoIHRoaXMgYXBwcm9hY2guICBUaGF0IHRo ZSBlbnRlcnByaXNlDQo+d291bGQgcmVjZWl2ZSBhIGNlcnRhaW4gc2VtYW50aWMsIGFuZCB3b3Vs ZCBiZSBhbGxvY2F0ZWQgYSBjZXJ0YWluIC80OA0KPnRvIG1hdGNoIHRoYXQuICBXaGlsZSB0aGlz IHNvdW5kcyBhdHRyYWN0aXZlIGFuZCBoYXJtbGVzczoNCj4xKSBJdCBpcyBleHRyZW1lbHkgdW5s aWtlIHRoYXQgYSBjdXN0b21lciB3aWxsIGZhbGwgaW50byBhIHNpbmdsZQ0KPiJzZW1hbnRpYyIg d2l0aCBhbnkgdXNlZnVsIGRlZmluaXRpb24gb2Ygc2VtYW50aWMNCg0KQWdyZWUuIFR5cGljYWxs eSwgdGhlcmUgc2hvdWxkIGJlIG1vcmUgdGhhbiBvbmUgc2VtYW50aWMgZW1iZWRkZWQuIEFjdHVh bGx5LCBpdCBpcyB0aGUgcHJvYmxlbSBvZiBEU0NQLCB3aGljaCBhYnN0cmFjdCBhbGwgdGhlIHNl bWFudGljcyBpbnRvIHNlcnZpY2UgY2xhc3Nlcywgd2hpY2ggaXMgb25lIHNpbmdsZSBkaW1lbnNp b24uIFRoaXMgYWJzdHJhY3QgcHJvY2Vzc2luZyBoYXMgbG9zdCBhIGxvdCBvZiBpbmZvcm1hdGlv biwgd2hpY2ggcHJvdmlkZXJzIHdhbnQgdG8gaW5zcGVjdCBmb3IgZXZlcnkgcGFja2V0LCB0aGVu IHByb2Nlc3MgdGhlIHBhY2tldCBhY2NvcmRpbmdseS4gVGhlIGV4cGxpY2l0bHkgZXhwcmVzc2Vk IHNlbWFudGljcyBpbiBwcmVmaXggcHJvdmlkZXMgbXVjaCBtb3JlIGluZm9ybWF0aW9uLg0KDQo+ MikgWW91IGhhdmUgYXJndWVkIHRoYXQgeW91IGNhbiBub3QgdXNlIERTQ1AgYmVjYXVzZSB0aGV5 IGFyZSBub3QgZmluZQ0KPmVub3VnaCBncmFpbmVkLiAgVGhpcyBtZWFucyB0aGF0IHlvdSB3YW50 IHRvIGluY3JlYXNlIHRoZSByb3V0aW5nDQo+Y29tcGxleGl0eSBieSBtb3JlIHRoYW4gYSBmYWN0 b3Igb2YgNjQsIHdoaWNoIHNlZW1zIHRvIGJlIGEgVkVSWSBiYWQNCj5pZGVhIGZvciBhbnkgb3Bl cmF0b3IgaW5mcmFzdHJ1Y3R1cmUuDQoNCk5vdCBleGFjdGx5IG1vcmUgdGhhbiA2NC4gSXQgaXMg bW9yZSB0aGFuIG9uZSBkaW1lbnNpb24uIFNheSwgd2UgbWF5IGhhdmUgdGhyZWUgc2VtYW50aWNz ICgyLCAzLCA0IHR5cGVzIGZvciBlYWNoIHNlbWFudGljcykgaXQgaXMgb25seSAyNCBwb3NzaWJp bGl0aWVzLiBGdXJ0aGVybW9yZSwgaW4gdGhpcyB3YXksIGl0IGlzIG5vdCBuZWNlc3NhcnkgdGhh dCBvbmUgc2luZ2xlIHJvdXRlciB0byB1bmRlcnN0YW5kIGFsbCBzZW1hbnRpY3MgYW5kIGRpZmZl cmVudGlhdGUgdGhlIHBhY2tldCBwcm9jZXNzaW5nLiBEaWZmZXJlbnQgc2VtYW50aWNzIG1heSB0 cmlnZ2VyIGRpZmZlcmVudCBvbiBkaWZmZXJlbnQgcm91dGVycy4gRm9yIGV4YW1wbGUsIGV4cHJl c3Mgcm91dGVyIG1heSBvbmx5IGNhcmUgYWJvdXQgb25lIHNpbmdsZSBzZW1hbnRpYyAtIHdoZXRo ZXIgdGhlIHBhY2tldCBzaG91bGQgYmUgYWxsb3dlZCB0byBsZWF2ZSB0aGUgZG9tYWluLCB3aGls ZSBzb21lIGZpbHRlciBtYXkgY2FyZSBhYm91dCBhbm90aGVyIHNlbWFudGljcy4NCg0KQ2hlZXJz LA0KDQpTaGVuZw0KDQo+U28gZXZlbiBmcm9tIGEgc2ltcGxlIGFuYWx5c2lzLCB0aGlzIHNlZW1z IHNvbWV3aGVyZSBiZXR3ZWVuIHVzZWxlc3MgYW5kDQo+ZXh0cmVtZWx5IGRhbmdlcm91cy4NCj4N Cj5Zb3VycywNCj5Kb2VsIE0uIEhhbHBlcm4NCj4NCj5PbiA1LzMwLzIwMTMgMzowMCBBTSwgU2hl bmcgSmlhbmcgd3JvdGU6DQo+Li4uDQo+PiBIaSwgVGltLA0KPj4NCj4+IEl0IGlzIGV4YWN0bHkg d2hhdCB0aGUgZHJhZnQgZG9jdW1lbnQuIFRoZXNlIHNlbWFudGljcyBpcyBvbmx5IG1lYW5pbmdm dWwNCj5sb2NhbGx5IHdpdGhpbiB0aGUgYXNzaWduaW5nIHByb3ZpZGVyIG5ldHdvcmsuIEl0IG1h eSBvbmx5IGJlIGludGVycHJldGF0aW9uDQo+YmV0d2VlbiBhZ3JlZWluZyBwcm92aWRlcnMuDQo+ Pg0KPj4gQW55IGVmZm9ydHMgdG8gYWRkIGdsb2JhbCBvciBnZW5lcmljIHNlbWFudGljcyB0byBJ UCBhZGRyZXNzIGlzIG92ZXJsb2FkIHRoZQ0KPklQIGFyY2hpdGVjdHVyZSBhbmQgaXQgYmFkIGRp cmVjdGlvbiwgSSBhZ3JlZS4NCj4+DQo+Pj4gSSB0aGluayBwZW9wbGUgd2lsbCBkbyB0aGlzIHR5 cGUgb2YgdGhpbmcsIHNvIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQNCj4+PiBkaXNjdXNzaW5n IHRoZSBwcm9zIGFuZCBjb25zLCBhbmQgaG93IHNlbWFudGljcyBjYW4gYmUgdXNlZCwgaXMgcHJv YmFibHkgYQ0KPj4+IGdvb2QgdGhpbmcuICBQZXJoYXBzIGEgIlBvdGVudGlhbCBQaXRmYWxscyIg dHlwZSBzZWN0aW9uIGFmdGVyIHRoZQ0KPiJQb3RlbnRpYWwNCj4+PiBCZW5lZml0cyIgc2VjdGlv biB3b3VsZCBiYWxhbmNlIHRoZSBkb2N1bWVudCBhIGxpdHRsZSBiZXR0ZXI/DQo+Pg0KPj4gWWVz LiBXZSB3aWxsIGRvIHNvIGluIHRoZSBmdXR1cmUgdmVyc2lvbi4NCj4+DQo+PiBDaGVlcnMsDQo+ Pg0KPj4gU2hlbmcNCj4uLi4NCg== From leo.liubing@huawei.com Thu May 30 19:07:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D8721F96FB for ; Thu, 30 May 2013 19:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+UTLd9hIs+R for ; Thu, 30 May 2013 19:07:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 196CE21F967F for ; Thu, 30 May 2013 19:07:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY65718; Fri, 31 May 2013 02:07:44 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 03:05:24 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 03:05:59 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 31 May 2013 10:05:56 +0800 From: "Liubing (Leo)" To: Mark Smith , Lorenzo Colitti Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDCP/o7FharvUWYCiMlnZFFoJkc2luAgAGrd2A= Date: Fri, 31 May 2013 02:05:56 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D72A961@nkgeml506-mbx.china.huawei.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 02:07:54 -0000 > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@yahoo.com.au] > Sent: Thursday, May 30, 2013 4:11 PM > To: Lorenzo Colitti; v6ops@ietf.org WG > >Personally, I think that providing said guidance is much more useful and > important than enumerating scenarios that aren't widely, if at all, > implemented, and I hope that the authors > of=A0draft-ietf-v6ops-ula-usage-recommendations will agree. [Bing] I agree it would be helpful to provide some basic/general operationa= l guidance, and we did plan to include some in the next version. But as Mark commented in the following, the original intention of this draf= t is about use scenarios. Operational guidance is only a supplementary. =20 > So is this draft aiming for BCP status and therefore should only reflect = best > common practice? If not, I think it is reasonable to present scenarios wh= ere > ULAs could be useful.=A0 =20 >We've got a lot of experience with private address > spaces from IPv4 (the=A0Deprecating Site Local Addresses RFC3879 is also = a > pretty complete list of the problems with RFC1918 addresses), so the only > real difference is scenarios where concurrent global and private address > spaces could be useful.=20 [Bing] It might not be the "only" difference, but surely it is the most obv= ious advance comparing to IPv4, and it was the most important motivation to= write the draft. >In some cases, they'll just be more capable versions > of what we've already doing in IPv4 e.g. private addressed loopbacks on > routers, global addresses on the links, in a ULA environment you would ad= d > ULAs to the links too, which could make troubleshooting and other OAM les= s > dependent on the global address space. [Bing] Agreed. I think that would be a good use case and hope to see some r= eal experience in the future. All the best, Bing > Regards, > Mark. >=20 > >Cheers, > >Lorenzo > > > > > >---------- Forwarded message ---------- > >From: Jeroen Massar > >Date: Thu, May 30, 2013 at 4:59 AM > >Subject: Usage of fd00::/8 on the Interwebz - something with filters and > uRPF > >To: ipv6-ops@lists.cluenet.de > > > > > >... > >=A04 =A02001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) =A020.755 > ms =A020.763 ms =A020.784 ms > >=A05 =A0fd00:3303::1 (fd00:3303::1) =A022.010 ms =A021.984 ms =A021.986 = ms > >=A06 =A02a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) =A017.806 > ms =A017.889 ms =A017.842 ms > >=A07 =A02a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) =A018.720 > ms =A018.593 ms =A018.617 ms > >... > > > >Hmmmm fd00::/8, that really should never ever be visible on the Internet= , > being Unique *LOCAL* Addresses. > >And it does not look like they applied the randomness bit for picking a = prefix > either. > >You would also almost think that a /28 is more than enough address space > to put a few router loopbacks in. > > > >It is apparently time for people to start checking their filters again b= ecause > it seems that these packets leak into other ASNs too... > > > >More generally, do recheck your network for BCP38 compliance, please do > apply it and require your peers to do the same! > > > >Greets, > >=A0Jeroen > > > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > > > > From Ted.Lemon@nominum.com Thu May 30 19:12:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAD421F901A for ; Thu, 30 May 2013 19:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-NRjl7iFuO7 for ; Thu, 30 May 2013 19:12:26 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B721F8E9D for ; Thu, 30 May 2013 19:12:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUagHCYzHk05OMIYxjhdPdOcgKEFCT7sW@postini.com; Thu, 30 May 2013 19:12:26 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 457461B81C5 for ; Thu, 30 May 2013 19:12:25 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 365CB190052; Thu, 30 May 2013 19:12:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 30 May 2013 19:12:25 -0700 From: Ted Lemon To: Jeroen Massar Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAAZAgIAARGOA Date: Fri, 31 May 2013 02:12:24 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BDDBD@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <51A7CDA9.4090304@massar.ch> In-Reply-To: <51A7CDA9.4090304@massar.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <55D743264804C844A16E5DD7181FDB46@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 02:12:37 -0000 On May 30, 2013, at 6:07 PM, Jeroen Massar wrote: > If you know how to replicate it, I am very interested in a packet dump > or what is involved to cause it. Just number your internal network using ULAs and no global addresses, and t= hen run a traceroute across it. Global addresses on the source end, globa= l addresses on the destination end, ULAs in the middle. The only way to "= fix" this is to break traceroute. This does not represent brokenness. O= f course, it's just shy of brokenness=97if the devices that are answering t= he ICMP messages in the core of the network are using ULAs for that, they w= ould also use ULAs if they tried to *connect* to hosts outside of the core = of the network. But they are infrastructure devices=97routers=97so in pra= ctice they don't do this, and it isn't a problem. From jiangsheng@huawei.com Thu May 30 19:23:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C16321F9950; Thu, 30 May 2013 19:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfK9kpuLyHDB; Thu, 30 May 2013 19:23:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CCC7721F910D; Thu, 30 May 2013 19:23:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ04124; Fri, 31 May 2013 02:23:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 03:22:06 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 03:22:41 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 31 May 2013 10:22:38 +0800 From: Sheng Jiang To: Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAEA7rCAABrPAIABMw5Q Date: Fri, 31 May 2013 02:22:37 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99A9B@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9924F@nkgeml512-mbx.china.huawei.com> <5B817425-B386-4D9F-AD4C-DF69718411EE@delong.com> In-Reply-To: <5B817425-B386-4D9F-AD4C-DF69718411EE@delong.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 02:23:15 -0000 Pj4gVGhlc2UgZW1iZWRkZWQgc2VtYW50aWNzIGFyZSB2ZXJ5IGRpZmZlcmVudCBmcm9tIEVuZCBT eXN0ZW0gSWRlbnRpZmllci4NCj5UaGUgZW5kIHN5c3RlbSBpZGVudGlmaWVyIGZ1bmN0aW9ucyB3 YXMgcHJvYmxlbSBiZWNhdXNlIGl0IHZpb2xlbnRzIHRoZSBsYXllcg0KPm1vZGVsLiBNYW55IEFQ UHMgb3IgdHJhbnNwb3J0IGxheWVyIHVzZSBJUCBhZGRyZXNzIGFzIHRoZWlyIGlkZW50aWZpZXIu IEFuZCB0aGUNCj5lbmQgc3lzdGVtIGlkZW50aWZpZXIgYnJlYWtzIGluIGF0IGxlYXN0IHR3byBz Y2VuYXJpb3M6IHdoZW4gZW5kIGRldmljZXMNCj5jaGFuZ2UgdGhlIGFjY2VzcyBwb2ludHMgb3Ig d2hlbiBJUCBsYXllciB0cmFuc2xhdGlvbiAoTkFUNDQgb3IgTkFUNjQpDQo+aGFwcGVucy4NCj4N Cj5JJ20gbm90IHN1cmUgaG93IHRoYXQncyByZWxldmFudCB0byB0aGlzIGRpc2N1c3Npb24uDQo+ DQo+SXQgZG9lcyBub3QgY2hhbmdlIHRoZSBmYWN0IHRoYXQgb3ZlcmxvYWRpbmcgc2VtYW50aWNz IG9udG8gYWRkcmVzc2VzIGlzIGFuDQo+aW5oZXJlbnRseSBiYWQgaWRlYS4NCj4NCj4+IFRoZSBw cm9wb3NlZCBlbWJlZGRlZCBzZW1hbnRpY3MgaXMgc3RpbGwgbGF5ZXIgMy4gVGhleSBhcmUgdXNl ZCBmb3Igcm91dGVyJ3MNCj5wYWNrZXQgcHJvY2Vzc2luZy4gVGhlc2UgZW1iZWRkZWQgc2VtYW50 aWNzIGlzIG9ubHkgbWVhbmluZ2Z1bCBsb2NhbGx5DQo+d2l0aGluIElTUCBvd25lciBuZXR3b3Jr LiBBZnRlciBsZWF2aW5nIHRoZSBJU1AgbmV0d29yaywgSVAgYWRkcmVzc2VzIGFyZQ0KPm9ubHkg bG9jYXRvciwgbm90aGluZyBtb3JlLiBUaGUgYm90dG9tIGxpbmUgaXMgYSBuZXR3b3JrIG9wZXJh dG9yIGNhbiBjaG9vc2UNCj50byBlbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYgYWRk cmVzc2VzIGFzc2lnbm1lbnQuIFdlLCBhcyBJRVRGLA0KPm1heSBub3QgZW5jb3VyYWdlIHN1Y2gg dXNhZ2UsIGJ1dCBzaG91bGQgZG9jdW1lbnQgaXQgYW5kIG1heSBnaXZlIHNvbWUNCj5ndWlkYW5j ZSBvciBhbmFseXNpcyBvZiBpdC4NCj4NCj5UaGUgcHJvYmxlbSB3aXRoIG92ZXJsb2FkaW5nIHNl bWFudGljcyBjYW4gb2NjdXIgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yDQo+bm90IHlvdSBjcm9z cyBsYXllciBib3VuZGFyaWVzLg0KPg0KPllvdSBhcmUgY3JlYXRpbmcgYXJ0aWZpY2lhbCBwYXJ0 aXRpb25zIG9mIGFkZHJlc3Mgc3BhY2Ugd2hpY2ggY3JlYXRlcyB0aGUNCj5wb3NzaWJpbGl0eSBv ZiBmaWxsaW5nIHVwIG9uZSBwYXJ0aXRpb24gd2hpbGUgc3BhY2UgcmVtYWlucyBpbiBhbm90aGVy LiBUaGlzIG1heQ0KPmNyZWF0ZSBhIHNpdHVhdGlvbiB3aGVyZSB5b3UgYXJlIHVuYWJsZSB0byBn ZXQgbW9yZSBzcGFjZSBmcm9tIHRoZSBSSVIgb3INCj51cHN0cmVhbSBkdWUgdG8gaW5lZmZpY2ll bnQgdXRpbGl6YXRpb24gYW5kIHlvdSBhcmUgdGhlbiBmb3JjZWQgdG8gdmlvbGF0ZSB5b3VyDQo+ c2VtYW50aWMgYm91bmRhcmllcyBqdXN0IHRvIGtlZXAgdGhlIG5ldHdvcmsgcnVubmluZy4NCg0K RnVsbHkgYWdyZWUuIFdlIHdpbGwgZG9jdW1lbnQgdGhpcyBpbnRvIGEgbmV3IHNlY3Rpb24gb2Yg dGhpcyBkb2N1bWVudC4gIlBvdGVudGlhbCBQaXRmYWxscyINCg0KPlVuZm9ydHVuYXRlbHksIHNp bmNlDQo+eW91J3ZlIGN1bHRpdmF0ZWQgYWxsIHRoZXNlIHNlbWFudGljIGFzc3VtcHRpb25zIGlu IHBlb3BsZXMgaGVhZHMgKGlmIG5vdA0KPnJ1bm5pbmcgY29kZSksIG5vdyB5b3UndmUgZ290IGFk ZGl0aW9uYWwgcHJvYmxlbXMgd2hpY2ggbGFzdCBhIHZlcnkgbG9uZyB0aW1lDQo+YW5kIGRvbid0 IG5lY2Vzc2FyaWx5IGFwcGVhciByaWdodCBhd2F5Lg0KPg0KPkl0J3MgYSByZWFsbHkgZ3JlYXQg d2F5IHRvIGluc3RhbGwgdGltZSBib21icyBpbiB0byBvcGVyYXRpb25hbCBzeXN0ZW1zLg0KDQpJ IGFtIG5vdCBzdXJlIHdoZXRoZXIgZ29vZCBkZXNpZ25pbmcgYXQgdGhlIGJlZ2lubmluZyBjYW4g YXZvaWQgdGhpcyByZXN1bHQgb3Igbm90LiBJIGFtIHZlcnkgbXVjaCB3aXRoIHlvdSB0aGF0IHBy b3ZpZGVyLCB3aG8gY2hvb3NlIHRvIHBsYXkgdGhlaXIgb3duIGFkZHJlc3MgdGhpcyB3YXksIHNo b3VsZCBiZSBhd2FyZSBzdWNoIHJpc2suIFNvLCB3ZSBzaG91bGQgcHVibGljIHRoZXNlIGluZm9y bWF0aW9uIGluIG9yZGVyIHRvIG1ha2UgdGhlbSBrbm93IGl0IGJlZm9yZSB0aGV5IGRlY2lkZSBq dW1wIGludG8gaXQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiBJIGRvIG5vdA0KPnJl Y29tbWVuZCBpdC4NCj4NCj5Pd2VuDQo+DQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4NCj4+IFNo ZW5nDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogT3dlbiBE ZUxvbmcgW21haWx0bzpvd2VuQGRlbG9uZy5jb21dDQo+Pj4gU2VudDogVGh1cnNkYXksIE1heSAz MCwgMjAxMyA3OjAyIEFNDQo+Pj4gVG86IFNoZW5nIEppYW5nDQo+Pj4gQ2M6IDx2Nm9wc0BpZXRm Lm9yZz47IGlwdjZAaWV0Zi5vcmc7DQo+Pj4gZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJl Zml4QHRvb2xzLmlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFt2Nm9wc10gQ291bGQgSVB2NiBh ZGRyZXNzIGJlIG1vcmUgdGhhbg0KPj4+IGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1h bnRpYy1wcmVmaXgtMDMNCj4+Pg0KPj4+IFBlcnNvbmFsbHksIEkgdGhpbmsgdGhpcyBpcyBhbiBp bmhlcmVudGx5IGJhZCBpZGVhLg0KPj4+DQo+Pj4gSVAgYWRkcmVzc2VzIG5lZWQgbGVzcyBvdmVy bG9hZGluZyBvZiBzZW1hbnRpY3MsIG5vdCBtb3JlLg0KPj4+DQo+Pj4gV2UgYWxyZWFkeSB1c2Ug SVAgYWRkcmVzc2VzIGZvciB0d28gY29uZmxpY3RpbmcgcHVycG9zZXPigKYgVG9wb2xvZ3kNCj5s b2NhdG9yDQo+Pj4gYW5kIEVuZCBTeXN0ZW0gSWRlbnRpZmllci4NCj4+Pg0KPj4+IFRoaXMgb3Zl cmxvYWRpbmcgaXMgYXQgdGhlIGhlYXJ0IG9mIG91ciBjdXJyZW50IHNjYWxpbmcgaXNzdWVzIHdp dGggcmVzcGVjdCB0bw0KPj4+IHRoZSByb3V0aW5nIHRhYmxlLiBXaGlsZSB0aGVzZSBpc3N1ZXMg YXJlIGN1cnJlbnRseSBsZXNzIGNyaXRpY2FsIHRoYW4gdGhleQ0KPmhhdmUNCj4+PiBiZWVuIGlu IHRoZSBwYXN0IGFuZCB3aWxsIGxpa2VseSBnZXQgcXVpdGUgYSBiaXQgbGVzcyBjcml0aWNhbCBp biBJUHY2LCB0aGF0IGlzIG9ubHkNCj4+PiBiZWNhdXNlIHdlIGhhdmUgZ2l2ZW4gdXAgYSBmYWly IGFtb3VudCBvZiBmdW5jdGlvbmFsaXR5IHRvIHByZXNlcnZlDQo+Pj4gc2NhbGFiaWxpdHkgaW4g dGhpcyByZWdhcmQuDQo+Pj4NCj4+PiBJZiB3ZSBkaWQgbm90IGhhdmUgdGhpcyBvdmVybG9hZGlu ZywgdGhlbiBhbiBlbnRpdHkgY291bGQgb2J0YWluIGEgc2V0IG9mDQo+Pj4gZW5kLXN5c3RlbSBp ZGVudGlmaWVycyBhbmQga2VlcCB0aGVtIHRocm91Z2hvdXQgdGhlaXIgbGlmZXRpbWUsIHJlZ2Fy ZGxlc3MNCj5vZg0KPj4+IHRvcG9sb2dpY2FsIGNoYW5nZXMuIFRvZGF5LCB3aGVyZSB0aGUgYWRk cmVzc2VzIGFyZSBvdmVybG9hZGVkIHdpdGggYm90aA0KPj4+IHNlbWFudGljcywgd2UgZWl0aGVy IGhhdmUgdG8gZm9yY2UgbW9zdCBlbnRpdGllcyB0byBjaGFuZ2UgdGhlaXIgbnVtYmVycw0KPj4+ IHdoZW4gdGhleSBjaGFuZ2UgdG9wb2xvZ3kgb3Igd2UgZmFjZSB1bnN1c3RhaW5hYmxlIGdyb3d0 aCBpbiB0aGUNCj5yb3V0aW5nDQo+Pj4gdGFibGVzLg0KPj4+DQo+Pj4gVGhlIGlkZWEgb2YgYWRk aW5nIG1vcmUgc2VtYW50aWNzIHRvIGFkZHJlc3NpbmcgcmF0aGVyIHRoYW4gc2Vla2luZyB0bw0K Pj4+IHJlZHVjZSB0aGlzIG92ZXJsb2FkaW5nIHNlZW1zIGEgc3RlcCBpbiB0aGUgd3JvbmcgZGly ZWN0aW9uLCBJTUhPLg0KPj4+DQo+Pj4gT3dlbg0KPj4+DQo+Pj4gT24gTWF5IDI5LCAyMDEzLCBh dCAxMjowNiBBTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbT4NCj4+PiB3cm90 ZToNCj4+Pg0KPj4+PiBJUCBhZGRyZXNzZXMgYXJlIGRlc2lnbmVkIGFzIHRvcG9sb2d5IGxvY2F0 b3IsIHNvIHRoYXQgZXZlcnkgcGFja2V0IGNhbg0KPmJlDQo+Pj4gcm91dGVkIHRvIGl0cyBuZXR3 b3JrIGRlc3RpbmF0aW9uLg0KPj4+Pg0KPj4+PiBIb3dldmVyLCBldmVuIGluIElQdjQgZXJhLCBz b21lIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFwcGVkIHRoZWlyIElQDQo+Pj4gYWRkcmVzcyB3 aXRoIGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhlc2Uga2luZCBvZiBtZWNoYW5pc20gZXhw bGljaXRseQ0KPj4+IGV4cHJlc3MgdGhlIHNlbWFudGljIHByb3BlcnRpZXMgb2YgZXZlcnkgcGFj a2V0LiBDb25zZXF1ZW50bHksIHRoZXNlDQo+bmV0d29yaw0KPj4+IG9wZXJhdG9ycyBjYW4gaW5z cGVjdCB0aGUgcHJvcGVydGllcyBvZiBwYWNrZXRzIGVhc2lseSBieSBtYXBwaW5nIHRoZQ0KPj4+ IGFkZHJlc3NlcyBiYWNrIHRvIHNlbWFudGljLg0KPj4+Pg0KPj4+PiBOZXR3b3JrIG9wZXJhdG9y cywgd2hvIGhhdmUgbGFyZ2UgSVB2NiBhZGRyZXNzIHNwYWNlLCBtYXkgYWxzbyBjaG9vc2UNCj50 bw0KPj4+IGVtYmVkZGVkIHNvbWUgc2VtYW50aWNzIGludG8gSVB2NiBhZGRyZXNzZXMgYnkgYXNz aWduaW5nIGFkZGl0aW9uYWwNCj4+PiBzaWduaWZpY2FuY2UgdG8gc3BlY2lmaWMgYml0cyB3aXRo aW4gdGhlIHByZWZpeC4NCj4+PiBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXggZG9j dW1lbnRzIGEgZnJhbWV3b3JrIG1ldGhvZCB0aGF0DQo+Pj4gbmV0d29yayBvcGVyYXRpb25zIG1h eSB1c2UgdGhlaXIgYWRkcmVzc2VzIHdpdGggZW1iZWRkZWQgc2VtYW50aWNzLg0KPlRoZXNlDQo+ Pj4gc2VtYW50aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aXRoaW4gYSBzaW5nbGUgbmV0 d29yaywgb3IgZ3JvdXAgb2YNCj4+PiBpbnRlcmNvbm5lY3RlZCBuZXR3b3JrcyB3aGljaCBzaGFy ZSBhIGNvbW1vbiBhZGRyZXNzaW5nIHBvbGljeS4gQmFzZWQNCj5vbg0KPj4+IHRoZXNlIGVtYmVk ZGVkIHNlbWFudGljIGJpdHMgaW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3NlcywgdGhlDQo+ bmV0d29yaw0KPj4+IG9wZXJhdG9ycyBjYW4gYWNjb3JkaW5nbHkgdHJlYXQgbmV0d29yayBwYWNr ZXRzIGRpZmZlcmVudGx5IGFuZCBlZmZpY2llbnRseS4NCj4+Pj4NCj4+Pj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4+ DQo+Pj4+IENvdWxkIHlvdSBwbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgYW5kIGNvbW1lbnRzPyBJ dCB3aWxsIGhlbHAgdGhlDQo+ZG9jdW1lbnQNCj4+PiBiZWNvbWUgbW9yZSB1c2VmdWwgaW5mb3Jt YXRpb24gdG8gYmUgc2hhcmVkLg0KPj4+Pg0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+DQo+Pj4+ IFNoZW5nDQo+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXQ0KPj4+Pj4gU2VudDogVHVlc2RheSwgTWF5IDI4LCAyMDEzIDEwOjI4IEFNDQo+Pj4+PiBU bzogUWlvbmcgU3VuOyBJYW4gRmFycmVyOyBTaGVuZyBKaWFuZzsgQm95YW5nDQo+Pj4+PiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4+PiBkcmFmdC1qaWFuZy12Nm9w cy1zZW1hbnRpYy1wcmVmaXgtMDMudHh0DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMudHh0DQo+Pj4+ PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0 ZWQgdG8gdGhlDQo+Pj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+Pj4+Pg0KPj4+Pj4gRmlsZW5hbWU6 ICAgICBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgNCj4+Pj4+IFJldmlzaW9uOiAg ICAgMDMNCj4+Pj4+IFRpdGxlOiAgICAgICAgIEEgRnJhbWV3b3JrIGZvciBTZW1hbnRpYyBJUHY2 IFByZWZpeA0KPj4+Pj4gQ3JlYXRpb24gZGF0ZTogICAgIDIwMTMtMDUtMjgNCj4+Pj4+IEdyb3Vw OiAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4+Pj4gTnVtYmVyIG9mIHBhZ2VzOiAx OQ0KPj4+Pj4gVVJMOg0KPj4+DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzLnR4dA0KPj4+Pj4gU3RhdHVzOg0K Pj4+Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy12Nm9wcy1z ZW1hbnRpYy1wcmVmaXgNCj4+Pj4+IEh0bWxpemVkOg0KPj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4+PiBEaWZm Og0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamlhbmctdjZv cHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4+Pg0KPj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+PiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIGZyYW1ld29yayBtZXRob2QgdGhhdCBuZXR3b3JrIG9wZXJh dGlvbnMNCj4+Pj4+IG1heSB1c2UgdGhlaXIgYWRkcmVzc2VzLiAgTmV0d29yayBvcGVyYXRvcnMs IHdobyBoYXZlIGxhcmdlIElQdjYNCj4+Pj4+IGFkZHJlc3Mgc3BhY2UsIG1heSBjaG9vc2UgdG8g ZW1iZWRkZWQgc29tZSBzZW1hbnRpY3MgaW50byBJUHY2DQo+Pj4+PiBhZGRyZXNzZXMgYnkgYXNz aWduaW5nIGFkZGl0aW9uYWwgc2lnbmlmaWNhbmNlIHRvIHNwZWNpZmljIGJpdHMNCj4+Pj4+IHdp dGhpbiB0aGUgcHJlZml4LiAgQnkgZW1iZWRkZWQgc2VtYW50aWNzIGludG8gSVB2NiBwcmVmaXhl cywgdGhlDQo+Pj4+PiBzZW1hbnRpY3Mgb2YgcGFja2V0cyBjYW4gYmUgaW5zcGVjdGVkIGVhc2ls eS4gIFJvdXRlcnMgYW5kIG90aGVyDQo+Pj4+PiBpbnRlcm1lZGlhcnkgZGV2aWNlcyBjYW4gZWFz aWx5IGFwcGx5IHJlbGV2YW50IHBvbGljaWVzIGFzIHJlcXVpcmVkLg0KPj4+Pj4gUGFja2V0LWxl dmVsIGRpZmZlcmVudGlhdGlvbiBjYW4gYWxzbyBlbmFibGUgZmxvdy1sZXZlbCBhbmQgdXNlci0N Cj4+Pj4+IGxldmVsIGRpZmZlcmVudGlhdGlvbi4gIENvbnNlcXVlbnRseSwgdGhlIG5ldHdvcmsg b3BlcmF0b3JzIGNhbg0KPj4+Pj4gYWNjb3JkaW5nbHkgdHJlYXQgbmV0d29yayBwYWNrZXRzIGRp ZmZlcmVudGx5IGFuZCBlZmZpY2llbnRseS4gIFRoZQ0KPj4+Pj4gbWFuYWdlbWVudCBhbmQgbWFp bnRlbmFuY2Ugb2YgbmV0d29ya3MgY2FuIGJlIG11Y2ggc2ltcGxlci4NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+Pg0KPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCg== From jiangsheng@huawei.com Thu May 30 19:54:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4E821F9339; Thu, 30 May 2013 19:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGZWFV53I0ud; Thu, 30 May 2013 19:54:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4421F8CB4; Thu, 30 May 2013 19:54:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ05831; Fri, 31 May 2013 02:54:46 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 03:53:48 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 03:54:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Fri, 31 May 2013 10:54:16 +0800 From: Sheng Jiang To: "Duncan, Richard (Jeremy)" , Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXNw0JNfUIpIfbEiqc0a18kokB5kdRjJggABSEwCAAP8ssA== Date: Fri, 31 May 2013 02:54:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99AF7@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com>, <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> , <5D36713D8A4E7348A7E10DF7437A4B923AC9927B@nkgeml512-mbx.china.huawei.com> <923297B868FB664FBFA90FCC255696DF591E69CC@BY2PRD0510MB366.namprd05.prod.outlook.com> In-Reply-To: <923297B868FB664FBFA90FCC255696DF591E69CC@BY2PRD0510MB366.namprd05.prod.outlook.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 02:54:54 -0000 Pk5vdCBmb2xsb3dpbmcuLiAgSWYgdGhlIHByb3ZpZGVyIHB1dHMgc2VtYW50aWNzIG9uIGJpdHMg MzAtMzIsIGFuZCBJIGhhZCBhDQo+bmVlZCBmb3Igc2VydmljZXMgY292ZXJlZCBieSBvdGhlciBi aXRzIEkgd291bGQgdGhlbiBuZWVkIHRvIGhhdmUgYQ0KPm11bHRpLWRpc3BhcmF0ZSBhbGxvY2F0 aW9uIG9mIHNheSAoMykgLzQ4cyAtIG9yICgzKSAvNTJzLCB3aGF0ZXZlci4gIFRoZW4gdGhlDQo+ cHJvdmlkZXIgd2lsbCBoYXZlIGEgbG90IG9mIHVudXNlZCBzcGFjZSBpbnNpZGUgdGhlaXIgLzMw IGZvciBzZXJ2aWNlcy4NCg0KWWVzLCBEdW5jYW4uIEkgd2lsbCBub3QgZGVueSB0aGVyZSB3aWxs IGJlIG1vcmUgYWRkcmVzcyB3YXN0ZWQuIEhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgeW91ciBjb25j ZXJuIHNjZW5hcmlvIHdpbGwgaGFwcGVuLiBUaGUgcHJvdmlkZXIncyBhbGxvY2F0aW9uIHBsYW4g Zm9yIGVudGVycHJpc2Ugc2hvdWxkIGJlIHN0YWJsZS4gVGhlIHRyYWZmaWMgZnJvbSBvbmUgc2lu Z2xlIGVudGVycHJpc2Ugc2hvdWxkIGJlIHRyZWF0ZWQgYXMgZXF1YWwgb24gcHJvdmlkZXIncyBz aWRlLiBUaGUgYWJvdmUgbWVudGlvbmVkIHNjZW5hcmlvIHNob3VsZCBvbmx5IGhhcHBlbiBpZiB0 aGUgZW50ZXJwcmlzZSBpdHNlbGYgd2FudHMgdGhlIHByb3ZpZGVyIHRyZWF0IHRoZWlyIHRyYWZm aWMgZGlmZmVyZW50bHkuIEZvciBleGFtcGxlLCBwYXJ0IG9mIHByb3ZpZGVycyB0cmFmZmljIG1h eSB3YW50IHRvIGJlIGhpZ2hseSBzZWN1cmVkLCB0aGV5IHNob3VsZCB1c2Ugb24gLzQ4LCB0aGUg b3RoZXIgdHJhZmZpY3MgaXMgbm9ybWFsLCB0aGV5IHVzZSBhbm90aGVyIC80OC4NCg0KU2hlbmcN Cg0KPkkganVzdCBkb24ndCB1bmRlcnN0YW5kaW5nIHdoeSB1c2luZyBIYkggb3B0aW9ucywgVEMg Zm9yIERpZmZTZXJ2IG9yIHRoZSBGTA0KPmRvZXNuJ3QgYWxyZWFkeSBhbnN3ZXIgdGhlIG1haWw/ ICBJZiB0aGlzIHdhcyBteSBwcm92aWRlcnMgcGxhbiwgSSB3b3VsZCBzaG9wDQo+Zm9yIGFub3Ro ZXIgcHJvdmlkZXIuDQo+DQo+MDEwMTAwMTEwMTEwMDEwMTAxMTAxMTAxMDExMTAwMDAwMTEwMDEw MTAxMTEwMDEwMDAxMDAwMDAwMTAwMDExDQo+MDAxMTAxMDAxDQo+DQo+SmVyZW15IER1bmNhbg0K PlNlbmlvciBEaXJlY3RvciwgSVB2NiBOZXR3b3JrIEFyY2hpdGVjdCBTYWxpZW50IEZlZGVyYWwg U29sdXRpb25zLCBJbmMuDQo+KE5vdyBpbmNsdWRpbmcgU0dJUyAmIENvbW1hbmQgSW5mb3JtYXRp b24gSW5jLikNCj40MDAwIExlZ2F0byBSb2FkLCBTdWl0ZSA2MDAgRmFpcmZheCwgVkEgMjIwMzMN Cj5Hb29nbGUgVm9pY2U6ICA1NDAuNDQwLjExOTMNCj5qZXJlbXkuZHVuY2FuQHNhbGllbnRmZWQu Y29tDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkZyb206 IFNoZW5nIEppYW5nIFtqaWFuZ3NoZW5nQGh1YXdlaS5jb21dDQo+U2VudDogVGh1cnNkYXksIE1h eSAzMCwgMjAxMyAyOjQ1IEFNDQo+VG86IER1bmNhbiwgUmljaGFyZCAoSmVyZW15KTsgT3dlbiBE ZUxvbmcNCj5DYzogPHY2b3BzQGlldGYub3JnPjsgZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMt cHJlZml4QHRvb2xzLmlldGYub3JnOw0KPmlwdjZAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW3Y2 b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuDQo+bG9jYXRvcj8vL2RyYWZ0LWpp YW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMw0KPg0KPkhpLCBEdW5jYW4sDQo+DQo+QWN0dWFs bHksIHlvdSBxdWVzdGlvbiBpcyB2ZXJ5IGRldGFpbGVkIHNjZW5hcmlvIGluIHRoZSBhcHByb2Fj aC4gVGhlIGFuc3dlciBpcw0KPnRoZSBwcm92aWRlciBzdGlsbCBhc3NpZ24gYSAvNDggdG8gYW4g b3JnYW5pemF0aW9uLiBCdXQgd2l0aGluIHRoZSBhc3NpZ25lZCAvNDgsDQo+c29tZSBiaXQgKGZv ciBleGFtcGxlLCBiaXQgbm8uIDMwfjMyKSBoYXMgc29tZSBzZW1hbnRpYyAoZm9yIGV4YW1wbGUs IG5lZWQNCj5leHRyYSBzZWN1cml0eSBwcm9jZXNzaW5nKSBmb3IgdGhlIGFzc2lnbmluZyBwcm92 aWRlci4gVGhlbiwgd2hlbiB0aGUgcHJvdmlkZXINCj5yZWNlaXZlZCBwYWNrZXRzIGZyb20gc3Vj aCBvcmdhbml6YXRpb25zICh0aGVyZSBhcmUgbXVsdGlwbGUgZW50ZXJwcmlzZSBoYXMNCj50aGUg c2FtZSBzZW1hbnRpYyBhbmQgdGhlIHNhbWUgYml0IG5vLiAzMH4zMiksIGl0IGNhbiB0cmVhdCBh Y2NvcmRpbmdseS4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+DQo+U2hlbmcNCj4NCj4+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogRHVuY2FuLCBSaWNoYXJkIChKZXJlbXkpIFttYWls dG86amVyZW15LmR1bmNhbkBzYWxpZW50ZmVkLmNvbV0NCj4+U2VudDogVGh1cnNkYXksIE1heSAz MCwgMjAxMyAxMDoyMCBBTQ0KPj5UbzogT3dlbiBEZUxvbmcNCj4+Q2M6IFNoZW5nIEppYW5nOyA8 djZvcHNAaWV0Zi5vcmc+Ow0KPj5kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9v bHMuaWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmcNCj4+U3ViamVjdDogUmU6IFt2Nm9wc10gQ291bGQg SVB2NiBhZGRyZXNzIGJlIG1vcmUgdGhhbg0KPj5sb2NhdG9yPy8vZHJhZnQtamlhbmctdjZvcHMt c2VtYW50aWMtcHJlZml4LTAzDQo+Pg0KPj5JIHRlbmQgdG8gYWdyZWUgd2l0aCBPd2VuIGhlcmUu ICBJbiBmYWN0LCBJIGFtIGN1cmlvdXMgaG93IGFuIGFsbG9jYXRpb24NCj4+ZnJvbSBhIHByb3Zp ZGVyIHRvIGEgb3JnYW5pemF0aW9uIHdvdWxkIGxvb2s/ICBJbnN0ZWFkIG9mIGZvbGxvd2luZw0K PnN0YW5kYXJkDQo+Pmlzc3VpbmcgcHJhY3RpY2VzIG9mIGEgLzQ4LCBhcmUgeW91IHN1Z2dlc3Rp bmcgdGhlIHByb3ZpZGVyIHdvdWxkIGlzc3VlDQo+Pm11bHRpcGxlIC81MnMgdGhhdCBmb2xsb3cg ZnVuY3Rpb25hbCBjYXRlZ29yaWVzIChWb0lQLCBtYW5hZ2VtZW50LCBldGMpPw0KPk9yDQo+Pm1h eWJlIEkgbWlzc2VkIHNvbWV0aGluZz8NCj4+DQo+Pg0KPj4wMTAxMDAxMTAxMTAwMTAxMDExMDEx MDEwMTExMDAwMDAxMTAwMTAxMDExMTAwMTAwMDEwMDAwMDAxMDAwMQ0KPjENCj4+MDAxMTAxMDAx DQo+Pg0KPj5KZXJlbXkgRHVuY2FuDQo+PlNlbmlvciBEaXJlY3RvciwgSVB2NiBOZXR3b3JrIEFy Y2hpdGVjdA0KPj5TYWxpZW50IEZlZGVyYWwgU29sdXRpb25zLCBJbmMuIChOb3cgaW5jbHVkaW5n IFNHSVMgJiBDb21tYW5kIEluZm9ybWF0aW9uDQo+PkluYy4pDQo+PjQwMDAgTGVnYXRvIFJvYWQs IFN1aXRlIDYwMA0KPj5GYWlyZmF4LCBWQSAyMjAzMw0KPj5Hb29nbGUgVm9pY2U6IDU0MC40NDAu MTE5Mw0KPj5qZXJlbXkuZHVuY2FuQHNhbGllbnRmZWQuY29tDQo+Pg0KPj5Pd2VuIERlTG9uZyA8 b3dlbkBkZWxvbmcuY29tPiB3cm90ZToNCj4+DQo+Pg0KPj5QZXJzb25hbGx5LCBJIHRoaW5rIHRo aXMgaXMgYW4gaW5oZXJlbnRseSBiYWQgaWRlYS4NCj4+DQo+PklQIGFkZHJlc3NlcyBuZWVkIGxl c3Mgb3ZlcmxvYWRpbmcgb2Ygc2VtYW50aWNzLCBub3QgbW9yZS4NCj4+DQo+PldlIGFscmVhZHkg dXNlIElQIGFkZHJlc3NlcyBmb3IgdHdvIGNvbmZsaWN0aW5nIHB1cnBvc2Vz4oCmIFRvcG9sb2d5 IGxvY2F0b3INCj4+YW5kIEVuZCBTeXN0ZW0gSWRlbnRpZmllci4NCj4+DQo+PlRoaXMgb3Zlcmxv YWRpbmcgaXMgYXQgdGhlIGhlYXJ0IG9mIG91ciBjdXJyZW50IHNjYWxpbmcgaXNzdWVzIHdpdGgg cmVzcGVjdCB0bw0KPj50aGUgcm91dGluZyB0YWJsZS4gV2hpbGUgdGhlc2UgaXNzdWVzIGFyZSBj dXJyZW50bHkgbGVzcyBjcml0aWNhbCB0aGFuIHRoZXkgaGF2ZQ0KPj5iZWVuIGluIHRoZSBwYXN0 IGFuZCB3aWxsIGxpa2VseSBnZXQgcXVpdGUgYSBiaXQgbGVzcyBjcml0aWNhbCBpbiBJUHY2LCB0 aGF0IGlzIG9ubHkNCj4+YmVjYXVzZSB3ZSBoYXZlIGdpdmVuIHVwIGEgZmFpciBhbW91bnQgb2Yg ZnVuY3Rpb25hbGl0eSB0byBwcmVzZXJ2ZQ0KPj5zY2FsYWJpbGl0eSBpbiB0aGlzIHJlZ2FyZC4N Cj4+DQo+PklmIHdlIGRpZCBub3QgaGF2ZSB0aGlzIG92ZXJsb2FkaW5nLCB0aGVuIGFuIGVudGl0 eSBjb3VsZCBvYnRhaW4gYSBzZXQgb2YNCj4+ZW5kLXN5c3RlbSBpZGVudGlmaWVycyBhbmQga2Vl cCB0aGVtIHRocm91Z2hvdXQgdGhlaXIgbGlmZXRpbWUsIHJlZ2FyZGxlc3MNCj5vZg0KPj50b3Bv bG9naWNhbCBjaGFuZ2VzLiBUb2RheSwgd2hlcmUgdGhlIGFkZHJlc3NlcyBhcmUgb3ZlcmxvYWRl ZCB3aXRoIGJvdGgNCj4+c2VtYW50aWNzLCB3ZSBlaXRoZXIgaGF2ZSB0byBmb3JjZSBtb3N0IGVu dGl0aWVzIHRvIGNoYW5nZSB0aGVpciBudW1iZXJzDQo+PndoZW4gdGhleSBjaGFuZ2UgdG9wb2xv Z3kgb3Igd2UgZmFjZSB1bnN1c3RhaW5hYmxlIGdyb3d0aCBpbiB0aGUgcm91dGluZw0KPj50YWJs ZXMuDQo+Pg0KPj5UaGUgaWRlYSBvZiBhZGRpbmcgbW9yZSBzZW1hbnRpY3MgdG8gYWRkcmVzc2lu ZyByYXRoZXIgdGhhbiBzZWVraW5nIHRvDQo+PnJlZHVjZSB0aGlzIG92ZXJsb2FkaW5nIHNlZW1z IGEgc3RlcCBpbiB0aGUgd3JvbmcgZGlyZWN0aW9uLCBJTUhPLg0KPj4NCj4+T3dlbg0KPj4NCj4+ T24gTWF5IDI5LCAyMDEzLCBhdCAxMjowNiBBTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVh d2VpLmNvbT4NCj4+d3JvdGU6DQo+Pg0KPj4+IElQIGFkZHJlc3NlcyBhcmUgZGVzaWduZWQgYXMg dG9wb2xvZ3kgbG9jYXRvciwgc28gdGhhdCBldmVyeSBwYWNrZXQgY2FuIGJlDQo+PnJvdXRlZCB0 byBpdHMgbmV0d29yayBkZXN0aW5hdGlvbi4NCj4+Pg0KPj4+IEhvd2V2ZXIsIGV2ZW4gaW4gSVB2 NCBlcmEsIHNvbWUgbmV0d29yayBvcGVyYXRvcnMgaGF2ZSBtYXBwZWQgdGhlaXIgSVANCj4+YWRk cmVzcyB3aXRoIGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhlc2Uga2luZCBvZiBtZWNoYW5p c20gZXhwbGljaXRseQ0KPj5leHByZXNzIHRoZSBzZW1hbnRpYyBwcm9wZXJ0aWVzIG9mIGV2ZXJ5 IHBhY2tldC4gQ29uc2VxdWVudGx5LCB0aGVzZQ0KPm5ldHdvcmsNCj4+b3BlcmF0b3JzIGNhbiBp bnNwZWN0IHRoZSBwcm9wZXJ0aWVzIG9mIHBhY2tldHMgZWFzaWx5IGJ5IG1hcHBpbmcgdGhlDQo+ PmFkZHJlc3NlcyBiYWNrIHRvIHNlbWFudGljLg0KPj4+DQo+Pj4gTmV0d29yayBvcGVyYXRvcnMs IHdobyBoYXZlIGxhcmdlIElQdjYgYWRkcmVzcyBzcGFjZSwgbWF5IGFsc28gY2hvb3NlDQo+dG8N Cj4+ZW1iZWRkZWQgc29tZSBzZW1hbnRpY3MgaW50byBJUHY2IGFkZHJlc3NlcyBieSBhc3NpZ25p bmcgYWRkaXRpb25hbA0KPj5zaWduaWZpY2FuY2UgdG8gc3BlY2lmaWMgYml0cyB3aXRoaW4gdGhl IHByZWZpeC4NCj4+ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4IGRvY3VtZW50cyBh IGZyYW1ld29yayBtZXRob2QgdGhhdA0KPj5uZXR3b3JrIG9wZXJhdGlvbnMgbWF5IHVzZSB0aGVp ciBhZGRyZXNzZXMgd2l0aCBlbWJlZGRlZCBzZW1hbnRpY3MuDQo+VGhlc2UNCj4+c2VtYW50aWNz IGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yaywgb3IgZ3Jv dXAgb2YNCj4+aW50ZXJjb25uZWN0ZWQgbmV0d29ya3Mgd2hpY2ggc2hhcmUgYSBjb21tb24gYWRk cmVzc2luZyBwb2xpY3kuIEJhc2VkIG9uDQo+PnRoZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMg aW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3NlcywgdGhlIG5ldHdvcmsNCj4+b3BlcmF0b3Jz IGNhbiBhY2NvcmRpbmdseSB0cmVhdCBuZXR3b3JrIHBhY2tldHMgZGlmZmVyZW50bHkgYW5kIGVm ZmljaWVudGx5Lg0KPj4+DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlh bmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4NCj4+PiBDb3VsZCB5b3UgcGxlYXNlIHJl dmlldyB0aGlzIGRyYWZ0IGFuZCBjb21tZW50cz8gSXQgd2lsbCBoZWxwIHRoZQ0KPmRvY3VtZW50 DQo+PmJlY29tZSBtb3JlIHVzZWZ1bCBpbmZvcm1hdGlvbiB0byBiZSBzaGFyZWQuDQo+Pj4NCj4+ PiBCZXN0IHJlZ2FyZHMsDQo+Pj4NCj4+PiBTaGVuZw0KPj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+Pj4gU2VudDogVHVlc2RheSwgTWF5IDI4LCAy MDEzIDEwOjI4IEFNDQo+Pj4+IFRvOiBRaW9uZyBTdW47IElhbiBGYXJyZXI7IFNoZW5nIEppYW5n OyBCb3lhbmcNCj4+Pj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4+ PiBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMudHh0DQo+Pj4+DQo+Pj4+DQo+ Pj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVm aXgtMDMudHh0DQo+Pj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2hlbmcg SmlhbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4+Pj4gSUVURiByZXBvc2l0b3J5Lg0KPj4+Pg0KPj4+ PiBGaWxlbmFtZTogICAgIGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeA0KPj4+PiBS ZXZpc2lvbjogICAgIDAzDQo+Pj4+IFRpdGxlOiAgICAgICAgICAgICAgICBBIEZyYW1ld29yayBm b3IgU2VtYW50aWMgSVB2NiBQcmVmaXgNCj4+Pj4gQ3JlYXRpb24gZGF0ZTogICAgICAgIDIwMTMt MDUtMjgNCj4+Pj4gR3JvdXA6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K Pj4+PiBOdW1iZXIgb2YgcGFnZXM6IDE5DQo+Pj4+IFVSTDoNCj4+Pj4NCj4+aHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4 LTAzLnR4DQo+dA0KPj4+PiBTdGF0dXM6DQo+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4DQo+Pj4+IEh0bWxpemVkOg0K Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRp Yy1wcmVmaXgtMDMNCj4+Pj4gRGlmZjoNCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4+DQo+Pj4+IEFi c3RyYWN0Og0KPj4+PiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgbWV0aG9k IHRoYXQgbmV0d29yayBvcGVyYXRpb25zDQo+Pj4+ICBtYXkgdXNlIHRoZWlyIGFkZHJlc3Nlcy4g IE5ldHdvcmsgb3BlcmF0b3JzLCB3aG8gaGF2ZSBsYXJnZSBJUHY2DQo+Pj4+ICBhZGRyZXNzIHNw YWNlLCBtYXkgY2hvb3NlIHRvIGVtYmVkZGVkIHNvbWUgc2VtYW50aWNzIGludG8gSVB2Ng0KPj4+ PiAgYWRkcmVzc2VzIGJ5IGFzc2lnbmluZyBhZGRpdGlvbmFsIHNpZ25pZmljYW5jZSB0byBzcGVj aWZpYyBiaXRzDQo+Pj4+ICB3aXRoaW4gdGhlIHByZWZpeC4gIEJ5IGVtYmVkZGVkIHNlbWFudGlj cyBpbnRvIElQdjYgcHJlZml4ZXMsIHRoZQ0KPj4+PiAgc2VtYW50aWNzIG9mIHBhY2tldHMgY2Fu IGJlIGluc3BlY3RlZCBlYXNpbHkuICBSb3V0ZXJzIGFuZCBvdGhlcg0KPj4+PiAgaW50ZXJtZWRp YXJ5IGRldmljZXMgY2FuIGVhc2lseSBhcHBseSByZWxldmFudCBwb2xpY2llcyBhcyByZXF1aXJl ZC4NCj4+Pj4gIFBhY2tldC1sZXZlbCBkaWZmZXJlbnRpYXRpb24gY2FuIGFsc28gZW5hYmxlIGZs b3ctbGV2ZWwgYW5kIHVzZXItDQo+Pj4+ICBsZXZlbCBkaWZmZXJlbnRpYXRpb24uICBDb25zZXF1 ZW50bHksIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyBjYW4NCj4+Pj4gIGFjY29yZGluZ2x5IHRyZWF0 IG5ldHdvcmsgcGFja2V0cyBkaWZmZXJlbnRseSBhbmQgZWZmaWNpZW50bHkuICBUaGUNCj4+Pj4g IG1hbmFnZW1lbnQgYW5kIG1haW50ZW5hbmNlIG9mIG5ldHdvcmtzIGNhbiBiZSBtdWNoIHNpbXBs ZXIuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4+IHY2b3BzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+PmlwdjZAaWV0Zi5vcmcNCj4+ QWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXB2Ng0KPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4NCg0K From jiangsheng@huawei.com Thu May 30 20:09:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405C521F96FE; Thu, 30 May 2013 20:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7YnNw84n1Wf; Thu, 30 May 2013 20:09:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 634AD21F896D; Thu, 30 May 2013 20:09:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ07152; Fri, 31 May 2013 03:09:12 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:08:38 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:09:11 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Fri, 31 May 2013 11:09:06 +0800 From: Sheng Jiang To: Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAAQAgIAAioBg//9+QwCAAIvnkIAACAoAgAE8FgA= Date: Fri, 31 May 2013 03:09:05 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99B0D@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B0Dnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:09:20 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B0Dnkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgZGVueSB0aGVyZSB3aWxsIGJlIHdhc3RlLiBNeSBwb2ludCBpcyBvbmx5IGl0IGlz IG5vdCBhcyBtdWNoIHdhc3RlIGFzIDEvMl5uLiBIb3dldmVyLCBnaXZpbmcgLzQ4IHRvIGV2ZXJ5 IHN1YnNjcmliZXIsIGZvciBtZSwgaXMgbXVjaCBiaWdnZXIgd2FzdGUgYW5kIGx1eHVyeS4gWW91 IGFyZSBhc3N1bWluZyBldmVyeSBzdWJzY3JpYmVyIGhhcyBhcyBtYW55IGFzIHRoYW4gMl4xNiBz dWJuZXRzPyBDdXJyZW50bHksIHRoZXJlIG1heSBub3QgYmUgbW9yZSB0aGFuIDE2IGRldmljZXMg aW4gYW4gYXZlcmFnZSBzdWJzY3JpYmVy4oCZcyBvd24gbmV0d29yay4gIE9uIG90aGVyIHNpZGUs IHdoeSBzdWJzY3JpYmVyIG1heSB3YW50IG1vcmUgdGhhbiBvbmUgc3VibmV0cz8gT25lIHJlYXNv bmFibGUgcmVhc29uIGlzIHRvIG9yZ2FuaXplIGRpZmZlcmVudCB0cmFmZmljcyBvciBhcHBsaWNh dGlvbnMgaW4gZGlmZmVyZW50IHN1Ym5ldHMuIFNvLCB0aGVzZSBraW5kIG9mIHRyYWZmaWMgZGlm ZmVyZW50aWF0aW9uIGlzIGFsc28gbWVhbmluZ2Z1bCBzZW1hbnRpYyBmb3IgcHJvdmlkZXJzLiBJ ZiB0aGUgcHJvdmlkZXIgaGFzIGRpZmZlcmVudGlhdGUgdGhlc2UgdHJhZmZpY3MgaW4gaGlnaGVy IGJpdHMgb2YgcHJlZml4ZXMgdXNpbmcgc2VtYW50aWMgcHJlZml4LCB0aGUgc21hbGxlciBwcmVm aXggc3Vic2NyaWJlciBhcmUgbmVlZGVkLiBNYXliZSAvNTgsIG9yIC82MCBpcyBlbm91Z2ggZm9y IHN1YnNjcmliZXJzLCBpZiB0aGUgcHJvdmlkZXJzIGhhcyB3ZWxsIHNlcGFyYXRlIHRoZSB0cmFm ZmljIGZvciB0aGVtIGJ5IGFzc2lnbiBtdWx0aXBsZSBwcmVmaXggcmVnYXJkaW5nIHRvIGRpZmZl cmVudCBzZW1hbnRpYz8NCg0KQ2hlZXJzLA0KDQpTaGVuZw0KDQpGcm9tOiBPd2VuIERlTG9uZyBb bWFpbHRvOm93ZW5AZGVsb25nLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5IDMxLCAyMDEzIDEyOjA4 IEFNDQpUbzogU2hlbmcgSmlhbmcNCkNjOiBMb3JlbnpvIENvbGl0dGk7IFRpbSBDaG93bjsgPHY2 b3BzQGlldGYub3JnPjsgZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4QHRvb2xzLmll dGYub3JnOyBpcHY2QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFk ZHJlc3MgYmUgbW9yZSB0aGFuIGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1w cmVmaXgtMDMNCg0KPj5Ib3dldmVyLCBpdCBpcyBub3QgbmVjZXNzYXJ5IGFzIHdvcnNlIGFzIDJe TiB0aW1lcy4gRm9yIGV4YW1wbGUsIGl0IHRoZXJlIGFyZSAyIGJpdHMgdG8gc2VwYXJhdGUgZGlm ZmVyZW50IHVzZSB0eXBlcyAoc2F5IDQgZGlmZmVyZW50IHR5cGVzKSwgaXQgYWN0dWFsbHkgb25s eSBzZXBhcmF0ZSB1c2UgYWRkcmVzcyBzcGFjZXMgaW50byBmb3VyIGRpZmZlcmVudCBzcGFjZXMu IEl0IGRvZXMgbm90IGxpbWl0IHRoZSBhZGRyZXNzIHNwYWNlIHRvIGJlIDEvNCBvZiBvcmlnaW5h bCBzcGFjZS4NCkhvdyBpcyB0aGF0IGRpZmZlcmVudCBmcm9tIHNheWluZyAiYnkgYWRkaW5nIHR3 byBiaXRzIG9mIHNlbWFudGljcyBpbiB0aGUgcHJlZml4LCB0aGUgbmV0d29yayB3aWxsIHVzZSA0 IHRpbWVzIHRoZSBhZGRyZXNzIHNwYWNlIHRoYW4gaXQgd291bGQgb3RoZXJ3aXNlIj8NCk5vLiBU aGlzIGlzIHZlcnkgZGlmZmVyZW50LiBQdXR0aW5nIHRoZSBleGFtcGxlIGludG8gbnVtYmVycyBt YXkgYmUgbW9yZSBpbnR1aXRpb25pc3RpYy4gU2F5IGFuIElTUCBoYXMgNCBtaWxsaW9uIHN1YnNj cmliZXJzLCBpdCBuZWVkcyA0IG1pbGxpb24gLzU2IChhc3N1bWluZyBldmVyeSB1c2VyIGdldCBh IC81NikuIEJ5IHNlcGFyYXRpbmcgdGhlbSBpbnRvIDQgZGlmZmVyZW50IHR5cGVzLCB0aGUgYWRk cmVzcyBjb25zdW1wdGlvbiBpcyBzdGlsbCA0IG1pbGxpb24gLzU2IGlmIHRoZSBzZXBhcmF0aW9u IGlzIGV4YWN0bHkgZXZlbi4gSG93ZXZlciwgdGhlIG1vcmUNCk5vdCBhIGdyZWF0IGFzc3VtcHRp b24uLi4gVGhleSBzaG91bGQgbmVlZCA0IG1pbGxpb24gb3IgbW9yZSAvNDhzIHNpbmNlIGV2ZXJ5 IHN1YnNjcmliZXIgaXMgYXQgbGVhc3Qgb25lIGVuZCBzaXRlIGFuZCBldmVyeSBzdWJzY3JpYmVy IGVuZCBzaXRlIHNob3VsZCByZWNlaXZlIGEgLzQ4Lg0KDQpBc3N1bWluZyB0aGF0IHlvdSB3aWxs IGdldCA0IG1pbGxpb24gc3Vic2NyaWJlcnMgdGhhdCBjb252ZW5pZW50bHkgZGl2aWRlIGludG8g YnVja2V0cyBvZiAxIG1pbGxpb24gcGVyIGJ1Y2tldCBpcyBhYnN1cmQuIE1vcmUgbGlrZWx5LCB5 b3UnbGwgZ2V0IDUwMCwwMDAsIDc1MCwwMDAsIDIsMDAwLDAwMCwgYW5kIDc1MCwwMDAsIG9yIG90 aGVyIHNpbWlsYXJseSBza2V3ZWQgZGlzdHJpYnV0aW9uLiBJdCBtaWdodCBldmVuIGJlIDMsNTAw LDAwMCwgMTI1LDAwMCwgMTI1LDAwMCwgMjUwLDAwMC4NCmFkZHJlc3MgbWF5IG5lZWQgd2hlbiB0 aGUgc2VwYXJhdGlvbiBpcyBub3QgZXZlbi4gRm9yIGV4YW1wbGUsIGlmIHRoZSBiaWdnZXN0IHVz ZXIgdHlwZSBoYXMgMiBtaWxsaW9uIHVzZXJzLCB0aGVuIHRoZSB0b3RhbCBhZGRyZXNzIHNwYWNl IG1heSBiZWNvbWUgOCBtaWxsaW9uIC81NiDigJMgdHdvIHRpbWVzIG9mIG9yaWdpbmFsLiBJdCBj b21lcyBmcm9tIGFsaWduLiBUaGUgaW5jcmVhc2VkIHNlbWFudGljcyBiaXQgYXJlIGFsc28gaW5j cmVhc2luZyB0aGUgYWRkcmVzcyBzcGFjZSBhbHRob3VnaCBub3QgaW5jcmVhc2luZyBsaW5lYXJs eS4gU28sIGF0IHRoZSBlbmQsIGl0IGlzIG5vdCB0b3RhbGx5IHdhc3RlLg0KSWYgeW91IGdldCBl eHRyYW9yZGluYXJpbHkgbHVja3ksIGl0J3Mgbm8gd2FzdGUuIE90aGVyd2lzZSwgaXQncyBhdCBs ZWFzdCA1MCUgd2FzdGUgYW5kIGNhbiBlYXNpbHkgcmVhY2ggNzUlIHdhc3RlICg0eCBzcGFjZSB1 dGlsaXphdGlvbiwgYXMgTG9yZW56byBzYWlkKS4NCg0KRm9yIGV4YW1wbGUsIGlmIHlvdSBoYXZl IDQsMDAwLDAwMCBlbmQgc2l0ZXMgYW5kIHlvdSBnZXQgYXMgbGl0dGxlIGFzIDIsMDk3LDE1MyBz dWJzY3JpYmVycyBpbiBvbmUgb2YgdGhlIGJ1Y2tldHMsIHlvdSBoYXZlIHRvIGdvIHRvIDR4IHlv dXIgYWRkcmVzcyBzcGFjZSB0byBwcmVzZXJ2ZSB0aGUgc2VtYW50aWNzLg0KDQpPd2VuDQoNCkJl c3QgcmVnYXJkcywNClNoZW5nDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3Jlbnpv QGdvb2dsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDMwLCAyMDEzIDM6MTkgUE0NClRvOiBT aGVuZyBKaWFuZw0KQ2M6IFRpbSBDaG93bjsgT3dlbiBEZUxvbmc7IDx2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+PjsgZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4 QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhA dG9vbHMuaWV0Zi5vcmc+OyBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFt2Nm9wc10gQ291bGQgSVB2NiBhZGRyZXNzIGJlIG1vcmUgdGhhbiBsb2NhdG9y Py8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQoNCk9uIFRodSwgTWF5IDMw LCAyMDEzIGF0IDQ6MTMgUE0sIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb208bWFp bHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KWWVzLCB0aGVyZSBpcyBubyBpbnRl bnNpb24gdG8gY2hhbmdlIEFSSU7igJlzIHBvbGljeSBhdCBhbGwuIEFSSU4gc2hvdWxkIHJlbWFp biB0aGUgY3VycmVudCBwb2xpY3kgb2YgYXNzaWduIElQdjYgYWRkcmVzcyBibG9jay4gQnV0IHRo ZSBuZXR3b3JrIHByb3ZpZGVycywgd2hvIGhhcyBhbHJlYWR5IGdldCBhZGRyZXNzIGJsb2NrLCBj YW4gY2hvb3NlIHRvIHVzZSB0aGUgYWRkcmVzc2VzIHdpdGggY2VydGFpbiBzZW1hbnRpY3MuIEFu ZCBubyBvbmUsIGluY2x1ZGluZyBBUklOIGNhbiBzdG9wIHRoaXMuDQoNCkFncmVlZCwgYnV0IGV2 ZW4gZm9yIG5ldHdvcmsgcHJvdmlkZXJzIHRoYXQgYWxyZWFkeSBoYXZlIGJsb2NrcywgdGhpcyB3 aWxsIGJlIGFuIGlzc3VlIGlmIHRoZXkgZXZlciBuZWVkIGFub3RoZXIgYmxvY2suIEJ1dCBJIGRv IHRoaW5rIHlvdSBzaG91bGQgd3JpdGUgdGhpcyBpbiB0aGUgZHJhZnQuDQoNCkhvd2V2ZXIsIGl0 IGlzIG5vdCBuZWNlc3NhcnkgYXMgd29yc2UgYXMgMl5OIHRpbWVzLiBGb3IgZXhhbXBsZSwgaXQg dGhlcmUgYXJlIDIgYml0cyB0byBzZXBhcmF0ZSBkaWZmZXJlbnQgdXNlIHR5cGVzIChzYXkgNCBk aWZmZXJlbnQgdHlwZXMpLCBpdCBhY3R1YWxseSBvbmx5IHNlcGFyYXRlIHVzZSBhZGRyZXNzIHNw YWNlcyBpbnRvIGZvdXIgZGlmZmVyZW50IHNwYWNlcy4gSXQgZG9lcyBub3QgbGltaXQgdGhlIGFk ZHJlc3Mgc3BhY2UgdG8gYmUgMS80IG9mIG9yaWdpbmFsIHNwYWNlLg0KDQpIb3cgaXMgdGhhdCBk aWZmZXJlbnQgZnJvbSBzYXlpbmcgImJ5IGFkZGluZyB0d28gYml0cyBvZiBzZW1hbnRpY3MgaW4g dGhlIHByZWZpeCwgdGhlIG5ldHdvcmsgd2lsbCB1c2UgNCB0aW1lcyB0aGUgYWRkcmVzcyBzcGFj ZSB0aGFuIGl0IHdvdWxkIG90aGVyd2lzZSI/DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B0Dnkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYW0gbm90IGRlbnkgdGhlcmUgd2lsbCBiZSB3YXN0ZS4gTXkgcG9pbnQg aXMgb25seSBpdCBpcyBub3QgYXMgbXVjaCB3YXN0ZSBhcyAxLzJebi4gSG93ZXZlciwgZ2l2aW5n IC80OCB0byBldmVyeSBzdWJzY3JpYmVyLCBmb3IgbWUsIGlzIG11Y2gNCiBiaWdnZXIgd2FzdGUg YW5kIGx1eHVyeS4gWW91IGFyZSBhc3N1bWluZyBldmVyeSBzdWJzY3JpYmVyIGhhcyBhcyBtYW55 IGFzIHRoYW4gMl4xNiBzdWJuZXRzPyBDdXJyZW50bHksIHRoZXJlIG1heSBub3QgYmUgbW9yZSB0 aGFuIDE2IGRldmljZXMgaW4gYW4gYXZlcmFnZSBzdWJzY3JpYmVy4oCZcyBvd24gbmV0d29yay4g Jm5ic3A7T24gb3RoZXIgc2lkZSwgd2h5IHN1YnNjcmliZXIgbWF5IHdhbnQgbW9yZSB0aGFuIG9u ZSBzdWJuZXRzPyBPbmUgcmVhc29uYWJsZQ0KIHJlYXNvbiBpcyB0byBvcmdhbml6ZSBkaWZmZXJl bnQgdHJhZmZpY3Mgb3IgYXBwbGljYXRpb25zIGluIGRpZmZlcmVudCBzdWJuZXRzLiBTbywgdGhl c2Uga2luZCBvZiB0cmFmZmljIGRpZmZlcmVudGlhdGlvbiBpcyBhbHNvIG1lYW5pbmdmdWwgc2Vt YW50aWMgZm9yIHByb3ZpZGVycy4gSWYgdGhlIHByb3ZpZGVyIGhhcyBkaWZmZXJlbnRpYXRlIHRo ZXNlIHRyYWZmaWNzIGluIGhpZ2hlciBiaXRzIG9mIHByZWZpeGVzIHVzaW5nIHNlbWFudGljIHBy ZWZpeCwNCiB0aGUgc21hbGxlciBwcmVmaXggc3Vic2NyaWJlciBhcmUgbmVlZGVkLiBNYXliZSAv NTgsIG9yIC82MCBpcyBlbm91Z2ggZm9yIHN1YnNjcmliZXJzLCBpZiB0aGUgcHJvdmlkZXJzIGhh cyB3ZWxsIHNlcGFyYXRlIHRoZSB0cmFmZmljIGZvciB0aGVtIGJ5IGFzc2lnbiBtdWx0aXBsZSBw cmVmaXggcmVnYXJkaW5nIHRvIGRpZmZlcmVudCBzZW1hbnRpYz8NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE93ZW4gRGVMb25nIFttYWls dG86b3dlbkBkZWxvbmcuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDMxLCAy MDEzIDEyOjA4IEFNPGJyPg0KPGI+VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4g TG9yZW56byBDb2xpdHRpOyBUaW0gQ2hvd247ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRyYWZ0 LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUg bW9yZSB0aGFuIGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDtIb3dldmVyLCBpdCBpcyBu b3QgbmVjZXNzYXJ5IGFzIHdvcnNlIGFzIDJeTiB0aW1lcy4gRm9yIGV4YW1wbGUsIGl0IHRoZXJl IGFyZSAyIGJpdHMNCiB0byBzZXBhcmF0ZSBkaWZmZXJlbnQgdXNlIHR5cGVzIChzYXkgNCBkaWZm ZXJlbnQgdHlwZXMpLCBpdCBhY3R1YWxseSBvbmx5IHNlcGFyYXRlIHVzZSBhZGRyZXNzIHNwYWNl cyBpbnRvIGZvdXIgZGlmZmVyZW50IHNwYWNlcy4gSXQgZG9lcyBub3QgbGltaXQgdGhlIGFkZHJl c3Mgc3BhY2UgdG8gYmUgMS80IG9mIG9yaWdpbmFsIHNwYWNlLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+SG93IGlzIHRoYXQgZGlmZmVyZW50IGZyb20gc2F5aW5nICZxdW90O2J5 IGFkZGluZyB0d28gYml0cyBvZiBzZW1hbnRpY3MgaW4gdGhlIHByZWZpeCwgdGhlIG5ldHdvcmsg d2lsbCB1c2UgNCB0aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGFuIGl0IHdvdWxkIG90aGVyd2lz ZSZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8u IFRoaXMgaXMgdmVyeSBkaWZmZXJlbnQuIFB1dHRpbmcgdGhlIGV4YW1wbGUgaW50byBudW1iZXJz IG1heSBiZSBtb3JlIGludHVpdGlvbmlzdGljLg0KIFNheSBhbiBJU1AgaGFzIDQgbWlsbGlvbiBz dWJzY3JpYmVycywgaXQgbmVlZHMgNCBtaWxsaW9uIC81NiAoYXNzdW1pbmcgZXZlcnkgdXNlciBn ZXQgYSAvNTYpLiBCeSBzZXBhcmF0aW5nIHRoZW0gaW50byA0IGRpZmZlcmVudCB0eXBlcywgdGhl IGFkZHJlc3MgY29uc3VtcHRpb24gaXMgc3RpbGwgNCBtaWxsaW9uIC81NiBpZiB0aGUgc2VwYXJh dGlvbiBpcyBleGFjdGx5IGV2ZW4uIEhvd2V2ZXIsIHRoZSBtb3JlPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3Qg YSBncmVhdCBhc3N1bXB0aW9uLi4uIFRoZXkgc2hvdWxkIG5lZWQgNCBtaWxsaW9uIG9yIG1vcmUg LzQ4cyBzaW5jZSBldmVyeSBzdWJzY3JpYmVyIGlzIGF0IGxlYXN0IG9uZSBlbmQgc2l0ZSBhbmQg ZXZlcnkgc3Vic2NyaWJlciBlbmQgc2l0ZSBzaG91bGQgcmVjZWl2ZSBhIC80OC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzc3VtaW5nIHRoYXQgeW91 IHdpbGwgZ2V0IDQgbWlsbGlvbiBzdWJzY3JpYmVycyB0aGF0IGNvbnZlbmllbnRseSBkaXZpZGUg aW50byBidWNrZXRzIG9mIDEgbWlsbGlvbiBwZXIgYnVja2V0IGlzIGFic3VyZC4gTW9yZSBsaWtl bHksIHlvdSdsbCBnZXQgNTAwLDAwMCwgNzUwLDAwMCwgMiwwMDAsMDAwLCBhbmQgNzUwLDAwMCwg b3Igb3RoZXIgc2ltaWxhcmx5IHNrZXdlZCBkaXN0cmlidXRpb24uDQogSXQgbWlnaHQgZXZlbiBi ZSAzLDUwMCwwMDAsIDEyNSwwMDAsIDEyNSwwMDAsIDI1MCwwMDAuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFkZHJl c3MgbWF5IG5lZWQgd2hlbiB0aGUgc2VwYXJhdGlvbiBpcyBub3QgZXZlbi4gRm9yIGV4YW1wbGUs IGlmIHRoZSBiaWdnZXN0IHVzZXIgdHlwZQ0KIGhhcyAyIG1pbGxpb24gdXNlcnMsIHRoZW4gdGhl IHRvdGFsIGFkZHJlc3Mgc3BhY2UgbWF5IGJlY29tZSA4IG1pbGxpb24gLzU2IOKAkyB0d28gdGlt ZXMgb2Ygb3JpZ2luYWwuIEl0IGNvbWVzIGZyb20gYWxpZ24uIFRoZSBpbmNyZWFzZWQgc2VtYW50 aWNzIGJpdCBhcmUgYWxzbyBpbmNyZWFzaW5nIHRoZSBhZGRyZXNzIHNwYWNlIGFsdGhvdWdoIG5v dCBpbmNyZWFzaW5nIGxpbmVhcmx5LiBTbywgYXQgdGhlIGVuZCwgaXQgaXMgbm90IHRvdGFsbHkg d2FzdGUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgZ2V0IGV4dHJhb3JkaW5hcmlseSBsdWNreSwgaXQn cyBubyB3YXN0ZS4gT3RoZXJ3aXNlLCBpdCdzIGF0IGxlYXN0IDUwJSB3YXN0ZSBhbmQgY2FuIGVh c2lseSByZWFjaCA3NSUgd2FzdGUgKDR4IHNwYWNlIHV0aWxpemF0aW9uLCBhcyBMb3JlbnpvIHNh aWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9y IGV4YW1wbGUsIGlmIHlvdSBoYXZlIDQsMDAwLDAwMCBlbmQgc2l0ZXMgYW5kIHlvdSBnZXQgYXMg bGl0dGxlIGFzIDIsMDk3LDE1MyBzdWJzY3JpYmVycyBpbiBvbmUgb2YgdGhlIGJ1Y2tldHMsIHlv dSBoYXZlIHRvIGdvIHRvIDR4IHlvdXIgYWRkcmVzcyBzcGFjZSB0byBwcmVzZXJ2ZSB0aGUgc2Vt YW50aWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ T3dlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRz LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56bw0KIENvbGl0dGkgWzxhIGhyZWY9Im1h aWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPm1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb208L2E+XSA8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAzMCwgMjAxMyAzOjE5IFBNPGJyPg0KPGI+ VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4gVGltIENob3duOyBPd2VuIERlTG9u ZzsgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhA dG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5p ZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gQ291bGQgSVB2NiBhZGRyZXNz IGJlIG1vcmUgdGhhbiBsb2NhdG9yPy8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4 LTAzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgTWF5IDMwLCAyMDEzIGF0IDQ6MTMgUE0sIFNoZW5n IEppYW5nICZsdDs8YSBocmVmPSJtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9 Il9ibGFuayI+amlhbmdzaGVuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlll cywgdGhlcmUgaXMgbm8gaW50ZW5zaW9uIHRvIGNoYW5nZSBBUklO4oCZcyBwb2xpY3kgYXQgYWxs LiBBUklOIHNob3VsZCByZW1haW4gdGhlIGN1cnJlbnQNCiBwb2xpY3kgb2YgYXNzaWduIElQdjYg YWRkcmVzcyBibG9jay4gQnV0IHRoZSBuZXR3b3JrIHByb3ZpZGVycywgd2hvIGhhcyBhbHJlYWR5 IGdldCBhZGRyZXNzIGJsb2NrLCBjYW4gY2hvb3NlIHRvIHVzZSB0aGUgYWRkcmVzc2VzIHdpdGgg Y2VydGFpbiBzZW1hbnRpY3MuIEFuZCBubyBvbmUsIGluY2x1ZGluZyBBUklOIGNhbiBzdG9wIHRo aXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFncmVlZCwg YnV0IGV2ZW4gZm9yIG5ldHdvcmsgcHJvdmlkZXJzIHRoYXQgYWxyZWFkeSBoYXZlIGJsb2Nrcywg dGhpcyB3aWxsIGJlIGFuIGlzc3VlIGlmIHRoZXkgZXZlciBuZWVkIGFub3RoZXIgYmxvY2suIEJ1 dCBJIGRvIHRoaW5rIHlvdSBzaG91bGQgd3JpdGUgdGhpcyBpbg0KIHRoZSBkcmFmdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgaXQgaXMgbm90IG5lY2Vzc2FyeSBh cyB3b3JzZSBhcyAyXk4gdGltZXMuIEZvciBleGFtcGxlLCBpdCB0aGVyZSBhcmUgMiBiaXRzDQog dG8gc2VwYXJhdGUgZGlmZmVyZW50IHVzZSB0eXBlcyAoc2F5IDQgZGlmZmVyZW50IHR5cGVzKSwg aXQgYWN0dWFsbHkgb25seSBzZXBhcmF0ZSB1c2UgYWRkcmVzcyBzcGFjZXMgaW50byBmb3VyIGRp ZmZlcmVudCBzcGFjZXMuIEl0IGRvZXMgbm90IGxpbWl0IHRoZSBhZGRyZXNzIHNwYWNlIHRvIGJl IDEvNCBvZiBvcmlnaW5hbCBzcGFjZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+SG93IGlzIHRoYXQgZGlmZmVyZW50IGZyb20gc2F5aW5nICZxdW90O2J5IGFk ZGluZyB0d28gYml0cyBvZiBzZW1hbnRpY3MgaW4gdGhlIHByZWZpeCwgdGhlIG5ldHdvcmsgd2ls bCB1c2UgNCB0aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGFuIGl0IHdvdWxkIG90aGVyd2lzZSZx dW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B0Dnkgeml512mbxchi_-- From jiangsheng@huawei.com Thu May 30 20:25:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F3321F8FA3; Thu, 30 May 2013 20:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUF7s7OxNIlp; Thu, 30 May 2013 20:24:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E07321F918F; Thu, 30 May 2013 20:24:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ08069; Fri, 31 May 2013 03:24:52 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:24:11 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 11:24:47 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 31 May 2013 11:24:35 +0800 From: Sheng Jiang To: Ted Lemon , Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXWv5NCdRGHUzf0iyRc5RG5uUgJkenj6Q Date: Fri, 31 May 2013 03:24:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99B42@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B42nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:25:00 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B42nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tcGFyaW5nIGdpdmluZyAxNiBiaXRzIGZvciBzdWJzY3JpYmVycywgd2hpY2ggcmFyZWx5IHVz ZSBpdCBvciB3ZSBzdGlsbCBoYXZlIG5vIGNvbmNyZXRlIGlkZWEgaG93IHRoaXMgd2lsbCBiZSB1 c2VkLCB0aGUgc2VtYW50aWMgYml0cyBvbiB0aGUgcHJvdmlkZXIgc2lkZSBsb29rcyBtb3JlIGhl bHBmdWwuDQoNCk9yIHByb3ZpZGVyIG1heSBkZXNpZ25hdGUgdGhlIGJpdCBpbiB0aGUgbG93ZXIg MTYgYml0cyBjYW4gaGF2ZSBzb21lIHNlbWFudGljcy4gRm9yIGV4YW1wbGUsIGEgcHJvdmlkZXIg bWF5IGdpdmUgZXZlcnkgc3Vic2NyaWJlciAvNDggYW5kIGFwcG9pbnQgdGhhdCBhbGwgc3Vic2Ny aWJlcnMgc2hvdWxkIHVzZSB0aGVpciAvNDgrMDAwMCAoNDh+NTEgYml0KSAtPiBhIC81MiBwcmVm aXggZm9yIGEgY2VydGFpbiBhcHBsaWNhdGlvbiwgbGlrZSBWb0lQLiBUaGVuIHRoZSBwcm92aWRl ciBjYW4gaW5zcGVjdCBhbGwgVm9JUCB0cmFmZmljIGZyb20gZGlmZmVyZW50IHN1YnNjcmliZXJz IGJ5IG9ubHkgc2V0IGNvbmRpdGlvbiA0OH41MSBiaXQgZXF1YWwgdG8gMDAwMC4gVGhpcyB2YXJp YXRpb24gb2Ygc2VtYW50aWMgcHJlZml4IGlzIGFsc28gaGVscGZ1bC4NCg0KQ2hlZXJzLA0KDQpT aGVuZw0KDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzpUZWQuTGVtb25Abm9taW51bS5jb21dDQpT ZW50OiBGcmlkYXksIE1heSAzMSwgMjAxMyAzOjI5IEFNDQpUbzogT3dlbiBEZUxvbmcNCkNjOiBT aGVuZyBKaWFuZzsgZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4QHRvb2xzLmlldGYu b3JnOyBpcHY2QGlldGYub3JnOyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuIGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12 Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDMNCg0KT24gTWF5IDMwLCAyMDEzLCBhdCAxMjowOCBQTSwg T3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbTxtYWlsdG86b3dlbkBkZWxvbmcuY29tPj4gd3Jv dGU6DQpOb3QgYSBncmVhdCBhc3N1bXB0aW9uLi4uIFRoZXkgc2hvdWxkIG5lZWQgNCBtaWxsaW9u IG9yIG1vcmUgLzQ4cyBzaW5jZSBldmVyeSBzdWJzY3JpYmVyIGlzIGF0IGxlYXN0IG9uZSBlbmQg c2l0ZSBhbmQgZXZlcnkgc3Vic2NyaWJlciBlbmQgc2l0ZSBzaG91bGQgcmVjZWl2ZSBhIC80OC4N Cg0KSSBhbSBub3QgaW4gbG92ZSB3aXRoIHVzaW5nIGJpdHMgZnJvbSBwcmVmaXhlcyBhcyBzZW1h bnRpYyB0YWdzLiAgIEhvd2V2ZXIsIGhhdmluZyBzYWlkIHRoYXQsIEkgdGhpbmsgaXQncyBhIGJp dCBpcm9uaWMgdGhhdCB5b3UncmUgdGFsa2luZyBhYm91dCB3YXN0aW5nIHNwYWNlIHdpdGggc2Vt YW50aWMgYml0cywgb24gdGhlIG9uZSBoYW5kLCBhbmQgdGFsa2luZyBhYm91dCB0aGUgbmVlZCBm b3IgYSAvNDggaW4gZXZlcnkgaG9tZSBvbiB0aGUgb3RoZXIuICAgSXQgd291bGQgYmUgcGVyZmVj dGx5IHJlYXNvbmFibGUgZm9yIHRoZSBJU1AgdG8gc3BlY2lmeSB0aGF0IHNvbWUgb2YgdGhlIGJp dHMgaW4gdGhlIC80OCBoYXZlIHNlbWFudGljIG1lYW5pbmcsIGZvciBleGFtcGxlLCBhbmQgZ2l2 ZW4gdGhhdCB3ZSB0aGluayBpdCdzIG9rYXkgdG8gZ2l2ZSB0aGUgaG9tZSBuZXR3b3JrIGEgLzQ4 LCB3ZSBhcmUgaGFyZGx5IGluIGEgcG9zaXRpb24gdG8gcXVpYmJsZSBhYm91dCBob3cgdGhlIGJp dHMgaW4gdGhhdCAvNDggYXJlIHVzZWQuDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B42nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Ok9wdGltYTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkw LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbXBhcmluZyBnaXZpbmcgMTYgYml0cyBmb3Igc3Vic2Ny aWJlcnMsIHdoaWNoIHJhcmVseSB1c2UgaXQgb3Igd2Ugc3RpbGwgaGF2ZSBubyBjb25jcmV0ZSBp ZGVhIGhvdyB0aGlzIHdpbGwgYmUgdXNlZCwgdGhlIHNlbWFudGljIGJpdHMgb24gdGhlDQogcHJv dmlkZXIgc2lkZSBsb29rcyBtb3JlIGhlbHBmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk9yIHByb3ZpZGVyIG1heSBkZXNpZ25hdGUgdGhlIGJpdCBpbiB0aGUgbG93ZXIg MTYgYml0cyBjYW4gaGF2ZSBzb21lIHNlbWFudGljcy4gRm9yIGV4YW1wbGUsIGEgcHJvdmlkZXIg bWF5IGdpdmUgZXZlcnkgc3Vic2NyaWJlciAvNDggYW5kIGFwcG9pbnQNCiB0aGF0IGFsbCBzdWJz Y3JpYmVycyBzaG91bGQgdXNlIHRoZWlyIC80OCYjNDM7MDAwMCAoNDh+NTEgYml0KSAtJmd0OyBh IC81MiBwcmVmaXggZm9yIGEgY2VydGFpbiBhcHBsaWNhdGlvbiwgbGlrZSBWb0lQLiBUaGVuIHRo ZSBwcm92aWRlciBjYW4gaW5zcGVjdCBhbGwgVm9JUCB0cmFmZmljIGZyb20gZGlmZmVyZW50IHN1 YnNjcmliZXJzIGJ5IG9ubHkgc2V0IGNvbmRpdGlvbiA0OH41MSBiaXQgZXF1YWwgdG8gMDAwMC4g VGhpcyB2YXJpYXRpb24gb2Ygc2VtYW50aWMNCiBwcmVmaXggaXMgYWxzbyBoZWxwZnVsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRlZCBM ZW1vbiBbbWFpbHRvOlRlZC5MZW1vbkBub21pbnVtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIE1heSAzMSwgMjAxMyAzOjI5IEFNPGJyPg0KPGI+VG86PC9iPiBPd2VuIERlTG9uZzxi cj4NCjxiPkNjOjwvYj4gU2hlbmcgSmlhbmc7IGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXBy ZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzsgJmx0O3Y2b3BzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUg bW9yZSB0aGFuIGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1heSAz MCwgMjAxMywgYXQgMTI6MDggUE0sIE93ZW4gRGVMb25nICZsdDs8YSBocmVmPSJtYWlsdG86b3dl bkBkZWxvbmcuY29tIj5vd2VuQGRlbG9uZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtPcHRp bWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk5vdCBhIGdyZWF0IGFzc3VtcHRpb24uLi4gVGhl eSBzaG91bGQgbmVlZCA0IG1pbGxpb24gb3IgbW9yZSAvNDhzIHNpbmNlIGV2ZXJ5IHN1YnNjcmli ZXIgaXMgYXQgbGVhc3Qgb25lIGVuZCBzaXRlIGFuZCBldmVyeSBzdWJzY3JpYmVyIGVuZCBzaXRl IHNob3VsZCByZWNlaXZlIGEgLzQ4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIG5vdCBpbiBsb3ZlIHdpdGggdXNpbmcgYml0cyBm cm9tIHByZWZpeGVzIGFzIHNlbWFudGljIHRhZ3MuICZuYnNwOyBIb3dldmVyLCBoYXZpbmcgc2Fp ZCB0aGF0LCBJIHRoaW5rIGl0J3MgYSBiaXQgaXJvbmljIHRoYXQgeW91J3JlIHRhbGtpbmcgYWJv dXQgd2FzdGluZyBzcGFjZSB3aXRoIHNlbWFudGljIGJpdHMsIG9uIHRoZSBvbmUgaGFuZCwgYW5k IHRhbGtpbmcgYWJvdXQgdGhlDQogbmVlZCBmb3IgYSAvNDggaW4gZXZlcnkgaG9tZSBvbiB0aGUg b3RoZXIuICZuYnNwOyBJdCB3b3VsZCBiZSBwZXJmZWN0bHkgcmVhc29uYWJsZSBmb3IgdGhlIElT UCB0byBzcGVjaWZ5IHRoYXQgc29tZSBvZiB0aGUgYml0cyBpbiB0aGUgLzQ4IGhhdmUgc2VtYW50 aWMgbWVhbmluZywgZm9yIGV4YW1wbGUsIGFuZCBnaXZlbiB0aGF0IHdlIHRoaW5rIGl0J3Mgb2th eSB0byBnaXZlIHRoZSBob21lIG5ldHdvcmsgYSAvNDgsIHdlIGFyZSBoYXJkbHkgaW4gYSBwb3Np dGlvbg0KIHRvIHF1aWJibGUgYWJvdXQgaG93IHRoZSBiaXRzIGluIHRoYXQgLzQ4IGFyZSB1c2Vk Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99B42nkgeml512mbxchi_-- From jiangsheng@huawei.com Thu May 30 20:28:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64821F922A; Thu, 30 May 2013 20:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0B7kEGic5Nx; Thu, 30 May 2013 20:28:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 561F721F918F; Thu, 30 May 2013 20:28:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY70412; Fri, 31 May 2013 03:28:08 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:27:34 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:28:07 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 31 May 2013 11:28:03 +0800 From: Sheng Jiang To: joel jaeggli , Lorenzo Colitti , Tim Chown Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAAQAgIAA0WeAgAEOlHA= Date: Fri, 31 May 2013 03:28:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99B56@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <51A7A5B1.3050709@bogus.com> In-Reply-To: <51A7A5B1.3050709@bogus.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:28:26 -0000 Pj4gICAgIEkgYWdyZWUuIFRoYXQgc2FpZCwgYW4gSVNQLCBlbnRlcnByaXNlIG9yIGdyb3VwIG9m IG9yZ2FuaXNhdGlvbnMNCj4+ICAgICBjYW4gZm9sbG93IHdoYXRldmVyIHNlbWFudGljcyB0aGV5 IHdpc2ggd2l0aGluIHRoZWlyIG93biBib3JkZXJzLg0KPj4NCj4+DQo+PiBBcyBsb25nIGFzIHRo ZSBSSVJzIGFyZSB3aWxsaW5nIHRvIGdpdmUgdGhlbSBlbm91Z2ggYWRkcmVzcyBzcGFjZSB0bw0K Pj4gZG8gc28uDQo+Pg0KPj4gSWYgYW4gSVNQIHJlcXVlc3RlZCBhbiBJUHY2IC8xMCBmcm9tIEFS SU4gYmVjYXVzZSB0aGV5IHdhbnRlZCB0byBnaXZlDQo+PiBldmVyeSBjdXN0b21lciBhIC80OCBh bmQgd2FudGVkIHRvIGdlb2NvZGUgdGhlIGN1c3RvbWVyJ3Mgc3Vic2NyaWJlcg0KPj4gSUQgaW50 byB0aGUgLzQ4LCB0aGVuIEFSSU4gd291bGQgZG8gd2VsbCB0byBzYXksICJubywgc29ycnksIHRo YXQNCj4+IGRvZXNuJ3QgbWFrZSBzZW5zZSIuDQo+Pg0KPj4gTGVzdCBzb21lb25lIG5vdCByZWFs aXplIHRoaXMsIHRoZSBkcmFmdCBzaG91bGQgY2xlYXJseSBzdGF0ZSB0aGF0DQo+PiBlbWJlZGRp bmcgTiBiaXRzIG9mIHNlbWFudGljcyBpbnRvIElQdjYgYWRkcmVzc2VzIGNhdXNlcyB0aGUgbmV0 d29yaw0KPj4gdG8gdXNlIDJeTiB0aW1lcyB0aGUgYWRkcmVzcyBzcGFjZSB0aGF0IGl0IG5vcm1h bGx5IHdvdWxkLg0KPj4NCj5wcmV0dHkgbXVjaCB3aGF0IEkgc2FpZCBhdCB0aGUgbWljLi4uIElm IHRoaXMgZXZlciBzaG93cyB1cCBpbiBhDQo+anN1dGlmaWNhdGlvbiBmb3IgYSAvMTggb3IgLzI0 IHZzIGEgIC8yNiBhdCBhbiBSSVIgdGhhdCdzIGEgcmVhbGx5IGJhZA0KPnRoaW5nIGltaG8uDQoN CkFncmVlLiBUaGUgbmV0d29yayBwcm92aWRlcnMgc2hvdWxkIGtub3cgdGhleSBjYW5ub3QgZ2V0 IG1vcmUgYWRkcmVzc2VzIGJlY2F1c2UgdGhleSB1c2UgdGhlaXIgYmxvY2sgZm9yIHNlbWFudGlj LCB3aGljaCBsZWFkIHRvIGxvd2VyIGFkZHJlc3MgdXRpbGl0eSByYXRlLg0KDQpXaWxsIG1ha2Ug dGhpcyBjbGVhciBpbiB0aGUgbmV3IHNlY3Rpb24gInBvdGVudGlhbCBwaXRmYWxscyIuDQoNCkNo ZWVycywNCg0KU2hlbmcNCg0KPj4gSU1PIEkgdGhpbmsgaXQgc2hvdWxkIGFsc28gc3RhdGUgdGhh dCBhbHRob3VnaCBpdCBpcyBhbiBJRVRGIFJGQywgdGhpcw0KPj4gbW9kZWwgaXMgbm90IG5lY2Vz c2FyaWx5IGEgcmVjb21tZW5kZWQgbW9kZWwsIGFuZCB0aGF0IFJJUnMgYXJlIG5vdA0KPj4gb2Js aWdlZCB0byBhY2NlcHQgdGhpcyB0eXBlIG9mIGFkZHJlc3MgYWxsb2NhdGlvbiBhcyBhIGp1c3Rp ZmljYXRpb24NCj4+IGZvciBvYnRhaW5pbmcgbGFyZ2VyIGFkZHJlc3MgYmxvY2tzIHRoYW4gdGhl eSB3b3VsZCBub3JtYWxseSBiZSBhYmxlDQo+PiB0byBvYnRhaW4uDQo+Pg0KPj4NCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWls aW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== From jiangsheng@huawei.com Thu May 30 20:41:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367D521F8B07; Thu, 30 May 2013 20:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CWiuM0hVw2X; Thu, 30 May 2013 20:41:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3721F89C3; Thu, 30 May 2013 20:41:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY71211; Fri, 31 May 2013 03:41:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:40:33 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:41:08 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 31 May 2013 11:41:03 +0800 From: Sheng Jiang To: George Michaelson Thread-Topic: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kc8GIAgACHYyD//5aGgIABdpag//98OwCAAKUh8A== Date: Fri, 31 May 2013 03:41:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99BA8@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BA8nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:41:59 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BA8nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEdlb3JnZSwNCg0KTXkgZ3Vlc3MgaXMgd2UgbWF5IHRhbGtpbmcgYWJvdXQgZGlmZmVyZW50 IHRoaW5ncy4gQVNJQ1MvRlBHQSBjYW4gZGlzY3JpbWluYXRlIGZsb3dzLiBCdXQgdGhlcmUgaXMg bm8gZ2lzdCB3aGljaCBmbG93IHNob3VsZCBiZSB0cmVhdGVkIGluIHdoaWNoIHByb2Nlc3MuIFRo ZSBlbWJlZGRlZCBzZW1hbnRpY3MgZ2l2ZXMgc3VjaCBnaXN0LiBBbHNvIHRoaXMgd2lsbCBzaW1w bGlmeSB0aGUgcG9saWN5IGNvbmZpZ3VyYXRpb24uIEN1cnJlbnRseSwgeW91IG1heSBuZWVkIGEg bGFyZ2Ugc3RhdGVmdWwgdGFibGUgZm9yIGhvdyB0byBwcm9jZXNzIGV2ZXJ5IGZsb3dzLiBXaXRo IGV4cGxpY2l0bHkgZXhwcmVzc2VkIHNlbWFudGljIGJpdHMsIHlvdSBtYXkgZG8gaXQgaW4gc2lt cGxlIHdheSwgaWYgc2VtYW50aWMgYml0ID09IHZhbHVlIEEsIHByb2Nlc3MgcGFja2V0IGluIEEg bWV0aG9kLg0KDQpDaGVlcnMsDQoNClNoZW5nDQoNCkZyb206IEdlb3JnZSBNaWNoYWVsc29uIFtt YWlsdG86Z2dtQGFsZ2VicmFzLm9yZ10NClNlbnQ6IEZyaWRheSwgTWF5IDMxLCAyMDEzIDk6NDEg QU0NClRvOiBTaGVuZyBKaWFuZw0KQ2M6IFJheSBIdW50ZXI7IDx2Nm9wc0BpZXRmLm9yZz47IGRy YWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IENvdWxkIElQdjYgYWRkcmVzcyBiZSBtb3JlIHRoYW4gbG9jYXRv cj8vL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMw0KDQp3aHkgb24gYWRkcmVz cyBhbmQgbm90IHBlciBmbG93PyB5b3UgYWxyZWFkeSBoYXZlIEFTSUNTL0ZQR0Egd2hpY2ggZG8g ZmxvdyBkaXNjcmltaW5hdGlvbiwgaXMgYSBwYWNrZXQgY2xhc3NpZmllciBvbiBzcmMsZHN0IHJl YWxseSBiZXR0ZXIsIHdoZW4geW91IGNhbm5vdCBhY3R1YWxseSB0cnVzdCBpdD8NCg0KT24gRnJp LCBNYXkgMzEsIDIwMTMgYXQgMTE6MzggQU0sIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdl aS5jb208bWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPj4gU2hlbmcgSmlh bmcgPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb208bWFpbHRvOmppYW5nc2hlbmdAaHVhd2Vp LmNvbT4+DQo+PiAzMCBNYXkgMjAxMyAxMTo1OA0KPj4+PiBJUCBhZGRyZXNzZXMgYXJlIGRlc2ln bmVkIGFzIHRvcG9sb2d5IGxvY2F0b3IsIHNvIHRoYXQgZXZlcnkgcGFja2V0IGNhbg0KPmJlDQo+ Pj4gcm91dGVkIHRvIGl0cyBuZXR3b3JrIGRlc3RpbmF0aW9uLg0KPj4+PiBIb3dldmVyLCBldmVu IGluIElQdjQgZXJhLCBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFwcGVkIHRoZWlyIElQ DQo+Pj4gYWRkcmVzcyB3aXRoIGNlcnRhaW4gc2VtYW50aWMgbG9jYWxseS4gVGhlc2Uga2luZCBv ZiBtZWNoYW5pc20gZXhwbGljaXRseQ0KPj4+IGV4cHJlc3MgdGhlIHNlbWFudGljIHByb3BlcnRp ZXMgb2YgZXZlcnkgcGFja2V0LiBDb25zZXF1ZW50bHksIHRoZXNlDQo+bmV0d29yaw0KPj4+IG9w ZXJhdG9ycyBjYW4gaW5zcGVjdCB0aGUgcHJvcGVydGllcyBvZiBwYWNrZXRzIGVhc2lseSBieSBt YXBwaW5nIHRoZQ0KPj4+IGFkZHJlc3NlcyBiYWNrIHRvIHNlbWFudGljLg0KPj4+PiBOZXR3b3Jr IG9wZXJhdG9ycywgd2hvIGhhdmUgbGFyZ2UgSVB2NiBhZGRyZXNzIHNwYWNlLCBtYXkgYWxzbyBj aG9vc2UNCj50bw0KPj4+IGVtYmVkZGVkIHNvbWUgc2VtYW50aWNzIGludG8gSVB2NiBhZGRyZXNz ZXMgYnkgYXNzaWduaW5nIGFkZGl0aW9uYWwNCj4+PiBzaWduaWZpY2FuY2UgdG8gc3BlY2lmaWMg Yml0cyB3aXRoaW4gdGhlIHByZWZpeC4NCj4+PiBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1w cmVmaXggZG9jdW1lbnRzIGEgZnJhbWV3b3JrIG1ldGhvZCB0aGF0DQo+Pj4gbmV0d29yayBvcGVy YXRpb25zIG1heSB1c2UgdGhlaXIgYWRkcmVzc2VzIHdpdGggZW1iZWRkZWQgc2VtYW50aWNzLg0K PlRoZXNlDQo+Pj4gc2VtYW50aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aXRoaW4gYSBz aW5nbGUgbmV0d29yaywgb3IgZ3JvdXAgb2YNCj4+PiBpbnRlcmNvbm5lY3RlZCBuZXR3b3JrcyB3 aGljaCBzaGFyZSBhIGNvbW1vbiBhZGRyZXNzaW5nIHBvbGljeS4gQmFzZWQNCj5vbg0KPj4+IHRo ZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMgaW4gc291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3Nl cywgdGhlDQo+bmV0d29yaw0KPj4+IG9wZXJhdG9ycyBjYW4gYWNjb3JkaW5nbHkgdHJlYXQgbmV0 d29yayBwYWNrZXRzIGRpZmZlcmVudGx5IGFuZCBlZmZpY2llbnRseS4NCj4+Pj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+ Pj4+DQo+Pj4+IENvdWxkIHlvdSBwbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgYW5kIGNvbW1lbnRz PyBJdCB3aWxsIGhlbHAgdGhlDQo+ZG9jdW1lbnQNCj4+PiBiZWNvbWUgbW9yZSB1c2VmdWwgaW5m b3JtYXRpb24gdG8gYmUgc2hhcmVkLg0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IFNo ZW5nDQo+Pj4+DQo+Pj4gSSBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3Igb3Bl cmF0b3JzIHRvIGhhdmUgYWRkaXRpb25hbA0KPj4+IHNlbWFudGljcyBhdmFpbGFibGUgZm9yIGN1 c3RvbWl6ZWQgcGFja2V0IHByb2Nlc3NpbmcuIEZsb3cgbGFiZWwgbm93IGhhcw0KPj4+IHZlcnkg bGltaXRlZCBwcm9wZXJ0aWVzIG9wdGltaXNlZCBmb3IgbG9hZCBiYWxhbmNlcnMuIERTQ1Agb25s eSBoYXMgYQ0KPj4+IGZldyBiaXRzICh3YXkgbGVzcyB0aGFuIHRoZSBudW1iZXIgb2YgY3VzdG9t ZXJzJyBwb2xpY2llcykuIEFDTHMgYXJlDQo+Pj4gaGVhdnkgdG8gcHJvY2VzcyBhdCBlYWNoIGhv cC4uLi4NCj4+Pg0KPj4+IEJ1dCB3b3VsZG4ndCB0aGlzIGluZm9ybWF0aW9uIGJlIGJldHRlciBv ZmYgZW5jb2RlZCBhcyB0YWdzIGluIG9uZSBvcg0KPj4+IG1vcmUgaG9wLWJ5LWhvcCBoZWFkZXIg b3B0aW9ucyAodGhhdCBjb3VsZCBiZSByZS13cml0dGVuIG9uIHRoZSBmbHkpLA0KPj4+IHJhdGhl ciB0aGFuIGVuY29kZWQgaW4gdGhlIElQdjYgYWRkcmVzcyBzcGFjZT8NCj4+DQo+PiBUaGUgc2Vj dGlvbiA0LjEgIkp1c3RpZmNhdGlvbiBmb3IgU2VtYW50aWNzIHdpdGggdGhlIElQdjYgUHJlZml4 IiBkZXNjcmliZXMNCj50aGUgcmVhc29ucy4NCj4+DQo+PiBVc2VycyBtYXkgZWFzaWx5IGNoYW5n ZSB0aGUgc2V0dGluZyBvZiBleHRlbnNpb24gaGVhZGVyIGluIG9yZGVyIHRvIG9idGFpbg0KPnVu ZGVzZXJ2ZWQgcHJpb3JpdGllcy9wcml2aWxlZ2VzLiBTZW1hbnRpYyBwcmVmaXggYXBwcm9hY2gg ZG9lcyByZXF1aXJlIHRoZQ0KPmRlcGxveW1lbnQgb2YgYWNjZXNzIGNvbnRyb2wgZmlsdGVycy4g VGhlIHBhY2tldHMgd2l0aCB0aGUgbm9uY29tcGxpYW5jZQ0KPnNvdXJjZSBhZGRyZXNzZXMgc2hv dWxkIGJlIGZpbHRlcmVkLiBUaGUgcHJlZml4IGlzIGRlbGVnYXRlZCBieSB0aGUgbmV0d29yay4N Cj5UaGVyZWZvcmUgdGhlIG5ldHdvcmsgaXMgYWJsZSB0byBkZXRlY3QgYW55IHVuZGVzaXJlZCBt b2RpZmljYXRpb25zIGFuZCBmaWx0ZXINCj50aGUgcGFja2V0IGFjY29yZGluZ2x5Lg0KPj4NCj4+ IENoZWVycywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+DQo+SSBkb24ndCBidXkgeW91ciBqdXN0aWZp Y2F0aW9uLiBXaGV0aGVyIGFuIG9wZXJhdG9yIGZpbHRlcnMgb24NCj5hdXRob3Jpc2VkIGFkZHJl c3MgcmFuZ2Ugb3IgcmUtd3JpdGVzL2ZpbHRlcnMgYW4gdW5hdXRob3Jpc2VkIGhvcC1ieS1ob3AN Cj50YWcgaXMgZWZmZWN0aXZlbHkgdGhlIHNhbWUgSU1ITy4gV2UgaGF2ZSBleGFjdGx5IHRoZSBz YW1lIGlzc3VlcyBvZg0KPnBvdGVudGlhbCB0aGVmdCBvZiBzZXJ2aWNlIHdpdGggRFNDUCB0b2Rh eSwgYW5kIHRoZSBzb2x1dGlvbiBpcyBlcXVhbGx5DQo+c2ltcGxlOiBEU0NQIG1hcmtkb3duIGF0 IHRoZSBpbmdyZXNzIHBvcnQuDQpZZXMsIHRoZSB0cnVzdCBpc3N1ZSBpcyB0aGUgc2FtZSB3aXRo IERTQ1AuIEhvd2V2ZXIsIHRoZSBEU0NQIGFic3RyYWN0IGFsbCB0aGUgc2VtYW50aWNzIGludG8g c2VydmljZSBjbGFzc2VzLCB3aGljaCBpcyBvbmUgc2luZ2xlIGRpbWVuc2lvbi4gVGhpcyBhYnN0 cmFjdCBwcm9jZXNzaW5nIGhhcyBsb3N0IGEgbG90IG9mIGluZm9ybWF0aW9uLCB3aGljaCBwcm92 aWRlcnMgd2FudCB0byBpbnNwZWN0IGZvciBldmVyeSBwYWNrZXQsIHRoZW4gcHJvY2VzcyB0aGUg cGFja2V0IGFjY29yZGluZ2x5LiBUaGUgZXhwbGljaXRseSBleHByZXNzZWQgc2VtYW50aWNzIGlu IHByZWZpeCBwcm92aWRlcyBtdWNoIG1vcmUgaW5mb3JtYXRpb25zDQoNClNoZW5nDQoNCj5yZWdh cmRzLA0KPlJheUgNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BA8nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksIEdlb3JnZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TXkgZ3Vlc3MgaXMgd2UgbWF5IHRhbGtpbmcgYWJvdXQgZGlmZmVyZW50IHRoaW5ncy4gQVNJ Q1MvRlBHQSBjYW4gZGlzY3JpbWluYXRlIGZsb3dzLiBCdXQgdGhlcmUgaXMgbm8gZ2lzdCB3aGlj aCBmbG93IHNob3VsZCBiZSB0cmVhdGVkIGluIHdoaWNoDQogcHJvY2Vzcy4gVGhlIGVtYmVkZGVk IHNlbWFudGljcyBnaXZlcyBzdWNoIGdpc3QuIEFsc28gdGhpcyB3aWxsIHNpbXBsaWZ5IHRoZSBw b2xpY3kgY29uZmlndXJhdGlvbi4gQ3VycmVudGx5LCB5b3UgbWF5IG5lZWQgYSBsYXJnZSBzdGF0 ZWZ1bCB0YWJsZSBmb3IgaG93IHRvIHByb2Nlc3MgZXZlcnkgZmxvd3MuIFdpdGggZXhwbGljaXRs eSBleHByZXNzZWQgc2VtYW50aWMgYml0cywgeW91IG1heSBkbyBpdCBpbiBzaW1wbGUgd2F5LCBp ZiBzZW1hbnRpYw0KIGJpdCA9PSB2YWx1ZSBBLCBwcm9jZXNzIHBhY2tldCBpbiBBIG1ldGhvZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBH ZW9yZ2UgTWljaGFlbHNvbiBbbWFpbHRvOmdnbUBhbGdlYnJhcy5vcmddDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBNYXkgMzEsIDIwMTMgOTo0MSBBTTxicj4NCjxiPlRvOjwvYj4gU2hlbmcg Smlhbmc8YnI+DQo8Yj5DYzo8L2I+IFJheSBIdW50ZXI7ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7 IGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ291bGQgSVB2NiBhZGRyZXNzIGJlIG1v cmUgdGhhbiBsb2NhdG9yPy8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndoeSBvbiBhZGRyZXNzIGFu ZCBub3QgcGVyIGZsb3c/IHlvdSBhbHJlYWR5IGhhdmUgQVNJQ1MvRlBHQSB3aGljaCBkbyBmbG93 IGRpc2NyaW1pbmF0aW9uLCBpcyBhIHBhY2tldCBjbGFzc2lmaWVyIG9uIHNyYyxkc3QgcmVhbGx5 IGJldHRlciwgd2hlbiB5b3UgY2Fubm90IGFjdHVhbGx5IHRydXN0IGl0PyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gRnJpLCBNYXkgMzEsIDIwMTMgYXQgMTE6MzggQU0sIFNoZW5nIEppYW5nICZsdDs8 YSBocmVmPSJtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amlh bmdzaGVuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jmd0OyBTaGVuZyBKaWFuZyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20iPmppYW5nc2hlbmdAaHVhd2Vp LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgMzAgTWF5IDIwMTMgMTE6NTg8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IElQIGFkZHJlc3NlcyBhcmUgZGVzaWduZWQgYXMgdG9wb2xvZ3kgbG9jYXRvciwg c28gdGhhdCBldmVyeSBwYWNrZXQgY2FuPGJyPg0KJmd0O2JlPGJyPg0KJmd0OyZndDsmZ3Q7IHJv dXRlZCB0byBpdHMgbmV0d29yayBkZXN0aW5hdGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhv d2V2ZXIsIGV2ZW4gaW4gSVB2NCBlcmEsIHNvbWUgbmV0d29yayBvcGVyYXRvcnMgaGF2ZSBtYXBw ZWQgdGhlaXIgSVA8YnI+DQomZ3Q7Jmd0OyZndDsgYWRkcmVzcyB3aXRoIGNlcnRhaW4gc2VtYW50 aWMgbG9jYWxseS4gVGhlc2Uga2luZCBvZiBtZWNoYW5pc20gZXhwbGljaXRseTxicj4NCiZndDsm Z3Q7Jmd0OyBleHByZXNzIHRoZSBzZW1hbnRpYyBwcm9wZXJ0aWVzIG9mIGV2ZXJ5IHBhY2tldC4g Q29uc2VxdWVudGx5LCB0aGVzZTxicj4NCiZndDtuZXR3b3JrPGJyPg0KJmd0OyZndDsmZ3Q7IG9w ZXJhdG9ycyBjYW4gaW5zcGVjdCB0aGUgcHJvcGVydGllcyBvZiBwYWNrZXRzIGVhc2lseSBieSBt YXBwaW5nIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyBhZGRyZXNzZXMgYmFjayB0byBzZW1hbnRpYy48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE5ldHdvcmsgb3BlcmF0b3JzLCB3aG8gaGF2ZSBsYXJnZSBJ UHY2IGFkZHJlc3Mgc3BhY2UsIG1heSBhbHNvIGNob29zZTxicj4NCiZndDt0bzxicj4NCiZndDsm Z3Q7Jmd0OyBlbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYgYWRkcmVzc2VzIGJ5IGFz c2lnbmluZyBhZGRpdGlvbmFsPGJyPg0KJmd0OyZndDsmZ3Q7IHNpZ25pZmljYW5jZSB0byBzcGVj aWZpYyBiaXRzIHdpdGhpbiB0aGUgcHJlZml4Ljxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC1qaWFu Zy12Nm9wcy1zZW1hbnRpYy1wcmVmaXggZG9jdW1lbnRzIGEgZnJhbWV3b3JrIG1ldGhvZCB0aGF0 PGJyPg0KJmd0OyZndDsmZ3Q7IG5ldHdvcmsgb3BlcmF0aW9ucyBtYXkgdXNlIHRoZWlyIGFkZHJl c3NlcyB3aXRoIGVtYmVkZGVkIHNlbWFudGljcy48YnI+DQomZ3Q7VGhlc2U8YnI+DQomZ3Q7Jmd0 OyZndDsgc2VtYW50aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1bCB3aXRoaW4gYSBzaW5nbGUg bmV0d29yaywgb3IgZ3JvdXAgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsgaW50ZXJjb25uZWN0ZWQgbmV0 d29ya3Mgd2hpY2ggc2hhcmUgYSBjb21tb24gYWRkcmVzc2luZyBwb2xpY3kuIEJhc2VkPGJyPg0K Jmd0O29uPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMgaW4g c291cmNlL2Rlc3RpbmF0aW9uIGFkZHJlc3NlcywgdGhlPGJyPg0KJmd0O25ldHdvcms8YnI+DQom Z3Q7Jmd0OyZndDsgb3BlcmF0b3JzIGNhbiBhY2NvcmRpbmdseSB0cmVhdCBuZXR3b3JrIHBhY2tl dHMgZGlmZmVyZW50bHkgYW5kIGVmZmljaWVudGx5Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctdjZvcHMtc2VtYW50 aWMtcHJlZml4LTAzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8L2E+PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQ291bGQgeW91IHBsZWFzZSByZXZpZXcgdGhp cyBkcmFmdCBhbmQgY29tbWVudHM/IEl0IHdpbGwgaGVscCB0aGU8YnI+DQomZ3Q7ZG9jdW1lbnQ8 YnI+DQomZ3Q7Jmd0OyZndDsgYmVjb21lIG1vcmUgdXNlZnVsIGluZm9ybWF0aW9uIHRvIGJlIHNo YXJlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTaGVuZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgSSBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3Ig b3BlcmF0b3JzIHRvIGhhdmUgYWRkaXRpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyBzZW1hbnRpY3Mg YXZhaWxhYmxlIGZvciBjdXN0b21pemVkIHBhY2tldCBwcm9jZXNzaW5nLiBGbG93IGxhYmVsIG5v dyBoYXM8YnI+DQomZ3Q7Jmd0OyZndDsgdmVyeSBsaW1pdGVkIHByb3BlcnRpZXMgb3B0aW1pc2Vk IGZvciBsb2FkIGJhbGFuY2Vycy4gRFNDUCBvbmx5IGhhcyBhPGJyPg0KJmd0OyZndDsmZ3Q7IGZl dyBiaXRzICh3YXkgbGVzcyB0aGFuIHRoZSBudW1iZXIgb2YgY3VzdG9tZXJzJyBwb2xpY2llcyku IEFDTHMgYXJlPGJyPg0KJmd0OyZndDsmZ3Q7IGhlYXZ5IHRvIHByb2Nlc3MgYXQgZWFjaCBob3Au Li4uPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEJ1dCB3b3VsZG4ndCB0aGlz IGluZm9ybWF0aW9uIGJlIGJldHRlciBvZmYgZW5jb2RlZCBhcyB0YWdzIGluIG9uZSBvcjxicj4N CiZndDsmZ3Q7Jmd0OyBtb3JlIGhvcC1ieS1ob3AgaGVhZGVyIG9wdGlvbnMgKHRoYXQgY291bGQg YmUgcmUtd3JpdHRlbiBvbiB0aGUgZmx5KSw8YnI+DQomZ3Q7Jmd0OyZndDsgcmF0aGVyIHRoYW4g ZW5jb2RlZCBpbiB0aGUgSVB2NiBhZGRyZXNzIHNwYWNlPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgVGhlIHNlY3Rpb24gNC4xICZxdW90O0p1c3RpZmNhdGlvbiBmb3IgU2VtYW50aWNzIHdp dGggdGhlIElQdjYgUHJlZml4JnF1b3Q7IGRlc2NyaWJlczxicj4NCiZndDt0aGUgcmVhc29ucy48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFVzZXJzIG1heSBlYXNpbHkgY2hhbmdlIHRoZSBz ZXR0aW5nIG9mIGV4dGVuc2lvbiBoZWFkZXIgaW4gb3JkZXIgdG8gb2J0YWluPGJyPg0KJmd0O3Vu ZGVzZXJ2ZWQgcHJpb3JpdGllcy9wcml2aWxlZ2VzLiBTZW1hbnRpYyBwcmVmaXggYXBwcm9hY2gg ZG9lcyByZXF1aXJlIHRoZTxicj4NCiZndDtkZXBsb3ltZW50IG9mIGFjY2VzcyBjb250cm9sIGZp bHRlcnMuIFRoZSBwYWNrZXRzIHdpdGggdGhlIG5vbmNvbXBsaWFuY2U8YnI+DQomZ3Q7c291cmNl IGFkZHJlc3NlcyBzaG91bGQgYmUgZmlsdGVyZWQuIFRoZSBwcmVmaXggaXMgZGVsZWdhdGVkIGJ5 IHRoZSBuZXR3b3JrLjxicj4NCiZndDtUaGVyZWZvcmUgdGhlIG5ldHdvcmsgaXMgYWJsZSB0byBk ZXRlY3QgYW55IHVuZGVzaXJlZCBtb2RpZmljYXRpb25zIGFuZCBmaWx0ZXI8YnI+DQomZ3Q7dGhl IHBhY2tldCBhY2NvcmRpbmdseS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNoZW5nPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDtJIGRvbid0IGJ1eSB5b3VyIGp1c3RpZmljYXRpb24uIFdoZXRoZXIgYW4g b3BlcmF0b3IgZmlsdGVycyBvbjxicj4NCiZndDthdXRob3Jpc2VkIGFkZHJlc3MgcmFuZ2Ugb3Ig cmUtd3JpdGVzL2ZpbHRlcnMgYW4gdW5hdXRob3Jpc2VkIGhvcC1ieS1ob3A8YnI+DQomZ3Q7dGFn IGlzIGVmZmVjdGl2ZWx5IHRoZSBzYW1lIElNSE8uIFdlIGhhdmUgZXhhY3RseSB0aGUgc2FtZSBp c3N1ZXMgb2Y8YnI+DQomZ3Q7cG90ZW50aWFsIHRoZWZ0IG9mIHNlcnZpY2Ugd2l0aCBEU0NQIHRv ZGF5LCBhbmQgdGhlIHNvbHV0aW9uIGlzIGVxdWFsbHk8YnI+DQomZ3Q7c2ltcGxlOiBEU0NQIG1h cmtkb3duIGF0IHRoZSBpbmdyZXNzIHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ZZXMsIHRo ZSB0cnVzdCBpc3N1ZSBpcyB0aGUgc2FtZSB3aXRoIERTQ1AuIEhvd2V2ZXIsIHRoZSBEU0NQIGFi c3RyYWN0IGFsbCB0aGUgc2VtYW50aWNzIGludG8gc2VydmljZSBjbGFzc2VzLCB3aGljaCBpcyBv bmUgc2luZ2xlIGRpbWVuc2lvbi4gVGhpcyBhYnN0cmFjdCBwcm9jZXNzaW5nIGhhcyBsb3N0IGEg bG90IG9mIGluZm9ybWF0aW9uLCB3aGljaCBwcm92aWRlcnMgd2FudA0KIHRvIGluc3BlY3QgZm9y IGV2ZXJ5IHBhY2tldCwgdGhlbiBwcm9jZXNzIHRoZSBwYWNrZXQgYWNjb3JkaW5nbHkuIFRoZSBl eHBsaWNpdGx5IGV4cHJlc3NlZCBzZW1hbnRpY3MgaW4gcHJlZml4IHByb3ZpZGVzIG11Y2ggbW9y ZSBpbmZvcm1hdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpTaGVuZzxicj4NCjxicj4N CiZndDtyZWdhcmRzLDxicj4NCiZndDtSYXlIPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQ djYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBp ZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czog PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8 L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BA8nkgeml512mbxchi_-- From bingxuere@gmail.com Thu May 30 20:45:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1C21F8EBC; Thu, 30 May 2013 20:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwlLMXTAbh21; Thu, 30 May 2013 20:45:45 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0372E21F8CF4; Thu, 30 May 2013 20:45:43 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so765720veb.26 for ; Thu, 30 May 2013 20:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ocrAnoUn+ziKeerM1jzZMmNBmpAxHCw/Ut0F3hJ2bm0=; b=ypqDG3kpq4mH13sI9DQ7Yzbx8QM+E2MtT8ePvRzGJRk4tj1xmAKolRjGl/hdObm3R3 owBBJDIAuwSbiJMmSDjqYlRepkrXmQuIGpJt9FP6U89ay0UVdj+rx071HXNDZGi7m3ah oKMIOj/NagMvt58SoMaVg7UveH865jVdkd0b0D+BJu+Pbi3z3YTPxfwYzwwBqAUYpaJs 1DoJYJc4fY19nMkfIZLEI2ei5y7+3HxRgQnXiWmlCCcE/P0eMLl1G90Tuo2Wrv62ZVMR SMEwZazVB2jLkVnh7KietayoMXnySpXatEqwdtteW0eAv12QkGLMlQsLuUdrvou2/8t3 26LQ== X-Received: by 10.52.76.103 with SMTP id j7mr7173687vdw.90.1369971943154; Thu, 30 May 2013 20:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.115.3 with HTTP; Thu, 30 May 2013 20:45:02 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99B42@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99B42@nkgeml512-mbx.china.huawei.com> From: Qiong Date: Fri, 31 May 2013 11:45:02 +0800 Message-ID: To: Sheng Jiang Content-Type: multipart/alternative; boundary=bcaec50162330658ad04ddfb735f Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:45:46 -0000 --bcaec50162330658ad04ddfb735f Content-Type: text/plain; charset=UTF-8 Hi Sheng, On Fri, May 31, 2013 at 11:24 AM, Sheng Jiang wrote: > Comparing giving 16 bits for subscribers, which rarely use it or we > still have no concrete idea how this will be used, the semantic bits on the > provider side looks more helpful.**** > > ** ** > > Or provider may designate the bit in the lower 16 bits can have some > semantics. For example, a provider may give every subscriber /48 and > appoint that all subscribers should use their /48+0000 (48~51 bit) -> a /52 > prefix for a certain application, like VoIP. Then the provider can inspect > all VoIP traffic from different subscribers by only set condition 48~51 bit > equal to 0000. This variation of semantic prefix is also helpful. > [Qiong] I have little concern for this variation. For operators who can not fully control of subscriber's CPE, this solution may have trust issue, and it may get conflict with other CPE's allocation policy. But it is ok for operators who can fully control of subscriber's CPE. Best wishes Qiong ** ** > > *From:* Ted Lemon [mailto:Ted.Lemon@nominum.com] > *Sent:* Friday, May 31, 2013 3:29 AM > *To:* Owen DeLong > *Cc:* Sheng Jiang; draft-jiang-v6ops-semantic-prefix@tools.ietf.org; > ipv6@ietf.org; > *Subject:* Re: [v6ops] Could IPv6 address be more than > locator?//draft-jiang-v6ops-semantic-prefix-03**** > > ** ** > > On May 30, 2013, at 12:08 PM, Owen DeLong wrote:**** > > Not a great assumption... They should need 4 million or more /48s since > every subscriber is at least one end site and every subscriber end site > should receive a /48.**** > > ** ** > > I am not in love with using bits from prefixes as semantic tags. > However, having said that, I think it's a bit ironic that you're talking > about wasting space with semantic bits, on the one hand, and talking about > the need for a /48 in every home on the other. It would be perfectly > reasonable for the ISP to specify that some of the bits in the /48 have > semantic meaning, for example, and given that we think it's okay to give > the home network a /48, we are hardly in a position to quibble about how > the bits in that /48 are used.**** > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --bcaec50162330658ad04ddfb735f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sheng,

On Fri, May 31, 2013 at 11:24 AM, Sheng Jiang &l= t;jiangsheng@hua= wei.com> wrote:

Comparing = giving 16 bits for subscribers, which rarely use it or we still have no con= crete idea how this will be used, the semantic bits on the provider side looks more helpful.

=C2= =A0

Or provide= r may designate the bit in the lower 16 bits can have some semantics. For e= xample, a provider may give every subscriber /48 and appoint that all subscribers should use their /48+0000 (48~51 bit) -> a /52 pre= fix for a certain application, like VoIP. Then the provider can inspect all= VoIP traffic from different subscribers by only set condition 48~51 bit eq= ual to 0000. This variation of semantic prefix is also helpful.
[Qiong] I have little concern for this variation. For operators who can n= ot fully control of subscriber's CPE, this solution may have trust issu= e, and it may get conflict with other CPE's allocation policy. But it i= s ok for operators who can fully control of subscriber's CPE.

Best wishes
Qiong

=C2= =A0

From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Friday, May 31, 2013 3:29 AM
To: Owen DeLong
Cc: Sheng Jiang; draft-jiang-v6ops-semantic-prefix@tools.= ietf.org; ipv6@ietf.= org; <v6ops@ietf= .org>

Subject: Re: [v6ops] Could IPv6 address be m= ore than locator?//draft-jiang-v6ops-semantic-prefix-03
=

=C2=A0

On May 30, 2013, at 12:08 PM, O= wen DeLong <owen@de= long.com> wrote:

Not a great assumption... They= should need 4 million or more /48s since every subscriber is at least one = end site and every subscriber end site should receive a /48.<= /span>

=C2=A0

I am not in love with using bit= s from prefixes as semantic tags. =C2=A0 However, having said that, I think= it's a bit ironic that you're talking about wasting space with sem= antic bits, on the one hand, and talking about the need for a /48 in every home on the other. =C2=A0 It would be perfectly re= asonable for the ISP to specify that some of the bits in the /48 have seman= tic meaning, for example, and given that we think it's okay to give the= home network a /48, we are hardly in a position to quibble about how the bits in that /48 are used.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude

Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--bcaec50162330658ad04ddfb735f-- From jiangsheng@huawei.com Thu May 30 20:52:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8673521F8A68; Thu, 30 May 2013 20:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+JG6nt6Kyl9; Thu, 30 May 2013 20:52:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 644EB21F8A0B; Thu, 30 May 2013 20:52:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY71800; Fri, 31 May 2013 03:52:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:51:36 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 04:52:11 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 31 May 2013 11:52:06 +0800 From: Sheng Jiang To: Qiong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXbFYPRFGuqgFt0q7mRTZXmU/OZkep5Pg Date: Fri, 31 May 2013 03:52:05 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99BE0@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99B42@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BE0nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:52:21 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BE0nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFFpb25nLA0KDQpTaGFyaW5nIHlvdXIgY29uY2Vybi4gVGhpcyB2YXJpYXRpb24gaXMgb25s eSBvbmUgb2YgcG9zc2libGUgd2F5IHRvIHVzZSB0aGUgYWRkcmVzcy4gU28gZmFyLCBJIGFtIG5v dCBjb252aW5jZWQgd2h5IGdpdmUgc3Vic2NyaWJlciBzb21lIG11Y2ggZnJlZSBiaXRzIGFuZCBo b3cgdG8gdXNlIGl0IHdlbGwuIE1heWJlIE93ZW4sIHdobyBzdWdnZXN0IHRoaXMgY2FuIGdpdmUg dXMgZm9yIGluZm9ybWF0aW9uLiBMZXRz4oCZIGRpc2N1c3MgdGhlIGZ1cnRoZXIuIEF0IHRoZSBl bmQsIG1heWJlIHdoYXQgd2Ugb25seSBuZWVkIHRvIGRvIGluIHRoZSBkcmFmdCBpcyB0byBkb2N1 bWVudCB0aGlzIHBvc3NpYmlsaXRpZXMgYW5kIG5ldXRyYWxseSByZWNvcmQgaXRzIGFkdmFudGFn ZXMgYW5kIHBpdGZhbGxzLg0KDQpDaGVlcnMsDQoNClNoZW5nDQoNCkZyb206IFFpb25nIFttYWls dG86YmluZ3h1ZXJlQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5IDMxLCAyMDEzIDExOjQ1 IEFNDQpUbzogU2hlbmcgSmlhbmcNCkNjOiBUZWQgTGVtb247IE93ZW4gRGVMb25nOyA8djZvcHNA aWV0Zi5vcmc+OyBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9vbHMuaWV0Zi5v cmc7IGlwdjZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIENvdWxkIElQdjYgYWRkcmVz cyBiZSBtb3JlIHRoYW4gbG9jYXRvcj8vL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZp eC0wMw0KDQpIaSBTaGVuZywNCg0KT24gRnJpLCBNYXkgMzEsIDIwMTMgYXQgMTE6MjQgQU0sIFNo ZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb208bWFpbHRvOmppYW5nc2hlbmdAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KQ29tcGFyaW5nIGdpdmluZyAxNiBiaXRzIGZvciBzdWJzY3JpYmVycywg d2hpY2ggcmFyZWx5IHVzZSBpdCBvciB3ZSBzdGlsbCBoYXZlIG5vIGNvbmNyZXRlIGlkZWEgaG93 IHRoaXMgd2lsbCBiZSB1c2VkLCB0aGUgc2VtYW50aWMgYml0cyBvbiB0aGUgcHJvdmlkZXIgc2lk ZSBsb29rcyBtb3JlIGhlbHBmdWwuDQoNCk9yIHByb3ZpZGVyIG1heSBkZXNpZ25hdGUgdGhlIGJp dCBpbiB0aGUgbG93ZXIgMTYgYml0cyBjYW4gaGF2ZSBzb21lIHNlbWFudGljcy4gRm9yIGV4YW1w bGUsIGEgcHJvdmlkZXIgbWF5IGdpdmUgZXZlcnkgc3Vic2NyaWJlciAvNDggYW5kIGFwcG9pbnQg dGhhdCBhbGwgc3Vic2NyaWJlcnMgc2hvdWxkIHVzZSB0aGVpciAvNDgrMDAwMCAoNDh+NTEgYml0 KSAtPiBhIC81MiBwcmVmaXggZm9yIGEgY2VydGFpbiBhcHBsaWNhdGlvbiwgbGlrZSBWb0lQLiBU aGVuIHRoZSBwcm92aWRlciBjYW4gaW5zcGVjdCBhbGwgVm9JUCB0cmFmZmljIGZyb20gZGlmZmVy ZW50IHN1YnNjcmliZXJzIGJ5IG9ubHkgc2V0IGNvbmRpdGlvbiA0OH41MSBiaXQgZXF1YWwgdG8g MDAwMC4gVGhpcyB2YXJpYXRpb24gb2Ygc2VtYW50aWMgcHJlZml4IGlzIGFsc28gaGVscGZ1bC4N CltRaW9uZ10gSSBoYXZlIGxpdHRsZSBjb25jZXJuIGZvciB0aGlzIHZhcmlhdGlvbi4gRm9yIG9w ZXJhdG9ycyB3aG8gY2FuIG5vdCBmdWxseSBjb250cm9sIG9mIHN1YnNjcmliZXIncyBDUEUsIHRo aXMgc29sdXRpb24gbWF5IGhhdmUgdHJ1c3QgaXNzdWUsIGFuZCBpdCBtYXkgZ2V0IGNvbmZsaWN0 IHdpdGggb3RoZXIgQ1BFJ3MgYWxsb2NhdGlvbiBwb2xpY3kuIEJ1dCBpdCBpcyBvayBmb3Igb3Bl cmF0b3JzIHdobyBjYW4gZnVsbHkgY29udHJvbCBvZiBzdWJzY3JpYmVyJ3MgQ1BFLg0KDQpCZXN0 IHdpc2hlcw0KUWlvbmcNCg0KDQoNCkZyb206IFRlZCBMZW1vbiBbbWFpbHRvOlRlZC5MZW1vbkBu b21pbnVtLmNvbTxtYWlsdG86VGVkLkxlbW9uQG5vbWludW0uY29tPl0NClNlbnQ6IEZyaWRheSwg TWF5IDMxLCAyMDEzIDM6MjkgQU0NClRvOiBPd2VuIERlTG9uZw0KQ2M6IFNoZW5nIEppYW5nOyBk cmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZz47IGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+OyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3Bz QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIENvdWxkIElQdjYgYWRkcmVzcyBiZSBt b3JlIHRoYW4gbG9jYXRvcj8vL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeC0wMw0K DQpPbiBNYXkgMzAsIDIwMTMsIGF0IDEyOjA4IFBNLCBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcu Y29tPG1haWx0bzpvd2VuQGRlbG9uZy5jb20+PiB3cm90ZToNCk5vdCBhIGdyZWF0IGFzc3VtcHRp b24uLi4gVGhleSBzaG91bGQgbmVlZCA0IG1pbGxpb24gb3IgbW9yZSAvNDhzIHNpbmNlIGV2ZXJ5 IHN1YnNjcmliZXIgaXMgYXQgbGVhc3Qgb25lIGVuZCBzaXRlIGFuZCBldmVyeSBzdWJzY3JpYmVy IGVuZCBzaXRlIHNob3VsZCByZWNlaXZlIGEgLzQ4Lg0KDQpJIGFtIG5vdCBpbiBsb3ZlIHdpdGgg dXNpbmcgYml0cyBmcm9tIHByZWZpeGVzIGFzIHNlbWFudGljIHRhZ3MuICAgSG93ZXZlciwgaGF2 aW5nIHNhaWQgdGhhdCwgSSB0aGluayBpdCdzIGEgYml0IGlyb25pYyB0aGF0IHlvdSdyZSB0YWxr aW5nIGFib3V0IHdhc3Rpbmcgc3BhY2Ugd2l0aCBzZW1hbnRpYyBiaXRzLCBvbiB0aGUgb25lIGhh bmQsIGFuZCB0YWxraW5nIGFib3V0IHRoZSBuZWVkIGZvciBhIC80OCBpbiBldmVyeSBob21lIG9u IHRoZSBvdGhlci4gICBJdCB3b3VsZCBiZSBwZXJmZWN0bHkgcmVhc29uYWJsZSBmb3IgdGhlIElT UCB0byBzcGVjaWZ5IHRoYXQgc29tZSBvZiB0aGUgYml0cyBpbiB0aGUgLzQ4IGhhdmUgc2VtYW50 aWMgbWVhbmluZywgZm9yIGV4YW1wbGUsIGFuZCBnaXZlbiB0aGF0IHdlIHRoaW5rIGl0J3Mgb2th eSB0byBnaXZlIHRoZSBob21lIG5ldHdvcmsgYSAvNDgsIHdlIGFyZSBoYXJkbHkgaW4gYSBwb3Np dGlvbiB0byBxdWliYmxlIGFib3V0IGhvdyB0aGUgYml0cyBpbiB0aGF0IC80OCBhcmUgdXNlZC4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3Bz IG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCg0KLS0NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClFpb25nIFN1bg0KQ2hp bmEgVGVsZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHVkZQ0KDQoNCk9wZW4gc291cmNlIGNv ZGU6DQpsaWdodHdlaWdodCA0b3ZlcjY6IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMv bGFmdDYvDQpQQ1AtbmF0Y29vcmQ6IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNw cG9ydHNldGRlbW8vDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BE0nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMi Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpPcHRpbWE7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwgUWlv bmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoYXJpbmcgeW91ciBjb25j ZXJuLiBUaGlzIHZhcmlhdGlvbiBpcyBvbmx5IG9uZSBvZiBwb3NzaWJsZSB3YXkgdG8gdXNlIHRo ZSBhZGRyZXNzLiBTbyBmYXIsIEkgYW0gbm90IGNvbnZpbmNlZCB3aHkgZ2l2ZSBzdWJzY3JpYmVy IHNvbWUgbXVjaCBmcmVlDQogYml0cyBhbmQgaG93IHRvIHVzZSBpdCB3ZWxsLiBNYXliZSBPd2Vu LCB3aG8gc3VnZ2VzdCB0aGlzIGNhbiBnaXZlIHVzIGZvciBpbmZvcm1hdGlvbi4gTGV0c+KAmSBk aXNjdXNzIHRoZSBmdXJ0aGVyLiBBdCB0aGUgZW5kLCBtYXliZSB3aGF0IHdlIG9ubHkgbmVlZCB0 byBkbyBpbiB0aGUgZHJhZnQgaXMgdG8gZG9jdW1lbnQgdGhpcyBwb3NzaWJpbGl0aWVzIGFuZCBu ZXV0cmFsbHkgcmVjb3JkIGl0cyBhZHZhbnRhZ2VzIGFuZCBwaXRmYWxscy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRaW9uZyBbbWFpbHRv OmJpbmd4dWVyZUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMzEs IDIwMTMgMTE6NDUgQU08YnI+DQo8Yj5Ubzo8L2I+IFNoZW5nIEppYW5nPGJyPg0KPGI+Q2M6PC9i PiBUZWQgTGVtb247IE93ZW4gRGVMb25nOyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1q aWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9vbHMuaWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gQ291bGQgSVB2NiBhZGRyZXNzIGJlIG1v cmUgdGhhbiBsb2NhdG9yPy8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIFNoZW5nLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIE1heSAzMSwgMjAxMyBhdCAxMToyNCBB TSwgU2hlbmcgSmlhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb20i IHRhcmdldD0iX2JsYW5rIj5qaWFuZ3NoZW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q29tcGFyaW5nIGdpdmluZyAxNiBiaXRzIGZvciBzdWJzY3JpYmVycywgd2hpY2ggcmFy ZWx5IHVzZSBpdCBvciB3ZSBzdGlsbCBoYXZlIG5vIGNvbmNyZXRlDQogaWRlYSBob3cgdGhpcyB3 aWxsIGJlIHVzZWQsIHRoZSBzZW1hbnRpYyBiaXRzIG9uIHRoZSBwcm92aWRlciBzaWRlIGxvb2tz IG1vcmUgaGVscGZ1bC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PciBwcm92 aWRlciBtYXkgZGVzaWduYXRlIHRoZSBiaXQgaW4gdGhlIGxvd2VyIDE2IGJpdHMgY2FuIGhhdmUg c29tZSBzZW1hbnRpY3MuIEZvcg0KIGV4YW1wbGUsIGEgcHJvdmlkZXIgbWF5IGdpdmUgZXZlcnkg c3Vic2NyaWJlciAvNDggYW5kIGFwcG9pbnQgdGhhdCBhbGwgc3Vic2NyaWJlcnMgc2hvdWxkIHVz ZSB0aGVpciAvNDgmIzQzOzAwMDAgKDQ4fjUxIGJpdCkgLSZndDsgYSAvNTIgcHJlZml4IGZvciBh IGNlcnRhaW4gYXBwbGljYXRpb24sIGxpa2UgVm9JUC4gVGhlbiB0aGUgcHJvdmlkZXIgY2FuIGlu c3BlY3QgYWxsIFZvSVAgdHJhZmZpYyBmcm9tIGRpZmZlcmVudCBzdWJzY3JpYmVycyBieSBvbmx5 DQogc2V0IGNvbmRpdGlvbiA0OH41MSBiaXQgZXF1YWwgdG8gMDAwMC4gVGhpcyB2YXJpYXRpb24g b2Ygc2VtYW50aWMgcHJlZml4IGlzIGFsc28gaGVscGZ1bC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W1Fpb25nXSBJIGhhdmUg bGl0dGxlIGNvbmNlcm4gZm9yIHRoaXMgdmFyaWF0aW9uLiBGb3Igb3BlcmF0b3JzIHdobyBjYW4g bm90IGZ1bGx5IGNvbnRyb2wgb2Ygc3Vic2NyaWJlcidzIENQRSwgdGhpcyBzb2x1dGlvbiBtYXkg aGF2ZSB0cnVzdCBpc3N1ZSwgYW5kIGl0IG1heSBnZXQgY29uZmxpY3Qgd2l0aCBvdGhlciBDUEUn cyBhbGxvY2F0aW9uIHBvbGljeS4gQnV0IGl0IGlzDQogb2sgZm9yIG9wZXJhdG9ycyB3aG8gY2Fu IGZ1bGx5IGNvbnRyb2wgb2Ygc3Vic2NyaWJlcidzIENQRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3Qgd2lzaGVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlFpb25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBUZWQNCiBMZW1vbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpUZWQuTGVtb25Abm9taW51bS5j b20iIHRhcmdldD0iX2JsYW5rIj5UZWQuTGVtb25Abm9taW51bS5jb208L2E+XQ0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlbnQ6PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IEZyaWRheSwgTWF5IDMxLCAyMDEzIDM6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+ IE93ZW4gRGVMb25nPGJyPg0KPGI+Q2M6PC9iPiBTaGVuZyBKaWFuZzsgPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4QHRvb2xzLmlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CmlwdjZAaWV0Zi5vcmc8L2E+OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW3Y2b3BzXSBD b3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuIGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9w cy1zZW1hbnRpYy1wcmVmaXgtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1heSAzMCwgMjAxMywgYXQgMTI6MDggUE0sIE93 ZW4gRGVMb25nICZsdDs8YSBocmVmPSJtYWlsdG86b3dlbkBkZWxvbmcuY29tIiB0YXJnZXQ9Il9i bGFuayI+b3dlbkBkZWxvbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7T3B0 aW1hJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ob3QgYSBncmVhdCBhc3N1bXB0aW9uLi4uIFRo ZXkgc2hvdWxkIG5lZWQgNCBtaWxsaW9uIG9yIG1vcmUgLzQ4cyBzaW5jZSBldmVyeSBzdWJzY3Jp YmVyIGlzIGF0IGxlYXN0IG9uZQ0KIGVuZCBzaXRlIGFuZCBldmVyeSBzdWJzY3JpYmVyIGVuZCBz aXRlIHNob3VsZCByZWNlaXZlIGEgLzQ4Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5JIGFtIG5vdCBpbiBsb3ZlIHdpdGggdXNpbmcgYml0cyBmcm9tIHByZWZp eGVzIGFzIHNlbWFudGljIHRhZ3MuICZuYnNwOyBIb3dldmVyLCBoYXZpbmcgc2FpZCB0aGF0LCBJ IHRoaW5rIGl0J3MgYSBiaXQgaXJvbmljIHRoYXQgeW91J3JlIHRhbGtpbmcgYWJvdXQgd2FzdGlu ZyBzcGFjZQ0KIHdpdGggc2VtYW50aWMgYml0cywgb24gdGhlIG9uZSBoYW5kLCBhbmQgdGFsa2lu ZyBhYm91dCB0aGUgbmVlZCBmb3IgYSAvNDggaW4gZXZlcnkgaG9tZSBvbiB0aGUgb3RoZXIuICZu YnNwOyBJdCB3b3VsZCBiZSBwZXJmZWN0bHkgcmVhc29uYWJsZSBmb3IgdGhlIElTUCB0byBzcGVj aWZ5IHRoYXQgc29tZSBvZiB0aGUgYml0cyBpbiB0aGUgLzQ4IGhhdmUgc2VtYW50aWMgbWVhbmlu ZywgZm9yIGV4YW1wbGUsIGFuZCBnaXZlbiB0aGF0IHdlIHRoaW5rIGl0J3MNCiBva2F5IHRvIGdp dmUgdGhlIGhvbWUgbmV0d29yayBhIC80OCwgd2UgYXJlIGhhcmRseSBpbiBhIHBvc2l0aW9uIHRv IHF1aWJibGUgYWJvdXQgaG93IHRoZSBiaXRzIGluIHRoYXQgLzQ4IGFyZSB1c2VkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDxicj4NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpRaW9uZyBTdW48 YnI+DQpDaGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dWRlPGJyPg0KPGJyPg0K PGJyPg0KT3BlbiBzb3VyY2UgY29kZTo8YnI+DQpsaWdodHdlaWdodCA0b3ZlcjY6IDxpPjxhIGhy ZWY9Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni88L2E+PC9pPjxicj4NClBD UC1uYXRjb29yZDo8aT4gPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9w Y3Bwb3J0c2V0ZGVtby8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQv cHJvamVjdHMvcGNwcG9ydHNldGRlbW8vPC9hPiA8L2k+PGJyPg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AC99BE0nkgeml512mbxchi_-- From v6ops@globis.net Thu May 30 23:23:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2E21F928C; Thu, 30 May 2013 23:23:09 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgxui7H21jfU; Thu, 30 May 2013 23:23:08 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D592D21F909A; Thu, 30 May 2013 23:23:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 81190870076; Fri, 31 May 2013 08:22:51 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAJm0d-621Ii; Fri, 31 May 2013 08:22:51 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 6273487002E; Fri, 31 May 2013 08:22:51 +0200 (CEST) Message-ID: <51A841B5.3010805@globis.net> Date: Fri, 31 May 2013 08:22:45 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 06:23:09 -0000 > Sheng Jiang > 31 May 2013 03:38 >>> Sheng Jiang >>> 30 May 2013 11:58 >>>>> IP addresses are designed as topology locator, so that every packet can >> be >>>> routed to its network destination. >>>>> However, even in IPv4 era, some network operators have mapped their IP >>>> address with certain semantic locally. These kind of mechanism explicitly >>>> express the semantic properties of every packet. Consequently, these >> network >>>> operators can inspect the properties of packets easily by mapping the >>>> addresses back to semantic. >>>>> Network operators, who have large IPv6 address space, may also choose >> to >>>> embedded some semantics into IPv6 addresses by assigning additional >>>> significance to specific bits within the prefix. >>>> draft-jiang-v6ops-semantic-prefix documents a framework method that >>>> network operations may use their addresses with embedded semantics. >> These >>>> semantics bits are only meaningful within a single network, or group of >>>> interconnected networks which share a common addressing policy. Based >> on >>>> these embedded semantic bits in source/destination addresses, the >> network >>>> operators can accordingly treat network packets differently and efficiently. >>>>> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >>>>> >>>>> Could you please review this draft and comments? It will help the >> document >>>> become more useful information to be shared. >>>>> Best regards, >>>>> >>>>> Sheng >>>>> >>>> I completely understand the desire for operators to have additional >>>> semantics available for customized packet processing. Flow label now has >>>> very limited properties optimised for load balancers. DSCP only has a >>>> few bits (way less than the number of customers' policies). ACLs are >>>> heavy to process at each hop.... >>>> >>>> But wouldn't this information be better off encoded as tags in one or >>>> more hop-by-hop header options (that could be re-written on the fly), >>>> rather than encoded in the IPv6 address space? >>> The section 4.1 "Justifcation for Semantics with the IPv6 Prefix" describes >> the reasons. >>> Users may easily change the setting of extension header in order to obtain >> undeserved priorities/privileges. Semantic prefix approach does require the >> deployment of access control filters. The packets with the noncompliance >> source addresses should be filtered. The prefix is delegated by the network. >> Therefore the network is able to detect any undesired modifications and filter >> the packet accordingly. >>> Cheers, >>> >>> Sheng >>> >>> >> I don't buy your justification. Whether an operator filters on >> authorised address range or re-writes/filters an unauthorised hop-by-hop >> tag is effectively the same IMHO. We have exactly the same issues of >> potential theft of service with DSCP today, and the solution is equally >> simple: DSCP markdown at the ingress port. > > Yes, the trust issue is the same with DSCP. However, the DSCP abstract all the semantics into service classes, which is one single dimension. This abstract processing has lost a lot of information, which providers want to inspect for every packet, then process the packet accordingly. The explicitly expressed semantics in prefix provides much more informations > > Sheng > >> regards, >> RayH > Which is why I wrote "wouldn't this information be better off encoded as tags in one or more hop-by-hop header options?" and not just "go and use DSCP" I contend that hop by hop options acting as tags would: 1) be the correct and logical place to transport such information 2) be capable of handling multiple semantics simultaneously 3) not unnecessarily waste/reserve IPv6 address space, which is large, but not infinite 4) have much more information carrying capacity than a small and fixed number of bits stolen from the IPv6 prefix Your example in Appendix A shows 12 bits of information with only 3 bits available per type of semantic bits. I suspect it will be impossible to agree on a standard division of 12 bits that works for everyone, just as DSCP gets overwritten at every AS boundary. Whereas a single hop by hop option header has 4 octets as a minimum and can be extended by another 8 octets if necessary. 5) be optional: if a particular tag isn't required by a particular session or node or LAN or site, you don't add it. Rather than having a fixed 12 bits of information as suggested in appendix A, you could only tag those properties necessary for this packet (penalty of course is potentially more parsing on the fly, but that trade off can be discussed e.g. by fixing the option length as you suggest) The conclusion from replies to the draft so far would seem to read "No, don't do it" I would therefore humbly suggest you concentrate more effort on documenting a problem statement detailing the requirements for the semantics of tagging that aren't met by today's solutions, and which are making people turn to this alternative of prefix encoding, rather than focussing on the mechanics of how to encode the semantics into the prefix. One example I can think of would be Bellovin's distributed firewalls and marking of security zones. regards RayH From martin@millnert.se Thu May 30 23:48:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172EA21F9123; Thu, 30 May 2013 23:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rQzvH8jEhoJ; Thu, 30 May 2013 23:48:44 -0700 (PDT) Received: from ncis.csbnet.se (smtp.millnert.se [IPv6:2a02:9a0:100:2:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9EB21F919D; Thu, 30 May 2013 23:48:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 6282E7596; Fri, 31 May 2013 08:37:26 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP9oc8eUlGUD; Fri, 31 May 2013 08:37:26 +0200 (CEST) Received: from [10.140.114.24] (unknown [91.143.127.196]) by ncis.csbnet.se (Postfix) with ESMTPSA id 5A50493; Fri, 31 May 2013 08:37:25 +0200 (CEST) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Martin Millnert Date: Fri, 31 May 2013 08:48:40 +0200 To: Sheng Jiang Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 06:48:45 -0000 Hi Sheng, For reference, Deutsche Telekom's Peter L=C3=B6thberg brainchild-project Ter= astream puts locally significant information in IPv6 addresses (recreating s= ome sort of label switching/routing). It's currently being deployed in Croat= ia. Regards, Martin On 29 maj 2013, at 09:06, Sheng Jiang wrote: > IP addresses are designed as topology locator, so that every packet can be= routed to its network destination. >=20 > However, even in IPv4 era, some network operators have mapped their IP add= ress with certain semantic locally. These kind of mechanism explicitly expre= ss the semantic properties of every packet. Consequently, these network oper= ators can inspect the properties of packets easily by mapping the addresses b= ack to semantic. >=20 > Network operators, who have large IPv6 address space, may also choose to e= mbedded some semantics into IPv6 addresses by assigning additional significa= nce to specific bits within the prefix. draft-jiang-v6ops-semantic-prefix do= cuments a framework method that network operations may use their addresses w= ith embedded semantics. These semantics bits are only meaningful within a si= ngle network, or group of interconnected networks which share a common addre= ssing policy. Based on these embedded semantic bits in source/destination ad= dresses, the network operators can accordingly treat network packets differe= ntly and efficiently. >=20 > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >=20 > Could you please review this draft and comments? It will help the document= become more useful information to be shared. >=20 > Best regards, >=20 > Sheng >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, May 28, 2013 10:28 AM >> To: Qiong Sun; Ian Farrer; Sheng Jiang; Boyang >> Subject: New Version Notification for >> draft-jiang-v6ops-semantic-prefix-03.txt >>=20 >>=20 >> A new version of I-D, draft-jiang-v6ops-semantic-prefix-03.txt >> has been successfully submitted by Sheng Jiang and posted to the >> IETF repository. >>=20 >> Filename: draft-jiang-v6ops-semantic-prefix >> Revision: 03 >> Title: A Framework for Semantic IPv6 Prefix >> Creation date: 2013-05-28 >> Group: Individual Submission >> Number of pages: 19 >> URL: >> http://www.ietf.org/internet-drafts/draft-jiang-v6ops-semantic-prefix-03.= txt >> Status: >> http://datatracker.ietf.org/doc/draft-jiang-v6ops-semantic-prefix >> Htmlized: >> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-v6ops-semantic-prefix-03 >>=20 >> Abstract: >> This document describes a framework method that network operations >> may use their addresses. Network operators, who have large IPv6 >> address space, may choose to embedded some semantics into IPv6 >> addresses by assigning additional significance to specific bits >> within the prefix. By embedded semantics into IPv6 prefixes, the >> semantics of packets can be inspected easily. Routers and other >> intermediary devices can easily apply relevant policies as required. >> Packet-level differentiation can also enable flow-level and user- >> level differentiation. Consequently, the network operators can >> accordingly treat network packets differently and efficiently. The >> management and maintenance of networks can be much simpler. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Fri May 31 00:38:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0E21F9289; Fri, 31 May 2013 00:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ISgz9z6X6WN; Fri, 31 May 2013 00:38:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 47C5721F9425; Fri, 31 May 2013 00:38:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ26653; Fri, 31 May 2013 07:38:06 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 08:37:24 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 08:37:57 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Fri, 31 May 2013 15:37:51 +0800 From: Sheng Jiang To: Ray Hunter Thread-Topic: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kc8GIAgACHYyD//5aGgIABdpag///LE4CAAJHXcA== Date: Fri, 31 May 2013 07:37:50 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> In-Reply-To: <51A841B5.3010805@globis.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 07:38:14 -0000 Pj4+Pj4+IElQIGFkZHJlc3NlcyBhcmUgZGVzaWduZWQgYXMgdG9wb2xvZ3kgbG9jYXRvciwgc28g dGhhdCBldmVyeSBwYWNrZXQgY2FuDQo+Pj4gYmUNCj4+Pj4+IHJvdXRlZCB0byBpdHMgbmV0d29y ayBkZXN0aW5hdGlvbi4NCj4+Pj4+PiBIb3dldmVyLCBldmVuIGluIElQdjQgZXJhLCBzb21lIG5l dHdvcmsgb3BlcmF0b3JzIGhhdmUgbWFwcGVkIHRoZWlyDQo+SVANCj4+Pj4+IGFkZHJlc3Mgd2l0 aCBjZXJ0YWluIHNlbWFudGljIGxvY2FsbHkuIFRoZXNlIGtpbmQgb2YgbWVjaGFuaXNtIGV4cGxp Y2l0bHkNCj4+Pj4+IGV4cHJlc3MgdGhlIHNlbWFudGljIHByb3BlcnRpZXMgb2YgZXZlcnkgcGFj a2V0LiBDb25zZXF1ZW50bHksIHRoZXNlDQo+Pj4gbmV0d29yaw0KPj4+Pj4gb3BlcmF0b3JzIGNh biBpbnNwZWN0IHRoZSBwcm9wZXJ0aWVzIG9mIHBhY2tldHMgZWFzaWx5IGJ5IG1hcHBpbmcgdGhl DQo+Pj4+PiBhZGRyZXNzZXMgYmFjayB0byBzZW1hbnRpYy4NCj4+Pj4+PiBOZXR3b3JrIG9wZXJh dG9ycywgd2hvIGhhdmUgbGFyZ2UgSVB2NiBhZGRyZXNzIHNwYWNlLCBtYXkgYWxzbw0KPmNob29z ZQ0KPj4+IHRvDQo+Pj4+PiBlbWJlZGRlZCBzb21lIHNlbWFudGljcyBpbnRvIElQdjYgYWRkcmVz c2VzIGJ5IGFzc2lnbmluZyBhZGRpdGlvbmFsDQo+Pj4+PiBzaWduaWZpY2FuY2UgdG8gc3BlY2lm aWMgYml0cyB3aXRoaW4gdGhlIHByZWZpeC4NCj4+Pj4+IGRyYWZ0LWppYW5nLXY2b3BzLXNlbWFu dGljLXByZWZpeCBkb2N1bWVudHMgYSBmcmFtZXdvcmsgbWV0aG9kIHRoYXQNCj4+Pj4+IG5ldHdv cmsgb3BlcmF0aW9ucyBtYXkgdXNlIHRoZWlyIGFkZHJlc3NlcyB3aXRoIGVtYmVkZGVkIHNlbWFu dGljcy4NCj4+PiBUaGVzZQ0KPj4+Pj4gc2VtYW50aWNzIGJpdHMgYXJlIG9ubHkgbWVhbmluZ2Z1 bCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yaywgb3IgZ3JvdXAgb2YNCj4+Pj4+IGludGVyY29ubmVj dGVkIG5ldHdvcmtzIHdoaWNoIHNoYXJlIGEgY29tbW9uIGFkZHJlc3NpbmcgcG9saWN5Lg0KPkJh c2VkDQo+Pj4gb24NCj4+Pj4+IHRoZXNlIGVtYmVkZGVkIHNlbWFudGljIGJpdHMgaW4gc291cmNl L2Rlc3RpbmF0aW9uIGFkZHJlc3NlcywgdGhlDQo+Pj4gbmV0d29yaw0KPj4+Pj4gb3BlcmF0b3Jz IGNhbiBhY2NvcmRpbmdseSB0cmVhdCBuZXR3b3JrIHBhY2tldHMgZGlmZmVyZW50bHkgYW5kDQo+ ZWZmaWNpZW50bHkuDQo+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlh bmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQo+Pj4+Pj4NCj4+Pj4+PiBDb3VsZCB5b3UgcGxl YXNlIHJldmlldyB0aGlzIGRyYWZ0IGFuZCBjb21tZW50cz8gSXQgd2lsbCBoZWxwIHRoZQ0KPj4+ IGRvY3VtZW50DQo+Pj4+PiBiZWNvbWUgbW9yZSB1c2VmdWwgaW5mb3JtYXRpb24gdG8gYmUgc2hh cmVkLg0KPj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+Pg0KPj4+Pj4+IFNoZW5nDQo+Pj4+Pj4N Cj4+Pj4+IEkgY29tcGxldGVseSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgZm9yIG9wZXJhdG9ycyB0 byBoYXZlIGFkZGl0aW9uYWwNCj4+Pj4+IHNlbWFudGljcyBhdmFpbGFibGUgZm9yIGN1c3RvbWl6 ZWQgcGFja2V0IHByb2Nlc3NpbmcuIEZsb3cgbGFiZWwgbm93DQo+aGFzDQo+Pj4+PiB2ZXJ5IGxp bWl0ZWQgcHJvcGVydGllcyBvcHRpbWlzZWQgZm9yIGxvYWQgYmFsYW5jZXJzLiBEU0NQIG9ubHkg aGFzIGENCj4+Pj4+IGZldyBiaXRzICh3YXkgbGVzcyB0aGFuIHRoZSBudW1iZXIgb2YgY3VzdG9t ZXJzJyBwb2xpY2llcykuIEFDTHMgYXJlDQo+Pj4+PiBoZWF2eSB0byBwcm9jZXNzIGF0IGVhY2gg aG9wLi4uLg0KPj4+Pj4NCj4+Pj4+IEJ1dCB3b3VsZG4ndCB0aGlzIGluZm9ybWF0aW9uIGJlIGJl dHRlciBvZmYgZW5jb2RlZCBhcyB0YWdzIGluIG9uZSBvcg0KPj4+Pj4gbW9yZSBob3AtYnktaG9w IGhlYWRlciBvcHRpb25zICh0aGF0IGNvdWxkIGJlIHJlLXdyaXR0ZW4gb24gdGhlIGZseSksDQo+ Pj4+PiByYXRoZXIgdGhhbiBlbmNvZGVkIGluIHRoZSBJUHY2IGFkZHJlc3Mgc3BhY2U/DQo+Pj4+ IFRoZSBzZWN0aW9uIDQuMSAiSnVzdGlmY2F0aW9uIGZvciBTZW1hbnRpY3Mgd2l0aCB0aGUgSVB2 NiBQcmVmaXgiIGRlc2NyaWJlcw0KPj4+IHRoZSByZWFzb25zLg0KPj4+PiBVc2VycyBtYXkgZWFz aWx5IGNoYW5nZSB0aGUgc2V0dGluZyBvZiBleHRlbnNpb24gaGVhZGVyIGluIG9yZGVyIHRvDQo+ b2J0YWluDQo+Pj4gdW5kZXNlcnZlZCBwcmlvcml0aWVzL3ByaXZpbGVnZXMuIFNlbWFudGljIHBy ZWZpeCBhcHByb2FjaCBkb2VzIHJlcXVpcmUgdGhlDQo+Pj4gZGVwbG95bWVudCBvZiBhY2Nlc3Mg Y29udHJvbCBmaWx0ZXJzLiBUaGUgcGFja2V0cyB3aXRoIHRoZSBub25jb21wbGlhbmNlDQo+Pj4g c291cmNlIGFkZHJlc3NlcyBzaG91bGQgYmUgZmlsdGVyZWQuIFRoZSBwcmVmaXggaXMgZGVsZWdh dGVkIGJ5IHRoZQ0KPm5ldHdvcmsuDQo+Pj4gVGhlcmVmb3JlIHRoZSBuZXR3b3JrIGlzIGFibGUg dG8gZGV0ZWN0IGFueSB1bmRlc2lyZWQgbW9kaWZpY2F0aW9ucyBhbmQNCj5maWx0ZXINCj4+PiB0 aGUgcGFja2V0IGFjY29yZGluZ2x5Lg0KPj4+PiBDaGVlcnMsDQo+Pj4+DQo+Pj4+IFNoZW5nDQo+ Pj4+DQo+Pj4+DQo+Pj4gSSBkb24ndCBidXkgeW91ciBqdXN0aWZpY2F0aW9uLiBXaGV0aGVyIGFu IG9wZXJhdG9yIGZpbHRlcnMgb24NCj4+PiBhdXRob3Jpc2VkIGFkZHJlc3MgcmFuZ2Ugb3IgcmUt d3JpdGVzL2ZpbHRlcnMgYW4gdW5hdXRob3Jpc2VkIGhvcC1ieS1ob3ANCj4+PiB0YWcgaXMgZWZm ZWN0aXZlbHkgdGhlIHNhbWUgSU1ITy4gV2UgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIGlzc3VlcyBv Zg0KPj4+IHBvdGVudGlhbCB0aGVmdCBvZiBzZXJ2aWNlIHdpdGggRFNDUCB0b2RheSwgYW5kIHRo ZSBzb2x1dGlvbiBpcyBlcXVhbGx5DQo+Pj4gc2ltcGxlOiBEU0NQIG1hcmtkb3duIGF0IHRoZSBp bmdyZXNzIHBvcnQuDQo+Pg0KPj4gWWVzLCB0aGUgdHJ1c3QgaXNzdWUgaXMgdGhlIHNhbWUgd2l0 aCBEU0NQLiBIb3dldmVyLCB0aGUgRFNDUCBhYnN0cmFjdCBhbGwNCj50aGUgc2VtYW50aWNzIGlu dG8gc2VydmljZSBjbGFzc2VzLCB3aGljaCBpcyBvbmUgc2luZ2xlIGRpbWVuc2lvbi4gVGhpcw0K PmFic3RyYWN0IHByb2Nlc3NpbmcgaGFzIGxvc3QgYSBsb3Qgb2YgaW5mb3JtYXRpb24sIHdoaWNo IHByb3ZpZGVycyB3YW50IHRvDQo+aW5zcGVjdCBmb3IgZXZlcnkgcGFja2V0LCB0aGVuIHByb2Nl c3MgdGhlIHBhY2tldCBhY2NvcmRpbmdseS4gVGhlIGV4cGxpY2l0bHkNCj5leHByZXNzZWQgc2Vt YW50aWNzIGluIHByZWZpeCBwcm92aWRlcyBtdWNoIG1vcmUgaW5mb3JtYXRpb25zDQo+Pg0KPj4g U2hlbmcNCj4+DQo+Pj4gcmVnYXJkcywNCj4+PiBSYXlIDQo+Pg0KPldoaWNoIGlzIHdoeSBJIHdy b3RlICJ3b3VsZG4ndCB0aGlzIGluZm9ybWF0aW9uIGJlIGJldHRlciBvZmYgZW5jb2RlZCBhcw0K PnRhZ3MgaW4gb25lIG9yIG1vcmUgaG9wLWJ5LWhvcCBoZWFkZXIgb3B0aW9ucz8iIGFuZCBub3Qg anVzdCAiZ28gYW5kIHVzZQ0KPkRTQ1AiDQo+DQo+SSBjb250ZW5kIHRoYXQgaG9wIGJ5IGhvcCBv cHRpb25zIGFjdGluZyBhcyB0YWdzIHdvdWxkOg0KPg0KPjEpIGJlIHRoZSBjb3JyZWN0IGFuZCBs b2dpY2FsIHBsYWNlIHRvIHRyYW5zcG9ydCBzdWNoIGluZm9ybWF0aW9uDQo+DQo+MikgYmUgY2Fw YWJsZSBvZiBoYW5kbGluZyBtdWx0aXBsZSBzZW1hbnRpY3Mgc2ltdWx0YW5lb3VzbHkNCj4NCj4z KSBub3QgdW5uZWNlc3NhcmlseSB3YXN0ZS9yZXNlcnZlIElQdjYgYWRkcmVzcyBzcGFjZSwgd2hp Y2ggaXMgbGFyZ2UsDQo+YnV0IG5vdCBpbmZpbml0ZQ0KPg0KPjQpIGhhdmUgbXVjaCBtb3JlIGlu Zm9ybWF0aW9uIGNhcnJ5aW5nIGNhcGFjaXR5IHRoYW4gYSBzbWFsbCBhbmQgZml4ZWQNCj5udW1i ZXIgb2YgYml0cyBzdG9sZW4gZnJvbSB0aGUgSVB2NiBwcmVmaXgNCj5Zb3VyIGV4YW1wbGUgaW4g QXBwZW5kaXggQSBzaG93cyAxMiBiaXRzIG9mIGluZm9ybWF0aW9uIHdpdGggb25seSAzIGJpdHMN Cj5hdmFpbGFibGUgcGVyIHR5cGUgb2Ygc2VtYW50aWMgYml0cy4gSSBzdXNwZWN0IGl0IHdpbGwg YmUgaW1wb3NzaWJsZSB0bw0KPmFncmVlIG9uIGEgc3RhbmRhcmQgZGl2aXNpb24gb2YgMTIgYml0 cyB0aGF0IHdvcmtzIGZvciBldmVyeW9uZSwganVzdCBhcw0KPkRTQ1AgZ2V0cyBvdmVyd3JpdHRl biBhdCBldmVyeSBBUyBib3VuZGFyeS4gV2hlcmVhcyBhIHNpbmdsZSBob3AgYnkgaG9wDQo+b3B0 aW9uIGhlYWRlciBoYXMgNCBvY3RldHMgYXMgYSBtaW5pbXVtIGFuZCBjYW4gYmUgZXh0ZW5kZWQg YnkgYW5vdGhlciA4DQo+b2N0ZXRzIGlmIG5lY2Vzc2FyeS4NCj4NCj41KSBiZSBvcHRpb25hbDog aWYgYSBwYXJ0aWN1bGFyIHRhZyBpc24ndCByZXF1aXJlZCBieSBhIHBhcnRpY3VsYXINCj5zZXNz aW9uIG9yIG5vZGUgb3IgTEFOIG9yIHNpdGUsIHlvdSBkb24ndCBhZGQgaXQuDQo+UmF0aGVyIHRo YW4gaGF2aW5nIGEgZml4ZWQgMTIgYml0cyBvZiBpbmZvcm1hdGlvbiBhcyBzdWdnZXN0ZWQgaW4N Cj5hcHBlbmRpeCBBLCB5b3UgY291bGQgb25seSB0YWcgdGhvc2UgcHJvcGVydGllcyBuZWNlc3Nh cnkgZm9yIHRoaXMNCj5wYWNrZXQgKHBlbmFsdHkgb2YgY291cnNlIGlzIHBvdGVudGlhbGx5IG1v cmUgcGFyc2luZyBvbiB0aGUgZmx5LCBidXQNCj50aGF0IHRyYWRlIG9mZiBjYW4gYmUgZGlzY3Vz c2VkIGUuZy4gYnkgZml4aW5nIHRoZSBvcHRpb24gbGVuZ3RoIGFzIHlvdQ0KPnN1Z2dlc3QpDQo+ DQo+VGhlIGNvbmNsdXNpb24gZnJvbSByZXBsaWVzIHRvIHRoZSBkcmFmdCBzbyBmYXIgd291bGQg c2VlbSB0byByZWFkICJObywNCj5kb24ndCBkbyBpdCINCj4NCj5JIHdvdWxkIHRoZXJlZm9yZSBo dW1ibHkgc3VnZ2VzdCB5b3UgY29uY2VudHJhdGUgbW9yZSBlZmZvcnQgb24NCj5kb2N1bWVudGlu ZyBhIHByb2JsZW0gc3RhdGVtZW50IGRldGFpbGluZyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUN Cj5zZW1hbnRpY3Mgb2YgdGFnZ2luZyB0aGF0IGFyZW4ndCBtZXQgYnkgdG9kYXkncyBzb2x1dGlv bnMsIGFuZCB3aGljaCBhcmUNCj5tYWtpbmcgcGVvcGxlIHR1cm4gdG8gdGhpcyBhbHRlcm5hdGl2 ZSBvZiBwcmVmaXggZW5jb2RpbmcsIHJhdGhlciB0aGFuDQo+Zm9jdXNzaW5nIG9uIHRoZSBtZWNo YW5pY3Mgb2YgaG93IHRvIGVuY29kZSB0aGUgc2VtYW50aWNzIGludG8gdGhlDQo+cHJlZml4LiBP bmUgZXhhbXBsZSBJIGNhbiB0aGluayBvZiB3b3VsZCBiZSBCZWxsb3ZpbidzIGRpc3RyaWJ1dGVk DQo+ZmlyZXdhbGxzIGFuZCBtYXJraW5nIG9mIHNlY3VyaXR5IHpvbmVzLg0KDQpIaSwgUmF5LA0K DQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbi4gSG9wLWJ5LWhvcCBoZWFkZXIgb3B0aW9ucyBt YXkgYWxzbyBiZSBhbHRlcm5hdGl2ZSBmb3IgdGhpcy4gQnV0IGl0J3MgbW9yZSBkaWZmaWN1bHQg dG8gdmVyaWZ5IGFuZCB0cnVzdCBpdC4gSWYgeW91IHdlcmUgZ29pbmcgdG8gcHJvcG9zZSBzdWNo IG1lY2hhbmlzbSwgSSB3aWxsIGNvbnNpZGVyIHRvIGNvbnRyaWJ1dGUuIDopDQoNCkFjdHVhbGx5 LCBteSBtb3RpdmF0aW9uIGlzIE5PVCB0byBzZWxsIHRoaXMgbWVjaGFuaXNtIHRvIGFueW9uZS4g TXkgb2JzZXJ2YXRpb24gaXMgc29tZSBuZXR3b3JrIG9wZXJhdG9ycywgYm90aCBJU1BzIGFuZCBl bnRlcnByaXNlIG5ldHdvcmsgb3BlcmF0b3IsIGhhcyBzdWNoIGFkZHJlc3MgcGxhbiwgb3IgYWxy ZWFkeSBpbiB1c2UuIFdlLCBhcyBJRVRGLCBjYW5ub3Qgc3RvcCB0aGVtLiBTbywgd2Ugc2hvdWxk IGRvY3VtZW50IGFuZCBhbmFseXplIHRoaXMgbWVjaGFuaXNtLiBUaGlzIHNob3VsZCBnaXZlIHNv bWUgaW5mb3JtYXRpb24gdG8gdGhlc2Ugd2hvIGhhdmUgbm90IG1hZGUgdGhlaXIgYWRkcmVzcyBw bGFuIHlldCBvbiB3aGV0aGVyIHRoZXkgbWF5IGZvbGxvdyBvciBub3QuDQoNCkkgaGF2ZSB0byBh ZG1pdCB0aGF0IHRoZSBjdXJyZW50IHN0cnVjdHVyZSBvZiB0aGlzIGRyYWZ0IG1vcmUgbGlrZSBh IHByb3Bvc2FsIHJhdGhlciB0aGFuIGFuIGFuYWx5c2lzLiBJIHdpbGwgaW1wcm92ZSB0aGlzIGlu IG5leHQgdXBkYXRlLg0KDQpDaGVlcnMsDQoNClNoZW5nDQoNCj5yZWdhcmRzDQo+UmF5SA0K From tjc@ecs.soton.ac.uk Fri May 31 01:55:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D89121F9344; Fri, 31 May 2013 01:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5xLNKtyDsAz; Fri, 31 May 2013 01:55:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 23D4521F9339; Fri, 31 May 2013 01:55:01 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4V8sM9D020678; Fri, 31 May 2013 09:54:22 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4V8sM9D020678 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1369990462; bh=Lj9mHNzjOjtoq2IRo+ftDiJ0CGU=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=CyFZaEEgcaZ86WgiHxmkD9mMcwEkgWH/EjxrEXfIKnx3fpOjEVYyulvCekYYDooMg hed//SQlm4BGWNYAqS3MB90TLAmSY2OfxuVdVSglR2rzGBfWVnHYSO8O8LBo0yEIGB ycPcX8dk+kacMsp83yQPhd0fR9YeOeskuOgAEKv0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p4U9sM0430633418Yx ret-id none; Fri, 31 May 2013 09:54:22 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4V8sIO5032360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 May 2013 09:54:19 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Tim Chown In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> Date: Fri, 31 May 2013 09:54:29 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <257DD6F7-C63E-4A03-A0E5-46ADADCBBEC9@ecs.soton.ac.uk> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p4U9sM043063341800; tid=p4U9sM0430633418Yx; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r4V8sM9D020678 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 08:55:03 -0000 On 31 May 2013, at 08:37, Sheng Jiang wrote: >=20 > Actually, my motivation is NOT to sell this mechanism to anyone. My = observation is some network operators, both ISPs and enterprise network = operator, has such address plan, or already in use. We, as IETF, cannot = stop them. So, we should document and analyze this mechanism. This = should give some information to these who have not made their address = plan yet on whether they may follow or not. Sheng, are those ISPs and enterprises already contributors within the = IETF? Can you say any more about who these are, and examples of the = semantics actually being deployed? I assume China Telecom and Deutsche = Telekom are two of them. As you say, at the moment the draft reads as a proposal, rather than an = analysis of something already in use. Some concrete examples may help. Tim From jiangsheng@huawei.com Fri May 31 02:10:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9321F9433; Fri, 31 May 2013 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi2KTQZbve9R; Fri, 31 May 2013 02:10:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43021F9425; Fri, 31 May 2013 02:09:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY99373; Fri, 31 May 2013 09:09:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 10:09:18 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 10:09:54 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 31 May 2013 17:09:51 +0800 From: Sheng Jiang To: Tim Chown Thread-Topic: Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kc8GIAgACHYyD//5aGgIABdpag///LE4CAAJHXcP//mI6AABDpg3A= Date: Fri, 31 May 2013 09:09:51 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC99D6B@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <257DD6F7-C63E-4A03-A0E5-46ADADCBBEC9@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:10:06 -0000 Pj4gQWN0dWFsbHksIG15IG1vdGl2YXRpb24gaXMgTk9UIHRvIHNlbGwgdGhpcyBtZWNoYW5pc20g dG8gYW55b25lLiBNeQ0KPm9ic2VydmF0aW9uIGlzIHNvbWUgbmV0d29yayBvcGVyYXRvcnMsIGJv dGggSVNQcyBhbmQgZW50ZXJwcmlzZSBuZXR3b3JrDQo+b3BlcmF0b3IsIGhhcyBzdWNoIGFkZHJl c3MgcGxhbiwgb3IgYWxyZWFkeSBpbiB1c2UuIFdlLCBhcyBJRVRGLCBjYW5ub3Qgc3RvcA0KPnRo ZW0uIFNvLCB3ZSBzaG91bGQgZG9jdW1lbnQgYW5kIGFuYWx5emUgdGhpcyBtZWNoYW5pc20uIFRo aXMgc2hvdWxkIGdpdmUNCj5zb21lIGluZm9ybWF0aW9uIHRvIHRoZXNlIHdobyBoYXZlIG5vdCBt YWRlIHRoZWlyIGFkZHJlc3MgcGxhbiB5ZXQgb24NCj53aGV0aGVyIHRoZXkgbWF5IGZvbGxvdyBv ciBub3QuDQo+DQo+U2hlbmcsIGFyZSB0aG9zZSBJU1BzIGFuZCBlbnRlcnByaXNlcyBhbHJlYWR5 IGNvbnRyaWJ1dG9ycyB3aXRoaW4gdGhlIElFVEY/DQo+Q2FuIHlvdSBzYXkgYW55IG1vcmUgYWJv dXQgd2hvIHRoZXNlIGFyZSwgYW5kIGV4YW1wbGVzIG9mIHRoZSBzZW1hbnRpY3MNCj5hY3R1YWxs eSBiZWluZyBkZXBsb3llZD8gIEkgYXNzdW1lIENoaW5hIFRlbGVjb20gYW5kIERldXRzY2hlIFRl bGVrb20gYXJlDQo+dHdvIG9mIHRoZW0uDQoNCkhpLCBUaW0sDQoNCkFjdHVhbGx5LCBpbiB0aGUg YXBwZW5kaXhlcyB0aGVyZSBhcmUgb25lIGV4YW1wbGUgZm9yIElTUCBhbmQgb25lIGZvciBlbnRl cnByaXNlLiBUaGUgZXhhbXBsZSBmb3IgSVNQIChBcHBlbmRpeCBBKSBpcyBtYWlubHkgYWJzdHJh Y3RlZCBmcm9tIENoaW5hIFRlbGVjb20ncyBhZGRyZXNzIHBsYW4uIEFzIGZhciBhcyBJIGtub3cs IENoaW5hIFRlbGVjb20gYW5kIENoaW5hIE1vYmlsZSBoYXZlIHZlcnkgc2ltaWxhciBhZGRyZXNz IHBsYW4uIERldXRzY2hlIFRlbGVrb20ncyBwbGFuIGhhcyBtdWNoIG1vcmUgY29tcGxpY2F0ZWQg c2VtYW50aWNzLCB3aGljaCBJIHBlcnNvbmFsbHkgdGhpbmsgaGFzIGJpZ2dlciB0ZWNobmljYWwg Z2FwcyB0byBiZWNvbWUgZGVwbG95YWJsZS4gVGhlIGVudGVycHJpc2UgZXhhbXBsZSAoQXBwZW5k aXggQikgaXMgYWJzdHJhY3RlZCBmcm9tIGFuIG9uZ29pbmcgcHJvamVjdCB0aGF0IGNvbm5lY3Qg YWxsIHZpZGVvIG1vbml0b3JzIGluIGEgYmlnIGNpdHkgYW5kIHRoZWlyIHJlYWwtdGltZSB2aWRl byBpbnRvIGFuIElQIGludHJhbmV0Lg0KDQo+QXMgeW91IHNheSwgYXQgdGhlIG1vbWVudCB0aGUg ZHJhZnQgcmVhZHMgYXMgYSBwcm9wb3NhbCwgcmF0aGVyIHRoYW4gYW4NCj5hbmFseXNpcyBvZiBz b21ldGhpbmcgYWxyZWFkeSBpbiB1c2UuICBTb21lIGNvbmNyZXRlIGV4YW1wbGVzIG1heSBoZWxw Lg0KDQpJIGd1ZXNzIHRoZSBpbnRyb2R1Y3Rpb24gYW5kIGFic3RyYWN0IHNlY3Rpb25zIGhhdmUg dG8gYmUgcmV3cml0dGVuIGZvciBiZXR0ZXIgZXhwbGFuYXRpb24uIEl0IGlzIG5vdyBtaXNsZWFk aW5nIHNvIG11Y2guDQoNClRoYW5rcywNCg0KU2hlbmcNCg0KPlRpbQ0KDQo= From martin@millnert.se Fri May 31 02:14:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE321F96F2; Fri, 31 May 2013 02:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rowEleqVrY-x; Fri, 31 May 2013 02:14:39 -0700 (PDT) Received: from ncis.csbnet.se (smtp.millnert.se [IPv6:2a02:9a0:100:2:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F421F9433; Fri, 31 May 2013 02:14:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 41A9A7596; Fri, 31 May 2013 11:03:21 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OUT5rgbT2t3; Fri, 31 May 2013 11:03:20 +0200 (CEST) Received: from [172.16.58.216] (unknown [77.233.232.198]) by ncis.csbnet.se (Postfix) with ESMTPSA id 968F493; Fri, 31 May 2013 11:03:20 +0200 (CEST) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> X-Mailer: iPad Mail (10B329) From: Martin Millnert Date: Fri, 31 May 2013 11:14:36 +0200 To: Sheng Jiang Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:14:40 -0000 Hi, On 31 maj 2013, at 09:37, Sheng Jiang wrote: > Hi, Ray, >=20 > Thanks for your suggestion. Hop-by-hop header options may also be alternat= ive for this. Extra headers is a no-go for efficient FIB-lookup and thus a waste of time i= n many aspects to standardize.=20 My 2 cents. Regards, Martin From v6ops@globis.net Fri May 31 02:46:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E66821F92E3; Fri, 31 May 2013 02:46:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWX9ncsCt5Qr; Fri, 31 May 2013 02:46:50 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36621F91CA; Fri, 31 May 2013 02:46:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B84998700E7; Fri, 31 May 2013 11:46:34 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DdSoy4EKvjy; Fri, 31 May 2013 11:46:34 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 881D2870076; Fri, 31 May 2013 11:46:34 +0200 (CEST) Message-ID: <51A87174.3080204@globis.net> Date: Fri, 31 May 2013 11:46:28 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Martin Millnert References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> In-Reply-To: <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:46:51 -0000 > Martin Millnert > 31 May 2013 11:14 > Hi, > > On 31 maj 2013, at 09:37, Sheng Jiang wrote: > > > > Extra headers is a no-go for efficient FIB-lookup and thus a waste of > time in many aspects to standardize. > > My 2 cents. > > Regards, > Martin I was suggesting looking at using a tag option within an existing header (the hop by hop header), which theoretically is already processed by all nodes along the path. So new options rather than a new header. Whether we encode these additional semantics via an address match, or a DSCP match, or a hop by hop approach, I agree the tag has to be found and parsed and processed, so it would seem sensible to me to avoid unnecessarily overloading existing semantics and instead to encode it in the position in the packet where you'd expect to find something meant for hop by hop processing i.e. the hop by hop header. If operators don't want to process the hop by hop header in the network core for whatever reason, draft-carpenter-6man-ext-transmit already proposes allowing skipping it. The alternatives: tagging in the address structure, creating tunnels, and tagging by encapsulation e.g. MPLS, also have significant pros and cons for both parsing and forwarding. But why are people coming up with these schemes for encoding semantics in the address prefixes in the first place? That's what I'd like to understand first and foremost: what lack of functionality is motivating/forcing these people to adopt such schemes? regards, RayH From Ted.Lemon@nominum.com Fri May 31 04:37:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA2D21F9371; Fri, 31 May 2013 04:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL9ABe5ZLvVo; Fri, 31 May 2013 04:37:44 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6A32421F9344; Fri, 31 May 2013 04:37:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUaiLiIpB+lUnTKZsB/lR1B5SxT0mZ8RP@postini.com; Fri, 31 May 2013 04:37:44 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E367E1B81BF; Fri, 31 May 2013 04:37:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D8151190052; Fri, 31 May 2013 04:37:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 31 May 2013 04:37:43 -0700 From: Ted Lemon To: Ray Hunter Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXd9SQdyBVa+4iEqfP8l0AGeJNJkfgQsAgAAfFYA= Date: Fri, 31 May 2013 11:37:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BE653@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> In-Reply-To: <51A87174.3080204@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 11:37:51 -0000 On May 31, 2013, at 5:46 AM, Ray Hunter wrote: > I was suggesting looking at using a tag option within an existing header > (the hop by hop header), which theoretically is already processed by all > nodes along the path. So new options rather than a new header. Right, but the hop-by-hop header doesn't exist unless you add it, and it ca= n't be processed on the fast path. It's useful for networks where there _= is_ no fast path (e.g., llns), but not so useful for the applications we're= talking about here (e.g., VoIP). > But why are people coming up with these schemes for encoding semantics > in the address prefixes in the first place? That's what I'd like to > understand first and foremost: what lack of functionality is > motivating/forcing these people to adopt such schemes? This is a good question to be asking. From nalini.elkins@insidethestack.com Fri May 31 05:32:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96D021F91CB for ; Fri, 31 May 2013 05:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u4kfBlH42Tc for ; Fri, 31 May 2013 05:32:26 -0700 (PDT) Received: from nm5-vm0.access.bullet.mail.sp2.yahoo.com (nm5-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.112]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6221F8FB3 for ; Fri, 31 May 2013 05:32:26 -0700 (PDT) Received: from [98.139.44.96] by nm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 31 May 2013 12:32:26 -0000 Received: from [98.139.44.66] by tm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 31 May 2013 12:32:26 -0000 Received: from [127.0.0.1] by omp1003.access.mail.sp2.yahoo.com with NNFMP; 31 May 2013 12:32:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 144346.10435.bm@omp1003.access.mail.sp2.yahoo.com Received: (qmail 30163 invoked by uid 60001); 31 May 2013 12:32:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370003545; bh=HgHo37lAk7szLYDhe0d9pgrS39AxORZF3xTKCRLbCXY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sR+maXKJJKUl9F9zVrBofByo1bVtZW0UQ8wp7Szx+UUyUXUHUcRCipAz5MmD6lN8pYPSjshslKtKl4Nxfve2FqWVruNsZ5PVvjpvMBjWpBQh1kp6AzQEKjhumrhIzTMJkrf+ZIC25H4wwGcCIfrRda/oT2gDdY/7d7CWSKgNRrY= X-YMail-OSG: raSX900VM1kPcRHjVeM1d.RScdbzcf3Fg3GlLvGLVRgqIuF wemwhq03WSe7C5c_ydiKpYbCCWBnAfPcdTM9fi29P6RhD7JdEuXkLT1HsldD 9fpwA7jre4BKFLuiQCxwNuIkfPewU_Lip9RgTqN4FFQYeg6013hgscSUN4ii yV_FYOSvm9nMjWythrWUzauW4s9oFgRnZRWL0_K1lcnT1IpPqyujo.kYniYB ZeNxBv9MYxqnVWm5CJNwcwUNLdb9hkzkQo8LGmcSQoRZEUGXo8t8TVtsTy_3 KExJ9sfVA0OqDUebtYQkA4kRUoHB7JJ8bl7gnTPOxC2O0J6_Vs3CxBT50f37 pLkWGc5peLHPsXjsmHZNztwo3gCWSM3cRtpMOh0p_8JjxY7sDmNKX64M4dDy XqVe3WZGjlI9IC3kBVwq1R.0qmTfDkFjxrTn0SLoLus6NIE18oBaiX3BO.PP iBhPaNmqqNYJ9gTo38uCLJbRRtWbJ6Is9.WrT1XVCfhyy0n.9kHG.hLqCpeO Sv72owmROyOaw8.yVOHPH3ehF5RbLxW9LhaMwOSzY0bfgXDKUFiakGNAwJ_5 fScPH.ktO9IFVs2uU6Yofi0JepWGa_KXb_ECdjXYcIbOYKxMfmcQiPukiDoh MBZXEqxmBlOtDuYc8tt0ty_0KN1lgACwaIgq9.w3vXRbDGG0au5aNQWvox5u cbmp.e8GM8yQP2.CUcpqpNSmcNXm8AOa2g26geEWZEjkzApAfVaXintfsiRw X0UqNSxEVoMo- Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Fri, 31 May 2013 05:32:25 PDT X-Rocket-MIMEInfo: 002.001, QWxsLAoKUGxlYXNlIGNvbW1lbnQgb24gYSBuZXcgRGVzdGluYXRpb24gT3B0aW9uIHRoYXQgd2UgYXJlIHByb3Bvc2luZzoKCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVsa2lucy02bWFuLWlwdjYtcGRtLWRlc3Qtb3B0aW9uLwoKVGhlcmUgYXJlIHR3byBkb2N1bWVudHMgd2hpY2ggZ2l2ZSB0aGUgYmFja2dyb3VuZDoKCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVsa2lucy12Nm9wcy1pcHY2LWVuZC10by1lbmQtcnQtbmVlZGVkLwoKCmh0dHBzOi8vZGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com> <519AD0EF.60600@si6networks.com> <87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com> <519F3364.80301@si6networks.com> <51A204F2.7060400@si6networks.com> <7047d3011cea40a4979aed6ab339b515@BY2PR03MB269.namprd03.prod.outlook.com> <51A77038.9000706@si6networks.com> <51A8812E.9090309@gont.com.ar> Message-ID: <1370003545.24023.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Fri, 31 May 2013 05:32:25 -0700 (PDT) From: Nalini Elkins To: "6man@ietf.org" <6man@ietf.org>, "" , "ipv6@ietf.org" In-Reply-To: <51A8812E.9090309@gont.com.ar> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1457027007-1370003545=:24023" Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> Subject: [v6ops] New PDM Destination Option Proposed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 12:32:31 -0000 --1510626085-1457027007-1370003545=:24023 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=0APlease comment on a new Destination Option that we are proposing:= =0A=0Ahttps://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-opti= on/=0A=0AThere are two documents which give the background:=0A=0Ahttps://da= tatracker.ietf.org/doc/draft-elkins-v6ops-ipv6-end-to-end-rt-needed/=0A=0A= =0Ahttps://datatracker.ietf.org/doc/draft-elkins-v6ops-ipv6-packet-sequence= -needed/=0A=0A=0AAnd one which gives the recommended usage of this destinat= ion option:=0A=0Ahttps://datatracker.ietf.org/doc/draft-elkins-v6ops-ipv6-p= dm-recommended-usage/=0A=0AWe will be contacting the 6Man chairs to get on = the agenda for Berlin.=0A=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Pr= oducts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com --1510626085-1457027007-1370003545=:24023 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,

Please comment on a new Destina= tion Option that we are proposing:

https://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pd= m-dest-option/
There are two doc= uments which give the background:

https://data= tracker.ietf.org/doc/draft-elkins-v6ops-ipv6-end-to-end-rt-needed/
<= /div>

https://datatra= cker.ietf.org/doc/draft-elkins-v6ops-ipv6-packet-sequence-needed/

And one which gives the recommended usage of= this destination option:
https://datatracker.ietf= .org/doc/draft-elkins-v6ops-ipv6-pdm-recommended-usage/

<= /div>
We will be contacting the 6Man chairs to = get on the agenda for Berlin.

Thanks,

Nalini Elkins
Inside Products, Inc.(831) 659-8360
www.insidethestack.com

<= /div>
--1510626085-1457027007-1370003545=:24023-- From fred@cisco.com Fri May 31 05:45:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB89F21F92C5 for ; Fri, 31 May 2013 05:45:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywaHibCjN9vt for ; Fri, 31 May 2013 05:45:09 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DFC6721F9425 for ; Fri, 31 May 2013 05:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147; q=dns/txt; s=iport; t=1370004308; x=1371213908; h=date:from:message-id:to:subject:cc; bh=CFyW9IrWgyYurmP5qUK4MA42DmYZ7yekwU1u3/9+OYs=; b=dXR2dJDG7vEMtDoXeIpo0nIeMoCgXFYMVD8gyFe+a3uoyBnD6hQ8l7kU 08AvQFn2q+8jl3bT7VZN2dV/rnhONnYcghfJ6ZdA16HKy5l947ZWCNbjx KBvtTlf6bfjfZUW819h43f5q0nddPI8eA37L8QcIfbk+nsyGWoeSaztOe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEGAEaaqFGrRDoG/2dsb2JhbABagwkwgnWqAgGRcoEAFnSDIzwtB4htDbpSjxwdgmBhA4kgj0eQF4Mv X-IronPort-AV: E=Sophos;i="4.87,778,1363132800"; d="scan'208";a="79460101" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 May 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4VCj0NZ002999; Fri, 31 May 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r4VCj0D00915; Fri, 31 May 2013 05:45:00 -0700 (PDT) Date: Fri, 31 May 2013 05:45:00 -0700 (PDT) From: Message-Id: <201305311245.r4VCj0D00915@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-pdm-recommended-usage@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-pdm-recommended-usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 12:45:13 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-pdm-recommended-usage. Please take a look at it and comment. From fred@cisco.com Fri May 31 05:45:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D488021F9344 for ; Fri, 31 May 2013 05:45:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LywqBysc5Fw8 for ; Fri, 31 May 2013 05:45:09 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0096221F947C for ; Fri, 31 May 2013 05:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=148; q=dns/txt; s=iport; t=1370004309; x=1371213909; h=date:from:message-id:to:subject:cc; bh=rC8o26EcEy+8REy+Wav0AEulGLPBTyA3RweQHZHii4M=; b=izEeSnUMx1/eCzpKP8lkqOUVOkhILPC0SdS/7MgvGvDyQR5cp8U+n+vl eyWFoG3IagfwwjX2z9B6u1tywqPbnyw1/3+qB54jJpBRAKc+vU26HZMlo MMYmXWV6c9DnC5MlWWAD787lZlnxL6HeXha7o9Q559ItzHLQxxkpPbHxq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEGAOeaqFGrRDoI/2dsb2JhbABagwkwgnWqAgGRcoEAFnSDIzwtB4htDbpRjxwdg0EDiSCPR5AXgy8 X-IronPort-AV: E=Sophos;i="4.87,778,1363132800"; d="scan'208";a="82479848" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 31 May 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4VCj0l0027915; Fri, 31 May 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r4VCj0l00909; Fri, 31 May 2013 05:45:00 -0700 (PDT) Date: Fri, 31 May 2013 05:45:00 -0700 (PDT) From: Message-Id: <201305311245.r4VCj0l00909@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-packet-sequence-needed@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-packet-sequence-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 12:45:14 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed. Please take a look at it and comment. From fred@cisco.com Fri May 31 05:45:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA3B21F9732 for ; Fri, 31 May 2013 05:45:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCitJLraqyDW for ; Fri, 31 May 2013 05:45:34 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CA7BE21F971B for ; Fri, 31 May 2013 05:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=146; q=dns/txt; s=iport; t=1370004334; x=1371213934; h=date:from:message-id:to:subject:cc; bh=Lh12eQGSOC8bsJXakkISHcNph3OXtiZ04KFi8s6qKp4=; b=VmEpRAam9xsleyEGKlTtCpV/7wvsVaxqwq8cDZwqiKUKxj4s67R7bFz0 U8epZYhQGcdONzjakQg7YHzeQ/vMlVCn+e2dW411Nyjl3iCArpxUlEYs1 wSzAdZQpsqwWfAIuJFowrZTiiIKaEHdQy+axJkGYV9jaKLKgSDvC70QUS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiINAOeaqFGrRDoH/2dsb2JhbABagwkwgnWqAgGRagMBAwGBABZ0gyM8LQeIbQ26UY4KgRIdg0EDiSCPR5AXgy8 X-IronPort-AV: E=Sophos;i="4.87,778,1363132800"; d="scan'208";a="79975179" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 31 May 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4VCj0cK002368; Fri, 31 May 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r4VCj0N00903; Fri, 31 May 2013 05:45:00 -0700 (PDT) Date: Fri, 31 May 2013 05:45:00 -0700 (PDT) From: Message-Id: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 12:45:38 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. Please take a look at it and comment. From bingxuere@gmail.com Fri May 31 07:02:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7421F8FEB; Fri, 31 May 2013 07:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48ZGNU7633iD; Fri, 31 May 2013 07:02:27 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3F21F8F83; Fri, 31 May 2013 07:02:27 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id 10so2244305pdi.31 for ; Fri, 31 May 2013 07:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=lkq6mdcf5vCjfHmfV9JixwN/j7lyb/2gCUwgQiJcGzI=; b=J1OuERpRjpnVoVGh8K+wBW54mUSGvJOrjB7kfkx2Kf7a7lPozU14FKDB+xRYNfElU6 dzYhBNmIPOoB9ydoe8r66GPoGHJghgXmIJlwpphEZ5O4ldrls6hxojFFvj1vHt4MWtK1 hRvn/nE70ZM0IJqwK2+b/Xlfii/pJ+WV/zatKhK+2D2ymKHZF/FAzYdG8KuSdmj5OC8u WsGrPLETcvq13IwVMlc9wuropvS+szzQ469n4uT63Eeep852VJ2d0t55SXkc5KVMKd6C kbp+enkCC8nPD6cVZV2khRxGjSpl0eOqZLbGK1PnQV4yxkBg3FuCuE0RjBTX+l9CyD98 nUoQ== X-Received: by 10.66.248.228 with SMTP id yp4mr13627185pac.158.1370008944836; Fri, 31 May 2013 07:02:24 -0700 (PDT) Received: from [10.4.128.172] ([61.148.242.239]) by mx.google.com with ESMTPSA id l4sm46865651pbo.6.2013.05.31.07.02.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 07:02:23 -0700 (PDT) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> <8D23D4052ABE7A4490E77B1A012B6307751BE653@mbx-01.win.nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BE653@mbx-01.win.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4EF22CF5-7BF1-4FF5-8696-C3EC2CEC3427@gmail.com> X-Mailer: iPad Mail (10A8500) From: "bingxuere@gmail.com" Date: Fri, 31 May 2013 22:02:12 +0800 To: Ted Lemon Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:02:33 -0000 Hi Ted and all, On 2013-5-31, at 19:37, Ted Lemon wrote: > On May 31, 2013, at 5:46 AM, Ray Hunter wrote: >> I was suggesting looking at using a tag option within an existing header >> (the hop by hop header), which theoretically is already processed by all >> nodes along the path. So new options rather than a new header. >=20 > Right, but the hop-by-hop header doesn't exist unless you add it, and it c= an't be processed on the fast path. It's useful for networks where there _= is_ no fast path (e.g., llns), but not so useful for the applications we're t= alking about here (e.g., VoIP). >=20 >> But why are people coming up with these schemes for encoding semantics >> in the address prefixes in the first place? That's what I'd like to >> understand first and foremost: what lack of functionality is >> motivating/forcing these people to adopt such schemes? >=20 > This is a good question to be asking. [Qiong] I'm trying to answer this question from operator's aspect. When we a= re trying to encode semantics e.g service type, subscriber type, etc., in so= me flag, it should have the following features: 1) It should exist and be encoded from the beginning. Otherwise, we still ne= ed to introduce dpi-related system to identify certain services, which I bel= ieve is not scalable. 2) It cannot be changed along the path. Otherwise, there will be trust issue= and may be changed to a different value without notice. 3) It can be easily treated in existing routers. In the ideal way, it does n= ot need to introduce new functionality so that all our existing routers can d= eal with it. This can greatly reduce our upgrading cost. These are major reasons that we embed semantics in prefixes. But I'm still o= pen suggestions if there is a better choice. Best wishes Qiong >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dwing@cisco.com Fri May 31 17:48:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2321F8F2F for ; Fri, 31 May 2013 17:48:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvpMyKfjRHGt for ; Fri, 31 May 2013 17:48:09 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7505221F867B for ; Fri, 31 May 2013 17:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1320; q=dns/txt; s=iport; t=1370047689; x=1371257289; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nBZKYJt8H1vD4jMLD1X9FFO4zrVWLzZsWhc0Fiovx1s=; b=XHC+i5f1vRIZbw0AIJ8Hl5SJdpCRgZimP8BMuZ4PD66/YJS7ZtDXIsc4 H67ls39BSJ1ysFyGd1u3BOcoKcsno3qwqN2aBmThsK+VO5emhQY57LrX7 Lmb9Mo5XSlB8K2CJ3JfknWAEWy5VIdhRMOZQHtZwVIu3kVWFrvfXVu5ZC 8=; X-IronPort-AV: E=Sophos;i="4.87,782,1363132800"; d="scan'208";a="79499034" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 01 Jun 2013 00:48:09 +0000 Received: from [10.156.16.77] ([10.156.16.77]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r510m8oP032720; Sat, 1 Jun 2013 00:48:08 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Dan Wing In-Reply-To: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> Date: Fri, 31 May 2013 17:48:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201305311245.r4VCj0N00903@ftpeng-update.cisco.com> To: fred@cisco.com X-Mailer: Apple Mail (2.1503) Cc: v6ops@ietf.org, draft-elkins-v6ops-ipv6-end-to-end-rt-needed@tools.ietf.org Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 00:48:14 -0000 On May 31, 2013, at 5:45 AM, fred@cisco.com wrote: > A new draft has been posted, at = http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. = Please take a look at it and comment. I read that document and draft-elkins-v6ops-ipv6-packet-sequence-needed. = Both the documents talk about how IPID is useful on IPv4 (if the sender = is monotonically increasing the IPID, which is a necessity for the = existing system to operate) and how routers sometimes send a packet = twice (which is normal behavior of Ethernet) and that the monotonically = increasing IPID helps distinguish Ethernet re-transmissions from host = stack retransmissions. I note that Real Time Protocol (RTP, RFC3550; previously RFC1889 = published in 1996) had similar needs and solved them at the RTP = application layer with sequence numbers and timestamps, and with its = RTCP feedback channel. The two I-Ds that I reviewed did not discuss why = this application timing problem cannot be solved at the application = layer like RTP solved it. I did not see an analysis of forcing an IPv6 fragmentation header (as = done by 4rd for transparency, = http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that could = provide a function nearly identical to the existing (ab)use of IPv4 = IPID. -d From owen@delong.com Fri May 31 19:03:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531121F8B90 for ; Fri, 31 May 2013 19:03:16 -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_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPj8oCijKuM4 for ; Fri, 31 May 2013 19:03:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 35CED21F8B21 for ; Fri, 31 May 2013 19:03:04 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r5120CDh008308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 19:00:15 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r5120CDh008308 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370052018; bh=FVbJAsGTJaGwzVVZo7oLfbvkLMM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1Qr5CoIynF7hz0/YJQ4/MPY+R4vaDhp0YLMh2tgWl7qRgxwLmDTO6Il3CwdC35DNE NJoGustP+2MWXLYa5yixslj00xDbwvv/vdrW+o2PFoCGu9OBFjeTj8zs3VeZcFDv/n CooL+0IfhtNWVPSqpdioSlWeHCdJtGHtjk/E9tew= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 31 May 2013 19:00:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13F02E5A-8915-4D8E-AE6C-7E04B05C6DCD@delong.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <1369948995.76791.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 19:00:18 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:03:18 -0000 On May 30, 2013, at 2:23 PM, Mark Smith = wrote: >=20 >> ________________________________ >> From: Lorenzo Colitti >> To: Mark Smith =20 >> Cc: "v6ops@ietf.org WG" ; = "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" = =20 >> Sent: Thursday, 30 May 2013 7:07 PM >> Subject: Re: [v6ops] A good example of why we need to careful about = ULAs >>=20 >>=20 >>=20 >> On Thu, May 30, 2013 at 5:11 PM, Mark Smith = wrote: >> In the early news, not really a new problem. >>>=20 >>=20 >>=20 >> The part where an RFC asserts says that we can generate globally = unique addresses with no global coordination is a new problem. Yes, in = theory it works, but in practice it doesn't, because everyone ends up = using fd00:: - because that's the way it worked in IPv4, and ULA is just = RFC1918 all over again, right? >>=20 >=20 > I don't agree with trying to create a registry for the non-centrally = assigned ULAs (because I think those people probably think they now own = that prefix), however here is quite a list to show that a lot of people = from a variety of organisations get that ULAs aren't set to fd00::/8 >=20 > http://www.sixxs.net/tools/grh/ula/list/ >=20 Not exactly.. It's a list of people that thought the newest pez = dispenser on the internet might be fun to play with for a little while. = Some of them may actually be using the ULAs as described in the list. = Most probably aren't. I think I even appear in that list once or twice. I guarantee you I'm = not using any ULAs at this time. >> If as an operational group we publish guidance to operators that = doesn't work in the real world (like the pref64 case above), it will be = embarrassing for us and wasteful of operators' time. We should strive to = do better than that. >>=20 >>=20 >=20 > Ok. So then a follow up question is how to provide perhaps more = tutorial oriented information? RFCs, quite reasonably, provide enough = information to justify what is proposed, and usually one use case, but = not all of them. That may not be enough information for more of a novice = fully understand the problem that is being solved, the variety of = opportunities to use it, and the pros and cons of the use of what is = proposed in those scenarios. I haven't thought v6ops was just a place to = document what has been done, but rather to document any topics related = to operations, including advice and more information on how things = invented here and in other IPv6 working groups could be used. RFCs which document standards follow the format you describe. = Informational RFCs, OTOH, can be more tutorial in nature and I don't = really see much value in this one if it is not. Owen From owen@delong.com Fri May 31 19:03:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66321F8BC0 for ; Fri, 31 May 2013 19:03:24 -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_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLR9j-hcZSRu for ; Fri, 31 May 2013 19:03:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 82ACD21F8B21 for ; Fri, 31 May 2013 19:03:20 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r5121gvT008344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 19:01:45 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r5121gvT008344 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370052107; bh=F3Eb2O7+VvssY0Is81Fy0wA+ToU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tGouYTErNShnNj2BZcQzNCc6Sc0gkYX33snpQmaem6Yr9rM26o8e0sm8G6mkUs+C1 2GbT9TJIZ/NGmq1BrFUkZLGF3cgbHhx/CQDcSFXjVy1cHBvar45RZkjVK13cy/Bwl4 mjnvJKywS/9mEa9f0zttN3Qu5OQiGeOBPyY74+Nw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <51A7C86B.3020808@gmail.com> Date: Fri, 31 May 2013 19:01:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 19:01:47 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:03:24 -0000 On May 30, 2013, at 2:45 PM, Brian E Carpenter = wrote: > On 30/05/2013 20:11, Mark Smith wrote: >>> ________________________________ >>> From: Lorenzo Colitti >>> To: "v6ops@ietf.org WG" =20 >>> Cc: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" = =20 >>> Sent: Thursday, 30 May 2013 4:41 PM >>> Subject: [v6ops] A good example of why we need to careful about ULAs >>>=20 >>>=20 >>>=20 >>> News at 11: >>>=20 >>>=20 >>> 1. ULAs leak. >>>=20 >>> 2. People assign ULAs by hand. >>>=20 >>=20 >> In the early news, not really a new problem. >>=20 >> RFC1918 and 100.64/10 leak too,=20 >=20 > In traceroutes, link-locals sometimes leak too. >=20 Only if the intermediate routers are broken. A router should not forward = the ICMP Time Exceeded message off link if it contains a link-local = source address. > All these are confusing and make the traceroute hard to interpret, > but they don't actually *matter*. What matters is if they leak in > actual traffic such as attempted TCP connections. Does that happen? How is having them leak in attempted TCP connections worse than having = them leak in ICMP headers? It's still an invalid header. Owen >=20 > Brian >=20 >> and what is worse, I've seen people intentionally expose RFC1918s to = other networks - the largest carrier here in .au uses RFC1918 addresses = for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, = spread across multiple /16s within 172.16/12) and then expect their many = wholesale ADSL customers' to just accept those addresses and make them = work within their own networks, despite their own, quite legitimate = internal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate = that address space from your own). So we can't pretend that RFC1918s = have been perfectly used, and therefore ULAs being less private than = intended is going to be new problem and experience. At least properly = formed ULAs are unlikely to conflict with other network's ones, even if = the other network has used fd00::/8, and if the two interconnecting = parties have both been lazy and used fd00::/8, they'll both be victims = of theirs and the other >> party's laziness (which they'll be used to, since they've probably = experienced it with RFC1918). They'll probably resort to NPTv6 to fix = it, because that is what they're used to, rather than using IPv6's = address aging mechanisms to renumber to a properly formed ULA. Good luck = to them, as long as it doesn't effect the rest of us. >>=20 >>=20 >>=20 >>> Yes, both of these a violation of IETF guidance. I don't think that = matters much, though - while we can always claim that the = implementer/operator is "holding it wrong", we should be careful that = what we design/standardize is hard to misconfigure and possibly robust = in the face of misconfiguration. Subtle nuances like "these addresses = are global scope, but not globally routable" tend to get lost very = easily. >>>=20 >>=20 >> I think recommending against ULAs is just going to result in people = stealing other address spaces for devices that don't need global = reachability - like 2001:db8::/32, or unused global address space (as we = saw with 1/8, 5/8 and other IPv4 prefixes). >>=20 >> I think global address space comes with and implies a default = assumption of global reachability, and you'll therefore have to actively = take measures to ensure they don't provide global reachability if you = don't want it. Link-locals don't cut it because they're not routable. = The need ULAs fulfils is the gap in between global space and = link-locals, and the one which RFC1918 generally fulfils in IPv4, except = that the likelyhood of address space collision is reduced. >>=20 >>> Of course, in the case of ULAs, there's not much that can be done = about the design at this point, but we should make an effort to make it = clear that the potential for misconfiguration exists and provide clear = guidance on how not to misconfigure them. >>>=20 >>>=20 >>=20 >>> Personally, I think that providing said guidance is much more useful = and important than enumerating scenarios that aren't widely, if at all, = implemented, and I hope that the authors of = draft-ietf-v6ops-ula-usage-recommendations will agree. >>>=20 >>=20 >> So is this draft aiming for BCP status and therefore should only = reflect best common practice? If not, I think it is reasonable to = present scenarios where ULAs could be useful. We've got a lot of = experience with private address spaces from IPv4 (the Deprecating Site = Local Addresses RFC3879 is also a pretty complete list of the problems = with RFC1918 addresses), so the only real difference is scenarios where = concurrent global and private address spaces could be useful. In some = cases, they'll just be more capable versions of what we've already doing = in IPv4 e.g. private addressed loopbacks on routers, global addresses on = the links, in a ULA environment you would add ULAs to the links too, = which could make troubleshooting and other OAM less dependent on the = global address space. >>=20 >> Regards, >> Mark. >>=20 >>> Cheers, >>> Lorenzo >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: Jeroen Massar >>> Date: Thu, May 30, 2013 at 4:59 AM >>> Subject: Usage of fd00::/8 on the Interwebz - something with filters = and uRPF >>> To: ipv6-ops@lists.cluenet.de >>>=20 >>>=20 >>> ... >>> 4 2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) 20.755 ms = 20.763 ms 20.784 ms >>> 5 fd00:3303::1 (fd00:3303::1) 22.010 ms 21.984 ms 21.986 ms >>> 6 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 17.806 ms = 17.889 ms 17.842 ms >>> 7 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 18.720 ms = 18.593 ms 18.617 ms >>> ... >>>=20 >>> Hmmmm fd00::/8, that really should never ever be visible on the = Internet, being Unique *LOCAL* Addresses. >>> And it does not look like they applied the randomness bit for = picking a prefix either. >>> You would also almost think that a /28 is more than enough address = space to put a few router loopbacks in. >>>=20 >>> It is apparently time for people to start checking their filters = again because it seems that these packets leak into other ASNs too... >>>=20 >>> More generally, do recheck your network for BCP38 compliance, please = do apply it and require your peers to do the same! >>>=20 >>> Greets, >>> Jeroen >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri May 31 19:17:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40D21F8DDD; Fri, 31 May 2013 19:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8fmwZYhKhbe; Fri, 31 May 2013 19:17:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 10E6521F8CF4; Fri, 31 May 2013 19:17:51 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r512ES4J008556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 19:14:31 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r512ES4J008556 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370052874; bh=pysIzCnRrFRw0tONDGMTKfi0Xsc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=gtUZlioDG1gTRaKYpSHYIsPUepLO2TzXx4Goax6O2Xj0Hx7ZCGZUF4aMjzbi+6JCo huK8Pi836V34Dv8Nz7VeNFypX6jaJFLcD7ws7DTYS1FN+iBher66S4OR6mpXu3iUoT MOxEZ2HTJw0GaWZe0J90jGJOey8hcqtCPJbXSqGs= Content-Type: multipart/alternative; boundary="Apple-Mail=_B7579E1E-80E8-4B9D-973F-0E637B85058C" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> Date: Fri, 31 May 2013 19:14:33 -0700 Message-Id: <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 19:14:34 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:17:53 -0000 --Apple-Mail=_B7579E1E-80E8-4B9D-973F-0E637B85058C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2013, at 12:29 PM, Ted Lemon wrote: > On May 30, 2013, at 12:08 PM, Owen DeLong wrote: >> Not a great assumption... They should need 4 million or more /48s = since every subscriber is at least one end site and every subscriber end = site should receive a /48. >=20 > I am not in love with using bits from prefixes as semantic tags. = However, having said that, I think it's a bit ironic that you're talking = about wasting space with semantic bits, on the one hand, and talking = about the need for a /48 in every home on the other. It would be = perfectly reasonable for the ISP to specify that some of the bits in the = /48 have semantic meaning, for example, and given that we think it's = okay to give the home network a /48, we are hardly in a position to = quibble about how the bits in that /48 are used. >=20 The /48 is in order to allow 16 bits of space for automating the = deployment of hierarchy and routing within the end-site. I wasn't specific about the nature of the end-site (home or otherwise, = as I believe all end sites should be treated the same). Taking away from those bits for ISP semantics (or some antics, depending = on your perspective) is an entirely different can of worms. Owen --Apple-Mail=_B7579E1E-80E8-4B9D-973F-0E637B85058C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 30, 2013, at 12:29 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On May 30, 2013, at 12:08 PM, Owen DeLong <owen@delong.com> wrote:

Not a great assumption... They should need 4 million or more /48s since every subscriber is at least one end site and every subscriber end site should receive a /48.

I am not in love with using bits from prefixes as semantic tags. However, having said that, I think it's a bit ironic that you're talking about wasting space with semantic bits, on the one hand, and talking about the need for a /48 in every home on the other. It would be perfectly reasonable for the ISP to specify that some of the bits in the /48 have semantic meaning, for example, and given that we think it's okay to give the home network a /48, we are hardly in a position to quibble about how the bits in that /48 are used.

The /48 is in order to allow 16 bits of space for automating the deployment of hierarchy and routing within the end-site.

I wasn't specific about the nature of the end-site (home or otherwise, as I believe all end sites should be treated the same).

Taking away from those bits for ISP semantics (or some antics, depending on your perspective) is an entirely different can of worms.

Owen

--Apple-Mail=_B7579E1E-80E8-4B9D-973F-0E637B85058C-- From Ted.Lemon@nominum.com Fri May 31 19:21:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5E121F88AC for ; Fri, 31 May 2013 19:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeQsQYU5m3SS for ; Fri, 31 May 2013 19:21:13 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 861F721F883B for ; Fri, 31 May 2013 19:21:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUalalF1f7XHMgA5XVKWI1IO/YTLu55D7@postini.com; Fri, 31 May 2013 19:21:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4364C1B81D0 for ; Fri, 31 May 2013 19:21:08 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3B328190052; Fri, 31 May 2013 19:21:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 31 May 2013 19:21:08 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] A good example of why we need to careful about ULAs Thread-Index: AQHOXQDC7OUgkY0DIk+iNTfiImmj3Zkd1dCAgADjd4CAAdoBgIAABWYA Date: Sat, 1 Jun 2013 02:21:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <28F6ACB2FD452A4BA86F08A38C9B387D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:21:20 -0000 On May 31, 2013, at 10:01 PM, Owen DeLong wrote: > How is having them leak in attempted TCP connections worse than having th= em leak in ICMP headers? It's still an invalid header. The ttl exceeded return packet doesn't expect a return packet of its own, s= o the fact that there's a "bogus" IP address on the header causes no harm, = despite being technically wrong. Filtering the packet based on the source= address, on the other hand, would cause harm. Nobody ever said life was = going to be simple. From Ted.Lemon@nominum.com Fri May 31 19:23:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C111221F8B3D; Fri, 31 May 2013 19:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+6k2IIVYUDV; Fri, 31 May 2013 19:22:58 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 162B021F88FB; Fri, 31 May 2013 19:22:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUala/jrRr/8dltpX/lfnsYB4a1/X2ezb@postini.com; Fri, 31 May 2013 19:22:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3864E1B81D2; Fri, 31 May 2013 19:22:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2E61119005C; Fri, 31 May 2013 19:22:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 31 May 2013 19:22:54 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOA Date: Sat, 1 Jun 2013 02:22:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> In-Reply-To: <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751BFE2Dmbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:23:06 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751BFE2Dmbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 31, 2013, at 10:14 PM, Owen DeLong > wrote: The /48 is in order to allow 16 bits of space for automating the deployment= of hierarchy and routing within the end-site. Right, which is ludicrous overkill, given that we have two different soluti= ons for the problem of efficiently distributing prefixes in the home, neith= er of which require 16 bits of prefix unless you have 64k distinct links in= the home. --_000_8D23D4052ABE7A4490E77B1A012B6307751BFE2Dmbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <8FD8C39946879F4F80BC70D4B45D7F72@nominum.com> Content-Transfer-Encoding: quoted-printable

On May 31, 2013, at 10:14 PM, Owen DeLong <owen@delong.com> wrote:

The /48 is in order to allow 16 bits of space for automating the deployment= of hierarchy and routing within the end-site.

Right, which is ludicrous overkill, given that we have two different s= olutions for the problem of efficiently distributing prefixes in the home, = neither of which require 16 bits of prefix unless you have 64k distinct lin= ks in the home.

--_000_8D23D4052ABE7A4490E77B1A012B6307751BFE2Dmbx01winnominum_-- From owen@delong.com Fri May 31 19:47:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8F21F8CF4 for ; Fri, 31 May 2013 19:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy5o26IFKLkZ for ; Fri, 31 May 2013 19:47:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCFC21F8C4C for ; Fri, 31 May 2013 19:47:55 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r512ihB3009107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 19:44:47 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r512ihB3009107 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370054690; bh=Z2ROAGmzx0Boj4YgM+NxgQS1WIY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Xw2Gesb5mA/E/D5tqhcsnYmLXkfCboVn7O70hajrIVuHE9ydB4MrvpSopkUQkygqe JCy+F1s7rQxtu8ktn3gR1oODhhbOr7OZtu2LDbUVgUtoS1dYIs+WJA8U5uJTW3ViaB vCfmrsv1GHESX+vQw3eB6QBnnot50PIVsSd9/5/I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> Date: Fri, 31 May 2013 19:44:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 19:44:50 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:47:56 -0000 On May 31, 2013, at 7:21 PM, Ted Lemon wrote: > On May 31, 2013, at 10:01 PM, Owen DeLong wrote: >> How is having them leak in attempted TCP connections worse than = having them leak in ICMP headers? It's still an invalid header. >=20 > The ttl exceeded return packet doesn't expect a return packet of its = own, so the fact that there's a "bogus" IP address on the header causes = no harm, despite being technically wrong. Filtering the packet based = on the source address, on the other hand, would cause harm. Nobody = ever said life was going to be simple. The TTL Exceeded packet shouldn't get forwarded by any router as a = result of the LL Source address. Thus it should never reach its destination. Thus it will break traceroutes. Thus it is harmful. Owen From owen@delong.com Fri May 31 19:48:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC41521F8EAE; Fri, 31 May 2013 19:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiMrTr4O9BYW; Fri, 31 May 2013 19:48:04 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EF83F21F8EAD; Fri, 31 May 2013 19:48:03 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r512l0xU009137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 19:47:04 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r512l0xU009137 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370054827; bh=zlditU8r2xm7zgLsGW0yBEC/mJY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=J+aEq0OOeJxaLDS8zYA7OY/+gBCsi9W84a3Txa2Z4+TkClFLzTiUngGgWtCLBa8aX ozDmokvVISYWARl6gqSdGAV21wrqJ0J1QIxaTqLzRbdrVKAu6fTKEujVZO0LuPRF52 ybC/j9FZjKffqPyA+nYiHrxnQZkDYzRG7v3yzYaQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_9E55564B-F1E1-4E70-8BB1-450BA7294A2B" Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> Date: Fri, 31 May 2013 19:47:05 -0700 Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 19:47:07 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:48:05 -0000 --Apple-Mail=_9E55564B-F1E1-4E70-8BB1-450BA7294A2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 31, 2013, at 7:22 PM, Ted Lemon wrote: > On May 31, 2013, at 10:14 PM, Owen DeLong wrote: >> The /48 is in order to allow 16 bits of space for automating the = deployment of hierarchy and routing within the end-site. >=20 > Right, which is ludicrous overkill, given that we have two different = solutions for the problem of efficiently distributing prefixes in the = home, neither of which require 16 bits of prefix unless you have 64k = distinct links in the home. >=20 >=20 Please explicate. What solutions exist today that provide for the home of the future where = there are, in fact, multiple levels of routers many of which are = managing routers underneath them with multiple links attached? How do these solutions adapt to arbitrary topologies and hierarchies as = they are built in the home? I've only seen such capabilities in early development stages. I haven't = seen anything like it deployed in the wild. Owen --Apple-Mail=_9E55564B-F1E1-4E70-8BB1-450BA7294A2B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 31, 2013, at 7:22 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On May 31, 2013, at 10:14 PM, Owen DeLong <owen@delong.com> wrote:

The /48 is in order to allow 16 bits of space for automating the deployment of hierarchy and routing within the end-site.

Right, which is ludicrous overkill, given that we have two different solutions for the problem of efficiently distributing prefixes in the home, neither of which require 16 bits of prefix unless you have 64k distinct links in the home.

Please explicate.

What solutions exist today that provide for the home of the future where there are, in fact, multiple levels of routers many of which are managing routers underneath them with multiple links attached?

How do these solutions adapt to arbitrary topologies and hierarchies as they are built in the home?

I've only seen such capabilities in early development stages. I haven't seen anything like it deployed in the wild.

Owen

--Apple-Mail=_9E55564B-F1E1-4E70-8BB1-450BA7294A2B-- From lorenzo@google.com Fri May 31 20:13:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01CD21F8CB7 for ; Fri, 31 May 2013 20:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBUObgwYgnYj for ; Fri, 31 May 2013 20:13:10 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5F21F8916 for ; Fri, 31 May 2013 20:13:09 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id x7so1343588qeu.37 for ; Fri, 31 May 2013 20:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jqk0N6pviClAItEl4TQNG1HIDE6A3prVWzbNS7pjCUg=; b=eK4hL7y6JrkvwJ3mQD8+tFacMPeD0dvt+IXfJ7gy3YldUGzuaB2s8bEOXhyYuYTy7C smAQq4DKwUw8sh9hdKFMb+Q0WaHaCjUtHVXdAJw3QQz7DHwM3V5AdFfAFFbaym98clfx brZi53fH/L0zeBpgcbDWEI/jvEYLK8DRf+fkL2np28mcO7L968TqvHSYhY6JjMPFnIfS JzKIApadJjAEB3pogLs0xwPW0LdZlc0OYpMomaa2c9PDbEsIZN8CJOJTQsLXaFY0dbiY cxeHJM9tSbduERLq/ADACcaQu/vgPH2lZuetEDYv/lKELivf94PQMmMBM7nIezpwkW5C KOxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Jqk0N6pviClAItEl4TQNG1HIDE6A3prVWzbNS7pjCUg=; b=D3Tuu3AUzGDfEFThFILBF24rSVspRXMyinOtgYVUg+nvBBTpYGN5A94wJTSzBEdq5t dJm5UmYqc3o3dPKk44taWUkoksScc4+xJ5tVOl7kj41nZ49LZDq+Kte1zHu64TrFS5Jv wlSvK228WLFbaE4YbZSmErLAg1bDd5FoST0smPz+EMcUwWdgTINeuo/y9dwaMr6FulLd x5D6Vymd2RE+HNHJHa74iuSl7ukhuIkk6oHBz5Z/6frCGFS/cRWFDUztTx8NaWrcTpUp WbQyBWVQj2jujVmZprtC2Wueya3roKRgBVn8SLNTwpnpWMqnvA8369o7AFG5EiRMM5bQ Ky+A== X-Received: by 10.224.42.195 with SMTP id t3mr10962565qae.44.1370056389355; Fri, 31 May 2013 20:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Fri, 31 May 2013 20:12:49 -0700 (PDT) In-Reply-To: <4EF22CF5-7BF1-4FF5-8696-C3EC2CEC3427@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> <8D23D4052ABE7A4490E77B1A012B6307751BE653@mbx-01.win.nominum.com> <4EF22CF5-7BF1-4FF5-8696-C3EC2CEC3427@gmail.com> From: Lorenzo Colitti Date: Sat, 1 Jun 2013 12:12:49 +0900 Message-ID: To: "bingxuere@gmail.com" Content-Type: multipart/alternative; boundary=089e0160bbb26927fd04de0f1c22 X-Gm-Message-State: ALoCoQnF/oPlDdPfB16edzKxnNsRmDMvOFdRencsa2iM2WFCdd+Tg+t9KlvKiJCzBl6hF/T5u4YZxL69Q7S/30YsYviaLJp1rHyFsHmMtzMHAVNaKgyIcYCoQnjxP8vEHuNu2icJh2DgeI2sZJ70TkJIxWEN8Rck2OUnh77XvKJ1wyfuBSNFFnhhZmRGTa+Ln0NrwB6KTTQ/ Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 03:13:16 -0000 --089e0160bbb26927fd04de0f1c22 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 31, 2013 at 11:02 PM, bingxuere@gmail.com wrote: > [Qiong] I'm trying to answer this question from operator's aspect. When we > are trying to encode semantics e.g service type, subscriber type, etc., in > some flag, it should have the following features: > 1) It should exist and be encoded from the beginning. Otherwise, we still > need to introduce dpi-related system to identify certain services, which I > believe is not scalable. > 2) It cannot be changed along the path. Otherwise, there will be trust > issue and may be changed to a different value without notice. > 3) It can be easily treated in existing routers. In the ideal way, it does > not need to introduce new functionality so that all our existing routers > can deal with it. This can greatly reduce our upgrading cost. > These are major reasons that we embed semantics in prefixes. But I'm > still open suggestions if there is a better choice. > DSCP does all of those today. All you need to do is ensure that you always mark the packets on ingress. --089e0160bbb26927fd04de0f1c22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2013 at 11:02 PM, bingxuere@gmail.com <bingxuere@gmail.com> wrote:

[Qiong] I'm trying to answer this question from operator'= s aspect. When we are trying to encode semantics e.g service type, subscrib= er type, etc., in some flag, it should have the following features:
1) It should exist and be encoded from the beginning. Otherwise, we still n= eed to introduce dpi-related system to identify certain services, which I b= elieve is not scalable.
2) It cannot be changed along the path. Otherwise, there will be trust issu= e and may be changed to a different value without notice.
3) It can be easily treated in existing routers. In the ideal way, it does = not need to introduce new functionality so that all our existing routers ca= n deal with it. This can greatly reduce our upgrading cost.
These are major reasons that we embed semantics in prefixes. =A0But I'm= still open suggestions if there is a better choice.
<= br>
DSCP does all of those today. All you need to do is ens= ure that you always mark the packets on ingress.=A0

--089e0160bbb26927fd04de0f1c22-- From lorenzo@google.com Fri May 31 20:19:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50721F8B98 for ; Fri, 31 May 2013 20:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZuurfJfjvMF for ; Fri, 31 May 2013 20:19:37 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AA2CC21F8ADF for ; Fri, 31 May 2013 20:19:37 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c11so1221249qcv.32 for ; Fri, 31 May 2013 20:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J3/rbdJvEMa0aASeAOrWW41Ei1Kb45oc/Si15Pd4Lio=; b=krdn1se1P+mvaHvrV0Ri0oWAaMZusjf2yh6JLmvJOShg2yqdoj/mU7Kq99ozLJ5c55 Z03dXs8R8+BaLZ2rGsmHpVWY0kElAZV9OjZVTNzFy08xFmyjeQEd//RFwrk2nddX3RUx isrzOWzRKT9E92mpaHN37PXLUX5ZzSV1T4mXIA3nMdurTRRkX5M7UD2cT82r0ui8nDva HUvjSsK9j6VveoehcMwbSY6ABEUUU2x00nWT5OCg54yqJcJtpN2A5lTX4kSMDMwLUHuZ JxkLTWQXaI8TGfoqZi/SsagU9keKXKDeGrxjefWSQ50XovTha1tGnjlcm3wD7IAo3Xaf CVOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=J3/rbdJvEMa0aASeAOrWW41Ei1Kb45oc/Si15Pd4Lio=; b=AqPHaYItTa/J5BOu/EZi8Lf78LXn5WwtBaYnwFGjFZgmm3UeEnyj3AXddIuU70UbAd SAaL8jObP3umG4bRJlqydml7YCh4aRcgI5RwenVtEu5xiKe42KvQKEClIIL8icq1x2Pc +Rr9jP4U3LOJMDL10Vfk3n3G1DKFr1p1KSbPtEptHu0Z7S06E0qDR0yF6rwPbgKa+qOQ 5VBGrlO4EmkJEMly9vrhKTiHvFf9Xzxw7z6jcU/t9z4Llr7WmnfiuKGwzTsrm2EReoRd LcYlidoerlrUkCLVZXt0aiDjqTZsjTyR9t7TS+HFz4MpiDGZPejdRLnUuQiUESH4B+L3 2uvw== X-Received: by 10.49.85.131 with SMTP id h3mr12513241qez.42.1370056776896; Fri, 31 May 2013 20:19:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Fri, 31 May 2013 20:19:16 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BDDBD@mbx-01.win.nominum.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <51A7CDA9.4090304@massar.ch> <8D23D4052ABE7A4490E77B1A012B6307751BDDBD@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Sat, 1 Jun 2013 12:19:16 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd7566a82946b04de0f331c X-Gm-Message-State: ALoCoQn6aGt8Er7d7QwH6Y7yOMfEFTGOcdUZESHHZtZRZKSWOgVxc6+1NUyl9/dbjBdhUI2wOTz8erukjMaHIzsylEZWaLQlafExTWJLPnKRTHhbiilN6vrI3IofOeoQWO/bFzApAS9l47aL2VsCQkVgrEDFgeO5mfasIpS/eJ2GHmUYsTWSzBA4Yj1eCZ+wqrqY3LriQTPL Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 03:19:38 -0000 --047d7bd7566a82946b04de0f331c Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 31, 2013 at 11:12 AM, Ted Lemon wrote: > On May 30, 2013, at 6:07 PM, Jeroen Massar wrote: > > If you know how to replicate it, I am very interested in a packet dump > > or what is involved to cause it. > > Just number your internal network using ULAs and no global addresses, and > then run a traceroute across it. Global addresses on the source end, > global addresses on the destination end, ULAs in the middle. The only way > to "fix" this is to break traceroute. This does not represent brokenness. RFC 4193 section 4.3 disagrees with you. It says that border routers should drop those packets and send back ICMP unreachables. --047d7bd7566a82946b04de0f331c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2013 at 11:12 AM, Ted Lemon <Ted.Lemo= n@nominum.com> wrote:

On May 30, 2013, at 6:07 PM, Jeroen Mass= ar <jeroen@massar.ch> wrote:<= br> > If you know how to replicate it, I am very interested in a packet dump=
> or what is involved to cause it.

Just number your internal network using ULAs and no global addresses,= and then run a traceroute across it. =A0 Global addresses on the source en= d, global addresses on the destination end, ULAs in the middle. =A0 The onl= y way to "fix" this is to break traceroute. =A0 This does not rep= resent brokenness.

RFC 4193 section 4.3 disagrees with you. It says = that border routers should drop those packets and send back ICMP unreachabl= es.
--047d7bd7566a82946b04de0f331c-- From shane@castlepoint.net Fri May 31 20:20:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7721F8E6E for ; Fri, 31 May 2013 20:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-o5oV9XYcM7 for ; Fri, 31 May 2013 20:20:28 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9973C21F8C20 for ; Fri, 31 May 2013 20:20:28 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id DDAA630007D for ; Sat, 1 Jun 2013 03:20:27 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id AF7BA300062; Fri, 31 May 2013 21:20:25 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Shane Amante In-Reply-To: <51A87174.3080204@globis.net> Date: Fri, 31 May 2013 21:20:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <708D821F-0EA0-44EE-AA5E-6321C7E73910@castlepoint.net> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri May 31 21:20:27 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 51a9687b42071774657738 X-DSPAM-Factors: 27, 2013+at, 0.40000, encoding+semantics, 0.40000, Mime-Version*Mail+6.3, 0.40000, SP+able, 0.40000, to+#+#+#+an, 0.40000, trusted+If, 0.40000, But+#+#+#+coming, 0.40000, I'd+like, 0.40000, and+#+#+#+the, 0.40000, incoming+packets, 0.40000, incoming+packets, 0.40000, prefixes+#+#+first, 0.40000, such+#+1, 0.40000, 3+#+#+Ray, 0.40000, somehow+#+#+#+prefixes, 0.40000, to+#+#+#+enforce, 0.40000, an+#+#+IP, 0.40000, encoding+#+#+#+address, 0.40000, May+31, 0.40000, But+#+#+people, 0.40000, such+schemes, 0.40000, trust+and, 0.40000, packets+with, 0.40000, 3+46, 0.40000, foremost+what, 0.40000, foremost+#+lack, 0.40000, be+#+If, 0.40000 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 03:20:35 -0000 Hi Sheng, Ray, On May 31, 2013, at 3:46 AM, Ray Hunter wrote: [--snip--] > But why are people coming up with these schemes for encoding semantics > in the address prefixes in the first place? That's what I'd like to > understand first and foremost: what lack of functionality is > motivating/forcing these people to adopt such schemes? +1. =20 In one part of the draft, Section 2.1, it appears to suggest that = packets coming in to the border of an SP boundary are "untrusted", = therefore existing packet header fields (e.g.: IPv6 TC) cannot be = trusted. If incoming packets are untrusted: - why doesn't the SP deploy unicast RPF to drop incoming packets with an = illegitimate source IP address/prefix? - more importantly, how is an SP able to _trust_ and somehow enforce = that the prefixes that it is handing out (dynamically via DHCP?) are = being properly assigned according the policies governing the mapping of = semantic prefix <-> user-type/application/security-domain/etc.? -shane= From brian.e.carpenter@gmail.com Fri May 31 21:07:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D185721F8904 for ; Fri, 31 May 2013 21:07:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYYluiEJ3iwO for ; Fri, 31 May 2013 21:07:10 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6756821F888F for ; Fri, 31 May 2013 21:07:10 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wy17so3148812pbc.23 for ; Fri, 31 May 2013 21:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DFrzJiMgXe1UOifA2wU6dPnH//7RxRuhtZ1PY7WD7So=; b=GavdpD3X6ZICX8IjTEjpR6Q2XO/INLFipIWk2/FNdXGjCBiM/HVft5+byIgVrwCRin GzYN9kO9gxtG5g+hWQqp5GI7gY2lqcm39jKuyD7L90Cru0htUkOpBdEgCLqE8VFl7yXL 4lhXEkVegO4Bk2cTBA42SrPxuy9J7A9n0KmTTlnOodhNqoKLD7vGG5oRouoV5O4TjUqi vJolJjtZlisJBPFj0B5AMkrAIsRUzi8eY6wUVSpGJLb7QuSL+BrTBB2FGW+nuHm9vW1x 3NtufWeKBU2YpASJ3SgiPQq32dQxGuShVmYC0iOlNVa69b5FhT5WIpbMvvVfn2eDAUg2 Wa7w== X-Received: by 10.66.232.69 with SMTP id tm5mr16387880pac.120.1370059629632; Fri, 31 May 2013 21:07:09 -0700 (PDT) Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id pl9sm31074253pbc.5.2013.05.31.21.07.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 21:07:08 -0700 (PDT) Message-ID: <51A97375.1090402@gmail.com> Date: Sat, 01 Jun 2013 16:07:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> In-Reply-To: <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:07:10 -0000 On 01/06/2013 14:44, Owen DeLong wrote: > On May 31, 2013, at 7:21 PM, Ted Lemon wrote: > >> On May 31, 2013, at 10:01 PM, Owen DeLong wrote: >>> How is having them leak in attempted TCP connections worse than having them leak in ICMP headers? It's still an invalid header. >> The ttl exceeded return packet doesn't expect a return packet of its own, so the fact that there's a "bogus" IP address on the header causes no harm, despite being technically wrong. Filtering the packet based on the source address, on the other hand, would cause harm. Nobody ever said life was going to be simple. > > The TTL Exceeded packet shouldn't get forwarded by any router as a result of the LL Source address. > > Thus it should never reach its destination. Agreed. But when it does get through, it does no particular harm (you just see a bizarre hop in the traceroute). If it got through in a SYN/ACK exchange, it would probably distress a user. > > Thus it will break traceroutes. > > Thus it is harmful. I'm not defending bad practice; just observing that it doesn't cause a disaster in traceroute. Brian From jeroen@massar.ch Fri May 31 21:31:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377B321F8746 for ; Fri, 31 May 2013 21:31:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIT6HcTvpHxw for ; Fri, 31 May 2013 21:31:27 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id A581721F86DC for ; Fri, 31 May 2013 21:31:26 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 1DEE7801C2BA; Sat, 1 Jun 2013 06:31:21 +0200 (CEST) Message-ID: <51A97918.9070404@massar.ch> Date: Fri, 31 May 2013 21:31:20 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> In-Reply-To: <51A97375.1090402@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:31:28 -0000 On 2013-05-31 21:07, Brian E Carpenter wrote: [..] > Agreed. But when it does get through, it does no particular > harm (you just see a bizarre hop in the traceroute). If it got > through in a SYN/ACK exchange, it would probably distress a user. If such a packet gets through it means BCP38 is not applied as things are not properly filtered. And likely thus one can spoof at one's hearts content and that does do lots of harm. Greets, Jeroen From owen@delong.com Fri May 31 21:38:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2094821F8E37 for ; Fri, 31 May 2013 21:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb5FyC1Jp98A for ; Fri, 31 May 2013 21:38:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D5BB921F8DE4 for ; Fri, 31 May 2013 21:38:19 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r514X4N1010836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 21:33:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r514X4N1010836 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370061231; bh=lqwY4li2TZ39Htb0Y4mJnZyWh1o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OjAtSDrsLGkZpDEfQ1/ZM1eedOsf9GNCs1g4+QGbbzPbb/DLabGFVU9pDrBFcNyTY +q6H6OKzpJfsILBNC9USSwG/7qwfGTj8D059N6IX9wSatDziJfWJMl15AERoS4y9/j OlpL2hjErBJGu6kEXOq/jU64ncsJv6Ktfx10LsbA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <51A97918.9070404@massar.ch> Date: Fri, 31 May 2013 21:33:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 21:33:51 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:38:22 -0000 On May 31, 2013, at 9:31 PM, Jeroen Massar wrote: > On 2013-05-31 21:07, Brian E Carpenter wrote: > [..] >> Agreed. But when it does get through, it does no particular >> harm (you just see a bizarre hop in the traceroute). If it got >> through in a SYN/ACK exchange, it would probably distress a user. >=20 > If such a packet gets through it means BCP38 is not applied as things > are not properly filtered. >=20 This has nothing to do with BCP38. Any router which forwards a packet containing a link local address in = the header is broken regardless of any BCP38 configuration. Owen From owen@delong.com Fri May 31 21:38:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8A21F8E8F for ; Fri, 31 May 2013 21:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml9hdS-FjFCX for ; Fri, 31 May 2013 21:38:36 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEE821F8E8C for ; Fri, 31 May 2013 21:38:35 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r514X4N0010836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 21:33:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r514X4N0010836 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370061191; bh=E/FFYp38Wt+YkUKCDUZloeNp24A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QvCp3JcE94oMt/onyJbF3qbZSkXKHXtY0bsBmMLdJxJwie7Jur8KJxW4TMdUxe6vT iLgmCu25fxBIE++9yivtM4c/0tYovyeYgP4SZvBNcTcgbit1JKhSaY7u+8ElOML5Kc AwjIW+uzzjrh8g/Nw5uM2EEzlrx3gdFymhLTLOcY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Owen DeLong In-Reply-To: <51A97375.1090402@gmail.com> Date: Fri, 31 May 2013 21:33:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33795D9E-6174-4373-9506-0D62ED9013D0@delong.com> References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 May 2013 21:33:11 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:38:37 -0000 On May 31, 2013, at 9:07 PM, Brian E Carpenter = wrote: > On 01/06/2013 14:44, Owen DeLong wrote: >> On May 31, 2013, at 7:21 PM, Ted Lemon wrote: >>=20 >>> On May 31, 2013, at 10:01 PM, Owen DeLong wrote: >>>> How is having them leak in attempted TCP connections worse than = having them leak in ICMP headers? It's still an invalid header. >>> The ttl exceeded return packet doesn't expect a return packet of its = own, so the fact that there's a "bogus" IP address on the header causes = no harm, despite being technically wrong. Filtering the packet based = on the source address, on the other hand, would cause harm. Nobody = ever said life was going to be simple. >>=20 >> The TTL Exceeded packet shouldn't get forwarded by any router as a = result of the LL Source address. >>=20 >> Thus it should never reach its destination. >=20 > Agreed. But when it does get through, it does no particular > harm (you just see a bizarre hop in the traceroute). If it got > through in a SYN/ACK exchange, it would probably distress a user. >=20 If it gets through, then it is an indication that every router between = the one that sourced the packet and the recipient host is broken. True, the packet itself is "mostly harmless", but=85 >>=20 >> Thus it will break traceroutes. >>=20 >> Thus it is harmful. >=20 > I'm not defending bad practice; just observing that it doesn't > cause a disaster in trace route. And I'm saying that if any of the routers between the LL-packet = generating router and the recipient are working correctly, it does, in = fact, break traceroute. Owen From jeroen@massar.ch Fri May 31 21:50:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E3121F86F4 for ; Fri, 31 May 2013 21:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Prl7CaPSmCi for ; Fri, 31 May 2013 21:50:44 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 184DE21F8657 for ; Fri, 31 May 2013 21:50:42 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 37381801C2BA; Sat, 1 Jun 2013 06:50:37 +0200 (CEST) Message-ID: <51A97D9D.5010003@massar.ch> Date: Fri, 31 May 2013 21:50:37 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> In-Reply-To: <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:50:58 -0000 On 2013-05-31 21:33, Owen DeLong wrote: > > On May 31, 2013, at 9:31 PM, Jeroen Massar wrote: > >> On 2013-05-31 21:07, Brian E Carpenter wrote: [..] >>> Agreed. But when it does get through, it does no particular harm >>> (you just see a bizarre hop in the traceroute). If it got through >>> in a SYN/ACK exchange, it would probably distress a user. >> >> If such a packet gets through it means BCP38 is not applied as >> things are not properly filtered. >> > > This has nothing to do with BCP38. I would say it has everything to do with it actually ;) Especially as it covers checking ALL traffic being forwarded and doing a simple source check on them. > Any router which forwards a packet containing a link local address in > the header is broken regardless of any BCP38 configuration. And BCP38 (Section 3, please read it, it is really informative ;) is inclusive of those requirements. Of course do also take into account BCP84 which details things a lot more. Note that you have a fe80::/10 on every single interface, thus receiving such packets from another box and trying to forward it to another interface is just not right as it would fail uRPF do it being present on multiple interfaces. Greets, Jeroen From owen@delong.com Fri May 31 23:08:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026F621F89D5 for ; Fri, 31 May 2013 23:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZDjmGRGIQx8 for ; Fri, 31 May 2013 23:08:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE9121F8749 for ; Fri, 31 May 2013 23:08:01 -0700 (PDT) Received: from [IPv6:2600:100c:b210:87e6:1983:16db:e387:be5f] ([IPv6:2600:100c:b210:87e6:1983:16db:e387:be5f]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r5165fck012577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 23:05:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r5165fck012577 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370066746; bh=6h79qxyzCphUhatqOXMDIfybpxU=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=uDeElYcZDQF2eI6FbYndSWdG/ZpoTfupKoGtJ4brT7rA2p5l2ZpZSVG63YC1pnqAp zrIi89fuYsUFzsQ2TC9DFwiY6AD1UFJ/MfRrAf9OS6HVduW7AErSCld1PpNlIqCcYd 4fNe0/sqCiMmr+VMO3CaOVfdFrR8KNKAPVbyeHpg= References: <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> <51A97D9D.5010003@massar.ch> Mime-Version: 1.0 (1.0) In-Reply-To: <51A97D9D.5010003@massar.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Owen DeLong Date: Sat, 1 Jun 2013 01:05:39 -0500 To: Jeroen Massar X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 31 May 2013 23:05:46 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] A good example of why we need to careful about ULAs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 06:08:03 -0000 My point is that link local packets shouldn't even get far enough for BCP38 t= o matter. Every router is required to not forward then no matter what. If th= e packet gets far enough into the forwarding process for your BCP38 filters t= o matter, then you need a software update for the router.=20 Owen On May 31, 2013, at 23:50, Jeroen Massar wrote: > On 2013-05-31 21:33, Owen DeLong wrote: >>=20 >> On May 31, 2013, at 9:31 PM, Jeroen Massar wrote: >>=20 >>> On 2013-05-31 21:07, Brian E Carpenter wrote: [..] >>>> Agreed. But when it does get through, it does no particular harm >>>> (you just see a bizarre hop in the traceroute). If it got through >>>> in a SYN/ACK exchange, it would probably distress a user. >>>=20 >>> If such a packet gets through it means BCP38 is not applied as >>> things are not properly filtered. >>>=20 >>=20 >> This has nothing to do with BCP38. >=20 > I would say it has everything to do with it actually ;) >=20 > Especially as it covers checking ALL traffic being forwarded and doing a > simple source check on them. >=20 >> Any router which forwards a packet containing a link local address in >> the header is broken regardless of any BCP38 configuration. >=20 > And BCP38 (Section 3, please read it, it is really informative ;) is > inclusive of those requirements. Of course do also take into account > BCP84 which details things a lot more. >=20 > Note that you have a fe80::/10 on every single interface, thus receiving > such packets from another box and trying to forward it to another > interface is just not right as it would fail uRPF do it being present on > multiple interfaces. >=20 > Greets, > Jeroen