From martin.hunek@tul.cz Sun Nov 12 07:32:19 2023 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 05EBBC17C538 for ; Sun, 12 Nov 2023 07:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.108 X-Spam-Level: X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tul.cz Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssQ6mDWpsA_n for ; Sun, 12 Nov 2023 07:32:14 -0800 (PST) Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFF9C17C53A for ; Sun, 12 Nov 2023 07:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at tul.cz Received: from asclepius.adm.tul.cz (unknown [147.230.238.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 6D13018050A1A; Sun, 12 Nov 2023 16:32:07 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz 6D13018050A1A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1699803128; bh=FLI6IDCe9ypvtcvnZ5wrc8Ihlrr6BAh3FRlmYsPRJIg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OdfDDxYuJUlWKgSre+FnsRVvd0OZsc0T4tw47afKcPwuYfDNXPDsEnx2PQmxU+xbN F3VktqMMI1bV+PilHkXYNnKHBRK48M1x5EjLwIS70zpn1bVVLu29RMqdyw14PWsWbA eECJoIWwvTm/XvH1j6ANJ+yzRqd8DfoD7tIULmYsy42u57myHOnGakB+jIpqy9pITs CxFf/x3Hwc+ttXbaCtDBpfkww/3GjgLAAwIE6WfSZ2hk5IBauxTTnQCBm/glZOZKGm SuED0fkcQDRLYRdJhzleUeQAWrfZaflgJAUVkTX0Ld2cVd5enkugUTlN790wlWJCn4 pxt0Iziyc76ag== From: Martin =?utf-8?B?SHVuxJtr?= To: V6 Ops List Date: Sun, 12 Nov 2023 16:32:00 +0100 Message-ID: <4350734.1mFrItZxnq@asclepius.adm.tul.cz> Organization: =?UTF-8?B?VGVjaG5pY2vDoQ==?= univerzita v Liberci In-Reply-To: References: <169919966581.36738.5162400304409089286@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2336199.1XnueRTxXe"; micalg="sha384"; protocol="application/pkcs7-signature" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2023 15:32:19 -0000 --nextPart2336199.1XnueRTxXe Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi folks, After meeting the authors, the WG chair, and the document Shepard, I would = like to express my current stance concerning this draft. =46irst of all, I would like to say thank you all for a long, in-depth, but= friendly discussion. Personally, I see those Pros: =2D It solves problems caused by devices having too many addresses (like vi= rtualization with separate L3 segment with ND proxy or specifically Google = ChromeOS devices having 20+ addresses) =2D When addresses are grouped into a single prefix, they are easier to tra= ck by the network operator =2D The client/host is able to use as many addresses in the single prefix a= s it wants without the side effects on the rest of the network =2D When the used addresses are registered, I could allow to maintain AAAA = records for services behind the device (additional draft/RFC in the process) Risks for the network operators: 1) The loss of the ability to differentiate between Routers extending the n= etwork outside of the device itself (currently using DHCPv6-PD) and hosts 2) The ability of network extension outside a single device might be unwant= ed in enterprise-style networks and may introduce security risks for them o= r the risk of not complying with the local laws/regulations 3) With PIO flags set to A=3D1, L=3D1, and P=3D1: As it is currently writte= n, it increases the load on routers in case of peer-to-peer communication. = The L flag is de facto ignored by PD clients as they are not locally reacha= ble when not using SLAAC. To maintain local reachability, the operator need= s to set 2 prefixes (one for SLAAC: A=3D1, L=3D1, P=3D0; the second virtual= with A=3Dx, L=3Dx, P=3D1 where x is preferably 0 but would work with 1 too= ). 4) As the proposed method is not usable for every network, it MUST NOT be v= iewed as a replacement of the SLAAC (I've been told that it is not the case= by authors and WG chair - so no problem) Cons: 1) The requirement of SLAAC ability (/64 per device) is unnecessary and mak= es this method unusable for the address-space constraint networks 2) Address plans of the early adopters had to be changed 3) It causes pressure on network operators to provide additional address sp= ace while simple network space extension doesn't have to be possible. This = produces additional pressure on LIRs and could also lead to RIRs policy cha= nges 4) The P flag draft should be the Normative reference There is no need for the requirement in section 7, 2nd point. Some implemen= tations may not depend on internal SLAAC use. They can use proprietary algo= rithms to generate addresses with shorter IID or the DHCPv6 IA_NA. For such= devices, it is OK to ask for less than /64 currently needed for SLAAC auto= configuration. If the client asks for less than /64, there is no point for = the server to MUST give at least SLAAC usable prefix. It should be able to = provide what the client asked for, while it can provide more. That is why I= can see the Con 1). There is no harm in the client indicating that it needs less than/64 and fo= r the server to honor such a request. Such signaling is possible by the "pr= efix-length hint" field. However, I see the reasoning why the network SHOULD expect that the prefix = requested by the client will be /64 as there probably will be the majority = of the devices asking for the /64. Con 2) is a minor problem, but it could cause additional work for early ado= pters and could be seen as a sign of the immaturity of IPv6 addressing phil= osophy. The con 3) is the situation I'm currently facing as the network administrat= or of the university network, having just /48. It is specific to some netwo= rks, so I'm just stating that it could be a problem for some networks. The Con 4): One thing I've just realized is that the draft in 6man (pio-pfl= ag) is not a normative reference. However, this seems an integral part of t= he method as it describes both client behaviour and network signalling. As = the 6man draft has a direct effect on how this draft behaves, it should pro= bably be published together with the draft in 6man with a proper normative = cross-reference. The major risks I can see with the draft are the numbers 1 and 2. While I, = as the "enterprise-style" network administrator, would be OK with the clien= t asking for a prefix to run containers or VMs, I would not want to give a = prefix to a Wi-Fi router extending my network (possibly without required se= curity). Not to mention other adverse effects that unmanaged Wi-Fi routers = have on the spectrum and so on. I think that this concern must be solved, b= ut not necessary here in this document. I know that I cannot guarantee this= in IPv4, but this document doesn't talk about IPv4. IPv6 could solve the i= ssues that IPv4 does not. As I've been told that this is not here to replace SLAAC in the future for = those networks that could not use this, I'm less worried about this draft. = Apart from the unnecessary MUST in section 7 and missing signalling of the = client's intent to extend the network to an external interface, I'm reasona= bly fine with it. However, without that missing signalling (and getting mor= e address space from my upstream), I don't see the possibility of using it = in my network now. Once again, thank you all for your time and informative discussion. Regards, Martin Dne ned=C4=9Ble 5. listopadu 2023 17:17:13 CET, Jen Linkova napsal(a): > Hello, >=20 > Following the conclusion of the WGLC (thanks to everyone who > commented!), we've submitted a -05 version with the following changes: > 1. Making it more clear that the draft requires the network to > delegate a SLAAC-suitable prefix, and /64 is currently required for > SLAAC to work - but it doesn't have to be like that in the future. > Examples also use /64. Brian, does it address your comment? > 2. To address most of Ole's comments: > 2.1 Making it explicit that the draft only covers the network > behavior, while host requirements are out of scope. > 2.2 Clarifying that the network can support both flat and > hierarchical models - it's up to the host to specify the hint. > 3. Rewriting examples in the prefix length consideration section to > make it clearer that the proposal does not require an excessive amount > of IPv6 space. >=20 >=20 >=20 > On Sun, Nov 5, 2023 at 4:54=E2=80=AFPM wrote: > > > > A new version of Internet-Draft draft-ietf-v6ops-dhcp-pd-per-device-05.= txt has > > been successfully submitted by Jen Linkova and posted to the > > IETF repository. > > > > Name: draft-ietf-v6ops-dhcp-pd-per-device > > Revision: 05 > > Title: Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in = Large Broadcast Networks > > Date: 2023-11-05 > > Group: v6ops > > Pages: 20 > > URL: https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-= device-05.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per= =2Ddevice/ > > HTML: https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-= device-05.html > > HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-p= d-per-device > > Diff: https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-v6ops-= dhcp-pd-per-device-05 > > > > Abstract: > > > > This document discusses an IPv6 deployment scenario when individual > > clients connected to large broadcast networks (such as enterprise > > networks or public Wi-Fi networks) are allocated unique prefixes via > > DHCPv6 Prefix Delegation (DHCPv6-PD). > > > > > > > > The IETF Secretariat > > > > >=20 >=20 >=20 --nextPart2336199.1XnueRTxXe Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgIFADCABgkqhkiG9w0BBwEAAKCCEsIw ggWBMIIEaaADAgECAhA5ckQ6+SK3UdfTbBDdMTWVMA0GCSqGSIb3DQEBDAUAMHsxCzAJBgNVBAYT AkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNV BAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMw HhcNMTkwMzEyMDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgT Ck5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCAEmUXNg7D2wiz0KxXDXbtzSfTTK1Qg2Hi qiBNCS1kCdzOiZ/MPans9s/B3PHTsdZ7NygRK0faOca8Ohm0X6a9fZ2jY0K2dvKpOyuR+OJv0OwW IJAJPuLodMkYtJHUYmTbf6MG8YgYapAiPLz+E/CHFHv25B+O1ORRxhFnRghRy4YUVD+8M/5+bJz/ Fp0YvVGONaanZshyZ9shZrHUm3gDwFA66Mzw3LyeTP6vBZY1H1dat//O+T23LLb2VN3I5xI6Ta5M irdcmrS3ID3KfyI0rn47aGYBROcBTkZTmzNg95S+UzeQc0PzMsNT79uq/nROacdrjGCT3sTHDN/h Mq7MkztReJVni+49Vv4M0GkPGw/zJSZrM233bkf6c0Plfg6lZrEpfDKEY1WJxA3Bk1QwGROs0303 p+tdOmw1XNtB1xLaqUkL39iAigmTYo61Zs8liM2EuLE/pDkP2QKe6xJMlXzzawWpXhaDzLhn4ugT ncxbgtNMs+1b/97lc6wjOy0AvzVVdAlJ2ElYGn+SNuZRkg7zJn0cTRe8yexDJtC/QV9AqURE9Jnn V4eeUB9XVKg+/XRjL7FQZQnmWEIuQxpMtPAlR1n6BB6T1CZGSlCBst6+eLf8ZxXhyVeEHg9j1uli utZfVS7qXMYoCAQlObgOK6nyTJccBz8NUvXt7y+CDwIDAQABo4HyMIHvMB8GA1UdIwQYMBaAFKAR CiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBRTeb9aqitKz1SA4dibwJ3ysgNmyzAOBgNVHQ8B Af8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggEBABiHUdx0IT2ciuAntzPQLszs8ObLXhHeIm+bdY6ecv7k1v6qH5yWLe8D Sn6u9I1vcjxDO8A/67jfXKqpxq7y/Njuo3tD9oY2fBTgzfT3P/7euLSK8JGW/v1DZH79zNIBoX19 +BkZyUIrE79Yi7qkomYEdoiRTgyJFM6iTckys7roFBq8cfFb8EELmAAKIgMQ5Qyx+c2SNxntO/Hk Orb5RRMmda+7qu8/e3c70sQCkT0ZANMXXDnbP3sYDUXNk4WWL13fWRZPP1G91UUYP+1KjugGYXQj FrUNUHMnREd/EF2JKmuFMRTE6KlqTIC8anjPuH+OdnKZDJ3+15EIFqGjX5UwggbmMIIEzqADAgEC AhAxAnDUNb6bJJr4VtDh4oVJMA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UE CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJV U1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0yMDAyMTgwMDAwMDBaFw0zMzA1MDEyMzU5NTlaMEYxCzAJBgNVBAYTAk5MMRkwFwYDVQQK ExBHRUFOVCBWZXJlbmlnaW5nMRwwGgYDVQQDExNHRUFOVCBQZXJzb25hbCBDQSA0MIICIjANBgkq hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAs0riIl4nW+kEWxQENTIgFK600jFAxs1QwB6hRMqvnkph fy2Q3mKbM2otpELKlgE8/3AQPYBo7p7yeORuPMnAuA+oMGRb2wbeSaLcZbpwXgfCvnKxmq97/kQk OFX706F9O7/h0yehHhDjUdyMyT0zMs4AMBDRrAFn/b2vR3j0BSYgoQs16oSqadM3p+d0vvH/YrRM tOhkvGpLuzL8m+LTAQWvQJ92NwCyKiHspoP4mLPJvVpEpDMnpDbRUQdftSpZzVKTNORvPrGPRLnJ 0EEVCHR82LL6oz915WkrgeCY9ImuulBn4uVsd9ZpubCgM/EXvVBlViKqusChSsZEn7juIsGIiDya IhhLsd3amm8BS3bgK6AxdSMROND6hiHT182Lmf8C+gRHxQG9McvG35uUvRu8v7bPZiJRaT7ZC2f5 0P4lTlnbLvWpXv5yv7hheO8bMXltiyLweLB+VNvg+GnfL6TW3Aq1yF1yrZAZzR4MbpjTWdEdSLKv z8+0wCwscQ81nbDOwDt9vyZ+0eJXbRkWZiqScnwAg5/B1NUD4TrYlrI4n6zFp2pyYUOiuzP+as/A Znz63GvjFK69WODR2W/TK4D7VikEMhg18vhuRf4hxnWZOy0vhfDR/g3aJbdsGac+diahjEwzyB+U KJOCyzvecG8bZ/u/U8PsEMZg07iIPi8CAwEAAaOCAYswggGHMB8GA1UdIwQYMBaAFFN5v1qqK0rP VIDh2JvAnfKyA2bLMB0GA1UdDgQWBBRpAKHHIVj44MUbILAK3adRvxPZ5DAOBgNVHQ8BAf8EBAMC AYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwOAYD VR0gBDEwLzAtBgRVHSAAMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6 Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcw AYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEACgVOew2PHxM5 AP1v7GLGw+3tF6rjAcx43D9Hl110Q+BABABglkrPkES/VyMZsfuds8fcDGvGE3o5UfjSno4sij0x dKut8zMazv8/4VMKPCA3EUS0tDUoL01ugDdqwlyXuYizeXyH2ICAQfXMtS+raz7mf741CZvO50Ox MUMxqljeRfVPDJQJNHOYi2pxuxgjKDYx4hdZ9G2o+oLlHhu5+anMDkE8g0tffjRKn8I1D1BmrDdW R/IdbBOj6870abYvqys1qYlPotv5N5dm+XxQ8vlrvY7+kfQaAYeO3rP1DM8BGdpEqyFVa+I0rpJP haZkeWW7cImDQFerHW9bKzBrCC815a3WrEhNpxh72ZJZNs1HYJ+29NTB6uu4NJjaMxpk+g2puNSm 4b9uVjBbPO9V6sFSG+IBqE9ckX/1XjzJtY8Grqoo4SiRb6zcHhp3mxj3oqWi8SKNohAOKnUc7RIP 6ss1hqIFyv0xXZor4N9tnzD0Fo0JDIURjDPEgo5WTdti/MdGTmKFQNqxyZuT9uSI2Xvhz8p+4pCY kiZqpahZlHqMFxdw9XRZQgrP+cgtOkWEaiNkRBbvtvLdp7MCL2OsQhQEdEbUvDM9slzZXdI7NjJo kVBq3O4pls3VD2z3L/bHVBe0rBERjyM2C/HSIh84rfmAqBgklzIOqXhd+4RzadUwggZPMIIEN6AD AgECAhAFbGuYX3OQeAjRPkNMDO6QMA0GCSqGSIb3DQEBDAUAMEYxCzAJBgNVBAYTAk5MMRkwFwYD VQQKExBHRUFOVCBWZXJlbmlnaW5nMRwwGgYDVQQDExNHRUFOVCBQZXJzb25hbCBDQSA0MB4XDTIx MDExOTAwMDAwMFoXDTI0MDExOTIzNTk1OVowgdwxDjAMBgNVBBETBTQ2MDAxMSgwJgYDVQQKDB9U ZWNobmlja8OhIHVuaXZlcnppdGEgdiBMaWJlcmNpMRswGQYDVQQJDBJTdHVkZW50c2vDoSAxNDAy LzIxGDAWBgNVBAgMD0xpYmVyZWNrw70ga3JhajEgMB4GA1UEBwwXTGliZXJlYyBJLVN0YXLDqSBN xJtzdG8xCzAJBgNVBAYTAkNaMRYwFAYDVQQDDA1NYXJ0aW4gSHVuxJtrMSIwIAYJKoZIhvcNAQkB FhNtYXJ0aW4uaHVuZWtAdHVsLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjhbT mclrkAIpQE+39nyeNM6UmcFXjt60yBT80gqMWoHe3Xic5okADbuw7zMc/d8YTky//MI/fDyjrVpZ yP7+Sq1pqsmYZ8OIRquo3lmQmPGAmlVdw+d6PC3fSE7gnESG4dl+nm+X0PnOtZ6GVTENWldQdOqS RhekqAsrvzQSsc1LCafqDQ6ys9MQ/ILyoPf8w+30J86EjfNo7t/fqQogX5RPdW4Gs6OCw3o7jyFw vLVeUFJ64Wpq0JsOgUBh9XxkJvlKEzvgPmKTh6aKHIV+C2myMZ+CNfX1TG0BloGIlVYD/R0LYfbJ ivxiI95U4h90f74rey6GdhZJINuzm4O9AwIDAQABo4IBoDCCAZwwHwYDVR0jBBgwFoAUaQChxyFY +ODFGyCwCt2nUb8T2eQwHQYDVR0OBBYEFF2e6zweGd9IWrEy0ZpCpVK3Rr31MA4GA1UdDwEB/wQE AwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjA/BgNVHSAE ODA2MDQGCysGAQQBsjEBAgJPMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BT MEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9HRUFOVC5jcmwuc2VjdGlnby5jb20vR0VBTlRQZXJz b25hbENBNC5jcmwweAYIKwYBBQUHAQEEbDBqMD0GCCsGAQUFBzAChjFodHRwOi8vR0VBTlQuY3J0 LnNlY3RpZ28uY29tL0dFQU5UUGVyc29uYWxDQTQuY3J0MCkGCCsGAQUFBzABhh1odHRwOi8vR0VB TlQub2NzcC5zZWN0aWdvLmNvbTAeBgNVHREEFzAVgRNtYXJ0aW4uaHVuZWtAdHVsLmN6MA0GCSqG SIb3DQEBDAUAA4ICAQCyzO/xKtpvZIoWT/Ova0kwOV4Bq9R7LplFlIgleG7QS/KRC6bT0WJY3Ddz j1gQOddJPtyQRhFa5DBlgJtI9V8EwNplt1qbZvGjxxpfIJEN2IeK0NJlHQfVFrYNGuVxCeW7AYj2 ZC2oHmVL87aUcu7w1Iz2mXUv5q8jHfGiyi+jABT/YrVWi53UpUgacVb/CiXB1YPDUhj4YF9Wk5Su Acr5rdkBtKT2triaPZvcLLzrKZJpnKBnvrT74EMC8GFlU/PtpeSEb/sox83Whk453PLH9K780Po4 eroWtYhh5Z++lTlKz3j1NVSX42T9VbN18oybtyyX3SpnTcwAS+1Ah/s0gqufQlsIDHI9yyuyf7tg rOvHpPpMYzHHKq4seWJ9Y6g/j9ELwN44ZD+xVkZb8bTpDYjnPftavcTFPVrAJGZg/aiyA65PNwIi YPrAcAD9mNIsehAltkpuk9dcmY2+qh/ob67Wkvd74WIR4HVxjxJBHS4xFyVExCgsm4wqKLtf+vnU /YxprlCFSIbFfq30U57g/hT+auljBkFcnWFzOVPyE6b+mSS6kfCT3hCosflPoeHuQ2wTpJFInAs1 KZuTOf0CwOeV0DdsVdZizovitUthm+ULluKNi/r0AWRUmk2hynMzjYREShVF4H0wB50efzP9O5/w BGtpBCQOUjcQYmH4xTGCAjgwggI0AgEBMFowRjELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdFQU5U IFZlcmVuaWdpbmcxHDAaBgNVBAMTE0dFQU5UIFBlcnNvbmFsIENBIDQCEAVsa5hfc5B4CNE+Q0wM 7pAwDQYJYIZIAWUDBAICBQCggbAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjMxMTEyMTUzMjAwWjA1BgkqhkiG9w0BCQ8xKDAmMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwPwYJKoZIhvcNAQkEMTIEMJRPblcqYX6E2tlwO/boHLMhdwH9psXX MgBAatbnZudDw3kArM8+KT4uo16nb3R9+zANBgkqhkiG9w0BAQEFAASCAQCAvwj3JDBvBbrwd9KE scYtz8iexCcYygLoQlFFFOU5iKAhUzYm2oEUizYeL5uxPspJZa65nxmqnjMOsF0yKrLNbRl9mM4n pWbaw8JxUQif8S6q7RBdVjci2fz9T0KkATEOdTarCZ6QUdTcgquz3E794SkMPg51af3Dsu0eiQpF NZRcftokmR2eofW6HNA27dxPjQ12hfrJRAeyfOM+cIFJjFstnT0SOz/Ot7lWvUSxoIhXBdLg374r kP5gQDp5zO+sD5dnsSOSWipbO2ZXBzoWSCV6nPH2dtrymCLTLlbmlWWAwHfac6wrrtR6zaacb6+7 O4M9Wq6a5Ydr1OkKASb9AAAAAAAA --nextPart2336199.1XnueRTxXe--