From nobody Wed Jul 1 14:12:59 2020 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 255173A0D9F for ; Wed, 1 Jul 2020 14:12:56 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_omltASeiei for ; Wed, 1 Jul 2020 14:12:54 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 80F9B3A0D9E for ; Wed, 1 Jul 2020 14:12:54 -0700 (PDT) Received: from [IPv6:2620:0:930::5] ([IPv6:2620:0:930:0:0:0:0:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 061LC5jZ2603666 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 1 Jul 2020 14:12:54 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 061LC5jZ2603666 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1593637974; bh=t5qyULwhF7BqRctQoHQZd1RkGxZEhWW7bho/wNBJJOw=; h=From:Subject:Date:To:From; b=umy2XACRk6Clccp8UhLwhKXAncJbLrRoTNr3U4qbeogMnUsXLn3i0zSsjmMWu2FzU b5PdUbYX59aYtJbKmxhOo677Pi1RvpXQM/aPnPV8InKpn6SuR6tVSNviVc7T6+uQzL pa21vv8K4lBere4itbSj4rnjRJ3HzEPHcSKSkYjc= From: Owen DeLong Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 1 Jul 2020 14:12:53 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 01 Jul 2020 14:12:54 -0700 (PDT) Archived-At: Subject: [v6ops] Document Shepherd Writeup for draft-ietf-v6ops-cpe-slaac-renum-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 21:12:57 -0000 This has been submitted to the AD and the IESG: (1) This draft is aimed at being an Informational RFC is the appropriate = type because it provides clarifying information and suggested behaviors to = address issues experienced in existing implementations. (2) IESG Approval Announcement Technical Summary: This document sets forth recommendations intended to improve CPE default = behavior on IPv6 networks. Specifically, it aims to clarify certain timer interactions on dynamic = prefixes and improve behavior in scenarios where network configuration information becomes invalid = without explicit signaling of that condition. Document Quality: The document so far has been approved by the V6OPS working group = (successful working group last call). The document does not specify new protocol, but rather = changes to the default parameters in existing protocols. Personnel Owen DeLong is the Document Shepherd Fred Baker and Ron Bonica are the WG chairs Warren Kumari is the responsible AD. (3) Shepherd=E2=80=99s review Prior to becoming shepherd, I was significantly involved in reviewing = each revision of the document and provided feedback and contributed improvements at each step. I have = been active in the debate of this I-D on the working group mailing list. This version of = the document is ready for publication. While there remains one dissenter in the working group, the = working group has reached consensus. His concerns are a particular corner case where = DHCPv6 is being used to distribute effectively static addresses. (4) Shepherd=E2=80=99s concerns I have no concerns about the depth or breadth of the reviews that have = been performed. Through the three revisions, the document has received substantial = comments from the working group and significantly improved with each revision as a result. Author = has been very responsive and incorporated feedback very well.=20 (5) Special Reviews Needed I do not believe any special reviews are necessary for this document. = The HOMENET working group may wish to review this document as the proposed change in = default behavior could affect their work, but we believe the proposals here would be = beneficial in such an environment. (6) Shepherd=E2=80=99s Concerns or issues I have no concerns or issues with the document in its current form. (7) IPR disclosures There are no relevant IPR disclosures in this document. The document = does not touch on any technologies other than those in existing RFCs developed within the = IETF. (8) IPRs referencing this document No IPR disclosures have been filed referencing this document and for the = reasons stated in the previous section, it is very unlikely one would be filed. (9) WG consensus strength This document had good participation and discussion in the working group = and received fairly broad support both prior to and during WG last call. (10) Dissent There remains one dissenter, but I would not characterize his discontent = as extreme, nor has he threatened appeal. His concern relates to a corner case where DHCP is = being used by an ISP to distribute (through DHCPv6-PD) a static prefix address which does = not change. He is concerned that the proposed default behavior here could either increase = his configuration complexity or result in an unnecessary local outage in the event that he = loses connectivity to his service provider. Multiple alternative solutions were suggested = to him on the mailing list. Since this document specifies only default behavior and does not = preclude vendors from providing knobs to alter that behavior, I believe his objection was = more than adequately addressed. (11) ID nits No nits found (once I got past the fact that the NITS interface via URL = doesn=E2=80=99t cope well with this draft for reasons beyond me). Feeding it the raw text worked = fine. From nobody Fri Jul 3 14:22:36 2020 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 3F10C3A02C1 for ; Fri, 3 Jul 2020 14:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PutXwV9lFJV for ; Fri, 3 Jul 2020 14:22:31 -0700 (PDT) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C712E3A0112 for ; Fri, 3 Jul 2020 14:22:31 -0700 (PDT) Received: from rva2rmd102.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda10.webex.com (Postfix) with ESMTP id 69BA63009396 for ; Fri, 3 Jul 2020 21:22:31 +0000 (GMT) Received: from rva2rmd102.webex.com (localhost [127.0.0.1]) by rva2rmd102.webex.com (Postfix) with ESMTP id 0F7F4100D9A8 for ; Fri, 3 Jul 2020 21:22:31 +0000 (GMT) Date: Fri, 3 Jul 2020 21:22:31 +0000 (GMT) From: V6OPS Working Group Reply-To: v6ops-chairs@ietf.org To: v6ops@ietf.org Message-ID: <442114615.2043311593811351062.JavaMail.nobody@rva2rmd102.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_408656_740508543.1593811351062" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=165782540274118175, X-WBX-TID=2f3obd6m5ymjey7p7pvx2pe84to4b3aeb1lgiojikqo1t66wmcjavlmc, X-WBX-RID=653402066f7b4cf9b3e930ada260d605, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Fri Jul 03 21:22:31 GMT 2020 reminder-40.6.2-3143 Archived-At: Subject: [v6ops] Webex meeting invitation: IPv6 Operations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 21:22:33 -0000 ------=_Part_408656_740508543.1593811351062 Content-Type: multipart/Alternative; boundary="----=_Part_408657_1933625064.1593811351062" ------=_Part_408657_1933625064.1593811351062 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCB2Nm9wc0BpZXRmLm9yZywKClY2T1BTIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8g am9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuCgoKSVB2NiBPcGVyYXRpb25zClRodXJzZGF5LCBKdWx5 IDE2LCAyMDIwCjc6MDAgYW0gIHwgIChVVEMtMDc6MDApIFBhY2lmaWMgVGltZSAoVVMgJiBDYW5h ZGEpICB8ICAyIGhycwpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAxNjEgMDU3IDIzMDMg Ck1lZXRpbmcgcGFzc3dvcmQ6IHE1NHRSVndLOE11CgoKCldoZW4gaXQncyB0aW1lLCBqb2luIHRo ZSBtZWV0aW5nLgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYjgyYjcy NzIxYTA3Y2Y0MDk2NmE4YWI2YmZjNDdlY2IKCkFkZCB0byBDYWxlbmRhcgpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNzViOGEwOWY0ZGU4YzVjOWE0NTYzMzliMmJjMTBi NjENCg0KCgoNCkpPSU4gQlkgUEhPTkUNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkKVGFwIGhlcmUgdG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0 cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTYxMDU3MjMwMyUy MyUyMyowMSoKDQpHbG9iYWwgY2FsbC1pbiBudW1iZXJzDQpodHRwczovL2lldGYud2ViZXguY29t L2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW0zZDU5YzNiMWIyYmNkMzU3NTkxMjY3ZDVmMmMw OGQ2Yg0KDQoKSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OCkRpYWwgc2lw OjE2MTA1NzIzMDNAaWV0Zi53ZWJleC5jb20KWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLgoKCkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5 bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzcwpEaWFsIHNpcDoxNjEwNTcyMzAzLmll dGZAbHluYy53ZWJleC5jb20KCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwpodHRwczovL2NvbGxh Ym9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NQoKCklNUE9SVEFOVCBO T1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBh bmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3Jk ZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5p bmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3Jk aW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlv dXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4K ------=_Part_408657_1933625064.1593811351062 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAgICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7 fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVy OiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0 ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50 aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmltYWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lk dGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDogNjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBz Y3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNp emU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdlIHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAl ICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3 aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0K PC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxl PSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJn Y29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmct bGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFp biI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7 CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJsZT4tLT4KCgo8dGFibGU+CiAgICAgICA8dHI+ CiAgICAgICAgICAgPHRkIHN0eWxlPSJoZWlnaHQ6IDIycHg7Y29sb3I6ICMwMDAwMDA7Zm9udC1m YW1pbHk6IEFyaWFsOwlmb250LXNpemU6IDE2cHg7Zm9udC13ZWlnaHQ6IGJvbGQ7bGluZS1oZWln aHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgIFY2T1BTIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5 b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuCiAgICAgICAgICAgICAgICAJICAgICAgICAg ICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+CgogICAgPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudDsi PgogICAgICAgIDx0cj4KICAgICAgICAgICAgPHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+CiAg ICAgICAgICAgICAgICBNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAxNjEgMDU3IDIzMDMK ICAgICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgIDx0YWJsZSBz dHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgogICAgICAgIDx0ciA+CiAg ICAgICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogIzAwMDAwMDsg Zm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJweDsiPk1lZXRpbmcgcGFzc3dvcmQ6IHE1 NHRSVndLOE11PC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgICAgICAKPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCiAgICA8dGFibGUgIHdpZHRoPSIxMDAlIj4KICAgICAg ICA8dHIgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFs O2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5 bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6 ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPlRodXJzZGF5LCBKdWx5IDE2LCAyMDIwCiAgICAg ICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9Im1hcmdpbjowcHg7 Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhl aWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2 NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJw eDsiPjc6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQy0wNzowMCkgUGFjaWZpYyBU aW1lIChVUyAmIENhbmFkYSkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MiBocnMKICAgICAgICAg ICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9OVCBzaXplPSIyIiBDT0xP Uj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD4KCiAgICAKCgkJ CTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7Ij48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz cDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRoOmF1 dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+PHRh YmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0nd2lk dGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjojNDNBOTQyOyBi b3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsgbWluLXdpZHRoOjE2 MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0eWxlPSdwYWRk aW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYjgyYjcyNzIxYTA3Y2Y0MDk2NmE4YWI2YmZjNDdl Y2InIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9u Om5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwv dHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDQ4cHgiPjx0ZCBz dHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKCgk8dGFibGU+PHRi b2R5Pjx0cj48dGQgc3R5bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsgZm9u dC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5K b2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJjb2xvcjogIzk5OTk5OTtm b250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5U YXAgdG8gY2FsbCBpbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpPC90ZD48 L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMztmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJl Zj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTYxMDU3MjMwMyUyMyUyMyowMSonIHN0eWxl PSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlh bDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4xLTY1MC00NzktMzIwODwvYT4m bmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Ij5DYWxsLWluIHRvbGwgbnVtYmVyIChV Uy9DYW5hZGEpPC9zcGFuPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsi PjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01U SUQ9bTNkNTljM2IxYjJiY2QzNTc1OTEyNjdkNWYyYzA4ZDZiIiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOm5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwQUZGOSI+R2xvYmFsIGNhbGwtaW4gbnVt YmVyczwvYT48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjx0YWJsZSBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjAiPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDI4cHg7Ij48dGQgc3R5bGU9 ImhlaWdodDoyOHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCTx0YWJsZT48dHI+PHRkICBz dHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7 IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRweDsiPjxiPkpvaW4gZnJvbSBhIHZp ZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46 MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQt c2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6MTYxMDU3 MjMwM0BpZXRmLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6 IzAwQUZGOSI+MTYxMDU3MjMwM0BpZXRmLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PHRyIHN0eWxl PSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJp YWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5Zb3UgY2FuIGFsc28gZGlh bCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuPC90ZD48L3RyPjwv dGFibGU+PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KICAgIDx0YWJsZSBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9u dC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUt aGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAx NHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDoxNjEwNTcyMzAzLmll dGZAbHluYy53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMw MEFGRjkiPjE2MTA1NzIzMDMuaWV0ZkBseW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJs ZT4KCgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1h aW4iPgogICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8 L3RkPjwvdHI+CgkJCQk8dHI+CgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAj MDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDog MjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBz dHlsZT0iY29sb3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53 ZWJleC5jb208L2E+CgkJCQkJPC90ZD4KCQkJCTwvdHI+CiAgICAgICAgICAgICAgICA8dHIgc3R5 bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj4KCQkJPC90YWJsZT4KCQk8L3Rk PgoJPC90cj4KPC90YWJsZT4K ------=_Part_408657_1933625064.1593811351062 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTG9zX0FuZ2VsZXMNClRaVVJMOmh0dHA6Ly90enVybC5vcmcv em9uZWluZm8tb3V0bG9vay9BbWVyaWNhL0xvc19BbmdlbGVzDQpYLUxJQy1MT0NBVElPTjpBbWVy aWNhL0xvc19BbmdlbGVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wODAwDQpUWk9G RlNFVFRPOi0wNzAwDQpUWk5BTUU6UERUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6 RlJFUT1ZRUFSTFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFO REFSRA0KVFpPRkZTRVRGUk9NOi0wNzAwDQpUWk9GRlNFVFRPOi0wODAwDQpUWk5BTUU6UFNUDQpE VFNUQVJUOjE5NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURB WT0xU1UNCkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1Q OjIwMjAwNzAzVDIxMjIzMFoNCkFUVEVOREVFO0NOPSJ2Nm9wc0BpZXRmLm9yZyI7Uk9MRT1SRVEt UEFSVElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxUTzp2Nm9wc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NO PSJWNk9QUyBXb3JraW5nIEdyb3VwIjpNQUlMVE86djZvcHMtY2hhaXJzQGlldGYub3JnDQpEVFNU QVJUO1RaSUQ9QW1lcmljYS9Mb3NfQW5nZWxlczoyMDIwMDcxNlQwNzAwMDANCkRURU5EO1RaSUQ9 QW1lcmljYS9Mb3NfQW5nZWxlczoyMDIwMDcxNlQwOTAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1iODJiNzI3MjFhMDdjZjQwOTY2YThhYjZiZmM0 N2VjYg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU5MzgxMTM1MA0KVUlEOjI2MzgzYzRmLTg0 ZGYtNGVhZC1iZjQyLTZkMTUxZTQ5MzU3Zg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVY IE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1iODJiNzI3 MjFhMDdjZjQwOTY2YThhYjZiZmM0N2VjYlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTog MTYxIDA1NyAyMzAzXG5cblxuTWVldGluZyBwYXNzd29yZDogcTU0dFJWd0s4TXVcblxuXG5cbkpP SU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSlcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBv cnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE2MTA1NzIzMDMlMjMlMjMqMDEqXG5c bkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9i YWxjYWxsaW4ucGhwP01USUQ9bTNkNTljM2IxYjJiY2QzNTc1OTEyNjdkNWYyYzA4ZDZiXG5cblxu Sk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoxNjEwNTcy MzAzQGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBv ciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDoxNjEwNTcyMzAzLmlldGZA bHluYy53ZWJleC5jb21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2Nv bGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9S VEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBh dWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUg cmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5 IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2gg cmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNj dXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lv bi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PlxuKiB7XG4gICAgcGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXIt Y29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2lu ZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNp emU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJl YWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglm b250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1 dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEg c2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250 LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5t YWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9y dGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0i cGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249Imxl ZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0 cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAi PlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdp ZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGln bj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIi IHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0t PlxuXG5cblxuXG5cbgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjQiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpv aW4gdGhlIFdlYmV4IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5c bgkJCQk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBw eCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNz IGNvZGUpOiAxNjEgMDU3IDIzMDM8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwv dGFibGU+XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQg U0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+cTU0dFJWd0s4TXU8L0ZPTlQ+ PC90ZD48L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxu CQkJCQk8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0 eWxlPSJ3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQz QTk0MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13 aWR0aDoxNjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNl bnRlciIgc3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWI4MmI3MjcyMWEwN2NmNDA5NjZhOGFiNmJmYzQ3ZWNi IiBzdHlsZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpu b25lOyI+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxu CQkJCTwvdGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9 IiNGRjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpF PSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBT SVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjE2MTA1NzIzMDMlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAw QUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tM2Q1OWMzYjFiMmJjZDM1NzU5MTI2N2Q1 ZjJjMDhkNmIiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTRweDtjb2xv cjojMDBBRkY5Ij5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxC Uj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxl PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PkpvaW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVm PSJzaXA6MTYxMDU3MjMwM0BpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMw MEFGRjkiIEZBQ0U9ImFyaWFsIj4xNjEwNTcyMzAzQGlldGYud2ViZXguY29tPC9GT05UPjwvYT4m bmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91 IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVy LjwvRk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBm b250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGlu ZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29m dCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE2MTA1NzIzMDMu aWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6 IzAwQUZGOSI+MTYxMDU3MjMwMy5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3Rh YmxlPlxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNz PSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBj b2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4 LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDov L2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAg ICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3Rh YmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOklQdjYgT3BlcmF0aW9u cw0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0N CkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZF VkVOVA0KRU5EOlZDQUxFTkRBUg0K ------=_Part_408657_1933625064.1593811351062-- ------=_Part_408656_740508543.1593811351062 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTG9zX0FuZ2VsZXMNClRaVVJMOmh0dHA6Ly90enVybC5vcmcv em9uZWluZm8tb3V0bG9vay9BbWVyaWNhL0xvc19BbmdlbGVzDQpYLUxJQy1MT0NBVElPTjpBbWVy aWNhL0xvc19BbmdlbGVzDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wODAwDQpUWk9G RlNFVFRPOi0wNzAwDQpUWk5BTUU6UERUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6 RlJFUT1ZRUFSTFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFO REFSRA0KVFpPRkZTRVRGUk9NOi0wNzAwDQpUWk9GRlNFVFRPOi0wODAwDQpUWk5BTUU6UFNUDQpE VFNUQVJUOjE5NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURB WT0xU1UNCkVORDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1Q OjIwMjAwNzAzVDIxMjIzMFoNCkFUVEVOREVFO0NOPSJ2Nm9wc0BpZXRmLm9yZyI7Uk9MRT1SRVEt UEFSVElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxUTzp2Nm9wc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NO PSJWNk9QUyBXb3JraW5nIEdyb3VwIjpNQUlMVE86djZvcHMtY2hhaXJzQGlldGYub3JnDQpEVFNU QVJUO1RaSUQ9QW1lcmljYS9Mb3NfQW5nZWxlczoyMDIwMDcxNlQwNzAwMDANCkRURU5EO1RaSUQ9 QW1lcmljYS9Mb3NfQW5nZWxlczoyMDIwMDcxNlQwOTAwMDANCkxPQ0FUSU9OOmh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1iODJiNzI3MjFhMDdjZjQwOTY2YThhYjZiZmM0 N2VjYg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU5MzgxMTM1MA0KVUlEOjI2MzgzYzRmLTg0 ZGYtNGVhZC1iZjQyLTZkMTUxZTQ5MzU3Zg0KREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVY IE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1iODJiNzI3 MjFhMDdjZjQwOTY2YThhYjZiZmM0N2VjYlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTog MTYxIDA1NyAyMzAzXG5cblxuTWVldGluZyBwYXNzd29yZDogcTU0dFJWd0s4TXVcblxuXG5cbkpP SU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSlcblRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBv cnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE2MTA1NzIzMDMlMjMlMjMqMDEqXG5c bkdsb2JhbCBjYWxsLWluIG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9i YWxjYWxsaW4ucGhwP01USUQ9bTNkNTljM2IxYjJiY2QzNTc1OTEyNjdkNWYyYzA4ZDZiXG5cblxu Sk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoxNjEwNTcy MzAzQGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBv ciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDoxNjEwNTcyMzAzLmlldGZA bHluYy53ZWJleC5jb21cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2Nv bGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklNUE9S VEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBh dWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUg cmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5 IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2gg cmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNj dXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lv bi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PlxuKiB7XG4gICAgcGFkZGluZzogMDsgICAgbWFyZ2luOiAwO31cbnRhYmxlIHtcbglib3JkZXIt Y29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2lu ZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRkIHtcbglmb250LXNp emU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJl YWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxuLnRpdGxlIHtcbglm b250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1 dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7XG5cbn1AbWVkaWEg c2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0bGUge1xuCQlmb250 LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRoOiBhdXRvICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290ZXIge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxuCS5t YWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9y dGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0i cGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249Imxl ZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCTx0 cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAi PlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7IHdp ZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBhbGln bj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFsaWduPSJjZW50ZXIi IHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPi0t PlxuXG5cblxuXG5cbgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5cbgkJCQkJCTxGT05U IFNJWkU9IjQiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBpdCdzIHRpbWUsIGpv aW4gdGhlIFdlYmV4IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5c bgkJCQk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBw eCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNz IGNvZGUpOiAxNjEgMDU3IDIzMDM8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwv dGFibGU+XG4JCQlcbgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQg U0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+cTU0dFJWd0s4TXU8L0ZPTlQ+ PC90ZD48L3RyPjwvdGFibGU+XG5cbiAgICAgICAgPHRhYmxlPlxuICAgICAgICAJPHRyIHN0eWxl PSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCTx0cj5cbgkJCQk8dGQgc3R5bGU9IndpZHRoOmF1dG8haW1wb3J0YW50OyAiPlxu CQkJCQk8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0 eWxlPSJ3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50O2JhY2tncm91bmQtY29sb3I6IzQz QTk0MjsgYm9yZGVyOjBweCBzb2xpZCAjNDNBOTQyOyBib3JkZXItcmFkaXVzOjI1cHg7IG1pbi13 aWR0aDoxNjBweCFpbXBvcnRhbnQ7Ij5cbgkJCQkJCTx0cj5cbgkJCQkJCQk8dGQgYWxpZ249ImNl bnRlciIgc3R5bGU9InBhZGRpbmc6MTBweCAzNnB4OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWI4MmI3MjcyMWEwN2NmNDA5NjZhOGFiNmJmYzQ3ZWNi IiBzdHlsZT0iY29sb3I6I0ZGRkZGRjsgZm9udC1zaXplOjIwcHg7IHRleHQtZGVjb3JhdGlvbjpu b25lOyI+Sm9pbiBtZWV0aW5nPC9hPjwvdGQ+XG4JCQkJCQk8L3RyPlxuCQkJCQk8L3RhYmxlPlxu CQkJCTwvdGQ+XG4JCQk8L3RyPlxuCQk8L3RhYmxlPlxuXG4gPEZPTlQgc2l6ZT0iMiIgQ09MT1I9 IiNGRjAwMDAiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Ij48L0ZPTlQ+XG48Rk9OVCBTSVpF PSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+XG5cbiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBT SVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjE2MTA1NzIzMDMlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAw QUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tM2Q1OWMzYjFiMmJjZDM1NzU5MTI2N2Q1 ZjJjMDhkNmIiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTRweDtjb2xv cjojMDBBRkY5Ij5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxC Uj48QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxl PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PkpvaW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVm PSJzaXA6MTYxMDU3MjMwM0BpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMw MEFGRjkiIEZBQ0U9ImFyaWFsIj4xNjEwNTcyMzAzQGlldGYud2ViZXguY29tPC9GT05UPjwvYT4m bmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91 IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVy LjwvRk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBm b250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGlu ZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29m dCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE2MTA1NzIzMDMu aWV0ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6 IzAwQUZGOSI+MTYxMDU3MjMwMy5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3Rh YmxlPlxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNz PSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNzJweCI+PHRkPiZu YnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBj b2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4 LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0cDov L2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4gICAgICAgICAgICAg ICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8L3Rh YmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1NQVJZOklQdjYgT3BlcmF0aW9u cw0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0N CkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZF VkVOVA0KRU5EOlZDQUxFTkRBUg0K ------=_Part_408656_740508543.1593811351062-- From nobody Fri Jul 3 14:29:34 2020 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 F1B3B3A0764 for ; Fri, 3 Jul 2020 14:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0OTyOFDnCuR for ; Fri, 3 Jul 2020 14:29:30 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4FC3A0544 for ; Fri, 3 Jul 2020 14:29:30 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id x11so13035585plo.7 for ; Fri, 03 Jul 2020 14:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:references:to:date:message-id; bh=jCctkDDgeHTJSxEVqrni3y7NbzY7ooM9JeMWtgdfmck=; b=EugEQ8T50Fr58nRCrNw16WlipTHDwxUq5J4BNSUEYmHl0sTKuQYt/ZL0i4haXyM0v8 uY3Mj3nj5dS4KgzlBWBXO+gbUm3egETjhCFKuLtxmjF4CdJpzDc1BDMbljZb4E6mNihF GcDmBZbzS6byoY5Hcd0SywNeEQQ1FJWozFGVglUxrP/qUPSKUaDLSiKirErLdxbm4Fyu 54K0iYkEH4v4cEdG8LUq/Y0HirG5d2PuuS7hARhgv+mnMkHFnCK0IIa8JEMOjV4harZ7 pm8bQ1u3QnISGvqYIGdaDKIO7/PXmM8DkTQUSnZ+lDehiAFI8xS2iZ3pSPhOTLFYA0QU MQOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:references:to:date :message-id; bh=jCctkDDgeHTJSxEVqrni3y7NbzY7ooM9JeMWtgdfmck=; b=aORiTKXnSM5ZbhFFmJ0DmmdnS9oy2Gh+ZOmyU9gQWVqCikj1zOTGZtzBA8L8/btqkd zoEo6sV8sdkH8SBDltLjLRJqL7t+/aanFFvAvC9guYnkudVI4ZQ0QmmpuQlxxN7m1SOg LcWJS8Vi6Uo5vuh8X0MTYENoj+fMiv0mFK+YexVRqVVMZYHftlCvBhTmA8h2hgvrgavP 6Pv1Xa19aXNsC39kgty7IZ72iXtP8pjgMMDZ4YF0dM1j/00ZkSdDBxv/VkM6gD8bMoGn Ckr4/WbFOu1fpj+fNjHppEftF6qPACrUqDmNP3G8gLn2WmucKPsXSfMMqjF8t7NxOyWD u7oQ== X-Gm-Message-State: AOAM530VjudlFmYCmc1cF6IXIGZOkMH1vZqnFbRKxqZZpYcYYd+ykymo raABrU+j/ZK8iMIwERYTUeDrbJXQ X-Google-Smtp-Source: ABdhPJzboQfHIrhWiLLbOMVMp99rs5Xh33RjG3H6DtEsb8hkm4UcUKG5DAaapMLvlgRxuM0tcfOh0A== X-Received: by 2002:a17:90a:aa88:: with SMTP id l8mr40881026pjq.145.1593811769836; Fri, 03 Jul 2020 14:29:29 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::1116? ([2600:8802:5800:652::1116]) by smtp.gmail.com with ESMTPSA id nh14sm5688370pjb.4.2020.07.03.14.29.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jul 2020 14:29:29 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_37BE3D12-72E1-4A95-9E8A-788E9557483B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) X-Mail-Calendar-Part: Yes References: To: IPv6 Operations Date: Fri, 3 Jul 2020 14:29:27 -0700 Message-Id: <1F01677C-0F01-4A28-A61F-8ECA04E5DB1B@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] Fwd: [www.ietf.org/rt #290174] V6ops interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 21:29:33 -0000 --Apple-Mail=_37BE3D12-72E1-4A95-9E8A-788E9557483B Content-Type: multipart/alternative; boundary="Apple-Mail=_9267E75C-FC6C-47C3-B25D-0C7BC00B1C7C" --Apple-Mail=_9267E75C-FC6C-47C3-B25D-0C7BC00B1C7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Heads up: the IESG tells me I need to move the interim meeting to 16 = July. So, I have accordingly changed the webex information from = 14:00-16:00 UTC on 23 July to the same time on 16 July. > Begin forwarded message: >=20 > From: Fred Baker > Subject: Re: [www.ietf.org/rt #290174] V6ops interim meeting > Date: July 3, 2020 at 2:16:41 PM PDT > To: The IESG > Cc: Ron Bonica , JORDI PALET MARTINEZ = , Jen Linkova , = xiechf@chinatelecom.cn, warren >=20 > I managed to miss her email, but I'm happy to move it to 16 July at = the same time. I obviously need to change the webex invitation; let me = know if there is anything else you need me to do. I'm assuming that with = the date change you have the information you need. >=20 >> On Jun 30, 2020, at 12:50 PM, Amy Vezza via RT = wrote: >>=20 >> Hi Fred, >>=20 >> As I am sure you have seen Alissa=E2=80=99s recent message to the WG = Chairs list >> = (https://mailarchive.ietf.org/arch/msg/wgchairs/WgFn1d2hq95IDZNypm_5sFtJI7= Y/), >> we are unable to complete the V6OPS Interim Meeting Request, as the = IESG has >> forbidden working groups from holding virtual interim meetings the = week of July >> 20th. >>=20 >> Please let us know if the V6OPS WG would prefer to change the date to = happen >> the week of July 13th or to move it after IETF 108 to sometime in = August. >>=20 >> Best regards, >>=20 >> Amy >>=20 >>=20 >>=20 >> On Tue Jun 23 18:28:29 2020, fredbaker.ietf@gmail.com wrote: >>=20 >> Amy/Cindy: >>=20 >> Now that I have filed an interim meeting, I have this quaint idea = that I should be able to see it somewhere. Where should I be looking? >>=20 >>> On Jun 22, 2020, at 10:22 PM, Fred Baker via RT = wrote: >>>=20 >>>=20 >>>=20 >>>> On Jun 22, 2020, at 4:35 PM, Amy Vezza via RT = wrote: >>>>=20 >>>> Hi Fred, >>>>=20 >>>> I can absolutely discuss this over WebEx with your tomorrow (Cindy = is >>>> unavailable), however I think in testing to find out what you can = see as a >>>> chair, Cindy accidentally sent you the link in the datatracker = Sandbox, which >>>> is the testing suite for the datatracker, and not the datatracker = itself. >>>=20 >>> I suspected that was an issue. And yes, that is there in the data = tracker after I have logged in. >>>=20 >>>> Looking at the V6OPS Working Group meetings page = (https://datatracker.ietf.org/wg/v6ops/meetings/) >>>> one of the top buttons should be "Request an interim meeting" = (note: please be >>>> sure you are logged in to the datatracker). Once you click on that = button, you >>>> should be able to fill in all the details for the meeting and = submit to us to >>>> go into the queue for us to make the announcement. >>>>=20 >>>> If you are still having trouble we can meet tomorrow so we can look = at the >>>> datatracker together. >>>=20 >>> Thanks for your help. I now have a posted interim. If you have = questions, please feel free to call me at +1-805-637-0529 so we can get = it sorted out quickly. >>>=20 >>>> Best regards, >>>>=20 >>>> Amy >>>>=20 >>>> On Mon Jun 22 15:13:01 2020, fredbaker.ietf@gmail.com wrote: >>>>=20 >>>>=20 >>>>> On Jun 22, 2020, at 1:54 PM, Cindy Morgan via RT = wrote: >>>>>=20 >>>>> Hi Fred, >>>>>=20 >>>>> To get this interim meeting into the Datatracker, please go to the = V6OPS >>>>> meeting tab (https://sandbox.ietf.org/wg/v6ops/meetings/) and hit = the "Request >>>>> an interim meeting" button. >>>>=20 >>>> first problem - there is no such button on the page. There is a = "schedule a meeting" button, but that doesn't get me to scheduling an = interim either. >>>>=20 >>>> Given that, may I suggest we talk via webex, where I can display = what I'm doing and you can tell me what I'm doing wrong? Give me a webex = link. I'm available 8:00-15:30 Tuesday, any time after 9:00 on = Wednesday... >>>>=20 >>>>> =46rom there you will be prompted to enter in the meeting details, = including >>>>> date, time, duration, and remote participation (e.g. Webex) = instructions. There >>>>> is also a field there to enter the agenda. >>>>>=20 >>>>> Once you fill all of that out and hit Submit, it will send a = ticket to us >>>>> prompting us to review the request and send the formal = announcement to the >>>>> IETF-Announce list. When we sent the announcement, the Datatracker = also >>>>> automatically adds the meeting to = https://datatracker.ietf.org/meeting/upcoming >>>>> and sets up the meeting in the Datatracker so that you can add = your minutes and >>>>> meeting materials. >>>>>=20 >>>>> Best regards, >>>>> Cindy >>>>>=20 >>>>> On Sun Jun 21 20:33:20 2020, fredbaker.ietf@gmail.com wrote: >>>>>=20 >>>>> This is to let you know that we have scheduled an interim meeting = on July 23 at 15:00 UTC. At this point, we have no drafts on our agenda; = we will have >>>>> - Ben Kyemba, RENU, discussing dual stack deployment in his = network >>>>> - Jen Linkova, Google, discussing convertion to IPv6-only within = Google >>>>> - Chongfen Xie, China Telecom, talking about IPv6 traffic = statistics within China (which are disputed) >>>>>=20 >>>>> A possible future is that drafts will be filed that are = interesting to the operational community. We will add people to the = agenda if that occurs. >>>>>=20 >>>>> I'm not sure what you need from us to have this included in the = IETF 108 proceedings. Minutes and meeting materials, certainly. Anything = else? --Apple-Mail=_9267E75C-FC6C-47C3-B25D-0C7BC00B1C7C Content-Type: multipart/mixed; boundary="Apple-Mail=_6FB02FA1-F498-447F-B728-EF2CBFB38D62" --Apple-Mail=_6FB02FA1-F498-447F-B728-EF2CBFB38D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Heads= up: the IESG tells me I need to move the interim meeting to 16 July. = So, I have accordingly changed the webex information from 14:00-16:00 = UTC on 23 July to the same time on 16 July.

Begin forwarded message:

From: = Fred Baker <fredbaker.ietf@gmail.com>
Subject: = Re: [www.ietf.org/rt = #290174] V6ops interim meeting
Date: = July 3, 2020 at 2:16:41 PM = PDT
To: = The IESG <iesg-secretary@ietf.org>
Cc: Ron Bonica <rbonica@juniper.net>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, Jen Linkova <furry@google.com>, xiechf@chinatelecom.cn, warren <warren@kumari.net>

I managed to miss her email, but = I'm happy to move it to 16 July at the same time. I obviously need to = change the webex invitation; let me know if there is anything else you = need me to do. I'm assuming that with the date change you have the = information you need.

On Jun 30, 2020, at 12:50 PM, Amy Vezza via RT = <iesg-secretary@ietf.org> wrote:

Hi Fred,

As I am sure you have = seen Alissa=E2=80=99s recent message to the WG Chairs list
(https://mailarchive.ietf.org/arch/msg/wgchairs/WgFn1d2hq95IDZNy= pm_5sFtJI7Y/),
we are unable to complete the V6OPS = Interim Meeting Request, as the IESG has
forbidden working = groups from holding virtual interim meetings the week of July
20th.

Please let us know if the = V6OPS WG would prefer to change the date to happen
the = week of July 13th or to move it after IETF 108 to sometime in August.

Best regards,

Amy



On Tue Jun 23 18:28:29 2020, fredbaker.ietf@gmail.com wrote:

Amy/Cindy:

Now that I have = filed an interim meeting, I have this quaint idea that I should be able = to see it somewhere. Where should I be looking?

On Jun 22, 2020, at = 10:22 PM, Fred Baker via RT <iesg-secretary@ietf.org> wrote:



On Jun 22, 2020, at 4:35 PM, Amy Vezza via RT <iesg-secretary@ietf.org> wrote:

Hi Fred,

I can absolutely = discuss this over WebEx with your tomorrow (Cindy is
unavailable), however I think in testing to find out what you = can see as a
chair, Cindy accidentally sent you the link = in the datatracker Sandbox, which
is the testing suite for = the datatracker, and not the datatracker itself.

I suspected that was an issue. = And yes, that is there in the data tracker after I have logged in.

Looking = at the V6OPS Working Group meetings page (https://datatracker.ietf.org/wg/v6ops/meetings/)
one of the top buttons should be "Request an interim meeting" = (note: please be
sure you are logged in to the = datatracker). Once you click on that button, you
should be = able to fill in all the details for the meeting and submit to us to
go into the queue for us to make the announcement.

If you are still having trouble we can meet = tomorrow so we can look at the
datatracker together.

Thanks for your help. I now have = a posted interim. If you have questions, please feel free to call me at = +1-805-637-0529 so we can get it sorted out quickly.

Best regards,

Amy

On Mon Jun 22 = 15:13:01 2020, fredbaker.ietf@gmail.com wrote:


On Jun = 22, 2020, at 1:54 PM, Cindy Morgan via RT <iesg-secretary@ietf.org> wrote:

Hi Fred,

To get this interim = meeting into the Datatracker, please go to the V6OPS
meeting= tab (https://sandbox.ietf.org/wg/v6ops/meetings/) and hit the = "Request
an interim meeting" button.

first problem - there is no such = button on the page. There is a "schedule a meeting" button, but that = doesn't get me to scheduling an interim either.

Given that, may I suggest we talk via webex, where I can = display what I'm doing and you can tell me what I'm doing wrong? Give me = a webex link. I'm available 8:00-15:30 Tuesday, any time after 9:00 on = Wednesday...

=46rom there you will be prompted to enter in the meeting = details, including
date, time, duration, and remote = participation (e.g. Webex) instructions. There
is also a = field there to enter the agenda.

Once you = fill all of that out and hit Submit, it will send a ticket to us
prompting us to review the request and send the formal = announcement to the
IETF-Announce list. When we sent the = announcement, the Datatracker also
automatically adds the = meeting to https://datatracker.ietf.org/meeting/upcoming
and sets up the meeting in the Datatracker so that you can = add your minutes and
meeting materials.

Best regards,
Cindy

On Sun Jun 21 20:33:20 2020, fredbaker.ietf@gmail.com wrote:

This is to let you know that we have scheduled an interim = meeting on July 23 at 15:00 UTC. At this point, we have no drafts on our = agenda; we will have
- Ben Kyemba, RENU, discussing dual = stack deployment in his network
- Jen Linkova, Google, = discussing convertion to IPv6-only within Google
- = Chongfen Xie, China Telecom, talking about IPv6 traffic statistics = within China (which are disputed)

A = possible future is that drafts will be filed that are interesting to the = operational community. We will add people to the agenda if that = occurs.

I'm not sure what you need from us = to have this included in the IETF 108 proceedings. Minutes and meeting = materials, certainly. Anything else?
= --Apple-Mail=_6FB02FA1-F498-447F-B728-EF2CBFB38D62 Content-Disposition: attachment; filename=Webex_Meeting.ics Content-Type: text/calendar; x-unix-mode=0644; name="Webex_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0D=0AVERSION:2.0=0D=0AMETHOD:REQUEST=0D=0ABEGIN:VTIMEZONE=0D=0A= TZID:America/Los_Angeles=0D=0A= TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles=0D=0A= X-LIC-LOCATION:America/Los_Angeles=0D=0ABEGIN:DAYLIGHT=0D=0A= TZOFFSETFROM:-0800=0D=0ATZOFFSETTO:-0700=0D=0ATZNAME:PDT=0D=0A= DTSTART:19700308T020000=0D=0ARRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU=0D= =0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0ATZOFFSETFROM:-0700=0D=0A= TZOFFSETTO:-0800=0D=0ATZNAME:PST=0D=0ADTSTART:19701101T020000=0D=0A= RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU=0D=0AEND:STANDARD=0D=0A= END:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0ADTSTAMP:20200703T212230Z=0D=0A= ATTENDEE;CN=3D"V6OPS=20Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAILTO:v6ops-chairs@ietf.org=0D= =0AORGANIZER;CN=3D"Cisco=20Webex":MAILTO:messenger@webex.com=0D=0A= DTSTART;TZID=3DAmerica/Los_Angeles:20200716T070000=0D=0A= DTEND;TZID=3DAmerica/Los_Angeles:20200716T090000=0D=0A= LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm4f9d8ceb024dd551711051e= 06eb598ae=0D=0ATRANSP:OPAQUE=0D=0ASEQUENCE:1593811350=0D=0A= UID:26383c4f-84df-4ead-bf42-6d151e49357f=0D=0ADESCRIPTION:\n\nJOIN=20= WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm4f9d8ceb024dd551711051e= 06eb598ae\nMeeting=20number=20(access=20code):=20161=20057=20= 2303\n\n\nMeeting=20password:=20q54tRVwK8Mu\n\n\n\nJOIN=20BY=20= PHONE\n1-650-479-3208=20Call-in=20toll=20number=20(US/Canada)\nTap=20= here=20to=20call=20(mobile=20phones=20only,=20hosts=20not=20supported):=20= tel:%2B1-650-479-3208,,*01*1610572303%23%23*01*\n\nGlobal=20call-in=20= numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm3d59c3b1b2bc= d357591267d5f2c08d6b\n\n\nJOIN=20FROM=20A=20VIDEO=20SYSTEM=20OR=20= APPLICATION\nDial=20sip:1610572303@ietf.webex.com\nYou=20can=20also=20= dial=20173.243.2.68=20and=20enter=20your=20meeting=20number.\n\n\nJoin=20= using=20Microsoft=20Lync=20or=20Microsoft=20Skype=20for=20Business\nDial=20= sip:1610572303.ietf@lync.webex.com\n\n\n\nIf=20you=20are=20a=20host,=20= click=20here=20to=20view=20host=20= information:\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm9fa33a66ba736b73e5= 4480005715f92f\n\n\n\nCan't=20join=20the=20meeting?=20Contact=20support=20= here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT=20NOTICE:=20Please=20= note=20that=20this=20Webex=20service=20allows=20audio=20and=20other=20= information=20sent=20during=20the=20session=20to=20be=20recorded,=20= which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20You=20= should=20inform=20all=20meeting=20attendees=20prior=20to=20recording=20= if=20you=20intend=20to=20record=20the=20meeting.\n=0D=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:\ntable=20{\n=09= border-collapse:=20separate;=20width=20=3D100%;=09border:=200;=09= border-spacing:=200;}\n\ntr=20{\n=09line-height:=2018px;}\n\na,=20td=20= {\n=09font-size:=2014px;=09font-family:=20Arial;=09color:=20#333;=09= word-wrap:=20break-word;=09word-break:=20normal;=09padding:=20= 0;}\n\n.title=20{\n=09font-size:=2028px;}\n\n.image=20{\n=09width:=20= auto;=09max-width:=20auto;}\n\n.footer=20{\n=09width:=20604px;}\n\n.main=20= {\n\n}@media=20screen=20and=20(max-device-width:=20800px)=20{\n=09.title=20= {\n=09=09font-size:=2022px=20!important;=09}\n=09.image=20{\n=09=09= width:=20auto=20!important;=09=09max-width:=20100%=20!important;=09}\n=09= .footer=20{\n=09=09width:=20100%=20!important;=09=09max-width:=20604px=20= !important\n=09}\n=09.main=20{\n=09=09width:=20100%=20!important;=09=09= max-width:=20604px=20!important\n=09}\n}\n\n\n\n=09 \n=09\n=09=09\n=09=09=09\n\n\n\n=09=09=09\n=09=09=09=09\n=09=09=09=09=09= \n=09=09=09=09\n=09=09=09=09 \n=09=09=09=09\n=09=09=09=09=09= \n=09=09=09=09\n=09=09=09=
\n=09=09=09=09=09=09When=20it's=20time,=20join=20the=20Webex=20meeting=20= here.\n=09=09=09=09=09
\n=09=09=09=09=09=09Meeting=20number=20(access=20code):=20161=20057=20= 2303\n=09=09=09=09=09
\n=09=09=09
Meeting=20password:q54tRVwK8Mu
\n\n=20=20=20=20=20=20= =20=20\n=20=20=20=20=20=20=20=20=09 \n=09=09=09\n=09=09= =09=09\n=09=09=09=09=09\n=09=09=09=09=09=09\n=09=09=09=09=09=09=09= Join=20meeting\n=09=09=09=09=09=09= \n=09=09=09=09=09
\n=09=09=09=09\n=09=09=09\n=09=09= \n\n=20\n 
 
\n\n =20
Join=20by=20phone=20 =20
1-650-479-3208=20= Call-in=20toll=20number=20(US/Canada)=20 =20
Global=20= call-in=20numbers =20


\n\n 
\n\nJoin=20from=20a=20video=20system=20or=20= application
Dial=201610572303@ietf.webex.com =20
You=20can=20also=20dial=20= 173.243.2.68=20and=20enter=20your=20meeting=20number.=20 =20=
 =20
\n\nJoin=20using=20Microsoft=20Lync=20or=20Microsoft=20Skype=20for=20= BusinessDial=201610572303.ietf@lync.webex.co= m\n\n=09 
\n=09= If=20= you=20are=20a=20host,=20click=20= here=20to=20view=20host=20information.
\n\n=09=09=09= \n=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 \n=09=09=09=09\n=09=09=09=09=09Need=20help?=20Go=20to=20http://help.webex.com\n=09=09=09=09=09\n=09= =09=09=09\n=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 \n=09=09=09\n=09=09= \n=09\n\n=0D=0ASUMMARY:IPv6=20Operations=0D=0A= PRIORITY:5=0D=0ACLASS:PUBLIC=0D=0ABEGIN:VALARM=0D=0ATRIGGER:-PT5M=0D=0A= ACTION:DISPLAY=0D=0ADESCRIPTION:Reminder=0D=0AEND:VALARM=0D=0AEND:VEVENT=0D= =0AEND:VCALENDAR=0D=0A= --Apple-Mail=_6FB02FA1-F498-447F-B728-EF2CBFB38D62 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_6FB02FA1-F498-447F-B728-EF2CBFB38D62-- --Apple-Mail=_9267E75C-FC6C-47C3-B25D-0C7BC00B1C7C-- --Apple-Mail=_37BE3D12-72E1-4A95-9E8A-788E9557483B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl7/ozcACgkQEhdRnd2G P+DNfA//UMcKd2aUNWvBNyP4p/N1OJHJrPv+L7+mMMtCGQezqelufnlIxCvVkOb1 A20/01tTii/1kU8uHWXovN1qx6rIMylUO5zvSxciHXly5USURSVo9xMzL6d7yT3D s4x5452KSR2Am42dnjOFDmXbkJzpHwiHA2tmjXRGnpPzGegiWa2Uc56RbcHK+OfI m7LO6xM2GXazLlPSjFLujP8gZjf+pM+4h56QvPB1NcPp5jI+FQh66qbb09LEBCwV N53S48/4v3hI9P5aAWFTqTJRoe0WsTDbQS3XabIz/KSubq6tT9SjCnPMxwIlVnCB Axy22sLwwQldo5fTlPxEvyXUowDz2/KULCkL09W+yeHH2rcKWsWg7+dLnazHR6fv gpRdT+KZXhnwp9GLRVnLUuyQrz2nU1sofU0jF0GSwN/KTMOOJNm3oHUWFFy3bd6p bUxEF5vCzaR6xUL2/VU7ptEW5spMLthBgrgqJFX484Za/PHmnTlD4KWm5lBlihuo KWqEGUgKhayS2kfpVS5J6BYseML7COqfLskAXJn/B16P0+HogrLj4nYuV9PSPl6C odSEtvsXO5r2kmB8vaNnxDuK2c6lsYGyBFn1RmEqyQLXFAb0QYAEjXvfG+Q1oWmx D3B8JHJTYK6zOugwT0X5J2yxdUE2MNw8XQ5hPJosk3cUJ9hMGHY= =AKMJ -----END PGP SIGNATURE----- --Apple-Mail=_37BE3D12-72E1-4A95-9E8A-788E9557483B-- From nobody Fri Jul 3 22:59:02 2020 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 CB1AC3A0BCA for ; Fri, 3 Jul 2020 22:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceG-LrWDxzd7 for ; Fri, 3 Jul 2020 22:58:58 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id ABADB3A0BC9 for ; Fri, 3 Jul 2020 22:58:57 -0700 (PDT) Received: from [IPv6:2620::930:0:94b5:b641:64de:8e07] ([IPv6:2620:0:930:0:94b5:b641:64de:8e07]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 0645wvkZ208920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 3 Jul 2020 22:58:57 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 0645wvkZ208920 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1593842337; bh=vrH5f3+YwRYZd9wqf36uXgcP1J29EEwMaEWLD+1OPZ4=; h=From:Subject:Date:To:From; b=eiWbr99nEV6y35wM/MN3hentEKwOfqvvGxTOg8/Zg78rlriXPJdPvbEAIGDPwzyXF +2pfoFoojC8deMELt4g+kepC6gXHEZYJ65uXNF1YMIKoqqbFWV0Sb3fh4Rtbi9dIDG 6CKsawZfmlKsAs7NXZIcKLw/11Hd+1MGFxccyiIc= From: Owen DeLong Content-Type: multipart/alternative; boundary="Apple-Mail=_7975695B-8926-49D8-939A-5D7787AAA2D7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <69CCFA4C-C9DB-46E4-A878-E73185FDCECE@delong.com> Date: Fri, 3 Jul 2020 22:58:56 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 03 Jul 2020 22:58:57 -0700 (PDT) Archived-At: Subject: [v6ops] Shepherd write-up for draft-ietf-v6ops-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 05:59:01 -0000 --Apple-Mail=_7975695B-8926-49D8-939A-5D7787AAA2D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This has been submitted per RFC4858 section 3.1 (1) This draft is aimed at being an Informational RFC. Informational is = the appropriate type because it provides both a problem statement and possible operational = mitigations and associated constraints. (2) IESG Approval Announcement Technical Summary: This is a companion document to = https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ = . This document provides advice for the operator side of the process = whereas the other document provides advice for the client or CPE side of the process. Together, = both documents attempt to improve the user experience when unplanned SLAAC renumbering events = occur. Document Quality: The document so far has been approved by the V6OPS working group = (successful working group last call). The document does not specify new protocol, but rather = provides guidance regarding how to override the default values of some parameters in the existing = protocols. Personnel Owen DeLong is the Document Shepherd Fred Baker and Ron Bonica are the WG chairs Warren Kumari is the responsible AD. (3) Shepherd=E2=80=99s review Prior to becoming shepherd, I was significantly involved in reviewing = each revision of the document and provided feedback and contributed improvements at each step. I have = been active in the debate of this I-D on the working group mailing list. This version of = the document is ready for publication.=20 (4) Shepherd=E2=80=99s concerns I have no concerns about the depth or breadth of the reviews that have = been performed. The document (along side its companion document = https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ = has received substantial comments from the working group. Author has = been very responsive and incorporated feedback very well.=20 (5) Special Reviews Needed I do not believe any special reviews are necessary for this document. (6) Shepherd=E2=80=99s Concerns or issues I have no concerns or issues with the document in its current form. (7) IPR disclosures There are no relevant IPR disclosures in this document. The document = does not touch on any technologies other than those in existing RFCs developed within the = IETF. (8) IPRs referencing this document No IPR disclosures have been filed referencing this document and for the = reasons stated in the previous section, it is very unlikely one would be filed. (9) WG consensus strength This document had good participation and discussion in the working group = and received fairly broad support both prior to and during WG last call. (10) Dissent None (11) ID nits No nits found (once I got past the fact that the NITS interface via URL = doesn=E2=80=99t cope well with this draft for reasons beyond me). Feeding it the raw text worked = fine.= --Apple-Mail=_7975695B-8926-49D8-939A-5D7787AAA2D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = has been submitted per RFC4858 section 3.1



(1) This draft is aimed = at being an Informational RFC. Informational is the appropriate type = because
it provides both a problem statement and possible = operational mitigations and associated
= constraints.

(2) IESG = Approval Announcement

Technical Summary:
This is a companion document to https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-ren= um/.
This document provides advice for the = operator side of the process whereas the other document
provides advice for the client or CPE side of the process. = Together, both documents attempt to
improve the = user experience when unplanned SLAAC renumbering events occur.

Document Quality:

The document so far has been approved by the V6OPS working = group (successful working group
last call). The document = does not specify new protocol, but rather provides guidance regarding = how
to override the default values of some = parameters in the existing protocols.

Personnel

Owen DeLong is the = Document Shepherd
Fred Baker and Ron Bonica are the WG = chairs
Warren Kumari is the responsible AD.


(3) Shepherd=E2=80=99s = review

Prior to becoming shepherd, I was = significantly involved in reviewing each revision of the document
and provided feedback and contributed improvements at each = step. I have been active in the
debate of this I-D on the = working group mailing list. This version of the document is ready for
publication. 

(4) = Shepherd=E2=80=99s concerns

I have no = concerns about the depth or breadth of the reviews that have been = performed.

The document (along side its = companion document https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-ren= um/
has received substantial comments from the = working group. Author has been very responsive
and = incorporated feedback very well. 

(5) = Special Reviews Needed

I do not believe any = special reviews are necessary for this document.

(6) Shepherd=E2=80=99s Concerns or issues

I have no concerns or issues with the document in its current = form.

(7) IPR disclosures

There are no relevant IPR disclosures in this document. The = document does not touch on
any technologies other than = those in existing RFCs developed within the IETF.

(8) IPRs referencing this document

No IPR disclosures have been filed referencing this document = and for the reasons stated in the
previous section, it is = very unlikely one would be filed.

(9) WG = consensus strength

This document had good = participation and discussion in the working group and received fairly
broad support both prior to and during WG last call.

(10) Dissent

None

(11) ID nits

No nits found (once I got past the fact that = the NITS interface via URL doesn=E2=80=99t cope well
with = this draft for reasons beyond me). Feeding it the raw text worked = fine.
= --Apple-Mail=_7975695B-8926-49D8-939A-5D7787AAA2D7-- From nobody Mon Jul 6 09:12:32 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 665DD3A16A2; Mon, 6 Jul 2020 09:12:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159405194728.471.11478316078825521581@ietfa.amsl.com> Date: Mon, 06 Jul 2020 09:12:27 -0700 Archived-At: Subject: [v6ops] IPv6 Operations (v6ops) WG Virtual Meeting: 2020-07-16 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 16:12:28 -0000 The IPv6 Operations (v6ops) WG will hold a virtual interim meeting on 2020-07-16 from 16:00 to 18:00 Europe/Madrid (14:00 to 16:00 UTC). Agenda: Ben Kyemba: IPv6 Deployment - RENU Dual Stack Scenario Jen Linkova: Turning IPv4 off at Google Chongfen Xie: IPv6 traffic statistics as seen by China Telecom Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mb82b72721a07cf40966a8ab6bfc47ecb Meeting number (access code): 161 057 2303 Meeting password: q54tRVwK8Mu From nobody Tue Jul 7 10:17:34 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 856FE3A0D70; Tue, 7 Jul 2020 10:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <159414225246.17044.3724528991852825184@ietfa.amsl.com> Date: Tue, 07 Jul 2020 10:17:32 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 17:17:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-01.txt Pages : 18 Date : 2020-07-07 Abstract: This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are already available with IPv6. When SIIT is used as a stateless NAT46 and IPv4-only devices or applications initiate traffic flows to dual- stack services (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. Avoiding this dual- translation will significantly reduce the usage of the NAT64 and the relevant logging, which may be a high impact when traffic flows are towards CDNs, caches or similar resources. This is the case for 464XLAT and MAP-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 9 20:58:20 2020 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 273613A0BF2; Thu, 9 Jul 2020 20:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQBIEOpwGfGb; Thu, 9 Jul 2020 20:58:16 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530BD3A0BF1; Thu, 9 Jul 2020 20:58:16 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id a14so1997930qvq.6; Thu, 09 Jul 2020 20:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6CKuTHI2o1wIQ6BsEQR27l7L6lAPEZNAPj4tB5G9VM=; b=kX+9ot8CbTyuFjKl1JXimRTbDLXwy2zzi7CPlV5cwo906Apw2Uxv5MBQIHq3JL431d aaalanS6BM8/Ah4pOV74cj+RQYlxTNngQwUFd1eQDdnSjQOkG2opZF0vQWtS49U6kmMu 3DjWR6bfG7bIaDroC62TWkFAfXV1CGCv/lrGqKRqfO2TjjZaKYI+wbh7Ifd3uD29YRxM GRNR7d+hYY5hzI2jsJJvvYYJ9K9nyJ4qZOQc85ypVHo9KZS5TfmFLuustRU7/tPF0Gvb K5PDXn2teercXbVTTzWDAeiQl4ZHb6/FXk3Q9iLMyitr7oxYLWI0/N4GaNhKJrJSDGSO +QGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E6CKuTHI2o1wIQ6BsEQR27l7L6lAPEZNAPj4tB5G9VM=; b=NTVV/QEuZHE9eJOTyt/1Pz0Z3qq7eqTiE97CfN9P6imHZScO6mV8AJDnKIYYA8E7EC k0kfGclvzfdnUlK1jxklU2F+4FinRRby8xb1GwslBQ+ympAf+saRRBIDufuxeOWZPiOy GB2i6iU0oHtS6LGIqepz6GtYRP/t4c2Nv/RcATNdKBelNNmwPVunVN5nQNtB+lsntdDc XnIdghwnIx/3qV3V31Ccm+gDGf6yjerggD3iNdcQ3r+hV658PsMNLck7ogrz1WfzTTn7 zbtnNOS1+FEhG4ubFTC8bgSz/ff/Kv8clvCpXx7kyMFJ86aYEbb6Ou9/wkdzw1vzTit4 ym3g== X-Gm-Message-State: AOAM531jAAgqmE0klLWuTBw3XlzWTYW+/SDewjx5UfnYG6d+jTKzaG/M uP9jaBmF4Xr4aoX2zeCIAEYAOjF0EgCWtycUwQM= X-Google-Smtp-Source: ABdhPJwj/ITrFlQgM9dC2rY2XVn7Q4nx1nFfRQg4NDguXox/jjYuIjnwA/xKpxgSOyr3E5Hd5zZ1ASdBmHgNo7243Zs= X-Received: by 2002:ad4:4a6d:: with SMTP id cn13mr66095015qvb.165.1594353495227; Thu, 09 Jul 2020 20:58:15 -0700 (PDT) MIME-Version: 1.0 References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> In-Reply-To: From: Jen Linkova Date: Fri, 10 Jul 2020 13:58:04 +1000 Message-ID: To: =?UTF-8?Q?Jordi_Palet_Mart=C3=ADnez?= Cc: Fred Baker , draft-ietf-v6ops-464xlat-optimization@ietf.org, warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 03:58:18 -0000 OK, I"ve read the document and before I finish the write up I'd like to discuss a number of comments I have. My apologies for not raising them during the WGLC - I was not paying attention, got busy with work... 0) I might need coffee but I found the Abstract a bit confusing so if I may suggest some text.. ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case the traffic flows are translated twice: first from IPv4 to IPv6 (at the ingress point to then IPv6-only network) and then from IPv6 back to IPv4 at the egress point. If the destination is IPv6-enabled that second translation might not be required. This document describes some optimization to 464XLAT and MAP-T deployments to avoid translating IP6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilisation in the operator's network" 1) Introduction section The draft says: "allow IPv4-only devices or applications to connect with IPv4 services in Internet, by means of a stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]." Do you think it would help saying "with IPv4 services in Internet over IPv6-only infrastructure"? Otherwise it sounds confusing - why do we need anything at all to help IPv4-only clients to talk to IPv6-only services? 2) ""This allows to translate the IPv6-only flow back to IPv4, in order to forward it to Internet." I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used extensively in the draft. 3) "In both cases (NAT46 and NAT64), the translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 addresses following [RFC6052]." IMHO this text would be more readable if we split it in two sentences: " In both cases (NAT46 and NAT64), the translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] . Translation between IPv4 and IPv6 addresses is done as per RFC6052]." 4) Section 3 is called "Possible Optimisation". However it comes before the Section 4 (problem statement) and the text seems to be more about the problem. Also, the first 3 paragraphs of Section 4 (until "until "As shown in the Figure 4" text) seem to repeat Section 3. Shall those two sections be merged? Or am I missing anything and they are actually talking about different things? 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge of the synthesis of AAAA records from the A records, so they can use a NAT64, without the need of doing a double-translation by means of the NAT46/CLAT." - who are "they"? This is the first sentence of the section so not sure who you are referring to. 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? 7) ""As it can be observed in the preceding picture, the situation is the same, regardless of in case of a wired network with a CE Router or a cellular network where a UE is connecting other devices (which may be IPv4-only or have IPv4-only apps), by means of a tethering functionality." IMHO it's a bit hard to parse...Maybe smth like: "Examples of a topology shown on the picture above includes: - a residential ISP IPv6-only access network with a dual-stack LAN behind a CPE performing NAT46 (CLAT); - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only applications running on that UE or for traffic originated by other devices connected to the UE via tethering." 8) Section 5.1. Approach 1: DNS/Routing-based Solution "5.1. Approach 1: DNS/Routing-based Solution "Because the WKP is non-routable, this solution will only be possible if the CDN/cache is in the same ASN as the provider network, or somehow interconnected without routing thru" Internet." Maybe it's worth explicitly mentioning that this approach would require that the path to the destination is NOT traversing NAT64 devices. Otherwise the simple configuration of such devices 'translate everything with the destination address in the WKP' would become much more complex. 9) Section 5.2.3 ""In normal conditions the TTL for both A and AAAA records, of a given FQDN, should be the same," I'm not sure it's the case actually and we can expect that to happen 'normally'. Do you have any references proving that point? 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs Sorry but I have difficulties understanding those two sentences. What 'existing procedures' the resolver must be using? IMHO this section would be much easier to understand if there is an example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries would be created? As most CDNs would have multiple entries, this is a key point of the proposal. 11) Section 5.2.8. Behavior in presence/absence of DNS64 "Furthermore, because as indicated in Section 5.2.2, the EAMT entry is not created when the service is IPv6-enabled." Is it correct? The section 5.2.2 seems to be talking about detecting IPv6 enabled services and using their AAAAs for creating EAMT entries. 12) (related to 11) The draft seems to assume that the CPE/UA knows the NAT64 prefix somehow. As it's an operational document I believe it would be beneficial to provide some guidance on how exactly the device should discover the prefix. Obviously, the operator could use RFC8781 (PREF64 RA option) or PCE. Or the device and use RFC7050. However if the device uses RFC7050 then the Section 5.2.8 shall discuss this. 13) IMHO sections 5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should be follow each other or sections 5.2.9. might have a reference to 5.2.12. 14) Section 5.2.11 Behavior in presence of Happy Eyeballs IMHO, this section should make it explicit and very very clear: as soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs fallback to that IPv4 address becomes impossible. In case of connectivity issues with the IPv6 address used in that EAMT entry, the client would not be able to reach the destination. I feel like the draft does not discuss the impact enough. It's not about delay, it's about IPv6 becoming the only protocol to reach IPv6-enabled destinations for both dual-stack and IPv4-only hosts. Maybe it's a good thing in 2020 ;) 15) Later in that section the draft says: " So even if Happy Eyeballs is present, the fallback to IPv4-only typically, will be slower than native IPv6 itself, because the added delay in the NAT46+NAT64 translations, when not using this optimization." I think it should be saying "IPv4 would be slower", not "fallback to IPv4". So maybe smth like " 'IPv4 is expected to be slower than native IPv6 due to delays added by NAT46+NAT64. This optimization reduced that delay by eliminating the need of the second translation (NAT64)"? 16) The draft does not discuss the troubleshooting implication. For example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and there is an EAMT entry for 8.8.8.8. IMHO this draft needs to discuss this and potential impact on tech support procedures. 17) Another thing which seems to be missing is some guidelines on controlling this feature. I'd suggest adding some text about that. IMHO, the router vendors SHOULD (I'd vote for MUST even) have that optimization disabled by default. The routers MUST have a knob to turn it off if it's enabled. 18) Acknowledgements Section Pls remove "....and TBD". -- SY, Jen Linkova aka Furry From nobody Fri Jul 10 00:04:43 2020 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 806AB3A07F4; Fri, 10 Jul 2020 00:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xdVMC1_ZKqk; Fri, 10 Jul 2020 00:04:39 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BDD3A07BB; Fri, 10 Jul 2020 00:04:39 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id a14so2127688qvq.6; Fri, 10 Jul 2020 00:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zGsNuT7R+BTzkgd9wet/J65Llq1kHOcxoaOg+LUH8x0=; b=kj7dAfgaSfVgFWgO5WvGgM5CBC+jrKSH5FiKHMrYnaZfP1QoNIr4u9SmElcE1mql3q iCK7coYa7JPPNesxjQpNqQFRqdd2Xw10itGd0FakfBcUwFehBucBiLhAUiFoM9GIsYhl XNS9xTjWwXq1n+naOizVxBsMSjrKuTtUOV7XvKH9/lUV4n/SmbF3yu5onc+3+bazMZxA evCw1WKrUOMHit/r2mQ+yNPeAPYBalilwsuUCtI1SoDOmvIpAk+QTFYcWz2hRrDmTQIN ujw4hJPiSmA7RekEOupcxkeV57rMIkOuVvH5taQ2R9GMknBjUPLe6tepkTuLuuh/dnmL b60w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zGsNuT7R+BTzkgd9wet/J65Llq1kHOcxoaOg+LUH8x0=; b=EHe0Ve2FFSTE0PskTeAyS7ASxTQ24yLNmwp/GaLDajSBGQwf+DPOHxUqNUzTP20OOF TlVQ3GyMJyBfOX0hIW5+gBAYl7A2wxkWZSFU9T3u1r5h5TweQojh54LHoeE3YLaoie00 4PTsRR4ze4Dvi+a813mzEVqvHmiGA0B5fPxizmNI+gkSNMqJA6wLi4t0CzLhnCI7SVc4 dgADtvzDafkd4illlKE2AIJdmNdFB/kx+bkUzIDdzC9dpqBfb+l2tzHb4HeLf8BLPCE1 F8futXwVvj4P/0Io35tWnTpvSZ9ZBZPgiGzIWewFlfAdopo5odstTCsKPaBMK3xt7k1i l7DQ== X-Gm-Message-State: AOAM531NS2YabG7bmdsI18zSSYk7y24ykQ1Rzdtc9jgzn0/klLiTvOx4 9sv6qF+FvbED4/x/hfHUQ8r0pU+iyom0CH06ljalp+GG X-Google-Smtp-Source: ABdhPJz9Ry6/l7cgBms6XVSHQEa7IEQjAHXRqxwRIPjdACLBhHE8aMcngOnqvtrTeEdBpzHMC6TveJIDCyaWMCTllco= X-Received: by 2002:ad4:4106:: with SMTP id i6mr49751068qvp.191.1594364678202; Fri, 10 Jul 2020 00:04:38 -0700 (PDT) MIME-Version: 1.0 References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> In-Reply-To: From: Jen Linkova Date: Fri, 10 Jul 2020 17:04:26 +1000 Message-ID: To: =?UTF-8?Q?Jordi_Palet_Mart=C3=ADnez?= , draft-ietf-v6ops-464xlat-optimization@ietf.org Cc: Fred Baker , warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 07:04:42 -0000 Oh I forgot to add one more thing: - The Security Considerations section states that "This document does not have any new specific security considerations, besides the ones already known for DNS64.". I'm not sure it's the case. The proposed approach drastically amplifies DNS poisoning impact. If the attacker manages to spoof the DNS response the CPE would create an EAMT entry which would affect *all* traffic to that destination, even for devices/applications behind that CPE which might be using DNSSEC. This could create DoS attack vector and force CDN operators to turn off IPv6 for their caches. I believe that should be discussed in more detail. On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova wrote: > > OK, I"ve read the document and before I finish the write up I'd like > to discuss a number of comments I have. > My apologies for not raising them during the WGLC - I was not paying > attention, got busy with work... > > 0) I might need coffee but I found the Abstract a bit confusing so if > I may suggest some text.. > > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access > for IPv4-only devices or applications to IPv4-only or dual-stack > destinations over IPv6-only infrastructure. In that case the traffic > flows are translated twice: first from IPv4 to IPv6 (at the ingress > point to then IPv6-only network) and then from IPv6 back to IPv4 at > the egress point. If the destination is IPv6-enabled that second > translation might not be required. This document describes some > optimization to 464XLAT and MAP-T deployments to avoid translating IP6 > flows back to IPv4 if the destination is reachable over IPv6. The > proposed solution would significantly reduce the NAT64 utilisation in > the operator's network" > > 1) Introduction section > The draft says: "allow IPv4-only devices or applications to connect > with IPv4 services in Internet, by means of a > stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described > by [RFC7915]." > > Do you think it would help saying "with IPv4 services in Internet > over IPv6-only infrastructure"? Otherwise it sounds confusing - why > do we need anything at all to help IPv4-only clients to talk to > IPv6-only services? > > 2) ""This allows to translate the IPv6-only flow back to IPv4, in > order to forward it to Internet." > > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used > extensively in the draft. > > 3) "In both cases (NAT46 and NAT64), the translation of the packet > headers is done using the IP/ICMP translation algorithm defined in > [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 > addresses following [RFC6052]." > > IMHO this text would be more readable if we split it in two sentences: > " In both cases (NAT46 and NAT64), the translation of the packet > headers is done using the IP/ICMP translation algorithm defined in > [RFC7915] . Translation between IPv4 and IPv6 addresses is done as > per RFC6052]." > > 4) Section 3 is called "Possible Optimisation". However it comes > before the Section 4 (problem statement) and the text seems to be more > about the problem. > Also, the first 3 paragraphs of Section 4 (until "until "As shown in > the Figure 4" text) seem to repeat Section 3. Shall those two sections > be merged? > Or am I missing anything and they are actually talking about different things? > > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge > of the synthesis of AAAA records from the A records, so they can use > a NAT64, without the need of doing a double-translation by means of > the NAT46/CLAT." - who are "they"? This is the first sentence of > the section so not sure who you are referring to. > > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? > > 7) ""As it can be observed in the preceding picture, the situation is the > same, regardless of in case of a wired network with a CE Router or a > cellular network where a UE is connecting other devices (which may be > IPv4-only or have IPv4-only apps), by means of a tethering > functionality." > > IMHO it's a bit hard to parse...Maybe smth like: > "Examples of a topology shown on the picture above includes: > - a residential ISP IPv6-only access network with a dual-stack LAN > behind a CPE performing NAT46 (CLAT); > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only > applications running on that UE or for traffic originated by other > devices connected to the UE via tethering." > > 8) Section 5.1. Approach 1: DNS/Routing-based Solution > "5.1. Approach 1: DNS/Routing-based Solution > "Because the WKP is non-routable, this solution will only be possible > if the CDN/cache is in the same ASN as the provider network, or > somehow interconnected without routing thru" Internet." > > Maybe it's worth explicitly mentioning that this approach would > require that the path to the destination is NOT traversing NAT64 > devices. Otherwise the simple configuration of such devices 'translate > everything with the destination address in the WKP' would become much > more complex. > > 9) Section 5.2.3 > ""In normal conditions the TTL for both A and AAAA records, of a given > FQDN, should be the same," > > I'm not sure it's the case actually and we can expect that to happen > 'normally'. Do you have any references proving that point? > > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs > Sorry but I have difficulties understanding those two sentences. What > 'existing procedures' the resolver must be using? > IMHO this section would be much easier to understand if there is an > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries > would be created? > As most CDNs would have multiple entries, this is a key point of the proposal. > > 11) Section 5.2.8. Behavior in presence/absence of DNS64 > "Furthermore, because as indicated in Section 5.2.2, the EAMT entry > is not created > when the service is IPv6-enabled." > > Is it correct? The section 5.2.2 seems to be talking about detecting > IPv6 enabled services and using their AAAAs for creating EAMT entries. > > 12) (related to 11) The draft seems to assume that the CPE/UA knows > the NAT64 prefix somehow. As it's an operational document I believe it > would be beneficial to provide some guidance on how exactly the device > should discover the prefix. Obviously, the operator could use RFC8781 > (PREF64 RA option) or PCE. Or the device and use RFC7050. However if > the device uses RFC7050 then the Section 5.2.8 shall discuss this. > > 13) IMHO sections 5.2.9. Behavior when using literal addresses or non > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should > be follow each other or sections 5.2.9. might have a reference to > 5.2.12. > > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs > IMHO, this section should make it explicit and very very clear: as > soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs > fallback to that IPv4 address becomes impossible. In case of > connectivity issues with the IPv6 address used in that EAMT entry, the > client would not be able to reach the destination. > I feel like the draft does not discuss the impact enough. It's not > about delay, it's about IPv6 becoming the only protocol to reach > IPv6-enabled destinations for both dual-stack and IPv4-only hosts. > Maybe it's a good thing in 2020 ;) > > 15) Later in that section the draft says: > " So even if Happy Eyeballs is present, the fallback to IPv4-only > typically, will be slower than native IPv6 itself, because > the added delay in the NAT46+NAT64 translations, when not using this > optimization." > > I think it should be saying "IPv4 would be slower", not "fallback to > IPv4". So maybe smth like " 'IPv4 is expected to be slower than > native IPv6 due to delays added by NAT46+NAT64. This optimization > reduced that delay by eliminating the need of the second translation > (NAT64)"? > > 16) The draft does not discuss the troubleshooting implication. For > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and > there is an EAMT entry for 8.8.8.8. > IMHO this draft needs to discuss this and potential impact on tech > support procedures. > > 17) Another thing which seems to be missing is some guidelines on > controlling this feature. I'd suggest adding some text about that. > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that > optimization disabled by default. The routers MUST have a knob to turn > it off if it's enabled. > > 18) Acknowledgements Section > Pls remove "....and TBD". > > -- > SY, Jen Linkova aka Furry -- SY, Jen Linkova aka Furry From nobody Fri Jul 10 00:18:05 2020 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 8F5193A0E6D; Fri, 10 Jul 2020 00:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfck-UfpNg7q; Fri, 10 Jul 2020 00:18:02 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 82D253A0E69; Fri, 10 Jul 2020 00:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594365480; x=1594970280; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=HOtBNXP73ASWWhLRC4T1wBIe7wXaA5HT6sNHeEhJ0To=; b=M4hvjt3QDqKOa HHxEG+XopVp+JjSY9XZGuaqk8HCGpFyfoMSiD9olF2AecBd0adpOxPLzn1/DdGFV w0r16yv9ibnZ8CPj9APDhaAE4zNI85PsB1sz8GXjsQf3DfEPBYYeSGforIuYgrPN +psKh+oPgV8+xwXSYu1OOFxnOdL+9U= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Jul 2020 09:18:00 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Jul 2020 09:17:59 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000272146.msg; Fri, 10 Jul 2020 09:17:58 +0200 X-MDRemoteIP: 2001:470:1f09:495:89d1:c574:5a9:139d X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 10 Jul 2020 09:17:58 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=146098d669=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Fri, 10 Jul 2020 09:17:54 +0200 From: JORDI PALET MARTINEZ To: Jen Linkova , CC: Fred Baker , warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Message-ID: <0A5FD684-199C-4979-8818-36C9B3047746@consulintel.es> Thread-Topic: - pre-(shepherd-writeup) review References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 07:18:05 -0000 Hi Jen, Still Reading thru all your points. On this specific one, if the attacker spoof the DNS response, it will be ab= le to create an invalid EAMT entry, so the client behind the NAT using that= destination will not reach what it wanted to reach. This is not different = if it happens without an EAMT. Having the same result as a regular DNS spoofing, should I mention it in th= e security considerations? May be indicating that it is the same kind of at= tack as a DNS spoofing without the EAMT entry, so it is not a new security = risk. I will try to respond to the other later on in the morning, and if needed u= pdate the last version with the relevant clarifications. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/7/20 9:04, "Jen Linkova" escribi=C3=B3: Oh I forgot to add one more thing: - The Security Considerations section states that "This document does not have any new specific security considerations, besides the ones already known for DNS64.". I'm not sure it's the case. The proposed approach drastically amplifies DNS poisoning impact. If the attacker manages to spoof the DNS response the CPE would create an EAMT entry which would affect *all* traffic to that destination, even for devices/applications behind that CPE which might be using DNSSEC. This could create DoS attack vector and force CDN operators to turn off IPv6 for their caches. I believe that should be discussed in more detail. On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova wrote: > > OK, I"ve read the document and before I finish the write up I'd like > to discuss a number of comments I have. > My apologies for not raising them during the WGLC - I was not paying > attention, got busy with work... > > 0) I might need coffee but I found the Abstract a bit confusing so if > I may suggest some text.. > > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access > for IPv4-only devices or applications to IPv4-only or dual-stack > destinations over IPv6-only infrastructure. In that case the traffic > flows are translated twice: first from IPv4 to IPv6 (at the ingress > point to then IPv6-only network) and then from IPv6 back to IPv4 at > the egress point. If the destination is IPv6-enabled that second > translation might not be required. This document describes some > optimization to 464XLAT and MAP-T deployments to avoid translating IP= 6 > flows back to IPv4 if the destination is reachable over IPv6. The > proposed solution would significantly reduce the NAT64 utilisation in > the operator's network" > > 1) Introduction section > The draft says: "allow IPv4-only devices or applications to connect > with IPv4 services in Internet, by means of a > stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described > by [RFC7915]." > > Do you think it would help saying "with IPv4 services in Internet > over IPv6-only infrastructure"? Otherwise it sounds confusing - why > do we need anything at all to help IPv4-only clients to talk to > IPv6-only services? > > 2) ""This allows to translate the IPv6-only flow back to IPv4, in > order to forward it to Internet." > > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 o= r > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used > extensively in the draft. > > 3) "In both cases (NAT46 and NAT64), the translation of the packet > headers is done using the IP/ICMP translation algorithm defined in > [RFC7915] and algorithmically translating the IPv4 addresses to IP= v6 > addresses following [RFC6052]." > > IMHO this text would be more readable if we split it in two sentences= : > " In both cases (NAT46 and NAT64), the translation of the packet > headers is done using the IP/ICMP translation algorithm defined in > [RFC7915] . Translation between IPv4 and IPv6 addresses is done as > per RFC6052]." > > 4) Section 3 is called "Possible Optimisation". However it comes > before the Section 4 (problem statement) and the text seems to be mor= e > about the problem. > Also, the first 3 paragraphs of Section 4 (until "until "As shown in > the Figure 4" text) seem to repeat Section 3. Shall those two section= s > be merged? > Or am I missing anything and they are actually talking about differen= t things? > > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in ch= arge > of the synthesis of AAAA records from the A records, so they can use > a NAT64, without the need of doing a double-translation by means o= f > the NAT46/CLAT." - who are "they"? This is the first sentence of > the section so not sure who you are referring to. > > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? > > 7) ""As it can be observed in the preceding picture, the situation is= the > same, regardless of in case of a wired network with a CE Router or= a > cellular network where a UE is connecting other devices (which may= be > IPv4-only or have IPv4-only apps), by means of a tethering > functionality." > > IMHO it's a bit hard to parse...Maybe smth like: > "Examples of a topology shown on the picture above includes: > - a residential ISP IPv6-only access network with a dual-stack LAN > behind a CPE performing NAT46 (CLAT); > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only > applications running on that UE or for traffic originated by other > devices connected to the UE via tethering." > > 8) Section 5.1. Approach 1: DNS/Routing-based Solution > "5.1. Approach 1: DNS/Routing-based Solution > "Because the WKP is non-routable, this solution will only be possible > if the CDN/cache is in the same ASN as the provider network, or > somehow interconnected without routing thru" Internet." > > Maybe it's worth explicitly mentioning that this approach would > require that the path to the destination is NOT traversing NAT64 > devices. Otherwise the simple configuration of such devices 'translat= e > everything with the destination address in the WKP' would become much > more complex. > > 9) Section 5.2.3 > ""In normal conditions the TTL for both A and AAAA records, of a give= n > FQDN, should be the same," > > I'm not sure it's the case actually and we can expect that to happen > 'normally'. Do you have any references proving that point? > > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs > Sorry but I have difficulties understanding those two sentences. What > 'existing procedures' the resolver must be using? > IMHO this section would be much easier to understand if there is an > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entrie= s > would be created? > As most CDNs would have multiple entries, this is a key point of the = proposal. > > 11) Section 5.2.8. Behavior in presence/absence of DNS64 > "Furthermore, because as indicated in Section 5.2.2, the EAMT entry > is not created > when the service is IPv6-enabled." > > Is it correct? The section 5.2.2 seems to be talking about detecting > IPv6 enabled services and using their AAAAs for creating EAMT entries= . > > 12) (related to 11) The draft seems to assume that the CPE/UA knows > the NAT64 prefix somehow. As it's an operational document I believe i= t > would be beneficial to provide some guidance on how exactly the devic= e > should discover the prefix. Obviously, the operator could use RFC8781 > (PREF64 RA option) or PCE. Or the device and use RFC7050. However if > the device uses RFC7050 then the Section 5.2.8 shall discuss this. > > 13) IMHO sections 5.2.9. Behavior when using literal addresses or no= n > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS shoul= d > be follow each other or sections 5.2.9. might have a reference to > 5.2.12. > > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs > IMHO, this section should make it explicit and very very clear: as > soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs > fallback to that IPv4 address becomes impossible. In case of > connectivity issues with the IPv6 address used in that EAMT entry, th= e > client would not be able to reach the destination. > I feel like the draft does not discuss the impact enough. It's not > about delay, it's about IPv6 becoming the only protocol to reach > IPv6-enabled destinations for both dual-stack and IPv4-only hosts. > Maybe it's a good thing in 2020 ;) > > 15) Later in that section the draft says: > " So even if Happy Eyeballs is present, the fallback to IPv4-only > typically, will be slower than native IPv6 itself, because > the added delay in the NAT46+NAT64 translations, when not using th= is > optimization." > > I think it should be saying "IPv4 would be slower", not "fallback to > IPv4". So maybe smth like " 'IPv4 is expected to be slower than > native IPv6 due to delays added by NAT46+NAT64. This optimization > reduced that delay by eliminating the need of the second translation > (NAT64)"? > > 16) The draft does not discuss the troubleshooting implication. For > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and > there is an EAMT entry for 8.8.8.8. > IMHO this draft needs to discuss this and potential impact on tech > support procedures. > > 17) Another thing which seems to be missing is some guidelines on > controlling this feature. I'd suggest adding some text about that. > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that > optimization disabled by default. The routers MUST have a knob to tur= n > it off if it's enabled. > > 18) Acknowledgements Section > Pls remove "....and TBD". > > -- > SY, Jen Linkova aka Furry --=20 SY, Jen Linkova aka Furry ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Jul 10 00:53:37 2020 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 2DCE93A07D1; Fri, 10 Jul 2020 00:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPIgsFR2CyaT; Fri, 10 Jul 2020 00:53:33 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422A93A07C5; Fri, 10 Jul 2020 00:53:33 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id e11so4405318qkm.3; Fri, 10 Jul 2020 00:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vc5M+d4vsxewXrm1fUMNlXdw12T9VQ8pGs3DGoMO/CI=; b=nIWLt3uPcPAPHeO3GhpPw2TN8r4kolAXL87kecZ+n7OqtDvwk7keZfOHzi1D9t19AQ oD0zQzJGHsh8DnwUebniL7BBkQJc5ORp6X8X2gtIuk1pNqLOddcDetdAaGnVJMLk/Z6o rqff4auS+U3avnnRb0QyQRVYlBgKFMxMwLf9tTJEwedAyabCBeK45TiKtYlkj7xb/vGJ bNIEkdfyp/hELv1Qjbv9HsKsm3lsH0AgGsHxRUHY0d4oJvyT/wi4J10KOdw+UoLpk9pu KHfnSpkxwbQuFeCzGU1soUldzaVClA4R0bOISSXn9OOoBlfpN7zr6RF/Z3F769GEBFPF HTVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vc5M+d4vsxewXrm1fUMNlXdw12T9VQ8pGs3DGoMO/CI=; b=EKJpV+bibVcZ5uFd/Sg9sO0z74Mt2WtP1X20b3ywDi3Bj9GFiAa0EwqJrGU9LOkadm ATTzBNxiqsc9ILHLT9V9LKjTJmUwj0oKoM4ldI0Dv+jr9eV/aJ/WzoohyI9rsau7aVbu RAxQUNZkkOyTWvBLNbiltFaKLqAFTRxPbOUtJMaEssd59xn014ESVXMxLpJNE5+u/TUp 6NO2qVSlXtZQU1P+TtYePtNxtmz0f9St4cmUekUJIKTqOpyiK2r93qkJF4GFewEcOJ9n wZooc44h4NNDKsPhqX+NIilpijq/SJ3BxUoBOej1e63NN40y0W4Jo8m2LouaSpu+VQ/e Pkfg== X-Gm-Message-State: AOAM5315qiQCpXAaXnEa8VkGv1rias/HaBQA+wu37dr4O4X46U5PtC9N JmrMxYFmZ91lk3Jb82a1q0cP1aogGRDqmARmLp4= X-Google-Smtp-Source: ABdhPJzuew/U2sQV28cOyGbWmIJjOdqJwTV5Es+TtDN6R6fCn3XO3nmI8P/j5Os2SSgSTK56J9RdqHpVLrWue5ANX80= X-Received: by 2002:a05:620a:24b:: with SMTP id q11mr67551580qkn.277.1594367611955; Fri, 10 Jul 2020 00:53:31 -0700 (PDT) MIME-Version: 1.0 References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> <0A5FD684-199C-4979-8818-36C9B3047746@consulintel.es> In-Reply-To: <0A5FD684-199C-4979-8818-36C9B3047746@consulintel.es> From: Jen Linkova Date: Fri, 10 Jul 2020 17:53:20 +1000 Message-ID: To: JORDI PALET MARTINEZ Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org, Fred Baker , warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 07:53:36 -0000 On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ wrote: > On this specific one, if the attacker spoof the DNS response, it will be = able to create an invalid EAMT entry, so the client behind the NAT using th= at destination will not reach what it wanted to reach. This is not differen= t if it happens without an EAMT. I believe it's different. The difference here is that invalid EAMT entry would affect *all* devices behind the CPE. Let's consider an example: - I have a CPE which has that optimization enabled. I have 5 devices at home, all of them are smart and using DNSSEC even. - Now one of them sent a A query for www.example.com. - The CPE sent an AAAA which got spoofed. The invalid EAMT entry is created= . - Now none of the devices could reach www.example.com, despite the fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers. This is actually related to my point about 'when/how this feature gets enabled'. It's not just must be explicitly enabled by an operator, it MUST be disabled if the roiter does not have IPv6 connectivity on the uplink (and the question is 'how to define that'). > > Having the same result as a regular DNS spoofing, should I mention it in = the security considerations? May be indicating that it is the same kind of = attack as a DNS spoofing without the EAMT entry, so it is not a new securit= y risk. The impact is much higher as it would affect all devices, incl.ones which might not be even using that CPE as a resolver. Shall this feature only be used if the CPE is capable of DNSSEC? We must be really careful here as what you are proposing basically nullifies Happy Eyeballs and might force content providers to go back to IPv4. > I will try to respond to the other later on in the morning, and if needed= update the last version with the relevant clarifications. Thank you! > =EF=BB=BFEl 10/7/20 9:04, "Jen Linkova" escribi=C3=B3= : > > Oh I forgot to add one more thing: > - The Security Considerations section states that "This document does > not have any new specific security considerations, > besides the ones already known for DNS64.". > I'm not sure it's the case. The proposed approach drastically > amplifies DNS poisoning impact. > If the attacker manages to spoof the DNS response the CPE would creat= e > an EAMT entry which would affect *all* traffic to that destination, > even for devices/applications behind that CPE which might be using > DNSSEC. This could create DoS attack vector and force CDN operators t= o > turn off IPv6 for their caches. > I believe that should be discussed in more detail. > > On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova wrote= : > > > > OK, I"ve read the document and before I finish the write up I'd lik= e > > to discuss a number of comments I have. > > My apologies for not raising them during the WGLC - I was not payin= g > > attention, got busy with work... > > > > 0) I might need coffee but I found the Abstract a bit confusing so = if > > I may suggest some text.. > > > > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide acces= s > > for IPv4-only devices or applications to IPv4-only or dual-stack > > destinations over IPv6-only infrastructure. In that case the traffi= c > > flows are translated twice: first from IPv4 to IPv6 (at the ingress > > point to then IPv6-only network) and then from IPv6 back to IPv4 at > > the egress point. If the destination is IPv6-enabled that second > > translation might not be required. This document describes some > > optimization to 464XLAT and MAP-T deployments to avoid translating = IP6 > > flows back to IPv4 if the destination is reachable over IPv6. The > > proposed solution would significantly reduce the NAT64 utilisation = in > > the operator's network" > > > > 1) Introduction section > > The draft says: "allow IPv4-only devices or applications to connect > > with IPv4 services in Internet, by means of a > > stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as describe= d > > by [RFC7915]." > > > > Do you think it would help saying "with IPv4 services in Internet > > over IPv6-only infrastructure"? Otherwise it sounds confusing - wh= y > > do we need anything at all to help IPv4-only clients to talk to > > IPv6-only services? > > > > 2) ""This allows to translate the IPv6-only flow back to IPv4, in > > order to forward it to Internet." > > > > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6= or > > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used > > extensively in the draft. > > > > 3) "In both cases (NAT46 and NAT64), the translation of the packet > > headers is done using the IP/ICMP translation algorithm defined = in > > [RFC7915] and algorithmically translating the IPv4 addresses to = IPv6 > > addresses following [RFC6052]." > > > > IMHO this text would be more readable if we split it in two sentenc= es: > > " In both cases (NAT46 and NAT64), the translation of the packet > > headers is done using the IP/ICMP translation algorithm defined = in > > [RFC7915] . Translation between IPv4 and IPv6 addresses is done = as > > per RFC6052]." > > > > 4) Section 3 is called "Possible Optimisation". However it comes > > before the Section 4 (problem statement) and the text seems to be m= ore > > about the problem. > > Also, the first 3 paragraphs of Section 4 (until "until "As shown i= n > > the Figure 4" text) seem to repeat Section 3. Shall those two secti= ons > > be merged? > > Or am I missing anything and they are actually talking about differ= ent things? > > > > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in = charge > > of the synthesis of AAAA records from the A records, so they can us= e > > a NAT64, without the need of doing a double-translation by means= of > > the NAT46/CLAT." - who are "they"? This is the first sentence o= f > > the section so not sure who you are referring to. > > > > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? > > > > 7) ""As it can be observed in the preceding picture, the situation = is the > > same, regardless of in case of a wired network with a CE Router = or a > > cellular network where a UE is connecting other devices (which m= ay be > > IPv4-only or have IPv4-only apps), by means of a tethering > > functionality." > > > > IMHO it's a bit hard to parse...Maybe smth like: > > "Examples of a topology shown on the picture above includes: > > - a residential ISP IPv6-only access network with a dual-stack LAN > > behind a CPE performing NAT46 (CLAT); > > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-onl= y > > applications running on that UE or for traffic originated by other > > devices connected to the UE via tethering." > > > > 8) Section 5.1. Approach 1: DNS/Routing-based Solution > > "5.1. Approach 1: DNS/Routing-based Solution > > "Because the WKP is non-routable, this solution will only be possib= le > > if the CDN/cache is in the same ASN as the provider network, or > > somehow interconnected without routing thru" Internet." > > > > Maybe it's worth explicitly mentioning that this approach would > > require that the path to the destination is NOT traversing NAT64 > > devices. Otherwise the simple configuration of such devices 'transl= ate > > everything with the destination address in the WKP' would become mu= ch > > more complex. > > > > 9) Section 5.2.3 > > ""In normal conditions the TTL for both A and AAAA records, of a gi= ven > > FQDN, should be the same," > > > > I'm not sure it's the case actually and we can expect that to happe= n > > 'normally'. Do you have any references proving that point? > > > > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs > > Sorry but I have difficulties understanding those two sentences. Wh= at > > 'existing procedures' the resolver must be using? > > IMHO this section would be much easier to understand if there is an > > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entr= ies > > would be created? > > As most CDNs would have multiple entries, this is a key point of th= e proposal. > > > > 11) Section 5.2.8. Behavior in presence/absence of DNS64 > > "Furthermore, because as indicated in Section 5.2.2, the EAMT entr= y > > is not created > > when the service is IPv6-enabled." > > > > Is it correct? The section 5.2.2 seems to be talking about detectin= g > > IPv6 enabled services and using their AAAAs for creating EAMT entri= es. > > > > 12) (related to 11) The draft seems to assume that the CPE/UA know= s > > the NAT64 prefix somehow. As it's an operational document I believe= it > > would be beneficial to provide some guidance on how exactly the dev= ice > > should discover the prefix. Obviously, the operator could use RFC87= 81 > > (PREF64 RA option) or PCE. Or the device and use RFC7050. However i= f > > the device uses RFC7050 then the Section 5.2.8 shall discuss this. > > > > 13) IMHO sections 5.2.9. Behavior when using literal addresses or = non > > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS sho= uld > > be follow each other or sections 5.2.9. might have a reference to > > 5.2.12. > > > > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs > > IMHO, this section should make it explicit and very very clear: as > > soon as an EAMT entry is created for an IPv4 address, Happy Eyeball= s > > fallback to that IPv4 address becomes impossible. In case of > > connectivity issues with the IPv6 address used in that EAMT entry, = the > > client would not be able to reach the destination. > > I feel like the draft does not discuss the impact enough. It's not > > about delay, it's about IPv6 becoming the only protocol to reach > > IPv6-enabled destinations for both dual-stack and IPv4-only hosts. > > Maybe it's a good thing in 2020 ;) > > > > 15) Later in that section the draft says: > > " So even if Happy Eyeballs is present, the fallback to IPv4-only > > typically, will be slower than native IPv6 itself, because > > the added delay in the NAT46+NAT64 translations, when not using = this > > optimization." > > > > I think it should be saying "IPv4 would be slower", not "fallback t= o > > IPv4". So maybe smth like " 'IPv4 is expected to be slower than > > native IPv6 due to delays added by NAT46+NAT64. This optimization > > reduced that delay by eliminating the need of the second translatio= n > > (NAT64)"? > > > > 16) The draft does not discuss the troubleshooting implication. For > > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host a= nd > > there is an EAMT entry for 8.8.8.8. > > IMHO this draft needs to discuss this and potential impact on tech > > support procedures. > > > > 17) Another thing which seems to be missing is some guidelines on > > controlling this feature. I'd suggest adding some text about that. > > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that > > optimization disabled by default. The routers MUST have a knob to t= urn > > it off if it's enabled. > > > > 18) Acknowledgements Section > > Pls remove "....and TBD". > > > > -- > > SY, Jen Linkova aka Furry > > > > -- > SY, Jen Linkova aka Furry > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > --=20 SY, Jen Linkova aka Furry From nobody Fri Jul 10 04:29:48 2020 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 40D2B3A09D6; Fri, 10 Jul 2020 04:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN48XXl6hnlH; Fri, 10 Jul 2020 04:29:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 643703A09B1; Fri, 10 Jul 2020 04:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594380582; x=1594985382; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=qTKWQPOPLnfIMXHSNWmjTkVxgrVc3AflGyTvsH2nRJI=; b=R1z7B1cBYPSJB awN5XiHd4LH4G1RxMbH6vnDYNSSJ599nFG8Cti5Ztgdt/GhFOdLBxhmDkClls05q JoZL432RNKJmO6Bwwh2dLmWjjg2ZzNbD0KSZvb82iorva4SiqrPjF6Rktf0m8DVZ Y3ovD7g5z8yMWzsDpNM15JjdNuzpds= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Jul 2020 13:29:42 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Jul 2020 13:29:39 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000272394.msg; Fri, 10 Jul 2020 13:29:38 +0200 X-MDRemoteIP: 2001:470:1f09:495:a51d:eb47:f29:4b24 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 10 Jul 2020 13:29:38 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=146098d669=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Fri, 10 Jul 2020 13:29:35 +0200 From: JORDI PALET MARTINEZ To: Jen Linkova CC: , Fred Baker , warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Message-ID: Thread-Topic: - pre-(shepherd-writeup) review References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> <0A5FD684-199C-4979-8818-36C9B3047746@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 11:29:47 -0000 Hi Jen, =EF=BB=BFEl 10/7/20 9:53, "Jen Linkova" escribi=C3=B3: On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ wrote: > On this specific one, if the attacker spoof the DNS response, it will= be able to create an invalid EAMT entry, so the client behind the NAT usin= g that destination will not reach what it wanted to reach. This is not diff= erent if it happens without an EAMT. I believe it's different. The difference here is that invalid EAMT entry would affect *all* devices behind the CPE. Let's consider an example: - I have a CPE which has that optimization enabled. I have 5 devices at home, all of them are smart and using DNSSEC even. - Now one of them sent a A query for www.example.com. - The CPE sent an AAAA which got spoofed. The invalid EAMT entry is cre= ated. - Now none of the devices could reach www.example.com, despite the fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers. [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even th= e AAAA (without this optimization), the result is the same. In my opinion i= t all depends on how and "where" the attack occurs, because the DNS cache m= ay be poisoned in the CPE or the hosts, etc. As said, I've no problem to me= ntion it, but I think is not clear if it is worst or not, it very much depe= nds on how and where the attach is performed. This is actually related to my point about 'when/how this feature gets enabled'. It's not just must be explicitly enabled by an operator, it MUST be disabled if the roiter does not have IPv6 connectivity on the uplink (and the question is 'how to define that'). [Jordi] This nullifies the full purpose of the optimization. The idea is th= at the optimization is performed as easy and automatically as possible if t= he WAN is IPv6-only. I will say in the other way around. If, in an extreme = situation, an operator has any "big" trouble with this optimization, they w= ill use TR-069 or whatever to disable it by default. Clearly the optimizati= on will be only enabled by the CPE if it is using 464XLAT because it has IP= v6-only WAN. I'm happy to add a sentence or even a section to clarify that,= but for me an optimization for 464XLAT only works if 464XLAT is working, n= ot otherwise! > > Having the same result as a regular DNS spoofing, should I mention it= in the security considerations? May be indicating that it is the same kind= of attack as a DNS spoofing without the EAMT entry, so it is not a new sec= urity risk. The impact is much higher as it would affect all devices, incl.ones which might not be even using that CPE as a resolver. Shall this feature only be used if the CPE is capable of DNSSEC? [Jordi] I don't see the relevance of DNSSEC in the CPE here. What I'm missi= ng? I understand that if validation of DNSSEC is present and the RR have be= en spoofed then the CPE *already* will discard them, because it just discov= ered that the DNSSEC validation is failing. Right? We must be really careful here as what you are proposing basically nullifies Happy Eyeballs and might force content providers to go back to IPv4. [Jordi] In my experience, in an IPv6-only environment Happy Eyeballs doesn'= t "solve" most of the cases. Let's see: 1) If the IPv6-only link or part of the IPv6-only network is broken inside = the operator, IPv4 will not work as well. So, HE will only add delay in det= ecting the problem (the Resolution Delay). 2) If the IPv6 connectivity is broken outside the operator network, in most= of the cases, IPv4 may be broken as well. 3) I agree that there may be cases where the IPv6 connectivity is broken ou= tside the operator network and IPv4 is working, and a very typical example = was when a www owner sets an AAAA record, not having IPv6 connectivity. Thi= s happen less and less often. **** However as explained in section 5.2.11, happy eyeballs it is only avai= lable in dual-stack hosts. A dual-stack hosts, normally, will not create the EAMT entry, neither use i= t (if it was created already by an IPv4-only host accessing the same FQDN). There may be an extreme case, where an IPv4-only hosts creates the EAMT ent= ry, and then a dual-stack host, talking to the same destination, using HE, = because suddenly the IPv6 connectivity fails, falls back to IPv4. In this c= ase, the dual-stack host will be using the optimization. It may be in the c= ase 1 or 2 above. HE with or without optimization is not resolving the prob= lem. If we are in case 3 above, then is not a good thing that IPv4 is failing co= nsidering that we are in an IPv6-only operator? It is acceptable that dual-stack networks/services don't realize that IPv6 = is not working? If there are IPv6-only hosts (example a NAT64+DNS64 instead of 464XLAT, in = the same operator or others), they will not reach the destination, because = HE will not help them, right? So, is this an acceptable trade-off? > I will try to respond to the other later on in the morning, and if ne= eded update the last version with the relevant clarifications. Thank you! > =EF=BB=BFEl 10/7/20 9:04, "Jen Linkova" escribi= =C3=B3: > > Oh I forgot to add one more thing: > - The Security Considerations section states that "This document = does > not have any new specific security considerations, > besides the ones already known for DNS64.". > I'm not sure it's the case. The proposed approach drastically > amplifies DNS poisoning impact. > If the attacker manages to spoof the DNS response the CPE would c= reate > an EAMT entry which would affect *all* traffic to that destinatio= n, > even for devices/applications behind that CPE which might be usin= g > DNSSEC. This could create DoS attack vector and force CDN operato= rs to > turn off IPv6 for their caches. > I believe that should be discussed in more detail. > > On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova w= rote: > > > > OK, I"ve read the document and before I finish the write up I'd= like > > to discuss a number of comments I have. > > My apologies for not raising them during the WGLC - I was not p= aying > > attention, got busy with work... > > > > 0) I might need coffee but I found the Abstract a bit confusing= so if > > I may suggest some text.. > > > > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide a= ccess > > for IPv4-only devices or applications to IPv4-only or dual-stac= k > > destinations over IPv6-only infrastructure. In that case the tr= affic > > flows are translated twice: first from IPv4 to IPv6 (at the ing= ress > > point to then IPv6-only network) and then from IPv6 back to IPv= 4 at > > the egress point. If the destination is IPv6-enabled that seco= nd > > translation might not be required. This document describes some > > optimization to 464XLAT and MAP-T deployments to avoid translat= ing IP6 > > flows back to IPv4 if the destination is reachable over IPv6. T= he > > proposed solution would significantly reduce the NAT64 utilisat= ion in > > the operator's network" > > > > 1) Introduction section > > The draft says: "allow IPv4-only devices or applications to con= nect > > with IPv4 services in Internet, by means of a > > stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as desc= ribed > > by [RFC7915]." > > > > Do you think it would help saying "with IPv4 services in Inter= net > > over IPv6-only infrastructure"? Otherwise it sounds confusing = - why > > do we need anything at all to help IPv4-only clients to talk to > > IPv6-only services? > > > > 2) ""This allows to translate the IPv6-only flow back to IPv4, = in > > order to forward it to Internet." > > > > I'm not sure we can call a flow 'IPv6-only'. Flows are usually = IPv6 or > > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are = used > > extensively in the draft. > > > > 3) "In both cases (NAT46 and NAT64), the translation of the pac= ket > > headers is done using the IP/ICMP translation algorithm defi= ned in > > [RFC7915] and algorithmically translating the IPv4 addresses= to IPv6 > > addresses following [RFC6052]." > > > > IMHO this text would be more readable if we split it in two sen= tences: > > " In both cases (NAT46 and NAT64), the translation of the packe= t > > headers is done using the IP/ICMP translation algorithm defi= ned in > > [RFC7915] . Translation between IPv4 and IPv6 addresses is d= one as > > per RFC6052]." > > > > 4) Section 3 is called "Possible Optimisation". However it come= s > > before the Section 4 (problem statement) and the text seems to = be more > > about the problem. > > Also, the first 3 paragraphs of Section 4 (until "until "As sho= wn in > > the Figure 4" text) seem to repeat Section 3. Shall those two s= ections > > be merged? > > Or am I missing anything and they are actually talking about di= fferent things? > > > > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally)= in charge > > of the synthesis of AAAA records from the A records, so they ca= n use > > a NAT64, without the need of doing a double-translation by m= eans of > > the NAT46/CLAT." - who are "they"? This is the first senten= ce of > > the section so not sure who you are referring to. > > > > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Sta= ck'? > > > > 7) ""As it can be observed in the preceding picture, the situat= ion is the > > same, regardless of in case of a wired network with a CE Rou= ter or a > > cellular network where a UE is connecting other devices (whi= ch may be > > IPv4-only or have IPv4-only apps), by means of a tethering > > functionality." > > > > IMHO it's a bit hard to parse...Maybe smth like: > > "Examples of a topology shown on the picture above includes: > > - a residential ISP IPv6-only access network with a dual-stack = LAN > > behind a CPE performing NAT46 (CLAT); > > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4= -only > > applications running on that UE or for traffic originated by ot= her > > devices connected to the UE via tethering." > > > > 8) Section 5.1. Approach 1: DNS/Routing-based Solution > > "5.1. Approach 1: DNS/Routing-based Solution > > "Because the WKP is non-routable, this solution will only be po= ssible > > if the CDN/cache is in the same ASN as the provider network,= or > > somehow interconnected without routing thru" Internet." > > > > Maybe it's worth explicitly mentioning that this approach would > > require that the path to the destination is NOT traversing NAT6= 4 > > devices. Otherwise the simple configuration of such devices 'tr= anslate > > everything with the destination address in the WKP' would becom= e much > > more complex. > > > > 9) Section 5.2.3 > > ""In normal conditions the TTL for both A and AAAA records, of = a given > > FQDN, should be the same," > > > > I'm not sure it's the case actually and we can expect that to h= appen > > 'normally'. Do you have any references proving that point? > > > > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs > > Sorry but I have difficulties understanding those two sentences= . What > > 'existing procedures' the resolver must be using? > > IMHO this section would be much easier to understand if there i= s an > > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT = entries > > would be created? > > As most CDNs would have multiple entries, this is a key point o= f the proposal. > > > > 11) Section 5.2.8. Behavior in presence/absence of DNS64 > > "Furthermore, because as indicated in Section 5.2.2, the EAMT = entry > > is not created > > when the service is IPv6-enabled." > > > > Is it correct? The section 5.2.2 seems to be talking about dete= cting > > IPv6 enabled services and using their AAAAs for creating EAMT e= ntries. > > > > 12) (related to 11) The draft seems to assume that the CPE/UA = knows > > the NAT64 prefix somehow. As it's an operational document I bel= ieve it > > would be beneficial to provide some guidance on how exactly the= device > > should discover the prefix. Obviously, the operator could use R= FC8781 > > (PREF64 RA option) or PCE. Or the device and use RFC7050. Howev= er if > > the device uses RFC7050 then the Section 5.2.8 shall discuss th= is. > > > > 13) IMHO sections 5.2.9. Behavior when using literal addresses= or non > > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS= should > > be follow each other or sections 5.2.9. might have a reference= to > > 5.2.12. > > > > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs > > IMHO, this section should make it explicit and very very clear:= as > > soon as an EAMT entry is created for an IPv4 address, Happy Eye= balls > > fallback to that IPv4 address becomes impossible. In case of > > connectivity issues with the IPv6 address used in that EAMT ent= ry, the > > client would not be able to reach the destination. > > I feel like the draft does not discuss the impact enough. It's= not > > about delay, it's about IPv6 becoming the only protocol to reac= h > > IPv6-enabled destinations for both dual-stack and IPv4-only hos= ts. > > Maybe it's a good thing in 2020 ;) > > > > 15) Later in that section the draft says: > > " So even if Happy Eyeballs is present, the fallback to IPv4-on= ly > > typically, will be slower than native IPv6 itself, because > > the added delay in the NAT46+NAT64 translations, when not us= ing this > > optimization." > > > > I think it should be saying "IPv4 would be slower", not "fallba= ck to > > IPv4". So maybe smth like " 'IPv4 is expected to be slower tha= n > > native IPv6 due to delays added by NAT46+NAT64. This optimizati= on > > reduced that delay by eliminating the need of the second transl= ation > > (NAT64)"? > > > > 16) The draft does not discuss the troubleshooting implication.= For > > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only ho= st and > > there is an EAMT entry for 8.8.8.8. > > IMHO this draft needs to discuss this and potential impact on t= ech > > support procedures. > > > > 17) Another thing which seems to be missing is some guidelines = on > > controlling this feature. I'd suggest adding some text about th= at. > > IMHO, the router vendors SHOULD (I'd vote for MUST even) have t= hat > > optimization disabled by default. The routers MUST have a knob = to turn > > it off if it's enabled. > > > > 18) Acknowledgements Section > > Pls remove "....and TBD". > > > > -- > > SY, Jen Linkova aka Furry > > > > -- > SY, Jen Linkova aka Furry > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > --=20 SY, Jen Linkova aka Furry ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Jul 10 07:30:11 2020 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 EF9953A0D27 for ; Fri, 10 Jul 2020 07:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFUblhEHD4bu for ; Fri, 10 Jul 2020 07:30:08 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 144393A0D21 for ; Fri, 10 Jul 2020 07:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594391406; x=1594996206; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=BJMcd6Q+P6CSrv6Xy8b1l aqi7b7bmtStqs9HUsi7NYs=; b=Ij1+54/jai4gnDZpknbprK+hX3uvcSHEnylc+ zcKsh3w0SUjZ1rEUOUWNj/kH4+frE3lOGhddFwr9AA0bh14YDNXP2BhcPZXnXxwC A6X7zgogjEuS8bC7HkVVoQiEEZbRmo+NShS5mLNCM/jSmVJzaQQ9cnLA+1yijfaq YcqYNc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Jul 2020 16:30:06 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Jul 2020 16:30:06 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000272565.msg for ; Fri, 10 Jul 2020 16:30:05 +0200 X-MDRemoteIP: 2001:470:1f09:495:7d28:c798:2038:51e4 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 10 Jul 2020 16:30:05 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=146098d669=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Fri, 10 Jul 2020 16:30:05 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <54063D84-E5A2-4149-8800-CD0FB3C58A3C@consulintel.es> Thread-Topic: shepherd write-up for draft-ietf-v6ops-nd-cache-init: IPR status confirmation Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] shepherd write-up for draft-ietf-v6ops-nd-cache-init: IPR status confirmation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 14:30:10 -0000 Hi Jen, all, I've been assigned as shepherd for draft-ietf-v6ops-nd-cache-init. I understand that not being a new protocol, and relying only in existing RFCs, this document is not having any IPR related issues. Anyway, could you please confirm if you have any relevant information that I should report in the write-up? Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Sat Jul 11 02:23:19 2020 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 EFBE63A09A3; Sat, 11 Jul 2020 02:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzwV_8mdfAhS; Sat, 11 Jul 2020 02:23:15 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id A18EB3A0999; Sat, 11 Jul 2020 02:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594459393; x=1595064193; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=FBrQtRzA0UrK/lZ5ZhE4M +L6hxvrvZm+SiQ5ULBmkfI=; b=CON5ss8eZprbyZRVq5mJbVprs4Sz28IEuEiCB JSQKPyp0DAYpiH0ghNLdHy3+k1kj9wUNT//qmrb+gglBmaScUYaf8kpogI6bgyyL nvVnWQE6SAjlSXrGCHf9LWVwpFDao93fzK9QREeeuEDNR9xiraexuT5WUOmPZ4Th eGH3mA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 11 Jul 2020 11:23:13 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 11 Jul 2020 11:23:11 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000273428.msg; Sat, 11 Jul 2020 11:23:10 +0200 X-MDRemoteIP: 2001:470:1f09:495:bcee:705c:2526:f4 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sat, 11 Jul 2020 11:23:10 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1461d49966=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Sat, 11 Jul 2020 11:23:05 +0200 From: JORDI PALET MARTINEZ To: JORDI PALET MARTINEZ , Jen Linkova CC: V6 Ops List , V6Ops Chairs , Message-ID: <5F769CAC-CB49-4B35-A7AB-78DEE4B6EF81@consulintel.es> Thread-Topic: [v6ops] - pre-(shepherd-writeup) review Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 09:23:18 -0000 Hi Jen, I've tried to find information about: 1) DNSSEC support in CPEs. 2) DNSSEC support in CDNs. It seems that neither of them is common. In the case of the CDNs, it seems that the at least some of them, use dynam= ic mapping instead of anycast. This will mean that having DNSSEC signatures= in advance to the server assigned to each "customer" will need to be done = in real-time, which is too expensive. When anycast is used, then they can b= e pre-computed.=20 I'm happy to hear otherwise from the WG. So, if someone can provide some details of both aspects, we could consider = it. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 10/7/20 13:30, "v6ops en nombre de JORDI PALET MARTINEZ" escribi=C3=B3: Hi Jen, =EF=BB=BFEl 10/7/20 9:53, "Jen Linkova" escribi=C3= =B3: On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ wrote: > On this specific one, if the attacker spoof the DNS response, it = will be able to create an invalid EAMT entry, so the client behind the NAT = using that destination will not reach what it wanted to reach. This is not = different if it happens without an EAMT. I believe it's different. The difference here is that invalid EAMT entry would affect *all* devices behind the CPE. Let's consider an example: - I have a CPE which has that optimization enabled. I have 5 device= s at home, all of them are smart and using DNSSEC even. - Now one of them sent a A query for www.example.com. - The CPE sent an AAAA which got spoofed. The invalid EAMT entry is= created. - Now none of the devices could reach www.example.com, despite the fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers= . [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or eve= n the AAAA (without this optimization), the result is the same. In my opini= on it all depends on how and "where" the attack occurs, because the DNS cac= he may be poisoned in the CPE or the hosts, etc. As said, I've no problem t= o mention it, but I think is not clear if it is worst or not, it very much = depends on how and where the attach is performed. This is actually related to my point about 'when/how this feature g= ets enabled'. It's not just must be explicitly enabled by an operator,= it MUST be disabled if the roiter does not have IPv6 connectivity on t= he uplink (and the question is 'how to define that'). [Jordi] This nullifies the full purpose of the optimization. The idea i= s that the optimization is performed as easy and automatically as possible = if the WAN is IPv6-only. I will say in the other way around. If, in an extr= eme situation, an operator has any "big" trouble with this optimization, th= ey will use TR-069 or whatever to disable it by default. Clearly the optimi= zation will be only enabled by the CPE if it is using 464XLAT because it ha= s IPv6-only WAN. I'm happy to add a sentence or even a section to clarify t= hat, but for me an optimization for 464XLAT only works if 464XLAT is workin= g, not otherwise! > > Having the same result as a regular DNS spoofing, should I mentio= n it in the security considerations? May be indicating that it is the same = kind of attack as a DNS spoofing without the EAMT entry, so it is not a new= security risk. The impact is much higher as it would affect all devices, incl.ones which might not be even using that CPE as a resolver. Shall this feature only be used if the CPE is capable of DNSSEC? [Jordi] I don't see the relevance of DNSSEC in the CPE here. What I'm m= issing? I understand that if validation of DNSSEC is present and the RR hav= e been spoofed then the CPE *already* will discard them, because it just di= scovered that the DNSSEC validation is failing. Right? We must be really careful here as what you are proposing basically nullifies Happy Eyeballs and might force content providers to go ba= ck to IPv4. [Jordi] In my experience, in an IPv6-only environment Happy Eyeballs do= esn't "solve" most of the cases. Let's see: 1) If the IPv6-only link or part of the IPv6-only network is broken ins= ide the operator, IPv4 will not work as well. So, HE will only add delay in= detecting the problem (the Resolution Delay). 2) If the IPv6 connectivity is broken outside the operator network, in = most of the cases, IPv4 may be broken as well. 3) I agree that there may be cases where the IPv6 connectivity is broke= n outside the operator network and IPv4 is working, and a very typical exam= ple was when a www owner sets an AAAA record, not having IPv6 connectivity.= This happen less and less often. **** However as explained in section 5.2.11, happy eyeballs it is only = available in dual-stack hosts. A dual-stack hosts, normally, will not create the EAMT entry, neither u= se it (if it was created already by an IPv4-only host accessing the same FQ= DN). There may be an extreme case, where an IPv4-only hosts creates the EAMT= entry, and then a dual-stack host, talking to the same destination, using = HE, because suddenly the IPv6 connectivity fails, falls back to IPv4. In th= is case, the dual-stack host will be using the optimization. It may be in t= he case 1 or 2 above. HE with or without optimization is not resolving the = problem. If we are in case 3 above, then is not a good thing that IPv4 is failin= g considering that we are in an IPv6-only operator? It is acceptable that dual-stack networks/services don't realize that I= Pv6 is not working? If there are IPv6-only hosts (example a NAT64+DNS64 instead of 464XLAT,= in the same operator or others), they will not reach the destination, beca= use HE will not help them, right? So, is this an acceptable trade-off? > I will try to respond to the other later on in the morning, and i= f needed update the last version with the relevant clarifications. Thank you! > =EF=BB=BFEl 10/7/20 9:04, "Jen Linkova" escri= bi=C3=B3: > > Oh I forgot to add one more thing: > - The Security Considerations section states that "This docum= ent does > not have any new specific security considerations, > besides the ones already known for DNS64.". > I'm not sure it's the case. The proposed approach drastically > amplifies DNS poisoning impact. > If the attacker manages to spoof the DNS response the CPE wou= ld create > an EAMT entry which would affect *all* traffic to that destin= ation, > even for devices/applications behind that CPE which might be = using > DNSSEC. This could create DoS attack vector and force CDN ope= rators to > turn off IPv6 for their caches. > I believe that should be discussed in more detail. > > On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova wrote: > > > > OK, I"ve read the document and before I finish the write up= I'd like > > to discuss a number of comments I have. > > My apologies for not raising them during the WGLC - I was n= ot paying > > attention, got busy with work... > > > > 0) I might need coffee but I found the Abstract a bit confu= sing so if > > I may suggest some text.. > > > > ""IP/ICMP Translation Algorithm (SIIT) can be used to provi= de access > > for IPv4-only devices or applications to IPv4-only or dual-= stack > > destinations over IPv6-only infrastructure. In that case th= e traffic > > flows are translated twice: first from IPv4 to IPv6 (at the= ingress > > point to then IPv6-only network) and then from IPv6 back to= IPv4 at > > the egress point. If the destination is IPv6-enabled that = second > > translation might not be required. This document describes = some > > optimization to 464XLAT and MAP-T deployments to avoid tran= slating IP6 > > flows back to IPv4 if the destination is reachable over IPv= 6. The > > proposed solution would significantly reduce the NAT64 util= isation in > > the operator's network" > > > > 1) Introduction section > > The draft says: "allow IPv4-only devices or applications to= connect > > with IPv4 services in Internet, by means of a > > stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as = described > > by [RFC7915]." > > > > Do you think it would help saying "with IPv4 services in I= nternet > > over IPv6-only infrastructure"? Otherwise it sounds confus= ing - why > > do we need anything at all to help IPv4-only clients to tal= k to > > IPv6-only services? > > > > 2) ""This allows to translate the IPv6-only flow back to IP= v4, in > > order to forward it to Internet." > > > > I'm not sure we can call a flow 'IPv6-only'. Flows are usua= lly IPv6 or > > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' = are used > > extensively in the draft. > > > > 3) "In both cases (NAT46 and NAT64), the translation of the= packet > > headers is done using the IP/ICMP translation algorithm = defined in > > [RFC7915] and algorithmically translating the IPv4 addre= sses to IPv6 > > addresses following [RFC6052]." > > > > IMHO this text would be more readable if we split it in two= sentences: > > " In both cases (NAT46 and NAT64), the translation of the p= acket > > headers is done using the IP/ICMP translation algorithm = defined in > > [RFC7915] . Translation between IPv4 and IPv6 addresses = is done as > > per RFC6052]." > > > > 4) Section 3 is called "Possible Optimisation". However it = comes > > before the Section 4 (problem statement) and the text seems= to be more > > about the problem. > > Also, the first 3 paragraphs of Section 4 (until "until "As= shown in > > the Figure 4" text) seem to repeat Section 3. Shall those t= wo sections > > be merged? > > Or am I missing anything and they are actually talking abou= t different things? > > > > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optiona= lly) in charge > > of the synthesis of AAAA records from the A records, so the= y can use > > a NAT64, without the need of doing a double-translation = by means of > > the NAT46/CLAT." - who are "they"? This is the first se= ntence of > > the section so not sure who you are referring to. > > > > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual= -Stack'? > > > > 7) ""As it can be observed in the preceding picture, the si= tuation is the > > same, regardless of in case of a wired network with a CE= Router or a > > cellular network where a UE is connecting other devices = (which may be > > IPv4-only or have IPv4-only apps), by means of a tetheri= ng > > functionality." > > > > IMHO it's a bit hard to parse...Maybe smth like: > > "Examples of a topology shown on the picture above includes= : > > - a residential ISP IPv6-only access network with a dual-st= ack LAN > > behind a CPE performing NAT46 (CLAT); > > - IPv6-only mobile ISP network when a UE performs CLAT for = IPv4-only > > applications running on that UE or for traffic originated b= y other > > devices connected to the UE via tethering." > > > > 8) Section 5.1. Approach 1: DNS/Routing-based Solution > > "5.1. Approach 1: DNS/Routing-based Solution > > "Because the WKP is non-routable, this solution will only b= e possible > > if the CDN/cache is in the same ASN as the provider netw= ork, or > > somehow interconnected without routing thru" Internet." > > > > Maybe it's worth explicitly mentioning that this approach w= ould > > require that the path to the destination is NOT traversing = NAT64 > > devices. Otherwise the simple configuration of such devices= 'translate > > everything with the destination address in the WKP' would b= ecome much > > more complex. > > > > 9) Section 5.2.3 > > ""In normal conditions the TTL for both A and AAAA records,= of a given > > FQDN, should be the same," > > > > I'm not sure it's the case actually and we can expect that = to happen > > 'normally'. Do you have any references proving that point? > > > > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs > > Sorry but I have difficulties understanding those two sente= nces. What > > 'existing procedures' the resolver must be using? > > IMHO this section would be much easier to understand if the= re is an > > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What E= AMT entries > > would be created? > > As most CDNs would have multiple entries, this is a key poi= nt of the proposal. > > > > 11) Section 5.2.8. Behavior in presence/absence of DNS64 > > "Furthermore, because as indicated in Section 5.2.2, the E= AMT entry > > is not created > > when the service is IPv6-enabled." > > > > Is it correct? The section 5.2.2 seems to be talking about = detecting > > IPv6 enabled services and using their AAAAs for creating EA= MT entries. > > > > 12) (related to 11) The draft seems to assume that the CPE= /UA knows > > the NAT64 prefix somehow. As it's an operational document I= believe it > > would be beneficial to provide some guidance on how exactly= the device > > should discover the prefix. Obviously, the operator could u= se RFC8781 > > (PREF64 RA option) or PCE. Or the device and use RFC7050. H= owever if > > the device uses RFC7050 then the Section 5.2.8 shall discus= s this. > > > > 13) IMHO sections 5.2.9. Behavior when using literal addre= sses or non > > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign= DNS should > > be follow each other or sections 5.2.9. might have a refer= ence to > > 5.2.12. > > > > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs > > IMHO, this section should make it explicit and very very cl= ear: as > > soon as an EAMT entry is created for an IPv4 address, Happy= Eyeballs > > fallback to that IPv4 address becomes impossible. In case o= f > > connectivity issues with the IPv6 address used in that EAMT= entry, the > > client would not be able to reach the destination. > > I feel like the draft does not discuss the impact enough. = It's not > > about delay, it's about IPv6 becoming the only protocol to = reach > > IPv6-enabled destinations for both dual-stack and IPv4-only= hosts. > > Maybe it's a good thing in 2020 ;) > > > > 15) Later in that section the draft says: > > " So even if Happy Eyeballs is present, the fallback to IPv= 4-only > > typically, will be slower than native IPv6 itself, because > > the added delay in the NAT46+NAT64 translations, when no= t using this > > optimization." > > > > I think it should be saying "IPv4 would be slower", not "fa= llback to > > IPv4". So maybe smth like " 'IPv4 is expected to be slower= than > > native IPv6 due to delays added by NAT46+NAT64. This optimi= zation > > reduced that delay by eliminating the need of the second tr= anslation > > (NAT64)"? > > > > 16) The draft does not discuss the troubleshooting implicat= ion. For > > example if I'm running 'traceroute 8.8.8.8 from my IPv4-onl= y host and > > there is an EAMT entry for 8.8.8.8. > > IMHO this draft needs to discuss this and potential impact = on tech > > support procedures. > > > > 17) Another thing which seems to be missing is some guideli= nes on > > controlling this feature. I'd suggest adding some text abou= t that. > > IMHO, the router vendors SHOULD (I'd vote for MUST even) ha= ve that > > optimization disabled by default. The routers MUST have a k= nob to turn > > it off if it's enabled. > > > > 18) Acknowledgements Section > > Pls remove "....and TBD". > > > > -- > > SY, Jen Linkova aka Furry > > > > -- > SY, Jen Linkova aka Furry > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privile= ged or confidential. The information is intended to be for the exclusive us= e of the individual(s) named above and further non-explicilty authorized di= sclosure, copying, distribution or use of the contents of this information,= even if partially, including attached files, is strictly prohibited and wi= ll be considered a criminal offense. If you are not the intended recipient = be aware that any disclosure, copying, distribution or use of the contents = of this information, even if partially, including attached files, is strict= ly prohibited, will be considered a criminal offense, so you must reply to = the original sender to inform about this communication and delete it. > > > --=20 SY, Jen Linkova aka Furry ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sat Jul 11 02:45:20 2020 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 5B1C03A0B93 for ; Sat, 11 Jul 2020 02:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Ef5FxBYj5m for ; Sat, 11 Jul 2020 02:45:14 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 AAA323A0D04 for ; Sat, 11 Jul 2020 02:44:57 -0700 (PDT) Received: from [192.168.1.138] (host-79-121-40-79.kabelnet.hu [79.121.40.79]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 06B9ibd5008208 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 11 Jul 2020 11:44:42 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-40-79.kabelnet.hu [79.121.40.79] claimed to be [192.168.1.138] To: v6ops@ietf.org References: <5F769CAC-CB49-4B35-A7AB-78DEE4B6EF81@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <9835676c-6b3b-0660-2916-4b71c15f9264@hit.bme.hu> Date: Sat, 11 Jul 2020 11:44:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5F769CAC-CB49-4B35-A7AB-78DEE4B6EF81@consulintel.es> Content-Type: multipart/alternative; boundary="------------27E2FD2B2DF9EF87CCEDB075" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.40.79; helo=[192.168.1.138]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 09:45:18 -0000 This is a multi-part message in MIME format. --------------27E2FD2B2DF9EF87CCEDB075 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jordi, I have done a quick google search and found a 12 years old ICANN report with the following conclusion: As a consequence, we conclude that just 6 units (25%) operate with full DNSSEC compatibility "out of the box." 9units (37%) can be reconfigured to bypass DNS proxy incompatibilities. Unfortunately, the rest (38%) lack reconfigurable DHCP DNS parameters, making it harder for LAN clients to bypass their interference with DNSSEC use. Source: https://www.icann.org/en/system/files/files/sac-035-en.pdf I hope that the situation has improved a lot since then. I have also found 2 years old CZ.NIC presentation: https://static.ptbl.co/static/attachments/169316/1520904408.pdf But I do not know, how representative it is. Best regards, Gábor 2020.07.11. 11:23 keltezéssel, JORDI PALET MARTINEZ írta: > Hi Jen, > > I've tried to find information about: > > 1) DNSSEC support in CPEs. > 2) DNSSEC support in CDNs. > > It seems that neither of them is common. > > In the case of the CDNs, it seems that the at least some of them, use dynamic mapping instead of anycast. This will mean that having DNSSEC signatures in advance to the server assigned to each "customer" will need to be done in real-time, which is too expensive. When anycast is used, then they can be pre-computed. > > I'm happy to hear otherwise from the WG. > > So, if someone can provide some details of both aspects, we could consider it. > > Regards, > Jordi > @jordipalet > > > > El 10/7/20 13:30, "v6ops en nombre de JORDI PALET MARTINEZ" escribió: > > Hi Jen, > > > El 10/7/20 9:53, "Jen Linkova" escribió: > > On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ > wrote: > > On this specific one, if the attacker spoof the DNS response, it will be able to create an invalid EAMT entry, so the client behind the NAT using that destination will not reach what it wanted to reach. This is not different if it happens without an EAMT. > > I believe it's different. The difference here is that invalid EAMT > entry would affect *all* devices behind the CPE. > Let's consider an example: > - I have a CPE which has that optimization enabled. I have 5 devices > at home, all of them are smart and using DNSSEC even. > - Now one of them sent a A query for www.example.com. > - The CPE sent an AAAA which got spoofed. The invalid EAMT entry is created. > - Now none of the devices could reach www.example.com, despite the > fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers. > > [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even the AAAA (without this optimization), the result is the same. In my opinion it all depends on how and "where" the attack occurs, because the DNS cache may be poisoned in the CPE or the hosts, etc. As said, I've no problem to mention it, but I think is not clear if it is worst or not, it very much depends on how and where the attach is performed. > > This is actually related to my point about 'when/how this feature gets > enabled'. It's not just must be explicitly enabled by an operator, it > MUST be disabled if the roiter does not have IPv6 connectivity on the > uplink (and the question is 'how to define that'). > > [Jordi] This nullifies the full purpose of the optimization. The idea is that the optimization is performed as easy and automatically as possible if the WAN is IPv6-only. I will say in the other way around. If, in an extreme situation, an operator has any "big" trouble with this optimization, they will use TR-069 or whatever to disable it by default. Clearly the optimization will be only enabled by the CPE if it is using 464XLAT because it has IPv6-only WAN. I'm happy to add a sentence or even a section to clarify that, but for me an optimization for 464XLAT only works if 464XLAT is working, not otherwise! > > > > > Having the same result as a regular DNS spoofing, should I mention it in the security considerations? May be indicating that it is the same kind of attack as a DNS spoofing without the EAMT entry, so it is not a new security risk. > > The impact is much higher as it would affect all devices, incl.ones > which might not be even using that CPE as a resolver. > Shall this feature only be used if the CPE is capable of DNSSEC? > > [Jordi] I don't see the relevance of DNSSEC in the CPE here. What I'm missing? I understand that if validation of DNSSEC is present and the RR have been spoofed then the CPE *already* will discard them, because it just discovered that the DNSSEC validation is failing. Right? > > We must be really careful here as what you are proposing basically > nullifies Happy Eyeballs and might force content providers to go back > to IPv4. > > [Jordi] In my experience, in an IPv6-only environment Happy Eyeballs doesn't "solve" most of the cases. Let's see: > 1) If the IPv6-only link or part of the IPv6-only network is broken inside the operator, IPv4 will not work as well. So, HE will only add delay in detecting the problem (the Resolution Delay). > 2) If the IPv6 connectivity is broken outside the operator network, in most of the cases, IPv4 may be broken as well. > 3) I agree that there may be cases where the IPv6 connectivity is broken outside the operator network and IPv4 is working, and a very typical example was when a www owner sets an AAAA record, not having IPv6 connectivity. This happen less and less often. > > **** However as explained in section 5.2.11, happy eyeballs it is only available in dual-stack hosts. > > A dual-stack hosts, normally, will not create the EAMT entry, neither use it (if it was created already by an IPv4-only host accessing the same FQDN). > > There may be an extreme case, where an IPv4-only hosts creates the EAMT entry, and then a dual-stack host, talking to the same destination, using HE, because suddenly the IPv6 connectivity fails, falls back to IPv4. In this case, the dual-stack host will be using the optimization. It may be in the case 1 or 2 above. HE with or without optimization is not resolving the problem. > > If we are in case 3 above, then is not a good thing that IPv4 is failing considering that we are in an IPv6-only operator? > It is acceptable that dual-stack networks/services don't realize that IPv6 is not working? > If there are IPv6-only hosts (example a NAT64+DNS64 instead of 464XLAT, in the same operator or others), they will not reach the destination, because HE will not help them, right? > So, is this an acceptable trade-off? > > > I will try to respond to the other later on in the morning, and if needed update the last version with the relevant clarifications. > > Thank you! > > > El 10/7/20 9:04, "Jen Linkova" escribió: > > > > Oh I forgot to add one more thing: > > - The Security Considerations section states that "This document does > > not have any new specific security considerations, > > besides the ones already known for DNS64.". > > I'm not sure it's the case. The proposed approach drastically > > amplifies DNS poisoning impact. > > If the attacker manages to spoof the DNS response the CPE would create > > an EAMT entry which would affect *all* traffic to that destination, > > even for devices/applications behind that CPE which might be using > > DNSSEC. This could create DoS attack vector and force CDN operators to > > turn off IPv6 for their caches. > > I believe that should be discussed in more detail. > > > > On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova wrote: > > > > > > OK, I"ve read the document and before I finish the write up I'd like > > > to discuss a number of comments I have. > > > My apologies for not raising them during the WGLC - I was not paying > > > attention, got busy with work... > > > > > > 0) I might need coffee but I found the Abstract a bit confusing so if > > > I may suggest some text.. > > > > > > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access > > > for IPv4-only devices or applications to IPv4-only or dual-stack > > > destinations over IPv6-only infrastructure. In that case the traffic > > > flows are translated twice: first from IPv4 to IPv6 (at the ingress > > > point to then IPv6-only network) and then from IPv6 back to IPv4 at > > > the egress point. If the destination is IPv6-enabled that second > > > translation might not be required. This document describes some > > > optimization to 464XLAT and MAP-T deployments to avoid translating IP6 > > > flows back to IPv4 if the destination is reachable over IPv6. The > > > proposed solution would significantly reduce the NAT64 utilisation in > > > the operator's network" > > > > > > 1) Introduction section > > > The draft says: "allow IPv4-only devices or applications to connect > > > with IPv4 services in Internet, by means of a > > > stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described > > > by [RFC7915]." > > > > > > Do you think it would help saying "with IPv4 services in Internet > > > over IPv6-only infrastructure"? Otherwise it sounds confusing - why > > > do we need anything at all to help IPv4-only clients to talk to > > > IPv6-only services? > > > > > > 2) ""This allows to translate the IPv6-only flow back to IPv4, in > > > order to forward it to Internet." > > > > > > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or > > > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used > > > extensively in the draft. > > > > > > 3) "In both cases (NAT46 and NAT64), the translation of the packet > > > headers is done using the IP/ICMP translation algorithm defined in > > > [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 > > > addresses following [RFC6052]." > > > > > > IMHO this text would be more readable if we split it in two sentences: > > > " In both cases (NAT46 and NAT64), the translation of the packet > > > headers is done using the IP/ICMP translation algorithm defined in > > > [RFC7915] . Translation between IPv4 and IPv6 addresses is done as > > > per RFC6052]." > > > > > > 4) Section 3 is called "Possible Optimisation". However it comes > > > before the Section 4 (problem statement) and the text seems to be more > > > about the problem. > > > Also, the first 3 paragraphs of Section 4 (until "until "As shown in > > > the Figure 4" text) seem to repeat Section 3. Shall those two sections > > > be merged? > > > Or am I missing anything and they are actually talking about different things? > > > > > > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge > > > of the synthesis of AAAA records from the A records, so they can use > > > a NAT64, without the need of doing a double-translation by means of > > > the NAT46/CLAT." - who are "they"? This is the first sentence of > > > the section so not sure who you are referring to. > > > > > > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? > > > > > > 7) ""As it can be observed in the preceding picture, the situation is the > > > same, regardless of in case of a wired network with a CE Router or a > > > cellular network where a UE is connecting other devices (which may be > > > IPv4-only or have IPv4-only apps), by means of a tethering > > > functionality." > > > > > > IMHO it's a bit hard to parse...Maybe smth like: > > > "Examples of a topology shown on the picture above includes: > > > - a residential ISP IPv6-only access network with a dual-stack LAN > > > behind a CPE performing NAT46 (CLAT); > > > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only > > > applications running on that UE or for traffic originated by other > > > devices connected to the UE via tethering." > > > > > > 8) Section 5.1. Approach 1: DNS/Routing-based Solution > > > "5.1. Approach 1: DNS/Routing-based Solution > > > "Because the WKP is non-routable, this solution will only be possible > > > if the CDN/cache is in the same ASN as the provider network, or > > > somehow interconnected without routing thru" Internet." > > > > > > Maybe it's worth explicitly mentioning that this approach would > > > require that the path to the destination is NOT traversing NAT64 > > > devices. Otherwise the simple configuration of such devices 'translate > > > everything with the destination address in the WKP' would become much > > > more complex. > > > > > > 9) Section 5.2.3 > > > ""In normal conditions the TTL for both A and AAAA records, of a given > > > FQDN, should be the same," > > > > > > I'm not sure it's the case actually and we can expect that to happen > > > 'normally'. Do you have any references proving that point? > > > > > > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs > > > Sorry but I have difficulties understanding those two sentences. What > > > 'existing procedures' the resolver must be using? > > > IMHO this section would be much easier to understand if there is an > > > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries > > > would be created? > > > As most CDNs would have multiple entries, this is a key point of the proposal. > > > > > > 11) Section 5.2.8. Behavior in presence/absence of DNS64 > > > "Furthermore, because as indicated in Section 5.2.2, the EAMT entry > > > is not created > > > when the service is IPv6-enabled." > > > > > > Is it correct? The section 5.2.2 seems to be talking about detecting > > > IPv6 enabled services and using their AAAAs for creating EAMT entries. > > > > > > 12) (related to 11) The draft seems to assume that the CPE/UA knows > > > the NAT64 prefix somehow. As it's an operational document I believe it > > > would be beneficial to provide some guidance on how exactly the device > > > should discover the prefix. Obviously, the operator could use RFC8781 > > > (PREF64 RA option) or PCE. Or the device and use RFC7050. However if > > > the device uses RFC7050 then the Section 5.2.8 shall discuss this. > > > > > > 13) IMHO sections 5.2.9. Behavior when using literal addresses or non > > > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should > > > be follow each other or sections 5.2.9. might have a reference to > > > 5.2.12. > > > > > > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs > > > IMHO, this section should make it explicit and very very clear: as > > > soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs > > > fallback to that IPv4 address becomes impossible. In case of > > > connectivity issues with the IPv6 address used in that EAMT entry, the > > > client would not be able to reach the destination. > > > I feel like the draft does not discuss the impact enough. It's not > > > about delay, it's about IPv6 becoming the only protocol to reach > > > IPv6-enabled destinations for both dual-stack and IPv4-only hosts. > > > Maybe it's a good thing in 2020 ;) > > > > > > 15) Later in that section the draft says: > > > " So even if Happy Eyeballs is present, the fallback to IPv4-only > > > typically, will be slower than native IPv6 itself, because > > > the added delay in the NAT46+NAT64 translations, when not using this > > > optimization." > > > > > > I think it should be saying "IPv4 would be slower", not "fallback to > > > IPv4". So maybe smth like " 'IPv4 is expected to be slower than > > > native IPv6 due to delays added by NAT46+NAT64. This optimization > > > reduced that delay by eliminating the need of the second translation > > > (NAT64)"? > > > > > > 16) The draft does not discuss the troubleshooting implication. For > > > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and > > > there is an EAMT entry for 8.8.8.8. > > > IMHO this draft needs to discuss this and potential impact on tech > > > support procedures. > > > > > > 17) Another thing which seems to be missing is some guidelines on > > > controlling this feature. I'd suggest adding some text about that. > > > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that > > > optimization disabled by default. The routers MUST have a knob to turn > > > it off if it's enabled. > > > > > > 18) Acknowledgements Section > > > Pls remove "....and TBD". > > > > > > -- > > > SY, Jen Linkova aka Furry > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > -- > SY, Jen Linkova aka Furry > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------27E2FD2B2DF9EF87CCEDB075 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jordi,

I have done a quick google search and found a 12 years old ICANN report with the following conclusion:

As a consequence, we conclude that just 6 units (25%) operate with full DNSSEC compatibility "out of the box." 9 units (37%) can be reconfigured to bypass DNS proxy incompatibilities. Unfortunately, the rest (38%) lack reconfigurable DHCP DNS parameters, making it harder for LAN clients to bypass their interference with DNSSEC use.

Source: https://www.icann.org/en/system/files/files/sac-035-en.pdf

I hope that the situation has improved a lot since then. 

I have also found 2 years old CZ.NIC presentation: https://static.ptbl.co/static/attachments/169316/1520904408.pdf

But I do not know, how representative it is.

Best regards,

Gábor

2020.07.11. 11:23 keltezéssel, JORDI PALET MARTINEZ írta:
Hi Jen,

I've tried to find information about:

1) DNSSEC support in CPEs.
2) DNSSEC support in CDNs.

It seems that neither of them is common.

In the case of the CDNs, it seems that the at least some of them, use dynamic mapping instead of anycast. This will mean that having DNSSEC signatures in advance to the server assigned to each "customer" will need to be done in real-time, which is too expensive. When anycast is used, then they can be pre-computed. 

I'm happy to hear otherwise from the WG.

So, if someone can provide some details of both aspects, we could consider it.

Regards,
Jordi
@jordipalet
 
 

El 10/7/20 13:30, "v6ops en nombre de JORDI PALET MARTINEZ" <v6ops-bounces@ietf.org en nombre de jordi.palet=40consulintel.es@dmarc.ietf.org> escribió:

    Hi Jen,


    El 10/7/20 9:53, "Jen Linkova" <furry13@gmail.com> escribió:

        On Fri, Jul 10, 2020 at 5:18 PM JORDI PALET MARTINEZ
        <jordi.palet@consulintel.es> wrote:
        > On this specific one, if the attacker spoof the DNS response, it will be able to create an invalid EAMT entry, so the client behind the NAT using that destination will not reach what it wanted to reach. This is not different if it happens without an EAMT.

        I believe it's different. The difference here is that invalid EAMT
        entry would affect *all* devices behind the CPE.
        Let's consider an example:
        - I have a CPE which has that optimization enabled. I have 5 devices
        at home, all of them are smart and using DNSSEC even.
        - Now one of them sent a A query for www.example.com.
        - The CPE sent an AAAA which got spoofed. The invalid EAMT entry is created.
        - Now none of the devices could reach www.example.com, despite the
        fact that 4 of them maybe using DNSSEC and/or 3rd party DNS servers.

    [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even the AAAA (without this optimization), the result is the same. In my opinion it all depends on how and "where" the attack occurs, because the DNS cache may be poisoned in the CPE or the hosts, etc. As said, I've no problem to mention it, but I think is not clear if it is worst or not, it very much depends on how and where the attach is performed.

        This is actually related to my point about 'when/how this feature gets
        enabled'.  It's not just must be explicitly enabled by an operator, it
        MUST be disabled if the roiter does not have IPv6 connectivity on the
        uplink (and the question is 'how to define that').

    [Jordi] This nullifies the full purpose of the optimization. The idea is that the optimization is performed as easy and automatically as possible if the WAN is IPv6-only. I will say in the other way around. If, in an extreme situation, an operator has any "big" trouble with this optimization, they will use TR-069 or whatever to disable it by default. Clearly the optimization will be only enabled by the CPE if it is using 464XLAT because it has IPv6-only WAN. I'm happy to add a sentence or even a section to clarify that, but for me an optimization for 464XLAT only works if 464XLAT is working, not otherwise!

        >
        > Having the same result as a regular DNS spoofing, should I mention it in the security considerations? May be indicating that it is the same kind of attack as a DNS spoofing without the EAMT entry, so it is not a new security risk.

        The impact is much higher as it would affect all devices, incl.ones
        which might not be even using that CPE as a resolver.
        Shall this feature only be used if the CPE is capable of DNSSEC?

    [Jordi] I don't see the relevance of DNSSEC in the CPE here. What I'm missing? I understand that if validation of DNSSEC is present and the RR have been spoofed then the CPE *already* will discard them, because it just discovered that the DNSSEC validation is failing. Right?

        We must be really careful here as what you are proposing basically
        nullifies Happy Eyeballs and might force content providers to go back
        to IPv4.

    [Jordi] In my experience, in an IPv6-only environment Happy Eyeballs doesn't "solve" most of the cases. Let's see:
    1) If the IPv6-only link or part of the IPv6-only network is broken inside the operator, IPv4 will not work as well. So, HE will only add delay in detecting the problem (the Resolution Delay).
    2) If the IPv6 connectivity is broken outside the operator network, in most of the cases, IPv4 may be broken as well.
    3) I agree that there may be cases where the IPv6 connectivity is broken outside the operator network and IPv4 is working, and a very typical example was when a www owner sets an AAAA record, not having IPv6 connectivity. This happen less and less often.

    **** However as explained in section 5.2.11, happy eyeballs it is only available in dual-stack hosts.

    A dual-stack hosts, normally, will not create the EAMT entry, neither use it (if it was created already by an IPv4-only host accessing the same FQDN).

    There may be an extreme case, where an IPv4-only hosts creates the EAMT entry, and then a dual-stack host, talking to the same destination, using HE, because suddenly the IPv6 connectivity fails, falls back to IPv4. In this case, the dual-stack host will be using the optimization. It may be in the case 1 or 2 above. HE with or without optimization is not resolving the problem.

    If we are in case 3 above, then is not a good thing that IPv4 is failing considering that we are in an IPv6-only operator?
    It is acceptable that dual-stack networks/services don't realize that IPv6 is not working?
    If there are IPv6-only hosts (example a NAT64+DNS64 instead of 464XLAT, in the same operator or others), they will not reach the destination, because HE will not help them, right?
    So, is this an acceptable trade-off?

        > I will try to respond to the other later on in the morning, and if needed update the last version with the relevant clarifications.

        Thank you!

        > El 10/7/20 9:04, "Jen Linkova" <furry13@gmail.com> escribió:
        >
        >     Oh I forgot to add one more thing:
        >     - The Security Considerations section states that "This document does
        >     not have any new specific security considerations,
        >        besides the ones already known for DNS64.".
        >     I'm not sure it's the case. The proposed approach drastically
        >     amplifies DNS poisoning impact.
        >     If the attacker manages to spoof the DNS response the CPE would create
        >     an EAMT entry which would affect *all* traffic to that destination,
        >     even for devices/applications behind that CPE which might be using
        >     DNSSEC. This could create DoS attack vector and force CDN operators to
        >     turn off IPv6 for their caches.
        >     I believe that should be discussed in more detail.
        >
        >     On Fri, Jul 10, 2020 at 1:58 PM Jen Linkova <furry13@gmail.com> wrote:
        >     >
        >     > OK, I"ve read the document and before I finish the write up I'd like
        >     > to discuss a number of comments I have.
        >     > My apologies for not raising them during the WGLC - I was not paying
        >     > attention, got busy with work...
        >     >
        >     > 0) I might need coffee but I found the Abstract a bit confusing so if
        >     > I may suggest some text..
        >     >
        >     > ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access
        >     > for IPv4-only devices or applications to IPv4-only or dual-stack
        >     > destinations over IPv6-only infrastructure. In that case the traffic
        >     > flows are translated twice: first from IPv4 to IPv6 (at the ingress
        >     > point to then IPv6-only network) and then from IPv6 back to IPv4 at
        >     > the egress point.  If the destination is IPv6-enabled that second
        >     > translation might not be required. This document describes some
        >     > optimization to 464XLAT and MAP-T deployments to avoid translating IP6
        >     > flows back to IPv4 if the destination is reachable over IPv6. The
        >     > proposed solution would significantly reduce the NAT64 utilisation in
        >     > the operator's network"
        >     >
        >     > 1) Introduction section
        >     > The draft says: "allow IPv4-only devices or applications to connect
        >     > with IPv4 services in Internet, by means of a
        >     >    stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described
        >     > by  [RFC7915]."
        >     >
        >     > Do you think it would help saying  "with IPv4 services in Internet
        >     > over IPv6-only infrastructure"?  Otherwise it sounds confusing - why
        >     > do we need anything at all to help IPv4-only clients to talk to
        >     > IPv6-only services?
        >     >
        >     > 2) ""This allows to translate the IPv6-only flow back to IPv4, in
        >     > order to forward it to Internet."
        >     >
        >     > I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or
        >     > IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used
        >     > extensively in the draft.
        >     >
        >     > 3) "In both cases (NAT46 and NAT64), the translation of the packet
        >     >    headers is done using the IP/ICMP translation algorithm defined in
        >     >    [RFC7915] and algorithmically translating the IPv4 addresses to IPv6
        >     >    addresses following [RFC6052]."
        >     >
        >     > IMHO this text would be more readable if we split it in two sentences:
        >     > " In both cases (NAT46 and NAT64), the translation of the packet
        >     >    headers is done using the IP/ICMP translation algorithm defined in
        >     >    [RFC7915] . Translation between IPv4 and IPv6 addresses is done as
        >     > per RFC6052]."
        >     >
        >     > 4) Section 3 is called "Possible Optimisation". However it comes
        >     > before the Section 4 (problem statement) and the text seems to be more
        >     > about the problem.
        >     > Also, the first 3 paragraphs of Section 4 (until "until "As shown in
        >     > the Figure 4" text) seem to repeat Section 3. Shall those two sections
        >     > be merged?
        >     > Or am I missing anything and they are actually talking about different things?
        >     >
        >     > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge
        >     > of the synthesis of AAAA records from the A records, so they can use
        >     >    a NAT64, without the need of doing a double-translation by means of
        >     >    the NAT46/CLAT." - who are "they"?  This is the first sentence of
        >     > the section so not sure who you are referring to.
        >     >
        >     > 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'?
        >     >
        >     > 7) ""As it can be observed in the preceding picture, the situation is the
        >     >    same, regardless of in case of a wired network with a CE Router or a
        >     >    cellular network where a UE is connecting other devices (which may be
        >     >    IPv4-only or have IPv4-only apps), by means of a tethering
        >     >    functionality."
        >     >
        >     > IMHO it's a bit hard to parse...Maybe smth like:
        >     > "Examples of a topology shown on the picture above includes:
        >     > - a residential ISP IPv6-only access network with a dual-stack LAN
        >     > behind a CPE performing NAT46 (CLAT);
        >     > - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only
        >     > applications running on that UE or for traffic originated by other
        >     > devices connected to the UE via tethering."
        >     >
        >     > 8) Section 5.1. Approach 1: DNS/Routing-based Solution
        >     > "5.1. Approach 1: DNS/Routing-based Solution
        >     > "Because the WKP is non-routable, this solution will only be possible
        >     >    if the CDN/cache is in the same ASN as the provider network, or
        >     >    somehow interconnected without routing thru" Internet."
        >     >
        >     > Maybe it's worth explicitly mentioning that this approach would
        >     > require that the path to the destination is NOT traversing NAT64
        >     > devices. Otherwise the simple configuration of such devices 'translate
        >     > everything with the destination address in the WKP' would become much
        >     > more complex.
        >     >
        >     > 9) Section 5.2.3
        >     > ""In normal conditions the TTL for both A and AAAA records, of a given
        >     > FQDN, should be the same,"
        >     >
        >     > I'm not sure it's the case actually and we can expect that to happen
        >     > 'normally'. Do you have any references proving that point?
        >     >
        >     > 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs
        >     > Sorry but I have difficulties understanding those two sentences. What
        >     > 'existing procedures'  the resolver must be using?
        >     > IMHO this section would be much easier to understand if there is an
        >     > example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries
        >     > would be created?
        >     > As most CDNs would have multiple entries, this is a key point of the proposal.
        >     >
        >     > 11) Section 5.2.8. Behavior in presence/absence of DNS64
        >     > "Furthermore,  because as indicated in Section 5.2.2, the EAMT entry
        >     > is not created
        >     >    when the service is IPv6-enabled."
        >     >
        >     > Is it correct? The section 5.2.2 seems to be talking about detecting
        >     > IPv6 enabled services and using their AAAAs for creating EAMT entries.
        >     >
        >     > 12)  (related to 11) The draft seems to assume that the CPE/UA knows
        >     > the NAT64 prefix somehow. As it's an operational document I believe it
        >     > would be beneficial to provide some guidance on how exactly the device
        >     > should discover the prefix. Obviously, the operator could use RFC8781
        >     > (PREF64 RA option) or PCE. Or the device and use RFC7050. However if
        >     > the device uses RFC7050 then the Section 5.2.8 shall discuss this.
        >     >
        >     > 13) IMHO sections 5.2.9.  Behavior when using literal addresses or non
        >     > IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should
        >     > be follow each other or  sections 5.2.9. might have a reference to
        >     > 5.2.12.
        >     >
        >     > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs
        >     > IMHO, this section should make it explicit and very very clear: as
        >     > soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs
        >     > fallback to that IPv4 address becomes impossible. In case of
        >     > connectivity issues with the IPv6 address used in that EAMT entry, the
        >     > client would not be able to reach the destination.
        >     > I feel like the draft does not discuss the impact enough.  It's not
        >     > about delay, it's about IPv6 becoming the only protocol to reach
        >     > IPv6-enabled destinations for both dual-stack and IPv4-only hosts.
        >     > Maybe it's a good thing in 2020 ;)
        >     >
        >     > 15) Later in that section the draft says:
        >     > " So even if Happy Eyeballs is present, the fallback to IPv4-only
        >     > typically, will be slower than native IPv6 itself, because
        >     >    the added delay in the NAT46+NAT64 translations, when not using this
        >     >    optimization."
        >     >
        >     > I think it should be saying "IPv4 would be slower", not "fallback to
        >     > IPv4".  So maybe smth like " 'IPv4 is expected to be slower than
        >     > native IPv6 due to delays added by NAT46+NAT64. This optimization
        >     > reduced that delay by eliminating the need of the second translation
        >     > (NAT64)"?
        >     >
        >     > 16) The draft does not discuss the troubleshooting implication. For
        >     > example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and
        >     > there is an EAMT entry for 8.8.8.8.
        >     > IMHO this draft needs to discuss this and potential impact on tech
        >     > support procedures.
        >     >
        >     > 17) Another thing which seems to be missing is some guidelines on
        >     > controlling this feature. I'd suggest adding some text about that.
        >     > IMHO, the router vendors SHOULD (I'd vote for MUST even) have that
        >     > optimization disabled by default. The routers MUST have a knob to turn
        >     > it off if it's enabled.
        >     >
        >     > 18) Acknowledgements Section
        >     > Pls remove "....and TBD".
        >     >
        >     > --
        >     > SY, Jen Linkova aka Furry
        >
        >
        >
        >     --
        >     SY, Jen Linkova aka Furry
        >
        >
        >
        > **********************************************
        > IPv4 is over
        > Are you ready for the new Internet ?
        > http://www.theipv6company.com
        > The IPv6 Company
        >
        > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
        >
        >
        >


        -- 
        SY, Jen Linkova aka Furry



    **********************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.theipv6company.com
    The IPv6 Company

    This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--------------27E2FD2B2DF9EF87CCEDB075-- From nobody Sat Jul 11 05:32:09 2020 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 98E113A0EA4; Sat, 11 Jul 2020 05:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQjFiXt3Kq2H; Sat, 11 Jul 2020 05:32:05 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id F0CDE3A0EA2; Sat, 11 Jul 2020 05:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594470721; x=1595075521; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=mzXT7E0BZ8GbFsuHLu2VThx4DgndPoE6D/e2lF0woOI=; b=tVQTcSv0lUzrX 0SCtKfyHX8ARBR4YZPII+w+DHjc0tI/Uh2BxtSgGFcq9KmlU8g3JVMNwJ5x695jp SqdI1N18xlR9x72WOidyTbfqo7UHBSjMuY9YfLLNi+5hu6qbEO7+tzRsiOPyxTPh NekOEn3vh/Q4npF5TKDWs2SoZmrBLw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 11 Jul 2020 14:32:00 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 11 Jul 2020 14:32:00 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000273711.msg; Sat, 11 Jul 2020 14:31:59 +0200 X-MDRemoteIP: 2001:470:1f09:495:e8e7:5a00:b336:2a1e X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sat, 11 Jul 2020 14:31:59 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1461d49966=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Sat, 11 Jul 2020 14:31:57 +0200 From: JORDI PALET MARTINEZ To: Jen Linkova CC: Fred Baker , , warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Message-ID: Thread-Topic: - pre-(shepherd-writeup) review References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 12:32:08 -0000 Hi Jen, Tks a lot, very useful inputs! Responding now to this ... sorry bit busy today with another document ;-) a= nd as a consequence, a new version (-02) being published in a while ... =EF=BB=BFEl 10/7/20 5:58, "Jen Linkova" escribi=C3=B3: OK, I"ve read the document and before I finish the write up I'd like to discuss a number of comments I have. My apologies for not raising them during the WGLC - I was not paying attention, got busy with work... 0) I might need coffee but I found the Abstract a bit confusing so if I may suggest some text.. ""IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case the traffic flows are translated twice: first from IPv4 to IPv6 (at the ingress point to then IPv6-only network) and then from IPv6 back to IPv4 at the egress point. If the destination is IPv6-enabled that second translation might not be required. This document describes some optimization to 464XLAT and MAP-T deployments to avoid translating IP6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilisation in the operator's network" [Jordi] Yep, tks, I'm happy to use this alternative text (slightly changed)= : IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network. 1) Introduction section The draft says: "allow IPv4-only devices or applications to connect with IPv4 services in Internet, by means of a stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]." Do you think it would help saying "with IPv4 services in Internet over IPv6-only infrastructure"? Otherwise it sounds confusing - why do we need anything at all to help IPv4-only clients to talk to IPv6-only services? [Jordi] Yep, tks! 2) ""This allows to translate the IPv6-only flow back to IPv4, in order to forward it to Internet." I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used extensively in the draft. [Jordi] Yep, tks! Reviewed across all the doc. 3) "In both cases (NAT46 and NAT64), the translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 addresses following [RFC6052]." IMHO this text would be more readable if we split it in two sentences: " In both cases (NAT46 and NAT64), the translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] . Translation between IPv4 and IPv6 addresses is done as per RFC6052]." [Jordi] I'm sure I've read/used this text in other documents and got no com= plains, but I'm happy to change it. 4) Section 3 is called "Possible Optimisation". However it comes before the Section 4 (problem statement) and the text seems to be more about the problem. Also, the first 3 paragraphs of Section 4 (until "until "As shown in the Figure 4" text) seem to repeat Section 3. Shall those two sections be merged? Or am I missing anything and they are actually talking about different = things? [Jordi] This was a single longer section before, including the intro (which= explains also some of your other inputs later on), but a previous review f= rom the WG suggested to split it. I think it makes sense to keep the actual= distribution of the text, as it follows a natural reading flow, even if th= e problem statement comes "later". May be an alternative is to rename secti= on 4 as "problem statement summary" ? 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in char= ge of the synthesis of AAAA records from the A records, so they can use a NAT64, without the need of doing a double-translation by means of the NAT46/CLAT." - who are "they"? This is the first sentence of the section so not sure who you are referring to. [Jordi] Caused by the split of the section ... resolved now. 6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? [Jordi] I think it was originally just LAN's or just Dual-Stack and when ad= ding the other wording ... changed. 7) ""As it can be observed in the preceding picture, the situation is t= he same, regardless of in case of a wired network with a CE Router or a cellular network where a UE is connecting other devices (which may b= e IPv4-only or have IPv4-only apps), by means of a tethering functionality." IMHO it's a bit hard to parse...Maybe smth like: "Examples of a topology shown on the picture above includes: - a residential ISP IPv6-only access network with a dual-stack LAN behind a CPE performing NAT46 (CLAT); - IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only applications running on that UE or for traffic originated by other devices connected to the UE via tethering." [Jordi] Yep, reworded. 8) Section 5.1. Approach 1: DNS/Routing-based Solution "5.1. Approach 1: DNS/Routing-based Solution "Because the WKP is non-routable, this solution will only be possible if the CDN/cache is in the same ASN as the provider network, or somehow interconnected without routing thru" Internet." Maybe it's worth explicitly mentioning that this approach would require that the path to the destination is NOT traversing NAT64 devices. Otherwise the simple configuration of such devices 'translate everything with the destination address in the WKP' would become much more complex. [Jordi] Is there "having more specific routing prefixes", anyway, I've adde= d test to remark it. 9) Section 5.2.3 ""In normal conditions the TTL for both A and AAAA records, of a given FQDN, should be the same," I'm not sure it's the case actually and we can expect that to happen 'normally'. Do you have any references proving that point? [Jordi] I don't have in mind a reference. Tried to find it now, and no luck= , but I'm sure is the correct way. If you have different TTLs for A and AAA= A records strange things will happen to IPv4-only or IPv6-only or dual-stac= k users. Anyway, even if I'm wrong, the text we have doesn't get impacted, = because for the optimization the important one is the AAAA record, as alrea= dy indicated in the actual text. 10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs Sorry but I have difficulties understanding those two sentences. What 'existing procedures' the resolver must be using? IMHO this section would be much easier to understand if there is an example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries would be created? As most CDNs would have multiple entries, this is a key point of the pr= oposal. [Jordi] Existing procedures are either using the first RR, or shuffling amo= ng them (RFC1794). Whatever is done must be transparent to the CDNs. In fac= t, CDNs and caches usually (just done some random test to verify it) do the= round robin. What it is clear, and this what I'm trying to say, is that wh= atever is doing the CE, should not be "modified" with the optimization, be= cause the CDN is making sure that the response is good never mind it is any= of the A records or any of the AAAA records. I will try to reword the text= to make it clearer. 11) Section 5.2.8. Behavior in presence/absence of DNS64 "Furthermore, because as indicated in Section 5.2.2, the EAMT entry is not created when the service is IPv6-enabled." Is it correct? The section 5.2.2 seems to be talking about detecting IPv6 enabled services and using their AAAAs for creating EAMT entries. [Jordi] The "not" is a typo. Some wrong copy and paste. Anyway, I think I w= ill reword the full paragraphs to make it clearer and actually shorter. 12) (related to 11) The draft seems to assume that the CPE/UA knows the NAT64 prefix somehow. As it's an operational document I believe it would be beneficial to provide some guidance on how exactly the device should discover the prefix. Obviously, the operator could use RFC8781 (PREF64 RA option) or PCE. Or the device and use RFC7050. However if the device uses RFC7050 then the Section 5.2.8 shall discuss this. [Jordi] I was having in mind using RFC8585, but actually never put it, beca= use the other references (464XLAT, NAT64, etc., already have it). However n= ow I think it is a good point having a reference to RFC8781, and all the ot= her choices. 13) IMHO sections 5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should be follow each other or sections 5.2.9. might have a reference to 5.2.12. [Jordi] Ok. Moved 5.2.12 after 5.2.9. 14) Section 5.2.11 Behavior in presence of Happy Eyeballs IMHO, this section should make it explicit and very very clear: as soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs fallback to that IPv4 address becomes impossible. In case of connectivity issues with the IPv6 address used in that EAMT entry, the client would not be able to reach the destination. I feel like the draft does not discuss the impact enough. It's not about delay, it's about IPv6 becoming the only protocol to reach IPv6-enabled destinations for both dual-stack and IPv4-only hosts. Maybe it's a good thing in 2020 ;) [Jordi] I've pointed to this in the other email ... So, I think we agree on= the possible tradeoff. I will see how I can improve the text to made it cl= earer. 15) Later in that section the draft says: " So even if Happy Eyeballs is present, the fallback to IPv4-only typically, will be slower than native IPv6 itself, because the added delay in the NAT46+NAT64 translations, when not using this optimization." I think it should be saying "IPv4 would be slower", not "fallback to IPv4". So maybe smth like " 'IPv4 is expected to be slower than native IPv6 due to delays added by NAT46+NAT64. This optimization reduced that delay by eliminating the need of the second translation (NAT64)"? [Jordi] Yep. All the happy eyeballs section re-worded and made more explici= t. Note that depending on "where" the IPv6 failure is happening, IPv6 to a = destination could be failing and IPv4 still working ... see the new text. 16) The draft does not discuss the troubleshooting implication. For example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and there is an EAMT entry for 8.8.8.8. IMHO this draft needs to discuss this and potential impact on tech support procedures. [Jordi] This is already considered, either via a CLI, GUI or both, you can = configure static "invalid" entries: 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT be used and consequently no optimization performed. It may be used also for an explicit configuration (GUI, CLI, provisioning system, etc.) to disallow optimization for explicitly configured IPv4 addresses. 7. Auto/Static: When set to 1, means that this EAMT entry has been manually/statically configured, for example by means of an explicit configuration (GUI, CLI, provisioning system, etc.), so it doesn't expire with TTL. Anyway, I will add a specific section to remark it. 17) Another thing which seems to be missing is some guidelines on controlling this feature. I'd suggest adding some text about that. IMHO, the router vendors SHOULD (I'd vote for MUST even) have that optimization disabled by default. The routers MUST have a knob to turn it off if it's enabled. [Jordi] In my previous email already discussed about this. I've added this = text: Note that this optimization MUST NOT be enabled when the WAN link is IPv4-only or dual-stack. In other words, only can be enabled if the WAN link is IPv6-only and consequently, the NAT46/CLAT is enabled in the CE 18) Acknowledgements Section Pls remove "....and TBD". [Jordi] I usually keep it open for last minute contributors, and the RFC ed= itor close it (and they order them alphabetically, etc.). Done now. --=20 SY, Jen Linkova aka Furry ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sat Jul 11 05:34:10 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EBF3A0EA4; Sat, 11 Jul 2020 05:34:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <159447084891.12202.7385089345894802719@ietfa.amsl.com> Date: Sat, 11 Jul 2020 05:34:08 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 12:34:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 11 06:46:57 2020 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 C609D3A0E71 for ; Sat, 11 Jul 2020 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKGzr7J4Jz13 for ; Sat, 11 Jul 2020 06:46:50 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4818A3A0D9C for ; Sat, 11 Jul 2020 06:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594475208; x=1595080008; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=UBfTryBSvrJh0m6ryDcrPROpVsPMbaW+5q 3t6VmJvFA=; b=IEpto5Addpg9bGqXEa4adOK2Dw+ZZJJUY/82RZ0HVAJygz8NOM 3fOzWxKY1NcMb5FRlV0Mxh5RXBxyFx21+47UwoqTEptkPc1FxURq5kzovBt0+ISt N8KxO9NDJjQN8z0zQ4t1BR26gK38r8uaEGZxWv4cBYDAV44Eb2Ws+QLiI= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 11 Jul 2020 15:46:48 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 11 Jul 2020 15:46:45 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000273799.msg for ; Sat, 11 Jul 2020 15:46:45 +0200 X-MDRemoteIP: 2001:470:1f09:495:a52a:88d6:d109:151a X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sat, 11 Jul 2020 15:46:45 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1461d49966=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Sat, 11 Jul 2020 15:46:42 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] - pre-(shepherd-writeup) review References: <5F769CAC-CB49-4B35-A7AB-78DEE4B6EF81@consulintel.es> <9835676c-6b3b-0660-2916-4b71c15f9264@hit.bme.hu> In-Reply-To: <9835676c-6b3b-0660-2916-4b71c15f9264@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3677327202_419371489" Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 13:46:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3677327202_419371489 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Tks Gabor, =20 I already knew about the ICANN one. =20 I=E2=80=99m going to take a look to the other one, in case I need to change= some wording in the document, the even if the CEs support DNSSEC the main = issue is the CDNs. =20 Regards, Jordi @jordipalet =20 =20 =20 El 11/7/20 11:46, "v6ops en nombre de Lencse G=C3=A1bor" escribi=C3=B3: =20 Hi Jordi, I have done a quick google search and found a 12 years old ICANN report wit= h the following conclusion: As a consequence, we conclude that just 6 units (25%) operate with full DNS= SEC compatibility "out of the box." 9 units (37%) can be reconfigured to by= pass DNS proxy incompatibilities. Unfortunately, the rest (38%) lack reconf= igurable DHCP DNS parameters, making it harder for LAN clients to bypass th= eir interference with DNSSEC use. Source: https://www.icann.org/en/system/files/files/sac-035-en.pdf I hope that the situation has improved a lot since then. =20 I have also found 2 years old CZ.NIC presentation: https://static.ptbl.co/s= tatic/attachments/169316/1520904408.pdf But I do not know, how representative it is. Best regards, G=C3=A1bor 2020.07.11. 11:23 keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta: Hi Jen, =20 I've tried to find information about: =20 1) DNSSEC support in CPEs. 2) DNSSEC support in CDNs. =20 It seems that neither of them is common. =20 In the case of the CDNs, it seems that the at least some of them, use dynam= ic mapping instead of anycast. This will mean that having DNSSEC signatures= in advance to the server assigned to each "customer" will need to be done = in real-time, which is too expensive. When anycast is used, then they can b= e pre-computed.=20 =20 I'm happy to hear otherwise from the WG. =20 So, if someone can provide some details of both aspects, we could consider = it. =20 Regards, Jordi @jordipalet =20 =C2=A0 =20 =EF=BB=BFEl 10/7/20 13:30, "v6ops en nombre de JORDI PALET MARTINEZ" escribi=C3=B3: =20 =C2=A0=C2=A0=C2=A0 Hi Jen, =20 =20 =C2=A0=C2=A0=C2=A0 =EF=BB=BFEl 10/7/20 9:53, "Jen Linkova" escribi=C3=B3: =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Fri, Jul 10, 2020 at 5:18 PM = JORDI PALET MARTINEZ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wro= te: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On this specific one, if the a= ttacker spoof the DNS response, it will be able to create an invalid EAMT e= ntry, so the client behind the NAT using that destination will not reach wh= at it wanted to reach. This is not different if it happens without an EAMT. =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I believe it's different. The di= fference here is that invalid EAMT =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 entry would affect *all* devices= behind the CPE. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let's consider an example: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - I have a CPE which has that op= timization enabled. I have 5 devices =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at home, all of them are smart a= nd using DNSSEC even. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Now one of them sent a A query= for www.example.com. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - The CPE sent an AAAA which got= spoofed. The invalid EAMT entry is created. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Now none of the devices could = reach www.example.com, despite the =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0fact that 4 of them maybe using = DNSSEC and/or 3rd party DNS servers. =20 =C2=A0=C2=A0=C2=A0 [Jordi] If instead of the spoofing the AAAA, it is spoof= ed the A or even the AAAA (without this optimization), the result is the sa= me. In my opinion it all depends on how and "where" the attack occurs, beca= use the DNS cache may be poisoned in the CPE or the hosts, etc. As said, I'= ve no problem to mention it, but I think is not clear if it is worst or not= , it very much depends on how and where the attach is performed. =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is actually related to my p= oint about 'when/how this feature gets =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enabled'.=C2=A0 It's not just mu= st be explicitly enabled by an operator, it =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST be disabled if the roiter d= oes not have IPv6 connectivity on the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uplink (and the question is 'how= to define that'). =20 =C2=A0=C2=A0=C2=A0 [Jordi] This nullifies the full purpose of the optimizat= ion. The idea is that the optimization is performed as easy and automatical= ly as possible if the WAN is IPv6-only. I will say in the other way around.= If, in an extreme situation, an operator has any "big" trouble with this o= ptimization, they will use TR-069 or whatever to disable it by default. Cle= arly the optimization will be only enabled by the CPE if it is using 464XLA= T because it has IPv6-only WAN. I'm happy to add a sentence or even a secti= on to clarify that, but for me an optimization for 464XLAT only works if 46= 4XLAT is working, not otherwise! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Having the same result as a re= gular DNS spoofing, should I mention it in the security considerations? May= be indicating that it is the same kind of attack as a DNS spoofing without= the EAMT entry, so it is not a new security risk. =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The impact is much higher as it = would affect all devices, incl.ones =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which might not be even using th= at CPE as a resolver. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Shall this feature only be used = if the CPE is capable of DNSSEC? =20 =C2=A0=C2=A0=C2=A0 [Jordi] I don't see the relevance of DNSSEC in the CPE h= ere. What I'm missing? I understand that if validation of DNSSEC is present= and the RR have been spoofed then the CPE *already* will discard them, bec= ause it just discovered that the DNSSEC validation is failing. Right? =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We must be really careful here a= s what you are proposing basically =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nullifies Happy Eyeballs and mig= ht force content providers to go back =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to IPv4. =20 =C2=A0=C2=A0=C2=A0 [Jordi] In my experience, in an IPv6-only environment Ha= ppy Eyeballs doesn't "solve" most of the cases. Let's see: =C2=A0=C2=A0=C2=A0 1) If the IPv6-only link or part of the IPv6-only networ= k is broken inside the operator, IPv4 will not work as well. So, HE will on= ly add delay in detecting the problem (the Resolution Delay). =C2=A0=C2=A0=C2=A0 2) If the IPv6 connectivity is broken outside the operat= or network, in most of the cases, IPv4 may be broken as well. =C2=A0=C2=A0=C2=A0 3) I agree that there may be cases where the IPv6 connec= tivity is broken outside the operator network and IPv4 is working, and a ve= ry typical example was when a www owner sets an AAAA record, not having IPv= 6 connectivity. This happen less and less often. =20 =C2=A0=C2=A0=C2=A0 **** However as explained in section 5.2.11, happy eyeba= lls it is only available in dual-stack hosts. =20 =C2=A0=C2=A0=C2=A0 A dual-stack hosts, normally, will not create the EAMT e= ntry, neither use it (if it was created already by an IPv4-only host access= ing the same FQDN). =20 =C2=A0=C2=A0=C2=A0 There may be an extreme case, where an IPv4-only hosts c= reates the EAMT entry, and then a dual-stack host, talking to the same dest= ination, using HE, because suddenly the IPv6 connectivity fails, falls back= to IPv4. In this case, the dual-stack host will be using the optimization.= It may be in the case 1 or 2 above. HE with or without optimization is not= resolving the problem. =20 =C2=A0=C2=A0=C2=A0 If we are in case 3 above, then is not a good thing that= IPv4 is failing considering that we are in an IPv6-only operator? =C2=A0=C2=A0=C2=A0 It is acceptable that dual-stack networks/services don't= realize that IPv6 is not working? =C2=A0=C2=A0=C2=A0 If there are IPv6-only hosts (example a NAT64+DNS64 inst= ead of 464XLAT, in the same operator or others), they will not reach the de= stination, because HE will not help them, right? =C2=A0=C2=A0=C2=A0 So, is this an acceptable trade-off? =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > I will try to respond to the o= ther later on in the morning, and if needed update the last version with th= e relevant clarifications. =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank you! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =EF=BB=BFEl 10/7/20 9:04, "Jen= Linkova" escribi=C3=B3: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Oh I f= orgot to add one more thing: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 - The = Security Considerations section states that "This document does =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 not ha= ve any new specific security considerations, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 besides the ones already known for DNS64.". =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0=C2=A0=C2=A0I'm no= t sure it's the case. The proposed approach drastically =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 amplif= ies DNS poisoning impact. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 If the= attacker manages to spoof the DNS response the CPE would create =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 an EAM= T entry which would affect *all* traffic to that destination, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 even f= or devices/applications behind that CPE which might be using =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 DNSSEC= . This could create DoS attack vector and force CDN operators to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 turn o= ff IPv6 for their caches. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 I beli= eve that should be discussed in more detail. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 On Fri= , Jul 10, 2020 at 1:58 PM Jen Linkova wrote: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > OK, = I"ve read the document and before I finish the write up I'd like =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > to d= iscuss a number of comments I have. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > My a= pologies for not raising them during the WGLC - I was not paying =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > atte= ntion, got busy with work... =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 0) I= might need coffee but I found the Abstract a bit confusing so if =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I ma= y suggest some text.. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > ""IP= /ICMP Translation Algorithm (SIIT) can be used to provide access =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > for = IPv4-only devices or applications to IPv4-only or dual-stack =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > dest= inations over IPv6-only infrastructure. In that case the traffic =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > flow= s are translated twice: first from IPv4 to IPv6 (at the ingress =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > poin= t to then IPv6-only network) and then from IPv6 back to IPv4 at =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the = egress point.=C2=A0 If the destination is IPv6-enabled that second =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > tran= slation might not be required. This document describes some =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > opti= mization to 464XLAT and MAP-T deployments to avoid translating IP6 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > flow= s back to IPv4 if the destination is reachable over IPv6. The =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > prop= osed solution would significantly reduce the NAT64 utilisation in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the = operator's network" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 1) I= ntroduction section =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > The = draft says: "allow IPv4-only devices or applications to connect =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > with= IPv4 services in Internet, by means of a =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as des= cribed =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > by= =C2=A0 [RFC7915]." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Do y= ou think it would help saying=C2=A0 "with IPv4 services in Internet =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > over= IPv6-only infrastructure"?=C2=A0 Otherwise it sounds confusing - why =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > do w= e need anything at all to help IPv4-only clients to talk to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6= -only services? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 2) "= "This allows to translate the IPv6-only flow back to IPv4, in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > orde= r to forward it to Internet." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I'm = not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv4= ...I think the terms 'IPv6-only' and 'IPv4-only flows' are used =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > exte= nsively in the draft. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 3) "= In both cases (NAT46 and NAT64), the translation of the packet =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 headers is done using the IP/ICMP translation algorithm def= ined in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 [RFC7915] and algorithmically translating the IPv4 addresse= s to IPv6 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 addresses following [RFC6052]." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO= this text would be more readable if we split it in two sentences: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > " In= both cases (NAT46 and NAT64), the translation of the packet =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 headers is done using the IP/ICMP translation algorithm def= ined in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 [RFC7915] . Translation between IPv4 and IPv6 addresses is = done as =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > per = RFC6052]." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 4) S= ection 3 is called "Possible Optimisation". However it comes =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > befo= re the Section 4 (problem statement) and the text seems to be more =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > abou= t the problem. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Also= , the first 3 paragraphs of Section 4 (until "until "As shown in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the = Figure 4" text) seem to repeat Section 3. Shall those two sections =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > be m= erged? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 =C2=A0> Or a= m I missing anything and they are actually talking about different things? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 5) "= In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > of t= he synthesis of AAAA records from the A records, so they can use =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 a NAT64, without the need of doing a double-translation by = means of =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 the NAT46/CLAT." - who are "they"?=C2=A0 This is the first = sentence of =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the = section so not sure who you are referring to. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 6) F= ig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 7) "= "As it can be observed in the preceding picture, the situation is the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 same, regardless of in case of a wired network with a CE Ro= uter or a =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 cellular network where a UE is connecting other devices (wh= ich may be =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 IPv4-only or have IPv4-only apps), by means of a tethering =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 functionality." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO= it's a bit hard to parse...Maybe smth like: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > "Exa= mples of a topology shown on the picture above includes: =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > - a = residential ISP IPv6-only access network with a dual-stack LAN =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > behi= nd a CPE performing NAT46 (CLAT); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > - IP= v6-only mobile ISP network when a UE performs CLAT for IPv4-only =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > appl= ications running on that UE or for traffic originated by other =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > devi= ces connected to the UE via tethering." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 8) S= ection 5.1. Approach 1: DNS/Routing-based Solution =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > "5.1= . Approach 1: DNS/Routing-based Solution =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > "Bec= ause the WKP is non-routable, this solution will only be possible =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 if the CDN/cache is in the same ASN as the provider network= , or =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 somehow interconnected without routing thru" Internet." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Mayb= e it's worth explicitly mentioning that this approach would =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > requ= ire that the path to the destination is NOT traversing NAT64 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > devi= ces. Otherwise the simple configuration of such devices 'translate =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > ever= ything with the destination address in the WKP' would become much =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > more= complex. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 9) S= ection 5.2.3 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > ""In= normal conditions the TTL for both A and AAAA records, of a given =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0=C2=A0=C2=A0> FQDN= , should be the same," =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I'm = not sure it's the case actually and we can expect that to happen =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 'nor= mally'. Do you have any references proving that point? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 10) = Section 5.2.7. Behavior in case of multiple A/AAAA RRs =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Sorr= y but I have difficulties understanding those two sentences. What =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 'exi= sting procedures'=C2=A0 the resolver must be using? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO= this section would be much easier to understand if there is an =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > exam= ple: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > woul= d be created? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > As m= ost CDNs would have multiple entries, this is a key point of the proposal. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 11) = Section 5.2.8. Behavior in presence/absence of DNS64 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > "Fur= thermore,=C2=A0 because as indicated in Section 5.2.2, the EAMT entry =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > is n= ot created =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 when the service is IPv6-enabled." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Is i= t correct? The section 5.2.2 seems to be talking about detecting =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6= enabled services and using their AAAAs for creating EAMT entries. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 12)= =C2=A0 (related to 11) The draft seems to assume that the CPE/UA knows =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the = NAT64 prefix somehow. As it's an operational document I believe it =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > woul= d be beneficial to provide some guidance on how exactly the device =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > shou= ld discover the prefix. Obviously, the operator could use RFC8781 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > (PRE= F64 RA option) or PCE. Or the device and use RFC7050. However if =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the = device uses RFC7050 then the Section 5.2.8 shall discuss this. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 13) = IMHO sections 5.2.9.=C2=A0 Behavior when using literal addresses or non =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6= -compliant APIs and 5.2.12. Behavior in case of Foreign DNS should =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > be f= ollow each other or=C2=A0 sections 5.2.9. might have a reference to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 5.2.= 12. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 14) = Section 5.2.11 Behavior in presence of Happy Eyeballs =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO= , this section should make it explicit and very very clear: as =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > soon= as an EAMT entry is created for an IPv4 address, Happy Eyeballs =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > fall= back to that IPv4 address becomes impossible. In case of =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > conn= ectivity issues with the IPv6 address used in that EAMT entry, the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > clie= nt would not be able to reach the destination. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I fe= el like the draft does not discuss the impact enough.=C2=A0 It's not =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > abou= t delay, it's about IPv6 becoming the only protocol to reach =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6= -enabled destinations for both dual-stack and IPv4-only hosts. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Mayb= e it's a good thing in 2020 ;) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 15) = Later in that section the draft says: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > " So= even if Happy Eyeballs is present, the fallback to IPv4-only =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 =C2=A0> typi= cally, will be slower than native IPv6 itself, because =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 the added delay in the NAT46+NAT64 translations, when not u= sing this =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0=C2=A0=C2=A0 optimization." =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I th= ink it should be saying "IPv4 would be slower", not "fallback to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv4= ".=C2=A0 So maybe smth like " 'IPv4 is expected to be slower than =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > nati= ve IPv6 due to delays added by NAT46+NAT64. This optimization =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > redu= ced that delay by eliminating the need of the second translation =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > (NAT= 64)"? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 16) = The draft does not discuss the troubleshooting implication. For =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > exam= ple if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > ther= e is an EAMT entry for 8.8.8.8. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO= this draft needs to discuss this and potential impact on tech =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > supp= ort procedures. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 17) = Another thing which seems to be missing is some guidelines on =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > cont= rolling this feature. I'd suggest adding some text about that. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO= , the router vendors SHOULD (I'd vote for MUST even) have that =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > opti= mization disabled by default. The routers MUST have a knob to turn =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > it o= ff if it's enabled. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 18) = Acknowledgements Section =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Pls = remove "....and TBD". =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > -- =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > SY, = Jen Linkova aka Furry =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 -- =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 SY, Je= n Linkova aka Furry =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > ******************************= **************** =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > IPv4 is over =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are you ready for the new Inte= rnet ? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > http://www.theipv6company.com =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > The IPv6 Company =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > This electronic message contai= ns information which may be privileged or confidential. The information is = intended to be for the exclusive use of the individual(s) named above and f= urther non-explicilty authorized disclosure, copying, distribution or use o= f the contents of this information, even if partially, including attached f= iles, is strictly prohibited and will be considered a criminal offense. If = you are not the intended recipient be aware that any disclosure, copying, d= istribution or use of the contents of this information, even if partially, = including attached files, is strictly prohibited, will be considered a crim= inal offense, so you must reply to the original sender to inform about this= communication and delete it. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =20 =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0SY, Jen Linkova aka Furry =20 =20 =20 =C2=A0=C2=A0=C2=A0 ********************************************** =C2=A0=C2=A0=C2=A0 IPv4 is over =C2=A0=C2=A0=C2=A0 Are you ready for the new Internet ? =C2=A0=C2=A0=C2=A0 http://www.theipv6company.com =C2=A0=C2=A0=C2=A0 The IPv6 Company =20 =C2=A0=C2=A0=C2=A0 This electronic message contains information which may b= e privileged or confidential. The information is intended to be for the exc= lusive use of the individual(s) named above and further non-explicilty auth= orized disclosure, copying, distribution or use of the contents of this inf= ormation, even if partially, including attached files, is strictly prohibit= ed and will be considered a criminal offense. If you are not the intended r= ecipient be aware that any disclosure, copying, distribution or use of the = contents of this information, even if partially, including attached files, = is strictly prohibited, will be considered a criminal offense, so you must = reply to the original sender to inform about this communication and delete = it. =20 =20 =20 =C2=A0=C2=A0=C2=A0 _______________________________________________ =C2=A0=C2=A0=C2=A0 v6ops mailing list =C2=A0=C2=A0=C2=A0 v6ops@ietf.org =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3677327202_419371489 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Tks Gabor,

 

I already knew about = the ICANN one.

 

I=E2=80=99m going to take a look to the other on= e, in case I need to change some wording in the document, the even if the C= Es support DNSSEC the main issue is the CDNs.

 

Regards,<= /p>

Jordi=

@jordipalet

 

 

 

El 11/7/20 11= :46, "v6ops en nombre de Lencse G=C3=A1bor" <v6ops-bounces@ietf.org en nombre de lencse@hit.bme.hu> escribi=C3=B3:

<= o:p> 

Hi Jordi,
=
I have done a quick google search and found a 12 years old ICANN report= with the following conclusion:

As a consequence, we conclude that just 6 = units (25%) operate with full DNSSEC compatibility "out of the box.&qu= ot; 9 units (37%) can be reconfigured to bypass DNS proxy incompatibilities= . Unfortunately, the rest (38%) lack reconfigurable DHCP DNS parameters, ma= king it harder for LAN clients to bypass their interference with DNSSEC use= .

Source: https://www.icann.org/en/system/files/files/sac-035-en.= pdf

I hope that the situation has improved a lot since then.&nbs= p;

I have also found 2 years old CZ.NIC presentation: https://stat= ic.ptbl.co/static/attachments/169316/1520904408.pdf

But I do not= know, how representative it is.

Best regards,

G=C3=A1bor

2020.07.1= 1. 11:23 keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta:

Hi Jen,
 
I've tried =
to find information about:
 
1) DNSSEC suppor=
t in CPEs.
2) DNSSEC supp=
ort in CDNs.
 <=
/o:p>
It seems that neither of them =
is common.
 
In the c=
ase of the CDNs, it seems that the at least some of them, use dynamic mappi=
ng instead of anycast. This will mean that having DNSSEC signatures in adva=
nce to the server assigned to each "customer" will need to be don=
e in real-time, which is too expensive. When anycast is used, then they can=
 be pre-computed. 
&=
nbsp;
I'm happy to hear otherw=
ise from the WG.
&nb=
sp;
So, if someone can provide=
 some details of both aspects, we could consider it.
 
Regards,
Jordi<=
o:p>
@jordipalet
 
=C2=A0
 
=EF=BB=BFEl 10/7/20 13=
:30, "v6ops en nombre de JORDI PALET MARTINEZ" <v6ops-bounces@ietf.org en nombre de jordi.palet=3D40consulintel.es@=
dmarc.ietf.org> escribi=C3=B3:
 
=C2=
=A0=C2=A0=C2=A0 Hi Jen,
<=
o:p> 
 
=C2=A0=C2=A0=C2=A0 =EF=BB=BFEl 10/7/2=
0 9:53, "Jen Linkova" <fu=
rry13@gmail.com> escribi=C3=B3:
 
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Fri, Jul 10, 2020 at 5:18 PM JOR=
DI PALET MARTINEZ
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <jordi.palet@consulintel.es> wrote:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
; On this specific one, if the attacker spoof the DNS response, it will be =
able to create an invalid EAMT entry, so the client behind the NAT using th=
at destination will not reach what it wanted to reach. This is not differen=
t if it happens without an EAMT.
 
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I believe it's different. The difference =
here is that invalid EAMT
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 entry would affect *all* device=
s behind the CPE.
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let's consider an example:<=
/pre>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 - I have a CPE which has that optimization enabled. I have 5 devices=

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 at home, all of them are smart and using DNSSEC even.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 - Now one of them sent a A query for www.example.com.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - The CPE sent an AAAA =
which got spoofed. The invalid EAMT entry is created.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - N=
ow none of the devices could reach www.e=
xample.com, despite the
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0fact that 4 of them maybe usi=
ng DNSSEC and/or 3rd party DNS servers.
 
=C2=
=A0=C2=A0=C2=A0 [Jordi] If instead of the spoofing the AAAA, it is spoofed =
the A or even the AAAA (without this optimization), the result is the same.=
 In my opinion it all depends on how and "where" the attack occur=
s, because the DNS cache may be poisoned in the CPE or the hosts, etc. As said, I've no problem to mention it, but I think is not clear if it is worst=
 or not, it very much depends on how and where the attach is performed.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thi=
s is actually related to my point about 'when/how this feature gets
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 enabled'.=C2=A0 It's not just must be explicitly enabled by an=
 operator, it
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST be disabled if the roiter does not h=
ave IPv6 connectivity on the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uplink (and the question is =
'how to define that').
 
=C2=A0=C2=A0=C2=A0 [=
Jordi] This nullifies the full purpose of the optimization. The idea is tha=
t the optimization is performed as easy and automatically as possible if th=
e WAN is IPv6-only. I will say in the other way around. If, in an extreme s=
ituation, an operator has any "big" trouble with this optimizatio=
n, they will use TR-069 or whatever to disable it by default. Clearly the o=
ptimization will be only enabled by the CPE if it is using 464XLAT because =
it has IPv6-only WAN. I'm happy to add a sentence or even a section to clar=
ify that, but for me an optimization for 464XLAT only works if 464XLAT is w=
orking, not otherwise!
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Having the same result=
 as a regular DNS spoofing, should I mention it in the security considerati=
ons? May be indicating that it is the same kind of attack as a DNS spoofing=
 without the EAMT entry, so it is not a new security risk.
=

 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The impact is mu=
ch higher as it would affect all devices, incl.ones
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which=
 might not be even using that CPE as a resolver.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Shall th=
is feature only be used if the CPE is capable of DNSSEC?
 
=C2=A0=C2=A0=C2=A0 [Jordi] I don't see the relevance of DNSSE=
C in the CPE here. What I'm missing? I understand that if validation of DNS=
SEC is present and the RR have been spoofed then the CPE *already* will dis=
card them, because it just discovered that the DNSSEC validation is failing=
. Right?
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 We must be really careful here as what you are proposing basicall=
y
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 nullifies Happy Eyeballs and might force content prov=
iders to go back
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to IPv4.
 
=C2=A0=C2=A0=C2=A0 [Jordi] In my experience, in an IPv6-only environment=
 Happy Eyeballs doesn't "solve" most of the cases. Let's see:
=C2=A0=C2=A0=C2=A0 1) If the=
 IPv6-only link or part of the IPv6-only network is broken inside the opera=
tor, IPv4 will not work as well. So, HE will only add delay in detecting th=
e problem (the Resolution Delay).
=C2=A0=C2=A0=C2=A0 2) If the IPv6 connectivity is broken outside t=
he operator network, in most of the cases, IPv4 may be broken as well.=

=C2=A0=C2=A0=C2=A0 3) I agree=
 that there may be cases where the IPv6 connectivity is broken outside the =
operator network and IPv4 is working, and a very typical example was when a=
 www owner sets an AAAA record, not having IPv6 connectivity. This happen l=
ess and less often.
 
=C2=A0=C2=A0=
=C2=A0 **** However as explained in section 5.2.11, happy eyeballs it is on=
ly available in dual-stack hosts.
 
=C2=A0=C2=
=A0=C2=A0 A dual-stack hosts, normally, will not create the EAMT entry, nei=
ther use it (if it was created already by an IPv4-only host accessing the s=
ame FQDN).
 
=C2=A0=C2=A0=C2=A0 There may be =
an extreme case, where an IPv4-only hosts creates the EAMT entry, and then =
a dual-stack host, talking to the same destination, using HE, because sudde=
nly the IPv6 connectivity fails, falls back to IPv4. In this case, the dual=
-stack host will be using the optimization. It may be in the case 1 or 2 ab=
ove. HE with or without optimization is not resolving the problem.
 
=C2=A0=C2=A0=C2=A0 If we are in case 3 above, then =
is not a good thing that IPv4 is failing considering that we are in an IPv6=
-only operator?
=C2=A0=C2=
=A0=C2=A0 It is acceptable that dual-stack networks/services don't realize =
that IPv6 is not working?
=C2=A0=C2=A0=C2=A0 If there are IPv6-only hosts (example a NAT64+DNS64 ins=
tead of 464XLAT, in the same operator or others), they will not reach the d=
estination, because HE will not help them, right?
=C2=A0=C2=A0=C2=A0 So, is this an acceptable trade=
-off?
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 > I will try to respond to the other later on in the morning, and=
 if needed update the last version with the relevant clarifications.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thank =
you!
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 > =EF=BB=BFEl 10/7/20 9:04, "Jen Linkova" <furry13@gmail.com> escribi=C3=B3:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Oh I forg=
ot to add one more thing:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 - =
The Security Considerations section states that "This document does
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 not have any new specific secu=
rity considerations,
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 besides the ones already known for DNS64.".
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >=C2=A0 =C2=A0=C2=A0=C2=A0I'm not sure it's the case. The propose=
d approach drastically
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 amp=
lifies DNS poisoning impact.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=
 If the attacker manages to spoof the DNS response the CPE would create
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 an EAMT entry which would affe=
ct *all* traffic to that destination,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 even for devices/applications behind that CPE which might be usin=
g
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 DNSSEC. This could creat=
e DoS attack vector and force CDN operators to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 turn off IPv6 for their caches.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
;=C2=A0=C2=A0=C2=A0=C2=A0 I believe that should be discussed in more detail=
.
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 O=
n Fri, Jul 10, 2020 at 1:58 PM Jen Linkova <furry13@gmail.com> wrote:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > OK, I"ve read the document and before I fin=
ish the write up I'd like
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &g=
t; to discuss a number of comments I have.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0=C2=A0=C2=A0 > My apologies for not raising them during the WGLC - I =
was not paying
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > attenti=
on, got busy with work...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &g=
t;
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 0) I might need cof=
fee but I found the Abstract a bit confusing so if
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > I may suggest some text..
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt;=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=
=C2=A0 > ""IP/ICMP Translation Algorithm (SIIT) can be used to=
 provide access
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > for IPv=
4-only devices or applications to IPv4-only or dual-stack
<=
pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 >=C2=A0=C2=A0=C2=A0=C2=A0 > destinations over IPv6-only infrastructu=
re. In that case the traffic
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=
 > flows are translated twice: first from IPv4 to IPv6 (at the ingress
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > point to then IPv6-onl=
y network) and then from IPv6 back to IPv4 at
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=
=C2=A0=C2=A0=C2=A0 > the egress point.=C2=A0 If the destination is IPv6-=
enabled that second
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > t=
ranslation might not be required. This document describes some
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > optimization to 464XLAT and MAP-T =
deployments to avoid translating IP6
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 > flows back to IPv4 if the destination is reachable over IPv6=
. The
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > proposed solutio=
n would significantly reduce the NAT64 utilisation in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
;=C2=A0=C2=A0=C2=A0=C2=A0 > the operator's network"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 > 1) Introduction section
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 > The draft says: "allow IPv4-only devices or applicat=
ions to connect
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > with IP=
v4 services in Internet, by means of a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 stateless NAT46 SIIT (IP/ICMP Translati=
on Algorithm) as described
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt; by=C2=A0 [RFC7915]."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 >
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Do you think =
it would help saying=C2=A0 "with IPv4 services in Internet<=
/pre>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > over IPv6-only infrastructure"=
;?=C2=A0 Otherwise it sounds confusing - why
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=
=C2=A0=C2=A0=C2=A0 > do we need anything at all to help IPv4-only client=
s to talk to
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6-only =
services?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 > 2) ""This allows to translate the IPv6-only flo=
w back to IPv4, in
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > orde=
r to forward it to Internet."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=
=C2=A0 >
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I'm not su=
re we can call a flow 'IPv6-only'. Flows are usually IPv6 or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv4...I think the terms 'IPv6-only' =
and 'IPv4-only flows' are used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 > extensively in the draft.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=
=C2=A0 >
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 3) "I=
n both cases (NAT46 and NAT64), the translation of the packet
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 headers is done =
using the IP/ICMP translation algorithm defined in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 [RFC7915] and algorithmical=
ly translating the IPv4 addresses to IPv6
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 addresses following [RFC6052]."=

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO this text would be more readable if we s=
plit it in two sentences:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &g=
t; " In both cases (NAT46 and NAT64), the translation of the packet
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 headers=
 is done using the IP/ICMP translation algorithm defined in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 [RFC7915] . Transla=
tion between IPv4 and IPv6 addresses is done as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > per RFC6052]."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt; 4) Section 3 is called "Possible Optimisation". However it co=
mes
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > before the Section =
4 (problem statement) and the text seems to be more
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > about the problem.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > Also, the first 3 paragraphs of Section 4 (until=
 "until "As shown in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 > the Figure 4" text) seem to repeat Section 3. Shall those two=
 sections
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > be merged?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 =C2=A0> Or am I missing anything =
and they are actually talking about different things?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
;=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 > 5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionall=
y) in charge
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > of the syn=
thesis of AAAA records from the A records, so they can use
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 a NAT64, without th=
e need of doing a double-translation by means of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 the NAT46/CLAT." - who ar=
e "they"?=C2=A0 This is the first sentence of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > the section so not sure who you are referring=
 to.
 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 >
<=
pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 >=C2=A0=C2=A0=C2=A0=C2=A0 > 6) Fig 1: Shouldn't it be 'Dual-Stack LA=
N', not 'LAN's Dual-Stack'?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 =
>
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 7) ""A=
s it can be observed in the preceding picture, the situation is the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 same, rega=
rdless of in case of a wired network with a CE Router or a
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 cellular network wh=
ere a UE is connecting other devices (which may be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 IPv4-only or have IPv4-only=
 apps), by means of a tethering
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0 functionality."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt; IMHO it's a bit hard to parse...Maybe smth like:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > "Examples of a topology shown on the pic=
ture above includes:
=C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > -=
 a residential ISP IPv6-only access network with a dual-stack LAN
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > behind a CPE performing NAT46 (=
CLAT);
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > - IPv6-only mobi=
le ISP network when a UE performs CLAT for IPv4-only
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > applications running on that UE or for traffi=
c originated by other
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > d=
evices connected to the UE via tethering."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt; 8) Section 5.1. Approach 1: DNS/Routing-based Solution
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > "5.1. Approach 1: DNS/Routing-ba=
sed Solution
=C2=A0=C2=A0=
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > "Beca=
use the WKP is non-routable, this solution will only be possible=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 if the CDN/ca=
che is in the same ASN as the provider network, or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 somehow interconnected with=
out routing thru" Internet."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 >
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Mayb=
e it's worth explicitly mentioning that this approach would
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > require that the path to the destinat=
ion is NOT traversing NAT64
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 =
> devices. Otherwise the simple configuration of such devices 'translate=

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 > everything with the de=
stination address in the WKP' would become much
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > more complex.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 >
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 9) S=
ection 5.2.3
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > "&quo=
t;In normal conditions the TTL for both A and AAAA records, of a given
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0=C2=A0=
=C2=A0> FQDN, should be the same,"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0=C2=A0=C2=A0 >
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > I=
'm not sure it's the case actually and we can expect that to happen
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 'normally'. Do you have any =
references proving that point?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 >
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 10) Section 5=
.2.7. Behavior in case of multiple A/AAAA RRs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=
=C2=A0=C2=A0=C2=A0 > Sorry but I have difficulties understanding those t=
wo sentences. What
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 'exi=
sting procedures'=C2=A0 the resolver must be using?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO this section would be much easier to und=
erstand if there is an
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=
; example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > would be created?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > As most CDNs would have mult=
iple entries, this is a key point of the proposal.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 > 11) Section 5.2.8. Behavior in presence/absence of DNS64
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > "Furthermore,=C2=A0 becaus=
e as indicated in Section 5.2.2, the EAMT entry
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > is not created
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 when the service is IPv6-enabled.&qu=
ot;
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt;=C2=A0=C2=A0=C2=A0=C2=A0 > Is it correct? The section 5.2.2 seems to =
be talking about detecting
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt; IPv6 enabled services and using their AAAAs for creating EAMT entries.<=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > 12)=C2=A0 (related to 11) The draft seems to =
assume that the CPE/UA knows
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=
 > the NAT64 prefix somehow. As it's an operational document I believe i=
t
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > would be beneficial=
 to provide some guidance on how exactly the device
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > should discover the prefix. Obviously, the op=
erator could use RFC8781
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=
; (PREF64 RA option) or PCE. Or the device and use RFC7050. However if=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > the device uses RFC7050 t=
hen the Section 5.2.8 shall discuss this.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0=C2=A0=C2=A0 >
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 1=
3) IMHO sections 5.2.9.=C2=A0 Behavior when using literal addresses or non<=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6-compliant APIs an=
d 5.2.12. Behavior in case of Foreign DNS should
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > be follow each other or=C2=A0 sections 5.2.9. mi=
ght have a reference to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 5.2.12.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0>=
=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 > 14) Section 5.2.11 Behavior in presence of Happy Eyeballs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO, this section should make =
it explicit and very very clear: as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 > soon as an EAMT entry is created for an IPv4 address, Happy =
Eyeballs
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > fallback to t=
hat IPv4 address becomes impossible. In case of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > connectivity issues with the IPv6 address used i=
n that EAMT entry, the
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=
; client would not be able to reach the destination.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > I feel like the draft does not discuss the im=
pact enough.=C2=A0 It's not
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 =
> about delay, it's about IPv6 becoming the only protocol to reach<=
/o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IPv6-enabled destinations fo=
r both dual-stack and IPv4-only hosts.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 > Maybe it's a good thing in 2020 ;)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 > 15) Later in that section the draft says:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > " So even if Happy Eyeballs is present, =
the fallback to IPv4-only
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 =C2=A0&g=
t; typically, will be slower than native IPv6 itself, because
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 the added delay =
in the NAT46+NAT64 translations, when not using this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 optimization."
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 > I think it should be saying "IPv4 would be =
slower", not "fallback to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 > IPv4".=C2=A0 So maybe smth like " 'IPv4 is expecte=
d to be slower than
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > n=
ative IPv6 due to delays added by NAT46+NAT64. This optimization=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > reduced that delay by eliminati=
ng the need of the second translation
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 > (NAT64)"?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 >
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 16) The draft=
 does not discuss the troubleshooting implication. For
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &g=
t;=C2=A0=C2=A0=C2=A0=C2=A0 > example if I'm running 'traceroute 8.8.8.8 =
from my IPv4-only host and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt; there is an EAMT entry for 8.8.8.8.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 > IMHO this draft needs to discuss this and potential impac=
t on tech
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > support proce=
dures.
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 17) Another thing which seems to be m=
issing is some guidelines on
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=
; controlling this feature. I'd suggest adding some text about that.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > IMHO, the router vendors SHO=
ULD (I'd vote for MUST even) have that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 > optimization disabled by default. The routers MUST have a=
 knob to turn
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > it off =
if it's enabled.
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > 18) Acknowledgements Sect=
ion
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > Pls remove "..=
..and TBD".
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 >=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 > --
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0 > SY, Jen Linkova aka Furry
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &=
gt;
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 --
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 SY,=
 Jen Linkova aka Furry
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 >
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > ******************************=
****************
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > IPv4 is over
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &g=
t; Are you ready for the new Internet ?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > http://www.theipv6company.com<=
/pre>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 > The IPv6 Company
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =
This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 >
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
 
 
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0SY, Jen =
Linkova aka Furry
&n=
bsp;
 
 
=C2=A0=C2=A0=C2=A0 ******************************************=
****
=C2=A0=C2=A0=C2=A0 I=
Pv4 is over
=C2=A0=C2=A0=
=C2=A0 Are you ready for the new Internet ?
=C2=A0=C2=A0=C2=A0 http://www.the=
ipv6company.com
=C2=
=A0=C2=A0=C2=A0 The IPv6 Company
 
=C2=A0=C2=
=A0=C2=A0 This electronic message contains information which may be privile=
ged or confidential. The information is intended to be for the exclusive us=
e of the individual(s) named above and further non-explicilty authorized di=
sclosure, copying, distribution or use of the contents of this information,=
 even if partially, including attached files, is strictly prohibited and wi=
ll be considered a criminal offense. If you are not the intended recipient =
be aware that any disclosure, copying, distribution or use of the contents =
of this information, even if partially, including attached files, is strict=
ly prohibited, will be considered a criminal offense, so you must reply to =
the original sender to inform about this communication and delete it.<=
/o:p>
 
 
 
=C2=A0=C2=
=A0=C2=A0 _______________________________________________
<=
pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0 v6ops mailing list=

=C2=A0=C2=A0=C2=A0 v6ops@ietf.org
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6ops
 
 
 
************=
**********************************
IPv4 is over
Ar=
e you ready for the new Internet ?
http://www.theipv6compa=
ny.com
The IPv6 Compa=
ny
 
This electronic message contains informa=
tion which may be privileged or confidential. The information is intended t=
o be for the exclusive use of the individual(s) named above and further non=
-explicilty authorized disclosure, copying, distribution or use of the cont=
ents of this information, even if partially, including attached files, is s=
trictly prohibited and will be considered a criminal offense. If you are no=
t the intended recipient be aware that any disclosure, copying, distributio=
n or use of the contents of this information, even if partially, including =
attached files, is strictly prohibited, will be considered a criminal offen=
se, so you must reply to the original sender to inform about this communica=
tion and delete it.
=
 
 
=

 
_______________________________________________<=
/pre>
v6ops mailing list
<=
pre style=3D'margin-left:35.4pt'>v6ops@ie=
tf.org
https://www.ietf.org/mailman/list=
info/v6ops
 =
;


_______________________________________________ v6ops mailing list v6o= ps@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677327202_419371489-- From nobody Sun Jul 12 18:28:35 2020 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 151D83A0651 for ; Sun, 12 Jul 2020 18:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkPI3fHJKQxs for ; Sun, 12 Jul 2020 18:28:29 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE21F3A00B3 for ; Sun, 12 Jul 2020 18:28:29 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id b25so8875801qto.2 for ; Sun, 12 Jul 2020 18:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=J5oYahyfD0AqYs4d/5O+TTxYzsGFqGsXh23g77Fa3AY=; b=KngZcrNLhAYjCT9ht6uyNhDmSZiih/g6nDp+JsT9GR+BefTEPhjMvl+jNDkuw4378T aXfdqqFPdKT+zsOT2iVGkJURr175UARKKwRxO+fCVCYqrKutnrIv4cnZkdPbKVIRBwZm QLROYKDHMb9n5m7zrbL2oFoeGNxH6Q2txjb44j+jzWJ0M01aSMEGrzC1vTonoLpLWFbG 0Lq67JeduhD79yRjlYvTOwDioaLB65kqFn7Epta2gdPJwbaChIk4BxfTA8Bglp9IQKD9 FRJqPi+k9ypwEISYrhbqDVb99fT4HkuKqGzGUsJdHcPBIRB76my7UsviIPF4OX+Touc+ ENFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=J5oYahyfD0AqYs4d/5O+TTxYzsGFqGsXh23g77Fa3AY=; b=Ccp8OH7pgyDdIC588zMnq8w0mYm7gNJUiZ0ss+3dMKxTs1mrMu6aa+t4UFznkd7aTo ehcbpmoLg0lCmE994oZ9tdfdiLnc311TWlLIX00CBlpwxJFkQHHjUvBWadD7Opv914nG vjVC3SZFK3CqhxyjaopinajHKB7zt6hlbCWen3ZiW3Z7haR9wlc9cqfdcEuF1Au/cF3b webH+z8qXfabFeg+zzqmHk0y7Auyc3vkH7fdUYYPm8FdxcNVxgPQwVIPzWY0I0l0Ko3d 2q1Nf8DJauWfhBb//Am7X6DOT0LnG5cJDKnGc3C63F5dvAG01gfD3hrI6rEzxpdV4A+D tXPg== X-Gm-Message-State: AOAM532qfsmMjoHFj8ouhGbQzVRY9T0J0KestLRNDxfRA5pGNP//NLhM IShaNYk6fjwpLtOqEmvNn2YEEedLUJN2ouIiKf5EuOmi X-Google-Smtp-Source: ABdhPJxVekQZuMJLdeSril83JtZkNlFCdptHBd/zhRAzRBTx69i6Zs4fiVVPbjPuV/HDaIzpdhngn6C9pXkmN7OpQ+U= X-Received: by 2002:ac8:4e2d:: with SMTP id d13mr83635018qtw.52.1594603708629; Sun, 12 Jul 2020 18:28:28 -0700 (PDT) MIME-Version: 1.0 References: <54063D84-E5A2-4149-8800-CD0FB3C58A3C@consulintel.es> In-Reply-To: <54063D84-E5A2-4149-8800-CD0FB3C58A3C@consulintel.es> From: Jen Linkova Date: Mon, 13 Jul 2020 11:28:17 +1000 Message-ID: To: JORDI PALET MARTINEZ Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] shepherd write-up for draft-ietf-v6ops-nd-cache-init: IPR status confirmation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 01:28:34 -0000 There is no IPR-related issues for that draft, however there is an IPR claim for the related draft-ietf-6man-grand: https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-6ma= n-grand On Sat, Jul 11, 2020 at 12:30 AM JORDI PALET MARTINEZ wrote: > > Hi Jen, all, > > I've been assigned as shepherd for draft-ietf-v6ops-nd-cache-init. > > I understand that not being a new protocol, and relying only in existing = RFCs, this document is not having any IPR related issues. > > Anyway, could you please confirm if you have any relevant information tha= t I should report in the write-up? > > Regards, > Jordi > @jordipalet > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Mon Jul 13 15:24:26 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF2F3A011B; Mon, 13 Jul 2020 15:24:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <159467906532.715.13664033476826329202@ietfa.amsl.com> Date: Mon, 13 Jul 2020 15:24:25 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nd-cache-init-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 22:24:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Neighbor Cache Entries on First-Hop Routers: Operational Considerations Author : Jen Linkova Filename : draft-ietf-v6ops-nd-cache-init-03.txt Pages : 12 Date : 2020-07-13 Abstract: Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document discusses how the neighbor discovery state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nd-cache-init-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nd-cache-init-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 14 04:48:26 2020 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 B37FC3A0AF7 for ; Tue, 14 Jul 2020 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvufXaPm2WD4 for ; Tue, 14 Jul 2020 04:48:23 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0993A0AF6 for ; Tue, 14 Jul 2020 04:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594727300; x=1595332100; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=H/ZG1J0DTc0S6LqZygGbi byGSgw1gNfkF/9wAYP7FzQ=; b=kU9Lg1az4+yd2l7Z0cwb4Riwn5+YadkI/se6A 8p4f34gwVX1BirLRN2iOIPRhyVtwoqDLtItHFyr1iEVBSYAC4aER6Tkktoec+nSf 2xCfKOi/KqYkpd1DFl5N1ILYkSskLOVwMffbfi2cFzgTC7YD6RF/FsM4lfrqmG39 UKh26I= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 14 Jul 2020 13:48:20 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 14 Jul 2020 13:48:19 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000280371.msg for ; Tue, 14 Jul 2020 13:48:19 +0200 X-MDRemoteIP: 2001:470:1f09:495:9e0:a103:2f17:fc6a X-MDHelo: [10.10.10.144] X-MDArrival-Date: Tue, 14 Jul 2020 13:48:19 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=146403ea97=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.38.20061401 Date: Tue, 14 Jul 2020 13:48:18 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: shepherd write-up for draft-ietf-v6ops-nd-cache-init Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] shepherd write-up for draft-ietf-v6ops-nd-cache-init X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 11:48:25 -0000 === Submitted as per RFC4858 (3.1) (1) The document aims for Information status, as indicated in the title page header. This seems appropriate as it is not describing a new protocol but instead discussing details of an existing one, problems and possible mitigations. A "companion" protocol update document exists in 6man (draft-ietf-6man-grand). (2) IESG approval announcement Technical Summary: This document discusses how the neighbor discovery (RFC4861) state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used. Working Group Summary: There were no issues during the WG process, on the other way around, consensus was clear. Document Quality: The document reports existing and know issues and several vendors have workarounds. It has been approved by v6ops, having successfully passed the last-call. Personnel: The document shepherd is Jordi Palet Martinez The responsible area director is Warren Kumari (3) Shepherd's review Before being assigned as shepherd for this document , I was already following the discussion of the document and supported adopting it as WG item. Anyway, as shepherd, I've re-read all the discussion in the mailing list, which started with the typical discussion about separating the problem statement from solution approach and if it belongs to v6ops or 6man and if it requires an errata or update to RFC4861. All has been cleared by the author, which has quickly reacted to all the inputs. I did one more complete review, sent some final typos/editorial inputs to the author, and I believe the document is ready for publication. (4) Shepherd's concerns I don't have any concerns about the depth or breadth of the reviews that have been performed. There was sufficient discussion, WG review and no objections. (5) Other Reviews I don't think any additional review is required for this document. (6) Shepherd's Concerns or issues I don't have any concerns or issues with this document. (7) IPR disclosures The author has publicly acknowledged in the WG that there are no known IPRs about this document. (8) IPRs referencing this document There are no known IPRs referencing this document, neither was any relevant discussion in the WG. There is a statement related to the companion document: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6man-grand (9) WG consensus strength The document discussion in v6ops had sufficient participation and discussion, received broad support and no objections. (10) Document conflicts There was no indication of discontent during the document progress in the WG. (11) ID nits No nits found. (12) No formal review required. (13) Document references All the document references have been correctly identified as normative and informative. (14) Normative references to other documents There is a normative reference to a companion document in 6man, ietf-6man-grand. This document has been already adopted as WG item by 6man, and at the time being, is progressing with no objections. Furthermore, it has been reported as something already implemented and tested by at least a vendor. I understand that both documents will need to be processed/published together by the RFC Editor, as it will not make too much sense to publish only this document and not ietf-6man-grand. (15) There are no conflicting downward normative references. (16) No further documents updated/obsoleted by this one. (17) No IANA reservations. (18) No IANA registries that require Expert Review. (19) No formal language. (20) No YANG modules. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Tue Jul 14 22:53:35 2020 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 9F9D03A0843; Tue, 14 Jul 2020 22:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHrLaTXyJdZW; Tue, 14 Jul 2020 22:53:30 -0700 (PDT) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511A03A0842; Tue, 14 Jul 2020 22:53:30 -0700 (PDT) Received: by mail-wm1-f65.google.com with SMTP id f18so4123789wml.3; Tue, 14 Jul 2020 22:53:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pMyK+NFN6czDhQy06Ac2/aQFcmyD62LiCLgBP5p0AP8=; b=aEsvnMHvQsZoxB9D0TRv4QyBRPA7M0iXkbd7/YSJzbXZONTpjdrPMBP9aHGeM6dZRi 3R5LkSu4YHj7yjHi4WdEoDHLpBylVkxzkly006eIE5y1Z82If8ZxpIMFknwdzwLUzTyc nFsjOwyfdDnsbvcDsK41HJdMbP+PJVeut8HCAX2akGOXW32hdw01aS/fHWtS7LgEQvEF Y8Dvpq8iiL30hKcsXoAvDUw9M5pepIri09J5MLRh1LliY0b/Y9AIUW1lEkbSEXwUj1Ex Cyy54iV4o3S5k4lB/Df+Xtm70KoKOhZ0xELlLryK5xMWocbdzvtC+M/HZbqzUzOLkUWY yXLg== X-Gm-Message-State: AOAM533n0M2tMdi/wlfhfp/5Lmrkjq820zlrlJ31HHj42Uo+MJ9pZxhF xnTnxgO0oPa1/h9Fp8hRxjFJcKt7Y6avqJRHggE= X-Google-Smtp-Source: ABdhPJxr+ivH/gVPtgwrxXc3NsY0kDeS3hXce+HP5FQ4mii2Z6zlsX21rIPU26okiUJO/x1bQ2h6zy0YRhAMRZKg7VQ= X-Received: by 2002:a7b:c92e:: with SMTP id h14mr6736638wml.36.1594792408641; Tue, 14 Jul 2020 22:53:28 -0700 (PDT) MIME-Version: 1.0 References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> In-Reply-To: From: Erik Nygren Date: Wed, 15 Jul 2020 01:53:16 -0400 Message-ID: To: Jen Linkova Cc: =?UTF-8?Q?Jordi_Palet_Mart=C3=ADnez?= , V6 Ops List , V6Ops Chairs , draft-ietf-v6ops-464xlat-optimization@ietf.org Content-Type: multipart/alternative; boundary="00000000000001f6e005aa748bc1" Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 05:53:34 -0000 --00000000000001f6e005aa748bc1 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 9, 2020 at 11:58 PM Jen Linkova wrote: > OK, I"ve read the document and before I finish the write up I'd like > to discuss a number of comments I have. > My apologies for not raising them during the WGLC - I was not paying > attention, got busy with work... > Prodded by Jen's response here I also re-read draft-ietf-v6ops-464xlat-optimization-02. (My apologies also for not raising these during WGLC -- similar excuses to Jen... ;-) While this continues to close corner-cases, I'm still concerned that there is significant possibility for breakage in a way that will result in content that is now dual-stacked getting switched to be IPv4-only. It would be good to add some examples as to why some of the invalidation logic needs to actually work (and the risk of corner cases where it doesn't). To that end, it may make sense to also have some more use of normative rfc2119 language for clearly spelling out behaviors where there are sharp edges. Some example cases of breakage or significant risk of breakage: * A site is IPv4-only (breaks for or denies all IPv6 users) but shares an A record with a dual-stack site. If this isn't detected properly, it will break users who get sent over IPv6 to the IPv4-only site. * some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address for demuxing IPv6 traffic (both to determine which cert to serve). This means that the IPv4:IPv6 associations are one to many and using the wrong one will result in cert errors. * Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one customer/tenant, but then cluster A for IPv4 and cluster C for a different customer/tenant. An stale or invalid association will result in going to the wrong cluster which may not be able to serve the request properly. While the recent revisions help some, there are still a bunch of cases where things could still break. I fear that when they do break it's not something that content providers or CDNs or their customers will debug and the result will be for content to get switched back to IPv4-only (which is not what we want happening, but will appear to "fix" issues here). I think there may also be some significant security issues not called out that are independent of the DNS spoofing issue. Another area not discussed is clients caching DNS lookups well past their TTL. This is fairly common in some clients (eg, some Java versions) which could result in entries getting expired from the EAMT but then used with a new association that should be invalid but wasn't detected as such as the first client is caching well past the expiry. Some other specific concerns on parts of the doc: > 5.2.1 Detection of IPv4-only hosts or applications > It needs to be remarked that, if the detection of the IPv4-only > device or application is done incorrectly (either not detecting it > or by a false detection), no harm is caused. I'm not sure that "no harm is caused" is always the case. There may be harm due to cases such as a client no longer able to fall back to the IPv4 address it would have used in a Happy Eyeballs setup. (ie, connectivity is discussed extensively here, but application-level breakage due to some of the issues mentioned above may not be possible to recover from). ========= > 5.2.1 Detection of IPv4-only hosts or applications Will Android doing synchronous A/AAAA lookups break this detection? and does this impact other things like STBs built on Android? Android does one of the A or AAAA lookups, waits for it to return, then does the other. From the perspective of the CPE resolver, could look like an IPv4-only host and just always introduce the 50ms delay? Some more details may be needed here on the timing heuristics needed to detect various scenarios like this. ===== > 5.2.3 > 4. TTL > "In normal conditions the TTL for both A > and AAAA records, of a given FQDN, should be the same, so this > ensures a proper behavior if there is any DNS mismatch." Actually if the resolver is a forwarding resolver talking to the ISP's recursive resolver then it is likely the TTLs returned will have degraded some and will be different. For example, if a CDN is using a 60s TTL then it is likely that the A RRset could have 12s remaining while the AAAA RRset has 48s remaining. Using the minimum of the two TTLs is likely better than assuming they will match. It may make sense to keep track of EAMT records somewhat past their TTL to handle clients caching things longer as well as race conditions. For example, add a "stale" state which can convert to "invalid" but won't get used for new connections and which entries stay in for some amount of time past expiry. Nit: Is this really an "expiry time" rather than a "TTL"? While mentioned later, it would be good to emphasize that invalidating or expiring EAMT entries MUST NOT break existing connections. (ie, that the 5.2.4 behavior is absolutely required.) Implementations getting this wrong would be really bad in-terms of breaking dual-stack content while IPv4-only content would keep working (ie, due to the lack of associations). Hurting reliability for dualstack content relative to IPv4-only content would be bad. Also not covered here is clients caching A/IPv4 lookups for extended time. For example, the EAMT entry may have expired but client may have A record cached and then another mismatching EAMT entry might get created for a different FQDN. ======= > 5.2.6. > "The existing EAMT entry for 192.0.2.1 is set as invalid". Clarify that: * 5. Existing connections to 192.0.2.1 remapped to 2001:db8::a:b:c:d MUST NOT be broken. ======= > 5.2.7. Behavior in case of multiple A/AAAA RRs Agreed with Jen's earlier comment that this needs more clarification. Example algorithm: * For each A record on the A RRset, create an EAMT entry with a randomly selected record from the AAAA RRset. * Resolver should ideally randomly permute the A RRset prior to returning to the client ========== > 5.2.10 Behavior in case of Foreign DNS How will the mismatches that should trigger invalidations get detected in this case? * Breakage due to as mismatches won't be detected and result in invalidations if one device or app is doing lookups via this resolver but another is not. Constraining the EAMT entry to the IPv4 client IP could at least bound the damage to a single device, but not if some apps on it use different resolver schemes. * I believe Google ships Chromecast to hardcode DNS lookups to 8.8.8.8 in addition to also sometimes using the local resolver. Some other STBs and mobile apps do the same. This has significant potential for mismatches to not get detected and not get invalidated. ================ > 5.2.13. Troubleshooting Implications How do corner-cases around collisions where EAMT entries don't get proprerly invalidated get debugged by the ISP (and content provider!)? This is opaque to the CDN and could result in lots of escalations from end-users and customers. The net result will be for content to get switched to IPv4-only if that "fixes" the problem which might impact users world-wide. (Neither the CDN or their customer has any visibility into what is going on here other than that some end users may be reporting not being able to view dual-stacked content.) ============ General for 5.2.x: * Should this doc use more normative language in places where warranted? (There are a bunch of MUST NOT sharp edges.) Especially in 5.2.4. * Clarify that EAMT table updates MUST be made before A record is returned to the client (especially invalidations!). Otherwise there is a potential race condition. * What happens if the FQDNs mismatch but the A and AAAA RRsets are identical? This is going to be very common as many CDNs use lots of names with a smaller number of IPv4 addresses. What if the A and AAAA RRsets overlap but aren't identical? (Perhaps the EAMT entry MUST be marked invalid if the FQDNs mismatch and the EAMT entry does not have both its A *and* AAAA values in the returned RRsets. ie, all EAMT entries must be valid within the mismatching FQDN.) (May still be corner cases here I'm forgetting?) * We have a recommended maximum cap/threshold on the TTL? (even if it's something like 8 hours...) Otherwise bad entries might stick around too long. ========== Additional security considerations: (The first of these is minor --- the others seem like they make this too dangerous to deploy. It may be worth having a Security AD do some focused review in this context.) * Filling EAMT table with very long TTL records. (ie, triggering a client to do DNS lookups that create lots of long-lived associations) * There is an serious risk exposure to hijacking traffic by inserting bogus binding (ie, return target's A record and malicious actor's AAAA record). In most cases these records should get marked as Invalid, but the corner cases here are fragile (eg, with foreign DNS or clients caching past the TTL mixed in here. An example attack here is that a client has an A record for "www.example.com" pointing to 192.0.2.1 cached past its TTL so the EAMT record is gone. An attacker convinces another user in the same home network to do a DNS lookup that has an A record of 192.0.2.1 (which the attacker doesn't own) but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled). Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never existed then the attacker can redirect all traffic to it to an IPv6 address of their choice. No DNS spoofing is needed here at all, just making a "claim" that the A/AAAA are associated (which has no authentication). This is potentially worse as I'd hypothesize that IPv4-only STB clients are much less likely to use HTTPS/TLS. * This previous risk is particularly problematic for hijacking traffic from users/devices/clients using Foreign DNS since they won't create EAMT entries but will be exposed to clients getting tricked into creating them. (This cCould be especially problematic for users using DoH for privacy on one device, but then another device in their home allows them to be hjijacked. At some point Firefox preferred IPv4 in some cases when using DoH so this may be a real exposure / vulnerability risk.) Sorry again for not sending these earlier --- I think a bunch of these concerns were raised in my previous feedback and while this version has made significant improvements, I'm still very concerned that it will be very risky from an operational fragility and security perspective. Erik --00000000000001f6e005aa748bc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 9, 2020 at 11:58 PM Jen Linkova <furry13@gmail.com> wrote:
OK, I&qu= ot;ve read the document and before I finish the write up I'd like
to discuss a number of comments I have.
My apologies for not raising them during the WGLC - I was not paying
attention, got busy with work...

Prodded by Jen's r= esponse here I also re-read draft-ietf-v6ops-464xlat-optimization-02.
(M= y apologies also for not raising these during WGLC -- similar excuses to Je= n... =C2=A0;-)

While this continues to close corner-cases, I'm s= till concerned
that there is significant possibility for breakage in a w= ay that
will result in content that is now dual-stacked getting switched=
to be IPv4-only.

It would be good to add some examples as to why=
some of the invalidation logic needs to actually work
(and the risk = of corner cases where it doesn't).
To that end, it may make sense to= also have some more
use of normative rfc2119 language for clearly spell= ing out behaviors
where there are sharp edges.

Some example cases= of breakage or significant risk of breakage:
* A site is IPv4-only (bre= aks for or denies all IPv6 users) but shares an A record with a dual-stack = site.=C2=A0 If this isn't detected properly, it will break users who ge= t sent over IPv6 to the IPv4-only site.
* some CDNs use TLS SNI for demu= xing IPv4 traffic but the IPv6 address for demuxing IPv6 traffic (both to d= etermine which cert to serve).=C2=A0 This means that the IPv4:IPv6 associat= ions are one to many and using the wrong one will result in cert errors.* Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one cust= omer/tenant, but then cluster A for IPv4 and cluster C for a different cust= omer/tenant.=C2=A0 An stale or invalid association will result in going to = the wrong cluster which may not be able to serve the request properly.
<= br>While the recent revisions help some, there are still a bunch of caseswhere things could still break.=C2=A0 I fear that when they do break it&#= 39;s
not something that content providers or CDNs or their customers wil= l
debug and the result will be for content to get switched back
to IP= v4-only (which is not what we want happening, but will
appear to "f= ix" issues here).

I think there may also be some significant se= curity issues not called out
that are independent of the DNS spoofing is= sue.

Another area not discussed is clients caching DNS lookups well = past
their TTL.=C2=A0 This is fairly common in some clients (eg, some Ja= va versions)
which could result in entries getting expired from the EAMT= but then used
with a new association that should be invalid but wasn= 9;t detected as such
as the first client is caching well past the expiry= .

Some other specific concerns on parts of the doc:

> 5.2.= 1 Detection of IPv4-only hosts or applications
> It needs to be remar= ked that, if the detection of the IPv4-only
> device or application i= s done incorrectly (either not detecting it
> or by a false detection= ), no harm is caused.

I'm not sure that "no harm is caused&= quot; is always the case.
There may be harm due to cases such as a clien= t no longer
able to fall back to the IPv4 address it would have used
= in a Happy Eyeballs setup. =C2=A0(ie, connectivity is discussed extensively=
here, but application-level breakage due to some of the issues
menti= oned above may not be possible to recover from).

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

> 5.2.1 =C2=A0Detection of IPv4-only hosts or applicati= ons

Will Android doing synchronous A/AAAA lookups break this
dete= ction? =C2=A0and does this impact other things like STBs built on
Androi= d?=C2=A0 Android does one of the A or AAAA lookups, waits for it
to retu= rn, then does the other.=C2=A0 From the perspective of the CPE resolver,could look like an IPv4-only host and just always introduce the 50ms delay= ?

Some more details may be needed here on the timing heuristics need= ed
to detect various scenarios like this.


=3D=3D=3D=3D=3D
=
> 5.2.3
> 4. TTL
> =C2=A0 =C2=A0"In normal conditio= ns the TTL for both A
> =C2=A0 =C2=A0 =C2=A0 and AAAA records, of a g= iven FQDN, should be the same, so this
> =C2=A0 =C2=A0 =C2=A0 ensures= a proper behavior if there is any DNS mismatch."

Actually if t= he resolver is a forwarding resolver talking
to the ISP's recursive = resolver then it is likely the TTLs
returned will have degraded some and= will be different.
For example, if a CDN is using a 60s TTL then it is = likely
that the A RRset could have 12s remaining while the AAAA RRsethas 48s remaining.

Using the minimum of the two TTLs is likely bett= er than assuming they will match.

It may make sense to keep track of= EAMT records somewhat past their
TTL to handle clients caching things l= onger as well as race conditions.
For example, add a "stale" s= tate which can convert to "invalid" but won't
get used for= new connections and which entries stay in for some amount
of time past = expiry.

Nit: Is this really an "expiry time" rather than a= "TTL"?
While mentioned later, it would be good to emphasizethat invalidating or expiring EAMT entries MUST NOT
break existing con= nections. =C2=A0(ie, that the 5.2.4 behavior
is absolutely required.) = =C2=A0Implementations getting this wrong
would be really bad in-terms of= breaking dual-stack content
while IPv4-only content would keep working = (ie, due to
the lack of associations). =C2=A0 Hurting reliability for du= alstack
content relative to IPv4-only content would be bad.

Also = not covered here is clients caching A/IPv4 lookups for extended time.
Fo= r example, the =C2=A0EAMT entry may have expired but client may have A reco= rd
cached and then another mismatching EAMT entry might get created for = a
different FQDN.
=3D=3D=3D=3D=3D=3D=3D

> 5.2.6.
> &q= uot;The existing EAMT entry for 192.0.2.1 is set as invalid".

C= larify that:
* 5. Existing connections to 192.0.2.1 remapped to 2001:db8= ::a:b:c:d
=C2=A0 MUST NOT be broken.

=3D=3D=3D=3D=3D=3D=3D
> 5.2.7.=C2=A0 Behavior in case of multiple A/AAAA RRs

Agreed wi= th Jen's earlier comment that this needs more clarification.=C2=A0 Exam= ple algorithm:

* For each A record on the A RRset, create an EAMT en= try with a randomly
=C2=A0 selected record from the AAAA RRset.

*= Resolver should ideally randomly permute the A RRset prior to
=C2=A0 re= turning to the client

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

> 5.2= .10 Behavior in case of Foreign DNS

How will the mismatches that sho= uld trigger invalidations
get detected in this case?

* Breakage d= ue to as mismatches won't be detected and result in invalidations
= =C2=A0if one device or app is doing lookups via this resolver but another i= s not.
=C2=A0 Constraining the EAMT entry to the IPv4 client IP could at= least bound
=C2=A0 the damage to a single device, but not if some apps = on it use different
=C2=A0 resolver schemes.

* I believe Google s= hips Chromecast to hardcode DNS lookups to 8.8.8.8
=C2=A0 in addition to= also sometimes using the local resolver.=C2=A0 Some other STBs and mobile = apps
=C2=A0 do the same.=C2=A0 This has significant potential for mismat= ches to not get
=C2=A0 detected and not get invalidated.

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

> 5.2.13.=C2=A0 Troubl= eshooting Implications

How do corner-cases around collisions where E= AMT entries
don't get proprerly invalidated get debugged by the ISP<= br>(and content provider!)?

This is opaque to the CDN and could resu= lt in lots of escalations from
end-users and customers.=C2=A0 The net re= sult will be for content to get
switched to IPv4-only if that "fixe= s" the problem which might impact
users world-wide. =C2=A0(Neither = the CDN or their customer has any
visibility into what is going on here = other than that some end users
may be reporting not being able to view d= ual-stacked content.)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Genera= l for 5.2.x:

* Should this doc use more normative language in places= where warranted?
=C2=A0 (There are a bunch of MUST NOT sharp edges.)=C2=A0 Especially in 5.2.4.

* Clarify that EAMT table updates MUST = be made before A record
=C2=A0 is returned to the client (especially inv= alidations!).=C2=A0 Otherwise there
=C2=A0 is a potential race condition= .

* What happens if the FQDNs mismatch but the A and AAAA RRsets are= identical?
This is going to be very common as many CDNs use lots of nam= es
=C2=A0with a smaller number of IPv4 addresses.
=C2=A0 What if the = A and AAAA RRsets overlap but aren't identical?
=C2=A0 (Perhaps the = EAMT entry MUST be marked invalid if the FQDNs mismatch
=C2=A0 and the E= AMT entry does not have both its A *and* AAAA values
=C2=A0 in the retur= ned RRsets. =C2=A0ie, all EAMT entries must be valid
=C2=A0 within the m= ismatching FQDN.)
=C2=A0 (May still be corner cases here I'm forgett= ing?)

* We have a recommended maximum cap/threshold on the TTL?
= =C2=A0 (even if it's something like 8 hours...) =C2=A0Otherwise bad ent= ries
=C2=A0 might stick around too long.

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

Additional security considerations:

(The first of thes= e is minor --- the others seem like they make this too dangerous to deploy.=
It may be worth having a Security AD do some focused review in this con= text.)

* Filling EAMT table with very long TTL records. =C2=A0(ie, t= riggering a client to
=C2=A0 do DNS lookups that create lots of long-liv= ed associations)

* There is an serious risk exposure to hijacking tr= affic by inserting bogus binding
=C2=A0 (ie, return target's A recor= d and malicious actor's AAAA record).
=C2=A0 In most cases these rec= ords should get marked as Invalid,
=C2=A0 but the corner cases here are = fragile (eg, with foreign DNS or
=C2=A0 clients caching past the TTL mix= ed in here.
=C2=A0 An example attack here is that a client has an A reco= rd
=C2=A0 for "www.example.com" pointing to 192.0.2.1 cached past
=C2=A0 its TTL so the EAMT re= cord is gone.=C2=A0 An attacker convinces
=C2=A0 another user in the sam= e home network to do a DNS lookup
=C2=A0 that has an A record of 192.0.2= .1 (which the attacker doesn't own)
=C2=A0 but a AAAA record for 200= 1:db8:eeee::eeee (which is attacker-controlled).
=C2=A0 Even if 192.0.2.= 1 is IPv4-only, if the EAMT entry has expired or never
=C2=A0 existed th= en the attacker can redirect all traffic to it to an IPv6 address
=C2=A0= of their choice.=C2=A0 No DNS spoofing is needed here at all, just making<= br>=C2=A0 a "claim" that the A/AAAA are associated (which has no = authentication).
=C2=A0 This is potentially worse as I'd hypothesize= that IPv4-only STB
=C2=A0 clients are much less likely to use HTTPS/TLS= .

* This previous risk is particularly problematic for hijacking tra= ffic from
=C2=A0 users/devices/clients using Foreign DNS since they won&= #39;t create
=C2=A0 EAMT entries but will be exposed to clients getting = tricked into creating them.
=C2=A0 (This cCould be especially problemati= c for users using DoH for privacy
=C2=A0 on one device, but then another= device in their home allows
=C2=A0 them to be hjijacked.=C2=A0 At some = point Firefox preferred IPv4 in some
=C2=A0 cases when using DoH so this= may be a real exposure
=C2=A0 / vulnerability risk.)

Sorry again= for not sending these earlier --- I think a bunch of these
concerns wer= e raised in my previous feedback and while this version
has made signifi= cant improvements, I'm still very concerned that it will
be very ris= ky from an operational fragility and security perspective.

=C2=A0 = =C2=A0 =C2=A0Erik


=C2=A0
--00000000000001f6e005aa748bc1-- From nobody Tue Jul 14 23:05:33 2020 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 286CF3A08A7 for ; Tue, 14 Jul 2020 23:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MKFIPW3Im0h for ; Tue, 14 Jul 2020 23:05:29 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0453A08A2 for ; Tue, 14 Jul 2020 23:05:29 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id a24so1616439pfc.10 for ; Tue, 14 Jul 2020 23:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=qoixcd4mNzHgB4+BXIWJRXPCmuj7NG5VDRSlBtWXvDc=; b=jUnzZmleczLxMnh9bgtAg9j3iTkl90stoBZVuiSRvG5Hdk5rpwaGBSAfxj1A2iugbi Y7O39dKUG5W9cdEeIK2dHZRJtrBKhBOXE6EKbziRfCRpTsrnT1bUXE1LoFmSSP38YXXc uKSJd1GanJCudS+DxVMeHHdrbpAdBDNhV5kdGH5a095aXEaQ2Z921flOBYPut4v+FXmV f7SNFJUV8/NHFW+H+prbelvr5fyqX0eY/x0i4QJPgb0yulmZDkUfmfJffKt9ejjsNu+i ziqxSdxLc6nusNLGwBw6Jt1u1C+QvkVVGRtm3jqbC6BUb1ycf2d/xBe3TUCxIK9jrgOJ 57AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=qoixcd4mNzHgB4+BXIWJRXPCmuj7NG5VDRSlBtWXvDc=; b=eq1qlit3GH5+YZ8qgF+csoH4Ke+/n8lcALzUoQedINSgUKZLl8RhKUc4K3o1hqQHQ6 fEwtkz3AP0hcZE/vz7VHzHoLoPKBpUW6d1Kihm/YDmiLR6/Xdee8f+hXTmWdjafAyloe 0LmZ8saL5mZz4mX6UKAVv+rBhzjlBPnVIp1mxVBVmO0HHnHXYimCOgyJQ8Jg6RzMgtlR R6dEJT9GgqGY5Oeh/Srlpmo89LNf8yWnYlkiLu50QXG0mhPQYQsE2VCjKUcDiP0XJMav s0VZSADtoO6Nn+A9Z9/OOPeynHmnUw7CelvBWrzPA74Jy8Wi82bD363W05htCwDNcAXl VxSg== X-Gm-Message-State: AOAM531ljtLXf6nTc/g8zhhhpZUp7vB7qLs2Ycv7jDH9/3aHvFjTQrKv lE9YME2yHkHIPZS6wBaiyiLbM25k8bI= X-Google-Smtp-Source: ABdhPJwUY+35oU3hmIgPDYk76cMnCtpDCKXCxOOu2ITtE3WjkuypmnfbOAIsROVg+wx9+H9t0mwE/A== X-Received: by 2002:aa7:934a:: with SMTP id 10mr7303679pfn.302.1594793128856; Tue, 14 Jul 2020 23:05:28 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::1c1e? ([2600:8802:5800:652::1c1e]) by smtp.gmail.com with ESMTPSA id io3sm834173pjb.22.2020.07.14.23.05.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2020 23:05:28 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_F03F11FA-37F1-494E-B675-4ADA3E624315" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <993155F9-D553-4B3B-A28F-495073A25A4C@gmail.com> References: To: IPv6 Operations Date: Tue, 14 Jul 2020 23:05:26 -0700 X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] Fwd: netflix and ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 06:05:31 -0000 --Apple-Mail=_F03F11FA-37F1-494E-B675-4ADA3E624315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You may enjoy reading this paper. > Begin forwarded message: >=20 > From: "Bajpai, Vaibhav" > Subject: netflix and ipv6 > Date: July 14, 2020 at 10:42:22 AM PDT > To: Nathaniel Wingard via NANOG >=20 > Hi NANOG, >=20 > We measured NETFLIX over v6 for the last couple of years. The paper > describing this research is now online, thought to share: >=20 > -- Vaibhav >=20 > A Longitudinal View of Netflix: Content Delivery over IPv6 and Content = Cache Deployments >=20 > paper: https://bit.ly/2toOGWP > slides: https://bit.ly/2ZoEpap > video: https://vimeo.com/437111302 >=20 >=20 > ------------------------------ > Vaibhav Bajpai, www.vaibhavbajpai.com --Apple-Mail=_F03F11FA-37F1-494E-B675-4ADA3E624315 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii You = may enjoy reading this paper.

Begin = forwarded message:

From: = "Bajpai, Vaibhav" <vaibhav.bajpai@tum.de>
Subject: = netflix and = ipv6
Date: = July 14, 2020 at 10:42:22 AM = PDT
To: = Nathaniel Wingard via NANOG = <nanog@nanog.org>

Hi NANOG,

We measured NETFLIX over v6 for the last couple of years. The = paper
describing this research is now online, thought to = share:

-- Vaibhav

A Longitudinal View of Netflix: Content Delivery over IPv6 = and Content Cache Deployments

paper: =   https://bit.ly/2toOGWP
slides:  https://bit.ly/2ZoEpap
video:   https://vimeo.com/437111302


------------------------------
Vaibhav Bajpai, www.vaibhavbajpai.com

= --Apple-Mail=_F03F11FA-37F1-494E-B675-4ADA3E624315-- From nobody Wed Jul 15 02:23:16 2020 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 C34E23A07E3; Wed, 15 Jul 2020 02:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWArYWtIh9Iw; Wed, 15 Jul 2020 02:23:13 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CB93A07E2; Wed, 15 Jul 2020 02:23:13 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id o38so1111690qtf.6; Wed, 15 Jul 2020 02:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7Bh8ea0219Tev5DDjyrZ7tncoO81Wszj4Rsi/KJ6NvA=; b=A6I2ogl0ge+dVRg7kJf1aGuA6uZVyCOP+N+0huACLzFZz2ytb9uzny0ZQcdDoP+/sE 7jFvkLaL3vLGAA7hoqV81L/9ZXQg5Cck+ukghJN+20Mb3xgmYAZfyWv/TRJGo/2f01L0 fFc7kQrxwbv+HJZNAIFVvYgo4XAWZSEFZrKgOCR/YNaBGuFLBoiM9CkIWGHll9XRszYc OyV+zhBR976LaTgg8ReqzovrQXl4QcuzKcO7fJoTd8M8XuR73MKaaJQCyG7z8uRMM3Qj /AECFxicUFtMlOGQhX3G7PKS8xA0BI4etWhg66OMrs9ROqIJKDosx660zkPscT1IDXYb bUdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7Bh8ea0219Tev5DDjyrZ7tncoO81Wszj4Rsi/KJ6NvA=; b=TIIWMlt7GUDiQsRcXYkEn9iQepUcvwZq44mcnTf2y7LWO4xLv9RMLNLq1gHiMx2FIC Hm4Nq0qCHzK6n/p52rbUP2NxLU9HBEnDWsxP0arIHRoSRp85v1QUWBb6evq7k/3l7X9y Dm7+zv4c7oXAX2PGMdesH9MkzHz+Rs8+vjijuimgRjy33x8GiUoprTmi0fIT6tqwzTYT uNhUHqXEsanEZzHWjkWD65pPq6Ci7XLErOX6MGhM8hib2N/pun9kfhih6g6dtlhiVEbR A30HrIYLEbaWQYaiNCoqR+sTU+Ait8d1+j/Lo7550mOe4Zrpa9gVl8i4q6emHC3TRYFJ r0fw== X-Gm-Message-State: AOAM530oVmUqhjvhTtmLrxx8AbxLVC1rniMlXWqkuScGaYg1uBs/Yo/H NoOMgJL00B/DsEoTtIUtHkJ3MgLj422LuYGHq+c= X-Google-Smtp-Source: ABdhPJz2LQ01UfhXWSkD+PNAWZSoIgGkMusHiieHdF5i6C7gghOdzEZVf+2Tyo1G2G/YhBOcW/9Ex38cZFitoYT05mo= X-Received: by 2002:ac8:4e2d:: with SMTP id d13mr9437633qtw.52.1594804992367; Wed, 15 Jul 2020 02:23:12 -0700 (PDT) MIME-Version: 1.0 References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> <0A5FD684-199C-4979-8818-36C9B3047746@consulintel.es> In-Reply-To: From: Jen Linkova Date: Wed, 15 Jul 2020 19:23:01 +1000 Message-ID: To: JORDI PALET MARTINEZ Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org, Fred Baker , warren , V6Ops Chairs , "Alejandro D'Egidio (Telecentro)" , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 09:23:15 -0000 On Fri, Jul 10, 2020 at 9:29 PM JORDI PALET MARTINEZ wrote: > [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even = the AAAA (without this optimization), the result is the same. In my opinion= it all depends on how and "where" the attack occurs, because the DNS cache= may be poisoned in the CPE or the hosts, etc. Sorry I should have clarified. The difference is that spoofing *one* DNS response would affect *all* devices behind the CPE *even* if those device are not using that CPE as a resolver and use DNS over [smth] and/or DNSSEC. My laptop might build a secure tunnel to the DNS server it's using and validate response using DNSSEC. But it does not help because my TV asked for an A RR and the corresponding AAAA was spoofed on the CPE, so now all devices in my house can not reach that IPv4 address. > This is actually related to my point about 'when/how this feature get= s > enabled'. It's not just must be explicitly enabled by an operator, i= t > MUST be disabled if the roiter does not have IPv6 connectivity on the > uplink (and the question is 'how to define that'). > > [Jordi] This nullifies the full purpose of the optimization. The idea is = that the optimization is performed as easy and automatically as possible if= the WAN is IPv6-only. I will say in the other way around. If, in an extrem= e situation, an operator has any "big" trouble with this optimization, they= will use TR-069 or whatever to disable it by default. Why can they not use TR-069 or whatever to enable it? Operators might not have CDNs in their network, they might have enough capacity etc - so they might not need the optimisation at all. >Clearly the optimization will be only enabled by the CPE if it is using 46= 4XLAT because it has IPv6-only WAN. I'm happy to add a sentence or even a s= ection to clarify that, but for me an optimization for 464XLAT only works i= f 464XLAT is working, not otherwise! I do like the update to Section 5.2, thanks for that! However IMHO the current version does not imply that the optimization is enabled only if 464X:AT is enabled. What if the device was not able to get an IPv4 address on the uplink initially but eventually DHCPv4 succeeded? Not sure there is any clear guidance for that. That's why I was thinking that letting the operator make a decision if they need this feature and enable it would make sense - those who really need would know that they shall buy routers supporting this and enable it. Those who do not care would not be negatively impacted. --=20 SY, Jen Linkova aka Furry From nobody Wed Jul 15 06:40:15 2020 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 670693A08B6; Wed, 15 Jul 2020 06:40:13 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyjEwpNLOAgm; Wed, 15 Jul 2020 06:40:11 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 08C2D3A08B0; Wed, 15 Jul 2020 06:40:11 -0700 (PDT) Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9B40B829B72D25BEDA5E; Wed, 15 Jul 2020 14:40:09 +0100 (IST) Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml736-chm.china.huawei.com (10.201.108.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 14:40:09 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 16:40:08 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 15 Jul 2020 16:40:08 +0300 From: Vasilenko Eduard To: "v6ops@ietf.org" CC: "draft-ietf-v6ops-464xlat-optimization@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness Thread-Index: AdZahX3EQd4WoMAlRH285zQQjJVudw== Date: Wed, 15 Jul 2020 13:40:08 +0000 Message-ID: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.198.141] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 13:40:13 -0000 Hi all, I have concern on the capability to use this mechanism for 464XLAT, but it = should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB traffic is still d= esignated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. active sessions = from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to squeeze (for path= to Internet it would be "source IP address") many private IPv4 hosts to on= e IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port translation is = mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearly state in the d= ocument that we are going to reuse NAPT. Then translation would be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, it could be not = public, but public A+P has been given to MAP CE anyway - better to reuse it= for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not popular - not = implemented by many carriers (if any?). It would be the big news that Carriers should choose stateful CLAT option f= or 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use Stateless CLAT for ba= sic 464XLAT and Stateful CLAT for traffic optimization to IPv4 sites? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smooth expansion for = MAP-T. Hence, does it make sense to change the name of this draft to reflect MAP-T= as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: 11 =C9=C0=CC=D1 2020 =C7. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization= -02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimization-0= 2 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. 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 From nobody Wed Jul 15 06:48:12 2020 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 C98DD3A08D8; Wed, 15 Jul 2020 06:48:10 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmFeHNGvgYaJ; Wed, 15 Jul 2020 06:48:09 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id E387C3A08EC; Wed, 15 Jul 2020 06:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1594820882; x=1595425682; i=jordi.palet@theipv6company.com; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=aNhHVHSMT2grwXx0fIVTFQwFhUSfUFQBThikVjknZrE=; b=KTpPioG5Dhp75 f9unrF7HTesOiKJw6NiG4ytqf77R1vQ56Qj1ocv0fEm9WTBAqqJowLW7j0d4uWeU TiOr5DTPu5VZ1ut8SdE/C781m4KoDdDcseiXh3HTAnigR8Q6ODxKGK/2tJNmkn63 Fji74JJZGE8x6rm2Xu7p+ulPF4NQuA= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Wed, 15 Jul 2020 15:48:02 +0200 X-Spam-Processed: consulintel.es, Wed, 15 Jul 2020 15:48:02 +0200 Received: from [10.10.10.144] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000283221.msg; Wed, 15 Jul 2020 15:48:00 +0200 X-MDRemoteIP: 2001:470:1f09:495:319c:517a:245c:1d02 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Wed, 15 Jul 2020 15:48:00 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1465cbc289=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Wed, 15 Jul 2020 15:47:58 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Vasilenko Eduard , "v6ops@ietf.org" CC: "draft-ietf-v6ops-464xlat-optimization@ietf.org" Message-ID: <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> In-Reply-To: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 13:48:11 -0000 Hi Vasilenko, The implementations of 464XLAT, can do the same (and in fact, many of them = is what they do). NAT44 stateful and the 46 stateless. Many SoC have embedd= ed NAT44 acceleration, but not NAT46, so that explains it as well. I guess that could clear your concern? I've several customers doing 464XLAT in broadband, one of them 25.000.000 s= ubscribers. There is no difference in doing 464XLAT in cellular and broadba= nd. When we say in the title 464XLAT/NAT64, I think both are covered. But I've = no issue to change the title if this makes sense to others. We could explic= tily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, in my opi= nion. =20 Regards, Jordi @jordipalet =20 =EF=BB=BFEl 15/7/20 15:40, "Vasilenko Eduard" = escribi=C3=B3: Hi all, I have concern on the capability to use this mechanism for 464XLAT, but= it should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB traffic is sti= ll designated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. active sessi= ons from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to squeeze (for = path to Internet it would be "source IP address") many private IPv4 hosts t= o one IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port translation= is mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearly state in t= he document that we are going to reuse NAPT. Then translation would be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, it could be = not public, but public A+P has been given to MAP CE anyway - better to reus= e it for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not popular - = not implemented by many carriers (if any?). It would be the big news that Carriers should choose stateful CLAT opti= on for 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use Stateless CLAT fo= r basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 sites? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smooth expansion = for MAP-T. Hence, does it make sense to change the name of this draft to reflect M= AP-T as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: 11 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.t= xt A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The propose= d solution would significantly reduce the NAT64 utilization in the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimiza= tion-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimizati= on-02 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jul 15 06:49:06 2020 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 A67663A08D8 for ; Wed, 15 Jul 2020 06:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn_VJtL-SAjI for ; Wed, 15 Jul 2020 06:49:03 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id D40EE3A0916 for ; Wed, 15 Jul 2020 06:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594820927; x=1595425727; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version: Content-type:Content-transfer-encoding; bh=USGx98w8+xGQauLRiXmQL CwQs2pGxsnhWVf3YlYcPgI=; b=hM0VCP+9PQnjpWYWeLStl8GjmV+jZv9iaZPK7 oCvKZS6yb5dcx2k5w7HMG8M3o3a1xgd2XsA0/TnimSOT3ZPue1LicwYy43Nxswal jJeP+uR749AXnVxGt0AbtGfQxV9dv4a9AgAM4oBCjFUOdSnIIgOF/OSd5dZMIV1V ozK/r0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 15 Jul 2020 15:48:47 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 15 Jul 2020 15:48:46 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000283224.msg for ; Wed, 15 Jul 2020 15:48:45 +0200 X-MDRemoteIP: 2001:470:1f09:495:319c:517a:245c:1d02 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Wed, 15 Jul 2020 15:48:45 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1465db90bd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Wed, 15 Jul 2020 15:48:45 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <9265919E-7D54-4C69-BADF-B8F055462B5A@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness In-Reply-To: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 13:49:05 -0000 Hi Vasilenko, The implementations of 464XLAT, can do the same (and in fact, many of them = is what they do). NAT44 stateful and the 46 stateless. Many SoC have embedd= ed NAT44 acceleration, but not NAT46, so that explains it as well. I guess that could clear your concern? I've several customers doing 464XLAT in broadband, one of them 25.000.000 s= ubscribers. There is no difference in doing 464XLAT in cellular and broadba= nd. When we say in the title 464XLAT/NAT64, I think both are covered. But I've = no issue to change the title if this makes sense to others. We could explic= tily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, in my opi= nion. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:40, "Vasilenko Eduard" = escribi=C3=B3: Hi all, I have concern on the capability to use this mechanism for 464XLAT, but= it should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB traffic is sti= ll designated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. active sessi= ons from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to squeeze (for = path to Internet it would be "source IP address") many private IPv4 hosts t= o one IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port translation= is mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearly state in t= he document that we are going to reuse NAPT. Then translation would be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, it could be = not public, but public A+P has been given to MAP CE anyway - better to reus= e it for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not popular - = not implemented by many carriers (if any?). It would be the big news that Carriers should choose stateful CLAT opti= on for 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use Stateless CLAT fo= r basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 sites? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smooth expansion = for MAP-T. Hence, does it make sense to change the name of this draft to reflect M= AP-T as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: 11 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.t= xt A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The propose= d solution would significantly reduce the NAT64 utilization in the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimiza= tion-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimizati= on-02 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jul 15 06:59:09 2020 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 A5CED3A092B; Wed, 15 Jul 2020 06:59:07 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0LXnexhS5Se; Wed, 15 Jul 2020 06:59:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1C5C43A0924; Wed, 15 Jul 2020 06:59:05 -0700 (PDT) Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 61EF29DAB80D959FA9C6; Wed, 15 Jul 2020 14:59:02 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 15 Jul 2020 14:59:02 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 16:59:01 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 15 Jul 2020 16:59:01 +0300 From: Vasilenko Eduard To: =?utf-8?B?Sm9yZGkgUGFsZXQgTWFydMOtbmV6?= , "v6ops@ietf.org" CC: "draft-ietf-v6ops-464xlat-optimization@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness Thread-Index: AdZahX3EQd4WoMAlRH285zQQjJVudwAD+lQAAAZ9kJA= Date: Wed, 15 Jul 2020 13:59:01 +0000 Message-ID: <0dd28c07dc82413ebac3c231a47cf038@huawei.com> References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> In-Reply-To: <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.198.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 13:59:08 -0000 SGkgSm9yZGksDQpJIHN0aWxsIGJlbGlldmUgdGhhdCB0b3VnaCAobmV3KSByZXF1aXJlbWVudCB0 aGF0IENMQVQgc2hvdWxkIGJlY29tZSBTdGF0ZWZ1bCAobWFuZGF0b3J5KQ0KTWFrZSBzZW5zZSB0 byBpbnNlcnQgaW50byB0aGUgZG9jdW1lbnQuDQoNCkFuZCBleHBsYW5hdGlvbiB3aHkgc3RhdGVm dWwgTkFQVCBpcyBuZWVkZWQgd291bGQgYmUgZ29vZC4NCkkgaGF2ZSBzcGVudCBzb21lIHRpbWUg dG8gcmVzZWFyY2ggdGhpcyAtIGl0IGlzIGJldHRlciB0byBzYXZlIHRpbWUgb2Ygb3RoZXIgcGVv cGxlLg0KSXQgaXMgaW1wb3J0YW50IHBvaW50IHRoYXQgaXMgb21pdHRlZCBpbiB0aGUgZG9jdW1l bnQuDQoNCkZvciB0aGUgbmFtZTogSSBkbyBub3QgaGF2ZSBhbnkgc3Ryb25nIG9waW5pb24uDQpK dXN0IEkgc2VlIHRoYXQgZHJhZnQgaXMgYXBwbGljYWJsZSBtb3N0bHkgdG8gTUFQLVQsDQpBbmQg bm90IG11Y2ggYXBwbGljYWJsZSB0byBYTEFUIChiZWNhdXNlIG1ham9yaXR5IG9mIGluc3RhbGxh dGlvbnMgaGF2ZSBzdGF0ZWxlc3MgQ0xBVCkuDQpCdXQgdGhlIG5hbWUgbWlzbGVhZCB0byBvcHBv c2l0ZSBjb25jbHVzaW9uLg0KDQpFZHVhcmQNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKb3JkaSBQYWxldCBNYXJ0w61uZXogW21haWx0bzpqb3JkaS5wYWxldEB0aGVpcHY2Y29t cGFueS5jb21dIA0KU2VudDogMTUg0LjRjtC70Y8gMjAyMCDQsy4gMTY6NDgNClRvOiBWYXNpbGVu a28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+OyB2Nm9wc0BpZXRmLm9yZw0K Q2M6IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb25AaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRp bWl6YXRpb24tMDIgLSBjb25jZXJuIG9uIHN0YXRlZnVsbmVzcw0KDQpIaSBWYXNpbGVua28sDQoN ClRoZSBpbXBsZW1lbnRhdGlvbnMgb2YgNDY0WExBVCwgY2FuIGRvIHRoZSBzYW1lIChhbmQgaW4g ZmFjdCwgbWFueSBvZiB0aGVtIGlzIHdoYXQgdGhleSBkbykuIE5BVDQ0IHN0YXRlZnVsIGFuZCB0 aGUgNDYgc3RhdGVsZXNzLiBNYW55IFNvQyBoYXZlIGVtYmVkZGVkIE5BVDQ0IGFjY2VsZXJhdGlv biwgYnV0IG5vdCBOQVQ0Niwgc28gdGhhdCBleHBsYWlucyBpdCBhcyB3ZWxsLg0KDQpJIGd1ZXNz IHRoYXQgY291bGQgY2xlYXIgeW91ciBjb25jZXJuPw0KDQpJJ3ZlIHNldmVyYWwgY3VzdG9tZXJz IGRvaW5nIDQ2NFhMQVQgaW4gYnJvYWRiYW5kLCBvbmUgb2YgdGhlbSAyNS4wMDAuMDAwIHN1YnNj cmliZXJzLiBUaGVyZSBpcyBubyBkaWZmZXJlbmNlIGluIGRvaW5nIDQ2NFhMQVQgaW4gY2VsbHVs YXIgYW5kIGJyb2FkYmFuZC4NCg0KV2hlbiB3ZSBzYXkgaW4gdGhlIHRpdGxlIDQ2NFhMQVQvTkFU NjQsIEkgdGhpbmsgYm90aCBhcmUgY292ZXJlZC4gQnV0IEkndmUgbm8gaXNzdWUgdG8gY2hhbmdl IHRoZSB0aXRsZSBpZiB0aGlzIG1ha2VzIHNlbnNlIHRvIG90aGVycy4gV2UgY291bGQgZXhwbGlj dGlseSBzYXkgNDY0WExBVC9OQVQ2NC9NQVAtVCBvciB3aGF0ZXZlci4gVGhpcyBpcyBhIG1pbm9y IGRldGFpbCwgaW4gbXkgb3Bpbmlvbi4NCiANClJlZ2FyZHMsDQpKb3JkaQ0KQGpvcmRpcGFsZXQN CiANCg0K77u/RWwgMTUvNy8yMCAxNTo0MCwgIlZhc2lsZW5rbyBFZHVhcmQiIDx2YXNpbGVua28u ZWR1YXJkQGh1YXdlaS5jb20+IGVzY3JpYmnDszoNCg0KICAgIEhpIGFsbCwNCiAgICBJIGhhdmUg Y29uY2VybiBvbiB0aGUgY2FwYWJpbGl0eSB0byB1c2UgdGhpcyBtZWNoYW5pc20gZm9yIDQ2NFhM QVQsIGJ1dCBpdCBzaG91bGQgYmUgZmluZSBmb3IgTUFQLVQuDQoNCiAgICBXZSBtYXkgaGF2ZSBt YW55IGhvc3RzIG9uIENQRSBMQU4uIFR5cGljYWxseSwgNzAlIG9mIEZCQiB0cmFmZmljIGlzIHN0 aWxsIGRlc2lnbmF0ZWQgdG8gSVB2NCBzaXRlcy4NCiAgICBTb3VyY2UgVURQL1RDUCBwb3J0IGNv bGxpc2lvbiBpcyBzdGlsbCB2ZXJ5IHBvc3NpYmxlIChpLmUuIGFjdGl2ZSBzZXNzaW9ucyBmcm9t IGRpZmZlcmVudCBob3N0IG1heSBoYXZlIHRoZSBzYW1lIHNvdXJjZSBUQ1AvVURQIHBvcnQpLA0K ICAgIEl0IGlzIG5vdCBzdGF0ZWQgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50LCBidXQgd2UgbmVl ZCB0byBzcXVlZXplIChmb3IgcGF0aCB0byBJbnRlcm5ldCBpdCB3b3VsZCBiZSAic291cmNlIElQ IGFkZHJlc3MiKSBtYW55IHByaXZhdGUgSVB2NCBob3N0cyB0byBvbmUgSVB2NiAoYXNzaWduZWQg YnkgY2FycmllciB0byBDUEUgdXBsaW5rKS4NCiAgICBDbGFzc2ljYWwgTjoxIHByb2JsZW0gdGhh dCBzaG91bGQgYmUgcmVzb2x2ZWQgYnkgTkFQVCAocG9ydCB0cmFuc2xhdGlvbiBpcyBtYW5kYXRv cnkpLg0KDQogICAgTUFQLVQgaGFzIE5BUFQgZW5naW5lIG9uIENQRSBzaWRlIC0gaXQgbWFrZSBz ZW5zZSB0byBjbGVhcmx5IHN0YXRlIGluIHRoZSBkb2N1bWVudCB0aGF0IHdlIGFyZSBnb2luZyB0 byByZXVzZSBOQVBULiBUaGVuIHRyYW5zbGF0aW9uIHdvdWxkIGJlOg0KICAgICgxKSBOQVBUNDQg Zm9yIG1hbnkgcHJpdmF0ZSBJUHY0IHRvIG9uZSBwdWJsaWMgSVB2NCAod2VsbCwgaXQgY291bGQg YmUgbm90IHB1YmxpYywgYnV0IHB1YmxpYyBBK1AgaGFzIGJlZW4gZ2l2ZW4gdG8gTUFQIENFIGFu eXdheSAtIGJldHRlciB0byByZXVzZSBpdCBmb3IgdW5pZmljYXRpb24pDQogICAgKDIpIFNJSVQg KHdpdGggRUFNVCkgZm9yIHNpbmdsZSBJUHY0IHRvIHNpbmdsZSBJUHY2ICgxOjEpDQoNCiAgICBY TEFUL0NMQVQgZG9lcyBoYXZlIHN0YXRlZnVsIE5BUFQgYnkgUkZDIDY4NzcsIGJ1dCBpdCBpcyBu b3QgcG9wdWxhciAtIG5vdCBpbXBsZW1lbnRlZCBieSBtYW55IGNhcnJpZXJzIChpZiBhbnk/KS4N CiAgICBJdCB3b3VsZCBiZSB0aGUgYmlnIG5ld3MgdGhhdCBDYXJyaWVycyBzaG91bGQgY2hvb3Nl IHN0YXRlZnVsIENMQVQgb3B0aW9uIGZvciA0NjRYTEFULg0KICAgIEl0IGlzIGJldHRlciB0byB0 ZWxsIHRoZW0gdXBmcm9udC4NCg0KICAgIFRoZSBuZXh0IHF1ZXN0aW9uIGNvdWxkIGJlOiBkb2Vz IGl0IG1ha2Ugc2Vuc2UgdG8gdXNlIFN0YXRlbGVzcyBDTEFUIGZvciBiYXNpYyA0NjRYTEFUIGFu ZCBTdGF0ZWZ1bCBDTEFUIGZvciB0cmFmZmljIG9wdGltaXphdGlvbiB0byBJUHY0IHNpdGVzPw0K ICAgIE9yIGl0IGlzIGJldHRlciB0byB1bmlmeSBvbiBTdGF0ZWZ1bCBDTEFUIGZvciBldmVyeXRo aW5nLg0KDQogICAgSW4gZ2VuZXJhbCwgaXQgaXMgYSByZXZvbHV0aW9uIGZvciA0NjRYTEFULiBC dXQgaXQgaXMgc21vb3RoIGV4cGFuc2lvbiBmb3IgTUFQLVQuDQogICAgSGVuY2UsIGRvZXMgaXQg bWFrZSBzZW5zZSB0byBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhpcyBkcmFmdCB0byByZWZsZWN0IE1B UC1UIGFzIHRoZSBwcmltYXJ5IHRhcmdldD8NCg0KICAgIEVkdWFyZA0KICAgIC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQogICAgU2VudDog MTEg0LjRjtC70Y8gMjAyMCDQsy4gMTU6MzQNCiAgICBUbzogaS1kLWFubm91bmNlQGlldGYub3Jn DQogICAgQ2M6IHY2b3BzQGlldGYub3JnDQogICAgU3ViamVjdDogW3Y2b3BzXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyLnR4dA0KDQoNCiAgICBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiA0NjRYTEFUL05BVDY0IE9wdGltaXphdGlvbg0KICAgICAgICAgICAgQXV0aG9y cyAgICAgICAgIDogSm9yZGkgUGFsZXQgTWFydGluZXoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEFsZWphbmRybyBEJ0VnaWRpbw0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p ZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyLnR4dA0KICAgIAlQYWdlcyAgICAgICAg ICAgOiAyMQ0KICAgIAlEYXRlICAgICAgICAgICAgOiAyMDIwLTA3LTExDQoNCiAgICBBYnN0cmFj dDoNCiAgICAgICBJUC9JQ01QIFRyYW5zbGF0aW9uIEFsZ29yaXRobSAoU0lJVCkgY2FuIGJlIHVz ZWQgdG8gcHJvdmlkZSBhY2Nlc3MNCiAgICAgICBmb3IgSVB2NC1vbmx5IGRldmljZXMgb3IgYXBw bGljYXRpb25zIHRvIElQdjQtb25seSBvciBkdWFsLXN0YWNrDQogICAgICAgZGVzdGluYXRpb25z IG92ZXIgSVB2Ni1vbmx5IGluZnJhc3RydWN0dXJlLiAgSW4gdGhhdCBjYXNlLCB0aGUNCiAgICAg ICB0cmFmZmljIGZsb3dzIGFyZSB0cmFuc2xhdGVkIHR3aWNlOiBmaXJzdCBmcm9tIElQdjQgdG8g SVB2Ng0KICAgICAgIChzdGF0ZWxlc3MgTkFUNDYgYXQgdGhlIGluZ3Jlc3MgcG9pbnQgdG8gdGhl IElQdjYtb25seQ0KICAgICAgIGluZnJhc3RydWN0dXJlKSBhbmQgdGhlbiBmcm9tIElQdjYgYmFj ayB0byBJUHY0IChzdGF0ZWZ1bCBOQVQ2NCwgYXQNCiAgICAgICB0aGUgZWdyZXNzIHBvaW50KS4g IFdoZW4gdGhlIGRlc3RpbmF0aW9uIGlzIElQdjYtZW5hYmxlZCwgdGhlIHNlY29uZA0KICAgICAg IHRyYW5zbGF0aW9uIG1pZ2h0IGJlIGF2b2lkZWQuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IHBvc3NpYmxlDQogICAgICAgb3B0aW1pemF0aW9uIHRvIDQ2NFhMQVQgYW5kIE1BUC1UIHRvIGF2 b2lkIHRyYW5zbGF0aW5nIElQdjYgZmxvd3MNCiAgICAgICBiYWNrIHRvIElQdjQgaWYgdGhlIGRl c3RpbmF0aW9uIGlzIHJlYWNoYWJsZSBvdmVyIElQdjYuICBUaGUgcHJvcG9zZWQNCiAgICAgICBz b2x1dGlvbiB3b3VsZCBzaWduaWZpY2FudGx5IHJlZHVjZSB0aGUgTkFUNjQgdXRpbGl6YXRpb24g aW4gdGhlDQogICAgICAgb3BlcmF0b3IncyBuZXR3b3JrLg0KDQoNCiAgICBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9u Lw0KDQogICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQt b3B0aW1pemF0aW9uLTAyDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyDQoNCiAgICBBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6 YXRpb24tMDINCg0KDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQogICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K ICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGlu ZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQpJUHY0IGlzIG92ZXINCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcg SW50ZXJuZXQgPw0KaHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb20NClRoZSBJUHY2IENvbXBh bnkNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2gg bWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50 ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5h bWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3Vy ZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBp bmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywg aXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwg b2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0 aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBj b250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5n IGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVy ZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwg c2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4N Cg0KDQoNCg== From nobody Wed Jul 15 07:17:35 2020 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 8573C3A0C13; Wed, 15 Jul 2020 07:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5kypJzfc8T9; Wed, 15 Jul 2020 07:17:31 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id EB8C43A0C1F; Wed, 15 Jul 2020 07:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594822648; x=1595427448; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=sOzJanpjJit7zm6AISqE6xk4Oz1Leqf/O4wWeo3LBM8=; b=O7EQAuBixDKUn uO8v1FxjXnxl4hTL9RLP3Slr81GkkHM8Iv3czyFaLUFb4L0UxVw9N6bIF8IXfB6x nbVoEyfroyddvJsFxDogiyA/kk7Q/WH5t3edDyd5LCXOcKma2P7xP/6C/6cBAy65 UB7xF+rX0itUrAgY3cZMP8ezYBA1vY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 15 Jul 2020 16:17:28 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 15 Jul 2020 16:17:26 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000283284.msg; Wed, 15 Jul 2020 16:17:26 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c99:b839:c816:17ed X-MDHelo: [10.10.10.144] X-MDArrival-Date: Wed, 15 Jul 2020 16:17:26 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1465db90bd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Wed, 15 Jul 2020 16:17:23 +0200 From: JORDI PALET MARTINEZ To: Vasilenko Eduard , "v6ops@ietf.org" CC: "draft-ietf-v6ops-464xlat-optimization@ietf.org" Message-ID: <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> In-Reply-To: <0dd28c07dc82413ebac3c231a47cf038@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 14:17:34 -0000 I think your point will be to make it clear in the document that for this o= ptimization to work, the CLAT should be stateful? I think is there (5.2.4. Forwarding path via stateful NAT for existing EAM= T entries), but I will make sure to add the relevant text in the next versi= on to make it clearer.=20 I insist: most of the CLAT implementations today (running in both CPEs and = UEs) are stateful. At least this is the data I've. =20 Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" escribi=C3=B3: Hi Jordi, I still believe that tough (new) requirement that CLAT should become St= ateful (mandatory) Make sense to insert into the document. And explanation why stateful NAPT is needed would be good. I have spent some time to research this - it is better to save time of = other people. It is important point that is omitted in the document. For the name: I do not have any strong opinion. Just I see that draft is applicable mostly to MAP-T, And not much applicable to XLAT (because majority of installations have= stateless CLAT). But the name mislead to opposite conclusion. Eduard -----Original Message----- From: Jordi Palet Mart=C3=ADnez [mailto:jordi.palet@theipv6company.com]= =20 Sent: 15 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 16:48 To: Vasilenko Eduard ; v6ops@ietf.org Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-= 02 - concern on statefulness Hi Vasilenko, The implementations of 464XLAT, can do the same (and in fact, many of t= hem is what they do). NAT44 stateful and the 46 stateless. Many SoC have em= bedded NAT44 acceleration, but not NAT46, so that explains it as well. I guess that could clear your concern? I've several customers doing 464XLAT in broadband, one of them 25.000.0= 00 subscribers. There is no difference in doing 464XLAT in cellular and bro= adband. When we say in the title 464XLAT/NAT64, I think both are covered. But I= 've no issue to change the title if this makes sense to others. We could ex= plictily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, in my= opinion. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:40, "Vasilenko Eduard" escribi=C3=B3: Hi all, I have concern on the capability to use this mechanism for 464XLAT,= but it should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB traffic is= still designated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. active s= essions from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to squeeze (= for path to Internet it would be "source IP address") many private IPv4 hos= ts to one IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port transla= tion is mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearly state = in the document that we are going to reuse NAPT. Then translation would be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, it could= be not public, but public A+P has been given to MAP CE anyway - better to = reuse it for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not popula= r - not implemented by many carriers (if any?). It would be the big news that Carriers should choose stateful CLAT = option for 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use Stateless CLA= T for basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 site= s? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smooth expans= ion for MAP-T. Hence, does it make sense to change the name of this draft to refle= ct MAP-T as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-d= rafts@ietf.org Sent: 11 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-= 02.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide acce= ss for IPv4-only devices or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64,= at the egress point). When the destination is IPv6-enabled, the se= cond translation might be avoided. This document describes a possibl= e optimization to 464XLAT and MAP-T to avoid translating IPv6 flow= s back to IPv4 if the destination is reachable over IPv6. The pro= posed solution would significantly reduce the NAT64 utilization in the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimizat= ion/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-0= 2 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-opti= mization-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimi= zation-02 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.o= rg. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jul 15 08:52:57 2020 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 B484E3A087B; Wed, 15 Jul 2020 08:52:54 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2i1MlAfYiGy; Wed, 15 Jul 2020 08:52:52 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 569913A080C; Wed, 15 Jul 2020 08:52:52 -0700 (PDT) Received: from lhreml706-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6E49557E78C29F083215; Wed, 15 Jul 2020 16:52:49 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 15 Jul 2020 16:52:49 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 18:52:48 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 15 Jul 2020 18:52:48 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ , "v6ops@ietf.org" CC: "draft-ietf-v6ops-464xlat-optimization@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness Thread-Index: AdZahX3EQd4WoMAlRH285zQQjJVudwAD+lQAAAZ9kJD//9RLgP//yulQ Date: Wed, 15 Jul 2020 15:52:48 +0000 Message-ID: <6897a420362d4caaaf24c77f7eca4e29@huawei.com> References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> In-Reply-To: <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.198.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:52:55 -0000 SGkgSm9yZGksDQpZZXMsIHRoaXMgb25lIGxvb2tzIGxpa2Ugb3V0c2lkZSBvZiBhbnkgY29udGV4 dDogDQoiIENvbnNlcXVlbnRseSwgdGhlIEVBTVQgZW50cmllcyBzaG91bGQgbm90IGJlIHVzZWQg ZGlyZWN0bHkgdG8NCiAgIGVzdGFibGlzaCBhIGZvcndhcmRpbmcgcGF0aCwgYnV0IGluc3RlYWQs IHRvIGNyZWF0ZSBhIHN0YXRlZnVsIE5BVA0KICAgZW50cnkgZm9yIHRoZSA0LXR1cGxlIGZvciB0 aGUgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24vY29ubmVjdGlvbi4gIg0KSXQgaXMgZGlmZmljdWx0 IHRvIHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBhYm91dCBtYW5kYXRvcnkgc3RhdGVmdWwgQ0xBVC4N Cg0KQWJvdXQgImV2ZXJ5Ym9keSB1c2Ugc3RhdGVmdWwgQ0xBVCI6DQpZb3VyIHByZXNlbnRhdGlv biBjbGVhcmx5IHN0YXRlICJTdGF0ZWxlc3MgQ0xBVCIgKHNsaWRlIDYpOiBodHRwczovL3d3dy5s YWNuaWMubmV0L2lubm92YXBvcnRhbC9maWxlLzI5MDcvMS9pcHY2LXRyYW5zLW1lY2hzLXN0YXR1 c192MS1zaG9ydC1qb3JkaS1wYWxldC5wZGYNCkFuZCB5b3VyIFJGQyB0YWxraW5nIG9ubHkgYWJv dXQgInN0YXRlbGVzcyBDTEFUIjogaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg2 ODMuaHRtbA0KDQpSRkMgODU4NSBkb2VzIG5vdCBjbGFyaWZ5IHR5cGUgb2YgQ0xBVC4NCg0KTWFu eSBodW5kcmVkcyBvZiBzdGF0ZWxlc3MgQ0xBVCBkaXNjdXNzaW9ucyBpcyBwb3NzaWJsZSB0byBn b29nbGU6DQpodHRwczovL2NvbmZlcmVuY2UuYXBuaWMubmV0LzM0L3BkZi8zNHRoX2FwbmljXzQ2 NHhsYXQucGRmDQpodHRwczovL2lwdjZjb3VuY2lsLmJlL0lNRy9wZGYvMTItd3V5dHMtWExBVF9h dF90aGVfQ1BFLnBkZg0KaHR0cHM6Ly93d3cuYXByaWNvdC5uZXQvYXByaWNvdDIwMTMvYXNzZXRz LzIwMTMwMjI2X2Fwcmljb3QyMDEzX2lwdjRfb3Zlcl9pcHY2XzEzNjE5Njk3MDMucGRmDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODQvbWF0ZXJpYWxzL3NsaWRlcy04NC1z dW5zZXQ0LTENCmh0dHBzOi8vd3d3LmlwdjYub3JnLnVrL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDE4 LzExL05pY2stSGVhdGxleV9CVF9FRV80NjR4bGF0X1VLdjZDb3VuY2lsXzIwMTgwOTI1LnBkZg0K aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg2ODMuaHRtbA0KaHR0cHM6Ly9hcmNo aXZlLm5hbm9nLm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3dlZG5lc2RheV9nZW5lcmFsX2J5cm5l X2JyZWFraW5nZnJlZV8xMS5wZGYNCklzIGV2ZXJ5Ym9keSB0YWxraW5nIGFib3V0IHN0YXRlbGVz cywgYnV0IGltcGxlbWVudCBzdGF0ZWZ1bD8NCg0KQXQgbGVhc3Qgc29tZWJvZHkgbm90Og0KaHR0 cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvdG1vaXB2Ni80NjR4bGF0DQoiIE5vIGNoYW5nZXMg d2VyZSByZXF1aXJlZCB0byB0aGUgZXhpc3RpbmcgVC1Nb2JpbGUgVVNBIElQdjYtb25seSArIE5B VDY0L0ROUzY0IHRvIHN1cHBvcnQgdGhlIDQ2NFhMQVQgYXJjaGl0ZWN0dXJlLiAgVGhlIHN0YXRl bGVzcyBSRkM2MTQ1IHRyYW5zbGF0aW9uIG9uIHRoZSBoYW5kc2V0IHdhcyB0aGUgb25seSBtb2Rp ZmljYXRpb24gbmVlZGVkLiAiDQoNCk9LLiBBcmUgeW91IHN1cmUgdGhhdCBHb29nbGUgQW5kcm9p ZCBzdXBwb3J0IFN0YXRlZnVsIENMQVQgaW4gcHJpbmNpcGxlPw0KQmVjYXVzZSBMaW51eCBkb2Vz IG5vdC4NCkxpbnV4IGRhZW1vbiBodHRwczovL2dpdGh1Yi5jb20vdG9yZWFuZGVyc29uL2NsYXRk DQpJcyBiYXNlZCBvbiBodHRwOi8vd3d3LmxpdGVjaC5vcmcvdGF5Z2EvDQpUaGF0IGNsYWltZWQg dG8gYmUgInN0YXRlbGVzcyBOQVQ2NCBpbXBsZW1lbnRhdGlvbiINCg0KQW5kcm9pZCBsb29rcyBh IGxpdHRsZSBiZWhpbmQgKHVzaW5nIHByZXZpb3VzIHZlcnNpb24gb2YgQ0xBVEQpOiBodHRwczov L2FuZHJvaWQuZ29vZ2xlc291cmNlLmNvbS9wbGF0Zm9ybS9leHRlcm5hbC9hbmRyb2lkLWNsYXQv Ky9jNzg2Yjc0MDkwMzIwNTA3MjEwMjE1ODMyMzZkZTg2MDhhYzg5NDhlL2NsYXRkLmgNCkFuZHJv aWQgaW52ZXN0aWdhdGlvbiBpcyBiZXR0ZXIgdG8gc3RhcnQgaGVyZTogaHR0cHM6Ly9hbmRyb2lk Lmdvb2dsZXNvdXJjZS5jb20vcGxhdGZvcm0vZXh0ZXJuYWwvYW5kcm9pZC1jbGF0Lw0KSGVuY2Us IEFuZHJvaWQgQ0xBVCBkYWVtb24gZG9lcyBub3Qgc3VwcG9ydCBzdGF0ZWZ1bCBDTEFUIHRvby4N Cg0KQ291bGQgaXQgYmUgdGhhdCBDTEFUIGlzIHVzZWQgdG9nZXRoZXIgd2l0aCBzb21lIG90aGVy IGRhZW1vbiBmb3IgTkFQVCBiZWZvcmUgQ0xBVD8NCkxvb2tzIGxpa2UgTm8gQ0xBVCBkYWVtb24g ZGVwZW5kZW5jeTogaHR0cHM6Ly9vcGVud3J0Lm9yZy9wYWNrYWdlcy9wa2dkYXRhLzQ2NHhsYXQN Cg0KVGhlbiBob3cgaXMgaXQgcG9zc2libGUgdGhhdCBTdGF0dWZ1bCBDTEFUIGlzIHVzZWQsIGlm IGl0IGlzIG5vdCBzdXBwb3J0ZWQgb24gQ1BFL1NtYXJ0cGhvbmU/DQoNCkVkdWFyZA0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpPUkRJIFBBTEVUIE1BUlRJTkVaIFttYWlsdG86 am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXNdIA0KU2VudDogMTUg0LjRjtC70Y8gMjAyMCDQsy4g MTc6MTcNClRvOiBWYXNpbGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+ OyB2Nm9wc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRp b25AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt djZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDIgLSBjb25jZXJuIG9uIHN0YXRlZnVsbmVzcw0K DQpJIHRoaW5rIHlvdXIgcG9pbnQgd2lsbCBiZSB0byBtYWtlIGl0IGNsZWFyIGluIHRoZSBkb2N1 bWVudCB0aGF0IGZvciB0aGlzIG9wdGltaXphdGlvbiB0byB3b3JrLCB0aGUgQ0xBVCBzaG91bGQg YmUgc3RhdGVmdWw/DQoNCkkgdGhpbmsgaXMgdGhlcmUgKDUuMi40LiAgRm9yd2FyZGluZyBwYXRo IHZpYSBzdGF0ZWZ1bCBOQVQgZm9yIGV4aXN0aW5nIEVBTVQgZW50cmllcyksIGJ1dCBJIHdpbGwg bWFrZSBzdXJlIHRvIGFkZCB0aGUgcmVsZXZhbnQgdGV4dCBpbiB0aGUgbmV4dCB2ZXJzaW9uIHRv IG1ha2UgaXQgY2xlYXJlci4gDQoNCkkgaW5zaXN0OiBtb3N0IG9mIHRoZSBDTEFUIGltcGxlbWVu dGF0aW9ucyB0b2RheSAocnVubmluZyBpbiBib3RoIENQRXMgYW5kIFVFcykgYXJlIHN0YXRlZnVs LiBBdCBsZWFzdCB0aGlzIGlzIHRoZSBkYXRhIEkndmUuDQogDQpSZWdhcmRzLA0KSm9yZGkNCkBq b3JkaXBhbGV0DQogDQogDQoNCu+7v0VsIDE1LzcvMjAgMTU6NTksICJ2Nm9wcyBlbiBub21icmUg ZGUgVmFzaWxlbmtvIEVkdWFyZCIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgZW4gbm9tYnJlIGRl IHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4gZXNjcmliacOzOg0KDQogICAgSGkgSm9yZGks DQogICAgSSBzdGlsbCBiZWxpZXZlIHRoYXQgdG91Z2ggKG5ldykgcmVxdWlyZW1lbnQgdGhhdCBD TEFUIHNob3VsZCBiZWNvbWUgU3RhdGVmdWwgKG1hbmRhdG9yeSkNCiAgICBNYWtlIHNlbnNlIHRv IGluc2VydCBpbnRvIHRoZSBkb2N1bWVudC4NCg0KICAgIEFuZCBleHBsYW5hdGlvbiB3aHkgc3Rh dGVmdWwgTkFQVCBpcyBuZWVkZWQgd291bGQgYmUgZ29vZC4NCiAgICBJIGhhdmUgc3BlbnQgc29t ZSB0aW1lIHRvIHJlc2VhcmNoIHRoaXMgLSBpdCBpcyBiZXR0ZXIgdG8gc2F2ZSB0aW1lIG9mIG90 aGVyIHBlb3BsZS4NCiAgICBJdCBpcyBpbXBvcnRhbnQgcG9pbnQgdGhhdCBpcyBvbWl0dGVkIGlu IHRoZSBkb2N1bWVudC4NCg0KICAgIEZvciB0aGUgbmFtZTogSSBkbyBub3QgaGF2ZSBhbnkgc3Ry b25nIG9waW5pb24uDQogICAgSnVzdCBJIHNlZSB0aGF0IGRyYWZ0IGlzIGFwcGxpY2FibGUgbW9z dGx5IHRvIE1BUC1ULA0KICAgIEFuZCBub3QgbXVjaCBhcHBsaWNhYmxlIHRvIFhMQVQgKGJlY2F1 c2UgbWFqb3JpdHkgb2YgaW5zdGFsbGF0aW9ucyBoYXZlIHN0YXRlbGVzcyBDTEFUKS4NCiAgICBC dXQgdGhlIG5hbWUgbWlzbGVhZCB0byBvcHBvc2l0ZSBjb25jbHVzaW9uLg0KDQogICAgRWR1YXJk DQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBKb3JkaSBQYWxldCBN YXJ0w61uZXogW21haWx0bzpqb3JkaS5wYWxldEB0aGVpcHY2Y29tcGFueS5jb21dIA0KICAgIFNl bnQ6IDE1INC40Y7Qu9GPIDIwMjAg0LMuIDE2OjQ4DQogICAgVG86IFZhc2lsZW5rbyBFZHVhcmQg PHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT47IHY2b3BzQGlldGYub3JnDQogICAgQ2M6IGRy YWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb25AaWV0Zi5vcmcNCiAgICBTdWJqZWN0 OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1p emF0aW9uLTAyIC0gY29uY2VybiBvbiBzdGF0ZWZ1bG5lc3MNCg0KICAgIEhpIFZhc2lsZW5rbywN Cg0KICAgIFRoZSBpbXBsZW1lbnRhdGlvbnMgb2YgNDY0WExBVCwgY2FuIGRvIHRoZSBzYW1lIChh bmQgaW4gZmFjdCwgbWFueSBvZiB0aGVtIGlzIHdoYXQgdGhleSBkbykuIE5BVDQ0IHN0YXRlZnVs IGFuZCB0aGUgNDYgc3RhdGVsZXNzLiBNYW55IFNvQyBoYXZlIGVtYmVkZGVkIE5BVDQ0IGFjY2Vs ZXJhdGlvbiwgYnV0IG5vdCBOQVQ0Niwgc28gdGhhdCBleHBsYWlucyBpdCBhcyB3ZWxsLg0KDQog ICAgSSBndWVzcyB0aGF0IGNvdWxkIGNsZWFyIHlvdXIgY29uY2Vybj8NCg0KICAgIEkndmUgc2V2 ZXJhbCBjdXN0b21lcnMgZG9pbmcgNDY0WExBVCBpbiBicm9hZGJhbmQsIG9uZSBvZiB0aGVtIDI1 LjAwMC4wMDAgc3Vic2NyaWJlcnMuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgaW4gZG9pbmcgNDY0 WExBVCBpbiBjZWxsdWxhciBhbmQgYnJvYWRiYW5kLg0KDQogICAgV2hlbiB3ZSBzYXkgaW4gdGhl IHRpdGxlIDQ2NFhMQVQvTkFUNjQsIEkgdGhpbmsgYm90aCBhcmUgY292ZXJlZC4gQnV0IEkndmUg bm8gaXNzdWUgdG8gY2hhbmdlIHRoZSB0aXRsZSBpZiB0aGlzIG1ha2VzIHNlbnNlIHRvIG90aGVy cy4gV2UgY291bGQgZXhwbGljdGlseSBzYXkgNDY0WExBVC9OQVQ2NC9NQVAtVCBvciB3aGF0ZXZl ci4gVGhpcyBpcyBhIG1pbm9yIGRldGFpbCwgaW4gbXkgb3Bpbmlvbi4NCg0KICAgIFJlZ2FyZHMs DQogICAgSm9yZGkNCiAgICBAam9yZGlwYWxldA0KDQoNCiAgICDvu79FbCAxNS83LzIwIDE1OjQw LCAiVmFzaWxlbmtvIEVkdWFyZCIgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4gZXNjcmli acOzOg0KDQogICAgICAgIEhpIGFsbCwNCiAgICAgICAgSSBoYXZlIGNvbmNlcm4gb24gdGhlIGNh cGFiaWxpdHkgdG8gdXNlIHRoaXMgbWVjaGFuaXNtIGZvciA0NjRYTEFULCBidXQgaXQgc2hvdWxk IGJlIGZpbmUgZm9yIE1BUC1ULg0KDQogICAgICAgIFdlIG1heSBoYXZlIG1hbnkgaG9zdHMgb24g Q1BFIExBTi4gVHlwaWNhbGx5LCA3MCUgb2YgRkJCIHRyYWZmaWMgaXMgc3RpbGwgZGVzaWduYXRl ZCB0byBJUHY0IHNpdGVzLg0KICAgICAgICBTb3VyY2UgVURQL1RDUCBwb3J0IGNvbGxpc2lvbiBp cyBzdGlsbCB2ZXJ5IHBvc3NpYmxlIChpLmUuIGFjdGl2ZSBzZXNzaW9ucyBmcm9tIGRpZmZlcmVu dCBob3N0IG1heSBoYXZlIHRoZSBzYW1lIHNvdXJjZSBUQ1AvVURQIHBvcnQpLA0KICAgICAgICBJ dCBpcyBub3Qgc3RhdGVkIGFueXdoZXJlIGluIHRoZSBkb2N1bWVudCwgYnV0IHdlIG5lZWQgdG8g c3F1ZWV6ZSAoZm9yIHBhdGggdG8gSW50ZXJuZXQgaXQgd291bGQgYmUgInNvdXJjZSBJUCBhZGRy ZXNzIikgbWFueSBwcml2YXRlIElQdjQgaG9zdHMgdG8gb25lIElQdjYgKGFzc2lnbmVkIGJ5IGNh cnJpZXIgdG8gQ1BFIHVwbGluaykuDQogICAgICAgIENsYXNzaWNhbCBOOjEgcHJvYmxlbSB0aGF0 IHNob3VsZCBiZSByZXNvbHZlZCBieSBOQVBUIChwb3J0IHRyYW5zbGF0aW9uIGlzIG1hbmRhdG9y eSkuDQoNCiAgICAgICAgTUFQLVQgaGFzIE5BUFQgZW5naW5lIG9uIENQRSBzaWRlIC0gaXQgbWFr ZSBzZW5zZSB0byBjbGVhcmx5IHN0YXRlIGluIHRoZSBkb2N1bWVudCB0aGF0IHdlIGFyZSBnb2lu ZyB0byByZXVzZSBOQVBULiBUaGVuIHRyYW5zbGF0aW9uIHdvdWxkIGJlOg0KICAgICAgICAoMSkg TkFQVDQ0IGZvciBtYW55IHByaXZhdGUgSVB2NCB0byBvbmUgcHVibGljIElQdjQgKHdlbGwsIGl0 IGNvdWxkIGJlIG5vdCBwdWJsaWMsIGJ1dCBwdWJsaWMgQStQIGhhcyBiZWVuIGdpdmVuIHRvIE1B UCBDRSBhbnl3YXkgLSBiZXR0ZXIgdG8gcmV1c2UgaXQgZm9yIHVuaWZpY2F0aW9uKQ0KICAgICAg ICAoMikgU0lJVCAod2l0aCBFQU1UKSBmb3Igc2luZ2xlIElQdjQgdG8gc2luZ2xlIElQdjYgKDE6 MSkNCg0KICAgICAgICBYTEFUL0NMQVQgZG9lcyBoYXZlIHN0YXRlZnVsIE5BUFQgYnkgUkZDIDY4 NzcsIGJ1dCBpdCBpcyBub3QgcG9wdWxhciAtIG5vdCBpbXBsZW1lbnRlZCBieSBtYW55IGNhcnJp ZXJzIChpZiBhbnk/KS4NCiAgICAgICAgSXQgd291bGQgYmUgdGhlIGJpZyBuZXdzIHRoYXQgQ2Fy cmllcnMgc2hvdWxkIGNob29zZSBzdGF0ZWZ1bCBDTEFUIG9wdGlvbiBmb3IgNDY0WExBVC4NCiAg ICAgICAgSXQgaXMgYmV0dGVyIHRvIHRlbGwgdGhlbSB1cGZyb250Lg0KDQogICAgICAgIFRoZSBu ZXh0IHF1ZXN0aW9uIGNvdWxkIGJlOiBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gdXNlIFN0YXRlbGVz cyBDTEFUIGZvciBiYXNpYyA0NjRYTEFUIGFuZCBTdGF0ZWZ1bCBDTEFUIGZvciB0cmFmZmljIG9w dGltaXphdGlvbiB0byBJUHY0IHNpdGVzPw0KICAgICAgICBPciBpdCBpcyBiZXR0ZXIgdG8gdW5p Znkgb24gU3RhdGVmdWwgQ0xBVCBmb3IgZXZlcnl0aGluZy4NCg0KICAgICAgICBJbiBnZW5lcmFs LCBpdCBpcyBhIHJldm9sdXRpb24gZm9yIDQ2NFhMQVQuIEJ1dCBpdCBpcyBzbW9vdGggZXhwYW5z aW9uIGZvciBNQVAtVC4NCiAgICAgICAgSGVuY2UsIGRvZXMgaXQgbWFrZSBzZW5zZSB0byBjaGFu Z2UgdGhlIG5hbWUgb2YgdGhpcyBkcmFmdCB0byByZWZsZWN0IE1BUC1UIGFzIHRoZSBwcmltYXJ5 IHRhcmdldD8NCg0KICAgICAgICBFZHVhcmQNCiAgICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCiAgICAgICAgRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQogICAgICAgIFNlbnQ6IDEx INC40Y7Qu9GPIDIwMjAg0LMuIDE1OjM0DQogICAgICAgIFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCiAgICAgICAgQ2M6IHY2b3BzQGlldGYub3JnDQogICAgICAgIFN1YmplY3Q6IFt2Nm9wc10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMi50eHQN Cg0KDQogICAgICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICAgICAgVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0KDQog ICAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogNDY0WExBVC9OQVQ2NCBPcHRpbWl6YXRp b24NCiAgICAgICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBKb3JkaSBQYWxldCBNYXJ0aW5l eg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFsZWphbmRybyBEJ0VnaWRpbw0K ICAgICAgICAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGlt aXphdGlvbi0wMi50eHQNCiAgICAgICAgCVBhZ2VzICAgICAgICAgICA6IDIxDQogICAgICAgIAlE YXRlICAgICAgICAgICAgOiAyMDIwLTA3LTExDQoNCiAgICAgICAgQWJzdHJhY3Q6DQogICAgICAg ICAgIElQL0lDTVAgVHJhbnNsYXRpb24gQWxnb3JpdGhtIChTSUlUKSBjYW4gYmUgdXNlZCB0byBw cm92aWRlIGFjY2Vzcw0KICAgICAgICAgICBmb3IgSVB2NC1vbmx5IGRldmljZXMgb3IgYXBwbGlj YXRpb25zIHRvIElQdjQtb25seSBvciBkdWFsLXN0YWNrDQogICAgICAgICAgIGRlc3RpbmF0aW9u cyBvdmVyIElQdjYtb25seSBpbmZyYXN0cnVjdHVyZS4gIEluIHRoYXQgY2FzZSwgdGhlDQogICAg ICAgICAgIHRyYWZmaWMgZmxvd3MgYXJlIHRyYW5zbGF0ZWQgdHdpY2U6IGZpcnN0IGZyb20gSVB2 NCB0byBJUHY2DQogICAgICAgICAgIChzdGF0ZWxlc3MgTkFUNDYgYXQgdGhlIGluZ3Jlc3MgcG9p bnQgdG8gdGhlIElQdjYtb25seQ0KICAgICAgICAgICBpbmZyYXN0cnVjdHVyZSkgYW5kIHRoZW4g ZnJvbSBJUHY2IGJhY2sgdG8gSVB2NCAoc3RhdGVmdWwgTkFUNjQsIGF0DQogICAgICAgICAgIHRo ZSBlZ3Jlc3MgcG9pbnQpLiAgV2hlbiB0aGUgZGVzdGluYXRpb24gaXMgSVB2Ni1lbmFibGVkLCB0 aGUgc2Vjb25kDQogICAgICAgICAgIHRyYW5zbGF0aW9uIG1pZ2h0IGJlIGF2b2lkZWQuICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIHBvc3NpYmxlDQogICAgICAgICAgIG9wdGltaXphdGlvbiB0 byA0NjRYTEFUIGFuZCBNQVAtVCB0byBhdm9pZCB0cmFuc2xhdGluZyBJUHY2IGZsb3dzDQogICAg ICAgICAgIGJhY2sgdG8gSVB2NCBpZiB0aGUgZGVzdGluYXRpb24gaXMgcmVhY2hhYmxlIG92ZXIg SVB2Ni4gIFRoZSBwcm9wb3NlZA0KICAgICAgICAgICBzb2x1dGlvbiB3b3VsZCBzaWduaWZpY2Fu dGx5IHJlZHVjZSB0aGUgTkFUNjQgdXRpbGl6YXRpb24gaW4gdGhlDQogICAgICAgICAgIG9wZXJh dG9yJ3MgbmV0d29yay4NCg0KDQogICAgICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLw0KDQogICAgICAg IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRp bWl6YXRpb24tMDINCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyDQoNCiAgICAgICAgQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0 LW9wdGltaXphdGlvbi0wMg0KDQoNCiAgICAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQogICAgICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCiAgICAgICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCg0KDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgICAgICB2Nm9wc0BpZXRmLm9y Zw0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoN Cg0KDQogICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K ICAgIElQdjQgaXMgb3Zlcg0KICAgIEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQg Pw0KICAgIGh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQogICAgVGhlIElQdjYgQ29tcGFu eQ0KDQogICAgVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hp Y2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMg aW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMp IG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxl cywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWlu YWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2Fy ZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRo ZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVk aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNp ZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2lu YWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBp dC4NCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgIHY2b3BzQGlldGYub3JnDQogICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUg eW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cudGhlaXB2NmNvbXBh bnkuY29tDQpUaGUgSVB2NiBDb21wYW55DQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRh aW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4g VGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0 eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2Yg dGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNs dWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUg Y29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBp ZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3Qg cmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5p Y2F0aW9uIGFuZCBkZWxldGUgaXQuDQoNCg0KDQo= From nobody Wed Jul 15 09:30:27 2020 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 D2E6F3A0E8B for ; Wed, 15 Jul 2020 09:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SHORT_SHORTNER=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb2076AN4Aa3 for ; Wed, 15 Jul 2020 09:30:22 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F863A0CB0 for ; Wed, 15 Jul 2020 09:30:21 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id k5so3218646pjg.3 for ; Wed, 15 Jul 2020 09:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:date:subject:references:to; bh=p21zcxRNCjuLmn/SxmekBp1dJDbvufxH67XNnnyWjPc=; b=D582I4sCUmvoKtGdQ4wYeMkOLLF/h+OiaL/tdFQfhj21bJYL2rIgjHf0H/rFhdeOW1 bQ3I+ARVzhINlc4lOz658PaL46wFGgXNeqZ46hYkJpsJADmI4E9fE5I8BVkwn2wPlrOy ofIEZtCz4F8SMCBlT8Stay/1yT/XP01BR0+pxgJBcisM4PNcdQtxcvQZz5N/ls9rfHn6 B7vgYd3AW2ANrxGze94OHIYRjs1780WRNzUghPtnq2GOMjremtnJhc+vnGcWjjggQFjk 4svXc7nRg40ScFHLXE+wrAmNg83yupQ3Izm5Fxkv6X6VuRvRS+JonEmNTTFTi1TJLGQg CZDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:date:subject :references:to; bh=p21zcxRNCjuLmn/SxmekBp1dJDbvufxH67XNnnyWjPc=; b=DQSqH/RoCYu1M4P2cJeFHbSltVPJyYvKssO8LQc994ELFKCiy6m9vW0WKLT/a6wmCI KxwnMsmktpWJS1/WrgjD38l40sn9O/RCS7SccHBx9Qav6bGKMETIS/M2dQZkDR7MkWOf Gz6QrkrXP1e1Z4ZXo6NzPZy1NFlqyglXroJGCemZ/poCWawyBZ5drWBJYbj8c18W6nOd cLFGdTRqA2Wzf/eufi5NDH9lhrNWjcIU+o17O+KwihABUvdS+lIyGJ/nNko19vMBWe55 CiYEcODUv0oLj78Pxbvpk7tHmiNNy12RTY5c8pBXO3LAWv8RyLqR7bFCAOCH10wRK5M4 6+gA== X-Gm-Message-State: AOAM531cd5mNHscYorwL5H7d5M5BGpnyCwI5tF4K0QNookaq0HkGZMjj xLeBkGEu+KH8Y642FDFipPP15KYWJ5c= X-Google-Smtp-Source: ABdhPJypBIr4a6evFPWmiG/SL0WTETIJQkG9f16DRM0sPKE5MftjJyoBHU3pn4X0irQbRgTCMmQ7rQ== X-Received: by 2002:a17:902:9a96:: with SMTP id w22mr245725plp.172.1594830621004; Wed, 15 Jul 2020 09:30:21 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::1c1e? ([2600:8802:5800:652::1c1e]) by smtp.gmail.com with ESMTPSA id gn5sm2567722pjb.23.2020.07.15.09.30.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2020 09:30:20 -0700 (PDT) From: Fred Baker Message-Id: <04F146A4-AAEA-46DB-BCFB-F631F8A84072@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1105CD04-DCF9-4041-B302-CCB1E9616C4E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 15 Jul 2020 09:30:18 -0700 References: <1F01677C-0F01-4A28-A61F-8ECA04E5DB1B@gmail.com> To: IPv6 Operations X-Mail-Calendar-Part: Yes X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] Fwd: [www.ietf.org/rt #290174] V6ops interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 16:30:25 -0000 --Apple-Mail=_1105CD04-DCF9-4041-B302-CCB1E9616C4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is a reminder. If it's a surprise for you, surprise! We're having = an interim meeting tomorrow (Thursday or Friday as you measure fit). The = discussion will include: -- Ben Kyemba from RENU, talking about IPv6 deployment in an NREN in = Uganda -- Jen Linkova from Google, talking about her current project: turning = IPv4 off within Google. -- Chongfeng Xie, talking about IPv6 deployment in China Telecom Ben's topic is interesting to me in large part because it is unusual: of = all of the countries in Africa, only Zimbabwe and Kenya are reported as = having more than 5% of their requests arrive at Google using IPv6. = Historically, Africa has been referred to as "the dark continent"; from = an IPv4 perspective, it is only within the past few years that it has = been emerging from behind layers and layers of NAT, and from an IPv6 = perspective it is still largely "dark". RENU is, so to speak, a light in = a dark place. I tend to think that Jen's topic is currently topical and relevant to a = number of networks. In the US, there is (I'm told) a project afoot to = turn off IPv6 within US federal networks, for example. I have invited = some folks that don't usually participate in v6ops (although they are of = course always welcome) because of that project. Xie's topic is interesting because it disputes measurements made outside = China. There are a number of possible explanations, including = differences in measurement methodology and the impact of the routing and = filtering issues. I'm hoping for some dialog on that topic. You might = review the following for comparison: https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dc= n https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DCN = =20= https://www.vyncke.org/ipv6status/compare.php?metric=3Dk&countries=3Dc= n =20 I have also attached a web page I automatically generate from IETF = Datatracker data (as in, you could get this information directly from = the Data Tracker, but I find the format more useful for my purposes). It = shows the status of drafts in v6ops. I expect drafts from Jen and Ben on = their topics, as Brian Carpenter suggested; in Ben's case, he is having = some issues with xml2rfc and getting the thing filed. I'm also = interested in drafts, especially from operators, on topics that we need = to discuss. As usual, when drafts are filed, the person filing it should = forward the note that they get from the secretariat announcing the = posting, and initiate a discussion on the list. I don't consider a draft = to have been accepted by the group unless I see supporting commentary on = the list.=20 > From: "Bajpai, Vaibhav" > > Subject: netflix and ipv6 > Date: July 14, 2020 at 10:42:22 AM PDT > To: Nathaniel Wingard via NANOG > >=20 > Hi NANOG, >=20 > We measured NETFLIX over v6 for the last couple of years. The paper > describing this research is now online, thought to share: >=20 > -- Vaibhav >=20 > A Longitudinal View of Netflix: Content Delivery over IPv6 and Content = Cache Deployments >=20 > paper: https://bit.ly/2toOGWP > slides: https://bit.ly/2ZoEpap > video: https://vimeo.com/437111302 > Begin forwarded message: >=20 > From: Fred Baker > Subject: Fwd: [www.ietf.org/rt #290174] V6ops interim meeting > Date: July 3, 2020 at 2:29:27 PM PDT > To: IPv6 Operations >=20 > Heads up: the IESG tells me I need to move the interim meeting to 16 = July. So, I have accordingly changed the webex information from = 14:00-16:00 UTC on 23 July to the same time on 16 July. >=20 >> Begin forwarded message: >>=20 >> From: Fred Baker > >> Subject: Re: [www.ietf.org/rt #290174 = ] V6ops interim meeting >> Date: July 3, 2020 at 2:16:41 PM PDT >> To: The IESG > >> Cc: Ron Bonica >, = JORDI PALET MARTINEZ >, Jen Linkova >, xiechf@chinatelecom.cn = , warren > >>=20 >> I managed to miss her email, but I'm happy to move it to 16 July at = the same time. I obviously need to change the webex invitation; let me = know if there is anything else you need me to do. I'm assuming that with = the date change you have the information you need. >>=20 >>> On Jun 30, 2020, at 12:50 PM, Amy Vezza via RT = > wrote: >>>=20 >>> Hi Fred, >>>=20 >>> As I am sure you have seen Alissa=E2=80=99s recent message to the WG = Chairs list >>> = (https://mailarchive.ietf.org/arch/msg/wgchairs/WgFn1d2hq95IDZNypm_5sFtJI7= Y/ = ), >>> we are unable to complete the V6OPS Interim Meeting Request, as the = IESG has >>> forbidden working groups from holding virtual interim meetings the = week of July >>> 20th. >>>=20 >>> Please let us know if the V6OPS WG would prefer to change the date = to happen >>> the week of July 13th or to move it after IETF 108 to sometime in = August. >>>=20 >>> Best regards, >>>=20 >>> Amy >>>=20 >>>=20 >>>=20 >>> On Tue Jun 23 18:28:29 2020, fredbaker.ietf@gmail.com = wrote: >>>=20 >>> Amy/Cindy: >>>=20 >>> Now that I have filed an interim meeting, I have this quaint idea = that I should be able to see it somewhere. Where should I be looking? >>>=20 >>>> On Jun 22, 2020, at 10:22 PM, Fred Baker via RT = > wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Jun 22, 2020, at 4:35 PM, Amy Vezza via RT = > wrote: >>>>>=20 >>>>> Hi Fred, >>>>>=20 >>>>> I can absolutely discuss this over WebEx with your tomorrow (Cindy = is >>>>> unavailable), however I think in testing to find out what you can = see as a >>>>> chair, Cindy accidentally sent you the link in the datatracker = Sandbox, which >>>>> is the testing suite for the datatracker, and not the datatracker = itself. >>>>=20 >>>> I suspected that was an issue. And yes, that is there in the data = tracker after I have logged in. >>>>=20 >>>>> Looking at the V6OPS Working Group meetings page = (https://datatracker.ietf.org/wg/v6ops/meetings/ = ) >>>>> one of the top buttons should be "Request an interim meeting" = (note: please be >>>>> sure you are logged in to the datatracker). Once you click on that = button, you >>>>> should be able to fill in all the details for the meeting and = submit to us to >>>>> go into the queue for us to make the announcement. >>>>>=20 >>>>> If you are still having trouble we can meet tomorrow so we can = look at the >>>>> datatracker together. >>>>=20 >>>> Thanks for your help. I now have a posted interim. If you have = questions, please feel free to call me at +1-805-637-0529 so we can get = it sorted out quickly. >>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Amy >>>>>=20 >>>>> On Mon Jun 22 15:13:01 2020, fredbaker.ietf@gmail.com = wrote: >>>>>=20 >>>>>=20 >>>>>> On Jun 22, 2020, at 1:54 PM, Cindy Morgan via RT = > wrote: >>>>>>=20 >>>>>> Hi Fred, >>>>>>=20 >>>>>> To get this interim meeting into the Datatracker, please go to = the V6OPS >>>>>> meeting tab (https://sandbox.ietf.org/wg/v6ops/meetings/ = ) and hit the "Request >>>>>> an interim meeting" button. >>>>>=20 >>>>> first problem - there is no such button on the page. There is a = "schedule a meeting" button, but that doesn't get me to scheduling an = interim either. >>>>>=20 >>>>> Given that, may I suggest we talk via webex, where I can display = what I'm doing and you can tell me what I'm doing wrong? Give me a webex = link. I'm available 8:00-15:30 Tuesday, any time after 9:00 on = Wednesday... >>>>>=20 >>>>>> =46rom there you will be prompted to enter in the meeting = details, including >>>>>> date, time, duration, and remote participation (e.g. Webex) = instructions. There >>>>>> is also a field there to enter the agenda. >>>>>>=20 >>>>>> Once you fill all of that out and hit Submit, it will send a = ticket to us >>>>>> prompting us to review the request and send the formal = announcement to the >>>>>> IETF-Announce list. When we sent the announcement, the = Datatracker also >>>>>> automatically adds the meeting to = https://datatracker.ietf.org/meeting/upcoming = >>>>>> and sets up the meeting in the Datatracker so that you can add = your minutes and >>>>>> meeting materials. >>>>>>=20 >>>>>> Best regards, >>>>>> Cindy >>>>>>=20 >>>>>> On Sun Jun 21 20:33:20 2020, fredbaker.ietf@gmail.com = wrote: >>>>>>=20 >>>>>> This is to let you know that we have scheduled an interim meeting = on July 23 at 15:00 UTC. At this point, we have no drafts on our agenda; = we will have >>>>>> - Ben Kyemba, RENU, discussing dual stack deployment in his = network >>>>>> - Jen Linkova, Google, discussing convertion to IPv6-only within = Google >>>>>> - Chongfen Xie, China Telecom, talking about IPv6 traffic = statistics within China (which are disputed) >>>>>>=20 >>>>>> A possible future is that drafts will be filed that are = interesting to the operational community. We will add people to the = agenda if that occurs. >>>>>>=20 >>>>>> I'm not sure what you need from us to have this included in the = IETF 108 proceedings. Minutes and meeting materials, certainly. Anything = else? --Apple-Mail=_1105CD04-DCF9-4041-B302-CCB1E9616C4E Content-Type: multipart/mixed; boundary="Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916" --Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This is a reminder. If it's a surprise for you, surprise! = We're having an interim meeting tomorrow (Thursday or Friday as you = measure fit). The discussion will include:

 -- Ben Kyemba from RENU, talking = about IPv6 deployment in an NREN in Uganda
 -- = Jen Linkova from Google, talking about her current project: turning IPv4 = off within Google.
 -- Chongfeng Xie, talking about IPv6 deployment in China = Telecom

Ben's topic = is interesting to me in large part because it is unusual: of all of the = countries in Africa, only Zimbabwe and Kenya are reported as having more = than 5% of their requests arrive at Google using IPv6. Historically, = Africa has been referred to as "the dark continent"; from an IPv4 = perspective, it is only within the past few years that it has been = emerging from behind layers and layers of NAT, and from an IPv6 = perspective it is still largely "dark". RENU is, so to speak, a light in = a dark place.

I tend to = think that Jen's topic is currently topical and relevant to a number = of networks. In the US, there is (I'm told) a project afoot to turn = off IPv6 within US federal networks, for example. I have invited some = folks that don't usually participate in v6ops (although they are of = course always welcome) because of that project.

Xie's = topic is interesting because it disputes measurements made outside = China. There are a number of possible explanations, including = differences in measurement methodology and the impact of the routing and = filtering issues. I'm hoping for some dialog on that topic. You might = review the following for comparison:
    https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&co= untries=3Dcn
    https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&= amp;w=3D30&c=3DCN 
    https://www.vyncke.org/ipv6status/compare.php?metric=3Dk&co= untries=3Dcn 

I have also attached a web page I automatically generate from = IETF Datatracker data (as in, you could get this information = directly from the Data Tracker, but I find the format more useful for my = purposes). It shows the status of drafts in v6ops. I expect drafts from = Jen and Ben on their topics, as Brian Carpenter suggested; in Ben's = case, he is having some issues with xml2rfc and getting the thing filed. = I'm also interested in drafts, especially from operators, on = topics that we need to discuss. As usual, when drafts are filed, = the person filing it should forward the note that they get from the = secretariat announcing the posting, and initiate a discussion on the = list. I don't consider a draft to have been accepted by the group unless = I see supporting commentary on the list. 

From: "Bajpai, Vaibhav" <vaibhav.bajpai@tum.de>
Subject: netflix and ipv6
Date: July 14, 2020 at 10:42:22 AM PDT
To: Nathaniel Wingard via NANOG <nanog@nanog.org>

Hi = NANOG,

We measured NETFLIX over v6 for the = last couple of years. The paper
describing this research = is now online, thought to share:

-- = Vaibhav

A Longitudinal View of Netflix: = Content Delivery over IPv6 and Content Cache Deployments
paper:   https://bit.ly/2toOGWP
slides:  https://bit.ly/2ZoEpap
video:   https://vimeo.com/437111302

Begin forwarded = message:

From: = Fred Baker <fredbaker.ietf@gmail.com>
Subject: = Fwd: [www.ietf.org/rt = #290174] V6ops interim meeting
Date: = July 3, 2020 at 2:29:27 PM = PDT
To: = IPv6 Operations <v6ops@ietf.org>

Heads up: the IESG tells me I need to move the = interim meeting to 16 July. So, I have accordingly changed the webex = information from 14:00-16:00 UTC on 23 July to the same time on 16 = July.

Begin = forwarded message:

From: Fred Baker <fredbaker.ietf@gmail.com>
Subject: Re: [www.ietf.org/rt = #290174] V6ops interim meeting
Date: July 3, 2020 at 2:16:41 PM PDT
To: The IESG <iesg-secretary@ietf.org>
Cc: Ron Bonica <rbonica@juniper.net>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, Jen Linkova <furry@google.com>, xiechf@chinatelecom.cn, warren <warren@kumari.net>

I managed to miss her email, but = I'm happy to move it to 16 July at the same time. I obviously need to = change the webex invitation; let me know if there is anything else you = need me to do. I'm assuming that with the date change you have the = information you need.

On Jun 30, 2020, at 12:50 PM, Amy Vezza via RT = <iesg-secretary@ietf.org> wrote:

Hi Fred,

As I am sure you have = seen Alissa=E2=80=99s recent message to the WG Chairs list
(https://mailarchive.ietf.org/arch/msg/wgchairs/WgFn1d2hq95IDZNy= pm_5sFtJI7Y/),
we are unable to complete the V6OPS = Interim Meeting Request, as the IESG has
forbidden working = groups from holding virtual interim meetings the week of July
20th.

Please let us know if the = V6OPS WG would prefer to change the date to happen
the = week of July 13th or to move it after IETF 108 to sometime in August.

Best regards,

Amy



On Tue Jun 23 18:28:29 2020, fredbaker.ietf@gmail.com wrote:

Amy/Cindy:

Now that I have filed = an interim meeting, I have this quaint idea that I should be able to see = it somewhere. Where should I be looking?

On Jun 22, 2020, at = 10:22 PM, Fred Baker via RT <iesg-secretary@ietf.org> wrote:



On Jun 22, 2020, at 4:35 PM, Amy Vezza via RT <iesg-secretary@ietf.org> wrote:

Hi Fred,

I can absolutely = discuss this over WebEx with your tomorrow (Cindy is
unavailable), however I think in testing to find out what you = can see as a
chair, Cindy accidentally sent you the link = in the datatracker Sandbox, which
is the testing suite for = the datatracker, and not the datatracker itself.

I suspected that was an issue. = And yes, that is there in the data tracker after I have logged in.

Looking = at the V6OPS Working Group meetings page (https://datatracker.ietf.org/wg/v6ops/meetings/)
one of the top buttons should be "Request an interim meeting" = (note: please be
sure you are logged in to the = datatracker). Once you click on that button, you
should be = able to fill in all the details for the meeting and submit to us to
go into the queue for us to make the announcement.

If you are still having trouble we can meet = tomorrow so we can look at the
datatracker together.

Thanks for your help. I now have = a posted interim. If you have questions, please feel free to call me at = +1-805-637-0529 so we can get it sorted out quickly.

Best regards,

Amy

On Mon Jun 22 = 15:13:01 2020, fredbaker.ietf@gmail.com wrote:


On Jun = 22, 2020, at 1:54 PM, Cindy Morgan via RT <iesg-secretary@ietf.org> wrote:

Hi Fred,

To get this interim = meeting into the Datatracker, please go to the V6OPS
meeting= tab (https://sandbox.ietf.org/wg/v6ops/meetings/) and hit the = "Request
an interim meeting" button.

first problem - there is no such = button on the page. There is a "schedule a meeting" button, but that = doesn't get me to scheduling an interim either.

Given that, may I suggest we talk via webex, where I can = display what I'm doing and you can tell me what I'm doing wrong? Give me = a webex link. I'm available 8:00-15:30 Tuesday, any time after 9:00 on = Wednesday...

=46rom there you will be prompted to enter in the meeting = details, including
date, time, duration, and remote = participation (e.g. Webex) instructions. There
is also a = field there to enter the agenda.

Once you = fill all of that out and hit Submit, it will send a ticket to us
prompting us to review the request and send the formal = announcement to the
IETF-Announce list. When we sent the = announcement, the Datatracker also
automatically adds the = meeting to https://datatracker.ietf.org/meeting/upcoming
and sets up the meeting in the Datatracker so that you can = add your minutes and
meeting materials.

Best regards,
Cindy

On Sun Jun 21 20:33:20 2020, fredbaker.ietf@gmail.com wrote:

This is to let you know that we have scheduled an interim = meeting on July 23 at 15:00 UTC. At this point, we have no drafts on our = agenda; we will have
- Ben Kyemba, RENU, discussing dual = stack deployment in his network
- Jen Linkova, Google, = discussing convertion to IPv6-only within Google
- = Chongfen Xie, China Telecom, talking about IPv6 traffic statistics = within China (which are disputed)

A = possible future is that drafts will be filed that are interesting to the = operational community. We will add people to the agenda if that = occurs.

I'm not sure what you need from us = to have this included in the IETF 108 proceedings. Minutes and meeting = materials, certainly. Anything else?
= --Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916 Content-Disposition: attachment; filename=Webex_Meeting.ics Content-Type: text/calendar; x-unix-mode=0644; name="Webex_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0D=0AVERSION:2.0=0D=0AMETHOD:REQUEST=0D=0ABEGIN:VTIMEZONE=0D=0A= TZID:America/Los_Angeles=0D=0A= TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles=0D=0A= X-LIC-LOCATION:America/Los_Angeles=0D=0ABEGIN:DAYLIGHT=0D=0A= TZOFFSETFROM:-0800=0D=0ATZOFFSETTO:-0700=0D=0ATZNAME:PDT=0D=0A= DTSTART:19700308T020000=0D=0ARRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU=0D= =0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0ATZOFFSETFROM:-0700=0D=0A= TZOFFSETTO:-0800=0D=0ATZNAME:PST=0D=0ADTSTART:19701101T020000=0D=0A= RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU=0D=0AEND:STANDARD=0D=0A= END:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0ADTSTAMP:20200703T212230Z=0D=0A= ATTENDEE;CN=3D"V6OPS=20Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAILTO:v6ops-chairs@ietf.org=0D= =0AORGANIZER;CN=3D"Cisco=20Webex":MAILTO:messenger@webex.com=0D=0A= DTSTART;TZID=3DAmerica/Los_Angeles:20200716T070000=0D=0A= DTEND;TZID=3DAmerica/Los_Angeles:20200716T090000=0D=0A= LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm4f9d8ceb024dd551711051e= 06eb598ae=0D=0ATRANSP:OPAQUE=0D=0ASEQUENCE:1593811350=0D=0A= UID:26383c4f-84df-4ead-bf42-6d151e49357f=0D=0ADESCRIPTION:\n\nJOIN=20= WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm4f9d8ceb024dd551711051e= 06eb598ae\nMeeting=20number=20(access=20code):=20161=20057=20= 2303\n\n\nMeeting=20password:=20q54tRVwK8Mu\n\n\n\nJOIN=20BY=20= PHONE\n1-650-479-3208=20Call-in=20toll=20number=20(US/Canada)\nTap=20= here=20to=20call=20(mobile=20phones=20only,=20hosts=20not=20supported):=20= tel:%2B1-650-479-3208,,*01*1610572303%23%23*01*\n\nGlobal=20call-in=20= numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm3d59c3b1b2bc= d357591267d5f2c08d6b\n\n\nJOIN=20FROM=20A=20VIDEO=20SYSTEM=20OR=20= APPLICATION\nDial=20sip:1610572303@ietf.webex.com\nYou=20can=20also=20= dial=20173.243.2.68=20and=20enter=20your=20meeting=20number.\n\n\nJoin=20= using=20Microsoft=20Lync=20or=20Microsoft=20Skype=20for=20Business\nDial=20= sip:1610572303.ietf@lync.webex.com\n\n\n\nIf=20you=20are=20a=20host,=20= click=20here=20to=20view=20host=20= information:\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm9fa33a66ba736b73e5= 4480005715f92f\n\n\n\nCan't=20join=20the=20meeting?=20Contact=20support=20= here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT=20NOTICE:=20Please=20= note=20that=20this=20Webex=20service=20allows=20audio=20and=20other=20= information=20sent=20during=20the=20session=20to=20be=20recorded,=20= which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20You=20= should=20inform=20all=20meeting=20attendees=20prior=20to=20recording=20= if=20you=20intend=20to=20record=20the=20meeting.\n=0D=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:\ntable=20{\n=09= border-collapse:=20separate;=20width=20=3D100%;=09border:=200;=09= border-spacing:=200;}\n\ntr=20{\n=09line-height:=2018px;}\n\na,=20td=20= {\n=09font-size:=2014px;=09font-family:=20Arial;=09color:=20#333;=09= word-wrap:=20break-word;=09word-break:=20normal;=09padding:=20= 0;}\n\n.title=20{\n=09font-size:=2028px;}\n\n.image=20{\n=09width:=20= auto;=09max-width:=20auto;}\n\n.footer=20{\n=09width:=20604px;}\n\n.main=20= {\n\n}@media=20screen=20and=20(max-device-width:=20800px)=20{\n=09.title=20= {\n=09=09font-size:=2022px=20!important;=09}\n=09.image=20{\n=09=09= width:=20auto=20!important;=09=09max-width:=20100%=20!important;=09}\n=09= .footer=20{\n=09=09width:=20100%=20!important;=09=09max-width:=20604px=20= !important\n=09}\n=09.main=20{\n=09=09width:=20100%=20!important;=09=09= max-width:=20604px=20!important\n=09}\n}\n\n\n\n=09 \n=09\n=09=09\n=09=09=09\n\n\n\n=09=09=09\n=09=09=09=09\n=09=09=09=09=09= \n=09=09=09=09\n=09=09=09=09 \n=09=09=09=09\n=09=09=09=09=09= \n=09=09=09=09\n=09=09=09=
\n=09=09=09=09=09=09When=20it's=20time,=20join=20the=20Webex=20meeting=20= here.\n=09=09=09=09=09
\n=09=09=09=09=09=09Meeting=20number=20(access=20code):=20161=20057=20= 2303\n=09=09=09=09=09
\n=09=09=09
Meeting=20password:q54tRVwK8Mu
\n\n=20=20=20=20=20=20= =20=20\n=20=20=20=20=20=20=20=20=09 \n=09=09=09\n=09=09= =09=09\n=09=09=09=09=09\n=09=09=09=09=09=09\n=09=09=09=09=09=09=09= Join=20meeting\n=09=09=09=09=09=09= \n=09=09=09=09=09
\n=09=09=09=09\n=09=09=09\n=09=09= \n\n=20\n 
 
\n\n =20
Join=20by=20phone=20 =20
1-650-479-3208=20= Call-in=20toll=20number=20(US/Canada)=20 =20
Global=20= call-in=20numbers =20


\n\n 
\n\nJoin=20from=20a=20video=20system=20or=20= application
Dial=201610572303@ietf.webex.com =20
You=20can=20also=20dial=20= 173.243.2.68=20and=20enter=20your=20meeting=20number.=20 =20=
 =20
\n\nJoin=20using=20Microsoft=20Lync=20or=20Microsoft=20Skype=20for=20= BusinessDial=201610572303.ietf@lync.webex.co= m\n\n=09 
\n=09= If=20= you=20are=20a=20host,=20click=20= here=20to=20view=20host=20information.
\n\n=09=09=09= \n=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 \n=09=09=09=09\n=09=09=09=09=09Need=20help?=20Go=20to=20http://help.webex.com\n=09=09=09=09=09\n=09= =09=09=09\n=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 \n=09=09=09\n=09=09= \n=09\n\n=0D=0ASUMMARY:IPv6=20Operations=0D=0A= PRIORITY:5=0D=0ACLASS:PUBLIC=0D=0ABEGIN:VALARM=0D=0ATRIGGER:-PT5M=0D=0A= ACTION:DISPLAY=0D=0ADESCRIPTION:Reminder=0D=0AEND:VALARM=0D=0AEND:VEVENT=0D= =0AEND:VCALENDAR=0D=0A= --Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916 Content-Disposition: attachment; filename=raw-agenda-data-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="raw-agenda-data-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

This document describes the drafts associated with this group. It describes their current state as seen by the RFC Editor, IESG/AD, and the working or research group. For working group drafts and individual submissions, it also indicates whether the draft has been updated since the previous IETF meeting. Drafts that are new or have been updated are "current"; other drafts are "old".

On each draft, there are three or four links:

  • the relevant datatracker link,
  • a pointer to the HTML version of the draft in the tools directory,
  • a pointer to the email archived on IETF mailing lists related to the draft, and
  • a pointer to RFCDIFF against the previous version, if there was one.

WG: In WG Last Call

Individual Submission: Unupdated

Individual Submission: Updated (since 2020-03-28)

The charter for this group is at https://datatracker.ietf.org/group/v6ops/about/

Wed Jul 15 07:29:12 2020

--Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_09ADAB61-3556-4616-8BF9-013A71159916-- --Apple-Mail=_1105CD04-DCF9-4041-B302-CCB1E9616C4E-- From nobody Wed Jul 15 10:29:26 2020 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 6C32F3A0D56; Wed, 15 Jul 2020 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7z4rUVxaNQ6; Wed, 15 Jul 2020 10:29:21 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3DE3A0D0E; Wed, 15 Jul 2020 10:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594834159; x=1595438959; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=NTCIAIZV1B6/V0QSzKEI/iXt9gCCAXDZB7LxiDifoRQ=; b=Cg1dYeYn/TI5j cIA+8F1ydknPYxwYjkryE8+HADLTSmMtJJW4R9frPBjAz3/dNmDOYQAHOmHLlCRm DQ9jUUMySjVC/k6ChJgwD9xHEmanK0I5MxFmg/51VQOgA/w6SEKBJNMhzpBscBvG sjOrUOjybDDbI3ZWn2yWa4V/IIehuw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 15 Jul 2020 19:29:19 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 15 Jul 2020 19:29:18 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000284459.msg; Wed, 15 Jul 2020 19:29:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c99:b839:c816:17ed X-MDHelo: [10.10.10.144] X-MDArrival-Date: Wed, 15 Jul 2020 19:29:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1465db90bd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Wed, 15 Jul 2020 19:29:13 +0200 From: JORDI PALET MARTINEZ To: Vasilenko Eduard , "v6ops@ietf.org" CC: "draft-ietf-v6ops-464xlat-optimization@ietf.org" Message-ID: <9E6F1483-9805-4944-A93D-6057053128CB@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> <6897a420362d4caaaf24c77f7eca4e29@huawei.com> In-Reply-To: <6897a420362d4caaaf24c77f7eca4e29@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 17:29:25 -0000 Hi Vasilenko, My presentations and I guess the ones from other people, are based in the *= current* 464XLAT RFC6877, so they are correct. Before working in the optimization, not having discovered this issue, I was= convinced that stateless is much better. And this is still true, if it is = supported in the SoC or implementation. However, it is not true if you want= to have the optimization and avoid problems when there are proxies for ser= vers, etc., which require tracking the connections as per 5.2.4. However, because the optimization can be disabled, it is perfectly possible= to support also stateless in a given product so to improve the performance= . For example, you can have a SoC and a Linux based CPE that can do hardwar= e stateless NAT46, in some cases (you're a geek and you don't have any IPv4= -only smartTV), you could disable the optimization and increase the perform= ance of the CPE. I know it is a extreme case, but it is not a big trouble i= n terms of implementation to support both ways. The optimization requires it to be stateful this is clear. I fully agree th= at it should be more clear, but that doesn't change the status of the curre= nt reality or previous presentations of RFC6877. Same about RFC8683 and RFC8585, they are refering to the actual RFC6877. This is the same for *any* presentation or RFC referring to a previous RFC.= Something may change, some new options could change something that, as in = the current case, RFC6877 indicates it may be statless or stateful, and thi= s doesn't invalidates previous work. Right? I know for sure: 1) Android is stateful NAT44 then stateless NAT46. This has been confirmed = by Lorenzo a couple of times in meetings, probably also in the mailing list= . 2) OpenWRT it is stateful. 3) I've seen several Linux implementations. Under NDA, working with several= CPEs vendors in several proyects, so I can't name them. Some are in the li= st and could say by themselves. 4) Jool is stateful NAT44 then stateless NAT46. 5) Several SoC (System on Chip) support only stateful NAT44, not directly s= tateless NAT46. Ole has indicated that VPP is stateless NAT46, but it also supports support= s stateful NAT44. iOS doesn't support CLAT for the UE itself (because all the apps should be = IPv6-only ready and the support of HEv2 does something similar), but for th= e tethering yes. However I don't know if it is statelss or stateful. So I'm talking with the information I've for real. Anyway, this doesn't excludes at all 464XLAT being used in broadband CPEs (= T-Mobile also provides broadband service via 4G using 464XLAT, for example)= , broadband wired, etc. It is clear in RFC6877. Similarly doesn't preclude that if you want to support the optimization, yo= u make sure that you're using a stateful CLAT in case your existing impleme= ntation is stateless now. Regards, Jordi =EF=BB=BFEl 15/7/20 17:53, "Vasilenko Eduard" = escribi=C3=B3: Hi Jordi, Yes, this one looks like outside of any context:=20 " Consequently, the EAMT entries should not be used directly to establish a forwarding path, but instead, to create a stateful NAT entry for the 4-tuple for the duration of the session/connection. " It is difficult to understand that it is about mandatory stateful CLAT. About "everybody use stateful CLAT": Your presentation clearly state "Stateless CLAT" (slide 6): https://www= .lacnic.net/innovaportal/file/2907/1/ipv6-trans-mechs-status_v1-short-jordi= -palet.pdf And your RFC talking only about "stateless CLAT": https://www.rfc-edito= r.org/rfc/rfc8683.html RFC 8585 does not clarify type of CLAT. Many hundreds of stateless CLAT discussions is possible to google: https://conference.apnic.net/34/pdf/34th_apnic_464xlat.pdf https://ipv6council.be/IMG/pdf/12-wuyts-XLAT_at_the_CPE.pdf https://www.apricot.net/apricot2013/assets/20130226_apricot2013_ipv4_ov= er_ipv6_1361969703.pdf https://datatracker.ietf.org/meeting/84/materials/slides-84-sunset4-1 https://www.ipv6.org.uk/wp-content/uploads/2018/11/Nick-Heatley_BT_EE_4= 64xlat_UKv6Council_20180925.pdf https://www.rfc-editor.org/rfc/rfc8683.html https://archive.nanog.org/sites/default/files/wednesday_general_byrne_b= reakingfree_11.pdf Is everybody talking about stateless, but implement stateful? At least somebody not: https://sites.google.com/site/tmoipv6/464xlat " No changes were required to the existing T-Mobile USA IPv6-only + NAT= 64/DNS64 to support the 464XLAT architecture. The stateless RFC6145 transl= ation on the handset was the only modification needed. " OK. Are you sure that Google Android support Stateful CLAT in principle= ? Because Linux does not. Linux daemon https://github.com/toreanderson/clatd Is based on http://www.litech.org/tayga/ That claimed to be "stateless NAT64 implementation" Android looks a little behind (using previous version of CLATD): https:= //android.googlesource.com/platform/external/android-clat/+/c786b7409032050= 721021583236de8608ac8948e/clatd.h Android investigation is better to start here: https://android.googleso= urce.com/platform/external/android-clat/ Hence, Android CLAT daemon does not support stateful CLAT too. Could it be that CLAT is used together with some other daemon for NAPT = before CLAT? Looks like No CLAT daemon dependency: https://openwrt.org/packages/pkgd= ata/464xlat Then how is it possible that Statuful CLAT is used, if it is not suppor= ted on CPE/Smartphone? Eduard -----Original Message----- From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es]=20 Sent: 15 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 17:17 To: Vasilenko Eduard ; v6ops@ietf.org Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-= 02 - concern on statefulness I think your point will be to make it clear in the document that for th= is optimization to work, the CLAT should be stateful? I think is there (5.2.4. Forwarding path via stateful NAT for existing= EAMT entries), but I will make sure to add the relevant text in the next v= ersion to make it clearer.=20 I insist: most of the CLAT implementations today (running in both CPEs = and UEs) are stateful. At least this is the data I've. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" escribi=C3=B3: Hi Jordi, I still believe that tough (new) requirement that CLAT should becom= e Stateful (mandatory) Make sense to insert into the document. And explanation why stateful NAPT is needed would be good. I have spent some time to research this - it is better to save time= of other people. It is important point that is omitted in the document. For the name: I do not have any strong opinion. Just I see that draft is applicable mostly to MAP-T, And not much applicable to XLAT (because majority of installations = have stateless CLAT). But the name mislead to opposite conclusion. Eduard -----Original Message----- From: Jordi Palet Mart=C3=ADnez [mailto:jordi.palet@theipv6company.= com]=20 Sent: 15 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 16:48 To: Vasilenko Eduard ; v6ops@ietf.org Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimizat= ion-02 - concern on statefulness Hi Vasilenko, The implementations of 464XLAT, can do the same (and in fact, many = of them is what they do). NAT44 stateful and the 46 stateless. Many SoC hav= e embedded NAT44 acceleration, but not NAT46, so that explains it as well. I guess that could clear your concern? I've several customers doing 464XLAT in broadband, one of them 25.0= 00.000 subscribers. There is no difference in doing 464XLAT in cellular and= broadband. When we say in the title 464XLAT/NAT64, I think both are covered. B= ut I've no issue to change the title if this makes sense to others. We coul= d explictily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, i= n my opinion. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:40, "Vasilenko Eduard" escribi=C3=B3: Hi all, I have concern on the capability to use this mechanism for 464X= LAT, but it should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB traffi= c is still designated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. acti= ve sessions from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to squee= ze (for path to Internet it would be "source IP address") many private IPv4= hosts to one IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port tra= nslation is mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearly st= ate in the document that we are going to reuse NAPT. Then translation would= be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, it c= ould be not public, but public A+P has been given to MAP CE anyway - better= to reuse it for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not po= pular - not implemented by many carriers (if any?). It would be the big news that Carriers should choose stateful C= LAT option for 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use Stateless= CLAT for basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 = sites? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smooth ex= pansion for MAP-T. Hence, does it make sense to change the name of this draft to r= eflect MAP-T as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of intern= et-drafts@ietf.org Sent: 11 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimizat= ion-02.txt A New Internet-Draft is available from the on-line Internet-Dra= fts directories. This draft is a work item of the IPv6 Operations WG of the IETF= . Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide = access for IPv4-only devices or applications to IPv4-only or dual-s= tack destinations over IPv6-only infrastructure. In that case, t= he traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NA= T64, at the egress point). When the destination is IPv6-enabled, th= e second translation might be avoided. This document describes a pos= sible optimization to 464XLAT and MAP-T to avoid translating IPv6 = flows back to IPv4 if the destination is reachable over IPv6. The= proposed solution would significantly reduce the NAT64 utilization in= the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optim= ization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimizati= on-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-= optimization-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-op= timization-02 Please note that it may take a couple of minutes from the time = of submission until the htmlized version and diff are available at tools.ie= tf.org. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jul 15 11:17:44 2020 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 E58FE3A0A6D; Wed, 15 Jul 2020 11:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLTG3P5a2sx9; Wed, 15 Jul 2020 11:17:41 -0700 (PDT) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5873A0FD3; Wed, 15 Jul 2020 11:17:15 -0700 (PDT) Received: by mail-wr1-f66.google.com with SMTP id z13so3752200wrw.5; Wed, 15 Jul 2020 11:17:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cwKialJs6FhrBslJX0CzloAbRR8ifMoG1T75XdJ1W0o=; b=Pi5V2V4FTKuH7H1ia4qvZ6i+1d/QDJGtUIv3+2Wky7clf49RTAsj8DvA2/sQrGXBKz HIxcN9rPZHntsyfiqYQBQKMgyZHVyMjK8CgYaBP7RUfQIlhoT/FuKLKsw5FGa+p2Vg+X KOTLwRRgNMZ8PkD8rEtGsy948KMMP09zJOuy0sWOV7pgNjGI2UocVmpqhEMoJg1/PMGj 0X2PMWLJrjAUjGM7oFJ/dnYaib5rYqFEAnlIiLKaiMl54oJTfEJd6FsSfj0xxPT5wfLv iyjGZZ7xa1LXctiWOy5ICtoefmaKIBfIJdQI+orhBWdfy8ePYIgA3U81Hv70WCIB6jAL 00uA== X-Gm-Message-State: AOAM533p1IGODM8M0NNX3L+HxZJLzGh5Kek8U+VTA0eD9clQCb5Lmvrj m6C+gLU6eUvDv0BoZc/oVZun2lhP2njNHetF2L0= X-Google-Smtp-Source: ABdhPJxQG14ysbhLTjlfux4e1ZnCT6xtlhG1hxXSGEEG9Jy+DU5f7S5FR8UaaMXUfd3jYFizYFCt1xMUgNOH5mCCq4U= X-Received: by 2002:adf:f350:: with SMTP id e16mr599621wrp.43.1594837034028; Wed, 15 Jul 2020 11:17:14 -0700 (PDT) MIME-Version: 1.0 References: <159393243745.16561.15755916877984628536@ietfa.amsl.com> <17D88CF8-B2CF-4737-910A-3D07881946BA@gmail.com> <24FDA390-8587-4366-8E4D-C6BBBB529CF8@theipv6company.com> <0B3CDBC8-3EBE-4FC4-AC5A-2DCD2480B502@theipv6company.com> <0A5FD684-199C-4979-8818-36C9B3047746@consulintel.es> In-Reply-To: From: Erik Nygren Date: Wed, 15 Jul 2020 14:17:02 -0400 Message-ID: To: Jen Linkova Cc: JORDI PALET MARTINEZ , V6 Ops List , V6Ops Chairs , draft-ietf-v6ops-464xlat-optimization@ietf.org Content-Type: multipart/alternative; boundary="000000000000e352a205aa7eee7a" Archived-At: Subject: Re: [v6ops] - pre-(shepherd-writeup) review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 18:17:43 -0000 --000000000000e352a205aa7eee7a Content-Type: text/plain; charset="UTF-8" On Wed, Jul 15, 2020 at 5:23 AM Jen Linkova wrote: > On Fri, Jul 10, 2020 at 9:29 PM JORDI PALET MARTINEZ > wrote: > > [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or even > the AAAA (without this optimization), the result is the same. In my opinion > it all depends on how and "where" the attack occurs, because the DNS cache > may be poisoned in the CPE or the hosts, etc. > > > Sorry I should have clarified. The difference is that spoofing *one* > DNS response would affect *all* devices behind the CPE *even* if those > device are not using that CPE as a resolver and use DNS over [smth] > and/or DNSSEC. My laptop might build a secure tunnel to the DNS server > it's using and validate response using DNSSEC. > But it does not help because my TV asked for an A RR and the > corresponding AAAA was spoofed on the CPE, so now all devices in my > house can not reach that IPv4 address. > It's also not just a matter of spoofing. All it takes is for one device to get tricked into doing an A/AAAA looking for a legitimate name (eg, URL embedded in an advertisement or even email) and if the attacker controls the name being looked up they can put in a redirection for an IPv4 address of their choice (which could belong to someone else) to an IPv6 address of their choice (which could belong to the attacker). As this is a legit name, it could be happily DNSSEC signed as well. The problem is that an attacker can return an A record for IP space they don't own. The collision invalidation may help in some cases, but it won't help for cases where other clients in the local network are using DoH or are caching and using A records well past their DNS TTL (common in some cases like older Java). This is a fairly serious new attack vector that is very easy to exploit (much more so than DNS spoofing). If we see deployment of this, we should expect to see people attacking it this way to bad effect. Erik --000000000000e352a205aa7eee7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 15, 2020 at 5:23 AM Jen Linkova <= ;furry13@gmail.com> wrote:
<= /div>
On Fri, Jul 10, 2020 at 9:29 PM JORDI PALET MARTINEZ
<jordi.p= alet@consulintel.es> wrote:
> [Jordi] If instead of the spoofing the AAAA, it is spoofed the A or ev= en the AAAA (without this optimization), the result is the same. In my opin= ion it all depends on how and "where" the attack occurs, because = the DNS cache may be poisoned in the CPE or the hosts, etc.


Sorry I should have clarified. The difference is that spoofing *one*
DNS response would affect *all* devices behind the CPE *even* if those
device are not using that CPE as a resolver and use DNS over [smth]
and/or DNSSEC. My laptop might build a secure tunnel to the DNS server
it's using and validate response using DNSSEC.
But it does not help because my TV asked for an A RR and the
corresponding AAAA was spoofed on the CPE, so now all devices in my
house can not reach that IPv4 address.

=
It'= ;s also not just a matter of spoofing.=C2=A0 All it takes is for one device=
= to get tricked into doing an A/AAAA looking for a legitimate name
(eg, = URL embedded in an advertisement or even email) and
if the attacker con= trols the name being looked up they can
put in a redirection for an IPv4 add= ress of their choice (which
could belong to someone else) to an IPv6 address= of their choice
(which could belong to the attacker).=C2=A0 As this is a le= git name,
it could be happily DNSSEC signed as well.=C2=A0 The problem is th= at
an attacker can return an A record for IP space they don't own.
=

Th= e collision invalidation may help in some cases, but it won't help
for c= ases where other clients in the local network are using DoH
or are caching a= nd using A records well past their DNS TTL (common
in some cases like older = Java).
This is a fairly serious new attack vector that is very = easy to exploit
(much more so than DNS spoofing).
If we see deployment of thi= s, we should expect to see people attacking
it this way to bad effect.

=C2=A0 =C2=A0 Erik
--000000000000e352a205aa7eee7a-- From nobody Wed Jul 15 14:22:16 2020 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 D5BDC3A0920 for ; Wed, 15 Jul 2020 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMFStSlT6RNN for ; Wed, 15 Jul 2020 14:22:13 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A333A091D for ; Wed, 15 Jul 2020 14:22:13 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id e90so2618200ote.1 for ; Wed, 15 Jul 2020 14:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D0byaGtdjYcAm66Dj9/p5f9LB48bcphGH7nRsMor18U=; b=jg4LN/MfKvyWtbiD+1BFusLuey9sZWsVvKCoTmfW6CJv1GIREdLHJ7G9/+BA/K0o4V x1cs08x4KhqNCxcnqVRLm45x+U096YQOCO/AliuC09APncM3SgdlBVh3GMMvOKe5fAXv PJNAg+gPi/s0SydGNVh0gbjDkM2ZdMQZCDSfJYTuvMP7NMRW7GG1aRPPzWkGylL3rdzL cj7szJireqUaSP8DbbGosSfZBWouXfp7p/HvfG0/Rchdx9lKj7mGX2UBQReq9OHiPzQB SJY/sXAkNEWdid24uVnk5yCoaHEumK4YzqK5bWYf8zSPQ54hzyGERNkrtXe3MWUeMGbY XegA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D0byaGtdjYcAm66Dj9/p5f9LB48bcphGH7nRsMor18U=; b=YmEkFhWhkqz0wN6kMwfdIoFjhBW/DjDBUILPB3qXLBJSKm0aoNLhXzY4ziUJ0W3k4b lAlGJlRC40FYVrdGmXZVky2fh9y9fQFXZWsQSDfnitf/Abs4bMROGzonQSX70lBegm4O dXm5kAOlzNq2CmCQsAG7J2Eolz2w4tp2cAunI740Yuw59YfYCF33GyJAnXKEeVVNnJie brN4eyNXQl8pQGKetT2ncLuwDiPB5dQBoHLXJDzffVhqAkU0ku8jPW1/JbFJTi20bcZN vKuNSrG8HP3NSpvkynAxjOXoNRchBzpnbooJI8bYRUiWCzMj+yjkAJ0Qi8hZezD8yKTD 5Wnw== X-Gm-Message-State: AOAM531l2cFMDS1uM6NUEM82l68r9GHHsT5IIfaFcL7B6j3+Nl4FjZUh s0Zf/d5W0PQIqnE22COe25m67JbfZpStU5h2/wjPC2zt X-Google-Smtp-Source: ABdhPJw+w4PRoJrjERoH7CPjk04oexWi0Lg/x2Igd0+w5RJSIul8PYNspDO5YHkHV9+cQyJeX2+n2xHmmFVWtT5xAtk= X-Received: by 2002:a9d:6a12:: with SMTP id g18mr1600505otn.155.1594848132668; Wed, 15 Jul 2020 14:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Kline Date: Wed, 15 Jul 2020 14:22:01 -0700 Message-ID: To: Ron Bonica Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Working Group Last Call draft-ietf-v6ops-464xlat-optimization X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 21:22:15 -0000 On Mon, Apr 27, 2020 at 10:05 AM Ron Bonica wrote: > > Folks, > > This message initiates a WG Last Call on draft-ietf-v6ops-464xlat-optimization. > > Please submit comments by May 11, 2020. > > Fred and Ron (July 15th < May 11th, yes? Apologies for the lateness of the review.) doc{draft-ietf-v6ops-464xlat-optimization-02} I find this draft to be problematic in several ways. I'm not sure if/how it can be fixed, frankly. But perhaps I've misunderstood several things... [1] As has been noted by others, the EAMT maintenance laid out in 5.2.3 and 5.2.6 is attackable by someone who can cause IPv4-only hosts to lookup a name in their control. This name would have some victim IPv4 address for an A record and some other IPv6 address for an AAAA that the attacker controls. I disagree with the assessment in the Security Considerations section on this point. This is very different. Ordinarily, translation entries are created by observation of traffic. Here, the translation entries are partially pre-made by DNS results. And this is where all the trouble starts, IMHO. [2] What about STUN/TURN and custom implementations of similar functionality done via encrypted means (e.g., QUIC)? If I do: bash$ for i in stun turn; do host $i.l.google.com; done stun.l.google.com has address 172.253.117.127 stun.l.google.com has IPv6 address 2607:f8b0:400e:c0a::7f turn.l.google.com has address 173.194.196.127 turn.l.google.com has IPv6 address 2607:f8b0:4001:c03::7f An IPv4-only host would be unable to learn its public IPv4 address information if this "optimization" were employed because the IPv4 STUN/TURN service would be utterly unreachable. I don't think we can just "exempt" STUN/TURN traffic because there might be custom, cryptographically protected ways to effect much of the same thing, and these services could be run on non-standard ports. I don't think we can even craft some exemption for just optimizing "CDN/cache traffic" because then there are restrictions being imposed on what the CDN devices can do (they already do much more that just serve static cached content). [3] Isn't the possibility of an EAMT entry collision (5.2.10 a) really bad? Different apps can use different DNS services to resolve hostnames. But even if a client used the CE's DNS, a service provider can have two hostnames with the same IPv4 address but two different IPv6 addresses. This is supported today, but with this "optimization" wouldn't the EAMT mapping collisions break this use case? Given the above, I'm sure how this can be fixed. 5.2.1 can work, if a CDN pod is located within the ISP's network and the CDN operator is amenable to the operational work and to the restriction on the kinds of services that can be provided. But I think the rest of the stuff...is just going to break things. :-/ From nobody Wed Jul 15 20:22:31 2020 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 35CE63A0B33; Wed, 15 Jul 2020 20:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyeGRUcRKZJi; Wed, 15 Jul 2020 20:22:29 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31BD3A0B32; Wed, 15 Jul 2020 20:22:28 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id z63so4236257qkb.8; Wed, 15 Jul 2020 20:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jgGgigR+fPM2c4sKZ2zva185XEuAXQNfzVJidR8//VA=; b=aY//AiiCwIPe7sH4eRMeAqKSkH0DlV8ExjMBcX2U/the9FwI530Cg4Cju4R5dsP6Cs y/gnCnM2N4xvyjl+4Nty9i2ExHqvmF+ruCDZKdgAe/THQ5aZh/JYxiLFBani78JiRh5x 5JAOvkFKHZzRtCu3cTuZKb/YmxdB9G5y7Ykni66o2YqoVhSt9Aqm9/Rod51UNlojSvG3 PxvIM1o7zSgvZN9tc8rk7+lfr3Vhsif7mTttutj/pJ87Q9/NJRNrwacIuWeOFxv265vF ZZM3qmcAQkWet/KFWD5pIcXVCb66CR2led3p4nFmT2PuQvPj978rUjU2bBRHgbyy75as P35g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jgGgigR+fPM2c4sKZ2zva185XEuAXQNfzVJidR8//VA=; b=tPwcYqdvwTTtIJ4EtMzgkTkCgSDazO/pFgBBsqGWdy/nykVM0gysCPxx/5vSfz/YKR mznUDdow7YMY4P7PT3pP2pWl88f8Qx46NJ2evznewSiD+NeGYKCLoHVI6RbvkekTfxGQ +XYmMocuE+0/qrpP7B81jHEXn0lt4406HK5+l20emi8zAJ0gIsNMqEuied8A3r53+52k 9ccITRradecrydvzK7flYbC4Z3qOHeVT7ZkidZRDUUdMwiczUkzlWbNFbijfRswTSaEr 2s3K9XX6d+3kmKZJX3poZbF2PySizBw/4lw8CPsVV5ObJvAOXfR/Ersy9Fu/jGSgtJXG XqAQ== X-Gm-Message-State: AOAM533laCCjMCn9llNsepHtcYkHAyLDIXyyq/tiCH6DrP3UJBn79o16 pidYySH8aFxyuqn+Few9NkK/WrFEcQK5AkCSmHwGdHg1slk= X-Google-Smtp-Source: ABdhPJwx1i8uPkLocanKeoMZA7m8VXX0VV9ogi3tDG9Z05iTP8gu0lI07ncW770mnmG9Ztm7LrkQfZUtfv2AUzvF4gU= X-Received: by 2002:ae9:dcc6:: with SMTP id q189mr2189204qkf.332.1594869747072; Wed, 15 Jul 2020 20:22:27 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Thu, 16 Jul 2020 13:22:16 +1000 Message-ID: To: V6 Ops List , draft-ietf-v6ops-464xlat-optimization authors Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] More thoughts on draft-ietf-v6ops-464xlat-optimization X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 03:22:30 -0000 Sorry, it's me again with more comments.. First of all I fully agree there is a problem and it would be highly desirable to solve this problem. It's not some form of corner case or misconfiguration which we could ignore. However I'm getting less and less convinced that the solution proposed in the document (Section 5.2) is the best way forward. Others have already mentioned scenarios where the algorithm defined in Section 5.2 would break things for clients and/or introduce new attack vectors. So I've been thinking about Section 5.1. The draft provides two reasons to discard that approach: 1) this solution will only be possible if the CDN/cache is in the same ASN as the provider network, or somehow interconnected without routing thru Internet. [nitpicking: 'the same ASN' is not a requirement, it's more about having a direct connectivity. The caches can easily have their own ASN] What confuses me: isn't it the case for IPv4 traffic already in a dual-stack network? If the operator has a dual-stack network, the IPv4 traffic to local CDN caches would bypass CGN devices while traffic for external destinations would need to be NATed. There is no easy way to bypass CGN for external traffic, right? So if the solution from Section 5.1 is implemented, the operator would need to do NAT64 instead of CGN for the same traffic. While it would not drastically improve the situation compared to dual-stack/IPv4-only right away, it would not make it worse either. Also, as IPv6 support is improving, one could expect % of traffic to go through NAT64 decreasing. 2) some work required on the CDN/cache side. Yes, it would introduce an additional requirement for CDNs to ensure that for each IPv4 address there is a corresponding NAT46-translated IPv6 address. The routing needs to be updated as well - but I do not see this as a big issue - whatever method is used to propagate IPv4 routing information (BGP?) could be used for propagating IPv6 information as well. Or am I missing anything? At least in this case all mechanisms used are well-known, straightforward, time-proved and much more predictable than creating dynamic EAMT entries which are impossible to troubleshoot if smth goes wrong. To make the long story short, I believe the approach described in Section 5.1 looks much cleaner and safer than one in Section 5.2. -- SY, Jen Linkova aka Furry From nobody Thu Jul 16 06:46:47 2020 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 65F773A07F2 for ; Thu, 16 Jul 2020 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbMxXMrCAL74 for ; Thu, 16 Jul 2020 06:46:45 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E0C3A07F7 for ; Thu, 16 Jul 2020 06:46:45 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id o13so4896983pgf.0 for ; Thu, 16 Jul 2020 06:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=GZpPW2wCaMpWTHfiavrWeVS9ICOmCpfsSL8yCtMA7/4=; b=BTkeFCjsSkwfDT8DSxvSnhI7m/7BF+I1rPFFM5infhqHOGh0+NORctnii0yJ/Xz8XA GsstGbCoyJnBl2Mf7YT24+g/hDKghY+yPlA5C+CJhyCZgX35jhJ6Q6LKsOT0M/V93PST FyF1PmHjDgLbSSV+c4K+7phdFFfhU/OfRWZMX0q5e70l0Svms4kguB7vH5pzUwkJLDFZ byy0cQmZt1LxvizrbBAjU2aJLlRlOnM7xweN6r8St44aKOD4F0RHs1YurRHrfnbCHZfK BiDdvVBUIOh+B2j4IWSjphTCERjhZZWN/LPvoioq2PWYU31xKkcEE8ZoCVThNEtddyLx WOmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=GZpPW2wCaMpWTHfiavrWeVS9ICOmCpfsSL8yCtMA7/4=; b=ZnA4+ylkwdmh46wIH1EOpDl3OohWKgEHQtW9OjLfxv/YhUXtb3I2CjzvMlghKdN5gV qRELz/GzXvm9eh+TrNIjVDNnp7I2ld43yq+ZZ2J63h6zGJeT3QGTTd9pOCIfkypD7SE4 VCffVPXP5Raxa4iTpCsMUPZ6tKBCTdA3EoZHush50Mru8nvQ4T0HiivdG+Nc4AxT6t3C BKG3crcomPyLTHY62GDMp7UNG2N4iI3AUza0Y0fK58994TUbMDFpV4mioo3s9nSCYm/G STDX1sXILUhBXCRhdcBNw7nuPlVU1r2Q2FVZvrCyChK7gtgtw2fh4A3icfon9trsc5en GjmQ== X-Gm-Message-State: AOAM532zaWPE5wOrcZQsP+n2/JZYAbWaZv1/bH3ba1KkSxYu3ABZpO98 a9OuqkpVTaA/ThSnopOwh2inV6/G9f4= X-Google-Smtp-Source: ABdhPJzV4xkIuvBnruEAz1ATYyp6inUVYHVLAQuji9bBniSIw3oQ4hliJhb/9QZiB6c/+5X74bxSTA== X-Received: by 2002:a62:8045:: with SMTP id j66mr3684194pfd.162.1594907204485; Thu, 16 Jul 2020 06:46:44 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::14fa? ([2600:8802:5800:652::14fa]) by smtp.gmail.com with ESMTPSA id t126sm5013497pfd.214.2020.07.16.06.46.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2020 06:46:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Fred Baker X-Priority: 3 In-Reply-To: <482946731.2043301593811351061.JavaMail.nobody@rva2rmd102.webex.com> Date: Thu, 16 Jul 2020 06:46:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <482946731.2043301593811351061.JavaMail.nobody@rva2rmd102.webex.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] Webex meeting scheduled: IPv6 Operations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 13:46:46 -0000 Webex seems pretty sure that the meeting isn't starting early. I expect = it will come up at the top of the hour. > On Jul 3, 2020, at 2:22 PM, V6OPS Working Group = wrote: >=20 > =20 > You are the host for this Webex meeting. >=20 > =20 > When it's time, start your Webex meeting here. >=20 > =20 > Meeting number (access code): 161 057 2303 > Meeting password: q54tRVwK8Mu > =20 > Thursday, July 16, 2020 > 7:00 am | (UTC-07:00) Pacific Time (US & Canada) | 2 hrs > =20 > Start meeting > =20 > Join by phone > Tap to call in from a mobile device (attendees only) > 1-650-479-3208 Call-in toll number (US/Canada) > Global call-in numbers > =20 > Join from a video system or application > Dial 1610572303@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > =20 > Join using Microsoft Lync or Microsoft Skype for Business > Dial 1610572303.ietf@lync.webex.com > =20 > If you are a host, click here to view host information. > =20 > Need help? Go to http://help.webex.com > =20 > Fred Baker fredbaker.ietf@gmail.com GPG Key DD863FE0 GPG Fingerprint 72D8 E526 3426 56BA 7DB8 CABB 1217 519D DD86 3FE0 From nobody Thu Jul 16 10:05:49 2020 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 440AC3A0C97 for ; Thu, 16 Jul 2020 10:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoZSLuGWNc-F for ; Thu, 16 Jul 2020 10:05:47 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D6E3A0C98 for ; Thu, 16 Jul 2020 10:05:47 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id w2so5143682pgg.10 for ; Thu, 16 Jul 2020 10:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9Hyd65BmCx0wstOTqx+hQ1iWgJVSlTnBS2FU5gVEalA=; b=OdmjDXn8KiZK5er4bNT2Zey9I4Xw/RL28inb5bq9cRBSDZPM/066sVAn45kEi99nm7 rl8iECSoUEr79BP2Wt05F1C+FAYrbOLycaynPB5W6CraUtifTqRCuvcUGdHSpbTgo4o6 f1N3T/C85cKAzz/RQGj/2JQbBt6Tb5LCcPH10a/h05Jh0rdL87yHBO7aIiGXrbBMb75N 142Z1zRtkZLkrYHJb4QjL0Rh20Dk32nqbfvLH0ytymanYr68+gWbIIgfjex2AfkeEUoq KzGE5rRd6yBBN9LxOR1s2PaskaM321rkp3krjFe99po0/546STHzEGTLXlrm0EraBFuG PpCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9Hyd65BmCx0wstOTqx+hQ1iWgJVSlTnBS2FU5gVEalA=; b=dlRwZrW3e3I6sdjoPmKhucnWIqz88nOytUtwpvaDw9C44LGNf63hvAYkD6YLrU9PpW LstkLkbToFUbaY4CLRNJgTOmoQRlSuayU98XXJs+zDLMTttK9Fmspudfs29ZO6v4jihf +WRBi0d7QAYuMe1ebs1mxkZN6N+HthShjjlY5JR6eCC13oUhvYGIAM4okrnKP7lH5rWz mVwEbnEFFI22DaMWcKt6HMwFXCtK83vYb3+lM44Y60pqew/Jp4NrgZ4pSFZ6bym90Y6V oP2DM7GXJq149Jwc/BqG80oQaY9EsLaleHU2POcty84RFSKBnvqNsOGGmzePVtRbpMgn lvOQ== X-Gm-Message-State: AOAM533nLnL3z0re7VWggRW/9DSSYVvUGo792ndrqpp3A2cSPpydLlil Z0kkJ7uh/YyIfzN9dVGzQwtec1MckWc= X-Google-Smtp-Source: ABdhPJxLiImnoY0Hv+avzu/9Osak1q7w3GrdhROI0tbtyQNmBxE9rRDiCu9HJWIBwcMsAKe0lS840Q== X-Received: by 2002:a63:5b55:: with SMTP id l21mr5212981pgm.348.1594919146480; Thu, 16 Jul 2020 10:05:46 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::14fa? ([2600:8802:5800:652::14fa]) by smtp.gmail.com with ESMTPSA id f15sm5571086pgr.36.2020.07.16.10.05.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2020 10:05:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Fred Baker X-Priority: 3 In-Reply-To: <814746451.12265051594918983964.JavaMail.nobody@rva2rmd101.webex.com> Date: Thu, 16 Jul 2020 10:05:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7925B06A-B233-4443-928D-8DB7E9F75E8D@gmail.com> References: <814746451.12265051594918983964.JavaMail.nobody@rva2rmd101.webex.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] Webex Recording: IPv6 Operations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:05:48 -0000 > On Jul 16, 2020, at 10:03 AM, messenger@webex.com wrote: > Your Webex meeting content is available. >=20 > =20 > IPv6 Operations > =20 > Host: V6OPS Working Group > Thursday, July 16, 2020 > 6:55 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 2 hr = 4 min > =20 > Recording > Topic Link Password > IPv6 Operations-20200716 1355-1 View No password > =20 > View meeting content > =20 > Need help? Go to http://help.webex.com > =20 > =20 > =C2=A9 2020 Cisco and/or its affiliates. All rights reserved. = Privacy Statement | Terms of Service From nobody Thu Jul 16 10:07:51 2020 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 8494E3A0C98 for ; Thu, 16 Jul 2020 10:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reG-9VjNtEEJ for ; Thu, 16 Jul 2020 10:07:48 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772A03A0C97 for ; Thu, 16 Jul 2020 10:07:47 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id w2so5146356pgg.10 for ; Thu, 16 Jul 2020 10:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=XGDc9K5VyCYa6VF1wMb+d5ejA2AOhSqyJIQEHvpVNpw=; b=IPROnkdIZ6poIC88QJ0z5Dxlvmmj8QzH1q/YVH1X2sdSUrtNvNZDgJHpF+yRmR4tj+ 2lkWBIh36e3Ts/LHDCMsWSsBJqz6O9Ij0lQ+zH1+TrGkKwpx3mxhG8UrSGCG67gc02s7 4ZtZeRTseKtynUyXIBH/cjXp1bmgniv4aubFLR46wfDPoLuedpRTWTkC01noVEzp3wtw +XXrI27cnKBQ9jYkCA/5AisEFn10W9lCQjMBnulCC44xtK+NPB5kyv9vG/BTzTpLTlDz E0uC3WXUVzP3UNYZqj3o/05vBFeR4xvcDQpD59CXfKI1Z1hlMibLrMNB95GWIYPkAxrh 3Mbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=XGDc9K5VyCYa6VF1wMb+d5ejA2AOhSqyJIQEHvpVNpw=; b=lry9b0xBpEZqSWhBew4FCv3mi3fMuShxS3rz5XvPuPvAAPofVxpMe3HlE1Hadkte8B ecxQjGA2aQvmyHhBQBnAd1XFgGax/44bmuimWxQgLnx66ug6G1/prMZhowGN9RSZWi1P 4F/fKDwSdQY6D7RHYY64swrL+SMJkRn7ebVagiNQrMUJFvv0QSGhLRE7cYQ5n+EuIaQU dxPCYxrcRyI2Ny3/btVm67KSa6LeFGW8R2tPZ+D4n+xicfpyzmEAp2lusCJjO3pFGLvv +MzHrxQQmByg5ihcq1HFRHhdrd3zAFqHzoo0ajqx1MELy5hvNhMIeM91JXPfeps3wpWQ skOQ== X-Gm-Message-State: AOAM532YmS8RGaR14kbvslZYNY2oR/YUl75lT5TnjQlIiJOWe+PpsVl6 uoFXhiH85ttPy2ORoQ5a7p6wPJaAGDk= X-Google-Smtp-Source: ABdhPJzUkmKILF6vtj0OfFhTiVLR6qiBJ4S5+i82fRt0FVQR3XS02Ccj/ovOHANNtGcGSHqOc/YoJQ== X-Received: by 2002:a63:7054:: with SMTP id a20mr4915784pgn.17.1594919266778; Thu, 16 Jul 2020 10:07:46 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::14fa? ([2600:8802:5800:652::14fa]) by smtp.gmail.com with ESMTPSA id e18sm5318338pff.37.2020.07.16.10.07.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2020 10:07:46 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> Date: Thu, 16 Jul 2020 10:07:45 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:07:50 -0000 In today's Interim Meeting, Jordi pointed out that all transition = mechanisms are at Proposed Standard except 464XLAT, and asked the = working group to advance it to that status. /* Personal Opinion */ I have no problem with doing so, but I would ask whether 464XLAT is = indeed a transition mechanism. It is an operational procedure (and = therefore within v6ops' charter to produce, which it did) that uses RFCs = 6146, 6147, 7915, and possibly 6092, which are at Proposed Standard. /* Personal Opinion */ My huffing and puffing aside, I'd like to poll the opinion of the = working group. - does RFC 6877 need to be updated? A good approach to doing so would = be to file errata (https://www.rfc-editor.org/errata.php). The document currently has no errata filed. Consider this an = invitation to file any needed errata and tell v6ops you have done so. - failing that, we certainly have operational experience with it. It = is currently an informational document.=20 Would it be appropriate to raise it to Proposed Standard? - Per RFC 6410, we may be in a position to advance 6877, 6146, 6147, = and/or 7915 to Internet Standard. The criterion and process are described in https://tools.ietf.org/html/rfc6410, and boil down to = (1) multiple interoperable implementations and (2) a general belief that the technology works. =46rom my perspective, = if we believe that 464XLAT is widely deployed and useful, we believe that each of those are "characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community." Please reply all with your viewpoint. If the answer is "yes", fair warning: Ron and I are going to be looking = for someone to write an internet draft documenting the fact and the = deployment status.= From nobody Thu Jul 16 10:23:33 2020 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 7EA423A0841 for ; Thu, 16 Jul 2020 10:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD6JZrN9OdaN for ; Thu, 16 Jul 2020 10:23:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6034C3A0858 for ; Thu, 16 Jul 2020 10:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594920201; x=1595525001; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=SjAr7/gT Oiu8zXSfwqcSvxdk1X+NMWb5ywoul0Ktabo=; b=eTWrwAXiWYlfKh2nS1t231Zq JhyiaiOHp86KkplpIxDZFdvOyd6/5VS58nW1dOzIFz8n/djqP990r+Bk5EcZa6BX 3jRhfkwoBhPz6OcsIuH274wZVYlqZFFrJBv64n/Nsh2XXZz8+DPlUKUNtMNmSSJj ub3A5cnjdSiG3AUPl+A= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 16 Jul 2020 19:23:21 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 16 Jul 2020 19:23:19 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000289412.msg for ; Thu, 16 Jul 2020 19:23:18 +0200 X-MDRemoteIP: 2001:470:1f09:495:a1ad:2510:bacc:bf51 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 16 Jul 2020 19:23:18 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=14667434b7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Thu, 16 Jul 2020 19:23:15 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , IPv6 Operations Message-ID: <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es> Thread-Topic: [v6ops] RFC 6877 to Proposed Standard References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> In-Reply-To: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:23:32 -0000 Hi Fred, all, While I agree that 464XLAT is a procedure to put together other protocols, = it defines how to. This is actually the case for other standard track docum= ents. Sometimes this is in "the border line". However, I think it is clear = that there is a strong signal for the market, CPE vendors, etc., when somet= hing is standard vs informational. This is a key reason. I think we may take the opportunity to see if some of the considerations in= RFC8585 could be included in the RFC6877-bis. Those aren't new things, jus= t nobody put them in text before, and in fact are part of existing 464XLAT = implementations/deployments. I recall Jen mention one of them today, maybe = there are others. There is also text in RFC8683 which may be re-used in an RFC6877-bis, again= thinks that are there in deployments, but not written in RFC6877. Regarding the operational experience we have now, I was thinking to include= a section reporting it in the RFC6877-bis, but I'm fine if you think it sh= ould me a different document. I will be happy to participate on it, and I w= ould think that we should makes sure to have co-authors from other existing= deployments. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 16/7/20 19:08, "v6ops en nombre de Fred Baker" escribi=C3=B3: In today's Interim Meeting, Jordi pointed out that all transition mecha= nisms are at Proposed Standard except 464XLAT, and asked the working group = to advance it to that status. /* Personal Opinion */ I have no problem with doing so, but I would ask whether 464XLAT is ind= eed a transition mechanism. It is an operational procedure (and therefore w= ithin v6ops' charter to produce, which it did) that uses RFCs 6146, 6147, 7= 915, and possibly 6092, which are at Proposed Standard. /* Personal Opinion */ My huffing and puffing aside, I'd like to poll the opinion of the worki= ng group. - does RFC 6877 need to be updated? A good approach to doing so woul= d be to file errata (https://www.rfc-editor.org/errata.php). The document currently has no errata filed. Consider this an invit= ation to file any needed errata and tell v6ops you have done so. - failing that, we certainly have operational experience with it. It= is currently an informational document.=20 Would it be appropriate to raise it to Proposed Standard? - Per RFC 6410, we may be in a position to advance 6877, 6146, 6147,= and/or 7915 to Internet Standard. The criterion and process are described in https://tools.ietf.org/html/rfc6410, and boil down to= (1) multiple interoperable implementations and (2) a general belief that the technology works. From my perspective, i= f we believe that 464XLAT is widely deployed and useful, we believe that each of those are "characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community." Please reply all with your viewpoint. If the answer is "yes", fair warning: Ron and I are going to be looking= for someone to write an internet draft documenting the fact and the deploy= ment status. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jul 16 10:29:14 2020 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 022413A00B3 for ; Thu, 16 Jul 2020 10:29:13 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwPVBoYKCGdx for ; Thu, 16 Jul 2020 10:29:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 70E033A0867 for ; Thu, 16 Jul 2020 10:29:11 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 06GHT6gY623565 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jul 2020 10:29:06 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 06GHT6gY623565 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1594920546; bh=K3Oafv4i92TO3OoWlbav2QWYnDSs9BJnPHk5tkyw2x8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gOQrSlo4nAqp6WXIqutLOFRAiVfyJ6XdZLlc2iadnSKWZ5T0LzDlGmrgGYac1jMig mgJHJ/gomZzmupyGy0vvH5Dsx4pNw2cW7Ag6ZKFr/Q1KtWrRA02nscvDrQojY8MfOi WLNKFNvkdBezyZjmC9eAUOXd0Lot2voEfCLPOoOQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> Date: Thu, 16 Jul 2020 10:29:06 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Thu, 16 Jul 2020 10:29:06 -0700 (PDT) Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:29:13 -0000 I have no strong opinion one way or the other. I will say that if making it a proposed standard somehow helps people = get on with IPv6 deployment, I=E2=80=99m all for it. This transition has = taken far too long already. Owen > On Jul 16, 2020, at 10:07 , Fred Baker = wrote: >=20 > In today's Interim Meeting, Jordi pointed out that all transition = mechanisms are at Proposed Standard except 464XLAT, and asked the = working group to advance it to that status. >=20 > /* Personal Opinion */ > I have no problem with doing so, but I would ask whether 464XLAT is = indeed a transition mechanism. It is an operational procedure (and = therefore within v6ops' charter to produce, which it did) that uses RFCs = 6146, 6147, 7915, and possibly 6092, which are at Proposed Standard. > /* Personal Opinion */ >=20 > My huffing and puffing aside, I'd like to poll the opinion of the = working group. > - does RFC 6877 need to be updated? A good approach to doing so = would be to file errata (https://www.rfc-editor.org/errata.php). > The document currently has no errata filed. Consider this an = invitation to file any needed errata and tell v6ops you have done so. >=20 > - failing that, we certainly have operational experience with it. It = is currently an informational document.=20 > Would it be appropriate to raise it to Proposed Standard? >=20 > - Per RFC 6410, we may be in a position to advance 6877, 6146, 6147, = and/or 7915 to Internet Standard. The criterion and process are > described in https://tools.ietf.org/html/rfc6410, and boil down to = (1) multiple interoperable implementations and (2) > a general belief that the technology works. =46rom my perspective, = if we believe that 464XLAT is widely deployed and useful, > we believe that each of those are >=20 > "characterized by a high degree of > technical maturity and by a generally held belief that the > specified protocol or service provides significant benefit to the > Internet community." >=20 > Please reply all with your viewpoint. >=20 > If the answer is "yes", fair warning: Ron and I are going to be = looking for someone to write an internet draft documenting the fact and = the deployment status. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 16 17:08:11 2020 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 C537D3A0E45 for ; Thu, 16 Jul 2020 17:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2hImSVxUFHl for ; Thu, 16 Jul 2020 17:08:03 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2043A0E43 for ; Thu, 16 Jul 2020 17:08:03 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id b9so4637517plx.6 for ; Thu, 16 Jul 2020 17:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ey8/snYMmqjnhXLoIGn3tpVTIBKApPWsupzCa176W14=; b=HoWQ42AcPjvWKfDsoNU7vsvL4YdtBF6Hvkpe+MbsR5/kKL7cGd8ymO5BoYqFZ6F3lV G7l0ZYLulaWwrL6VP+PYWWnfgNTvY9qMCECqdC5Urkj8KOoiXiYbe0mwga/lvhqzbize iXqjWhIMbDmNGtHKSabSlj7VweOA9DgQDGjxw6Mm+oH0wzVwhpR9Fwlyg39C43eao9qL I2u+lxQJNfo8LxxntZgoulmQhqIhxpCMOv2wSqHlUyMDEZ8k7N9J7a/UxvCgDgQbYgS+ s7dBtD10+jR3AVVCAu1yubVQO677arzg1qMRvVy7OtkjdidYc7hqIEWvx/TGpCL6LXZ5 ucfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ey8/snYMmqjnhXLoIGn3tpVTIBKApPWsupzCa176W14=; b=ULP3pzS3KodZ++Ente7IoxsdC9Z9Tx566nDxFvDR0/aLJzTIjDG5WwaoM6r1higdM0 mQ8HBcs0K/9MwOPU7NGtB4Cr8kVrE1Wlqcn+xmcNfS8i5fWPjUnk0suPLEnm0oUhHqQw cWe18v9afIWnKufG6lNvyGSpOVnpDCTSXh/SZhXQ4iQH1WkL4GoI6QEt+e45dbA50+fh a9e2IH853eluEehrCs2+wYonNfIoBseOpVmLls0ArdReptUQNx9UKhM5wMFjes4y99M5 fM0Ra91QrTjklhdoBViAN1/mvCVCfk5EZ/3idWy4SgFn2Pko9gkg6J9o96rwImAgm0vk mf8g== X-Gm-Message-State: AOAM533DuUahoHEGqwoHZL+xepuF1p1/ToqDgIJloFTITExAzDKM43Cx /Hklky0KqJ6nJfmULQc+BsSk2yx/mQ8= X-Google-Smtp-Source: ABdhPJxgupfJ7O4R6pCuhXlkQWZQIVt0uCvQ/uIP+/pmAkT5INhYcpsne9SyLaSQ0ylUKC8TXU/uAQ== X-Received: by 2002:a17:90a:d912:: with SMTP id c18mr7213580pjv.184.1594944482619; Thu, 16 Jul 2020 17:08:02 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::14fa? ([2600:8802:5800:652::14fa]) by smtp.gmail.com with ESMTPSA id j2sm1152627pjy.1.2020.07.16.17.08.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2020 17:08:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Fred Baker In-Reply-To: <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es> Date: Thu, 16 Jul 2020 17:08:01 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com> References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 00:08:10 -0000 Well, may I suggest that you contact some appropriate people, whoever = they may be, and put together a design team to do the update? Some or = all of the original authors may be interested to participate. When you = post it, I'll be interested in the rfcdiff (which I might just generate = myself),the point being that this is not a rewrite but an update. > On Jul 16, 2020, at 10:23 AM, JORDI PALET MARTINEZ = wrote: >=20 > Hi Fred, all, >=20 > While I agree that 464XLAT is a procedure to put together other = protocols, it defines how to. This is actually the case for other = standard track documents. Sometimes this is in "the border line". = However, I think it is clear that there is a strong signal for the = market, CPE vendors, etc., when something is standard vs informational. = This is a key reason. >=20 > I think we may take the opportunity to see if some of the = considerations in RFC8585 could be included in the RFC6877-bis. Those = aren't new things, just nobody put them in text before, and in fact are = part of existing 464XLAT implementations/deployments. I recall Jen = mention one of them today, maybe there are others. >=20 > There is also text in RFC8683 which may be re-used in an RFC6877-bis, = again thinks that are there in deployments, but not written in RFC6877. >=20 > Regarding the operational experience we have now, I was thinking to = include a section reporting it in the RFC6877-bis, but I'm fine if you = think it should me a different document. I will be happy to participate = on it, and I would think that we should makes sure to have co-authors = from other existing deployments. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 16/7/20 19:08, "v6ops en nombre de Fred Baker" = = escribi=C3=B3: >=20 > In today's Interim Meeting, Jordi pointed out that all transition = mechanisms are at Proposed Standard except 464XLAT, and asked the = working group to advance it to that status. >=20 > /* Personal Opinion */ > I have no problem with doing so, but I would ask whether 464XLAT is = indeed a transition mechanism. It is an operational procedure (and = therefore within v6ops' charter to produce, which it did) that uses RFCs = 6146, 6147, 7915, and possibly 6092, which are at Proposed Standard. > /* Personal Opinion */ >=20 > My huffing and puffing aside, I'd like to poll the opinion of the = working group. > - does RFC 6877 need to be updated? A good approach to doing so = would be to file errata (https://www.rfc-editor.org/errata.php). > The document currently has no errata filed. Consider this an = invitation to file any needed errata and tell v6ops you have done so. >=20 > - failing that, we certainly have operational experience with = it. It is currently an informational document.=20 > Would it be appropriate to raise it to Proposed Standard? >=20 > - Per RFC 6410, we may be in a position to advance 6877, 6146, = 6147, and/or 7915 to Internet Standard. The criterion and process are > described in https://tools.ietf.org/html/rfc6410, and boil = down to (1) multiple interoperable implementations and (2) > a general belief that the technology works. =46rom my = perspective, if we believe that 464XLAT is widely deployed and useful, > we believe that each of those are >=20 > "characterized by a high degree of > technical maturity and by a generally held belief that the > specified protocol or service provides significant benefit to = the > Internet community." >=20 > Please reply all with your viewpoint. >=20 > If the answer is "yes", fair warning: Ron and I are going to be = looking for someone to write an internet draft documenting the fact and = the deployment status. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 From nobody Thu Jul 16 23:15:33 2020 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 91B673A12AA for ; Thu, 16 Jul 2020 23:15:32 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=necglobal.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cXF_343bAdS for ; Thu, 16 Jul 2020 23:15:31 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410083.outbound.protection.outlook.com [40.107.141.83]) (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 EED7E3A0D71 for ; Thu, 16 Jul 2020 23:15:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WGnq/UsnqPC+sOIRScUyzHEQgkxi3MfqV7/YmR7eMl6GKopdh4gQhsXUD0SaMWu7sBp3sYX/N+2hZD4K75q4Kh8ii2E9lvrl10OLpjm02fKKgX5qpGV1BmyV0p1cmGLLaJiF4i38LUAJS0n2tb2+PEuzi8nKpSlxT0IAf3dJDRvhbcJy8rQm1RjjgOoWTLiHRfav7PqGAkWwWHwxYEZsC0Vmpe3YPXXnGYHKJ5rXakLyHa4CNdi6viV/0XPqttZJPU3EFtuAlHcXEoRuQkXMmbEB7JzsOLYssr3SXmu6VTou39STRyesrC23Kg0tRuh8m8WK1RMekNJSqXXvewdjfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HqSm82ppCRw5sCKgj3OetD4rNznvjV4Fl+J7UFC6F40=; b=HGC57rnI/f1bAYVVZ60jCdCJtkE3MHH5cO80fU0Xa/Iy0G6O9M3nuVwiYV9/8CVi1uWKNUzgh0tKUrHr+xYi+rKRdNQKH7xPqc/sNuqe+6n6nb4KS+iBfcUpUkrPI/uw4sQH6khIKRgEzIfTh5U4+A8Ex6LpdWxxk5mjXDdCDqdxufObkAEEGOS5Gi0vAGb3tbes22GRQWjfpkAKg2wNGitSBBLOPCSOA5tsZiWDOOamZnN7bPO/pYm2AXgUc4b3GO9eZPNaRk3/ybkfkDf5DdJo3AorfXnbHD5b68XEQxp5PCex+rf02piyjt8G1qeZb43o7vcylfuDWzwIbT3VEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nec.com; dmarc=pass action=none header.from=nec.com; dkim=pass header.d=nec.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=necglobal.onmicrosoft.com; s=selector1-necglobal-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HqSm82ppCRw5sCKgj3OetD4rNznvjV4Fl+J7UFC6F40=; b=bQzVtMj925MYyKx40Z2tGJrQNYAU01pO8MbZB1m6NooCAfk71jTITgUUPo5mNzWgGoKGcD6E1PnXroi9Kn1Vs0udLUd1NLm3KMLHZoHQ7Re7Dgon/55SdEcLl3MJQaWkt8ouWTBTrPR4auIdrs7MwUWYOQw6v8kj2I4juBeZKBs= Received: from TY2PR01MB2057.jpnprd01.prod.outlook.com (2603:1096:404:d::23) by TYAPR01MB4959.jpnprd01.prod.outlook.com (2603:1096:404:124::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Fri, 17 Jul 2020 06:15:28 +0000 Received: from TY2PR01MB2057.jpnprd01.prod.outlook.com ([fe80::cc2:297d:cf95:e5dd]) by TY2PR01MB2057.jpnprd01.prod.outlook.com ([fe80::cc2:297d:cf95:e5dd%4]) with mapi id 15.20.3174.027; Fri, 17 Jul 2020 06:15:28 +0000 From: =?utf-8?B?S2F3YXNoaW1hIE1hc2Fub2J1KOW3neWztuOAgOato+S8uCk=?= To: 'Fred Baker' , JORDI PALET MARTINEZ CC: IPv6 Operations Thread-Topic: [v6ops] RFC 6877 to Proposed Standard Thread-Index: AQHWW5OuI6reCcCZNk+EHQVaC4alkakKdGyAgABxF4CAAGLbsA== Date: Fri, 17 Jul 2020 06:13:34 +0000 Deferred-Delivery: Fri, 17 Jul 2020 06:15:00 +0000 Message-ID: References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es> <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com> In-Reply-To: <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nec.com; x-originating-ip: [165.225.110.176] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 580b865c-617c-4b94-97e2-08d82a18cd68 x-ms-traffictypediagnostic: TYAPR01MB4959: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nbeiZkVtTwZdlL2JmMf3uFnToXIKPLCgJEbHXGqG++ly3J5WNhzNXgAeRS4cKw8pK1IeG5b39/HXiRyfineGsef8mkF9m3R2FeLKmjQb9hrFtYFV8y6uazjKZLwMpKtN55LdT+yKtebYwQzwxM0E0UCIwE/o5u1PcFJ1ozWx4mvqG7xRxcjrZhqGHuojSvfwqYJsmT1VDD8V4VXXEn7rtDBDZ6vSsO8zdoL4wKZuKeNZY4mWseIfAGaaGFEEk4hytpT7lg7Qkdm8O/iLwbfWz+WMLljaoeA/eEe7pxRRJXq3I+LaD9DGBTxM9T8EnepXJSEdiTmKwUO8tSe0wVOBAVeIQJIrpHszci1ZCmy6ce0iteXp+2rki14qQrGbhUvMnfx8Yudn0fdKYk/dJDfpnmzElc1wUWwyHRMGF3Lm1NoducCAoMWbfBt266b+s2XnswLkVj96ZV+SMofWFHwCtw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB2057.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(346002)(366004)(396003)(16799955002)(5660300002)(8676002)(52536014)(83380400001)(110136005)(33656002)(4326008)(2906002)(71200400001)(86362001)(6666004)(66574015)(76116006)(186003)(9686003)(316002)(966005)(26005)(8936002)(478600001)(7696005)(85182001)(55236004)(53546011)(6506007)(66446008)(66556008)(64756008)(66476007)(55016002)(66946007)(443494004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1/kWe7h5IfHgJo7afwPxFDeamF46m/Z4Slf0rdtxo6QizFV9+i2ncy2oOTL+8u1Km5p8vA5yYUJWorYkQ3eMJEuKMqxLcuMxxAg+sDJ51PCV/iC3i+Ujr/jB5HmxHL/SZGvpRXcF+igUbhst+ObzMjE5CeTDj2E4Ixz+oqs+A3Zm+C99BD0iP2XhBgidCTRCLubTVmf3dLzMZ+IMpZU/29+HCb8fdjHq0aZREt199ZItm4ly62sV83z/0+sIA2qEH2MLq6t70PlSKw96C7BRCy46EpKFiXryjWl8L36YwKNXjjXj0sD6WLdiZSEYEhWnJsV0obwe4tPHn0e3OYd1gT32cuwwFGxTPF3XtuTGCu9mXFCiBnZuJ6442GYTwM7W9I8899tYKBOc+2S4nUtRHzxRrvVnVV8N0o7ZHWAdr+2BKpkrj+RZOE2HRcz5PgJymRb5PwJh7tuKudwalbwkFkZLhqr3nKioRUSK5N0NulO2cCUFp1Jb+dgFy4lXlzhM x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nec.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TY2PR01MB2057.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 580b865c-617c-4b94-97e2-08d82a18cd68 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 06:15:28.5901 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e67df547-9d0d-4f4d-9161-51c6ed1f7d11 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dXAhHTd95grBGc5Vly88R6kkY9MrrUeFdqkPmB+PN9pVTnJUi2fNE+g2B25KCjoFP4qe3+2sjDq7tYElh7CZAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4959 Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 06:15:33 -0000 DQpIaSBGcmVkLCBKb3JkaSwgYWxsLCANCg0KSSdtIGludGVyZXN0ZWQgdG8gcGFydGljaXBhdGUg dGhpcy4gSSdtIGFsbCBmb3IgdGhpcy4gDQpQbGVhc2UgbGV0IG1lIGpvaW4gdGhpcyBmcm9tIHRo ZSB2aWV3cG9pbnQgb2YgNDY0WExBVCBjby1hdXRob3IgYW5kIENFIHZlbmRvciBhcyB3ZWxsLiAN Cg0KUmVnYXJkcywgDQpNYXNhbm9idSANCg0KPT09PT09PT09PT09PT09PT09PT09DQogTkVDIFBs YXRmb3JtcywgTHRkLiANCiBLQVdBU0hJTUEgTWFzYW5vYnUgIA0KPT09PT09PT09PT09PT09PT09 PT09DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyA8djZv cHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEZyZWQgQmFrZXINCj4gU2VudDogRnJp ZGF5LCBKdWx5IDE3LCAyMDIwIDk6MDggQU0NCj4gVG86IEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxq b3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NCj4gQ2M6IElQdjYgT3BlcmF0aW9ucyA8djZvcHNA aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFJGQyA2ODc3IHRvIFByb3Bvc2VkIFN0 YW5kYXJkDQo+IA0KPiBXZWxsLCBtYXkgSSBzdWdnZXN0IHRoYXQgeW91IGNvbnRhY3Qgc29tZSBh cHByb3ByaWF0ZSBwZW9wbGUsIHdob2V2ZXIgdGhleSBtYXkgYmUsIGFuZCBwdXQgdG9nZXRoZXIg YSBkZXNpZ24gdGVhbQ0KPiB0byBkbyB0aGUgdXBkYXRlPyBTb21lIG9yIGFsbCBvZiB0aGUgb3Jp Z2luYWwgYXV0aG9ycyBtYXkgYmUgaW50ZXJlc3RlZCB0byBwYXJ0aWNpcGF0ZS4gV2hlbiB5b3Ug cG9zdCBpdCwgSSdsbA0KPiBiZSBpbnRlcmVzdGVkIGluIHRoZSByZmNkaWZmICh3aGljaCBJIG1p Z2h0IGp1c3QgZ2VuZXJhdGUgbXlzZWxmKSx0aGUgcG9pbnQgYmVpbmcgdGhhdCB0aGlzIGlzIG5v dCBhIHJld3JpdGUgYnV0DQo+IGFuIHVwZGF0ZS4NCj4gDQo+ID4gT24gSnVsIDE2LCAyMDIwLCBh dCAxMDoyMyBBTSwgSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVs LmVzPiB3cm90ZToNCj4gPg0KPiA+IEhpIEZyZWQsIGFsbCwNCj4gPg0KPiA+IFdoaWxlIEkgYWdy ZWUgdGhhdCA0NjRYTEFUIGlzIGEgcHJvY2VkdXJlIHRvIHB1dCB0b2dldGhlciBvdGhlciBwcm90 b2NvbHMsIGl0IGRlZmluZXMgaG93IHRvLiBUaGlzIGlzIGFjdHVhbGx5DQo+IHRoZSBjYXNlIGZv ciBvdGhlciBzdGFuZGFyZCB0cmFjayBkb2N1bWVudHMuIFNvbWV0aW1lcyB0aGlzIGlzIGluICJ0 aGUgYm9yZGVyIGxpbmUiLiBIb3dldmVyLCBJIHRoaW5rIGl0IGlzIGNsZWFyDQo+IHRoYXQgdGhl cmUgaXMgYSBzdHJvbmcgc2lnbmFsIGZvciB0aGUgbWFya2V0LCBDUEUgdmVuZG9ycywgZXRjLiwg d2hlbiBzb21ldGhpbmcgaXMgc3RhbmRhcmQgdnMgaW5mb3JtYXRpb25hbC4gVGhpcw0KPiBpcyBh IGtleSByZWFzb24uDQo+ID4NCj4gPiBJIHRoaW5rIHdlIG1heSB0YWtlIHRoZSBvcHBvcnR1bml0 eSB0byBzZWUgaWYgc29tZSBvZiB0aGUgY29uc2lkZXJhdGlvbnMgaW4gUkZDODU4NSBjb3VsZCBi ZSBpbmNsdWRlZCBpbiB0aGUNCj4gUkZDNjg3Ny1iaXMuIFRob3NlIGFyZW4ndCBuZXcgdGhpbmdz LCBqdXN0IG5vYm9keSBwdXQgdGhlbSBpbiB0ZXh0IGJlZm9yZSwgYW5kIGluIGZhY3QgYXJlIHBh cnQgb2YgZXhpc3RpbmcgNDY0WExBVA0KPiBpbXBsZW1lbnRhdGlvbnMvZGVwbG95bWVudHMuIEkg cmVjYWxsIEplbiBtZW50aW9uIG9uZSBvZiB0aGVtIHRvZGF5LCBtYXliZSB0aGVyZSBhcmUgb3Ro ZXJzLg0KPiA+DQo+ID4gVGhlcmUgaXMgYWxzbyB0ZXh0IGluIFJGQzg2ODMgd2hpY2ggbWF5IGJl IHJlLXVzZWQgaW4gYW4gUkZDNjg3Ny1iaXMsIGFnYWluIHRoaW5rcyB0aGF0IGFyZSB0aGVyZSBp biBkZXBsb3ltZW50cywNCj4gYnV0IG5vdCB3cml0dGVuIGluIFJGQzY4NzcuDQo+ID4NCj4gPiBS ZWdhcmRpbmcgdGhlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Ugd2UgaGF2ZSBub3csIEkgd2FzIHRo aW5raW5nIHRvIGluY2x1ZGUgYSBzZWN0aW9uIHJlcG9ydGluZyBpdCBpbiB0aGUgUkZDNjg3Ny1i aXMsDQo+IGJ1dCBJJ20gZmluZSBpZiB5b3UgdGhpbmsgaXQgc2hvdWxkIG1lIGEgZGlmZmVyZW50 IGRvY3VtZW50LiBJIHdpbGwgYmUgaGFwcHkgdG8gcGFydGljaXBhdGUgb24gaXQsIGFuZCBJIHdv dWxkDQo+IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIG1ha2VzIHN1cmUgdG8gaGF2ZSBjby1hdXRob3Jz IGZyb20gb3RoZXIgZXhpc3RpbmcgZGVwbG95bWVudHMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+ IEpvcmRpDQo+ID4gQGpvcmRpcGFsZXQNCj4gPg0KPiA+DQo+ID4NCj4gPiDvu79FbCAxNi83LzIw IDE5OjA4LCAidjZvcHMgZW4gbm9tYnJlIGRlIEZyZWQgQmFrZXIiIDx2Nm9wcy1ib3VuY2VzQGll dGYub3JnIGVuIG5vbWJyZSBkZSBmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+DQo+IGVzY3JpYmnD szoNCj4gPg0KPiA+ICAgIEluIHRvZGF5J3MgSW50ZXJpbSBNZWV0aW5nLCBKb3JkaSBwb2ludGVk IG91dCB0aGF0IGFsbCB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgYXJlIGF0IFByb3Bvc2VkIFN0YW5k YXJkIGV4Y2VwdA0KPiA0NjRYTEFULCBhbmQgYXNrZWQgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWR2 YW5jZSBpdCB0byB0aGF0IHN0YXR1cy4NCj4gPg0KPiA+ICAgIC8qIFBlcnNvbmFsIE9waW5pb24g Ki8NCj4gPiAgICBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIGRvaW5nIHNvLCBidXQgSSB3b3VsZCBh c2sgd2hldGhlciA0NjRYTEFUIGlzIGluZGVlZCBhIHRyYW5zaXRpb24gbWVjaGFuaXNtLiBJdCBp cyBhbg0KPiBvcGVyYXRpb25hbCBwcm9jZWR1cmUgKGFuZCB0aGVyZWZvcmUgd2l0aGluIHY2b3Bz JyBjaGFydGVyIHRvIHByb2R1Y2UsIHdoaWNoIGl0IGRpZCkgdGhhdCB1c2VzIFJGQ3MgNjE0Niwg NjE0NywNCj4gNzkxNSwgYW5kIHBvc3NpYmx5IDYwOTIsIHdoaWNoIGFyZSBhdCBQcm9wb3NlZCBT dGFuZGFyZC4NCj4gPiAgICAvKiBQZXJzb25hbCBPcGluaW9uICovDQo+ID4NCj4gPiAgICBNeSBo dWZmaW5nIGFuZCBwdWZmaW5nIGFzaWRlLCBJJ2QgbGlrZSB0byBwb2xsIHRoZSBvcGluaW9uIG9m IHRoZSB3b3JraW5nIGdyb3VwLg0KPiA+ICAgICAgIC0gZG9lcyBSRkMgNjg3NyBuZWVkIHRvIGJl IHVwZGF0ZWQ/IEEgZ29vZCBhcHByb2FjaCB0byBkb2luZyBzbyB3b3VsZCBiZSB0byBmaWxlIGVy cmF0YQ0KPiAoaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhLnBocCkuDQo+ID4gICAg ICAgICBUaGUgZG9jdW1lbnQgY3VycmVudGx5IGhhcyBubyBlcnJhdGEgZmlsZWQuIENvbnNpZGVy IHRoaXMgYW4gaW52aXRhdGlvbiB0byBmaWxlIGFueSBuZWVkZWQgZXJyYXRhIGFuZA0KPiB0ZWxs IHY2b3BzIHlvdSBoYXZlIGRvbmUgc28uDQo+ID4NCj4gPiAgICAgICAtIGZhaWxpbmcgdGhhdCwg d2UgY2VydGFpbmx5IGhhdmUgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRoIGl0LiBJdCBpcyBj dXJyZW50bHkgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC4NCj4gPiAgICAgICAgIFdvdWxkIGl0 IGJlIGFwcHJvcHJpYXRlIHRvIHJhaXNlIGl0IHRvIFByb3Bvc2VkIFN0YW5kYXJkPw0KPiA+DQo+ ID4gICAgICAgLSBQZXIgUkZDIDY0MTAsIHdlIG1heSBiZSBpbiBhIHBvc2l0aW9uIHRvIGFkdmFu Y2UgNjg3NywgNjE0NiwgNjE0NywgYW5kL29yIDc5MTUgdG8gSW50ZXJuZXQgU3RhbmRhcmQuDQo+ IFRoZSBjcml0ZXJpb24gYW5kIHByb2Nlc3MgYXJlDQo+ID4gICAgICAgICBkZXNjcmliZWQgaW4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY0MTAsIGFuZCBib2lsIGRvd24gdG8gKDEp IG11bHRpcGxlIGludGVyb3BlcmFibGUNCj4gaW1wbGVtZW50YXRpb25zIGFuZCAoMikNCj4gPiAg ICAgICAgIGEgZ2VuZXJhbCBiZWxpZWYgdGhhdCB0aGUgdGVjaG5vbG9neSB3b3Jrcy4gRnJvbSBt eSBwZXJzcGVjdGl2ZSwgaWYgd2UgYmVsaWV2ZSB0aGF0IDQ2NFhMQVQgaXMgd2lkZWx5DQo+IGRl cGxveWVkIGFuZCB1c2VmdWwsDQo+ID4gICAgICAgICB3ZSBiZWxpZXZlIHRoYXQgZWFjaCBvZiB0 aG9zZSBhcmUNCj4gPg0KPiA+ICAgICAgICAgICJjaGFyYWN0ZXJpemVkIGJ5IGEgaGlnaCBkZWdy ZWUgb2YNCj4gPiAgICAgICAgICB0ZWNobmljYWwgbWF0dXJpdHkgYW5kIGJ5IGEgZ2VuZXJhbGx5 IGhlbGQgYmVsaWVmIHRoYXQgdGhlDQo+ID4gICAgICAgICAgc3BlY2lmaWVkIHByb3RvY29sIG9y IHNlcnZpY2UgcHJvdmlkZXMgc2lnbmlmaWNhbnQgYmVuZWZpdCB0byB0aGUNCj4gPiAgICAgICAg ICBJbnRlcm5ldCBjb21tdW5pdHkuIg0KPiA+DQo+ID4gICAgUGxlYXNlIHJlcGx5IGFsbCB3aXRo IHlvdXIgdmlld3BvaW50Lg0KPiA+DQo+ID4gICAgSWYgdGhlIGFuc3dlciBpcyAieWVzIiwgZmFp ciB3YXJuaW5nOiBSb24gYW5kIEkgYXJlIGdvaW5nIHRvIGJlIGxvb2tpbmcgZm9yIHNvbWVvbmUg dG8gd3JpdGUgYW4gaW50ZXJuZXQgZHJhZnQNCj4gZG9jdW1lbnRpbmcgdGhlIGZhY3QgYW5kIHRo ZSBkZXBsb3ltZW50IHN0YXR1cy4NCj4gPiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+ICAgIHY2 b3BzQGlldGYub3JnDQo+ID4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KPiA+DQo+ID4NCj4gPg0KPiA+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCj4gPiBJUHY0IGlzIG92ZXINCj4gPiBBcmUgeW91IHJlYWR5IGZv ciB0aGUgbmV3IEludGVybmV0ID8NCj4gPiBodHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0K PiA+IFRoZSBJUHY2IENvbXBhbnkNCj4gPg0KPiA+IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNv bnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlh bC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkDQo+IHRvIGJlIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhw bGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsDQo+IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBv ciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlh bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsDQo+IGlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUNCj4gdGhhdCBhbnkgZGlzY2xvc3VyZSwg Y29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZw0KPiBhdHRhY2hlZCBmaWxlcywg aXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2Zm ZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsDQo+IHNlbmRlciB0byBpbmZv cm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQo+ID4NCj4gPg0KPiA+ DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu Jul 16 23:19:24 2020 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 97D593A12C7 for ; Thu, 16 Jul 2020 23:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8Zyswh7SHjG for ; Thu, 16 Jul 2020 23:19:19 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id EAE603A12C5 for ; Thu, 16 Jul 2020 23:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594966757; x=1595571557; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=HEiVTtw5dDaJopn1uzwLomcFovWMEKdHWyPWIjV2wN0=; b=gnFfc3YtHD53w qlo5OAP+HOprxb+hiOo5NHgl9sIEjZbePsA71XQGdUpBUQjvBIn9gKVPdG6I1UAH biD15N2sGf9sGxT/qc9ErT1FCtx8XCAU8FuF+Nv4Ik5ljSbnASGBhpjwzHrYGH5L SYcHZoe5nWYGDxQQWpgKphsAd+RPuA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 08:19:17 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 08:19:16 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000290580.msg for ; Fri, 17 Jul 2020 08:19:15 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 08:19:15 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 08:19:12 +0200 From: JORDI PALET MARTINEZ To: Fred Baker CC: IPv6 Operations Message-ID: <80F07ECE-B36F-40F4-BD00-220D56E8DE66@consulintel.es> Thread-Topic: [v6ops] RFC 6877 to Proposed Standard References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es> <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com> In-Reply-To: <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 06:19:22 -0000 Hi Fred, Actually, before your message to the list on this, I'd already sent a messa= ge to the original authors of RFC6877, so just waiting for them to respond. We can look also into other folks that have already deployed 464XLAT in oth= er networks. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 17/7/20 2:08, "Fred Baker" escribi= =C3=B3: Well, may I suggest that you contact some appropriate people, whoever t= hey may be, and put together a design team to do the update? Some or all of= the original authors may be interested to participate. When you post it, I= 'll be interested in the rfcdiff (which I might just generate myself),the p= oint being that this is not a rewrite but an update. > On Jul 16, 2020, at 10:23 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Fred, all, >=20 > While I agree that 464XLAT is a procedure to put together other proto= cols, it defines how to. This is actually the case for other standard track= documents. Sometimes this is in "the border line". However, I think it is = clear that there is a strong signal for the market, CPE vendors, etc., when= something is standard vs informational. This is a key reason. >=20 > I think we may take the opportunity to see if some of the considerati= ons in RFC8585 could be included in the RFC6877-bis. Those aren't new thing= s, just nobody put them in text before, and in fact are part of existing 46= 4XLAT implementations/deployments. I recall Jen mention one of them today, = maybe there are others. >=20 > There is also text in RFC8683 which may be re-used in an RFC6877-bis,= again thinks that are there in deployments, but not written in RFC6877. >=20 > Regarding the operational experience we have now, I was thinking to i= nclude a section reporting it in the RFC6877-bis, but I'm fine if you think= it should me a different document. I will be happy to participate on it, a= nd I would think that we should makes sure to have co-authors from other ex= isting deployments. >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 > =EF=BB=BFEl 16/7/20 19:08, "v6ops en nombre de Fred Baker" escribi=C3=B3: >=20 > In today's Interim Meeting, Jordi pointed out that all transition = mechanisms are at Proposed Standard except 464XLAT, and asked the working g= roup to advance it to that status. >=20 > /* Personal Opinion */ > I have no problem with doing so, but I would ask whether 464XLAT i= s indeed a transition mechanism. It is an operational procedure (and theref= ore within v6ops' charter to produce, which it did) that uses RFCs 6146, 61= 47, 7915, and possibly 6092, which are at Proposed Standard. > /* Personal Opinion */ >=20 > My huffing and puffing aside, I'd like to poll the opinion of the = working group. > - does RFC 6877 need to be updated? A good approach to doing so= would be to file errata (https://www.rfc-editor.org/errata.php). > The document currently has no errata filed. Consider this an = invitation to file any needed errata and tell v6ops you have done so. >=20 > - failing that, we certainly have operational experience with i= t. It is currently an informational document.=20 > Would it be appropriate to raise it to Proposed Standard? >=20 > - Per RFC 6410, we may be in a position to advance 6877, 6146, = 6147, and/or 7915 to Internet Standard. The criterion and process are > described in https://tools.ietf.org/html/rfc6410, and boil do= wn to (1) multiple interoperable implementations and (2) > a general belief that the technology works. From my perspecti= ve, if we believe that 464XLAT is widely deployed and useful, > we believe that each of those are >=20 > "characterized by a high degree of > technical maturity and by a generally held belief that the > specified protocol or service provides significant benefit t= o the > Internet community." >=20 > Please reply all with your viewpoint. >=20 > If the answer is "yes", fair warning: Ron and I are going to be lo= oking for someone to write an internet draft documenting the fact and the d= eployment status. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jul 16 23:36:35 2020 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 CCB003A10C0 for ; Thu, 16 Jul 2020 23:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZwjfmEluepA for ; Thu, 16 Jul 2020 23:36:32 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7F71D3A0FE5 for ; Thu, 16 Jul 2020 23:36:31 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:49823.511996811 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.75?logid-77dda039f67b44b4bdd24565c352ae3b (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 2D09A2800CF; Fri, 17 Jul 2020 14:36:13 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 77dda039f67b44b4bdd24565c352ae3b for jordi.palet=40consulintel.es@dmarc.ietf.org; Fri Jul 17 14:36:16 2020 X-Transaction-ID: 77dda039f67b44b4bdd24565c352ae3b X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: xiechf@chinatelecom.cn Date: Fri, 17 Jul 2020 14:36:12 +0800 From: "xiechf@chinatelecom.cn" To: "JORDI PALET MARTINEZ" , fredbaker.ietf Cc: v6ops References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com>, <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es>, <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com>, <80F07ECE-B36F-40F4-BD00-220D56E8DE66@consulintel.es> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <2020071714361215140011@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart821331147662_=----" Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 06:36:34 -0000 This is a multi-part message in MIME format. ------=_001_NextPart821331147662_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGnvvIxKb3JkaSBhbmQgRnJlZO+8jA0KSSBhbSBpbnRlcmVzdGVkIGluIHRoaXMgd29yayBhbmQg SSdkIGxpa2UgdG8gam9pbiB0aGUgZGVzaWduIHRlYW0uDQpCZXN0IHJlZ2FyZHMNCkNob25nZmVu Zw0KDQoNCkZyb206IEpPUkRJIFBBTEVUIE1BUlRJTkVaDQpEYXRlOiAyMDIwLTA3LTE3IDE0OjE5 DQpUbzogRnJlZCBCYWtlcg0KQ0M6IElQdjYgT3BlcmF0aW9ucw0KU3ViamVjdDogUmU6IFt2Nm9w c10gUkZDIDY4NzcgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCkhpIEZyZWQsDQogDQpBY3R1YWxseSwg YmVmb3JlIHlvdXIgbWVzc2FnZSB0byB0aGUgbGlzdCBvbiB0aGlzLCBJJ2QgYWxyZWFkeSBzZW50 IGEgbWVzc2FnZSB0byB0aGUgb3JpZ2luYWwgYXV0aG9ycyBvZiBSRkM2ODc3LCBzbyBqdXN0IHdh aXRpbmcgZm9yIHRoZW0gdG8gcmVzcG9uZC4NCiANCldlIGNhbiBsb29rIGFsc28gaW50byBvdGhl ciBmb2xrcyB0aGF0IGhhdmUgYWxyZWFkeSBkZXBsb3llZCA0NjRYTEFUIGluIG90aGVyIG5ldHdv cmtzLg0KIA0KUmVnYXJkcywNCkpvcmRpDQpAam9yZGlwYWxldA0KIA0K77u/RWwgMTcvNy8yMCAy OjA4LCAiRnJlZCBCYWtlciIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbT4gZXNjcmliacOzOg0K IA0KICAgIFdlbGwsIG1heSBJIHN1Z2dlc3QgdGhhdCB5b3UgY29udGFjdCBzb21lIGFwcHJvcHJp YXRlIHBlb3BsZSwgd2hvZXZlciB0aGV5IG1heSBiZSwgYW5kIHB1dCB0b2dldGhlciBhIGRlc2ln biB0ZWFtIHRvIGRvIHRoZSB1cGRhdGU/IFNvbWUgb3IgYWxsIG9mIHRoZSBvcmlnaW5hbCBhdXRo b3JzIG1heSBiZSBpbnRlcmVzdGVkIHRvIHBhcnRpY2lwYXRlLiBXaGVuIHlvdSBwb3N0IGl0LCBJ J2xsIGJlIGludGVyZXN0ZWQgaW4gdGhlIHJmY2RpZmYgKHdoaWNoIEkgbWlnaHQganVzdCBnZW5l cmF0ZSBteXNlbGYpLHRoZSBwb2ludCBiZWluZyB0aGF0IHRoaXMgaXMgbm90IGEgcmV3cml0ZSBi dXQgYW4gdXBkYXRlLg0KIA0KICAgID4gT24gSnVsIDE2LCAyMDIwLCBhdCAxMDoyMyBBTSwgSk9S REkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPiB3cm90ZToNCiAg ICA+IA0KICAgID4gSGkgRnJlZCwgYWxsLA0KICAgID4gDQogICAgPiBXaGlsZSBJIGFncmVlIHRo YXQgNDY0WExBVCBpcyBhIHByb2NlZHVyZSB0byBwdXQgdG9nZXRoZXIgb3RoZXIgcHJvdG9jb2xz LCBpdCBkZWZpbmVzIGhvdyB0by4gVGhpcyBpcyBhY3R1YWxseSB0aGUgY2FzZSBmb3Igb3RoZXIg c3RhbmRhcmQgdHJhY2sgZG9jdW1lbnRzLiBTb21ldGltZXMgdGhpcyBpcyBpbiAidGhlIGJvcmRl ciBsaW5lIi4gSG93ZXZlciwgSSB0aGluayBpdCBpcyBjbGVhciB0aGF0IHRoZXJlIGlzIGEgc3Ry b25nIHNpZ25hbCBmb3IgdGhlIG1hcmtldCwgQ1BFIHZlbmRvcnMsIGV0Yy4sIHdoZW4gc29tZXRo aW5nIGlzIHN0YW5kYXJkIHZzIGluZm9ybWF0aW9uYWwuIFRoaXMgaXMgYSBrZXkgcmVhc29uLg0K ICAgID4gDQogICAgPiBJIHRoaW5rIHdlIG1heSB0YWtlIHRoZSBvcHBvcnR1bml0eSB0byBzZWUg aWYgc29tZSBvZiB0aGUgY29uc2lkZXJhdGlvbnMgaW4gUkZDODU4NSBjb3VsZCBiZSBpbmNsdWRl ZCBpbiB0aGUgUkZDNjg3Ny1iaXMuIFRob3NlIGFyZW4ndCBuZXcgdGhpbmdzLCBqdXN0IG5vYm9k eSBwdXQgdGhlbSBpbiB0ZXh0IGJlZm9yZSwgYW5kIGluIGZhY3QgYXJlIHBhcnQgb2YgZXhpc3Rp bmcgNDY0WExBVCBpbXBsZW1lbnRhdGlvbnMvZGVwbG95bWVudHMuIEkgcmVjYWxsIEplbiBtZW50 aW9uIG9uZSBvZiB0aGVtIHRvZGF5LCBtYXliZSB0aGVyZSBhcmUgb3RoZXJzLg0KICAgID4gDQog ICAgPiBUaGVyZSBpcyBhbHNvIHRleHQgaW4gUkZDODY4MyB3aGljaCBtYXkgYmUgcmUtdXNlZCBp biBhbiBSRkM2ODc3LWJpcywgYWdhaW4gdGhpbmtzIHRoYXQgYXJlIHRoZXJlIGluIGRlcGxveW1l bnRzLCBidXQgbm90IHdyaXR0ZW4gaW4gUkZDNjg3Ny4NCiAgICA+IA0KICAgID4gUmVnYXJkaW5n IHRoZSBvcGVyYXRpb25hbCBleHBlcmllbmNlIHdlIGhhdmUgbm93LCBJIHdhcyB0aGlua2luZyB0 byBpbmNsdWRlIGEgc2VjdGlvbiByZXBvcnRpbmcgaXQgaW4gdGhlIFJGQzY4NzctYmlzLCBidXQg SSdtIGZpbmUgaWYgeW91IHRoaW5rIGl0IHNob3VsZCBtZSBhIGRpZmZlcmVudCBkb2N1bWVudC4g SSB3aWxsIGJlIGhhcHB5IHRvIHBhcnRpY2lwYXRlIG9uIGl0LCBhbmQgSSB3b3VsZCB0aGluayB0 aGF0IHdlIHNob3VsZCBtYWtlcyBzdXJlIHRvIGhhdmUgY28tYXV0aG9ycyBmcm9tIG90aGVyIGV4 aXN0aW5nIGRlcGxveW1lbnRzLg0KICAgID4gDQogICAgPiBSZWdhcmRzLA0KICAgID4gSm9yZGkN CiAgICA+IEBqb3JkaXBhbGV0DQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiDvu79FbCAx Ni83LzIwIDE5OjA4LCAidjZvcHMgZW4gbm9tYnJlIGRlIEZyZWQgQmFrZXIiIDx2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnIGVuIG5vbWJyZSBkZSBmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+IGVzY3Jp YmnDszoNCiAgICA+IA0KICAgID4gICAgSW4gdG9kYXkncyBJbnRlcmltIE1lZXRpbmcsIEpvcmRp IHBvaW50ZWQgb3V0IHRoYXQgYWxsIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBhcmUgYXQgUHJvcG9z ZWQgU3RhbmRhcmQgZXhjZXB0IDQ2NFhMQVQsIGFuZCBhc2tlZCB0aGUgd29ya2luZyBncm91cCB0 byBhZHZhbmNlIGl0IHRvIHRoYXQgc3RhdHVzLg0KICAgID4gDQogICAgPiAgICAvKiBQZXJzb25h bCBPcGluaW9uICovDQogICAgPiAgICBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIGRvaW5nIHNvLCBi dXQgSSB3b3VsZCBhc2sgd2hldGhlciA0NjRYTEFUIGlzIGluZGVlZCBhIHRyYW5zaXRpb24gbWVj aGFuaXNtLiBJdCBpcyBhbiBvcGVyYXRpb25hbCBwcm9jZWR1cmUgKGFuZCB0aGVyZWZvcmUgd2l0 aGluIHY2b3BzJyBjaGFydGVyIHRvIHByb2R1Y2UsIHdoaWNoIGl0IGRpZCkgdGhhdCB1c2VzIFJG Q3MgNjE0NiwgNjE0NywgNzkxNSwgYW5kIHBvc3NpYmx5IDYwOTIsIHdoaWNoIGFyZSBhdCBQcm9w b3NlZCBTdGFuZGFyZC4NCiAgICA+ICAgIC8qIFBlcnNvbmFsIE9waW5pb24gKi8NCiAgICA+IA0K ICAgID4gICAgTXkgaHVmZmluZyBhbmQgcHVmZmluZyBhc2lkZSwgSSdkIGxpa2UgdG8gcG9sbCB0 aGUgb3BpbmlvbiBvZiB0aGUgd29ya2luZyBncm91cC4NCiAgICA+ICAgICAgIC0gZG9lcyBSRkMg Njg3NyBuZWVkIHRvIGJlIHVwZGF0ZWQ/IEEgZ29vZCBhcHByb2FjaCB0byBkb2luZyBzbyB3b3Vs ZCBiZSB0byBmaWxlIGVycmF0YSAoaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhLnBo cCkuDQogICAgPiAgICAgICAgIFRoZSBkb2N1bWVudCBjdXJyZW50bHkgaGFzIG5vIGVycmF0YSBm aWxlZC4gQ29uc2lkZXIgdGhpcyBhbiBpbnZpdGF0aW9uIHRvIGZpbGUgYW55IG5lZWRlZCBlcnJh dGEgYW5kIHRlbGwgdjZvcHMgeW91IGhhdmUgZG9uZSBzby4NCiAgICA+IA0KICAgID4gICAgICAg LSBmYWlsaW5nIHRoYXQsIHdlIGNlcnRhaW5seSBoYXZlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2Ug d2l0aCBpdC4gSXQgaXMgY3VycmVudGx5IGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuIA0KICAg ID4gICAgICAgICBXb3VsZCBpdCBiZSBhcHByb3ByaWF0ZSB0byByYWlzZSBpdCB0byBQcm9wb3Nl ZCBTdGFuZGFyZD8NCiAgICA+IA0KICAgID4gICAgICAgLSBQZXIgUkZDIDY0MTAsIHdlIG1heSBi ZSBpbiBhIHBvc2l0aW9uIHRvIGFkdmFuY2UgNjg3NywgNjE0NiwgNjE0NywgYW5kL29yIDc5MTUg dG8gSW50ZXJuZXQgU3RhbmRhcmQuIFRoZSBjcml0ZXJpb24gYW5kIHByb2Nlc3MgYXJlDQogICAg PiAgICAgICAgIGRlc2NyaWJlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQx MCwgYW5kIGJvaWwgZG93biB0byAoMSkgbXVsdGlwbGUgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRh dGlvbnMgYW5kICgyKQ0KICAgID4gICAgICAgICBhIGdlbmVyYWwgYmVsaWVmIHRoYXQgdGhlIHRl Y2hub2xvZ3kgd29ya3MuIEZyb20gbXkgcGVyc3BlY3RpdmUsIGlmIHdlIGJlbGlldmUgdGhhdCA0 NjRYTEFUIGlzIHdpZGVseSBkZXBsb3llZCBhbmQgdXNlZnVsLA0KICAgID4gICAgICAgICB3ZSBi ZWxpZXZlIHRoYXQgZWFjaCBvZiB0aG9zZSBhcmUNCiAgICA+IA0KICAgID4gICAgICAgICAgImNo YXJhY3Rlcml6ZWQgYnkgYSBoaWdoIGRlZ3JlZSBvZg0KICAgID4gICAgICAgICAgdGVjaG5pY2Fs IG1hdHVyaXR5IGFuZCBieSBhIGdlbmVyYWxseSBoZWxkIGJlbGllZiB0aGF0IHRoZQ0KICAgID4g ICAgICAgICAgc3BlY2lmaWVkIHByb3RvY29sIG9yIHNlcnZpY2UgcHJvdmlkZXMgc2lnbmlmaWNh bnQgYmVuZWZpdCB0byB0aGUNCiAgICA+ICAgICAgICAgIEludGVybmV0IGNvbW11bml0eS4iDQog ICAgPiANCiAgICA+ICAgIFBsZWFzZSByZXBseSBhbGwgd2l0aCB5b3VyIHZpZXdwb2ludC4NCiAg ICA+IA0KICAgID4gICAgSWYgdGhlIGFuc3dlciBpcyAieWVzIiwgZmFpciB3YXJuaW5nOiBSb24g YW5kIEkgYXJlIGdvaW5nIHRvIGJlIGxvb2tpbmcgZm9yIHNvbWVvbmUgdG8gd3JpdGUgYW4gaW50 ZXJuZXQgZHJhZnQgZG9jdW1lbnRpbmcgdGhlIGZhY3QgYW5kIHRoZSBkZXBsb3ltZW50IHN0YXR1 cy4NCiAgICA+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgPiAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICA+ICAgIHY2b3BzQGlldGYub3Jn DQogICAgPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQog ICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQogICAgPiBJUHY0IGlzIG92ZXINCiAgICA+IEFyZSB5b3UgcmVh ZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KICAgID4gaHR0cDovL3d3dy50aGVpcHY2Y29tcGFu eS5jb20NCiAgICA+IFRoZSBJUHY2IENvbXBhbnkNCiAgICA+IA0KICAgID4gVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0 aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBp ZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGlu Zm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZl bnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBh Ym91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCiAgICA+IA0KICAgID4gDQog ICAgPiANCiANCiANCiANCiANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCklQdjQgaXMgb3Zlcg0KQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5l dCA/DQpodHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0KVGhlIElQdjYgQ29tcGFueQ0KIA0K VGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQg dG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFi b3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29w eWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1h dGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5z ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFu eSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBj cmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVy IHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCiANCiAN CiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9w cyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo= ------=_001_NextPart821331147662_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Chongfeng,

 

Tks!

 

= I will contact you off-line. At the moment I got the confirmation from one = of the original authors, waiting for the others as well, and other folks th= at have 464XLAT deployments and want to contribute.

 

Regards,

Jord= i

= @jordipalet

 

 

 

El 17/7= /20 8:37, "v6ops en nombre de xiechf@chinatelecom.cn" <v6ops-bounces@ietf.org en nombre de xiechf@chinatelecom.cn> escribi=C3=B3:

 = ;

Hi=EF=BC=8CJordi and Fred=EF=BC=8C

I am interested in this work and I'd like to join t= he design team.

Best regards

Chongfeng

 

 =

Date: 2020-07-17 14:19

CC: <= a href=3D"mailto:v6ops@ietf.org">IPv6 Operations

<= /div>

Subject: Re: [v6ops] RFC 6877 to Proposed Standard=

Hi Fred,

 

Actually, before your message to = the list on this, I'd already sent a message to the original authors of RFC= 6877, so just waiting for them to respond.

 

=

We can look also into oth= er folks that have already deployed 464XLAT in other networks.

 <= /o:p>

Regar= ds,

Jordi

@jordipalet

 

=EF=BB=BFEl 17/7/20 2:08, "Fred Baker&q= uot; <fredbaker.ietf@gmail.com> escribi=C3=B3:

 

<= /div>

  &nb= sp; Well, may I suggest that you contact some appropriate people, whoever t= hey may be, and put together a design team to do the update? Some or all of= the original authors may be interested to participate. When you post it, I= 'll be interested in the rfcdiff (which I might just generate myself),the p= oint being that this is not a rewrite but an update.

 

<= /div>

  &nb= sp; > On Jul 16, 2020, at 10:23 AM, JORDI PALET MARTINEZ <jordi.palet= @consulintel.es> wrote:

    >

    >= Hi Fred, all,

    >

    > While I a= gree that 464XLAT is a procedure to put together other protocols, it define= s how to. This is actually the case for other standard track documents. Som= etimes this is in "the border line". However, I think it is clear= that there is a strong signal for the market, CPE vendors, etc., when some= thing is standard vs informational. This is a key reason.

   = ; >

  &n= bsp; > I think we may take the opportunity to see if some of the conside= rations in RFC8585 could be included in the RFC6877-bis. Those aren't new t= hings, just nobody put them in text before, and in fact are part of existin= g 464XLAT implementations/deployments. I recall Jen mention one of them tod= ay, maybe there are others.

    >

    >= ; There is also text in RFC8683 which may be re-used in an RFC6877-bis, aga= in thinks that are there in deployments, but not written in RFC6877.

 =    >

    > Regarding the operational experi= ence we have now, I was thinking to include a section reporting it in the R= FC6877-bis, but I'm fine if you think it should me a different document. I = will be happy to participate on it, and I would think that we should makes = sure to have co-authors from other existing deployments.

   = >

    > Regards,

    > Jordi

&nb= sp;   > @jordipalet

    >

   = ; >

    >

    > =EF=BB=BFEl 16/7/2= 0 19:08, "v6ops en nombre de Fred Baker" <v6ops-bounces@ietf.o= rg en nombre de fredbaker.ietf@gmail.com> escribi=C3=B3:

<= /div>

  &nb= sp; >

    >    In today's Interim Meet= ing, Jordi pointed out that all transition mechanisms are at Proposed Stand= ard except 464XLAT, and asked the working group to advance it to that statu= s.

    >

    >    /* Pe= rsonal Opinion */

    >    I have no probl= em with doing so, but I would ask whether 464XLAT is indeed a transition me= chanism. It is an operational procedure (and therefore within v6ops' charte= r to produce, which it did) that uses RFCs 6146, 6147, 7915, and possibly 6= 092, which are at Proposed Standard.

    >  &nb= sp; /* Personal Opinion */

    >

    >=     My huffing and puffing aside, I'd like to poll the opini= on of the working group.

    >    &nb= sp;  - does RFC 6877 need to be updated? A good approach to doing so w= ould be to file errata (https://www.rfc-editor.org/errata.php).<= /p>

  = ;  >         The document c= urrently has no errata filed. Consider this an invitation to file any needed errata and tell v6ops you have done so.

    >

&nb= sp;   >       - failing that, we= certainly have operational experience with it. It is currently an informat= ional document.

    >      = ;   Would it be appropriate to raise it to Proposed Standard?

&nb= sp;   >

    >    &nbs= p;  - Per RFC 6410, we may be in a position to advance 6877, 6146, 614= 7, and/or 7915 to Internet Standard. The criterion and process are

 &n= bsp;  >         described i= n https://tools.ietf.org/html/rfc6410, and boil down to (1) multiple intero= perable implementations and (2)

    >   &n= bsp;     a general belief that the technology works.. F= rom my perspective, if we believe that 464XLAT is widely deployed and usefu= l,

    >         = we believe that each of those are

    >

  &nbs= p; >          "charact= erized by a high degree of

    >    &= nbsp;     technical maturity and by a generally held be= lief that the

    >      &n= bsp;   specified protocol or service provides significant benefit= to the

    >       &n= bsp;  Internet community."

    >

  &= nbsp; >    Please reply all with your viewpoint.

 &n= bsp;  >

    >    If the answer is= "yes", fair warning: Ron and I are going to be looking for someo= ne to write an internet draft documenting the fact and the deployment statu= s.

    >    ______________________________= _________________

    >    v6ops mailing l= ist

    >    v6ops@ietf.org

=

  &n= bsp; >    https://www..ietf.org/mailman/listinfo/v6ops

&n= bsp;   >

    >

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    >

    > **********************************************=

    > IPv4 is over

    > Are you ready= for the new Internet ?

    > http://www.theipv6company.c= om

    > The IPv6 Company

    >

 =    > This electronic message contains information which may be= privileged or confidential. The information is intended to be for the excl= usive use of the individual(s) named above and further non-explicilty autho= rized disclosure, copying, distribution or use of the contents of this info= rmation, even if partially, including attached files, is strictly prohibite= d and will be considered a criminal offense. If you are not the intended re= cipient be aware that any disclosure, copying, distribution or use of the c= ontents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must r= eply to the original sender to inform about this communication and delete i= t.

    >

    >

    >= ;

 

 

 

 

********************************************= **

IPv4 is over

Are you ready for the new Internet ?

http://www.theipv6comp= any.com

The IPv6 Company

 

This electronic message contains informatio= n which may be privileged or confidential. The information is intended to b= e for the exclusive use of the individual(s) named above and further non-ex= plicilty authorized disclosure, copying, distribution or use of the content= s of this information, even if partially, including attached files, is stri= ctly prohibited and will be considered a criminal offense. If you are not t= he intended recipient be aware that any disclosure, copying, distribution o= r use of the contents of this information, even if partially, including att= ached files, is strictly prohibited, will be considered a criminal offense,= so you must reply to the original sender to inform about this communicatio= n and delete 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/v= 6ops


*********************************************= *
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677820861_571986675-- From nobody Fri Jul 17 01:00:57 2020 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 850113A14E4 for ; Fri, 17 Jul 2020 01:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcb9fDGrjIFE for ; Fri, 17 Jul 2020 01:00:53 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id DC0713A12F1 for ; Fri, 17 Jul 2020 01:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594972851; x=1595577651; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Zr1Me1Js tm8koAl1wbnrxTlfRgk4E265+5mHJb37yUk=; b=NG5gH2K3e5VXlLVfR6bhFcey 1sbhbMkuenpKL/IOaylNWA9PzbZYz+M5YEFmRxsXsIOCIgZmSBRsSum7Yegef64c rE6V+u4cehIZWBoNQXTpaichIXoDEc0rxOXOLaRVV4wRZYBWJhDF0uX4eMBdLlH1 ZK3vziaa/AhJ7tUXBoQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 10:00:51 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 10:00:51 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000290778.msg for ; Fri, 17 Jul 2020 10:00:49 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 10:00:49 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 10:00:45 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <75108EA5-62D2-43EF-BEBC-646737384F9C@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> In-Reply-To: <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 08:00:56 -0000 Hi Eduard, Let us know what do you think about this tentative alternative text to reso= lve this issue: 5.2.4. Forwarding path via stateful NAT for existing EAMT entries Following this approach, if there is a valid EAMT entry, for a given IPv4-destination, the IPv6-native path pointed by the IPv6 address of that EAMT entry, will take precedence versus the NAT64 path, so the traffic will not be forwarded to the NAT64. However, this is not sufficient to ensure that individual applications are able to keep existing connections. In many cases, audio and video streaming may use a single TCP connection lasting from minutes to hours. Instead, the CDN TTLs may be configured in the range from 10 to 300 seconds in order to allow new resolutions to switch quickly and to handle large recursive resolvers (with hundreds of thousands of clients behind them). Consequently, the EAMT entries MUST NOT be used directly to establish a forwarding path, but instead, MUST be used to create a stateful NAT entry for the 4-tuple for the duration of the session/connection. This means that to implement the optimization the NAT46 MUST be stateful. Typically, stateful NAT46 are implemented by means of a stateful NAT44 (which often maybe hardware off-loaded), followed by a stateless NAT46. If the SoC/code is able to do stateless NAT46, this still could be used when the optimization is disabled. Note that also following Erik inputs, the text has more normative language. Also, for the title we thought that it will make sense: 464XLAT/MAP-T Optimization No need to mention NAT64, which is part of the 464XLAT. =20 Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 15/7/20 16:18, "v6ops en nombre de JORDI PALET MARTINEZ" escribi=C3=B3: I think your point will be to make it clear in the document that for th= is optimization to work, the CLAT should be stateful? I think is there (5.2.4. Forwarding path via stateful NAT for existing= EAMT entries), but I will make sure to add the relevant text in the next v= ersion to make it clearer.=20 I insist: most of the CLAT implementations today (running in both CPEs = and UEs) are stateful. At least this is the data I've. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" escribi=C3=B3: Hi Jordi, I still believe that tough (new) requirement that CLAT should becom= e Stateful (mandatory) Make sense to insert into the document. And explanation why stateful NAPT is needed would be good. I have spent some time to research this - it is better to save time= of other people. It is important point that is omitted in the document. For the name: I do not have any strong opinion. Just I see that draft is applicable mostly to MAP-T, And not much applicable to XLAT (because majority of installations = have stateless CLAT). But the name mislead to opposite conclusion. Eduard -----Original Message----- From: Jordi Palet Mart=C3=ADnez [mailto:jordi.palet@theipv6company.= com]=20 Sent: 15 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 16:48 To: Vasilenko Eduard ; v6ops@ietf.org Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimizat= ion-02 - concern on statefulness Hi Vasilenko, The implementations of 464XLAT, can do the same (and in fact, many = of them is what they do). NAT44 stateful and the 46 stateless. Many SoC hav= e embedded NAT44 acceleration, but not NAT46, so that explains it as well. I guess that could clear your concern? I've several customers doing 464XLAT in broadband, one of them 25.0= 00.000 subscribers. There is no difference in doing 464XLAT in cellular and= broadband. When we say in the title 464XLAT/NAT64, I think both are covered. B= ut I've no issue to change the title if this makes sense to others. We coul= d explictily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, i= n my opinion. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:40, "Vasilenko Eduard" escribi=C3=B3: Hi all, I have concern on the capability to use this mechanism for 464X= LAT, but it should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB traffi= c is still designated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. acti= ve sessions from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to squee= ze (for path to Internet it would be "source IP address") many private IPv4= hosts to one IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port tra= nslation is mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearly st= ate in the document that we are going to reuse NAPT. Then translation would= be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, it c= ould be not public, but public A+P has been given to MAP CE anyway - better= to reuse it for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not po= pular - not implemented by many carriers (if any?). It would be the big news that Carriers should choose stateful C= LAT option for 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use Stateless= CLAT for basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 = sites? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smooth ex= pansion for MAP-T. Hence, does it make sense to change the name of this draft to r= eflect MAP-T as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of intern= et-drafts@ietf.org Sent: 11 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimizat= ion-02.txt A New Internet-Draft is available from the on-line Internet-Dra= fts directories. This draft is a work item of the IPv6 Operations WG of the IETF= . Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02.txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide = access for IPv4-only devices or applications to IPv4-only or dual-s= tack destinations over IPv6-only infrastructure. In that case, t= he traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NA= T64, at the egress point). When the destination is IPv6-enabled, th= e second translation might be avoided. This document describes a pos= sible optimization to 464XLAT and MAP-T to avoid translating IPv6 = flows back to IPv4 if the destination is reachable over IPv6. The= proposed solution would significantly reduce the NAT64 utilization in= the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optim= ization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimizati= on-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-= optimization-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-op= timization-02 Please note that it may take a couple of minutes from the time = of submission until the htmlized version and diff are available at tools.ie= tf.org. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Jul 17 02:40:27 2020 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 8F44A3A15E0 for ; Fri, 17 Jul 2020 02:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtqrWD2fiS61 for ; Fri, 17 Jul 2020 02:40:22 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 454643A07B9 for ; Fri, 17 Jul 2020 02:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594978820; x=1595583620; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=RdVtPQdiT/5zwYStrWcXBVF8jPrVs43HkC47NwKdXgw=; b=QN3Hl9c5P+82CDVg8bmHZ3UYJ5rzpUbOvpQr4i0bXDWQP9MyMBf8RYAp5NFBgS nxKUcL0JPlAqMW5Qdf1cMlf6sHmG03Vdp++C7Dxq3UeO9sTeyoOZG6qTNcKSh10x vk48iJKfz7ifcGur+19RK/CSx+yaWvua86tV4ObIlsAJ0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 11:40:20 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 11:40:17 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000290917.msg for ; Fri, 17 Jul 2020 11:40:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 11:40:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 11:40:12 +0200 From: JORDI PALET MARTINEZ To: Erik Nygren , V6 Ops List Message-ID: Thread-Topic: draft-ietf-v6ops-464xlat-optimization-02 general concerns Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3677830812_1531450007" Archived-At: Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 09:40:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3677830812_1531450007 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Erik, =20 I think it will be good to respond in different threads to simplify the dis= cussion and try to find appropriate text for each of the issues that you me= ntion. This one is on your general concerns, below in-line. If any of the general concerns is further discussed in the rest of your ema= il, I will try to tackle it also in the follow-up emails, so we can concent= rate in every possible issue in the specific email to avoid multiple parall= el threads on the same issue. Tks a lot! =20 El 15/7/20 7:54, "v6ops en nombre de Erik Nygren" escribi=C3=B3: =20 On Thu, Jul 9, 2020 at 11:58 PM Jen Linkova wrote: OK, I"ve read the document and before I finish the write up I'd like to discuss a number of comments I have. My apologies for not raising them during the WGLC - I was not paying attention, got busy with work... Prodded by Jen's response here I also re-read draft-ietf-v6ops-464xlat-opti= mization-02. (My apologies also for not raising these during WGLC -- similar excuses to = Jen... ;-) While this continues to close corner-cases, I'm still concerned that there is significant possibility for breakage in a way that will result in content that is now dual-stacked getting switched to be IPv4-only. It would be good to add some examples as to why some of the invalidation logic needs to actually work (and the risk of corner cases where it doesn't). To that end, it may make sense to also have some more use of normative rfc2119 language for clearly spelling out behaviors where there are sharp edges. [Jordi] Often when an informational document goes to the IESG they complain= about the use of normative language. One open question is, if we advance R= FC6877 to standards then, we could consider that this optimization should b= e also in the standards track. Anyway, at the time being I will keep it as = informational, but I will add normative language to make everything very cl= ear and more examples as needed in every section. Some example cases of breakage or significant risk of breakage: * A site is IPv4-only (breaks for or denies all IPv6 users) but shares an A= record with a dual-stack site. If this isn't detected properly, it will b= reak users who get sent over IPv6 to the IPv4-only site. =20 [Jordi] My goal has been to ensure that the optimization doesn=E2=80=99t br= eak any case, and especially when the site only offers A records. Unless I= =E2=80=99m missing something, I think this is perfectly resolved in 5.2.2, = because the EAMT entry will be only created if the site is only IPv4-only. * some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address for = demuxing IPv6 traffic (both to determine which cert to serve). This means = that the IPv4:IPv6 associations are one to many and using the wrong one wil= l result in cert errors. =20 [Jordi] This was discussed in a previous version (I recall it was after the= presentation in Prague) and resolved by incorporating the FQDN in the EAMT= entry and a section 5.2.4, which forces the forwarding path via a stateful= NAT44. * Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one custo= mer/tenant, but then cluster A for IPv4 and cluster C for a different custo= mer/tenant. An stale or invalid association will result in going to the wr= ong cluster which may not be able to serve the request properly. [Jordi] Same as the previous one. Because the EAMT entry is created by ever= y CE, the association between a given IPv4 and IPv6 FQDN/addresses is done = the same way as if the same CE is actually dual-stack instead of IPv6-only.= If I got it correctly, in a CDN, any change in terms of what cluster is se= rving what, depends on DNS TTLs and maybe routing, right? If that=E2=80=99s= the case, routing is transparent because the entries are created in each C= E, and to the CDN they appear as a dual-stack eyeball. Similarly, we rely i= n the CDN provided TTLs. =20 ** if the user changes DNSs, unexpected consequences may happen, but there = is no difference vs the case when there is no optimization. Any change in t= he DNSs done by users, may break thinks (for example, CDN contents are serv= er from another cluster). Nevertheless, usually users change DNS in end-hos= ts (Windows, Linux, MacOS, etc.), it is not so common to change those in th= e CE. Is even less common to change them in the smartTV or STB, because in = many cases they don=E2=80=99t allow it. This is described in 5.2.10. If nee= ded I can improve that section. While the recent revisions help some, there are still a bunch of cases where things could still break. I fear that when they do break it's not something that content providers or CDNs or their customers will debug and the result will be for content to get switched back to IPv4-only (which is not what we want happening, but will appear to "fix" issues here). [Jordi] Fully agree here, we need to make sure that we don=E2=80=99t break = anything. I think there may also be some significant security issues not called out that are independent of the DNS spoofing issue. [Jordi] I will move this to independent threads. Another area not discussed is clients caching DNS lookups well past their TTL. This is fairly common in some clients (eg, some Java versions) which could result in entries getting expired from the EAMT but then used with a new association that should be invalid but wasn't detected as such as the first client is caching well past the expiry.. [Jordi] I=E2=80=99m confused here. =20 You mean a client ignoring DNS TTLs ? This could actually be a problem with= out the optimization. If the CDN is changing the IPv4 or IPv6 addresses, bu= t the client is still using them, the content will be unreachable or someth= ing different served, right? So, the optimization is not the problem here i= t is a broken client already =E2=80=A6 =20 Note that if the EAMT expired and the client tries to use it again, the EAM= T entry will be re-created with the new (correct) information from the CDN = DNSs, so we may be potentially solving the broken client problem. If the EA= MT, for whatever reason is not recreated, the optimization will not be used= , so the client will be still doing the =E2=80=9Ccorrect=E2=80=9D thing acc= ording to its expected behavior (non-optimized NAT46+NAT64) =E2=80=93 wheth= er it is a broken behavior or not. =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3677830812_1531450007 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Erik,

 

I think it will be good to respond in different threads to sim= plify the discussion and try to find appropriate text for each of the issue= s that you mention.

This one is on your general concerns, below in-line.

If any of = the general concerns is further discussed in the rest of your email, I will= try to tackle it also in the follow-up emails, so we can concentrate in ev= ery possible issue in the specific email to avoid multiple parallel threads= on the same issue.

Tks a lot!

=  

El 15/7/20 7:54, "v6ops en nombre de Erik Nygren" <= v6ops-bounces@ietf.org en nom= bre de erik+ietf@nygren.org>= escribi=C3=B3:

 

On Thu, Jul 9, 2020 at 11:58 PM Jen Linkova = <furry13@gmail.com> wrote:

OK, I"ve read the documen= t and before I finish the write up I'd like
to discuss a number of comme= nts I have.
My apologies for not raising them during the WGLC - I was no= t paying
attention, got busy with work...


Prodded by Jen's respons= e here I also re-read draft-ietf-v6ops-464xlat-optimization-02.
(My apol= ogies also for not raising these during WGLC -- similar excuses to Jen... &= nbsp;;-)

While this continues to close corner-cases, I'm still conce= rned
that there is significant possibility for breakage in a way thatwill result in content that is now dual-stacked getting switched
to be = IPv4-only.

It would be good to add some examples as to why
some o= f the invalidation logic needs to actually work
(and the risk of corner = cases where it doesn't).
To that end, it may make sense to also have som= e more
use of normative rfc2119 language for clearly spelling out behavi= ors
where there are sharp edges.

[Jordi] Often when an inf= ormational document goes to the IESG they complain about the use of normati= ve language. One open question is, if we advance RFC6877 to standards then,= we could consider that this optimization should be also in the standards t= rack. Anyway, at the time being I will keep it as informational, but I will= add normative language to make everything very clear and more examples as = needed in every section.


Some example cases of breakage = or significant risk of breakage:
* A site is IPv4-only (breaks for or de= nies all IPv6 users) but shares an A record with a dual-stack site.  <= /span>If this isn't detected properly, it will break users who get sent over IPv6 to the IPv4-only site.

 

[Jordi] My goal has been to= ensure that the optimization doesn=E2=80=99t break any case, and especiall= y when the site only offers A records. Unless I=E2=80=99m missing something= , I think this is perfectly resolved in 5.2.2, because the EAMT entry will = be only created if the site is only IPv4-only.


* some CD= Ns use TLS SNI for demuxing IPv4 traffic but the IPv6 address for demuxing = IPv6 traffic (both to determine which cert to serve).  This mea= ns that the IPv4:IPv6 associations are one to many and using the wrong one = will result in cert errors.

 

[Jordi] This was discussed in a p= revious version (I recall it was after the presentation in Prague) and reso= lved by incorporating the FQDN in the EAMT entry and a section 5.2.4, which= forces the forwarding path via a stateful NAT44.


* Some= CDNs may use cluster A for IPv4 and cluster B for IPv6 for one customer/te= nant, but then cluster A for IPv4 and cluster C for a different customer/te= nant.  An stale or invalid association will result in going to = the wrong cluster which may not be able to serve the request properly.
<= br>

[Jordi] Same as the previous one. Because the EAMT entry is creat= ed by every CE, the association between a given IPv4 and IPv6 FQDN/addresse= s is done the same way as if the same CE is actually dual-stack instead of = IPv6-only. If I got it correctly, in a CDN, any change in terms of what clu= ster is serving what, depends on DNS TTLs and maybe routing, right? If that= =E2=80=99s the case, routing is transparent because the entries are created= in each CE, and to the CDN they appear as a dual-stack eyeball. Similarly,= we rely in the CDN provided TTLs.

 

** if t= he user changes DNSs, unexpected consequences may happen, but there is no d= ifference vs the case when there is no optimization. Any change in the DNSs= done by users, may break thinks (for example, CDN contents are server from= another cluster). Nevertheless, usually users change DNS in end-hosts (Win= dows, Linux, MacOS, etc.), it is not so common to change those in the CE. I= s even less common to change them in the smartTV or STB, because in many ca= ses they don=E2=80=99t allow it. This is described in 5.2.10. If needed I c= an improve that section.


While the recent revisions help= some, there are still a bunch of cases
where things could still break.&= nbsp; I fear that when they do break it's
not something that cont= ent providers or CDNs or their customers will
debug and the result will = be for content to get switched back
to IPv4-only (which is not what we w= ant happening, but will
appear to "fix" issues here).

<= o:p>

[Jordi] Fully agree here, we need to make sure that we don=E2=80=99t = break anything.


I think there may also be some significa= nt security issues not called out
that are independent of the DNS spoofi= ng issue.

[Jordi] I will move this to independent thre= ads.


Another area not discussed is clients caching DNS l= ookups well past
their TTL.  This is fairly common in some cli= ents (eg, some Java versions)
which could result in entries getting expi= red from the EAMT but then used
with a new association that should be in= valid but wasn't detected as such
as the first client is caching well pa= st the expiry..

[Jordi] I=E2=80=99m confused here.=

 

You mean a client ignoring DNS TTLs ? This could act= ually be a problem without the optimization. If the CDN is changing the IPv= 4 or IPv6 addresses, but the client is still using them, the content will b= e unreachable or something different served, right? So, the optimization is= not the problem here it is a broken client already =E2=80=A6

=  

Note that if the EAMT expired and the client tries to= use it again, the EAMT entry will be re-created with the new (correct) inf= ormation from the CDN DNSs, so we may be potentially solving the broken cli= ent problem. If the EAMT, for whatever reason is not recreated, the optimiz= ation will not be used, so the client will be still doing the =E2=80=9Ccorr= ect=E2=80=9D thing according to its expected behavior (non-optimized NAT46+= NAT64) =E2=80=93 whether it is a broken behavior or not.<= /p>

=  

 


********= **************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677830812_1531450007-- From nobody Fri Jul 17 03:14:13 2020 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 C2D553A07D1 for ; Fri, 17 Jul 2020 03:14:11 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiyzYjIxew0x for ; Fri, 17 Jul 2020 03:14:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697A83A07C0 for ; Fri, 17 Jul 2020 03:14:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jwNNT-00007PC; Fri, 17 Jul 2020 12:14:03 +0200 Message-Id: To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com In-reply-to: Your message of "Fri, 17 Jul 2020 11:40:12 +0200 ." Date: Fri, 17 Jul 2020 12:14:02 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 10:14:12 -0000 > * Some CDNs may use cluster A for IPv4 and cluster B for IPv6 > for one customer/tenant, but then cluster A for IPv4 and cluster > C for a different customer/tenant. An stale or invalid association > will result in going to the wrong cluster which may not be able > to serve the request properly. > > [Jordi] Same as the previous one. Because the EAMT entry is > created by every CE, the association between a given IPv4 and > IPv6 FQDN/addresses is done the same way as if the same CE is > actually dual-stack instead of IPv6-only. If I got it correctly, > in a CDN, any change in terms of what cluster is serving what, > depends on DNS TTLs and maybe routing, right? If that's the > case, routing is transparent because the entries are created in > each CE, and to the CDN they appear as a dual-stack eyeball. > Similarly, we rely in the CDN provided TTLs. I don't understand this. Suppose an IPv4-only client looks up a.example.com and b.example.com (in parallel). Both return 192.0.2.1 However, the IPv6 address for a.example.com is 2001:DB8::1 and the one for b.example.com is 2001:DB8::2 Now the client connects twice to 192.0.2.1 to set up two tls connections, one for a.example.com and one for b.example.com. How does the CPE know that it needs to connect one tcp connection to 2001:DB8::1 and the other to 2001:DB8::2? From nobody Fri Jul 17 03:15:39 2020 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 B3B1B3A0887 for ; Fri, 17 Jul 2020 03:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RHdyntiEIaf for ; Fri, 17 Jul 2020 03:15:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id C797D3A07E5 for ; Fri, 17 Jul 2020 03:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594980919; x=1595585719; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=c9WJ21TF312/roJ+91E3KZ4zwG8NR4I5YM4rBXoT2Wo=; b=mZcZRfb7lF/Q2RrHkLKns3vd8oBe36/Ub1CV8+C9/2rzs2wbUUncOypCMlcncr GR21cXIst8q6gQOYFmRK+GgHvKOjjofGw6JB0J+eNuM3eRO+Cl5Hb+17pDgcN8pF sWWfBsWIyvk+QMQB/DgxNiv5eHOrQu7uaQ1gC2khJoMl8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 12:15:19 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 12:15:18 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000290954.msg for ; Fri, 17 Jul 2020 12:15:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 12:15:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 12:15:16 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <67C20112-4347-4F99-891C-993D25EEA19E@consulintel.es> Thread-Topic: draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3677832916_683102658" Archived-At: Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 10:15:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3677832916_683102658 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > 5.2.1 Detection of IPv4-only hosts or applications > It needs to be remarked that, if the detection of the IPv4-only > device or application is done incorrectly (either not detecting it > or by a false detection), no harm is caused. I'm not sure that "no harm is caused" is always the case. There may be harm due to cases such as a client no longer able to fall back to the IPv4 address it would have used in a Happy Eyeballs setup. (ie, connectivity is discussed extensively here, but application-level breakage due to some of the issues mentioned above may not be possible to recover from). [Jordi] Maybe is a matter of an alternative wording: =E2=80=9Cthe goal is t= hat no harm is caused=E2=80=9D. =20 Regarding HE, I think this is well explained in the updated 5.2.12. section= . =20 One possible alternative if we want to keep HE working *at all means*, even= if it is worse than the optimization (which is very possible, because we a= re talking about IPv6-only access, so most probably if IPv6 is broken, IPv4= is broken as well), will be to add one more field in the EAMT entry: The I= Pv4 source address from the hosts in that network. Then we can ensure that = the EAMT entries are =E2=80=9Cper client=E2=80=9D and applied only to each = client and only to IPv4-only clients. So dual-stack clients will NOT use th= e optimization (in normal conditions they should prefer IPv6!). This small = change in the approach makes the optimization implementation a bit more com= plex, but being done by the CPE, still is preferable to the NAT64 unnecessa= ry overload. I think that this may also *resolve* many of the other issues = that I=E2=80=99m still reading from the list and even some security issues. =3D=3D=3D=3D=3D=3D=3D=3D=3D > 5.2.1 Detection of IPv4-only hosts or applications Will Android doing synchronous A/AAAA lookups break this detection? and does this impact other things like STBs built on Android? Android does one of the A or AAAA lookups, waits for it to return, then does the other. From the perspective of the CPE resolver, could look like an IPv4-only host and just always introduce the 50ms delay? Some more details may be needed here on the timing heuristics needed to detect various scenarios like this. =20 [Jordi] When a synchronous lookup is performed, then it is clear that the h= osts is IPv6 enabled (actually dual-stack), so the EAMT entry is not create= d. If the EAMT entry already exists, then it will be used only if the host = decides to prefer IPv4 instead of IPv6, which doesn=E2=80=99t look like a n= ormal behavior. To ensure it, we may need to double-check if the 50 ms. del= ay is still good for Android or it is too small. I don=E2=80=99t think it i= s a big issue to increase it. We could improve it, to avoid the delay, if w= e create an additional table for the =E2=80=9Calready known=E2=80=9D to be = dual-stack hosts. This may be also related to the new field in the EAMT tha= t I mention above. =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3677832916_683102658 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


> 5.2.1 Detection of IPv4-only hosts or applications=
> It needs to be remarked that, if the detection of the IPv4-only> device or application is done incorrectly (either not detecting it> or by a false detection), no harm is caused.

I'm not su= re that "no harm is caused" is always the case.
There may be h= arm due to cases such as a client no longer
able to fall back to the IPv= 4 address it would have used
in a Happy Eyeballs setup.  (ie, conne= ctivity is discussed extensively
here, but application-level breakage du= e to some of the issues
mentioned above may not be possible to recover f= rom).

[Jordi] Maybe is a matter of an alternative wording: = =E2=80=9Cthe goal is that no harm is caused=E2=80=9D.

=

&nb= sp;

Regarding HE, I think this is well explained in the updated 5.2= .12. section.

 

One possible alternative if = we want to keep HE working *at all means*, even if it is worse than = the optimization (which is very possible, because we are talking about IPv6= -only access, so most probably if IPv6 is broken, IPv4 is broken as well), = will be to add one more field in the EAMT entry: The IPv4 source address fr= om the hosts in that network. Then we can ensure that the EAMT entries are = =E2=80=9Cper client=E2=80=9D and applied only to each client and only to IP= v4-only clients. So dual-stack clients will NOT use the optimization (in no= rmal conditions they should prefer IPv6!). This small change in the approac= h makes the optimization implementation a bit more complex, but being done = by the CPE, still is preferable to the NAT64 unnecessary overload. I think = that this may also *resolve* many of the other issues that I=E2=80= =99m still reading from the list and even some security issues.<= /span>


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

> 5.2.1  Detection of IP= v4-only hosts or applications

Will Android doing synchronous A/AAAA = lookups break this
detection?  and does this impact other th= ings like STBs built on
Android?  Android does one of the A or AAAA= lookups, waits for it
to return, then does the other.  From the pe= rspective of the CPE resolver,
could look like an IPv4-only host and jus= t always introduce the 50ms delay?

Some more deta= ils may be needed here on the timing heuristics needed
to detect various= scenarios like this.

 

[Jordi] When a sync= hronous lookup is performed, then it is clear that the hosts is IPv6 enable= d (actually dual-stack), so the EAMT entry is not created. If the EAMT entr= y already exists, then it will be used only if the host decides to prefer I= Pv4 instead of IPv6, which doesn=E2=80=99t look like a normal behavior. To = ensure it, we may need to double-check if the 50 ms. delay is still good fo= r Android or it is too small. I don=E2=80=99t think it is a big issue to in= crease it. We could improve it, to avoid the delay, if we create an additio= nal table for the =E2=80=9Calready known=E2=80=9D to be dual-stack hosts. T= his may be also related to the new field in the EAMT that I mention above.<= o:p>

 



 


**************= ********************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677832916_683102658-- From nobody Fri Jul 17 03:20:22 2020 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 055D83A080E for ; Fri, 17 Jul 2020 03:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ke-SaZva16J for ; Fri, 17 Jul 2020 03:20:19 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 440AC3A0807 for ; Fri, 17 Jul 2020 03:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594981218; x=1595586018; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Tno5Vm93 NFlKpTtEb4npQJJxVpjROO1wum5MHoB7Icw=; b=cWDLVoKJo9Em3/bXSZQPUb/4 qKUfTRJbngRPwnbXmkdC75zvX8eLlvj9hJbTD0npni/Joel4sAcLMz+2eyzjQ6Z9 adeiR0RfXRtQ0Izvi5o56L43dCyzW+vNcLV3uql/VCuvtCDRnfnEqsPe8BjwZU2r zoXx+1+xI0rnhuWvzWk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 12:20:18 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 12:20:18 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000290978.msg for ; Fri, 17 Jul 2020 12:20:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 12:20:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 12:20:13 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 10:20:21 -0000 Hi Philip, Because the EAMT contains the FQDN so to avoid creating a trouble, in this case the EAMT entry is set to invalid, and not used. This is described in 5.2.6 with a similar example. > * Some CDNs may use cluster A for IPv4 and cluster B for IPv6 > for one customer/tenant, but then cluster A for IPv4 and cluster > C for a different customer/tenant. An stale or invalid association > will result in going to the wrong cluster which may not be able > to serve the request properly. > > [Jordi] Same as the previous one. Because the EAMT entry is > created by every CE, the association between a given IPv4 and > IPv6 FQDN/addresses is done the same way as if the same CE is > actually dual-stack instead of IPv6-only. If I got it correctly, > in a CDN, any change in terms of what cluster is serving what, > depends on DNS TTLs and maybe routing, right? If that's the > case, routing is transparent because the entries are created in > each CE, and to the CDN they appear as a dual-stack eyeball. > Similarly, we rely in the CDN provided TTLs. I don't understand this. Suppose an IPv4-only client looks up a.example.com and b.example.com (in parallel). Both return 192.0.2.1 However, the IPv6 address for a.example.com is 2001:DB8::1 and the one for b.example.com is 2001:DB8::2 Now the client connects twice to 192.0.2.1 to set up two tls connections, one for a.example.com and one for b.example.com. How does the CPE know that it needs to connect one tcp connection to 2001:DB8::1 and the other to 2001:DB8::2? ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Fri Jul 17 03:38:00 2020 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 0AB4E3A0917 for ; Fri, 17 Jul 2020 03:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FizXOqVWDoEQ for ; Fri, 17 Jul 2020 03:37:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25653A091D for ; Fri, 17 Jul 2020 03:37:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jwNkW-0000HJC; Fri, 17 Jul 2020 12:37:52 +0200 Message-Id: To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-reply-to: Your message of "Fri, 17 Jul 2020 12:20:13 +0200 ." <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> Date: Fri, 17 Jul 2020 12:37:51 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 10:37:58 -0000 In your letter dated Fri, 17 Jul 2020 12:20:13 +0200 you wrote: >Because the EAMT contains the FQDN so to avoid creating a trouble, in this case >the EAMT entry is set to invalid, and not used. This is described in 5.2.6 with >a similar example. Can you explain what happens if both A queries and the first AAAA query is served from a local resolver's cache and then the second AAAA query is delayed? I guess Section 5.2.2 can be made explicit that the CPE must not return the answer to an A query until an answer to the AAAA query has been received. From nobody Fri Jul 17 03:43:45 2020 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 476013A097C for ; Fri, 17 Jul 2020 03:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3xmmlXACjIw for ; Fri, 17 Jul 2020 03:43:42 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 281AD3A097B for ; Fri, 17 Jul 2020 03:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594982620; x=1595587420; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=9OwjeAvlrItN35VO+hQEXeEvC+r5LAExRWujZQpJf74=; b=dtOVJB125Zmkm7YQ54+BL18cnxpM5BY/qdlIqcrbQbQ1+ORU+rwQOaSH6p9pgX ZYWoHZEe2C9J0v4xqZZb+5latSXjEyk9k0MPyfoXro6LVEJ7z/8cHybX/YyLJFSv KgszrBTf2Bpa2Ih+oUiCzH06Ve6wEgJI7a10pbzV81mYo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 12:43:40 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 12:43:40 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000291087.msg for ; Fri, 17 Jul 2020 12:43:39 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 12:43:39 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 12:43:35 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <26AB832C-543C-4D61-9998-F6C8E9A9EA39@consulintel.es> Thread-Topic: draft-ietf-v6ops-464xlat-optimization-02 - 5.2.3 > 4. TTL Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3677834615_329334172" Archived-At: Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.3 > 4. TTL X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 10:43:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3677834615_329334172 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > 5.2.3 > 4. TTL > "In normal conditions the TTL for both A > and AAAA records, of a given FQDN, should be the same, so this > ensures a proper behavior if there is any DNS mismatch." Actually if the resolver is a forwarding resolver talking to the ISP's recursive resolver then it is likely the TTLs returned will have degraded some and will be different. For example, if a CDN is using a 60s TTL then it is likely that the A RRset could have 12s remaining while the AAAA RRset has 48s remaining. Using the minimum of the two TTLs is likely better than assuming they will = match. =20 [Jordi] Yep, you=E2=80=99re right. In an optimal situation they should matc= h, but using the minimum of the could resolve some inconsistences even if t= his just means that the EAMT expires and then a new one needs to be created= . It may make sense to keep track of EAMT records somewhat past their TTL to handle clients caching things longer as well as race conditions. For example, add a "stale" state which can convert to "invalid" but won't get used for new connections and which entries stay in for some amount of time past expiry. =20 [Jordi] Yes, again you=E2=80=99re right. It can help to avoid extreme cases= even for broken clients. Nit: Is this really an "expiry time" rather than a "TTL"? While mentioned later, it would be good to emphasize that invalidating or expiring EAMT entries MUST NOT break existing connections. (ie, that the 5.2.4 behavior is absolutely required.) Implementations getting this wrong would be really bad in-terms of breaking dual-stack content while IPv4-only content would keep working (ie, due to the lack of associations). Hurting reliability for dualstack content relative to IPv4-only content would be bad. [Jordi] I will reword expire time/TTLs to make it clear. On the other point= , I=E2=80=99ve provided earlier today a tentative text for 5.2.4 using norm= ative language in response to one of the Eduard inputs. Let me know if you = think that=E2=80=99s sufficient. Also not covered here is clients caching A/IPv4 lookups for extended time. For example, the EAMT entry may have expired but client may have A record cached and then another mismatching EAMT entry might get created for a different FQDN. =20 [Jordi] This is one of the points in a previous email. Is not that a broken= client? Is not that a situation, that without the optimization already wil= l mean the client may be getting a different response from the CDN or nothi= ng at all? Also, if we add the client source address as a field in the EAMT, this is a= lso resolved, I think. =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3677834615_329334172 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

>= ; 5.2.3
> 4. TTL
>    "In normal conditions the = TTL for both A
>       and AAAA records, of a given FQ= DN, should be the same, so this
>       ensures a prop= er behavior if there is any DNS mismatch."

Actually if the reso= lver is a forwarding resolver talking
to the ISP's recursive resolver th= en it is likely the TTLs
returned will have degraded some and will be di= fferent.
For example, if a CDN is using a 60s TTL then it is likely
t= hat the A RRset could have 12s remaining while the AAAA RRset
has 48s re= maining.

Using the minimum of the two TTLs is likely better than ass= uming they will match.

 

[Jordi] Yep, you=E2=80=99re right. In a= n optimal situation they should match, but using the minimum of the could r= esolve some inconsistences even if this just means that the EAMT expires an= d then a new one needs to be created.



It may make se= nse to keep track of EAMT records somewhat past their
TTL to handle clie= nts caching things longer as well as race conditions.
For example= , add a "stale" state which can convert to "invalid" bu= t won't
get used for new connections and which entries stay in for some = amount
of time past expiry.

 

[Jordi] Yes, again you=E2=80=99= re right. It can help to avoid extreme cases even for broken clients.<= /o:p>



Nit: Is this really an "expiry time" rather tha= n a "TTL"?
While mentioned later, it would be good to e= mphasize
that invalidating or expiring EAMT entries MUST NOT
break ex= isting connections.  (ie, that the 5.2.4 behavior
is absolutely req= uired.)  Implementations getting this wrong
would be really bad in-= terms of breaking dual-stack content
while IPv4-only content would keep = working (ie, due to
the lack of associations).   Hurting reliabilit= y for dualstack
content relative to IPv4-only content would be bad.
<= br>

[Jordi] I will reword expire time/TTLs to make it clear. On the o= ther point, I=E2=80=99ve provided earlier today a tentative text for 5.2.4 = using normative language in response to one of the Eduard inputs. Let me kn= ow if you think that=E2=80=99s sufficient.


Also not cove= red here is clients caching A/IPv4 lookups for extended time.
For= example, the  EAMT entry may have expired but client may have A recor= d
cached and then another mismatching EAMT entry might get created for a=
different FQDN.

 

[Jordi] This is one of the points in a pre= vious email. Is not that a broken client? Is not that a situation, that wit= hout the optimization already will mean the client may be getting a differe= nt response from the CDN or nothing at all?

Also, if we add = the client source address as a field in the EAMT, this is also resolved, I = think.

 

 


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677834615_329334172-- From nobody Fri Jul 17 04:03:13 2020 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 CD6EF3A09EF for ; Fri, 17 Jul 2020 04:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejQpaDLXkpC1 for ; Fri, 17 Jul 2020 04:03:10 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id F31643A09EE for ; Fri, 17 Jul 2020 04:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594983788; x=1595588588; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=aygiMpD+ hflCnyUX1opSfNeRXwNbyIkP4dC/DHejBj4=; b=MyBpUM1ZYYzrE0LuaIru0H6E DcXJ6EMJ5ywXBi/p6211GgUZUSYgpQijO6zo1aiQK0o6hdtUBamiJuM93RTcoMOc zpkuXNbbXngM/1cO8H+miXd3ZsMnJil2389VEnH0gFmcvHNInxhojxypY3X1RT3Y bwHm7R0aS0H/zcumOPw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 13:03:08 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 13:03:08 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000291140.msg for ; Fri, 17 Jul 2020 13:03:06 +0200 X-MDRemoteIP: 2001:470:1f09:495:45be:3ec8:c6f0:2bd0 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 13:03:06 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 13:03:03 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 11:03:12 -0000 In your letter dated Fri, 17 Jul 2020 12:20:13 +0200 you wrote: >Because the EAMT contains the FQDN so to avoid creating a trouble, in this case >the EAMT entry is set to invalid, and not used. This is described in 5.2.6 with >a similar example. Can you explain what happens if both A queries and the first AAAA query is served from a local resolver's cache and then the second AAAA query is delayed? [Jordi] If the 2nd AAAA query is delayed past the "Resolution Delay", the EAMT entry will not be created (this time, it may happen later), so the optimization will not be performed for this IPv4 destination. See section 5.2.3. I guess Section 5.2.2 can be made explicit that the CPE must not return the answer to an A query until an answer to the AAAA query has been received. [Jordi] Good point. May be: "The CE DNS proxy MUST NOT return the answer to an A query until either an answer to the AAAA query has been received or the Resolution Delay has passed" If you think this resolves it, I may need to move the text relevant to "what is the resolution delay" to 5.2.2, to make it clearer. This may be in the actual 5.2.2 or a new section after that to be more explicit, something like "CE DNS proxy responses" ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Fri Jul 17 05:14:14 2020 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 A66873A09E5 for ; Fri, 17 Jul 2020 05:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSvsiqn_KOky for ; Fri, 17 Jul 2020 05:14:09 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3581A3A0AF1 for ; Fri, 17 Jul 2020 05:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1594988048; x=1595592848; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=PHomnAGSh175Lmdq7cZpTNLb3cT5KOSHEh472aoNjXc=; b=hMZFrkHgXkcPH7LffwC7LstQGLWAvnwmamlWNUCqfBQAwcKxSCuNyZWoSl8Osx Bvr3n4zOHYnIEZ5GFn1TwrioZjt45EVe409PDvecaJrKFedvLNlL4MNsSam7DJ8V p9r83umK/m8QuceNAPRC8rPVYVABzYQ1zaasrK3W97fio= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 14:14:08 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 14:14:07 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000291323.msg for ; Fri, 17 Jul 2020 14:14:05 +0200 X-MDRemoteIP: 2001:470:1f09:495:59c0:cc79:face:2a33 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Fri, 17 Jul 2020 14:14:05 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 14:14:04 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3677840044_1648140606" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 12:14:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3677840044_1648140606 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m thinking something else that may be very useful if we include i= n the EAMT entry a field for the source host that is using it, we may want = to create also another table (better than using the same table because we d= on=E2=80=99t need the other fields, so less memory is used) for those hosts= that are detected to be dual-stack. This will avoid delaying the AAAA quer= y from the A one (it will happen only if the table is empty). So, once a dual-stack host is detected, it will never get EAMT entries, and= HE is never broken. If this host suddenly becomes IPv4-only (corner case),= then nothing from that hosts will be optimized (except if we decide to add= an expiry time to the table of =E2=80=9Cdetected-dual-stack hosts=E2=80=9D= or the CE is rebooted). For example, if you disable IPv6 in the browser, i= t will still use 464XLAT as we do it today, no optimization, etc. A dual-stack host may be =E2=80=9Cwrongly=E2=80=9D classified, in corner ca= ses, as IPv4-only if a given app is using only IPv4 and doing only A querie= s and that will be optimized. However, this will be re-checked when the sam= e host tries to initiate a new connection to a new destination. The disadvantage is that then we don=E2=80=99t optimize any application fro= m that host, but I think this is a good thing as a conservative approach, i= t resolves some of the other issues and even keeps allowing troubleshooting= with IPv4 and IPv6, using literal IPv4 addresses, etc., etc. So only IPv4-only hosts will need to wait the Resolution Delay for every ne= w destination, to make sure if the destination is IPv6-enabled to create th= e EAMT entry. In the case of the hosts that we are trying to optimize (a Sm= artTV or STB), I don=E2=80=99t think it is a big issue, because usually is = running a single =E2=80=9Capp=E2=80=9D, so the delays introduced should not= have a user-noticeable impact. At the end the main goal of the optimization was to resolve the access from= *IPv4-only* devices such as old smartTVs/STBs, so I feel that disallowing = at all dual-stack hosts to take advantage of the optimization is a very goo= d trade-off. Thoughs? =20 =20 El 17/7/20 12:16, "v6ops en nombre de JORDI PALET MARTINEZ" escrib= i=C3=B3: =20 > 5.2.1 Detection of IPv4-only hosts or applications > It needs to be remarked that, if the detection of the IPv4-only > device or application is done incorrectly (either not detecting it > or by a false detection), no harm is caused. I'm not sure that "no harm is caused" is always the case. There may be harm due to cases such as a client no longer able to fall back to the IPv4 address it would have used in a Happy Eyeballs setup. (ie, connectivity is discussed extensively here, but application-level breakage due to some of the issues mentioned above may not be possible to recover from). [Jordi] Maybe is a matter of an alternative wording: =E2=80=9Cthe goal is t= hat no harm is caused=E2=80=9D. =20 Regarding HE, I think this is well explained in the updated 5.2..12. sectio= n. =20 One possible alternative if we want to keep HE working *at all means*, even= if it is worse than the optimization (which is very possible, because we a= re talking about IPv6-only access, so most probably if IPv6 is broken, IPv4= is broken as well), will be to add one more field in the EAMT entry: The I= Pv4 source address from the hosts in that network. Then we can ensure that = the EAMT entries are =E2=80=9Cper client=E2=80=9D and applied only to each = client and only to IPv4-only clients. So dual-stack clients will NOT use th= e optimization (in normal conditions they should prefer IPv6!). This small = change in the approach makes the optimization implementation a bit more com= plex, but being done by the CPE, still is preferable to the NAT64 unnecessa= ry overload. I think that this may also *resolve* many of the other issues = that I=E2=80=99m still reading from the list and even some security issues. =3D=3D=3D=3D=3D=3D=3D=3D=3D > 5.2.1 Detection of IPv4-only hosts or applications Will Android doing synchronous A/AAAA lookups break this detection? and does this impact other things like STBs built on Android? Android does one of the A or AAAA lookups, waits for it to return, then does the other. From the perspective of the CPE resolver, could look like an IPv4-only host and just always introduce the 50ms delay? Some more details may be needed here on the timing heuristics needed to detect various scenarios like this. =20 [Jordi] When a synchronous lookup is performed, then it is clear that the h= osts is IPv6 enabled (actually dual-stack), so the EAMT entry is not create= d. If the EAMT entry already exists, then it will be used only if the host = decides to prefer IPv4 instead of IPv6, which doesn=E2=80=99t look like a n= ormal behavior. To ensure it, we may need to double-check if the 50 ms. del= ay is still good for Android or it is too small. I don=E2=80=99t think it i= s a big issue to increase it. We could improve it, to avoid the delay, if w= e create an additional table for the =E2=80=9Calready known=E2=80=9D to be = dual-stack hosts. This may be also related to the new field in the EAMT tha= t I mention above. =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3677840044_1648140606 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I=E2=80= =99m thinking something else that may be very useful if we include in the E= AMT entry a field for the source host that is using it, we may want to crea= te also another table (better than using the same table because we don=E2= =80=99t need the other fields, so less memory is used) for those hosts that= are detected to be dual-stack. This will avoid delaying the AAAA query fro= m the A one (it will happen only if the table is empty).<= /p>

So, once a dual-stack = host is detected, it will never get EAMT entries, and HE is never broken. I= f this host suddenly becomes IPv4-only (corner case), then nothing from tha= t hosts will be optimized (except if we decide to add an expiry time to the= table of =E2=80=9Cdetected-dual-stack hosts=E2=80=9D or the CE is rebooted= ). For example, if you disable IPv6 in the browser, it will still use 464XL= AT as we do it today, no optimization, etc.

A dual-stack host may be =E2=80= =9Cwrongly=E2=80=9D classified, in corner cases, as IPv4-only if a given ap= p is using only IPv4 and doing only A queries and that will be optimized. H= owever, this will be re-checked when the same host tries to initiate a new = connection to a new destination.

The disadvantage is that then we don=E2=80=99t= optimize any application from that host, but I think this is a good thing = as a conservative approach, it resolves some of the other issues and even k= eeps allowing troubleshooting with IPv4 and IPv6, using literal IPv4 addres= ses, etc., etc.

So only IPv4-only hosts will need to wait the Resolution Delay = for every new destination, to make sure if the destination is IPv6-enabled = to create the EAMT entry. In the case of the hosts that we are trying to op= timize (a SmartTV or STB), I don=E2=80=99t think it is a big issue, because= usually is running a single =E2=80=9Capp=E2=80=9D, so the delays introduce= d should not have a user-noticeable impact.

At the end the main goal of the o= ptimization was to resolve the access from *IPv4-only* devices such = as old smartTVs/STBs, so I feel that disallowing at all dual-stack hosts to= take advantage of the optimization is a very good trade-off.

Thoughs?

&nb= sp;

 

El 17/7/20 12:16, "= ;v6ops en nombre de JORDI PALET MARTINEZ" <v6ops-bounces@ietf.org en nombre de jordi.palet=3D40consulintel= .es@dmarc.ietf.org> escribi=C3=B3:

 

=


> 5.2.1 Detection of IPv4-only hosts or applications
> It = needs to be remarked that, if the detection of the IPv4-only
> device or application is done incorrectly (either not detecting it
&g= t; or by a false detection), no harm is caused.

I'm not sure = that "no harm is caused" is always the case.
There may be harm= due to cases such as a client no longer
able to fall back to the IPv4 a= ddress it would have used
in a Happy Eyeballs setup.  (ie, connecti= vity is discussed extensively
here, but application-level breakage due t= o some of the issues
mentioned above may not be possible to recover from= ).


[Jordi] Maybe is a matter= of an alternative wording: =E2=80=9Cthe goal is that no harm is caused=E2= =80=9D.

 <= /p>

Regarding HE, I think this is well explained in the= updated 5.2..12. section.

 = ;

One possible alternative if we = want to keep HE working *at all means*, even if it is worse than the= optimization (which is very possible, because we are talking about IPv6-on= ly access, so most probably if IPv6 is broken, IPv4 is broken as well), wil= l be to add one more field in the EAMT entry: The IPv4 source address from = the hosts in that network. Then we can ensure that the EAMT entries are =E2= =80=9Cper client=E2=80=9D and applied only to each client and only to IPv4-= only clients. So dual-stack clients will NOT use the optimization (in norma= l conditions they should prefer IPv6!). This small change in the approach m= akes the optimization implementation a bit more complex, but being done by = the CPE, still is preferable to the NAT64 unnecessary overload. I think tha= t this may also *resolve* many of the other issues that I=E2=80=99m = still reading from the list and even some security issues.

<= br>=3D=3D=3D=3D=3D=3D=3D=3D=3D

> 5.2.1  Detection of IPv4-on= ly hosts or applications

Will Android doing synchronous A/AAAA looku= ps break this
detection?  and does this impact other things = like STBs built on
Android?  Android does one of the A or AAAA look= ups, waits for it
to return, then does the other.  From the perspec= tive of the CPE resolver,
could look like an IPv4-only host and just alw= ays introduce the 50ms delay?

Some more details m= ay be needed here on the timing heuristics needed
to detect various scen= arios like this.

 

[Jordi] When a synchronous lookup is perfo= rmed, then it is clear that the hosts is IPv6 enabled (actually dual-stack)= , so the EAMT entry is not created. If the EAMT entry already exists, then = it will be used only if the host decides to prefer IPv4 instead of IPv6, wh= ich doesn=E2=80=99t look like a normal behavior. To ensure it, we may need = to double-check if the 50 ms. delay is still good for Android or it is too = small. I don=E2=80=99t think it is a big issue to increase it. We could imp= rove it, to avoid the delay, if we create an additional table for the =E2= =80=9Calready known=E2=80=9D to be dual-stack hosts. This may be also relat= ed to the new field in the EAMT that I mention above.

=

 




<= /p>

 


**************************************= ********
IPv4 is over
Are you ready for the new Internet ?
http://= www.theipv6company.com
The IPv6 Company

This electronic message c= ontains information which may be privileged or confidential. The informatio= n is intended to be for the exclusive use of the individual(s) named above = and further non-explicilty authorized disclosure, copying, distribution or = use of the contents of this information, even if partially, including attac= hed files, is strictly prohibited and will be considered a criminal offense= . If you are not the intended recipient be aware that any disclosure, copyi= ng, distribution or use of the contents of this information, even if partia= lly, including attached files, is strictly prohibited, will be considered a= criminal offense, so you must reply to the original sender to inform about= this communication and delete it.

_________________________________= ______________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailm= an/listinfo/v6ops


********************************= **************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677840044_1648140606-- From nobody Fri Jul 17 08:05:16 2020 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 7BACC3A094B for ; Fri, 17 Jul 2020 08:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGjxL_nAgfxG for ; Fri, 17 Jul 2020 08:05:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE5D3A0A49 for ; Fri, 17 Jul 2020 08:05:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jwRvB-0000MVC; Fri, 17 Jul 2020 17:05:09 +0200 Message-Id: To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-reply-to: Your message of "Fri, 17 Jul 2020 13:03:03 +0200 ." Date: Fri, 17 Jul 2020 17:05:08 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 15:05:15 -0000 >[Jordi] Good point. May be: > >"The CE DNS proxy MUST NOT return the answer to an A query until either an answe >r to the AAAA query has been received or the Resolution Delay has passed" Yes, I think this is important. Otherwise small differences in DNS timing may cause hard to diagnose bugs. Another suggestion is that if the AAAA query either gets a timeout or SERVFAIL then any existing EAMT entry for the corresponding IPv4 address should be set to invalid. Then there is DNSSEC. For example, the AAAA lookup MUST/SHOULD/MAY be verified using DNSSEC local validation. (Or, the AD bit of the reply could be used instead). A reply that fails DNSSEC validation MUST/SHOULD/MAY not result in the creation of an EAMT entry (and MUST/SHOULD/MAY result in marking an exiting entry invalid) One question that doesn't seem answer, what if the upstream resolver is doing DNS64. In that case an AAAA query would get an answer for an IPv4-only service. Maybe it doesn't matter, because the mapping will be the same. Otherwise setting the CD flag in the query may help to get only 'real' AAAA records. From nobody Fri Jul 17 08:54:41 2020 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 5C2A03A07D7 for ; Fri, 17 Jul 2020 08:54:39 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDnlfLi_cDHs for ; Fri, 17 Jul 2020 08:54:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8468E3A0788 for ; Fri, 17 Jul 2020 08:54:35 -0700 (PDT) Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 92A3AF2B8843BD57E5BE; Fri, 17 Jul 2020 16:54:31 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 16:54:31 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 18:54:30 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 17 Jul 2020 18:54:30 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness Thread-Index: AQHWXBBfQd4WoMAlRH285zQQjJVud6kL6mmA Date: Fri, 17 Jul 2020 15:54:30 +0000 Message-ID: <19114aa217f443d0965f602269c432a7@huawei.com> References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> <75108EA5-62D2-43EF-BEBC-646737384F9C@consulintel.es> In-Reply-To: <75108EA5-62D2-43EF-BEBC-646737384F9C@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.202.92] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 15:54:39 -0000 SGkgSm9yZGksDQpJdCBpcyBldmVuIGxvbmdlciB0aGFuIEkgaGF2ZSBleHBlY3RlZC4gRmluZS4N Cg0KQnV0IGluIHNlcGFyYXRlIGRpc2N1c3Npb24geW91IGhhdmUgcHJvcG9zZWQgdG8gcHV0IHNv dXJjZSBJUHY0IGludG8gRUFNVCB0YWJsZSwNClRoYXQgd291bGQgYnJlYWsgbG9naWMgYmVsb3cg LSBpdCB3b3VsZCBub3QgYmUgcG9zc2libGUgYW55bW9yZSB0byBwaXBlbGluZSAyIGluZGVwZW5k ZW50IGVuZ2luZXM6IE5BUFQ0NCBhbmQgTkFUNDYuIEl0IHNob3VsZCBiZSBvbmUgc3RhdGVmdWwg ZW5naW5lLg0KTGV0J3Mgd2FpdCBmb3IgdGhlIGZpbmlzaCBvZiBvdGhlciBkaXNjdXNzaW9ucyAt IG1heSBiZSB5b3UgaGF2ZSB0byByZXR1cm4gdG8gNS4yLjQgYWdhaW4uDQoNCkVkdWFyZA0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQpTZW50OiAxNyDQ uNGO0LvRjyAyMDIwINCzLiAxMTowMQ0KVG86IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9u LTAyIC0gY29uY2VybiBvbiBzdGF0ZWZ1bG5lc3MNCg0KSGkgRWR1YXJkLA0KDQpMZXQgdXMga25v dyB3aGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGlzIHRlbnRhdGl2ZSBhbHRlcm5hdGl2ZSB0ZXh0 IHRvIHJlc29sdmUgdGhpcyBpc3N1ZToNCg0KNS4yLjQuICBGb3J3YXJkaW5nIHBhdGggdmlhIHN0 YXRlZnVsIE5BVCBmb3IgZXhpc3RpbmcgRUFNVCBlbnRyaWVzDQoNCiAgIEZvbGxvd2luZyB0aGlz IGFwcHJvYWNoLCBpZiB0aGVyZSBpcyBhIHZhbGlkIEVBTVQgZW50cnksIGZvciBhIGdpdmVuDQog ICBJUHY0LWRlc3RpbmF0aW9uLCB0aGUgSVB2Ni1uYXRpdmUgcGF0aCBwb2ludGVkIGJ5IHRoZSBJ UHY2IGFkZHJlc3Mgb2YNCiAgIHRoYXQgRUFNVCBlbnRyeSwgd2lsbCB0YWtlIHByZWNlZGVuY2Ug dmVyc3VzIHRoZSBOQVQ2NCBwYXRoLCBzbyB0aGUNCiAgIHRyYWZmaWMgd2lsbCBub3QgYmUgZm9y d2FyZGVkIHRvIHRoZSBOQVQ2NC4NCg0KICAgSG93ZXZlciwgdGhpcyBpcyBub3Qgc3VmZmljaWVu dCB0byBlbnN1cmUgdGhhdCBpbmRpdmlkdWFsDQogICBhcHBsaWNhdGlvbnMgYXJlIGFibGUgdG8g a2VlcCBleGlzdGluZyBjb25uZWN0aW9ucy4gIEluIG1hbnkgY2FzZXMsDQogICBhdWRpbyBhbmQg dmlkZW8gc3RyZWFtaW5nIG1heSB1c2UgYSBzaW5nbGUgVENQIGNvbm5lY3Rpb24gbGFzdGluZw0K ICAgZnJvbSBtaW51dGVzIHRvIGhvdXJzLiAgSW5zdGVhZCwgdGhlIENETiBUVExzIG1heSBiZSBj b25maWd1cmVkIGluDQogICB0aGUgcmFuZ2UgZnJvbSAxMCB0byAzMDAgc2Vjb25kcyBpbiBvcmRl ciB0byBhbGxvdyBuZXcgcmVzb2x1dGlvbnMgdG8NCiAgIHN3aXRjaCBxdWlja2x5IGFuZCB0byBo YW5kbGUgbGFyZ2UgcmVjdXJzaXZlIHJlc29sdmVycyAod2l0aCBodW5kcmVkcw0KICAgb2YgdGhv dXNhbmRzIG9mIGNsaWVudHMgYmVoaW5kIHRoZW0pLg0KDQogICBDb25zZXF1ZW50bHksIHRoZSBF QU1UIGVudHJpZXMgTVVTVCBOT1QgYmUgdXNlZCBkaXJlY3RseSB0byBlc3RhYmxpc2gNCiAgIGEg Zm9yd2FyZGluZyBwYXRoLCBidXQgaW5zdGVhZCwgTVVTVCBiZSB1c2VkIHRvIGNyZWF0ZSBhIHN0 YXRlZnVsIE5BVA0KICAgZW50cnkgZm9yIHRoZSA0LXR1cGxlIGZvciB0aGUgZHVyYXRpb24gb2Yg dGhlIHNlc3Npb24vY29ubmVjdGlvbi4NCiAgIFRoaXMgbWVhbnMgdGhhdCB0byBpbXBsZW1lbnQg dGhlIG9wdGltaXphdGlvbiB0aGUgTkFUNDYgTVVTVCBiZQ0KICAgc3RhdGVmdWwuICBUeXBpY2Fs bHksIHN0YXRlZnVsIE5BVDQ2IGFyZSBpbXBsZW1lbnRlZA0KICAgYnkgbWVhbnMgb2YgYSBzdGF0 ZWZ1bCBOQVQ0NCAod2hpY2ggb2Z0ZW4gbWF5YmUgaGFyZHdhcmUgb2ZmLWxvYWRlZCksDQogICBm b2xsb3dlZCBieSBhIHN0YXRlbGVzcyBOQVQ0Ni4gIElmIHRoZSBTb0MvY29kZSBpcyBhYmxlIHRv IGRvDQogICBzdGF0ZWxlc3MgTkFUNDYsIHRoaXMgc3RpbGwgY291bGQgYmUgdXNlZCB3aGVuIHRo ZSBvcHRpbWl6YXRpb24gaXMNCiAgIGRpc2FibGVkLg0KDQpOb3RlIHRoYXQgYWxzbyBmb2xsb3dp bmcgRXJpayBpbnB1dHMsIHRoZSB0ZXh0IGhhcyBtb3JlIG5vcm1hdGl2ZSBsYW5ndWFnZS4NCg0K QWxzbywgZm9yIHRoZSB0aXRsZSB3ZSB0aG91Z2h0IHRoYXQgaXQgd2lsbCBtYWtlIHNlbnNlOg0K NDY0WExBVC9NQVAtVCBPcHRpbWl6YXRpb24NCg0KTm8gbmVlZCB0byBtZW50aW9uIE5BVDY0LCB3 aGljaCBpcyBwYXJ0IG9mIHRoZSA0NjRYTEFULg0KICANClJlZ2FyZHMsDQpKb3JkaQ0KQGpvcmRp cGFsZXQNCiANCiANCg0K77u/RWwgMTUvNy8yMCAxNjoxOCwgInY2b3BzIGVuIG5vbWJyZSBkZSBK T1JESSBQQUxFVCBNQVJUSU5FWiIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgZW4gbm9tYnJlIGRl IGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+IGVzY3JpYmnDszoN Cg0KICAgIEkgdGhpbmsgeW91ciBwb2ludCB3aWxsIGJlIHRvIG1ha2UgaXQgY2xlYXIgaW4gdGhl IGRvY3VtZW50IHRoYXQgZm9yIHRoaXMgb3B0aW1pemF0aW9uIHRvIHdvcmssIHRoZSBDTEFUIHNo b3VsZCBiZSBzdGF0ZWZ1bD8NCg0KICAgIEkgdGhpbmsgaXMgdGhlcmUgKDUuMi40LiAgRm9yd2Fy ZGluZyBwYXRoIHZpYSBzdGF0ZWZ1bCBOQVQgZm9yIGV4aXN0aW5nIEVBTVQgZW50cmllcyksIGJ1 dCBJIHdpbGwgbWFrZSBzdXJlIHRvIGFkZCB0aGUgcmVsZXZhbnQgdGV4dCBpbiB0aGUgbmV4dCB2 ZXJzaW9uIHRvIG1ha2UgaXQgY2xlYXJlci4gDQoNCiAgICBJIGluc2lzdDogbW9zdCBvZiB0aGUg Q0xBVCBpbXBsZW1lbnRhdGlvbnMgdG9kYXkgKHJ1bm5pbmcgaW4gYm90aCBDUEVzIGFuZCBVRXMp IGFyZSBzdGF0ZWZ1bC4gQXQgbGVhc3QgdGhpcyBpcyB0aGUgZGF0YSBJJ3ZlLg0KDQogICAgUmVn YXJkcywNCiAgICBKb3JkaQ0KICAgIEBqb3JkaXBhbGV0DQoNCg0KDQogICAg77u/RWwgMTUvNy8y MCAxNTo1OSwgInY2b3BzIGVuIG5vbWJyZSBkZSBWYXNpbGVua28gRWR1YXJkIiA8djZvcHMtYm91 bmNlc0BpZXRmLm9yZyBlbiBub21icmUgZGUgdmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPiBl c2NyaWJpw7M6DQoNCiAgICAgICAgSGkgSm9yZGksDQogICAgICAgIEkgc3RpbGwgYmVsaWV2ZSB0 aGF0IHRvdWdoIChuZXcpIHJlcXVpcmVtZW50IHRoYXQgQ0xBVCBzaG91bGQgYmVjb21lIFN0YXRl ZnVsIChtYW5kYXRvcnkpDQogICAgICAgIE1ha2Ugc2Vuc2UgdG8gaW5zZXJ0IGludG8gdGhlIGRv Y3VtZW50Lg0KDQogICAgICAgIEFuZCBleHBsYW5hdGlvbiB3aHkgc3RhdGVmdWwgTkFQVCBpcyBu ZWVkZWQgd291bGQgYmUgZ29vZC4NCiAgICAgICAgSSBoYXZlIHNwZW50IHNvbWUgdGltZSB0byBy ZXNlYXJjaCB0aGlzIC0gaXQgaXMgYmV0dGVyIHRvIHNhdmUgdGltZSBvZiBvdGhlciBwZW9wbGUu DQogICAgICAgIEl0IGlzIGltcG9ydGFudCBwb2ludCB0aGF0IGlzIG9taXR0ZWQgaW4gdGhlIGRv Y3VtZW50Lg0KDQogICAgICAgIEZvciB0aGUgbmFtZTogSSBkbyBub3QgaGF2ZSBhbnkgc3Ryb25n IG9waW5pb24uDQogICAgICAgIEp1c3QgSSBzZWUgdGhhdCBkcmFmdCBpcyBhcHBsaWNhYmxlIG1v c3RseSB0byBNQVAtVCwNCiAgICAgICAgQW5kIG5vdCBtdWNoIGFwcGxpY2FibGUgdG8gWExBVCAo YmVjYXVzZSBtYWpvcml0eSBvZiBpbnN0YWxsYXRpb25zIGhhdmUgc3RhdGVsZXNzIENMQVQpLg0K ICAgICAgICBCdXQgdGhlIG5hbWUgbWlzbGVhZCB0byBvcHBvc2l0ZSBjb25jbHVzaW9uLg0KDQog ICAgICAgIEVkdWFyZA0KICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAg ICBGcm9tOiBKb3JkaSBQYWxldCBNYXJ0w61uZXogW21haWx0bzpqb3JkaS5wYWxldEB0aGVpcHY2 Y29tcGFueS5jb21dIA0KICAgICAgICBTZW50OiAxNSDQuNGO0LvRjyAyMDIwINCzLiAxNjo0OA0K ICAgICAgICBUbzogVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29t PjsgdjZvcHNAaWV0Zi5vcmcNCiAgICAgICAgQ2M6IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1v cHRpbWl6YXRpb25AaWV0Zi5vcmcNCiAgICAgICAgU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMiAtIGNvbmNlcm4g b24gc3RhdGVmdWxuZXNzDQoNCiAgICAgICAgSGkgVmFzaWxlbmtvLA0KDQogICAgICAgIFRoZSBp bXBsZW1lbnRhdGlvbnMgb2YgNDY0WExBVCwgY2FuIGRvIHRoZSBzYW1lIChhbmQgaW4gZmFjdCwg bWFueSBvZiB0aGVtIGlzIHdoYXQgdGhleSBkbykuIE5BVDQ0IHN0YXRlZnVsIGFuZCB0aGUgNDYg c3RhdGVsZXNzLiBNYW55IFNvQyBoYXZlIGVtYmVkZGVkIE5BVDQ0IGFjY2VsZXJhdGlvbiwgYnV0 IG5vdCBOQVQ0Niwgc28gdGhhdCBleHBsYWlucyBpdCBhcyB3ZWxsLg0KDQogICAgICAgIEkgZ3Vl c3MgdGhhdCBjb3VsZCBjbGVhciB5b3VyIGNvbmNlcm4/DQoNCiAgICAgICAgSSd2ZSBzZXZlcmFs IGN1c3RvbWVycyBkb2luZyA0NjRYTEFUIGluIGJyb2FkYmFuZCwgb25lIG9mIHRoZW0gMjUuMDAw LjAwMCBzdWJzY3JpYmVycy4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBpbiBkb2luZyA0NjRYTEFU IGluIGNlbGx1bGFyIGFuZCBicm9hZGJhbmQuDQoNCiAgICAgICAgV2hlbiB3ZSBzYXkgaW4gdGhl IHRpdGxlIDQ2NFhMQVQvTkFUNjQsIEkgdGhpbmsgYm90aCBhcmUgY292ZXJlZC4gQnV0IEkndmUg bm8gaXNzdWUgdG8gY2hhbmdlIHRoZSB0aXRsZSBpZiB0aGlzIG1ha2VzIHNlbnNlIHRvIG90aGVy cy4gV2UgY291bGQgZXhwbGljdGlseSBzYXkgNDY0WExBVC9OQVQ2NC9NQVAtVCBvciB3aGF0ZXZl ci4gVGhpcyBpcyBhIG1pbm9yIGRldGFpbCwgaW4gbXkgb3Bpbmlvbi4NCg0KICAgICAgICBSZWdh cmRzLA0KICAgICAgICBKb3JkaQ0KICAgICAgICBAam9yZGlwYWxldA0KDQoNCiAgICAgICAg77u/ RWwgMTUvNy8yMCAxNTo0MCwgIlZhc2lsZW5rbyBFZHVhcmQiIDx2YXNpbGVua28uZWR1YXJkQGh1 YXdlaS5jb20+IGVzY3JpYmnDszoNCg0KICAgICAgICAgICAgSGkgYWxsLA0KICAgICAgICAgICAg SSBoYXZlIGNvbmNlcm4gb24gdGhlIGNhcGFiaWxpdHkgdG8gdXNlIHRoaXMgbWVjaGFuaXNtIGZv ciA0NjRYTEFULCBidXQgaXQgc2hvdWxkIGJlIGZpbmUgZm9yIE1BUC1ULg0KDQogICAgICAgICAg ICBXZSBtYXkgaGF2ZSBtYW55IGhvc3RzIG9uIENQRSBMQU4uIFR5cGljYWxseSwgNzAlIG9mIEZC QiB0cmFmZmljIGlzIHN0aWxsIGRlc2lnbmF0ZWQgdG8gSVB2NCBzaXRlcy4NCiAgICAgICAgICAg IFNvdXJjZSBVRFAvVENQIHBvcnQgY29sbGlzaW9uIGlzIHN0aWxsIHZlcnkgcG9zc2libGUgKGku ZS4gYWN0aXZlIHNlc3Npb25zIGZyb20gZGlmZmVyZW50IGhvc3QgbWF5IGhhdmUgdGhlIHNhbWUg c291cmNlIFRDUC9VRFAgcG9ydCksDQogICAgICAgICAgICBJdCBpcyBub3Qgc3RhdGVkIGFueXdo ZXJlIGluIHRoZSBkb2N1bWVudCwgYnV0IHdlIG5lZWQgdG8gc3F1ZWV6ZSAoZm9yIHBhdGggdG8g SW50ZXJuZXQgaXQgd291bGQgYmUgInNvdXJjZSBJUCBhZGRyZXNzIikgbWFueSBwcml2YXRlIElQ djQgaG9zdHMgdG8gb25lIElQdjYgKGFzc2lnbmVkIGJ5IGNhcnJpZXIgdG8gQ1BFIHVwbGluayku DQogICAgICAgICAgICBDbGFzc2ljYWwgTjoxIHByb2JsZW0gdGhhdCBzaG91bGQgYmUgcmVzb2x2 ZWQgYnkgTkFQVCAocG9ydCB0cmFuc2xhdGlvbiBpcyBtYW5kYXRvcnkpLg0KDQogICAgICAgICAg ICBNQVAtVCBoYXMgTkFQVCBlbmdpbmUgb24gQ1BFIHNpZGUgLSBpdCBtYWtlIHNlbnNlIHRvIGNs ZWFybHkgc3RhdGUgaW4gdGhlIGRvY3VtZW50IHRoYXQgd2UgYXJlIGdvaW5nIHRvIHJldXNlIE5B UFQuIFRoZW4gdHJhbnNsYXRpb24gd291bGQgYmU6DQogICAgICAgICAgICAoMSkgTkFQVDQ0IGZv ciBtYW55IHByaXZhdGUgSVB2NCB0byBvbmUgcHVibGljIElQdjQgKHdlbGwsIGl0IGNvdWxkIGJl IG5vdCBwdWJsaWMsIGJ1dCBwdWJsaWMgQStQIGhhcyBiZWVuIGdpdmVuIHRvIE1BUCBDRSBhbnl3 YXkgLSBiZXR0ZXIgdG8gcmV1c2UgaXQgZm9yIHVuaWZpY2F0aW9uKQ0KICAgICAgICAgICAgKDIp IFNJSVQgKHdpdGggRUFNVCkgZm9yIHNpbmdsZSBJUHY0IHRvIHNpbmdsZSBJUHY2ICgxOjEpDQoN CiAgICAgICAgICAgIFhMQVQvQ0xBVCBkb2VzIGhhdmUgc3RhdGVmdWwgTkFQVCBieSBSRkMgNjg3 NywgYnV0IGl0IGlzIG5vdCBwb3B1bGFyIC0gbm90IGltcGxlbWVudGVkIGJ5IG1hbnkgY2Fycmll cnMgKGlmIGFueT8pLg0KICAgICAgICAgICAgSXQgd291bGQgYmUgdGhlIGJpZyBuZXdzIHRoYXQg Q2FycmllcnMgc2hvdWxkIGNob29zZSBzdGF0ZWZ1bCBDTEFUIG9wdGlvbiBmb3IgNDY0WExBVC4N CiAgICAgICAgICAgIEl0IGlzIGJldHRlciB0byB0ZWxsIHRoZW0gdXBmcm9udC4NCg0KICAgICAg ICAgICAgVGhlIG5leHQgcXVlc3Rpb24gY291bGQgYmU6IGRvZXMgaXQgbWFrZSBzZW5zZSB0byB1 c2UgU3RhdGVsZXNzIENMQVQgZm9yIGJhc2ljIDQ2NFhMQVQgYW5kIFN0YXRlZnVsIENMQVQgZm9y IHRyYWZmaWMgb3B0aW1pemF0aW9uIHRvIElQdjQgc2l0ZXM/DQogICAgICAgICAgICBPciBpdCBp cyBiZXR0ZXIgdG8gdW5pZnkgb24gU3RhdGVmdWwgQ0xBVCBmb3IgZXZlcnl0aGluZy4NCg0KICAg ICAgICAgICAgSW4gZ2VuZXJhbCwgaXQgaXMgYSByZXZvbHV0aW9uIGZvciA0NjRYTEFULiBCdXQg aXQgaXMgc21vb3RoIGV4cGFuc2lvbiBmb3IgTUFQLVQuDQogICAgICAgICAgICBIZW5jZSwgZG9l cyBpdCBtYWtlIHNlbnNlIHRvIGNoYW5nZSB0aGUgbmFtZSBvZiB0aGlzIGRyYWZ0IHRvIHJlZmxl Y3QgTUFQLVQgYXMgdGhlIHByaW1hcnkgdGFyZ2V0Pw0KDQogICAgICAgICAgICBFZHVhcmQNCiAg ICAgICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgICAgICAgICBGcm9tOiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcNCiAgICAgICAgICAgIFNlbnQ6IDExINC40Y7Qu9GPIDIwMjAg0LMu IDE1OjM0DQogICAgICAgICAgICBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQogICAgICAgICAg ICBDYzogdjZvcHNAaWV0Zi5vcmcNCiAgICAgICAgICAgIFN1YmplY3Q6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMi50eHQNCg0KDQog ICAgICAgICAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgICAgICAgICBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE9wZXJhdGlvbnMgV0cgb2YgdGhlIElFVEYuDQoN CiAgICAgICAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogNDY0WExBVC9OQVQ2NCBPcHRp bWl6YXRpb24NCiAgICAgICAgICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogSm9yZGkgUGFs ZXQgTWFydGluZXoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxlamFu ZHJvIEQnRWdpZGlvDQogICAgICAgICAgICAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi12 Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMi50eHQNCiAgICAgICAgICAgIAlQYWdlcyAgICAg ICAgICAgOiAyMQ0KICAgICAgICAgICAgCURhdGUgICAgICAgICAgICA6IDIwMjAtMDctMTENCg0K ICAgICAgICAgICAgQWJzdHJhY3Q6DQogICAgICAgICAgICAgICBJUC9JQ01QIFRyYW5zbGF0aW9u IEFsZ29yaXRobSAoU0lJVCkgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBhY2Nlc3MNCiAgICAgICAg ICAgICAgIGZvciBJUHY0LW9ubHkgZGV2aWNlcyBvciBhcHBsaWNhdGlvbnMgdG8gSVB2NC1vbmx5 IG9yIGR1YWwtc3RhY2sNCiAgICAgICAgICAgICAgIGRlc3RpbmF0aW9ucyBvdmVyIElQdjYtb25s eSBpbmZyYXN0cnVjdHVyZS4gIEluIHRoYXQgY2FzZSwgdGhlDQogICAgICAgICAgICAgICB0cmFm ZmljIGZsb3dzIGFyZSB0cmFuc2xhdGVkIHR3aWNlOiBmaXJzdCBmcm9tIElQdjQgdG8gSVB2Ng0K ICAgICAgICAgICAgICAgKHN0YXRlbGVzcyBOQVQ0NiBhdCB0aGUgaW5ncmVzcyBwb2ludCB0byB0 aGUgSVB2Ni1vbmx5DQogICAgICAgICAgICAgICBpbmZyYXN0cnVjdHVyZSkgYW5kIHRoZW4gZnJv bSBJUHY2IGJhY2sgdG8gSVB2NCAoc3RhdGVmdWwgTkFUNjQsIGF0DQogICAgICAgICAgICAgICB0 aGUgZWdyZXNzIHBvaW50KS4gIFdoZW4gdGhlIGRlc3RpbmF0aW9uIGlzIElQdjYtZW5hYmxlZCwg dGhlIHNlY29uZA0KICAgICAgICAgICAgICAgdHJhbnNsYXRpb24gbWlnaHQgYmUgYXZvaWRlZC4g IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcG9zc2libGUNCiAgICAgICAgICAgICAgIG9wdGlt aXphdGlvbiB0byA0NjRYTEFUIGFuZCBNQVAtVCB0byBhdm9pZCB0cmFuc2xhdGluZyBJUHY2IGZs b3dzDQogICAgICAgICAgICAgICBiYWNrIHRvIElQdjQgaWYgdGhlIGRlc3RpbmF0aW9uIGlzIHJl YWNoYWJsZSBvdmVyIElQdjYuICBUaGUgcHJvcG9zZWQNCiAgICAgICAgICAgICAgIHNvbHV0aW9u IHdvdWxkIHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSBOQVQ2NCB1dGlsaXphdGlvbiBpbiB0aGUN CiAgICAgICAgICAgICAgIG9wZXJhdG9yJ3MgbmV0d29yay4NCg0KDQogICAgICAgICAgICBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtNDY0 eGxhdC1vcHRpbWl6YXRpb24vDQoNCiAgICAgICAgICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyDQogICAgICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZv cHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDINCg0KICAgICAgICAgICAgQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6 YXRpb24tMDINCg0KDQogICAgICAgICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNCiAgICAgICAgICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCiAgICAgICAgICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQoNCg0KICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICAgICAgICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgICAgICAg ICAgdjZvcHNAaWV0Zi5vcmcNCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCg0KDQoNCiAgICAgICAgKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KICAgICAgICBJUHY0IGlzIG92ZXINCiAgICAgICAgQXJl IHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQogICAgICAgIGh0dHA6Ly93d3cudGhl aXB2NmNvbXBhbnkuY29tDQogICAgICAgIFRoZSBJUHY2IENvbXBhbnkNCg0KICAgICAgICBUaGlz IGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJp dmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBi ZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUg YW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5n LCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9u LCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRp c2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9m IHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQg ZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1p bmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8g aW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KDQoNCg0KICAg ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICAgICAgdjZvcHNAaWV0Zi5vcmcNCiAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCg0KICAgICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgICBJUHY0IGlz IG92ZXINCiAgICBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCiAgICBodHRw Oi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0KICAgIFRoZSBJUHY2IENvbXBhbnkNCg0KICAgIFRo aXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRv IGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92 ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlp bmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRp b24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2Uu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkg ZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMg b2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hl ZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3Jp bWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0 byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQoNCg0KDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICB2 Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICB2Nm9wc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQoNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCklQdjQgaXMgb3Zlcg0KQXJlIHlvdSByZWFkeSBm b3IgdGhlIG5ldyBJbnRlcm5ldCA/DQpodHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0KVGhl IElQdjYgQ29tcGFueQ0KDQpUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1h dGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1h dGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXpl ZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQg YSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5 LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwg YmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRo ZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQg ZGVsZXRlIGl0Lg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Fri Jul 17 08:57:49 2020 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 8915D3A07E2 for ; Fri, 17 Jul 2020 08:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAq8k2VKH_8z for ; Fri, 17 Jul 2020 08:57:46 -0700 (PDT) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA1C3A07E5 for ; Fri, 17 Jul 2020 08:57:45 -0700 (PDT) Received: by mail-wm1-f51.google.com with SMTP id 17so17892465wmo.1 for ; Fri, 17 Jul 2020 08:57:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=De3gY5SAJ2Qzi2hFgZQ8Z9k7uJ9WdxjISIItWsJojO8=; b=XmawKXRhC3nKUNyVKO3nFoLAbhGr4FYjI6r9cSifhgFnwFzWKPTgsO/frNUFR++4Mw D9J88/Ied25WmGHGxMl/tYhhvPPAGCAWmgf2yaXEzYG5ZoC+GABxgnybJqlGllYjwzlV LKiFEspjqEBbeophpDLesbHrL+t81s55qfd2XHvqEmSOirRFZDH0GJRgmoGKts1Zu0ns FbwV/68sAiLcF2IXeIiAL4vpBkN9Mubpn7vypU5zbbf4aMDaWquWwhRRG3MKi4z09wqE ZgmmCJ24beuCpVsDt6AUvZGxi82ffV53a5D04BEPwfgV76NROqOv2TEoK9EwRr2/ZFtR kYAA== X-Gm-Message-State: AOAM532Y3+CC67b6ci5ibHRdWIKlKs+hfaZMVApJ/V3UFdNfalL25qDj N7tdCFJyOs2vEq3uRs3X3GewsTqdokPLTJwmALI= X-Google-Smtp-Source: ABdhPJxdEhY7+S9QvcFfwLnpZ/zoXw0BKpRJEE9DIE3YpIXVaprzLOJeCe/kQ/nawaZ/CH/2fKKp8P0LElOGn7FP2Ds= X-Received: by 2002:a1c:e383:: with SMTP id a125mr10156496wmh.11.1595001464117; Fri, 17 Jul 2020 08:57:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Nygren Date: Fri, 17 Jul 2020 11:57:32 -0400 Message-ID: To: JORDI PALET MARTINEZ Cc: V6 Ops List Content-Type: multipart/alternative; boundary="000000000000af62f805aaa537e9" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 15:57:49 -0000 --000000000000af62f805aaa537e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At the high-level, not causing problems relies heavily on assumptions about client behavior, both for STBs/SmartTVs as well as for other devices in the home. If the EAMT entries also contained the internal client IPv4 address then it might make it so that at least devices couldn't interfere with each other, but absent that there is also plenty of possibility for wacky interactions. The more we look for corner-cases that will cause production problems, the more I suspect we'll find. On some of the assumptions: * We know clients cache DNS lookups for some amount of time past their TTL. (ie, a client will do a "gethostbyname" and then just keep using the result for multiple connections). CDNs have to mostly deal with this (eg, wait a few hours after removing an IP from being handed out before assuming the rate of new connections drops to an acceptable level). I suspect some of the STBs/SmartTVs may be particularly bad about this (eg, within a viewing session). This generally works fine today and no one notices. But if entries drop out of the EAMT cache after 20 seconds but clients keep using them for 15 minutes, then it is likely another lookup for another hostname (perhaps from another device) would have created another EAMT entry that would have marked the first invalid but doesn't see it due to the early expiry. Keeping EAMT entries in a "stale" state for some amount of time following TTL expiry (an hour or two?) where they can't be used but can be transitioned to invalid and also kept in invalid for an hour or two would help. The question is whether this is too much state and if it would help enough. * The problem with the "user changes DNS" is that it is not just the user. There are plenty of devices in the field that do this today, including SmartTV/STB platforms but also desktops/laptops. In-particular, Chromecast-based devices (a major STB platform) use their own resolver of 8.8.8.8 and 8.8.4.4. It would not surprise me (but I haven't tested) that Chromecast does synchronous A/AAAA lookups in a way that may break the "IPv4-only detection". Apple has also announced that starting this Fall, apps will be able specify a DoH server to use (and it's possible this might apply to AppleTV as well?). Chrome and Firefox also now use DoH servers outside of the home in a bunch of places. The whole DoH/ADD situation has gotten very messy in the past year. If one dual-stacked device in the home using Do= H get requests for IPv4-only sites hijacked and sent to an IPv6 address, that's going to be a real problem. Keying the EAMT entry by client IP might help, but won't help in the iOS/OSX case where apps can specify their own DoH server. More comments inline below on topics not covered above... On Fri, Jul 17, 2020 at 5:40 AM JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > [Jordi] My goal has been to ensure that the optimization doesn=E2=80=99t = break any > case, and especially when the site only offers A records. Unless I=E2=80= =99m > missing something, I think this is perfectly resolved in 5.2.2, because t= he > EAMT entry will be only created if the site is only IPv4-only. > [Erik] Ah, I think the invariant here is that DNS64 will always guarantee that *everything* has a AAAA record available to the CPE resolver. If there are ever cases where no AAAA is returned (eg, where the CLAT would get used) then problems can show up because "IPv4-only" (no AAAA record) entries won't be validated against the EAMT table and won't cause EAMT entries to get created. It may be that we should be creating "invalid" EAMT entries for {IPv4,FQDN} pairs where no AAAA is returned. Also, we should be invalidating EAMT entries when an IPv4 address in an EAMT entry is returned for a different FQDN. > * some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address fo= r > demuxing IPv6 traffic (both to determine which cert to serve). This > means that the IPv4:IPv6 associations are one to many and using the wrong > one will result in cert errors. > > > > [Jordi] This was discussed in a previous version (I recall it was after > the presentation in Prague) and resolved by incorporating the FQDN in the > EAMT entry and a section 5.2.4, which forces the forwarding path via a > stateful NAT44. > > * Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one > customer/tenant, but then cluster A for IPv4 and cluster C for a differen= t > customer/tenant. An stale or invalid association will result in going to > the wrong cluster which may not be able to serve the request properly. > > [Jordi] Same as the previous one. Because the EAMT entry is created by > every CE, the association between a given IPv4 and IPv6 FQDN/addresses is > done the same way as if the same CE is actually dual-stack instead of > IPv6-only. If I got it correctly, in a CDN, any change in terms of what > cluster is serving what, depends on DNS TTLs and maybe routing, right? If > that=E2=80=99s the case, routing is transparent because the entries are c= reated in > each CE, and to the CDN they appear as a dual-stack eyeball. Similarly, w= e > rely in the CDN provided TTLs. > [Erik] My question for both of these is if we should provide some context or examples in the doc to explain the invariants and things that must be tested for? While these conversations happened on-list, having summaries of the risks (and what is being relied on to mitigate them) seems like it may be valuable in an Informational draft. Another area not discussed is clients caching DNS lookups well past > their TTL. This is fairly common in some clients (eg, some Java versions= ) > which could result in entries getting expired from the EAMT but then used > with a new association that should be invalid but wasn't detected as such > as the first client is caching well past the expiry.. > > [Jordi] I=E2=80=99m confused here. > > > > You mean a client ignoring DNS TTLs ? This could actually be a problem > without the optimization. If the CDN is changing the IPv4 or IPv6 > addresses, but the client is still using them, the content will be > unreachable or something different served, right? So, the optimization is > not the problem here it is a broken client already =E2=80=A6 > > > > Note that if the EAMT expired and the client tries to use it again, the > EAMT entry will be re-created with the new (correct) information from the > CDN DNSs, so we may be potentially solving the broken client problem. If > the EAMT, for whatever reason is not recreated, the optimization will not > be used, so the client will be still doing the =E2=80=9Ccorrect=E2=80=9D = thing according to > its expected behavior (non-optimized NAT46+NAT64) =E2=80=93 whether it is= a broken > behavior or not. > The case is: 1) a.example.com (TTL 20s) is resolved but cached by App A for 30 minutes 2) Five minutes later, b.example.com is resolved (TTL 600s) is resolved an EAMT entry is created (but shares an IPv4 address with a.example.com but a different IPv6 address) 3) Two minutes later, the IPv4 address from a.example.com gets used (past the DNS TTL) and will now use the IPv6 EAMT entry for b.example.com (which breaks). Does this help clarify? While you could argue this client is 'broken", anecdotal experience is that this is a very common behavior for some client software that servers already need to work around by padding operational actions for an hour or two past the DNS TTL. Erik --000000000000af62f805aaa537e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the high-level, not causing problems relies = heavily on assumptions about client behavior,
both for STBs/SmartTVs as well= as for other devices in the home.=C2=A0 If the EAMT entries
also contained = the internal client IPv4 address then it might make it so that
at least devi= ces couldn't interfere with each other, but absent that there is also
pl= enty of possibility for wacky interactions.=C2=A0 The more we look for corn= er-cases
that will cause production problems, the more I suspect we'll f= ind.
On some of the assumptions:

* We know clients cache DNS lookups for = some amount of time past their TTL.
=C2=A0=C2=A0 (ie, a client will do a &qu= ot;gethostbyname" and then just keep using the result
=C2=A0=C2=A0 for= multiple connections).=C2=A0 CDNs have to mostly deal with this (eg, wait = a few
=C2=A0 hours after removing an IP from being handed out before as= suming the rate
=C2=A0 of new connections drops to an acceptable level).=C2= =A0 I suspect some of the STBs/SmartTVs
=C2=A0 may be particularly bad about= this (eg, within a viewing session).=C2=A0
=C2=A0 This generally works= fine today and no one notices.=C2=A0 But if entries drop
=C2=A0 out of= the EAMT cache after 20 seconds but clients keep using them
=C2=A0 for= 15 minutes, then it is likely another lookup for another hostname
=C2=A0 (p= erhaps from another device) would have created another EAMT entry
=C2=A0 tha= t would have marked the first invalid but doesn't see it due to the ear= ly expiry.
=C2=A0 Keeping EAMT entries in a "stale" state for some= amount of time following TTL expiry
=C2=A0 (an hour or two?) where they can= 't be used but can be transitioned to invalid
=C2=A0 and also kept = in invalid for an hour or two would help.=C2=A0 The question is whether
=C2= =A0 this is too much state and if it would help enough.

* The problem wi= th the "user changes DNS" is that it is not just the user.
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">=C2=A0= =C2=A0 There are plenty of devices in the field that do this today, includi= ng
=C2=A0=C2=A0 SmartTV/STB platforms but also desktops/laptops.
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">=C2=A0= =C2=A0 In-particular, Chromecast-based devices (a major STB platform)
<= /div>
= =C2=A0=C2=A0 use their own resolver of 8.8.8.8 and 8.8.4.4.
=C2=A0=C2=A0 It = would not surprise me (but I haven't tested) that Chromecast does
=
=C2=A0= =C2=A0 synchronous A/AAAA lookups in a way that may break the "IPv4-on= ly detection".
=C2=A0=C2=A0 Apple has also announced that starting = this Fall, apps will be able
=C2=A0=C2=A0 specify a DoH server to use= (and it's possible this might apply to AppleTV as well?).
=C2=A0=C2=A0 = Chrome and Firefox also now use DoH servers outside of the home
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">=C2=A0= =C2=A0 in a bunch of places.=C2=A0 The whole DoH/ADD situation has gotten v= ery
=C2=A0=C2=A0 messy in the past year.=C2=A0 If one dual-stacked device in= the home using DoH
=C2=A0=C2=A0 get requests for IPv4-only sites hijacked a= nd sent to an IPv6 address,
=C2=A0=C2=A0 that's going to be a real probl= em.=C2=A0=C2=A0=C2=A0 Keying the EAMT entry by client IP might
=C2=A0=C2=A0 = help, but won't help in the iOS/OSX case where apps can specify
=C2= =A0=C2=A0 their own DoH server.

More comments inline below on topics= not covered above...


On Fri, Jul 17, 2020 at 5:40 AM JORDI PALET = MARTINEZ <jordi.palet@cons= ulintel.es> wrote:

[Jordi] My goal has been= to ensure that the optimization doesn=E2=80=99t break any case, and especi= ally when the site only offers A records. Unless I=E2=80=99m missing someth= ing, I think this is perfectly resolved in 5.2.2, because the EAMT entry wi= ll be only created if the site is only IPv4-only.

<= /div>

[Erik]=C2=A0 Ah, I think = the invariant here is that DNS64 will always guarantee that *everything* ha= s a AAAA record
available to the CPE resolver.=C2=A0 If there are ever cases= where no AAAA is returned (eg, where the CLAT would get used)
then problems= can show up because "IPv4-only" (no AAAA record) entries won'= ;t be validated against the EAMT table
and won't cause EAMT entries to g= et created.=C2=A0 It may be that we should be creating "invalid" = EAMT entries
for {IPv4,FQDN} pairs where no AAAA is returned.=C2=A0 A= lso, we should be invalidating EAMT entries
when an IPv4 address in an = EAMT entry is returned for a different FQDN.


= =C2=A0

* some = CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address for demuxin= g IPv6 traffic (both to determine which cert to serve).=C2=A0 This m= eans that the IPv4:IPv6 associations are one to many and using the wrong on= e will result in cert errors.

=C2=A0

[Jordi] This was discuss= ed in a previous version (I recall it was after the presentation in Prague)= and resolved by incorporating the FQDN in the EAMT entry and a section 5.2= .4, which forces the forwarding path via a stateful NAT44.

=
=C2=A0

* Some CDNs may use cluster A for IPv4 and clu= ster B for IPv6 for one customer/tenant, but then cluster A for IPv4 and cl= uster C for a different customer/tenant.=C2=A0 An stale or invalid a= ssociation will result in going to the wrong cluster which may not be able = to serve the request properly.

[Jordi] Same as the previ= ous one. Because the EAMT entry is created by every CE, the association bet= ween a given IPv4 and IPv6 FQDN/addresses is done the same way as if the sa= me CE is actually dual-stack instead of IPv6-only. If I got it correctly, i= n a CDN, any change in terms of what cluster is serving what, depends on DN= S TTLs and maybe routing, right? If that=E2=80=99s the case, routing is tra= nsparent because the entries are created in each CE, and to the CDN they ap= pear as a dual-stack eyeball. Similarly, we rely in the CDN provided TTLs.<= /span>


[Erik]=C2=A0 My question for both of these is if we should provide some co= ntext or examples in the doc
to explain the invariants and things that must = be tested for?=C2=A0 While these conversations happened on-list,
having summ= aries of the risks (and what is being relied on to mitigate them) seems lik= e it may be valuable
in an Informational draft.


=

Another area not di= scussed is clients caching DNS lookups well past
their TTL.=C2=A0 This is fairly common in some clients (eg, some Java versions)
which co= uld result in entries getting expired from the EAMT but then used
with a= new association that should be invalid but wasn't detected as such
= as the first client is caching well past the expiry..

=

[J= ordi] I=E2=80=99m confused here.

=C2=A0

You mean a client ignoring DNS TTLs ? This could actually be a problem wit= hout the optimization. If the CDN is changing the IPv4 or IPv6 addresses, b= ut the client is still using them, the content will be unreachable or somet= hing different served, right? So, the optimization is not the problem here = it is a broken client already =E2=80=A6

=C2=A0<= /u>

Note that if the EAMT expired and the client tries to use it again,= the EAMT entry will be re-created with the new (correct) information from = the CDN DNSs, so we may be potentially solving the broken client problem. I= f the EAMT, for whatever reason is not recreated, the optimization will not= be used, so the client will be still doing the =E2=80=9Ccorrect=E2=80=9D t= hing according to its expected behavior (non-optimized NAT46+NAT64) =E2=80= =93 whether it is a broken behavior or not.


The case is:

1) a.example.com (TTL 20s) is resolved but cached by App A for 30 minute= s
2) Five minutes later, b.example.com = is resolved (TTL 600s) is resolved an EAMT entry is created
=C2=A0=C2= =A0 (but shares an IPv4 address with a.exa= mple.com but a different IPv6 address)
3) Two minutes later, the IPv= 4 address from a.example.com gets used= (past the DNS TTL)
=C2=A0=C2=A0=C2=A0=C2=A0 and will now use the IPv6 = EAMT entry for b.example.com (which br= eaks).

Does this help clarify?=C2=A0 While you could argue this client i= s 'broken", anecdotal experience
is that this is a very common beha= vior for some client software that servers already
need to work around by pa= dding operational actions for an hour or two past the DNS TTL.

=C2=A0=C2= =A0=C2=A0=C2=A0 Erik


--000000000000af62f805aaa537e9-- From nobody Fri Jul 17 12:19:48 2020 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 6E2C33A07A2 for ; Fri, 17 Jul 2020 12:19:46 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iECAEXhZWI0 for ; Fri, 17 Jul 2020 12:19:44 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C036E3A079E for ; Fri, 17 Jul 2020 12:19:44 -0700 (PDT) Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DFF586B8E94B123EA97D; Fri, 17 Jul 2020 20:19:41 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 20:19:41 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 22:19:40 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 17 Jul 2020 22:19:40 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration Thread-Index: AdZcbcA6ExEyPlrQR6qUbzYTEusxMw== Date: Fri, 17 Jul 2020 19:19:40 +0000 Message-ID: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.202.92] Content-Type: multipart/alternative; boundary="_000_1a0f8217382048eb8329424c5b3f79f9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 19:19:47 -0000 --_000_1a0f8217382048eb8329424c5b3f79f9huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQpIb3cgQ2FycmllciB3b3VsZCBrbm93IHRoYXQgdXNlciBoYXMgYnJvdWdodCBh ZGRpdGlvbmFsIGRldmljZSAoVFYgZm9yIGV4YW1wbGUpIHRvIGhpcyByZXNpZGVuY2U/DQpPciBs ZXTigJlzIGFzayBpbiBzaW1wbGVyIGZvcm06IGhvdyBDYXJyaWVyIHdvdWxkIGtub3cgaG93IG1h bnkgU3R1cGlkVFZzIChJUHY0IG9ubHkpIHVzZXIgYWxyZWFkeSBoYXZlPw0KV2hhdCB0byBwcm9n cmFtIGluIGNlbnRyYWxpemVkIElUIHN5c3RlbT8NCklNSE86IHRoZSB3aG9sZSBBcHByb2FjaCAj MyAoY2xhdXNlIDUuMykgZG9lcyBub3QgbWFrZSBzZW5zZS4NCldvdWxkIHlvdSBhZ3JlZSB0byBk ZWxldGUgaXQ/DQpBcyB5b3UgbWVudGlvbmVkIGluIHRoZSBkcmFmdDogSXQgaXMgdXNlbGVzcyBh bnl3YXkgd2l0aG91dCBwcm90b2NvbCB0byB1cGxvYWQgRUFNVC4NCkVkdWFyZA0KDQo= --_000_1a0f8217382048eb8329424c5b3f79f9huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvcmRpLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+SG93IENhcnJpZXIgd291 bGQga25vdyB0aGF0IHVzZXIgaGFzIGJyb3VnaHQgYWRkaXRpb25hbCBkZXZpY2UgKFRWIGZvciBl eGFtcGxlKSB0byBoaXMgcmVzaWRlbmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+T3IgbGV04oCZcyBhc2sgaW4gc2ltcGxlciBmb3JtOiBob3cgQ2FycmllciB3 b3VsZCBrbm93IGhvdyBtYW55IFN0dXBpZFRWcyAoSVB2NCBvbmx5KSB1c2VyIGFscmVhZHkgaGF2 ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgdG8gcHJv Z3JhbSBpbiBjZW50cmFsaXplZCBJVCBzeXN0ZW0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmIj5JTUhPOiB0aGUgd2hvbGUgQXBwcm9hY2ggIzMgKGNsYXVzZSA1LjMp IGRvZXMgbm90IG1ha2Ugc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5Xb3VsZCB5b3UgYWdyZWUgdG8gZGVsZXRlIGl0PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+QXMgeW91IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQ6IEl0 IGlzIHVzZWxlc3MgYW55d2F5IHdpdGhvdXQgcHJvdG9jb2wgdG8gdXBsb2FkIEVBTVQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5FZHVhcmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_1a0f8217382048eb8329424c5b3f79f9huaweicom_-- From nobody Fri Jul 17 13:25:36 2020 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 2AF143A08B6 for ; Fri, 17 Jul 2020 13:25:34 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbdm9AGFzA_P for ; Fri, 17 Jul 2020 13:25:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 94F1B3A08AC for ; Fri, 17 Jul 2020 13:25:31 -0700 (PDT) Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9B575B56A2A9C146ACE0; Fri, 17 Jul 2020 21:25:29 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 21:25:29 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 17 Jul 2020 23:25:28 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 17 Jul 2020 23:25:28 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals Thread-Index: AdZcdd5aW2KjixhYTwqkJPfQUrMFfQ== Date: Fri, 17 Jul 2020 20:25:28 +0000 Message-ID: <8c749e34e6ba49b9afbf5899b70cbcbe@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.202.92] Content-Type: multipart/alternative; boundary="_000_8c749e34e6ba49b9afbf5899b70cbcbehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 20:25:34 -0000 --_000_8c749e34e6ba49b9afbf5899b70cbcbehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQpTb3JyeSB0byBvdmVybG9hZCB5b3UgYWdhaW4uDQpFcmlrIGFuZCBKZW4gd2Vy ZSByaWdodDogZHJhZnQgZG9lcyBpbnRyb2R1Y2UgbmV3IGF0dGFjayB2ZWN0b3JzLiBCZWNhdXNl IGhvc3RzIGFyZSDigJxzaGFyaW5nIHNlY3VyaXR5IGZhdGXigJ0g4oCTIHRoZXkgaGF2ZSBwcm92 ZWQgaXQgaW4gbWFueSBleGFtcGxlcy4gTGV04oCZcyBkaXNqb2luIGhvc3RzIGJhY2suDQoNCg0K DQoxLiAgICAgSSBwcm9wb3NlIHRvIHN0b3AgdGhpcyBndWVzcy13b3JrIHdobyBpcyBJUHY0LW9u bHkgYW5kIHdobyBpcyBub3QuIEROUyBxdWVyeSB0aW1lb3V0IHN5bmNocm9uaXphdGlvbiBiZXR3 ZWVuIEhhcHB5IEV5ZWJhbGwgb2YgcGFydGljdWxhciBob3N0IGltcGxlbWVudGF0aW9uIGFuZCBD TEFULU5HIChDTEFUIE5leHQgR2VuZXJhdGlvbikg4oCTIGlzIGEgdmVyeSByZWxpYWJsZSBwYXRo IHRvIGRpc2FzdGVyLiBXaGF0IGlmIHNvbWVib2R5IHdvdWxkIGNoYW5nZSB0aGlzIHRpbWVvdXQg aW4gbmV4dCBzb2Z0d2FyZSByZWxlYXNlPyBXaGF0IGlmIHRpbWVvdXQgYXJlIHZlcnkgZGlmZmVy ZW50IG9uIGN1cnJlbnQgaG9zdHM/IChJIGFtIHN1cmUgYWJvdXQgQW5kcm9pZCBhbmQgaU9TIGRp ZmZlcmVuY2UpDQpJIHByb3Bvc2UganVzdCB0byBsb29rIHRvIE5EIGFuZCBBUlAgY2FjaGVzOiBp ZiBwYXJ0aWN1bGFyIE1BQyBoYXMgb25seSBiaW5kaW5nIHRvIElQdjQgYW5kIHRoZSBzYW1lIE1B QyBkb2VzIG5vdCBoYXZlIGJpbmRpbmcgdG8gSVB2NiwgdGhlbiBpdCBpcyBvdXIg4oCcb3B0aW1p emF0aW9uIGNhc2XigJ0uDQoNCjIuICAgICBOQVBUNDQgZG9lcyBnZW5lcmF0ZSBtYW55IGlzc3Vl cyB0aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBvbiB0aGlzIG1haWxpbmcgbGlzdC4NCkkgcHJvcG9z ZSB0byByZXR1cm4gdG8gc3RhdGVsZXNzIG5hdHVyZSBvZiBDTEFULiBMZXTigJlzIGNyZWF0ZSBz ZXBhcmF0ZSBFQU1UIHRhYmxlIHBlciBldmVyeSBJUHY0LW9ubHkgaG9zdCAodGhhdCBoYXMgYmVl biBkaXNjb3ZlcmVkIGFzIGVsaWdpYmxlIG9uIHRoZSBwcmV2aW91cyBzdGVwIG9mIGNhY2hlIGNv bXBhcmlzb24pLg0KVGhlbiB0cmFuc2xhdGUgaXQgYXMgdG9kYXkgZm9yIENMQVQgKElQdjQtRW1i ZWRkZWQgSVB2NiBBZGRyZXNzIOKAkyBjbGF1c2UgMiBSRkMgNjA1MiwgYnV0IFJGQyA2ODc3IGNs YXVzZSA2LjMgc3RhdGVzIHRoYXQgb25seSAvNjQgdmVyc2lvbiBzaG91bGQgYmUgdXNlZCkuDQpX ZSBjb3VsZCByZXVzZSBleGFjdGx5IHRoZSBzYW1lIElQdjYgYWRkcmVzcyB0aGF0IHdlIGFyZSB1 c2luZyBub3cgZm9yIHRyYWZmaWMgdG8gUExBVCBhbmQgcHJlcGFyZSBpdCBieSBleGFjdGx5IHRo ZSBzYW1lIHJ1bGVzLg0KSVB2NCBzb3VyY2Ugd291bGQgYmUgdmlzaWJsZSAoaW5zaWRlIElQdjYg c291cmNlKSwgYnV0IHRyYWNraW5nIHdvdWxkIGJlIGRpZmZpY3VsdCBiZWNhdXNlIHdvdWxkIGJl IG1pbGxpb25zIG9mIHN1Y2ggMTkyLjE2OC4xLnguIEkgZG8gbm90IGJlbGlldmUgdGhhdCBhbnkg cmFuZG9taXphdGlvbiBpcyBuZWVkZWQgKGNvdWxkIGJlIGFkZGVkIGlmIHNvbWVib2R5IHdvdWxk IGluc2lzdCkuDQpUZWNobmljYWxseSwgaXQgY291bGQgYmUgb25lIEVBTVQsIGp1c3QgaXQgc2hv dWxkIGhhdmUgc291cmNlIElQdjQgYXMgdGhlIGtleSBmaWVsZC4gRUFNIHRhYmxlIGRvZXMgbm90 IG5lZWQgSVB2NCBwcmVmaXggKG9mIExBTiBzdWJuZXQpLg0KDQozLiAgICAgVGhlIHdheSBob3cg d2Ugd291bGQgc2VhcmNoIGZvciBwcm9wZXIgZGVzdGluYXRpb24gSVB2NiDigJMgd2UgY291bGQg a2VlcCBhcyBpdCBpcyBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCAocXVlcnkg YnkgcHJveHkgRE5TLCBqdXN0IGl0IHdvdWxkIGJlIHBlcnNvbmFsIHF1ZXJ5IGZvciBldmVyeSBo b3N0KS4NCg0KNC4gICAgIElmIEROUyAodG9nZXRoZXIgd2l0aCBFQU0gcmVjb3JkKSB3b3VsZCBl eHBpcmUsIGJ1dCBob3N0IHdvdWxkIG5vdCBwYXkgYXR0ZW50aW9uIHRvIEROUyBUVEwgKGFwcGxp Y2F0aW9uIGRvZXMgbm90IHdhbnQgdG8gaW50ZXJydXB0IHVzZXIgc2Vzc2lvbiDigJMgdGhhdCBp cyBwcm9wZXIgYmVoYXZpb3IpLCB0aGVuIGhvc3QgY291bGQgaW5pdGlhdGUgbmV3IEVBTSByZWNv cmQgdGhhdCBjb3VsZCBiZSByZXNvbHZlZCB0byBkaWZmZXJlbnQgSVB2Ni4gSXQgaXMgbm90IGdv b2QgaWRlYSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYnkgdGltZXJzLg0KSSBwcm9wb3NlIHRvIHVz ZSBFQU0gcmVjb3JkcyBmb3JldmVyIChkbyBub3QgcGF5IGF0dGVudGlvbiB0byBETlMgVFRMIHRp bWVyKSwgRUFNIHJlY29yZCBzaG91bGQgYmUgZGVsZXRlZCBvbmx5IGlmICgxKSBob3N0IHdvdWxk IGFzayBhZ2FpbiBmb3IgdGhlIHNhbWUgRlFETiwgb3IgKDIpIEFSUCBlbnRyeSB3b3VsZCBiZSBk ZWxldGVkIOKAkyB0aGVuIGFsbCBFQU0gZW50cmllcyByZWxhdGVkIHRvIHRoaXMgaG9zdCBzaG91 bGQgYmUgZGVsZXRlZCAoaW4gdGhlIGNhc2Ugb2Ygc3RhdGljIEFSUCBpdCBtZWFucyDigJMgICgy KSB3b3VsZCBuZXZlciBoYXBwZW4pLg0KV2Ugd291bGQgcmVwbGljYXRlIGhvc3QgYmVoYXZpb3I6 IGlmIGhlIHdvdWxkIGFzayDigJMgd2Ugd291bGQgcmVmcmVzaCwgaWYgaGUgZG9lcyB2aW9sYXRl IHByb3RvY29sIOKAkyB3ZSB3b3VsZCBkbyB0aGUgc2FtZSAoZm9yIGhpbSkuIFdlIHNob3VsZCBi ZSB0cmFuc3BhcmVudCBmb3IgaGltLg0KDQpHb29kIHRoaW5nczoNCg0KwrcgICAgICAgSXQgc2hv dWxkIHJlc29sdmUgTkFULXRyYXZlcnNhbCBpc3N1ZXMsIGJlY2F1c2UgSVB2NDpJUHY2PTE6MS4g QW55IGdsb2JhbCBJUHY2IGNvdWxkIGNvbm5lY3QgdG8gdGhpcyBQcml2YXRlIElQdjQgKGl0IHdv dWxkIHNlZSBpdCBhcyBJUHY0LUVtYmVkZGVkIElQdjYgQWRkcmVzcykuIElmIElQdjYgcGVyc2lz dGVudCAocmVjb21tZW5kZWQgZm9yIEZCQiksIHRoZW4gc3Vic2NyaWJlciBjb3VsZCBvcmdhbml6 ZSBXZWIgc2VydmVyIG9uIHRoaXMgcHJpdmF0ZSBJUHY0LCBpdCB3b3VsZCBiZSBhdmFpbGFibGUg Zm9yIHRoZSB3aG9sZSBJbnRlcm5ldA0KDQrCtyAgICAgICBObyBwb3NzaWJpbGl0eSBmb3Igb25l IElQdjQgaG9zdCB0byBoaWphY2sgY29ubmVjdGlvbiBvZiBvdGhlciBJUHY0IGhvc3QgKGluY2x1 ZGluZyB0aGUgc2l0dWF0aW9uIHdoZW4gb25lIGhvc3QgcG9pbnRlZCB0byBmb3JlaWduIEROUyDi gJMgaGlzIEZRRE4gcmVxdWVzdCB3b3VsZCBiZSBqdXN0IG5vdCB2aXNpYmxlIOKAkyBFQU0gcmVj b3JkIGZvciBoaW0gd291bGQgbm90IGJlIGNyZWF0ZWQpDQoNCsK3ICAgICAgIElmIGFueSBzdHJh bmdlIGNvbmZpZ3VyYXRpb24gb24gc2VydmVyIHNpZGUgKFRMUyBTTkkgZGVtdXggYWdhaW5zdCBJ UHY2IGFkZHJlc3MgZGVtdXgsIElQdjQgb25seSBzZXJ2ZXIgc2hhcmUgQSByZWNvcmQgd2l0aCBE dWFsU3RhY2sgc2VydmVyLCBjbGV2ZXIgQ0ROIGNsdXN0ZXJzIGNvbmZpZ3VyYXRpb24gLSBtYW55 IHByZXNlbnRlZCBieSBFcmlrKSDigJMgdGhlbiBjbGllbnQgd291bGQgYmVoYXZlIGxpa2Ugc2lu Z2xlIGR1YWwgc3RhY2sgY2xpZW50LiBJZiBzdWNoIGNsaWVudCB3b3VsZCBub3QgYmUgc2VydmVk IHByb3Blcmx5IOKAkyB0aGVuIFNlcnZlciBvd25lciB3b3VsZCBoYXZlIGEgYmlnIHRyb3VibGUg YW55d2F5LCBiZWNhdXNlIG1hbnkgb3RoZXIgRHVhbFN0YWNrIGNsaWVudCB3b3JsZC13aWRlDQoN CsK3ICAgICAgIElmIEROUyB3b3VsZCByZXNvbHZlIHRvIEFBQUEsIGJ1dCBubyBJUCBjb25uZWN0 aXZpdHkg4oCTIHRoZW4gYWdhaW46IG90aGVyIER1YWxTdGFjayBjbGllbnRzIHdvdWxkIGhhdmUg dGhlIGJpZyB0cm91YmxlDQoNCsK3ICAgICAgIFBhcnRpY3VsYXIgRUFNVCByZWNvcmQgY291bGQg c3RpY2sgdG8gb25seSAxIGRlc3RpbmF0aW9uIElQdjYgYWRkcmVzcywgZGVzcGl0ZSBETlMgTG9h ZCBCYWxhbmNpbmcsIGJ1dCBpdCB3b3VsZCBiZSBleGFjdGx5IHRoZSBzYW1lIGlmIGhvc3Qgd291 bGQgYXNrIGJ5IGl0c2VsZiwgb3VyIENMQVQtTkcgaXMgdHJhbnNwYXJlbnQgYW5kIHBlcnNvbmFs DQoNCsK3ICAgICAgIElmIHVzZXIgd291bGQgbW9kaWZ5IEROUyBvbiBDUEUg4oCTIGl0IGlzIGZp bmUg4oCTIHdlIHdvdWxkIHRyeSB0byBnZXQgQUFBQSBmcm9tIEROUyBzZXJ2ZXIgcHJlZmVycmVk IGJ5IGhpbS4gTm8gQUFBQSBhbnN3ZXIgLT4gbm8gRUFNIHJlY29yZCAtPiB0cmFmZmljIHdvdWxk IGdvIHRvIFBMQVQgLT4gbm8gcHJvYmxlbQ0KDQrCtyAgICAgICBETlMgcG9pc29uaW5nIHdvdWxk IGFmZmVjdCBvbmx5IDEgaG9zdCDigJMgZXhhY3RseSB0aGUgc2FtZSBzaXR1YXRpb24gYXMgd2l0 aG91dCBhbnkgb3B0aW1pemF0aW9uDQoNCsK3ICAgICAgIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxl bSB3aXRoIEROU1NFQyB0b28g4oCTIGl0IGNvdWxkIGFkZGl0aW9uYWxseSBjaGVjayBETlMgYW5z d2Vycw0KDQpDdXJyZW50bHkgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCAoYW5kIG5vdCBmaXhlZCk6 DQoNCsK3ICAgICAgIE9ubHkgSVB2NiBiYWNrYm9uZSBpcyBkb3duIG9yIGxpbmsgZGVncmFkZWQg KElQdjQgaXMgZmluZSksLSBidXQgd2UgcHVzaCB0cmFmZmljIHRvIElQdjYgb25seeKYuQ0KDQpP bmUgdmlzaWJsZSByZXN0cmljdGlvbjoNCg0KwrcgICAgICAgSWYgc3Vic2NyaWJlciB3b3VsZCBo YXZlIGJpZyByb3V0ZWQgbmV0d29yayBpbnNpZGUsIHRoZW4gQVJQIGVudHJ5IHdvdWxkIG5vdCBi ZSB2aXNpYmxlIG9uIENQRS4gTmV4dCBob3Agcm91dGVyIHdvdWxkIGJlIER1YWwgU3RhY2suIElu IHN1Y2ggY2FzZTogRUFNVCBlbnRyeSB3b3VsZCBub3QgYmUgY3JlYXRlZCDigJMgdHJhZmZpYyB3 b3VsZCBnbyB0byBQTEFUDQoNCkkgaGF2ZSBsb29rZWQgY2FyZWZ1bGx5IHRvIGFsbCBjb21tZW50 cyBvZiBKZW4sIEVyaWssIGFuZCBQaGlsaXAgYWdhaW4uIEkgaGF2ZSBub3QgZm91bmQgYW55IGhv bGVzIGxlZnQuIFByaW1hcmlseSwgYmVjYXVzZSBpbiB0aGlzIHByb3Bvc2FsIHdlIGFyZSBtaW1p Y2tpbmcgaG9zdHMgaW5kaXZpZHVhbGx5IOKAkyB3ZSBhcmUganVzdCDigJxmdWxseSB0cmFuc3Bh cmVudCBpbiBib3RoIGRpcmVjdGlvbnPigJ0uDQoNCkVkdWFyZA0K --_000_8c749e34e6ba49b9afbf5899b70cbcbehuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTo4LjBwdDsNCgltYXJnaW4tbGVmdDoz Ni4wcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNiU7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xp c3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGRpdi5N c29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNiU7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1p ZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBw dDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUt aGVpZ2h0OjEwNiU7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFn cmFwaEN4U3BMYXN0LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0DQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBj bTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206OC4wcHQ7DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglsaW5lLWhlaWdodDoxMDYlOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjE5MTcxMTcyOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDY2MzQzNzEyIDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjE2MTgwMjEzNjE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xMDQ5NzQ5MjEyIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21z by1saXN0LWlkOjIwMzM5OTMzNTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xMjIxMzM0NTIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvcmRpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvcnJ5IHRvIG92ZXJsb2Fk IHlvdSBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5F cmlrIGFuZCBKZW4gd2VyZSByaWdodDogZHJhZnQgZG9lcyBpbnRyb2R1Y2UgbmV3IGF0dGFjayB2 ZWN0b3JzLiBCZWNhdXNlIGhvc3RzIGFyZSDigJxzaGFyaW5nIHNlY3VyaXR5IGZhdGXigJ0g4oCT IHRoZXkgaGF2ZSBwcm92ZWQgaXQgaW4gbWFueSBleGFtcGxlcy4gTGV04oCZcyBkaXNqb2luIGhv c3RzIGJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGhDeFNwRmlyc3QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEw NiUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoQ3hTcE1pZGRsZSIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7bGluZS1oZWlnaHQ6MTA2JSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNiUiPkkgcHJvcG9zZSB0byBz dG9wIHRoaXMgZ3Vlc3Mtd29yayB3aG8gaXMgSVB2NC1vbmx5IGFuZCB3aG8gaXMgbm90LiBETlMg cXVlcnkgdGltZW91dCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBIYXBweSBFeWViYWxsIG9mIHBh cnRpY3VsYXIgaG9zdCBpbXBsZW1lbnRhdGlvbiBhbmQgQ0xBVC1ORyAoQ0xBVCBOZXh0DQogR2Vu ZXJhdGlvbikg4oCTIGlzIGEgdmVyeSByZWxpYWJsZSBwYXRoIHRvIGRpc2FzdGVyLiBXaGF0IGlm IHNvbWVib2R5IHdvdWxkIGNoYW5nZSB0aGlzIHRpbWVvdXQgaW4gbmV4dCBzb2Z0d2FyZSByZWxl YXNlPyBXaGF0IGlmIHRpbWVvdXQgYXJlIHZlcnkgZGlmZmVyZW50IG9uIGN1cnJlbnQgaG9zdHM/ IChJIGFtIHN1cmUgYWJvdXQgQW5kcm9pZCBhbmQgaU9TIGRpZmZlcmVuY2UpPGJyPg0KPGI+SSBw cm9wb3NlIGp1c3QgdG8gbG9vayB0byBORCBhbmQgQVJQIGNhY2hlczogaWYgcGFydGljdWxhciBN QUMgaGFzIG9ubHkgYmluZGluZyB0byBJUHY0IGFuZCB0aGUgc2FtZSBNQUMgZG9lcyBub3QgaGF2 ZSBiaW5kaW5nIHRvIElQdjYsIHRoZW4gaXQgaXMgb3VyIOKAnG9wdGltaXphdGlvbiBjYXNl4oCd LjwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4 U3BNaWRkbGUiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2xpbmUtaGVpZ2h0OjEwNiUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlIj5OQTxiPlA8L2I+VDQ0IGRvZXMg Z2VuZXJhdGUgbWFueSBpc3N1ZXMgdGhhdCBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhpcyBtYWls aW5nIGxpc3QuPGJyPg0KPGI+SSBwcm9wb3NlIHRvIHJldHVybiB0byBzdGF0ZWxlc3MgbmF0dXJl IG9mIENMQVQuIExldOKAmXMgY3JlYXRlIHNlcGFyYXRlIEVBTVQgdGFibGUgcGVyIGV2ZXJ5IElQ djQtb25seSBob3N0DQo8L2I+KHRoYXQgaGFzIGJlZW4gZGlzY292ZXJlZCBhcyBlbGlnaWJsZSBv biB0aGUgcHJldmlvdXMgc3RlcCBvZiBjYWNoZSBjb21wYXJpc29uKS48Yj48YnI+DQpUaGVuIHRy YW5zbGF0ZSBpdCBhcyB0b2RheSBmb3IgQ0xBVCAoPC9iPjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA2JSI+SVB2NC1FbWJlZGRl ZCBJUHY2IEFkZHJlc3Mg4oCTIGNsYXVzZSAyIFJGQyA2MDUyLCBidXQgUkZDIDY4NzcgY2xhdXNl IDYuMyBzdGF0ZXMgdGhhdCBvbmx5IC82NCB2ZXJzaW9uIHNob3VsZCBiZSB1c2VkPC9zcGFuPjwv Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlIj4pLjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA2JSI+ PGJyPg0KV2UgY291bGQgcmV1c2UgZXhhY3RseSB0aGUgc2FtZSBJUHY2IGFkZHJlc3MgdGhhdCB3 ZSBhcmUgdXNpbmcgbm93IGZvciB0cmFmZmljIHRvIFBMQVQgYW5kIHByZXBhcmUgaXQgYnkgZXhh Y3RseSB0aGUgc2FtZSBydWxlcy48YnI+DQpJUHY0IHNvdXJjZSB3b3VsZCBiZSB2aXNpYmxlIChp bnNpZGUgSVB2NiBzb3VyY2UpLCBidXQgdHJhY2tpbmcgd291bGQgYmUgZGlmZmljdWx0IGJlY2F1 c2Ugd291bGQgYmUgbWlsbGlvbnMgb2Ygc3VjaCAxOTIuMTY4LjEueC4gSSBkbyBub3QgYmVsaWV2 ZSB0aGF0IGFueSByYW5kb21pemF0aW9uIGlzIG5lZWRlZCAoY291bGQgYmUgYWRkZWQgaWYgc29t ZWJvZHkgd291bGQgaW5zaXN0KS48YnI+DQpUZWNobmljYWxseSwgaXQgY291bGQgYmUgb25lIEVB TVQsIGp1c3QgaXQgc2hvdWxkIGhhdmUgc291cmNlIElQdjQgYXMgdGhlIGtleSBmaWVsZC4gRUFN IHRhYmxlIGRvZXMgbm90IG5lZWQgSVB2NCBwcmVmaXggKG9mIExBTiBzdWJuZXQpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6 MTA2JSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlIj5UaGUgd2F5IGhvdyB3ZSB3b3VsZCBz ZWFyY2ggZm9yIHByb3BlciBkZXN0aW5hdGlvbiBJUHY2IOKAkyB3ZSBjb3VsZCBrZWVwIGFzIGl0 IGlzIGluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IChxdWVyeSBieSBwcm94eSBE TlMsIGp1c3QgaXQgd291bGQgYmUgcGVyc29uYWwgcXVlcnkNCiBmb3IgZXZlcnkgaG9zdCkuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNiUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0 OjEwNiUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlIj5JZiBETlMgKHRvZ2V0aGVyIHdpdGggRUFNIHJlY29y ZCkgd291bGQgZXhwaXJlLCBidXQgaG9zdCB3b3VsZCBub3QgcGF5IGF0dGVudGlvbiB0byBETlMg VFRMIChhcHBsaWNhdGlvbiBkb2VzIG5vdCB3YW50IHRvIGludGVycnVwdCB1c2VyIHNlc3Npb24g 4oCTIHRoYXQgaXMgcHJvcGVyIGJlaGF2aW9yKSwgdGhlbg0KIGhvc3QgY291bGQgaW5pdGlhdGUg bmV3IEVBTSByZWNvcmQgdGhhdCBjb3VsZCBiZSByZXNvbHZlZCB0byBkaWZmZXJlbnQgSVB2Ni4g SXQgaXMgbm90IGdvb2QgaWRlYSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYnkgdGltZXJzLjxicj4N CkkgcHJvcG9zZSB0byB1c2UgRUFNIHJlY29yZHMgZm9yZXZlciAoPGI+ZG8gbm90IHBheSBhdHRl bnRpb24gdG8gRE5TIFRUTCB0aW1lcjwvYj4pLCBFQU0gcmVjb3JkIHNob3VsZCBiZSBkZWxldGVk IG9ubHkgaWYgKDEpIGhvc3Qgd291bGQgYXNrIGFnYWluIGZvciB0aGUgc2FtZSBGUUROLCBvciAo MikgQVJQIGVudHJ5IHdvdWxkIGJlIGRlbGV0ZWQg4oCTIHRoZW4gYWxsIEVBTSBlbnRyaWVzIHJl bGF0ZWQgdG8gdGhpcyBob3N0IHNob3VsZCBiZSBkZWxldGVkDQogKGluIHRoZSBjYXNlIG9mIHN0 YXRpYyBBUlAgaXQgbWVhbnMg4oCTICZuYnNwOygyKSB3b3VsZCBuZXZlciBoYXBwZW4pLjxicj4N CldlIHdvdWxkIHJlcGxpY2F0ZSBob3N0IGJlaGF2aW9yOiBpZiBoZSB3b3VsZCBhc2sg4oCTIHdl IHdvdWxkIHJlZnJlc2gsIGlmIGhlIGRvZXMgdmlvbGF0ZSBwcm90b2NvbCDigJMgd2Ugd291bGQg ZG8gdGhlIHNhbWUgKGZvciBoaW0pLiBXZSBzaG91bGQgYmUgdHJhbnNwYXJlbnQgZm9yIGhpbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Hb29kIHRoaW5nczo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6 MTA2JTtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlIj5J dCBzaG91bGQgcmVzb2x2ZSBOQVQtdHJhdmVyc2FsIGlzc3VlcywgYmVjYXVzZSBJUHY0OklQdjY9 MToxLiBBbnkgZ2xvYmFsIElQdjYgY291bGQgY29ubmVjdCB0byB0aGlzIFByaXZhdGUgSVB2NCAo aXQgd291bGQgc2VlIGl0IGFzIElQdjQtRW1iZWRkZWQgSVB2NiBBZGRyZXNzKS4gSWYgSVB2NiBw ZXJzaXN0ZW50DQogKHJlY29tbWVuZGVkIGZvciBGQkIpLCB0aGVuIHN1YnNjcmliZXIgY291bGQg b3JnYW5pemUgV2ViIHNlcnZlciBvbiB0aGlzIHByaXZhdGUgSVB2NCwgaXQgd291bGQgYmUgYXZh aWxhYmxlIGZvciB0aGUgd2hvbGUgSW50ZXJuZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNiU7Zm9udC1mYW1pbHk6U3lt Ym9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA2JSI+Tm8gcG9zc2liaWxpdHkgZm9yIG9u ZSBJUHY0IGhvc3QgdG8gaGlqYWNrIGNvbm5lY3Rpb24gb2Ygb3RoZXIgSVB2NCBob3N0IChpbmNs dWRpbmcgdGhlIHNpdHVhdGlvbiB3aGVuIG9uZSBob3N0IHBvaW50ZWQgdG8gZm9yZWlnbiBETlMg 4oCTIGhpcyBGUUROIHJlcXVlc3Qgd291bGQgYmUganVzdCBub3QgdmlzaWJsZQ0KIOKAkyBFQU0g cmVjb3JkIGZvciBoaW0gd291bGQgbm90IGJlIGNyZWF0ZWQpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlO2ZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNiUiPklmIGFueSBzdHJhbmdl IGNvbmZpZ3VyYXRpb24gb24gc2VydmVyIHNpZGUgKFRMUyBTTkkgZGVtdXggYWdhaW5zdCBJUHY2 IGFkZHJlc3MgZGVtdXgsIElQdjQgb25seSBzZXJ2ZXIgc2hhcmUgQSByZWNvcmQgd2l0aCBEdWFs U3RhY2sgc2VydmVyLCBjbGV2ZXIgQ0ROIGNsdXN0ZXJzIGNvbmZpZ3VyYXRpb24gLQ0KIG1hbnkg cHJlc2VudGVkIGJ5IEVyaWspIOKAkyB0aGVuIGNsaWVudCB3b3VsZCBiZWhhdmUgbGlrZSA8Yj5z aW5nbGU8L2I+IGR1YWwgc3RhY2sgY2xpZW50LiBJZiBzdWNoIGNsaWVudCB3b3VsZCBub3QgYmUg c2VydmVkIHByb3Blcmx5IOKAkyB0aGVuIFNlcnZlciBvd25lciB3b3VsZCBoYXZlIGEgYmlnIHRy b3VibGUgYW55d2F5LCBiZWNhdXNlIG1hbnkgb3RoZXIgRHVhbFN0YWNrIGNsaWVudCB3b3JsZC13 aWRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZv MiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDts aW5lLWhlaWdodDoxMDYlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVp Z2h0OjEwNiUiPklmIEROUyB3b3VsZCByZXNvbHZlIHRvIEFBQUEsIGJ1dCBubyBJUCBjb25uZWN0 aXZpdHkg4oCTIHRoZW4gYWdhaW46IG90aGVyIER1YWxTdGFjayBjbGllbnRzIHdvdWxkIGhhdmUg dGhlIGJpZyB0cm91YmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MiBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2xpbmUtaGVpZ2h0OjEwNiUiPlBhcnRpY3VsYXIgRUFNVCByZWNvcmQgY291bGQgc3RpY2sg dG8gb25seSAxIGRlc3RpbmF0aW9uIElQdjYgYWRkcmVzcywgZGVzcGl0ZSBETlMgTG9hZCBCYWxh bmNpbmcsIGJ1dCBpdCB3b3VsZCBiZSBleGFjdGx5IHRoZSBzYW1lIGlmIGhvc3Qgd291bGQgYXNr IGJ5IGl0c2VsZiwgb3VyIENMQVQtTkcgaXMgdHJhbnNwYXJlbnQNCiBhbmQgcGVyc29uYWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8yIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVp Z2h0OjEwNiU7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA2 JSI+SWYgdXNlciB3b3VsZCBtb2RpZnkgRE5TIG9uIENQRSDigJMgaXQgaXMgZmluZSDigJMgd2Ug d291bGQgdHJ5IHRvIGdldCBBQUFBIGZyb20gRE5TIHNlcnZlciBwcmVmZXJyZWQgYnkgaGltLiBO byBBQUFBIGFuc3dlciAtJmd0OyBubyBFQU0gcmVjb3JkIC0mZ3Q7IHRyYWZmaWMgd291bGQgZ28g dG8gUExBVCAtJmd0OyBubyBwcm9ibGVtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNiUiPkROUyBwb2lzb25pbmcgd291bGQgYWZmZWN0 IG9ubHkgMSBob3N0IOKAkyBleGFjdGx5IHRoZSBzYW1lIHNpdHVhdGlvbiBhcyB3aXRob3V0IGFu eSBvcHRpbWl6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BMYXN0IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtsaW5lLWhlaWdodDoxMDYlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2xpbmUtaGVpZ2h0OjEwNiUiPkkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbSB3aXRoIEROU1NFQyB0 b28g4oCTIGl0IGNvdWxkIGFkZGl0aW9uYWxseSBjaGVjayBETlMgYW5zd2VyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkN1cnJlbnRseSBkaXNjdXNzZWQgaW4gdGhlIGRy YWZ0IChhbmQgbm90IGZpeGVkKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2xpbmUtaGVpZ2h0OjEwNiU7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGlu ZS1oZWlnaHQ6MTA2JSI+T25seSBJUHY2IGJhY2tib25lIGlzIGRvd24gb3IgbGluayBkZWdyYWRl ZCAoSVB2NCBpcyBmaW5lKSwtIGJ1dCB3ZSBwdXNoIHRyYWZmaWMgdG8gSVB2NiBvbmx5PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNiU7Zm9udC1mYW1p bHk6V2luZ2RpbmdzIj5MPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUt aGVpZ2h0OjEwNiUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSB2 aXNpYmxlIHJlc3RyaWN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZl bDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7bGluZS1oZWlnaHQ6MTA2JTtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5l LWhlaWdodDoxMDYlIj5JZiBzdWJzY3JpYmVyIHdvdWxkIGhhdmUgYmlnIHJvdXRlZCBuZXR3b3Jr IGluc2lkZSwgdGhlbiBBUlAgZW50cnkgd291bGQgbm90IGJlIHZpc2libGUgb24gQ1BFLiBOZXh0 IGhvcCByb3V0ZXIgd291bGQgYmUgRHVhbCBTdGFjay4gSW4gc3VjaCBjYXNlOiBFQU1UIGVudHJ5 IHdvdWxkIG5vdCBiZSBjcmVhdGVkDQog4oCTIHRyYWZmaWMgd291bGQgZ28gdG8gUExBVDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBsb29rZWQgY2FyZWZ1bGx5 IHRvIGFsbCBjb21tZW50cyBvZiBKZW4sIEVyaWssIGFuZCBQaGlsaXAgYWdhaW4uIEkgaGF2ZSBu b3QgZm91bmQgYW55IGhvbGVzIGxlZnQuIFByaW1hcmlseSwgYmVjYXVzZSBpbiB0aGlzIHByb3Bv c2FsIHdlIGFyZSBtaW1pY2tpbmcgaG9zdHMgaW5kaXZpZHVhbGx5IOKAkyB3ZSBhcmUganVzdA0K IOKAnGZ1bGx5IHRyYW5zcGFyZW50IGluIGJvdGggZGlyZWN0aW9uc+KAnS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RWR1YXJkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8c749e34e6ba49b9afbf5899b70cbcbehuaweicom_-- From nobody Fri Jul 17 14:54:54 2020 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 A3BF03A080E for ; Fri, 17 Jul 2020 14:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHJ-JtjBiNL4 for ; Fri, 17 Jul 2020 14:54:52 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 139563A0809 for ; Fri, 17 Jul 2020 14:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595022889; x=1595627689; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=luLAVUiN8Gy7tTIsseKoYp4m2bfwyMZde6 nUI+FHKQI=; b=ctznkEp/7NRdG6DSvdmYBujpn5mn/R5u6luxret1n6lY86iW+e TP5IAsj8hLFIKejimqsQyUeY4ic5/dJ91tonw/w/oY/TAZ15tsOsypPcyq1Hr7Kb evzBX4684U67/pmRoHhWH/6kqKZsxOdTNQDMGITKQbByp/yWKmLoYgWVg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 17 Jul 2020 23:54:49 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 17 Jul 2020 23:54:49 +0200 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000292821.msg for ; Fri, 17 Jul 2020 23:54:47 +0200 X-MDRemoteIP: 2001:470:1f09:495:fd3d:bcb7:60e7:66ed X-MDHelo: [10.10.10.131] X-MDArrival-Date: Fri, 17 Jul 2020 23:54:47 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1467b8aa93=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Fri, 17 Jul 2020 23:54:46 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration References: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> In-Reply-To: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3677874886_1712324456" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 21:54:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3677874886_1712324456 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Eduard, =20 Responding to this one as it is =E2=80=9Cshort=E2=80=9D,=C2=A0 I will conti= nue with the others tomorrow and across the weekend. =20 The operator doesn=E2=80=99t need to know which customers have =E2=80=9Cold= =E2=80=9D TVs. The operator can either push the EAMT or have it in some ser= ver so the CEs can pull it.=C2=A0 We can rely on many existing protocols fo= r that, or even provide it as part of the document itself, but that only ma= kes sense if other issues are resolved. =20 The main difficulty for this approach is that CDNs are used to do frequent = changes at the DNS level, so unless the CDNs are offering an API or somethi= ng-like to update the EAMT of the operator, it will become more complex. Th= e operator could just cache the most frequent FQDNs being resolved in their= own DNS and based on the TTLs, update the table and push it to the CEs, et= c. There are many possible solutions. =20 The document exposes different possible solutions. We have considered 3, in= other RFCs=C2=A0 there are even more.=C2=A0 For example I was reviewing dr= aft-ietf-v6ops-nd-cache-init a few days ago, and it presents about 8 soluti= ons and suggest one as the most reasonable. =20 So in my opinion is perfeclty valid to have several choices and then decide= . Note that when we started=C2=A0 the document it was not clear=C2=A0 for u= s,=C2=A0 the document keeps growing, and we may change our minds about what= solution is better, depending on the inputs, however, I think it is import= ant to keep all=C2=A0 the possible solutions documented even if it is clear= that they don=E2=80=99t make sense. =20 Regards, Jordi @jordipalet =20 =20 =20 El 17/7/20 21:19, "Vasilenko Eduard" escribi= =C3=B3: =20 Hi Jordi, How Carrier would know that user has brought additional device (TV for exam= ple) to his residence? Or let=E2=80=99s ask in simpler form: how Carrier would know how many Stupi= dTVs (IPv4 only) user already have? What to program in centralized IT system? IMHO: the whole Approach #3 (clause 5.3) does not make sense. Would you agree to delete it? As you mentioned in the draft: It is useless anyway without protocol to upl= oad EAMT. Eduard =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3677874886_1712324456 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Eduard,=

 

Responding to this one as it is =E2=80=9Cshort= =E2=80=9D,=C2=A0 I will continue with the others tomorrow and across the we= ekend.

 = ;

The operator doesn=E2= =80=99t need to know which customers have =E2=80=9Cold=E2=80=9D TVs. The op= erator can either push the EAMT or have it in some server so the CEs can pu= ll it.=C2=A0 We can rely on many existing protocols for that, or even provi= de it as part of the document itself, but that only makes sense if other is= sues are resolved.

=  

The main d= ifficulty for this approach is that CDNs are used to do frequent changes at= the DNS level, so unless the CDNs are offering an API or something-like to= update the EAMT of the operator, it will become more complex. The operator= could just cache the most frequent FQDNs being resolved in their own DNS a= nd based on the TTLs, update the table and push it to the CEs, etc. There a= re many possible solutions.

 

The documen= t exposes different possible solutions. We have considered 3, in other RFCs= =C2=A0 there are even more.=C2=A0 For example I was reviewing draft-ietf-v6= ops-nd-cache-init a few days ago, and it presents about 8 solutions and sug= gest one as the most reasonable.

= <= o:p> 

So in my opinion is perfeclt= y valid to have several choices and then decide. Note that when we started= =C2=A0 the document it was not clear=C2=A0 for us,=C2=A0 the document keeps= growing, and we may change our minds about what solution is better, depend= ing on the inputs, however, I think it is important to keep all=C2=A0 the p= ossible solutions documented even if it is clear that they don=E2=80=99t ma= ke sense.

 =

Regards,

Jordi

@jordipalet

 

 

 

El 17/7/20 21:19, "Vasilenk= o Eduard" <vasilenko.eduard@huawei.com> escribi=C3=B3:


******************************************= ****
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3677874886_1712324456-- From nobody Fri Jul 17 17:36:48 2020 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 9398C3A0420 for ; Fri, 17 Jul 2020 17:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVg4OipXeL8x for ; Fri, 17 Jul 2020 17:36:45 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC5B3A0433 for ; Fri, 17 Jul 2020 17:36:45 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id g37so8140856otb.9 for ; Fri, 17 Jul 2020 17:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l0mqlIXovi/Fewh4FYjAFfDn6TVr/OXaQaJQHNK1nlo=; b=e7jaaS4m0NOV+/YV4Kr5hc3LWDBTE8goPQiRCWOXSAv3u8nim6gPcbCpZHD3CKY2+c RSWZQ8tPUgf6L9DNi460Z8h5TQe1P/5MEQtWtkZVXahtByNToRx1gXzTGi/QCvXmVGNJ gNZXPwcNhO+gdrI1+b6L+XsV39vgAvstvoU+uR9ZPvteJG+1xbHiLn0wSiUbDPLv4PYr vuSgKMVJl+xta9EEDQlAa0GwFEWQZZhKKpIhVCzVyyexM3BhqnChPhPz4EKxGtNfz5JF O2TlDH/IPvMWFEcLYjpmLdQ0rMAkkb+37/SxS/a/WIddBRNAJUyUjoEVxFn5FM8LY+7c 3d7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l0mqlIXovi/Fewh4FYjAFfDn6TVr/OXaQaJQHNK1nlo=; b=rXKboSP67c1AhV41BqdP6vAj1E7uPfrbXXu0SW5dgRClnCmDfCE4FyNhC66ImF+Oh4 XEbRMkcmfNyjELOd5OjVboG2rq9OMSH47ITvJR52UXLRVTbbQgw76PcfvlK7xTMpEq+w Hm9mwu+3o+FZUdRiCieBvmAkxIBNdH0ak1ftRmMsEL+73wpxQsZDgHNXYZng0yYQWoNm lsPMNNBfAE/QQhN57wH+COx/d5iNX8BlF5aX2tvzlBjA8t8FXUcmG4f3lcERJ7awLQt8 ErVw9A0knn4xvivZb58PcYZ40SUw9br2MOws8omQyY98Zc9HjrEOMmFpt9m45XvFy+6/ Y0mQ== X-Gm-Message-State: AOAM533gaiOoBCzKrmpsvULSgwzHHRqQwrdPw6UXoT5m8LTc5Y5X7JBh Qd0l0fZgUOk8HIUcDi2Ow4vycmPaFVnsD926i0rCuw== X-Google-Smtp-Source: ABdhPJzcwR0YkPIeDU7ieZbRG4m+W5K0m3KjZTkeijLV/RWlRGLn1mNL1a0bfqADpr63RScLMG0DwK7gCAvuP4RkUZs= X-Received: by 2002:a05:6830:13c1:: with SMTP id e1mr11341735otq.191.1595032604292; Fri, 17 Jul 2020 17:36:44 -0700 (PDT) MIME-Version: 1.0 References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: From: Erik Kline Date: Fri, 17 Jul 2020 17:36:33 -0700 Message-ID: To: JORDI PALET MARTINEZ Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 00:36:48 -0000 On Fri, Jul 17, 2020 at 4:03 AM JORDI PALET MARTINEZ wrote: > > In your letter dated Fri, 17 Jul 2020 12:20:13 +0200 you wrote: > >Because the EAMT contains the FQDN so to avoid creating a trouble, in this case > >the EAMT entry is set to invalid, and not used. This is described in 5.2.6 with > >a similar example. > > Can you explain what happens if both A queries and the first AAAA query is > served from a local resolver's cache and then the second AAAA query is delayed? > > [Jordi] If the 2nd AAAA query is delayed past the "Resolution Delay", the EAMT entry will not be created (this time, it may happen later), so the optimization will not be performed for this IPv4 destination. See section 5.2.3. > > I guess Section 5.2.2 can be made explicit that the CPE must not return the > answer to an A query until an answer to the AAAA query has been received. > > [Jordi] Good point. May be: > > "The CE DNS proxy MUST NOT return the answer to an A query until either an answer to the AAAA query has been received or the Resolution Delay has passed" > > If you think this resolves it, I may need to move the text relevant to "what is the resolution delay" to 5.2.2, to make it clearer. > > This may be in the actual 5.2.2 or a new section after that to be more explicit, something like "CE DNS proxy responses" I don't think waiting helps anything. If there's packet loss and the 2nd AAAA never comes back, the client's TCP SYN to 192.0.2.1 will be sent to the wrong IPv6 host. I think this is hopelessly broken. From nobody Sat Jul 18 00:20:46 2020 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 8BD7E3A0CED for ; Sat, 18 Jul 2020 00:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av-BDGGOf33m for ; Sat, 18 Jul 2020 00:20:42 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2CD793A0CEB for ; Sat, 18 Jul 2020 00:20:42 -0700 (PDT) Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E6DE64407CFE36CCE04A; Sat, 18 Jul 2020 08:20:39 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 18 Jul 2020 08:20:39 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 18 Jul 2020 10:20:39 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Sat, 18 Jul 2020 10:20:39 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ , "V6 Ops List" Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration Thread-Index: AdZcbcA6ExEyPlrQR6qUbzYTEusxM///+/oA//8v8KA= Date: Sat, 18 Jul 2020 07:20:39 +0000 Message-ID: References: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> In-Reply-To: <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.206.68] Content-Type: multipart/alternative; boundary="_000_df7dae4c05354c0abb9d0942a4f7a2c3huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 07:20:45 -0000 --_000_df7dae4c05354c0abb9d0942a4f7a2c3huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQpNYXkgYmUgdGhlbiB0byBjb3B5IHNvbWUgaW5mb3JtYXRpb24gZnJvbSB0aGlz IGFuc3dlciB0byA1LjMuDQpCZWNhdXNlIGl0IGxvb2tzIG5vdyBsaWtlIOKAnG1pc3Npb24gaW1w b3NzaWJsZeKAnS4NCkVkdWFyZA0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSk9SREkgUEFMRVQgTUFSVElORVoNClNlbnQ6IDE4INC40Y7Q u9GPIDIwMjAg0LMuIDA6NTUNClRvOiBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAy IGNvbmNlcm5zIG9uIGNlbnRyYWxpemVkIChJVCkgRUFNVCBjb25maWd1cmF0aW9uDQoNCkhpIEVk dWFyZCwNCg0KUmVzcG9uZGluZyB0byB0aGlzIG9uZSBhcyBpdCBpcyDigJxzaG9ydOKAnSwgIEkg d2lsbCBjb250aW51ZSB3aXRoIHRoZSBvdGhlcnMgdG9tb3Jyb3cgYW5kIGFjcm9zcyB0aGUgd2Vl a2VuZC4NCg0KVGhlIG9wZXJhdG9yIGRvZXNu4oCZdCBuZWVkIHRvIGtub3cgd2hpY2ggY3VzdG9t ZXJzIGhhdmUg4oCcb2xk4oCdIFRWcy4gVGhlIG9wZXJhdG9yIGNhbiBlaXRoZXIgcHVzaCB0aGUg RUFNVCBvciBoYXZlIGl0IGluIHNvbWUgc2VydmVyIHNvIHRoZSBDRXMgY2FuIHB1bGwgaXQuICBX ZSBjYW4gcmVseSBvbiBtYW55IGV4aXN0aW5nIHByb3RvY29scyBmb3IgdGhhdCwgb3IgZXZlbiBw cm92aWRlIGl0IGFzIHBhcnQgb2YgdGhlIGRvY3VtZW50IGl0c2VsZiwgYnV0IHRoYXQgb25seSBt YWtlcyBzZW5zZSBpZiBvdGhlciBpc3N1ZXMgYXJlIHJlc29sdmVkLg0KDQpUaGUgbWFpbiBkaWZm aWN1bHR5IGZvciB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgQ0ROcyBhcmUgdXNlZCB0byBkbyBmcmVx dWVudCBjaGFuZ2VzIGF0IHRoZSBETlMgbGV2ZWwsIHNvIHVubGVzcyB0aGUgQ0ROcyBhcmUgb2Zm ZXJpbmcgYW4gQVBJIG9yIHNvbWV0aGluZy1saWtlIHRvIHVwZGF0ZSB0aGUgRUFNVCBvZiB0aGUg b3BlcmF0b3IsIGl0IHdpbGwgYmVjb21lIG1vcmUgY29tcGxleC4gVGhlIG9wZXJhdG9yIGNvdWxk IGp1c3QgY2FjaGUgdGhlIG1vc3QgZnJlcXVlbnQgRlFETnMgYmVpbmcgcmVzb2x2ZWQgaW4gdGhl aXIgb3duIEROUyBhbmQgYmFzZWQgb24gdGhlIFRUTHMsIHVwZGF0ZSB0aGUgdGFibGUgYW5kIHB1 c2ggaXQgdG8gdGhlIENFcywgZXRjLiBUaGVyZSBhcmUgbWFueSBwb3NzaWJsZSBzb2x1dGlvbnMu DQoNClRoZSBkb2N1bWVudCBleHBvc2VzIGRpZmZlcmVudCBwb3NzaWJsZSBzb2x1dGlvbnMuIFdl IGhhdmUgY29uc2lkZXJlZCAzLCBpbiBvdGhlciBSRkNzICB0aGVyZSBhcmUgZXZlbiBtb3JlLiAg Rm9yIGV4YW1wbGUgSSB3YXMgcmV2aWV3aW5nIGRyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5p dCBhIGZldyBkYXlzIGFnbywgYW5kIGl0IHByZXNlbnRzIGFib3V0IDggc29sdXRpb25zIGFuZCBz dWdnZXN0IG9uZSBhcyB0aGUgbW9zdCByZWFzb25hYmxlLg0KDQpTbyBpbiBteSBvcGluaW9uIGlz IHBlcmZlY2x0eSB2YWxpZCB0byBoYXZlIHNldmVyYWwgY2hvaWNlcyBhbmQgdGhlbiBkZWNpZGUu IE5vdGUgdGhhdCB3aGVuIHdlIHN0YXJ0ZWQgIHRoZSBkb2N1bWVudCBpdCB3YXMgbm90IGNsZWFy ICBmb3IgdXMsICB0aGUgZG9jdW1lbnQga2VlcHMgZ3Jvd2luZywgYW5kIHdlIG1heSBjaGFuZ2Ug b3VyIG1pbmRzIGFib3V0IHdoYXQgc29sdXRpb24gaXMgYmV0dGVyLCBkZXBlbmRpbmcgb24gdGhl IGlucHV0cywgaG93ZXZlciwgSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBhbGwgIHRo ZSBwb3NzaWJsZSBzb2x1dGlvbnMgZG9jdW1lbnRlZCBldmVuIGlmIGl0IGlzIGNsZWFyIHRoYXQg dGhleSBkb27igJl0IG1ha2Ugc2Vuc2UuDQoNClJlZ2FyZHMsDQpKb3JkaQ0KQGpvcmRpcGFsZXQN Cg0KDQoNCkVsIDE3LzcvMjAgMjE6MTksICJWYXNpbGVua28gRWR1YXJkIiA8dmFzaWxlbmtvLmVk dWFyZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiBlc2Ny aWJpw7M6DQoNCkhpIEpvcmRpLA0KSG93IENhcnJpZXIgd291bGQga25vdyB0aGF0IHVzZXIgaGFz IGJyb3VnaHQgYWRkaXRpb25hbCBkZXZpY2UgKFRWIGZvciBleGFtcGxlKSB0byBoaXMgcmVzaWRl bmNlPw0KT3IgbGV04oCZcyBhc2sgaW4gc2ltcGxlciBmb3JtOiBob3cgQ2FycmllciB3b3VsZCBr bm93IGhvdyBtYW55IFN0dXBpZFRWcyAoSVB2NCBvbmx5KSB1c2VyIGFscmVhZHkgaGF2ZT8NCldo YXQgdG8gcHJvZ3JhbSBpbiBjZW50cmFsaXplZCBJVCBzeXN0ZW0/DQpJTUhPOiB0aGUgd2hvbGUg QXBwcm9hY2ggIzMgKGNsYXVzZSA1LjMpIGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQpXb3VsZCB5b3Ug YWdyZWUgdG8gZGVsZXRlIGl0Pw0KQXMgeW91IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQ6IEl0IGlz IHVzZWxlc3MgYW55d2F5IHdpdGhvdXQgcHJvdG9jb2wgdG8gdXBsb2FkIEVBTVQuDQpFZHVhcmQN Cg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpJUHY0 IGlzIG92ZXINCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KaHR0cDovL3d3 dy50aGVpcHY2Y29tcGFueS5jb20NClRoZSBJUHY2IENvbXBhbnkNCg0KVGhpcyBlbGVjdHJvbmlj IG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3Ig Y29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBl eGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVy IG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBw YXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBj b3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9y bWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNl LCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91 dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCg== --_000_df7dae4c05354c0abb9d0942a4f7a2c3huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSm9yZGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1heSBi ZSB0aGVuIHRvIGNvcHkgc29tZSBpbmZvcm1hdGlvbiBmcm9tIHRoaXMgYW5zd2VyIHRvIDUuMy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QmVjYXVzZSBpdCBsb29rcyBub3cgbGlrZSDigJxtaXNzaW9uIGlt cG9zc2libGXigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkpPUkRJIFBBTEVUIE1BUlRJTkVaPGJyPg0KPGI+U2VudDo8L2I+IDE4INC40Y7Qu9GPIDIwMjAg 0LMuIDA6NTU8YnI+DQo8Yj5Ubzo8L2I+IFY2IE9wcyBMaXN0ICZsdDt2Nm9wc0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy00NjR4 bGF0LW9wdGltaXphdGlvbi0wMiBjb25jZXJucyBvbiBjZW50cmFsaXplZCAoSVQpIEVBTVQgY29u ZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkhpIEVkdWFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZXNwb25k aW5nIHRvIHRoaXMgb25lIGFzIGl0IGlzIOKAnHNob3J04oCdLCZuYnNwOyBJIHdpbGwgY29udGlu dWUgd2l0aCB0aGUgb3RoZXJzIHRvbW9ycm93IGFuZCBhY3Jvc3MgdGhlIHdlZWtlbmQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIG9wZXJhdG9yIGRvZXNu4oCZdCBu ZWVkIHRvIGtub3cgd2hpY2ggY3VzdG9tZXJzIGhhdmUg4oCcb2xk4oCdIFRWcy4gVGhlIG9wZXJh dG9yIGNhbiBlaXRoZXIgcHVzaCB0aGUgRUFNVCBvciBoYXZlIGl0IGluIHNvbWUgc2VydmVyIHNv IHRoZSBDRXMgY2FuIHB1bGwgaXQuJm5ic3A7IFdlIGNhbiByZWx5IG9uIG1hbnkgZXhpc3Rpbmcg cHJvdG9jb2xzDQogZm9yIHRoYXQsIG9yIGV2ZW4gcHJvdmlkZSBpdCBhcyBwYXJ0IG9mIHRoZSBk b2N1bWVudCBpdHNlbGYsIGJ1dCB0aGF0IG9ubHkgbWFrZXMgc2Vuc2UgaWYgb3RoZXIgaXNzdWVz IGFyZSByZXNvbHZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUg bWFpbiBkaWZmaWN1bHR5IGZvciB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgQ0ROcyBhcmUgdXNlZCB0 byBkbyBmcmVxdWVudCBjaGFuZ2VzIGF0IHRoZSBETlMgbGV2ZWwsIHNvIHVubGVzcyB0aGUgQ0RO cyBhcmUgb2ZmZXJpbmcgYW4gQVBJIG9yIHNvbWV0aGluZy1saWtlIHRvIHVwZGF0ZSB0aGUgRUFN VCBvZiB0aGUgb3BlcmF0b3IsDQogaXQgd2lsbCBiZWNvbWUgbW9yZSBjb21wbGV4LiBUaGUgb3Bl cmF0b3IgY291bGQganVzdCBjYWNoZSB0aGUgbW9zdCBmcmVxdWVudCBGUUROcyBiZWluZyByZXNv bHZlZCBpbiB0aGVpciBvd24gRE5TIGFuZCBiYXNlZCBvbiB0aGUgVFRMcywgdXBkYXRlIHRoZSB0 YWJsZSBhbmQgcHVzaCBpdCB0byB0aGUgQ0VzLCBldGMuIFRoZXJlIGFyZSBtYW55IHBvc3NpYmxl IHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+VGhlIGRvY3VtZW50IGV4cG9zZXMgZGlmZmVyZW50IHBvc3NpYmxlIHNvbHV0 aW9ucy4gV2UgaGF2ZSBjb25zaWRlcmVkIDMsIGluIG90aGVyIFJGQ3MmbmJzcDsgdGhlcmUgYXJl IGV2ZW4gbW9yZS4mbmJzcDsgRm9yIGV4YW1wbGUgSSB3YXMgcmV2aWV3aW5nIGRyYWZ0LWlldGYt djZvcHMtbmQtY2FjaGUtaW5pdCBhIGZldyBkYXlzDQogYWdvLCBhbmQgaXQgcHJlc2VudHMgYWJv dXQgOCBzb2x1dGlvbnMgYW5kIHN1Z2dlc3Qgb25lIGFzIHRoZSBtb3N0IHJlYXNvbmFibGUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+U28gaW4gbXkgb3BpbmlvbiBpcyBwZXJmZWNsdHkgdmFsaWQgdG8gaGF2ZSBzZXZlcmFsIGNo b2ljZXMgYW5kIHRoZW4gZGVjaWRlLiBOb3RlIHRoYXQgd2hlbiB3ZSBzdGFydGVkJm5ic3A7IHRo ZSBkb2N1bWVudCBpdCB3YXMgbm90IGNsZWFyJm5ic3A7IGZvciB1cywmbmJzcDsgdGhlIGRvY3Vt ZW50IGtlZXBzIGdyb3dpbmcsIGFuZCB3ZQ0KIG1heSBjaGFuZ2Ugb3VyIG1pbmRzIGFib3V0IHdo YXQgc29sdXRpb24gaXMgYmV0dGVyLCBkZXBlbmRpbmcgb24gdGhlIGlucHV0cywgaG93ZXZlciwg SSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBhbGwmbmJzcDsgdGhlIHBvc3NpYmxlIHNv bHV0aW9ucyBkb2N1bWVudGVkIGV2ZW4gaWYgaXQgaXMgY2xlYXIgdGhhdCB0aGV5IGRvbuKAmXQg bWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Sm9y ZGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkBqb3JkaXBhbGV0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0i RVMiPkVsIDE3LzcvMjAgMjE6MTksICZxdW90O1Zhc2lsZW5rbyBFZHVhcmQmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20iPnZhc2lsZW5rby5lZHVh cmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IGVzY3JpYmnDszo8L3NwYW4+PHNwYW4gbGFuZz0iRVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvcmRpLDwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+SG93IENhcnJpZXIgd291bGQga25v dyB0aGF0IHVzZXIgaGFzIGJyb3VnaHQgYWRkaXRpb25hbCBkZXZpY2UgKFRWIGZvciBleGFtcGxl KSB0byBoaXMgcmVzaWRlbmNlPzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+T3IgbGV04oCZcyBhc2sgaW4gc2ltcGxlciBmb3JtOiBob3cgQ2FycmllciB3b3Vs ZCBrbm93IGhvdyBtYW55IFN0dXBpZFRWcyAoSVB2NCBvbmx5KSB1c2VyIGFscmVhZHkgaGF2ZT88 L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgdG8gcHJv Z3JhbSBpbiBjZW50cmFsaXplZCBJVCBzeXN0ZW0/PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmIj5JTUhPOiB0aGUgd2hvbGUgQXBwcm9hY2ggIzMgKGNsYXVzZSA1 LjMpIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUu NHB0Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmIj5Xb3VsZCB5b3UgYWdyZWUgdG8gZGVsZXRlIGl0Pzwvc3Bhbj48c3BhbiBs YW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+QXMgeW91IG1lbnRpb25lZCBpbiB0aGUg ZHJhZnQ6IEl0IGlzIHVzZWxlc3MgYW55d2F5IHdpdGhvdXQgcHJvdG9jb2wgdG8gdXBsb2FkIEVB TVQuPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5FZHVhcmQ8 L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFUyI+PGJyPg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCklQdjQgaXMgb3Zlcjxicj4NCkFyZSB5 b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPzxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu dGhlaXB2NmNvbXBhbnkuY29tIj5odHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbTwvYT48YnI+ DQpUaGUgSVB2NiBDb21wYW55PGJyPg0KPGJyPg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29u dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFs LiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNp bHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBv Zg0KIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwg aW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxs IGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRp c3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzDQogb2YgdGhpcyBpbmZvcm1hdGlvbiwg ZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91 IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBj b21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_df7dae4c05354c0abb9d0942a4f7a2c3huaweicom_-- From nobody Sat Jul 18 00:37:23 2020 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 6EDAC3A0D1F for ; Sat, 18 Jul 2020 00:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttEe-of6sC8u for ; Sat, 18 Jul 2020 00:37:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2D6523A0D1E for ; Sat, 18 Jul 2020 00:37:20 -0700 (PDT) Received: from lhreml715-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 40FB1D923E2518C471F6; Sat, 18 Jul 2020 08:37:18 +0100 (IST) Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 18 Jul 2020 08:37:17 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 18 Jul 2020 10:37:17 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Sat, 18 Jul 2020 10:37:17 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals Thread-Index: AdZcdd5aW2KjixhYTwqkJPfQUrMFfQAXlVEA Date: Sat, 18 Jul 2020 07:37:17 +0000 Message-ID: <7d12c5b6b855488fa6af9b75085c3385@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.206.68] Content-Type: multipart/alternative; boundary="_000_7d12c5b6b855488fa6af9b75085c3385huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 07:37:22 -0000 --_000_7d12c5b6b855488fa6af9b75085c3385huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQpJIGhhdmUgY2xhcmlmaWVkIGEgbGl0dGxlIGJlbG93LiBVc2UgdGhpcyB2ZXJz aW9uLg0KRWR1YXJkDQpGcm9tOiBWYXNpbGVua28gRWR1YXJkDQpTZW50OiAxNyDQuNGO0LvRjyAy MDIwINCzLiAyMzoyNw0KVG86ICdKT1JESSBQQUxFVCBNQVJUSU5FWicgPGpvcmRpLnBhbGV0QGNv bnN1bGludGVsLmVzPg0KQ2M6ICdWNiBPcHMgTGlzdCcgPHY2b3BzQGlldGYub3JnPg0KU3ViamVj dDogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyIC0gc29t ZSBkaXNydXB0aXZlIHByb3Bvc2Fscw0KDQpIaSBKb3JkaSwNClNvcnJ5IHRvIG92ZXJsb2FkIHlv dSBhZ2Fpbi4NCkVyaWsgYW5kIEplbiB3ZXJlIHJpZ2h0OiBkcmFmdCBkb2VzIGludHJvZHVjZSBu ZXcgYXR0YWNrIHZlY3RvcnMuIEJlY2F1c2UgaG9zdHMgYXJlIOKAnHNoYXJpbmcgc2VjdXJpdHkg ZmF0ZeKAnSDigJMgdGhleSBoYXZlIHByb3ZlZCBpdCBpbiBtYW55IGV4YW1wbGVzLiBMZXTigJlz IGRpc2pvaW4gaG9zdHMgYmFjay4NCg0KDQoNCjEuICAgICBJIHByb3Bvc2UgdG8gc3RvcCB0aGlz IGd1ZXNzLXdvcmsgd2hvIGlzIElQdjQtb25seSBhbmQgd2hvIGlzIG5vdC4gRE5TIHF1ZXJ5IHRp bWVvdXQgc3luY2hyb25pemF0aW9uIGJldHdlZW4gSGFwcHkgRXllYmFsbCBvZiBwYXJ0aWN1bGFy IGhvc3QgaW1wbGVtZW50YXRpb24gYW5kIENMQVQtTkcgKENMQVQgTmV4dCBHZW5lcmF0aW9uKSDi gJMgaXMgYSB2ZXJ5IHJlbGlhYmxlIHBhdGggdG8gZGlzYXN0ZXIuIFdoYXQgaWYgc29tZWJvZHkg d291bGQgY2hhbmdlIHRoaXMgdGltZW91dCBpbiBuZXh0IHNvZnR3YXJlIHJlbGVhc2U/IFdoYXQg aWYgdGltZW91dCBhcmUgdmVyeSBkaWZmZXJlbnQgb24gY3VycmVudCBob3N0cz8gKEkgYW0gc3Vy ZSBhYm91dCBBbmRyb2lkIGFuZCBpT1MgZGlmZmVyZW5jZSkNCkkgcHJvcG9zZSBqdXN0IHRvIGxv b2sgdG8gTkQgYW5kIEFSUCBjYWNoZXM6IGlmIHBhcnRpY3VsYXIgTUFDIGhhcyBvbmx5IGJpbmRp bmcgdG8gSVB2NCBhbmQgdGhlIHNhbWUgTUFDIGRvZXMgbm90IGhhdmUgYmluZGluZyB0byBJUHY2 LCB0aGVuIGl0IGlzIG91ciDigJxvcHRpbWl6YXRpb24gY2FzZeKAnS4NCg0KMi4gICAgIE5BUFQ0 NCBkb2VzIGdlbmVyYXRlIG1hbnkgaXNzdWVzIHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIG9uIHRo aXMgbWFpbGluZyBsaXN0Lg0KSSBwcm9wb3NlIHRvIHJldHVybiB0byBzdGF0ZWxlc3MgbmF0dXJl IG9mIENMQVQgdHJhbnNsYXRpb24uIExldOKAmXMgY3JlYXRlIHNlcGFyYXRlIEVBTVQgdGFibGUg cGVyIGV2ZXJ5IElQdjQtb25seSBob3N0ICh0aGF0IGhhcyBiZWVuIGRpc2NvdmVyZWQgYXMgZWxp Z2libGUgb24gdGhlIHByZXZpb3VzIHN0ZXAgb2YgY2FjaGUgY29tcGFyaXNvbikuDQpUaGVuIHRy YW5zbGF0ZSBpdCBhcyB0b2RheSBmb3IgQ0xBVCAoSVB2NC1FbWJlZGRlZCBJUHY2IEFkZHJlc3Mg 4oCTIGNsYXVzZSAyIFJGQyA2MDUyLCBidXQgUkZDIDY4NzcgY2xhdXNlIDYuMyBzdGF0ZXMgdGhh dCBvbmx5IC82NCB2ZXJzaW9uIHNob3VsZCBiZSB1c2VkKS4NCldlIGNvdWxkIHJldXNlIGV4YWN0 bHkgdGhlIHNhbWUgSVB2NiBhZGRyZXNzIHRoYXQgd2UgYXJlIHVzaW5nIG5vdyBmb3IgdHJhZmZp YyB0byBQTEFUIGFuZCBwcmVwYXJlIGl0IGJ5IGV4YWN0bHkgdGhlIHNhbWUgcnVsZXMuDQpJUHY0 IHNvdXJjZSB3b3VsZCBiZSB2aXNpYmxlIChpbnNpZGUgSVB2NiBzb3VyY2UpLCBidXQgdHJhY2tp bmcgd291bGQgYmUgZGlmZmljdWx0IGJlY2F1c2Ugd291bGQgYmUgbWlsbGlvbnMgb2Ygc3VjaCAx OTIuMTY4LjEueC4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGFueSByYW5kb21pemF0aW9uIGlzIG5l ZWRlZCAoY291bGQgYmUgYWRkZWQgaWYgc29tZWJvZHkgd291bGQgaW5zaXN0KS4NClRlY2huaWNh bGx5LCBpdCBjb3VsZCBiZSBvbmUgRUFNVCwganVzdCBpdCBzaG91bGQgaGF2ZSBzb3VyY2UgSVB2 NCBhcyB0aGUga2V5IGZpZWxkLiBFQU0gdGFibGUgZG9lcyBub3QgbmVlZCBJUHY0IHByZWZpeCAo b2YgTEFOIHN1Ym5ldCkuDQpDTEFUIHRyYW5zbGF0aW9uIHdvdWxkIGJlY29tZSBzdGF0ZWxlc3Mg YWdhaW4uIEJ1dCBpbiBnZW5lcmFsIENMQVQgd291bGQgYmUgc3RhdGVmdWwsIGJlY2F1c2UgZGVj aXNpb24gYWJvdXQgZGVzdGluYXRpb24gSVB2NiAoUExBVCBvciByZWFsIEludGVybmV0IHJlc291 cmNlKSBzaG91bGQgYmUgZG9uZSBhbG1vc3QgcGVyLWZsb3cgKGZvciBzb3VyY2UgSVB2NCArIGRl c3RpbmF0aW9uIElQdjQpIHRoYXQgd2FzIGx1Y2t5IHRvIGNyZWF0ZSBhIHN0YXRlIGluIEVBTVQu DQoNCjMuICAgICBUaGUgd2F5IGhvdyB3ZSB3b3VsZCBzZWFyY2ggZm9yIHByb3BlciBkZXN0aW5h dGlvbiBJUHY2IOKAkyB3ZSBjb3VsZCBrZWVwIGFzIGl0IGlzIGluIHRoZSBjdXJyZW50IHZlcnNp b24gb2YgdGhlIGRyYWZ0IChxdWVyeSBieSBwcm94eSBETlMsIGp1c3QgaXQgd291bGQgYmUgcGVy c29uYWwgcXVlcnkgZm9yIGV2ZXJ5IGhvc3QpLg0KV2UgY291bGQgcmV1c2Ugbm93IEhhcHB5IEV5 ZWJhbGwgKFJGQyA4MzA1KSBmb3IgZG91YmxlIEROUyByZXF1ZXN0cyB3aXRoIGFsbCBhc3NvY2lh dGVkIHRpbWVycywgYmVjYXVzZSBGUUROIHJlcXVlc3QgaXMgcGVyc29uYWwgbm93IChqdXN0IGZv ciBvbmUgQXBwIG9mIG9uZSBIb3N0KS4gUGFydCBvZiBIRXYyIGNvdWxkIGJlIG9uIHByb3h5IENQ RSAob24gYmVoYWxmIG9mIElQdjQgaG9zdCkuDQoNCjQuICAgICBJZiBETlMgKHRvZ2V0aGVyIHdp dGggRUFNIHJlY29yZCkgd291bGQgZXhwaXJlLCBidXQgaG9zdCB3b3VsZCBub3QgcGF5IGF0dGVu dGlvbiB0byBETlMgVFRMIChhcHBsaWNhdGlvbiBkb2VzIG5vdCB3YW50IHRvIGludGVycnVwdCB1 c2VyIHNlc3Npb24g4oCTIHRoYXQgaXMgcHJvcGVyIGJlaGF2aW9yKSwgdGhlbiBob3N0IGNvdWxk IGluaXRpYXRlIG5ldyBFQU0gcmVjb3JkIHRoYXQgY291bGQgYmUgcmVzb2x2ZWQgdG8gZGlmZmVy ZW50IElQdjYuIEl0IGlzIG5vdCBnb29kIGlkZWEgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGJ5IHRp bWVycy4NCkkgcHJvcG9zZSB0byB1c2UgRUFNIHJlY29yZHMgZm9yZXZlciAoZG8gbm90IHBheSBh dHRlbnRpb24gdG8gRE5TIFRUTCB0aW1lciksIEVBTSByZWNvcmQgc2hvdWxkIGJlIGRlbGV0ZWQg b25seSBpZiAoMSkgaG9zdCB3b3VsZCBhc2sgYWdhaW4gZm9yIHRoZSBzYW1lIEZRRE4sIG9yICgy KSBBUlAgZW50cnkgd291bGQgYmUgZGVsZXRlZCDigJMgdGhlbiBhbGwgRUFNIGVudHJpZXMgcmVs YXRlZCB0byB0aGlzIGhvc3Qgc2hvdWxkIGJlIGRlbGV0ZWQgKGluIHRoZSBjYXNlIG9mIHN0YXRp YyBBUlAgaXQgbWVhbnMg4oCTICAoMikgd291bGQgbmV2ZXIgaGFwcGVuKS4NCldlIHdvdWxkIHJl cGxpY2F0ZSBob3N0IGJlaGF2aW9yOiBpZiBoZSB3b3VsZCBhc2sg4oCTIHdlIHdvdWxkIHJlZnJl c2gsIGlmIGhlIGRvZXMgdmlvbGF0ZSBwcm90b2NvbCDigJMgd2Ugd291bGQgZG8gdGhlIHNhbWUg KGZvciBoaW0pLiBXZSBzaG91bGQgYmUgdHJhbnNwYXJlbnQgZm9yIGhpbS4NCg0KR29vZCB0aGlu Z3M6DQoNCsK3ICAgICAgIEl0IHNob3VsZCByZXNvbHZlIE5BVC10cmF2ZXJzYWwgaXNzdWVzLCBi ZWNhdXNlIElQdjQ6SVB2Nj0xOjEuIEFueSBnbG9iYWwgSVB2NiBjb3VsZCBjb25uZWN0IHRvIHRo aXMgUHJpdmF0ZSBJUHY0IChpdCB3b3VsZCBzZWUgaXQgYXMgSVB2NC1FbWJlZGRlZCBJUHY2IEFk ZHJlc3MpLiBJZiBJUHY2IHBlcnNpc3RlbnQgKHJlY29tbWVuZGVkIGZvciBGQkIpLCB0aGVuIHN1 YnNjcmliZXIgY291bGQgb3JnYW5pemUgV2ViIHNlcnZlciBvbiB0aGlzIHByaXZhdGUgSVB2NCwg aXQgd291bGQgYmUgYXZhaWxhYmxlIGZvciB0aGUgd2hvbGUgSW50ZXJuZXQNCg0KwrcgICAgICAg Tm8gcG9zc2liaWxpdHkgZm9yIG9uZSBJUHY0IGhvc3QgdG8gaGlqYWNrIGNvbm5lY3Rpb24gb2Yg b3RoZXIgSVB2NCBob3N0IChpbmNsdWRpbmcgdGhlIHNpdHVhdGlvbiB3aGVuIG9uZSBob3N0IHBv aW50ZWQgdG8gZm9yZWlnbiBETlMg4oCTIGhpcyBGUUROIHJlcXVlc3Qgd291bGQgYmUganVzdCBu b3QgdmlzaWJsZSDigJMgRUFNIHJlY29yZCBmb3IgaGltIHdvdWxkIG5vdCBiZSBjcmVhdGVkKQ0K DQrCtyAgICAgICBJZiBhbnkgc3RyYW5nZSBjb25maWd1cmF0aW9uIG9uIHNlcnZlciBzaWRlIChU TFMgU05JIGRlbXV4IGFnYWluc3QgSVB2NiBhZGRyZXNzIGRlbXV4LCBJUHY0IG9ubHkgc2VydmVy IHNoYXJlIEEgcmVjb3JkIHdpdGggRHVhbFN0YWNrIHNlcnZlciwgY2xldmVyIENETiBjbHVzdGVy cyBjb25maWd1cmF0aW9uIC0gbWFueSBwcmVzZW50ZWQgYnkgRXJpaykg4oCTIHRoZW4gY2xpZW50 IHdvdWxkIGJlaGF2ZSBsaWtlIHNpbmdsZSBkdWFsIHN0YWNrIGNsaWVudC4gSWYgc3VjaCBjbGll bnQgd291bGQgbm90IGJlIHNlcnZlZCBwcm9wZXJseSDigJMgdGhlbiBTZXJ2ZXIgb3duZXIgd291 bGQgaGF2ZSBhIGJpZyB0cm91YmxlIGFueXdheSwgYmVjYXVzZSBtYW55IG90aGVyIER1YWxTdGFj ayBjbGllbnQgd29ybGQtd2lkZQ0KDQrCtyAgICAgICBJZiBETlMgd291bGQgcmVzb2x2ZSB0byBB QUFBLCBidXQgbm8gSVAgY29ubmVjdGl2aXR5IOKAkyB0aGVuIGFnYWluOiBvdGhlciBEdWFsU3Rh Y2sgY2xpZW50cyB3b3VsZCBoYXZlIHRoZSBiaWcgdHJvdWJsZQ0KDQrCtyAgICAgICBQYXJ0aWN1 bGFyIEVBTVQgcmVjb3JkIGNvdWxkIHN0aWNrIHRvIG9ubHkgMSBkZXN0aW5hdGlvbiBJUHY2IGFk ZHJlc3MsIGRlc3BpdGUgRE5TIExvYWQgQmFsYW5jaW5nLCBidXQgaXQgd291bGQgYmUgZXhhY3Rs eSB0aGUgc2FtZSBpZiBob3N0IHdvdWxkIGFzayBieSBpdHNlbGYsIG91ciBDTEFULU5HIGlzIHRy YW5zcGFyZW50IGFuZCBwZXJzb25hbA0KDQrCtyAgICAgICBJZiB1c2VyIHdvdWxkIG1vZGlmeSBE TlMgb24gQ1BFIOKAkyBpdCBpcyBmaW5lIOKAkyB3ZSB3b3VsZCB0cnkgdG8gZ2V0IEFBQUEgZnJv bSBETlMgc2VydmVyIHByZWZlcnJlZCBieSBoaW0uIE5vIEFBQUEgYW5zd2VyIC0+IG5vIEVBTSBy ZWNvcmQgLT4gdHJhZmZpYyB3b3VsZCBnbyB0byBQTEFUIC0+IG5vIHByb2JsZW0NCg0KwrcgICAg ICAgRE5TIHBvaXNvbmluZyB3b3VsZCBhZmZlY3Qgb25seSAxIGhvc3Qg4oCTIGV4YWN0bHkgdGhl IHNhbWUgc2l0dWF0aW9uIGFzIHdpdGhvdXQgYW55IG9wdGltaXphdGlvbg0KDQrCtyAgICAgICBJ IGRvIG5vdCBzZWUgYW55IHByb2JsZW0gd2l0aCBETlNTRUMgdG9vIOKAkyBpdCBjb3VsZCBhZGRp dGlvbmFsbHkgY2hlY2sgRE5TIGFuc3dlcnMNCg0KQ3VycmVudGx5IGRpc2N1c3NlZCBpbiB0aGUg ZHJhZnQgKGFuZCBub3QgZml4ZWQpOg0KDQrCtyAgICAgICBPbmx5IElQdjYgYmFja2JvbmUgaXMg ZG93biBvciBsaW5rIGRlZ3JhZGVkIChJUHY0IGlzIGZpbmUpLC0gYnV0IHdlIHB1c2ggdHJhZmZp YyB0byBJUHY2IG9ubHnimLkNCg0KT25lIHZpc2libGUgcmVzdHJpY3Rpb246DQoNCsK3ICAgICAg IElmIHN1YnNjcmliZXIgd291bGQgaGF2ZSBiaWcgcm91dGVkIG5ldHdvcmsgaW5zaWRlLCB0aGVu IEFSUCBlbnRyeSB3b3VsZCBub3QgYmUgdmlzaWJsZSBvbiBDUEUuIE5leHQgaG9wIHJvdXRlciB3 b3VsZCBiZSBEdWFsIFN0YWNrLiBJbiBzdWNoIGNhc2U6IEVBTVQgZW50cnkgd291bGQgbm90IGJl IGNyZWF0ZWQg4oCTIHRyYWZmaWMgd291bGQgZ28gdG8gUExBVA0KDQpJIGhhdmUgbG9va2VkIGNh cmVmdWxseSB0byBhbGwgY29tbWVudHMgb2YgSmVuLCBFcmlrLCBhbmQgUGhpbGlwIGFnYWluLiBJ IGhhdmUgbm90IGZvdW5kIGFueSBob2xlcyBsZWZ0LiBQcmltYXJpbHksIGJlY2F1c2UgaW4gdGhp cyBwcm9wb3NhbCB3ZSBhcmUgbWltaWNraW5nIGhvc3RzIGluZGl2aWR1YWxseSDigJMgd2UgYXJl IGp1c3Qg4oCcZnVsbHkgdHJhbnNwYXJlbnQgaW4gYm90aCBkaXJlY3Rpb25z4oCdLg0KDQpFZHVh cmQNCg== --_000_7d12c5b6b855488fa6af9b75085c3385huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTo4LjBwdDsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbXNv LWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNSU7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhD eFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdy YXBoQ3hTcEZpcnN0DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNSU7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNSU7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0 LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN Cgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206OC4wcHQ7DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1zby1hZGQtc3BhY2U6YXV0bzsNCglsaW5lLWhlaWdodDoxMDUlOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIz DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTIxOTE3 MTE3MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ2 NjM0MzcxMiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNjE4MDIxMzYxOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA0OTc0OTIxMiA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMDMzOTkzMzU3Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTIyMTMzNDUyIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSm9yZGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgaGF2ZSBjbGFyaWZpZWQgYSBsaXR0bGUgYmVsb3cuIFVzZSB0aGlzIHZlcnNp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBWYXNpbGVua28g RWR1YXJkDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTcg0LjRjtC70Y8gMjAyMCDQsy4gMjM6Mjc8YnI+ DQo8Yj5Ubzo8L2I+ICdKT1JESSBQQUxFVCBNQVJUSU5FWicgJmx0O2pvcmRpLnBhbGV0QGNvbnN1 bGludGVsLmVzJmd0Ozxicj4NCjxiPkNjOjwvYj4gJ1Y2IE9wcyBMaXN0JyAmbHQ7djZvcHNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy00 NjR4bGF0LW9wdGltaXphdGlvbi0wMiAtIHNvbWUgZGlzcnVwdGl2ZSBwcm9wb3NhbHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBKb3JkaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Tb3JyeSB0byBvdmVybG9hZCB5 b3UgYWdhaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXJp ayBhbmQgSmVuIHdlcmUgcmlnaHQ6IGRyYWZ0IGRvZXMgaW50cm9kdWNlIG5ldyBhdHRhY2sgdmVj dG9ycy4gQmVjYXVzZSBob3N0cyBhcmUg4oCcc2hhcmluZyBzZWN1cml0eSBmYXRl4oCdIOKAkyB0 aGV5IGhhdmUgcHJvdmVkIGl0IGluIG1hbnkgZXhhbXBsZXMuIExldOKAmXMgZGlzam9pbiBob3N0 cyBiYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo Q3hTcEZpcnN0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUl Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aEN4U3BNaWRkbGUiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2xpbmUtaGVpZ2h0OjEwNSUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj5JIHByb3Bvc2UgdG8gc3Rv cCB0aGlzIGd1ZXNzLXdvcmsgd2hvIGlzIElQdjQtb25seSBhbmQgd2hvIGlzIG5vdC4gRE5TIHF1 ZXJ5IHRpbWVvdXQgc3luY2hyb25pemF0aW9uIGJldHdlZW4gSGFwcHkgRXllYmFsbCBvZiBwYXJ0 aWN1bGFyIGhvc3QgaW1wbGVtZW50YXRpb24gYW5kIENMQVQtTkcgKENMQVQgTmV4dA0KIEdlbmVy YXRpb24pIOKAkyBpcyBhIHZlcnkgcmVsaWFibGUgcGF0aCB0byBkaXNhc3Rlci4gV2hhdCBpZiBz b21lYm9keSB3b3VsZCBjaGFuZ2UgdGhpcyB0aW1lb3V0IGluIG5leHQgc29mdHdhcmUgcmVsZWFz ZT8gV2hhdCBpZiB0aW1lb3V0IGFyZSB2ZXJ5IGRpZmZlcmVudCBvbiBjdXJyZW50IGhvc3RzPyAo SSBhbSBzdXJlIGFib3V0IEFuZHJvaWQgYW5kIGlPUyBkaWZmZXJlbmNlKTxicj4NCjxiPkkgcHJv cG9zZSBqdXN0IHRvIGxvb2sgdG8gTkQgYW5kIEFSUCBjYWNoZXM6IGlmIHBhcnRpY3VsYXIgTUFD IGhhcyBvbmx5IGJpbmRpbmcgdG8gSVB2NCBhbmQgdGhlIHNhbWUgTUFDIGRvZXMgbm90IGhhdmUg YmluZGluZyB0byBJUHY2LCB0aGVuIGl0IGlzIG91ciDigJxvcHRpbWl6YXRpb24gY2FzZeKAnS48 L2I+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDts aW5lLWhlaWdodDoxMDUlIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+TkE8Yj5QPC9iPlQ0NCBkb2VzIGdl bmVyYXRlIG1hbnkgaXNzdWVzIHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIG9uIHRoaXMgbWFpbGlu ZyBsaXN0Ljxicj4NCjxiPkkgcHJvcG9zZSB0byByZXR1cm4gdG8gc3RhdGVsZXNzIG5hdHVyZSBv ZiBDTEFUIDxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj50cmFuc2xhdGlvbjwvc3Bhbj4uIExl dOKAmXMgY3JlYXRlIHNlcGFyYXRlIEVBTVQgdGFibGUgcGVyIGV2ZXJ5IElQdjQtb25seSBob3N0 DQo8L2I+KHRoYXQgaGFzIGJlZW4gZGlzY292ZXJlZCBhcyBlbGlnaWJsZSBvbiB0aGUgcHJldmlv dXMgc3RlcCBvZiBjYWNoZSBjb21wYXJpc29uKS48Yj48YnI+DQpUaGVuIHRyYW5zbGF0ZSBpdCBh cyB0b2RheSBmb3IgQ0xBVCAoPC9iPjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+SVB2NC1FbWJlZGRlZCBJUHY2IEFkZHJl c3Mg4oCTIGNsYXVzZSAyIFJGQyA2MDUyLCBidXQgUkZDIDY4NzcgY2xhdXNlIDYuMyBzdGF0ZXMg dGhhdCBvbmx5IC82NCB2ZXJzaW9uIHNob3VsZCBiZSB1c2VkPC9zcGFuPjwvYj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj4pLjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+PGJyPg0KV2UgY291 bGQgcmV1c2UgZXhhY3RseSB0aGUgc2FtZSBJUHY2IGFkZHJlc3MgdGhhdCB3ZSBhcmUgdXNpbmcg bm93IGZvciB0cmFmZmljIHRvIFBMQVQgYW5kIHByZXBhcmUgaXQgYnkgZXhhY3RseSB0aGUgc2Ft ZSBydWxlcy48YnI+DQpJUHY0IHNvdXJjZSB3b3VsZCBiZSB2aXNpYmxlIChpbnNpZGUgSVB2NiBz b3VyY2UpLCBidXQgdHJhY2tpbmcgd291bGQgYmUgZGlmZmljdWx0IGJlY2F1c2Ugd291bGQgYmUg bWlsbGlvbnMgb2Ygc3VjaCAxOTIuMTY4LjEueC4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGFueSBy YW5kb21pemF0aW9uIGlzIG5lZWRlZCAoY291bGQgYmUgYWRkZWQgaWYgc29tZWJvZHkgd291bGQg aW5zaXN0KS48YnI+DQpUZWNobmljYWxseSwgaXQgY291bGQgYmUgb25lIEVBTVQsIGp1c3QgaXQg c2hvdWxkIGhhdmUgc291cmNlIElQdjQgYXMgdGhlIGtleSBmaWVsZC4gRUFNIHRhYmxlIGRvZXMg bm90IG5lZWQgSVB2NCBwcmVmaXggKG9mIExBTiBzdWJuZXQpLjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojNzAzMEEwIj5DTEFUIHRyYW5zbGF0aW9uIHdvdWxkIGJlY29tZSBzdGF0ZWxlc3MgYWdh aW4uIEJ1dCBpbiBnZW5lcmFsIENMQVQgd291bGQgYmUgc3RhdGVmdWwsIGJlY2F1c2UgZGVjaXNp b24gYWJvdXQgZGVzdGluYXRpb24gSVB2NiAoUExBVCBvciByZWFsIEludGVybmV0IHJlc291cmNl KSBzaG91bGQgYmUgZG9uZSBhbG1vc3QgcGVyLWZsb3cgKGZvciBzb3VyY2UgSVB2NCAmIzQzOyBk ZXN0aW5hdGlvbiBJUHY0KSB0aGF0DQogd2FzIGx1Y2t5IHRvIGNyZWF0ZSBhIHN0YXRlIGluIEVB TVQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+VGhl IHdheSBob3cgd2Ugd291bGQgc2VhcmNoIGZvciBwcm9wZXIgZGVzdGluYXRpb24gSVB2NiDigJMg d2UgY291bGQga2VlcCBhcyBpdCBpcyBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFm dCAocXVlcnkgYnkgcHJveHkgRE5TLCBqdXN0IGl0IHdvdWxkIGJlIHBlcnNvbmFsIHF1ZXJ5DQog Zm9yIGV2ZXJ5IGhvc3QpLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj5XZSBjb3Vs ZCByZXVzZSBub3cgSGFwcHkgRXllYmFsbCAoUkZDIDgzMDUpIGZvciBkb3VibGUgRE5TIHJlcXVl c3RzIHdpdGggYWxsIGFzc29jaWF0ZWQgdGltZXJzLCBiZWNhdXNlIEZRRE4gcmVxdWVzdCBpcyBw ZXJzb25hbCBub3cgKGp1c3QgZm9yIG9uZSBBcHAgb2Ygb25lIEhvc3QpLiBQYXJ0IG9mIEhFdjIg Y291bGQgYmUgb24gcHJveHkgQ1BFIChvbiBiZWhhbGYgb2YgSVB2NCBob3N0KS48L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0 OjEwNSUiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj5JZiBETlMgKHRvZ2V0aGVyIHdpdGggRUFNIHJlY29y ZCkgd291bGQgZXhwaXJlLCBidXQgaG9zdCB3b3VsZCBub3QgcGF5IGF0dGVudGlvbiB0byBETlMg VFRMIChhcHBsaWNhdGlvbiBkb2VzIG5vdCB3YW50IHRvIGludGVycnVwdCB1c2VyIHNlc3Npb24g 4oCTIHRoYXQgaXMgcHJvcGVyIGJlaGF2aW9yKSwgdGhlbg0KIGhvc3QgY291bGQgaW5pdGlhdGUg bmV3IEVBTSByZWNvcmQgdGhhdCBjb3VsZCBiZSByZXNvbHZlZCB0byBkaWZmZXJlbnQgSVB2Ni4g SXQgaXMgbm90IGdvb2QgaWRlYSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYnkgdGltZXJzLjxicj4N CkkgcHJvcG9zZSB0byB1c2UgRUFNIHJlY29yZHMgZm9yZXZlciAoPGI+ZG8gbm90IHBheSBhdHRl bnRpb24gdG8gRE5TIFRUTCB0aW1lcjwvYj4pLCBFQU0gcmVjb3JkIHNob3VsZCBiZSBkZWxldGVk IG9ubHkgaWYgKDEpIGhvc3Qgd291bGQgYXNrIGFnYWluIGZvciB0aGUgc2FtZSBGUUROLCBvciAo MikgQVJQIGVudHJ5IHdvdWxkIGJlIGRlbGV0ZWQg4oCTIHRoZW4gYWxsIEVBTSBlbnRyaWVzIHJl bGF0ZWQgdG8gdGhpcyBob3N0IHNob3VsZCBiZSBkZWxldGVkDQogKGluIHRoZSBjYXNlIG9mIHN0 YXRpYyBBUlAgaXQgbWVhbnMg4oCTICZuYnNwOygyKSB3b3VsZCBuZXZlciBoYXBwZW4pLjxicj4N CldlIHdvdWxkIHJlcGxpY2F0ZSBob3N0IGJlaGF2aW9yOiBpZiBoZSB3b3VsZCBhc2sg4oCTIHdl IHdvdWxkIHJlZnJlc2gsIGlmIGhlIGRvZXMgdmlvbGF0ZSBwcm90b2NvbCDigJMgd2Ugd291bGQg ZG8gdGhlIHNhbWUgKGZvciBoaW0pLiBXZSBzaG91bGQgYmUgdHJhbnNwYXJlbnQgZm9yIGhpbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Hb29kIHRoaW5nczo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6 MTA1JTtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj5J dCBzaG91bGQgcmVzb2x2ZSBOQVQtdHJhdmVyc2FsIGlzc3VlcywgYmVjYXVzZSBJUHY0OklQdjY9 MToxLiBBbnkgZ2xvYmFsIElQdjYgY291bGQgY29ubmVjdCB0byB0aGlzIFByaXZhdGUgSVB2NCAo aXQgd291bGQgc2VlIGl0IGFzIElQdjQtRW1iZWRkZWQgSVB2NiBBZGRyZXNzKS4gSWYgSVB2NiBw ZXJzaXN0ZW50DQogKHJlY29tbWVuZGVkIGZvciBGQkIpLCB0aGVuIHN1YnNjcmliZXIgY291bGQg b3JnYW5pemUgV2ViIHNlcnZlciBvbiB0aGlzIHByaXZhdGUgSVB2NCwgaXQgd291bGQgYmUgYXZh aWxhYmxlIGZvciB0aGUgd2hvbGUgSW50ZXJuZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSU7Zm9udC1mYW1pbHk6U3lt Ym9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+Tm8gcG9zc2liaWxpdHkgZm9yIG9u ZSBJUHY0IGhvc3QgdG8gaGlqYWNrIGNvbm5lY3Rpb24gb2Ygb3RoZXIgSVB2NCBob3N0IChpbmNs dWRpbmcgdGhlIHNpdHVhdGlvbiB3aGVuIG9uZSBob3N0IHBvaW50ZWQgdG8gZm9yZWlnbiBETlMg 4oCTIGhpcyBGUUROIHJlcXVlc3Qgd291bGQgYmUganVzdCBub3QgdmlzaWJsZQ0KIOKAkyBFQU0g cmVjb3JkIGZvciBoaW0gd291bGQgbm90IGJlIGNyZWF0ZWQpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlO2ZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPklmIGFueSBzdHJhbmdl IGNvbmZpZ3VyYXRpb24gb24gc2VydmVyIHNpZGUgKFRMUyBTTkkgZGVtdXggYWdhaW5zdCBJUHY2 IGFkZHJlc3MgZGVtdXgsIElQdjQgb25seSBzZXJ2ZXIgc2hhcmUgQSByZWNvcmQgd2l0aCBEdWFs U3RhY2sgc2VydmVyLCBjbGV2ZXIgQ0ROIGNsdXN0ZXJzIGNvbmZpZ3VyYXRpb24gLQ0KIG1hbnkg cHJlc2VudGVkIGJ5IEVyaWspIOKAkyB0aGVuIGNsaWVudCB3b3VsZCBiZWhhdmUgbGlrZSA8Yj5z aW5nbGU8L2I+IGR1YWwgc3RhY2sgY2xpZW50LiBJZiBzdWNoIGNsaWVudCB3b3VsZCBub3QgYmUg c2VydmVkIHByb3Blcmx5IOKAkyB0aGVuIFNlcnZlciBvd25lciB3b3VsZCBoYXZlIGEgYmlnIHRy b3VibGUgYW55d2F5LCBiZWNhdXNlIG1hbnkgb3RoZXIgRHVhbFN0YWNrIGNsaWVudCB3b3JsZC13 aWRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZv NCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDts aW5lLWhlaWdodDoxMDUlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVp Z2h0OjEwNSUiPklmIEROUyB3b3VsZCByZXNvbHZlIHRvIEFBQUEsIGJ1dCBubyBJUCBjb25uZWN0 aXZpdHkg4oCTIHRoZW4gYWdhaW46IG90aGVyIER1YWxTdGFjayBjbGllbnRzIHdvdWxkIGhhdmUg dGhlIGJpZyB0cm91YmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2xpbmUtaGVpZ2h0OjEwNSUiPlBhcnRpY3VsYXIgRUFNVCByZWNvcmQgY291bGQgc3RpY2sg dG8gb25seSAxIGRlc3RpbmF0aW9uIElQdjYgYWRkcmVzcywgZGVzcGl0ZSBETlMgTG9hZCBCYWxh bmNpbmcsIGJ1dCBpdCB3b3VsZCBiZSBleGFjdGx5IHRoZSBzYW1lIGlmIGhvc3Qgd291bGQgYXNr IGJ5IGl0c2VsZiwgb3VyIENMQVQtTkcgaXMgdHJhbnNwYXJlbnQNCiBhbmQgcGVyc29uYWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVp Z2h0OjEwNSU7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1 JSI+SWYgdXNlciB3b3VsZCBtb2RpZnkgRE5TIG9uIENQRSDigJMgaXQgaXMgZmluZSDigJMgd2Ug d291bGQgdHJ5IHRvIGdldCBBQUFBIGZyb20gRE5TIHNlcnZlciBwcmVmZXJyZWQgYnkgaGltLiBO byBBQUFBIGFuc3dlciAtJmd0OyBubyBFQU0gcmVjb3JkIC0mZ3Q7IHRyYWZmaWMgd291bGQgZ28g dG8gUExBVCAtJmd0OyBubyBwcm9ibGVtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPkROUyBwb2lzb25pbmcgd291bGQgYWZmZWN0 IG9ubHkgMSBob3N0IOKAkyBleGFjdGx5IHRoZSBzYW1lIHNpdHVhdGlvbiBhcyB3aXRob3V0IGFu eSBvcHRpbWl6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BMYXN0IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlO2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2xpbmUtaGVpZ2h0OjEwNSUiPkkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbSB3aXRoIEROU1NFQyB0 b28g4oCTIGl0IGNvdWxkIGFkZGl0aW9uYWxseSBjaGVjayBETlMgYW5zd2VyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkN1cnJlbnRseSBkaXNjdXNzZWQgaW4gdGhlIGRy YWZ0IChhbmQgbm90IGZpeGVkKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2xpbmUtaGVpZ2h0OjEwNSU7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGlu ZS1oZWlnaHQ6MTA1JSI+T25seSBJUHY2IGJhY2tib25lIGlzIGRvd24gb3IgbGluayBkZWdyYWRl ZCAoSVB2NCBpcyBmaW5lKSwtIGJ1dCB3ZSBwdXNoIHRyYWZmaWMgdG8gSVB2NiBvbmx5PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSU7Zm9udC1mYW1p bHk6V2luZ2RpbmdzIj5MPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUt aGVpZ2h0OjEwNSUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSB2 aXNpYmxlIHJlc3RyaWN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZl bDEgbGZvNiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7bGluZS1oZWlnaHQ6MTA1JTtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5l LWhlaWdodDoxMDUlIj5JZiBzdWJzY3JpYmVyIHdvdWxkIGhhdmUgYmlnIHJvdXRlZCBuZXR3b3Jr IGluc2lkZSwgdGhlbiBBUlAgZW50cnkgd291bGQgbm90IGJlIHZpc2libGUgb24gQ1BFLiBOZXh0 IGhvcCByb3V0ZXIgd291bGQgYmUgRHVhbCBTdGFjay4gSW4gc3VjaCBjYXNlOiBFQU1UIGVudHJ5 IHdvdWxkIG5vdCBiZSBjcmVhdGVkDQog4oCTIHRyYWZmaWMgd291bGQgZ28gdG8gUExBVDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBsb29rZWQgY2FyZWZ1bGx5 IHRvIGFsbCBjb21tZW50cyBvZiBKZW4sIEVyaWssIGFuZCBQaGlsaXAgYWdhaW4uIEkgaGF2ZSBu b3QgZm91bmQgYW55IGhvbGVzIGxlZnQuIFByaW1hcmlseSwgYmVjYXVzZSBpbiB0aGlzIHByb3Bv c2FsIHdlIGFyZSBtaW1pY2tpbmcgaG9zdHMgaW5kaXZpZHVhbGx5IOKAkyB3ZSBhcmUganVzdA0K IOKAnGZ1bGx5IHRyYW5zcGFyZW50IGluIGJvdGggZGlyZWN0aW9uc+KAnS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RWR1YXJkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7d12c5b6b855488fa6af9b75085c3385huaweicom_-- From nobody Sat Jul 18 01:53:44 2020 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 760523A0403 for ; Sat, 18 Jul 2020 01:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z-LINe9rMXK for ; Sat, 18 Jul 2020 01:53:41 -0700 (PDT) Received: from tools.si6networks.com (v6toolkit.go6lab.si [91.239.96.57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DB43A040F for ; Sat, 18 Jul 2020 01:53:40 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8cac:f8e6:7ef:af39] (unknown [IPv6:2800:810:464:1f7:8cac:f8e6:7ef:af39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tools.si6networks.com (Postfix) with ESMTPSA id B1518400F9; Sat, 18 Jul 2020 10:53:37 +0200 (CEST) To: Vasilenko Eduard , JORDI PALET MARTINEZ , V6 Ops List References: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> From: Fernando Gont Message-ID: <6becbb19-a4e1-3d6f-87e1-6baac015a7d2@gont.com.ar> Date: Sat, 18 Jul 2020 05:53:17 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 08:53:43 -0000 On 18/7/20 04:20, Vasilenko Eduard wrote: [....] > So in my opinion is perfeclty valid to have several choices and then > decide. Note that when we started  the document it was not clear  for > us,  the document keeps growing, and we may change our minds about what > solution is better, depending on the inputs, however, I think it is > important to keep all  the possible solutions documented even if it is > clear that they don’t make sense. If something does not really make sense, I don't really see that point of "documenting" it -- unless it's an existing practice that one is planning to recommend against. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sat Jul 18 03:00:53 2020 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 4E29E3A0900 for ; Sat, 18 Jul 2020 03:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgDsDThPwjxz for ; Sat, 18 Jul 2020 03:00:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB313A08F5 for ; Sat, 18 Jul 2020 03:00:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jwjeA-0000MFC; Sat, 18 Jul 2020 12:00:46 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-reply-to: Your message of "Fri, 17 Jul 2020 17:36:33 -0700 ." Date: Sat, 18 Jul 2020 12:00:45 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 10:00:51 -0000 >I don't think waiting helps anything. If there's packet loss and the >2nd AAAA never comes back, the client's TCP SYN to 192.0.2.1 will be >sent to the wrong IPv6 host. That can be fixed by deleting the entry upon timeout. From nobody Sat Jul 18 08:10:29 2020 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 4C2DE3A00D3 for ; Sat, 18 Jul 2020 08:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9qvcJVmHnyB for ; Sat, 18 Jul 2020 08:10:22 -0700 (PDT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D25A3A011B for ; Sat, 18 Jul 2020 08:10:22 -0700 (PDT) Received: by mail-wr1-f52.google.com with SMTP id q5so13915740wru.6 for ; Sat, 18 Jul 2020 08:10:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MDBSCABEtz/qO6Svcgfp+UDC1tieCRJT3Zpy3m4vLqw=; b=T/0C3NzJ9u8839BM999TRsexaRQzVZ8MHpUzDFxAUAlT43/bcYz3/9MdgmqNaIPNW+ UpqHPJmr1Rcfk28ZT0/6MJ9LScbU+VG/7pOS5Vs17vC7wf4UbXxe9fiU/EH7LiJMH89T wekhG5GCwpEndkvVM51aWvhT8pktlGBP0NF46Bukv6nEAz6QHWeX9iI2jOUXbFZME74+ xKAiffM+JC6XJqwM4IwnfG+FUbIgUU1DEtsqMy5ZX2Q2GDKH0ruWa2v1qnTlbgiyc52u TPGg6SEzBXvwO3OtV8LL7b7DDS/yhrQBye9NaclhzzfDyfkXyQI3vG+KsENkhJtSnugI WgDA== X-Gm-Message-State: AOAM533DlobxymI1KVhVQ+JQ3jObZF/wNOC1oK0I3UoRmt5Xm4Te5Lsy TG2CZRXDQjFfPaHPTbL/cMc+axHMcew3n1pM+imzIdev4ek= X-Google-Smtp-Source: ABdhPJymd2W1KEde2zoSRY1+tNz1v0EgvHF7HS0J8nNCOqq4avYZlxgTjZUt4KTKTzwEHMmim1lTHBgjJUxp/2/uOGY= X-Received: by 2002:adf:ff87:: with SMTP id j7mr15801240wrr.128.1595085020963; Sat, 18 Jul 2020 08:10:20 -0700 (PDT) MIME-Version: 1.0 References: <67C20112-4347-4F99-891C-993D25EEA19E@consulintel.es> In-Reply-To: <67C20112-4347-4F99-891C-993D25EEA19E@consulintel.es> From: Erik Nygren Date: Sat, 18 Jul 2020 11:10:09 -0400 Message-ID: To: JORDI PALET MARTINEZ Cc: V6 Ops List Content-Type: multipart/alternative; boundary="0000000000000faa4305aab8acd1" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 15:10:24 -0000 --0000000000000faa4305aab8acd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2020 at 6:16 AM JORDI PALET MARTINEZ wrote: > > > 5.2.1 Detection of IPv4-only hosts or applications > > Will Android doing synchronous A/AAAA lookups break this > detection? and does this impact other things like STBs built on > Android? Android does one of the A or AAAA lookups, waits for it > to return, then does the other. From the perspective of the CPE resolver= , > could look like an IPv4-only host and just always introduce the 50ms dela= y? > > Some more details may be needed here on the timing heuristics needed > to detect various scenarios like this. > > > > [Jordi] When a synchronous lookup is performed, then it is clear that the > hosts is IPv6 enabled (actually dual-stack), so the EAMT entry is not > created. If the EAMT entry already exists, then it will be used only if > the host decides to prefer IPv4 instead of IPv6, which doesn=E2=80=99t lo= ok like a > normal behavior. To ensure it, we may need to double-check if the 50 ms. > delay is still good for Android or it is too small. I don=E2=80=99t think= it is a > big issue to increase it. We could improve it, to avoid the delay, if we > create an additional table for the =E2=80=9Calready known=E2=80=9D to be = dual-stack hosts. > This may be also related to the new field in the EAMT that I mention abov= e. > Will *all* A lookups invalidate EAMT entries? If they don't, IPv4-only hosts can break dual-stack hosts. Also on "only if the host decides to prefer IPv4 instead of IPv6, which doesn=E2=80=99t look like a normal behavior" a reminder that this is a normal behavior for many clients. For example, a large portion of deployed AppleTVs will always do A and AAAA lookups but will randomly pick between IPv4 and IPv6 to use. (ie, they are based on an older iOS that doesn't give a bias towards IPv6 so ~half of their traffic is IPv4.) An important principle here may be that whatever we do here needs to work for all clients, not just a subset of clients following an assumption of what "well behaved" is. While I started out overly optimistic, I'm starting to fear that this may not be tractable without a level of complexity and risk which may not be worth the effort. (I have a bunch of ideas for additional hacks that might help, but they jus= t make things more fragile in different ways.) Erik --0000000000000faa4305aab8acd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jul 17, 2020 at 6:16 AM JORDI PALET MARTINEZ <jordi.p= alet=3D40consulintel.es@= dmarc.ietf.org> wrote:
<= br>

> 5.2.1 =C2=A0Detection of IPv4-only hosts = or applications

Will Android doing synchronous A/AAAA lookups break = this
detection? =C2=A0and does this impact other things like STBs= built on
Android?=C2=A0 Android does one of the A or AAAA lookups, wait= s for it
to return, then does the other.=C2=A0 From the perspective of t= he CPE resolver,
could look like an IPv4-only host and just always intro= duce the 50ms delay?

Some more details may be n= eeded here on the timing heuristics needed
to detect various scenarios l= ike this.

=C2=A0

[Jordi] When a synchro= nous lookup is performed, then it is clear that the hosts is IPv6 enabled (= actually dual-stack), so the EAMT entry is not created. If the EAMT entry a= lready exists, then it will be used only if the host decides to prefer IP= v4 instead of IPv6, which doesn=E2=80=99t look like a normal behavior. To e= nsure it, we may need to double-check if the 50 ms. delay is still good for= Android or it is too small. I don=E2=80=99t think it is a big issue to inc= rease it. We could improve it, to avoid the delay, if we create an addition= al table for the =E2=80=9Calready known=E2=80=9D to be dual-stack hosts. Th= is may be also related to the new field in the EAMT that I mention above.


=
W= ill *all* A lookups invalidate EAMT entries?=C2=A0 If they don't, IPv4-= only hosts can break dual-stack hosts.

Also on "only if the h= ost decides to prefer IPv4 instead of IPv6, which doesn=E2=80=99t look like= a normal behavior"
a reminder that this is a normal behavior for many = clients.=C2=A0 For example, a large portion of deployed
AppleTVs will always= do A and AAAA lookups but will randomly pick between IPv4 and IPv6 to use.=
= (ie, they are based on an older iOS that doesn't give a bias towards IP= v6 so ~half of their traffic is IPv4.)

An important principle here may b= e that whatever we do here needs to work for all clients,
not just a subse= t of clients following an assumption of what "well behaved" is.
Wh= ile I started out overly optimistic, I'm starting to fear that this may= not be tractable
without a level of complexity and risk which may not = be worth the effort.
(I have a bunch of ideas for additional hacks that migh= t help, but they just
make things more fragile in different ways.)

=
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Erik









--0000000000000faa4305aab8acd1-- From nobody Sun Jul 19 02:34:33 2020 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 B7DE23A0C11 for ; Sun, 19 Jul 2020 02:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxnhKgDIjhmz for ; Sun, 19 Jul 2020 02:34:30 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8013A0C10 for ; Sun, 19 Jul 2020 02:34:29 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id w3so22318544wmi.4 for ; Sun, 19 Jul 2020 02:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LPoHrJO3MP0hWjc9FwygNT6FGXOWZhsA8Nkc3ERm/3A=; b=So230QmXIj2WIy4ElWl84jgCAHk5MEkgv1l6kLciQWKzumLG5leBlqZWOyi9Xqc2KF /zVcp+OFZLdUQ85l1eMFECCCu6iPJ5JP2uzxS+QiwfDetjH1pu6u88qlH0+gj8zApi/V Cc+cad7rq35SrBL9HxzLAvI/bsjKXkv190+WFiKhy3rxDTUx2E0sbeRmTfXERV9oMRdw Xc913ctOjbi4mkaFsv2ZdHEChSD5ncQmxxx/ZZzBvXDXusDKkjXILaSKuNcPw1PH9Sdp 6RdlngobD9TF5w1PitBQUpe4kx8zDbpvdW5ewKC1yMi3jvU5jarDz3tgLHmiBWeKx6tC 3HRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LPoHrJO3MP0hWjc9FwygNT6FGXOWZhsA8Nkc3ERm/3A=; b=MSqElYhMd+8++QlWKTPdu5rGSH78faHMxwgjYeayji6p/huaV62MQENs7W2YfoANCS KeWzHc95h/q6eHs82jKA5wO0CohmkUIYVxw2b5mNTmNd/67mRcJqaWMgF7lkne7384AP qquEzFzmeqBKtOxwRyB9InWRESRtE0elydd/vYLZ7MDToaLMulqaR8yXabtHEiY8j2OA CJAHvuJGb4Nqh/CrIWFFHT4eSWZ+R1X43bgMYIWFyOFjDGP1V2u3VW6s0jcIIr6VifNC ZtE3i4dXdMu37mDIq0tmwQ2r8n6hjWW0xogUbnjh5QsoBtGtZINLdj3PHnO4pdy8oeR1 jhQQ== X-Gm-Message-State: AOAM532RAvoI0J6lpIwRN1Jmr2LZWOHRiMd862Cc0XrO7gmKSU6s5iTw e4+IKLUwurYvsRDcNtB7rVQwhJW+ X-Google-Smtp-Source: ABdhPJxBkWZpY9lpj34CvAPuHXYXCgPn3K730LQbl2fRaqE2bmLE0IrDqSCzuEPKOwRLemIBP1xLEg== X-Received: by 2002:a1c:7f82:: with SMTP id a124mr15811293wmd.132.1595151268155; Sun, 19 Jul 2020 02:34:28 -0700 (PDT) Received: from [192.168.0.12] (tchowndsl.claranet.co.uk. [212.188.254.49]) by smtp.gmail.com with ESMTPSA id f15sm24373059wrx.91.2020.07.19.02.34.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jul 2020 02:34:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Chown In-Reply-To: Date: Sun, 19 Jul 2020 10:34:26 +0100 Cc: Fred Baker , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <405C6BC1-299B-4457-A1A3-C219B3C6B9E6@gmail.com> References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com> To: Owen DeLong X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] RFC 6877 to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 09:34:32 -0000 I assume the original RFC 6877 essentially documented what T-Mobile did = for their IPv6 deployment back in around 2013. 464XLAT. has been used = by other operators since, on millions of handsets they have sold, so it = would seem more than timely to get the approach promoted to Standards = Track, with an update from seven years of experience if required. Tim > On 16 Jul 2020, at 18:29, Owen DeLong wrote: >=20 > I have no strong opinion one way or the other. >=20 > I will say that if making it a proposed standard somehow helps people = get on with IPv6 deployment, I=E2=80=99m all for it. This transition has = taken far too long already. >=20 > Owen >=20 >=20 >> On Jul 16, 2020, at 10:07 , Fred Baker = wrote: >>=20 >> In today's Interim Meeting, Jordi pointed out that all transition = mechanisms are at Proposed Standard except 464XLAT, and asked the = working group to advance it to that status. >>=20 >> /* Personal Opinion */ >> I have no problem with doing so, but I would ask whether 464XLAT is = indeed a transition mechanism. It is an operational procedure (and = therefore within v6ops' charter to produce, which it did) that uses RFCs = 6146, 6147, 7915, and possibly 6092, which are at Proposed Standard. >> /* Personal Opinion */ >>=20 >> My huffing and puffing aside, I'd like to poll the opinion of the = working group. >> - does RFC 6877 need to be updated? A good approach to doing so = would be to file errata (https://www.rfc-editor.org/errata.php). >> The document currently has no errata filed. Consider this an = invitation to file any needed errata and tell v6ops you have done so. >>=20 >> - failing that, we certainly have operational experience with it. It = is currently an informational document.=20 >> Would it be appropriate to raise it to Proposed Standard? >>=20 >> - Per RFC 6410, we may be in a position to advance 6877, 6146, 6147, = and/or 7915 to Internet Standard. The criterion and process are >> described in https://tools.ietf.org/html/rfc6410, and boil down to = (1) multiple interoperable implementations and (2) >> a general belief that the technology works. =46rom my perspective, = if we believe that 464XLAT is widely deployed and useful, >> we believe that each of those are >>=20 >> "characterized by a high degree of >> technical maturity and by a generally held belief that the >> specified protocol or service provides significant benefit to the >> Internet community." >>=20 >> Please reply all with your viewpoint. >>=20 >> If the answer is "yes", fair warning: Ron and I are going to be = looking for someone to write an internet draft documenting the fact and = the deployment status. >> _______________________________________________ >> 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 nobody Sun Jul 19 03:45:35 2020 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 A67BA3A0869 for ; Sun, 19 Jul 2020 03:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpHzVapGTt9i for ; Sun, 19 Jul 2020 03:45:31 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 999813A0867 for ; Sun, 19 Jul 2020 03:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595155528; x=1595760328; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=3bu3k8ezAtSNcBfRszKfxPykZDr0K1d/KU FZrWYYbSg=; b=RLPPYCnHJbepyStALWBTgR5UGeyVjMqatydSA+k0YNw5fPFGw/ HhsLbZLv2p9WYC+C0U4rdZUuzAYnzZAU95Rk0hDNMCSH36ur+suaCtpYSCrGm7wu M+KG0i26Aje9fT6/mSfGPAIWLBU8gkJMWaDzxI3UAzAjWBWwmuxz31ET8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 12:45:28 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 12:45:27 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000298924.msg for ; Sun, 19 Jul 2020 12:45:26 +0200 X-MDRemoteIP: 2001:470:1f09:495:a868:4c2e:4585:82c3 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sun, 19 Jul 2020 12:45:26 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 12:45:24 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration References: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678007524_1188799760" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 10:45:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678007524_1188799760 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Yep, good point making it more explicit. =20 Regards, Jordi @jordipalet =20 =20 =20 El 18/7/20 9:21, "v6ops en nombre de Vasilenko Eduard" escribi=C3=B3: =20 Hi Jordi, May be then to copy some information from this answer to 5.3. Because it looks now like =E2=80=9Cmission impossible=E2=80=9D. Eduard From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of JORDI PALET MARTIN= EZ Sent: 18 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 0:55 To: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on c= entralized (IT) EAMT configuration =20 Hi Eduard, =20 Responding to this one as it is =E2=80=9Cshort=E2=80=9D, I will continue w= ith the others tomorrow and across the weekend. =20 The operator doesn=E2=80=99t need to know which customers have =E2=80=9Cold= =E2=80=9D TVs. The operator can either push the EAMT or have it in some ser= ver so the CEs can pull it. We can rely on many existing protocols for tha= t, or even provide it as part of the document itself, but that only makes s= ense if other issues are resolved. =20 The main difficulty for this approach is that CDNs are used to do frequent = changes at the DNS level, so unless the CDNs are offering an API or somethi= ng-like to update the EAMT of the operator, it will become more complex. Th= e operator could just cache the most frequent FQDNs being resolved in their= own DNS and based on the TTLs, update the table and push it to the CEs, et= c. There are many possible solutions. =20 The document exposes different possible solutions. We have considered 3, in= other RFCs there are even more. For example I was reviewing draft-ietf-v= 6ops-nd-cache-init a few days ago, and it presents about 8 solutions and su= ggest one as the most reasonable. =20 So in my opinion is perfeclty valid to have several choices and then decide= . Note that when we started the document it was not clear for us, the do= cument keeps growing, and we may change our minds about what solution is be= tter, depending on the inputs, however, I think it is important to keep all= the possible solutions documented even if it is clear that they don=E2=80= =99t make sense. =20 Regards, Jordi @jordipalet =20 =20 =20 El 17/7/20 21:19, "Vasilenko Eduard" escribi= =C3=B3: =20 Hi Jordi, How Carrier would know that user has brought additional device (TV for exam= ple) to his residence? Or let=E2=80=99s ask in simpler form: how Carrier would know how many Stupi= dTVs (IPv4 only) user already have? What to program in centralized IT system? IMHO: the whole Approach #3 (clause 5.3) does not make sense. Would you agree to delete it? As you mentioned in the draft: It is useless anyway without protocol to upl= oad EAMT. Eduard =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3678007524_1188799760 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Yep, good point making it mo= re explicit.

 

Regards,

Jordi=

@jordipalet

 

 <= /p>

 

El 18/7/20 9:21, "v= 6ops en nombre de Vasilenko Eduard" <v6ops-bounces@ietf.org en nombre de vasilenko.eduard@huawei.com> escribi=C3=B3:<= span style=3D'font-size:11.0pt'>

 

Hi Jordi,<= /o:p>

May be then= to copy some information from this answer to 5.3.

Because it looks now li= ke =E2=80=9Cmission impossible=E2=80=9D.

Eduard

=

From: v6ops [mailt= o:v6ops-bounces@ietf.org] On Behalf Of JORDI PALET MARTINEZ
Se= nt: 18 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 0:55
To: V6 Ops = List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops= -464xlat-optimization-02 concerns on centralized (IT) EAMT configuration

 

Hi Eduard,

 

Responding to this one as it is =E2=80=9Cshort=E2=80=9D,  I w= ill continue with the others tomorrow and across the weekend.

 

The operator doesn=E2=80=99t need to know which customers have =E2= =80=9Cold=E2=80=9D TVs. The operator can either push the EAMT or have it in= some server so the CEs can pull it.  We can rely on many existing pro= tocols for that, or even provide it as part of the document itself, but tha= t only makes sense if other issues are resolved.

 

The main difficulty for this app= roach is that CDNs are used to do frequent changes at the DNS level, so unl= ess the CDNs are offering an API or something-like to update the EAMT of th= e operator, it will become more complex. The operator could just cache the = most frequent FQDNs being resolved in their own DNS and based on the TTLs, = update the table and push it to the CEs, etc. There are many possible solut= ions.

 =

The document exposes different= possible solutions. We have considered 3, in other RFCs  there are ev= en more.  For example I was reviewing draft-ietf-v6ops-nd-cache-init a= few days ago, and it presents about 8 solutions and suggest one as the mos= t reasonable.

&nbs= p;

<= span style=3D'font-family:"Calibri",sans-serif;color:black'>So in my opinio= n is perfeclty valid to have several choices and then decide. Note that whe= n we started  the document it was not clear  for us,  the do= cument keeps growing, and we may change our minds about what solution is be= tter, depending on the inputs, however, I think it is important to keep all=   the possible solutions documented even if it is clear that they don= =E2=80=99t make sense.

 

Regard= s,

Jordi

@jordipalet

=  

 

 

El 17/7/20 21:19, "Vas= ilenko Eduard" <vasi= lenko.eduard@huawei.com> escribi=C3=B3:

 

<= /div>

Hi Jordi,

<= /div>

How Carrier would know that user has broug= ht additional device (TV for example) to his residence?

Or let=E2=80=99s ask in simpler form: how Carrier = would know how many StupidTVs (IPv4 only) user already have?

What to program in centralized IT system?

IMHO: the whole Approach #3 (clause 5.3) does not make sense= .

Would you agree to delete it?=

As you mentioned in the draft:= It is useless anyway without protocol to upload EAMT.

Eduard

 


**********************************************
IPv= 4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it.

_____________________________= __________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/m= ailman/listinfo/v6ops


*********************= *************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3678007524_1188799760-- From nobody Sun Jul 19 03:57:34 2020 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 E7AD93A087B for ; Sun, 19 Jul 2020 03:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrPvUqcmtRJo for ; Sun, 19 Jul 2020 03:57:31 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 676C23A0879 for ; Sun, 19 Jul 2020 03:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595156249; x=1595761049; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=V6SpobNr 2clQJPjdect+JLXdCi76eJUXRe4JpP9OiPQ=; b=QhYG7N+yXsDsLc1dAT4H7+Rm 3fVj5Ea909+T4lBlDzmEBOJWvYYc+nc5qZWg9lex/tQwtthHbpK8KkjT+XKuND0s 8jisvhyP7Nju2zXIIN/7wcGb+E2D7xAuQT8jZfCAPSgL/6VlUiNjLk/2zKb8E5I6 3C9eBadJ3QIo9aE6Thg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 12:57:29 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 12:57:27 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000298958.msg for ; Sun, 19 Jul 2020 12:57:27 +0200 X-MDRemoteIP: 2001:470:1f09:495:a868:4c2e:4585:82c3 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sun, 19 Jul 2020 12:57:27 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 12:57:23 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <4D67F606-3141-4432-A78B-3D357383F59B@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> <75108EA5-62D2-43EF-BEBC-646737384F9C@consulintel.es> <19114aa217f443d0965f602269c432a7@huawei.com> In-Reply-To: <19114aa217f443d0965f602269c432a7@huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 10:57:33 -0000 Hi Eduard, I'm still thinking in the other email from you about using the MAC of the s= ource hosts instead of the DNS queries to guess if it is a dual-stack or IP= v4-only host. It looks like a very smart idea, unless anyone else could tel= l why not ... If we use than then we could just include the MAC address in the EAMT. However, I don't see why identifying the hosts (whether is via MAC or sourc= e IPv4) disallows using the NAT44+NAT46. I guess it is a matter of implemen= tation. =EF=BB=BFEl 17/7/20 17:55, "v6ops en nombre de Vasilenko Eduard" escribi=C3=B3: Hi Jordi, It is even longer than I have expected. Fine. But in separate discussion you have proposed to put source IPv4 into EA= MT table, That would break logic below - it would not be possible anymore to pipe= line 2 independent engines: NAPT44 and NAT46. It should be one stateful eng= ine. Let's wait for the finish of other discussions - may be you have to ret= urn to 5.2.4 again. Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of JORDI PALET MA= RTINEZ Sent: 17 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 11:01 To: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-= 02 - concern on statefulness Hi Eduard, Let us know what do you think about this tentative alternative text to = resolve this issue: 5.2.4. Forwarding path via stateful NAT for existing EAMT entries Following this approach, if there is a valid EAMT entry, for a given IPv4-destination, the IPv6-native path pointed by the IPv6 address o= f that EAMT entry, will take precedence versus the NAT64 path, so the traffic will not be forwarded to the NAT64. However, this is not sufficient to ensure that individual applications are able to keep existing connections. In many cases, audio and video streaming may use a single TCP connection lasting from minutes to hours. Instead, the CDN TTLs may be configured in the range from 10 to 300 seconds in order to allow new resolutions t= o switch quickly and to handle large recursive resolvers (with hundred= s of thousands of clients behind them). Consequently, the EAMT entries MUST NOT be used directly to establis= h a forwarding path, but instead, MUST be used to create a stateful NA= T entry for the 4-tuple for the duration of the session/connection. This means that to implement the optimization the NAT46 MUST be stateful. Typically, stateful NAT46 are implemented by means of a stateful NAT44 (which often maybe hardware off-loaded)= , followed by a stateless NAT46. If the SoC/code is able to do stateless NAT46, this still could be used when the optimization is disabled. Note that also following Erik inputs, the text has more normative langu= age. Also, for the title we thought that it will make sense: 464XLAT/MAP-T Optimization No need to mention NAT64, which is part of the 464XLAT. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 16:18, "v6ops en nombre de JORDI PALET MARTINEZ" escribi=C3=B3: I think your point will be to make it clear in the document that fo= r this optimization to work, the CLAT should be stateful? I think is there (5.2.4. Forwarding path via stateful NAT for exis= ting EAMT entries), but I will make sure to add the relevant text in the ne= xt version to make it clearer.=20 I insist: most of the CLAT implementations today (running in both C= PEs and UEs) are stateful. At least this is the data I've. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" escribi=C3= =B3: Hi Jordi, I still believe that tough (new) requirement that CLAT should b= ecome Stateful (mandatory) Make sense to insert into the document. And explanation why stateful NAPT is needed would be good. I have spent some time to research this - it is better to save = time of other people. It is important point that is omitted in the document. For the name: I do not have any strong opinion. Just I see that draft is applicable mostly to MAP-T, And not much applicable to XLAT (because majority of installati= ons have stateless CLAT). But the name mislead to opposite conclusion. Eduard -----Original Message----- From: Jordi Palet Mart=C3=ADnez [mailto:jordi.palet@theipv6comp= any.com]=20 Sent: 15 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 16:48 To: Vasilenko Eduard ; v6ops@ietf.= org Cc: draft-ietf-v6ops-464xlat-optimization@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optim= ization-02 - concern on statefulness Hi Vasilenko, The implementations of 464XLAT, can do the same (and in fact, m= any of them is what they do). NAT44 stateful and the 46 stateless. Many SoC= have embedded NAT44 acceleration, but not NAT46, so that explains it as we= ll. I guess that could clear your concern? I've several customers doing 464XLAT in broadband, one of them = 25.000.000 subscribers. There is no difference in doing 464XLAT in cellular= and broadband. When we say in the title 464XLAT/NAT64, I think both are covere= d. But I've no issue to change the title if this makes sense to others. We = could explictily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detai= l, in my opinion. Regards, Jordi @jordipalet =EF=BB=BFEl 15/7/20 15:40, "Vasilenko Eduard" escribi=C3=B3: Hi all, I have concern on the capability to use this mechanism for = 464XLAT, but it should be fine for MAP-T. We may have many hosts on CPE LAN. Typically, 70% of FBB tr= affic is still designated to IPv4 sites. Source UDP/TCP port collision is still very possible (i.e. = active sessions from different host may have the same source TCP/UDP port), It is not stated anywhere in the document, but we need to s= queeze (for path to Internet it would be "source IP address") many private = IPv4 hosts to one IPv6 (assigned by carrier to CPE uplink). Classical N:1 problem that should be resolved by NAPT (port= translation is mandatory). MAP-T has NAPT engine on CPE side - it make sense to clearl= y state in the document that we are going to reuse NAPT. Then translation w= ould be: (1) NAPT44 for many private IPv4 to one public IPv4 (well, = it could be not public, but public A+P has been given to MAP CE anyway - be= tter to reuse it for unification) (2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1) XLAT/CLAT does have stateful NAPT by RFC 6877, but it is no= t popular - not implemented by many carriers (if any?). It would be the big news that Carriers should choose statef= ul CLAT option for 464XLAT. It is better to tell them upfront. The next question could be: does it make sense to use State= less CLAT for basic 464XLAT and Stateful CLAT for traffic optimization to I= Pv4 sites? Or it is better to unify on Stateful CLAT for everything. In general, it is a revolution for 464XLAT. But it is smoot= h expansion for MAP-T. Hence, does it make sense to change the name of this draft = to reflect MAP-T as the primary target? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org Sent: 11 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 15:34 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optim= ization-02.txt A New Internet-Draft is available from the on-line Internet= -Drafts directories. This draft is a work item of the IPv6 Operations WG of the = IETF. Title : 464XLAT/NAT64 Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-02= .txt Pages : 21 Date : 2020-07-11 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to prov= ide access for IPv4-only devices or applications to IPv4-only or du= al-stack destinations over IPv6-only infrastructure. In that cas= e, the traffic flows are translated twice: first from IPv4 to I= Pv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (statefu= l NAT64, at the egress point). When the destination is IPv6-enabled= , the second translation might be avoided. This document describes a= possible optimization to 464XLAT and MAP-T to avoid translating I= Pv6 flows back to IPv4 if the destination is reachable over IPv6. = The proposed solution would significantly reduce the NAT64 utilizatio= n in the operator's network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-o= ptimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimi= zation-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464x= lat-optimization-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xla= t-optimization-02 Please note that it may take a couple of minutes from the t= ime of submission until the htmlized version and diff are available at tool= s.ietf.org. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privi= leged or confidential. The information is intended to be for the exclusive = use of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this informatio= n, even if partially, including attached files, is strictly prohibited and = will be considered a criminal offense. If you are not the intended recipien= t be aware that any disclosure, copying, distribution or use of the content= s of this information, even if partially, including attached files, is stri= ctly prohibited, will be considered a criminal offense, so you must reply t= o the original sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jul 19 03:57:41 2020 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 B59893A08A6 for ; Sun, 19 Jul 2020 03:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onkoVo4HEvjt for ; Sun, 19 Jul 2020 03:57:34 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6DECF3A0879 for ; Sun, 19 Jul 2020 03:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595156253; x=1595761053; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=SakZzSRk bfjTw1+Yd7vipGrAEA6V/3xhcbi+Gkp/JnM=; b=OPnzVaI9vjgpTtuzGRp4+wYQ bX7usYs1FTQ6WbKLhhaRy8OolLST89qWvWBfEzn/QbU4ynLhc7ZVB4u3hO/mDs/h Bv9qfDi8tbZu7cU3hGNUmKG2CiZzencm8QSSinO+5VJ6Dbu8/LTr4H2AcRKj45i/ cbjq4/2EoTzp2mIEzM4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 12:57:33 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 12:57:32 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000298959.msg for ; Sun, 19 Jul 2020 12:57:32 +0200 X-MDRemoteIP: 2001:470:1f09:495:a868:4c2e:4585:82c3 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sun, 19 Jul 2020 12:57:32 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 12:57:31 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 10:57:40 -0000 Actually, it is much simpler than that. Because we are looking for EAMT entries which also contain the FQDN, there = will be no match, so no optimization performed if the AAAA response doesn't= come timely. =20 =EF=BB=BFEl 18/7/20 12:01, "v6ops en nombre de Philip Homburg" escribi=C3=B3: >I don't think waiting helps anything. If there's packet loss and the >2nd AAAA never comes back, the client's TCP SYN to 192.0.2.1 will be >sent to the wrong IPv6 host. That can be fixed by deleting the entry upon timeout. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jul 19 07:18:45 2020 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 47B633A08B8 for ; Sun, 19 Jul 2020 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmLP_8Xe7RES for ; Sun, 19 Jul 2020 07:18:41 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id E9D9E3A08B7 for ; Sun, 19 Jul 2020 07:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595168319; x=1595773119; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=tHoGhZYQ LWehXwzApMODtrVIgAj+h5pJeRpiczreqMc=; b=FKGzxUrcD6sCkqzUgyBW1a+v 6wxsLbhECiPj5X9O9a+oZVQNEOnptj/89j7/DMs6Xxb5LeaQ0aJrBj4DOfybFyYr Tav8dSMCwQxSYeWJKyyHRVDByOOwz5I6l0WdOtAaxYdF5c1XqrVs8f8fA7iiYfrx 2HtcN+YJwgZKMBmmoKQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 16:18:39 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 16:18:38 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000299413.msg for ; Sun, 19 Jul 2020 16:18:37 +0200 X-MDRemoteIP: 2001:470:1f09:495:1cd4:2728:a834:1ea3 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sun, 19 Jul 2020 16:18:37 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 16:18:33 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 14:18:43 -0000 Hi Philip, =EF=BB=BFEl 17/7/20 17:05, "v6ops en nombre de Philip Homburg" escribi=C3=B3: >[Jordi] Good point. May be: > >"The CE DNS proxy MUST NOT return the answer to an A query until eithe= r an answe >r to the AAAA query has been received or the Resolution Delay has pass= ed" Yes, I think this is important. Otherwise small differences in DNS timi= ng may cause hard to diagnose bugs. Another suggestion is that if the AAAA query either gets a timeout or S= ERVFAIL then any existing EAMT entry for the corresponding IPv4 address should = be set to invalid. Then there is DNSSEC. For example, the AAAA lookup MUST/SHOULD/MAY be verified using DNSSEC local validation. (Or, the AD bit of the reply co= uld be used instead). A reply that fails DNSSEC validation MUST/SHOULD/MAY = not result in the creation of an EAMT entry (and MUST/SHOULD/MAY result in marking an exiting entry invalid) [Jordi] Yes both of those are also very good points. Maybe, we can summariz= e all those changes and some of my previous responses to Erik and Eduard in= the list with the text (tentative) that I'm adding at the end of this emai= l. One question that doesn't seem answer, what if the upstream resolver is doing DNS64. In that case an AAAA query would get an answer for an IPv4= -only service. Maybe it doesn't matter, because the mapping will be the same. Otherwise setting the CD flag in the query may help to get only 'real'= =20 AAAA records. [Jordi] This is already resolved by NOT creating an EAMT entry if only a sy= nthetized AAAA is received. Section 5.2.2: " Note that the NAT46/CLAT MUST already know the WKP or NSP being used in that network. If the response contains at least one IPv6 address not using the WKP/NSP, it means that the destination is IPv6-enabled (because at least one of the IPv6 addresses is not synthesized). This means that it is possible for the NAT46/CLAT, to create an Explicit Address Mapping" [Jordi] I'm still trying to tidy up all the text according to other inputs = and respond to them. Too soon to send a new version, but close ... Tentative changes: 5.2.2. Detection of IPv4-only hosts The goal is to ensure that only IPv4-only hosts are optimized. Towards that, the CE MUST use ARP and ND (and their relevant caches, if the information of a hosts has been already learnt) each time a new host starts a connection. If it is not possible to bind the same MAC address to both an IPv4 and IPv6 address, then the host is not IPv4-only (it may be IPv6-only or dual-stack), and MUST NOT be optimized. The CE MUST maintain a table of IPv4-only hosts and ensure that if any IPv4-only hosts become IPv6-enabled, it is properly handled. This mechanism to detect IPv4-only hosts has two drawbacks: 1. If a subscriber has intermediate dual-stack routers in between the IPv4-only host and the NAT46/CLAT, the IPv4-only hosts will be detected as dual-stack, so no optimization will be performed. This is not the most common scenario, as typically the devices that are more relevant to the optimization (in terms of those that generate more IPv4-only traffic) are directly attached to the CE, or in bridged interfaces. 2. If a host is dual-stack, but has some IPv4-only applications, because the host will be detected as dual-stack, none of the applications will be optimized. This is a good trade-off, considering the most important traffic to optimize is typically coming from real IPv4-only devices such as old SmartTVs/STBs. Furthermore, this avoid breaking other mechanisms present only in dual-stack hosts, such as Happy Eyeballs [RFC8305] and simplifies troubleshooting. It needs to be remarked that, if the detection of the IPv4-only host is done incorrectly (either not detecting it or by a false detection), the goal is that no harm is caused. In the worst case, optimization MUST NOT be performed. 5.2.3. Detection of IPv6-enabled service In the case of an IPv4-only detected host, the DNS proxy/stub resolver MUST actually perform an additional AAAA query, unless the information is already present in the Additional Section, as per Section 3 of [RFC3596]. Note that the NAT46/CLAT MUST already know the WKP or NSP being used in that network. If the response contains at least one IPv6 address not using the WKP/NSP, it means that the destination is IPv6-enabled (because at least one of the IPv6 addresses is not synthesized). This means that it is possible for the NAT46/CLAT, to create an Explicit Address Mapping ([RFC7757]). 5.2.4. CE DNS proxy responses In the case of an IPv4-only detected host, the CE DNS proxy MUST only return the answer to an A query once any of the following happens: 1. An answer to the AAAA query has been received. 2. A SERVFAIL has been received. 3. The "Resolution Delay" has passed. The Resolution Delay MUST be set to the same value (50 milliseconds) as indicated by Happy Eyeballs [RFC8305]. 5.2.5. Creation of EAMT entries An EAM Table (EAMT used for short, across the rest of this document) MUST be created/maintained automatically by the NAT46/CLAT, which is responsible to prioritize any available entries in the EAMT, versus the use of any synthetic AAAA. The EAMT entry MUST only be created if all the following conditions are met: 1. The source host is IPv4-only. 2. The DNS proxy is ready to return the A answer (according to Section 5.2.4). 3. There is at least one non-synthesized AAAA response. 4. If DNSSEC is available, the response has been locally validated or the AD bit has been set by a trusted resolver, as per [RFC3655]. This avoids a slight NAT64 overload and flapping between destination addresses (IPv4/IPv6), which may impact some applications, at the cost of a small extra delay for the initial communication setup, when the EAMT entry doesn't yet exist. Each EAMT entry MUST contain, the fields already described in [RFC7757] and a few new extensions (as per section 3.1 of [RFC7757]): 1. ID: EAMT Entry Index (optional). 2. MAC address: Identify the host to which this EAMT entry belongs. 3. Destination IPv4 address/prefix: By default, the prefix length is 32 bits. 4. Destination IPv6 address/prefix: By default, the prefix length is 128 bits. Only non-synthesized addresses are allowed. 5. TTL: It MUST be set to the minimum value from the AAAA/A RR pair. In normal conditions the TTL for both A and AAAA records, of a given FQDN, should be the same, so this ensures a proper behavior if there is any DNS mismatch. 6. FQDN: The one that originated the A query for this EAMT entry. Required in order to ensure a correct detection of cases such as the use of reverse-proxy with a single IPv4 address to multiple IPv6 addresses. 7. Valid/Stale/Invalid: When set to Stale, means that this EAMT entry MUST NOT be used for new connections. When set to Invalid, means that this EAMT entry can be deleted, unless the Auto/Static bit is also set. 8. Auto/Static: When set to 1, means that this EAMT entry has been manually/statically configured, for example by means of an explicit configuration (GUI, CLI, provisioning system, etc.). Note that allowing destination IPv4 and IPv6 prefixes, together with the Valid/Stale/Invalid and Auto/Static flags, allows manual explicit optimization and non-optimization configuration for specific parts of Internet. When a new EAMT entry is first automatically created, it is flagged as "Valid" and "Auto". If a subsequent A query, with a different FQDN, results in an IPv4 address that has already an EAMT entry and a different IPv6 address, it means that some reverse-proxy or similar functionality is being used by the IPv6-enabled service. In this case, the existing EAMT entry will be marked as "Stale". No new EAMT entry is created for that IPv4 address. Otherwise, the optimization will only allow to access the first set of IPv4/IPv6/FQDN, which may break the access to other FQDN that share the same IPv4 address and different IPv6 addresses. In this case the EAMT entry will still become "Invalid" according the TTL, which allows to re-enable optimization if a new query for the A record has changed the situation. For example, maybe the reverse- proxy has been removed, or there is now only a single device using it, so at the time being, the optimization is again possible without creating troubles to other hosts. An EAMT entry marked as "Stale" or "Invalid", only affects the relevant host. Other hosts have their own EAMT entries or they are using the regular NAT46/CLAT+NAT64 path (without the optimization). 5.2.6. Forwarding path via stateful NAT for existing EAMT entries Following this approach, if there is a valid EAMT entry, for a given pair of source-MAC-address/IPv4-destination, the IPv6-native path pointed by the IPv6 address of that EAMT entry, will take precedence versus the NAT64 path, so the traffic will not be forwarded to the NAT64. However, this is not sufficient to ensure that individual applications are able to keep existing connections. In many cases, audio and video streaming may use a single TCP connection lasting from minutes to hours. Instead, the CDN TTLs may be configured in the range from 10 to 300 seconds in order to allow new resolutions to switch quickly and to handle large recursive resolvers (with hundreds of thousands of clients behind them). Consequently, the EAMT entries MUST NOT be used directly to establish a forwarding path, but instead, MUST be used to create a stateful NAT entry for the 4-tuple for the duration of the session/connection. This means that to implement the optimization the NAT46 MUST be stateful. Typically stateful NAT46 are implemented by means of a stateful NAT44 (which often maybe hardware off-loaded), followed by a stateless NAT46. If the SoC/code is able to do stateless NAT46, this still could be used when the optimization is disabled. 5.2.7. Maintenance of the EAMT entries An EATM entry with the Auto/Static bit set, MUST NOT be automatically modified. An EAMT entry with the Auto/Static bit clear, MUST be set to Stale in case of: 1. TTL time-out. 2. Or the conditions for creation of the EAMT entry (Section 5.2.5) aren't longer met. Entries in Stale state MUST be set to Invalid once existing connections time-out. The Invalid EAMT entries MUST be deleted, unless the Auto/Static bit is set. This allows users/operators to set explicit rules for diagnostics or resolution of issues in special situations. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jul 19 07:18:49 2020 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 CC0AD3A08B7 for ; Sun, 19 Jul 2020 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAyR1sACaBgM for ; Sun, 19 Jul 2020 07:18:41 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id DC2903A08B6 for ; Sun, 19 Jul 2020 07:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595168319; x=1595773119; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=sEnYzb8i6n1BjO4itttb4Ubv3flXGclzM9 AMzfMuZys=; b=pLgfzXfZ4n9rj3l+Hw5TLq6HLNHk+7mGaLXmi65Qa6IynKtRld DBApDZZ1X6a+LW2IsDbz5zAQ6XRSlm8CSEhwN5sj6KtMekwKZ7RU3GoFGTK/U5fa mtkGg+ReCh+Jma94G2N6mV25ywrv5x+kR+O6HZ5zDLvNYyMvXiIot20y0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 16:18:39 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 16:18:38 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000299414.msg for ; Sun, 19 Jul 2020 16:18:37 +0200 X-MDRemoteIP: 2001:470:1f09:495:1cd4:2728:a834:1ea3 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Sun, 19 Jul 2020 16:18:37 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 16:18:36 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <87EA9471-5BA1-4E3F-A4DE-4ECB48452C02@consulintel.es> Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals References: <7d12c5b6b855488fa6af9b75085c3385@huawei.com> In-Reply-To: <7d12c5b6b855488fa6af9b75085c3385@huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678020316_980063361" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 14:18:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678020316_980063361 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Eduard, Tks a lot! I just sent a tentative text as part of the responses to Philip. See below,= anyway. =20 El 18/7/20 9:37, "Vasilenko Eduard" escribi= =C3=B3: =20 Hi Jordi, I have clarified a little below. Use this version. Eduard From: Vasilenko Eduard=20 Sent: 17 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 23:27 To: 'JORDI PALET MARTINEZ' Cc: 'V6 Ops List' Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive= proposals =20 Hi Jordi, Sorry to overload you again. =20 [Jordi] Actually a pleasure to get so many good inputs! =20 Erik and Jen were right: draft does introduce new attack vectors. Because h= osts are =E2=80=9Csharing security fate=E2=80=9D =E2=80=93 they have proved= it in many examples. Let=E2=80=99s disjoin hosts back. =20 1. I propose to stop this guess-work who is IPv4-only and who is not.= DNS query timeout synchronization between Happy Eyeball of particular host= implementation and CLAT-NG (CLAT Next Generation) =E2=80=93 is a very reli= able path to disaster. What if somebody would change this timeout in next s= oftware release? What if timeout are very different on current hosts? (I am= sure about Android and iOS difference) I propose just to look to ND and ARP caches: if particular MAC has only bin= ding to IPv4 and the same MAC does not have binding to IPv6, then it is our= =E2=80=9Coptimization case=E2=80=9D. [Jordi] Yep, this seems to be a very good solution, even if it has a few dr= awbacks, is a good trade-off.=20 =20 2. NAPT44 does generate many issues that has been discussed on this m= ailing list. I propose to return to stateless nature of CLAT translation. Let=E2=80=99s = create separate EAMT table per every IPv4-only host (that has been discover= ed as eligible on the previous step of cache comparison). Then translate it as today for CLAT (IPv4-Embedded IPv6 Address =E2=80=93 c= lause 2 RFC 6052, but RFC 6877 clause 6.3 states that only /64 version shou= ld be used). We could reuse exactly the same IPv6 address that we are using now for traf= fic to PLAT and prepare it by exactly the same rules. [Jordi] Not sure if I got it correctly. I don=E2=80=99t think so. If we use= the addresses as in a non-optimized CLAT, they are synthetized, so they wi= ll naturally follow the PLAT path =E2=80=93 this is what we try to avoid. T= he IPv6 source address after the CLAT is not relevant for the optimization = (no impact). IPv4 source would be visible (inside IPv6 source), but tracking would be di= fficult because would be millions of such 192.168.1.x. I do not believe tha= t any randomization is needed (could be added if somebody would insist). Technically, it could be one EAMT, just it should have source IPv4 as the k= ey field. EAM table does not need IPv4 prefix (of LAN subnet). CLAT translation would become stateless again. But in general CLAT would be= stateful, because decision about destination IPv6 (PLAT or real Internet r= esource) should be done almost per-flow (for source IPv4 + destination IPv4= ) that was lucky to create a state in EAMT.=20 =20 [Jordi] Exactly. We need state because we need to =E2=80=9Cdisconnect=E2=80= =9D the DNS TTLs form the hosts applications connections. =20 3. The way how we would search for proper destination IPv6 =E2=80=93 = we could keep as it is in the current version of the draft (query by proxy = DNS, just it would be personal query for every host). We could reuse now Happy Eyeball (RFC 8305) for double DNS requests with al= l associated timers, because FQDN request is personal now (just for one App= of one Host). Part of HEv2 could be on proxy CPE (on behalf of IPv4 host). [Jordi] No need for that. We only optimize IPv4-only hosts. Further, trying= to change HE is a =E2=80=9Cno way=E2=80=9D. =20 4. If DNS (together with EAM record) would expire, but host would not= pay attention to DNS TTL (application does not want to interrupt user sess= ion =E2=80=93 that is proper behavior), then host could initiate new EAM re= cord that could be resolved to different IPv6. It is not good idea to solve= this problem by timers. I propose to use EAM records forever (do not pay attention to DNS TTL timer= ), EAM record should be deleted only if (1) host would ask again for the sa= me FQDN, or (2) ARP entry would be deleted =E2=80=93 then all EAM entries r= elated to this host should be deleted (in the case of static ARP it means = =E2=80=93 (2) would never happen). We would replicate host behavior: if he would ask =E2=80=93 we would refres= h, if he does violate protocol =E2=80=93 we would do the same (for him). We= should be transparent for him. [Jordi] I don=E2=80=99t think this is good, because that will mean having a= bigger EAMT than actually needed. We need to delete entries as soon as pos= sible. The =E2=80=9Cstale=E2=80=9D status, as suggested by Erik, resolves t= he issue. Anyway, I still need to think and work more on this text. =20 Good things: =C2=B7 It should resolve NAT-traversal issues, because IPv4:IPv6=3D= 1:1. Any global IPv6 could connect to this Private IPv4 (it would see it as= IPv4-Embedded IPv6 Address). If IPv6 persistent (recommended for FBB), the= n subscriber could organize Web server on this private IPv4, it would be av= ailable for the whole Internet [Jordi] I don=E2=80=99t see this. It is only possible using IPv6, not IPv4. =20 =C2=B7 No possibility for one IPv4 host to hijack connection of oth= er IPv4 host (including the situation when one host pointed to foreign DNS = =E2=80=93 his FQDN request would be just not visible =E2=80=93 EAM record f= or him would not be created) =C2=B7 If any strange configuration on server side (TLS SNI demux a= gainst IPv6 address demux, IPv4 only server share A record with DualStack s= erver, clever CDN clusters configuration - many presented by Erik) =E2=80= =93 then client would behave like single dual stack client. If such client = would not be served properly =E2=80=93 then Server owner would have a big t= rouble anyway, because many other DualStack client world-wide =C2=B7 If DNS would resolve to AAAA, but no IP connectivity =E2=80= =93 then again: other DualStack clients would have the big trouble =C2=B7 Particular EAMT record could stick to only 1 destination IPv= 6 address, despite DNS Load Balancing, but it would be exactly the same if = host would ask by itself, our CLAT-NG is transparent and personal =C2=B7 If user would modify DNS on CPE =E2=80=93 it is fine =E2=80= =93 we would try to get AAAA from DNS server preferred by him. No AAAA answ= er -> no EAM record -> traffic would go to PLAT -> no problem =C2=B7 DNS poisoning would affect only 1 host =E2=80=93 exactly the= same situation as without any optimization =C2=B7 I do not see any problem with DNSSEC too =E2=80=93 it could = additionally check DNS answers =20 Currently discussed in the draft (and not fixed): =C2=B7 Only IPv6 backbone is down or link degraded (IPv4 is fine),-= but we push traffic to IPv6 onlyL =20 One visible restriction: =C2=B7 If subscriber would have big routed network inside, then ARP= entry would not be visible on CPE. Next hop router would be Dual Stack. In= such case: EAMT entry would not be created =E2=80=93 traffic would go to P= LAT =20 [Jordi] yes to all those points =20 I have looked carefully to all comments of Jen, Erik, and Philip again. I h= ave not found any holes left. Primarily, because in this proposal we are mi= micking hosts individually =E2=80=93 we are just =E2=80=9Cfully transparent= in both directions=E2=80=9D. =20 [Jordi] I=E2=80=99m re-reading anyway, everything and making sure we aren= =E2=80=99t missing any issue before sending a new version =E2=80=A6 =20 =20 Eduard ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3678020316_980063361 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Eduard,

Tks a lot!

I just sent a ten= tative text as part of the responses to Philip. See below, anyway.

 

El 18/7= /20 9:37, "Vasilenko Eduard" <vasilenko.eduard@huawei.com> escribi=C3=B3:

 

Hi Jordi,

=

I have clarified a l= ittle below. Use this version.

Eduard

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>From: Vasilenko Eduard
= Sent: 17 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 23:27
To: 'JOR= DI PALET MARTINEZ' <jordi.palet@consulintel.es>
Cc: 'V6 Ops= List' <v6ops@ietf.org>
Subject: [v6ops] draft-ietf-v6ops-4= 64xlat-optimization-02 - some disruptive proposals

 

Hi Jordi,

Sorry to overload you again.

 

[Jordi] Actually a pleasure to get so many good inputs!=

 

Erik and Jen were right: draft does introduce new attack vectors. Because= hosts are =E2=80=9Csharing security fate=E2=80=9D =E2=80=93 they have prov= ed it in many examples. Let=E2=80=99s disjoin hosts back.=

 

1.       I propose to stop t= his guess-work who is IPv4-only and who is not. DNS query timeout synchroni= zation between Happy Eyeball of particular host implementation and CLAT-NG = (CLAT Next Generation) =E2=80=93 is a very reliable path to disaster. What = if somebody would change this timeout in next software release? What if timeout are v= ery different on current hosts? (I am sure about Android and iOS difference= )
I propose just to look to ND and ARP caches: if particular MAC has = only binding to IPv4 and the same MAC does not have binding to IPv6, then i= t is our =E2=80=9Coptimization case=E2=80=9D.

[Jordi] Yep, this seems to be a very good solution, even if it has a fe= w drawbacks, is a good trade-off.

 =

2.       NAPT44 does generate= many issues that has been discussed on this mailing list.
I propose = to return to stateless nature of CLAT transla= tion. Let=E2=80=99s create separate EAMT table per every IPv4-only h= ost (that has been discovered as eligible on the previous step of cache= comparison).
Then translate it as today for CLAT (IPv4-Embedded IPv6 = Address =E2=80=93 clause 2 RFC 6052, but RFC 6877 clause 6.3 states that on= ly /64 version should be used).
We could reuse exactly the same IPv6 address that we are using no= w for traffic to PLAT and prepare it by exactly the same rules.=

[Jordi] Not sure if I got it correctly. I don=E2=80=99t t= hink so. If we use the addresses as in a non-optimized CLAT, they are synth= etized, so they will naturally follow the PLAT path =E2=80=93 this is what = we try to avoid. The IPv6 source address after the CLAT is not relevant for= the optimization (no impact).


IPv4 source would be visi= ble (inside IPv6 source), but tracking would be difficult because would be = millions of such 192.168.1.x. I do not believe that any randomization is ne= eded (could be added if somebody would insist).
Technically, it c= ould be one EAMT, just it should have source IPv4 as the key field. EAM tab= le does not need IPv4 prefix (of LAN subnet).
CLAT translation would become stateless again. But in general CLAT woul= d be stateful, because decision about destination IPv6 (PLAT or real Intern= et resource) should be done almost per-flow (for source IPv4 + destination = IPv4) that was lucky to create a state in EAMT.

 = ;

[Jordi] Exactly. We need state because we need to= =E2=80=9Cdisconnect=E2=80=9D the DNS TTLs form the hosts applications conn= ections.

 

3.  &= nbsp;    The way how we would search for proper des= tination IPv6 =E2=80=93 we could keep as it is in the current version of th= e draft (query by proxy DNS, just it would be personal query for every host= ).
We could reuse now Happy Eyeball (RFC 8= 305) for double DNS requests with all associated timers, because FQDN reque= st is personal now (just for one App of one Host). Part of HEv2 could be on proxy CPE (on behalf = of IPv4 host).

[Jordi] No need for that. We only optimize IPv4-only hosts. Furthe= r, trying to change HE is a =E2=80=9Cno way=E2=80=9D.

=

 

4.       = If DNS (= together with EAM record) would expire, but host would not pay attention to= DNS TTL (application does not want to interrupt user session =E2=80=93 tha= t is proper behavior), then host could initiate new EAM record that could b= e resolved to different IPv6. It is not good idea to solve this problem by = timers.
I propose to use EAM records forever (do not pay attention to= DNS TTL timer), EAM record should be deleted only if (1) host would as= k again for the same FQDN, or (2) ARP entry would be deleted =E2=80=93 then= all EAM entries related to this host should be deleted (in the case of sta= tic ARP it means =E2=80=93  (2) would never happen).
We would repli= cate host behavior: if he would ask =E2=80=93 we would refresh, if he does = violate protocol =E2=80=93 we would do the same (for him). We should be tra= nsparent for him.

[Jordi] I don=E2=80=99t= think this is good, because that will mean having a bigger EAMT than actua= lly needed. We need to delete entries as soon as possible. The =E2=80=9Csta= le=E2=80=9D status, as suggested by Erik, resolves the issue. Anyway, I sti= ll need to think and work more on this text.

=  

Good things:

=C2=B7=      =     It should resolve NAT-traversal issues, because IP= v4:IPv6=3D1:1. Any global IPv6 could connect to this Private IPv4 (it would= see it as IPv4-Embedded IPv6 Address). If IPv6 persistent (recommended for= FBB), then subscriber could organize Web server on this private IPv4, it w= ould be available for the whole Internet

[Jordi] I don=E2=80=99t see this. It is only pos= sible using IPv6, not IPv4.

 <= /span>

=C2=B7   &nbs= p;     No possibility for one IPv4 host to hijack= connection of other IPv4 host (including the situation when one host point= ed to foreign DNS =E2=80=93 his FQDN request would be just not visible =E2= =80=93 EAM record for him would not be created)

=C2=B7      &= nbsp;  If any strange configuration on server side (TLS SNI= demux against IPv6 address demux, IPv4 only server share A record with Dua= lStack server, clever CDN clusters configuration - many presented by Erik) = =E2=80=93 then client would behave like single dual stack client. If= such client would not be served properly =E2=80=93 then Server owner would= have a big trouble anyway, because many other DualStack client world-wide<= /span>

=C2=B7 &nbs= p;       If DNS would resolve to AAAA, = but no IP connectivity =E2=80=93 then again: other DualStack clients would = have the big trouble

=C2=B7         <= /span>Particula= r EAMT record could stick to only 1 destination IPv6 address, despite DNS L= oad Balancing, but it would be exactly the same if host would ask by itself= , our CLAT-NG is transparent and personal

=C2=B7       = ;  If user would modify DNS on CPE =E2=80=93 it is fine =E2=80= =93 we would try to get AAAA from DNS server preferred by him. No AAAA answ= er -> no EAM record -> traffic would go to PLAT -> no problem

=C2=B7  &n= bsp;      DNS poisoning would affect only 1 = host =E2=80=93 exactly the same situation as without any optimization

=C2=B7   = ;      I do not see any problem with DNSSEC= too =E2=80=93 it could additionally check DNS answers

 

Currently discussed in the draft (and not fixed):

=C2=B7       = ;  Only IPv6 backbone is down or link degraded (IPv4 is fine),- = but we push traffic to IPv6 onlyL

 

One visible restriction:

=C2=B7         If subscrib= er would have big routed network inside, then ARP entry would not be visibl= e on CPE. Next hop router would be Dual Stack. In such case: EAMT entry wou= ld not be created =E2=80=93 traffic would go to PLAT

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> 

[Jordi] yes to a= ll those points

 

I have looked carefully to all comments of Jen, Erik,= and Philip again. I have not found any holes left. Primarily, because in t= his proposal we are mimicking hosts individually =E2=80=93 we are just =E2= =80=9Cfully transparent in both directions=E2=80=9D.

<= p class=3DMsoNormal>&= nbsp;

[Jordi] I=E2=80=99m re-reading anyway, everyt= hing and making sure we aren=E2=80=99t missing any issue before sending a n= ew version =E2=80=A6

 

 <= o:p>

Eduard<= /p>


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3678020316_980063361-- From nobody Sun Jul 19 13:49:28 2020 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 BB0B63A0932 for ; Sun, 19 Jul 2020 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmEWZh98rCPG for ; Sun, 19 Jul 2020 13:49:22 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 183693A092E for ; Sun, 19 Jul 2020 13:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595191760; x=1595796560; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=BmUtTMRPl36GIR1sg5q3FLfbtkzYTtuRDC Td2QBcyA4=; b=u+jfUVgyaxkp55SiT2O6ptqiyrElL1H5LUKq+ELPP5ssNmpF46 t9wMHHAllVAD2715o7UHAlQdw9/SsM897rluhzY4TDsb/+9p2F/taAVF0aRbxXLS kGU0NVftqhgxeiEMZJY+Ufif4yp8H/XH6o+KXpWsGsANuVtv6xgkd+rDY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 22:49:20 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 22:49:18 +0200 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000303560.msg for ; Sun, 19 Jul 2020 22:49:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:c034:405:afe5:cbb X-MDHelo: [10.10.10.131] X-MDArrival-Date: Sun, 19 Jul 2020 22:49:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 22:49:16 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: Thread-Topic: draft-ietf-v6ops-464xlat-optimization-02 general concerns References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678043756_288862498" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 20:49:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678043756_288862498 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =EF=BB=BFHi Erik, =20 I think that the changes that I=E2=80=99ve introduced with the Eduard=E2=80= =99s idea of doing an alternative detection of the IPv4-only host, together= with having the MAC address in the EAMT entry and the =E2=80=9CStale=E2=80= =9D state, solve most of the issues: Only IPv4-only hosts are now using the optimization. We keep the EAMT entries until the connection is gone. HE is not affected. IPv4 hosts that use vendor defined DNSs (such as 8.8.8.8), will not take ad= vantage of the optimization, because they don=E2=80=99t reuse existing entr= ies =E2=80=93 unless they are manually configured by the user or operator. =20 We lose applying the optimization to specific applications=C2=A0 (i.e., a d= ual-stack host running an IPv4 only app), but because the main goal is the = =E2=80=9Cbig=E2=80=9D traffic generators (SmartTVs/STBs), I think this is j= ust fine. =20 I=E2=80=99m responding in-line to some points. =20 El 17/7/20 17:57, "Erik Nygren" escribi=C3=B3: =20 At the high-level, not causing problems relies heavily on assumptions about= client behavior, both for STBs/SmartTVs as well as for other devices in the home. If the EA= MT entries also contained the internal client IPv4 address then it might make it so th= at at least devices couldn't interfere with each other, but absent that there = is also plenty of possibility for wacky interactions. The more we look for corner-= cases that will cause production problems, the more I suspect we'll find. On some of the assumptions: =20 * We know clients cache DNS lookups for some amount of time past their TTL. (ie, a client will do a "gethostbyname" and then just keep using the res= ult for multiple connections). CDNs have to mostly deal with this (eg, wait= a few=20 hours after removing an IP from being handed out before assuming the rate of new connections drops to an acceptable level). I suspect some of the = STBs/SmartTVs may be particularly bad about this (eg, within a viewing session). =20 This generally works fine today and no one notices. But if entries drop= =20 out of the EAMT cache after 20 seconds but clients keep using them=20 for 15 minutes, then it is likely another lookup for another hostname (perhaps from another device) would have created another EAMT entry that would have marked the first invalid but doesn't see it due to the ea= rly expiry. Keeping EAMT entries in a "stale" state for some amount of time following= TTL expiry (an hour or two?) where they can't be used but can be transitioned to inv= alid=20 and also kept in invalid for an hour or two would help. The question is = whether this is too much state and if it would help enough. =20 [Jordi] I=E2=80=99m not sure if instead of defining time is sufficient to w= ait for the connection to die. If it never dies, it will be there for as mu= ch time as the CE needs to clean up entries, because lack of memory. We may= need to define this in a much better way. Note however, that I think the n= umber of devices that are IPv4 only and the number of connections they stab= lish, in a typical subscriber, should not be a big problem. A couple of Sma= rtTVs and STBs, may be some other devices. Are we talking about a few tens = of entries? =20 * The problem with the "user changes DNS" is that it is not just the user. There are plenty of devices in the field that do this today, including SmartTV/STB platforms but also desktops/laptops.=20 In-particular, Chromecast-based devices (a major STB platform)=20 use their own resolver of 8.8.8.8 and 8.8.4.4. It would not surprise me (but I haven't tested) that Chromecast does synchronous A/AAAA lookups in a way that may break the "IPv4-only detect= ion". Apple has also announced that starting this Fall, apps will be able=20 specify a DoH server to use (and it's possible this might apply to Apple= TV as well?). Chrome and Firefox also now use DoH servers outside of the home=20 in a bunch of places. The whole DoH/ADD situation has gotten very messy in the past year. If one dual-stacked device in the home using Do= H get requests for IPv4-only sites hijacked and sent to an IPv6 address, that's going to be a real problem. Keying the EAMT entry by client IP= might help, but won't help in the iOS/OSX case where apps can specify=20 their own DoH server. =20 [Jordi] We don=E2=80=99t create/reuse EAMT entries for those cases, neither= use DNS for the detection. Clearly, we will not optimize those,=C2=A0 but = we *don=E2=80=99t need to* because I expect devices being updated to suppor= t DoH, etc., are also supporting IPv6, specially Apple case and also Chrome= cast/Android. =20 More comments inline below on topics not covered above... =20 =20 On Fri, Jul 17, 2020 at 5:40 AM JORDI PALET MARTINEZ wrote: [Jordi] My goal has been to ensure that the optimization doesn=E2=80=99t br= eak any case, and especially when the site only offers A records. Unless I= =E2=80=99m missing something, I think this is perfectly resolved in 5.2.2, = because the EAMT entry will be only created if the site is only IPv4-only. =20 [Erik] Ah, I think the invariant here is that DNS64 will always guarantee = that *everything* has a AAAA record available to the CPE resolver. If there are ever cases where no AAAA is re= turned (eg, where the CLAT would get used) then problems can show up because "IPv4-only" (no AAAA record) entries won'= t be validated against the EAMT table and won't cause EAMT entries to get created. It may be that we should be c= reating "invalid" EAMT entries=20 for {IPv4,FQDN} pairs where no AAAA is returned. Also, we should be invali= dating EAMT entries=20 when an IPv4 address in an EAMT entry is returned for a different FQDN. =20 [Jordi] That was solved since the first version. We only create EAMT entrie= s if we have an AAAA and is not using the NAT64 prefix (so we make sure isn= =E2=80=99t synthesized). I=E2=80=99ve added more text to make it more expli= cit, and not using. I don=E2=80=99t see if I=E2=80=99m missing something, b= ut I believe there is no way to create an EAMT which doesn=E2=80=99t really= have the right set of parameters (FQDN, IPv4, IPv6). We are also already s= etting to stale EAMT entries if a new FQDN starts to use a different IPv6 w= ith the same IPv4, so will not be longer optimized for new connections, but= the existing one is kept. =20 =20 * some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6 address for = demuxing IPv6 traffic (both to determine which cert to serve). This means = that the IPv4:IPv6 associations are one to many and using the wrong one wil= l result in cert errors. =20 [Jordi] This was discussed in a previous version (I recall it was after the= presentation in Prague) and resolved by incorporating the FQDN in the EAMT= entry and a section 5.2.4, which forces the forwarding path via a stateful= NAT44. =20 * Some CDNs may use cluster A for IPv4 and cluster B for IPv6 for one custo= mer/tenant, but then cluster A for IPv4 and cluster C for a different custo= mer/tenant. An stale or invalid association will result in going to the wr= ong cluster which may not be able to serve the request properly. [Jordi] Same as the previous one. Because the EAMT entry is created by ever= y CE, the association between a given IPv4 and IPv6 FQDN/addresses is done = the same way as if the same CE is actually dual-stack instead of IPv6-only.= If I got it correctly, in a CDN, any change in terms of what cluster is se= rving what, depends on DNS TTLs and maybe routing, right? If that=E2=80=99s= the case, routing is transparent because the entries are created in each C= E, and to the CDN they appear as a dual-stack eyeball. Similarly, we rely i= n the CDN provided TTLs. =20 =20 [Erik] My question for both of these is if we should provide some context = or examples in the doc to explain the invariants and things that must be tested for? While these = conversations happened on-list, having summaries of the risks (and what is being relied on to mitigate them= ) seems like it may be valuable in an Informational draft. =20 [Jordi] Yes, no problem on that. I=E2=80=99m happy to have more examples. W= e first need to make sure that the =E2=80=9Cnew direction=E2=80=9D is appro= priate so not to lose right track. =20 =20 Another area not discussed is clients caching DNS lookups well past their TTL. This is fairly common in some clients (eg, some Java versions) which could result in entries getting expired from the EAMT but then used with a new association that should be invalid but wasn't detected as such as the first client is caching well past the expiry.. [Jordi] I=E2=80=99m confused here. =20 You mean a client ignoring DNS TTLs ? This could actually be a problem with= out the optimization. If the CDN is changing the IPv4 or IPv6 addresses, bu= t the client is still using them, the content will be unreachable or someth= ing different served, right? So, the optimization is not the problem here i= t is a broken client already =E2=80=A6 =20 Note that if the EAMT expired and the client tries to use it again, the EAM= T entry will be re-created with the new (correct) information from the CDN = DNSs, so we may be potentially solving the broken client problem. If the EA= MT, for whatever reason is not recreated, the optimization will not be used= , so the client will be still doing the =E2=80=9Ccorrect=E2=80=9D thing acc= ording to its expected behavior (non-optimized NAT46+NAT64) =E2=80=93 wheth= er it is a broken behavior or not. =20 The case is: =20 1) a.example.com (TTL 20s) is resolved but cached by App A for 30 minutes 2) Five minutes later, b.example.com is resolved (TTL 600s) is resolved an = EAMT entry is created=20 (but shares an IPv4 address with a.example.com but a different IPv6 addr= ess) 3) Two minutes later, the IPv4 address from a.example.com gets used (past t= he DNS TTL)=20 and will now use the IPv6 EAMT entry for b.example.com (which breaks). =20 Does this help clarify? While you could argue this client is 'broken", ane= cdotal experience is that this is a very common behavior for some client software that server= s already need to work around by padding operational actions for an hour or two past = the DNS TTL. =20 [Jordi] No, this can=E2=80=99t happen. Now even less with the new way (stal= e status, entries per host, no duplicate entries with the same IPv4). Even = if your example is the same host, a.example.com will be optimized, but b an= d c will not. Further when b happens, a.example.com will become stale (I=E2= =80=99m not sure if this is any longer needed =E2=80=A6 I need to double-th= ink about that). =20 Erik =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3678043756_288862498 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

=EF=BB=BF<= span lang=3DEN-US style=3D'font-size:12.0pt'>Hi Erik,

 

I think = that the changes that I=E2=80=99ve introduced with the Eduard=E2=80=99s ide= a of doing an alternative detection of the IPv4-only host, together with ha= ving the MAC address in the EAMT entry and the =E2=80=9CStale=E2=80=9D stat= e, solve most of the issues:

  1. Only IPv4-only hosts are now using the optimizatio= n.
  2. We keep the EAMT entries until the connection is= gone.
  3. HE is not affected.
    4. = IPv4 hosts that use vendor defined DNSs (such as 8.8.8.8), will not take ad= vantage of the optimization, because they don=E2=80=99t reuse existing entr= ies =E2=80=93 unless they are manually configured by the user or operator.<= o:p>

 

<= p class=3DMsoNormal>We lose applying the optimization to specific application= s=C2=A0 (i.e., a dual-stack host running an IPv4 only app), but because the= main goal is the =E2=80=9Cbig=E2=80=9D traffic generators (SmartTVs/STBs),= I think this is just fine.

&n= bsp;

I=E2=80=99m responding in-line to s= ome points.

 

El 17/7/20= 17:57, "Erik Nygren" <erik+ietf@nygren.org> escribi=C3=B3:

 

At the high-level, not causing pro= blems relies heavily on assumptions about client behavior,

both for STBs/SmartTVs as well as fo= r other devices in the home.  If the EAMT entries

also contained the internal client IPv= 4 address then it might make it so that

at least devices couldn't interfere with each other, bu= t absent that there is also

plenty of possibility for wacky interactions.  The more we loo= k for corner-cases

t= hat will cause production problems, the more I suspect we'll find.

On some of the assumptions:

 

* We know clients cache DNS lookups for some amount of time past thei= r TTL.

   = (ie, a client will do a "gethostbyname" and then just keep using = the result

 &nb= sp; for multiple connections).  CDNs have to mostly deal with this (eg= , wait a few

 = hours after removing an IP from being handed out before assuming the rate<= o:p>

  of new connec= tions drops to an acceptable level).  I suspect some of the STBs/Smart= TVs

  may be pa= rticularly bad about this (eg, within a viewing session).  =

  This generally works fi= ne today and no one notices.  But if entries drop

  out of the EAMT cache after 20 = seconds but clients keep using them

  for 15 minutes, then it is likely another lookup fo= r another hostname

&= nbsp; (perhaps from another device) would have created another EAMT entry

  that would hav= e marked the first invalid but doesn't see it due to the early expiry.=

  Keeping EAMT entr= ies in a "stale" state for some amount of time following TTL expi= ry

  (an hour o= r two?) where they can't be used but can be transitioned to invalid

  and also kept in in= valid for an hour or two would help.  The question is whether

<= span style=3D'font-family:"Tahoma",sans-serif'>  this is too much stat= e and if it would help enough.

 

[Jordi] I=E2=80=99m not sure if instead of d= efining time is sufficient to wait for the connection to die. If it never d= ies, it will be there for as much time as the CE needs to clean up entries,= because lack of memory. We may need to define this in a much better way. N= ote however, that I think the number of devices that are IPv4 only and the = number of connections they stablish, in a typical subscriber, should not be= a big problem. A couple of SmartTVs and STBs, may be some other devices. Are we talkin= g about a few tens of entries?

 

* The problem with the "user changes DN= S" is that it is not just the user.

   There are plenty of devices in the field = that do this today, including

   SmartTV/STB platforms but also desktops/laptops.

   In-partic= ular, Chromecast-based devices (a major STB platform)

   use their own resolver of= 8.8.8.8 and 8.8.4.4.

   It would not surprise me (but I haven't tested) that Chromec= ast does

  = ; synchronous A/AAAA lookups in a way that may break the "IPv4-only de= tection".

&nb= sp;  Apple has also announced that starting this Fall, apps will be ab= le

   spe= cify a DoH server to use (and it's possible this might apply to AppleTV as = well?).

  = Chrome and Firefox also now use DoH servers outside of the home

   in a bunch of pl= aces.  The whole DoH/ADD situation has gotten very

   messy in the past year.&n= bsp; If one dual-stacked device in the home using DoH

=

   get requests for IPv4-only s= ites hijacked and sent to an IPv6 address,

=

   that's going to be a real problem. = ;   Keying the EAMT entry by client IP might

   help, but won't help in t= he iOS/OSX case where apps can specify

   their own DoH server.

 

[Jordi] We don= =E2=80=99t create/reuse EAMT entries for those cases, neither use DNS for t= he detection. Clearly, we will not optimize those,=C2=A0 but we *don=E2= =80=99t need to* because I expect devices being updated to support DoH,= etc., are also supporting IPv6, specially Apple case and also Chromecast/A= ndroid.

 

More comments inline below on top= ics not covered above...

 

 

On Fri, Jul 17, 2020 at 5:40 AM JORDI PA= LET MARTINEZ <jordi.palet@= consulintel.es> wrote:

= [Jordi] My goal has been to e= nsure that the optimization doesn=E2=80=99t break any case, and especially = when the site only offers A records. Unless I=E2=80=99m missing something, = I think this is perfectly resolved in 5.2.2, because the EAMT entry will be= only created if the site is only IPv4-only.

 

[Erik]&= nbsp; Ah, I think the invariant here is that DNS64 will always guarantee th= at *everything* has a AAAA record

available to the CPE resolver.  If there are ever cases= where no AAAA is returned (eg, where the CLAT would get used)

then problems can show up becaus= e "IPv4-only" (no AAAA record) entries won't be validated against= the EAMT table

and= won't cause EAMT entries to get created.  It may be that we should be= creating "invalid" EAMT entries

for {IPv4,FQDN} pairs where no AAAA is returned.&nb= sp; Also, we should be invalidating EAMT entries

when an IPv4 address in an EAMT entry is retu= rned for a different FQDN.

 

[Jordi] That was solved since the first version.= We only create EAMT entries if we have an AAAA and is not using the NAT64 = prefix (so we make sure isn=E2=80=99t synthesized). I=E2=80=99ve added more= text to make it more explicit, and not using. I don=E2=80=99t see if I=E2= =80=99m missing something, but I believe there is no way to create an EAMT = which doesn=E2=80=99t really have the right set of parameters (FQDN, IPv4, = IPv6). We are also already setting to stale EAMT entries if a new FQDN star= ts to use a different IPv6 with the same IPv4, so will not be longer optimi= zed for new connections, but the existing one is kept.

 

 

* some CDNs use TLS SNI for demuxing IPv4 traffic but the IPv6= address for demuxing IPv6 traffic (both to determine which cert to serve).  This means that the IPv4:IPv= 6 associations are one to many and using the wrong one will result in cert = errors.

 

[Jordi] This was discussed in a previous ver= sion (I recall it was after the presentation in Prague) and resolved by inc= orporating the FQDN in the EAMT entry and a section 5.2.4, which forces the= forwarding path via a stateful NAT44.

 

* Some CDN= s may use cluster A for IPv4 and cluster B for IPv6 for one customer/tenant= , but then cluster A for IPv4 and cluster C for a different customer/tenant= .  An stale or invalid association will result in going to the = wrong cluster which may not be able to serve the request properly.

[Jordi] Same as the previous one. Because the EAMT entry is created by e= very CE, the association between a given IPv4 and IPv6 FQDN/addresses is do= ne the same way as if the same CE is actually dual-stack instead of IPv6-on= ly. If I got it correctly, in a CDN, any change in terms of what cluster is= serving what, depends on DNS TTLs and maybe routing, right? If that=E2=80= =99s the case, routing is transparent because the entries are created in ea= ch CE, and to the CDN they appear as a dual-stack eyeball. Similarly, we re= ly in the CDN provided TTLs.

<= /blockquote>

&nb= sp;

 

[Erik]  My = question for both of these is if we should provide some context or examples= in the doc

to expla= in the invariants and things that must be tested for?  While these con= versations happened on-list,

having summaries of the risks (and what is being relied on to miti= gate them) seems like it may be valuable

in an Informational draft.

 

[Jordi]= Yes, no problem on that. I=E2=80=99m happy to have more examples. We first= need to make sure that the =E2=80=9Cnew direction=E2=80=9D is appropriate = so not to lose right track.

 

 

Another area not discussed is clients caching DNS loo= kups well past
their TTL.  This is fairly common in some clients (eg, some J= ava versions)
which could result in entries getting expired from the EAM= T but then used
with a new association that should be invalid but wasn't= detected as such
as the first client is caching well past the expiry..<= o:p>

[Jordi] I=E2=80=99m confused here.

 

You mean a client ignoring DNS TTLs ? This could actually be = a problem without the optimization. If the CDN is changing the IPv4 or IPv6= addresses, but the client is still using them, the content will be unreach= able or something different served, right? So, the optimization is not the = problem here it is a broken client already =E2=80=A6

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto;margin-left:35.4pt'>&nbs= p;

Note that if the EAMT expired and the client tries to= use it again, the EAMT entry will be re-created with the new (correct) inf= ormation from the CDN DNSs, so we may be potentially solving the broken cli= ent problem. If the EAMT, for whatever reason is not recreated, the optimiz= ation will not be used, so the client will be still doing the =E2=80=9Ccorr= ect=E2=80=9D thing according to its expected behavior (non-optimized NAT46+= NAT64) =E2=80=93 whether it is a broken behavior or not.<= /p>

 

= The case is:

&n= bsp;

1) a.example.com (TTL 20s) is resolved but cached by App A= for 30 minutes

2) = Five minutes later, b.example.com is r= esolved (TTL 600s) is resolved an EAMT entry is created <= /p>

   (but shares an IPv4 addre= ss with a.example.com but a different = IPv6 address)

3) Two= minutes later, the IPv4 address from a.ex= ample.com gets used (past the DNS TTL)

     and will now use the IPv6 = EAMT entry for b.example.com (which br= eaks).

 

Does this help clarify?&nb= sp; While you could argue this client is 'broken", anecdotal experienc= e

is that this is a = very common behavior for some client software that servers already

need to work around by padding operational actions for an hour or= two past the DNS TTL.

 

[Jordi] No, this can=E2=80=99t h= appen. Now even less with the new way (stale status, entries per host, no d= uplicate entries with the same IPv4). Even if your example is the same host= , a.example.com will be optimized, but b and c will not. Further when b hap= pens, a.example.com will become stale (I=E2=80=99m not sure if this is any = longer needed =E2=80=A6 I need to double-think about that).

 

   &nbs= p; Erik

 

 


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3678043756_288862498-- From nobody Sun Jul 19 13:58:09 2020 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 75EF83A09CC for ; Sun, 19 Jul 2020 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17u_WohcOwoa for ; Sun, 19 Jul 2020 13:58:06 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3617C3A09C9 for ; Sun, 19 Jul 2020 13:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595192285; x=1595797085; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=9N331hHdehVtkzUsDFm0cZpErXMaegIA4M AKceOFrD0=; b=P5ZYxRj55We/K5RMxAJg/Cq824E9ciYyMPoybTq+n4mMaGkXnh h0lYY8BVoxk2G4Xeushm7fckKpWEqE0MAUvmvMiBN1Pg3O6QkPNdHyUDziV/orr3 LTa09Ej1mvmeRoj4Jq3VD4BzdjNkpY1x59TlrdnITIp6qhcnh9CEDkY80= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 22:58:05 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 22:58:04 +0200 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000303643.msg for ; Sun, 19 Jul 2020 22:58:03 +0200 X-MDRemoteIP: 2001:470:1f09:495:c034:405:afe5:cbb X-MDHelo: [10.10.10.131] X-MDArrival-Date: Sun, 19 Jul 2020 22:58:03 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 22:57:59 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <36B41A3F-5D95-4AE5-A139-28B1D1EA7F12@consulintel.es> Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications References: <67C20112-4347-4F99-891C-993D25EEA19E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678044279_687486037" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.1 Detection of IPv4-only hosts or applications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 20:58:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678044279_687486037 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable With the new detection and the per-host entries, we never optimize dual-sta= ck hosts, neither re-use entries from other hosts, so one less issue =E2=80= =A6 =20 El 18/7/20 17:11, "v6ops en nombre de Erik Nygren" escribi=C3=B3: =20 =20 On Fri, Jul 17, 2020 at 6:16 AM JORDI PALET MARTINEZ wrote: =20 > 5.2.1 Detection of IPv4-only hosts or applications Will Android doing synchronous A/AAAA lookups break this detection? and does this impact other things like STBs built on Android? Android does one of the A or AAAA lookups, waits for it to return, then does the other. From the perspective of the CPE resolver, could look like an IPv4-only host and just always introduce the 50ms delay? Some more details may be needed here on the timing heuristics needed to detect various scenarios like this. =20 [Jordi] When a synchronous lookup is performed, then it is clear that the h= osts is IPv6 enabled (actually dual-stack), so the EAMT entry is not create= d. If the EAMT entry already exists, then it will be used only if the host = decides to prefer IPv4 instead of IPv6, which doesn=E2=80=99t look like a n= ormal behavior. To ensure it, we may need to double-check if the 50 ms. del= ay is still good for Android or it is too small. I don=E2=80=99t think it i= s a big issue to increase it. We could improve it, to avoid the delay, if w= e create an additional table for the =E2=80=9Calready known=E2=80=9D to be = dual-stack hosts. This may be also related to the new field in the EAMT tha= t I mention above. =20 Will *all* A lookups invalidate EAMT entries? If they don't, IPv4-only hos= ts can break dual-stack hosts. =20 Also on "only if the host decides to prefer IPv4 instead of IPv6, which doe= sn=E2=80=99t look like a normal behavior" a reminder that this is a normal behavior for many clients. For example, a= large portion of deployed AppleTVs will always do A and AAAA lookups but will randomly pick between I= Pv4 and IPv6 to use. (ie, they are based on an older iOS that doesn't give a bias towards IPv6 s= o ~half of their traffic is IPv4.) =20 An important principle here may be that whatever we do here needs to work f= or all clients, not just a subset of clients following an assumption of what "well behaved"= is. While I started out overly optimistic, I'm starting to fear that this may n= ot be tractable=20 without a level of complexity and risk which may not be worth the effort. (I have a bunch of ideas for additional hacks that might help, but they jus= t make things more fragile in different ways.) =20 Erik =20 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3678044279_687486037 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

With the= new detection and the per-host entries, we never optimize dual-stack hosts= , neither re-use entries from other hosts, so one less issue =E2=80=A6

 

El = 18/7/20 17:11, "v6ops en nombre de Erik Nygren" <v6ops-bounces@ietf.org en nombre de erik+ietf@nygren.org> escribi=C3= =B3:

 

 

On Fri, Jul 17, 2020 at 6:16 AM JORDI PALET MARTINE= Z <jordi.palet=3D40co= nsulintel.es@dmarc.ietf.org> wrote:

 

> 5.2.1  Detection of IPv4-only hosts or = applications

Will Android doing synchronous A/AAAA lookups break thi= s
detection?  and does this impact other things like STBs bu= ilt on
Android?  Android does one of the A or AAAA lookups, waits f= or it
to return, then does the other.  From the perspective of the = CPE resolver,
could look like an IPv4-only host and just always introduc= e the 50ms delay?

Some more details may be needed= here on the timing heuristics needed
to detect various scenarios like t= his.

 

[Jordi] When a synchronous = lookup is performed, then it is clear that the hosts is IPv6 enabled (actua= lly dual-stack), so the EAMT entry is not created. If the EAMT entry alread= y exists, then it will be used only if the host decides to prefer IPv4 inst= ead of IPv6, which doesn=E2=80=99t look like a normal behavior. To ensure i= t, we may need to double-check if the 50 ms. delay is still good for Androi= d or it is too small. I don=E2=80=99t think it is a big issue to increase i= t. We could improve it, to avoid the delay, if we create an additional tabl= e for the =E2=80=9Calready known=E2=80=9D to be dual-stack hosts. This may = be also related to the new field in the EAMT that I mention above.

 

Will *all* A lookups invalidate EAMT entries?  If they = don't, IPv4-only hosts can break dual-stack hosts.

 

Also on "only if the host decides to prefer IPv4 ins= tead of IPv6, which doesn=E2=80=99t look like a normal behavior"<= /o:p>

a reminder that this is a= normal behavior for many clients.  For example, a large portion of deployed

AppleTVs will always do A and AAAA lookups but will ra= ndomly pick between IPv4 and IPv6 to use.

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>(ie, they are based on an older iOS that doesn't give= a bias towards IPv6 so ~half of their traffic is IPv4.)<= /p>

 

An important principle here may be that whatever we= do here needs to work for all clients,

not just a subset of clients following an assumption of= what "well behaved" is.

While I started out overly optimistic, I'm starting to fear = that this may not be tractable

without a level of complexity and risk which may not be worth t= he effort.

(I have a= bunch of ideas for additional hacks that might help, but they just

= make things more fragile in= different ways.)

 

  &nb= sp;   Erik

 

 <= /o:p>

 <= /p>

 

 

 

 

 

<= span style=3D'font-family:"Tahoma",sans-serif'> 

=

_= ______________________________________________ v6ops mailing list v6ops@iet= f.org https://www.ietf.org/mailman/listinfo/v6ops


= **********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3678044279_687486037-- From nobody Sun Jul 19 14:29:31 2020 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 8C6693A005B for ; Sun, 19 Jul 2020 14:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLZXJjSEM4KI for ; Sun, 19 Jul 2020 14:29:27 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04B63A0039 for ; Sun, 19 Jul 2020 14:29:27 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id w17so10730764otl.4 for ; Sun, 19 Jul 2020 14:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xgrY98o10ifm6oodJFIoxV7sWAePdfsPSdRXdyVqvrk=; b=EdA0W6j9Tl94V0Du+IXFjyWL1rXLk1Xv5OjBGq2DMxAOl7+FC2MxFHhzgi3C/kY0ps dbF6yGkWBHKbVH0mBKtcB0qyZzgPqFXmHZNY+d3cMCDgzm6lDAq00BsOO1LL71M++scO BSgpgJG8HH+f0v/Mg7OZDdm74EUATbIohO/X0ezo3ReLehHhmlFBL1dsK0Fd4rdyMpCr wvF3I2zEzq6PonwRJMe60lqQtYJFc6tc/JQAI5od0DJUMSE58N2D35SXT8CHaZGRB0Va yaUI7A8kykjURA458x+o+fEd3Aw8KohFpL9QUSdvngUI8lAFunohFbAz0fh4lTrCWrlc f0vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xgrY98o10ifm6oodJFIoxV7sWAePdfsPSdRXdyVqvrk=; b=ZcwH46QsPYZqMclBvhVGVVMU7rM+yhOD83n2Nc+mdCa/oUZ0nsloj767AkkQH4iETi jHmwmAQ6T0vGvhjX0qq5Wi9aDWflgLpIYIo6ll3x98H2Dmnb7rtoQsqESsDu9dl6Greo rypUFOp98fFO5RQ7fKkSVhv/tOGegd6D4AkOcXc6q1lnagTH8r30W+lOPOabsWMXs3sH VPOnID6Hvh9kWJ59P++yZ36f1SM7gZD6fhY9I2Zu45siCO8TN+O8+DrEGh75s74LLt+H 9pClvSChWo6Uf9EI1wQ78Iw2RsSsAX9irQf83AzTuOeVmiWKnp3k/Bk3SFEXo2iYlKZu E0Ww== X-Gm-Message-State: AOAM530LS6LkTruvhVuKLmIES2u2NEJW6O0gCr3EACKu1kYIhLttswcv QSS6Vc4LW6FiWTkrgbJOl/s5iC8p5Xauu/JzyeIwig== X-Google-Smtp-Source: ABdhPJwUH8V81WenXQfQW7+40uIl+iF4UonLZ/4BuyvTawh6GtRh7KopNL75MPqu3EdnbaSd3l5ZDbhJXmhpciWJnRg= X-Received: by 2002:a9d:2aea:: with SMTP id e97mr18375203otb.144.1595194166725; Sun, 19 Jul 2020 14:29:26 -0700 (PDT) MIME-Version: 1.0 References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: From: Erik Kline Date: Sun, 19 Jul 2020 14:29:15 -0700 Message-ID: To: JORDI PALET MARTINEZ Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 21:29:30 -0000 Does any of the below solve the problem of an IPv4-only host trying to learn it's external IPv4 address via a STUN service that is dualstacked? On Sun, Jul 19, 2020 at 7:19 AM JORDI PALET MARTINEZ wrote: > > Hi Philip, > > > =EF=BB=BFEl 17/7/20 17:05, "v6ops en nombre de Philip Homburg" escribi=C3=B3: > > >[Jordi] Good point. May be: > > > >"The CE DNS proxy MUST NOT return the answer to an A query until eit= her an answe > >r to the AAAA query has been received or the Resolution Delay has pa= ssed" > > Yes, I think this is important. Otherwise small differences in DNS ti= ming > may cause hard to diagnose bugs. > > Another suggestion is that if the AAAA query either gets a timeout or= SERVFAIL > then any existing EAMT entry for the corresponding IPv4 address shoul= d be > set to invalid. > > Then there is DNSSEC. For example, the AAAA lookup MUST/SHOULD/MAY be > verified using DNSSEC local validation. (Or, the AD bit of the reply = could > be used instead). A reply that fails DNSSEC validation MUST/SHOULD/MA= Y not > result in the creation of an EAMT entry (and MUST/SHOULD/MAY result i= n > marking an exiting entry invalid) > > [Jordi] Yes both of those are also very good points. Maybe, we can summar= ize all those changes and some of my previous responses to Erik and Eduard = in the list with the text (tentative) that I'm adding at the end of this em= ail. > > One question that doesn't seem answer, what if the upstream resolver = is > doing DNS64. In that case an AAAA query would get an answer for an IP= v4-only > service. Maybe it doesn't matter, because the mapping will be the sam= e. > Otherwise setting the CD flag in the query may help to get only 'real= ' > AAAA records. > > [Jordi] This is already resolved by NOT creating an EAMT entry if only a = synthetized AAAA is received. Section 5.2.2: > " Note that the NAT46/CLAT MUST already > know the WKP or NSP being used in that network. If the response > contains at least one IPv6 address not using the WKP/NSP, it means > that the destination is IPv6-enabled (because at least one of the > IPv6 addresses is not synthesized). This means that it is possible > for the NAT46/CLAT, to create an Explicit Address Mapping" > > [Jordi] I'm still trying to tidy up all the text according to other input= s and respond to them. Too soon to send a new version, but close ... > > > Tentative changes: > > > > 5.2.2. Detection of IPv4-only hosts > > The goal is to ensure that only IPv4-only hosts are optimized. > Towards that, the CE MUST use ARP and ND (and their relevant caches, > if the information of a hosts has been already learnt) each time a > new host starts a connection. If it is not possible to bind the same > MAC address to both an IPv4 and IPv6 address, then the host is not > IPv4-only (it may be IPv6-only or dual-stack), and MUST NOT be > optimized. > > The CE MUST maintain a table of IPv4-only hosts and ensure that if > any IPv4-only hosts become IPv6-enabled, it is properly handled. > > This mechanism to detect IPv4-only hosts has two drawbacks: > > 1. If a subscriber has intermediate dual-stack routers in between > the IPv4-only host and the NAT46/CLAT, the IPv4-only hosts will > be detected as dual-stack, so no optimization will be performed. > This is not the most common scenario, as typically the devices > that are more relevant to the optimization (in terms of those > that generate more IPv4-only traffic) are directly attached to > the CE, or in bridged interfaces. > > 2. If a host is dual-stack, but has some IPv4-only applications, > because the host will be detected as dual-stack, none of the > applications will be optimized. This is a good trade-off, > considering the most important traffic to optimize is typically > coming from real IPv4-only devices such as old SmartTVs/STBs. > Furthermore, this avoid breaking other mechanisms present only in > dual-stack hosts, such as Happy Eyeballs [RFC8305] and simplifies > troubleshooting. > > It needs to be remarked that, if the detection of the IPv4-only host > is done incorrectly (either not detecting it or by a false > detection), the goal is that no harm is caused. In the worst case, > optimization MUST NOT be performed. > > 5.2.3. Detection of IPv6-enabled service > > In the case of an IPv4-only detected host, the DNS proxy/stub > resolver MUST actually perform an additional AAAA query, unless the > information is already present in the Additional Section, as per > Section 3 of [RFC3596]. > > Note that the NAT46/CLAT MUST already know the WKP or NSP being used > in that network. If the response contains at least one IPv6 address > not using the WKP/NSP, it means that the destination is IPv6-enabled > (because at least one of the IPv6 addresses is not synthesized). > This means that it is possible for the NAT46/CLAT, to create an > Explicit Address Mapping ([RFC7757]). > > 5.2.4. CE DNS proxy responses > > In the case of an IPv4-only detected host, the CE DNS proxy MUST only > return the answer to an A query once any of the following happens: > > 1. An answer to the AAAA query has been received. > > 2. A SERVFAIL has been received. > > 3. The "Resolution Delay" has passed. > > The Resolution Delay MUST be set to the same value (50 milliseconds) > as indicated by Happy Eyeballs [RFC8305]. > > 5.2.5. Creation of EAMT entries > > An EAM Table (EAMT used for short, across the rest of this document) > MUST be created/maintained automatically by the NAT46/CLAT, which is > responsible to prioritize any available entries in the EAMT, versus > the use of any synthetic AAAA. > > The EAMT entry MUST only be created if all the following conditions > are met: > > 1. The source host is IPv4-only. > > 2. The DNS proxy is ready to return the A answer (according to > Section 5.2.4). > > 3. There is at least one non-synthesized AAAA response. > > 4. If DNSSEC is available, the response has been locally validated > or the AD bit has been set by a trusted resolver, as per > [RFC3655]. > > This avoids a slight NAT64 overload and flapping between destination > addresses (IPv4/IPv6), which may impact some applications, at the > cost of a small extra delay for the initial communication setup, when > the EAMT entry doesn't yet exist. > > Each EAMT entry MUST contain, the fields already described in > [RFC7757] and a few new extensions (as per section 3.1 of [RFC7757]): > > 1. ID: EAMT Entry Index (optional). > > 2. MAC address: Identify the host to which this EAMT entry belongs. > > 3. Destination IPv4 address/prefix: By default, the prefix length is > 32 bits. > > 4. Destination IPv6 address/prefix: By default, the prefix length is > 128 bits. Only non-synthesized addresses are allowed. > > 5. TTL: It MUST be set to the minimum value from the AAAA/A RR pair. > In normal conditions the TTL for both A and AAAA records, of a > given FQDN, should be the same, so this ensures a proper behavior > if there is any DNS mismatch. > > 6. FQDN: The one that originated the A query for this EAMT entry. > Required in order to ensure a correct detection of cases such as > the use of reverse-proxy with a single IPv4 address to multiple > IPv6 addresses. > > 7. Valid/Stale/Invalid: When set to Stale, means that this EAMT > entry MUST NOT be used for new connections. When set to Invalid, > means that this EAMT entry can be deleted, unless the Auto/Static > bit is also set. > > 8. Auto/Static: When set to 1, means that this EAMT entry has been > manually/statically configured, for example by means of an > explicit configuration (GUI, CLI, provisioning system, etc.). > > Note that allowing destination IPv4 and IPv6 prefixes, together with > the Valid/Stale/Invalid and Auto/Static flags, allows manual explicit > optimization and non-optimization configuration for specific parts of > Internet. > > When a new EAMT entry is first automatically created, it is flagged > as "Valid" and "Auto". If a subsequent A query, with a different > FQDN, results in an IPv4 address that has already an EAMT entry and a > different IPv6 address, it means that some reverse-proxy or similar > functionality is being used by the IPv6-enabled service. In this > case, the existing EAMT entry will be marked as "Stale". No new EAMT > entry is created for that IPv4 address. Otherwise, the optimization > will only allow to access the first set of IPv4/IPv6/FQDN, which may > break the access to other FQDN that share the same IPv4 address and > different IPv6 addresses. > > In this case the EAMT entry will still become "Invalid" according the > TTL, which allows to re-enable optimization if a new query for the A > record has changed the situation. For example, maybe the reverse- > proxy has been removed, or there is now only a single device using > it, so at the time being, the optimization is again possible without > creating troubles to other hosts. > > An EAMT entry marked as "Stale" or "Invalid", only affects the > relevant host. Other hosts have their own EAMT entries or they are > using the regular NAT46/CLAT+NAT64 path (without the optimization). > > 5.2.6. Forwarding path via stateful NAT for existing EAMT entries > > Following this approach, if there is a valid EAMT entry, for a given > pair of source-MAC-address/IPv4-destination, the IPv6-native path > pointed by the IPv6 address of that EAMT entry, will take precedence > versus the NAT64 path, so the traffic will not be forwarded to the > NAT64. > > However, this is not sufficient to ensure that individual > applications are able to keep existing connections. In many cases, > audio and video streaming may use a single TCP connection lasting > from minutes to hours. Instead, the CDN TTLs may be configured in > the range from 10 to 300 seconds in order to allow new resolutions to > switch quickly and to handle large recursive resolvers (with hundreds > of thousands of clients behind them). > > Consequently, the EAMT entries MUST NOT be used directly to establish > a forwarding path, but instead, MUST be used to create a stateful NAT > entry for the 4-tuple for the duration of the session/connection. > This means that to implement the optimization the NAT46 MUST be > stateful. Typically stateful NAT46 are implemented by means of a > stateful NAT44 (which often maybe hardware off-loaded), followed by a > stateless NAT46. If the SoC/code is able to do stateless NAT46, this > still could be used when the optimization is disabled. > > 5.2.7. Maintenance of the EAMT entries > > An EATM entry with the Auto/Static bit set, MUST NOT be automatically > modified. > > An EAMT entry with the Auto/Static bit clear, MUST be set to Stale > in case of: > > 1. TTL time-out. > > 2. Or the conditions for creation of the EAMT entry (Section 5.2.5) > aren't longer met. > > Entries in Stale state MUST be set to Invalid once existing > connections time-out. > > The Invalid EAMT entries MUST be deleted, unless the Auto/Static bit > is set. This allows users/operators to set explicit rules for > diagnostics or resolution of issues in special situations. > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Jul 19 14:54:25 2020 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 D3FF13A0817 for ; Sun, 19 Jul 2020 14:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnFUI-ASDoaC for ; Sun, 19 Jul 2020 14:54:20 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id EFE6C3A0816 for ; Sun, 19 Jul 2020 14:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595195658; x=1595800458; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=OBsVFo/G9E5iljR72TQYWf2cGbmiDynDIzXF6a2kpnk=; b=pUheq2mj19cDav9/D/NtlONTpYjnuM/lG7ZE4K92cT7tjQPC8XAXmLYs4Tymtd bFvgxjnQEOMzQ59YbR61lG/oxZKJHB4aB2NHXMxrI/IENPlowaG+nJ4+jczLF+2Q 7mqgHHLz2Zw0MSwsjBLrF29d983jQAJtbIFNoVTTC6At8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 19 Jul 2020 23:54:17 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 19 Jul 2020 23:54:16 +0200 Received: from [10.10.10.131] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000303764.msg for ; Sun, 19 Jul 2020 23:54:16 +0200 X-MDRemoteIP: 2001:470:1f09:495:b109:d5fd:cd5:c7f X-MDHelo: [10.10.10.131] X-MDArrival-Date: Sun, 19 Jul 2020 23:54:16 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1469d5a63d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 19 Jul 2020 23:54:12 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> Thread-Topic: draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678047652_938746321" Archived-At: Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 21:54:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678047652_938746321 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > 5.2.6. > "The existing EAMT entry for 192.0.2.1 is set as invalid". Clarify that: * 5. Existing connections to 192.0.2.1 remapped to 2001:db8::a:b:c:d MUST NOT be broken. [Jordi] Yes, this has been solved with the stale status : 5.=C2=A0 The existing EAMT entry for 192.0.2.1 is set to Stale And 5.2.13.=C2=A0 False detection of a dual-stack host as IPv4-only =20 =C2=A0=C2=A0 If a dual-stack host is being detected as IPv4-only, is becaus= e it is =C2=A0=C2=A0 not responding to the CE ND messages, so by all means, should = be =C2=A0=C2=A0 considered, at the time being, as IPv4-only, and consequently = EAMT =C2=A0=C2=A0 entries will be created and traffic will be optimized for IPv4= flows. =20 =C2=A0=C2=A0 However, if this hosts suddenly become IPv6-enabled (or dual-s= tack), =C2=A0=C2=A0 the relevant EAMT entries must be flagged by the CE as "Stale"= .=C2=A0 The =C2=A0=C2=A0 host will be able to complete the connections and the entries = will be =C2=A0=C2=A0 marked as "Invalid" and deleted. =20 =C2=A0=C2=A0 Anyway, those EAMT entries, while "Valid", may not be actually= used =C2=A0=C2=A0 by the dual-stack hosts, because those hosts or applications s= hould =C2=A0=C2=A0 prefer IPv6, so most probably was either a temporary failure o= r done =C2=A0=C2=A0 on-purpose (user, troubleshooting).=C2=A0 If the host is prefe= rring IPv4 =C2=A0=C2=A0 for connecting to the CDN/cache or IPv6-enabled service, it wi= ll be =C2=A0=C2=A0 actually using the NAT46/CLAT, including the EAMT entry and =C2=A0=C2=A0 consequently IPv6, so this mechanism will be correcting an =C2=A0=C2=A0 undesirable behavior.=C2=A0 This may be also a special case, w= hich =C2=A0=C2=A0 actually seems to be an incoherent host or application =C2=A0=C2=A0 implementation. =20 =20 =3D=3D=3D=3D=3D=3D=3D > 5.2.7. Behavior in case of multiple A/AAAA RRs Agreed with Jen's earlier comment that this needs more clarification. Exam= ple algorithm: * For each A record on the A RRset, create an EAMT entry with a randomly selected record from the AAAA RRset. * Resolver should ideally randomly permute the A RRset prior to returning to the client =20 [Jordi]=C2=A0 If I got correctly what you mean, the goal is to ensure that = several devices using the same CDN resources, get different A/AAAA pairs (E= AMT entries). Also, that the same CE in different customers, is not =E2=80= =9Calways=E2=80=9D using the same A/AAAA pair, so the load is =E2=80=9Cbala= nced=E2=80=9D as much as possible among the CDN resources. I couldn=E2=80= =99t fine if this is already specified at that level in a previous document= , so while I assume some random is applied in resolvers, we want to take th= e opportunity to ensure it. So maybe: =20 5.2.9.=C2=A0 Behavior in case of multiple A/AAAA RRs =20 =C2=A0=C2=A0 If multiple A/AAAA RRs are available, any of them could be =C2=A0=C2=A0 chosen and in general, the optimization will not present any =C2=A0=C2=A0 different result to the hosts compared with a situation where = the =C2=A0=C2=A0 optimization is not used. =20 =C2=A0=C2=A0 Existing DNS proxy/stub resolvers already implement mechanisms= for =C2=A0=C2=A0 DNS Load Balancing ([RFC1794]).=C2=A0 This don't need to be mo= dified to =C2=A0=C2=A0 implement the optimization, if some degree of randomness is al= ready secured. =20 =C2=A0=C2=A0 To secure sufficient randomness, a possible algorithm shall en= sure =C2=A0=C2=A0 that different EAMT entries (for different hosts) are permuted =C2=A0=C2=A0 randomly among different A/AAAA records on the A/AAAA RR set. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5.2..10 Behavior in case of Foreign DNS How will the mismatches that should trigger invalidations get detected in this case? * Breakage due to as mismatches won't be detected and result in invalidatio= ns if one device or app is doing lookups via this resolver but another is not= . Constraining the EAMT entry to the IPv4 client IP could at least bound the damage to a single device, but not if some apps on it use different resolver schemes. * I believe Google ships Chromecast to hardcode DNS lookups to 8.8.8.8 in addition to also sometimes using the local resolver. Some other STBs = and mobile apps do the same. This has significant potential for mismatches to not get detected and not get invalidated. [Jordi] All this is no longer a problem: We don=E2=80=99t optimize if a for= eign DNS is=C2=A0 used. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5.2.13. Troubleshooting Implications How do corner-cases around collisions where EAMT entries don't get proprerly invalidated get debugged by the ISP (and content provider!)? This is opaque to the CDN and could result in lots of escalations from end-users and customers. The net result will be for content to get switched to IPv4-only if that "fixes" the problem which might impact users world-wide. (Neither the CDN or their customer has any visibility into what is going on here other than that some end users may be reporting not being able to view dual-stacked content.) [Jordi] If the troubleshooting is done with dual-stack host, no issues. If = it is an IPv4-only host, the optimization can be fully disabled, or specifi= c entries can be disabled. Is not that solving the problem? This is the tex= t I=E2=80=99ve right now: =20 5.2.15.=C2=A0 Troubleshooting Implications =20 =C2=A0=C2=A0 When there is a need to troubleshoot IPv4 from the CE LANs, it= may =C2=A0=C2=A0 happen that there is an EAMT entry forcing the flow to a given =C2=A0=C2=A0 destination(s) to use IPv6, which will distort the results, un= less =C2=A0=C2=A0 the host being used is dual-stack (which is the most common =C2=A0=C2=A0 situation). =20 =C2=A0=C2=A0 This can be avoided, using a CLI/GUI or provisioning procedure= , to =C2=A0=C2=A0 either completely disable the optimization during the =C2=A0=C2=A0 troubleshooting, or create specific static EAMT entries, using= the =C2=A0=C2=A0 Valid/Stale/Invalid and Auto/Static flags, as described in =C2=A0=C2=A0 Section 5.2.5. =20 =C2=A0=C2=A0 Consequently, the CE MUST allow both, disabling the optimizati= on and =C2=A0=C2=A0 the setup of manual/static EAMT entries. =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General for 5.2.x: * Should this doc use more normative language in places where warranted? (There are a bunch of MUST NOT sharp edges.) Especially in 5.2.4. * Clarify that EAMT table updates MUST be made before A record is returned to the client (especially invalidations!). Otherwise there is a potential race condition.. * What happens if the FQDNs mismatch but the A and AAAA RRsets are identica= l? This is going to be very common as many CDNs use lots of names with a smaller number of IPv4 addresses. What if the A and AAAA RRsets overlap but aren't identical? (Perhaps the EAMT entry MUST be marked invalid if the FQDNs mismatch and the EAMT entry does not have both its A *and* AAAA values in the returned RRsets. ie, all EAMT entries must be valid within the mismatching FQDN.) (May still be corner cases here I'm forgetting?) [Jordi] I think all this has been already resolved. * We have a recommended maximum cap/threshold on the TTL? (even if it's something like 8 hours...) Otherwise bad entries might stick around too long. [Jordi] This is an open question. I don=E2=80=99t know if it makes sense to= invalidate the stale entries if the connections don=E2=80=99t die =E2=80= =A6 and if so, I guess your 8 hours come from your CDN view of operational = details (changes in FQDNs/A/AAAA), or it is just random? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Additional security considerations: (The first of these is minor --- the others seem like they make this too da= ngerous to deploy. It may be worth having a Security AD do some focused review in this context= .) * Filling EAMT table with very long TTL records. (ie, triggering a client = to do DNS lookups that create lots of long-lived associations) [Jordi] Yep,=C2=A0 same point as the 8 hours. Should we set some limits for= the EAMT entries, despite the TTLs? * There is an serious risk exposure to hijacking traffic by inserting bogus= binding (ie, return target's A record and malicious actor's AAAA record). In most cases these records should get marked as Invalid, but the corner cases here are fragile (eg, with foreign DNS or clients caching past the TTL mixed in here. An example attack here is that a client has an A record for "www.example.com" pointing to 192.0.2.1 cached past its TTL so the EAMT record is gone. An attacker convinces another user in the same home network to do a DNS lookup that has an A record of 192.0.2..1 (which the attacker doesn't own) but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled). Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never existed then the attacker can redirect all traffic to it to an IPv6 addre= ss of their choice. No DNS spoofing is needed here at all, just making a "claim" that the A/AAAA are associated (which has no authentication). This is potentially worse as I'd hypothesize that IPv4-only STB clients are much less likely to use HTTPS/TLS.. [Jordi] I think that having a per-host EAMT entries resolves this. * This previous risk is particularly problematic for hijacking traffic from users/devices/clients using Foreign DNS since they won't create EAMT entries but will be exposed to clients getting tricked into creating= them. (This cCould be especially problematic for users using DoH for privacy on one device, but then another device in their home allows them to be hjijacked. At some point Firefox preferred IPv4 in some cases when using DoH so this may be a real exposure / vulnerability risk.) [Jordi] Not anymnore, because we don=E2=80=99t reuse EAMT entries from one = host to another. Sorry again for not sending these earlier --- I think a bunch of these concerns were raised in my previous feedback and while this version has made significant improvements, I'm still very concerned that it will be very risky from an operational fragility and security perspective. Erik =20 [Jordi] Not at all, very happy for so much detailed review. Sometimes a las= t-call, even if failed, is good to get all this! =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3678047652_938746321 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

> 5.2.6.
> "The existing EAMT entry for 192.0.2.1 is set as = invalid".

Clarify that:
* 5. Existing connections to 192.0.2= .1 remapped to 2001:db8::a:b:c:d
  MUST NOT be broken.

=

[Jordi] Yes, this has been solved with the stale status :

5.=C2=A0 The existing EAMT entry for 19= 2.0.2.1 is set to Stale

And

5.2.13.=C2=A0 False detection of a dual-stack host as IPv4-only<=
/o:p>
 =

=C2=A0=C2=
=A0 If a dual-stack host is being detected as IPv4-only, is because it is
=C2=A0=
=C2=A0 not responding to the CE ND messages, so by all means, should be
=C2=A0=C2=
=A0 considered, at the time being, as IPv4-only, and consequently EAMT=

=C2=A0=C2=
=A0 entries will be created and traffic will be optimized for IPv4 flows.
&n=
bsp;
=C2=A0=
=C2=A0 However, if this hosts suddenly become IPv6-enabled (or dual-stack),=

=C2=
=A0=C2=A0 the relevant EAMT entries must be flagged by the CE as "Stal=
e".=C2=A0 The
=C2=A0=C2=A0 host will be able to complete the connections and=
 the entries will be
=C2=A0=C2=A0 marked as "Invalid" and deleted.
&nb=
sp;
=C2=A0=
=C2=A0 Anyway, those EAMT entries, while "Valid", may not be actu=
ally used
=C2=A0=C2=A0 by the dual-stack hosts, because those hosts or applicatio=
ns should
=C2=A0=C2=A0 prefer IPv6, so most probably was either a temporary failu=
re or done
=C2=A0=C2=A0 on-purpose (user, troubleshooting).=C2=A0 If the host is =
preferring IPv4
=C2=A0=C2=A0 for connecting to the CDN/cache or IPv6-enabled serv=
ice, it will be
=C2=A0=C2=A0 actually using the NAT46/CLAT, including the EAMT en=
try and
=C2=A0=C2=A0 consequently IPv6, so this mechanism will be correcting an
=C2=A0=
=C2=A0 undesirable behavior.=C2=A0 This may be also a special case, which
=C2=A0=
=C2=A0 actually seems to be an incoherent host or application
=C2=A0=C2=A0 implementation.

 

 

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

> 5.2.7.  Behavior in case = of multiple A/AAAA RRs

Agreed with Jen's earlier comment that this n= eeds more clarification.  Example algorithm:

* For each A recor= d on the A RRset, create an EAMT entry with a randomly
  selected r= ecord from the AAAA RRset.

* Resolver should ideally randomly permute the A RRset prior to
  returning to the client

=  

[Jordi]=C2=A0 If I got correctly what you mean, the goal is = to ensure that several devices using the same CDN resources, get different = A/AAAA pairs (EAMT entries). Also, that the same CE in different customers,= is not =E2=80=9Calways=E2=80=9D using the same A/AAAA pair, so the load is= =E2=80=9Cbalanced=E2=80=9D as much as possible among the CDN resources. I = couldn=E2=80=99t fine if this is already specified at that level in a previ= ous document, so while I assume some random is applied in resolvers, we wan= t to take the opportunity to ensure it. So maybe:

 <= /o:p>

5.2.9.=C2=A0 Behavior in case= of multiple A/AAAA RRs

=  

=C2=A0=C2=A0 If= multiple A/AAAA RRs are available, any of them could be<= /p>

=C2=A0=C2=A0 chosen and in general, the op= timization will not present any

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New";color= :black'>=C2=A0=C2=A0 different result to the hosts compared with a situatio= n where the

=C2=A0=C2=A0= optimization is not used.

 

=C2=A0=C2=A0 E= xisting DNS proxy/stub resolvers already implement mechanisms for

=C2=A0=C2=A0 DNS Load Balancing (= [RFC1794]).=C2=A0 This don't need to be modified to

=C2=A0=C2=A0 implement the optimization, if som= e degree of randomness is already secured.

 

=C2=A0=C2=A0 th= at different EAMT entries (for different hosts) are permuted

=C2=A0=C2=A0 randomly among different = A/AAAA records on the A/AAAA RR set.

 

 


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

> 5.2..10 Behavior in case of Foreign DN= S

How will the mismatches that should trigger invalidations
get d= etected in this case?

* Breakage due to as mismatches won't b= e detected and result in invalidations
 if one device or app is doi= ng lookups via this resolver but another is not.
  Constraining the= EAMT entry to the IPv4 client IP could at least bound
  the damage= to a single device, but not if some apps on it use different
  res= olver schemes.

* I believe Google ships Chromecast to hardcode DNS l= ookups to 8.8.8.8
  in addition to also sometimes using the local reso= lver.  Some other STBs and mobile apps
  do the same.  Th= is has significant potential for mismatches to not get
  detected a= nd not get invalidated.

[Jordi] All this is no longer a probl= em: We don=E2=80=99t optimize if a foreign DNS is=C2=A0 used.


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

> 5.2.13.&= nbsp; Troubleshooting Implications

How do corner-cases around= collisions where EAMT entries
don't get proprerly invalidated get debug= ged by the ISP
(and content provider!)?

This is opaque to the CDN= and could result in lots of escalations from
end-users and customers.&n= bsp; The net result will be for content to get
switched to IPv4-only if = that "fixes" the problem which might impact
users world-wide. =  (Neither the CDN or their customer has any
visibility into what is= going on here other than that some end users
may be reporting not being= able to view dual-stacked content.)

[Jordi] If the troublesh= ooting is done with dual-stack host, no issues. If it is an IPv4-only host,= the optimization can be fully disabled, or specific entries can be disable= d. Is not that solving the problem? This is the text I=E2=80=99ve right now= :

 

5.2.15.=C2=A0 Troubleshooting Implications<=
/pre>
 =

=C2=A0=C2=A0 When there=
 is a need to troubleshoot IPv4 from the CE LANs, it may<=
/pre>
=C2=A0=C2=A0 happen that=
 there is an EAMT entry forcing the flow to a given
=

=C2=A0=C2=A0 destination(s) t=
o use IPv6, which will distort the results, unless
<=
pre>=C2=A0=C2=A0 the host being us=
ed is dual-stack (which is the most common
=C2=A0=C2=A0 situation).
 
=C2=A0=C2=A0 This =
can be avoided, using a CLI/GUI or provisioning procedure, to
=C2=A0=C2=A0 either=
 completely disable the optimization during the
=C2=A0=C2=A0 troubleshooting, or =
create specific static EAMT entries, using the
=
=C2=A0=C2=A0 Valid/Stale/Invalid a=
nd Auto/Static flags, as described in
=C2=A0=C2=A0 Section 5.2.5.
 
=C2=A0=C2=A0 Consequ=
ently, the CE MUST allow both, disabling the optimization and
=C2=A0=C2=A0 the se=
tup of manual/static EAMT entries.

 <= /p>

=  

 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
General for 5.2.x:

* Should this doc use more normative langu= age in places where warranted?
  (There are a bunch of MUST = NOT sharp edges.)
  Especially in 5.2.4.

* Clarify that EAMT= table updates MUST be made before A record
  is returned to the cl= ient (especially invalidations!).  Otherwise there
  is a potential race condition..
=
* What happens if the FQDNs mismatch but the A and AAAA RRsets are iden= tical?
This is going to be very common as many CDNs use lots of names with a smaller number of IPv4 addresses.
  What if the A and= AAAA RRsets overlap but aren't identical?
  (Perhaps the EAMT entr= y MUST be marked invalid if the FQDNs mismatch
  and the EAMT entry= does not have both its A *and* AAAA values
  in the returned RRset= s.  ie, all EAMT entries must be valid
  within the mismatchin= g FQDN.)
  (May still be corner cases here I'm forgetting?)

=

[Jordi] I think all this has been already resolved.

<= br>* We have a recommended maximum cap/threshold on the TTL?
  (even if it's something like 8 hours...)  Otherwise bad entries
=   might stick around too long.

[Jordi] This is an open q= uestion. I don=E2=80=99t know if it makes sense to invalidate the stale ent= ries if the connections don=E2=80=99t die =E2=80=A6 and if so, I guess your= 8 hours come from your CDN view of operational details (changes in FQDNs/A= /AAAA), or it is just random?


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

Additional security considerations:

(The first of thes= e is minor --- the others seem like they make this too dangerous to deploy.=
It may be worth having a Security AD do some focused review in t= his context.)

* Filling EAMT table with very long TTL records.  = ;(ie, triggering a client to
  do DNS lookups that create lots of l= ong-lived associations)

[Jordi] Yep,=C2=A0 same point as the = 8 hours. Should we set some limits for the EAMT entries, despite the TTLs?<= o:p>


* There is an serious risk exposure to hijacking traffic= by inserting bogus binding
  (ie, return target's A record and mal= icious actor's AAAA record).
  In most cases these records s= hould get marked as Invalid,
  but the corner cases here are fragil= e (eg, with foreign DNS or
  clients caching past the TTL mixed in = here.
  An example attack here is that a client has an A record
=   for "www.example.com&quo= t; pointing to 192.0.2.1 cached past
  its TTL so the EAMT record i= s gone.  An attacker convinces
  another user in the same home= network to do a DNS lookup
  that has an A record of 192.0.2..1 (w= hich the attacker doesn't own)
  but a AAAA record for 2001:db8:eee= e::eeee (which is attacker-controlled).
  Even if 192.0.2.1 is IPv4= -only, if the EAMT entry has expired or never
  existed then the at= tacker can redirect all traffic to it to an IPv6 address
  of their= choice.  No DNS spoofing is needed here at all, just making
 = a "claim" that the A/AAAA are associated (which has no authentic= ation).
  This is potentially worse as I'd hypothesize that IPv4-on= ly STB
  clients are much less likely to use HTTPS/TLS..

[Jordi] I think that having a per-host EAMT entries resolves this.=


* This previous risk is particularly problematic for hijacki= ng traffic from
  users/devices/clients using Foreign DNS since the= y won't create
  EAMT entries but will be exposed to clients gettin= g tricked into creating them.
  (This cCould be especially p= roblematic for users using DoH for privacy
  on one device, but then another device in their home allows
  them to be h= jijacked.  At some point Firefox preferred IPv4 in some
  case= s when using DoH so this may be a real exposure
  / vulnerability r= isk.)

[Jordi] Not anymnore, because we don=E2=80=99t reuse = EAMT entries from one host to another.


Sorry again for n= ot sending these earlier --- I think a bunch of these
concerns were rais= ed in my previous feedback and while this version
has made significant i= mprovements, I'm still very concerned that it will
be very risky from an= operational fragility and security perspective.

     = ;Erik
 

[Jordi] Not at all, very happy for so much det= ailed review. Sometimes a last-call, even if failed, is good to get all thi= s!

 

 

&n= bsp;


********************************************= **
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3678047652_938746321-- From nobody Mon Jul 20 01:15:50 2020 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 1B1BB3A077A for ; Mon, 20 Jul 2020 01:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SINAcBqeLSWP for ; Mon, 20 Jul 2020 01:15:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9DC1C3A0768 for ; Mon, 20 Jul 2020 01:15:44 -0700 (PDT) Received: from lhreml745-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B6A37D2D7E4FE837C5E0; Mon, 20 Jul 2020 09:15:42 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml745-chm.china.huawei.com (10.201.108.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 09:15:42 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 11:15:41 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 11:15:41 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ , "V6 Ops List" Thread-Topic: draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest Thread-Index: AQHWXhc/K6tozmRt0kKaAvFhAK9ImakQFg/g Date: Mon, 20 Jul 2020 08:15:41 +0000 Message-ID: <02f63b1af4284239801567cfaf4d9c9b@huawei.com> References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> In-Reply-To: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: multipart/alternative; boundary="_000_02f63b1af4284239801567cfaf4d9c9bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 08:15:48 -0000 --_000_02f63b1af4284239801567cfaf4d9c9bhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSGkgSm9yZGksDQoNCk15IGNvbW1lbnQgYWJvdXQgOGggVFRMOg0KSSBpbnNpc3Qg dG8gbWFrZSBpdCBtdWNoIGxvbmdlci4gSSBoYXZlIHRoZSB0aGVvcnkgYmVsb3cgd2h5IGl0IHNo b3VsZCBiZSBkZWZpbml0ZWx5IG1vcmUgdGhhbiAyNGgsIHByb2JhYmx5IGV2ZW4gbG9uZ2VyICgx IHdlZWs/KS4NCg0KSSBhbSBhIHN1YnNjcmliZXIgKGF0IGRpZmZlcmVudCB0aW1lcykgb2YgTWVn YWZvbiwgTVRTLCBhbmQgVGVsZTIgUnVzc2lhLiBMYXN0IG9uZSB3b3VsZCBkcm9wIGFueSBjYWxs IGFmdGVyIDMwbWluLCBwcmV2aW91cyB0d28gd291bGQgZHJvcCBhZnRlciAxaC4gTG9va3MgbGlr ZSB0aGV5IGRvIG5vdCB3YW50IHN0YWxlIGNvbm5lY3Rpb24gdG9vIChlc3BlY2lhbGx5IHBhaWQp Lg0KSXQgaXMgdmVyeSBkaXN0cmFjdGluZyB3aGVuIHlvdSBhcmUgb24gY29uZmVyZW5jZSBjYWxs Lg0KDQpJdCBpcyBwZXJmZWN0bHkgcG9zc2libGUgdGhhdCB3ZSB3b3VsZCBzZWUgb25seSBvbmUg RE5TIHJlcXVlc3QgYmVmb3JlIG1lZGlhIHN0cmVhbSB3b3VsZCBzdGFydC4NCkkgY291bGQgaW1h Z2luZSBpbnRlcmFjdGl2ZSBtZWRpYSBzdHJlYW0gbG9uZ2VyIHRoYW4gOGguIEkgY291bGQgbm90 IGltYWdpbmUgaW50ZXJhY3RpdmUgbG9uZ2VyIHRoZW4gMjRoIOKAkyBwZW9wbGUgbmVlZCB0byBz bGVlcC4NCg0KV2hhdGV2ZXIgdGltZXIgeW91IHdvdWxkIGludHJvZHVjZSDigJMgSSBhbSBzdXJl IHRoYXQgd291bGQgYmUgY2FzZXMgd2hlbiBsZWdpdGltYXRlIGNvbm5lY3Rpb24gd291bGQgYmUg ZHJvcHBlZC4gMjRoIHdvdWxkIGJlIHByb2JhYmx5IHNhZmUgdGltZSBhZ2FpbnN0IGludGVyYWN0 aXZlIHN0cmVhbSBpbnRlcnJ1cHRpb24uDQpCdXQgc29tZSB2aWRlbyBjYW1lcmEgKHN1cnZlaWxs YW5jZSkgbWF5IGJlIGludGVycnVwdGVkIGV2ZW4gYWZ0ZXIgMSB3ZWVrIHRpbWVyLg0KQW5kIGlm IG9yaWdpbmFsIGFwcGxpY2F0aW9uIGRvZXMgbm90IGhhdmUgYSBsb2dpYyB0byByZWVzdGFibGlz aCBjb25uZWN0aW9uIChpdCBpcyBhc3N1bWVkIG1hbnVhbCBvciBkaWZmZXJlbnQgYXBwbGljYXRp b24gc2hvdWxkIHB1c2gpIOKAkyB0aGVuIGFueSB0aW1lciBpcyBhIGRpc2FzdGVyLg0KSW1hZ2lu ZSBhIHN1YnNjcmliZXIgdGhhdCBuZWVkcyB0byByZWVzdGFibGlzaCBtYW51YWxseSBoaXMgdmlk ZW8gc3VydmVpbGxhbmNlIGNvbm5lY3Rpb24gZXZlcnkgd2VlayDigJMgd2hhdCBoZSB3b3VsZCB0 aGluayBhYm91dCB1cz8NCg0KV2UgaGF2ZSB0cmFkZSBvZmYgaGVyZTogZHJvcCBzb21lIGxlZ2l0 aW1hdGUgbG9uZyBzZXNzaW9ucyBvciByZWZyZXNoIHRpbWVyIGFmdGVyIHN3aXRjaGluZyBldmVy eSBwYWNrZXQgYWdhaW5zdCB0aGlzIEVBTSBlbnRyeS4NCldobyBoYXMgZXhwZXJpZW5jZSB3aXRo IENQRSBkZXZlbG9wbWVudDogaXMgaXQgcmVhbGx5IGV4cGVuc2l2ZSBmb3IgQ1BFIHRvIHJlZnJl c2ggVFRMIGFmdGVyIGFueSBwYWNrZXQgc3dpdGNoZWQ/DQpUaGVuIHRpbWVyIGluIDI0aCB3b3Vs ZCBiZSBzYWZlLiAoaXMgd2UgYXJlIHN1cmUgdGhhdCBjb25uZWN0aW9uIGlzIHJlYWxseSBzdGFs ZSkNCg0KDQoqIFRoZXJlIGlzIGFuIHNlcmlvdXMgcmlzayBleHBvc3VyZSB0byBoaWphY2tpbmcg dHJhZmZpYyBieSBpbnNlcnRpbmcgYm9ndXMgYmluZGluZw0KICAoaWUsIHJldHVybiB0YXJnZXQn cyBBIHJlY29yZCBhbmQgbWFsaWNpb3VzIGFjdG9yJ3MgQUFBQSByZWNvcmQpLg0KICBJbiBtb3N0 IGNhc2VzIHRoZXNlIHJlY29yZHMgc2hvdWxkIGdldCBtYXJrZWQgYXMgSW52YWxpZCwNCiAgYnV0 IHRoZSBjb3JuZXIgY2FzZXMgaGVyZSBhcmUgZnJhZ2lsZSAoZWcsIHdpdGggZm9yZWlnbiBETlMg b3INCiAgY2xpZW50cyBjYWNoaW5nIHBhc3QgdGhlIFRUTCBtaXhlZCBpbiBoZXJlLg0KICBBbiBl eGFtcGxlIGF0dGFjayBoZXJlIGlzIHRoYXQgYSBjbGllbnQgaGFzIGFuIEEgcmVjb3JkDQogIGZv ciAid3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20+IiBwb2ludGluZyB0byAx OTIuMC4yLjEgY2FjaGVkIHBhc3QNCiAgaXRzIFRUTCBzbyB0aGUgRUFNVCByZWNvcmQgaXMgZ29u ZS4gIEFuIGF0dGFja2VyIGNvbnZpbmNlcw0KICBhbm90aGVyIHVzZXIgaW4gdGhlIHNhbWUgaG9t ZSBuZXR3b3JrIHRvIGRvIGEgRE5TIGxvb2t1cA0KICB0aGF0IGhhcyBhbiBBIHJlY29yZCBvZiAx OTIuMC4yLi4xICh3aGljaCB0aGUgYXR0YWNrZXIgZG9lc24ndCBvd24pDQogIGJ1dCBhIEFBQUEg cmVjb3JkIGZvciAyMDAxOmRiODplZWVlOjplZWVlICh3aGljaCBpcyBhdHRhY2tlci1jb250cm9s bGVkKS4NCiAgRXZlbiBpZiAxOTIuMC4yLjEgaXMgSVB2NC1vbmx5LCBpZiB0aGUgRUFNVCBlbnRy eSBoYXMgZXhwaXJlZCBvciBuZXZlcg0KICBleGlzdGVkIHRoZW4gdGhlIGF0dGFja2VyIGNhbiBy ZWRpcmVjdCBhbGwgdHJhZmZpYyB0byBpdCB0byBhbiBJUHY2IGFkZHJlc3MNCiAgb2YgdGhlaXIg Y2hvaWNlLiAgTm8gRE5TIHNwb29maW5nIGlzIG5lZWRlZCBoZXJlIGF0IGFsbCwganVzdCBtYWtp bmcNCiAgYSAiY2xhaW0iIHRoYXQgdGhlIEEvQUFBQSBhcmUgYXNzb2NpYXRlZCAod2hpY2ggaGFz IG5vIGF1dGhlbnRpY2F0aW9uKS4NCiAgVGhpcyBpcyBwb3RlbnRpYWxseSB3b3JzZSBhcyBJJ2Qg aHlwb3RoZXNpemUgdGhhdCBJUHY0LW9ubHkgU1RCDQogIGNsaWVudHMgYXJlIG11Y2ggbGVzcyBs aWtlbHkgdG8gdXNlIEhUVFBTL1RMUy4uDQpbSm9yZGldIEkgdGhpbmsgdGhhdCBoYXZpbmcgYSBw ZXItaG9zdCBFQU1UIGVudHJpZXMgcmVzb2x2ZXMgdGhpcy4NCg0KW0VkdWFyZF0gSSBiZWxpZXZl IHRoYXQgdGhpcyBkcmFmdCAodGhhdCBzaW11bGF0ZSBub3JtYWwgaG9zdHMpIGNvdWxkIG5vdCBy ZXNvbHZlIHRoaXMgcHJvYmxlbSBpbiBwcmluY2lwbGUuDQpJZiBzb21lYm9keSBhcmUgY2FwYWJs ZSB0byBwcm9ncmFtIDNyZCBwYXJ0eSBGUUROIHRvIGZha2UgQUFBQSByZWNvcmQgKG9mIGhpcyks IHRoZW4gdGhlIHdob2xlIGludGVybmV0IHdvdWxkIGJlIGFmZmVjdGVkLg0KVGhpcyBmYWtlIHJl Y29yZCB3b3VsZCBiZSB1c2VkIGJ5IG5vcm1hbCBJUHY2LW9ubHkgYW5kIER1YWwtU3RhY2sgaG9z dHMuDQpJdCBpcyBkZWZpbml0ZWx5IG5vdCBhIHByb2JsZW0gZm9yIHRoaXMgZHJhZnQuDQpBbmQg RE5TIHN0YW5kYXJkcyBoYXZlIGEgbG90IG9mIHRvb2xzIGFnYWluc3QgdGhpcy4NCg0KRWR1YXJk DQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKT1JESSBQQUxFVCBNQVJUSU5FWg0KU2VudDogMjAg0LjRjtC70Y8gMjAyMCDQsy4gMDo1NA0K VG86IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFt2Nm9wc10gZHJhZnQt aWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMiAtIDUuMi42IGFuZCB0aGUgcmVzdA0K DQoNCj4gNS4yLjYuDQo+ICJUaGUgZXhpc3RpbmcgRUFNVCBlbnRyeSBmb3IgMTkyLjAuMi4xIGlz IHNldCBhcyBpbnZhbGlkIi4NCg0KQ2xhcmlmeSB0aGF0Og0KKiA1LiBFeGlzdGluZyBjb25uZWN0 aW9ucyB0byAxOTIuMC4yLi4xIHJlbWFwcGVkIHRvIDIwMDE6ZGI4OjphOmI6YzpkDQogIE1VU1Qg Tk9UIGJlIGJyb2tlbi4NCltKb3JkaV0gWWVzLCB0aGlzIGhhcyBiZWVuIHNvbHZlZCB3aXRoIHRo ZSBzdGFsZSBzdGF0dXMgOg0KNS4gIFRoZSBleGlzdGluZyBFQU1UIGVudHJ5IGZvciAxOTIuMC4y LjEgaXMgc2V0IHRvIFN0YWxlDQpBbmQNCg0KNS4yLjEzLiAgRmFsc2UgZGV0ZWN0aW9uIG9mIGEg ZHVhbC1zdGFjayBob3N0IGFzIElQdjQtb25seQ0KDQoNCg0KICAgSWYgYSBkdWFsLXN0YWNrIGhv c3QgaXMgYmVpbmcgZGV0ZWN0ZWQgYXMgSVB2NC1vbmx5LCBpcyBiZWNhdXNlIGl0IGlzDQoNCiAg IG5vdCByZXNwb25kaW5nIHRvIHRoZSBDRSBORCBtZXNzYWdlcywgc28gYnkgYWxsIG1lYW5zLCBz aG91bGQgYmUNCg0KICAgY29uc2lkZXJlZCwgYXQgdGhlIHRpbWUgYmVpbmcsIGFzIElQdjQtb25s eSwgYW5kIGNvbnNlcXVlbnRseSBFQU1UDQoNCiAgIGVudHJpZXMgd2lsbCBiZSBjcmVhdGVkIGFu ZCB0cmFmZmljIHdpbGwgYmUgb3B0aW1pemVkIGZvciBJUHY0IGZsb3dzLg0KDQoNCg0KICAgSG93 ZXZlciwgaWYgdGhpcyBob3N0cyBzdWRkZW5seSBiZWNvbWUgSVB2Ni1lbmFibGVkIChvciBkdWFs LXN0YWNrKSwNCg0KICAgdGhlIHJlbGV2YW50IEVBTVQgZW50cmllcyBtdXN0IGJlIGZsYWdnZWQg YnkgdGhlIENFIGFzICJTdGFsZSIuICBUaGUNCg0KICAgaG9zdCB3aWxsIGJlIGFibGUgdG8gY29t cGxldGUgdGhlIGNvbm5lY3Rpb25zIGFuZCB0aGUgZW50cmllcyB3aWxsIGJlDQoNCiAgIG1hcmtl ZCBhcyAiSW52YWxpZCIgYW5kIGRlbGV0ZWQuDQoNCg0KDQogICBBbnl3YXksIHRob3NlIEVBTVQg ZW50cmllcywgd2hpbGUgIlZhbGlkIiwgbWF5IG5vdCBiZSBhY3R1YWxseSB1c2VkDQoNCiAgIGJ5 IHRoZSBkdWFsLXN0YWNrIGhvc3RzLCBiZWNhdXNlIHRob3NlIGhvc3RzIG9yIGFwcGxpY2F0aW9u cyBzaG91bGQNCg0KICAgcHJlZmVyIElQdjYsIHNvIG1vc3QgcHJvYmFibHkgd2FzIGVpdGhlciBh IHRlbXBvcmFyeSBmYWlsdXJlIG9yIGRvbmUNCg0KICAgb24tcHVycG9zZSAodXNlciwgdHJvdWJs ZXNob290aW5nKS4gIElmIHRoZSBob3N0IGlzIHByZWZlcnJpbmcgSVB2NA0KDQogICBmb3IgY29u bmVjdGluZyB0byB0aGUgQ0ROL2NhY2hlIG9yIElQdjYtZW5hYmxlZCBzZXJ2aWNlLCBpdCB3aWxs IGJlDQoNCiAgIGFjdHVhbGx5IHVzaW5nIHRoZSBOQVQ0Ni9DTEFULCBpbmNsdWRpbmcgdGhlIEVB TVQgZW50cnkgYW5kDQoNCiAgIGNvbnNlcXVlbnRseSBJUHY2LCBzbyB0aGlzIG1lY2hhbmlzbSB3 aWxsIGJlIGNvcnJlY3RpbmcgYW4NCg0KICAgdW5kZXNpcmFibGUgYmVoYXZpb3IuICBUaGlzIG1h eSBiZSBhbHNvIGEgc3BlY2lhbCBjYXNlLCB3aGljaA0KDQogICBhY3R1YWxseSBzZWVtcyB0byBi ZSBhbiBpbmNvaGVyZW50IGhvc3Qgb3IgYXBwbGljYXRpb24NCg0KICAgaW1wbGVtZW50YXRpb24u DQoNCg0KDQo9PT09PT09DQoNCj4gNS4yLjcuICBCZWhhdmlvciBpbiBjYXNlIG9mIG11bHRpcGxl IEEvQUFBQSBSUnMNCg0KQWdyZWVkIHdpdGggSmVuJ3MgZWFybGllciBjb21tZW50IHRoYXQgdGhp cyBuZWVkcyBtb3JlIGNsYXJpZmljYXRpb24uICBFeGFtcGxlIGFsZ29yaXRobToNCg0KKiBGb3Ig ZWFjaCBBIHJlY29yZCBvbiB0aGUgQSBSUnNldCwgY3JlYXRlIGFuIEVBTVQgZW50cnkgd2l0aCBh IHJhbmRvbWx5DQogIHNlbGVjdGVkIHJlY29yZCBmcm9tIHRoZSBBQUFBIFJSc2V0Lg0KDQoqIFJl c29sdmVyIHNob3VsZCBpZGVhbGx5IHJhbmRvbWx5IHBlcm11dGUgdGhlIEEgUlJzZXQgcHJpb3Ig dG8NCiAgcmV0dXJuaW5nIHRvIHRoZSBjbGllbnQNCg0KW0pvcmRpXSAgSWYgSSBnb3QgY29ycmVj dGx5IHdoYXQgeW91IG1lYW4sIHRoZSBnb2FsIGlzIHRvIGVuc3VyZSB0aGF0IHNldmVyYWwgZGV2 aWNlcyB1c2luZyB0aGUgc2FtZSBDRE4gcmVzb3VyY2VzLCBnZXQgZGlmZmVyZW50IEEvQUFBQSBw YWlycyAoRUFNVCBlbnRyaWVzKS4gQWxzbywgdGhhdCB0aGUgc2FtZSBDRSBpbiBkaWZmZXJlbnQg Y3VzdG9tZXJzLCBpcyBub3Qg4oCcYWx3YXlz4oCdIHVzaW5nIHRoZSBzYW1lIEEvQUFBQSBwYWly LCBzbyB0aGUgbG9hZCBpcyDigJxiYWxhbmNlZOKAnSBhcyBtdWNoIGFzIHBvc3NpYmxlIGFtb25n IHRoZSBDRE4gcmVzb3VyY2VzLiBJIGNvdWxkbuKAmXQgZmluZSBpZiB0aGlzIGlzIGFscmVhZHkg c3BlY2lmaWVkIGF0IHRoYXQgbGV2ZWwgaW4gYSBwcmV2aW91cyBkb2N1bWVudCwgc28gd2hpbGUg SSBhc3N1bWUgc29tZSByYW5kb20gaXMgYXBwbGllZCBpbiByZXNvbHZlcnMsIHdlIHdhbnQgdG8g dGFrZSB0aGUgb3Bwb3J0dW5pdHkgdG8gZW5zdXJlIGl0LiBTbyBtYXliZToNCg0KNS4yLjkuICBC ZWhhdmlvciBpbiBjYXNlIG9mIG11bHRpcGxlIEEvQUFBQSBSUnMNCg0KICAgSWYgbXVsdGlwbGUg QS9BQUFBIFJScyBhcmUgYXZhaWxhYmxlLCBhbnkgb2YgdGhlbSBjb3VsZCBiZQ0KICAgY2hvc2Vu IGFuZCBpbiBnZW5lcmFsLCB0aGUgb3B0aW1pemF0aW9uIHdpbGwgbm90IHByZXNlbnQgYW55DQog ICBkaWZmZXJlbnQgcmVzdWx0IHRvIHRoZSBob3N0cyBjb21wYXJlZCB3aXRoIGEgc2l0dWF0aW9u IHdoZXJlIHRoZQ0KICAgb3B0aW1pemF0aW9uIGlzIG5vdCB1c2VkLg0KDQogICBFeGlzdGluZyBE TlMgcHJveHkvc3R1YiByZXNvbHZlcnMgYWxyZWFkeSBpbXBsZW1lbnQgbWVjaGFuaXNtcyBmb3IN CiAgIEROUyBMb2FkIEJhbGFuY2luZyAoW1JGQzE3OTRdKS4gIFRoaXMgZG9uJ3QgbmVlZCB0byBi ZSBtb2RpZmllZCB0bw0KICAgaW1wbGVtZW50IHRoZSBvcHRpbWl6YXRpb24sIGlmIHNvbWUgZGVn cmVlIG9mIHJhbmRvbW5lc3MgaXMgYWxyZWFkeSBzZWN1cmVkLg0KDQogICBUbyBzZWN1cmUgc3Vm ZmljaWVudCByYW5kb21uZXNzLCBhIHBvc3NpYmxlIGFsZ29yaXRobSBzaGFsbCBlbnN1cmUNCiAg IHRoYXQgZGlmZmVyZW50IEVBTVQgZW50cmllcyAoZm9yIGRpZmZlcmVudCBob3N0cykgYXJlIHBl cm11dGVkDQogICByYW5kb21seSBhbW9uZyBkaWZmZXJlbnQgQS9BQUFBIHJlY29yZHMgb24gdGhl IEEvQUFBQSBSUiBzZXQuDQoNCg0KDQo9PT09PT09PT09DQoNCj4gNS4yLi4xMCBCZWhhdmlvciBp biBjYXNlIG9mIEZvcmVpZ24gRE5TDQoNCkhvdyB3aWxsIHRoZSBtaXNtYXRjaGVzIHRoYXQgc2hv dWxkIHRyaWdnZXIgaW52YWxpZGF0aW9ucw0KZ2V0IGRldGVjdGVkIGluIHRoaXMgY2FzZT8NCg0K KiBCcmVha2FnZSBkdWUgdG8gYXMgbWlzbWF0Y2hlcyB3b24ndCBiZSBkZXRlY3RlZCBhbmQgcmVz dWx0IGluIGludmFsaWRhdGlvbnMNCiBpZiBvbmUgZGV2aWNlIG9yIGFwcCBpcyBkb2luZyBsb29r dXBzIHZpYSB0aGlzIHJlc29sdmVyIGJ1dCBhbm90aGVyIGlzIG5vdC4NCiAgQ29uc3RyYWluaW5n IHRoZSBFQU1UIGVudHJ5IHRvIHRoZSBJUHY0IGNsaWVudCBJUCBjb3VsZCBhdCBsZWFzdCBib3Vu ZA0KICB0aGUgZGFtYWdlIHRvIGEgc2luZ2xlIGRldmljZSwgYnV0IG5vdCBpZiBzb21lIGFwcHMg b24gaXQgdXNlIGRpZmZlcmVudA0KICByZXNvbHZlciBzY2hlbWVzLg0KDQoqIEkgYmVsaWV2ZSBH b29nbGUgc2hpcHMgQ2hyb21lY2FzdCB0byBoYXJkY29kZSBETlMgbG9va3VwcyB0byA4LjguOC44 DQogIGluIGFkZGl0aW9uIHRvIGFsc28gc29tZXRpbWVzIHVzaW5nIHRoZSBsb2NhbCByZXNvbHZl ci4gIFNvbWUgb3RoZXIgU1RCcyBhbmQgbW9iaWxlIGFwcHMNCiAgZG8gdGhlIHNhbWUuICBUaGlz IGhhcyBzaWduaWZpY2FudCBwb3RlbnRpYWwgZm9yIG1pc21hdGNoZXMgdG8gbm90IGdldA0KICBk ZXRlY3RlZCBhbmQgbm90IGdldCBpbnZhbGlkYXRlZC4NCltKb3JkaV0gQWxsIHRoaXMgaXMgbm8g bG9uZ2VyIGEgcHJvYmxlbTogV2UgZG9u4oCZdCBvcHRpbWl6ZSBpZiBhIGZvcmVpZ24gRE5TIGlz ICB1c2VkLg0KDQo9PT09PT09PT09PT09PT09DQoNCj4gNS4yLjEzLiAgVHJvdWJsZXNob290aW5n IEltcGxpY2F0aW9ucw0KDQpIb3cgZG8gY29ybmVyLWNhc2VzIGFyb3VuZCBjb2xsaXNpb25zIHdo ZXJlIEVBTVQgZW50cmllcw0KZG9uJ3QgZ2V0IHByb3ByZXJseSBpbnZhbGlkYXRlZCBnZXQgZGVi dWdnZWQgYnkgdGhlIElTUA0KKGFuZCBjb250ZW50IHByb3ZpZGVyISk/DQoNClRoaXMgaXMgb3Bh cXVlIHRvIHRoZSBDRE4gYW5kIGNvdWxkIHJlc3VsdCBpbiBsb3RzIG9mIGVzY2FsYXRpb25zIGZy b20NCmVuZC11c2VycyBhbmQgY3VzdG9tZXJzLiAgVGhlIG5ldCByZXN1bHQgd2lsbCBiZSBmb3Ig Y29udGVudCB0byBnZXQNCnN3aXRjaGVkIHRvIElQdjQtb25seSBpZiB0aGF0ICJmaXhlcyIgdGhl IHByb2JsZW0gd2hpY2ggbWlnaHQgaW1wYWN0DQp1c2VycyB3b3JsZC13aWRlLiAgKE5laXRoZXIg dGhlIENETiBvciB0aGVpciBjdXN0b21lciBoYXMgYW55DQp2aXNpYmlsaXR5IGludG8gd2hhdCBp cyBnb2luZyBvbiBoZXJlIG90aGVyIHRoYW4gdGhhdCBzb21lIGVuZCB1c2Vycw0KbWF5IGJlIHJl cG9ydGluZyBub3QgYmVpbmcgYWJsZSB0byB2aWV3IGR1YWwtc3RhY2tlZCBjb250ZW50LikNCltK b3JkaV0gSWYgdGhlIHRyb3VibGVzaG9vdGluZyBpcyBkb25lIHdpdGggZHVhbC1zdGFjayBob3N0 LCBubyBpc3N1ZXMuIElmIGl0IGlzIGFuIElQdjQtb25seSBob3N0LCB0aGUgb3B0aW1pemF0aW9u IGNhbiBiZSBmdWxseSBkaXNhYmxlZCwgb3Igc3BlY2lmaWMgZW50cmllcyBjYW4gYmUgZGlzYWJs ZWQuIElzIG5vdCB0aGF0IHNvbHZpbmcgdGhlIHByb2JsZW0/IFRoaXMgaXMgdGhlIHRleHQgSeKA mXZlIHJpZ2h0IG5vdzoNCg0KDQo1LjIuMTUuICBUcm91Ymxlc2hvb3RpbmcgSW1wbGljYXRpb25z DQoNCg0KDQogICBXaGVuIHRoZXJlIGlzIGEgbmVlZCB0byB0cm91Ymxlc2hvb3QgSVB2NCBmcm9t IHRoZSBDRSBMQU5zLCBpdCBtYXkNCg0KICAgaGFwcGVuIHRoYXQgdGhlcmUgaXMgYW4gRUFNVCBl bnRyeSBmb3JjaW5nIHRoZSBmbG93IHRvIGEgZ2l2ZW4NCg0KICAgZGVzdGluYXRpb24ocykgdG8g dXNlIElQdjYsIHdoaWNoIHdpbGwgZGlzdG9ydCB0aGUgcmVzdWx0cywgdW5sZXNzDQoNCiAgIHRo ZSBob3N0IGJlaW5nIHVzZWQgaXMgZHVhbC1zdGFjayAod2hpY2ggaXMgdGhlIG1vc3QgY29tbW9u DQoNCiAgIHNpdHVhdGlvbikuDQoNCg0KDQogICBUaGlzIGNhbiBiZSBhdm9pZGVkLCB1c2luZyBh IENMSS9HVUkgb3IgcHJvdmlzaW9uaW5nIHByb2NlZHVyZSwgdG8NCg0KICAgZWl0aGVyIGNvbXBs ZXRlbHkgZGlzYWJsZSB0aGUgb3B0aW1pemF0aW9uIGR1cmluZyB0aGUNCg0KICAgdHJvdWJsZXNo b290aW5nLCBvciBjcmVhdGUgc3BlY2lmaWMgc3RhdGljIEVBTVQgZW50cmllcywgdXNpbmcgdGhl DQoNCiAgIFZhbGlkL1N0YWxlL0ludmFsaWQgYW5kIEF1dG8vU3RhdGljIGZsYWdzLCBhcyBkZXNj cmliZWQgaW4NCg0KICAgU2VjdGlvbiA1LjIuNS4NCg0KDQoNCiAgIENvbnNlcXVlbnRseSwgdGhl IENFIE1VU1QgYWxsb3cgYm90aCwgZGlzYWJsaW5nIHRoZSBvcHRpbWl6YXRpb24gYW5kDQoNCiAg IHRoZSBzZXR1cCBvZiBtYW51YWwvc3RhdGljIEVBTVQgZW50cmllcy4NCg0KDQoNCg0KPT09PT09 PT09PT09DQpHZW5lcmFsIGZvciA1LjIueDoNCg0KKiBTaG91bGQgdGhpcyBkb2MgdXNlIG1vcmUg bm9ybWF0aXZlIGxhbmd1YWdlIGluIHBsYWNlcyB3aGVyZSB3YXJyYW50ZWQ/DQogIChUaGVyZSBh cmUgYSBidW5jaCBvZiBNVVNUIE5PVCBzaGFycCBlZGdlcy4pDQogIEVzcGVjaWFsbHkgaW4gNS4y LjQuDQoNCiogQ2xhcmlmeSB0aGF0IEVBTVQgdGFibGUgdXBkYXRlcyBNVVNUIGJlIG1hZGUgYmVm b3JlIEEgcmVjb3JkDQogIGlzIHJldHVybmVkIHRvIHRoZSBjbGllbnQgKGVzcGVjaWFsbHkgaW52 YWxpZGF0aW9ucyEpLiAgT3RoZXJ3aXNlIHRoZXJlDQogIGlzIGEgcG90ZW50aWFsIHJhY2UgY29u ZGl0aW9uLi4NCg0KKiBXaGF0IGhhcHBlbnMgaWYgdGhlIEZRRE5zIG1pc21hdGNoIGJ1dCB0aGUg QSBhbmQgQUFBQSBSUnNldHMgYXJlIGlkZW50aWNhbD8NClRoaXMgaXMgZ29pbmcgdG8gYmUgdmVy eSBjb21tb24gYXMgbWFueSBDRE5zIHVzZSBsb3RzIG9mIG5hbWVzDQogd2l0aCBhIHNtYWxsZXIg bnVtYmVyIG9mIElQdjQgYWRkcmVzc2VzLg0KICBXaGF0IGlmIHRoZSBBIGFuZCBBQUFBIFJSc2V0 cyBvdmVybGFwIGJ1dCBhcmVuJ3QgaWRlbnRpY2FsPw0KICAoUGVyaGFwcyB0aGUgRUFNVCBlbnRy eSBNVVNUIGJlIG1hcmtlZCBpbnZhbGlkIGlmIHRoZSBGUUROcyBtaXNtYXRjaA0KICBhbmQgdGhl IEVBTVQgZW50cnkgZG9lcyBub3QgaGF2ZSBib3RoIGl0cyBBICphbmQqIEFBQUEgdmFsdWVzDQog IGluIHRoZSByZXR1cm5lZCBSUnNldHMuICBpZSwgYWxsIEVBTVQgZW50cmllcyBtdXN0IGJlIHZh bGlkDQogIHdpdGhpbiB0aGUgbWlzbWF0Y2hpbmcgRlFETi4pDQogIChNYXkgc3RpbGwgYmUgY29y bmVyIGNhc2VzIGhlcmUgSSdtIGZvcmdldHRpbmc/KQ0KW0pvcmRpXSBJIHRoaW5rIGFsbCB0aGlz IGhhcyBiZWVuIGFscmVhZHkgcmVzb2x2ZWQuDQoNCiogV2UgaGF2ZSBhIHJlY29tbWVuZGVkIG1h eGltdW0gY2FwL3RocmVzaG9sZCBvbiB0aGUgVFRMPw0KICAoZXZlbiBpZiBpdCdzIHNvbWV0aGlu ZyBsaWtlIDggaG91cnMuLi4pICBPdGhlcndpc2UgYmFkIGVudHJpZXMNCiAgbWlnaHQgc3RpY2sg YXJvdW5kIHRvbyBsb25nLg0KW0pvcmRpXSBUaGlzIGlzIGFuIG9wZW4gcXVlc3Rpb24uIEkgZG9u 4oCZdCBrbm93IGlmIGl0IG1ha2VzIHNlbnNlIHRvIGludmFsaWRhdGUgdGhlIHN0YWxlIGVudHJp ZXMgaWYgdGhlIGNvbm5lY3Rpb25zIGRvbuKAmXQgZGllIOKApiBhbmQgaWYgc28sIEkgZ3Vlc3Mg eW91ciA4IGhvdXJzIGNvbWUgZnJvbSB5b3VyIENETiB2aWV3IG9mIG9wZXJhdGlvbmFsIGRldGFp bHMgKGNoYW5nZXMgaW4gRlFETnMvQS9BQUFBKSwgb3IgaXQgaXMganVzdCByYW5kb20/DQoNCj09 PT09PT09PT0NCg0KQWRkaXRpb25hbCBzZWN1cml0eSBjb25zaWRlcmF0aW9uczoNCg0KKFRoZSBm aXJzdCBvZiB0aGVzZSBpcyBtaW5vciAtLS0gdGhlIG90aGVycyBzZWVtIGxpa2UgdGhleSBtYWtl IHRoaXMgdG9vIGRhbmdlcm91cyB0byBkZXBsb3kuDQpJdCBtYXkgYmUgd29ydGggaGF2aW5nIGEg U2VjdXJpdHkgQUQgZG8gc29tZSBmb2N1c2VkIHJldmlldyBpbiB0aGlzIGNvbnRleHQuKQ0KDQoq IEZpbGxpbmcgRUFNVCB0YWJsZSB3aXRoIHZlcnkgbG9uZyBUVEwgcmVjb3Jkcy4gIChpZSwgdHJp Z2dlcmluZyBhIGNsaWVudCB0bw0KICBkbyBETlMgbG9va3VwcyB0aGF0IGNyZWF0ZSBsb3RzIG9m IGxvbmctbGl2ZWQgYXNzb2NpYXRpb25zKQ0KW0pvcmRpXSBZZXAsICBzYW1lIHBvaW50IGFzIHRo ZSA4IGhvdXJzLiBTaG91bGQgd2Ugc2V0IHNvbWUgbGltaXRzIGZvciB0aGUgRUFNVCBlbnRyaWVz LCBkZXNwaXRlIHRoZSBUVExzPw0KDQoqIFRoZXJlIGlzIGFuIHNlcmlvdXMgcmlzayBleHBvc3Vy ZSB0byBoaWphY2tpbmcgdHJhZmZpYyBieSBpbnNlcnRpbmcgYm9ndXMgYmluZGluZw0KICAoaWUs IHJldHVybiB0YXJnZXQncyBBIHJlY29yZCBhbmQgbWFsaWNpb3VzIGFjdG9yJ3MgQUFBQSByZWNv cmQpLg0KICBJbiBtb3N0IGNhc2VzIHRoZXNlIHJlY29yZHMgc2hvdWxkIGdldCBtYXJrZWQgYXMg SW52YWxpZCwNCiAgYnV0IHRoZSBjb3JuZXIgY2FzZXMgaGVyZSBhcmUgZnJhZ2lsZSAoZWcsIHdp dGggZm9yZWlnbiBETlMgb3INCiAgY2xpZW50cyBjYWNoaW5nIHBhc3QgdGhlIFRUTCBtaXhlZCBp biBoZXJlLg0KICBBbiBleGFtcGxlIGF0dGFjayBoZXJlIGlzIHRoYXQgYSBjbGllbnQgaGFzIGFu IEEgcmVjb3JkDQogIGZvciAid3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20+ IiBwb2ludGluZyB0byAxOTIuMC4yLjEgY2FjaGVkIHBhc3QNCiAgaXRzIFRUTCBzbyB0aGUgRUFN VCByZWNvcmQgaXMgZ29uZS4gIEFuIGF0dGFja2VyIGNvbnZpbmNlcw0KICBhbm90aGVyIHVzZXIg aW4gdGhlIHNhbWUgaG9tZSBuZXR3b3JrIHRvIGRvIGEgRE5TIGxvb2t1cA0KICB0aGF0IGhhcyBh biBBIHJlY29yZCBvZiAxOTIuMC4yLi4xICh3aGljaCB0aGUgYXR0YWNrZXIgZG9lc24ndCBvd24p DQogIGJ1dCBhIEFBQUEgcmVjb3JkIGZvciAyMDAxOmRiODplZWVlOjplZWVlICh3aGljaCBpcyBh dHRhY2tlci1jb250cm9sbGVkKS4NCiAgRXZlbiBpZiAxOTIuMC4yLjEgaXMgSVB2NC1vbmx5LCBp ZiB0aGUgRUFNVCBlbnRyeSBoYXMgZXhwaXJlZCBvciBuZXZlcg0KICBleGlzdGVkIHRoZW4gdGhl IGF0dGFja2VyIGNhbiByZWRpcmVjdCBhbGwgdHJhZmZpYyB0byBpdCB0byBhbiBJUHY2IGFkZHJl c3MNCiAgb2YgdGhlaXIgY2hvaWNlLiAgTm8gRE5TIHNwb29maW5nIGlzIG5lZWRlZCBoZXJlIGF0 IGFsbCwganVzdCBtYWtpbmcNCiAgYSAiY2xhaW0iIHRoYXQgdGhlIEEvQUFBQSBhcmUgYXNzb2Np YXRlZCAod2hpY2ggaGFzIG5vIGF1dGhlbnRpY2F0aW9uKS4NCiAgVGhpcyBpcyBwb3RlbnRpYWxs eSB3b3JzZSBhcyBJJ2QgaHlwb3RoZXNpemUgdGhhdCBJUHY0LW9ubHkgU1RCDQogIGNsaWVudHMg YXJlIG11Y2ggbGVzcyBsaWtlbHkgdG8gdXNlIEhUVFBTL1RMUy4uDQpbSm9yZGldIEkgdGhpbmsg dGhhdCBoYXZpbmcgYSBwZXItaG9zdCBFQU1UIGVudHJpZXMgcmVzb2x2ZXMgdGhpcy4NCg0KKiBU aGlzIHByZXZpb3VzIHJpc2sgaXMgcGFydGljdWxhcmx5IHByb2JsZW1hdGljIGZvciBoaWphY2tp bmcgdHJhZmZpYyBmcm9tDQogIHVzZXJzL2RldmljZXMvY2xpZW50cyB1c2luZyBGb3JlaWduIERO UyBzaW5jZSB0aGV5IHdvbid0IGNyZWF0ZQ0KICBFQU1UIGVudHJpZXMgYnV0IHdpbGwgYmUgZXhw b3NlZCB0byBjbGllbnRzIGdldHRpbmcgdHJpY2tlZCBpbnRvIGNyZWF0aW5nIHRoZW0uDQogIChU aGlzIGNDb3VsZCBiZSBlc3BlY2lhbGx5IHByb2JsZW1hdGljIGZvciB1c2VycyB1c2luZyBEb0gg Zm9yIHByaXZhY3kNCiAgb24gb25lIGRldmljZSwgYnV0IHRoZW4gYW5vdGhlciBkZXZpY2UgaW4g dGhlaXIgaG9tZSBhbGxvd3MNCiAgdGhlbSB0byBiZSBoamlqYWNrZWQuICBBdCBzb21lIHBvaW50 IEZpcmVmb3ggcHJlZmVycmVkIElQdjQgaW4gc29tZQ0KICBjYXNlcyB3aGVuIHVzaW5nIERvSCBz byB0aGlzIG1heSBiZSBhIHJlYWwgZXhwb3N1cmUNCiAgLyB2dWxuZXJhYmlsaXR5IHJpc2suKQ0K W0pvcmRpXSBOb3QgYW55bW5vcmUsIGJlY2F1c2Ugd2UgZG9u4oCZdCByZXVzZSBFQU1UIGVudHJp ZXMgZnJvbSBvbmUgaG9zdCB0byBhbm90aGVyLg0KDQpTb3JyeSBhZ2FpbiBmb3Igbm90IHNlbmRp bmcgdGhlc2UgZWFybGllciAtLS0gSSB0aGluayBhIGJ1bmNoIG9mIHRoZXNlDQpjb25jZXJucyB3 ZXJlIHJhaXNlZCBpbiBteSBwcmV2aW91cyBmZWVkYmFjayBhbmQgd2hpbGUgdGhpcyB2ZXJzaW9u DQpoYXMgbWFkZSBzaWduaWZpY2FudCBpbXByb3ZlbWVudHMsIEknbSBzdGlsbCB2ZXJ5IGNvbmNl cm5lZCB0aGF0IGl0IHdpbGwNCmJlIHZlcnkgcmlza3kgZnJvbSBhbiBvcGVyYXRpb25hbCBmcmFn aWxpdHkgYW5kIHNlY3VyaXR5IHBlcnNwZWN0aXZlLg0KDQogICAgIEVyaWsNCg0KW0pvcmRpXSBO b3QgYXQgYWxsLCB2ZXJ5IGhhcHB5IGZvciBzbyBtdWNoIGRldGFpbGVkIHJldmlldy4gU29tZXRp bWVzIGEgbGFzdC1jYWxsLCBldmVuIGlmIGZhaWxlZCwgaXMgZ29vZCB0byBnZXQgYWxsIHRoaXMh DQoNCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN CklQdjQgaXMgb3Zlcg0KQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQpodHRw Oi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0KVGhlIElQdjYgQ29tcGFueQ0KDQpUaGlzIGVsZWN0 cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdl ZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3Ig dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1 cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVu IGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMg aW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMs IGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9m ZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3Jt IGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0K --_000_02f63b1af4284239801567cfaf4d9c9bhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5IVE1MY29uZm9ybWF0b3ByZXZpbywgbGkuSFRN TGNvbmZvcm1hdG9wcmV2aW8sIGRpdi5IVE1MY29uZm9ybWF0b3ByZXZpbw0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBjb24gZm9ybWF0byBwcmV2aW8iOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIGNv biBmb3JtYXRvIHByZXZpbyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5IVE1MY29uZm9ybWF0b3ByZXZpb0Nhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBjb24gZm9ybWF0byBwcmV2aW8gQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgY29uIGZvcm1hdG8gcHJldmlvIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgMy4wY20gNzAuODVwdCAzLjBjbTt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgYWxs LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5IaSBKb3JkaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPk15IGNvbW1lbnQgYWJvdXQgOGggVFRMOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGluc2lzdCB0 byBtYWtlIGl0IG11Y2ggbG9uZ2VyLiBJIGhhdmUgdGhlIHRoZW9yeSBiZWxvdyB3aHkgaXQgc2hv dWxkIGJlIGRlZmluaXRlbHkgbW9yZSB0aGFuIDI0aCwgcHJvYmFibHkgZXZlbiBsb25nZXIgKDEg d2Vlaz8pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhbSBhIHN1YnNj cmliZXIgKGF0IGRpZmZlcmVudCB0aW1lcykgb2YgTWVnYWZvbiwgTVRTLCBhbmQgVGVsZTIgUnVz c2lhLiBMYXN0IG9uZSB3b3VsZCBkcm9wIGFueSBjYWxsIGFmdGVyIDMwbWluLCBwcmV2aW91cyB0 d28gd291bGQgZHJvcCBhZnRlciAxaC4gTG9va3MgbGlrZSB0aGV5IGRvIG5vdCB3YW50IHN0YWxl IGNvbm5lY3Rpb24gdG9vIChlc3BlY2lhbGx5DQogcGFpZCkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IGlz IHZlcnkgZGlzdHJhY3Rpbmcgd2hlbiB5b3UgYXJlIG9uIGNvbmZlcmVuY2UgY2FsbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IGlzIHBlcmZlY3RseSBwb3NzaWJsZSB0 aGF0IHdlIHdvdWxkIHNlZSBvbmx5IG9uZSBETlMgcmVxdWVzdCBiZWZvcmUgbWVkaWEgc3RyZWFt IHdvdWxkIHN0YXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGNvdWxkIGltYWdpbmUgaW50ZXJhY3RpdmUg bWVkaWEgc3RyZWFtIGxvbmdlciB0aGFuIDhoLiBJIGNvdWxkIG5vdCBpbWFnaW5lIGludGVyYWN0 aXZlIGxvbmdlciB0aGVuIDI0aCDigJMgcGVvcGxlIG5lZWQgdG8gc2xlZXAuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGF0ZXZlciB0aW1lciB5b3Ugd291bGQgaW50cm9k dWNlIOKAkyBJIGFtIHN1cmUgdGhhdCB3b3VsZCBiZSBjYXNlcyB3aGVuIGxlZ2l0aW1hdGUgY29u bmVjdGlvbiB3b3VsZCBiZSBkcm9wcGVkLiAyNGggd291bGQgYmUgcHJvYmFibHkgc2FmZSB0aW1l IGFnYWluc3QgaW50ZXJhY3RpdmUgc3RyZWFtIGludGVycnVwdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ QnV0IHNvbWUgdmlkZW8gY2FtZXJhIChzdXJ2ZWlsbGFuY2UpIG1heSBiZSBpbnRlcnJ1cHRlZCBl dmVuIGFmdGVyIDEgd2VlayB0aW1lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW5kIGlmIG9yaWdpbmFsIGFw cGxpY2F0aW9uIGRvZXMgbm90IGhhdmUgYSBsb2dpYyB0byByZWVzdGFibGlzaCBjb25uZWN0aW9u IChpdCBpcyBhc3N1bWVkIG1hbnVhbCBvciBkaWZmZXJlbnQgYXBwbGljYXRpb24gc2hvdWxkIHB1 c2gpIOKAkyB0aGVuIGFueSB0aW1lciBpcyBhIGRpc2FzdGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbWFn aW5lIGEgc3Vic2NyaWJlciB0aGF0IG5lZWRzIHRvIHJlZXN0YWJsaXNoIG1hbnVhbGx5IGhpcyB2 aWRlbyBzdXJ2ZWlsbGFuY2UgY29ubmVjdGlvbiBldmVyeSB3ZWVrIOKAkyB3aGF0IGhlIHdvdWxk IHRoaW5rIGFib3V0IHVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2Ug aGF2ZSB0cmFkZSBvZmYgaGVyZTogZHJvcCBzb21lIGxlZ2l0aW1hdGUgbG9uZyBzZXNzaW9ucyBv ciByZWZyZXNoIHRpbWVyIGFmdGVyIHN3aXRjaGluZyBldmVyeSBwYWNrZXQgYWdhaW5zdCB0aGlz IEVBTSBlbnRyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hvIGhhcyBleHBlcmllbmNlIHdpdGggQ1BFIGRl dmVsb3BtZW50OiBpcyBpdCByZWFsbHkgZXhwZW5zaXZlIGZvciBDUEUgdG8gcmVmcmVzaCBUVEwg YWZ0ZXIgYW55IHBhY2tldCBzd2l0Y2hlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlbiB0aW1lciBpbiAy NGggd291bGQgYmUgc2FmZS4gKGlzIHdlIGFyZSBzdXJlIHRoYXQgY29ubmVjdGlvbiBpcyByZWFs bHkgc3RhbGUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdp bi1sZWZ0OjM1LjRwdCI+DQoqIFRoZXJlIGlzIGFuIHNlcmlvdXMgcmlzayBleHBvc3VyZSB0byBo aWphY2tpbmcgdHJhZmZpYyBieSBpbnNlcnRpbmcgYm9ndXMgYmluZGluZzxicj4NCiZuYnNwOyAo aWUsIHJldHVybiB0YXJnZXQncyBBIHJlY29yZCBhbmQgbWFsaWNpb3VzIGFjdG9yJ3MgQUFBQSBy ZWNvcmQpLjxicj4NCiZuYnNwOyA8c3BhbiBsYW5nPSJFUyI+SW4gbW9zdCBjYXNlcyB0aGVzZSBy ZWNvcmRzIHNob3VsZCBnZXQgbWFya2VkIGFzIEludmFsaWQsPGJyPg0KJm5ic3A7IGJ1dCB0aGUg Y29ybmVyIGNhc2VzIGhlcmUgYXJlIGZyYWdpbGUgKGVnLCB3aXRoIGZvcmVpZ24gRE5TIG9yPGJy Pg0KJm5ic3A7IGNsaWVudHMgY2FjaGluZyBwYXN0IHRoZSBUVEwgbWl4ZWQgaW4gaGVyZS48YnI+ DQombmJzcDsgQW4gZXhhbXBsZSBhdHRhY2sgaGVyZSBpcyB0aGF0IGEgY2xpZW50IGhhcyBhbiBB IHJlY29yZDxicj4NCiZuYnNwOyBmb3IgJnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5leGFtcGxl LmNvbSI+d3d3LmV4YW1wbGUuY29tPC9hPiZxdW90OyBwb2ludGluZyB0byAxOTIuMC4yLjEgY2Fj aGVkIHBhc3Q8YnI+DQombmJzcDsgaXRzIFRUTCBzbyB0aGUgRUFNVCByZWNvcmQgaXMgZ29uZS4m bmJzcDsgQW4gYXR0YWNrZXIgY29udmluY2VzPGJyPg0KJm5ic3A7IGFub3RoZXIgdXNlciBpbiB0 aGUgc2FtZSBob21lIG5ldHdvcmsgdG8gZG8gYSBETlMgbG9va3VwPGJyPg0KJm5ic3A7IHRoYXQg aGFzIGFuIEEgcmVjb3JkIG9mIDE5Mi4wLjIuLjEgKHdoaWNoIHRoZSBhdHRhY2tlciBkb2Vzbid0 IG93bik8YnI+DQombmJzcDsgYnV0IGEgQUFBQSByZWNvcmQgZm9yIDIwMDE6ZGI4OmVlZWU6OmVl ZWUgKHdoaWNoIGlzIGF0dGFja2VyLWNvbnRyb2xsZWQpLjxicj4NCiZuYnNwOyBFdmVuIGlmIDE5 Mi4wLjIuMSBpcyBJUHY0LW9ubHksIGlmIHRoZSBFQU1UIGVudHJ5IGhhcyBleHBpcmVkIG9yIG5l dmVyPGJyPg0KJm5ic3A7IGV4aXN0ZWQgdGhlbiB0aGUgYXR0YWNrZXIgY2FuIHJlZGlyZWN0IGFs bCB0cmFmZmljIHRvIGl0IHRvIGFuIElQdjYgYWRkcmVzczxicj4NCiZuYnNwOyBvZiB0aGVpciBj aG9pY2UuJm5ic3A7IE5vIEROUyBzcG9vZmluZyBpcyBuZWVkZWQgaGVyZSBhdCBhbGwsIGp1c3Qg bWFraW5nPGJyPg0KJm5ic3A7IGEgJnF1b3Q7Y2xhaW0mcXVvdDsgdGhhdCB0aGUgQS9BQUFBIGFy ZSBhc3NvY2lhdGVkICh3aGljaCBoYXMgbm8gYXV0aGVudGljYXRpb24pLjxicj4NCiZuYnNwOyBU aGlzIGlzIHBvdGVudGlhbGx5IHdvcnNlIGFzIEknZCBoeXBvdGhlc2l6ZSB0aGF0IElQdjQtb25s eSBTVEI8YnI+DQombmJzcDsgY2xpZW50cyBhcmUgbXVjaCBsZXNzIGxpa2VseSB0byB1c2UgSFRU UFMvVExTLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+W0pvcmRpXSBJIHRoaW5rIHRoYXQgaGF2aW5nIGEg cGVyLWhvc3QgRUFNVCBlbnRyaWVzIHJlc29sdmVzIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5bRWR1YXJkXSBJIGJlbGlldmUgdGhhdCB0aGlzIGRyYWZ0ICh0aGF0 IHNpbXVsYXRlIG5vcm1hbCBob3N0cykgY291bGQgbm90IHJlc29sdmUgdGhpcyBwcm9ibGVtIGlu IHByaW5jaXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWYgc29tZWJvZHkgYXJlIGNhcGFibGUgdG8gcHJv Z3JhbSAzPHN1cD5yZDwvc3VwPiBwYXJ0eSBGUUROIHRvIGZha2UgQUFBQSByZWNvcmQgKG9mIGhp cyksIHRoZW4gdGhlIHdob2xlIGludGVybmV0IHdvdWxkIGJlIGFmZmVjdGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5UaGlzIGZha2UgcmVjb3JkIHdvdWxkIGJlIHVzZWQgYnkgbm9ybWFsIElQdjYtb25seSBh bmQgRHVhbC1TdGFjayBob3N0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQgaXMgZGVmaW5pdGVseSBub3Qg YSBwcm9ibGVtIGZvciB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BbmQgRE5TIHN0YW5kYXJk cyBoYXZlIGEgbG90IG9mIHRvb2xzIGFnYWluc3QgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g djZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj5KT1JESSBQQUxFVCBNQVJUSU5FWjxicj4NCjxiPlNlbnQ6PC9iPiAyMCDQuNGO0LvRjyAyMDIw INCzLiAwOjU0PGJyPg0KPGI+VG86PC9iPiBWNiBPcHMgTGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0 LW9wdGltaXphdGlvbi0wMiAtIDUuMi42IGFuZCB0aGUgcmVzdDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJFUyI+PGJyPg0KJmd0OyA1LjIuNi48YnI+DQomZ3Q7ICZx dW90O1RoZSBleGlzdGluZyBFQU1UIGVudHJ5IGZvciAxOTIuMC4yLjEgaXMgc2V0IGFzIGludmFs aWQmcXVvdDsuPGJyPg0KPGJyPg0KQ2xhcmlmeSB0aGF0Ojxicj4NCiogNS4gRXhpc3RpbmcgY29u bmVjdGlvbnMgdG8gMTkyLjAuMi4uMSByZW1hcHBlZCB0byAyMDAxOmRiODo6YTpiOmM6ZDxicj4N CiZuYnNwOyBNVVNUIE5PVCBiZSBicm9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPltKb3JkaV0gWWVz LCB0aGlzIGhhcyBiZWVuIHNvbHZlZCB3aXRoIHRoZSBzdGFsZSBzdGF0dXMgOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj41 LiZuYnNwOyBUaGUgZXhpc3RpbmcgRUFNVCBlbnRyeSBmb3IgMTkyLjAuMi4xIGlzIHNldCB0byBT dGFsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZDxvOnA+ PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjUuMi4xMy4mbmJzcDsg RmFsc2UgZGV0ZWN0aW9uIG9mIGEgZHVhbC1zdGFjayBob3N0IGFzIElQdjQtb25seTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBJZiBhIGR1YWwtc3RhY2sgaG9zdCBpcyBiZWluZyBkZXRlY3RlZCBhcyBJUHY0 LW9ubHksIGlzIGJlY2F1c2UgaXQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbm90IHJlc3BvbmRpbmcgdG8gdGhl IENFIE5EIG1lc3NhZ2VzLCBzbyBieSBhbGwgbWVhbnMsIHNob3VsZCBiZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBj b25zaWRlcmVkLCBhdCB0aGUgdGltZSBiZWluZywgYXMgSVB2NC1vbmx5LCBhbmQgY29uc2VxdWVu dGx5IEVBTVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgZW50cmllcyB3aWxsIGJlIGNyZWF0ZWQgYW5kIHRyYWZmaWMg d2lsbCBiZSBvcHRpbWl6ZWQgZm9yIElQdjQgZmxvd3MuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEhvd2V2 ZXIsIGlmIHRoaXMgaG9zdHMgc3VkZGVubHkgYmVjb21lIElQdjYtZW5hYmxlZCAob3IgZHVhbC1z dGFjayksPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSByZWxldmFudCBFQU1UIGVudHJpZXMgbXVzdCBiZSBmbGFn Z2VkIGJ5IHRoZSBDRSBhcyAmcXVvdDtTdGFsZSZxdW90Oy4mbmJzcDsgVGhlPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IGhvc3Qgd2lsbCBiZSBhYmxlIHRvIGNvbXBsZXRlIHRoZSBjb25uZWN0aW9ucyBhbmQgdGhlIGVu dHJpZXMgd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtYXJrZWQgYXMgJnF1b3Q7SW52YWxpZCZxdW90OyBh bmQgZGVsZXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQW55d2F5LCB0aG9zZSBFQU1UIGVudHJpZXMs IHdoaWxlICZxdW90O1ZhbGlkJnF1b3Q7LCBtYXkgbm90IGJlIGFjdHVhbGx5IHVzZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgYnkgdGhlIGR1YWwtc3RhY2sgaG9zdHMsIGJlY2F1c2UgdGhvc2UgaG9zdHMgb3IgYXBw bGljYXRpb25zIHNob3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwcmVmZXIgSVB2Niwgc28gbW9zdCBwcm9iYWJs eSB3YXMgZWl0aGVyIGEgdGVtcG9yYXJ5IGZhaWx1cmUgb3IgZG9uZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvbi1w dXJwb3NlICh1c2VyLCB0cm91Ymxlc2hvb3RpbmcpLiZuYnNwOyBJZiB0aGUgaG9zdCBpcyBwcmVm ZXJyaW5nIElQdjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZm9yIGNvbm5lY3RpbmcgdG8gdGhlIENETi9jYWNoZSBv ciBJUHY2LWVuYWJsZWQgc2VydmljZSwgaXQgd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY3R1YWxseSB1 c2luZyB0aGUgTkFUNDYvQ0xBVCwgaW5jbHVkaW5nIHRoZSBFQU1UIGVudHJ5IGFuZDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBjb25zZXF1ZW50bHkgSVB2Niwgc28gdGhpcyBtZWNoYW5pc20gd2lsbCBiZSBjb3JyZWN0 aW5nIGFuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IHVuZGVzaXJhYmxlIGJlaGF2aW9yLiZuYnNwOyBUaGlzIG1heSBi ZSBhbHNvIGEgc3BlY2lhbCBjYXNlLCB3aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY3R1YWxseSBzZWVtcyB0 byBiZSBhbiBpbmNvaGVyZW50IGhvc3Qgb3IgYXBwbGljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgPC9zcGFu PjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmltcGxlbWVudGF0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjEyLjBwdDttYXJnaW4tbGVmdDozNS40cHQiPg0KPGJyPg0KPT09PT09PTxicj4NCjxicj4NCiZn dDsgNS4yLjcuJm5ic3A7IDxzcGFuIGxhbmc9IkVTIj5CZWhhdmlvciBpbiBjYXNlIG9mIG11bHRp cGxlIEEvQUFBQSBSUnM8YnI+DQo8YnI+DQpBZ3JlZWQgd2l0aCBKZW4ncyBlYXJsaWVyIGNvbW1l bnQgdGhhdCB0aGlzIG5lZWRzIG1vcmUgY2xhcmlmaWNhdGlvbi4mbmJzcDsgRXhhbXBsZSBhbGdv cml0aG06PGJyPg0KPGJyPg0KKiBGb3IgZWFjaCBBIHJlY29yZCBvbiB0aGUgQSBSUnNldCwgY3Jl YXRlIGFuIEVBTVQgZW50cnkgd2l0aCBhIHJhbmRvbWx5PGJyPg0KJm5ic3A7IHNlbGVjdGVkIHJl Y29yZCBmcm9tIHRoZSBBQUFBIFJSc2V0Ljxicj4NCjxicj4NCiogUmVzb2x2ZXIgc2hvdWxkIGlk ZWFsbHkgcmFuZG9tbHkgcGVybXV0ZSB0aGUgQSBSUnNldCBwcmlvciB0bzxicj4NCiZuYnNwOyBy ZXR1cm5pbmcgdG8gdGhlIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPltKb3JkaV0mbmJzcDsgSWYgSSBnb3QgY29ycmVjdGx5IHdoYXQg eW91IG1lYW4sIHRoZSBnb2FsIGlzIHRvIGVuc3VyZSB0aGF0IHNldmVyYWwgZGV2aWNlcyB1c2lu ZyB0aGUgc2FtZSBDRE4gcmVzb3VyY2VzLCBnZXQgZGlmZmVyZW50IEEvQUFBQSBwYWlycyAoRUFN VCBlbnRyaWVzKS4gQWxzbywgdGhhdCB0aGUgc2FtZSBDRSBpbiBkaWZmZXJlbnQgY3VzdG9tZXJz LA0KIGlzIG5vdCDigJxhbHdheXPigJ0gdXNpbmcgdGhlIHNhbWUgQS9BQUFBIHBhaXIsIHNvIHRo ZSBsb2FkIGlzIOKAnGJhbGFuY2Vk4oCdIGFzIG11Y2ggYXMgcG9zc2libGUgYW1vbmcgdGhlIENE TiByZXNvdXJjZXMuIEkgY291bGRu4oCZdCBmaW5lIGlmIHRoaXMgaXMgYWxyZWFkeSBzcGVjaWZp ZWQgYXQgdGhhdCBsZXZlbCBpbiBhIHByZXZpb3VzIGRvY3VtZW50LCBzbyB3aGlsZSBJIGFzc3Vt ZSBzb21lIHJhbmRvbSBpcyBhcHBsaWVkIGluIHJlc29sdmVycywgd2UNCiB3YW50IHRvIHRha2Ug dGhlIG9wcG9ydHVuaXR5IHRvIGVuc3VyZSBpdC4gU28gbWF5YmU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj41LjIuOS4mbmJzcDsgQmVoYXZpb3IgaW4gY2FzZSBvZiBtdWx0aXBs ZSBBL0FBQUEgUlJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSWYgbXVs dGlwbGUgQS9BQUFBIFJScyBhcmUgYXZhaWxhYmxlLCBhbnkgb2YgdGhlbSBjb3VsZCBiZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgY2hvc2VuIGFuZCBpbiBnZW5lcmFsLCB0aGUgb3B0aW1pemF0aW9u IHdpbGwgbm90IHByZXNlbnQgYW55PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgcmVz dWx0IHRvIHRoZSBob3N0cyBjb21wYXJlZCB3aXRoIGEgc2l0dWF0aW9uIHdoZXJlIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgb3B0aW1pemF0aW9uIGlzIG5vdCB1c2VkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEV4aXN0aW5nIEROUyBwcm94eS9zdHViIHJlc29sdmVy cyBhbHJlYWR5IGltcGxlbWVudCBtZWNoYW5pc21zIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg RE5TIExvYWQgQmFsYW5jaW5nIChbUkZDMTc5NF0pLiZuYnNwOyBUaGlzIGRvbid0IG5lZWQgdG8g YmUgbW9kaWZpZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudCB0aGUgb3B0aW1p emF0aW9uLCBpZiBzb21lIGRlZ3JlZSBvZiByYW5kb21uZXNzIGlzIGFscmVhZHkgc2VjdXJlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUbyBzZWN1cmUgc3VmZmljaWVu dCByYW5kb21uZXNzLCBhIHBvc3NpYmxlIGFsZ29yaXRobSBzaGFsbCBlbnN1cmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHRoYXQgZGlmZmVyZW50IEVBTVQgZW50cmllcyAoZm9yIGRpZmZlcmVudCBo b3N0cykgYXJlIHBlcm11dGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByYW5kb21seSBhbW9uZyBk aWZmZXJlbnQgQS9BQUFBIHJlY29yZHMgb24gdGhlIEEvQUFBQSBSUiBzZXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDtt YXJnaW4tbGVmdDozNS40cHQiPg0KPGJyPg0KPT09PT09PT09PTxicj4NCjxicj4NCiZndDsgNS4y Li4xMCBCZWhhdmlvciBpbiBjYXNlIG9mIEZvcmVpZ24gRE5TPGJyPg0KPGJyPg0KSG93IHdpbGwg dGhlIG1pc21hdGNoZXMgdGhhdCBzaG91bGQgdHJpZ2dlciBpbnZhbGlkYXRpb25zPGJyPg0KZ2V0 IGRldGVjdGVkIGluIHRoaXMgY2FzZT88YnI+DQo8YnI+DQo8c3BhbiBsYW5nPSJFUyI+KiBCcmVh a2FnZSBkdWUgdG8gYXMgbWlzbWF0Y2hlcyB3b24ndCBiZSBkZXRlY3RlZCBhbmQgcmVzdWx0IGlu IGludmFsaWRhdGlvbnM8YnI+DQombmJzcDtpZiBvbmUgZGV2aWNlIG9yIGFwcCBpcyBkb2luZyBs b29rdXBzIHZpYSB0aGlzIHJlc29sdmVyIGJ1dCBhbm90aGVyIGlzIG5vdC48YnI+DQombmJzcDsg Q29uc3RyYWluaW5nIHRoZSBFQU1UIGVudHJ5IHRvIHRoZSBJUHY0IGNsaWVudCBJUCBjb3VsZCBh dCBsZWFzdCBib3VuZDxicj4NCiZuYnNwOyB0aGUgZGFtYWdlIHRvIGEgc2luZ2xlIGRldmljZSwg YnV0IG5vdCBpZiBzb21lIGFwcHMgb24gaXQgdXNlIGRpZmZlcmVudDxicj4NCiZuYnNwOyByZXNv bHZlciBzY2hlbWVzLjxicj4NCjxicj4NCiogSSBiZWxpZXZlIEdvb2dsZSBzaGlwcyBDaHJvbWVj YXN0IHRvIGhhcmRjb2RlIEROUyBsb29rdXBzIHRvIDguOC44Ljg8YnI+DQombmJzcDsgaW4gYWRk aXRpb24gdG8gYWxzbyBzb21ldGltZXMgdXNpbmcgdGhlIGxvY2FsIHJlc29sdmVyLiZuYnNwOyBT b21lIG90aGVyIFNUQnMgYW5kIG1vYmlsZSBhcHBzPGJyPg0KJm5ic3A7IGRvIHRoZSBzYW1lLiZu YnNwOyBUaGlzIGhhcyBzaWduaWZpY2FudCBwb3RlbnRpYWwgZm9yIG1pc21hdGNoZXMgdG8gbm90 IGdldDxicj4NCiZuYnNwOyBkZXRlY3RlZCBhbmQgbm90IGdldCBpbnZhbGlkYXRlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+W0pvcmRpXSBBbGwgdGhpcyBpcyBubyBsb25nZXIgYSBwcm9ibGVtOiBXZSBk b27igJl0IG9wdGltaXplIGlmIGEgZm9yZWlnbiBETlMgaXMmbmJzcDsgdXNlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjM1LjRwdCI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PGJyPg0KPGJyPg0KJmd0OyA1LjIuMTMu Jm5ic3A7IDxzcGFuIGxhbmc9IkVTIj5Ucm91Ymxlc2hvb3RpbmcgSW1wbGljYXRpb25zPGJyPg0K PGJyPg0KSG93IGRvIGNvcm5lci1jYXNlcyBhcm91bmQgY29sbGlzaW9ucyB3aGVyZSBFQU1UIGVu dHJpZXM8YnI+DQpkb24ndCBnZXQgcHJvcHJlcmx5IGludmFsaWRhdGVkIGdldCBkZWJ1Z2dlZCBi eSB0aGUgSVNQPGJyPg0KKGFuZCBjb250ZW50IHByb3ZpZGVyISk/PGJyPg0KPGJyPg0KVGhpcyBp cyBvcGFxdWUgdG8gdGhlIENETiBhbmQgY291bGQgcmVzdWx0IGluIGxvdHMgb2YgZXNjYWxhdGlv bnMgZnJvbTxicj4NCmVuZC11c2VycyBhbmQgY3VzdG9tZXJzLiZuYnNwOyBUaGUgbmV0IHJlc3Vs dCB3aWxsIGJlIGZvciBjb250ZW50IHRvIGdldDxicj4NCnN3aXRjaGVkIHRvIElQdjQtb25seSBp ZiB0aGF0ICZxdW90O2ZpeGVzJnF1b3Q7IHRoZSBwcm9ibGVtIHdoaWNoIG1pZ2h0IGltcGFjdDxi cj4NCnVzZXJzIHdvcmxkLXdpZGUuICZuYnNwOyhOZWl0aGVyIHRoZSBDRE4gb3IgdGhlaXIgY3Vz dG9tZXIgaGFzIGFueTxicj4NCnZpc2liaWxpdHkgaW50byB3aGF0IGlzIGdvaW5nIG9uIGhlcmUg b3RoZXIgdGhhbiB0aGF0IHNvbWUgZW5kIHVzZXJzPGJyPg0KbWF5IGJlIHJlcG9ydGluZyBub3Qg YmVpbmcgYWJsZSB0byB2aWV3IGR1YWwtc3RhY2tlZCBjb250ZW50Lik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+W0pvcmRpXSBJZiB0aGUgdHJvdWJsZXNob290aW5nIGlzIGRvbmUgd2l0aCBkdWFsLXN0YWNr IGhvc3QsIG5vIGlzc3Vlcy4gSWYgaXQgaXMgYW4gSVB2NC1vbmx5IGhvc3QsIHRoZSBvcHRpbWl6 YXRpb24gY2FuIGJlIGZ1bGx5IGRpc2FibGVkLCBvciBzcGVjaWZpYyBlbnRyaWVzIGNhbiBiZSBk aXNhYmxlZC4gSXMgbm90IHRoYXQgc29sdmluZyB0aGUgcHJvYmxlbT8NCiBUaGlzIGlzIHRoZSB0 ZXh0IEnigJl2ZSByaWdodCBub3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj41LjIuMTUuJm5ic3A7 IFRyb3VibGVzaG9vdGluZyBJbXBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgV2hlbiB0aGVy ZSBpcyBhIG5lZWQgdG8gdHJvdWJsZXNob290IElQdjQgZnJvbSB0aGUgQ0UgTEFOcywgaXQgbWF5 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGhhcHBlbiB0aGF0IHRoZXJlIGlzIGFuIEVBTVQgZW50cnkgZm9yY2luZyB0 aGUgZmxvdyB0byBhIGdpdmVuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRlc3RpbmF0aW9uKHMpIHRvIHVzZSBJUHY2 LCB3aGljaCB3aWxsIGRpc3RvcnQgdGhlIHJlc3VsdHMsIHVubGVzczxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUg aG9zdCBiZWluZyB1c2VkIGlzIGR1YWwtc3RhY2sgKHdoaWNoIGlzIHRoZSBtb3N0IGNvbW1vbjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBzaXR1YXRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGlzIGNhbiBiZSBhdm9p ZGVkLCB1c2luZyBhIENMSS9HVUkgb3IgcHJvdmlzaW9uaW5nIHByb2NlZHVyZSwgdG88bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZWl0aGVyIGNvbXBsZXRlbHkgZGlzYWJsZSB0aGUgb3B0aW1pemF0aW9uIGR1cmluZyB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgdHJvdWJsZXNob290aW5nLCBvciBjcmVhdGUgc3BlY2lmaWMgc3RhdGlj IEVBTVQgZW50cmllcywgdXNpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFZhbGlkL1N0YWxlL0ludmFsaWQg YW5kIEF1dG8vU3RhdGljIGZsYWdzLCBhcyBkZXNjcmliZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU2VjdGlv biA1LjIuNS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ29uc2VxdWVudGx5LCB0aGUgQ0UgTVVTVCBhbGxv dyBib3RoLCBkaXNhYmxpbmcgdGhlIG9wdGltaXphdGlvbiBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIHNl dHVwIG9mIG1hbnVhbC9zdGF0aWMgRUFNVCBlbnRyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJn aW4tbGVmdDozNS40cHQiPg0KPGJyPg0KPT09PT09PT09PT09PGJyPg0KR2VuZXJhbCBmb3IgNS4y Lng6PGJyPg0KPGJyPg0KKiBTaG91bGQgdGhpcyBkb2MgdXNlIG1vcmUgbm9ybWF0aXZlIGxhbmd1 YWdlIGluIHBsYWNlcyB3aGVyZSB3YXJyYW50ZWQ/PGJyPg0KJm5ic3A7IDxzcGFuIGxhbmc9IkVT Ij4oVGhlcmUgYXJlIGEgYnVuY2ggb2YgTVVTVCBOT1Qgc2hhcnAgZWRnZXMuKTxicj4NCiZuYnNw OyBFc3BlY2lhbGx5IGluIDUuMi40Ljxicj4NCjxicj4NCiogQ2xhcmlmeSB0aGF0IEVBTVQgdGFi bGUgdXBkYXRlcyBNVVNUIGJlIG1hZGUgYmVmb3JlIEEgcmVjb3JkPGJyPg0KJm5ic3A7IGlzIHJl dHVybmVkIHRvIHRoZSBjbGllbnQgKGVzcGVjaWFsbHkgaW52YWxpZGF0aW9ucyEpLiZuYnNwOyBP dGhlcndpc2UgdGhlcmU8YnI+DQombmJzcDsgaXMgYSBwb3RlbnRpYWwgcmFjZSBjb25kaXRpb24u Ljxicj4NCjxicj4NCiogV2hhdCBoYXBwZW5zIGlmIHRoZSBGUUROcyBtaXNtYXRjaCBidXQgdGhl IEEgYW5kIEFBQUEgUlJzZXRzIGFyZSBpZGVudGljYWw/PGJyPg0KVGhpcyBpcyBnb2luZyB0byBi ZSB2ZXJ5IGNvbW1vbiBhcyBtYW55IENETnMgdXNlIGxvdHMgb2YgbmFtZXM8YnI+DQombmJzcDt3 aXRoIGEgc21hbGxlciBudW1iZXIgb2YgSVB2NCBhZGRyZXNzZXMuPGJyPg0KJm5ic3A7IFdoYXQg aWYgdGhlIEEgYW5kIEFBQUEgUlJzZXRzIG92ZXJsYXAgYnV0IGFyZW4ndCBpZGVudGljYWw/PGJy Pg0KJm5ic3A7IChQZXJoYXBzIHRoZSBFQU1UIGVudHJ5IE1VU1QgYmUgbWFya2VkIGludmFsaWQg aWYgdGhlIEZRRE5zIG1pc21hdGNoPGJyPg0KJm5ic3A7IGFuZCB0aGUgRUFNVCBlbnRyeSBkb2Vz IG5vdCBoYXZlIGJvdGggaXRzIEEgKmFuZCogQUFBQSB2YWx1ZXM8YnI+DQombmJzcDsgaW4gdGhl IHJldHVybmVkIFJSc2V0cy4gJm5ic3A7aWUsIGFsbCBFQU1UIGVudHJpZXMgbXVzdCBiZSB2YWxp ZDxicj4NCiZuYnNwOyB3aXRoaW4gdGhlIG1pc21hdGNoaW5nIEZRRE4uKTxicj4NCiZuYnNwOyAo TWF5IHN0aWxsIGJlIGNvcm5lciBjYXNlcyBoZXJlIEknbSBmb3JnZXR0aW5nPyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+W0pvcmRpXSBJIHRoaW5rIGFsbCB0aGlzIGhhcyBiZWVuIGFscmVhZHkgcmVzb2x2 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDozNS40cHQiPg0KPGJyPg0KKiBXZSBoYXZlIGEgcmVjb21tZW5kZWQgbWF4 aW11bSBjYXAvdGhyZXNob2xkIG9uIHRoZSBUVEw/PGJyPg0KJm5ic3A7IDxzcGFuIGxhbmc9IkVT Ij4oZXZlbiBpZiBpdCdzIHNvbWV0aGluZyBsaWtlIDggaG91cnMuLi4pICZuYnNwO090aGVyd2lz ZSBiYWQgZW50cmllczxicj4NCiZuYnNwOyBtaWdodCBzdGljayBhcm91bmQgdG9vIGxvbmcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPltKb3JkaV0gVGhpcyBpcyBhbiBvcGVuIHF1ZXN0aW9uLiBJIGRvbuKA mXQga25vdyBpZiBpdCBtYWtlcyBzZW5zZSB0byBpbnZhbGlkYXRlIHRoZSBzdGFsZSBlbnRyaWVz IGlmIHRoZSBjb25uZWN0aW9ucyBkb27igJl0IGRpZSDigKYgYW5kIGlmIHNvLCBJIGd1ZXNzIHlv dXIgOCBob3VycyBjb21lIGZyb20geW91ciBDRE4gdmlldyBvZiBvcGVyYXRpb25hbCBkZXRhaWxz DQogKGNoYW5nZXMgaW4gRlFETnMvQS9BQUFBKSwgb3IgaXQgaXMganVzdCByYW5kb20/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDozNS40cHQiPg0KPGJyPg0KPT09PT09PT09PTxicj4NCjxicj4NCkFkZGl0aW9uYWwgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnM6PGJyPg0KPGJyPg0KKFRoZSBmaXJzdCBvZiB0aGVzZSBpcyBt aW5vciAtLS0gdGhlIG90aGVycyBzZWVtIGxpa2UgdGhleSBtYWtlIHRoaXMgdG9vIGRhbmdlcm91 cyB0byBkZXBsb3kuPGJyPg0KPHNwYW4gbGFuZz0iRVMiPkl0IG1heSBiZSB3b3J0aCBoYXZpbmcg YSBTZWN1cml0eSBBRCBkbyBzb21lIGZvY3VzZWQgcmV2aWV3IGluIHRoaXMgY29udGV4dC4pPGJy Pg0KPGJyPg0KKiBGaWxsaW5nIEVBTVQgdGFibGUgd2l0aCB2ZXJ5IGxvbmcgVFRMIHJlY29yZHMu ICZuYnNwOyhpZSwgdHJpZ2dlcmluZyBhIGNsaWVudCB0bzxicj4NCiZuYnNwOyBkbyBETlMgbG9v a3VwcyB0aGF0IGNyZWF0ZSBsb3RzIG9mIGxvbmctbGl2ZWQgYXNzb2NpYXRpb25zKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5bSm9yZGldIFllcCwmbmJzcDsgc2FtZSBwb2ludCBhcyB0aGUgOCBob3Vycy4g U2hvdWxkIHdlIHNldCBzb21lIGxpbWl0cyBmb3IgdGhlIEVBTVQgZW50cmllcywgZGVzcGl0ZSB0 aGUgVFRMcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 MTIuMHB0O21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8YnI+DQoqIFRoZXJlIGlzIGFuIHNlcmlvdXMg cmlzayBleHBvc3VyZSB0byBoaWphY2tpbmcgdHJhZmZpYyBieSBpbnNlcnRpbmcgYm9ndXMgYmlu ZGluZzxicj4NCiZuYnNwOyAoaWUsIHJldHVybiB0YXJnZXQncyBBIHJlY29yZCBhbmQgbWFsaWNp b3VzIGFjdG9yJ3MgQUFBQSByZWNvcmQpLjxicj4NCiZuYnNwOyA8c3BhbiBsYW5nPSJFUyI+SW4g bW9zdCBjYXNlcyB0aGVzZSByZWNvcmRzIHNob3VsZCBnZXQgbWFya2VkIGFzIEludmFsaWQsPGJy Pg0KJm5ic3A7IGJ1dCB0aGUgY29ybmVyIGNhc2VzIGhlcmUgYXJlIGZyYWdpbGUgKGVnLCB3aXRo IGZvcmVpZ24gRE5TIG9yPGJyPg0KJm5ic3A7IGNsaWVudHMgY2FjaGluZyBwYXN0IHRoZSBUVEwg bWl4ZWQgaW4gaGVyZS48YnI+DQombmJzcDsgQW4gZXhhbXBsZSBhdHRhY2sgaGVyZSBpcyB0aGF0 IGEgY2xpZW50IGhhcyBhbiBBIHJlY29yZDxicj4NCiZuYnNwOyBmb3IgJnF1b3Q7PGEgaHJlZj0i aHR0cDovL3d3dy5leGFtcGxlLmNvbSI+d3d3LmV4YW1wbGUuY29tPC9hPiZxdW90OyBwb2ludGlu ZyB0byAxOTIuMC4yLjEgY2FjaGVkIHBhc3Q8YnI+DQombmJzcDsgaXRzIFRUTCBzbyB0aGUgRUFN VCByZWNvcmQgaXMgZ29uZS4mbmJzcDsgQW4gYXR0YWNrZXIgY29udmluY2VzPGJyPg0KJm5ic3A7 IGFub3RoZXIgdXNlciBpbiB0aGUgc2FtZSBob21lIG5ldHdvcmsgdG8gZG8gYSBETlMgbG9va3Vw PGJyPg0KJm5ic3A7IHRoYXQgaGFzIGFuIEEgcmVjb3JkIG9mIDE5Mi4wLjIuLjEgKHdoaWNoIHRo ZSBhdHRhY2tlciBkb2Vzbid0IG93bik8YnI+DQombmJzcDsgYnV0IGEgQUFBQSByZWNvcmQgZm9y IDIwMDE6ZGI4OmVlZWU6OmVlZWUgKHdoaWNoIGlzIGF0dGFja2VyLWNvbnRyb2xsZWQpLjxicj4N CiZuYnNwOyBFdmVuIGlmIDE5Mi4wLjIuMSBpcyBJUHY0LW9ubHksIGlmIHRoZSBFQU1UIGVudHJ5 IGhhcyBleHBpcmVkIG9yIG5ldmVyPGJyPg0KJm5ic3A7IGV4aXN0ZWQgdGhlbiB0aGUgYXR0YWNr ZXIgY2FuIHJlZGlyZWN0IGFsbCB0cmFmZmljIHRvIGl0IHRvIGFuIElQdjYgYWRkcmVzczxicj4N CiZuYnNwOyBvZiB0aGVpciBjaG9pY2UuJm5ic3A7IE5vIEROUyBzcG9vZmluZyBpcyBuZWVkZWQg aGVyZSBhdCBhbGwsIGp1c3QgbWFraW5nPGJyPg0KJm5ic3A7IGEgJnF1b3Q7Y2xhaW0mcXVvdDsg dGhhdCB0aGUgQS9BQUFBIGFyZSBhc3NvY2lhdGVkICh3aGljaCBoYXMgbm8gYXV0aGVudGljYXRp b24pLjxicj4NCiZuYnNwOyBUaGlzIGlzIHBvdGVudGlhbGx5IHdvcnNlIGFzIEknZCBoeXBvdGhl c2l6ZSB0aGF0IElQdjQtb25seSBTVEI8YnI+DQombmJzcDsgY2xpZW50cyBhcmUgbXVjaCBsZXNz IGxpa2VseSB0byB1c2UgSFRUUFMvVExTLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+W0pvcmRpXSBJIHRo aW5rIHRoYXQgaGF2aW5nIGEgcGVyLWhvc3QgRUFNVCBlbnRyaWVzIHJlc29sdmVzIHRoaXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJn aW4tbGVmdDozNS40cHQiPg0KPGJyPg0KKiBUaGlzIHByZXZpb3VzIHJpc2sgaXMgcGFydGljdWxh cmx5IHByb2JsZW1hdGljIGZvciBoaWphY2tpbmcgdHJhZmZpYyBmcm9tPGJyPg0KJm5ic3A7IHVz ZXJzL2RldmljZXMvY2xpZW50cyB1c2luZyBGb3JlaWduIEROUyBzaW5jZSB0aGV5IHdvbid0IGNy ZWF0ZTxicj4NCiZuYnNwOyBFQU1UIGVudHJpZXMgYnV0IHdpbGwgYmUgZXhwb3NlZCB0byBjbGll bnRzIGdldHRpbmcgdHJpY2tlZCBpbnRvIGNyZWF0aW5nIHRoZW0uPGJyPg0KJm5ic3A7IDxzcGFu IGxhbmc9IkVTIj4oVGhpcyBjQ291bGQgYmUgZXNwZWNpYWxseSBwcm9ibGVtYXRpYyBmb3IgdXNl cnMgdXNpbmcgRG9IIGZvciBwcml2YWN5PGJyPg0KJm5ic3A7IG9uIG9uZSBkZXZpY2UsIGJ1dCB0 aGVuIGFub3RoZXIgZGV2aWNlIGluIHRoZWlyIGhvbWUgYWxsb3dzPGJyPg0KJm5ic3A7IHRoZW0g dG8gYmUgaGppamFja2VkLiZuYnNwOyBBdCBzb21lIHBvaW50IEZpcmVmb3ggcHJlZmVycmVkIElQ djQgaW4gc29tZTxicj4NCiZuYnNwOyBjYXNlcyB3aGVuIHVzaW5nIERvSCBzbyB0aGlzIG1heSBi ZSBhIHJlYWwgZXhwb3N1cmU8YnI+DQombmJzcDsgLyB2dWxuZXJhYmlsaXR5IHJpc2suKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5bSm9yZGldIE5vdCBhbnltbm9yZSwgYmVjYXVzZSB3ZSBkb27igJl0IHJl dXNlIEVBTVQgZW50cmllcyBmcm9tIG9uZSBob3N0IHRvIGFub3RoZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PGJyPg0KU29ycnkgYWdhaW4gZm9yIG5vdCBzZW5kaW5nIHRoZXNlIGVhcmxpZXIgLS0tIEkgdGhp bmsgYSBidW5jaCBvZiB0aGVzZTxicj4NCmNvbmNlcm5zIHdlcmUgcmFpc2VkIGluIG15IHByZXZp b3VzIGZlZWRiYWNrIGFuZCB3aGlsZSB0aGlzIHZlcnNpb248YnI+DQpoYXMgbWFkZSBzaWduaWZp Y2FudCBpbXByb3ZlbWVudHMsIEknbSBzdGlsbCB2ZXJ5IGNvbmNlcm5lZCB0aGF0IGl0IHdpbGw8 YnI+DQpiZSB2ZXJ5IHJpc2t5IGZyb20gYW4gb3BlcmF0aW9uYWwgZnJhZ2lsaXR5IGFuZCBzZWN1 cml0eSBwZXJzcGVjdGl2ZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0VyaWs8YnI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5bSm9yZGldIE5vdCBhdCBhbGwsIHZlcnkgaGFwcHkgZm9yIHNv IG11Y2ggZGV0YWlsZWQgcmV2aWV3LiBTb21ldGltZXMgYSBsYXN0LWNhbGwsIGV2ZW4gaWYgZmFp bGVkLCBpcyBnb29kIHRvIGdldCBhbGwgdGhpcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+ DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KSVB2 NCBpcyBvdmVyPGJyPg0KQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/PGJyPg0K PGEgaHJlZj0iaHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb20iPmh0dHA6Ly93d3cudGhlaXB2 NmNvbXBhbnkuY29tPC9hPjxicj4NClRoZSBJUHY2IENvbXBhbnk8YnI+DQo8YnI+DQpUaGlzIGVs ZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmls ZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBm b3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5k IGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBk aXN0cmlidXRpb24gb3IgdXNlIG9mDQogdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24s IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlz Y2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMNCiBv ZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmlt aW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRv IGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_02f63b1af4284239801567cfaf4d9c9bhuaweicom_-- From nobody Mon Jul 20 01:59:23 2020 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 8D1493A08E1 for ; Mon, 20 Jul 2020 01:59:22 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kZl1beECWHT for ; Mon, 20 Jul 2020 01:59:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F0E8C3A08D8 for ; Mon, 20 Jul 2020 01:59:19 -0700 (PDT) Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1BF2AE079545BF1252EB; Mon, 20 Jul 2020 09:59:18 +0100 (IST) Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 09:59:17 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 11:59:16 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 11:59:16 +0300 From: Vasilenko Eduard To: Erik Kline , JORDI PALET MARTINEZ CC: v6ops list Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns Thread-Index: AQHWXCMePERdOoO6CEWtMpgm5DnpN6kLXSaAgAA3Znb//9SRgIAAdiZcgALlI4CAAHhWgIAA69+w Date: Mon, 20 Jul 2020 08:59:16 +0000 Message-ID: References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 08:59:23 -0000 SGkgSm9yZGksDQpZZXMsIGl0IGlzIHJlYWxseSBuZWVkZWQ6DQo+IFtKb3JkaV0gSSdtIHN0aWxs IHRyeWluZyB0byB0aWR5IHVwIGFsbCB0aGUgdGV4dCBhY2NvcmRpbmcgdG8gb3RoZXIgaW5wdXRz IGFuZCByZXNwb25kIHRvIHRoZW0uIFRvbyBzb29uIHRvIHNlbmQgYSBuZXcgdmVyc2lvbiwgYnV0 IGNsb3NlIC4uLg0KDQpUaGVyZSBpcyBhIHRoZW9yeSB0aGF0IGF2ZXJhZ2UgcGVyc29uIGhhcyBh IGNhY2hlIGZvciA3IGRpZmZlcmVudCB0aGluZ3MuDQpUaGVuIGhlL3NoZSBoYXMgdG8gc3Vic3Rp dHV0ZSAxIHRoaW5nIGJ5IGFub3RoZXIuDQpBbmQgbGlrZSBpbiBDUFUgY2FzZSAtIHByb2R1Y3Rp dml0eSB3b3VsZCBjb25zaWRlcmFibHkgZGVncmFkZS4NCg0KSSBtZWFuOiBKaW4sIEVyaWMsIFBo aWxpcCBoYXZlIHB1c2hlZCB5b3UgbXVjaCBvdmVyIHRvbGVyYWJsZSA3IChvciBldmVuIDEwKSBj b25zaWRlcmFibGUgY2hhbmdlcy4NCk5vYm9keSBjb3VsZCBrZWVwIGFsbCB0aGVzZSBhZHZpc2Vz IGluIG1pbmQgLSByZS1yZWFkaW5nIG9mIGUtbWFpbHMgaXMgbmVlZGVkLCB0aGF0IGlzIG5vdCBw cm9kdWN0aXZlLg0KRHJhZnQgIi0wMyIgaXMgbmVlZGVkIHRvIGZsdXNoIGh1bWFuIGNhY2hlLiBG b3IgZWZmZWN0aXZlbmVzcy4NCg0KTm8gcHJvYmxlbSB0byBmaW5pc2ggb24gZHJhZnQgIi0wNCIg aW4gdGhlIGZ1dHVyZS4gRG8gbm90IHB1dCB0b28gbXVjaCBlZmZvcnRzIHRvIGZpbmlzaCBvbiAi LTAzIiAuDQoNCg0KDQo+ICAgIDUuICBUVEw6IEl0IE1VU1QgYmUgc2V0IHRvIHRoZSBtaW5pbXVt IHZhbHVlIGZyb20gdGhlIEFBQUEvQSBSUiBwYWlyLg0KPiAgICAgICAgSW4gbm9ybWFsIGNvbmRp dGlvbnMgdGhlIFRUTCBmb3IgYm90aCBBIGFuZCBBQUFBIHJlY29yZHMsIG9mIGENCj4gICAgICAg IGdpdmVuIEZRRE4sIHNob3VsZCBiZSB0aGUgc2FtZSwgc28gdGhpcyBlbnN1cmVzIGEgcHJvcGVy IGJlaGF2aW9yDQo+ICAgICAgICBpZiB0aGVyZSBpcyBhbnkgRE5TIG1pc21hdGNoLg0KDQpbRWR1 YXJkXSBUaGlzIGlzIHdyb25nLiBJZiBob3N0IHdvdWxkIG5vdCBwYXkgYXR0ZW50aW9uIHRvIERO UyBUVEwgYW5kIGNvbnRpbnVlIHRvIHVzZSBzZXNzaW9uIChvciBldmVuIGNyZWF0ZSBuZXcgc2Vz c2lvbnMpIC0gd2UgaGF2ZSBubyByaWdodHMgdG8gZHJvcCBoaXMgZXhwZXJpZW5jZS4NCg0KDQo+ ICAgIENvbnNlcXVlbnRseSwgdGhlIEVBTVQgZW50cmllcyBNVVNUIE5PVCBiZSB1c2VkIGRpcmVj dGx5IHRvIGVzdGFibGlzaA0KPiAgICBhIGZvcndhcmRpbmcgcGF0aCwgYnV0IGluc3RlYWQsIE1V U1QgYmUgdXNlZCB0byBjcmVhdGUgYSBzdGF0ZWZ1bCBOQVQNCj4gICAgZW50cnkgZm9yIHRoZSA0 LXR1cGxlIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24vY29ubmVjdGlvbi4NCj4gICAg VGhpcyBtZWFucyB0aGF0IHRvIGltcGxlbWVudCB0aGUgb3B0aW1pemF0aW9uIHRoZSBOQVQ0NiBN VVNUIGJlDQo+ICAgIHN0YXRlZnVsLiAgVHlwaWNhbGx5IHN0YXRlZnVsIE5BVDQ2IGFyZSBpbXBs ZW1lbnRlZCBieSBtZWFucyBvZiBhDQo+ICAgIHN0YXRlZnVsIE5BVDQ0ICh3aGljaCBvZnRlbiBt YXliZSBoYXJkd2FyZSBvZmYtbG9hZGVkKSwgZm9sbG93ZWQgYnkgYQ0KPiAgICBzdGF0ZWxlc3Mg TkFUNDYuICBJZiB0aGUgU29DL2NvZGUgaXMgYWJsZSB0byBkbyBzdGF0ZWxlc3MgTkFUNDYsIHRo aXMNCj4gICAgc3RpbGwgY291bGQgYmUgdXNlZCB3aGVuIHRoZSBvcHRpbWl6YXRpb24gaXMgZGlz YWJsZWQuDQoNCltFZHVhcmRdIE1heSBiZSBJIGhhdmUgbm90IHJlYWQgYWxsIHlvdXIgZS1tYWls cywgYnV0IGRvIHlvdSBzdGlsbCBoYXZlIE5BUFQ0ND8NCllvdSBhcmUgYWxyZWFkeSB0YWxraW5n IGFib3V0IGluZGl2aWR1YWwgY29udGV4dCBmb3IgZXZlcnkgaG9zdC4NCg0KPiAgICBFbnRyaWVz IGluIFN0YWxlIHN0YXRlIE1VU1QgYmUgc2V0IHRvIEludmFsaWQgb25jZSBleGlzdGluZw0KPiAg ICBjb25uZWN0aW9ucyB0aW1lLW91dC4NCltFZHVhcmRdIGl0IGlzIG5vdCBwcm9wZXJseSBkZWNp ZGVkIHlldCBob3cgdG8gdW5kZXJzdGFuZCB3aGF0IGlzICJzdGFsZSIgLSBzZWUgYWJvdmUgY29t bWVudHMuDQoNCkVkdWFyZA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3Bz IFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWsgS2xpbmUN ClNlbnQ6IDIwINC40Y7Qu9GPIDIwMjAg0LMuIDA6MjkNClRvOiBKT1JESSBQQUxFVCBNQVJUSU5F WiA8am9yZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4NCkNjOiB2Nm9w cyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYt djZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDIgZ2VuZXJhbCBjb25jZXJucw0KDQpEb2VzIGFu eSBvZiB0aGUgYmVsb3cgc29sdmUgdGhlIHByb2JsZW0gb2YgYW4gSVB2NC1vbmx5IGhvc3QgdHJ5 aW5nIHRvIGxlYXJuIGl0J3MgZXh0ZXJuYWwgSVB2NCBhZGRyZXNzIHZpYSBhIFNUVU4gc2Vydmlj ZSB0aGF0IGlzIGR1YWxzdGFja2VkPw0KDQpPbiBTdW4sIEp1bCAxOSwgMjAyMCBhdCA3OjE5IEFN IEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJj LmlldGYub3JnPiB3cm90ZToNCj4NCj4gSGkgUGhpbGlwLA0KPg0KPg0KPiDvu79FbCAxNy83LzIw IDE3OjA1LCAidjZvcHMgZW4gbm9tYnJlIGRlIFBoaWxpcCBIb21idXJnIiA8djZvcHMtYm91bmNl c0BpZXRmLm9yZyBlbiBub21icmUgZGUgcGNoLXY2b3BzLTlAdS0xLnBoaWNvaC5jb20+IGVzY3Jp YmnDszoNCj4NCj4gICAgID5bSm9yZGldIEdvb2QgcG9pbnQuIE1heSBiZToNCj4gICAgID4NCj4g ICAgID4iVGhlIENFIEROUyBwcm94eSBNVVNUIE5PVCByZXR1cm4gdGhlIGFuc3dlciB0byBhbiBB IHF1ZXJ5IHVudGlsIGVpdGhlciBhbiBhbnN3ZQ0KPiAgICAgPnIgdG8gdGhlIEFBQUEgcXVlcnkg aGFzIGJlZW4gcmVjZWl2ZWQgb3IgdGhlIFJlc29sdXRpb24gRGVsYXkgaGFzIHBhc3NlZCINCj4N Cj4gICAgIFllcywgSSB0aGluayB0aGlzIGlzIGltcG9ydGFudC4gT3RoZXJ3aXNlIHNtYWxsIGRp ZmZlcmVuY2VzIGluIEROUyB0aW1pbmcNCj4gICAgIG1heSBjYXVzZSBoYXJkIHRvIGRpYWdub3Nl IGJ1Z3MuDQo+DQo+ICAgICBBbm90aGVyIHN1Z2dlc3Rpb24gaXMgdGhhdCBpZiB0aGUgQUFBQSBx dWVyeSBlaXRoZXIgZ2V0cyBhIHRpbWVvdXQgb3IgU0VSVkZBSUwNCj4gICAgIHRoZW4gYW55IGV4 aXN0aW5nIEVBTVQgZW50cnkgZm9yIHRoZSBjb3JyZXNwb25kaW5nIElQdjQgYWRkcmVzcyBzaG91 bGQgYmUNCj4gICAgIHNldCB0byBpbnZhbGlkLg0KPg0KPiAgICAgVGhlbiB0aGVyZSBpcyBETlNT RUMuIEZvciBleGFtcGxlLCB0aGUgQUFBQSBsb29rdXAgTVVTVC9TSE9VTEQvTUFZIGJlDQo+ICAg ICB2ZXJpZmllZCB1c2luZyBETlNTRUMgbG9jYWwgdmFsaWRhdGlvbi4gKE9yLCB0aGUgQUQgYml0 IG9mIHRoZSByZXBseSBjb3VsZA0KPiAgICAgYmUgdXNlZCBpbnN0ZWFkKS4gQSByZXBseSB0aGF0 IGZhaWxzIEROU1NFQyB2YWxpZGF0aW9uIE1VU1QvU0hPVUxEL01BWSBub3QNCj4gICAgIHJlc3Vs dCBpbiB0aGUgY3JlYXRpb24gb2YgYW4gRUFNVCBlbnRyeSAoYW5kIE1VU1QvU0hPVUxEL01BWSBy ZXN1bHQgaW4NCj4gICAgIG1hcmtpbmcgYW4gZXhpdGluZyBlbnRyeSBpbnZhbGlkKQ0KPg0KPiBb Sm9yZGldIFllcyBib3RoIG9mIHRob3NlIGFyZSBhbHNvIHZlcnkgZ29vZCBwb2ludHMuIE1heWJl LCB3ZSBjYW4gc3VtbWFyaXplIGFsbCB0aG9zZSBjaGFuZ2VzIGFuZCBzb21lIG9mIG15IHByZXZp b3VzIHJlc3BvbnNlcyB0byBFcmlrIGFuZCBFZHVhcmQgaW4gdGhlIGxpc3Qgd2l0aCB0aGUgdGV4 dCAodGVudGF0aXZlKSB0aGF0IEknbSBhZGRpbmcgYXQgdGhlIGVuZCBvZiB0aGlzIGVtYWlsLg0K Pg0KPiAgICAgT25lIHF1ZXN0aW9uIHRoYXQgZG9lc24ndCBzZWVtIGFuc3dlciwgd2hhdCBpZiB0 aGUgdXBzdHJlYW0gcmVzb2x2ZXIgaXMNCj4gICAgIGRvaW5nIEROUzY0LiBJbiB0aGF0IGNhc2Ug YW4gQUFBQSBxdWVyeSB3b3VsZCBnZXQgYW4gYW5zd2VyIGZvciBhbiBJUHY0LW9ubHkNCj4gICAg IHNlcnZpY2UuIE1heWJlIGl0IGRvZXNuJ3QgbWF0dGVyLCBiZWNhdXNlIHRoZSBtYXBwaW5nIHdp bGwgYmUgdGhlIHNhbWUuDQo+ICAgICBPdGhlcndpc2Ugc2V0dGluZyB0aGUgQ0QgZmxhZyBpbiB0 aGUgcXVlcnkgbWF5IGhlbHAgdG8gZ2V0IG9ubHkgJ3JlYWwnDQo+ICAgICBBQUFBIHJlY29yZHMu DQo+DQo+IFtKb3JkaV0gVGhpcyBpcyBhbHJlYWR5IHJlc29sdmVkIGJ5IE5PVCBjcmVhdGluZyBh biBFQU1UIGVudHJ5IGlmIG9ubHkgYSBzeW50aGV0aXplZCBBQUFBIGlzIHJlY2VpdmVkLiBTZWN0 aW9uIDUuMi4yOg0KPiAiIE5vdGUgdGhhdCB0aGUgTkFUNDYvQ0xBVCBNVVNUIGFscmVhZHkNCj4g ICAga25vdyB0aGUgV0tQIG9yIE5TUCBiZWluZyB1c2VkIGluIHRoYXQgbmV0d29yay4gIElmIHRo ZSByZXNwb25zZQ0KPiAgICBjb250YWlucyBhdCBsZWFzdCBvbmUgSVB2NiBhZGRyZXNzIG5vdCB1 c2luZyB0aGUgV0tQL05TUCwgaXQgbWVhbnMNCj4gICAgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMg SVB2Ni1lbmFibGVkIChiZWNhdXNlIGF0IGxlYXN0IG9uZSBvZiB0aGUNCj4gICAgSVB2NiBhZGRy ZXNzZXMgaXMgbm90IHN5bnRoZXNpemVkKS4gIFRoaXMgbWVhbnMgdGhhdCBpdCBpcyBwb3NzaWJs ZQ0KPiAgICBmb3IgdGhlIE5BVDQ2L0NMQVQsIHRvIGNyZWF0ZSBhbiBFeHBsaWNpdCBBZGRyZXNz IE1hcHBpbmciDQo+DQo+IFtKb3JkaV0gSSdtIHN0aWxsIHRyeWluZyB0byB0aWR5IHVwIGFsbCB0 aGUgdGV4dCBhY2NvcmRpbmcgdG8gb3RoZXIgaW5wdXRzIGFuZCByZXNwb25kIHRvIHRoZW0uIFRv byBzb29uIHRvIHNlbmQgYSBuZXcgdmVyc2lvbiwgYnV0IGNsb3NlIC4uLg0KPg0KPg0KPiBUZW50 YXRpdmUgY2hhbmdlczoNCj4NCj4NCj4NCj4gNS4yLjIuICBEZXRlY3Rpb24gb2YgSVB2NC1vbmx5 IGhvc3RzDQo+DQo+ICAgIFRoZSBnb2FsIGlzIHRvIGVuc3VyZSB0aGF0IG9ubHkgSVB2NC1vbmx5 IGhvc3RzIGFyZSBvcHRpbWl6ZWQuDQo+ICAgIFRvd2FyZHMgdGhhdCwgdGhlIENFIE1VU1QgdXNl IEFSUCBhbmQgTkQgKGFuZCB0aGVpciByZWxldmFudCBjYWNoZXMsDQo+ICAgIGlmIHRoZSBpbmZv cm1hdGlvbiBvZiBhIGhvc3RzIGhhcyBiZWVuIGFscmVhZHkgbGVhcm50KSBlYWNoIHRpbWUgYQ0K PiAgICBuZXcgaG9zdCBzdGFydHMgYSBjb25uZWN0aW9uLiAgSWYgaXQgaXMgbm90IHBvc3NpYmxl IHRvIGJpbmQgdGhlIHNhbWUNCj4gICAgTUFDIGFkZHJlc3MgdG8gYm90aCBhbiBJUHY0IGFuZCBJ UHY2IGFkZHJlc3MsIHRoZW4gdGhlIGhvc3QgaXMgbm90DQo+ICAgIElQdjQtb25seSAoaXQgbWF5 IGJlIElQdjYtb25seSBvciBkdWFsLXN0YWNrKSwgYW5kIE1VU1QgTk9UIGJlDQo+ICAgIG9wdGlt aXplZC4NCj4NCj4gICAgVGhlIENFIE1VU1QgbWFpbnRhaW4gYSB0YWJsZSBvZiBJUHY0LW9ubHkg aG9zdHMgYW5kIGVuc3VyZSB0aGF0IGlmDQo+ICAgIGFueSBJUHY0LW9ubHkgaG9zdHMgYmVjb21l IElQdjYtZW5hYmxlZCwgaXQgaXMgcHJvcGVybHkgaGFuZGxlZC4NCj4NCj4gICAgVGhpcyBtZWNo YW5pc20gdG8gZGV0ZWN0IElQdjQtb25seSBob3N0cyBoYXMgdHdvIGRyYXdiYWNrczoNCj4NCj4g ICAgMS4gIElmIGEgc3Vic2NyaWJlciBoYXMgaW50ZXJtZWRpYXRlIGR1YWwtc3RhY2sgcm91dGVy cyBpbiBiZXR3ZWVuDQo+ICAgICAgICB0aGUgSVB2NC1vbmx5IGhvc3QgYW5kIHRoZSBOQVQ0Ni9D TEFULCB0aGUgSVB2NC1vbmx5IGhvc3RzIHdpbGwNCj4gICAgICAgIGJlIGRldGVjdGVkIGFzIGR1 YWwtc3RhY2ssIHNvIG5vIG9wdGltaXphdGlvbiB3aWxsIGJlIHBlcmZvcm1lZC4NCj4gICAgICAg IFRoaXMgaXMgbm90IHRoZSBtb3N0IGNvbW1vbiBzY2VuYXJpbywgYXMgdHlwaWNhbGx5IHRoZSBk ZXZpY2VzDQo+ICAgICAgICB0aGF0IGFyZSBtb3JlIHJlbGV2YW50IHRvIHRoZSBvcHRpbWl6YXRp b24gKGluIHRlcm1zIG9mIHRob3NlDQo+ICAgICAgICB0aGF0IGdlbmVyYXRlIG1vcmUgSVB2NC1v bmx5IHRyYWZmaWMpIGFyZSBkaXJlY3RseSBhdHRhY2hlZCB0bw0KPiAgICAgICAgdGhlIENFLCBv ciBpbiBicmlkZ2VkIGludGVyZmFjZXMuDQo+DQo+ICAgIDIuICBJZiBhIGhvc3QgaXMgZHVhbC1z dGFjaywgYnV0IGhhcyBzb21lIElQdjQtb25seSBhcHBsaWNhdGlvbnMsDQo+ICAgICAgICBiZWNh dXNlIHRoZSBob3N0IHdpbGwgYmUgZGV0ZWN0ZWQgYXMgZHVhbC1zdGFjaywgbm9uZSBvZiB0aGUN Cj4gICAgICAgIGFwcGxpY2F0aW9ucyB3aWxsIGJlIG9wdGltaXplZC4gIFRoaXMgaXMgYSBnb29k IHRyYWRlLW9mZiwNCj4gICAgICAgIGNvbnNpZGVyaW5nIHRoZSBtb3N0IGltcG9ydGFudCB0cmFm ZmljIHRvIG9wdGltaXplIGlzIHR5cGljYWxseQ0KPiAgICAgICAgY29taW5nIGZyb20gcmVhbCBJ UHY0LW9ubHkgZGV2aWNlcyBzdWNoIGFzIG9sZCBTbWFydFRWcy9TVEJzLg0KPiAgICAgICAgRnVy dGhlcm1vcmUsIHRoaXMgYXZvaWQgYnJlYWtpbmcgb3RoZXIgbWVjaGFuaXNtcyBwcmVzZW50IG9u bHkgaW4NCj4gICAgICAgIGR1YWwtc3RhY2sgaG9zdHMsIHN1Y2ggYXMgSGFwcHkgRXllYmFsbHMg W1JGQzgzMDVdIGFuZCBzaW1wbGlmaWVzDQo+ICAgICAgICB0cm91Ymxlc2hvb3RpbmcuDQo+DQo+ ICAgIEl0IG5lZWRzIHRvIGJlIHJlbWFya2VkIHRoYXQsIGlmIHRoZSBkZXRlY3Rpb24gb2YgdGhl IElQdjQtb25seSBob3N0DQo+ICAgIGlzIGRvbmUgaW5jb3JyZWN0bHkgKGVpdGhlciBub3QgZGV0 ZWN0aW5nIGl0IG9yIGJ5IGEgZmFsc2UNCj4gICAgZGV0ZWN0aW9uKSwgdGhlIGdvYWwgaXMgdGhh dCBubyBoYXJtIGlzIGNhdXNlZC4gIEluIHRoZSB3b3JzdCBjYXNlLA0KPiAgICBvcHRpbWl6YXRp b24gTVVTVCBOT1QgYmUgcGVyZm9ybWVkLg0KPg0KPiA1LjIuMy4gIERldGVjdGlvbiBvZiBJUHY2 LWVuYWJsZWQgc2VydmljZQ0KPg0KPiAgICBJbiB0aGUgY2FzZSBvZiBhbiBJUHY0LW9ubHkgZGV0 ZWN0ZWQgaG9zdCwgdGhlIEROUyBwcm94eS9zdHViDQo+ICAgIHJlc29sdmVyIE1VU1QgYWN0dWFs bHkgcGVyZm9ybSBhbiBhZGRpdGlvbmFsIEFBQUEgcXVlcnksIHVubGVzcyB0aGUNCj4gICAgaW5m b3JtYXRpb24gaXMgYWxyZWFkeSBwcmVzZW50IGluIHRoZSBBZGRpdGlvbmFsIFNlY3Rpb24sIGFz IHBlcg0KPiAgICBTZWN0aW9uIDMgb2YgW1JGQzM1OTZdLg0KPg0KPiAgICBOb3RlIHRoYXQgdGhl IE5BVDQ2L0NMQVQgTVVTVCBhbHJlYWR5IGtub3cgdGhlIFdLUCBvciBOU1AgYmVpbmcgdXNlZA0K PiAgICBpbiB0aGF0IG5ldHdvcmsuICBJZiB0aGUgcmVzcG9uc2UgY29udGFpbnMgYXQgbGVhc3Qg b25lIElQdjYgYWRkcmVzcw0KPiAgICBub3QgdXNpbmcgdGhlIFdLUC9OU1AsIGl0IG1lYW5zIHRo YXQgdGhlIGRlc3RpbmF0aW9uIGlzIElQdjYtZW5hYmxlZA0KPiAgICAoYmVjYXVzZSBhdCBsZWFz dCBvbmUgb2YgdGhlIElQdjYgYWRkcmVzc2VzIGlzIG5vdCBzeW50aGVzaXplZCkuDQo+ICAgIFRo aXMgbWVhbnMgdGhhdCBpdCBpcyBwb3NzaWJsZSBmb3IgdGhlIE5BVDQ2L0NMQVQsIHRvIGNyZWF0 ZSBhbg0KPiAgICBFeHBsaWNpdCBBZGRyZXNzIE1hcHBpbmcgKFtSRkM3NzU3XSkuDQo+DQo+IDUu Mi40LiAgQ0UgRE5TIHByb3h5IHJlc3BvbnNlcw0KPg0KPiAgICBJbiB0aGUgY2FzZSBvZiBhbiBJ UHY0LW9ubHkgZGV0ZWN0ZWQgaG9zdCwgdGhlIENFIEROUyBwcm94eSBNVVNUIG9ubHkNCj4gICAg cmV0dXJuIHRoZSBhbnN3ZXIgdG8gYW4gQSBxdWVyeSBvbmNlIGFueSBvZiB0aGUgZm9sbG93aW5n IGhhcHBlbnM6DQo+DQo+ICAgIDEuICBBbiBhbnN3ZXIgdG8gdGhlIEFBQUEgcXVlcnkgaGFzIGJl ZW4gcmVjZWl2ZWQuDQo+DQo+ICAgIDIuICBBIFNFUlZGQUlMIGhhcyBiZWVuIHJlY2VpdmVkLg0K Pg0KPiAgICAzLiAgVGhlICJSZXNvbHV0aW9uIERlbGF5IiBoYXMgcGFzc2VkLg0KPg0KPiAgICBU aGUgUmVzb2x1dGlvbiBEZWxheSBNVVNUIGJlIHNldCB0byB0aGUgc2FtZSB2YWx1ZSAoNTAgbWls bGlzZWNvbmRzKQ0KPiAgICBhcyBpbmRpY2F0ZWQgYnkgSGFwcHkgRXllYmFsbHMgW1JGQzgzMDVd Lg0KPg0KPiA1LjIuNS4gIENyZWF0aW9uIG9mIEVBTVQgZW50cmllcw0KPg0KPiAgICBBbiBFQU0g VGFibGUgKEVBTVQgdXNlZCBmb3Igc2hvcnQsIGFjcm9zcyB0aGUgcmVzdCBvZiB0aGlzIGRvY3Vt ZW50KQ0KPiAgICBNVVNUIGJlIGNyZWF0ZWQvbWFpbnRhaW5lZCBhdXRvbWF0aWNhbGx5IGJ5IHRo ZSBOQVQ0Ni9DTEFULCB3aGljaCBpcw0KPiAgICByZXNwb25zaWJsZSB0byBwcmlvcml0aXplIGFu eSBhdmFpbGFibGUgZW50cmllcyBpbiB0aGUgRUFNVCwgdmVyc3VzDQo+ICAgIHRoZSB1c2Ugb2Yg YW55IHN5bnRoZXRpYyBBQUFBLg0KPg0KPiAgICBUaGUgRUFNVCBlbnRyeSBNVVNUIG9ubHkgYmUg Y3JlYXRlZCBpZiBhbGwgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zDQo+ICAgIGFyZSBtZXQ6DQo+ DQo+ICAgIDEuICBUaGUgc291cmNlIGhvc3QgaXMgSVB2NC1vbmx5Lg0KPg0KPiAgICAyLiAgVGhl IEROUyBwcm94eSBpcyByZWFkeSB0byByZXR1cm4gdGhlIEEgYW5zd2VyIChhY2NvcmRpbmcgdG8N Cj4gICAgICAgIFNlY3Rpb24gNS4yLjQpLg0KPg0KPiAgICAzLiAgVGhlcmUgaXMgYXQgbGVhc3Qg b25lIG5vbi1zeW50aGVzaXplZCBBQUFBIHJlc3BvbnNlLg0KPg0KPiAgICA0LiAgSWYgRE5TU0VD IGlzIGF2YWlsYWJsZSwgdGhlIHJlc3BvbnNlIGhhcyBiZWVuIGxvY2FsbHkgdmFsaWRhdGVkDQo+ ICAgICAgICBvciB0aGUgQUQgYml0IGhhcyBiZWVuIHNldCBieSBhIHRydXN0ZWQgcmVzb2x2ZXIs IGFzIHBlcg0KPiAgICAgICAgW1JGQzM2NTVdLg0KPg0KPiAgICBUaGlzIGF2b2lkcyBhIHNsaWdo dCBOQVQ2NCBvdmVybG9hZCBhbmQgZmxhcHBpbmcgYmV0d2VlbiBkZXN0aW5hdGlvbg0KPiAgICBh ZGRyZXNzZXMgKElQdjQvSVB2NiksIHdoaWNoIG1heSBpbXBhY3Qgc29tZSBhcHBsaWNhdGlvbnMs IGF0IHRoZQ0KPiAgICBjb3N0IG9mIGEgc21hbGwgZXh0cmEgZGVsYXkgZm9yIHRoZSBpbml0aWFs IGNvbW11bmljYXRpb24gc2V0dXAsIHdoZW4NCj4gICAgdGhlIEVBTVQgZW50cnkgZG9lc24ndCB5 ZXQgZXhpc3QuDQo+DQo+ICAgIEVhY2ggRUFNVCBlbnRyeSBNVVNUIGNvbnRhaW4sIHRoZSBmaWVs ZHMgYWxyZWFkeSBkZXNjcmliZWQgaW4NCj4gICAgW1JGQzc3NTddIGFuZCBhIGZldyBuZXcgZXh0 ZW5zaW9ucyAoYXMgcGVyIHNlY3Rpb24gMy4xIG9mIFtSRkM3NzU3XSk6DQo+DQo+ICAgIDEuICBJ RDogRUFNVCBFbnRyeSBJbmRleCAob3B0aW9uYWwpLg0KPg0KPiAgICAyLiAgTUFDIGFkZHJlc3M6 IElkZW50aWZ5IHRoZSBob3N0IHRvIHdoaWNoIHRoaXMgRUFNVCBlbnRyeSBiZWxvbmdzLg0KPg0K PiAgICAzLiAgRGVzdGluYXRpb24gSVB2NCBhZGRyZXNzL3ByZWZpeDogQnkgZGVmYXVsdCwgdGhl IHByZWZpeCBsZW5ndGggaXMNCj4gICAgICAgIDMyIGJpdHMuDQo+DQo+ICAgIDQuICBEZXN0aW5h dGlvbiBJUHY2IGFkZHJlc3MvcHJlZml4OiBCeSBkZWZhdWx0LCB0aGUgcHJlZml4IGxlbmd0aCBp cw0KPiAgICAgICAgMTI4IGJpdHMuICBPbmx5IG5vbi1zeW50aGVzaXplZCBhZGRyZXNzZXMgYXJl IGFsbG93ZWQuDQo+DQo+ICAgIDUuICBUVEw6IEl0IE1VU1QgYmUgc2V0IHRvIHRoZSBtaW5pbXVt IHZhbHVlIGZyb20gdGhlIEFBQUEvQSBSUiBwYWlyLg0KPiAgICAgICAgSW4gbm9ybWFsIGNvbmRp dGlvbnMgdGhlIFRUTCBmb3IgYm90aCBBIGFuZCBBQUFBIHJlY29yZHMsIG9mIGENCj4gICAgICAg IGdpdmVuIEZRRE4sIHNob3VsZCBiZSB0aGUgc2FtZSwgc28gdGhpcyBlbnN1cmVzIGEgcHJvcGVy IGJlaGF2aW9yDQo+ICAgICAgICBpZiB0aGVyZSBpcyBhbnkgRE5TIG1pc21hdGNoLg0KPg0KPiAg ICA2LiAgRlFETjogVGhlIG9uZSB0aGF0IG9yaWdpbmF0ZWQgdGhlIEEgcXVlcnkgZm9yIHRoaXMg RUFNVCBlbnRyeS4NCj4gICAgICAgIFJlcXVpcmVkIGluIG9yZGVyIHRvIGVuc3VyZSBhIGNvcnJl Y3QgZGV0ZWN0aW9uIG9mIGNhc2VzIHN1Y2ggYXMNCj4gICAgICAgIHRoZSB1c2Ugb2YgcmV2ZXJz ZS1wcm94eSB3aXRoIGEgc2luZ2xlIElQdjQgYWRkcmVzcyB0byBtdWx0aXBsZQ0KPiAgICAgICAg SVB2NiBhZGRyZXNzZXMuDQo+DQo+ICAgIDcuICBWYWxpZC9TdGFsZS9JbnZhbGlkOiBXaGVuIHNl dCB0byBTdGFsZSwgbWVhbnMgdGhhdCB0aGlzIEVBTVQNCj4gICAgICAgIGVudHJ5IE1VU1QgTk9U IGJlIHVzZWQgZm9yIG5ldyBjb25uZWN0aW9ucy4gIFdoZW4gc2V0IHRvIEludmFsaWQsDQo+ICAg ICAgICBtZWFucyB0aGF0IHRoaXMgRUFNVCBlbnRyeSBjYW4gYmUgZGVsZXRlZCwgdW5sZXNzIHRo ZSBBdXRvL1N0YXRpYw0KPiAgICAgICAgYml0IGlzIGFsc28gc2V0Lg0KPg0KPiAgICA4LiAgQXV0 by9TdGF0aWM6IFdoZW4gc2V0IHRvIDEsIG1lYW5zIHRoYXQgdGhpcyBFQU1UIGVudHJ5IGhhcyBi ZWVuDQo+ICAgICAgICBtYW51YWxseS9zdGF0aWNhbGx5IGNvbmZpZ3VyZWQsIGZvciBleGFtcGxl IGJ5IG1lYW5zIG9mIGFuDQo+ICAgICAgICBleHBsaWNpdCBjb25maWd1cmF0aW9uIChHVUksIENM SSwgcHJvdmlzaW9uaW5nIHN5c3RlbSwgZXRjLikuDQo+DQo+ICAgIE5vdGUgdGhhdCBhbGxvd2lu ZyBkZXN0aW5hdGlvbiBJUHY0IGFuZCBJUHY2IHByZWZpeGVzLCB0b2dldGhlciB3aXRoDQo+ICAg IHRoZSBWYWxpZC9TdGFsZS9JbnZhbGlkIGFuZCBBdXRvL1N0YXRpYyBmbGFncywgYWxsb3dzIG1h bnVhbCBleHBsaWNpdA0KPiAgICBvcHRpbWl6YXRpb24gYW5kIG5vbi1vcHRpbWl6YXRpb24gY29u ZmlndXJhdGlvbiBmb3Igc3BlY2lmaWMgcGFydHMgb2YNCj4gICAgSW50ZXJuZXQuDQo+DQo+ICAg IFdoZW4gYSBuZXcgRUFNVCBlbnRyeSBpcyBmaXJzdCBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQsIGl0 IGlzIGZsYWdnZWQNCj4gICAgYXMgIlZhbGlkIiBhbmQgIkF1dG8iLiAgSWYgYSBzdWJzZXF1ZW50 IEEgcXVlcnksIHdpdGggYSBkaWZmZXJlbnQNCj4gICAgRlFETiwgcmVzdWx0cyBpbiBhbiBJUHY0 IGFkZHJlc3MgdGhhdCBoYXMgYWxyZWFkeSBhbiBFQU1UIGVudHJ5IGFuZCBhDQo+ICAgIGRpZmZl cmVudCBJUHY2IGFkZHJlc3MsIGl0IG1lYW5zIHRoYXQgc29tZSByZXZlcnNlLXByb3h5IG9yIHNp bWlsYXINCj4gICAgZnVuY3Rpb25hbGl0eSBpcyBiZWluZyB1c2VkIGJ5IHRoZSBJUHY2LWVuYWJs ZWQgc2VydmljZS4gIEluIHRoaXMNCj4gICAgY2FzZSwgdGhlIGV4aXN0aW5nIEVBTVQgZW50cnkg d2lsbCBiZSBtYXJrZWQgYXMgIlN0YWxlIi4gIE5vIG5ldyBFQU1UDQo+ICAgIGVudHJ5IGlzIGNy ZWF0ZWQgZm9yIHRoYXQgSVB2NCBhZGRyZXNzLiAgT3RoZXJ3aXNlLCB0aGUgb3B0aW1pemF0aW9u DQo+ICAgIHdpbGwgb25seSBhbGxvdyB0byBhY2Nlc3MgdGhlIGZpcnN0IHNldCBvZiBJUHY0L0lQ djYvRlFETiwgd2hpY2ggbWF5DQo+ICAgIGJyZWFrIHRoZSBhY2Nlc3MgdG8gb3RoZXIgRlFETiB0 aGF0IHNoYXJlIHRoZSBzYW1lIElQdjQgYWRkcmVzcyBhbmQNCj4gICAgZGlmZmVyZW50IElQdjYg YWRkcmVzc2VzLg0KPg0KPiAgICBJbiB0aGlzIGNhc2UgdGhlIEVBTVQgZW50cnkgd2lsbCBzdGls bCBiZWNvbWUgIkludmFsaWQiIGFjY29yZGluZyB0aGUNCj4gICAgVFRMLCB3aGljaCBhbGxvd3Mg dG8gcmUtZW5hYmxlIG9wdGltaXphdGlvbiBpZiBhIG5ldyBxdWVyeSBmb3IgdGhlIEENCj4gICAg cmVjb3JkIGhhcyBjaGFuZ2VkIHRoZSBzaXR1YXRpb24uICBGb3IgZXhhbXBsZSwgbWF5YmUgdGhl IHJldmVyc2UtDQo+ICAgIHByb3h5IGhhcyBiZWVuIHJlbW92ZWQsIG9yIHRoZXJlIGlzIG5vdyBv bmx5IGEgc2luZ2xlIGRldmljZSB1c2luZw0KPiAgICBpdCwgc28gYXQgdGhlIHRpbWUgYmVpbmcs IHRoZSBvcHRpbWl6YXRpb24gaXMgYWdhaW4gcG9zc2libGUgd2l0aG91dA0KPiAgICBjcmVhdGlu ZyB0cm91YmxlcyB0byBvdGhlciBob3N0cy4NCj4NCj4gICAgQW4gRUFNVCBlbnRyeSBtYXJrZWQg YXMgIlN0YWxlIiBvciAiSW52YWxpZCIsIG9ubHkgYWZmZWN0cyB0aGUNCj4gICAgcmVsZXZhbnQg aG9zdC4gIE90aGVyIGhvc3RzIGhhdmUgdGhlaXIgb3duIEVBTVQgZW50cmllcyBvciB0aGV5IGFy ZQ0KPiAgICB1c2luZyB0aGUgcmVndWxhciBOQVQ0Ni9DTEFUK05BVDY0IHBhdGggKHdpdGhvdXQg dGhlIG9wdGltaXphdGlvbikuDQo+DQo+IDUuMi42LiAgRm9yd2FyZGluZyBwYXRoIHZpYSBzdGF0 ZWZ1bCBOQVQgZm9yIGV4aXN0aW5nIEVBTVQgZW50cmllcw0KPg0KPiAgICBGb2xsb3dpbmcgdGhp cyBhcHByb2FjaCwgaWYgdGhlcmUgaXMgYSB2YWxpZCBFQU1UIGVudHJ5LCBmb3IgYSBnaXZlbg0K PiAgICBwYWlyIG9mIHNvdXJjZS1NQUMtYWRkcmVzcy9JUHY0LWRlc3RpbmF0aW9uLCB0aGUgSVB2 Ni1uYXRpdmUgcGF0aA0KPiAgICBwb2ludGVkIGJ5IHRoZSBJUHY2IGFkZHJlc3Mgb2YgdGhhdCBF QU1UIGVudHJ5LCB3aWxsIHRha2UgcHJlY2VkZW5jZQ0KPiAgICB2ZXJzdXMgdGhlIE5BVDY0IHBh dGgsIHNvIHRoZSB0cmFmZmljIHdpbGwgbm90IGJlIGZvcndhcmRlZCB0byB0aGUNCj4gICAgTkFU NjQuDQo+DQo+ICAgIEhvd2V2ZXIsIHRoaXMgaXMgbm90IHN1ZmZpY2llbnQgdG8gZW5zdXJlIHRo YXQgaW5kaXZpZHVhbA0KPiAgICBhcHBsaWNhdGlvbnMgYXJlIGFibGUgdG8ga2VlcCBleGlzdGlu ZyBjb25uZWN0aW9ucy4gIEluIG1hbnkgY2FzZXMsDQo+ICAgIGF1ZGlvIGFuZCB2aWRlbyBzdHJl YW1pbmcgbWF5IHVzZSBhIHNpbmdsZSBUQ1AgY29ubmVjdGlvbiBsYXN0aW5nDQo+ICAgIGZyb20g bWludXRlcyB0byBob3Vycy4gIEluc3RlYWQsIHRoZSBDRE4gVFRMcyBtYXkgYmUgY29uZmlndXJl ZCBpbg0KPiAgICB0aGUgcmFuZ2UgZnJvbSAxMCB0byAzMDAgc2Vjb25kcyBpbiBvcmRlciB0byBh bGxvdyBuZXcgcmVzb2x1dGlvbnMgdG8NCj4gICAgc3dpdGNoIHF1aWNrbHkgYW5kIHRvIGhhbmRs ZSBsYXJnZSByZWN1cnNpdmUgcmVzb2x2ZXJzICh3aXRoIGh1bmRyZWRzDQo+ICAgIG9mIHRob3Vz YW5kcyBvZiBjbGllbnRzIGJlaGluZCB0aGVtKS4NCj4NCj4gICAgQ29uc2VxdWVudGx5LCB0aGUg RUFNVCBlbnRyaWVzIE1VU1QgTk9UIGJlIHVzZWQgZGlyZWN0bHkgdG8gZXN0YWJsaXNoDQo+ICAg IGEgZm9yd2FyZGluZyBwYXRoLCBidXQgaW5zdGVhZCwgTVVTVCBiZSB1c2VkIHRvIGNyZWF0ZSBh IHN0YXRlZnVsIE5BVA0KPiAgICBlbnRyeSBmb3IgdGhlIDQtdHVwbGUgZm9yIHRoZSBkdXJhdGlv biBvZiB0aGUgc2Vzc2lvbi9jb25uZWN0aW9uLg0KPiAgICBUaGlzIG1lYW5zIHRoYXQgdG8gaW1w bGVtZW50IHRoZSBvcHRpbWl6YXRpb24gdGhlIE5BVDQ2IE1VU1QgYmUNCj4gICAgc3RhdGVmdWwu ICBUeXBpY2FsbHkgc3RhdGVmdWwgTkFUNDYgYXJlIGltcGxlbWVudGVkIGJ5IG1lYW5zIG9mIGEN Cj4gICAgc3RhdGVmdWwgTkFUNDQgKHdoaWNoIG9mdGVuIG1heWJlIGhhcmR3YXJlIG9mZi1sb2Fk ZWQpLCBmb2xsb3dlZCBieSBhDQo+ICAgIHN0YXRlbGVzcyBOQVQ0Ni4gIElmIHRoZSBTb0MvY29k ZSBpcyBhYmxlIHRvIGRvIHN0YXRlbGVzcyBOQVQ0NiwgdGhpcw0KPiAgICBzdGlsbCBjb3VsZCBi ZSB1c2VkIHdoZW4gdGhlIG9wdGltaXphdGlvbiBpcyBkaXNhYmxlZC4NCj4NCj4gNS4yLjcuICBN YWludGVuYW5jZSBvZiB0aGUgRUFNVCBlbnRyaWVzDQo+DQo+ICAgIEFuIEVBVE0gZW50cnkgd2l0 aCB0aGUgQXV0by9TdGF0aWMgYml0IHNldCwgTVVTVCBOT1QgYmUgYXV0b21hdGljYWxseQ0KPiAg ICBtb2RpZmllZC4NCj4NCj4gICAgQW4gRUFNVCBlbnRyeSB3aXRoIHRoZSBBdXRvL1N0YXRpYyBi aXQgY2xlYXIsIE1VU1QgYmUgc2V0IHRvIFN0YWxlDQo+ICAgIGluIGNhc2Ugb2Y6DQo+DQo+ICAg IDEuICBUVEwgdGltZS1vdXQuDQo+DQo+ICAgIDIuICBPciB0aGUgY29uZGl0aW9ucyBmb3IgY3Jl YXRpb24gb2YgdGhlIEVBTVQgZW50cnkgKFNlY3Rpb24gNS4yLjUpDQo+ICAgICAgICBhcmVuJ3Qg bG9uZ2VyIG1ldC4NCj4NCj4gICAgRW50cmllcyBpbiBTdGFsZSBzdGF0ZSBNVVNUIGJlIHNldCB0 byBJbnZhbGlkIG9uY2UgZXhpc3RpbmcNCj4gICAgY29ubmVjdGlvbnMgdGltZS1vdXQuDQo+DQo+ ICAgIFRoZSBJbnZhbGlkIEVBTVQgZW50cmllcyBNVVNUIGJlIGRlbGV0ZWQsIHVubGVzcyB0aGUg QXV0by9TdGF0aWMgYml0DQo+ICAgIGlzIHNldC4gIFRoaXMgYWxsb3dzIHVzZXJzL29wZXJhdG9y cyB0byBzZXQgZXhwbGljaXQgcnVsZXMgZm9yDQo+ICAgIGRpYWdub3N0aWNzIG9yIHJlc29sdXRp b24gb2YgaXNzdWVzIGluIHNwZWNpYWwgc2l0dWF0aW9ucy4NCj4NCj4NCj4NCj4NCj4gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXIN Cj4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cudGhl aXB2NmNvbXBhbnkuY29tDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4NCj4gVGhpcyBlbGVjdHJvbmlj IG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3Ig Y29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBl eGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVy IG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBw YXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBj b3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9y bWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNl LCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91 dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4NCj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Mon Jul 20 02:20:45 2020 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 3D3313A0143 for ; Mon, 20 Jul 2020 02:20:44 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIMbZ6SmKj2S for ; Mon, 20 Jul 2020 02:20:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 89CAC3A00B0 for ; Mon, 20 Jul 2020 02:20:41 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E014387D57DEE1ED88C8; Mon, 20 Jul 2020 10:20:39 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 10:20:39 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 12:20:38 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 12:20:38 +0300 From: Vasilenko Eduard To: Erik Kline , JORDI PALET MARTINEZ CC: v6ops list Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns Thread-Index: AQHWXCMePERdOoO6CEWtMpgm5DnpN6kLXSaAgAA3Znb//9SRgIAAdiZcgALlI4CAAHhWgIAA9qmg Date: Mon, 20 Jul 2020 09:20:38 +0000 Message-ID: References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 09:20:44 -0000 SGkgRXJpaywNCg0KV2hhdCBpcyB5b3VyIGNvbmNlcm4gb24gU1RVTj8NCklmIHNvbWVib2R5IHdv dWxkIGFjY2VzcyBzZXJ2ZXIgYnkgTGl0ZXJhbCAtIGl0IHdvdWxkIGdvIHRvIFBBVCAtIG5vIHBy b2JsZW0uDQpSRkMgNTM4OSBzZWN0aW9uIDk6IEhhcmQtY29kaW5nIHRoZSBkb21haW4gbmFtZSBv ZiB0aGUgc2VydmVyIGludG8gc29mdHdhcmUgaXMgTk9UIFJFQ09NTUVOREVEIGluIGNhc2UgdGhl IGRvbWFpbiBuYW1lIGlzIGxvc3Qgb3IgbmVlZHMgdG8gY2hhbmdlIGZvciBsZWdhbCBvciBvdGhl ciByZWFzb25zLg0KUkZDIDUzODkgc2VjdGlvbiAxOSAoY2hhbmdlcyk6ICAgbyAgQWRkZWQgc3Vw cG9ydCBmb3IgSVB2Ni4gIE1hZGUgaXQgY2xlYXIgdGhhdCBhbiBJUHY0IGNsaWVudCBjb3VsZCBn ZXQgYSB2NiBtYXBwZWQgYWRkcmVzcywgYW5kIHZpY2UgdmVyc2EuDQpUaGVyZWZvcmUsIElmIFNU VU4gc2VydmVyIGlzIGF2YWlsYWJsZSBvdmVyIElQdjYgLSB0aGVuIGl0IGlzIHRoZSBvd25lciBw cm9ibGVtIGZvciBpdCB0byBvcGVyYXRlIHByb3Blcmx5LiBBZ3JlZT8NCg0KRWR1YXJkDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpayBLbGluZQ0KU2VudDogMjAg0LjRjtC70Y8gMjAy MCDQsy4gMDoyOQ0KVG86IEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1 bGludGVsLmVzQGRtYXJjLmlldGYub3JnPg0KQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXph dGlvbi0wMiBnZW5lcmFsIGNvbmNlcm5zDQoNCkRvZXMgYW55IG9mIHRoZSBiZWxvdyBzb2x2ZSB0 aGUgcHJvYmxlbSBvZiBhbiBJUHY0LW9ubHkgaG9zdCB0cnlpbmcgdG8gbGVhcm4gaXQncyBleHRl cm5hbCBJUHY0IGFkZHJlc3MgdmlhIGEgU1RVTiBzZXJ2aWNlIHRoYXQgaXMgZHVhbHN0YWNrZWQ/ DQoNCk9uIFN1biwgSnVsIDE5LCAyMDIwIGF0IDc6MTkgQU0gSk9SREkgUEFMRVQgTUFSVElORVog PGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPg0K PiBIaSBQaGlsaXAsDQo+DQo+DQo+IO+7v0VsIDE3LzcvMjAgMTc6MDUsICJ2Nm9wcyBlbiBub21i cmUgZGUgUGhpbGlwIEhvbWJ1cmciIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIGVuIG5vbWJyZSBk ZSBwY2gtdjZvcHMtOUB1LTEucGhpY29oLmNvbT4gZXNjcmliacOzOg0KPg0KPiAgICAgPltKb3Jk aV0gR29vZCBwb2ludC4gTWF5IGJlOg0KPiAgICAgPg0KPiAgICAgPiJUaGUgQ0UgRE5TIHByb3h5 IE1VU1QgTk9UIHJldHVybiB0aGUgYW5zd2VyIHRvIGFuIEEgcXVlcnkgdW50aWwgZWl0aGVyIGFu IGFuc3dlDQo+ICAgICA+ciB0byB0aGUgQUFBQSBxdWVyeSBoYXMgYmVlbiByZWNlaXZlZCBvciB0 aGUgUmVzb2x1dGlvbiBEZWxheSBoYXMgcGFzc2VkIg0KPg0KPiAgICAgWWVzLCBJIHRoaW5rIHRo aXMgaXMgaW1wb3J0YW50LiBPdGhlcndpc2Ugc21hbGwgZGlmZmVyZW5jZXMgaW4gRE5TIHRpbWlu Zw0KPiAgICAgbWF5IGNhdXNlIGhhcmQgdG8gZGlhZ25vc2UgYnVncy4NCj4NCj4gICAgIEFub3Ro ZXIgc3VnZ2VzdGlvbiBpcyB0aGF0IGlmIHRoZSBBQUFBIHF1ZXJ5IGVpdGhlciBnZXRzIGEgdGlt ZW91dCBvciBTRVJWRkFJTA0KPiAgICAgdGhlbiBhbnkgZXhpc3RpbmcgRUFNVCBlbnRyeSBmb3Ig dGhlIGNvcnJlc3BvbmRpbmcgSVB2NCBhZGRyZXNzIHNob3VsZCBiZQ0KPiAgICAgc2V0IHRvIGlu dmFsaWQuDQo+DQo+ICAgICBUaGVuIHRoZXJlIGlzIEROU1NFQy4gRm9yIGV4YW1wbGUsIHRoZSBB QUFBIGxvb2t1cCBNVVNUL1NIT1VMRC9NQVkgYmUNCj4gICAgIHZlcmlmaWVkIHVzaW5nIEROU1NF QyBsb2NhbCB2YWxpZGF0aW9uLiAoT3IsIHRoZSBBRCBiaXQgb2YgdGhlIHJlcGx5IGNvdWxkDQo+ ICAgICBiZSB1c2VkIGluc3RlYWQpLiBBIHJlcGx5IHRoYXQgZmFpbHMgRE5TU0VDIHZhbGlkYXRp b24gTVVTVC9TSE9VTEQvTUFZIG5vdA0KPiAgICAgcmVzdWx0IGluIHRoZSBjcmVhdGlvbiBvZiBh biBFQU1UIGVudHJ5IChhbmQgTVVTVC9TSE9VTEQvTUFZIHJlc3VsdCBpbg0KPiAgICAgbWFya2lu ZyBhbiBleGl0aW5nIGVudHJ5IGludmFsaWQpDQo+DQo+IFtKb3JkaV0gWWVzIGJvdGggb2YgdGhv c2UgYXJlIGFsc28gdmVyeSBnb29kIHBvaW50cy4gTWF5YmUsIHdlIGNhbiBzdW1tYXJpemUgYWxs IHRob3NlIGNoYW5nZXMgYW5kIHNvbWUgb2YgbXkgcHJldmlvdXMgcmVzcG9uc2VzIHRvIEVyaWsg YW5kIEVkdWFyZCBpbiB0aGUgbGlzdCB3aXRoIHRoZSB0ZXh0ICh0ZW50YXRpdmUpIHRoYXQgSSdt IGFkZGluZyBhdCB0aGUgZW5kIG9mIHRoaXMgZW1haWwuDQo+DQo+ICAgICBPbmUgcXVlc3Rpb24g dGhhdCBkb2Vzbid0IHNlZW0gYW5zd2VyLCB3aGF0IGlmIHRoZSB1cHN0cmVhbSByZXNvbHZlciBp cw0KPiAgICAgZG9pbmcgRE5TNjQuIEluIHRoYXQgY2FzZSBhbiBBQUFBIHF1ZXJ5IHdvdWxkIGdl dCBhbiBhbnN3ZXIgZm9yIGFuIElQdjQtb25seQ0KPiAgICAgc2VydmljZS4gTWF5YmUgaXQgZG9l c24ndCBtYXR0ZXIsIGJlY2F1c2UgdGhlIG1hcHBpbmcgd2lsbCBiZSB0aGUgc2FtZS4NCj4gICAg IE90aGVyd2lzZSBzZXR0aW5nIHRoZSBDRCBmbGFnIGluIHRoZSBxdWVyeSBtYXkgaGVscCB0byBn ZXQgb25seSAncmVhbCcNCj4gICAgIEFBQUEgcmVjb3Jkcy4NCj4NCj4gW0pvcmRpXSBUaGlzIGlz IGFscmVhZHkgcmVzb2x2ZWQgYnkgTk9UIGNyZWF0aW5nIGFuIEVBTVQgZW50cnkgaWYgb25seSBh IHN5bnRoZXRpemVkIEFBQUEgaXMgcmVjZWl2ZWQuIFNlY3Rpb24gNS4yLjI6DQo+ICIgTm90ZSB0 aGF0IHRoZSBOQVQ0Ni9DTEFUIE1VU1QgYWxyZWFkeQ0KPiAgICBrbm93IHRoZSBXS1Agb3IgTlNQ IGJlaW5nIHVzZWQgaW4gdGhhdCBuZXR3b3JrLiAgSWYgdGhlIHJlc3BvbnNlDQo+ICAgIGNvbnRh aW5zIGF0IGxlYXN0IG9uZSBJUHY2IGFkZHJlc3Mgbm90IHVzaW5nIHRoZSBXS1AvTlNQLCBpdCBt ZWFucw0KPiAgICB0aGF0IHRoZSBkZXN0aW5hdGlvbiBpcyBJUHY2LWVuYWJsZWQgKGJlY2F1c2Ug YXQgbGVhc3Qgb25lIG9mIHRoZQ0KPiAgICBJUHY2IGFkZHJlc3NlcyBpcyBub3Qgc3ludGhlc2l6 ZWQpLiAgVGhpcyBtZWFucyB0aGF0IGl0IGlzIHBvc3NpYmxlDQo+ICAgIGZvciB0aGUgTkFUNDYv Q0xBVCwgdG8gY3JlYXRlIGFuIEV4cGxpY2l0IEFkZHJlc3MgTWFwcGluZyINCj4NCj4gW0pvcmRp XSBJJ20gc3RpbGwgdHJ5aW5nIHRvIHRpZHkgdXAgYWxsIHRoZSB0ZXh0IGFjY29yZGluZyB0byBv dGhlciBpbnB1dHMgYW5kIHJlc3BvbmQgdG8gdGhlbS4gVG9vIHNvb24gdG8gc2VuZCBhIG5ldyB2 ZXJzaW9uLCBidXQgY2xvc2UgLi4uDQo+DQo+DQo+IFRlbnRhdGl2ZSBjaGFuZ2VzOg0KPg0KPg0K Pg0KPiA1LjIuMi4gIERldGVjdGlvbiBvZiBJUHY0LW9ubHkgaG9zdHMNCj4NCj4gICAgVGhlIGdv YWwgaXMgdG8gZW5zdXJlIHRoYXQgb25seSBJUHY0LW9ubHkgaG9zdHMgYXJlIG9wdGltaXplZC4N Cj4gICAgVG93YXJkcyB0aGF0LCB0aGUgQ0UgTVVTVCB1c2UgQVJQIGFuZCBORCAoYW5kIHRoZWly IHJlbGV2YW50IGNhY2hlcywNCj4gICAgaWYgdGhlIGluZm9ybWF0aW9uIG9mIGEgaG9zdHMgaGFz IGJlZW4gYWxyZWFkeSBsZWFybnQpIGVhY2ggdGltZSBhDQo+ICAgIG5ldyBob3N0IHN0YXJ0cyBh IGNvbm5lY3Rpb24uICBJZiBpdCBpcyBub3QgcG9zc2libGUgdG8gYmluZCB0aGUgc2FtZQ0KPiAg ICBNQUMgYWRkcmVzcyB0byBib3RoIGFuIElQdjQgYW5kIElQdjYgYWRkcmVzcywgdGhlbiB0aGUg aG9zdCBpcyBub3QNCj4gICAgSVB2NC1vbmx5IChpdCBtYXkgYmUgSVB2Ni1vbmx5IG9yIGR1YWwt c3RhY2spLCBhbmQgTVVTVCBOT1QgYmUNCj4gICAgb3B0aW1pemVkLg0KPg0KPiAgICBUaGUgQ0Ug TVVTVCBtYWludGFpbiBhIHRhYmxlIG9mIElQdjQtb25seSBob3N0cyBhbmQgZW5zdXJlIHRoYXQg aWYNCj4gICAgYW55IElQdjQtb25seSBob3N0cyBiZWNvbWUgSVB2Ni1lbmFibGVkLCBpdCBpcyBw cm9wZXJseSBoYW5kbGVkLg0KPg0KPiAgICBUaGlzIG1lY2hhbmlzbSB0byBkZXRlY3QgSVB2NC1v bmx5IGhvc3RzIGhhcyB0d28gZHJhd2JhY2tzOg0KPg0KPiAgICAxLiAgSWYgYSBzdWJzY3JpYmVy IGhhcyBpbnRlcm1lZGlhdGUgZHVhbC1zdGFjayByb3V0ZXJzIGluIGJldHdlZW4NCj4gICAgICAg IHRoZSBJUHY0LW9ubHkgaG9zdCBhbmQgdGhlIE5BVDQ2L0NMQVQsIHRoZSBJUHY0LW9ubHkgaG9z dHMgd2lsbA0KPiAgICAgICAgYmUgZGV0ZWN0ZWQgYXMgZHVhbC1zdGFjaywgc28gbm8gb3B0aW1p emF0aW9uIHdpbGwgYmUgcGVyZm9ybWVkLg0KPiAgICAgICAgVGhpcyBpcyBub3QgdGhlIG1vc3Qg Y29tbW9uIHNjZW5hcmlvLCBhcyB0eXBpY2FsbHkgdGhlIGRldmljZXMNCj4gICAgICAgIHRoYXQg YXJlIG1vcmUgcmVsZXZhbnQgdG8gdGhlIG9wdGltaXphdGlvbiAoaW4gdGVybXMgb2YgdGhvc2UN Cj4gICAgICAgIHRoYXQgZ2VuZXJhdGUgbW9yZSBJUHY0LW9ubHkgdHJhZmZpYykgYXJlIGRpcmVj dGx5IGF0dGFjaGVkIHRvDQo+ICAgICAgICB0aGUgQ0UsIG9yIGluIGJyaWRnZWQgaW50ZXJmYWNl cy4NCj4NCj4gICAgMi4gIElmIGEgaG9zdCBpcyBkdWFsLXN0YWNrLCBidXQgaGFzIHNvbWUgSVB2 NC1vbmx5IGFwcGxpY2F0aW9ucywNCj4gICAgICAgIGJlY2F1c2UgdGhlIGhvc3Qgd2lsbCBiZSBk ZXRlY3RlZCBhcyBkdWFsLXN0YWNrLCBub25lIG9mIHRoZQ0KPiAgICAgICAgYXBwbGljYXRpb25z IHdpbGwgYmUgb3B0aW1pemVkLiAgVGhpcyBpcyBhIGdvb2QgdHJhZGUtb2ZmLA0KPiAgICAgICAg Y29uc2lkZXJpbmcgdGhlIG1vc3QgaW1wb3J0YW50IHRyYWZmaWMgdG8gb3B0aW1pemUgaXMgdHlw aWNhbGx5DQo+ICAgICAgICBjb21pbmcgZnJvbSByZWFsIElQdjQtb25seSBkZXZpY2VzIHN1Y2gg YXMgb2xkIFNtYXJ0VFZzL1NUQnMuDQo+ICAgICAgICBGdXJ0aGVybW9yZSwgdGhpcyBhdm9pZCBi cmVha2luZyBvdGhlciBtZWNoYW5pc21zIHByZXNlbnQgb25seSBpbg0KPiAgICAgICAgZHVhbC1z dGFjayBob3N0cywgc3VjaCBhcyBIYXBweSBFeWViYWxscyBbUkZDODMwNV0gYW5kIHNpbXBsaWZp ZXMNCj4gICAgICAgIHRyb3VibGVzaG9vdGluZy4NCj4NCj4gICAgSXQgbmVlZHMgdG8gYmUgcmVt YXJrZWQgdGhhdCwgaWYgdGhlIGRldGVjdGlvbiBvZiB0aGUgSVB2NC1vbmx5IGhvc3QNCj4gICAg aXMgZG9uZSBpbmNvcnJlY3RseSAoZWl0aGVyIG5vdCBkZXRlY3RpbmcgaXQgb3IgYnkgYSBmYWxz ZQ0KPiAgICBkZXRlY3Rpb24pLCB0aGUgZ29hbCBpcyB0aGF0IG5vIGhhcm0gaXMgY2F1c2VkLiAg SW4gdGhlIHdvcnN0IGNhc2UsDQo+ICAgIG9wdGltaXphdGlvbiBNVVNUIE5PVCBiZSBwZXJmb3Jt ZWQuDQo+DQo+IDUuMi4zLiAgRGV0ZWN0aW9uIG9mIElQdjYtZW5hYmxlZCBzZXJ2aWNlDQo+DQo+ ICAgIEluIHRoZSBjYXNlIG9mIGFuIElQdjQtb25seSBkZXRlY3RlZCBob3N0LCB0aGUgRE5TIHBy b3h5L3N0dWINCj4gICAgcmVzb2x2ZXIgTVVTVCBhY3R1YWxseSBwZXJmb3JtIGFuIGFkZGl0aW9u YWwgQUFBQSBxdWVyeSwgdW5sZXNzIHRoZQ0KPiAgICBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IHBy ZXNlbnQgaW4gdGhlIEFkZGl0aW9uYWwgU2VjdGlvbiwgYXMgcGVyDQo+ICAgIFNlY3Rpb24gMyBv ZiBbUkZDMzU5Nl0uDQo+DQo+ICAgIE5vdGUgdGhhdCB0aGUgTkFUNDYvQ0xBVCBNVVNUIGFscmVh ZHkga25vdyB0aGUgV0tQIG9yIE5TUCBiZWluZyB1c2VkDQo+ICAgIGluIHRoYXQgbmV0d29yay4g IElmIHRoZSByZXNwb25zZSBjb250YWlucyBhdCBsZWFzdCBvbmUgSVB2NiBhZGRyZXNzDQo+ICAg IG5vdCB1c2luZyB0aGUgV0tQL05TUCwgaXQgbWVhbnMgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMg SVB2Ni1lbmFibGVkDQo+ICAgIChiZWNhdXNlIGF0IGxlYXN0IG9uZSBvZiB0aGUgSVB2NiBhZGRy ZXNzZXMgaXMgbm90IHN5bnRoZXNpemVkKS4NCj4gICAgVGhpcyBtZWFucyB0aGF0IGl0IGlzIHBv c3NpYmxlIGZvciB0aGUgTkFUNDYvQ0xBVCwgdG8gY3JlYXRlIGFuDQo+ICAgIEV4cGxpY2l0IEFk ZHJlc3MgTWFwcGluZyAoW1JGQzc3NTddKS4NCj4NCj4gNS4yLjQuICBDRSBETlMgcHJveHkgcmVz cG9uc2VzDQo+DQo+ICAgIEluIHRoZSBjYXNlIG9mIGFuIElQdjQtb25seSBkZXRlY3RlZCBob3N0 LCB0aGUgQ0UgRE5TIHByb3h5IE1VU1Qgb25seQ0KPiAgICByZXR1cm4gdGhlIGFuc3dlciB0byBh biBBIHF1ZXJ5IG9uY2UgYW55IG9mIHRoZSBmb2xsb3dpbmcgaGFwcGVuczoNCj4NCj4gICAgMS4g IEFuIGFuc3dlciB0byB0aGUgQUFBQSBxdWVyeSBoYXMgYmVlbiByZWNlaXZlZC4NCj4NCj4gICAg Mi4gIEEgU0VSVkZBSUwgaGFzIGJlZW4gcmVjZWl2ZWQuDQo+DQo+ICAgIDMuICBUaGUgIlJlc29s dXRpb24gRGVsYXkiIGhhcyBwYXNzZWQuDQo+DQo+ICAgIFRoZSBSZXNvbHV0aW9uIERlbGF5IE1V U1QgYmUgc2V0IHRvIHRoZSBzYW1lIHZhbHVlICg1MCBtaWxsaXNlY29uZHMpDQo+ICAgIGFzIGlu ZGljYXRlZCBieSBIYXBweSBFeWViYWxscyBbUkZDODMwNV0uDQo+DQo+IDUuMi41LiAgQ3JlYXRp b24gb2YgRUFNVCBlbnRyaWVzDQo+DQo+ICAgIEFuIEVBTSBUYWJsZSAoRUFNVCB1c2VkIGZvciBz aG9ydCwgYWNyb3NzIHRoZSByZXN0IG9mIHRoaXMgZG9jdW1lbnQpDQo+ICAgIE1VU1QgYmUgY3Jl YXRlZC9tYWludGFpbmVkIGF1dG9tYXRpY2FsbHkgYnkgdGhlIE5BVDQ2L0NMQVQsIHdoaWNoIGlz DQo+ICAgIHJlc3BvbnNpYmxlIHRvIHByaW9yaXRpemUgYW55IGF2YWlsYWJsZSBlbnRyaWVzIGlu IHRoZSBFQU1ULCB2ZXJzdXMNCj4gICAgdGhlIHVzZSBvZiBhbnkgc3ludGhldGljIEFBQUEuDQo+ DQo+ICAgIFRoZSBFQU1UIGVudHJ5IE1VU1Qgb25seSBiZSBjcmVhdGVkIGlmIGFsbCB0aGUgZm9s bG93aW5nIGNvbmRpdGlvbnMNCj4gICAgYXJlIG1ldDoNCj4NCj4gICAgMS4gIFRoZSBzb3VyY2Ug aG9zdCBpcyBJUHY0LW9ubHkuDQo+DQo+ICAgIDIuICBUaGUgRE5TIHByb3h5IGlzIHJlYWR5IHRv IHJldHVybiB0aGUgQSBhbnN3ZXIgKGFjY29yZGluZyB0bw0KPiAgICAgICAgU2VjdGlvbiA1LjIu NCkuDQo+DQo+ICAgIDMuICBUaGVyZSBpcyBhdCBsZWFzdCBvbmUgbm9uLXN5bnRoZXNpemVkIEFB QUEgcmVzcG9uc2UuDQo+DQo+ICAgIDQuICBJZiBETlNTRUMgaXMgYXZhaWxhYmxlLCB0aGUgcmVz cG9uc2UgaGFzIGJlZW4gbG9jYWxseSB2YWxpZGF0ZWQNCj4gICAgICAgIG9yIHRoZSBBRCBiaXQg aGFzIGJlZW4gc2V0IGJ5IGEgdHJ1c3RlZCByZXNvbHZlciwgYXMgcGVyDQo+ICAgICAgICBbUkZD MzY1NV0uDQo+DQo+ICAgIFRoaXMgYXZvaWRzIGEgc2xpZ2h0IE5BVDY0IG92ZXJsb2FkIGFuZCBm bGFwcGluZyBiZXR3ZWVuIGRlc3RpbmF0aW9uDQo+ICAgIGFkZHJlc3NlcyAoSVB2NC9JUHY2KSwg d2hpY2ggbWF5IGltcGFjdCBzb21lIGFwcGxpY2F0aW9ucywgYXQgdGhlDQo+ICAgIGNvc3Qgb2Yg YSBzbWFsbCBleHRyYSBkZWxheSBmb3IgdGhlIGluaXRpYWwgY29tbXVuaWNhdGlvbiBzZXR1cCwg d2hlbg0KPiAgICB0aGUgRUFNVCBlbnRyeSBkb2Vzbid0IHlldCBleGlzdC4NCj4NCj4gICAgRWFj aCBFQU1UIGVudHJ5IE1VU1QgY29udGFpbiwgdGhlIGZpZWxkcyBhbHJlYWR5IGRlc2NyaWJlZCBp bg0KPiAgICBbUkZDNzc1N10gYW5kIGEgZmV3IG5ldyBleHRlbnNpb25zIChhcyBwZXIgc2VjdGlv biAzLjEgb2YgW1JGQzc3NTddKToNCj4NCj4gICAgMS4gIElEOiBFQU1UIEVudHJ5IEluZGV4IChv cHRpb25hbCkuDQo+DQo+ICAgIDIuICBNQUMgYWRkcmVzczogSWRlbnRpZnkgdGhlIGhvc3QgdG8g d2hpY2ggdGhpcyBFQU1UIGVudHJ5IGJlbG9uZ3MuDQo+DQo+ICAgIDMuICBEZXN0aW5hdGlvbiBJ UHY0IGFkZHJlc3MvcHJlZml4OiBCeSBkZWZhdWx0LCB0aGUgcHJlZml4IGxlbmd0aCBpcw0KPiAg ICAgICAgMzIgYml0cy4NCj4NCj4gICAgNC4gIERlc3RpbmF0aW9uIElQdjYgYWRkcmVzcy9wcmVm aXg6IEJ5IGRlZmF1bHQsIHRoZSBwcmVmaXggbGVuZ3RoIGlzDQo+ICAgICAgICAxMjggYml0cy4g IE9ubHkgbm9uLXN5bnRoZXNpemVkIGFkZHJlc3NlcyBhcmUgYWxsb3dlZC4NCj4NCj4gICAgNS4g IFRUTDogSXQgTVVTVCBiZSBzZXQgdG8gdGhlIG1pbmltdW0gdmFsdWUgZnJvbSB0aGUgQUFBQS9B IFJSIHBhaXIuDQo+ICAgICAgICBJbiBub3JtYWwgY29uZGl0aW9ucyB0aGUgVFRMIGZvciBib3Ro IEEgYW5kIEFBQUEgcmVjb3Jkcywgb2YgYQ0KPiAgICAgICAgZ2l2ZW4gRlFETiwgc2hvdWxkIGJl IHRoZSBzYW1lLCBzbyB0aGlzIGVuc3VyZXMgYSBwcm9wZXIgYmVoYXZpb3INCj4gICAgICAgIGlm IHRoZXJlIGlzIGFueSBETlMgbWlzbWF0Y2guDQo+DQo+ICAgIDYuICBGUUROOiBUaGUgb25lIHRo YXQgb3JpZ2luYXRlZCB0aGUgQSBxdWVyeSBmb3IgdGhpcyBFQU1UIGVudHJ5Lg0KPiAgICAgICAg UmVxdWlyZWQgaW4gb3JkZXIgdG8gZW5zdXJlIGEgY29ycmVjdCBkZXRlY3Rpb24gb2YgY2FzZXMg c3VjaCBhcw0KPiAgICAgICAgdGhlIHVzZSBvZiByZXZlcnNlLXByb3h5IHdpdGggYSBzaW5nbGUg SVB2NCBhZGRyZXNzIHRvIG11bHRpcGxlDQo+ICAgICAgICBJUHY2IGFkZHJlc3Nlcy4NCj4NCj4g ICAgNy4gIFZhbGlkL1N0YWxlL0ludmFsaWQ6IFdoZW4gc2V0IHRvIFN0YWxlLCBtZWFucyB0aGF0 IHRoaXMgRUFNVA0KPiAgICAgICAgZW50cnkgTVVTVCBOT1QgYmUgdXNlZCBmb3IgbmV3IGNvbm5l Y3Rpb25zLiAgV2hlbiBzZXQgdG8gSW52YWxpZCwNCj4gICAgICAgIG1lYW5zIHRoYXQgdGhpcyBF QU1UIGVudHJ5IGNhbiBiZSBkZWxldGVkLCB1bmxlc3MgdGhlIEF1dG8vU3RhdGljDQo+ICAgICAg ICBiaXQgaXMgYWxzbyBzZXQuDQo+DQo+ICAgIDguICBBdXRvL1N0YXRpYzogV2hlbiBzZXQgdG8g MSwgbWVhbnMgdGhhdCB0aGlzIEVBTVQgZW50cnkgaGFzIGJlZW4NCj4gICAgICAgIG1hbnVhbGx5 L3N0YXRpY2FsbHkgY29uZmlndXJlZCwgZm9yIGV4YW1wbGUgYnkgbWVhbnMgb2YgYW4NCj4gICAg ICAgIGV4cGxpY2l0IGNvbmZpZ3VyYXRpb24gKEdVSSwgQ0xJLCBwcm92aXNpb25pbmcgc3lzdGVt LCBldGMuKS4NCj4NCj4gICAgTm90ZSB0aGF0IGFsbG93aW5nIGRlc3RpbmF0aW9uIElQdjQgYW5k IElQdjYgcHJlZml4ZXMsIHRvZ2V0aGVyIHdpdGgNCj4gICAgdGhlIFZhbGlkL1N0YWxlL0ludmFs aWQgYW5kIEF1dG8vU3RhdGljIGZsYWdzLCBhbGxvd3MgbWFudWFsIGV4cGxpY2l0DQo+ICAgIG9w dGltaXphdGlvbiBhbmQgbm9uLW9wdGltaXphdGlvbiBjb25maWd1cmF0aW9uIGZvciBzcGVjaWZp YyBwYXJ0cyBvZg0KPiAgICBJbnRlcm5ldC4NCj4NCj4gICAgV2hlbiBhIG5ldyBFQU1UIGVudHJ5 IGlzIGZpcnN0IGF1dG9tYXRpY2FsbHkgY3JlYXRlZCwgaXQgaXMgZmxhZ2dlZA0KPiAgICBhcyAi VmFsaWQiIGFuZCAiQXV0byIuICBJZiBhIHN1YnNlcXVlbnQgQSBxdWVyeSwgd2l0aCBhIGRpZmZl cmVudA0KPiAgICBGUUROLCByZXN1bHRzIGluIGFuIElQdjQgYWRkcmVzcyB0aGF0IGhhcyBhbHJl YWR5IGFuIEVBTVQgZW50cnkgYW5kIGENCj4gICAgZGlmZmVyZW50IElQdjYgYWRkcmVzcywgaXQg bWVhbnMgdGhhdCBzb21lIHJldmVyc2UtcHJveHkgb3Igc2ltaWxhcg0KPiAgICBmdW5jdGlvbmFs aXR5IGlzIGJlaW5nIHVzZWQgYnkgdGhlIElQdjYtZW5hYmxlZCBzZXJ2aWNlLiAgSW4gdGhpcw0K PiAgICBjYXNlLCB0aGUgZXhpc3RpbmcgRUFNVCBlbnRyeSB3aWxsIGJlIG1hcmtlZCBhcyAiU3Rh bGUiLiAgTm8gbmV3IEVBTVQNCj4gICAgZW50cnkgaXMgY3JlYXRlZCBmb3IgdGhhdCBJUHY0IGFk ZHJlc3MuICBPdGhlcndpc2UsIHRoZSBvcHRpbWl6YXRpb24NCj4gICAgd2lsbCBvbmx5IGFsbG93 IHRvIGFjY2VzcyB0aGUgZmlyc3Qgc2V0IG9mIElQdjQvSVB2Ni9GUUROLCB3aGljaCBtYXkNCj4g ICAgYnJlYWsgdGhlIGFjY2VzcyB0byBvdGhlciBGUUROIHRoYXQgc2hhcmUgdGhlIHNhbWUgSVB2 NCBhZGRyZXNzIGFuZA0KPiAgICBkaWZmZXJlbnQgSVB2NiBhZGRyZXNzZXMuDQo+DQo+ICAgIElu IHRoaXMgY2FzZSB0aGUgRUFNVCBlbnRyeSB3aWxsIHN0aWxsIGJlY29tZSAiSW52YWxpZCIgYWNj b3JkaW5nIHRoZQ0KPiAgICBUVEwsIHdoaWNoIGFsbG93cyB0byByZS1lbmFibGUgb3B0aW1pemF0 aW9uIGlmIGEgbmV3IHF1ZXJ5IGZvciB0aGUgQQ0KPiAgICByZWNvcmQgaGFzIGNoYW5nZWQgdGhl IHNpdHVhdGlvbi4gIEZvciBleGFtcGxlLCBtYXliZSB0aGUgcmV2ZXJzZS0NCj4gICAgcHJveHkg aGFzIGJlZW4gcmVtb3ZlZCwgb3IgdGhlcmUgaXMgbm93IG9ubHkgYSBzaW5nbGUgZGV2aWNlIHVz aW5nDQo+ICAgIGl0LCBzbyBhdCB0aGUgdGltZSBiZWluZywgdGhlIG9wdGltaXphdGlvbiBpcyBh Z2FpbiBwb3NzaWJsZSB3aXRob3V0DQo+ICAgIGNyZWF0aW5nIHRyb3VibGVzIHRvIG90aGVyIGhv c3RzLg0KPg0KPiAgICBBbiBFQU1UIGVudHJ5IG1hcmtlZCBhcyAiU3RhbGUiIG9yICJJbnZhbGlk Iiwgb25seSBhZmZlY3RzIHRoZQ0KPiAgICByZWxldmFudCBob3N0LiAgT3RoZXIgaG9zdHMgaGF2 ZSB0aGVpciBvd24gRUFNVCBlbnRyaWVzIG9yIHRoZXkgYXJlDQo+ICAgIHVzaW5nIHRoZSByZWd1 bGFyIE5BVDQ2L0NMQVQrTkFUNjQgcGF0aCAod2l0aG91dCB0aGUgb3B0aW1pemF0aW9uKS4NCj4N Cj4gNS4yLjYuICBGb3J3YXJkaW5nIHBhdGggdmlhIHN0YXRlZnVsIE5BVCBmb3IgZXhpc3Rpbmcg RUFNVCBlbnRyaWVzDQo+DQo+ICAgIEZvbGxvd2luZyB0aGlzIGFwcHJvYWNoLCBpZiB0aGVyZSBp cyBhIHZhbGlkIEVBTVQgZW50cnksIGZvciBhIGdpdmVuDQo+ICAgIHBhaXIgb2Ygc291cmNlLU1B Qy1hZGRyZXNzL0lQdjQtZGVzdGluYXRpb24sIHRoZSBJUHY2LW5hdGl2ZSBwYXRoDQo+ICAgIHBv aW50ZWQgYnkgdGhlIElQdjYgYWRkcmVzcyBvZiB0aGF0IEVBTVQgZW50cnksIHdpbGwgdGFrZSBw cmVjZWRlbmNlDQo+ICAgIHZlcnN1cyB0aGUgTkFUNjQgcGF0aCwgc28gdGhlIHRyYWZmaWMgd2ls bCBub3QgYmUgZm9yd2FyZGVkIHRvIHRoZQ0KPiAgICBOQVQ2NC4NCj4NCj4gICAgSG93ZXZlciwg dGhpcyBpcyBub3Qgc3VmZmljaWVudCB0byBlbnN1cmUgdGhhdCBpbmRpdmlkdWFsDQo+ICAgIGFw cGxpY2F0aW9ucyBhcmUgYWJsZSB0byBrZWVwIGV4aXN0aW5nIGNvbm5lY3Rpb25zLiAgSW4gbWFu eSBjYXNlcywNCj4gICAgYXVkaW8gYW5kIHZpZGVvIHN0cmVhbWluZyBtYXkgdXNlIGEgc2luZ2xl IFRDUCBjb25uZWN0aW9uIGxhc3RpbmcNCj4gICAgZnJvbSBtaW51dGVzIHRvIGhvdXJzLiAgSW5z dGVhZCwgdGhlIENETiBUVExzIG1heSBiZSBjb25maWd1cmVkIGluDQo+ICAgIHRoZSByYW5nZSBm cm9tIDEwIHRvIDMwMCBzZWNvbmRzIGluIG9yZGVyIHRvIGFsbG93IG5ldyByZXNvbHV0aW9ucyB0 bw0KPiAgICBzd2l0Y2ggcXVpY2tseSBhbmQgdG8gaGFuZGxlIGxhcmdlIHJlY3Vyc2l2ZSByZXNv bHZlcnMgKHdpdGggaHVuZHJlZHMNCj4gICAgb2YgdGhvdXNhbmRzIG9mIGNsaWVudHMgYmVoaW5k IHRoZW0pLg0KPg0KPiAgICBDb25zZXF1ZW50bHksIHRoZSBFQU1UIGVudHJpZXMgTVVTVCBOT1Qg YmUgdXNlZCBkaXJlY3RseSB0byBlc3RhYmxpc2gNCj4gICAgYSBmb3J3YXJkaW5nIHBhdGgsIGJ1 dCBpbnN0ZWFkLCBNVVNUIGJlIHVzZWQgdG8gY3JlYXRlIGEgc3RhdGVmdWwgTkFUDQo+ICAgIGVu dHJ5IGZvciB0aGUgNC10dXBsZSBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBzZXNzaW9uL2Nvbm5l Y3Rpb24uDQo+ICAgIFRoaXMgbWVhbnMgdGhhdCB0byBpbXBsZW1lbnQgdGhlIG9wdGltaXphdGlv biB0aGUgTkFUNDYgTVVTVCBiZQ0KPiAgICBzdGF0ZWZ1bC4gIFR5cGljYWxseSBzdGF0ZWZ1bCBO QVQ0NiBhcmUgaW1wbGVtZW50ZWQgYnkgbWVhbnMgb2YgYQ0KPiAgICBzdGF0ZWZ1bCBOQVQ0NCAo d2hpY2ggb2Z0ZW4gbWF5YmUgaGFyZHdhcmUgb2ZmLWxvYWRlZCksIGZvbGxvd2VkIGJ5IGENCj4g ICAgc3RhdGVsZXNzIE5BVDQ2LiAgSWYgdGhlIFNvQy9jb2RlIGlzIGFibGUgdG8gZG8gc3RhdGVs ZXNzIE5BVDQ2LCB0aGlzDQo+ICAgIHN0aWxsIGNvdWxkIGJlIHVzZWQgd2hlbiB0aGUgb3B0aW1p emF0aW9uIGlzIGRpc2FibGVkLg0KPg0KPiA1LjIuNy4gIE1haW50ZW5hbmNlIG9mIHRoZSBFQU1U IGVudHJpZXMNCj4NCj4gICAgQW4gRUFUTSBlbnRyeSB3aXRoIHRoZSBBdXRvL1N0YXRpYyBiaXQg c2V0LCBNVVNUIE5PVCBiZSBhdXRvbWF0aWNhbGx5DQo+ICAgIG1vZGlmaWVkLg0KPg0KPiAgICBB biBFQU1UIGVudHJ5IHdpdGggdGhlIEF1dG8vU3RhdGljIGJpdCBjbGVhciwgTVVTVCBiZSBzZXQg dG8gU3RhbGUNCj4gICAgaW4gY2FzZSBvZjoNCj4NCj4gICAgMS4gIFRUTCB0aW1lLW91dC4NCj4N Cj4gICAgMi4gIE9yIHRoZSBjb25kaXRpb25zIGZvciBjcmVhdGlvbiBvZiB0aGUgRUFNVCBlbnRy eSAoU2VjdGlvbiA1LjIuNSkNCj4gICAgICAgIGFyZW4ndCBsb25nZXIgbWV0Lg0KPg0KPiAgICBF bnRyaWVzIGluIFN0YWxlIHN0YXRlIE1VU1QgYmUgc2V0IHRvIEludmFsaWQgb25jZSBleGlzdGlu Zw0KPiAgICBjb25uZWN0aW9ucyB0aW1lLW91dC4NCj4NCj4gICAgVGhlIEludmFsaWQgRUFNVCBl bnRyaWVzIE1VU1QgYmUgZGVsZXRlZCwgdW5sZXNzIHRoZSBBdXRvL1N0YXRpYyBiaXQNCj4gICAg aXMgc2V0LiAgVGhpcyBhbGxvd3MgdXNlcnMvb3BlcmF0b3JzIHRvIHNldCBleHBsaWNpdCBydWxl cyBmb3INCj4gICAgZGlhZ25vc3RpY3Mgb3IgcmVzb2x1dGlvbiBvZiBpc3N1ZXMgaW4gc3BlY2lh bCBzaXR1YXRpb25zLg0KPg0KPg0KPg0KPg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0 aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb20NCj4gVGhl IElQdjYgQ29tcGFueQ0KPg0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZv cm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZv cm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9y aXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250 ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVy ZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBv ciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlh bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdp bGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRv IHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBh bmQgZGVsZXRlIGl0Lg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBs aXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0K From nobody Mon Jul 20 02:57:18 2020 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 3F41D3A07FB for ; Mon, 20 Jul 2020 02:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNY8-T-2pOag for ; Mon, 20 Jul 2020 02:57:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCD53A07FC for ; Mon, 20 Jul 2020 02:57:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jxSXm-00007PC; Mon, 20 Jul 2020 11:57:10 +0200 Message-Id: To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-reply-to: Your message of "Sun, 19 Jul 2020 12:57:31 +0200 ." Date: Mon, 20 Jul 2020 11:57:10 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 09:57:17 -0000 > Because we are looking for EAMT entries which also contain the > FQDN, there will be no match, so no optimization performed if the > AAAA response doesn't come timely. I don't understand this. Suppose an IPv4-only client looks up a.example.com and b.example.com (in parallel). The CPE generates additional AAAA queries for a.example.com and b.example.com. The A queries for both a.example.com and b.example.com return 192.0.2.1. The AAAA query for a.example.com returns 2001:DB8::1 and the AAAA query for b.example.com results in a timeout. When the AAAA query for a.example.com returns, the CPE installs an EAMT entry for a.example.com. When b.example.com gets a timeout, the CPE does nothing Later the host connects twice to 192.0.2.1. The CPE sees the EAMT entry and connects the host twice to 2001:DB8::1 From nobody Mon Jul 20 03:07:53 2020 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 BD1FE3A082E for ; Mon, 20 Jul 2020 03:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtETeNNuuUkX for ; Mon, 20 Jul 2020 03:07:50 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB993A0828 for ; Mon, 20 Jul 2020 03:07:49 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id k18so14643440qke.4 for ; Mon, 20 Jul 2020 03:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UOIDJLH5GQLbxYdcXK+HVl29KfsUWaXu08gQoKsvEQo=; b=brlbnlSRNbXxLH8WNkFDRgvwOLFkwN9mMeOaLoeJotgK2TZXNYyKHZ7Cantlr9o981 aClUhj23l+zebKCkodgOnWGAFfGSbgivm51TUMmJHZzqsja5t6XSr6WkJcJOKMaVE0m5 M/v9n4kvdZclH9aGnqhP5UzN/vhoplteMQ9te3fTlJNneRRa3065/+CMfhScl6L6Epr2 1VPxYpt9ejq9oyrd7rKYYG/Vgm2QOTPKn5q5fTELv8v0TKm/wcWsXe6nIE8zG8QnOyZn r1m4BhE3KIE08nx/YXo7VSPajRGXmqXEDLZ3/nLUuXNCDosySoHpMsvnIN7+zcNmX3zx K6nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UOIDJLH5GQLbxYdcXK+HVl29KfsUWaXu08gQoKsvEQo=; b=Hz3JSE7AnTPL6VTWZ8cIBEuEd0yf1iEV95pYUEgpLgyj7bZTiIAYDlDsuVuVlx3WZ5 H5iKzpZdfmdCieGMihWsdAQYeNMUuHBXSFPw/2zEvNMINxtqfwb5Rl4dxxy67jJStN0c C5PIw0hb2ZSW9D7TneMu51COGC/bNEN2VSe/QiIoVch7RQxj68PDhNNnEZqCCAgqaSuA NKsXy0YyPusldQN10z7jJF5lcpCMmrN4la4VAJcD1XjebaNPh25PEc4tGmu4OzGSY/6D PNOx7SEbmmqSpOHdzTaAn3wrUYf9PyBrMibEi+1eh3cCWXa7LO+KLtHpT02ZxclSntGR 2VWQ== X-Gm-Message-State: AOAM532hsO/lj522vP1/Psv/4ScZhCczX5VomQytwG7NUR0/jZZ9nriY eFvUW/HqZG1ENx4cK5VBN5rjbp0rvxLZlIQ3ExMnO+/s X-Google-Smtp-Source: ABdhPJxx2uHFT36JdlXIMx97C7i9j1FXxRkXIUWgNtsUHfZFjJ2g5oQCJ401J+2Z2lpSuCpF4f5AxmMKIsCaYDrEe2w= X-Received: by 2002:a37:a354:: with SMTP id m81mr17437qke.277.1595239668900; Mon, 20 Jul 2020 03:07:48 -0700 (PDT) MIME-Version: 1.0 References: <1a0f8217382048eb8329424c5b3f79f9@huawei.com> <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> In-Reply-To: <5A9E6D25-777F-4D29-A839-A55686B81B33@consulintel.es> From: Jen Linkova Date: Mon, 20 Jul 2020 20:07:37 +1000 Message-ID: To: JORDI PALET MARTINEZ Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 concerns on centralized (IT) EAMT configuration X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 10:07:52 -0000 On Sat, Jul 18, 2020 at 7:55 AM JORDI PALET MARTINEZ wrote: > The document exposes different possible solutions. We have considered 3, = in other RFCs there are even more. For example I was reviewing draft-ietf= -v6ops-nd-cache-init a few days ago, and it presents about 8 solutions and = suggest one as the most reasonable. ;) Let me comment on it ;) The reason nd-cache-init lists all those options is some of them *are* implemented and could be seen in the wild. So the draft tries to explain why GRAND is proposed. We are not saying 'don't do this ever', we are saying 'we believe that would work (and does work) but there are limitations, so let's do GRAND'. I'm afraid option 3 in this draft is slightly different. Do we know any actual implementations? > So in my opinion is perfeclty valid to have several choices and then deci= de. Note that when we started the document it was not clear for us, the = document keeps growing, and we may change our minds about what solution is = better, depending on the inputs, however, I think it is important to keep a= ll the possible solutions documented even if it is clear that they don=E2= =80=99t make sense. The only concern here is that there are an endless number of solutions which do not make sense ;) I can suggest one more: - The main driver of the document and the underlying problem we are solving seems to be the cost of deploying NAT64 at large scale. If operators can do the second translation for free, we wouldn't even have this draft, right? So operators could start charging users based on IPv6/IPv4 traffic ratio ;) Remember all those cases when your uplink charged you based on egress/ingress ratio? '5% discount if your monthly IPv6/IPv4 ration is above 70%' As a result, users would suddenly start caring about that weird IPv6 thingy and maybe even ask for IPv6-enabled TVs. Operators get some of their CapEx shifted to users ;) On a serious note: maybe you can separate the proposed option from discarded ones more clearly - like different sections or even Appendix? > > > El 17/7/20 21:19, "Vasilenko Eduard" escrib= i=C3=B3: > > > > Hi Jordi, > > How Carrier would know that user has brought additional device (TV for ex= ample) to his residence? > > Or let=E2=80=99s ask in simpler form: how Carrier would know how many Stu= pidTVs (IPv4 only) user already have? > > What to program in centralized IT system? > > IMHO: the whole Approach #3 (clause 5.3) does not make sense. > > Would you agree to delete it? > > As you mentioned in the draft: It is useless anyway without protocol to u= pload EAMT. > > Eduard > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Mon Jul 20 03:17:25 2020 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 D868C3A0845 for ; Mon, 20 Jul 2020 03:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEhacbBOAF2i for ; Mon, 20 Jul 2020 03:17:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2B7633A083D for ; Mon, 20 Jul 2020 03:17:20 -0700 (PDT) Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AE421BF27A06D923C543; Mon, 20 Jul 2020 11:17:18 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 20 Jul 2020 11:17:18 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 13:17:17 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 13:17:17 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ , "V6 Ops List" Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals Thread-Index: AdZcdd5aW2KjixhYTwqkJPfQUrMFfQAXlVEAADqJKQAALyUsgA== Date: Mon, 20 Jul 2020 10:17:17 +0000 Message-ID: <1b57ee72a7ad41058a72abe8254c3b96@huawei.com> References: <7d12c5b6b855488fa6af9b75085c3385@huawei.com> <87EA9471-5BA1-4E3F-A4DE-4ECB48452C02@consulintel.es> In-Reply-To: <87EA9471-5BA1-4E3F-A4DE-4ECB48452C02@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: multipart/alternative; boundary="_000_1b57ee72a7ad41058a72abe8254c3b96huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - some disruptive proposals X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 10:17:24 -0000 --_000_1b57ee72a7ad41058a72abe8254c3b96huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQpbSm9yZGldIE5vdCBzdXJlIGlmIEkgZ290IGl0IGNvcnJlY3RseS4gSSBkb27i gJl0IHRoaW5rIHNvLiBJZiB3ZSB1c2UgdGhlIGFkZHJlc3NlcyBhcyBpbiBhIG5vbi1vcHRpbWl6 ZWQgQ0xBVCwgdGhleSBhcmUgc3ludGhldGl6ZWQsIHNvIHRoZXkgd2lsbCBuYXR1cmFsbHkgZm9s bG93IHRoZSBQTEFUIHBhdGgg4oCTIHRoaXMgaXMgd2hhdCB3ZSB0cnkgdG8gYXZvaWQuIFRoZSBJ UHY2IHNvdXJjZSBhZGRyZXNzIGFmdGVyIHRoZSBDTEFUIGlzIG5vdCByZWxldmFudCBmb3IgdGhl IG9wdGltaXphdGlvbiAobm8gaW1wYWN0KS4NCltFZHVhcmRdIFlvdSBhcmUgdGhpbmtpbmcgYWJv dXQgZGVzdGluYXRpb24gSVB2NiDigJMgeW91IGFyZSBkZWFsaW5nIHdpdGggaXQgYnkgRE5TIHJl cXVlc3QuIEkgaGF2ZSBzaG93biB0byB5b3UgYWxyZWFkeSBpbiBtYW55IGRpc2N1c3Npb25zIHRo YXQgSSBhbSB0aGlua2luZyBhYm91dCBzb3VyY2UgdG9vLiBTdGF0ZWZ1bCBhZ2FpbnN0IHN0YXRl bGVzcyDigJMgaXQgaXMgYWJvdXQgaXQuDQpJIHdhcyB0YWxraW5nIGluICgyKSBhYm91dCDigJxT b3VyY2UgYWRkcmVzc+KAnS4gU291cmNlIENMQVQgSVB2NiBpcyBhIElQdjYgdGhhdCBoYXMgYmVl biBnaXZlbiB0byBDUEUgYXMgYSByZXN1bHQgb2YgREhDUCBQRCAoZnJvbSBDYXJyaWVy4oCZcyBh ZGRyZXNzIHNwYWNlKS4NCkxvb2sgdG8gdGhlIHJlZmVyZW5jZWQgY2hhcHRlcnMgKHRoZXkgYXJl IHNob3J0KTogSVB2NC1FbWJlZGRlZCBJUHY2IEFkZHJlc3Mg4oCTIGNsYXVzZSAyIFJGQyA2MDUy LCBidXQgUkZDIDY4NzcgY2xhdXNlIDYuMyBzdGF0ZXMgdGhhdCBvbmx5IC82NCB2ZXJzaW9uIHNo b3VsZCBiZSB1c2VkDQoNCg0KwrcgICAgICAgIEl0IHNob3VsZCByZXNvbHZlIE5BVC10cmF2ZXJz YWwgaXNzdWVzLCBiZWNhdXNlIElQdjQ6SVB2Nj0xOjEuIEFueSBnbG9iYWwgSVB2NiBjb3VsZCBj b25uZWN0IHRvIHRoaXMgUHJpdmF0ZSBJUHY0IChpdCB3b3VsZCBzZWUgaXQgYXMgSVB2NC1FbWJl ZGRlZCBJUHY2IEFkZHJlc3MpLiBJZiBJUHY2IHBlcnNpc3RlbnQgKHJlY29tbWVuZGVkIGZvciBG QkIpLCB0aGVuIHN1YnNjcmliZXIgY291bGQgb3JnYW5pemUgV2ViIHNlcnZlciBvbiB0aGlzIHBy aXZhdGUgSVB2NCwgaXQgd291bGQgYmUgYXZhaWxhYmxlIGZvciB0aGUgd2hvbGUgSW50ZXJuZXQN CltKb3JkaV0gSSBkb27igJl0IHNlZSB0aGlzLiBJdCBpcyBvbmx5IHBvc3NpYmxlIHVzaW5nIElQ djYsIG5vdCBJUHY0Lg0KW0VkdWFyZF0gSXQgaXMgYmVjYXVzZSB5b3UgaGF2ZSBub3QgdW5kZXJz dG9vZCBwcmV2aW91cyBwb2ludCBhYm91dCBzb3VyY2UgYWRkcmVzcyB0cmFuc2xhdGlvbnMuDQpX ZSBjb3VsZCBwb3RlbnRpYWxseSBleHRlbmQgY3VycmVudCBkcmFmdCBhIGxpdHRsZSBhbmQgcGVy bWl0IGluYm91bmQgY29ubmVjdGlvbi4gSWYgTUFDIGlzIElQdjQgb25seS4gTm8gYW55IEZRRE4g cmVxdWVzdCBuZWVkZWQuIEVBTSByZWNvcmQgY291bGQgYmUgY3JlYXRlZCBqdXN0IG9uIHBhY2tl dCBhcnJpdmFsIGZyb20gdGhlIEludGVybmV0IHdpdGggcHJvcGVyIElQdjQtRW1iZWRkZWQgSVB2 NiBBZGRyZXNzIChwcm9wZXIgSVB2NC1vbmx5IHNob3VsZCBiZSBlbWJlZGRlZCkuDQpJdCBpcyBu b3QgYSBiaWcgc2VjdXJpdHkgaG9sZSBhbnl3YXksIGJlY2F1c2UgYWxsIHN1YnNjcmliZXLigJlz IElQdjYgYWRkcmVzcyBhcmUgRW5kLXRvLWVuZCBhY2Nlc3NpYmxlIGFueXdheSAob3BlbiB0byBw dWJsaWMpLg0KSWYgc2VjdXJpdHkgcGVvcGxlIHdvdWxkIGluc2lzdCAoc3Vic2NyaWJlciBjb3Vs ZCBiZSDigJxzbWFydOKAnSDigJMgY291bGQgbm90IGV4cGVjdCB0aGF0IHB1YmxpYyBJUHY0IGlz IHZpc2libGUgaW4gSVB2NiBpbnRlcm5ldOKYuikg4oCTIHRoaXMgZmVhdHVyZSBtYXkgYmUgZGlz YWJsZWQgYnkgZGVmYXVsdCwgY291bGQgYmUgbWFudWFsbHkgc3dpdGNoZWQgYnkgc3Vic2NyaWJl ciBpcyBoZSB3b3VsZCBsaWtlIHRvIGV4cG9zZSBoaXMgcHJpdmF0ZSBJUHY0IHNlcnZlciB0byBJ UHY2IHB1YmxpYyBpbnRlcm5ldC4NCg0KW0pvcmRpXSBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBn b29kLCBiZWNhdXNlIHRoYXQgd2lsbCBtZWFuIGhhdmluZyBhIGJpZ2dlciBFQU1UIHRoYW4gYWN0 dWFsbHkgbmVlZGVkLiBXZSBuZWVkIHRvIGRlbGV0ZSBlbnRyaWVzIGFzIHNvb24gYXMgcG9zc2li bGUuIFRoZSDigJxzdGFsZeKAnSBzdGF0dXMsIGFzIHN1Z2dlc3RlZCBieSBFcmlrLCByZXNvbHZl cyB0aGUgaXNzdWUuIEFueXdheSwgSSBzdGlsbCBuZWVkIHRvIHRoaW5rIGFuZCB3b3JrIG1vcmUg b24gdGhpcyB0ZXh0Lg0KW0pvcmRpXSBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBnb29kLCBiZWNh dXNlIHRoYXQgd2lsbCBtZWFuIGhhdmluZyBhIGJpZ2dlciBFQU1UIHRoYW4gYWN0dWFsbHkgbmVl ZGVkLiBXZSBuZWVkIHRvIGRlbGV0ZSBlbnRyaWVzIGFzIHNvb24gYXMgcG9zc2libGUuIFRoZSDi gJxzdGFsZeKAnSBzdGF0dXMsIGFzIHN1Z2dlc3RlZCBieSBFcmlrLCByZXNvbHZlcyB0aGUgaXNz dWUuIEFueXdheSwgSSBzdGlsbCBuZWVkIHRvIHRoaW5rIGFuZCB3b3JrIG1vcmUgb24gdGhpcyB0 ZXh0Lg0KW0VkdWFyZF0gSSBoYXZlIHNob3duIHRvIHlvdSBhbHJlYWR5IGluIHNlcGFyYXRlIGNv bW1lbnQgaG93IGJpZyB0cm91YmxlcyB3ZSBjb3VsZCBjcmVhdGUgd2l0aCBhbnkgdGltZXMgKGV2 ZW4gMSB3ZWVrIGxvbmcpLiBOZXZlciB0byBzYXkgYWJvdXQgdGltZXJzIHRha2VuIGZyb20gRE5T Lg0KT0suIFJlZnJlc2ggdGltZXJzIGJ5IHRyYWZmaWMgYXMgSSBoYXZlIHByb3Bvc2VkLiBNYWtl IHN1cmUgdGhhdCBzdGFsZSBpcyByZWFsbHkgc3RhbGUuDQoNCltKb3JkaV0gTm8gbmVlZCBmb3Ig dGhhdC4gV2Ugb25seSBvcHRpbWl6ZSBJUHY0LW9ubHkgaG9zdHMuIEZ1cnRoZXIsIHRyeWluZyB0 byBjaGFuZ2UgSEUgaXMgYSDigJxubyB3YXnigJ0uDQpbRWR1YXJkXSBJIGRpZCBub3QgcHJvcG9z ZSB0byBjaGFuZ2UgSEV2Mi4gSSBoYXZlIHByb3Bvc2VkIHRvIHJlYWQgaXQgY2FyZWZ1bGx5IGFu ZCByZXVzZSBldmVyeXRoaW5nIHBvc3NpYmxlIGluIHRoaXMgZHJhZnQuIEF0IGxlYXN0IHRpbWVy cy4gSWYgd2UgZW11bGF0ZSBJUHY2IGhvc3Qg4oCTIGxldOKAmXMgYmUgYXMgbXVjaCBjb25zaXN0 ZW50IHRvIEhFdjIgYXMgcG9zc2libGUuDQoNCkVkdWFyZA0KRnJvbTogdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSk9SREkgUEFMRVQgTUFSVElORVoN ClNlbnQ6IDE5INC40Y7Qu9GPIDIwMjAg0LMuIDE3OjE5DQpUbzogVjYgT3BzIExpc3QgPHY2b3Bz QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0 LW9wdGltaXphdGlvbi0wMiAtIHNvbWUgZGlzcnVwdGl2ZSBwcm9wb3NhbHMNCg0KSGkgRWR1YXJk LA0KVGtzIGEgbG90IQ0KSSBqdXN0IHNlbnQgYSB0ZW50YXRpdmUgdGV4dCBhcyBwYXJ0IG9mIHRo ZSByZXNwb25zZXMgdG8gUGhpbGlwLiBTZWUgYmVsb3csIGFueXdheS4NCg0KRWwgMTgvNy8yMCA5 OjM3LCAiVmFzaWxlbmtvIEVkdWFyZCIgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxtYWls dG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4gZXNjcmliacOzOg0KDQpIaSBKb3JkaSwN CkkgaGF2ZSBjbGFyaWZpZWQgYSBsaXR0bGUgYmVsb3cuIFVzZSB0aGlzIHZlcnNpb24uDQpFZHVh cmQNCkZyb206IFZhc2lsZW5rbyBFZHVhcmQNClNlbnQ6IDE3INC40Y7Qu9GPIDIwMjAg0LMuIDIz OjI3DQpUbzogJ0pPUkRJIFBBTEVUIE1BUlRJTkVaJyA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwu ZXM8bWFpbHRvOmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPj4NCkNjOiAnVjYgT3BzIExpc3Qn IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3Y2b3Bz XSBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyIC0gc29tZSBkaXNydXB0 aXZlIHByb3Bvc2Fscw0KDQpIaSBKb3JkaSwNClNvcnJ5IHRvIG92ZXJsb2FkIHlvdSBhZ2Fpbi4N Cg0KW0pvcmRpXSBBY3R1YWxseSBhIHBsZWFzdXJlIHRvIGdldCBzbyBtYW55IGdvb2QgaW5wdXRz IQ0KDQpFcmlrIGFuZCBKZW4gd2VyZSByaWdodDogZHJhZnQgZG9lcyBpbnRyb2R1Y2UgbmV3IGF0 dGFjayB2ZWN0b3JzLiBCZWNhdXNlIGhvc3RzIGFyZSDigJxzaGFyaW5nIHNlY3VyaXR5IGZhdGXi gJ0g4oCTIHRoZXkgaGF2ZSBwcm92ZWQgaXQgaW4gbWFueSBleGFtcGxlcy4gTGV04oCZcyBkaXNq b2luIGhvc3RzIGJhY2suDQoNCg0KDQoxLiAgICAgIEkgcHJvcG9zZSB0byBzdG9wIHRoaXMgZ3Vl c3Mtd29yayB3aG8gaXMgSVB2NC1vbmx5IGFuZCB3aG8gaXMgbm90LiBETlMgcXVlcnkgdGltZW91 dCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBIYXBweSBFeWViYWxsIG9mIHBhcnRpY3VsYXIgaG9z dCBpbXBsZW1lbnRhdGlvbiBhbmQgQ0xBVC1ORyAoQ0xBVCBOZXh0IEdlbmVyYXRpb24pIOKAkyBp cyBhIHZlcnkgcmVsaWFibGUgcGF0aCB0byBkaXNhc3Rlci4gV2hhdCBpZiBzb21lYm9keSB3b3Vs ZCBjaGFuZ2UgdGhpcyB0aW1lb3V0IGluIG5leHQgc29mdHdhcmUgcmVsZWFzZT8gV2hhdCBpZiB0 aW1lb3V0IGFyZSB2ZXJ5IGRpZmZlcmVudCBvbiBjdXJyZW50IGhvc3RzPyAoSSBhbSBzdXJlIGFi b3V0IEFuZHJvaWQgYW5kIGlPUyBkaWZmZXJlbmNlKQ0KSSBwcm9wb3NlIGp1c3QgdG8gbG9vayB0 byBORCBhbmQgQVJQIGNhY2hlczogaWYgcGFydGljdWxhciBNQUMgaGFzIG9ubHkgYmluZGluZyB0 byBJUHY0IGFuZCB0aGUgc2FtZSBNQUMgZG9lcyBub3QgaGF2ZSBiaW5kaW5nIHRvIElQdjYsIHRo ZW4gaXQgaXMgb3VyIOKAnG9wdGltaXphdGlvbiBjYXNl4oCdLg0KW0pvcmRpXSBZZXAsIHRoaXMg c2VlbXMgdG8gYmUgYSB2ZXJ5IGdvb2Qgc29sdXRpb24sIGV2ZW4gaWYgaXQgaGFzIGEgZmV3IGRy YXdiYWNrcywgaXMgYSBnb29kIHRyYWRlLW9mZi4NCg0KDQoyLiAgICAgIE5BUFQ0NCBkb2VzIGdl bmVyYXRlIG1hbnkgaXNzdWVzIHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIG9uIHRoaXMgbWFpbGlu ZyBsaXN0Lg0KSSBwcm9wb3NlIHRvIHJldHVybiB0byBzdGF0ZWxlc3MgbmF0dXJlIG9mIENMQVQg dHJhbnNsYXRpb24uIExldOKAmXMgY3JlYXRlIHNlcGFyYXRlIEVBTVQgdGFibGUgcGVyIGV2ZXJ5 IElQdjQtb25seSBob3N0ICh0aGF0IGhhcyBiZWVuIGRpc2NvdmVyZWQgYXMgZWxpZ2libGUgb24g dGhlIHByZXZpb3VzIHN0ZXAgb2YgY2FjaGUgY29tcGFyaXNvbikuDQpUaGVuIHRyYW5zbGF0ZSBp dCBhcyB0b2RheSBmb3IgQ0xBVCAoSVB2NC1FbWJlZGRlZCBJUHY2IEFkZHJlc3Mg4oCTIGNsYXVz ZSAyIFJGQyA2MDUyLCBidXQgUkZDIDY4NzcgY2xhdXNlIDYuMyBzdGF0ZXMgdGhhdCBvbmx5IC82 NCB2ZXJzaW9uIHNob3VsZCBiZSB1c2VkKS4NCldlIGNvdWxkIHJldXNlIGV4YWN0bHkgdGhlIHNh bWUgSVB2NiBhZGRyZXNzIHRoYXQgd2UgYXJlIHVzaW5nIG5vdyBmb3IgdHJhZmZpYyB0byBQTEFU IGFuZCBwcmVwYXJlIGl0IGJ5IGV4YWN0bHkgdGhlIHNhbWUgcnVsZXMuDQpbSm9yZGldIE5vdCBz dXJlIGlmIEkgZ290IGl0IGNvcnJlY3RseS4gSSBkb27igJl0IHRoaW5rIHNvLiBJZiB3ZSB1c2Ug dGhlIGFkZHJlc3NlcyBhcyBpbiBhIG5vbi1vcHRpbWl6ZWQgQ0xBVCwgdGhleSBhcmUgc3ludGhl dGl6ZWQsIHNvIHRoZXkgd2lsbCBuYXR1cmFsbHkgZm9sbG93IHRoZSBQTEFUIHBhdGgg4oCTIHRo aXMgaXMgd2hhdCB3ZSB0cnkgdG8gYXZvaWQuIFRoZSBJUHY2IHNvdXJjZSBhZGRyZXNzIGFmdGVy IHRoZSBDTEFUIGlzIG5vdCByZWxldmFudCBmb3IgdGhlIG9wdGltaXphdGlvbiAobm8gaW1wYWN0 KS4NCg0KSVB2NCBzb3VyY2Ugd291bGQgYmUgdmlzaWJsZSAoaW5zaWRlIElQdjYgc291cmNlKSwg YnV0IHRyYWNraW5nIHdvdWxkIGJlIGRpZmZpY3VsdCBiZWNhdXNlIHdvdWxkIGJlIG1pbGxpb25z IG9mIHN1Y2ggMTkyLjE2OC4xLnguIEkgZG8gbm90IGJlbGlldmUgdGhhdCBhbnkgcmFuZG9taXph dGlvbiBpcyBuZWVkZWQgKGNvdWxkIGJlIGFkZGVkIGlmIHNvbWVib2R5IHdvdWxkIGluc2lzdCku DQpUZWNobmljYWxseSwgaXQgY291bGQgYmUgb25lIEVBTVQsIGp1c3QgaXQgc2hvdWxkIGhhdmUg c291cmNlIElQdjQgYXMgdGhlIGtleSBmaWVsZC4gRUFNIHRhYmxlIGRvZXMgbm90IG5lZWQgSVB2 NCBwcmVmaXggKG9mIExBTiBzdWJuZXQpLg0KQ0xBVCB0cmFuc2xhdGlvbiB3b3VsZCBiZWNvbWUg c3RhdGVsZXNzIGFnYWluLiBCdXQgaW4gZ2VuZXJhbCBDTEFUIHdvdWxkIGJlIHN0YXRlZnVsLCBi ZWNhdXNlIGRlY2lzaW9uIGFib3V0IGRlc3RpbmF0aW9uIElQdjYgKFBMQVQgb3IgcmVhbCBJbnRl cm5ldCByZXNvdXJjZSkgc2hvdWxkIGJlIGRvbmUgYWxtb3N0IHBlci1mbG93IChmb3Igc291cmNl IElQdjQgKyBkZXN0aW5hdGlvbiBJUHY0KSB0aGF0IHdhcyBsdWNreSB0byBjcmVhdGUgYSBzdGF0 ZSBpbiBFQU1ULg0KDQpbSm9yZGldIEV4YWN0bHkuIFdlIG5lZWQgc3RhdGUgYmVjYXVzZSB3ZSBu ZWVkIHRvIOKAnGRpc2Nvbm5lY3TigJ0gdGhlIEROUyBUVExzIGZvcm0gdGhlIGhvc3RzIGFwcGxp Y2F0aW9ucyBjb25uZWN0aW9ucy4NCg0KDQozLiAgICAgIFRoZSB3YXkgaG93IHdlIHdvdWxkIHNl YXJjaCBmb3IgcHJvcGVyIGRlc3RpbmF0aW9uIElQdjYg4oCTIHdlIGNvdWxkIGtlZXAgYXMgaXQg aXMgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKHF1ZXJ5IGJ5IHByb3h5IERO UywganVzdCBpdCB3b3VsZCBiZSBwZXJzb25hbCBxdWVyeSBmb3IgZXZlcnkgaG9zdCkuDQpXZSBj b3VsZCByZXVzZSBub3cgSGFwcHkgRXllYmFsbCAoUkZDIDgzMDUpIGZvciBkb3VibGUgRE5TIHJl cXVlc3RzIHdpdGggYWxsIGFzc29jaWF0ZWQgdGltZXJzLCBiZWNhdXNlIEZRRE4gcmVxdWVzdCBp cyBwZXJzb25hbCBub3cgKGp1c3QgZm9yIG9uZSBBcHAgb2Ygb25lIEhvc3QpLiBQYXJ0IG9mIEhF djIgY291bGQgYmUgb24gcHJveHkgQ1BFIChvbiBiZWhhbGYgb2YgSVB2NCBob3N0KS4NCltKb3Jk aV0gTm8gbmVlZCBmb3IgdGhhdC4gV2Ugb25seSBvcHRpbWl6ZSBJUHY0LW9ubHkgaG9zdHMuIEZ1 cnRoZXIsIHRyeWluZyB0byBjaGFuZ2UgSEUgaXMgYSDigJxubyB3YXnigJ0uDQoNCg0KNC4gICAg ICBJZiBETlMgKHRvZ2V0aGVyIHdpdGggRUFNIHJlY29yZCkgd291bGQgZXhwaXJlLCBidXQgaG9z dCB3b3VsZCBub3QgcGF5IGF0dGVudGlvbiB0byBETlMgVFRMIChhcHBsaWNhdGlvbiBkb2VzIG5v dCB3YW50IHRvIGludGVycnVwdCB1c2VyIHNlc3Npb24g4oCTIHRoYXQgaXMgcHJvcGVyIGJlaGF2 aW9yKSwgdGhlbiBob3N0IGNvdWxkIGluaXRpYXRlIG5ldyBFQU0gcmVjb3JkIHRoYXQgY291bGQg YmUgcmVzb2x2ZWQgdG8gZGlmZmVyZW50IElQdjYuIEl0IGlzIG5vdCBnb29kIGlkZWEgdG8gc29s dmUgdGhpcyBwcm9ibGVtIGJ5IHRpbWVycy4NCkkgcHJvcG9zZSB0byB1c2UgRUFNIHJlY29yZHMg Zm9yZXZlciAoZG8gbm90IHBheSBhdHRlbnRpb24gdG8gRE5TIFRUTCB0aW1lciksIEVBTSByZWNv cmQgc2hvdWxkIGJlIGRlbGV0ZWQgb25seSBpZiAoMSkgaG9zdCB3b3VsZCBhc2sgYWdhaW4gZm9y IHRoZSBzYW1lIEZRRE4sIG9yICgyKSBBUlAgZW50cnkgd291bGQgYmUgZGVsZXRlZCDigJMgdGhl biBhbGwgRUFNIGVudHJpZXMgcmVsYXRlZCB0byB0aGlzIGhvc3Qgc2hvdWxkIGJlIGRlbGV0ZWQg KGluIHRoZSBjYXNlIG9mIHN0YXRpYyBBUlAgaXQgbWVhbnMg4oCTICAoMikgd291bGQgbmV2ZXIg aGFwcGVuKS4NCldlIHdvdWxkIHJlcGxpY2F0ZSBob3N0IGJlaGF2aW9yOiBpZiBoZSB3b3VsZCBh c2sg4oCTIHdlIHdvdWxkIHJlZnJlc2gsIGlmIGhlIGRvZXMgdmlvbGF0ZSBwcm90b2NvbCDigJMg d2Ugd291bGQgZG8gdGhlIHNhbWUgKGZvciBoaW0pLiBXZSBzaG91bGQgYmUgdHJhbnNwYXJlbnQg Zm9yIGhpbS4NCltKb3JkaV0gSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgZ29vZCwgYmVjYXVzZSB0 aGF0IHdpbGwgbWVhbiBoYXZpbmcgYSBiaWdnZXIgRUFNVCB0aGFuIGFjdHVhbGx5IG5lZWRlZC4g V2UgbmVlZCB0byBkZWxldGUgZW50cmllcyBhcyBzb29uIGFzIHBvc3NpYmxlLiBUaGUg4oCcc3Rh bGXigJ0gc3RhdHVzLCBhcyBzdWdnZXN0ZWQgYnkgRXJpaywgcmVzb2x2ZXMgdGhlIGlzc3VlLiBB bnl3YXksIEkgc3RpbGwgbmVlZCB0byB0aGluayBhbmQgd29yayBtb3JlIG9uIHRoaXMgdGV4dC4N Cg0KR29vZCB0aGluZ3M6DQoNCsK3ICAgICAgICBJdCBzaG91bGQgcmVzb2x2ZSBOQVQtdHJhdmVy c2FsIGlzc3VlcywgYmVjYXVzZSBJUHY0OklQdjY9MToxLiBBbnkgZ2xvYmFsIElQdjYgY291bGQg Y29ubmVjdCB0byB0aGlzIFByaXZhdGUgSVB2NCAoaXQgd291bGQgc2VlIGl0IGFzIElQdjQtRW1i ZWRkZWQgSVB2NiBBZGRyZXNzKS4gSWYgSVB2NiBwZXJzaXN0ZW50IChyZWNvbW1lbmRlZCBmb3Ig RkJCKSwgdGhlbiBzdWJzY3JpYmVyIGNvdWxkIG9yZ2FuaXplIFdlYiBzZXJ2ZXIgb24gdGhpcyBw cml2YXRlIElQdjQsIGl0IHdvdWxkIGJlIGF2YWlsYWJsZSBmb3IgdGhlIHdob2xlIEludGVybmV0 DQpbSm9yZGldIEkgZG9u4oCZdCBzZWUgdGhpcy4gSXQgaXMgb25seSBwb3NzaWJsZSB1c2luZyBJ UHY2LCBub3QgSVB2NC4NCg0KDQrCtyAgICAgICAgTm8gcG9zc2liaWxpdHkgZm9yIG9uZSBJUHY0 IGhvc3QgdG8gaGlqYWNrIGNvbm5lY3Rpb24gb2Ygb3RoZXIgSVB2NCBob3N0IChpbmNsdWRpbmcg dGhlIHNpdHVhdGlvbiB3aGVuIG9uZSBob3N0IHBvaW50ZWQgdG8gZm9yZWlnbiBETlMg4oCTIGhp cyBGUUROIHJlcXVlc3Qgd291bGQgYmUganVzdCBub3QgdmlzaWJsZSDigJMgRUFNIHJlY29yZCBm b3IgaGltIHdvdWxkIG5vdCBiZSBjcmVhdGVkKQ0KDQrCtyAgICAgICAgSWYgYW55IHN0cmFuZ2Ug Y29uZmlndXJhdGlvbiBvbiBzZXJ2ZXIgc2lkZSAoVExTIFNOSSBkZW11eCBhZ2FpbnN0IElQdjYg YWRkcmVzcyBkZW11eCwgSVB2NCBvbmx5IHNlcnZlciBzaGFyZSBBIHJlY29yZCB3aXRoIER1YWxT dGFjayBzZXJ2ZXIsIGNsZXZlciBDRE4gY2x1c3RlcnMgY29uZmlndXJhdGlvbiAtIG1hbnkgcHJl c2VudGVkIGJ5IEVyaWspIOKAkyB0aGVuIGNsaWVudCB3b3VsZCBiZWhhdmUgbGlrZSBzaW5nbGUg ZHVhbCBzdGFjayBjbGllbnQuIElmIHN1Y2ggY2xpZW50IHdvdWxkIG5vdCBiZSBzZXJ2ZWQgcHJv cGVybHkg4oCTIHRoZW4gU2VydmVyIG93bmVyIHdvdWxkIGhhdmUgYSBiaWcgdHJvdWJsZSBhbnl3 YXksIGJlY2F1c2UgbWFueSBvdGhlciBEdWFsU3RhY2sgY2xpZW50IHdvcmxkLXdpZGUNCg0Kwrcg ICAgICAgIElmIEROUyB3b3VsZCByZXNvbHZlIHRvIEFBQUEsIGJ1dCBubyBJUCBjb25uZWN0aXZp dHkg4oCTIHRoZW4gYWdhaW46IG90aGVyIER1YWxTdGFjayBjbGllbnRzIHdvdWxkIGhhdmUgdGhl IGJpZyB0cm91YmxlDQoNCsK3ICAgICAgICBQYXJ0aWN1bGFyIEVBTVQgcmVjb3JkIGNvdWxkIHN0 aWNrIHRvIG9ubHkgMSBkZXN0aW5hdGlvbiBJUHY2IGFkZHJlc3MsIGRlc3BpdGUgRE5TIExvYWQg QmFsYW5jaW5nLCBidXQgaXQgd291bGQgYmUgZXhhY3RseSB0aGUgc2FtZSBpZiBob3N0IHdvdWxk IGFzayBieSBpdHNlbGYsIG91ciBDTEFULU5HIGlzIHRyYW5zcGFyZW50IGFuZCBwZXJzb25hbA0K DQrCtyAgICAgICAgSWYgdXNlciB3b3VsZCBtb2RpZnkgRE5TIG9uIENQRSDigJMgaXQgaXMgZmlu ZSDigJMgd2Ugd291bGQgdHJ5IHRvIGdldCBBQUFBIGZyb20gRE5TIHNlcnZlciBwcmVmZXJyZWQg YnkgaGltLiBObyBBQUFBIGFuc3dlciAtPiBubyBFQU0gcmVjb3JkIC0+IHRyYWZmaWMgd291bGQg Z28gdG8gUExBVCAtPiBubyBwcm9ibGVtDQoNCsK3ICAgICAgICBETlMgcG9pc29uaW5nIHdvdWxk IGFmZmVjdCBvbmx5IDEgaG9zdCDigJMgZXhhY3RseSB0aGUgc2FtZSBzaXR1YXRpb24gYXMgd2l0 aG91dCBhbnkgb3B0aW1pemF0aW9uDQoNCsK3ICAgICAgICBJIGRvIG5vdCBzZWUgYW55IHByb2Js ZW0gd2l0aCBETlNTRUMgdG9vIOKAkyBpdCBjb3VsZCBhZGRpdGlvbmFsbHkgY2hlY2sgRE5TIGFu c3dlcnMNCg0KQ3VycmVudGx5IGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQgKGFuZCBub3QgZml4ZWQp Og0KDQrCtyAgICAgICAgT25seSBJUHY2IGJhY2tib25lIGlzIGRvd24gb3IgbGluayBkZWdyYWRl ZCAoSVB2NCBpcyBmaW5lKSwtIGJ1dCB3ZSBwdXNoIHRyYWZmaWMgdG8gSVB2NiBvbmx54pi5DQoN Ck9uZSB2aXNpYmxlIHJlc3RyaWN0aW9uOg0KDQrCtyAgICAgICAgSWYgc3Vic2NyaWJlciB3b3Vs ZCBoYXZlIGJpZyByb3V0ZWQgbmV0d29yayBpbnNpZGUsIHRoZW4gQVJQIGVudHJ5IHdvdWxkIG5v dCBiZSB2aXNpYmxlIG9uIENQRS4gTmV4dCBob3Agcm91dGVyIHdvdWxkIGJlIER1YWwgU3RhY2su IEluIHN1Y2ggY2FzZTogRUFNVCBlbnRyeSB3b3VsZCBub3QgYmUgY3JlYXRlZCDigJMgdHJhZmZp YyB3b3VsZCBnbyB0byBQTEFUDQoNCltKb3JkaV0geWVzIHRvIGFsbCB0aG9zZSBwb2ludHMNCg0K SSBoYXZlIGxvb2tlZCBjYXJlZnVsbHkgdG8gYWxsIGNvbW1lbnRzIG9mIEplbiwgRXJpaywgYW5k IFBoaWxpcCBhZ2Fpbi4gSSBoYXZlIG5vdCBmb3VuZCBhbnkgaG9sZXMgbGVmdC4gUHJpbWFyaWx5 LCBiZWNhdXNlIGluIHRoaXMgcHJvcG9zYWwgd2UgYXJlIG1pbWlja2luZyBob3N0cyBpbmRpdmlk dWFsbHkg4oCTIHdlIGFyZSBqdXN0IOKAnGZ1bGx5IHRyYW5zcGFyZW50IGluIGJvdGggZGlyZWN0 aW9uc+KAnS4NCg0KW0pvcmRpXSBJ4oCZbSByZS1yZWFkaW5nIGFueXdheSwgZXZlcnl0aGluZyBh bmQgbWFraW5nIHN1cmUgd2UgYXJlbuKAmXQgbWlzc2luZyBhbnkgaXNzdWUgYmVmb3JlIHNlbmRp bmcgYSBuZXcgdmVyc2lvbiDigKYNCg0KDQpFZHVhcmQNCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZv ciB0aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQpUaGUg SVB2NiBDb21wYW55DQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0 aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVk IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRz IG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNo ZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBh IGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVz ZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHks IGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBi ZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhl IG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBk ZWxldGUgaXQuDQo= --_000_1b57ee72a7ad41058a72abe8254c3b96huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTo4LjBwdDsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbXNv LWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNSU7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhD eFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdy YXBoQ3hTcEZpcnN0DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNSU7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWxpbmUtaGVpZ2h0OjEwNSU7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0 LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN Cgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206OC4wcHQ7DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1zby1hZGQtc3BhY2U6YXV0bzsNCglsaW5lLWhlaWdodDoxMDUlOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjE5MTcxMTcyOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDY2MzQzNzEyIDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjE2MTgwMjEzNjE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xMDQ5NzQ5MjEyIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyDQoJe21zby1saXN0LWlkOjIwMzM5OTMzNTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjIxMzM0NTIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBKb3JkaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bSm9yZGldIE5vdCBzdXJlIGlmIEkgZ290IGl0IGNvcnJl Y3RseS4gSSBkb27igJl0IHRoaW5rIHNvLiBJZiB3ZSB1c2UgdGhlIGFkZHJlc3NlcyBhcyBpbiBh IG5vbi1vcHRpbWl6ZWQgQ0xBVCwgdGhleSBhcmUgc3ludGhldGl6ZWQsIHNvIHRoZXkgd2lsbCBu YXR1cmFsbHkgZm9sbG93IHRoZSBQTEFUIHBhdGgg4oCTIHRoaXMgaXMgd2hhdA0KIHdlIHRyeSB0 byBhdm9pZC4gVGhlIElQdjYgc291cmNlIGFkZHJlc3MgYWZ0ZXIgdGhlIENMQVQgaXMgbm90IHJl bGV2YW50IGZvciB0aGUgb3B0aW1pemF0aW9uIChubyBpbXBhY3QpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0VkdWFyZF0gWW91IGFy ZSB0aGlua2luZyBhYm91dCBkZXN0aW5hdGlvbiBJUHY2IOKAkyB5b3UgYXJlIGRlYWxpbmcgd2l0 aCBpdCBieSBETlMgcmVxdWVzdC4gSSBoYXZlIHNob3duIHRvIHlvdSBhbHJlYWR5IGluIG1hbnkg ZGlzY3Vzc2lvbnMgdGhhdCBJIGFtIHRoaW5raW5nIGFib3V0IHNvdXJjZSB0b28uDQogU3RhdGVm dWwgYWdhaW5zdCBzdGF0ZWxlc3Mg4oCTIGl0IGlzIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB3YXMgdGFsa2luZyBp biAoMikgYWJvdXQg4oCcU291cmNlIGFkZHJlc3PigJ0uIFNvdXJjZSBDTEFUIElQdjYgaXMgYSBJ UHY2IHRoYXQgaGFzIGJlZW4gZ2l2ZW4gdG8gQ1BFIGFzIGEgcmVzdWx0IG9mIERIQ1AgUEQgKGZy b20gQ2FycmllcuKAmXMgYWRkcmVzcyBzcGFjZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Mb29rIHRvIHRoZSByZWZlcmVuY2VkIGNo YXB0ZXJzICh0aGV5IGFyZSBzaG9ydCk6DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4iPklQdjQt RW1iZWRkZWQgSVB2NiBBZGRyZXNzIOKAkyBjbGF1c2UgMiBSRkMgNjA1MiwgYnV0IFJGQyA2ODc3 IGNsYXVzZSA2LjMgc3RhdGVzIHRoYXQgb25seSAvNjQgdmVyc2lvbiBzaG91bGQgYmUgdXNlZDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdDttc28tYWRkLXNwYWNlOmF1dG87dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj5JdCBzaG91bGQgcmVzb2x2ZSBOQVQt dHJhdmVyc2FsIGlzc3VlcywgYmVjYXVzZSBJUHY0OklQdjY9MToxLiBBbnkgZ2xvYmFsIElQdjYg Y291bGQgY29ubmVjdCB0byB0aGlzIFByaXZhdGUgSVB2NCAoaXQgd291bGQgc2VlIGl0IGFzIElQ djQtRW1iZWRkZWQgSVB2NiBBZGRyZXNzKS4gSWYgSVB2Ng0KIHBlcnNpc3RlbnQgKHJlY29tbWVu ZGVkIGZvciBGQkIpLCB0aGVuIHN1YnNjcmliZXIgY291bGQgb3JnYW5pemUgV2ViIHNlcnZlciBv biB0aGlzIHByaXZhdGUgSVB2NCwgaXQgd291bGQgYmUgYXZhaWxhYmxlIGZvciB0aGUgd2hvbGUg SW50ZXJuZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPltKb3JkaV0gSSBkb27igJl0IHNlZSB0aGlzLiBJdCBpcyBvbmx5 IHBvc3NpYmxlIHVzaW5nIElQdjYsIG5vdCBJUHY0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bRWR1YXJkXSBJdCBpcyBiZWNhdXNlIHlvdSBoYXZl IG5vdCB1bmRlcnN0b29kIHByZXZpb3VzIHBvaW50IGFib3V0IHNvdXJjZSBhZGRyZXNzIHRyYW5z bGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPldlIGNvdWxkIHBvdGVudGlhbGx5IGV4dGVuZCBjdXJyZW50IGRyYWZ0IGEgbGl0 dGxlIGFuZCBwZXJtaXQgaW5ib3VuZCBjb25uZWN0aW9uLiBJZiBNQUMgaXMgSVB2NCBvbmx5LiBO byBhbnkgRlFETiByZXF1ZXN0IG5lZWRlZC4gRUFNIHJlY29yZCBjb3VsZCBiZSBjcmVhdGVkIGp1 c3Qgb24gcGFja2V0IGFycml2YWwNCiBmcm9tIHRoZSBJbnRlcm5ldCB3aXRoIHByb3BlciBJUHY0 LUVtYmVkZGVkIElQdjYgQWRkcmVzcyAocHJvcGVyIElQdjQtb25seSBzaG91bGQgYmUgZW1iZWRk ZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SXQgaXMgbm90IGEgYmlnIHNlY3VyaXR5IGhvbGUgYW55d2F5LCBiZWNhdXNlIGFsbCBz dWJzY3JpYmVy4oCZcyBJUHY2IGFkZHJlc3MgYXJlIEVuZC10by1lbmQgYWNjZXNzaWJsZSBhbnl3 YXkgKG9wZW4gdG8gcHVibGljKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHNlY3VyaXR5IHBlb3BsZSB3b3VsZCBpbnNpc3QgKHN1 YnNjcmliZXIgY291bGQgYmUg4oCcc21hcnTigJ0g4oCTIGNvdWxkIG5vdCBleHBlY3QgdGhhdCBw dWJsaWMgSVB2NCBpcyB2aXNpYmxlIGluIElQdjYgaW50ZXJuZXQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+KQ0KIOKAkyB0aGlzIGZlYXR1cmUgbWF5IGJlIGRpc2FibGVkIGJ5IGRlZmF1bHQsIGNvdWxk IGJlIG1hbnVhbGx5IHN3aXRjaGVkIGJ5IHN1YnNjcmliZXIgaXMgaGUgd291bGQgbGlrZSB0byBl eHBvc2UgaGlzIHByaXZhdGUgSVB2NCBzZXJ2ZXIgdG8gSVB2NiBwdWJsaWMgaW50ZXJuZXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bSm9yZGld Jm5ic3A7SSBkb27igJl0IHRoaW5rIHRoaXMgaXMgZ29vZCwgYmVjYXVzZSB0aGF0IHdpbGwgbWVh biBoYXZpbmcgYSBiaWdnZXIgRUFNVCB0aGFuIGFjdHVhbGx5IG5lZWRlZC4gV2UgbmVlZCB0byBk ZWxldGUgZW50cmllcyBhcyBzb29uIGFzIHBvc3NpYmxlLiBUaGUg4oCcc3RhbGXigJ0gc3RhdHVz LCBhcyBzdWdnZXN0ZWQgYnkgRXJpaywNCiByZXNvbHZlcyB0aGUgaXNzdWUuIEFueXdheSwgSSBz dGlsbCBuZWVkIHRvIHRoaW5rIGFuZCB3b3JrIG1vcmUgb24gdGhpcyB0ZXh0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltKb3JkaV0mbmJzcDtJIGRvbuKAmXQg dGhpbmsgdGhpcyBpcyBnb29kLCBiZWNhdXNlIHRoYXQgd2lsbCBtZWFuIGhhdmluZyBhIGJpZ2dl ciBFQU1UIHRoYW4gYWN0dWFsbHkgbmVlZGVkLiBXZSBuZWVkIHRvIGRlbGV0ZSBlbnRyaWVzIGFz IHNvb24gYXMgcG9zc2libGUuIFRoZSDigJxzdGFsZeKAnSBzdGF0dXMsIGFzIHN1Z2dlc3RlZCBi eSBFcmlrLA0KIHJlc29sdmVzIHRoZSBpc3N1ZS4gQW55d2F5LCBJIHN0aWxsIG5lZWQgdG8gdGhp bmsgYW5kIHdvcmsgbW9yZSBvbiB0aGlzIHRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bRWR1YXJkXSBJIGhhdmUgc2hvd24gdG8g eW91IGFscmVhZHkgaW4gc2VwYXJhdGUgY29tbWVudCBob3cgYmlnIHRyb3VibGVzIHdlIGNvdWxk IGNyZWF0ZSB3aXRoIGFueSB0aW1lcyAoZXZlbiAxIHdlZWsgbG9uZykuIE5ldmVyIHRvIHNheSBh Ym91dCB0aW1lcnMgdGFrZW4gZnJvbSBETlMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PSy4gUmVmcmVzaCB0aW1lcnMgYnkgdHJhZmZp YyBhcyBJIGhhdmUgcHJvcG9zZWQuIE1ha2Ugc3VyZSB0aGF0IHN0YWxlIGlzIHJlYWxseSBzdGFs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+W0pvcmRpXSBObyBuZWVkIGZvciB0aGF0LiBXZSBvbmx5IG9wdGltaXpl IElQdjQtb25seSBob3N0cy4gRnVydGhlciwgdHJ5aW5nIHRvIGNoYW5nZSBIRSBpcyBhIOKAnG5v IHdheeKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+W0VkdWFyZF0gSSBkaWQgbm90IHByb3Bvc2UgdG8gY2hhbmdlIEhFdjIuIEkgaGF2ZSBwcm9w b3NlZCB0byByZWFkIGl0IGNhcmVmdWxseSBhbmQgcmV1c2UgZXZlcnl0aGluZyBwb3NzaWJsZSBp biB0aGlzIGRyYWZ0LiBBdCBsZWFzdCB0aW1lcnMuIElmIHdlIGVtdWxhdGUgSVB2NiBob3N0IOKA kyBsZXTigJlzIGJlDQogYXMgbXVjaCBjb25zaXN0ZW50IHRvIEhFdjIgYXMgcG9zc2libGUuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpPUkRJIFBB TEVUIE1BUlRJTkVaPGJyPg0KPGI+U2VudDo8L2I+IDE5INC40Y7Qu9GPIDIwMjAg0LMuIDE3OjE5 PGJyPg0KPGI+VG86PC9iPiBWNiBPcHMgTGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRp bWl6YXRpb24tMDIgLSBzb21lIGRpc3J1cHRpdmUgcHJvcG9zYWxzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRVMtVFJBRCIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgRWR1YXJkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGtzIGEg bG90ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SSBqdXN0IHNlbnQgYSB0ZW50YXRpdmUgdGV4dCBhcyBwYXJ0 IG9mIHRoZSByZXNwb25zZXMgdG8gUGhpbGlwLiBTZWUgYmVsb3csIGFueXdheS48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyI+RWwg MTgvNy8yMCA5OjM3LCAmcXVvdDtWYXNpbGVua28gRWR1YXJkJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tIj52YXNpbGVua28uZWR1YXJkQGh1YXdl aS5jb208L2E+Jmd0OyBlc2NyaWJpw7M6PC9zcGFuPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJFUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEpvcmRpLDwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IGhhdmUgY2xhcmlmaWVkIGEgbGl0dGxlIGJlbG93LiBVc2UgdGhpcyB2ZXJzaW9uLjwvc3Bhbj48 c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5FZHVhcmQ8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48Yj48c3BhbiBsYW5nPSJFUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFZhc2ls ZW5rbyBFZHVhcmQNCjxicj4NCjxiPlNlbnQ6PC9iPiAxNyDQuNGO0LvRjyAyMDIwINCzLiAyMzoy Nzxicj4NCjxiPlRvOjwvYj4gJ0pPUkRJIFBBTEVUIE1BUlRJTkVaJyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzIj5qb3JkaS5wYWxldEBjb25zdWxpbnRlbC5l czwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAnVjYgT3BzIExpc3QnICZsdDs8YSBocmVmPSJtYWls dG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyIC0g c29tZSBkaXNydXB0aXZlIHByb3Bvc2Fsczwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SGkgSm9yZGksPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+U29ycnkgdG8gb3ZlcmxvYWQgeW91IGFnYWluLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bSm9yZGldIEFjdHVhbGx5IGEgcGxlYXN1 cmUgdG8gZ2V0IHNvIG1hbnkgZ29vZCBpbnB1dHMhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVyaWsgYW5k IEplbiB3ZXJlIHJpZ2h0OiBkcmFmdCBkb2VzIGludHJvZHVjZSBuZXcgYXR0YWNrIHZlY3RvcnMu IEJlY2F1c2UgaG9zdHMgYXJlIOKAnHNoYXJpbmcgc2VjdXJpdHkgZmF0ZeKAnSDigJMgdGhleSBo YXZlIHByb3ZlZCBpdCBpbiBtYW55IGV4YW1wbGVzLiBMZXTigJlzDQogZGlzam9pbiBob3N0cyBi YWNrLjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQ7 bXNvLWFkZC1zcGFjZTphdXRvIj4NCjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtsaW5lLWhlaWdodDoxMDUlIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QiIHN0 eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQ7bXNvLWFkZC1zcGFjZTphdXRvO3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+SSBwcm9wb3Nl IHRvIHN0b3AgdGhpcyBndWVzcy13b3JrIHdobyBpcyBJUHY0LW9ubHkgYW5kIHdobyBpcyBub3Qu IEROUyBxdWVyeSB0aW1lb3V0IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIEhhcHB5IEV5ZWJhbGwg b2YgcGFydGljdWxhciBob3N0IGltcGxlbWVudGF0aW9uIGFuZCBDTEFULU5HDQogKENMQVQgTmV4 dCBHZW5lcmF0aW9uKSDigJMgaXMgYSB2ZXJ5IHJlbGlhYmxlIHBhdGggdG8gZGlzYXN0ZXIuIFdo YXQgaWYgc29tZWJvZHkgd291bGQgY2hhbmdlIHRoaXMgdGltZW91dCBpbiBuZXh0IHNvZnR3YXJl IHJlbGVhc2U/IFdoYXQgaWYgdGltZW91dCBhcmUgdmVyeSBkaWZmZXJlbnQgb24gY3VycmVudCBo b3N0cz8gKEkgYW0gc3VyZSBhYm91dCBBbmRyb2lkIGFuZCBpT1MgZGlmZmVyZW5jZSk8YnI+DQo8 Yj5JIHByb3Bvc2UganVzdCB0byBsb29rIHRvIE5EIGFuZCBBUlAgY2FjaGVzOiBpZiBwYXJ0aWN1 bGFyIE1BQyBoYXMgb25seSBiaW5kaW5nIHRvIElQdjQgYW5kIHRoZSBzYW1lIE1BQyBkb2VzIG5v dCBoYXZlIGJpbmRpbmcgdG8gSVB2NiwgdGhlbiBpdCBpcyBvdXIg4oCcb3B0aW1pemF0aW9uIGNh c2XigJ0uPC9iPjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+W0pvcmRpXSBZZXAsIHRoaXMgc2VlbXMgdG8gYmUgYSB2ZXJ5 IGdvb2Qgc29sdXRpb24sIGV2ZW4gaWYgaXQgaGFzIGEgZmV3IGRyYXdiYWNrcywgaXMgYSBnb29k IHRyYWRlLW9mZi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0O21zby1hZGQtc3BhY2U6YXV0bzt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIGxhbmc9IkVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPk5BPGI+ UDwvYj5UNDQgZG9lcyBnZW5lcmF0ZSBtYW55IGlzc3VlcyB0aGF0IGhhcyBiZWVuIGRpc2N1c3Nl ZCBvbiB0aGlzIG1haWxpbmcgbGlzdC48YnI+DQo8Yj5JIHByb3Bvc2UgdG8gcmV0dXJuIHRvIHN0 YXRlbGVzcyBuYXR1cmUgb2YgQ0xBVCA8c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+dHJhbnNs YXRpb248L3NwYW4+LiBMZXTigJlzIGNyZWF0ZSBzZXBhcmF0ZSBFQU1UIHRhYmxlIHBlciBldmVy eSBJUHY0LW9ubHkgaG9zdA0KPC9iPih0aGF0IGhhcyBiZWVuIGRpc2NvdmVyZWQgYXMgZWxpZ2li bGUgb24gdGhlIHByZXZpb3VzIHN0ZXAgb2YgY2FjaGUgY29tcGFyaXNvbikuPGI+PGJyPg0KVGhl biB0cmFuc2xhdGUgaXQgYXMgdG9kYXkgZm9yIENMQVQgKDwvYj48L3NwYW4+PGI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPklQdjQtRW1i ZWRkZWQgSVB2NiBBZGRyZXNzIOKAkyBjbGF1c2UgMiBSRkMgNjA1MiwgYnV0IFJGQyA2ODc3IGNs YXVzZSA2LjMgc3RhdGVzIHRoYXQgb25seSAvNjQgdmVyc2lvbiBzaG91bGQgYmUgdXNlZDwvc3Bh bj48L2I+PGI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVp Z2h0OjEwNSUiPikuPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+PGJyPg0KV2UgY291bGQgcmV1c2UgZXhhY3RseSB0aGUg c2FtZSBJUHY2IGFkZHJlc3MgdGhhdCB3ZSBhcmUgdXNpbmcgbm93IGZvciB0cmFmZmljIHRvIFBM QVQgYW5kIHByZXBhcmUgaXQgYnkgZXhhY3RseSB0aGUgc2FtZSBydWxlcy48L3NwYW4+PHNwYW4g bGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltK b3JkaV0gTm90IHN1cmUgaWYgSSBnb3QgaXQgY29ycmVjdGx5LiBJIGRvbuKAmXQgdGhpbmsgc28u IElmIHdlIHVzZSB0aGUgYWRkcmVzc2VzIGFzIGluIGEgbm9uLW9wdGltaXplZCBDTEFULCB0aGV5 IGFyZSBzeW50aGV0aXplZCwgc28gdGhleSB3aWxsIG5hdHVyYWxseSBmb2xsb3cgdGhlIFBMQVQg cGF0aCDigJMgdGhpcyBpcyB3aGF0DQogd2UgdHJ5IHRvIGF2b2lkLiBUaGUgSVB2NiBzb3VyY2Ug YWRkcmVzcyBhZnRlciB0aGUgQ0xBVCBpcyBub3QgcmVsZXZhbnQgZm9yIHRoZSBvcHRpbWl6YXRp b24gKG5vIGltcGFjdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdCI+PGJyPg0KSVB2NCBzb3VyY2Ugd291bGQgYmUg dmlzaWJsZSAoaW5zaWRlIElQdjYgc291cmNlKSwgYnV0IHRyYWNraW5nIHdvdWxkIGJlIGRpZmZp Y3VsdCBiZWNhdXNlIHdvdWxkIGJlIG1pbGxpb25zIG9mIHN1Y2ggMTkyLjE2OC4xLnguIEkgZG8g bm90IGJlbGlldmUgdGhhdCBhbnkgcmFuZG9taXphdGlvbiBpcyBuZWVkZWQgKGNvdWxkIGJlIGFk ZGVkIGlmIHNvbWVib2R5IHdvdWxkIGluc2lzdCkuPGJyPg0KPHNwYW4gbGFuZz0iRVMiPlRlY2hu aWNhbGx5LCBpdCBjb3VsZCBiZSBvbmUgRUFNVCwganVzdCBpdCBzaG91bGQgaGF2ZSBzb3VyY2Ug SVB2NCBhcyB0aGUga2V5IGZpZWxkLiBFQU0gdGFibGUgZG9lcyBub3QgbmVlZCBJUHY0IHByZWZp eCAob2YgTEFOIHN1Ym5ldCkuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPkNMQVQg dHJhbnNsYXRpb24gd291bGQgYmVjb21lIHN0YXRlbGVzcyBhZ2Fpbi4gQnV0IGluIGdlbmVyYWwg Q0xBVCB3b3VsZCBiZSBzdGF0ZWZ1bCwgYmVjYXVzZSBkZWNpc2lvbiBhYm91dCBkZXN0aW5hdGlv biBJUHY2IChQTEFUIG9yIHJlYWwgSW50ZXJuZXQgcmVzb3VyY2UpIHNob3VsZCBiZSBkb25lIGFs bW9zdCBwZXItZmxvdyAoZm9yIHNvdXJjZSBJUHY0ICYjNDM7IGRlc3RpbmF0aW9uIElQdjQpIHRo YXQNCiB3YXMgbHVja3kgdG8gY3JlYXRlIGEgc3RhdGUgaW4gRUFNVC4gPC9zcGFuPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bSm9yZGldIEV4YWN0bHku IFdlIG5lZWQgc3RhdGUgYmVjYXVzZSB3ZSBuZWVkIHRvIOKAnGRpc2Nvbm5lY3TigJ0gdGhlIERO UyBUVExzIGZvcm0gdGhlIGhvc3RzIGFwcGxpY2F0aW9ucyBjb25uZWN0aW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcx LjRwdDttc28tYWRkLXNwYWNlOmF1dG87dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFUyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj5UaGUgd2F5IGhvdyB3ZSB3b3VsZCBzZWFyY2gg Zm9yIHByb3BlciBkZXN0aW5hdGlvbiBJUHY2IOKAkyB3ZSBjb3VsZCBrZWVwIGFzIGl0IGlzIGlu IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IChxdWVyeSBieSBwcm94eSBETlMsIGp1 c3QgaXQgd291bGQgYmUgcGVyc29uYWwgcXVlcnkNCiBmb3IgZXZlcnkgaG9zdCkuPGJyPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPldlIGNvdWxkIHJldXNlIG5vdyBIYXBweSBFeWViYWxs IChSRkMgODMwNSkgZm9yIGRvdWJsZSBETlMgcmVxdWVzdHMgd2l0aCBhbGwgYXNzb2NpYXRlZCB0 aW1lcnMsIGJlY2F1c2UgRlFETiByZXF1ZXN0IGlzIHBlcnNvbmFsIG5vdyAoanVzdCBmb3Igb25l IEFwcCBvZiBvbmUgSG9zdCkuIFBhcnQgb2YgSEV2MiBjb3VsZCBiZSBvbiBwcm94eSBDUEUgKG9u IGJlaGFsZiBvZiBJUHY0IGhvc3QpLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltKb3JkaV0gTm8gbmVlZCBm b3IgdGhhdC4gV2Ugb25seSBvcHRpbWl6ZSBJUHY0LW9ubHkgaG9zdHMuIEZ1cnRoZXIsIHRyeWlu ZyB0byBjaGFuZ2UgSEUgaXMgYSDigJxubyB3YXnigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdDttc28tYWRkLXNwYWNlOmF1 dG87dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdo dDoxMDUlIj5JZiBETlMgKHRvZ2V0aGVyIHdpdGggRUFNIHJlY29yZCkgd291bGQgZXhwaXJlLCBi dXQgaG9zdCB3b3VsZCBub3QgcGF5IGF0dGVudGlvbiB0byBETlMgVFRMIChhcHBsaWNhdGlvbiBk b2VzIG5vdCB3YW50IHRvIGludGVycnVwdCB1c2VyIHNlc3Npb24g4oCTIHRoYXQgaXMgcHJvcGVy IGJlaGF2aW9yKSwNCiB0aGVuIGhvc3QgY291bGQgaW5pdGlhdGUgbmV3IEVBTSByZWNvcmQgdGhh dCBjb3VsZCBiZSByZXNvbHZlZCB0byBkaWZmZXJlbnQgSVB2Ni4gSXQgaXMgbm90IGdvb2QgaWRl YSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYnkgdGltZXJzLjxicj4NCkkgcHJvcG9zZSB0byB1c2Ug RUFNIHJlY29yZHMgZm9yZXZlciAoPGI+ZG8gbm90IHBheSBhdHRlbnRpb24gdG8gRE5TIFRUTCB0 aW1lcjwvYj4pLCBFQU0gcmVjb3JkIHNob3VsZCBiZSBkZWxldGVkIG9ubHkgaWYgKDEpIGhvc3Qg d291bGQgYXNrIGFnYWluIGZvciB0aGUgc2FtZSBGUUROLCBvciAoMikgQVJQIGVudHJ5IHdvdWxk IGJlIGRlbGV0ZWQg4oCTIHRoZW4gYWxsIEVBTSBlbnRyaWVzIHJlbGF0ZWQgdG8gdGhpcyBob3N0 IHNob3VsZCBiZSBkZWxldGVkDQogKGluIHRoZSBjYXNlIG9mIHN0YXRpYyBBUlAgaXQgbWVhbnMg 4oCTICZuYnNwOygyKSB3b3VsZCBuZXZlciBoYXBwZW4pLjxicj4NCldlIHdvdWxkIHJlcGxpY2F0 ZSBob3N0IGJlaGF2aW9yOiBpZiBoZSB3b3VsZCBhc2sg4oCTIHdlIHdvdWxkIHJlZnJlc2gsIGlm IGhlIGRvZXMgdmlvbGF0ZSBwcm90b2NvbCDigJMgd2Ugd291bGQgZG8gdGhlIHNhbWUgKGZvciBo aW0pLiBXZSBzaG91bGQgYmUgdHJhbnNwYXJlbnQgZm9yIGhpbS48L3NwYW4+PHNwYW4gbGFuZz0i RVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltKb3JkaV0m bmJzcDtJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBnb29kLCBiZWNhdXNlIHRoYXQgd2lsbCBtZWFu IGhhdmluZyBhIGJpZ2dlciBFQU1UIHRoYW4gYWN0dWFsbHkgbmVlZGVkLiBXZSBuZWVkIHRvIGRl bGV0ZSBlbnRyaWVzIGFzIHNvb24gYXMgcG9zc2libGUuIFRoZSDigJxzdGFsZeKAnSBzdGF0dXMs IGFzIHN1Z2dlc3RlZCBieSBFcmlrLA0KIHJlc29sdmVzIHRoZSBpc3N1ZS4gQW55d2F5LCBJIHN0 aWxsIG5lZWQgdG8gdGhpbmsgYW5kIHdvcmsgbW9yZSBvbiB0aGlzIHRleHQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNw YW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkdvb2QgdGhpbmdzOjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 MS40cHQ7bXNvLWFkZC1zcGFjZTphdXRvO3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRVMiIHN0eWxl PSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1o ZWlnaHQ6MTA1JSI+SXQgc2hvdWxkIHJlc29sdmUgTkFULXRyYXZlcnNhbCBpc3N1ZXMsIGJlY2F1 c2UgSVB2NDpJUHY2PTE6MS4gQW55IGdsb2JhbCBJUHY2IGNvdWxkIGNvbm5lY3QgdG8gdGhpcyBQ cml2YXRlIElQdjQgKGl0IHdvdWxkIHNlZSBpdCBhcyBJUHY0LUVtYmVkZGVkIElQdjYgQWRkcmVz cykuIElmIElQdjYNCiBwZXJzaXN0ZW50IChyZWNvbW1lbmRlZCBmb3IgRkJCKSwgdGhlbiBzdWJz Y3JpYmVyIGNvdWxkIG9yZ2FuaXplIFdlYiBzZXJ2ZXIgb24gdGhpcyBwcml2YXRlIElQdjQsIGl0 IHdvdWxkIGJlIGF2YWlsYWJsZSBmb3IgdGhlIHdob2xlIEludGVybmV0PC9zcGFuPjxzcGFuIGxh bmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bSm9y ZGldIEkgZG9u4oCZdCBzZWUgdGhpcy4gSXQgaXMgb25seSBwb3NzaWJsZSB1c2luZyBJUHY2LCBu b3QgSVB2NC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0O21zby1hZGQtc3BhY2U6YXV0bzt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPk5vIHBvc3NpYmlsaXR5IGZvciBvbmUgSVB2 NCBob3N0IHRvIGhpamFjayBjb25uZWN0aW9uIG9mIG90aGVyIElQdjQgaG9zdCAoaW5jbHVkaW5n IHRoZSBzaXR1YXRpb24gd2hlbiBvbmUgaG9zdCBwb2ludGVkIHRvIGZvcmVpZ24gRE5TIOKAkyBo aXMgRlFETiByZXF1ZXN0IHdvdWxkIGJlIGp1c3QNCiBub3QgdmlzaWJsZSDigJMgRUFNIHJlY29y ZCBmb3IgaGltIHdvdWxkIG5vdCBiZSBjcmVhdGVkKTwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxl IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0O21zby1hZGQtc3BhY2U6YXV0bzt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPklmIGFueSBzdHJhbmdlIGNvbmZpZ3Vy YXRpb24gb24gc2VydmVyIHNpZGUgKFRMUyBTTkkgZGVtdXggYWdhaW5zdCBJUHY2IGFkZHJlc3Mg ZGVtdXgsIElQdjQgb25seSBzZXJ2ZXIgc2hhcmUgQSByZWNvcmQgd2l0aCBEdWFsU3RhY2sgc2Vy dmVyLCBjbGV2ZXIgQ0ROIGNsdXN0ZXJzIGNvbmZpZ3VyYXRpb24NCiAtIG1hbnkgcHJlc2VudGVk IGJ5IEVyaWspIOKAkyB0aGVuIGNsaWVudCB3b3VsZCBiZWhhdmUgbGlrZSA8Yj5zaW5nbGU8L2I+ IGR1YWwgc3RhY2sgY2xpZW50LiBJZiBzdWNoIGNsaWVudCB3b3VsZCBub3QgYmUgc2VydmVkIHBy b3Blcmx5IOKAkyB0aGVuIFNlcnZlciBvd25lciB3b3VsZCBoYXZlIGEgYmlnIHRyb3VibGUgYW55 d2F5LCBiZWNhdXNlIG1hbnkgb3RoZXIgRHVhbFN0YWNrIGNsaWVudCB3b3JsZC13aWRlPC9zcGFu PjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQ7bXNvLWFkZC1z cGFjZTphdXRvO3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZhbWlseTpT eW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+SWYg RE5TIHdvdWxkIHJlc29sdmUgdG8gQUFBQSwgYnV0IG5vIElQIGNvbm5lY3Rpdml0eSDigJMgdGhl biBhZ2Fpbjogb3RoZXIgRHVhbFN0YWNrIGNsaWVudHMgd291bGQgaGF2ZSB0aGUgYmlnIHRyb3Vi bGU8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdDtt c28tYWRkLXNwYWNlOmF1dG87dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEg bGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDox MDUlIj5QYXJ0aWN1bGFyIEVBTVQgcmVjb3JkIGNvdWxkIHN0aWNrIHRvIG9ubHkgMSBkZXN0aW5h dGlvbiBJUHY2IGFkZHJlc3MsIGRlc3BpdGUgRE5TIExvYWQgQmFsYW5jaW5nLCBidXQgaXQgd291 bGQgYmUgZXhhY3RseSB0aGUgc2FtZSBpZiBob3N0IHdvdWxkIGFzayBieSBpdHNlbGYsIG91ciBD TEFULU5HDQogaXMgdHJhbnNwYXJlbnQgYW5kIHBlcnNvbmFsPC9zcGFuPjxzcGFuIGxhbmc9IkVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQ7bXNvLWFkZC1zcGFjZTphdXRvO3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bGluZS1oZWlnaHQ6MTA1JSI+SWYgdXNlciB3b3VsZCBtb2Rp ZnkgRE5TIG9uIENQRSDigJMgaXQgaXMgZmluZSDigJMgd2Ugd291bGQgdHJ5IHRvIGdldCBBQUFB IGZyb20gRE5TIHNlcnZlciBwcmVmZXJyZWQgYnkgaGltLiBObyBBQUFBIGFuc3dlciAtJmd0OyBu byBFQU0gcmVjb3JkIC0mZ3Q7IHRyYWZmaWMgd291bGQgZ28gdG8gUExBVCAtJmd0Ow0KIG5vIHBy b2JsZW08L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRw dDttc28tYWRkLXNwYWNlOmF1dG87dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZl bDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZv bnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdo dDoxMDUlIj5ETlMgcG9pc29uaW5nIHdvdWxkIGFmZmVjdCBvbmx5IDEgaG9zdCDigJMgZXhhY3Rs eSB0aGUgc2FtZSBzaXR1YXRpb24gYXMgd2l0aG91dCBhbnkgb3B0aW1pemF0aW9uPC9zcGFuPjxz cGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BMYXN0IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNDttYXJnaW4tbGVmdDo3MS4uNHB0Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPkkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbSB3 aXRoIEROU1NFQyB0b28g4oCTIGl0IGNvdWxkIGFkZGl0aW9uYWxseSBjaGVjayBETlMgYW5zd2Vy czwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkN1cnJlbnRseSBk aXNjdXNzZWQgaW4gdGhlIGRyYWZ0IChhbmQgbm90IGZpeGVkKTo8L3NwYW4+PHNwYW4gbGFuZz0i RVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0O21zby1hZGQtc3BhY2U6YXV0bzt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPk9ubHkgSVB2NiBiYWNrYm9uZSBpcyBkb3du IG9yIGxpbmsgZGVncmFkZWQgKElQdjQgaXMgZmluZSksLSBidXQgd2UgcHVzaCB0cmFmZmljIHRv IElQdjYgb25seTwvc3Bhbj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 bGluZS1oZWlnaHQ6MTA1JTtmb250LWZhbWlseTpXaW5nZGluZ3MiPkw8L3NwYW4+PHNwYW4gbGFu Zz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbmUgdmlzaWJsZSByZXN0cmljdGlvbjo8L3Nw YW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0O21zby1hZGQtc3BhY2U6YXV0 bzt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm82Ij4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPklmIHN1YnNjcmli ZXIgd291bGQgaGF2ZSBiaWcgcm91dGVkIG5ldHdvcmsgaW5zaWRlLCB0aGVuIEFSUCBlbnRyeSB3 b3VsZCBub3QgYmUgdmlzaWJsZSBvbiBDUEUuIE5leHQgaG9wIHJvdXRlciB3b3VsZCBiZSBEdWFs IFN0YWNrLiBJbiBzdWNoIGNhc2U6IEVBTVQgZW50cnkgd291bGQgbm90DQogYmUgY3JlYXRlZCDi gJMgdHJhZmZpYyB3b3VsZCBnbyB0byBQTEFUPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzUuNHB0Ij48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+W0pvcmRpXSB5ZXMgdG8gYWxsIHRob3NlIHBvaW50czxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIGhhdmUgbG9va2VkIGNhcmVmdWxseSB0byBhbGwgY29tbWVudHMgb2YgSmVuLCBFcmlr LCBhbmQgUGhpbGlwIGFnYWluLiBJIGhhdmUgbm90IGZvdW5kIGFueSBob2xlcyBsZWZ0LiBQcmlt YXJpbHksIGJlY2F1c2UgaW4gdGhpcyBwcm9wb3NhbCB3ZSBhcmUgbWltaWNraW5nDQogaG9zdHMg aW5kaXZpZHVhbGx5IOKAkyB3ZSBhcmUganVzdCDigJxmdWxseSB0cmFuc3BhcmVudCBpbiBib3Ro IGRpcmVjdGlvbnPigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPltKb3JkaV0gSeKAmW0gcmUtcmVhZGluZyBhbnl3YXksIGV2ZXJ5dGhpbmcgYW5kIG1h a2luZyBzdXJlIHdlIGFyZW7igJl0IG1pc3NpbmcgYW55IGlzc3VlIGJlZm9yZSBzZW5kaW5nIGEg bmV3IHZlcnNpb24g4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5FZHVhcmQ8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFUyI+PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKjxicj4NCklQdjQgaXMgb3Zlcjxicj4NCkFyZSB5b3UgcmVhZHkgZm9yIHRo ZSBuZXcgSW50ZXJuZXQgPzxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnku Y29tIj5odHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbTwvYT48YnI+DQpUaGUgSVB2NiBDb21w YW55PGJyPg0KPGJyPg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRp b24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRp b24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQg ZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZg0KIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQg YSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgdGhlIGNvbnRlbnRzDQogb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFs bHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2ls bCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8g dGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFu ZCBkZWxldGUgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_1b57ee72a7ad41058a72abe8254c3b96huaweicom_-- From nobody Mon Jul 20 03:32:29 2020 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 032483A080F for ; Mon, 20 Jul 2020 03:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5swbzlcpYbl for ; Mon, 20 Jul 2020 03:32:26 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3033A0807 for ; Mon, 20 Jul 2020 03:32:26 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id t7so7099870qvl.8 for ; Mon, 20 Jul 2020 03:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NGIE1eXxc6YFIml/QzBFn9mP73HZiPUAG89qmlW8L2M=; b=fEpd8HyYTzHWt0UhuGWyLDtO0uFWbcchLsajnRTL9w3KK5g2ZErVofEcpQkFdPV2lY dIwxOboTZ3Sx1aT7Lnt4G/k9H0soR38EZxLOcvMBv1eVZ/YR1NzknIXxKb6H2AJqOrfp d0KmnoBSi1P4R8P6H13Vmzb7TRzFh8lHEgu5aIQB3aRsycSfaHlAKw8GcCn2vwXdk1qM JAFTEJ1k96KBJl9qb44e3Kx3CD+lN5UunC6HmuPlTPAMSSj4AumJGDTTHvIBsI8H/ION 4x6kkRSrFlM6LWnVQR1XeC19aDFQ8bB3pH0FuH6K3JiDf+J1RG+3H/c4H3HE02juAVRA eORA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NGIE1eXxc6YFIml/QzBFn9mP73HZiPUAG89qmlW8L2M=; b=EGjPGP6fCGQOmRGk4qfoA1gIzODUa70JOIe9TX/aHIdL+/C7TDWJu831MkiJuVfm1U +lnaUcBX7yfQ+pEVjlRzyFTkZOUmV3Mft7uFomCEOx6Wt1JAXlZAjBh+8etv70lQM3aP P5a/gJ6VFIvAGKtXxbtdf7OWfOVRv1xiXMC0aIf9n9HQeiTDzZKS8E39UZEcRxN42en3 8vlSwUPzyl34h3kkl610pUwTGu3zzR3APsk/BMXir4Q3Rk9rHEK25UcIDA2Zp68SDpG1 Jcn/z3vLgFHz+Xz+PS0HhjCOc9YemtFycBd/9qYr6cphMQze2eClmB3XiU7X8AsGnGUg tAJA== X-Gm-Message-State: AOAM531CTIpFqpdwz+9HuIfmnqisf4IanCfz2bxy2IvIaH71UE3FGJfD MJ7PcXengrYRxTd/bAUPLc+iYQojm3mZa0sJWDLeFE7A X-Google-Smtp-Source: ABdhPJxbI2GVK5Ngc8vBgUFVh25eYNoyhmCpXXBs9pQDcwilGyFRWqcUkKxEYMCooREANzsywg+IVQuM7Mz3d6OBStc= X-Received: by 2002:ad4:4a6d:: with SMTP id cn13mr21520148qvb.165.1595241145577; Mon, 20 Jul 2020 03:32:25 -0700 (PDT) MIME-Version: 1.0 References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> In-Reply-To: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> From: Jen Linkova Date: Mon, 20 Jul 2020 20:32:14 +1000 Message-ID: To: JORDI PALET MARTINEZ Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 10:32:28 -0000 On Mon, Jul 20, 2020 at 7:54 AM JORDI PALET MARTINEZ wrote: > > 5.2.13. Troubleshooting Implications > >> How do corner-cases around collisions where EAMT entries >> don't get proprerly invalidated get debugged by the ISP >> (and content provider!)? > > This is opaque to the CDN and could result in lots of escalations from > end-users and customers. The net result will be for content to get > switched to IPv4-only if that "fixes" the problem which might impact > users world-wide. (Neither the CDN or their customer has any > visibility into what is going on here other than that some end users > may be reporting not being able to view dual-stacked content.) > > [Jordi] If the troubleshooting is done with dual-stack host, no issues. If it is an IPv4-only host, the optimization can be fully disabled, or specific entries can be disabled. Is not that solving the problem? To disable the optimisation you need to know it exists, right? If the optimisation is enabled by default the operator might not be even aware of it, especially if the CPE is not provided by the ISP. In addition to that the issue might be rather intermittent and happen for some IPv4 addresses only. It's not like 'nothing works', it would be more like 'sometime my TV can not run this app or that app just stops working until I reboot it'. If we assume that the operator has an ability to turn the optimisation on/off it would be much safer to keep it turned off (shall I worry about this next time I buy a new CPE?) and let the operator make the decision, as before this feature can be useful the operator needs to: - educate the support team; - test the feature on the CPEs they provide - update the recommended feature lists for 'bring your own CPE' etc. And then the operator can go and enable this feature. If we assume they do not have control to enable it how can we assume they would be able to disable it for troubleshooting? >> * There is an serious risk exposure to hijacking traffic by inserting bogus binding >> (ie, return target's A record and malicious actor's AAAA record). >> In most cases these records should get marked as Invalid, >> but the corner cases here are fragile (eg, with foreign DNS or >> clients caching past the TTL mixed in here. >> An example attack here is that a client has an A record >> for "www.example.com" pointing to 192.0.2.1 cached past >> its TTL so the EAMT record is gone. An attacker convinces >> another user in the same home network to do a DNS lookup >> that has an A record of 192.0.2..1 (which the attacker doesn't own) >> but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled). >> Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never >> existed then the attacker can redirect all traffic to it to an IPv6 address >> of their choice. No DNS spoofing is needed here at all, just making >> a "claim" that the A/AAAA are associated (which has no authentication). >> This is potentially worse as I'd hypothesize that IPv4-only STB >> clients are much less likely to use HTTPS/TLS.. > > [Jordi] I think that having a per-host EAMT entries resolves this. I believe that per-host EAMT entries do reduce the impact by limiting it to a single host. However for that host the attack is rather easy to execute still. -- SY, Jen Linkova aka Furry From nobody Mon Jul 20 03:44:09 2020 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 D55203A097C for ; Mon, 20 Jul 2020 03:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkfqMLyZelD1 for ; Mon, 20 Jul 2020 03:44:07 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CFB3A097F for ; Mon, 20 Jul 2020 03:44:06 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id l6so14687923qkc.6 for ; Mon, 20 Jul 2020 03:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CL2p3SnKyHriiAHn4aG8n0ILQurrV3g+IDM5KWhK8Ro=; b=RsNLeiMwPNsLxm1dIdXCBhGXWVI8WqXg/YPH7Bw9q/xFCBqmxuMSh/75sgpCix2VPS Gvq9TFUDs80FWe3u0J84rxTlk/0arWB/djZTR0tP/9+cYKNv4Lyy2RTDDF/wA0yAzBxi bXsJziXACBd0Ti1OHdIxJURZi+nvqrvt67X35XXpJZdWj41FQRnlPYOBXu8BVOoqUprE 0ze6pVA4uE4ecJW0/HxveZ9xLuviEnGkeEtuyTrNIROIZNoxJioC2F98UB6jDVmZr8Xz sWIN0h/w91LnKYnbRD4S3TIDVr7OY8W+HLxLkk3fxpCVi12DydPldPVALrf1itETCDSs 8IUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CL2p3SnKyHriiAHn4aG8n0ILQurrV3g+IDM5KWhK8Ro=; b=LAmR3dc2rSwnCczLijx759vA9US5UdocNcwFZreZpcH8WhLRoJkMyEklyPz3mtbRTO k4KHffu0lTXv9nsIJcJOlGoKMx05KkCxPzQaR5xtxK23JnPb7gWG/sl96y4LZmgMhSWD eZIfX58rDZiBSLG+8aQKY0INseyUTAY7m5jSBiqvYOPhlD3NQsrQ1JzNcUOnZQ8hipad TCkLBCfgoS5AoyzZaJUNbjcIp5Ysfq3q7rme+xmQ0yaKN97htte/HPkYGFO/AkgDvloJ 95ycBeImjbZCBSwMeKruSJmWyBSDmNrVF9xYMsAOw+yBbg3n2xsJL0/isE2p8o7rJu0Q hG1A== X-Gm-Message-State: AOAM530N8KKTLYIHFMWSkE28FeckbM2dm749entSLytCCbFqyjo2Xj4i yF+CusyQuI9RhTepa3FAC+ae5FZgWgtSGmTYlGk= X-Google-Smtp-Source: ABdhPJxaeExlrsT8B6OKwv1Do5nKrWM4OuXbFBLw7w7p4M/QlMqfRlJd5lxGxNFwh2BgIXkyuMT4O72xHc/ZT/f0bu0= X-Received: by 2002:a05:620a:13fb:: with SMTP id h27mr20142181qkl.466.1595241845500; Mon, 20 Jul 2020 03:44:05 -0700 (PDT) MIME-Version: 1.0 References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> In-Reply-To: <02f63b1af4284239801567cfaf4d9c9b@huawei.com> From: Jen Linkova Date: Mon, 20 Jul 2020 20:43:53 +1000 Message-ID: To: Vasilenko Eduard Cc: JORDI PALET MARTINEZ , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 10:44:09 -0000 On Mon, Jul 20, 2020 at 6:16 PM Vasilenko Eduard wrote: >> An example attack here is that a client has an A record >> for "www.example.com" pointing to 192.0.2.1 cached past >> its TTL so the EAMT record is gone. An attacker convinces >> another user in the same home network to do a DNS lookup >> that has an A record of 192.0.2..1 (which the attacker doesn't own) >> but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled). >> Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never >> existed then the attacker can redirect all traffic to it to an IPv6 address >> of their choice. No DNS spoofing is needed here at all, just making >> a "claim" that the A/AAAA are associated (which has no authentication). >> This is potentially worse as I'd hypothesize that IPv4-only STB >> clients are much less likely to use HTTPS/TLS.. > > [Jordi] I think that having a per-host EAMT entries resolves this. > [Eduard] I believe that this draft (that simulate normal hosts) could not resolve this problem in principle. > If somebody are capable to program 3rd party FQDN to fake AAAA record (of his), then the whole internet would be affected. The attack does not require to fake AAAA RR for someone's else FQDN. The attacker owns the FQDN and can put whatever they want there, including the victim server IPv4 address. Let's say I own furry.example.com. I tricked your IPv4-only TV to ask for A RR for that name. I returned you an IPv4 address of www.youtube.com as A and - when the smart CPE asks for AAAA, IPv6 address of my own server. Now your smart TV would be sending traffic to my server instead of Youtube. I totally agree that binding the EAMT entry to the source IPv4 address limits the impact for a single device and makes the attack harder to implement (you need to trick the same device into resolving my evil FQDN, which is not as easy as tricking my laptop into it). > And DNS standards have a lot of tools against this. I'm not sure there is anything in DNS preventing me from putting the IPv4 address of www.huawei.com into the zone file for a domain name I own. -- SY, Jen Linkova aka Furry From nobody Mon Jul 20 03:49:45 2020 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 32E653A09A0 for ; Mon, 20 Jul 2020 03:49:43 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvyjfS1hN9rL for ; Mon, 20 Jul 2020 03:49:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3CFC83A099A for ; Mon, 20 Jul 2020 03:49:41 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D9302292D007AEB42261; Mon, 20 Jul 2020 11:49:38 +0100 (IST) Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 20 Jul 2020 11:49:38 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 13:49:37 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 13:49:37 +0300 From: Vasilenko Eduard To: Philip Homburg , "v6ops@ietf.org" CC: JORDI PALET MARTINEZ Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns Thread-Index: AQHWXCMePERdOoO6CEWtMpgm5DnpN6kLXSaAgAA3Znb//9SRgIAA40qAgADQJT6AAW+vgIABs/FjgAAIOaA= Date: Mon, 20 Jul 2020 10:49:37 +0000 Message-ID: <18ea3c3f6f8f43f092c911c8ae19d707@huawei.com> References: <7CBFD60E-93AF-42DE-8C16-D7B8BAB01B59@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 10:49:43 -0000 I do not see good resolution for this corner case (presented by Philip): "for the corner case when the owner of Internet resource has partially fini= shed his applications migration to IPv6, may be some applications accessibl= e by IPv4-only, despite sharing same dual-stack server (or servers)" But I see work-around (more complexity on draft - additional algorithm comp= lexity): if such situation would happen (destination IPv4 has the collision for the = same source IPv4 host, but at the same time second IPv6 is not resolved) th= en previous EAM entry should be put in "disabled" state, no new sessions fo= r this pair should be processes, current fl= ow could continue. The biggest problem that we should memorize this situation (in "disabled" s= tate) forever, because request to 1st (IPv6 available) resource could happe= n later - then traffic to 2nd resource (IPv4 only) would be disrupted (I as= sume it was flowing to PLAT). Such complicated logic would never come to hardware, but SoC chips have ARM= cores for this - should not be a problem. Of course, it is not good to keep states for the purpose "not to use". Any better idea? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg Sent: 20 =C9=C0=CC=D1 2020 =C7. 12:57 To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 general conce= rns > Because we are looking for EAMT entries which also contain the FQDN,=20 > there will be no match, so no optimization performed if the AAAA=20 > response doesn't come timely. I don't understand this. Suppose an IPv4-only client looks up a.example.com and b.example.com (in pa= rallel). The CPE generates additional AAAA queries for a.example.com and b.example.c= om. The A queries for both a.example.com and b.example.com return 192.0.2.1. The AAAA query for a.example.com returns 2001:DB8::1 and the AAAA query for= b.example.com results in a timeout. When the AAAA query for a.example.com returns, the CPE installs an EAMT ent= ry for a.example.com. When b.example.com gets a timeout, the CPE does nothi= ng Later the host connects twice to 192.0.2.1. The CPE sees the EAMT entry and= connects the host twice to 2001:DB8::1=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 20 04:03:47 2020 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 EE9753A09C7 for ; Mon, 20 Jul 2020 04:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9JbeSgv05dQ for ; Mon, 20 Jul 2020 04:03:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4913A09C5 for ; Mon, 20 Jul 2020 04:03:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jxTa8-00007YC; Mon, 20 Jul 2020 13:03:40 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> In-reply-to: Your message of "Mon, 20 Jul 2020 20:43:53 +1000 ." Date: Mon, 20 Jul 2020 13:03:40 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 11:03:46 -0000 >The attack does not require to fake AAAA RR for someone's else FQDN. >The attacker owns the FQDN and can put whatever they want there, >including the victim server IPv4 address. >Let's say I own furry.example.com. I tricked your IPv4-only TV to ask >for A RR for that name. I returned you an IPv4 address of >www.youtube.com as A and - when the smart CPE asks for AAAA, IPv6 >address of my own server. Now your smart TV would be sending traffic >to my server instead of Youtube. I don't see how that attack would work. Suppose the IPv4 address for youtube is 192.0.2.1. Now an attacker returns this address for furry.example.com along with 2001:DB8::1. Later the host tries to connect to youtube. Again the A query returns 192.0.2.1. Now the CPE detects that it has two domain names for this IPv4 address and removes the EAMT entry. Obviously, this would go wrong if youtube would use address literals instead of domain names. From nobody Mon Jul 20 04:39:01 2020 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 346E53A05A0 for ; Mon, 20 Jul 2020 04:38:58 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3m78f3hEzQT for ; Mon, 20 Jul 2020 04:38:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 5266E3A0598 for ; Mon, 20 Jul 2020 04:38:56 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B9E5F6F9E95E413358C3; Mon, 20 Jul 2020 12:38:53 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 12:38:50 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 14:38:49 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 14:38:49 +0300 From: Vasilenko Eduard To: Jen Linkova , JORDI PALET MARTINEZ CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest Thread-Index: AQHWXhc/K6tozmRt0kKaAvFhAK9ImakQE5cAgAA4nmA= Date: Mon, 20 Jul 2020 11:38:49 +0000 Message-ID: References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 11:38:58 -0000 I do agree to Jen that any transition to "extended CLAT" should have rollba= ck possibility. XLAT by itself has such capability. If everything is hard-coded into CPE - then how to do it? We need to push s= omehow the single bit: "Yes/No". Let's look how XLAT activated: RFC 8585 (CPE) is telling to us (3.2.1. 464XLAT):=20 464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] ("Discov= ery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discov= er the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)= /suffix(es). 464XLAT-6: If the network provides several choices for the discovery/learn= ing of the NAT64 prefix, the priority to use one or the other MUST follow t= his order: 1) [RFC7225] and 2) [RFC7050]. XLAT RFC 6877: " Discovery of the IPv6 Prefix Used for IPv6 Address Synthes= is" (it is RFC 7050) i.e. everything is referring to some other RFCs. I propose to do the same for CLAT-NG in this draft (as it was for CLAT 1.0)= : activation should be discussed in different place, NG functionality of CL= AT should be disabled by default, if CLAT would receive just NSP/WKP - it i= s not the reason yet to create EAMT. Ed/ -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova Sent: 20 =C9=C0=CC=D1 2020 =C7. 13:32 To: JORDI PALET MARTINEZ Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and t= he rest On Mon, Jul 20, 2020 at 7:54 AM JORDI PALET MARTINEZ wrote: > > 5.2.13. Troubleshooting Implications > >> How do corner-cases around collisions where EAMT entries don't get=20 >> proprerly invalidated get debugged by the ISP (and content=20 >> provider!)? > > This is opaque to the CDN and could result in lots of escalations from=20 > end-users and customers. The net result will be for content to get=20 > switched to IPv4-only if that "fixes" the problem which might impact=20 > users world-wide. (Neither the CDN or their customer has any=20 > visibility into what is going on here other than that some end users=20 > may be reporting not being able to view dual-stacked content.) > > [Jordi] If the troubleshooting is done with dual-stack host, no issues. I= f it is an IPv4-only host, the optimization can be fully disabled, or speci= fic entries can be disabled. Is not that solving the problem? To disable the optimisation you need to know it exists, right? If the optim= isation is enabled by default the operator might not be even aware of it, e= specially if the CPE is not provided by the ISP. In addition to that the issue might be rather intermittent and happen for s= ome IPv4 addresses only. It's not like 'nothing works', it would be more li= ke 'sometime my TV can not run this app or that app just stops working unti= l I reboot it'. If we assume that the operator has an ability to turn the optimisation on/o= ff it would be much safer to keep it turned off (shall I worry about this n= ext time I buy a new CPE?) and let the operator make the decision, as befor= e this feature can be useful the operator needs to: - educate the support team; - test the feature on the CPEs they provide - update the recommended feature lists for 'bring your own CPE' etc. And then the operator can go and enable this feature. If we assume they do not have control to enable it how can we assume they w= ould be able to disable it for troubleshooting? >> * There is an serious risk exposure to hijacking traffic by inserting bo= gus binding >> (ie, return target's A record and malicious actor's AAAA record). >> In most cases these records should get marked as Invalid, >> but the corner cases here are fragile (eg, with foreign DNS or >> clients caching past the TTL mixed in here. >> An example attack here is that a client has an A record >> for "www.example.com" pointing to 192.0.2.1 cached past >> its TTL so the EAMT record is gone. An attacker convinces >> another user in the same home network to do a DNS lookup >> that has an A record of 192.0.2..1 (which the attacker doesn't own) >> but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlle= d). >> Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never >> existed then the attacker can redirect all traffic to it to an IPv6 ad= dress >> of their choice. No DNS spoofing is needed here at all, just=20 >> making a "claim" that the A/AAAA are associated (which has no authentic= ation). >> This is potentially worse as I'd hypothesize that IPv4-only STB =20 >> clients are much less likely to use HTTPS/TLS.. > > [Jordi] I think that having a per-host EAMT entries resolves this. I believe that per-host EAMT entries do reduce the impact by limiting it to= a single host. However for that host the attack is rather easy to execute = still. -- SY, Jen Linkova aka Furry _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 20 05:13:21 2020 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 BF31B3A0889 for ; Mon, 20 Jul 2020 05:13:13 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTae5KEi9mH7 for ; Mon, 20 Jul 2020 05:13:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 700DC3A0853 for ; Mon, 20 Jul 2020 05:13:10 -0700 (PDT) Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A2DD178D4347D5B5CB0D; Mon, 20 Jul 2020 13:13:08 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 13:13:08 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 15:13:07 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 15:13:07 +0300 From: Vasilenko Eduard To: Jen Linkova CC: JORDI PALET MARTINEZ , "V6 Ops List" Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest Thread-Index: AQHWXhc/K6tozmRt0kKaAvFhAK9ImakQFg/ggAAAyoCAAEM64A== Date: Mon, 20 Jul 2020 12:13:07 +0000 Message-ID: <04d5eb82da794b9489474597cdb7fd11@huawei.com> References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 12:13:20 -0000 SGkgSmVuLA0KDQpIb3cgc21hcnRUViB3b3VsZCBzdGFydCB0byBhc2sgZnVycnkuZXhhbXBsZS5j b20gaW4gMXN0IHBsYWNlPw0KSXQgY291bGQgYXNrIG5ldGZsaXguY29tIGFuZCBzb21lIG90aGVy IGxpbWl0ZWQgbnVtYmVyIG9mIEZRRE4uIERvIHlvdSBiZWxpZXZlIGFueWJvZHkgZnJvbSB0aGVz ZSByZXNwZWN0ZWQgY29tcGFuaWVzIHdvdWxkIGJlIGRvaW5nIHdoYXQgeW91IGhhdmUgZGVzY3Jp YmVkIGJlbG93Pw0KSWYgdXNlciBpcyBnb2luZyBzb21ld2hlcmUgKEZRRE4pIC0gaXQgaXMgYWxy ZWFkeSBzb21lIGxldmVsIG9mIHRydXN0LCBiZWNhdXNlIGV2ZW4gMXN0IHdlYiBwYWdlIGNvdWxk IGhhdmUgbWFueSBzZWN1cml0eSBwcm9ibGVtcy4NCg0KQnkgdGhlIHdheSwgYmVmb3JlIHN1Y2Nl c3NmdWxseSByZWRpcmVjdGluZyBJUHY2IHRyYWZmaWMgdG8gaXRzZWxmIChieSBiZWxvdyBwcmVz ZW50ZWQgbWV0aG9kb2xvZ3kpLA0KU3VjaCB3ZWIgc2l0ZSAoZnVycnkuZXhhbXBsZS5jb20pIHdv dWxkIGFscmVhZHkgcmVkaXJlY3QgbWFueSBub3JtYWwgSVB2NCB1c2VycyB0byBZb3V0dWJlLiBQ ZW9wbGUgd291bGQgc3RhcnQgdG8gY29tcGxhaW4gLSBzb21lYm9keSBjb3VsZCBub3RpY2UuDQpB bmQgdGhlIGV2aWRlbmNlIHdvdWxkIHN0aWNrIGluIGNhY2hlIG9uIG1hbnkgRE5TIHNlcnZlcnMu IEl0IGlzIHZlcnkgdHJhY2VhYmxlIHRvIGF0dGFja2VyLg0KDQpXaGF0IGNvdWxkIGJlIHRoZSBy ZWFzb24gdG8gYXNrIGFueXRoaW5nIG9uIEZRRE4gZnVycnkuZXhhbXBsZS5jb20sIGlmIG9uZSB3 b3VsZCBuZXZlciBzZWUgdGhpcyB3ZWJzaXRlICh5b3V0dWJlIHdvdWxkIGJlIHN1YnN0aXR1dGVk KS4NCkJ1dCBpZiBhdHRhY2tlciB3b3VsZCBtYW5hZ2UgdG8gcHV0IHRoaXMgYm9va21hcmsgaW4g dXNlcnMgZmF2b3JpdGVzIC4uLg0KDQpJIGRvIG5vdCBoYXZlIHN0cmljdCBvcGluaW9uIHdoYXQg dG8gZG8gYWJvdXQgaXQuDQpJdCBpcyBkZWZpbml0ZWx5IG5ldyBhdHRhY2sgdmVjdG9yIGludHJv ZHVjZSBieSB0aGlzIGRyYWZ0LCBidXQgbm90IHZlcnkgZGFuZ2Vyb3VzIC4uLg0KQW55d2F5LCBi dXQgSUVURiBydWxlcyAtIGl0IHNob3VsZCBiZSBhdCBsZWFzdCBkb2N1bWVudGVkIGluIG1hbmRh dG9yeSBTZWN1cml0eSBzZWN0aW9uLiBNYW55IHBlb3BsZSBzaG91bGQgZGVjaWRlLg0KDQpFZHVh cmQNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKZW4gTGlua292YSBbbWFpbHRv OmZ1cnJ5MTNAZ21haWwuY29tXSANClNlbnQ6IDIwINC40Y7Qu9GPIDIwMjAg0LMuIDEzOjQ0DQpU bzogVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPg0KQ2M6IEpP UkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmll dGYub3JnPjsgVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9w c10gZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMiAtIDUuMi42IGFuZCB0 aGUgcmVzdA0KDQpPbiBNb24sIEp1bCAyMCwgMjAyMCBhdCA2OjE2IFBNIFZhc2lsZW5rbyBFZHVh cmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiAgIEFuIGV4YW1wbGUg YXR0YWNrIGhlcmUgaXMgdGhhdCBhIGNsaWVudCBoYXMgYW4gQSByZWNvcmQNCj4+ICAgZm9yICJ3 d3cuZXhhbXBsZS5jb20iIHBvaW50aW5nIHRvIDE5Mi4wLjIuMSBjYWNoZWQgcGFzdA0KPj4gICBp dHMgVFRMIHNvIHRoZSBFQU1UIHJlY29yZCBpcyBnb25lLiAgQW4gYXR0YWNrZXIgY29udmluY2Vz DQo+PiAgIGFub3RoZXIgdXNlciBpbiB0aGUgc2FtZSBob21lIG5ldHdvcmsgdG8gZG8gYSBETlMg bG9va3VwDQo+PiAgIHRoYXQgaGFzIGFuIEEgcmVjb3JkIG9mIDE5Mi4wLjIuLjEgKHdoaWNoIHRo ZSBhdHRhY2tlciBkb2Vzbid0IG93bikgIA0KPj4gYnV0IGEgQUFBQSByZWNvcmQgZm9yIDIwMDE6 ZGI4OmVlZWU6OmVlZWUgKHdoaWNoIGlzIGF0dGFja2VyLWNvbnRyb2xsZWQpLg0KPj4gICBFdmVu IGlmIDE5Mi4wLjIuMSBpcyBJUHY0LW9ubHksIGlmIHRoZSBFQU1UIGVudHJ5IGhhcyBleHBpcmVk IG9yIG5ldmVyDQo+PiAgIGV4aXN0ZWQgdGhlbiB0aGUgYXR0YWNrZXIgY2FuIHJlZGlyZWN0IGFs bCB0cmFmZmljIHRvIGl0IHRvIGFuIElQdjYgYWRkcmVzcw0KPj4gICBvZiB0aGVpciBjaG9pY2Uu ICBObyBETlMgc3Bvb2ZpbmcgaXMgbmVlZGVkIGhlcmUgYXQgYWxsLCBqdXN0IG1ha2luZw0KPj4g ICBhICJjbGFpbSIgdGhhdCB0aGUgQS9BQUFBIGFyZSBhc3NvY2lhdGVkICh3aGljaCBoYXMgbm8g YXV0aGVudGljYXRpb24pLg0KPj4gICBUaGlzIGlzIHBvdGVudGlhbGx5IHdvcnNlIGFzIEknZCBo eXBvdGhlc2l6ZSB0aGF0IElQdjQtb25seSBTVEINCj4+ICAgY2xpZW50cyBhcmUgbXVjaCBsZXNz IGxpa2VseSB0byB1c2UgSFRUUFMvVExTLi4NCj4NCj4gW0pvcmRpXSBJIHRoaW5rIHRoYXQgaGF2 aW5nIGEgcGVyLWhvc3QgRUFNVCBlbnRyaWVzIHJlc29sdmVzIHRoaXMuDQo+IFtFZHVhcmRdIEkg YmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQgKHRoYXQgc2ltdWxhdGUgbm9ybWFsIGhvc3RzKSBjb3Vs ZCBub3QgcmVzb2x2ZSB0aGlzIHByb2JsZW0gaW4gcHJpbmNpcGxlLg0KPiBJZiBzb21lYm9keSBh cmUgY2FwYWJsZSB0byBwcm9ncmFtIDNyZCBwYXJ0eSBGUUROIHRvIGZha2UgQUFBQSByZWNvcmQg KG9mIGhpcyksIHRoZW4gdGhlIHdob2xlIGludGVybmV0IHdvdWxkIGJlIGFmZmVjdGVkLg0KDQpU aGUgYXR0YWNrIGRvZXMgbm90IHJlcXVpcmUgdG8gZmFrZSBBQUFBIFJSIGZvciBzb21lb25lJ3Mg ZWxzZSBGUUROLg0KVGhlIGF0dGFja2VyIG93bnMgdGhlIEZRRE4gYW5kIGNhbiBwdXQgd2hhdGV2 ZXIgdGhleSB3YW50IHRoZXJlLCBpbmNsdWRpbmcgdGhlIHZpY3RpbSBzZXJ2ZXIgSVB2NCBhZGRy ZXNzLg0KTGV0J3Mgc2F5IEkgb3duIGZ1cnJ5LmV4YW1wbGUuY29tLiBJIHRyaWNrZWQgeW91ciBJ UHY0LW9ubHkgVFYgdG8gYXNrIGZvciBBIFJSIGZvciB0aGF0IG5hbWUuIEkgcmV0dXJuZWQgeW91 IGFuIElQdjQgYWRkcmVzcyBvZiB3d3cueW91dHViZS5jb20gYXMgQSBhbmQgLSB3aGVuIHRoZSBz bWFydCBDUEUgYXNrcyBmb3IgQUFBQSwgSVB2NiBhZGRyZXNzIG9mIG15IG93biBzZXJ2ZXIuIE5v dyB5b3VyIHNtYXJ0IFRWIHdvdWxkIGJlIHNlbmRpbmcgdHJhZmZpYyB0byBteSBzZXJ2ZXIgaW5z dGVhZCBvZiBZb3V0dWJlLg0KSSB0b3RhbGx5IGFncmVlIHRoYXQgYmluZGluZyB0aGUgRUFNVCBl bnRyeSB0byB0aGUgc291cmNlIElQdjQgYWRkcmVzcyBsaW1pdHMgdGhlIGltcGFjdCBmb3IgYSBz aW5nbGUgZGV2aWNlIGFuZCBtYWtlcyB0aGUgYXR0YWNrIGhhcmRlciB0byBpbXBsZW1lbnQgKHlv dSBuZWVkIHRvIHRyaWNrIHRoZSBzYW1lIGRldmljZSBpbnRvIHJlc29sdmluZyBteSBldmlsIEZR RE4sIHdoaWNoIGlzIG5vdCBhcyBlYXN5IGFzIHRyaWNraW5nIG15IGxhcHRvcCBpbnRvIGl0KS4N Cg0KPiBBbmQgRE5TIHN0YW5kYXJkcyBoYXZlIGEgbG90IG9mIHRvb2xzIGFnYWluc3QgdGhpcy4N Cg0KSSdtIG5vdCBzdXJlIHRoZXJlIGlzIGFueXRoaW5nIGluIEROUyBwcmV2ZW50aW5nIG1lIGZy b20gcHV0dGluZyB0aGUNCklQdjQgYWRkcmVzcyBvZiB3d3cuaHVhd2VpLmNvbSBpbnRvIHRoZSB6 b25lIGZpbGUgZm9yIGEgZG9tYWluIG5hbWUgSSBvd24uDQoNCi0tDQpTWSwgSmVuIExpbmtvdmEg YWthIEZ1cnJ5DQo= From nobody Mon Jul 20 06:41:27 2020 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 3D5933A0A3D for ; Mon, 20 Jul 2020 06:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5Wf8_wPpRnx for ; Mon, 20 Jul 2020 06:41:23 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024233A0A3B for ; Mon, 20 Jul 2020 06:41:23 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id j10so12930000qtq.11 for ; Mon, 20 Jul 2020 06:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l0zffywgBZTo9HvFXjJ5DIYeJBwzAPwVakDAvaxKQYc=; b=a/aCLnM3L+kcY7yWbdy+xFM8P68wsbaeH1fz5OPyzrgkPtWg4UEOyApsK/V17TSCJM I3olOwgGx0cgcpNs0J4KSCB/3N6mUQRoSemaZDcoECmbGWxvFeDjCySmU0tgudnLM60Z HJHFJ1pVq2+juxONevYya2CjZdWVlzEyvcuQjvKlH0khaRurh9DmIbJTd8x2ZQmZKr56 wkvfZjmgXWMyYJlKeaAQQnHxo6XR/Nal9h5kxj75TnNY1SGDm/xHeHrPvKjREcL2WVsC 3lLpUWqUveW7vLa0l+lCxWc+HH/O0kyVsM04MWPXkJdWdXfNl/zYOlayYZrkkmIpZS1u U09w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l0zffywgBZTo9HvFXjJ5DIYeJBwzAPwVakDAvaxKQYc=; b=RHxxREYI94Av9wWSBEPzBSiaMPeDIFyp3+Y/0JJl/WGnyrcjm6LBNq66qr6d8idloZ 6e4xy2M3HiSZohhcBmns2FHfmtCG4ZOMTKQzpZMlPRaOFtCn5g3fGkZaUh+/EVqEln92 UYqRhLC14D5nZQjnQd9872qGatVWOog1D5s7rbyKNkym6lnj8RvWnhgvWb9ebrnvsb/9 V7AVePuIXPomnR3RRi/Gl8wkopBONm2Lstmd2CQnTkffxrfxjcvBiWBT35dyXIea6CDZ 50YdqG6FHksSOpFXv/q4XicYzg8GIyZXW8ZkqcYHIg7xsUKl+1t7T800agxmyU4cj9FK J+sg== X-Gm-Message-State: AOAM531eIMD/jCmEqgm4zjvrkTAgpTUtATtFpcagFq6YqTIn1HtG5e8J rdusIAlwQukqH8/BErIBwJzmzcHfCS1EmNGofTg= X-Google-Smtp-Source: ABdhPJx6aesoQGTlE96ZoCs/orJ8fifBYUESmEsaos0AIVoNhrSp7TkjSVH2Lhr0ueUzshgBXsUj3I7cCQOXpDvgO/4= X-Received: by 2002:aed:3b0e:: with SMTP id p14mr24307730qte.149.1595252481057; Mon, 20 Jul 2020 06:41:21 -0700 (PDT) MIME-Version: 1.0 References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> <04d5eb82da794b9489474597cdb7fd11@huawei.com> In-Reply-To: <04d5eb82da794b9489474597cdb7fd11@huawei.com> From: Jen Linkova Date: Mon, 20 Jul 2020 23:41:09 +1000 Message-ID: To: Vasilenko Eduard Cc: JORDI PALET MARTINEZ , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 13:41:25 -0000 On Mon, Jul 20, 2020 at 10:13 PM Vasilenko Eduard wrote: > How smartTV would start to ask furry.example.com in 1st place? > It could ask netflix.com and some other limited number of FQDN. Do you be= lieve anybody from these respected companies would be doing what you have d= escribed below? > If user is going somewhere (FQDN) - it is already some level of trust, be= cause even 1st web page could have many security problems. Smart TVs do have browsers. I use the browser on my TV to watch online translations. Maybe I shouldn't. Browsers are used to open web-pages. Webpages could contain links and ads.. > By the way, before successfully redirecting IPv6 traffic to itself (by be= low presented methodology), > Such web site (furry.example.com) would already redirect many normal IPv4= users to Youtube. People would start to complain - somebody could notice. Except I do not need them to *open* the webpage. I only need them to resolve the name in the URL. Think about smth like Ads-based measurements Geoff Huston runs at APNIC. Or a browser with speculative pre-connections enabled. > And the evidence would stick in cache on many DNS servers. It is very tra= ceable to attacker. I really doubt anyone would trace it. The ISP support would probably ask the user to 'reboot the CPE' first. > What could be the reason to ask anything on FQDN furry.example.com, if on= e would never see this website (youtube would be substituted). For the same reason my laptop's just asked 'what's the A RR for 0du-results-u52855d7e-c13-a9533-s1595251604-i74ff1172-0.ap.dotnxdomain.net.= ' > I do not have strict opinion what to do about it. > It is definitely new attack vector introduce by this draft, but not very = dangerous ... > Anyway, but IETF rules - it should be at least documented in mandatory Se= curity section. Many people should decide. Yes, that's the point: this needs to be discussed in the Security Considerations and I'm not convinced that per-host EAMT mitigates the issue completely. > -----Original Message----- > From: Jen Linkova [mailto:furry13@gmail.com] > Sent: 20 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 13:44 > To: Vasilenko Eduard > Cc: JORDI PALET MARTINEZ ;= V6 Ops List > Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and= the rest > > On Mon, Jul 20, 2020 at 6:16 PM Vasilenko Eduard wrote: > >> An example attack here is that a client has an A record > >> for "www.example.com" pointing to 192.0.2.1 cached past > >> its TTL so the EAMT record is gone. An attacker convinces > >> another user in the same home network to do a DNS lookup > >> that has an A record of 192.0.2..1 (which the attacker doesn't own) > >> but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlle= d). > >> Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or nev= er > >> existed then the attacker can redirect all traffic to it to an IPv6 = address > >> of their choice. No DNS spoofing is needed here at all, just making > >> a "claim" that the A/AAAA are associated (which has no authenticatio= n). > >> This is potentially worse as I'd hypothesize that IPv4-only STB > >> clients are much less likely to use HTTPS/TLS.. > > > > [Jordi] I think that having a per-host EAMT entries resolves this. > > [Eduard] I believe that this draft (that simulate normal hosts) could n= ot resolve this problem in principle. > > If somebody are capable to program 3rd party FQDN to fake AAAA record (= of his), then the whole internet would be affected. > > The attack does not require to fake AAAA RR for someone's else FQDN. > The attacker owns the FQDN and can put whatever they want there, includin= g the victim server IPv4 address. > Let's say I own furry.example.com. I tricked your IPv4-only TV to ask for= A RR for that name. I returned you an IPv4 address of www.youtube.com as A= and - when the smart CPE asks for AAAA, IPv6 address of my own server. Now= your smart TV would be sending traffic to my server instead of Youtube. > I totally agree that binding the EAMT entry to the source IPv4 address li= mits the impact for a single device and makes the attack harder to implemen= t (you need to trick the same device into resolving my evil FQDN, which is = not as easy as tricking my laptop into it). > > > And DNS standards have a lot of tools against this. > > I'm not sure there is anything in DNS preventing me from putting the > IPv4 address of www.huawei.com into the zone file for a domain name I own= . > > -- > SY, Jen Linkova aka Furry --=20 SY, Jen Linkova aka Furry From nobody Mon Jul 20 08:27:24 2020 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 4244B3A0C58 for ; Mon, 20 Jul 2020 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxo3KaEsb99p for ; Mon, 20 Jul 2020 08:27:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3A1153A0C54 for ; Mon, 20 Jul 2020 08:27:20 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1F53F2592D64498088C5; Mon, 20 Jul 2020 16:27:18 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 20 Jul 2020 16:27:01 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 18:27:00 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 18:27:00 +0300 From: Vasilenko Eduard To: Jen Linkova , JORDI PALET MARTINEZ CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest Thread-Index: AQHWXhc/K6tozmRt0kKaAvFhAK9ImakQFg/ggAAAyoCAAEM64P//7k2AgABFGMA= Date: Mon, 20 Jul 2020 15:27:00 +0000 Message-ID: <92b0db11479d4c5aa949776ccb42e899@huawei.com> References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> <04d5eb82da794b9489474597cdb7fd11@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: multipart/alternative; boundary="_000_92b0db11479d4c5aa949776ccb42e899huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 15:27:23 -0000 --_000_92b0db11479d4c5aa949776ccb42e899huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVuLA0KDQpUaGFua3MgdGhhdCB5b3UgaGF2ZSBwdXNoZWQgdGhpcyBhdHRhY2sgdmVjdG9y IHNvIGZhci4NCg0KSSBiZWxpZXZlIHRoYXQgSSBoYXZlIHBvc3NpYmlsaXR5IG5vdyB0byBleHBs YWluIHRoYXQgaXQgaXMgbm90IHJlbGV2YW50Lg0KDQpOb3QgYmVjYXVzZSBpdCBpcyB3cm9uZy4g QnV0IGJlY2F1c2UgY3VycmVudCBzb2x1dGlvbiB3b3VsZCBub3QgbGl2ZSB0byB0aGUgcG9pbnQg dG8gdGVzdCB0aGlzIHZ1bG5lcmFiaWxpdHkuIEl0IGhhcyBtdWNoIGJpZ2dlciBmdW5jdGlvbmFs IHByb2JsZW0gdGhhdCB3b3VsZCBwcmV2ZW50IGl0IHRvIHN1cnZpdmUuDQoNCg0KDQpMZXQncyBs b29rIHRvIHVzZSBjYXNlIHdoZW4gb25lIHByaXZhdGUgSVB2NCBob3N0IHdvdWxkIGNvbnRhY3Qg c2FtZSBzbWFsbCBob3N0aW5nIHdoZXJlIG1hbnkgRlFETnMgYXJlIGF0dGFjaGVkIHRvIHNpbmds ZSBJUHY0LCBidXQgZGlmZmVyZW50IElQdjYg4oCTIGFuZCBpdCBpcyBub3JtYWwvcGVybWFuZW50 IHNpdHVhdGlvbiBmb3IgdGhpcyBob3N0aW5nIHByb3ZpZGVyLiBJdCBpcyBjb3JuZXIgY2FzZSwg YnV0IG5vdCBleHRyZW1lbHkgdW51c3VhbC4NCg0KVGhlbiAyIEVBTSByZWNvcmRzIHNob3VsZCBi ZSBjcmVhdGVkOg0KDQo8UHJpdmF0ZSBJUHY0IChzb3VyY2UgY2xpZW50KSwgRlFETjEsIElQdjQg KGRlc3RpbmF0aW9uIHNlcnZlciksIElQdjZfYSAoZGVzdGluYXRpb24gc2VydmVyKT4NCg0KPFBy aXZhdGUgSVB2NCAodGhlIHNhbWUgc291cmNlIGNsaWVudCksIEZRRE4yLCBJUHY0ICh0aGUgc2Ft ZSBkZXN0aW5hdGlvbiBzZXJ2ZXIpLCBJUHY2X2IgKGRpZmZlcmVudCBkZXN0aW5hdGlvbiBzZXJ2 ZXIpPg0KDQpJdCBpcyBmaW5lIGZvciBETlMgcHJvY2VzcywgYnV0IGxvb2sgdG8gdGhlIHByb2Js ZW0gZm9yIFBGRSBub3c6IFBGRSB3b3VsZCByZWNlaXZlIElQIHBhY2tldCB3aXRoIDxQcml2YXRl IElQdjQgKHNvdXJjZSBjbGllbnQpLCBJUHY0IChkZXN0aW5hdGlvbiBzZXJ2ZXIpPi4NCg0KV2hh dCBFQU0gcmVjb3JkIHNob3VsZCBiZSB1c2VkIGZvciBmb3J3YXJkaW5nPyE/IEVzcGVjaWFsbHkg aWYgaXQgaXMgMXN0IHBhY2tldCBmb3IgdGhlIG5ldyBmbG93IC0gZXZlbiBmdWxsIHBlci1mbG93 IHN0YXRlZnVsIG1hY2hpbmUgd291bGQgbm90IGhlbHAgaGVyZS4NCg0KDQoNCkhlbmNlLCBJIGhh dmUgdG8gc3RhdGUgYWdhaW4gKHByZXZpb3VzIHRpbWUgSSBkaWQgaXQgZm9yIFBoaWxpcCdzIGNo YWxsZW5nZSBvZiBwYXJ0aWFsbHkgbWlncmF0ZWQgSVB2NiBob3N0KToNCg0Kd2UgaGF2ZSB0byBr ZWVwIHN0YXRlcyBmb3IgY29sbGlzaW9ucyBvZiA8UHJpdmF0ZSBJUHY0IChzb3VyY2UgY2xpZW50 KSwgSVB2NCAoZGVzdGluYXRpb24gc2VydmVyKT4gcGFpcnMgd2l0aCBmbGFnICJEaXNhYmxlZCIg Zm9yZXZlci4gVGhpcyB0cmFmZmljIHNob3VsZCBnbyB0byBQTEFULg0KDQpCdXQgaW4gdGhpcyBj YXNlIHdpdGggbXVjaCBiaWdnZXIgY29uc2VxdWVuY2VzOiB3ZSBzaG91bGQgZHJvcCB1c2VyIHNl c3Npb24gdGhhdCB3YXMgc3VwcG9zZWQgdG8gZmxvdyBhZ2FpbnN0IDFzdCBFQU0gcmVjb3JkIChp dCB3YXMgdW5pcXVlIGJlZm9yZSBjb2xsaXNpb24pLiBCZWNhdXNlIHdlIGNvdWxkIG5vdCBiZSBz dXJlIGFueW1vcmUgdGhhdCB3ZSB3b3VsZCBzd2l0Y2ggdHJhZmZpYyB0byBwcm9wZXIgZGVzdGlu YXRpb24uDQoNCkFmdGVyIENQRSByZWxvYWQgd2Ugd291bGQgcHJvYmFibHkgZHJvcCB1c2VyIHNl c3Npb24gYWdhaW4g4oCTIENQRSBuZWVkcyB0byBsZWFybiBkaXNhYmxlZCBjb21iaW5hdGlvbnMg YnkgRE5TIHJlcXVlc3RzLiBJZiBVc2VyIGhhcyBjb250YWN0ZWQgdGhpcyBjb21iaW5hdGlvbiBv ZiBGUUROcyBvbmUgdGltZSDigJMgaGlnaCBwcm9iYWJpbGl0eSB0aGF0IGhlIHdvdWxkIGRvIGl0 IGFnYWluLg0KDQoNCg0KSXQgaXMgYWdhaW4gIndlIHdvdWxkIGtlZXAgc3RhdGVzIGZvciBub3Qg dG8gdXNlIGl0Ii4gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIG5vdCB0b28gbWFueSBzdGF0ZXMgaW4g bm9ybWFsIHNpdHVhdGlvbiwgYnV0IGF0dGFja2VyIGNvdWxkIG9yZ2FuaXplIEREb1MgZm9yIENh cnJpZXIgQ1BFcy4gRUFNVCB0YWJsZSBzaG91bGQgYmUgbGltaXRlZCBhbmQgYWZ0ZXIgdGhlIGxp bWl0IC0gdHJhZmZpYyBzaG91bGQgZ28gb25seSB0byBQTEFULiBWZW5kb3JzIHNob3VsZCBkZWNp ZGUgYnkgdGhlbXNlbHZlcyBob3cgbWFueSBFQU1UIGVudHJpZXMgdGhleSBhZ3JlZSB0byBzdXBw b3J0IOKAkyBpdCB3b3VsZCBiZSBkZXBlbmRlbnQgb24gbWVtb3J5IGFuZCBDUFUuDQoNCg0KDQpK aW4sIGlmIHlvdSB3b3VsZCBzdWJzdGl0dXRlIEZRRE4xIGJ5ICJmdXJyeS5leGFtcGxlLmNvbSIg YW5kIEZRRE4yIGJ5ICJ5b3V0dWJlLmNvbSIgLSB5b3Ugd291bGQgZ2V0IGV4YWN0bHkgeW91ciBz ZWN1cml0eSBjb25jZXJuLiBKdXN0IGNyZWF0ZWQgaW50ZW50aW9uYWxseSDigJMgSSBoYXZlIHBy ZXNlbnRlZCBhYm92ZSBuYXR1cmFsIGNhc2UuDQoNCkkgbmVlZCB0byB0ZWxsIHRoYXQgZm9yIHNl Y3VyaXR5IHByb2JsZW0gdG8gaGFwcGVuIGl0IHdhcyBtYW5kYXRvcnkgdGhhdCBzZWNvbmQgcmVz b2x1dGlvbiAoeW91dHViZS5jb20pIHNob3VsZCBiZSAxc3QsIHRoZW4gZnVycnkuZXhhbXBsZS5j b20gZm9yIGhpamFjaywNCg0KQmVjYXVzZSBpbiBvcHBvc2l0ZSBvcmRlciBwcm9wZXIgRlFETiBq dXN0IG92ZXJyaWRlIGZha2Ugb25lIOKAkyBpdCB3YXMgdGhlIHByZXZpb3VzICh3cm9uZykgYXNz dW1wdGlvbiBob3cgaXQgc2hvdWxkIG9wZXJhdGUuDQoNCkJ1dCBpdCB3b3VsZCBub3QgaGFwcGVu IGFueXdheSwgYmVjYXVzZSBQRkUgd291bGQgbm90IGJlIGNhcGFibGUgdG8gc29ydCBvdXQgc3Vj aCBjb2xsaXNpb24gaW4gcHJpbmNpcGxlLiBPdmVycmlkZSBpcyBub3QgYW4gb3B0aW9uIGhlcmUu DQoNCg0KDQpFZHVhcmQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEplbiBM aW5rb3ZhIFttYWlsdG86ZnVycnkxM0BnbWFpbC5jb21dDQpTZW50OiAyMCDQuNGO0LvRjyAyMDIw INCzLiAxNjo0MQ0KVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2Vp LmNvbT4NCkNjOiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXQ9NDBjb25zdWxpbnRl bC5lc0BkbWFyYy5pZXRmLm9yZz47IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDIg LSA1LjIuNiBhbmQgdGhlIHJlc3QNCg0KDQoNCk9uIE1vbiwgSnVsIDIwLCAyMDIwIGF0IDEwOjEz IFBNIFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86 dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCj4gSG93IHNtYXJ0VFYgd291 bGQgc3RhcnQgdG8gYXNrIGZ1cnJ5LmV4YW1wbGUuY29tIGluIDFzdCBwbGFjZT8NCg0KPiBJdCBj b3VsZCBhc2sgbmV0ZmxpeC5jb20gYW5kIHNvbWUgb3RoZXIgbGltaXRlZCBudW1iZXIgb2YgRlFE Ti4gRG8geW91IGJlbGlldmUgYW55Ym9keSBmcm9tIHRoZXNlIHJlc3BlY3RlZCBjb21wYW5pZXMg d291bGQgYmUgZG9pbmcgd2hhdCB5b3UgaGF2ZSBkZXNjcmliZWQgYmVsb3c/DQoNCj4gSWYgdXNl ciBpcyBnb2luZyBzb21ld2hlcmUgKEZRRE4pIC0gaXQgaXMgYWxyZWFkeSBzb21lIGxldmVsIG9m IHRydXN0LCBiZWNhdXNlIGV2ZW4gMXN0IHdlYiBwYWdlIGNvdWxkIGhhdmUgbWFueSBzZWN1cml0 eSBwcm9ibGVtcy4NCg0KDQoNClNtYXJ0IFRWcyBkbyBoYXZlIGJyb3dzZXJzLiBJIHVzZSB0aGUg YnJvd3NlciBvbiBteSBUViB0byB3YXRjaCBvbmxpbmUgdHJhbnNsYXRpb25zLiBNYXliZSBJIHNo b3VsZG4ndC4NCg0KQnJvd3NlcnMgYXJlIHVzZWQgdG8gb3BlbiB3ZWItcGFnZXMuIFdlYnBhZ2Vz IGNvdWxkIGNvbnRhaW4gbGlua3MgYW5kIGFkcy4uDQoNCg0KDQo+IEJ5IHRoZSB3YXksIGJlZm9y ZSBzdWNjZXNzZnVsbHkgcmVkaXJlY3RpbmcgSVB2NiB0cmFmZmljIHRvIGl0c2VsZiAoYnkNCg0K PiBiZWxvdyBwcmVzZW50ZWQgbWV0aG9kb2xvZ3kpLCBTdWNoIHdlYiBzaXRlIChmdXJyeS5leGFt cGxlLmNvbSkgd291bGQgYWxyZWFkeSByZWRpcmVjdCBtYW55IG5vcm1hbCBJUHY0IHVzZXJzIHRv IFlvdXR1YmUuIFBlb3BsZSB3b3VsZCBzdGFydCB0byBjb21wbGFpbiAtIHNvbWVib2R5IGNvdWxk IG5vdGljZS4NCg0KDQoNCkV4Y2VwdCBJIGRvIG5vdCBuZWVkIHRoZW0gdG8gKm9wZW4qIHRoZSB3 ZWJwYWdlLiBJIG9ubHkgbmVlZCB0aGVtIHRvIHJlc29sdmUgdGhlIG5hbWUgaW4gdGhlIFVSTC4N Cg0KVGhpbmsgYWJvdXQgc210aCBsaWtlIEFkcy1iYXNlZCBtZWFzdXJlbWVudHMgR2VvZmYgSHVz dG9uIHJ1bnMgYXQgQVBOSUMuDQoNCk9yIGEgYnJvd3NlciB3aXRoIHNwZWN1bGF0aXZlIHByZS1j b25uZWN0aW9ucyBlbmFibGVkLg0KDQoNCg0KPiBBbmQgdGhlIGV2aWRlbmNlIHdvdWxkIHN0aWNr IGluIGNhY2hlIG9uIG1hbnkgRE5TIHNlcnZlcnMuIEl0IGlzIHZlcnkgdHJhY2VhYmxlIHRvIGF0 dGFja2VyLg0KDQoNCg0KSSByZWFsbHkgZG91YnQgYW55b25lIHdvdWxkIHRyYWNlIGl0LiBUaGUg SVNQIHN1cHBvcnQgd291bGQgcHJvYmFibHkgYXNrIHRoZSB1c2VyIHRvICdyZWJvb3QgdGhlIENQ RScgZmlyc3QuDQoNCg0KDQo+IFdoYXQgY291bGQgYmUgdGhlIHJlYXNvbiB0byBhc2sgYW55dGhp bmcgb24gRlFETiBmdXJyeS5leGFtcGxlLmNvbSwgaWYgb25lIHdvdWxkIG5ldmVyIHNlZSB0aGlz IHdlYnNpdGUgKHlvdXR1YmUgd291bGQgYmUgc3Vic3RpdHV0ZWQpLg0KDQoNCg0KRm9yIHRoZSBz YW1lIHJlYXNvbiBteSBsYXB0b3AncyBqdXN0IGFza2VkICd3aGF0J3MgdGhlIEEgUlIgZm9yIDBk dS1yZXN1bHRzLXU1Mjg1NWQ3ZS1jMTMtYTk1MzMtczE1OTUyNTE2MDQtaTc0ZmYxMTcyLTAuYXAu ZG90bnhkb21haW4ubmV0LicNCg0KDQoNCj4gSSBkbyBub3QgaGF2ZSBzdHJpY3Qgb3BpbmlvbiB3 aGF0IHRvIGRvIGFib3V0IGl0Lg0KDQo+IEl0IGlzIGRlZmluaXRlbHkgbmV3IGF0dGFjayB2ZWN0 b3IgaW50cm9kdWNlIGJ5IHRoaXMgZHJhZnQsIGJ1dCBub3QgdmVyeSBkYW5nZXJvdXMgLi4uDQoN Cj4gQW55d2F5LCBidXQgSUVURiBydWxlcyAtIGl0IHNob3VsZCBiZSBhdCBsZWFzdCBkb2N1bWVu dGVkIGluIG1hbmRhdG9yeSBTZWN1cml0eSBzZWN0aW9uLiBNYW55IHBlb3BsZSBzaG91bGQgZGVj aWRlLg0KDQoNCg0KWWVzLCB0aGF0J3MgdGhlIHBvaW50OiB0aGlzIG5lZWRzIHRvIGJlIGRpc2N1 c3NlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYW5kIEknbSBub3QgY29udmluY2Vk IHRoYXQgcGVyLWhvc3QgRUFNVCBtaXRpZ2F0ZXMgdGhlIGlzc3VlIGNvbXBsZXRlbHkuDQoNCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogSmVuIExpbmtvdmEgW21h aWx0bzpmdXJyeTEzQGdtYWlsLmNvbV0NCg0KPiBTZW50OiAyMCDQuNGO0LvRjyAyMDIwINCzLiAx Mzo0NA0KDQo+IFRvOiBWYXNpbGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5j b208bWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4+DQoNCj4gQ2M6IEpPUkRJIFBB TEVUIE1BUlRJTkVaDQoNCj4gPGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOmpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+ PjsgVjYgT3BzIExpc3QNCg0KPiA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3Jn Pj4NCg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0 aW1pemF0aW9uLTAyIC0gNS4yLjYNCg0KPiBhbmQgdGhlIHJlc3QNCg0KPg0KDQo+IE9uIE1vbiwg SnVsIDIwLCAyMDIwIGF0IDY6MTYgUE0gVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFy ZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiB3cm90ZToN Cg0KPiA+PiAgIEFuIGV4YW1wbGUgYXR0YWNrIGhlcmUgaXMgdGhhdCBhIGNsaWVudCBoYXMgYW4g QSByZWNvcmQNCg0KPiA+PiAgIGZvciAid3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBs ZS5jb20+IiBwb2ludGluZyB0byAxOTIuMC4yLjEgY2FjaGVkIHBhc3QNCg0KPiA+PiAgIGl0cyBU VEwgc28gdGhlIEVBTVQgcmVjb3JkIGlzIGdvbmUuICBBbiBhdHRhY2tlciBjb252aW5jZXMNCg0K PiA+PiAgIGFub3RoZXIgdXNlciBpbiB0aGUgc2FtZSBob21lIG5ldHdvcmsgdG8gZG8gYSBETlMg bG9va3VwDQoNCj4gPj4gICB0aGF0IGhhcyBhbiBBIHJlY29yZCBvZiAxOTIuMC4yLi4xICh3aGlj aCB0aGUgYXR0YWNrZXIgZG9lc24ndA0KDQo+ID4+IG93bikgYnV0IGEgQUFBQSByZWNvcmQgZm9y IDIwMDE6ZGI4OmVlZWU6OmVlZWUgKHdoaWNoIGlzIGF0dGFja2VyLWNvbnRyb2xsZWQpLg0KDQo+ ID4+ICAgRXZlbiBpZiAxOTIuMC4yLjEgaXMgSVB2NC1vbmx5LCBpZiB0aGUgRUFNVCBlbnRyeSBo YXMgZXhwaXJlZCBvciBuZXZlcg0KDQo+ID4+ICAgZXhpc3RlZCB0aGVuIHRoZSBhdHRhY2tlciBj YW4gcmVkaXJlY3QgYWxsIHRyYWZmaWMgdG8gaXQgdG8gYW4gSVB2NiBhZGRyZXNzDQoNCj4gPj4g ICBvZiB0aGVpciBjaG9pY2UuICBObyBETlMgc3Bvb2ZpbmcgaXMgbmVlZGVkIGhlcmUgYXQgYWxs LCBqdXN0IG1ha2luZw0KDQo+ID4+ICAgYSAiY2xhaW0iIHRoYXQgdGhlIEEvQUFBQSBhcmUgYXNz b2NpYXRlZCAod2hpY2ggaGFzIG5vIGF1dGhlbnRpY2F0aW9uKS4NCg0KPiA+PiAgIFRoaXMgaXMg cG90ZW50aWFsbHkgd29yc2UgYXMgSSdkIGh5cG90aGVzaXplIHRoYXQgSVB2NC1vbmx5IFNUQg0K DQo+ID4+ICAgY2xpZW50cyBhcmUgbXVjaCBsZXNzIGxpa2VseSB0byB1c2UgSFRUUFMvVExTLi4N Cg0KPiA+DQoNCj4gPiBbSm9yZGldIEkgdGhpbmsgdGhhdCBoYXZpbmcgYSBwZXItaG9zdCBFQU1U IGVudHJpZXMgcmVzb2x2ZXMgdGhpcy4NCg0KPiA+IFtFZHVhcmRdIEkgYmVsaWV2ZSB0aGF0IHRo aXMgZHJhZnQgKHRoYXQgc2ltdWxhdGUgbm9ybWFsIGhvc3RzKSBjb3VsZCBub3QgcmVzb2x2ZSB0 aGlzIHByb2JsZW0gaW4gcHJpbmNpcGxlLg0KDQo+ID4gSWYgc29tZWJvZHkgYXJlIGNhcGFibGUg dG8gcHJvZ3JhbSAzcmQgcGFydHkgRlFETiB0byBmYWtlIEFBQUEgcmVjb3JkIChvZiBoaXMpLCB0 aGVuIHRoZSB3aG9sZSBpbnRlcm5ldCB3b3VsZCBiZSBhZmZlY3RlZC4NCg0KPg0KDQo+IFRoZSBh dHRhY2sgZG9lcyBub3QgcmVxdWlyZSB0byBmYWtlIEFBQUEgUlIgZm9yIHNvbWVvbmUncyBlbHNl IEZRRE4uDQoNCj4gVGhlIGF0dGFja2VyIG93bnMgdGhlIEZRRE4gYW5kIGNhbiBwdXQgd2hhdGV2 ZXIgdGhleSB3YW50IHRoZXJlLCBpbmNsdWRpbmcgdGhlIHZpY3RpbSBzZXJ2ZXIgSVB2NCBhZGRy ZXNzLg0KDQo+IExldCdzIHNheSBJIG93biBmdXJyeS5leGFtcGxlLmNvbS4gSSB0cmlja2VkIHlv dXIgSVB2NC1vbmx5IFRWIHRvIGFzayBmb3IgQSBSUiBmb3IgdGhhdCBuYW1lLiBJIHJldHVybmVk IHlvdSBhbiBJUHY0IGFkZHJlc3Mgb2Ygd3d3LnlvdXR1YmUuY29tPGh0dHA6Ly93d3cueW91dHVi ZS5jb20+IGFzIEEgYW5kIC0gd2hlbiB0aGUgc21hcnQgQ1BFIGFza3MgZm9yIEFBQUEsIElQdjYg YWRkcmVzcyBvZiBteSBvd24gc2VydmVyLiBOb3cgeW91ciBzbWFydCBUViB3b3VsZCBiZSBzZW5k aW5nIHRyYWZmaWMgdG8gbXkgc2VydmVyIGluc3RlYWQgb2YgWW91dHViZS4NCg0KPiBJIHRvdGFs bHkgYWdyZWUgdGhhdCBiaW5kaW5nIHRoZSBFQU1UIGVudHJ5IHRvIHRoZSBzb3VyY2UgSVB2NCBh ZGRyZXNzIGxpbWl0cyB0aGUgaW1wYWN0IGZvciBhIHNpbmdsZSBkZXZpY2UgYW5kIG1ha2VzIHRo ZSBhdHRhY2sgaGFyZGVyIHRvIGltcGxlbWVudCAoeW91IG5lZWQgdG8gdHJpY2sgdGhlIHNhbWUg ZGV2aWNlIGludG8gcmVzb2x2aW5nIG15IGV2aWwgRlFETiwgd2hpY2ggaXMgbm90IGFzIGVhc3kg YXMgdHJpY2tpbmcgbXkgbGFwdG9wIGludG8gaXQpLg0KDQo+DQoNCj4gPiBBbmQgRE5TIHN0YW5k YXJkcyBoYXZlIGEgbG90IG9mIHRvb2xzIGFnYWluc3QgdGhpcy4NCg0KPg0KDQo+IEknbSBub3Qg c3VyZSB0aGVyZSBpcyBhbnl0aGluZyBpbiBETlMgcHJldmVudGluZyBtZSBmcm9tIHB1dHRpbmcg dGhlDQoNCj4gSVB2NCBhZGRyZXNzIG9mIHd3dy5odWF3ZWkuY29tPGh0dHA6Ly93d3cuaHVhd2Vp LmNvbT4gaW50byB0aGUgem9uZSBmaWxlIGZvciBhIGRvbWFpbiBuYW1lIEkgb3duLg0KDQo+DQoN Cj4gLS0NCg0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQoNCg0KDQoNCg0KDQoNCi0tDQoN ClNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg== --_000_92b0db11479d4c5aa949776ccb42e899huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkgSmVuLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIHRoYXQgeW91IGhhdmUgcHVzaGVk IHRoaXMgYXR0YWNrIHZlY3RvciBzbyBmYXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGJlbGlldmUgdGhhdCBJIGhhdmUgcG9zc2liaWxpdHkgbm93IHRvIGV4cGxh aW4gdGhhdCBpdCBpcyBub3QgcmVsZXZhbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Ob3QgYmVjYXVzZSBpdCBpcyB3cm9uZy4gQnV0IGJlY2F1c2UgY3VycmVudCBz b2x1dGlvbiB3b3VsZCBub3QgbGl2ZSB0byB0aGUgcG9pbnQgdG8gdGVzdCB0aGlzIHZ1bG5lcmFi aWxpdHkuIEl0IGhhcyBtdWNoIGJpZ2dlciBmdW5jdGlvbmFsIHByb2JsZW0gdGhhdCB3b3VsZCBw cmV2ZW50IGl0IHRvIHN1cnZpdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkxldCdz IGxvb2sgdG8gdXNlIGNhc2Ugd2hlbiBvbmUgcHJpdmF0ZSBJUHY0IGhvc3Qgd291bGQgY29udGFj dCBzYW1lIHNtYWxsIGhvc3Rpbmcgd2hlcmUgbWFueSBGUUROcyBhcmUgYXR0YWNoZWQgdG8gc2lu Z2xlIElQdjQsIGJ1dCBkaWZmZXJlbnQgSVB2NiDigJMgYW5kIGl0IGlzIG5vcm1hbC9wZXJtYW5l bnQgc2l0dWF0aW9uIGZvciB0aGlzIGhvc3RpbmcgcHJvdmlkZXIuIEl0IGlzIGNvcm5lciBjYXNl LA0KIGJ1dCBub3QgZXh0cmVtZWx5IHVudXN1YWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UaGVuIDIgRUFNIHJlY29yZHMgc2hvdWxkIGJlIGNyZWF0ZWQ6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7UHJpdmF0ZSBJUHY0IChzb3Vy Y2UgY2xpZW50KSwgRlFETjEsIElQdjQgKGRlc3RpbmF0aW9uIHNlcnZlciksIElQdjZfYSAoZGVz dGluYXRpb24gc2VydmVyKSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZsdDtQcml2YXRlIElQdjQgKHRoZSBzYW1lIHNvdXJjZSBjbGllbnQpLCBGUUROMiwgSVB2 NCAodGhlIHNhbWUgZGVzdGluYXRpb24gc2VydmVyKSwgSVB2Nl9iIChkaWZmZXJlbnQgZGVzdGlu YXRpb24gc2VydmVyKSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pkl0IGlzIGZpbmUgZm9yIEROUyBwcm9jZXNzLCBidXQgbG9vayB0byB0aGUgcHJvYmxlbSBmb3Ig UEZFIG5vdzogUEZFIHdvdWxkIHJlY2VpdmUgSVAgcGFja2V0IHdpdGggJmx0O1ByaXZhdGUgSVB2 NCAoc291cmNlIGNsaWVudCksIElQdjQgKGRlc3RpbmF0aW9uIHNlcnZlcikmZ3Q7LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hhdCBFQU0gcmVjb3JkIHNob3VsZCBi ZSB1c2VkIGZvciBmb3J3YXJkaW5nPyE/IEVzcGVjaWFsbHkgaWYgaXQgaXMgMXN0IHBhY2tldCBm b3IgdGhlIG5ldyBmbG93IC0gZXZlbiBmdWxsIHBlci1mbG93IHN0YXRlZnVsIG1hY2hpbmUgd291 bGQgbm90IGhlbHAgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGVuY2UsIEkg aGF2ZSB0byBzdGF0ZSBhZ2FpbiAocHJldmlvdXMgdGltZSBJIGRpZCBpdCBmb3IgUGhpbGlwJ3Mg Y2hhbGxlbmdlIG9mIHBhcnRpYWxseSBtaWdyYXRlZCBJUHY2IGhvc3QpOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+d2UgaGF2ZSB0byBrZWVwIHN0YXRlcyBmb3Ig Y29sbGlzaW9ucyBvZiAmbHQ7UHJpdmF0ZSBJUHY0IChzb3VyY2UgY2xpZW50KSwgSVB2NCAoZGVz dGluYXRpb24gc2VydmVyKSZndDsgcGFpcnMgd2l0aCBmbGFnICZxdW90O0Rpc2FibGVkJnF1b3Q7 IGZvcmV2ZXIuDQo8L2I+VGhpcyB0cmFmZmljIHNob3VsZCBnbyB0byBQTEFULjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QnV0IGluIHRoaXMgY2FzZSB3aXRoIG11Y2gg YmlnZ2VyIGNvbnNlcXVlbmNlczogd2Ugc2hvdWxkIGRyb3AgdXNlciBzZXNzaW9uIHRoYXQgd2Fz IHN1cHBvc2VkIHRvIGZsb3cgYWdhaW5zdCAxc3QgRUFNIHJlY29yZCAoaXQgd2FzIHVuaXF1ZSBi ZWZvcmUgY29sbGlzaW9uKS4gQmVjYXVzZSB3ZSBjb3VsZCBub3QgYmUgc3VyZSBhbnltb3JlIHRo YXQgd2Ugd291bGQgc3dpdGNoIHRyYWZmaWMgdG8gcHJvcGVyDQogZGVzdGluYXRpb24uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BZnRlciBDUEUgcmVsb2FkIHdlIHdv dWxkIHByb2JhYmx5IGRyb3AgdXNlciBzZXNzaW9uIGFnYWluIOKAkyBDUEUgbmVlZHMgdG8gbGVh cm4gZGlzYWJsZWQgY29tYmluYXRpb25zIGJ5IEROUyByZXF1ZXN0cy4gSWYgVXNlciBoYXMgY29u dGFjdGVkIHRoaXMgY29tYmluYXRpb24gb2YgRlFETnMgb25lIHRpbWUg4oCTIGhpZ2ggcHJvYmFi aWxpdHkgdGhhdCBoZSB3b3VsZCBkbyBpdCBhZ2Fpbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SXQgaXMgYWdhaW4gJnF1b3Q7d2Ugd291bGQga2VlcCBzdGF0ZXMgZm9yIG5vdCB0byB1 c2UgaXQmcXVvdDsuIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBub3QgdG9vIG1hbnkgc3RhdGVzIGlu IG5vcm1hbCBzaXR1YXRpb24sIGJ1dCBhdHRhY2tlciBjb3VsZCBvcmdhbml6ZSBERG9TIGZvciBD YXJyaWVyIENQRXMuIEVBTVQgdGFibGUgc2hvdWxkIGJlIGxpbWl0ZWQgYW5kIGFmdGVyIHRoZSBs aW1pdCAtIHRyYWZmaWMgc2hvdWxkDQogZ28gb25seSB0byBQTEFULiBWZW5kb3JzIHNob3VsZCBk ZWNpZGUgYnkgdGhlbXNlbHZlcyBob3cgbWFueSBFQU1UIGVudHJpZXMgdGhleSBhZ3JlZSB0byBz dXBwb3J0IOKAkyBpdCB3b3VsZCBiZSBkZXBlbmRlbnQgb24gbWVtb3J5IGFuZCBDUFUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkppbiwgaWYgeW91IHdvdWxkIHN1YnN0aXR1dGUgRlFE TjEgYnkgJnF1b3Q7ZnVycnkuZXhhbXBsZS5jb20mcXVvdDsgYW5kIEZRRE4yIGJ5ICZxdW90O3lv dXR1YmUuY29tJnF1b3Q7IC0geW91IHdvdWxkIGdldCBleGFjdGx5IHlvdXIgc2VjdXJpdHkgY29u Y2Vybi4gSnVzdCBjcmVhdGVkIGludGVudGlvbmFsbHkg4oCTIEkgaGF2ZSBwcmVzZW50ZWQgYWJv dmUgbmF0dXJhbCBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSBuZWVkIHRvIHRlbGwgdGhhdCBmb3Igc2VjdXJpdHkgcHJvYmxlbSB0byBoYXBwZW4gaXQgd2Fz IG1hbmRhdG9yeSB0aGF0IHNlY29uZCByZXNvbHV0aW9uICh5b3V0dWJlLmNvbSkgc2hvdWxkIGJl IDFzdCwgdGhlbiBmdXJyeS5leGFtcGxlLmNvbSBmb3IgaGlqYWNrLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVjYXVzZSBpbiBvcHBvc2l0ZSBvcmRlciBwcm9wZXIg RlFETiBqdXN0IG92ZXJyaWRlIGZha2Ugb25lIOKAkyBpdCB3YXMgdGhlIHByZXZpb3VzICh3cm9u ZykgYXNzdW1wdGlvbiBob3cgaXQgc2hvdWxkIG9wZXJhdGUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5CdXQgaXQgd291bGQgbm90IGhhcHBlbiBhbnl3YXksIGJlY2F1 c2UgUEZFIHdvdWxkIG5vdCBiZSBjYXBhYmxlIHRvIHNvcnQgb3V0IHN1Y2ggY29sbGlzaW9uIGlu IHByaW5jaXBsZS4gT3ZlcnJpZGUgaXMgbm90IGFuIG9wdGlvbiBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5FZHVhcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSmVuIExpbmtvdmEg W21haWx0bzpmdXJyeTEzQGdtYWlsLmNvbV0gPGJyPg0KU2VudDogMjAg0LjRjtC70Y8gMjAyMCDQ sy4gMTY6NDE8YnI+DQpUbzogVmFzaWxlbmtvIEVkdWFyZCAmbHQ7dmFzaWxlbmtvLmVkdWFyZEBo dWF3ZWkuY29tJmd0Ozxicj4NCkNjOiBKT1JESSBQQUxFVCBNQVJUSU5FWiAmbHQ7am9yZGkucGFs ZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZyZndDs7IFY2IE9wcyBMaXN0ICZsdDt2 Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2 b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyIC0gNS4yLjYgYW5kIHRoZSByZXN0PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5PbiBNb24sIEp1bCAyMCwgMjAyMCBhdCAxMDoxMyBQTSBWYXNpbGVua28gRWR1 YXJkICZsdDs8YSBocmVmPSJtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+dmFzaWxlbmtv LmVkdWFyZEBodWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIb3cgc21hcnRUViB3b3VsZCBzdGFydCB0byBh c2sgZnVycnkuZXhhbXBsZS5jb20gaW4gMXN0IHBsYWNlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJdCBjb3VsZCBhc2sgbmV0ZmxpeC5jb20gYW5kIHNvbWUg b3RoZXIgbGltaXRlZCBudW1iZXIgb2YgRlFETi4gRG8geW91IGJlbGlldmUgYW55Ym9keSBmcm9t IHRoZXNlIHJlc3BlY3RlZCBjb21wYW5pZXMgd291bGQgYmUgZG9pbmcgd2hhdCB5b3UgaGF2ZSBk ZXNjcmliZWQgYmVsb3c/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IElmIHVzZXIgaXMgZ29pbmcgc29tZXdoZXJlIChGUUROKSAtIGl0IGlzIGFscmVhZHkgc29t ZSBsZXZlbCBvZiB0cnVzdCwgYmVjYXVzZSBldmVuIDFzdCB3ZWIgcGFnZSBjb3VsZCBoYXZlIG1h bnkgc2VjdXJpdHkgcHJvYmxlbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNtYXJ0 IFRWcyBkbyBoYXZlIGJyb3dzZXJzLiBJIHVzZSB0aGUgYnJvd3NlciBvbiBteSBUViB0byB3YXRj aCBvbmxpbmUgdHJhbnNsYXRpb25zLiBNYXliZSBJIHNob3VsZG4ndC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJyb3dzZXJzIGFyZSB1c2VkIHRvIG9wZW4gd2ViLXBh Z2VzLiBXZWJwYWdlcyBjb3VsZCBjb250YWluIGxpbmtzIGFuZCBhZHMuLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEJ5IHRoZSB3YXksIGJlZm9yZSBzdWNjZXNzZnVsbHkgcmVk aXJlY3RpbmcgSVB2NiB0cmFmZmljIHRvIGl0c2VsZiAoYnkNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBiZWxvdyBwcmVzZW50ZWQgbWV0aG9kb2xvZ3kpLCBT dWNoIHdlYiBzaXRlIChmdXJyeS5leGFtcGxlLmNvbSkgd291bGQgYWxyZWFkeSByZWRpcmVjdCBt YW55IG5vcm1hbCBJUHY0IHVzZXJzIHRvIFlvdXR1YmUuIFBlb3BsZSB3b3VsZCBzdGFydCB0byBj b21wbGFpbiAtIHNvbWVib2R5IGNvdWxkIG5vdGljZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+RXhjZXB0IEkgZG8gbm90IG5lZWQgdGhlbSB0byAqb3BlbiogdGhlIHdlYnBhZ2UuIEkg b25seSBuZWVkIHRoZW0gdG8gcmVzb2x2ZSB0aGUgbmFtZSBpbiB0aGUgVVJMLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpbmsgYWJvdXQgc210aCBsaWtlIEFkcy1i YXNlZCBtZWFzdXJlbWVudHMgR2VvZmYgSHVzdG9uIHJ1bnMgYXQgQVBOSUMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PciBhIGJyb3dzZXIgd2l0aCBzcGVjdWxhdGl2 ZSBwcmUtY29ubmVjdGlvbnMgZW5hYmxlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBBbmQgdGhlIGV2aWRlbmNlIHdvdWxkIHN0aWNrIGluIGNhY2hlIG9uIG1hbnkgRE5TIHNl cnZlcnMuIEl0IGlzIHZlcnkgdHJhY2VhYmxlIHRvIGF0dGFja2VyLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JIHJlYWxseSBkb3VidCBhbnlvbmUgd291bGQgdHJhY2UgaXQuIFRoZSBJ U1Agc3VwcG9ydCB3b3VsZCBwcm9iYWJseSBhc2sgdGhlIHVzZXIgdG8gJ3JlYm9vdCB0aGUgQ1BF JyBmaXJzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBXaGF0IGNvdWxkIGJl IHRoZSByZWFzb24gdG8gYXNrIGFueXRoaW5nIG9uIEZRRE4gZnVycnkuZXhhbXBsZS5jb20sIGlm IG9uZSB3b3VsZCBuZXZlciBzZWUgdGhpcyB3ZWJzaXRlICh5b3V0dWJlIHdvdWxkIGJlIHN1YnN0 aXR1dGVkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Rm9yIHRoZSBzYW1lIHJlYXNv biBteSBsYXB0b3AncyBqdXN0IGFza2VkICd3aGF0J3MgdGhlIEEgUlIgZm9yIDBkdS1yZXN1bHRz LXU1Mjg1NWQ3ZS1jMTMtYTk1MzMtczE1OTUyNTE2MDQtaTc0ZmYxMTcyLTAuYXAuZG90bnhkb21h aW4ubmV0Lic8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJIGRvIG5vdCBoYXZl IHN0cmljdCBvcGluaW9uIHdoYXQgdG8gZG8gYWJvdXQgaXQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEl0IGlzIGRlZmluaXRlbHkgbmV3IGF0dGFjayB2ZWN0 b3IgaW50cm9kdWNlIGJ5IHRoaXMgZHJhZnQsIGJ1dCBub3QgdmVyeSBkYW5nZXJvdXMgLi4uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEFueXdheSwgYnV0IElF VEYgcnVsZXMgLSBpdCBzaG91bGQgYmUgYXQgbGVhc3QgZG9jdW1lbnRlZCBpbiBtYW5kYXRvcnkg U2VjdXJpdHkgc2VjdGlvbi4gTWFueSBwZW9wbGUgc2hvdWxkIGRlY2lkZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+WWVzLCB0aGF0J3MgdGhlIHBvaW50OiB0aGlzIG5lZWRzIHRvIGJl IGRpc2N1c3NlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYW5kIEknbSBub3QgY29u dmluY2VkIHRoYXQgcGVyLWhvc3QgRUFNVCBtaXRpZ2F0ZXMgdGhlIGlzc3VlIGNvbXBsZXRlbHku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTog SmVuIExpbmtvdmEgWzxhIGhyZWY9Im1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbSI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpmdXJyeTEz QGdtYWlsLmNvbTwvc3Bhbj48L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBTZW50OiAyMCDQuNGO0LvRjyAyMDIwINCzLiAxMzo0NDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUbzogVmFzaWxlbmtvIEVkdWFyZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnZhc2lsZW5rby5lZHVhcmRA aHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBDYzogSk9SREkgUEFMRVQgTUFSVElORVogPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am9yZGkucGFs ZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwu ZXNAZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7IFY2IE9wcyBMaXN0DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWll dGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDIgLSA1LjIuNg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFuZCB0aGUgcmVzdDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPbiBNb24sIEp1bCAyMCwgMjAyMCBhdCA2OjE2IFBN IFZhc2lsZW5rbyBFZHVhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1 YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj52YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7IEFuIGV4YW1wbGUgYXR0YWNrIGhlcmUgaXMgdGhhdCBhIGNsaWVudCBoYXMgYW4gQSBy ZWNvcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmbmJzcDsmbmJzcDsgZm9yICZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj53d3cu ZXhhbXBsZS5jb208L3NwYW4+PC9hPiZxdW90OyBwb2ludGluZyB0byAxOTIuMC4yLjEgY2FjaGVk IHBhc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmbmJzcDsmbmJzcDsgaXRzIFRUTCBzbyB0aGUgRUFNVCByZWNvcmQgaXMgZ29uZS4mbmJzcDsg QW4gYXR0YWNrZXIgY29udmluY2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IGFub3RoZXIgdXNlciBpbiB0aGUgc2FtZSBo b21lIG5ldHdvcmsgdG8gZG8gYSBETlMgbG9va3VwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IHRoYXQgaGFzIGFuIEEgcmVj b3JkIG9mIDE5Mi4wLjIuLjEgKHdoaWNoIHRoZSBhdHRhY2tlciBkb2Vzbid0DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgb3duKSBidXQgYSBB QUFBIHJlY29yZCBmb3IgMjAwMTpkYjg6ZWVlZTo6ZWVlZSAod2hpY2ggaXMgYXR0YWNrZXItY29u dHJvbGxlZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7IEV2ZW4gaWYgMTkyLjAuMi4xIGlzIElQdjQtb25seSwgaWYgdGhl IEVBTVQgZW50cnkgaGFzIGV4cGlyZWQgb3IgbmV2ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmbmJzcDsmbmJzcDsgZXhpc3RlZCB0aGVuIHRo ZSBhdHRhY2tlciBjYW4gcmVkaXJlY3QgYWxsIHRyYWZmaWMgdG8gaXQgdG8gYW4gSVB2NiBhZGRy ZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7IG9mIHRoZWlyIGNob2ljZS4mbmJzcDsgTm8gRE5TIHNwb29maW5nIGlzIG5l ZWRlZCBoZXJlIGF0IGFsbCwganVzdCBtYWtpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmbmJzcDsmbmJzcDsgYSAmcXVvdDtjbGFpbSZxdW90 OyB0aGF0IHRoZSBBL0FBQUEgYXJlIGFzc29jaWF0ZWQgKHdoaWNoIGhhcyBubyBhdXRoZW50aWNh dGlvbikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgcG90ZW50aWFsbHkgd29yc2UgYXMgSSdkIGh5cG90aGVz aXplIHRoYXQgSVB2NC1vbmx5IFNUQjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBjbGllbnRzIGFyZSBtdWNoIGxlc3MgbGlr ZWx5IHRvIHVzZSBIVFRQUy9UTFMuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgW0pvcmRpXSBJIHRoaW5rIHRoYXQgaGF2aW5nIGEgcGVyLWhvc3QgRUFNVCBlbnRy aWVzIHJlc29sdmVzIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgW0VkdWFyZF0gSSBiZWxpZXZlIHRoYXQgdGhpcyBkcmFmdCAodGhhdCBzaW11 bGF0ZSBub3JtYWwgaG9zdHMpIGNvdWxkIG5vdCByZXNvbHZlIHRoaXMgcHJvYmxlbSBpbiBwcmlu Y2lwbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg SWYgc29tZWJvZHkgYXJlIGNhcGFibGUgdG8gcHJvZ3JhbSAzcmQgcGFydHkgRlFETiB0byBmYWtl IEFBQUEgcmVjb3JkIChvZiBoaXMpLCB0aGVuIHRoZSB3aG9sZSBpbnRlcm5ldCB3b3VsZCBiZSBh ZmZlY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGF0dGFj ayBkb2VzIG5vdCByZXF1aXJlIHRvIGZha2UgQUFBQSBSUiBmb3Igc29tZW9uZSdzIGVsc2UgRlFE Ti48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGF0dGFj a2VyIG93bnMgdGhlIEZRRE4gYW5kIGNhbiBwdXQgd2hhdGV2ZXIgdGhleSB3YW50IHRoZXJlLCBp bmNsdWRpbmcgdGhlIHZpY3RpbSBzZXJ2ZXIgSVB2NCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBMZXQncyBzYXkgSSBvd24gZnVycnkuZXhhbXBs ZS5jb20uIEkgdHJpY2tlZCB5b3VyIElQdjQtb25seSBUViB0byBhc2sgZm9yIEEgUlIgZm9yIHRo YXQgbmFtZS4gSSByZXR1cm5lZCB5b3UgYW4gSVB2NCBhZGRyZXNzIG9mDQo8YSBocmVmPSJodHRw Oi8vd3d3LnlvdXR1YmUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+d3d3LnlvdXR1YmUuY29tPC9zcGFuPjwvYT4gYXMgQSBhbmQgLSB3aGVu IHRoZSBzbWFydCBDUEUgYXNrcyBmb3IgQUFBQSwgSVB2NiBhZGRyZXNzIG9mIG15IG93biBzZXJ2 ZXIuIE5vdyB5b3VyIHNtYXJ0IFRWIHdvdWxkIGJlIHNlbmRpbmcgdHJhZmZpYyB0byBteSBzZXJ2 ZXIgaW5zdGVhZCBvZiBZb3V0dWJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBJIHRvdGFsbHkgYWdyZWUgdGhhdCBiaW5kaW5nIHRoZSBFQU1UIGVudHJ5IHRv IHRoZSBzb3VyY2UgSVB2NCBhZGRyZXNzIGxpbWl0cyB0aGUgaW1wYWN0IGZvciBhIHNpbmdsZSBk ZXZpY2UgYW5kIG1ha2VzIHRoZSBhdHRhY2sgaGFyZGVyIHRvIGltcGxlbWVudCAoeW91IG5lZWQg dG8gdHJpY2sgdGhlIHNhbWUgZGV2aWNlIGludG8gcmVzb2x2aW5nIG15IGV2aWwgRlFETiwgd2hp Y2ggaXMgbm90IGFzIGVhc3kNCiBhcyB0cmlja2luZyBteSBsYXB0b3AgaW50byBpdCkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQW5kIEROUyBzdGFuZGFyZHMg aGF2ZSBhIGxvdCBvZiB0b29scyBhZ2FpbnN0IHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEknbSBub3Qgc3VyZSB0aGVyZSBpcyBhbnl0aGluZyBpbiBETlMgcHJl dmVudGluZyBtZSBmcm9tIHB1dHRpbmcgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IElQdjQgYWRkcmVzcyBvZiA8YSBocmVmPSJodHRwOi8vd3d3Lmh1YXdl aS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij53d3cuaHVhd2VpLmNvbTwvc3Bhbj48L2E+IGludG8gdGhlIHpvbmUgZmlsZSBmb3IgYSBkb21h aW4gbmFtZSBJIG93bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLS08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU1ksIEplbiBMaW5r b3ZhIGFrYSBGdXJyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlNZLCBKZW4gTGlua292YSBha2EgRnVycnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_92b0db11479d4c5aa949776ccb42e899huaweicom_-- From nobody Mon Jul 20 08:43:50 2020 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 009853A0C78 for ; Mon, 20 Jul 2020 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH8ra54LVvOn for ; Mon, 20 Jul 2020 08:43:44 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 930DC3A0C70 for ; Mon, 20 Jul 2020 08:43:43 -0700 (PDT) Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1B81C89134218EA06E3F; Mon, 20 Jul 2020 16:43:42 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml736-chm.china.huawei.com (10.201.108.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 16:43:41 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 18:43:40 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 20 Jul 2020 18:43:40 +0300 From: Vasilenko Eduard To: JORDI PALET MARTINEZ , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness Thread-Index: AQHWXBBfQd4WoMAlRH285zQQjJVud6kL6mmAgAKh7oCAAhM50A== Date: Mon, 20 Jul 2020 15:43:40 +0000 Message-ID: References: <3bfb86ab0cb24764a5c2241d8b4b9053@huawei.com> <6583D12D-6628-4CEB-BCB2-67863D826342@theipv6company.com> <0dd28c07dc82413ebac3c231a47cf038@huawei.com> <8B19AAF9-0870-46F4-916C-730AB80D4F19@consulintel.es> <75108EA5-62D2-43EF-BEBC-646737384F9C@consulintel.es> <19114aa217f443d0965f602269c432a7@huawei.com> <4D67F606-3141-4432-A78B-3D357383F59B@consulintel.es> In-Reply-To: <4D67F606-3141-4432-A78B-3D357383F59B@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.117] Content-Type: multipart/alternative; boundary="_000_cb6fe24d877c44c290cb25a22e748044huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 15:43:48 -0000 --_000_cb6fe24d877c44c290cb25a22e748044huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVjYXVzZSBhZnRlciBOQVBUNDQgeW91IHdvdWxkIGxvc2UgdmlzaWJpbGl0eSBvZiA8c291cmNl IFByaXZhdGUgSVB2ND4gaW4gcHJpbmNpcGxlLA0KDQpJdCBpcyBsZWZ0IGluIHByZXZpb3VzIGxp YnJhcnksIG9ubHkgUHVibGljIElQdjQgaXQgdHJhbnNmZXJyZWQgaW4gbmV4dCAoQ0xBVCkgbGli cmFyeS4NCg0KQnV0IHlvdSBuZWVkIDxzb3VyY2UgUHJpdmF0ZSBJUHY0PiBmb3IgeW91ciBuZXcg RUFNVC4NCg0KSGVuY2UsIHRoZXNlICJtaWNyby1zZXJ2aWNlcyIgY291bGQgbm90IHNvbHZlIHRo ZSBwcm9ibGVtLg0KDQpJdCBzaG91bGQgYmUgMSBtb25vbGl0aGljICJwYXJ0aWFsbHkgc3RhdGVm dWwgTkcgQ0xBVCIuDQoNClRoYXQgQW5kcm9pZCBkb2VzIG5vdCBoYXZlIG5vdy4NCg0KDQoNCkpv cmRpLA0KDQpJIGRvIGFncmVlIHRoYXQgZGVzdGluYXRpb24gSVB2NiByZXNlYXJjaCAoYW5kIEVB TVQgbWFuaXB1bGF0aW9uKSAtIGlzIHRoZSBiaWdnZXN0IGNoYWxsZW5nZSBvZiB0aGlzIGRyYWZ0 Lg0KDQpZb3UgYXJlIHV0dGVybHkgY29uY2VudHJhdGVkIG9uIHRoZSBtb3N0IGltcG9ydGFudCB0 aGluZy4NCg0KQnV0IHBsZWFzZSwgcGF5IGEgbGl0dGxlIGF0dGVudGlvbiBob3cgc291cmNlIGFk ZHJlc3NlcyBzaG91bGQgYmUgbWFuaXB1bGF0ZWQuDQoNCg0KDQpFZHVhcmQNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQpTZW50OiAxOSDQuNGO0LvR jyAyMDIwINCzLiAxMzo1Nw0KVG86IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyIC0g Y29uY2VybiBvbiBzdGF0ZWZ1bG5lc3MNCg0KDQoNCkhpIEVkdWFyZCwNCg0KDQoNCkknbSBzdGls bCB0aGlua2luZyBpbiB0aGUgb3RoZXIgZW1haWwgZnJvbSB5b3UgYWJvdXQgdXNpbmcgdGhlIE1B QyBvZiB0aGUgc291cmNlIGhvc3RzIGluc3RlYWQgb2YgdGhlIEROUyBxdWVyaWVzIHRvIGd1ZXNz IGlmIGl0IGlzIGEgZHVhbC1zdGFjayBvciBJUHY0LW9ubHkgaG9zdC4gSXQgbG9va3MgbGlrZSBh IHZlcnkgc21hcnQgaWRlYSwgdW5sZXNzIGFueW9uZSBlbHNlIGNvdWxkIHRlbGwgd2h5IG5vdCAu Li4NCg0KDQoNCklmIHdlIHVzZSB0aGFuIHRoZW4gd2UgY291bGQganVzdCBpbmNsdWRlIHRoZSBN QUMgYWRkcmVzcyBpbiB0aGUgRUFNVC4NCg0KDQoNCkhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIHdoeSBp ZGVudGlmeWluZyB0aGUgaG9zdHMgKHdoZXRoZXIgaXMgdmlhIE1BQyBvciBzb3VyY2UgSVB2NCkg ZGlzYWxsb3dzIHVzaW5nIHRoZSBOQVQ0NCtOQVQ0Ni4gSSBndWVzcyBpdCBpcyBhIG1hdHRlciBv ZiBpbXBsZW1lbnRhdGlvbi4NCg0KDQoNCg0KDQrvu79FbCAxNy83LzIwIDE3OjU1LCAidjZvcHMg ZW4gbm9tYnJlIGRlIFZhc2lsZW5rbyBFZHVhcmQiIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIGVu IG5vbWJyZSBkZSB2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmclMjBlbiUyMG5vbWJyZSUyMGRlJTIwdmFzaWxlbmtvLmVkdWFyZEBodWF3ZWku Y29tPj4gZXNjcmliacOzOg0KDQoNCg0KICAgIEhpIEpvcmRpLA0KDQogICAgSXQgaXMgZXZlbiBs b25nZXIgdGhhbiBJIGhhdmUgZXhwZWN0ZWQuIEZpbmUuDQoNCg0KDQogICAgQnV0IGluIHNlcGFy YXRlIGRpc2N1c3Npb24geW91IGhhdmUgcHJvcG9zZWQgdG8gcHV0IHNvdXJjZSBJUHY0IGludG8g RUFNVCB0YWJsZSwNCg0KICAgIFRoYXQgd291bGQgYnJlYWsgbG9naWMgYmVsb3cgLSBpdCB3b3Vs ZCBub3QgYmUgcG9zc2libGUgYW55bW9yZSB0byBwaXBlbGluZSAyIGluZGVwZW5kZW50IGVuZ2lu ZXM6IE5BUFQ0NCBhbmQgTkFUNDYuIEl0IHNob3VsZCBiZSBvbmUgc3RhdGVmdWwgZW5naW5lLg0K DQogICAgTGV0J3Mgd2FpdCBmb3IgdGhlIGZpbmlzaCBvZiBvdGhlciBkaXNjdXNzaW9ucyAtIG1h eSBiZSB5b3UgaGF2ZSB0byByZXR1cm4gdG8gNS4yLjQgYWdhaW4uDQoNCg0KDQogICAgRWR1YXJk DQoNCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogICAgRnJvbTogdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSk9SREkgUEFMRVQgTUFS VElORVoNCg0KICAgIFNlbnQ6IDE3INC40Y7Qu9GPIDIwMjAg0LMuIDExOjAxDQoNCiAgICBUbzog djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQogICAgU3ViamVjdDogUmU6 IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlv bi0wMiAtIGNvbmNlcm4gb24gc3RhdGVmdWxuZXNzDQoNCg0KDQogICAgSGkgRWR1YXJkLA0KDQoN Cg0KICAgIExldCB1cyBrbm93IHdoYXQgZG8geW91IHRoaW5rIGFib3V0IHRoaXMgdGVudGF0aXZl IGFsdGVybmF0aXZlIHRleHQgdG8gcmVzb2x2ZSB0aGlzIGlzc3VlOg0KDQoNCg0KICAgIDUuMi40 LiAgRm9yd2FyZGluZyBwYXRoIHZpYSBzdGF0ZWZ1bCBOQVQgZm9yIGV4aXN0aW5nIEVBTVQgZW50 cmllcw0KDQoNCg0KICAgICAgIEZvbGxvd2luZyB0aGlzIGFwcHJvYWNoLCBpZiB0aGVyZSBpcyBh IHZhbGlkIEVBTVQgZW50cnksIGZvciBhIGdpdmVuDQoNCiAgICAgICBJUHY0LWRlc3RpbmF0aW9u LCB0aGUgSVB2Ni1uYXRpdmUgcGF0aCBwb2ludGVkIGJ5IHRoZSBJUHY2IGFkZHJlc3Mgb2YNCg0K ICAgICAgIHRoYXQgRUFNVCBlbnRyeSwgd2lsbCB0YWtlIHByZWNlZGVuY2UgdmVyc3VzIHRoZSBO QVQ2NCBwYXRoLCBzbyB0aGUNCg0KICAgICAgIHRyYWZmaWMgd2lsbCBub3QgYmUgZm9yd2FyZGVk IHRvIHRoZSBOQVQ2NC4NCg0KDQoNCiAgICAgICBIb3dldmVyLCB0aGlzIGlzIG5vdCBzdWZmaWNp ZW50IHRvIGVuc3VyZSB0aGF0IGluZGl2aWR1YWwNCg0KICAgICAgIGFwcGxpY2F0aW9ucyBhcmUg YWJsZSB0byBrZWVwIGV4aXN0aW5nIGNvbm5lY3Rpb25zLiAgSW4gbWFueSBjYXNlcywNCg0KICAg ICAgIGF1ZGlvIGFuZCB2aWRlbyBzdHJlYW1pbmcgbWF5IHVzZSBhIHNpbmdsZSBUQ1AgY29ubmVj dGlvbiBsYXN0aW5nDQoNCiAgICAgICBmcm9tIG1pbnV0ZXMgdG8gaG91cnMuICBJbnN0ZWFkLCB0 aGUgQ0ROIFRUTHMgbWF5IGJlIGNvbmZpZ3VyZWQgaW4NCg0KICAgICAgIHRoZSByYW5nZSBmcm9t IDEwIHRvIDMwMCBzZWNvbmRzIGluIG9yZGVyIHRvIGFsbG93IG5ldyByZXNvbHV0aW9ucyB0bw0K DQogICAgICAgc3dpdGNoIHF1aWNrbHkgYW5kIHRvIGhhbmRsZSBsYXJnZSByZWN1cnNpdmUgcmVz b2x2ZXJzICh3aXRoIGh1bmRyZWRzDQoNCiAgICAgICBvZiB0aG91c2FuZHMgb2YgY2xpZW50cyBi ZWhpbmQgdGhlbSkuDQoNCg0KDQogICAgICBDb25zZXF1ZW50bHksIHRoZSBFQU1UIGVudHJpZXMg TVVTVCBOT1QgYmUgdXNlZCBkaXJlY3RseSB0byBlc3RhYmxpc2gNCg0KICAgICAgIGEgZm9yd2Fy ZGluZyBwYXRoLCBidXQgaW5zdGVhZCwgTVVTVCBiZSB1c2VkIHRvIGNyZWF0ZSBhIHN0YXRlZnVs IE5BVA0KDQogICAgICAgZW50cnkgZm9yIHRoZSA0LXR1cGxlIGZvciB0aGUgZHVyYXRpb24gb2Yg dGhlIHNlc3Npb24vY29ubmVjdGlvbi4NCg0KICAgICAgIFRoaXMgbWVhbnMgdGhhdCB0byBpbXBs ZW1lbnQgdGhlIG9wdGltaXphdGlvbiB0aGUgTkFUNDYgTVVTVCBiZQ0KDQogICAgICAgc3RhdGVm dWwuICBUeXBpY2FsbHksIHN0YXRlZnVsIE5BVDQ2IGFyZSBpbXBsZW1lbnRlZA0KDQogICAgICAg YnkgbWVhbnMgb2YgYSBzdGF0ZWZ1bCBOQVQ0NCAod2hpY2ggb2Z0ZW4gbWF5YmUgaGFyZHdhcmUg b2ZmLWxvYWRlZCksDQoNCiAgICAgICBmb2xsb3dlZCBieSBhIHN0YXRlbGVzcyBOQVQ0Ni4gIElm IHRoZSBTb0MvY29kZSBpcyBhYmxlIHRvIGRvDQoNCiAgICAgICBzdGF0ZWxlc3MgTkFUNDYsIHRo aXMgc3RpbGwgY291bGQgYmUgdXNlZCB3aGVuIHRoZSBvcHRpbWl6YXRpb24gaXMNCg0KICAgICAg IGRpc2FibGVkLg0KDQoNCg0KICAgIE5vdGUgdGhhdCBhbHNvIGZvbGxvd2luZyBFcmlrIGlucHV0 cywgdGhlIHRleHQgaGFzIG1vcmUgbm9ybWF0aXZlIGxhbmd1YWdlLg0KDQoNCg0KICAgIEFsc28s IGZvciB0aGUgdGl0bGUgd2UgdGhvdWdodCB0aGF0IGl0IHdpbGwgbWFrZSBzZW5zZToNCg0KICAg IDQ2NFhMQVQvTUFQLVQgT3B0aW1pemF0aW9uDQoNCg0KDQogICAgTm8gbmVlZCB0byBtZW50aW9u IE5BVDY0LCB3aGljaCBpcyBwYXJ0IG9mIHRoZSA0NjRYTEFULg0KDQoNCg0KICAgIFJlZ2FyZHMs DQoNCiAgICBKb3JkaQ0KDQogICAgQGpvcmRpcGFsZXQNCg0KDQoNCg0KDQoNCg0KICAgIO+7v0Vs IDE1LzcvMjAgMTY6MTgsICJ2Nm9wcyBlbiBub21icmUgZGUgSk9SREkgUEFMRVQgTUFSVElORVoi IDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIGVuIG5vbWJyZSBkZSBqb3JkaS5wYWxldD00MGNvbnN1 bGludGVsLmVzQGRtYXJjLmlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnJTIw ZW4lMjBub21icmUlMjBkZSUyMGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0 Zi5vcmc+PiBlc2NyaWJpw7M6DQoNCg0KDQogICAgICAgIEkgdGhpbmsgeW91ciBwb2ludCB3aWxs IGJlIHRvIG1ha2UgaXQgY2xlYXIgaW4gdGhlIGRvY3VtZW50IHRoYXQgZm9yIHRoaXMgb3B0aW1p emF0aW9uIHRvIHdvcmssIHRoZSBDTEFUIHNob3VsZCBiZSBzdGF0ZWZ1bD8NCg0KDQoNCiAgICAg ICAgSSB0aGluayBpcyB0aGVyZSAoNS4yLjQuICBGb3J3YXJkaW5nIHBhdGggdmlhIHN0YXRlZnVs IE5BVCBmb3IgZXhpc3RpbmcgRUFNVCBlbnRyaWVzKSwgYnV0IEkgd2lsbCBtYWtlIHN1cmUgdG8g YWRkIHRoZSByZWxldmFudCB0ZXh0IGluIHRoZSBuZXh0IHZlcnNpb24gdG8gbWFrZSBpdCBjbGVh cmVyLg0KDQoNCg0KICAgICAgICBJIGluc2lzdDogbW9zdCBvZiB0aGUgQ0xBVCBpbXBsZW1lbnRh dGlvbnMgdG9kYXkgKHJ1bm5pbmcgaW4gYm90aCBDUEVzIGFuZCBVRXMpIGFyZSBzdGF0ZWZ1bC4g QXQgbGVhc3QgdGhpcyBpcyB0aGUgZGF0YSBJJ3ZlLg0KDQoNCg0KICAgICAgICBSZWdhcmRzLA0K DQogICAgICAgIEpvcmRpDQoNCiAgICAgICAgQGpvcmRpcGFsZXQNCg0KDQoNCg0KDQoNCg0KICAg ICAgIO+7v0VsIDE1LzcvMjAgMTU6NTksICJ2Nm9wcyBlbiBub21icmUgZGUgVmFzaWxlbmtvIEVk dWFyZCIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgZW4gbm9tYnJlIGRlIHZhc2lsZW5rby5lZHVh cmRAaHVhd2VpLmNvbTxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyUyMGVuJTIwbm9tYnJl JTIwZGUlMjB2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiBlc2NyaWJpw7M6DQoNCg0KDQog ICAgICAgICAgICBIaSBKb3JkaSwNCg0KICAgICAgICAgICAgSSBzdGlsbCBiZWxpZXZlIHRoYXQg dG91Z2ggKG5ldykgcmVxdWlyZW1lbnQgdGhhdCBDTEFUIHNob3VsZCBiZWNvbWUgU3RhdGVmdWwg KG1hbmRhdG9yeSkNCg0KICAgICAgICAgICAgTWFrZSBzZW5zZSB0byBpbnNlcnQgaW50byB0aGUg ZG9jdW1lbnQuDQoNCg0KDQogICAgICAgICAgICBBbmQgZXhwbGFuYXRpb24gd2h5IHN0YXRlZnVs IE5BUFQgaXMgbmVlZGVkIHdvdWxkIGJlIGdvb2QuDQoNCiAgICAgICAgICAgIEkgaGF2ZSBzcGVu dCBzb21lIHRpbWUgdG8gcmVzZWFyY2ggdGhpcyAtIGl0IGlzIGJldHRlciB0byBzYXZlIHRpbWUg b2Ygb3RoZXIgcGVvcGxlLg0KDQogICAgICAgICAgICBJdCBpcyBpbXBvcnRhbnQgcG9pbnQgdGhh dCBpcyBvbWl0dGVkIGluIHRoZSBkb2N1bWVudC4NCg0KDQoNCiAgICAgICAgICAgIEZvciB0aGUg bmFtZTogSSBkbyBub3QgaGF2ZSBhbnkgc3Ryb25nIG9waW5pb24uDQoNCiAgICAgICAgICAgIEp1 c3QgSSBzZWUgdGhhdCBkcmFmdCBpcyBhcHBsaWNhYmxlIG1vc3RseSB0byBNQVAtVCwNCg0KICAg ICAgICAgICAgQW5kIG5vdCBtdWNoIGFwcGxpY2FibGUgdG8gWExBVCAoYmVjYXVzZSBtYWpvcml0 eSBvZiBpbnN0YWxsYXRpb25zIGhhdmUgc3RhdGVsZXNzIENMQVQpLg0KDQogICAgICAgICAgICBC dXQgdGhlIG5hbWUgbWlzbGVhZCB0byBvcHBvc2l0ZSBjb25jbHVzaW9uLg0KDQoNCg0KICAgICAg ICAgICAgRWR1YXJkDQoNCiAgICAgICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN CiAgICAgICAgICAgIEZyb206IEpvcmRpIFBhbGV0IE1hcnTDrW5leiBbbWFpbHRvOmpvcmRpLnBh bGV0QHRoZWlwdjZjb21wYW55LmNvbV0NCg0KICAgICAgICAgICAgU2VudDogMTUg0LjRjtC70Y8g MjAyMCDQsy4gMTY6NDgNCg0KICAgICAgICAgICAgVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2ls ZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29t Pj47IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCg0KICAgICAgICAgICAg Q2M6IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb25AaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb25AaWV0Zi5vcmc+DQoNCiAgICAg ICAgICAgIFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMt NDY0eGxhdC1vcHRpbWl6YXRpb24tMDIgLSBjb25jZXJuIG9uIHN0YXRlZnVsbmVzcw0KDQoNCg0K ICAgICAgICAgICAgSGkgVmFzaWxlbmtvLA0KDQoNCg0KICAgICAgICAgICAgVGhlIGltcGxlbWVu dGF0aW9ucyBvZiA0NjRYTEFULCBjYW4gZG8gdGhlIHNhbWUgKGFuZCBpbiBmYWN0LCBtYW55IG9m IHRoZW0gaXMgd2hhdCB0aGV5IGRvKS4gTkFUNDQgc3RhdGVmdWwgYW5kIHRoZSA0NiBzdGF0ZWxl c3MuIE1hbnkgU29DIGhhdmUgZW1iZWRkZWQgTkFUNDQgYWNjZWxlcmF0aW9uLCBidXQgbm90IE5B VDQ2LCBzbyB0aGF0IGV4cGxhaW5zIGl0IGFzIHdlbGwuDQoNCg0KDQogICAgICAgICAgICBJIGd1 ZXNzIHRoYXQgY291bGQgY2xlYXIgeW91ciBjb25jZXJuPw0KDQoNCg0KICAgICAgICAgICAgSSd2 ZSBzZXZlcmFsIGN1c3RvbWVycyBkb2luZyA0NjRYTEFUIGluIGJyb2FkYmFuZCwgb25lIG9mIHRo ZW0gMjUuMDAwLjAwMCBzdWJzY3JpYmVycy4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBpbiBkb2lu ZyA0NjRYTEFUIGluIGNlbGx1bGFyIGFuZCBicm9hZGJhbmQuDQoNCg0KDQogICAgICAgICAgICBX aGVuIHdlIHNheSBpbiB0aGUgdGl0bGUgNDY0WExBVC9OQVQ2NCwgSSB0aGluayBib3RoIGFyZSBj b3ZlcmVkLiBCdXQgSSd2ZSBubyBpc3N1ZSB0byBjaGFuZ2UgdGhlIHRpdGxlIGlmIHRoaXMgbWFr ZXMgc2Vuc2UgdG8gb3RoZXJzLiBXZSBjb3VsZCBleHBsaWN0aWx5IHNheSA0NjRYTEFUL05BVDY0 L01BUC1UIG9yIHdoYXRldmVyLiBUaGlzIGlzIGEgbWlub3IgZGV0YWlsLCBpbiBteSBvcGluaW9u Lg0KDQoNCg0KICAgICAgICAgICAgUmVnYXJkcywNCg0KICAgICAgICAgICAgSm9yZGkNCg0KICAg ICAgICAgICAgQGpvcmRpcGFsZXQNCg0KDQoNCg0KDQogICAgICAgICAgICDvu79FbCAxNS83LzIw IDE1OjQwLCAiVmFzaWxlbmtvIEVkdWFyZCIgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxt YWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4gZXNjcmliacOzOg0KDQoNCg0KICAg ICAgICAgICAgICAgIEhpIGFsbCwNCg0KICAgICAgICAgICAgICAgIEkgaGF2ZSBjb25jZXJuIG9u IHRoZSBjYXBhYmlsaXR5IHRvIHVzZSB0aGlzIG1lY2hhbmlzbSBmb3IgNDY0WExBVCwgYnV0IGl0 IHNob3VsZCBiZSBmaW5lIGZvciBNQVAtVC4NCg0KDQoNCiAgICAgICAgICAgICAgICBXZSBtYXkg aGF2ZSBtYW55IGhvc3RzIG9uIENQRSBMQU4uIFR5cGljYWxseSwgNzAlIG9mIEZCQiB0cmFmZmlj IGlzIHN0aWxsIGRlc2lnbmF0ZWQgdG8gSVB2NCBzaXRlcy4NCg0KICAgICAgICAgICAgICAgIFNv dXJjZSBVRFAvVENQIHBvcnQgY29sbGlzaW9uIGlzIHN0aWxsIHZlcnkgcG9zc2libGUgKGkuZS4g YWN0aXZlIHNlc3Npb25zIGZyb20gZGlmZmVyZW50IGhvc3QgbWF5IGhhdmUgdGhlIHNhbWUgc291 cmNlIFRDUC9VRFAgcG9ydCksDQoNCiAgICAgICAgICAgICAgICBJdCBpcyBub3Qgc3RhdGVkIGFu eXdoZXJlIGluIHRoZSBkb2N1bWVudCwgYnV0IHdlIG5lZWQgdG8gc3F1ZWV6ZSAoZm9yIHBhdGgg dG8gSW50ZXJuZXQgaXQgd291bGQgYmUgInNvdXJjZSBJUCBhZGRyZXNzIikgbWFueSBwcml2YXRl IElQdjQgaG9zdHMgdG8gb25lIElQdjYgKGFzc2lnbmVkIGJ5IGNhcnJpZXIgdG8gQ1BFIHVwbGlu aykuDQoNCiAgICAgICAgICAgICAgICBDbGFzc2ljYWwgTjoxIHByb2JsZW0gdGhhdCBzaG91bGQg YmUgcmVzb2x2ZWQgYnkgTkFQVCAocG9ydCB0cmFuc2xhdGlvbiBpcyBtYW5kYXRvcnkpLg0KDQoN Cg0KICAgICAgICAgICAgICAgIE1BUC1UIGhhcyBOQVBUIGVuZ2luZSBvbiBDUEUgc2lkZSAtIGl0 IG1ha2Ugc2Vuc2UgdG8gY2xlYXJseSBzdGF0ZSBpbiB0aGUgZG9jdW1lbnQgdGhhdCB3ZSBhcmUg Z29pbmcgdG8gcmV1c2UgTkFQVC4gVGhlbiB0cmFuc2xhdGlvbiB3b3VsZCBiZToNCg0KICAgICAg ICAgICAgICAgICgxKSBOQVBUNDQgZm9yIG1hbnkgcHJpdmF0ZSBJUHY0IHRvIG9uZSBwdWJsaWMg SVB2NCAod2VsbCwgaXQgY291bGQgYmUgbm90IHB1YmxpYywgYnV0IHB1YmxpYyBBK1AgaGFzIGJl ZW4gZ2l2ZW4gdG8gTUFQIENFIGFueXdheSAtIGJldHRlciB0byByZXVzZSBpdCBmb3IgdW5pZmlj YXRpb24pDQoNCiAgICAgICAgICAgICAgICAoMikgU0lJVCAod2l0aCBFQU1UKSBmb3Igc2luZ2xl IElQdjQgdG8gc2luZ2xlIElQdjYgKDE6MSkNCg0KDQoNCiAgICAgICAgICAgICAgICBYTEFUL0NM QVQgZG9lcyBoYXZlIHN0YXRlZnVsIE5BUFQgYnkgUkZDIDY4NzcsIGJ1dCBpdCBpcyBub3QgcG9w dWxhciAtIG5vdCBpbXBsZW1lbnRlZCBieSBtYW55IGNhcnJpZXJzIChpZiBhbnk/KS4NCg0KICAg ICAgICAgICAgICAgIEl0IHdvdWxkIGJlIHRoZSBiaWcgbmV3cyB0aGF0IENhcnJpZXJzIHNob3Vs ZCBjaG9vc2Ugc3RhdGVmdWwgQ0xBVCBvcHRpb24gZm9yIDQ2NFhMQVQuDQoNCiAgICAgICAgICAg ICAgICBJdCBpcyBiZXR0ZXIgdG8gdGVsbCB0aGVtIHVwZnJvbnQuDQoNCg0KDQogICAgICAgICAg ICAgICAgVGhlIG5leHQgcXVlc3Rpb24gY291bGQgYmU6IGRvZXMgaXQgbWFrZSBzZW5zZSB0byB1 c2UgU3RhdGVsZXNzIENMQVQgZm9yIGJhc2ljIDQ2NFhMQVQgYW5kIFN0YXRlZnVsIENMQVQgZm9y IHRyYWZmaWMgb3B0aW1pemF0aW9uIHRvIElQdjQgc2l0ZXM/DQoNCiAgICAgICAgICAgICAgICBP ciBpdCBpcyBiZXR0ZXIgdG8gdW5pZnkgb24gU3RhdGVmdWwgQ0xBVCBmb3IgZXZlcnl0aGluZy4N Cg0KDQoNCiAgICAgICAgICAgICAgICBJbiBnZW5lcmFsLCBpdCBpcyBhIHJldm9sdXRpb24gZm9y IDQ2NFhMQVQuIEJ1dCBpdCBpcyBzbW9vdGggZXhwYW5zaW9uIGZvciBNQVAtVC4NCg0KICAgICAg ICAgICAgICAgIEhlbmNlLCBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gY2hhbmdlIHRoZSBuYW1lIG9m IHRoaXMgZHJhZnQgdG8gcmVmbGVjdCBNQVAtVCBhcyB0aGUgcHJpbWFyeSB0YXJnZXQ/DQoNCg0K DQogICAgICAgICAgICAgICAgRWR1YXJkDQoNCiAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KDQogICAgICAgICAgICAgICAgRnJvbTogdjZvcHMgW21haWx0bzp2Nm9w cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoNCiAgICAgICAgICAgICAgICBTZW50 OiAxMSDQuNGO0LvRjyAyMDIwINCzLiAxNTozNA0KDQogICAgICAgICAgICAgICAgVG86IGktZC1h bm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KDQogICAgICAg ICAgICAgICAgQ2M6IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCg0KICAg ICAgICAgICAgICAgIFN1YmplY3Q6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9w cy00NjR4bGF0LW9wdGltaXphdGlvbi0wMi50eHQNCg0KDQoNCg0KDQogICAgICAgICAgICAgICAg QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQogICAgICAgICAgICAgICAgVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0KDQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogNDY0WExBVC9OQVQ2NCBP cHRpbWl6YXRpb24NCg0KICAgICAgICAgICAgICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDog Sm9yZGkgUGFsZXQgTWFydGluZXoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQWxlamFuZHJvIEQnRWdpZGlvDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRp b24tMDIudHh0DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAg ICA6IDIxDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6 IDIwMjAtMDctMTENCg0KDQoNCiAgICAgICAgICAgICAgICBBYnN0cmFjdDoNCg0KICAgICAgICAg ICAgICAgICAgIElQL0lDTVAgVHJhbnNsYXRpb24gQWxnb3JpdGhtIChTSUlUKSBjYW4gYmUgdXNl ZCB0byBwcm92aWRlIGFjY2Vzcw0KDQogICAgICAgICAgICAgICAgICAgZm9yIElQdjQtb25seSBk ZXZpY2VzIG9yIGFwcGxpY2F0aW9ucyB0byBJUHY0LW9ubHkgb3IgZHVhbC1zdGFjaw0KDQogICAg ICAgICAgICAgICAgICAgZGVzdGluYXRpb25zIG92ZXIgSVB2Ni1vbmx5IGluZnJhc3RydWN0dXJl LiAgSW4gdGhhdCBjYXNlLCB0aGUNCg0KICAgICAgICAgICAgICAgICAgIHRyYWZmaWMgZmxvd3Mg YXJlIHRyYW5zbGF0ZWQgdHdpY2U6IGZpcnN0IGZyb20gSVB2NCB0byBJUHY2DQoNCiAgICAgICAg ICAgICAgICAgICAoc3RhdGVsZXNzIE5BVDQ2IGF0IHRoZSBpbmdyZXNzIHBvaW50IHRvIHRoZSBJ UHY2LW9ubHkNCg0KICAgICAgICAgICAgICAgICAgIGluZnJhc3RydWN0dXJlKSBhbmQgdGhlbiBm cm9tIElQdjYgYmFjayB0byBJUHY0IChzdGF0ZWZ1bCBOQVQ2NCwgYXQNCg0KICAgICAgICAgICAg ICAgICAgIHRoZSBlZ3Jlc3MgcG9pbnQpLiAgV2hlbiB0aGUgZGVzdGluYXRpb24gaXMgSVB2Ni1l bmFibGVkLCB0aGUgc2Vjb25kDQoNCiAgICAgICAgICAgICAgICAgICB0cmFuc2xhdGlvbiBtaWdo dCBiZSBhdm9pZGVkLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBwb3NzaWJsZQ0KDQogICAg ICAgICAgICAgICAgICAgb3B0aW1pemF0aW9uIHRvIDQ2NFhMQVQgYW5kIE1BUC1UIHRvIGF2b2lk IHRyYW5zbGF0aW5nIElQdjYgZmxvd3MNCg0KICAgICAgICAgICAgICAgICAgIGJhY2sgdG8gSVB2 NCBpZiB0aGUgZGVzdGluYXRpb24gaXMgcmVhY2hhYmxlIG92ZXIgSVB2Ni4gIFRoZSBwcm9wb3Nl ZA0KDQogICAgICAgICAgICAgICAgICAgc29sdXRpb24gd291bGQgc2lnbmlmaWNhbnRseSByZWR1 Y2UgdGhlIE5BVDY0IHV0aWxpemF0aW9uIGluIHRoZQ0KDQogICAgICAgICAgICAgICAgICAgb3Bl cmF0b3IncyBuZXR3b3JrLg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCg0KICAgICAgICAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtNDY0eGxh dC1vcHRpbWl6YXRpb24vDQoNCg0KDQogICAgICAgICAgICAgICAgVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KDQogICAgICAgICAgICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24t MDINCg0KICAgICAgICAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMg0KDQoNCg0KICAgICAg ICAgICAgICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCg0KICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyDQoNCg0KDQoNCg0KICAgICAg ICAgICAgICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNCiAgICAgICAg ICAgICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQoNCiAgICAgICAgICAgICAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQogICAgICAgICAgICAgICAgdjZvcHMgbWFpbGluZyBs aXN0DQoNCiAgICAgICAgICAgICAgICB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+DQoNCiAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQoNCg0KDQoNCg0KDQoNCiAgICAgICAgICAgICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICAgICAgSVB2NCBpcyBvdmVyDQoN CiAgICAgICAgICAgIEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KDQogICAg ICAgICAgICBodHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0KDQogICAgICAgICAgICBUaGUg SVB2NiBDb21wYW55DQoNCg0KDQogICAgICAgICAgICBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBj b250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRp YWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxp Y2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNl IG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwg aW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxs IGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRp c3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2 ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBt dXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29t bXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KDQoNCg0KDQoNCg0KDQogICAgICAgICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAgICAgICAg ICB2Nm9wcyBtYWlsaW5nIGxpc3QNCg0KICAgICAgICAgICAgdjZvcHNAaWV0Zi5vcmc8bWFpbHRv OnY2b3BzQGlldGYub3JnPg0KDQogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQoNCg0KDQoNCiAgICAgICAgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQogICAgICAgIElQdjQgaXMgb3Zlcg0K DQogICAgICAgIEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KDQogICAgICAg IGh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQoNCiAgICAgICAgVGhlIElQdjYgQ29tcGFu eQ0KDQoNCg0KICAgICAgICBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1h dGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1h dGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXpl ZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQg YSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5 LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwg YmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRo ZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQg ZGVsZXRlIGl0Lg0KDQoNCg0KDQoNCg0KDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgICAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQoN CiAgICAgICAgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQogICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQoNCg0KDQoN Cg0KICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K ICAgIElQdjQgaXMgb3Zlcg0KDQogICAgQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5l dCA/DQoNCiAgICBodHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbQ0KDQogICAgVGhlIElQdjYg Q29tcGFueQ0KDQoNCg0KICAgIFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9y bWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9y bWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3Jp emVkIGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRl bnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0 YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJl ZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9y IHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFs bHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2ls bCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8g dGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFu ZCBkZWxldGUgaXQuDQoNCg0KDQoNCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQoNCiAgICB2 Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQoNCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQoN CiAgICB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQoNCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQoNCg0KDQoNCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KSVB2NCBpcyBvdmVy DQoNCkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KDQpodHRwOi8vd3d3LnRo ZWlwdjZjb21wYW55LmNvbQ0KDQpUaGUgSVB2NiBDb21wYW55DQoNCg0KDQpUaGlzIGVsZWN0cm9u aWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBv ciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRo ZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmli dXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlm IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUs IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5m b3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVu c2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFi b3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KDQoNCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQp2Nm9wcyBtYWls aW5nIGxpc3QNCg0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= --_000_cb6fe24d877c44c290cb25a22e748044huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVjYXVzZSBhZnRlciBOQTxi PlA8L2I+VDQ0IHlvdSB3b3VsZCBsb3NlIHZpc2liaWxpdHkgb2YgJmx0O3NvdXJjZSBQcml2YXRl IElQdjQmZ3Q7IGluIHByaW5jaXBsZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkl0IGlzIGxlZnQgaW4gcHJldmlvdXMgbGlicmFyeSwgb25seSBQdWJsaWMgSVB2NCBp dCB0cmFuc2ZlcnJlZCBpbiBuZXh0IChDTEFUKSBsaWJyYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QnV0IHlvdSBuZWVkICZsdDtzb3VyY2UgUHJpdmF0ZSBJUHY0 Jmd0OyBmb3IgeW91ciBuZXcgRUFNVC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkhlbmNlLCB0aGVzZSAmcXVvdDttaWNyby1zZXJ2aWNlcyZxdW90OyBjb3VsZCBub3Qg c29sdmUgdGhlIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5JdCBzaG91bGQgYmUgMSBtb25vbGl0aGljICZxdW90O3BhcnRpYWxseSBzdGF0ZWZ1bCBORyBD TEFUJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhdCBB bmRyb2lkIGRvZXMgbm90IGhhdmUgbm93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5K b3JkaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgZG8gYWdyZWUg dGhhdCBkZXN0aW5hdGlvbiBJUHY2IHJlc2VhcmNoIChhbmQgRUFNVCBtYW5pcHVsYXRpb24pIC0g aXMgdGhlIGJpZ2dlc3QgY2hhbGxlbmdlIG9mIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Zb3UgYXJlIHV0dGVybHkgY29uY2VudHJhdGVkIG9uIHRo ZSBtb3N0IGltcG9ydGFudCB0aGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkJ1dCBwbGVhc2UsIHBheSBhIGxpdHRsZSBhdHRlbnRpb24gaG93IHNvdXJjZSBhZGRy ZXNzZXMgc2hvdWxkIGJlIG1hbmlwdWxhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5FZHVhcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSk9SREkgUEFMRVQgTUFSVElORVo8YnI+DQpTZW50OiAx OSDQuNGO0LvRjyAyMDIwINCzLiAxMzo1Nzxicj4NClRvOiB2Nm9wc0BpZXRmLm9yZzxicj4NClN1 YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1v cHRpbWl6YXRpb24tMDIgLSBjb25jZXJuIG9uIHN0YXRlZnVsbmVzczwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SGkgRWR1YXJkLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JJ20gc3RpbGwgdGhp bmtpbmcgaW4gdGhlIG90aGVyIGVtYWlsIGZyb20geW91IGFib3V0IHVzaW5nIHRoZSBNQUMgb2Yg dGhlIHNvdXJjZSBob3N0cyBpbnN0ZWFkIG9mIHRoZSBETlMgcXVlcmllcyB0byBndWVzcyBpZiBp dCBpcyBhIGR1YWwtc3RhY2sgb3IgSVB2NC1vbmx5IGhvc3QuIEl0IGxvb2tzIGxpa2UgYSB2ZXJ5 IHNtYXJ0IGlkZWEsIHVubGVzcyBhbnlvbmUgZWxzZSBjb3VsZCB0ZWxsIHdoeSBub3QNCiAuLi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYgd2UgdXNlIHRoYW4gdGhlbiB3ZSBjb3Vs ZCBqdXN0IGluY2x1ZGUgdGhlIE1BQyBhZGRyZXNzIGluIHRoZSBFQU1ULjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5Ib3dldmVyLCBJIGRvbid0IHNlZSB3aHkgaWRlbnRpZnlpbmcgdGhl IGhvc3RzICh3aGV0aGVyIGlzIHZpYSBNQUMgb3Igc291cmNlIElQdjQpIGRpc2FsbG93cyB1c2lu ZyB0aGUgTkFUNDQmIzQzO05BVDQ2LiBJIGd1ZXNzIGl0IGlzIGEgbWF0dGVyIG9mIGltcGxlbWVu dGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPu+7v0VsIDE3LzcvMjAgMTc6NTUsICZxdW90O3Y2 b3BzIGVuIG5vbWJyZSBkZSBWYXNpbGVua28gRWR1YXJkJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyUyMGVuJTIwbm9tYnJlJTIwZGUlMjB2YXNpbGVua28u ZWR1YXJkQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnIGVuIG5vbWJyZSBkZQ0KIHZhc2ls ZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OyBlc2NyaWJpw7M6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBIaSBKb3JkaSw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJdCBp cyBldmVuIGxvbmdlciB0aGFuIEkgaGF2ZSBleHBlY3RlZC4gRmluZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJ1dCBpbiBzZXBhcmF0ZSBkaXNjdXNz aW9uIHlvdSBoYXZlIHByb3Bvc2VkIHRvIHB1dCBzb3VyY2UgSVB2NCBpbnRvIEVBTVQgdGFibGUs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgVGhhdCB3b3VsZCBicmVhayBsb2dpYyBiZWxvdyAtIGl0IHdvdWxkIG5vdCBiZSBwb3NzaWJs ZSBhbnltb3JlIHRvIHBpcGVsaW5lIDIgaW5kZXBlbmRlbnQgZW5naW5lczogTkFQVDQ0IGFuZCBO QVQ0Ni4gSXQgc2hvdWxkIGJlIG9uZSBzdGF0ZWZ1bCBlbmdpbmUuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTGV0J3Mgd2FpdCBmb3Ig dGhlIGZpbmlzaCBvZiBvdGhlciBkaXNjdXNzaW9ucyAtIG1heSBiZSB5b3UgaGF2ZSB0byByZXR1 cm4gdG8gNS4yLjQgYWdhaW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBFZHVhcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb206IHY2 b3BzIFs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzp2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZiBKT1JESSBQQUxFVCBNQVJUSU5F WjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNlbnQ6IDE3INC40Y7Qu9GPIDIwMjAg0LMuIDExOjAxPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVG86IDxhIGhyZWY9Im1haWx0 bzp2Nm9wc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAy IC0gY29uY2VybiBvbiBzdGF0ZWZ1bG5lc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIEVkdWFyZCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExldCB1cyBrbm93IHdoYXQgZG8geW91IHRoaW5rIGFib3V0 IHRoaXMgdGVudGF0aXZlIGFsdGVybmF0aXZlIHRleHQgdG8gcmVzb2x2ZSB0aGlzIGlzc3VlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgNS4yLjQuJm5i c3A7IEZvcndhcmRpbmcgcGF0aCB2aWEgc3RhdGVmdWwgTkFUIGZvciBleGlzdGluZyBFQU1UIGVu dHJpZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEZvbGxvd2luZyB0aGlzIGFwcHJvYWNoLCBpZiB0aGVyZSBpcyBhIHZh bGlkIEVBTVQgZW50cnksIGZvciBhIGdpdmVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVB2NC1kZXN0 aW5hdGlvbiwgdGhlIElQdjYtbmF0aXZlIHBhdGggcG9pbnRlZCBieSB0aGUgSVB2NiBhZGRyZXNz IG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBFQU1UIGVudHJ5LCB3aWxsIHRha2UgcHJlY2Vk ZW5jZSB2ZXJzdXMgdGhlIE5BVDY0IHBhdGgsIHNvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRy YWZmaWMgd2lsbCBub3QgYmUgZm9yd2FyZGVkIHRvIHRoZSBOQVQ2NC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvd2V2 ZXIsIHRoaXMgaXMgbm90IHN1ZmZpY2llbnQgdG8gZW5zdXJlIHRoYXQgaW5kaXZpZHVhbDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9ucyBhcmUgYWJsZSB0byBrZWVwIGV4aXN0aW5nIGNv bm5lY3Rpb25zLiZuYnNwOyBJbiBtYW55IGNhc2VzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1ZGlv IGFuZCB2aWRlbyBzdHJlYW1pbmcgbWF5IHVzZSBhIHNpbmdsZSBUQ1AgY29ubmVjdGlvbiBsYXN0 aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnJvbSBtaW51dGVzIHRvIGhvdXJzLiZuYnNwOyBJbnN0 ZWFkLCB0aGUgQ0ROIFRUTHMgbWF5IGJlIGNvbmZpZ3VyZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgcmFuZ2UgZnJvbSAxMCB0byAzMDAgc2Vjb25kcyBpbiBvcmRlciB0byBhbGxvdyBuZXcg cmVzb2x1dGlvbnMgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzd2l0Y2ggcXVpY2tseSBhbmQgdG8g aGFuZGxlIGxhcmdlIHJlY3Vyc2l2ZSByZXNvbHZlcnMgKHdpdGggaHVuZHJlZHM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBvZiB0aG91c2FuZHMgb2YgY2xpZW50cyBiZWhpbmQgdGhlbSkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O0NvbnNlcXVlbnRseSwgdGhlIEVBTVQgZW50cmllcyBNVVNUIE5PVCBiZSB1c2VkIGRpcmVjdGx5 IHRvIGVzdGFibGlzaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgZm9yd2FyZGluZyBwYXRoLCBidXQg aW5zdGVhZCwgTVVTVCBiZSB1c2VkIHRvIGNyZWF0ZSBhIHN0YXRlZnVsIE5BVDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGVudHJ5IGZvciB0aGUgNC10dXBsZSBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBz ZXNzaW9uL2Nvbm5lY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBtZWFucyB0aGF0IHRv IGltcGxlbWVudCB0aGUgb3B0aW1pemF0aW9uIHRoZSBOQVQ0NiBNVVNUIGJlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc3RhdGVmdWwuJm5ic3A7IFR5cGljYWxseSwgc3RhdGVmdWwgTkFUNDYgYXJlIGlt cGxlbWVudGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkgbWVhbnMgb2YgYSBzdGF0ZWZ1bCBOQVQ0 NCAod2hpY2ggb2Z0ZW4gbWF5YmUgaGFyZHdhcmUgb2ZmLWxvYWRlZCksPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZm9sbG93ZWQgYnkgYSBzdGF0ZWxlc3MgTkFUNDYuJm5ic3A7IElmIHRoZSBTb0MvY29k ZSBpcyBhYmxlIHRvIGRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RhdGVsZXNzIE5BVDQ2LCB0aGlz IHN0aWxsIGNvdWxkIGJlIHVzZWQgd2hlbiB0aGUgb3B0aW1pemF0aW9uIGlzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGlzYWJsZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBOb3RlIHRoYXQgYWxzbyBmb2xsb3dpbmcgRXJpayBpbnB1dHMsIHRoZSB0ZXh0 IGhhcyBtb3JlIG5vcm1hdGl2ZSBsYW5ndWFnZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsc28sIGZvciB0aGUgdGl0bGUgd2UgdGhvdWdodCB0aGF0 IGl0IHdpbGwgbWFrZSBzZW5zZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA0NjRYTEFUL01BUC1UIE9wdGltaXphdGlvbjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTm8gbmVlZCB0byBtZW50 aW9uIE5BVDY0LCB3aGljaCBpcyBwYXJ0IG9mIHRoZSA0NjRYTEFULjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBKb3JkaTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEBqb3Jk aXBhbGV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg77u/RWwgMTUvNy8yMCAxNjoxOCwg JnF1b3Q7djZvcHMgZW4gbm9tYnJlIGRlIEpPUkRJIFBBTEVUIE1BUlRJTkVaJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyUyMGVuJTIwbm9tYnJlJTIwZGUl MjBqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+djZvcHMtYm91bmNlc0Bp ZXRmLm9yZw0KIGVuIG5vbWJyZSBkZSBqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJj LmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IGVzY3JpYmnDszo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhp bmsgeW91ciBwb2ludCB3aWxsIGJlIHRvIG1ha2UgaXQgY2xlYXIgaW4gdGhlIGRvY3VtZW50IHRo YXQgZm9yIHRoaXMgb3B0aW1pemF0aW9uIHRvIHdvcmssIHRoZSBDTEFUIHNob3VsZCBiZSBzdGF0 ZWZ1bD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgaXMgdGhlcmUgKDUuMi40LiZuYnNwOyBGb3J3 YXJkaW5nIHBhdGggdmlhIHN0YXRlZnVsIE5BVCBmb3IgZXhpc3RpbmcgRUFNVCBlbnRyaWVzKSwg YnV0IEkgd2lsbCBtYWtlIHN1cmUgdG8gYWRkIHRoZSByZWxldmFudCB0ZXh0IGluIHRoZSBuZXh0 IHZlcnNpb24gdG8gbWFrZSBpdCBjbGVhcmVyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGluc2lzdDog bW9zdCBvZiB0aGUgQ0xBVCBpbXBsZW1lbnRhdGlvbnMgdG9kYXkgKHJ1bm5pbmcgaW4gYm90aCBD UEVzIGFuZCBVRXMpIGFyZSBzdGF0ZWZ1bC4gQXQgbGVhc3QgdGhpcyBpcyB0aGUgZGF0YSBJJ3Zl LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKb3Jk aTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEBqb3JkaXBhbGV0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvvu79FbCAxNS83LzIwIDE1OjU5LCAm cXVvdDt2Nm9wcyBlbiBub21icmUgZGUgVmFzaWxlbmtvIEVkdWFyZCZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmclMjBlbiUyMG5vbWJyZSUyMGRlJTIwdmFz aWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+djZvcHMtYm91bmNlc0BpZXRmLm9yZyBlbiBub21icmUNCiBk ZSB2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDsgZXNjcmliacOzOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGkgSm9yZGksPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBzdGlsbCBiZWxpZXZl IHRoYXQgdG91Z2ggKG5ldykgcmVxdWlyZW1lbnQgdGhhdCBDTEFUIHNob3VsZCBiZWNvbWUgU3Rh dGVmdWwgKG1hbmRhdG9yeSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBNYWtlIHNlbnNlIHRvIGluc2VydCBpbnRvIHRoZSBkb2N1bWVudC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZCBleHBsYW5hdGlvbiB3aHkgc3Rh dGVmdWwgTkFQVCBpcyBuZWVkZWQgd291bGQgYmUgZ29vZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGhhdmUgc3BlbnQgc29tZSB0aW1lIHRvIHJl c2VhcmNoIHRoaXMgLSBpdCBpcyBiZXR0ZXIgdG8gc2F2ZSB0aW1lIG9mIG90aGVyIHBlb3BsZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCBpcyBp bXBvcnRhbnQgcG9pbnQgdGhhdCBpcyBvbWl0dGVkIGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciB0aGUgbmFtZTogSSBkbyBub3QgaGF2 ZSBhbnkgc3Ryb25nIG9waW5pb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSnVzdCBJIHNlZSB0aGF0IGRyYWZ0IGlzIGFwcGxpY2FibGUgbW9zdGx5 IHRvIE1BUC1ULDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEFuZCBub3QgbXVjaCBhcHBsaWNhYmxlIHRvIFhMQVQgKGJlY2F1c2UgbWFqb3JpdHkgb2Yg aW5zdGFsbGF0aW9ucyBoYXZlIHN0YXRlbGVzcyBDTEFUKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCdXQgdGhlIG5hbWUgbWlzbGVhZCB0byBvcHBv c2l0ZSBjb25jbHVzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RWR1YXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBGcm9tOiBKb3JkaSBQYWxldCBNYXJ0w61uZXogWzxhIGhyZWY9 Im1haWx0bzpqb3JkaS5wYWxldEB0aGVpcHY2Y29tcGFueS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86am9yZGkucGFsZXRAdGhl aXB2NmNvbXBhbnkuY29tPC9zcGFuPjwvYT5dDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NlbnQ6IDE1INC40Y7Qu9GPIDIwMjAg0LMuIDE2 OjQ4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG86 IFZhc2lsZW5rbyBFZHVhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1 YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj52YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDs7DQo8YSBocmVm PSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj52Nm9wc0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2M6IDxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uQGlldGYub3JnIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRm LXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAy IC0gY29uY2VybiBvbiBzdGF0ZWZ1bG5lc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEhpIFZhc2lsZW5rbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoZSBpbXBsZW1lbnRhdGlvbnMgb2YgNDY0WExBVCwgY2FuIGRvIHRoZSBzYW1lIChh bmQgaW4gZmFjdCwgbWFueSBvZiB0aGVtIGlzIHdoYXQgdGhleSBkbykuIE5BVDQ0IHN0YXRlZnVs IGFuZCB0aGUgNDYgc3RhdGVsZXNzLiBNYW55IFNvQyBoYXZlIGVtYmVkZGVkIE5BVDQ0IGFjY2Vs ZXJhdGlvbiwgYnV0IG5vdCBOQVQ0Niwgc28gdGhhdCBleHBsYWlucyBpdCBhcyB3ZWxsLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBndWVzcyB0aGF0IGNvdWxkIGNs ZWFyIHlvdXIgY29uY2Vybj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEkndmUgc2V2ZXJhbCBjdXN0b21lcnMgZG9pbmcgNDY0WExBVCBpbiBicm9hZGJhbmQsIG9uZSBv ZiB0aGVtIDI1LjAwMC4wMDAgc3Vic2NyaWJlcnMuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgaW4g ZG9pbmcgNDY0WExBVCBpbiBjZWxsdWxhciBhbmQgYnJvYWRiYW5kLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiB3ZSBzYXkgaW4gdGhlIHRpdGxlIDQ2NFhMQVQv TkFUNjQsIEkgdGhpbmsgYm90aCBhcmUgY292ZXJlZC4gQnV0IEkndmUgbm8gaXNzdWUgdG8gY2hh bmdlIHRoZSB0aXRsZSBpZiB0aGlzIG1ha2VzIHNlbnNlIHRvIG90aGVycy4gV2UgY291bGQgZXhw bGljdGlseSBzYXkgNDY0WExBVC9OQVQ2NC9NQVAtVCBvciB3aGF0ZXZlci4gVGhpcyBpcyBhIG1p bm9yIGRldGFpbCwgaW4gbXkNCiBvcGluaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBKb3JkaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEBqb3JkaXBhbGV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IO+7 v0VsIDE1LzcvMjAgMTU6NDAsICZxdW90O1Zhc2lsZW5rbyBFZHVhcmQmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj52YXNpbGVua28uZWR1YXJkQGh1YXdl aS5jb208L3NwYW4+PC9hPiZndDsgZXNjcmliacOzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGkgYWxsLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEkgaGF2ZSBjb25jZXJuIG9uIHRoZSBjYXBhYmlsaXR5IHRvIHVzZSB0aGlzIG1lY2hh bmlzbSBmb3IgNDY0WExBVCwgYnV0IGl0IHNob3VsZCBiZSBmaW5lIGZvciBNQVAtVC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFdlIG1heSBoYXZlIG1hbnkgaG9zdHMgb24gQ1BFIExBTi4gVHlwaWNhbGx5LCA3MCUgb2YgRkJC IHRyYWZmaWMgaXMgc3RpbGwgZGVzaWduYXRlZCB0byBJUHY0IHNpdGVzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNvdXJjZSBVRFAvVENQIHBvcnQgY29sbGlzaW9uIGlzIHN0aWxsIHZlcnkgcG9zc2libGUg KGkuZS4gYWN0aXZlIHNlc3Npb25zIGZyb20gZGlmZmVyZW50IGhvc3QgbWF5IGhhdmUgdGhlIHNh bWUgc291cmNlIFRDUC9VRFAgcG9ydCksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgbm90IHN0YXRl ZCBhbnl3aGVyZSBpbiB0aGUgZG9jdW1lbnQsIGJ1dCB3ZSBuZWVkIHRvIHNxdWVlemUgKGZvciBw YXRoIHRvIEludGVybmV0IGl0IHdvdWxkIGJlICZxdW90O3NvdXJjZSBJUCBhZGRyZXNzJnF1b3Q7 KSBtYW55IHByaXZhdGUgSVB2NCBob3N0cyB0byBvbmUgSVB2NiAoYXNzaWduZWQgYnkgY2Fycmll ciB0byBDUEUgdXBsaW5rKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtDbGFzc2ljYWwgTjoxIHByb2JsZW0g dGhhdCBzaG91bGQgYmUgcmVzb2x2ZWQgYnkgTkFQVCAocG9ydCB0cmFuc2xhdGlvbiBpcyBtYW5k YXRvcnkpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTUFQLVQgaGFzIE5BUFQgZW5naW5lIG9uIENQRSBzaWRlIC0gaXQgbWFr ZSBzZW5zZSB0byBjbGVhcmx5IHN0YXRlIGluIHRoZSBkb2N1bWVudCB0aGF0IHdlIGFyZSBnb2lu ZyB0byByZXVzZSBOQVBULiBUaGVuIHRyYW5zbGF0aW9uIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOygxKSBOQVBUNDQgZm9yIG1hbnkgcHJpdmF0ZSBJUHY0IHRvIG9uZSBwdWJsaWMgSVB2NCAo d2VsbCwgaXQgY291bGQgYmUgbm90IHB1YmxpYywgYnV0IHB1YmxpYyBBJiM0MztQIGhhcyBiZWVu IGdpdmVuIHRvIE1BUCBDRSBhbnl3YXkgLSBiZXR0ZXIgdG8gcmV1c2UgaXQgZm9yIHVuaWZpY2F0 aW9uKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICgyKSBTSUlUICh3aXRoIEVBTVQpIGZvciBzaW5nbGUgSVB2 NCB0byBzaW5nbGUgSVB2NiAoMToxKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7WExBVC9DTEFUIGRvZXMgaGF2ZSBzdGF0ZWZ1 bCBOQVBUIGJ5IFJGQyA2ODc3LCBidXQgaXQgaXMgbm90IHBvcHVsYXIgLSBub3QgaW1wbGVtZW50 ZWQgYnkgbWFueSBjYXJyaWVycyAoaWYgYW55PykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgd291bGQg YmUgdGhlIGJpZyBuZXdzIHRoYXQgQ2FycmllcnMgc2hvdWxkIGNob29zZSBzdGF0ZWZ1bCBDTEFU IG9wdGlvbiBmb3IgNDY0WExBVC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCBpcyBiZXR0ZXIgdG8gdGVs bCB0aGVtIHVwZnJvbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgbmV4dCBxdWVzdGlvbiBjb3VsZCBiZTogZG9lcyBp dCBtYWtlIHNlbnNlIHRvIHVzZSBTdGF0ZWxlc3MgQ0xBVCBmb3IgYmFzaWMgNDY0WExBVCBhbmQg U3RhdGVmdWwgQ0xBVCBmb3IgdHJhZmZpYyBvcHRpbWl6YXRpb24gdG8gSVB2NCBzaXRlcz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBPciBpdCBpcyBiZXR0ZXIgdG8gdW5pZnkgb24gU3RhdGVmdWwgQ0xBVCBm b3IgZXZlcnl0aGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGdlbmVyYWwsIGl0IGlzIGEgcmV2b2x1dGlvbiBmb3Ig NDY0WExBVC4gQnV0IGl0IGlzIHNtb290aCBleHBhbnNpb24gZm9yIE1BUC1ULjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEhlbmNlLCBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gY2hhbmdlIHRoZSBuYW1lIG9mIHRo aXMgZHJhZnQgdG8gcmVmbGVjdCBNQVAtVCBhcyB0aGUgcHJpbWFyeSB0YXJnZXQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBF ZHVhcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEZyb206IHY2b3BzIFs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pm1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZg0K PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VudDogMTEg0LjRjtC70Y8gMjAyMCDQ sy4gMTU6MzQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aS1kLWFubm91bmNlQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+djZvcHNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi12Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3Bl cmF0aW9ucyBXRyBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogNDY0WExBVC9OQVQ2NCBPcHRpbWl6YXRp b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDogSm9yZGkgUGFsZXQgTWFydGluZXo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbGVqYW5kcm8gRCdFZ2lkaW88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQt b3B0aW1pemF0aW9uLTAyLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA6IDIxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERh dGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgOiAyMDIwLTA3LTExPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBYnN0cmFjdDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJUC9JQ01QIFRyYW5zbGF0aW9uIEFsZ29yaXRobSAoU0lJVCkg Y2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBhY2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBmb3IgSVB2NC1vbmx5IGRldmljZXMgb3IgYXBwbGljYXRpb25zIHRvIElQdjQtb25s eSBvciBkdWFsLXN0YWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzdGlu YXRpb25zIG92ZXIgSVB2Ni1vbmx5IGluZnJhc3RydWN0dXJlLiZuYnNwOyBJbiB0aGF0IGNhc2Us IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYWZmaWMgZmxvd3MgYXJl IHRyYW5zbGF0ZWQgdHdpY2U6IGZpcnN0IGZyb20gSVB2NCB0byBJUHY2PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKHN0YXRlbGVzcyBOQVQ0NiBhdCB0aGUgaW5ncmVzcyBwb2lu dCB0byB0aGUgSVB2Ni1vbmx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5m cmFzdHJ1Y3R1cmUpIGFuZCB0aGVuIGZyb20gSVB2NiBiYWNrIHRvIElQdjQgKHN0YXRlZnVsIE5B VDY0LCBhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBlZ3Jlc3MgcG9p bnQpLiZuYnNwOyBXaGVuIHRoZSBkZXN0aW5hdGlvbiBpcyBJUHY2LWVuYWJsZWQsIHRoZSBzZWNv bmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0cmFuc2xhdGlvbiBtaWdodCBi ZSBhdm9pZGVkLiZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHBvc3NpYmxlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW1pemF0aW9uIHRvIDQ2NFhMQVQgYW5k IE1BUC1UIHRvIGF2b2lkIHRyYW5zbGF0aW5nIElQdjYgZmxvd3M8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBiYWNrIHRvIElQdjQgaWYgdGhlIGRlc3RpbmF0aW9uIGlzIHJlYWNo YWJsZSBvdmVyIElQdjYuJm5ic3A7IFRoZSBwcm9wb3NlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNvbHV0aW9uIHdvdWxkIHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSBOQVQ2 NCB1dGlsaXphdGlvbiBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBv cGVyYXRvcidzIG5ldHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24vIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1p emF0aW9uLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDIiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0 aW9uLTAyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtNDY0eGxhdC1vcHRpbWl6 YXRpb24tMDIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12 Nm9wcy00NjR4bGF0LW9wdGltaXphdGlvbi0wMjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZv cHMtNDY0eGxhdC1vcHRpbWl6YXRpb24tMDIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXY2b3BzLTQ2NHhsYXQtb3B0aW1pemF0aW9uLTAyPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdjZvcHMgbWFpbGluZyBsaXN0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+djZvcHNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJUHY0IGlzIG92ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0 ID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vd3d3LnRoZWlwdjZjb21wYW55LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnku Y29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaGUgSVB2NiBDb21wYW55PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBp bnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykg bmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9z dXJlLA0KIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls ZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1p bmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdh cmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uDQogb3IgdXNlIG9m IHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5j bHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNv bnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3Jp Z2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0 ZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHY2b3BzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnY2b3BzQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSVB2NCBpcyBvdmVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJl IHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPGEgaHJlZj0iaHR0cDovL3d3dy50aGVpcHY2Y29tcGFueS5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LnRoZWlwdjZj b21wYW55LmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIElQdjYg Q29tcGFueTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUg aW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1 dGhvcml6ZWQgZGlzY2xvc3VyZSwNCiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRo ZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVk aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNv bnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1 dGlvbg0KIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBp ZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3Qg cmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5p Y2F0aW9uIGFuZCBkZWxldGUgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2Nm9wcyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj52Nm9wc0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IElQdjQgaXMgb3ZlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Imh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy50aGVpcHY2Y29tcGFu eS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBJUHY2IENvbXBhbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRh aW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4g VGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0 eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQogZGlzdHJpYnV0aW9uIG9yIHVzZSBv ZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGlu Y2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBi ZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24NCiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2 ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBt dXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29t bXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdjZvcHMgbWFp bGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+djZvcHNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdjZv cHMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+djZvcHNAaWV0Zi5v cmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SVB2NCBpcyBv dmVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcmUgeW91IHJlYWR5 IGZvciB0aGUgbmV3IEludGVybmV0ID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxhIGhyZWY9Imh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy50aGVp cHY2Y29tcGFueS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VGhlIElQdjYgQ29tcGFueTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUg cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0 byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJv dmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5 aW5nLA0KIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3Jt YXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVu c2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBh bnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uDQogb3IgdXNlIG9mIHRoZSBjb250 ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQg YSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2Vu ZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij52Nm9wcyBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_cb6fe24d877c44c290cb25a22e748044huaweicom_-- From nobody Mon Jul 20 09:18:56 2020 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 B4EF83A0D17 for ; Mon, 20 Jul 2020 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98IM3TQdvA3G for ; Mon, 20 Jul 2020 09:18:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AA23A0D12 for ; Mon, 20 Jul 2020 09:18:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jxYUo-0000LDC; Mon, 20 Jul 2020 18:18:30 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> <04d5eb82da794b9489474597cdb7fd11@huawei.com> <92b0db11479d4c5aa949776ccb42e899@huawei.com> In-reply-to: Your message of "Mon, 20 Jul 2020 15:27:00 +0000 ." <92b0db11479d4c5aa949776ccb42e899@huawei.com> Date: Mon, 20 Jul 2020 18:18:27 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 16:18:55 -0000 > Hence, I have to state again (previous time I did it for Philip's > challenge of partially migrated IPv6 host): > > we have to keep states for collisions of client), IPv4 (destination server)> pairs with flag "Disabled" > forever. This traffic should go to PLAT. > > But in this case with much bigger consequences: we should drop > user session that was supposed to flow against 1st EAM record > (it was unique before collision). Because we could not be sure > anymore that we would switch traffic to proper destination. I can see a problem here. If a host as a long term connection to a.example.com, and then after a while connects to b.example.com which has the same IPv4 address as a.example.com, but a different IPv6 address, then there doesn't seem to be any alternative but to drop the connection to a.example.com From nobody Mon Jul 20 13:17:35 2020 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 7B49F3A0E8C for ; Mon, 20 Jul 2020 13:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3RPrpGVx1Tk for ; Mon, 20 Jul 2020 13:17:33 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 889083A0E8B for ; Mon, 20 Jul 2020 13:17:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06KKHUJJ026232 for ; Mon, 20 Jul 2020 22:17:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 172792061E5 for ; Mon, 20 Jul 2020 22:17:30 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C7BC200B39 for ; Mon, 20 Jul 2020 22:17:30 +0200 (CEST) Received: from [10.11.240.60] ([10.11.240.60]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06KKHTmQ019815 for ; Mon, 20 Jul 2020 22:17:29 +0200 From: Alexandre Petrescu To: V6OPS WG References: Message-ID: Date: Mon, 20 Jul 2020 22:17:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] IPv6-only and gather.town for meeting at IETF X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 20:17:35 -0000 Gather.town is a game-like tool for virtually attending the IETF https://gather.town/z6N2SDxHebMdDAfo/IETF-108 IPv6-only access is when I use only IPv6 on my Windows 10. (right button on RJ45 symbol on lower right icon bar on Windows, then Ethernet, then modify adapter options, then select the Ethernet interface, then Properties, then un-check IPv4 and check IPv6). With this on, when I walk on the floor of IETF and meet some people it is impossible to 'Connect' - it shows "Connecting..." and it blocks there. But it works fine when on IPv4. Maybe this gather.town Connecting to others works for other people on IPv6-only. Alex From nobody Mon Jul 20 15:34:23 2020 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 E99AD3A1048 for ; Mon, 20 Jul 2020 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0X9hUbjE0lE for ; Mon, 20 Jul 2020 15:34:18 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A913A0C56 for ; Mon, 20 Jul 2020 15:34:18 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id i3so14686727qtq.13 for ; Mon, 20 Jul 2020 15:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aY3yo+MrI0arqw3v9mqwg66cBxd20ZBzTWs4kZQRk4U=; b=Lmpq1ZyQmlavEikBa8McYcjX5WraPXFJXiPdLudbJ/zMiJVmOlKgy2HtSnVwRjOBs7 G7Dw2n/yj33ypMMRP9gm4LyqvXr58Fb1jaFj02ndLaOysU3jWewW2iKAztNyHmKI5cm7 OBs/M1C9+48617pjpHiJc2r311pMrX/HVgj4BUdz1CprpDf+MPTJeG+lTvzGHldl/1v2 U+VDLHZ92T7JJK1qCpJBtXem5j9Yd6GQL51Tc3qxRhQ70MdZSX3qH41FIwTMBDoeOEjQ gST0exQmzs4256w7DnCTpT3XI3eFIWTxGwasAUod3/hxjdafNOViGaa8T2cxINL/kG29 dqNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aY3yo+MrI0arqw3v9mqwg66cBxd20ZBzTWs4kZQRk4U=; b=frqg0OK3OhMDjUwMGC+UJvZZm7+Dj7CdgXiwi80zY8uH6e5fpxoHdHjUgiGxDBW91q M1F8nuHMW6qNdwudo8C6sjvxWjRsmaUm10O4q76VfXnrKwigqK0oNTf6zlRGW6JIVFIm I1IJwi4R148BmmMkO91v7dmeq2canGUPN7LsrYkh5JBeisLFgWgx7MwfBextHOrMUAv9 ai6qpa4oYQpnkzwmKXNpyhZ+YF5HQVLGvn0i939Zjkn5Q+k1/tiil+7fZIn95MCL4iM4 XOFQ1qv4adI8lycajgCSYnCcsq89P7e/7FaTRMyQJGtuqbf7BWJrjJOnyfkMuNRT1bit vzTQ== X-Gm-Message-State: AOAM530HVo47CSP/1tI/+lajo3UC+koyAOAtwU1nPyFkBTaLJHdw9FbR h9cScZsuRHTKSw/QE+xWB7wm1XFddqWacLOJKwxiztvq X-Google-Smtp-Source: ABdhPJxmzlqd8HTKbK1G7uEryIwK5ha/BxLfCgkfON4klOQfH0OdLdmXelR0Mqify+OgQGAEgQteSDETjXErixxpBPE= X-Received: by 2002:aed:3081:: with SMTP id 1mr26704255qtf.118.1595284456673; Mon, 20 Jul 2020 15:34:16 -0700 (PDT) MIME-Version: 1.0 References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> <04d5eb82da794b9489474597cdb7fd11@huawei.com> <92b0db11479d4c5aa949776ccb42e899@huawei.com> In-Reply-To: From: Jen Linkova Date: Tue, 21 Jul 2020 08:34:05 +1000 Message-ID: To: Philip Homburg Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 22:34:22 -0000 I believe we are now saying the same thing more or less. The proposed mechanism seems to have an issue if the same IPv4 address can be mapped to multiple IPv6 addresses. It could be either a legitimate case or an attack - there is no way to tell actually, but it does not matter. On Tue, Jul 21, 2020 at 2:19 AM Philip Homburg wrote: > > > Hence, I have to state again (previous time I did it for Philip's > > challenge of partially migrated IPv6 host): > > > > we have to keep states for collisions of > client), IPv4 (destination server)> pairs with flag "Disabled" > > forever. This traffic should go to PLAT. > > > > But in this case with much bigger consequences: we should drop > > user session that was supposed to flow against 1st EAM record > > (it was unique before collision). Because we could not be sure > > anymore that we would switch traffic to proper destination. > > I can see a problem here. If a host as a long term connection to > a.example.com, and then after a while connects to b.example.com which has > the same IPv4 address as a.example.com, but a different IPv6 address, > then there doesn't seem to be any alternative but to drop the connection to > a.example.com > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry From nobody Tue Jul 21 04:12:44 2020 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 79F863A0A65 for ; Tue, 21 Jul 2020 04:12:42 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJovEVWh1kwp for ; Tue, 21 Jul 2020 04:12:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 011C03A0A64 for ; Tue, 21 Jul 2020 04:12:41 -0700 (PDT) Received: from lhreml737-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A4D09EBB5DB36E678DB9; Tue, 21 Jul 2020 12:12:38 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml737-chm.china.huawei.com (10.201.108.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 21 Jul 2020 12:12:38 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 21 Jul 2020 14:12:37 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 21 Jul 2020 14:12:37 +0300 From: Vasilenko Eduard To: Jen Linkova , Philip Homburg CC: V6 Ops List Thread-Topic: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest Thread-Index: AQHWXhc/K6tozmRt0kKaAvFhAK9ImakQFg/ggAAAyoCAAEM64P//7k2AgABFGMCAABlJc4AANoWAgADrXMA= Date: Tue, 21 Jul 2020 11:12:37 +0000 Message-ID: References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> <04d5eb82da794b9489474597cdb7fd11@huawei.com> <92b0db11479d4c5aa949776ccb42e899@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.194.159] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 11:12:42 -0000 Hi all, Potentially, it is possible to keep states for TCP/UDP ports too, then curr= ent sessions could be finished. Only new 5-tuples would be forwarded to PLA= T. But it is so much a complexity! Really stateful up to every flow. How much is the probability to see this problem in the real life? I believe= that probability is low. Because big OTTs would not share many FQDNs on on= e IPv4 address. Even less probability that they would do both: share IPv4 and use many IPv6= s for these FQDNs. Whatever strategy OTTs would choose for one FQDN does not matter - it could= be any relationship between : - we= would fetch only 1 choice from all possible combinations for one particula= r DNS resolution. Hence, I propose to drop. It should be documented in the draft. Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova Sent: 21 =C9=C0=CC=D1 2020 =C7. 1:34 To: Philip Homburg Cc: V6 Ops List Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and t= he rest I believe we are now saying the same thing more or less. The proposed mecha= nism seems to have an issue if the same IPv4 address can be mapped to multi= ple IPv6 addresses. It could be either a legitimate case or an attack - th= ere is no way to tell actually, but it does not matter. On Tue, Jul 21, 2020 at 2:19 AM Philip Homburg = wrote: > > > Hence, I have to state again (previous time I did it for Philip's > > challenge of partially migrated IPv6 host): > > > > we have to keep states for collisions of > client), IPv4 (destination server)> pairs with flag "Disabled" > > forever. This traffic should go to PLAT. > > > > But in this case with much bigger consequences: we should drop > > user session that was supposed to flow against 1st EAM record > > (it was unique before collision). Because we could not be sure > > anymore that we would switch traffic to proper destination. > > I can see a problem here. If a host as a long term connection to=20 > a.example.com, and then after a while connects to b.example.com which=20 > has the same IPv4 address as a.example.com, but a different IPv6=20 > address, then there doesn't seem to be any alternative but to drop the=20 > connection to a.example.com > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 21 06:15:14 2020 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 2190B3A0805 for ; Tue, 21 Jul 2020 06:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uda4BvIcARPa for ; Tue, 21 Jul 2020 06:15:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FBF3A0813 for ; Tue, 21 Jul 2020 06:15:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jxs6T-0000J9C; Tue, 21 Jul 2020 15:14:41 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <09FC08EF-82ED-49DD-B849-38BEDC174FDA@consulintel.es> <02f63b1af4284239801567cfaf4d9c9b@huawei.com> <04d5eb82da794b9489474597cdb7fd11@huawei.com> <92b0db11479d4c5aa949776ccb42e899@huawei.com> In-reply-to: Your message of "Tue, 21 Jul 2020 11:12:37 +0000 ." Date: Tue, 21 Jul 2020 15:14:38 +0200 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 13:15:13 -0000 > Hi all, Potentially, it > is possible to keep states for TCP/UDP ports too, then current > sessions could be finished. Only new 5-tuples would be forwarded > to PLAT. But it is so much a complexity! Really stateful up to > every flow. That solves this issue. EAMT can be use to establish forwarding/translation state, so deleting an EAMT would not affect existing flows. I think it is better to first document a working solution and then abandon it if it proves to be too complex or fragile. From nobody Thu Jul 23 09:48:44 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C133A0C53; Thu, 23 Jul 2020 09:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ron Bonica via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.10.0 Auto-Submitted: auto-generated Precedence: bulk Cc: v6ops@ietf.org, owen@delong.com, v6ops-chairs@ietf.org, Owen DeLong , iesg-secretary@ietf.org Message-ID: <159552292174.23975.6505626742924512348@ietfa.amsl.com> Date: Thu, 23 Jul 2020 09:48:41 -0700 Archived-At: Subject: [v6ops] Publication has been requested for draft-ietf-v6ops-slaac-renum-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 16:48:42 -0000 Ron Bonica has requested publication of draft-ietf-v6ops-slaac-renum-02 as None on behalf of the V6OPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ From nobody Thu Jul 23 13:44:51 2020 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 F1B1F3A0D8C; Thu, 23 Jul 2020 13:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=IGIjsqZ3; dkim=pass (1024-bit key) header.d=juniper.net header.b=Eahypq71 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EQ_HTV1jOiO; Thu, 23 Jul 2020 13:44:47 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A6ECC3A0D88; Thu, 23 Jul 2020 13:44:47 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06NKWjLq016785; Thu, 23 Jul 2020 13:44:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=WSN3tjRWdRUYzUYuKT6e37/6NC1GWamXILqkE1wbap0=; b=IGIjsqZ3qQPt+crMv7e+sWotWdlTHMKsImiPhb3gZkYcCibkwW/xQADflult0zFzbipi LhZv79fg8v937CmOOFwbBcmwTJP5td07ROBjoYmx8bC9Hk3CLCoGr4vPg150VtkqIMT9 qL0Znli6kQOqaTd8No3T80CDbs7CwVi5r+F7yD5HkjYA7CgJslzF4dg7LTdl5hZj2+h2 u1NJ8sZOQJLWQtd38fqa8XCZj58Yt6Gj4c5+dgcVHCS9MA2eaAfJIQW1Z0Q4TBPIhNJp 0gWwnGOjLf4Mqi5U31CBahUwDJ31inU+Ifaht+4z9a1nhAx6HNrZT7HHfy9Ab6ILIs03 Ng== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by mx0b-00273201.pphosted.com with ESMTP id 32ehd3b8e9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jul 2020 13:44:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dl8kgCU4mZKPimJnJIxfqsLPIGDyPKHuedgwN+QWI1zQW+cDJVw5souDalrorPMK9trjdG4Nigi9Afw7GXM2MTuctpkMWbW1WrdCuWLDZ8NKhzyahLrSQZAMb4kl3Nb0xVNmIM7lJhrn0dJIK9fnZ+Cmg6mv5Lofzk29Y5pOdYPhHaNmkFZns7Hw4JR7UQ502G2TwcpRYxCQ5EEq9E3C8OTYmJPKKnSqPP2n/deDKdkd6RUMKqhAXljQYLTfJ7Yxd49jllL6oWFa/D0syV7bE6s7Zjb+zijKrIXaIFMohWGb8pozETTx6UjKxlztrmPhudsRqGO2NmtYI7MG28WuoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WSN3tjRWdRUYzUYuKT6e37/6NC1GWamXILqkE1wbap0=; b=SKISeZ4TNw8Crv/cDcLPM0sWt1mVORor8CWQSajDb0Z5lRwfy08h8gI8ic9o8v9VT/M9SxZbKTAto/9QmninrNXpjkODhm4WmG1rXNsY2tf2Tlt5cpHV5meA9jT+7ddrExkRJ0wxx1hG9GLpVD+SJTAGUWOilQmtIr56FQvLEzzO9vZIaQuN0g1b9KOrR3rVQO85Dhv3FFXkuwdiIzm5ZBjJiJYopI7H2M6bWSxwq5hnf1WPSc8tgssXAepiSikKOjv1vRP3cexJXCgBzNRajV0zbJCV8ZM7Q1BT6ukfBBxbHNBG3wFDvN2I250C/kY2I5kVlysOjXDuBaszx+HE3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WSN3tjRWdRUYzUYuKT6e37/6NC1GWamXILqkE1wbap0=; b=Eahypq71uZcOrfdlU7mhAWxmAsFOgLeTu3DF7xIspCLyBUKjfeF4jRuwiLdLrHVfLwkXKEy0TiH6KLg3vtPzF5p0Zftf0CmRWsDgUPFz7K4tpYxkDWLSWCjT6FBZK12PURpqZ9Ji/TH0wG9nepaIhl2mbwSP7GyntUomQEQSsuk= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM5PR05MB3115.namprd05.prod.outlook.com (2603:10b6:3:c9::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Thu, 23 Jul 2020 20:44:42 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e%7]) with mapi id 15.20.3216.018; Thu, 23 Jul 2020 20:44:42 +0000 From: Ron Bonica To: "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-cpe-slaac-renum: IPR Thread-Index: AdZhMfTBukn2fnzKQUaQP79C1gjs5A== Date: Thu, 23 Jul 2020 20:44:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-07-23T20:44:41Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=70aaa48e-9a7e-4eb8-b343-48e3e1e3cc36; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.132.205] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a6612b47-7d3b-42d1-8eec-08d82f4939e0 x-ms-traffictypediagnostic: DM5PR05MB3115: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jgFdjstafwYZLSK1GVNHz6zuAhCQUknT8A5UzGuf+C1bn5JJyKKjYhB8nlC9okoHTJSu+ejIpLKU3McPsmomUMHYe1wOvEMaJqKbNLUIZlSGFK+pAyj3IRqErF7X7YlMZBF2tw9JfgL/C2GsC8zzCwNT8Ri4jet3JlsffEas/AutD4IbnpP/S1HDOj54Wprk2s70eUcjO54e6janhTDgFcoU1Xzmci/7eBDmmQ4pzh3rtIc+ItIX7IHwClH2izQ5+TkwnP2gwJ+tD3XBgPcnSuemmkC6OcZjVuatv7Ek4/CmlJ20XsKRmQfWU6La+guORE8SV4Eon1zUna75fHtbHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(8936002)(316002)(186003)(450100002)(110136005)(558084003)(64756008)(478600001)(71200400001)(8676002)(66946007)(52536014)(55016002)(66556008)(66476007)(66446008)(76116006)(26005)(86362001)(33656002)(2906002)(7696005)(6506007)(9686003)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: jjbm9xXN8qT/bzkngbyWxdXkqb1pQB0TNWZsUXDiW+KpbNHGlYTBs4Sznmv/Ik8GsO8NEJyj3U6AsgrF/AX9L+E0DZbPCTcourm6piRPAhVShVmuFD4QlhtzHF1pEH4/KO72j9ussE7Qy/OlYsLPDfcp0TvHCnsOUDd7Gd8NDuqHjHHWoJgd3LYOPUsbZpAyA8lV+UNm0fw22ZU6vwLp6QK9XlRfgQfwWU6wm/7yEx+Ue8AEUFR2WLGtzntUI7vgk9sAb3zYWg09lo5Xj1wJNn6a1cUGDDdgvtkKcOBcFfTC48UHIb75+TEjhapxfszWw/NOCupVqUdXg1+I1xl3F3aWPwH0qjQwsLwxxxmSPHa++jo7AkLFJXIMwsrJi8fluEvCGCoiQoKrsRGiIYEnJNwBkHCK1gtZar7dpmTz3yiFTMXwNXMBRh09fmk36Dn42vKujpPrbxdKPBlxhkvVwXwLBgrzMRW1b3pusbj3nC0CJJv/BHp8mnoaRxYVilom2xuY8SRBKdcKUNBhbl91yFqqKkybryhRtznRENDSyiAZwQB5RIS6zEVOxqjCistcQ3cGFYYzwXWbTde07drMVfcIQEqjgQ/wz5qBftD/ty+5kIfTD6ilfG2US8R7C+FX6BQ0abMU8qOn2R72Q9iuMA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB63485A6D3D95DF2F2806E7A7AE760DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6612b47-7d3b-42d1-8eec-08d82f4939e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 20:44:42.2291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Pa/f6AcKKiyDzZnwchEdPfDoYSlN8pGhV9JMOgknMs1s2zwVXNJ5Q1sbdcm420ugbR44eIxFgQUavx1woIKDwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_09:2020-07-23, 2020-07-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 mlxlogscore=554 phishscore=0 adultscore=0 clxscore=1011 bulkscore=0 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007230146 Archived-At: Subject: [v6ops] draft-ietf-v6ops-cpe-slaac-renum: IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:44:49 -0000 --_000_DM6PR05MB63485A6D3D95DF2F2806E7A7AE760DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Co-authors, Please respond to the list indicating whether you know of any IPR associate= d with draft-ietf-v6ops-cpe-slaac-renum. Ron Juniper Business Use Only --_000_DM6PR05MB63485A6D3D95DF2F2806E7A7AE760DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Co-authors,

 

Please respond to the list indicating whether you kn= ow of any IPR associated with draft-ietf-v6ops-cpe-slaac-renum.<= /p>

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Ron


Juniper Business= Use Only

--_000_DM6PR05MB63485A6D3D95DF2F2806E7A7AE760DM6PR05MB6348namp_-- From nobody Thu Jul 23 13:46:39 2020 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 45D303A0D91; Thu, 23 Jul 2020 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=tsBHqyJX; dkim=pass (1024-bit key) header.d=juniper.net header.b=RflVIOS4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APseB8_1xMju; Thu, 23 Jul 2020 13:46:36 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 932133A0D90; Thu, 23 Jul 2020 13:46:36 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06NKXrWd022547; Thu, 23 Jul 2020 13:46:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=6XntwDcJphtlNsoauQfkTufgONOiGHemnZ3DYmp57pA=; b=tsBHqyJXVsKfCStOVx+XqonCt1gvrqL/Cv7jeOU/NZ8C6jb5xUO5KqzIKW/GOgGrSqTf wrQVFIjutCSE5S9yhCHSTUkLFaejQ36d7oT0TgbvWRRSkrZtDsgHKs4RUVfF/ib2849z T/erJ/rejAaIP44N2S9KVmmUm69JT8AOV/6tiBzXyWCYhEnjCwrPGdZdOxFLw3drsALl bQCskjQIv2GL6nuc3cNnZtDI1BO7BFXl2/ztUg3Qf/39pOW1VqQVitb6TbZgbL4zIYjU USyB+u/YtII0BDljV7iw78+shhKN0nla0UFCoTnTJvRspZxT1O19KuJldESxuBgI8tGN tg== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2109.outbound.protection.outlook.com [104.47.70.109]) by mx0a-00273201.pphosted.com with ESMTP id 32f6wh15ku-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jul 2020 13:46:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JmKxEW7UahUR237U3j+aYBZdyJElNBocquJCq/4edI2pru6/ceGEnFiDHTDG5Rzq+uK9ORdfJFrtlXTl5zk/E/w0FYM/NKmWrctqEzBB3WAPDajCF+z5PvtjtiUDUAP2b+oLYQrKYeMK3J1IH/rrLUKjA6GjgcauNG+aUMfc9QGAHg0nSlmuzPJoDSNPTKUCSx8CDny3ldMebsRb8m8i3twZhMIOUzz6UKlj0el46cTae7fLnEinwcfMmN+vgrui4vevHG2h9kFIQhJOvuFG13iy0vJHJLzAkXdvJ9CLxyR69dIr2jvKzhbJsnuLjEP38x4VOeNQQVAWlt0ofddUZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6XntwDcJphtlNsoauQfkTufgONOiGHemnZ3DYmp57pA=; b=jTfxkjtzWARHW0FeGrcBDBNYJ9AEDAYyq0rseoAQxC67p3iWnZckD+njz4t5xtDlUT67US7aKcnCbIlB3PpwcT/3E9T46eQkMQIT/g5y+59ODBgIAKeZeFB23VHxtaDbCBuKHPdhY5YyrQqvUd/h5hImQZTdAaIrlmRdrsQyYL962Ixq8qUGxOed9WdtEWw1HN0Ti7NtD+hxEDXl3vuhb1hWWwokbv+i3V4ByEHyx4hyruBUUG05D8P15tLNbbVlQmdQgrKSANFAOPb9mgErNrnltLW/5nyasSo358Bx2v5YSOOSBlr64ptsckg3aoIY+sXCX7lEsRuIyNPkCI/OMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6XntwDcJphtlNsoauQfkTufgONOiGHemnZ3DYmp57pA=; b=RflVIOS4kdh8UEWXAvrjjc8nG8CobxUUKMb7+YbVSkZmGMP9MetpfBfJzoCKQwKWFxmRz1GufvGNuhMRx2YEP00jAY8I4TT1OVszIjZgcudh3dahz7U4vne6zvpRfwKKnMEI+2jqFLjL/PvOL1al+LOSvH9qNHbJlMitD8WmoJQ= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM5PR05MB3467.namprd05.prod.outlook.com (2603:10b6:4:45::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.17; Thu, 23 Jul 2020 20:46:34 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e%7]) with mapi id 15.20.3216.018; Thu, 23 Jul 2020 20:46:34 +0000 From: Ron Bonica To: "draft-ietf-v6ops-slaac-renum@ietf.org" , "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-slaac-renum IPR Thread-Index: AdZhMj7y7fbC/hz4RG6l2mDxP4ar2g== Date: Thu, 23 Jul 2020 20:46:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-07-23T20:46:33Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=a9b6e9cc-2cdc-495d-914d-849e8569c284; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.132.205] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 375e3ff3-5f08-4aee-fc04-08d82f497caa x-ms-traffictypediagnostic: DM5PR05MB3467: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nfh/ws9nVg5PnrWC012VpXsMcGm1VernN5PuqR8+ihBKVlq2qHC4nij1QsviSQzi/lvvI0Jvl3/ee6pvoMhWx3bwxEk/tw3lXURKsSyLZRv+A621sYY3JELdZ1cZc/61j+UwiJ3+kAXwF1EmBj8WMqrOy3jFLoNTltserckbgoNqCwdrt80BYEkuf4+znlVRMbpEWBdgYdpVMSmMpL62mAzgXUbWkREr/B6LISGtr+snX1kg5lsmbM4Ikw3wPbrP22yOCAl3QjdK5+KD4kawJyyFh0muds1VFqJxmokwvQsKsn5ywuCP3OVr0cJY2CuxixJiG3O1xwtGgqtvWVyi8A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(366004)(136003)(39860400002)(8936002)(55016002)(7696005)(110136005)(9686003)(316002)(33656002)(2906002)(558084003)(66476007)(86362001)(5660300002)(52536014)(64756008)(76116006)(66446008)(66946007)(71200400001)(66556008)(26005)(186003)(8676002)(6506007)(450100002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TIE03AAIm1KSVK6r8T9csxG5bXsct48i2p+9XoHv5ECRxfoDeSYdA/4LhKIizusILxNHjwe+zeQjRabzCQ9bcvbUg3h9CypMUuBka3MqcDaooZKJcbmhjK2jUZ58mwi32YPtccYCzCm3r9Rk/e7eULayN01MRMzuvTNdcWoUGr/0lAMYOzb5z6cAp76TUsOhRf34VLmlsrw0RCMOVGymslJ1MsTa98bQHKBBF1Ux3hZ0BMtVZ1kVdz1KnpdYRs8NgbA5ao5BkrEW2EgjALnMfwKUTtMZV2rREldCNdT60QsqipCBFFtDLuL5WzjI71KdFoi60Ur7qbACm61jgQzlN2HS5qyoZR6ungqI9ViMmOvPj6KNur6T6OEtlJ+By1IUB692J6hkC/MmfRPTI61rauE/eWNvLDiktHGLAmaytwvoGoduxuStG29RAfOzuvkQw+G/jjvjHwEE6yGIq7EWmZS7+T8QMlDnaGThNT0QBF+AqB0vUe6Bg18KXyGXa0Zg x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB63489B81C4816FB5383C6AE4AE760DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 375e3ff3-5f08-4aee-fc04-08d82f497caa X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 20:46:34.3213 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yYqJ3Sl1wNIoC3qUkisrRtaKFbcWScTnzCfo1G0TwhCJB6542tWVH9DTtJyyDDKb1T0RqE7tn5QTvGs62aAYlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3467 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_09:2020-07-23, 2020-07-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 phishscore=0 suspectscore=0 spamscore=0 clxscore=1015 adultscore=0 bulkscore=0 mlxlogscore=540 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007230146 Archived-At: Subject: [v6ops] draft-ietf-v6ops-slaac-renum IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:46:38 -0000 --_000_DM6PR05MB63489B81C4816FB5383C6AE4AE760DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Co-authors, Please respond to the list indicating whether you know of any IPR associate= d with this draft-ietf-v6ops-slaac-renum. Ron Juniper Business Use Only --_000_DM6PR05MB63489B81C4816FB5383C6AE4AE760DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Co-authors,

 

Please respond to the list indicating whether you kn= ow of any IPR associated with this draft-ietf-v6ops-slaac-renum.=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       Ron

 


Juniper Business= Use Only

--_000_DM6PR05MB63489B81C4816FB5383C6AE4AE760DM6PR05MB6348namp_-- From nobody Thu Jul 23 13:47:50 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E863A0D9F; Thu, 23 Jul 2020 13:47:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ron Bonica via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.10.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Owen DeLong , v6ops@ietf.org, owen@delong.com, iesg-secretary@ietf.org, v6ops-chairs@ietf.org Message-ID: <159553726814.31937.13984423913554549512@ietfa.amsl.com> Date: Thu, 23 Jul 2020 13:47:48 -0700 Archived-At: Subject: [v6ops] Publication has been requested for draft-ietf-v6ops-cpe-slaac-renum-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:47:48 -0000 Ron Bonica has requested publication of draft-ietf-v6ops-cpe-slaac-renum-03 as Proposed Standard on behalf of the V6OPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ From nobody Fri Jul 24 02:15:22 2020 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 C730D3A0CA4 for ; Fri, 24 Jul 2020 02:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiSYvEusdrhz for ; Fri, 24 Jul 2020 02:15:18 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (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 33B9A3A0CA1 for ; Fri, 24 Jul 2020 02:15:18 -0700 (PDT) Received: from [IPv6:2a01:e35:2e59:ce10::da3d:a356] (unknown [IPv6:2a01:e35:2e59:ce10::da3d:a356]) by smtp4-g21.free.fr (Postfix) with ESMTP id 12D0A19F57E for ; Fri, 24 Jul 2020 11:15:14 +0200 (CEST) From: Alexandre Petrescu To: V6OPS WG References: Message-ID: Date: Fri, 24 Jul 2020 11:15:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8BF998A551BFC776DD94B18F" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6-only and Microsoft Teams X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 09:15:20 -0000 This is a multi-part message in MIME format. --------------8BF998A551BFC776DD94B18F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Microsoft Teams, a tool for online collaboration, works fine on IPv4. When tried on IPv6-only computer (IPv4 stack turned off) the initial phases of connection works, but connecting to a videoconference does not work. Alex Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit : > Gather.town is a game-like tool for virtually attending the IETF > > https://gather.town/z6N2SDxHebMdDAfo/IETF-108 > > IPv6-only access is when I use only IPv6 on my Windows 10. (right > button on RJ45 symbol on lower right icon bar on Windows, then > Ethernet, then modify adapter options, then select the Ethernet > interface, then Properties, then un-check IPv4 and check IPv6). > > With this on, when I walk on the floor of IETF and meet some people it > is impossible to 'Connect' - it shows "Connecting..." and it blocks > there.  But it works fine when on IPv4. > > Maybe this gather.town Connecting to others works for other people on > IPv6-only. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------8BF998A551BFC776DD94B18F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Microsoft Teams, a tool for online collaboration, works fine on IPv4.

When tried on IPv6-only computer (IPv4 stack turned off) the initial phases of connection works, but connecting to a videoconference does not work.

Alex

Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit :
Gather.town is a game-like tool for virtually attending the IETF

https://gather.town/z6N2SDxHebMdDAfo/IETF-108

IPv6-only access is when I use only IPv6 on my Windows 10. (right button on RJ45 symbol on lower right icon bar on Windows, then Ethernet, then modify adapter options, then select the Ethernet interface, then Properties, then un-check IPv4 and check IPv6).

With this on, when I walk on the floor of IETF and meet some people it is impossible to 'Connect' - it shows "Connecting..." and it blocks there.  But it works fine when on IPv4.

Maybe this gather.town Connecting to others works for other people on IPv6-only.

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------8BF998A551BFC776DD94B18F-- From nobody Fri Jul 24 02:49:39 2020 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 D09B53A0DD2; Fri, 24 Jul 2020 02:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtcJWImoDgPK; Fri, 24 Jul 2020 02:49:37 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2052.outbound.protection.outlook.com [40.107.22.52]) (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 B3E0C3A0AD9; Fri, 24 Jul 2020 02:49:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZFB7sDOOnMBBQFyas1fIZXS65TwQAyxSVPK7pwRKX/n+F1z07hq6TGq6V0mQ+d2tI9eclfUT949HR4gPWtr9hfsvR3KGMs1yYwiZL9EbgECze+1/7BvXFZSjCRlI5N6oV1E7A4m/PkO3fDtBA9NnlBwNjChqhL7l2zWXXesf3EndXpzARO0qL+3+950kyNyg8ENpSvPX+WF0RGjUhQL3aVcOTFGAxau+HUeAI58nD8ZEtOwBYa1SIV7jsdqKbpIZY7jKZrJ8xgj9OE4hy92kW1X41V1y0JCSERkwBCpZCIaEycJ1kHzbjPaA/2OzDJ6gW6VSIpSPIU+ZqrIyxzP7uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ijvnwRV1/OwzmzUY5szTtBxfUF7aoUbZh2GEEkMrCCU=; b=fM3ZGDBbOfeirNjKLa+VYWEmKKByaSBB2a/Tqaj0Jf/cHR9jUIpJSj6O7vuGCsYpyCf4SQivrGlsTYZ18ZVo3mCS9iKkVVUiLcgaJXblhCi4O9yrLX0Qz8inXfJqMuiKracz6WW4lcrBcZw/xpdvV0K3d2FT8cH762ydeBiBSxXh8nUC/cP3BHyS6OjH8G5wAt2AC0IV5KS1M8aTzxi5zEkQ9nYWCUY1sdspXjTTOLRtfsuG4LP7Jo785c53a27+kqQaO+jqM+n11yg7I0YHHacisUHn9EnbKzyUu6gKB9PGeJrUQi2ul7oZBd0dX8AO+VHDRdnUnXshp+kRL6UVig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ijvnwRV1/OwzmzUY5szTtBxfUF7aoUbZh2GEEkMrCCU=; b=eBdS7sGR7xVTYQdtfn2X/JW22oLNxJtcGZTEK8zVJm9hvq83B7fzhJ1h0JhbfKiREUbqHwdF6j98TR5F6XKnLPboV9zf8/ZXCzU9VnDEE6E7z/+axHeqGtfN+G6ul2YZFjN/S83IEDAJ2QZGSmxcCSUFRvauY3MmffYYemeH8Vc= Received: from DB8PR06MB6122.eurprd06.prod.outlook.com (2603:10a6:10:106::25) by DB7PR06MB4331.eurprd06.prod.outlook.com (2603:10a6:5:2c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Fri, 24 Jul 2020 09:49:28 +0000 Received: from DB8PR06MB6122.eurprd06.prod.outlook.com ([fe80::6116:8c06:dcb8:dfda]) by DB8PR06MB6122.eurprd06.prod.outlook.com ([fe80::6116:8c06:dcb8:dfda%7]) with mapi id 15.20.3216.024; Fri, 24 Jul 2020 09:49:28 +0000 From: "Patterson, Richard (Sky Network Services (SNS))" To: Ron Bonica , "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops@ietf.org" Thread-Topic: [EXTERNAL] draft-ietf-v6ops-cpe-slaac-renum: IPR Thread-Index: AdZhMfTBukn2fnzKQUaQP79C1gjs5AAdiUWA Date: Fri, 24 Jul 2020 09:49:28 +0000 Message-ID: <3888C6E6-A504-4CC9-8FAB-79910C7EA417@sky.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=sky.uk; x-originating-ip: [2a02:c7f:c282:e901:dfa:34f0:aa9e:f038] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f053b14-ff95-4847-eaab-08d82fb6db4b x-ms-traffictypediagnostic: DB7PR06MB4331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ywc6KCEYFxh1ItubBK5Kq+6lyXWislFyCCwQtg8ApKJgm6lJ8C8LjRQQ9E4nJLnEqMwDKUDt8hEDNqK5+LLJwTfUnZ/WNmkAUGS/HZtPG/nFUPtSyzzOc/1UgDi/7uvjQlX7rstkZbI7lOfhzgGU6iKUVR4lThojNe3yD1SDEBn0WYNPMbTHQze1CF/L2a4eszQFxUHOk6j9JwGUAUx6Rl10RP85yVCedIauedMzFtJFa7iSswyb/wkoKA1uIfJ4J4YwFPKfwMlu51jOVHDcz74TAD6TCWj5Z1jl58HKvMAHaIs8UoqFtTTU9JhBnymhLY1qPx43SHehdif9+Co3sg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR06MB6122.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(396003)(366004)(136003)(346002)(6512007)(66446008)(66556008)(76116006)(66946007)(64756008)(2616005)(91956017)(33656002)(66476007)(53546011)(86362001)(36756003)(110136005)(8676002)(316002)(9326002)(2906002)(6486002)(8936002)(5660300002)(478600001)(186003)(6506007)(71200400001)(83380400001)(45080400002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: I0a5t0ONEKTnZAOWLazRbKKWmOoF+S3PL4jAS7q31KN4eSjr2bjn2768Pi8ehazV2nQ0Z3v4nA9TB4O3tSZ5cr8PgOIMoT8ZncObbGs7AoyQzULfOytN76xDzLkqSvWEg9CkVyavhJj0IYFr6Bcu8pQNhlLpkNDe6ijwh2B0FovdBDddxEMdICBSPKX1DA3jk+MRZpvHCt89rzIR2qMZl0zld5sYSBoEBUNroPou8du8AfZfIL3yq7rGxBSVVDRIHSafb2Wf1nupNwxjniLqAFfC55lgsjWyNuwFpVCuP8X+r071d5cAG9TztCZS9cqaZ0TSalftmEm+4K68cZpB5FEL3ZMRz89BtDPszGl06D50xNr+mRj7ipSeE41M8XLHEuaDKue2MfTZdNQSuPEZsR0DatdGsI4KK6OowhlHR7chd94pZ/mN21xyCwDuxN6OPM92OpIx3Mfhy0fOZEaDE5lo/kzfh6cd2cGEYhTAQvyk5y6sdrUbnctkdaUTV8dfwEXwIRZ1PKW1N9wKmzD5/WPdMnMiqi+6oJ+E3g0BIdKYFGgoiDLkcJmS9oYUIyxu x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3888C6E6A5044CC98FAB79910C7EA417skyuk_" MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB8PR06MB6122.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f053b14-ff95-4847-eaab-08d82fb6db4b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2020 09:49:28.1274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U3OcCB/wDjEY28sIAIUXNUuJzOuwWx00u7bDmoHxTj1xXWHus/zH757gJidjOR0jglYxd9w07WkArNGjO+++PqzRf36hr3aNY56wWTNWlts= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR06MB4331 Archived-At: Subject: Re: [v6ops] [EXTERNAL] draft-ietf-v6ops-cpe-slaac-renum: IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 09:49:39 -0000 --_000_3888C6E6A5044CC98FAB79910C7EA417skyuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGZvciB0aGlzIGRyYWZ0Lg0KDQpG cm9tOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KRGF0ZTogVGh1cnNkYXksIDIz IEp1bHkgMjAyMCBhdCAyMTo0NA0KVG86ICJkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51 bUBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtQGlldGYub3JnPiwg InY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIGRy YWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtOiBJUFINClJlc2VudC1Gcm9tOiA8YWxpYXMt Ym91bmNlc0BpZXRmLm9yZz4NClJlc2VudC1UbzogPGZnb250QHNpNm5ldHdvcmtzLmNvbT4sIDxq YW5AZ282LnNpPiwgPHJpY2hhcmQucGF0dGVyc29uQHNreS51az4sIDx2b2x6QGNpc2NvLmNvbT4N ClJlc2VudC1EYXRlOiBUaHVyc2RheSwgMjMgSnVseSAyMDIwIGF0IDIxOjQ0DQoNCkNvLWF1dGhv cnMsDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgd2hldGhlciB5b3Ug a25vdyBvZiBhbnkgSVBSIGFzc29jaWF0ZWQgd2l0aCBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFh Yy1yZW51bS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9uDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClRoaXMgZW1haWwgaXMgZnJvbSBhbiBleHRlcm5hbCBzb3VyY2UuIFBsZWFzZSBkbyBub3Qgb3Bl biBhdHRhY2htZW50cyBvciBjbGljayBsaW5rcyBmcm9tIGFuIHVua25vd24gb3Igc3VzcGljaW91 cyBvcmlnaW4uIFBoaXNoaW5nIGF0dGVtcHRzIGNhbiBiZSByZXBvcnRlZCBieSB1c2luZyB0aGUg cmVwb3J0IG1lc3NhZ2UgYnV0dG9uIGluIE91dGxvb2sgb3Igc2VuZGluZyB0aGVtIGFzIGFuIGF0 dGFjaG1lbnQgdG8gcGhpc2hpbmdAc2t5LnVrLiBUaGFuayB5b3UNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCklu Zm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cyBtYXkgYmUg cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3Ig dGhlIGFkZHJlc3NlZS4gVGhlIHZpZXdzIGV4cHJlc3NlZCBtYXkgbm90IGJlIG9mZmljaWFsIHBv bGljeSwgYnV0IHRoZSBwZXJzb25hbCB2aWV3cyBvZiB0aGUgb3JpZ2luYXRvci4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1 cm4gZS1tYWlsIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4gWW91IHNob3VsZCBub3Qg cmVwcm9kdWNlLCBkaXN0cmlidXRlLCBzdG9yZSwgcmV0cmFuc21pdCwgdXNlIG9yIGRpc2Nsb3Nl IGl0cyBjb250ZW50cyB0byBhbnlvbmUuIFBsZWFzZSBub3RlIHdlIHJlc2VydmUgdGhlIHJpZ2h0 IHRvIG1vbml0b3IgYWxsIGUtbWFpbCBjb21tdW5pY2F0aW9uIHRocm91Z2ggb3VyIGludGVybmFs IGFuZCBleHRlcm5hbCBuZXR3b3Jrcy4gU0tZIGFuZCB0aGUgU0tZIG1hcmtzIGFyZSB0cmFkZW1h cmtzIG9mIFNreSBMaW1pdGVkIGFuZCBTa3kgSW50ZXJuYXRpb25hbCBBRyBhbmQgYXJlIHVzZWQg dW5kZXIgbGljZW5jZS4NCg0KU2t5IFVLIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjkwNjk5 MSksIFNreS1Jbi1Ib21lIFNlcnZpY2UgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMDY3MDc1 KSwgU2t5IFN1YnNjcmliZXJzIFNlcnZpY2VzIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjM0 MDE1MCkgYW5kIFNreSBDUCBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDk1MTMyNTkpIGFyZSBk aXJlY3Qgb3IgaW5kaXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBMaW1pdGVkIChSZWdpc3RyYXRp b24gTm8uIDIyNDc3MzUpLiBBbGwgb2YgdGhlIGNvbXBhbmllcyBtZW50aW9uZWQgaW4gdGhpcyBw YXJhZ3JhcGggYXJlIGluY29ycG9yYXRlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBhbmQgc2hhcmUg dGhlIHNhbWUgcmVnaXN0ZXJlZCBvZmZpY2UgYXQgR3JhbnQgV2F5LCBJc2xld29ydGgsIE1pZGRs ZXNleCBUVzcgNVFEDQo= --_000_3888C6E6A5044CC98FAB79910C7EA417skyuk_ Content-Type: text/html; charset="utf-8" Content-ID: <067D7F2A0354BF4097B008B286FB0F0D@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5tc2lwZm9vdGVy MzBiM2Q1MzgsIGxpLm1zaXBmb290ZXIzMGIzZDUzOCwgZGl2Lm1zaXBmb290ZXIzMGIzZDUzOA0K CXttc28tc3R5bGUtbmFtZTptc2lwZm9vdGVyMzBiM2Q1Mzg7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSb24sPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgZm9yIHRoaXMg ZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Sb24gQm9u aWNhICZsdDtyYm9uaWNhQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2Rh eSwgMjMgSnVseSAyMDIwIGF0IDIxOjQ0PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtkcmFmdC1pZXRm LXY2b3BzLWNwZS1zbGFhYy1yZW51bUBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi12Nm9w cy1jcGUtc2xhYWMtcmVudW1AaWV0Zi5vcmcmZ3Q7LCAmcXVvdDt2Nm9wc0BpZXRmLm9yZyZxdW90 OyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltFWFRFUk5BTF0g ZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW06IElQUjxicj4NCjxiPlJlc2VudC1Gcm9t OiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8 L2I+Jmx0O2Znb250QHNpNm5ldHdvcmtzLmNvbSZndDssICZsdDtqYW5AZ282LnNpJmd0OywgJmx0 O3JpY2hhcmQucGF0dGVyc29uQHNreS51ayZndDssICZsdDt2b2x6QGNpc2NvLmNvbSZndDs8YnI+ DQo8Yj5SZXNlbnQtRGF0ZTogPC9iPlRodXJzZGF5LCAyMyBKdWx5IDIwMjAgYXQgMjE6NDQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q28tYXV0 aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxpc3Qg aW5kaWNhdGluZyB3aGV0aGVyIHlvdSBrbm93IG9mIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRoIGRy YWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtc2lwZm9v dGVyMzBiM2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0 b206LjAwMDFwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOmJsYWNrIj5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+VGhpcyBlbWFpbCBpcyBmcm9tIGFuIGV4dGVybmFsIHNvdXJjZS4gUGxlYXNlIGRvIG5v dCBvcGVuIGF0dGFjaG1lbnRzIG9yIGNsaWNrIGxpbmtzIGZyb20gYW4gdW5rbm93biBvciBzdXNw aWNpb3VzIG9yaWdpbi4gUGhpc2hpbmcgYXR0ZW1wdHMgY2FuIGJlIHJlcG9ydGVkIGJ5IHVzaW5n DQogdGhlIHJlcG9ydCBtZXNzYWdlIGJ1dHRvbiBpbiBPdXRsb29rIG9yIHNlbmRpbmcgdGhlbSBh cyBhbiBhdHRhY2htZW50IHRvIHBoaXNoaW5nQHNreS51ay4gVGhhbmsgeW91PC9zcGFuPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQpJbmZvcm1hdGlvbiBpbiB0aGlzIGVtYWlsIGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMgbWF5IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBh bmQgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIHRoZSBhZGRyZXNzZWUuIFRoZSB2aWV3cyBl eHByZXNzZWQgbWF5IG5vdCBiZSBvZmZpY2lhbCBwb2xpY3ksIGJ1dCB0aGUgcGVyc29uYWwgdmll d3Mgb2YgdGhlIG9yaWdpbmF0b3IuIElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2UNCiBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUgaXQg ZnJvbSB5b3VyIHN5c3RlbS4gWW91IHNob3VsZCBub3QgcmVwcm9kdWNlLCBkaXN0cmlidXRlLCBz dG9yZSwgcmV0cmFuc21pdCwgdXNlIG9yIGRpc2Nsb3NlIGl0cyBjb250ZW50cyB0byBhbnlvbmUu IFBsZWFzZSBub3RlIHdlIHJlc2VydmUgdGhlIHJpZ2h0IHRvIG1vbml0b3IgYWxsIGUtbWFpbCBj b21tdW5pY2F0aW9uIHRocm91Z2ggb3VyIGludGVybmFsIGFuZA0KIGV4dGVybmFsIG5ldHdvcmtz LiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mgb2YgU2t5IExpbWl0ZWQgYW5k IFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRlciBsaWNlbmNlLg0KPGJyPg0K PGJyPg0KU2t5IFVLIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjkwNjk5MSksIFNreS1Jbi1I b21lIFNlcnZpY2UgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMDY3MDc1KSwgU2t5IFN1YnNj cmliZXJzIFNlcnZpY2VzIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjM0MDE1MCkgYW5kIFNr eSBDUCBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDk1MTMyNTkpIGFyZSBkaXJlY3Qgb3IgaW5k aXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBMaW1pdGVkIChSZWdpc3RyYXRpb24NCiBOby4gMjI0 NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBpbiB0aGlzIHBhcmFncmFwaCBh cmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFuZCBzaGFyZSB0aGUgc2FtZSBy ZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0aCwgTWlkZGxlc2V4IFRXNyA1 UUQNCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3888C6E6A5044CC98FAB79910C7EA417skyuk_-- From nobody Fri Jul 24 02:50:14 2020 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 5DF773A0E7A; Fri, 24 Jul 2020 02:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2TwjHOhgMHh; Fri, 24 Jul 2020 02:50:03 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2087.outbound.protection.outlook.com [40.107.22.87]) (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 D70F83A0E56; Fri, 24 Jul 2020 02:49:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AefSXTfi4L0hwGEbMe/AzZ+3tIax45lmZIoQ4Z7M60KrHb98tCGo3vHR9ukYvKX90ANwuD6my+E7QIeItBvppoMTfGsjbc2rk2QgEQxUTqHsiU1JmVNlpXbX8vArrWYAXjGF8wwJsgQp80ZVU1s0P6uc+RPvUBQ/jrN1YcWJm1JhaEfBqCA5AjbWTl4LEjjt5U5b7yemm2Ow5zZrWuU8zHvMZ7R0b2qNNaEQOw+9SqDUnqu77I+YUTmkBtbt/U6dU06mUlGYivIUq+opM0cd6Fl83j8ebCwdKTgjWmuOhnfvdVniA+xLQjMxgQBI8t55wcRAJuTozlTXmvz6Z+X0Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w1WgLRf6wwBGSBzmbO7YmY11jMaN0Uz6CPvAdSlnJRg=; b=LMAI25DZWmTyCB/x1xYocga79cWKFBHa0+ulvRoN2R513rn+a6yvB1v/nemgVpt4NSvWlsex62J0PvE+UC6mBUdD+fbUB/Hd/UgtjrnucWROc4cif/2Bu1okV2s+UFO42KOFiNrf7aCu3T8GVxN35ionDMymWkwzZB0owuRZjRx1tC5DU+HQI/SfN747YYha4VFIpJK8yOLDzWkb2/BtP44r8b5QOBCJ8xSGWrMIv9JJmQ7Le3nuYzwugfXJTT3+eTPOpjU8E5NarjQwe+zaxGcK5b0mDqekdAZ9HYQMGbAg1woHu5YPCbBXJaVNjulo7TrdPY+q0mmFP0f9z2xikg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w1WgLRf6wwBGSBzmbO7YmY11jMaN0Uz6CPvAdSlnJRg=; b=HTNuekMii/G5lzM9G81176MSOT1fVY11uPwppoR2BO532JbwqAYX0KJtVN8CHQfw2wqY9F5nHShJRwGMO9T4gm7c/EyF6xFSQUHiiuZL2JR1Ni1s6QOEEE7rxjIWIAeA9KoL/UdShfL0R80h3vWQeHzFUX+CVtMPVSNy2b+GIDM= Received: from DB8PR06MB6122.eurprd06.prod.outlook.com (2603:10a6:10:106::25) by DB7PR06MB4331.eurprd06.prod.outlook.com (2603:10a6:5:2c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Fri, 24 Jul 2020 09:49:56 +0000 Received: from DB8PR06MB6122.eurprd06.prod.outlook.com ([fe80::6116:8c06:dcb8:dfda]) by DB8PR06MB6122.eurprd06.prod.outlook.com ([fe80::6116:8c06:dcb8:dfda%7]) with mapi id 15.20.3216.024; Fri, 24 Jul 2020 09:49:56 +0000 From: "Patterson, Richard (Sky Network Services (SNS))" To: Ron Bonica , "draft-ietf-v6ops-slaac-renum@ietf.org" , "v6ops@ietf.org" Thread-Topic: [EXTERNAL] draft-ietf-v6ops-slaac-renum IPR Thread-Index: AdZhMj7y7fbC/hz4RG6l2mDxP4ar2gAdeuWA Date: Fri, 24 Jul 2020 09:49:55 +0000 Message-ID: <20C69BA6-EE61-43DA-BB78-7EE14C31C686@sky.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=sky.uk; x-originating-ip: [2a02:c7f:c282:e901:dfa:34f0:aa9e:f038] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9817f52-e57a-498f-b79e-08d82fb6ebd4 x-ms-traffictypediagnostic: DB7PR06MB4331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LJtWey7zWtue7XIUdiEF1yV4WmukQkD/q8fnPML/DrMrrksQcJ2cFKH7/JByk5Tk8dXwf5QDXajhnmvPhsORlcOrQ3Ei4FFGAg8EDk8yzBlCh9Z75xm4lIpeq/XXuuMPZaKXD8NotycykpuRllltIo7Jcs8nZGmb8Ay04Cm28dK2+YiUGQPPsVKfN5typry83zkpPkdlVmZBk4SkIh9nc48O6bJ/2KyA8zFGZ53djyHp1RT5aMg77uTP9qXSSM8hLxLtaIzwmQ4KgYRr/0lavWGPbLDeSctgdMcpVHMAr0VqFGarA25h3bUtBNqs2xRA/5Jg0IMLP1Ve5Azia0150g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR06MB6122.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(396003)(366004)(136003)(346002)(6512007)(66446008)(66556008)(76116006)(66946007)(64756008)(2616005)(91956017)(33656002)(66476007)(53546011)(86362001)(36756003)(110136005)(8676002)(316002)(9326002)(2906002)(6486002)(8936002)(5660300002)(478600001)(186003)(6506007)(71200400001)(83380400001)(45080400002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SU4VHwavX2LyR/QIiKbdwQgrUQb2hoxZ4kvZRuISTLJCiiWjItc4lQGRHLJfnyZbn5+JTVxZunApKmhYwzU8XvQ0l3+LXkdqrqYA9jfJ3aP/uu5RwOGBF1OKqjSr6EYCRirOJEjq8KmhtK4VnzTXH+V3ubs20Jcx/94OPkZ+xr6xZQgnhfzVfsRpxw+HUJ054UXIN+0ES2bHyNH/PyvE8Z8F1HbsGuM2SG2WUEY+DkHeb2Q+iMQxUlmrNZShKqyX666t41RXol/r2sdaDoTqhNvhoQhTQYIYiNrxQvK2lucCvgtNcMkPCGcMISqum7CVZASarvwyuGX8MfPXkrnb+S6NnVjxVug7Zx4PkqblxxVNYvXZGxR9cHUqpOsZFwSjxg78PlgIS24XFyI92HSi9F7Pic6zy87rqhqGsa52HKdFSVg5BaG767Wg4+Q47Sf6ChpVfrndZz1pSvM5CnK6u9hfD5N2ueFdxAk8V91nLcHKMYUa4Nkx5a9cL1470PvEP8lR/lSUrei0lsUkZ5BgRLux5HxxwTGhlTsQvEppzeagJNy241/rT6GB5gqwjG81 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_20C69BA6EE6143DABB787EE14C31C686skyuk_" MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB8PR06MB6122.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9817f52-e57a-498f-b79e-08d82fb6ebd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2020 09:49:55.8875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UqBh67bzxSXEs508KkJ9kLPdH4zcJurxumXYj/4FtaPm1cOSPyeAZ/TlpuR8Dku+YHOfYBc5dI8py27MdyVwkxMNT1FXQhHZ503SVf23vNw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR06MB4331 Archived-At: Subject: Re: [v6ops] [EXTERNAL] draft-ietf-v6ops-slaac-renum IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 09:50:13 -0000 --_000_20C69BA6EE6143DABB787EE14C31C686skyuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGZvciB0aGlzIGRyYWZ0Lg0KDQoN CkZyb206IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQpEYXRlOiBUaHVyc2RheSwg MjMgSnVseSAyMDIwIGF0IDIxOjQ2DQpUbzogImRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW1A aWV0Zi5vcmciIDxkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtQGlldGYub3JnPiwgInY2b3Bz QGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIGRyYWZ0LWll dGYtdjZvcHMtc2xhYWMtcmVudW0gSVBSDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0 Zi5vcmc+DQpSZXNlbnQtVG86IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+LCA8amFuQGdvNi5zaT4s IDxyaWNoYXJkLnBhdHRlcnNvbkBza3kudWs+DQpSZXNlbnQtRGF0ZTogVGh1cnNkYXksIDIzIEp1 bHkgMjAyMCBhdCAyMTo0Ng0KDQpDby1hdXRob3JzLA0KDQpQbGVhc2UgcmVzcG9uZCB0byB0aGUg bGlzdCBpbmRpY2F0aW5nIHdoZXRoZXIgeW91IGtub3cgb2YgYW55IElQUiBhc3NvY2lhdGVkIHdp dGggdGhpcyBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0K DQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIGVtYWlsIGlz IGZyb20gYW4gZXh0ZXJuYWwgc291cmNlLiBQbGVhc2UgZG8gbm90IG9wZW4gYXR0YWNobWVudHMg b3IgY2xpY2sgbGlua3MgZnJvbSBhbiB1bmtub3duIG9yIHN1c3BpY2lvdXMgb3JpZ2luLiBQaGlz aGluZyBhdHRlbXB0cyBjYW4gYmUgcmVwb3J0ZWQgYnkgdXNpbmcgdGhlIHJlcG9ydCBtZXNzYWdl IGJ1dHRvbiBpbiBPdXRsb29rIG9yIHNlbmRpbmcgdGhlbSBhcyBhbiBhdHRhY2htZW50IHRvIHBo aXNoaW5nQHNreS51ay4gVGhhbmsgeW91DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJbmZvcm1hdGlvbiBpbiB0 aGlzIGVtYWlsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMgbWF5IGJlIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIHRoZSBhZGRyZXNzZWUu IFRoZSB2aWV3cyBleHByZXNzZWQgbWF5IG5vdCBiZSBvZmZpY2lhbCBwb2xpY3ksIGJ1dCB0aGUg cGVyc29uYWwgdmlld3Mgb2YgdGhlIG9yaWdpbmF0b3IuIElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0 IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQg ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uIFlvdSBzaG91bGQgbm90IHJlcHJvZHVjZSwgZGlz dHJpYnV0ZSwgc3RvcmUsIHJldHJhbnNtaXQsIHVzZSBvciBkaXNjbG9zZSBpdHMgY29udGVudHMg dG8gYW55b25lLiBQbGVhc2Ugbm90ZSB3ZSByZXNlcnZlIHRoZSByaWdodCB0byBtb25pdG9yIGFs bCBlLW1haWwgY29tbXVuaWNhdGlvbiB0aHJvdWdoIG91ciBpbnRlcm5hbCBhbmQgZXh0ZXJuYWwg bmV0d29ya3MuIFNLWSBhbmQgdGhlIFNLWSBtYXJrcyBhcmUgdHJhZGVtYXJrcyBvZiBTa3kgTGlt aXRlZCBhbmQgU2t5IEludGVybmF0aW9uYWwgQUcgYW5kIGFyZSB1c2VkIHVuZGVyIGxpY2VuY2Uu DQoNClNreSBVSyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDI5MDY5OTEpLCBTa3ktSW4tSG9t ZSBTZXJ2aWNlIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjA2NzA3NSksIFNreSBTdWJzY3Jp YmVycyBTZXJ2aWNlcyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIzNDAxNTApIGFuZCBTa3kg Q1AgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiA5NTEzMjU5KSBhcmUgZGlyZWN0IG9yIGluZGly ZWN0IHN1YnNpZGlhcmllcyBvZiBTa3kgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMjQ3NzM1 KS4gQWxsIG9mIHRoZSBjb21wYW5pZXMgbWVudGlvbmVkIGluIHRoaXMgcGFyYWdyYXBoIGFyZSBp bmNvcnBvcmF0ZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgYW5kIHNoYXJlIHRoZSBzYW1lIHJlZ2lz dGVyZWQgb2ZmaWNlIGF0IEdyYW50IFdheSwgSXNsZXdvcnRoLCBNaWRkbGVzZXggVFc3IDVRRA0K --_000_20C69BA6EE6143DABB787EE14C31C686skyuk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5tc2lwZm9vdGVy MzBiM2Q1MzgsIGxpLm1zaXBmb290ZXIzMGIzZDUzOCwgZGl2Lm1zaXBmb290ZXIzMGIzZDUzOA0K CXttc28tc3R5bGUtbmFtZTptc2lwZm9vdGVyMzBiM2Q1Mzg7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSb24sPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgZm9yIHRoaXMg ZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJvbiBCb25pY2EgJmx0O3Jib25p Y2FAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCAyMyBKdWx5IDIw MjAgYXQgMjE6NDY8YnI+DQo8Yj5UbzogPC9iPiZxdW90O2RyYWZ0LWlldGYtdjZvcHMtc2xhYWMt cmVudW1AaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW1AaWV0 Zi5vcmcmZ3Q7LCAmcXVvdDt2Nm9wc0BpZXRmLm9yZyZxdW90OyAmbHQ7djZvcHNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltFWFRFUk5BTF0gZHJhZnQtaWV0Zi12Nm9wcy1zbGFh Yy1yZW51bSBJUFI8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGll dGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDtmZ29udEBzaTZuZXR3b3Jrcy5j b20mZ3Q7LCAmbHQ7amFuQGdvNi5zaSZndDssICZsdDtyaWNoYXJkLnBhdHRlcnNvbkBza3kudWsm Z3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5UaHVyc2RheSwgMjMgSnVseSAyMDIwIGF0IDIx OjQ2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNvLWF1dGhvcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSByZXNwb25kIHRvIHRo ZSBsaXN0IGluZGljYXRpbmcgd2hldGhlciB5b3Uga25vdyBvZiBhbnkgSVBSIGFzc29jaWF0ZWQg d2l0aCB0aGlzIGRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW0uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0ibXNpcGZvb3RlcjMwYjNkNTM4IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlRoaXMgZW1haWwgaXMgZnJvbSBhbiBleHRlcm5hbCBzb3VyY2UuIFBs ZWFzZSBkbyBub3Qgb3BlbiBhdHRhY2htZW50cyBvciBjbGljayBsaW5rcyBmcm9tIGFuIHVua25v d24gb3Igc3VzcGljaW91cyBvcmlnaW4uIFBoaXNoaW5nIGF0dGVtcHRzIGNhbiBiZSByZXBvcnRl ZCBieSB1c2luZw0KIHRoZSByZXBvcnQgbWVzc2FnZSBidXR0b24gaW4gT3V0bG9vayBvciBzZW5k aW5nIHRoZW0gYXMgYW4gYXR0YWNobWVudCB0byBwaGlzaGluZ0Bza3kudWsuIFRoYW5rIHlvdTwv c3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KSW5mb3JtYXRpb24gaW4gdGhp cyBlbWFpbCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzIG1heSBiZSBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB0aGUgYWRkcmVzc2VlLiBU aGUgdmlld3MgZXhwcmVzc2VkIG1heSBub3QgYmUgb2ZmaWNpYWwgcG9saWN5LCBidXQgdGhlIHBl cnNvbmFsIHZpZXdzIG9mIHRoZSBvcmlnaW5hdG9yLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlDQogbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQg ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uIFlvdSBzaG91bGQgbm90IHJlcHJvZHVjZSwgZGlz dHJpYnV0ZSwgc3RvcmUsIHJldHJhbnNtaXQsIHVzZSBvciBkaXNjbG9zZSBpdHMgY29udGVudHMg dG8gYW55b25lLiBQbGVhc2Ugbm90ZSB3ZSByZXNlcnZlIHRoZSByaWdodCB0byBtb25pdG9yIGFs bCBlLW1haWwgY29tbXVuaWNhdGlvbiB0aHJvdWdoIG91ciBpbnRlcm5hbCBhbmQNCiBleHRlcm5h bCBuZXR3b3Jrcy4gU0tZIGFuZCB0aGUgU0tZIG1hcmtzIGFyZSB0cmFkZW1hcmtzIG9mIFNreSBM aW1pdGVkIGFuZCBTa3kgSW50ZXJuYXRpb25hbCBBRyBhbmQgYXJlIHVzZWQgdW5kZXIgbGljZW5j ZS4NCjxicj4NCjxicj4NClNreSBVSyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDI5MDY5OTEp LCBTa3ktSW4tSG9tZSBTZXJ2aWNlIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjA2NzA3NSks IFNreSBTdWJzY3JpYmVycyBTZXJ2aWNlcyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIzNDAx NTApIGFuZCBTa3kgQ1AgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiA5NTEzMjU5KSBhcmUgZGly ZWN0IG9yIGluZGlyZWN0IHN1YnNpZGlhcmllcyBvZiBTa3kgTGltaXRlZCAoUmVnaXN0cmF0aW9u DQogTm8uIDIyNDc3MzUpLiBBbGwgb2YgdGhlIGNvbXBhbmllcyBtZW50aW9uZWQgaW4gdGhpcyBw YXJhZ3JhcGggYXJlIGluY29ycG9yYXRlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBhbmQgc2hhcmUg dGhlIHNhbWUgcmVnaXN0ZXJlZCBvZmZpY2UgYXQgR3JhbnQgV2F5LCBJc2xld29ydGgsIE1pZGRs ZXNleCBUVzcgNVFEDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_20C69BA6EE6143DABB787EE14C31C686skyuk_-- From nobody Fri Jul 24 03:49:17 2020 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 E6FBF3A0EAD for ; Fri, 24 Jul 2020 03:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoNP_h4lM-ux for ; Fri, 24 Jul 2020 03:49:14 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (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 368E13A0475 for ; Fri, 24 Jul 2020 03:49:14 -0700 (PDT) Received: from [IPv6:2a01:e35:2e59:ce10::da3d:a356] (unknown [IPv6:2a01:e35:2e59:ce10::da3d:a356]) by smtp4-g21.free.fr (Postfix) with ESMTP id 1E0E019F5A5 for ; Fri, 24 Jul 2020 12:49:08 +0200 (CEST) From: Alexandre Petrescu To: V6OPS WG References: Message-ID: Date: Fri, 24 Jul 2020 12:49:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------90B6793E5A671B3BF915CB95" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6-only and webex X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 10:49:16 -0000 This is a multi-part message in MIME format. --------------90B6793E5A671B3BF915CB95 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit www.webex.com is brwsable from an IPv6-only computer (IPv4 stack turned off) but when clicking on an URL of a telco (URL starts with an fqdn skku-ict.webex.com) the connection does not work. Alex Le 24/07/2020 à 11:15, Alexandre Petrescu a écrit : > > Microsoft Teams, a tool for online collaboration, works fine on IPv4. > > When tried on IPv6-only computer (IPv4 stack turned off) the initial > phases of connection works, but connecting to a videoconference does > not work. > > Alex > > Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit : >> Gather.town is a game-like tool for virtually attending the IETF >> >> https://gather.town/z6N2SDxHebMdDAfo/IETF-108 >> >> IPv6-only access is when I use only IPv6 on my Windows 10. (right >> button on RJ45 symbol on lower right icon bar on Windows, then >> Ethernet, then modify adapter options, then select the Ethernet >> interface, then Properties, then un-check IPv4 and check IPv6). >> >> With this on, when I walk on the floor of IETF and meet some people >> it is impossible to 'Connect' - it shows "Connecting..." and it >> blocks there.  But it works fine when on IPv4. >> >> Maybe this gather.town Connecting to others works for other people on >> IPv6-only. >> >> Alex >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --------------90B6793E5A671B3BF915CB95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

www.webex.com is brwsable from an IPv6-only computer (IPv4 stack turned off)

but when clicking on an URL of a telco (URL starts with an fqdn skku-ict.webex.com) the connection does not work.

Alex

Le 24/07/2020 à 11:15, Alexandre Petrescu a écrit :

Microsoft Teams, a tool for online collaboration, works fine on IPv4.

When tried on IPv6-only computer (IPv4 stack turned off) the initial phases of connection works, but connecting to a videoconference does not work.

Alex

Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit :
Gather.town is a game-like tool for virtually attending the IETF

https://gather.town/z6N2SDxHebMdDAfo/IETF-108

IPv6-only access is when I use only IPv6 on my Windows 10. (right button on RJ45 symbol on lower right icon bar on Windows, then Ethernet, then modify adapter options, then select the Ethernet interface, then Properties, then un-check IPv4 and check IPv6).

With this on, when I walk on the floor of IETF and meet some people it is impossible to 'Connect' - it shows "Connecting..." and it blocks there.  But it works fine when on IPv4.

Maybe this gather.town Connecting to others works for other people on IPv6-only.

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------90B6793E5A671B3BF915CB95-- From nobody Fri Jul 24 03:53:23 2020 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 72F1B3A0EB4; Fri, 24 Jul 2020 03:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NqIx7WBK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xqLf2NB9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwzS4cCu_FpL; Fri, 24 Jul 2020 03:53:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32D73A0EB0; Fri, 24 Jul 2020 03:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6955; q=dns/txt; s=iport; t=1595588000; x=1596797600; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KNXymGU9s9eEqXM+xirF0oo5hzU7pe4abLaiAXb0BE8=; b=NqIx7WBKlPC4UB70MU+qIzQXOOodv5P3ynMkQKhavCRgKcfmIeztwmKt LEKxoQURcIgf3ntp5CElXA2qtT4OXqKzznjLZ4yW9v1IMunbiptPIQgca rdd6GKoAHVlszbQeVw0f1u55qECm89oq5ar9FZvTZTrLaw4FNiR3MHHd1 o=; IronPort-PHdr: =?us-ascii?q?9a23=3AROYC/xU+Yp/AnFTan3QlEv2D07XV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAADcvBpf/5pdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBeAUBAQsBgSIvUQd9Si8sCoQpg0YDjVSTc4RsgS6BJQNVCwE?= =?us-ascii?q?BAQwBAS0CBAEBhEwCF4ILAiQ2Bw4CAwEBCwEBBQEBAQIBBgRthVwMhXEBAQE?= =?us-ascii?q?EEhEdAQE3AQ8CAQgOAwMBAisCAgIwHQgBAQQOBSKDBIF/TQMuAaIXAoE5iGF?= =?us-ascii?q?2gTKDAQEBBYUvGIIOCYE4AYJrg1WGMxqCAIE4HIJNPoRdgnYzgi2SX4ZWnDI?= =?us-ascii?q?Kgl2ZbAMegnuJRpMejVKDQQygCQIEAgQFAg4BAQWBWQEzgVdwFTsNCRQBgj5?= =?us-ascii?q?QFwINjh6DcYpWdDcCBgEHAQEDCXyOLwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,390,1589241600"; d="scan'208,217";a="712035217" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2020 10:53:19 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 06OArJWo016697 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2020 10:53:19 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 05:53:19 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 05:53:19 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Jul 2020 05:53:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j68WgyDFMRRWll1Viq2vPvmZHwJgC8d+/d6oaV03dW0LltRX7oBk+LYZGnlHxwfa0EOx9wrHZNwGnUNPWn+mSxgiB9vqMRmvLOtCzH9Qfs7DACK+HpHiWgVQymmvLOQg5X2A3V49CdFpUTk+Jq7RFlsrY/kqL9HsiTLgngv2yT63MJcODSS3HM/wjhFVpkqTwA2iqajgi1Ow0dzI9OWztiYPumH/flr1WvU+oE3m45S0YvXxgsmqgwZHA5VwLdUhYUCIG20IJ4wohXTKJHKumyBX5CHbEgi79wupPUTqJ63lRO4Bf7sLZpv3gAtRQ9iS/eAl2/BE8IjKWzkQ4W755Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KNXymGU9s9eEqXM+xirF0oo5hzU7pe4abLaiAXb0BE8=; b=UpvtVrZKsCWEka+M5Pq+/GRzNtcZ3UXXHCK8AEfaySuBphQwlXZEPrc13zrFpUUkY9pL/lkISSPvRzq4iesReSwt7G3rx+iypQjydX7MifilXc2PsobYqsq8w3gj2f3fX+f/QHq5hF6ulwNBzAOWs90Bi8xPmsumrxBa4KZXA+NPnLzXe9WMPZGDTytvvETcFXy4vgZeiwj/JP8Mp12IxHwhzBmd9qwWamHLizWCHh6nWrYHxdjti5FsZPY9Oce3yZRBI6+NcM8cI28km3tAt3gJy8Tci0rA+Wn+oPnvtn7l6uKONv2sNYsPKqb3H2nmomRWcJQ7l1P06BE24n8MYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KNXymGU9s9eEqXM+xirF0oo5hzU7pe4abLaiAXb0BE8=; b=xqLf2NB9iWuj0umS9rnuuyaBKQxPTkt4l7tSRgHk4DciOcEsCXx/rXngTMmte989X7uW/MDpwCFRj46lkyBhNNni2X+h0/M7yDYbiFRwq5UQahxBAEUdg4U1I+AtKkscFHare3MySRtHI109crWAW6H2/OZQWWW59LI+ck7cJDs= Received: from BYAPR11MB2549.namprd11.prod.outlook.com (2603:10b6:a02:c4::33) by BYAPR11MB3750.namprd11.prod.outlook.com (2603:10b6:a03:f9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Fri, 24 Jul 2020 10:53:16 +0000 Received: from BYAPR11MB2549.namprd11.prod.outlook.com ([fe80::4def:531c:68ed:5e2c]) by BYAPR11MB2549.namprd11.prod.outlook.com ([fe80::4def:531c:68ed:5e2c%4]) with mapi id 15.20.3216.023; Fri, 24 Jul 2020 10:53:16 +0000 From: "Bernie Volz (volz)" To: Ron Bonica CC: "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops@ietf.org" Thread-Topic: [EXTERNAL] draft-ietf-v6ops-cpe-slaac-renum: IPR Thread-Index: AdZhMfTBukn2fnzKQUaQP79C1gjs5AAdiUWAAAAiDg4= Date: Fri, 24 Jul 2020 10:53:15 +0000 Message-ID: References: , <3888C6E6-A504-4CC9-8FAB-79910C7EA417@sky.uk> In-Reply-To: <3888C6E6-A504-4CC9-8FAB-79910C7EA417@sky.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66d9c6bd-da83-4e5e-03cd-08d82fbfc4d7 x-ms-traffictypediagnostic: BYAPR11MB3750: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cBWP+1Jx+2E9e/TbiCAnWfHx2EM+rGxHFrHMt8BD2Hhvm9x1uoWbmh0878z9oXY1BxGKUzQaa23ivxyiyz3E7Q+/VlhH47Rqfe6dhZ+pXrYChINIHZ6axAW6vzRKbwwCMq9ljzRkvnFuprkpInlu5bfLXGpgJ8Tln7USbKdZF3kj5oIQMVjEK7zfC3Eg2Ap0N9pfiv5yjbhAEk2vfBqC/r1d/zMPviuGDyoWRp2UWFh9iu4Z8RylprkMYKpdX1UWKj4JLLuWvkSVi7G1GqTo3H8Leu1F2LFfzhoqikSX5pVWxkx7mTOogp6cpcIDjDvVGk6X0I21XBk3rGE9E6oyXA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2549.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(396003)(136003)(346002)(33656002)(26005)(5660300002)(66946007)(2906002)(76116006)(4744005)(8676002)(91956017)(4326008)(186003)(54906003)(71200400001)(8936002)(6512007)(316002)(66476007)(478600001)(66556008)(66446008)(64756008)(6486002)(6916009)(53546011)(6506007)(86362001)(36756003)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DRTVdaci5Oq1h3CX2c81UzU8P+2S+P+qnytMZd22I/i8lPvUD2SFSyZmCZB7hhPfxvvtncpg9gi0CTRXbaXb7ub1GCDwTA+j965d4OGXa/kK8sVrk6aWOcyd7VblVaFd4yEqvEEoXyHSJ4Hz4EUoQgAeCLyjLkeKGpdIS9ZBMlGUxmlPEEf33VQfawY4pu5EzSGOc288+DUDaixAxTrGuCGFChURWmsyJxBjnGNaKzgCrrQQ6IgPeWc8jvrueBg31RdQwQssSOtuiVnKNUUqZe5al+impgzI3lZj5v9PDzDXgq/9t/WahWkJlMlWxbvV3T0nWrsWPe+eYqXMy0/6cAuYyqLPSYhMCxNtf4siX9DA0pBzI2zzqof7xDXxpyKLxQjpDfR3yKAumyAmFLCLYPWVGBExe/QrIrZdYW10F6yijXO81q3Mig5EQA7OuiIrxwfBTbZUv9fa0vLZw7d/eXICZF5uk6PiKQnKP6ZtgucgMF7q+ZMAbko2KRsMNRfq x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F8A889CA37CC4DA39C7C82B5476DBB2Aciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2549.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66d9c6bd-da83-4e5e-03cd-08d82fbfc4d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2020 10:53:15.9680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4WH1XXgrPEzSF3KdoQVHFU0U0U2v2+dwbPsgTHQlh7lS7Om3MA8IkxJlVtJoEcuY X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3750 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [v6ops] [EXTERNAL] draft-ietf-v6ops-cpe-slaac-renum: IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 10:53:23 -0000 --_000_F8A889CA37CC4DA39C7C82B5476DBB2Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBhbHNvIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGZvciB0aGlzIGRyYWZ0Lg0KDQotIEJlcm5p ZSBWb2x6DQoNCk9uIEp1bCAyNCwgMjAyMCwgYXQgNTo0OSBBTSwgUGF0dGVyc29uLCBSaWNoYXJk IChTa3kgTmV0d29yayBTZXJ2aWNlcyAoU05TKSkgPFJpY2hhcmQuUGF0dGVyc29uQHNreS51az4g d3JvdGU6DQoNCu+7vw0KSGkgUm9uLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGZvciB0 aGlzIGRyYWZ0Lg0KDQpGcm9tOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KRGF0 ZTogVGh1cnNkYXksIDIzIEp1bHkgMjAyMCBhdCAyMTo0NA0KVG86ICJkcmFmdC1pZXRmLXY2b3Bz LWNwZS1zbGFhYy1yZW51bUBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJl bnVtQGlldGYub3JnPiwgInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbRVhURVJOQUxdIGRyYWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtOiBJUFINClJlc2Vu dC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudC1UbzogPGZnb250QHNpNm5l dHdvcmtzLmNvbT4sIDxqYW5AZ282LnNpPiwgPHJpY2hhcmQucGF0dGVyc29uQHNreS51az4sIDx2 b2x6QGNpc2NvLmNvbT4NClJlc2VudC1EYXRlOiBUaHVyc2RheSwgMjMgSnVseSAyMDIwIGF0IDIx OjQ0DQoNCkNvLWF1dGhvcnMsDQoNClBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0IGluZGljYXRp bmcgd2hldGhlciB5b3Uga25vdyBvZiBhbnkgSVBSIGFzc29jaWF0ZWQgd2l0aCBkcmFmdC1pZXRm LXY2b3BzLWNwZS1zbGFhYy1yZW51bS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0K --_000_F8A889CA37CC4DA39C7C82B5476DBB2Aciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpJ IGFtIGFsc28gbm90IGF3YXJlIG9mIGFueSBJUFIgZm9yIHRoaXMgZHJhZnQuPGJyPg0KPGJyPg0K PGRpdiBkaXI9Imx0ciI+LSBCZXJuaWUgVm9sejwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gSnVsIDI0LCAyMDIwLCBhdCA1OjQ5IEFNLCBQYXR0 ZXJzb24sIFJpY2hhcmQgKFNreSBOZXR3b3JrIFNlcnZpY2VzIChTTlMpKSAmbHQ7UmljaGFyZC5Q YXR0ZXJzb25Ac2t5LnVrJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8bWV0YSBu YW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRp dW0pIj4NCiA8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5tc2lwZm9vdGVyMzBi M2Q1MzgsIGxpLm1zaXBmb290ZXIzMGIzZDUzOCwgZGl2Lm1zaXBmb290ZXIzMGIzZDUzOA0KCXtt c28tc3R5bGUtbmFtZTptc2lwZm9vdGVyMzBiM2Q1Mzg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbiw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBmb3IgdGhpcyBkcmFmdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJvbiBCb25pY2EgJmx0 O3Jib25pY2FAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCAyMyBK dWx5IDIwMjAgYXQgMjE6NDQ8YnI+DQo8Yj5UbzogPC9iPiZxdW90O2RyYWZ0LWlldGYtdjZvcHMt Y3BlLXNsYWFjLXJlbnVtQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLXY2b3BzLWNwZS1z bGFhYy1yZW51bUBpZXRmLm9yZyZndDssICZxdW90O3Y2b3BzQGlldGYub3JnJnF1b3Q7ICZsdDt2 Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0VYVEVSTkFMXSBkcmFmdC1p ZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bTogSVBSPGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4m bHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj4mbHQ7 ZmdvbnRAc2k2bmV0d29ya3MuY29tJmd0OywgJmx0O2phbkBnbzYuc2kmZ3Q7LCAmbHQ7cmljaGFy ZC5wYXR0ZXJzb25Ac2t5LnVrJmd0OywgJmx0O3ZvbHpAY2lzY28uY29tJmd0Ozxicj4NCjxiPlJl c2VudC1EYXRlOiA8L2I+VGh1cnNkYXksIDIzIEp1bHkgMjAyMCBhdCAyMTo0NDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Dby1hdXRob3JzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcmVzcG9uZCB0byB0aGUgbGlzdCBpbmRpY2F0 aW5nIHdoZXRoZXIgeW91IGtub3cgb2YgYW55IElQUiBhc3NvY2lhdGVkIHdpdGggZHJhZnQtaWV0 Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im1zaXBmb290ZXIzMGIz ZDUzOCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxicj4NCjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F8A889CA37CC4DA39C7C82B5476DBB2Aciscocom_-- From nobody Fri Jul 24 07:54:38 2020 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 611F83A0B75 for ; Fri, 24 Jul 2020 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T8-fjSNtKW0 for ; Fri, 24 Jul 2020 07:54:34 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (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 7974F3A0B62 for ; Fri, 24 Jul 2020 07:54:34 -0700 (PDT) Received: from [IPv6:2a01:e35:2e59:ce10::da3d:a356] (unknown [IPv6:2a01:e35:2e59:ce10::da3d:a356]) by smtp4-g21.free.fr (Postfix) with ESMTP id A1A3919F594 for ; Fri, 24 Jul 2020 16:54:32 +0200 (CEST) To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Fri, 24 Jul 2020 16:54:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E91E289E71A4B9D7A92ABB71" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6-only and NTP on Windows 10 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 14:54:36 -0000 This is a multi-part message in MIME format. --------------E91E289E71A4B9D7A92ABB71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit During the hackathon with the help of a colleague I found that NTP on Windows 10 IPv6-only client (IPv4 stack turned off) works so and so. There are two pre-configured NTP servers on Windows 10: time.nist.gov and time.windows.com.  Only the former works.  It's not possible to add another NTP server in the GUI. Alex Le 24/07/2020 à 12:49, Alexandre Petrescu a écrit : > > www.webex.com is brwsable from an IPv6-only computer (IPv4 stack > turned off) > > but when clicking on an URL of a telco (URL starts with an fqdn > skku-ict.webex.com) the connection does not work. > > Alex > > Le 24/07/2020 à 11:15, Alexandre Petrescu a écrit : >> >> Microsoft Teams, a tool for online collaboration, works fine on IPv4. >> >> When tried on IPv6-only computer (IPv4 stack turned off) the initial >> phases of connection works, but connecting to a videoconference does >> not work. >> >> Alex >> >> Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit : >>> Gather.town is a game-like tool for virtually attending the IETF >>> >>> https://gather.town/z6N2SDxHebMdDAfo/IETF-108 >>> >>> IPv6-only access is when I use only IPv6 on my Windows 10. (right >>> button on RJ45 symbol on lower right icon bar on Windows, then >>> Ethernet, then modify adapter options, then select the Ethernet >>> interface, then Properties, then un-check IPv4 and check IPv6). >>> >>> With this on, when I walk on the floor of IETF and meet some people >>> it is impossible to 'Connect' - it shows "Connecting..." and it >>> blocks there.  But it works fine when on IPv4. >>> >>> Maybe this gather.town Connecting to others works for other people >>> on IPv6-only. >>> >>> Alex >>> >>> _______________________________________________ >>> 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 --------------E91E289E71A4B9D7A92ABB71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

During the hackathon with the help of a colleague

I found that NTP on Windows 10 IPv6-only client (IPv4 stack turned off) works so and so.

There are two pre-configured NTP servers on Windows 10: time.nist.gov and time.windows.com.  Only the former works.  It's not possible to add another NTP server in the GUI.

Alex

Le 24/07/2020 à 12:49, Alexandre Petrescu a écrit :

www.webex.com is brwsable from an IPv6-only computer (IPv4 stack turned off)

but when clicking on an URL of a telco (URL starts with an fqdn skku-ict.webex.com) the connection does not work.

Alex

Le 24/07/2020 à 11:15, Alexandre Petrescu a écrit :

Microsoft Teams, a tool for online collaboration, works fine on IPv4.

When tried on IPv6-only computer (IPv4 stack turned off) the initial phases of connection works, but connecting to a videoconference does not work.

Alex

Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit :
Gather.town is a game-like tool for virtually attending the IETF

https://gather.town/z6N2SDxHebMdDAfo/IETF-108

IPv6-only access is when I use only IPv6 on my Windows 10. (right button on RJ45 symbol on lower right icon bar on Windows, then Ethernet, then modify adapter options, then select the Ethernet interface, then Properties, then un-check IPv4 and check IPv6).

With this on, when I walk on the floor of IETF and meet some people it is impossible to 'Connect' - it shows "Connecting..." and it blocks there.  But it works fine when on IPv4.

Maybe this gather.town Connecting to others works for other people on IPv6-only.

Alex

_______________________________________________
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
--------------E91E289E71A4B9D7A92ABB71-- From nobody Fri Jul 24 08:34:07 2020 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 D75F93A0CE6 for ; Fri, 24 Jul 2020 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG83x1zrqoG7 for ; Fri, 24 Jul 2020 08:34:04 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 EA7763A0CE0 for ; Fri, 24 Jul 2020 08:34:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06OFY1i4017677 for ; Fri, 24 Jul 2020 17:34:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E6BEC204C9E for ; Fri, 24 Jul 2020 17:34:01 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA5C5201281 for ; Fri, 24 Jul 2020 17:34:01 +0200 (CEST) Received: from [10.11.240.62] ([10.11.240.62]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06OFY1ag017243 for ; Fri, 24 Jul 2020 17:34:01 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Fri, 24 Jul 2020 17:34:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E38224B0133E3D9E6D60F62" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6-only and NTP on Windows 10 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 15:34:06 -0000 This is a multi-part message in MIME format. --------------8E38224B0133E3D9E6D60F62 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 24/07/2020 à 16:54, Alexandre Petrescu a écrit : > > During the hackathon with the help of a colleague > > I found that NTP on Windows 10 IPv6-only client (IPv4 stack turned > off) works so and so. > > There are two pre-configured NTP servers on Windows 10: time.nist.gov > and time.windows.com.  Only the former works.  It's not possible to > add another NTP server in the GUI. > sorry, to correct myself, and I will stop on this NTP IPv6 topic. It is possible on Windows GUI to add another NTP server.  IT is  very straightforward.  I added 0.europe.pool.ntp.org, but it did not sync when queried from an IPv6-only client. Somebody provided me a list of servers to try but the chat was disconnected so I lost the log. Alex > Alex > > Le 24/07/2020 à 12:49, Alexandre Petrescu a écrit : >> >> www.webex.com is brwsable from an IPv6-only computer (IPv4 stack >> turned off) >> >> but when clicking on an URL of a telco (URL starts with an fqdn >> skku-ict.webex.com) the connection does not work. >> >> Alex >> >> Le 24/07/2020 à 11:15, Alexandre Petrescu a écrit : >>> >>> Microsoft Teams, a tool for online collaboration, works fine on IPv4. >>> >>> When tried on IPv6-only computer (IPv4 stack turned off) the initial >>> phases of connection works, but connecting to a videoconference does >>> not work. >>> >>> Alex >>> >>> Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit : >>>> Gather.town is a game-like tool for virtually attending the IETF >>>> >>>> https://gather.town/z6N2SDxHebMdDAfo/IETF-108 >>>> >>>> IPv6-only access is when I use only IPv6 on my Windows 10. (right >>>> button on RJ45 symbol on lower right icon bar on Windows, then >>>> Ethernet, then modify adapter options, then select the Ethernet >>>> interface, then Properties, then un-check IPv4 and check IPv6). >>>> >>>> With this on, when I walk on the floor of IETF and meet some people >>>> it is impossible to 'Connect' - it shows "Connecting..." and it >>>> blocks there.  But it works fine when on IPv4. >>>> >>>> Maybe this gather.town Connecting to others works for other people >>>> on IPv6-only. >>>> >>>> Alex >>>> >>>> _______________________________________________ >>>> 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 --------------8E38224B0133E3D9E6D60F62 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Le 24/07/2020 à 16:54, Alexandre Petrescu a écrit :

During the hackathon with the help of a colleague

I found that NTP on Windows 10 IPv6-only client (IPv4 stack turned off) works so and so.

There are two pre-configured NTP servers on Windows 10: time.nist.gov and time.windows.com.  Only the former works.  It's not possible to add another NTP server in the GUI.


sorry, to correct myself, and I will stop on this NTP IPv6 topic.

It is possible on Windows GUI to add another NTP server.  IT is  very straightforward.  I added 0.europe.pool.ntp.org, but it did not sync when queried from an IPv6-only client.

Somebody provided me a list of servers to try but the chat was disconnected so I lost the log.

Alex

Alex

Le 24/07/2020 à 12:49, Alexandre Petrescu a écrit :

www.webex.com is brwsable from an IPv6-only computer (IPv4 stack turned off)

but when clicking on an URL of a telco (URL starts with an fqdn skku-ict.webex.com) the connection does not work.

Alex

Le 24/07/2020 à 11:15, Alexandre Petrescu a écrit :

Microsoft Teams, a tool for online collaboration, works fine on IPv4.

When tried on IPv6-only computer (IPv4 stack turned off) the initial phases of connection works, but connecting to a videoconference does not work.

Alex

Le 20/07/2020 à 22:17, Alexandre Petrescu a écrit :
Gather.town is a game-like tool for virtually attending the IETF

https://gather.town/z6N2SDxHebMdDAfo/IETF-108

IPv6-only access is when I use only IPv6 on my Windows 10. (right button on RJ45 symbol on lower right icon bar on Windows, then Ethernet, then modify adapter options, then select the Ethernet interface, then Properties, then un-check IPv4 and check IPv6).

With this on, when I walk on the floor of IETF and meet some people it is impossible to 'Connect' - it shows "Connecting..." and it blocks there.  But it works fine when on IPv4.

Maybe this gather.town Connecting to others works for other people on IPv6-only.

Alex

_______________________________________________
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
--------------8E38224B0133E3D9E6D60F62-- From nobody Fri Jul 24 10:48:26 2020 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 951A73A10C5; Fri, 24 Jul 2020 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQx8ZuOfp4Kj; Fri, 24 Jul 2020 10:48:20 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152743A10A0; Fri, 24 Jul 2020 10:47:51 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:109:b9be:a52:530c] (unknown [IPv6:2800:810:464:1f7:109:b9be:a52:530c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E2449280B9C; Fri, 24 Jul 2020 17:47:46 +0000 (UTC) To: Ron Bonica , "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops@ietf.org" References: From: Fernando Gont Message-ID: <2580e124-a7f8-4aab-ae73-a46885cd1b23@si6networks.com> Date: Thu, 23 Jul 2020 17:47:17 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-cpe-slaac-renum: IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 17:48:25 -0000 Hi, Ron, On 23/7/20 17:44, Ron Bonica wrote: > Co-authors, > > Please respond to the list indicating whether you know of any IPR > associated with draft-ietf-v6ops-cpe-slaac-renum. I don't know of any IPRs associated with this document. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jul 24 10:58:24 2020 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 65CDA3A10E9; Fri, 24 Jul 2020 10:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X87HMahtspx; Fri, 24 Jul 2020 10:58:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0143A10E7; Fri, 24 Jul 2020 10:58:19 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:109:b9be:a52:530c] (unknown [IPv6:2800:810:464:1f7:109:b9be:a52:530c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 48ECE2802E0; Fri, 24 Jul 2020 17:58:15 +0000 (UTC) To: Ron Bonica , "draft-ietf-v6ops-slaac-renum@ietf.org" , "v6ops@ietf.org" References: From: Fernando Gont Message-ID: <69b0b948-3e3e-b683-0f84-5066ee143ad2@si6networks.com> Date: Fri, 24 Jul 2020 14:57:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum IPR X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 17:58:23 -0000 Hi, Ron, On 23/7/20 17:46, Ron Bonica wrote: > Co-authors, > > Please respond to the list indicating whether you know of any IPR > associated with this draft-ietf-v6ops-slaac-renum. I don't know of any IPRs associated with this document. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Jul 25 22:32:08 2020 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 DEA103A0B27 for ; Sat, 25 Jul 2020 22:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0PGnUI2VUCC for ; Sat, 25 Jul 2020 22:32:05 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD013A0B21 for ; Sat, 25 Jul 2020 22:32:05 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id d4so7592296pgk.4 for ; Sat, 25 Jul 2020 22:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:in-reply-to:to; bh=IBvKz1eu7uofL3raZgRiSiawgEkJ37RTZgRwjOwYdII=; b=Jg8c3VNf+uoxvKYSbEvml2siBJgkENO4PpeYTpo2uGGmy1109AvwHo8iWqQpxMWTFq cCpy3nDDKJ+Q6G7oseYt3LfVGe3id19iWgiqGSKKk9soIqZK5g6ZMId3RBHm3/B0Sd+f WCCl9ZidvqELpNGAM2QtmRgkQ1Rp5YdSKwGfqczSctZ1wisQkAsDUyAD9VYM9Ja7RgQS bTFMBG9EaSFnVJrw/gShbnJ2pHN+MEPr3sfcAAXLOPstcUjEIjH/5+wUOaq6I9GyVuf2 ETU4NXg4atI4aJsh7tZ96m506TDULoAHjF2vJTCB9u9rFzbX7hxHWqGcepZeGx/yXk+Y Uxcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:in-reply-to:to; bh=IBvKz1eu7uofL3raZgRiSiawgEkJ37RTZgRwjOwYdII=; b=GkkkcqPxHSVN0eHaicbF6QsiTSHkyNY9z7dpGvuDvf6tbMqx6u6R6Eqmpg33lvAhUu 3Uiv/MJdrJENVOslA16SoI0EREVGnvQJUxSKZ6pe79Pk+zaBfRmNLsVr20X4FPGUV22q 0tzA4YCA5Y9seCVQRXx8efWypvk6b1nAdHg8tO3LyYkMOPANjLhN3REeW6DmIlMXmzjd Qm5OTUVqsLbXyQjFVwJr/D7IAN0d5NOA9d4rUEEmaQ5eJaFnl4xuE54vwWid+sfLOnSX CJc+2miZj9H6U3iQ55rQZNfntd6k2FaVNbOiSGmNL2ST6ufAZiNnJ6SHOrvHn4HJ20k+ 2UPw== X-Gm-Message-State: AOAM530ccNOj/1WmFgkzBc+4AFyjj0xPAtWHzrqlgg+YLuerxvp3JbVP bYeeVEiV1t/j9Jjm4wc3FFL9TqL1bDQ= X-Google-Smtp-Source: ABdhPJws7RK6klWfVkVd0CF2bPo8TpwwxcUuAyiY++rCjviC3yCLL+91R43ZMv88IJrgZYnWEEiygg== X-Received: by 2002:aa7:92d7:: with SMTP id k23mr16032813pfa.189.1595741524421; Sat, 25 Jul 2020 22:32:04 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::1414? ([2600:8802:5800:652::1414]) by smtp.gmail.com with ESMTPSA id b4sm9175327pjn.38.2020.07.25.22.32.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Jul 2020 22:32:03 -0700 (PDT) From: Fred Baker X-Google-Original-From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sat, 25 Jul 2020 22:32:02 -0700 Message-Id: <4BB32295-4BCB-4EA4-A94C-CA41DA8A8E61@gmail.com> References: In-Reply-To: To: IPv6 Operations X-Mailer: iPad Mail (17G68) Archived-At: Subject: Re: [v6ops] Encourage people to visit NomCom during office hours X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 05:32:07 -0000 Passing along a couple of messages from the nomcom chair. There will be offi= ce hours next week, which you=E2=80=99re welcome to use. And in general, the= IETF, IESG, and IAB always need people willing to be selected as ADs, IAB m= embers, and so on. SO please be willing to be available, and if you see some= one that would be good in a stated role, check with them first, and if they a= gree, file a nomination. Sent from my iPad > On Jul 25, 2020, at 1:16 PM, STARK, BARBARA H wrote: >=20 > =EF=BB=BFHi WG Chairs, > Could you let your groups know that if anyone is interested in finding out= more about NomCom or about standing for an I* position (or just wants to sa= y Hi), they can visit with NomCom during office hours next week? Thx, > Barbara >=20 > Here is the message I sent to the ietf list: > --------------------------------------------------------------------------= ----------------------------------------------------- > I wanted to let everyone know that NomCom will be holding some office hour= s next week. If you want to stop by and talk with us (just to say Hi, ask ab= out NomCom, ask about being a nominee for the various I* positions, etc.), w= e'd love to see and hear from you. >=20 > The date and times (which are also posted on the IETF 108 Agenda) are: >=20 > Monday, July 27, 16:00-17:00 UTC WebEx: https://ietf.webex.com/ietf/j.p= hp?MTID=3Dm13c41ae118e538b6d25efb25d41307ee > Tuesday, July 28, 09:30-10:30 UTC WebEx: https://ietf.webex.com/ietf/j.= php?MTID=3Dm6132b48c3eac5469a41043ce55dada20 > Thursday, July 30, 20:00-21:00 UTC WebEx: https://ietf.webex.com/ietf/j= ..php?MTID=3Dmf7ce451931e35818fd7b3bf44abd1026 >=20 > In addition to being available by WebEx, those of us who can will simultan= eously be on Gather.Town (possibly in a special NomCom corner). To find us, t= he easiest way is to go to the Participants list (at right of the Gather scr= een), find "Barbara Stark", left click on my name and select "Locate". >=20 > See you next week! > Barbara=20 >=20 From nobody Sat Jul 25 22:46:32 2020 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 353D73A0B3C for ; Sat, 25 Jul 2020 22:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHr2kyHCN70x for ; Sat, 25 Jul 2020 22:46:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0DD3A0B3A for ; Sat, 25 Jul 2020 22:46:25 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:b555:9e82:e290:b934] (unknown [IPv6:2800:810:464:1f7:b555:9e82:e290:b934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 960292839A1; Sun, 26 Jul 2020 05:46:21 +0000 (UTC) References: <159574133039.611.5729379262275824659@ietfa.amsl.com> From: Fernando Gont To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org X-Forwarded-Message-Id: <159574133039.611.5729379262275824659@ietfa.amsl.com> Message-ID: Date: Sun, 26 Jul 2020 02:46:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <159574133039.611.5729379262275824659@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 05:46:30 -0000 Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers". The I-D is available at: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , Geoff Huston , Warren Kumari , Nick Hilliard A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Jul 26 15:14:08 2020 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 5BE1B3A14E6 for ; Sun, 26 Jul 2020 15:14:07 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2lEFfZqLyvj for ; Sun, 26 Jul 2020 15:14:06 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C21A3A14DA for ; Sun, 26 Jul 2020 15:14:06 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id k71so8070472pje.0 for ; Sun, 26 Jul 2020 15:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=j1kqeYdW8a1VWnDoO8QbrpQRnKb0tqUAlcKBlOx/n4s=; b=LVg1sDi1+RDdAI5MGbGfzNgbDcTqEOfV7cO0I1mGIfB17tgBuhK1JTadcWTi1oU254 iCUqcm7Em3JZCfTzdP8syIsCv2hf5Z5InWV6Ngyvr+vpkNwU1uSeue6HqhZZFwab2z3+ rKpbc3igAcuLKM0mo3PhjLj5LdmVZ6EQ/jwJ2KcmSFRDemlGMua/pcRbADHgL+wtWMPQ ZfFcroekDHkv7ym1XOtmWuV1tJEhspvMzXFaJN/JYNGT4ZbqH1B6r+GsnVcygL+Rj+CW 0OeIpSRyDJQ6zOcCieapAXA2tSD4OFv76Cs/TqTONYixcsqAsnKYBbXvMJUNm4ysdFwo O9tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j1kqeYdW8a1VWnDoO8QbrpQRnKb0tqUAlcKBlOx/n4s=; b=lOeDh5NCfPTWt+HnYEjakEhsbKJqBZw1ZAenXJboHpyNZfqd3KMAhVR5sJ5cU17VM0 v+tguqU6PS8hvG2lAY58vhMUB/xcjFjnGAjXmcF1cks9p1RILGGqAAif/APnNajUNVP4 8GsSDkXtmLR02EHPyPFrF3co2I9FX6Vr29hpau9DRo1Yfxh9hUm1//sUPBin7rqNv5fj jJ7ME73XEdJF9WAhxFn84XtbBbv5BDFoO+TKkxm7liDrfyiA5cnWEBYv7DaRze2Q1TO5 B/srU/BkoH4Kt3YHUiBB9aLrHv/drl7DSIa2Y67EuM3GJfD1nBIsF8qS6z43l52Rs+N2 EPTQ== X-Gm-Message-State: AOAM532+LM453MlBXowc42dGISa73hIKBh8cRe1MIGEL0Sm2wqSl0zUd zKWkhr/BWDlfnJcmxoBkrMnCUuLD X-Google-Smtp-Source: ABdhPJy9QgI3Pi3QWqXpCewgEVdE/Wn8cxnrgH6g2OiN4nqvyRqYdFzXifTEKkSDOlIS11kvFER02w== X-Received: by 2002:a17:90b:300d:: with SMTP id hg13mr16463862pjb.212.1595801645082; Sun, 26 Jul 2020 15:14:05 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id c132sm12389822pfb.112.2020.07.26.15.14.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 15:14:04 -0700 (PDT) References: <159574132870.611.12077598721404194383@ietfa.amsl.com> From: Brian E Carpenter To: IPv6 Operations Message-ID: Date: Mon, 27 Jul 2020 10:14:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <159574132870.611.12077598721404194383@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 22:14:07 -0000 Hi, IMHO this is useful work. > A number of recent RFCs have discussed issues related to IPv6 extension headers, I suggest to add RFC7045 to the bullet list, and delete the reference to it in the previous paragraph. In fact, the structure of the "Previous Work" section is a bit strange, with a prose paragraph followed by a bullet list. Maybe restructure that (e.g. transform it into a single longer bullet list)? Regards Brian On 26-Jul-20 17:28, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Operational Implications of IPv6 Packets with Extension Headers > Authors : Fernando Gont > Nick Hilliard > Gert Doering > Warren Kumari > Geoff Huston > Filename : draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Pages : 15 > Date : 2020-07-25 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sun Jul 26 23:47:11 2020 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 94A5A3A1735 for ; Sun, 26 Jul 2020 23:47:09 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_A-2WMTgA5J for ; Sun, 26 Jul 2020 23:47:07 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7ED123A1734 for ; Sun, 26 Jul 2020 23:47:07 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 901A0B200170CA0CE5F2; Mon, 27 Jul 2020 07:47:05 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 07:47:04 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 14:47:02 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 14:47:02 +0800 From: "Xiejingrong (Jingrong)" To: Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Thread-Index: AQHWY5oqHERLRLtRAUaPyhhedF3t5qka8dyg Date: Mon, 27 Jul 2020 06:47:02 +0000 Message-ID: <6b0bd06bf0624eb18780620cb918f3e8@huawei.com> References: <159574132870.611.12077598721404194383@ietfa.amsl.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.108.202.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 06:47:10 -0000 Hi, I read this draft and think it is a useful work. I have two suggestions below: 1. Section 4 describes the challenge of "packet filtering mechanisms that r= equire upper-layer information". Some similar need for "packet filtering mechanisms that require EH informat= ion" has also been seen recently in IETF. That may face the same challenge, and may need to be taken into considerati= on in this document. 2. Section 5.1.3 gives two examples to illustrate the requirement of "Deep = ACL" on the "infrastructure address".=20 Very good observation IMO, and I think some of the latest IETF practice may= be useful for citing in this document. RFC8754 section 5.1 separates a "programmable infrastructure address block"= from the normal "infrastructure address", and thus makes a good solution t= o this "differentiation" requirements -- Deny the ICMP/BGP/etc traffic toward the "programmable infrastructure addre= ss block ", but no impact on existing rules to permit the ICMP/BGP/etc traf= fic toward to the normal "infrastructure address". Thanks Jingrong Xie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Monday, July 27, 2020 6:14 AM To: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.= txt Hi, IMHO this is useful work. > A number of recent RFCs have discussed issues related to IPv6=20 > extension headers, I suggest to add RFC7045 to the bullet list, and delete the reference to it= in the previous paragraph. In fact, the structure of the "Previous Work" section is a bit strange, with a prose paragraph followed by a bullet list. Maybe restructure that (e.g. transform it into a single longer bullet list)= ? Regards Brian On 26-Jul-20 17:28, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Operational Implications of IPv6 Packets with E= xtension Headers > Authors : Fernando Gont > Nick Hilliard > Gert Doering > Warren Kumari > Geoff Huston > Filename : draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Pages : 15 > Date : 2020-07-25 >=20 > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drop > s/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet > -drops-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-dro > ps-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 27 00:39:52 2020 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 5F78F3A07B9 for ; Mon, 27 Jul 2020 00:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlG3PIY-GBC3 for ; Mon, 27 Jul 2020 00:39:48 -0700 (PDT) Received: from tools.si6networks.com (v6toolkit.go6lab.si [IPv6:2001:67c:27e4::57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8033A1772 for ; Mon, 27 Jul 2020 00:39:48 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tools.si6networks.com (Postfix) with ESMTPSA id F17BD3FF71; Mon, 27 Jul 2020 09:39:43 +0200 (CEST) To: Brian E Carpenter , IPv6 Operations References: <159574132870.611.12077598721404194383@ietfa.amsl.com> From: Fernando Gont Message-ID: <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> Date: Mon, 27 Jul 2020 03:49:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 07:39:50 -0000 On 26/7/20 19:14, Brian E Carpenter wrote: > Hi, > > IMHO this is useful work. > >> A number of recent RFCs have discussed issues related to IPv6 extension headers, > > I suggest to add RFC7045 to the bullet list, and delete the reference to it > in the previous paragraph. In fact, the structure of the "Previous Work" > section is a bit strange, with a prose paragraph followed by a bullet list. > Maybe restructure that (e.g. transform it into a single longer bullet list)? That's a good point. I wonder if we could somehow separate: * Std work that has become incorporated into the core spec. * Other Std work that affects EHs but hasn't been incorporated into the core spec (e.g., RFC6980) BTW... it seems that RFC7045 has not really been incorporated into RFC8200? I mean, other work (e.g. RFC6946 has been incorporated into RFC8200, and currently their raison d'etre is mostly for the reader to find additional information -- but from the pov of RFC8200 is not really necessary to read RFC6946). OTOH, it would seem that RFC7045 still applies to RFC8200 in the very same way it applies/applied to RFC2460? So in a way it should be in the bulleted list, but otoh it doesn't seem to have been incorporated into RFC8200 -- while it still applies to it? Modulo RFC6980 (and RFC7045), it would seem that the first para (prose) could also be arranged as a set of bullets, noting something along the lines of "documents that discuss operational implications of EHs"? And I guess we could also arrange the measurements stuff (last para) in their own set of bullets? Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Jul 27 01:46:49 2020 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 6282D3A17CC; Mon, 27 Jul 2020 01:46:47 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgwxu-Cd_99m; Mon, 27 Jul 2020 01:46:46 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7423B3A0C2D; Mon, 27 Jul 2020 01:46:45 -0700 (PDT) Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2FFA3EFF523B1396733C; Mon, 27 Jul 2020 09:46:43 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 09:46:42 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 11:46:42 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 11:46:42 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - MTU Thread-Index: AdZj8f/Upo2wn+ELR6mdAuOglYKu+g== Date: Mon, 27 Jul 2020 08:46:42 +0000 Message-ID: <678838bf6f0549689268a571498332d1@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 08:46:48 -0000 Hi Fernando, It is possible to search "MTU" in your draft. But I am surprised anyway how= small attention (to this problem) is in your draft. IMHO: MTU deserves to be section 5.4 Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 26 =C9=C0=CC=D1 2020 =C7. 8:46 To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt) Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pack= ets with Extension Headers". The I-D is available at:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , G= eoff Huston , Warren Kumari , Nick Hillia= rd A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Status:=20 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized:=20 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drop= s Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-= 04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 27 01:57:38 2020 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 0CA3F3A17D7; Mon, 27 Jul 2020 01:57:37 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vead9ypTUo_Z; Mon, 27 Jul 2020 01:57:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 15BDA3A17D6; Mon, 27 Jul 2020 01:57:35 -0700 (PDT) Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A9A652E65A073E3E847A; Mon, 27 Jul 2020 09:57:33 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 09:57:33 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 11:57:32 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 11:57:32 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality Thread-Index: AdZj8y0cpQvjOWzVQImqu+eAb68F0A== Date: Mon, 27 Jul 2020 08:57:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 08:57:37 -0000 Hi Fernando, Security is sometimes functionality, not vulnerability or attack vector. Th= e good example is Firewall. Firewall needs to parse all headers to be usefu= l. Hence, I believe it is in the logic of this draft to have section 5.1.5: on= e additional "use case" when parsing of ALL headers are mandatory. FW, IDPS Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 26 =C9=C0=CC=D1 2020 =C7. 8:46 To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt) Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pack= ets with Extension Headers". The I-D is available at:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , G= eoff Huston , Warren Kumari , Nick Hillia= rd A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Status:=20 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized:=20 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drop= s Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-= 04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 27 02:08:29 2020 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 B221D3A17E5; Mon, 27 Jul 2020 02:08:28 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajvIZ9hDg1gv; Mon, 27 Jul 2020 02:08:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0A6FD3A17E7; Mon, 27 Jul 2020 02:08:26 -0700 (PDT) Received: from lhreml740-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ADCE56C338A73D362A49; Mon, 27 Jul 2020 10:08:24 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:08:24 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:08:23 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:08:23 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AdZj9Efrgvrnr0hITbeSprlQeXLX0w== Date: Mon, 27 Jul 2020 09:08:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:08:29 -0000 Hi Fernando, Hence again, following the logic of this draft (the level of detalization t= hat you have given to 5.1) - may be you need additional section 5.1.x: Load= Balancer have to look into TCP/UDP ports. Moreover, it could not trust "Fl= ow label" - it is not reliable practice for LB. Or alternatively you could say something about LB in section 5.1.2, but bec= ause it is a little special case - may be better to have separate 5.1.x Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 26 =C9=C0=CC=D1 2020 =C7. 8:46 To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt) Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pack= ets with Extension Headers". The I-D is available at:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , G= eoff Huston , Warren Kumari , Nick Hillia= rd A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Status:=20 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized:=20 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drop= s Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-= 04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 nobody Mon Jul 27 02:18:58 2020 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 3F5E43A17EB; Mon, 27 Jul 2020 02:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDV23AI8AX18; Mon, 27 Jul 2020 02:18:54 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C5A3A17EC; Mon, 27 Jul 2020 02:18:50 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 080F6280365; Mon, 27 Jul 2020 09:18:45 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <678838bf6f0549689268a571498332d1@huawei.com> From: Fernando Gont Message-ID: <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> Date: Mon, 27 Jul 2020 06:18:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <678838bf6f0549689268a571498332d1@huawei.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:18:56 -0000 Hello, Edward, On 27/7/20 05:46, Vasilenko Eduard wrote: > Hi Fernando, > It is possible to search "MTU" in your draft. But I am surprised anyway how small attention (to this problem) is in your draft. > IMHO: MTU deserves to be section 5.4 Could you please clarify what's the discussion you expect to see about the MTU? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:22:29 2020 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 813173A17F4; Mon, 27 Jul 2020 02:22:26 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6GcvE19m2XQ; Mon, 27 Jul 2020 02:22:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6C4463A17ED; Mon, 27 Jul 2020 02:22:24 -0700 (PDT) Received: from lhreml739-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C8C8AE0D1572BA81D5F7; Mon, 27 Jul 2020 10:22:20 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml739-chm.china.huawei.com (10.201.108.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:22:20 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:22:19 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:22:19 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency Thread-Index: AdZj9zFJtjveS0eYRluv5AthxXDk5Q== Date: Mon, 27 Jul 2020 09:22:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:22:27 -0000 Hi Fernando, You did mention "implementation-dependent" in security section. But majorit= y of people would bypass security section on the 1st pass of reading your d= raft. Except security people, others would look to functionality 1st, them may be= security (may be not:-(). Hence, you almost ignore "implementation-depende= ncy" in such a way (putting it into security section). I propose to introduce additional 5.x, because (IMHO) "implementation-depen= dency" is the biggest problem in this draft - it is related to money/expens= es (especially to replace hardware). It would be even bigger problem on next years with proliferation of SRv6, i= Fit, iOAM, BIERv6 and other abuses of IPv6 headers extensibility. People need to check hardware (and software) capability far in advance, or = else could be negative surprise. Warn them. Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 26 =C9=C0=CC=D1 2020 =C7. 8:46 To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt) Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pack= ets with Extension Headers". The I-D is available at:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , G= eoff Huston , Warren Kumari , Nick Hillia= rd A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Status:=20 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized:=20 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drop= s Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-= 04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 nobody Mon Jul 27 02:25:36 2020 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 3D6A93A1831; Mon, 27 Jul 2020 02:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3zq4ha0sc7L; Mon, 27 Jul 2020 02:25:26 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5422F3A182B; Mon, 27 Jul 2020 02:25:26 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2058A28390A; Mon, 27 Jul 2020 09:25:22 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: From: Fernando Gont Message-ID: Date: Mon, 27 Jul 2020 06:25:07 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:25:35 -0000 Hello, Edward, On 27/7/20 05:57, Vasilenko Eduard wrote: > Hi Fernando, > Security is sometimes functionality, not vulnerability or attack vector. The good example is Firewall. Firewall needs to parse all headers to be useful. > Hence, I believe it is in the logic of this draft to have section 5.1.5: one additional "use case" when parsing of ALL headers are mandatory. FW, IDPS It's indeed normally necessary for a firewall to parse all headers, and certainly this might be a motivation to drop packets at the edge of the network. However, I'm not sure if it would make sense to cover IDPS/FW in this I-D, since we're mostly discussing the reasons for operators (as opposed to say, sys admins or security administrators) to drop them. What do folks think? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:30:28 2020 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 A2FB43A17F7; Mon, 27 Jul 2020 02:30:26 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkWPanhowOCB; Mon, 27 Jul 2020 02:30:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A073B3A17F5; Mon, 27 Jul 2020 02:30:24 -0700 (PDT) Received: from lhreml727-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3605BA7278116969B1FE; Mon, 27 Jul 2020 10:30:23 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:30:22 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:30:21 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:30:21 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - OAM Thread-Index: AdZj+M7rylVBEZ48S5ifVJiJzMekBw== Date: Mon, 27 Jul 2020 09:30:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - OAM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:30:27 -0000 Hi Fernando, The more messages I have sent to you - the less confident I am in the next = one comment, but anyway. 1. All these new staff would need more OAM tools. May be such simple as "pi= ng for SRv6", may be much more complicated (is anything exist to ping BIER = data plane?). Network Admin (or Planning department) should research what i= s available for the tools that they have decided to activate. 2. Some EH are not practical without proper OSS tools (example: iFit) IMHO: it could be one additional section X (numbering in the root). It is probably very relevant, because draft has "v6ops" in the middle of th= e name. Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 26 =C9=C0=CC=D1 2020 =C7. 8:46 To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt) Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pack= ets with Extension Headers". The I-D is available at:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , G= eoff Huston , Warren Kumari , Nick Hillia= rd A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Status:=20 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized:=20 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drop= s Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-= 04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 nobody Mon Jul 27 02:33:01 2020 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 0DA8E3A17FA; Mon, 27 Jul 2020 02:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-ItahqEmju1; Mon, 27 Jul 2020 02:32:56 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F9E3A17F7; Mon, 27 Jul 2020 02:32:55 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3C1C028390A; Mon, 27 Jul 2020 09:32:51 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: From: Fernando Gont Message-ID: Date: Mon, 27 Jul 2020 06:31:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:32:59 -0000 Hello, Eduard, On 27/7/20 06:08, Vasilenko Eduard wrote: > Hi Fernando, > Hence again, following the logic of this draft (the level of detalization that you have given to 5.1) - may be you need additional section 5.1.x: Load Balancer have to look into TCP/UDP ports. You mean anything else of the coverage we already have for ECMP? > Moreover, it could not trust "Flow label" - it is not reliable practice for LB. Could you please elaborate? Are you referring to the fact that some host implementations might not set the Flow Label? Something else? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:39:42 2020 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 B4DED3A1806; Mon, 27 Jul 2020 02:39:39 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c5i1x-VXHk6; Mon, 27 Jul 2020 02:39:38 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 33C373A180B; Mon, 27 Jul 2020 02:39:38 -0700 (PDT) Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id ADECAA6FE08E5AA75282; Mon, 27 Jul 2020 10:39:36 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:39:36 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:39:35 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:39:35 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - MTU Thread-Index: AdZj8f/Upo2wn+ELR6mdAuOglYKu+v//13aA///Jm1A= Date: Mon, 27 Jul 2020 09:39:35 +0000 Message-ID: <446331e9ebc84c88a9197a27b169710e@huawei.com> References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> In-Reply-To: <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:39:40 -0000 Hi Fernando, It is more important to have the problem mentioned on the list, then the qu= ality of the section itself. It is definitely a problem if one would like to activate any EH - potential= admin should be warned. What could be inside: - small discussion that fragmentation in the middle of IPv6 path is not pos= sible - some IPCMPv6 messages should not be filtered - MTU is better to change on networking links In reality, I do not believe that it is difficult to compile this section, = because so many materials on the IETF for this subject. IMHO: it is very important to have this warning on the list. If you like, I could try to write this small section. Just this week is a l= ittle busy for me. Eduard -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 12:18 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - MTU Hello, Edward, On 27/7/20 05:46, Vasilenko Eduard wrote: > Hi Fernando, > It is possible to search "MTU" in your draft. But I am surprised anyway h= ow small attention (to this problem) is in your draft. > IMHO: MTU deserves to be section 5.4 Could you please clarify what's the discussion you expect to see about the = MTU? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:40:06 2020 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 978893A184C; Mon, 27 Jul 2020 02:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUZyXaYS2Go6; Mon, 27 Jul 2020 02:39:55 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2EC3A1839; Mon, 27 Jul 2020 02:39:54 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C9D09280B5A; Mon, 27 Jul 2020 09:39:50 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: From: Fernando Gont Message-ID: <3f135d04-7db1-39fa-07ea-2da190f2665d@si6networks.com> Date: Mon, 27 Jul 2020 06:38:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:40:05 -0000 Hello, Eduard, On 27/7/20 06:22, Vasilenko Eduard wrote: > Hi Fernando, You did mention "implementation-dependent" in security > section. But majority of people would bypass security section on the > 1st pass of reading your draft. Except security people, others would > look to functionality 1st, them may be security (may be not:-(). > Hence, you almost ignore "implementation-dependency" in such a way > (putting it into security section). Not sure what you mean... > I propose to introduce additional > 5.x, because (IMHO) "implementation-dependency" is the biggest > problem in this draft - it is related to money/expenses (especially > to replace hardware). It would be even bigger problem on next years > with proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of > IPv6 headers extensibility. People need to check hardware (and > software) capability far in advance, or else could be negative > surprise. What would you expect us to cover in such section, other than what we already cover in Section 5.1.1. (Packet Forwarding Engine Constraints)? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:43:18 2020 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 E22BA3A180E; Mon, 27 Jul 2020 02:43:16 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1WDzCuXDs8g; Mon, 27 Jul 2020 02:43:15 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 128E33A180B; Mon, 27 Jul 2020 02:43:15 -0700 (PDT) Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1C50C29AD50D114B401A; Mon, 27 Jul 2020 10:43:12 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:43:11 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:43:10 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:43:10 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality Thread-Index: AdZj8y0cpQvjOWzVQImqu+eAb68F0P//1v2A///IybA= Date: Mon, 27 Jul 2020 09:43:10 +0000 Message-ID: <48214ae519994396ae77e73c9b2b8d57@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:43:17 -0000 There is no any restriction in the name of this draft that "Enterprises sho= uld not read this draft". Put this restriction, then I would agree that FW is out. Something like "Operational Implications of IPv6 Packets with Extension Hea= ders in Telco environment". -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 12:25 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - Security as Functionality Hello, Edward, On 27/7/20 05:57, Vasilenko Eduard wrote: > Hi Fernando, > Security is sometimes functionality, not vulnerability or attack vector. = The good example is Firewall. Firewall needs to parse all headers to be use= ful. > Hence, I believe it is in the logic of this draft to have section=20 > 5.1.5: one additional "use case" when parsing of ALL headers are=20 > mandatory. FW, IDPS It's indeed normally necessary for a firewall to parse all headers, and cer= tainly this might be a motivation to drop packets at the edge of the networ= k. However, I'm not sure if it would make sense to cover IDPS/FW in this I-D, = since we're mostly discussing the reasons for operators (as opposed to say,= sys admins or security administrators) to drop them. What do folks think? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:46:26 2020 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 673123A1811; Mon, 27 Jul 2020 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoeshE4jk_ec; Mon, 27 Jul 2020 02:46:22 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4DC3A180E; Mon, 27 Jul 2020 02:46:21 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 17DAB283893; Mon, 27 Jul 2020 09:46:17 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: From: Fernando Gont Message-ID: <556c9c3a-b8e5-eb3d-cecb-dfe66cf98ac2@si6networks.com> Date: Mon, 27 Jul 2020 06:46:09 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - OAM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:46:25 -0000 Eduard, On 27/7/20 06:30, Vasilenko Eduard wrote: > Hi Fernando, > The more messages I have sent to you - the less confident I am in the next one comment, but anyway. ? > 1. All these new staff would need more OAM tools. May be such simple as "ping for SRv6", may be much more complicated (is anything exist to ping BIER data plane?). Network Admin (or Planning department) should research what is available for the tools that they have decided to activate. > 2. Some EH are not practical without proper OSS tools (example: iFit) > IMHO: it could be one additional section X (numbering in the root). > It is probably very relevant, because draft has "v6ops" in the middle of the name. I'm not sure what's the point you are raising. Essentially, operators employ devices that need to access L-4 information for doing a bunch of things (EMCP, enforcing ACLs, etc.). The structure of IPv6 packets makes accessing such information challenging. In some cases, devices are unable to access such information. In other cases, they might be able to do so provided the packet goes through the slow-path (all this depending, to some extent, on the EH-chain length). Ultimately, in many of these cases (if not all), operators have no other option than to drop the offending packets. This is a general issue of IPv6 EHs. Yes, depending on the tools you might need support for this or that. BUt how does that change the discussion we're having in the document? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:47:16 2020 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 498CC3A180E; Mon, 27 Jul 2020 02:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfBE_VnBeyUB; Mon, 27 Jul 2020 02:47:12 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9B63A1811; Mon, 27 Jul 2020 02:47:12 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id w17so13820726oie.6; Mon, 27 Jul 2020 02:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ACBfLgWXMUkuJNT9QAnvoFfdYUCHQ6ryJYnXkUVdDxo=; b=uTql68T0RVaJM7Ics8NqpVCV/C5EpZrDC8dCrRUFrB5bG6TccEXGrx+MZpHaOFZ370 D0NyKEd7RjrtA/gNGp+oqUIFKMDX7tKqoFLC2EFydzthlF+1N1Qn/yrPWDx5VX9/wS43 11kLFPcuqve6DBf7/R7xcajpNVHt5wYStf+bvvSfA9o/A0n8sUL5jwHz2SA2l5fluJDY XODUu7EnQzI0WcAjRXOa5x9nvZCksSpgJWw3cKQCZdQ7vUdz7aVRfzlUjBgyphCXVjFA mxPUIuwEA4jWQ4cXbebHJXWfH6UWFOJ1bS2z64ajoUPv2998iTBDAa961bq9dVZm9kHI NzOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ACBfLgWXMUkuJNT9QAnvoFfdYUCHQ6ryJYnXkUVdDxo=; b=EuxwihN6CZms/Nl7RqtAStueXBKJiEDTyaO3p+PEkEgpz/77COnqvqq7mnaQuKLvPv LCJRO2QXhKpjNuWFwgJF3iZiWVPk8v5nKPT73B8MeZ5eu+zmj6UUREQw8dRlO5Lj/vnI NzP/DJbmSC+9SF1VK636F2F9bBNSGjwdEQhnPu7odz3N/XyNoqdb9aSdrYpfwEZZXWTB PvFzmBrI1WM6/SheiIjt32y298P1qvzHCDAsFOEADWmVdeBXB4mV3HZ0EZ3SWj9AUF2p eMpnlDkXwVepw4W6VQgTkwhhsYoaLxAd+3xbSSwZ2HJC1DY7z5haNXic0U6PW98Z2YWT YmcA== X-Gm-Message-State: AOAM530Z9+XgBGFJ0BI1D3FMe5lBv9gHCQgM/8bg94PVad+p1Em16KSt Rh5ya5nS1qADB0PmQCEWZ+v3GPjNWsfgnBy1/3w= X-Google-Smtp-Source: ABdhPJxWOo8w5zZJawmSV2bGc0jVh83lS2tqSt6IIjpWXAph9CcEhlH+EtMKZwgPtXREfyIpJn9nC5uEiIBEs+Wniz8= X-Received: by 2002:aca:50d5:: with SMTP id e204mr17917005oib.60.1595843231815; Mon, 27 Jul 2020 02:47:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Mon, 27 Jul 2020 19:47:01 +1000 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f31e3a05ab69346e" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:47:14 -0000 --000000000000f31e3a05ab69346e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, If load balancers are going to be discussed, it also needs to be pointed out that they don't follow the definition of unicast addresses. A unicast address is to uniquely identify a single node. Load balancers share a single unicast address between multiple nodes, contradictory to the unique and single node identification purpose of unicast addresses. That is why they need to do non-RFC compliant things like digging into transport layer headers to work with unicast protocols like UDP, TCP and ICMP, trying to make them work across a fleet of nodes sharing a single unicast address. An anycast address, combined with a multi-path transport layer protocol is the way to do service load balancing in an RFC compliant way. See Section 5.7.7 of this draft for how. https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01= #section-5.7.7 Regards, Mark. On Mon, 27 Jul 2020, 19:08 Vasilenko Eduard, wrote: > Hi Fernando, > Hence again, following the logic of this draft (the level of detalization > that you have given to 5.1) - may be you need additional section 5.1.x: > Load Balancer have to look into TCP/UDP ports. Moreover, it could not tru= st > "Flow label" - it is not reliable practice for LB. > Or alternatively you could say something about LB in section 5.1.2, but > because it is a little special case - may be better to have separate 5.1.= x > > Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > To: IPv6 Operations > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: [v6ops] Operational Implications of IPv6 Packets with Extension > Headers (Fwd: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) > > Folks, > > We have posted a rev of our IETF I-D "Operational Implications of IPv6 > Packets with Extension Headers". > > The I-D is available at: > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > > Your feedback will be appreciated. > > Thanks! > > Cheers, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Date: Sat, 25 Jul 2020 22:28:50 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering , > Geoff Huston , Warren Kumari , Nick > Hilliard > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > has been successfully submitted by Fernando Gont and posted to the IETF > repository. > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > Revision: 04 > Title: Operational Implications of IPv6 Packets with Extension > Headers > Document date: 2020-07-25 > Group: Individual Submission > Pages: 15 > URL: > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-dr= ops > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drop= s-04 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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 > --000000000000f31e3a05ab69346e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

If load balancers are going to be discussed, it also needs = to be pointed out that they don't follow the definition of unicast addr= esses.

A unicast address= is to uniquely identify a single node.

Load balancers share a single unicast address between multi= ple nodes, contradictory to the unique and single node identification purpo= se of unicast addresses.

That is why they need to do non-RFC compliant things like digging into tra= nsport layer headers to work with unicast protocols like UDP, TCP and ICMP,= trying to make them work across a fleet of nodes sharing a single unicast = address.

An anycast addr= ess, combined with a multi-path transport layer protocol is the way to do s= ervice load balancing in an RFC compliant way.

<= /div>
See Section 5.7.7 of this draft for how.

https://tools.ietf.org/html/draft-s= mith-6man-form-func-anycast-addresses-01#section-5.7.7

Regards,<= /div>
Mark.


On Mon, 27 Jul 2020, 19:08 Vasil= enko Eduard, <vasilenko.eduard@huawei.com= > wrote:
Hi Fernando,
Hence again, following the logic of this draft (the level of detalization t= hat you have given to 5.1) - may be you need additional section 5.1.x: Load= Balancer have to look into TCP/UDP ports. Moreover, it could not trust &qu= ot;Flow label" - it is not reliable practice for LB.
Or alternatively you could say something about LB in section 5.1.2, but bec= ause it is a little special case - may be better to have separate 5.1.x

Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf= .org] On Behalf Of Fernando Gont
Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46
To: IPv6 Operations <v6ops@ietf.org>=
Cc: draft-go= nt-v6ops-ipv6-ehs-packet-drops@ietf.org
Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt)

Folks,

We have posted a rev of our IETF I-D "Operational Implications of IPv6= Packets with Extension Headers".

The I-D is available at:
https://www.ietf.org/internet-drafts/draft-gont-v= 6ops-ipv6-ehs-packet-drops-04.txt

Your feedback will be appreciated.

Thanks!

Cheers,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Date: Sat, 25 Jul 2020 22:28:50 -0700
From: internet-drafts@ietf.org To: Fernando Gont <fgont@si6networks= .com>, Gert Doering <gert@space.net<= /a>>, Geoff Huston <gih@apnic.net>= , Warren Kumari <warren@kumari.net&g= t;, Nick Hilliard <nick@inex.ie>


A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
has been successfully submitted by Fernando Gont and posted to the IETF rep= ository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-v6ops-ipv6-ehs-pac= ket-drops
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operational Implications of IPv6 P= ackets with Extension Headers
Document date:=C2=A0 2020-07-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:
https://www.ietf.org/internet-drafts/draft-gont-v= 6ops-ipv6-ehs-packet-drops-04.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-= packet-drops/
Htmlized:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-d= rops-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gont-v6ops-= ipv6-ehs-packet-drops
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-i= pv6-ehs-packet-drops-04

Abstract:
=C2=A0 =C2=A0 This document summarizes the security and operational implica= tions of
=C2=A0 =C2=A0 IPv6 extension headers, and attempts to analyze reasons why p= ackets
=C2=A0 =C2=A0 with IPv6 extension headers may be dropped in the public Inte= rnet.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--000000000000f31e3a05ab69346e-- From nobody Mon Jul 27 02:48:39 2020 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 36F243A1811; Mon, 27 Jul 2020 02:48:36 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbhsPFv7oMon; Mon, 27 Jul 2020 02:48:34 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B35823A1818; Mon, 27 Jul 2020 02:48:34 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E39F26D2A37EC634A1C9; Mon, 27 Jul 2020 10:48:32 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:48:32 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:48:31 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:48:31 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AdZj9Efrgvrnr0hITbeSprlQeXLX0///1qSA///Jo9A= Date: Mon, 27 Jul 2020 09:48:31 +0000 Message-ID: <56e20bc1907f4bc094ab568dd8032f70@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:48:36 -0000 Hi Fernando, Sorry, I do not believe that LB is doing ECMP - it is much more clever. And yes, you could rewrite section 5.1.2 that it would be not about "ECMP-o= nly". It is potential option to proceed. But looking to the detalization that you have given already to other small = use cases in section 5.1 - it is more logical to have LB separate. IMHO. Eduard -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 12:32 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - Load Balancer Hello, Eduard, On 27/7/20 06:08, Vasilenko Eduard wrote: > Hi Fernando, > Hence again, following the logic of this draft (the level of detalization= that you have given to 5.1) - may be you need additional section 5.1.x: Lo= ad Balancer have to look into TCP/UDP ports.=20 You mean anything else of the coverage we already have for ECMP? > Moreover, it could not trust "Flow label" - it is not reliable practice f= or LB. Could you please elaborate? Are you referring to the fact that some host i= mplementations might not set the Flow Label? Something else? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 02:50:13 2020 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 B55BE3A1811; Mon, 27 Jul 2020 02:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHmpkoBC9-it; Mon, 27 Jul 2020 02:50:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 5A49B3A0CD3; Mon, 27 Jul 2020 02:50:08 -0700 (PDT) Received: from lhreml715-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E6D4B4F422FE5C26BC79; Mon, 27 Jul 2020 10:50:06 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:50:06 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:50:05 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:50:05 +0300 From: Vasilenko Eduard To: Mark Smith CC: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AdZj9Efrgvrnr0hITbeSprlQeXLX0///2uaA///MpDA= Date: Mon, 27 Jul 2020 09:50:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: multipart/alternative; boundary="_000_e551a751cd7846bf8d15848e1d738875huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:50:11 -0000 --_000_e551a751cd7846bf8d15848e1d738875huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlbiBpdCBpcyBkZWZpbml0ZWx5IHNlcGFyYXRlIDUuMS54IGxvb2tpbmcgdG8gb3RoZXIgc21h bGwgdXNlcyBjYXNlcyBpbnNpZGUgNS4xIHRoYXQgYWxyZWFkeSBnb3QgdGhlaXIgc2VwYXJhdGUg Y2hhcHRlci4NCg0KRnJvbTogTWFyayBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5j b21dDQpTZW50OiAyNyDQuNGO0LvRjyAyMDIwINCzLiAxMjo0Nw0KVG86IFZhc2lsZW5rbyBFZHVh cmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4NCkNjOiBGZXJuYW5kbyBHb250IDxmZ29u dEBzaTZuZXR3b3Jrcy5jb20+OyBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPjsgZHJh ZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbdjZvcHNdIE9wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBF eHRlbnNpb24gSGVhZGVycyAtIExvYWQgQmFsYW5jZXINCg0KSGksDQoNCklmIGxvYWQgYmFsYW5j ZXJzIGFyZSBnb2luZyB0byBiZSBkaXNjdXNzZWQsIGl0IGFsc28gbmVlZHMgdG8gYmUgcG9pbnRl ZCBvdXQgdGhhdCB0aGV5IGRvbid0IGZvbGxvdyB0aGUgZGVmaW5pdGlvbiBvZiB1bmljYXN0IGFk ZHJlc3Nlcy4NCg0KQSB1bmljYXN0IGFkZHJlc3MgaXMgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYSBz aW5nbGUgbm9kZS4NCg0KTG9hZCBiYWxhbmNlcnMgc2hhcmUgYSBzaW5nbGUgdW5pY2FzdCBhZGRy ZXNzIGJldHdlZW4gbXVsdGlwbGUgbm9kZXMsIGNvbnRyYWRpY3RvcnkgdG8gdGhlIHVuaXF1ZSBh bmQgc2luZ2xlIG5vZGUgaWRlbnRpZmljYXRpb24gcHVycG9zZSBvZiB1bmljYXN0IGFkZHJlc3Nl cy4NCg0KVGhhdCBpcyB3aHkgdGhleSBuZWVkIHRvIGRvIG5vbi1SRkMgY29tcGxpYW50IHRoaW5n cyBsaWtlIGRpZ2dpbmcgaW50byB0cmFuc3BvcnQgbGF5ZXIgaGVhZGVycyB0byB3b3JrIHdpdGgg dW5pY2FzdCBwcm90b2NvbHMgbGlrZSBVRFAsIFRDUCBhbmQgSUNNUCwgdHJ5aW5nIHRvIG1ha2Ug dGhlbSB3b3JrIGFjcm9zcyBhIGZsZWV0IG9mIG5vZGVzIHNoYXJpbmcgYSBzaW5nbGUgdW5pY2Fz dCBhZGRyZXNzLg0KDQpBbiBhbnljYXN0IGFkZHJlc3MsIGNvbWJpbmVkIHdpdGggYSBtdWx0aS1w YXRoIHRyYW5zcG9ydCBsYXllciBwcm90b2NvbCBpcyB0aGUgd2F5IHRvIGRvIHNlcnZpY2UgbG9h ZCBiYWxhbmNpbmcgaW4gYW4gUkZDIGNvbXBsaWFudCB3YXkuDQoNClNlZSBTZWN0aW9uIDUuNy43 IG9mIHRoaXMgZHJhZnQgZm9yIGhvdy4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNtaXRoLTZtYW4tZm9ybS1mdW5jLWFueWNhc3QtYWRkcmVzc2VzLTAxI3NlY3Rpb24tNS43 LjcNCg0KUmVnYXJkcywNCk1hcmsuDQoNCk9uIE1vbiwgMjcgSnVsIDIwMjAsIDE5OjA4IFZhc2ls ZW5rbyBFZHVhcmQsIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5r by5lZHVhcmRAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgRmVybmFuZG8sDQpIZW5jZSBhZ2Fpbiwg Zm9sbG93aW5nIHRoZSBsb2dpYyBvZiB0aGlzIGRyYWZ0ICh0aGUgbGV2ZWwgb2YgZGV0YWxpemF0 aW9uIHRoYXQgeW91IGhhdmUgZ2l2ZW4gdG8gNS4xKSAtIG1heSBiZSB5b3UgbmVlZCBhZGRpdGlv bmFsIHNlY3Rpb24gNS4xLng6IExvYWQgQmFsYW5jZXIgaGF2ZSB0byBsb29rIGludG8gVENQL1VE UCBwb3J0cy4gTW9yZW92ZXIsIGl0IGNvdWxkIG5vdCB0cnVzdCAiRmxvdyBsYWJlbCIgLSBpdCBp cyBub3QgcmVsaWFibGUgcHJhY3RpY2UgZm9yIExCLg0KT3IgYWx0ZXJuYXRpdmVseSB5b3UgY291 bGQgc2F5IHNvbWV0aGluZyBhYm91dCBMQiBpbiBzZWN0aW9uIDUuMS4yLCBidXQgYmVjYXVzZSBp dCBpcyBhIGxpdHRsZSBzcGVjaWFsIGNhc2UgLSBtYXkgYmUgYmV0dGVyIHRvIGhhdmUgc2VwYXJh dGUgNS4xLngNCg0KRWR1YXJkDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIEZlcm5hbmRvIEdvbnQNClNlbnQ6IDI2INC40Y7Qu9GPIDIw MjAg0LMuIDg6NDYNClRvOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2 Nm9wc0BpZXRmLm9yZz4+DQpDYzogZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJv cHNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3Bz QGlldGYub3JnPg0KU3ViamVjdDogW3Y2b3BzXSBPcGVyYXRpb25hbCBJbXBsaWNhdGlvbnMgb2Yg SVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5zaW9uIEhlYWRlcnMgKEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50 eHQpDQoNCkZvbGtzLA0KDQpXZSBoYXZlIHBvc3RlZCBhIHJldiBvZiBvdXIgSUVURiBJLUQgIk9w ZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24gSGVh ZGVycyIuDQoNClRoZSBJLUQgaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0 LnR4dA0KDQpZb3VyIGZlZWRiYWNrIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcyENCg0K Q2hlZXJzLA0KRmVybmFuZG8NCg0KDQoNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0t LS0tLS0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LWdvbnQt djZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0LnR4dA0KRGF0ZTogU2F0LCAyNSBKdWwgMjAy MCAyMjoyODo1MCAtMDcwMA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpUbzogRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0 d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+PiwgR2VydCBEb2VyaW5nIDxn ZXJ0QHNwYWNlLm5ldDxtYWlsdG86Z2VydEBzcGFjZS5uZXQ+PiwgR2VvZmYgSHVzdG9uIDxnaWhA YXBuaWMubmV0PG1haWx0bzpnaWhAYXBuaWMubmV0Pj4sIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBr dW1hcmkubmV0PG1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldD4+LCBOaWNrIEhpbGxpYXJkIDxuaWNr QGluZXguaWU8bWFpbHRvOm5pY2tAaW5leC5pZT4+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0LnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGZXJuYW5kbyBHb250IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWdvbnQtdjZvcHMtaXB2 Ni1laHMtcGFja2V0LWRyb3BzDQpSZXZpc2lvbjogICAgICAgMDQNClRpdGxlOiAgICAgICAgICBP cGVyYXRpb25hbCBJbXBsaWNhdGlvbnMgb2YgSVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5zaW9uIEhl YWRlcnMNCkRvY3VtZW50IGRhdGU6ICAyMDIwLTA3LTI1DQpHcm91cDogICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMTUNClVSTDoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1k cm9wcy0wNC50eHQNClN0YXR1czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLw0KSHRtbGl6ZWQ6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJv cHMtMDQNCkh0bWxpemVkOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcw0KRGlmZjoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1k cm9wcy0wNA0KDQpBYnN0cmFjdDoNCiAgICBUaGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgdGhlIHNl Y3VyaXR5IGFuZCBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMgb2YNCiAgICBJUHY2IGV4dGVuc2lv biBoZWFkZXJzLCBhbmQgYXR0ZW1wdHMgdG8gYW5hbHl6ZSByZWFzb25zIHdoeSBwYWNrZXRzDQog ICAgd2l0aCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIG1heSBiZSBkcm9wcGVkIGluIHRoZSBwdWJs aWMgSW50ZXJuZXQuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRw Oi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcg bGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRm Lm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9w c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cg== --_000_e551a751cd7846bf8d15848e1d738875huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVuIGl0IGlzIGRlZmluaXRl bHkgc2VwYXJhdGUgNS4xLnggbG9va2luZyB0byBvdGhlciBzbWFsbCB1c2VzIGNhc2VzIGluc2lk ZSA1LjEgdGhhdCBhbHJlYWR5IGdvdCB0aGVpciBzZXBhcmF0ZSBjaGFwdGVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBN YXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiAyNyDQuNGO0LvRjyAyMDIwINCzLiAxMjo0Nzxicj4NCjxiPlRvOjwvYj4gVmFzaWxlbmtv IEVkdWFyZCAmbHQ7dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gRmVybmFuZG8gR29udCAmbHQ7ZmdvbnRAc2k2bmV0d29ya3MuY29tJmd0OzsgSVB2NiBPcGVy YXRpb25zICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMt cGFja2V0LWRyb3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIE9w ZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24gSGVh ZGVycyAtIExvYWQgQmFsYW5jZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIGxvYWQgYmFsYW5jZXJzIGFyZSBnb2luZyB0byBiZSBkaXNjdXNzZWQsIGl0 IGFsc28gbmVlZHMgdG8gYmUgcG9pbnRlZCBvdXQgdGhhdCB0aGV5IGRvbid0IGZvbGxvdyB0aGUg ZGVmaW5pdGlvbiBvZiB1bmljYXN0IGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSB1bmljYXN0IGFkZHJlc3MgaXMgdG8gdW5p cXVlbHkgaWRlbnRpZnkgYSBzaW5nbGUgbm9kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9hZCBiYWxhbmNlcnMgc2hhcmUgYSBzaW5nbGUg dW5pY2FzdCBhZGRyZXNzIGJldHdlZW4gbXVsdGlwbGUgbm9kZXMsIGNvbnRyYWRpY3RvcnkgdG8g dGhlIHVuaXF1ZSBhbmQgc2luZ2xlIG5vZGUgaWRlbnRpZmljYXRpb24gcHVycG9zZSBvZiB1bmlj YXN0IGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCBpcyB3aHkgdGhleSBuZWVkIHRvIGRvIG5vbi1SRkMgY29tcGxpYW50 IHRoaW5ncyBsaWtlIGRpZ2dpbmcgaW50byB0cmFuc3BvcnQgbGF5ZXIgaGVhZGVycyB0byB3b3Jr IHdpdGggdW5pY2FzdCBwcm90b2NvbHMgbGlrZSBVRFAsIFRDUCBhbmQgSUNNUCwgdHJ5aW5nIHRv IG1ha2UgdGhlbSB3b3JrIGFjcm9zcyBhIGZsZWV0IG9mIG5vZGVzIHNoYXJpbmcgYSBzaW5nbGUg dW5pY2FzdCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbiBhbnljYXN0IGFkZHJlc3MsIGNvbWJpbmVkIHdpdGggYSBtdWx0aS1w YXRoIHRyYW5zcG9ydCBsYXllciBwcm90b2NvbCBpcyB0aGUgd2F5IHRvIGRvIHNlcnZpY2UgbG9h ZCBiYWxhbmNpbmcgaW4gYW4gUkZDIGNvbXBsaWFudCB3YXkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSBTZWN0aW9uIDUuNy43IG9mIHRo aXMgZHJhZnQgZm9yIGhvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNtaXRoLTZtYW4tZm9ybS1mdW5jLWFueWNhc3QtYWRkcmVzc2VzLTAxI3NlY3Rpb24tNS43Ljci IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc21pdGgt Nm1hbi1mb3JtLWZ1bmMtYW55Y2FzdC1hZGRyZXNzZXMtMDEjc2VjdGlvbi01LjcuNzwvYT48YnI+ DQo8YnI+DQpSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NYXJrLjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIDI3IEp1bCAyMDIwLCAxOTowOCBWYXNpbGVua28gRWR1YXJkLCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5r by5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRmVybmFuZG8sPGJyPg0KSGVu Y2UgYWdhaW4sIGZvbGxvd2luZyB0aGUgbG9naWMgb2YgdGhpcyBkcmFmdCAodGhlIGxldmVsIG9m IGRldGFsaXphdGlvbiB0aGF0IHlvdSBoYXZlIGdpdmVuIHRvIDUuMSkgLSBtYXkgYmUgeW91IG5l ZWQgYWRkaXRpb25hbCBzZWN0aW9uIDUuMS54OiBMb2FkIEJhbGFuY2VyIGhhdmUgdG8gbG9vayBp bnRvIFRDUC9VRFAgcG9ydHMuIE1vcmVvdmVyLCBpdCBjb3VsZCBub3QgdHJ1c3QgJnF1b3Q7Rmxv dyBsYWJlbCZxdW90OyAtIGl0IGlzIG5vdCByZWxpYWJsZSBwcmFjdGljZQ0KIGZvciBMQi48YnI+ DQpPciBhbHRlcm5hdGl2ZWx5IHlvdSBjb3VsZCBzYXkgc29tZXRoaW5nIGFib3V0IExCIGluIHNl Y3Rpb24gNS4xLjIsIGJ1dCBiZWNhdXNlIGl0IGlzIGEgbGl0dGxlIHNwZWNpYWwgY2FzZSAtIG1h eSBiZSBiZXR0ZXIgdG8gaGF2ZSBzZXBhcmF0ZSA1LjEueDxicj4NCjxicj4NCkVkdWFyZDxicj4N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogdjZvcHMgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRmVybmFuZG8gR29udDxicj4NClNl bnQ6IDI2INC40Y7Qu9GPIDIwMjAg0LMuIDg6NDY8YnI+DQpUbzogSVB2NiBPcGVyYXRpb25zICZs dDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1nb250LXY2b3Bz LWlwdjYtZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQt Z29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVj dDogW3Y2b3BzXSBPcGVyYXRpb25hbCBJbXBsaWNhdGlvbnMgb2YgSVB2NiBQYWNrZXRzIHdpdGgg RXh0ZW5zaW9uIEhlYWRlcnMgKEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQpPGJyPg0KPGJyPg0KRm9s a3MsPGJyPg0KPGJyPg0KV2UgaGF2ZSBwb3N0ZWQgYSByZXYgb2Ygb3VyIElFVEYgSS1EICZxdW90 O09wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24g SGVhZGVycyZxdW90Oy48YnI+DQo8YnI+DQpUaGUgSS1EIGlzIGF2YWlsYWJsZSBhdDogPGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQt djZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhz LXBhY2tldC1kcm9wcy0wNC50eHQ8L2E+PGJyPg0KPGJyPg0KWW91ciBmZWVkYmFjayB3aWxsIGJl IGFwcHJlY2lhdGVkLjxicj4NCjxicj4NClRoYW5rcyE8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0K RmVybmFuZG88YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLSBGb3J3YXJkZWQg TWVzc2FnZSAtLS0tLS0tLTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3I8YnI+DQpkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQ8YnI+ DQpEYXRlOiBTYXQsIDI1IEp1bCAyMDIwIDIyOjI4OjUwIC0wNzAwPGJyPg0KRnJvbTogPGEgaHJl Zj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpUbzogRmVybmFuZG8gR29udCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZnb250QHNp Nm5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCBHZXJ0IERvZXJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpn ZXJ0QHNwYWNlLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmdlcnRAc3BhY2UubmV0PC9hPiZndDssIEdl b2ZmIEh1c3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpaEBhcG5pYy5uZXQiIHRhcmdldD0iX2Js YW5rIj5naWhAYXBuaWMubmV0PC9hPiZndDssDQogV2FycmVuIEt1bWFyaSAmbHQ7PGEgaHJlZj0i bWFpbHRvOndhcnJlbkBrdW1hcmkubmV0IiB0YXJnZXQ9Il9ibGFuayI+d2FycmVuQGt1bWFyaS5u ZXQ8L2E+Jmd0OywgTmljayBIaWxsaWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY2tAaW5leC5p ZSIgdGFyZ2V0PSJfYmxhbmsiPm5pY2tAaW5leC5pZTwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRy b3BzLTA0LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRmVybmFu ZG8gR29udCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFt ZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWdvbnQtdjZv cHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7MDQ8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IE9wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24g SGVhZGVyczxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMjAtMDctMjU8YnI+DQpHcm91cDom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxi cj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTU8YnI+DQpVUkw6 IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ29udC12Nm9wcy1p cHY2LWVocy1wYWNrZXQtZHJvcHMtMDQudHh0PC9hPjxicj4NClN0YXR1czogPGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29udC12Nm9wcy1pcHY2 LWVocy1wYWNrZXQtZHJvcHMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMvPC9hPjxi cj4NCkh0bWxpemVkOiA8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMtMDQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1w YWNrZXQtZHJvcHMtMDQ8L2E+PGJyPg0KSHRtbGl6ZWQ6IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1w YWNrZXQtZHJvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzPC9hPjxicj4N CkRpZmY6IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1nb250LXY2b3BzLWlwdjYt ZWhzLXBhY2tldC1kcm9wcy0wNDwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsg Jm5ic3A7IFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyB0aGUgc2VjdXJpdHkgYW5kIG9wZXJhdGlv bmFsIGltcGxpY2F0aW9ucyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgSVB2NiBleHRlbnNpb24gaGVh ZGVycywgYW5kIGF0dGVtcHRzIHRvIGFuYWx5emUgcmVhc29ucyB3aHkgcGFja2V0czxicj4NCiZu YnNwOyAmbmJzcDsgd2l0aCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIG1heSBiZSBkcm9wcGVkIGlu IHRoZSBwdWJsaWMgSW50ZXJuZXQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9h Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_e551a751cd7846bf8d15848e1d738875huaweicom_-- From nobody Mon Jul 27 02:56:17 2020 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 B52363A181D; Mon, 27 Jul 2020 02:56:15 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgNz4qK-eKtS; Mon, 27 Jul 2020 02:56:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6B3193A161E; Mon, 27 Jul 2020 02:56:14 -0700 (PDT) Received: from lhreml723-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 967B05E7EE64CE581432; Mon, 27 Jul 2020 10:56:12 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml723-chm.china.huawei.com (10.201.108.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 10:56:12 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:56:11 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 12:56:11 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - OAM Thread-Index: AdZj+M7rylVBEZ48S5ifVJiJzMekB///0ZqA///Ln6A= Date: Mon, 27 Jul 2020 09:56:11 +0000 Message-ID: <16647bab75e0466794ab711b960770fd@huawei.com> References: <556c9c3a-b8e5-eb3d-cecb-dfe66cf98ac2@si6networks.com> In-Reply-To: <556c9c3a-b8e5-eb3d-cecb-dfe66cf98ac2@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - OAM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:56:16 -0000 Hi Fernando, May be me misunderstood the point of the draft in 1st place. I do see it as a warning list for potential issues that admin should resear= ch a little deeper before he/she would enable some EHs. IMHO: You could be very brief about solutions (because draft could bloat to= the size on Internet), but the list of all issues to check should be more = or less full. Or it would be small value from the draft. IMHO. Eduard -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 12:46 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - OAM Eduard, On 27/7/20 06:30, Vasilenko Eduard wrote: > Hi Fernando, > The more messages I have sent to you - the less confident I am in the nex= t one comment, but anyway. ? > 1. All these new staff would need more OAM tools. May be such simple as "= ping for SRv6", may be much more complicated (is anything exist to ping BIE= R data plane?). Network Admin (or Planning department) should research what= is available for the tools that they have decided to activate. > 2. Some EH are not practical without proper OSS tools (example: iFit) > IMHO: it could be one additional section X (numbering in the root). > It is probably very relevant, because draft has "v6ops" in the middle of = the name. I'm not sure what's the point you are raising. Essentially, operators employ devices that need to access L-4 information f= or doing a bunch of things (EMCP, enforcing ACLs, etc.).=20 The structure of IPv6 packets makes accessing such information challenging.= In some cases, devices are unable to access such information. In other cas= es, they might be able to do so provided the packet goes through the slow-p= ath (all this depending, to some extent, on the EH-chain length). Ultimatel= y, in many of these cases (if not all), operators have no other option than= to drop the offending packets. This is a general issue of IPv6 EHs. Yes, depending on the tools you might need support for this or that. BUt ho= w does that change the discussion we're having in the document? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 03:01:11 2020 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 6011B3A1831; Mon, 27 Jul 2020 03:01:09 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tofbfcXr6Ap; Mon, 27 Jul 2020 03:01:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 153B43A182E; Mon, 27 Jul 2020 03:01:08 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E085331265BD37E8BE08; Mon, 27 Jul 2020 11:01:04 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 11:01:04 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 13:01:04 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 13:01:03 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency Thread-Index: AdZj9zFJtjveS0eYRluv5AthxXDk5f//0swA///H5tA= Date: Mon, 27 Jul 2020 10:01:03 +0000 Message-ID: References: <3f135d04-7db1-39fa-07ea-2da190f2665d@si6networks.com> In-Reply-To: <3f135d04-7db1-39fa-07ea-2da190f2665d@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:01:09 -0000 >> What would you expect us to cover in such section, other than what we al= ready cover in Section 5.1.1. (Packet Forwarding Engine Constraints)? It is better to move this story into separate section before security discu= ssion. Make this story visible. It is relevant not just to security. It is expenses - the biggest restriction in business. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 12:39 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - implementation-dependency Hello, Eduard, On 27/7/20 06:22, Vasilenko Eduard wrote: > Hi Fernando, You did mention "implementation-dependent" in security=20 > section. But majority of people would bypass security section on the=20 > 1st pass of reading your draft. Except security people, others would=20 > look to functionality 1st, them may be security (may be not:-(). > Hence, you almost ignore "implementation-dependency" in such a way=20 > (putting it into security section). Not sure what you mean... > I propose to introduce additional > 5.x, because (IMHO) "implementation-dependency" is the biggest problem=20 > in this draft - it is related to money/expenses (especially to replace=20 > hardware). It would be even bigger problem on next years with=20 > proliferation of SRv6, iFit, iOAM, BIERv6 and other abuses of > IPv6 headers extensibility. People need to check hardware (and > software) capability far in advance, or else could be negative=20 > surprise. What would you expect us to cover in such section, other than what we alrea= dy cover in Section 5.1.1. (Packet Forwarding Engine Constraints)? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 03:04:36 2020 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 588333A181A; Mon, 27 Jul 2020 03:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbm4iCa5w7Kz; Mon, 27 Jul 2020 03:04:33 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA7B3A1820; Mon, 27 Jul 2020 03:04:33 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E115D283893; Mon, 27 Jul 2020 10:04:29 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com> From: Fernando Gont Message-ID: <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com> Date: Mon, 27 Jul 2020 06:56:07 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <446331e9ebc84c88a9197a27b169710e@huawei.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:04:35 -0000 On 27/7/20 06:39, Vasilenko Eduard wrote: > Hi Fernando, > It is more important to have the problem mentioned on the list, then the quality of the section itself. I fail to understand what's the MTU problem you are referring to. the Path-MTU being reduced as a consequence of the use of EHs? something else? > It is definitely a problem if one would like to activate any EH - potential admin should be warned. > What could be inside: > - small discussion that fragmentation in the middle of IPv6 path is not possible > - some IPCMPv6 messages should not be filtered > - MTU is better to change on networking links That seems to be unrelated with this particular document. If anything, MTU issues are a problem to the folks at both endpoints of an application. But this documents is concern with the operational challenges represented by EHs. i.e., why operators need to deal with them. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 03:09:23 2020 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 B05DF3A183D; Mon, 27 Jul 2020 03:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z6PqnwRPrB1; Mon, 27 Jul 2020 03:09:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9633A1836; Mon, 27 Jul 2020 03:09:17 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1C87F2838A4; Mon, 27 Jul 2020 10:09:13 +0000 (UTC) To: Mark Smith , Vasilenko Eduard Cc: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: From: Fernando Gont Message-ID: <4e073ff7-5230-654a-ab5f-002a6644b65b@si6networks.com> Date: Mon, 27 Jul 2020 07:09:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:09:21 -0000 Hello, Mark, On 27/7/20 06:47, Mark Smith wrote: > > If load balancers are going to be discussed, it also needs to be pointed > out that they don't follow the definition of unicast addresses. Don't such addresses become anyast addresses, automatically, as per Section 2.6 of RFC4291? > A unicast address is to uniquely identify a single node. > > Load balancers share a single unicast address between multiple nodes, > contradictory to the unique and single node identification purpose of > unicast addresses. As per RFC4291, such addresses would be anycast addresses, rather than unicast. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 03:13:31 2020 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 4CD053A183D; Mon, 27 Jul 2020 03:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSdHZD7CsU6x; Mon, 27 Jul 2020 03:13:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6017D3A1836; Mon, 27 Jul 2020 03:13:27 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B37052838A4; Mon, 27 Jul 2020 10:13:19 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <3f135d04-7db1-39fa-07ea-2da190f2665d@si6networks.com> From: Fernando Gont Message-ID: <45f6f88e-0c8f-e049-69ea-0b26944247ae@si6networks.com> Date: Mon, 27 Jul 2020 07:13:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:13:29 -0000 On 27/7/20 07:01, Vasilenko Eduard wrote: >>> What would you expect us to cover in such section, other than what we already cover in Section 5.1.1. (Packet Forwarding Engine Constraints)? > It is better to move this story into separate section before security discussion. > Make this story visible. Point taken. We will try to discuss this stuff much earlier in the draft. Thanks! Cheers, Fernando -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 03:21:52 2020 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 EF0F63A183E; Mon, 27 Jul 2020 03:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGawOxOyRKgF; Mon, 27 Jul 2020 03:21:39 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEDC3A0D45; Mon, 27 Jul 2020 03:21:39 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id dk23so4619905ejb.11; Mon, 27 Jul 2020 03:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2sxkKdEOFzaq49yqRDETkn0hpFdE/iyQR7JykO5uLec=; b=fz0LZmjJNoMk8rH47yIf2+kUx/Z7UCUbAb6bR0BoCvhdYZpdD554tJMGYv1MyU7/+j yHsvkiUf6WXS6lO7iCl3igFa26AfRaujs+cdr8aVvjNNy9IUaP2v/lcACLzJCgqPNMBS oAOLadcYr5xwyex/9a56+b6Q8R3RtHR0rxlUvtIiRVXxA7zaq0gqFon9VtppQvYI0PrC GdtP7py45ooIyLTDXwnCZ6MbRCZR4H3C+gNNR1JA+eRB+Ny7rcCVSLj+7uZebwv0DqwS +7TtEMWZyTXNUaZzc3oGesU2AFeswJsWrnANhzLjKS+4Q1xqV1yNnu1EM+LvA1egChIW m5+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2sxkKdEOFzaq49yqRDETkn0hpFdE/iyQR7JykO5uLec=; b=OYZ4744RZ3Vl+TdAoA4MZRppQEYIKtL9Pj+EjkzTeuSbIGavCnZuIdLik6HNSY7VXS zgE6o0/nh1+WzSr2wCXw8Uu0a6D7xTsjLQO4T4mGNxxBR6srmB4h/SpeRsI5Ez3w7De0 kymFAOcF9r66quEd/cxXZoTz7/hOr/jrEwKh1nplp8qYMowum0Nkgy557469xFphHqe5 eHwRJZSYHqHyGmKe+Zwr5kMjlPsIL6Xd81nxDCZOJlpdeFuH+HxQ5V4ABrRtHgP9TWq3 dGkRxgOdQiL4ppLMP9OWEzPV8qMqcL61GJZsZqUJ7yTbdbvUXRhURCAXWF3yzF0MJqSD CpaA== X-Gm-Message-State: AOAM530C87TRzkSfRh1t4/CzYspB/TspoBnANxzu9vvl3Vj7M7dI3n3y sDy2MZ4RSG8kU2f09xh9MRn/AFkEduW3fS3Kt6U= X-Google-Smtp-Source: ABdhPJz7jMmxSX679/OEP7PMNcmVweG3FCjsJeTwGGJGl7S7W6rsQ7hSs1mkjMNjYoGnZJxLCallxodQwBXcmh1ezsY= X-Received: by 2002:a17:906:1756:: with SMTP id d22mr20277300eje.29.1595845297513; Mon, 27 Jul 2020 03:21:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Carpenter Date: Mon, 27 Jul 2020 22:21:26 +1200 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000132c1905ab69b017" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:21:49 -0000 --000000000000132c1905ab69b017 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why isn't the flow label reliable, now that it's set by the major client o/s? But I agree, server load balancing is severely broken if the balancer is incapable of parsing the header chain. That's a design error in the balancer. See RFC7098 for discussion. Regards Brian (via tiny screen & keyboard) On Mon, 27 Jul 2020, 21:08 Vasilenko Eduard, wrote: > Hi Fernando, > Hence again, following the logic of this draft (the level of detalization > that you have given to 5.1) - may be you need additional section 5.1.x: > Load Balancer have to look into TCP/UDP ports. Moreover, it could not tru= st > "Flow label" - it is not reliable practice for LB. > Or alternatively you could say something about LB in section 5.1.2, but > because it is a little special case - may be better to have separate 5.1.= x > > Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > To: IPv6 Operations > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: [v6ops] Operational Implications of IPv6 Packets with Extension > Headers (Fwd: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) > > Folks, > > We have posted a rev of our IETF I-D "Operational Implications of IPv6 > Packets with Extension Headers". > > The I-D is available at: > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > > Your feedback will be appreciated. > > Thanks! > > Cheers, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Date: Sat, 25 Jul 2020 22:28:50 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering , > Geoff Huston , Warren Kumari , Nick > Hilliard > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > has been successfully submitted by Fernando Gont and posted to the IETF > repository. > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > Revision: 04 > Title: Operational Implications of IPv6 Packets with Extension > Headers > Document date: 2020-07-25 > Group: Individual Submission > Pages: 15 > URL: > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-dr= ops > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drop= s-04 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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 > --000000000000132c1905ab69b017 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why isn't the flow label reliable, now that it&#= 39;s set by the major client o/s? But I agree, server load balancing is sev= erely broken if the balancer is incapable of parsing the header chain. That= 's a design error in the balancer. See RFC7098 for discussion.

<= div data-smartmail=3D"gmail_signature">Regards
=C2=A0=C2=A0=C2=A0 Brian<= br>=C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard)

On Mon, 27 Jul 2020,= 21:08 Vasilenko Eduard, <vasilenko.eduard@huawei.com> w= rote:
Hi Fernando,
Hence again, following the logic of this draft (the level of detalization t= hat you have given to 5.1) - may be you need additional section 5.1.x: Load= Balancer have to look into TCP/UDP ports. Moreover, it could not trust &qu= ot;Flow label" - it is not reliable practice for LB.
Or alternatively you could say something about LB in section 5.1.2, but bec= ause it is a little special case - may be better to have separate 5.1.x

Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of= Fernando Gont
Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46
To: IPv6 Operations <v6ops@ietf.org>
Cc: draft-gont-v6ops-ipv6-ehs-pack= et-drops@ietf.org
Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt)

Folks,

We have posted a rev of our IETF I-D "Operational Implications of IPv6= Packets with Extension Headers".

The I-D is available at:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt

Your feedback will be appreciated.

Thanks!

Cheers,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Date: Sat, 25 Jul 2020 22:28:50 -0700
From: internet-drafts@ietf.org
To: Fernando Gont <fgont@si6networks.com>, Gert Doe= ring <gert@space.net>, Geoff Huston <gih@apnic.ne= t>, Warren Kumari <warren@kumari.net>, Nick Hill= iard <nick@inex.ie>


A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
has been successfully submitted by Fernando Gont and posted to the IETF rep= ository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-v6ops-ipv6-ehs-pac= ket-drops
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operational Implications of IPv6 P= ackets with Extension Headers
Document date:=C2=A0 2020-07-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt
Status:
https:= //datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
Htmlized:
https://t= ools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
Htmlized:
ht= tps://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops<= /a>
Diff:
h= ttps://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-0= 4

Abstract:
=C2=A0 =C2=A0 This document summarizes the security and operational implica= tions of
=C2=A0 =C2=A0 IPv6 extension headers, and attempts to analyze reasons why p= ackets
=C2=A0 =C2=A0 with IPv6 extension headers may be dropped in the public Inte= rnet.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at to= ols.ietf.org.

The IETF Secretariat



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--000000000000132c1905ab69b017-- From nobody Mon Jul 27 03:24:45 2020 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 52DE73A1850; Mon, 27 Jul 2020 03:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plmvRPjbsizB; Mon, 27 Jul 2020 03:24:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C273A184D; Mon, 27 Jul 2020 03:24:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 06RAOS5N058895 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2020 11:24:29 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com> From: Nick Hilliard Message-ID: Date: Mon, 27 Jul 2020 11:24:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.24 MIME-Version: 1.0 In-Reply-To: <446331e9ebc84c88a9197a27b169710e@huawei.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:24:44 -0000 Eduard MTUs don't change the principal that EHs can be operationally troublesome, although there may be a minor impact in terms of scope. It's probably a good idea to touch on the subject in the draft, but I don't think it needs much more than a mention. Nick Vasilenko Eduard wrote on 27/07/2020 10:39: > Hi Fernando, > It is more important to have the problem mentioned on the list, then the quality of the section itself. > It is definitely a problem if one would like to activate any EH - potential admin should be warned. > What could be inside: > - small discussion that fragmentation in the middle of IPv6 path is not possible > - some IPCMPv6 messages should not be filtered > - MTU is better to change on networking links > In reality, I do not believe that it is difficult to compile this section, because so many materials on the IETF for this subject. > IMHO: it is very important to have this warning on the list. > > If you like, I could try to write this small section. Just this week is a little busy for me. > Eduard > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: 27 2020 . 12:18 > To: Vasilenko Eduard ; IPv6 Operations > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: Re: Operational Implications of IPv6 Packets with Extension Headers - MTU > > Hello, Edward, > > On 27/7/20 05:46, Vasilenko Eduard wrote: >> Hi Fernando, >> It is possible to search "MTU" in your draft. But I am surprised anyway how small attention (to this problem) is in your draft. >> IMHO: MTU deserves to be section 5.4 > > Could you please clarify what's the discussion you expect to see about the MTU? > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > From nobody Mon Jul 27 03:25:49 2020 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 8CC6C3A184A; Mon, 27 Jul 2020 03:25:47 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8fxkIGpV3qc; Mon, 27 Jul 2020 03:25:46 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1DB743A1850; Mon, 27 Jul 2020 03:25:36 -0700 (PDT) Received: from lhreml714-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B9C35C89FE7EAA2C1A7F; Mon, 27 Jul 2020 11:25:34 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 11:25:34 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 13:25:33 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 13:25:33 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - MTU Thread-Index: AdZj8f/Upo2wn+ELR6mdAuOglYKu+v//13aA///Jm1CAAEDwgP//xhQQ Date: Mon, 27 Jul 2020 10:25:33 +0000 Message-ID: References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com> <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com> In-Reply-To: <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:25:48 -0000 If User would lose connectivity Because additional EH increased packet size And packet would be dropped. Then it is the problem of Carrier. There are a lot of recommendation how to avoid drop that happen as a result= of bigger MTU demands. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 12:56 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - MTU On 27/7/20 06:39, Vasilenko Eduard wrote: > Hi Fernando, > It is more important to have the problem mentioned on the list, then the = quality of the section itself. I fail to understand what's the MTU problem you are referring to. the Path= -MTU being reduced as a consequence of the use of EHs? something else? > It is definitely a problem if one would like to activate any EH - potenti= al admin should be warned. > What could be inside: > - small discussion that fragmentation in the middle of IPv6 path is not p= ossible > - some IPCMPv6 messages should not be filtered > - MTU is better to change on networking links That seems to be unrelated with this particular document. If anything,=20 MTU issues are a problem to the folks at both endpoints of an application. But this documents is concern with the operational challenges=20 represented by EHs. i.e., why operators need to deal with them. Thanks, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 03:31:18 2020 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 DDB583A185B; Mon, 27 Jul 2020 03:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOTx_FbjkejV; Mon, 27 Jul 2020 03:31:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 96F673A185A; Mon, 27 Jul 2020 03:31:14 -0700 (PDT) Received: from lhreml730-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EB702B2CC7B8BBC87214; Mon, 27 Jul 2020 11:31:12 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 11:31:12 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 13:31:11 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 13:31:11 +0300 From: Vasilenko Eduard To: Brian Carpenter CC: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AdZj9Efrgvrnr0hITbeSprlQeXLX0///5IMA///LU7A= Date: Mon, 27 Jul 2020 10:31:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: multipart/alternative; boundary="_000_d234e38e9c6a4b1f9a20e7c6d181f203huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:31:17 -0000 --_000_d234e38e9c6a4b1f9a20e7c6d181f203huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQpJdCBpcyBub3QgdGVjaG5vbG9neSBwcm9ibGVtIC0gTm8gYWRkaXRpb25hbCBz dGFuZGFyZCBpcyBuZWVkZWQuDQpKdXN0IGlmIHNvbWVib2R5IHdvdWxkIHVzZSDigJxmbG93IGxh YmVs4oCdIG5vdCBwcm9wZXJseSDigJMgTEIgc2hvdWxkIHN0aWxsIGRlbGl2ZXIgZXhwZWN0ZWQg cmVzdWx0cy4gSGVuY2UsIGl0IHNob3VsZCBwYXJzZSBMNCBhbnl3YXkuDQpFZHVhcmQNCkZyb206 IEJyaWFuIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NClNl bnQ6IDI3INC40Y7Qu9GPIDIwMjAg0LMuIDEzOjIxDQpUbzogVmFzaWxlbmtvIEVkdWFyZCA8dmFz aWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPg0KQ2M6IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5l dHdvcmtzLmNvbT47IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyBkcmFmdC1nb250 LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9w c10gT3BlcmF0aW9uYWwgSW1wbGljYXRpb25zIG9mIElQdjYgUGFja2V0cyB3aXRoIEV4dGVuc2lv biBIZWFkZXJzIC0gTG9hZCBCYWxhbmNlcg0KDQpXaHkgaXNuJ3QgdGhlIGZsb3cgbGFiZWwgcmVs aWFibGUsIG5vdyB0aGF0IGl0J3Mgc2V0IGJ5IHRoZSBtYWpvciBjbGllbnQgby9zPyBCdXQgSSBh Z3JlZSwgc2VydmVyIGxvYWQgYmFsYW5jaW5nIGlzIHNldmVyZWx5IGJyb2tlbiBpZiB0aGUgYmFs YW5jZXIgaXMgaW5jYXBhYmxlIG9mIHBhcnNpbmcgdGhlIGhlYWRlciBjaGFpbi4gVGhhdCdzIGEg ZGVzaWduIGVycm9yIGluIHRoZSBiYWxhbmNlci4gU2VlIFJGQzcwOTggZm9yIGRpc2N1c3Npb24u DQpSZWdhcmRzDQogICAgQnJpYW4NCiAgICAodmlhIHRpbnkgc2NyZWVuICYga2V5Ym9hcmQpDQoN Ck9uIE1vbiwgMjcgSnVsIDIwMjAsIDIxOjA4IFZhc2lsZW5rbyBFZHVhcmQsIDx2YXNpbGVua28u ZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4+IHdy b3RlOg0KSGkgRmVybmFuZG8sDQpIZW5jZSBhZ2FpbiwgZm9sbG93aW5nIHRoZSBsb2dpYyBvZiB0 aGlzIGRyYWZ0ICh0aGUgbGV2ZWwgb2YgZGV0YWxpemF0aW9uIHRoYXQgeW91IGhhdmUgZ2l2ZW4g dG8gNS4xKSAtIG1heSBiZSB5b3UgbmVlZCBhZGRpdGlvbmFsIHNlY3Rpb24gNS4xLng6IExvYWQg QmFsYW5jZXIgaGF2ZSB0byBsb29rIGludG8gVENQL1VEUCBwb3J0cy4gTW9yZW92ZXIsIGl0IGNv dWxkIG5vdCB0cnVzdCAiRmxvdyBsYWJlbCIgLSBpdCBpcyBub3QgcmVsaWFibGUgcHJhY3RpY2Ug Zm9yIExCLg0KT3IgYWx0ZXJuYXRpdmVseSB5b3UgY291bGQgc2F5IHNvbWV0aGluZyBhYm91dCBM QiBpbiBzZWN0aW9uIDUuMS4yLCBidXQgYmVjYXVzZSBpdCBpcyBhIGxpdHRsZSBzcGVjaWFsIGNh c2UgLSBtYXkgYmUgYmV0dGVyIHRvIGhhdmUgc2VwYXJhdGUgNS4xLngNCg0KRWR1YXJkDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEZl cm5hbmRvIEdvbnQNClNlbnQ6IDI2INC40Y7Qu9GPIDIwMjAg0LMuIDg6NDYNClRvOiBJUHY2IE9w ZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpDYzogZHJh ZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogW3Y2 b3BzXSBPcGVyYXRpb25hbCBJbXBsaWNhdGlvbnMgb2YgSVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5z aW9uIEhlYWRlcnMgKEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nb250 LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQpDQoNCkZvbGtzLA0KDQpXZSBoYXZl IHBvc3RlZCBhIHJldiBvZiBvdXIgSUVURiBJLUQgIk9wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBv ZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24gSGVhZGVycyIuDQoNClRoZSBJLUQgaXMgYXZh aWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdv bnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0LnR4dA0KDQpZb3VyIGZlZWRiYWNrIHdp bGwgYmUgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcyENCg0KQ2hlZXJzLA0KRmVybmFuZG8NCg0KDQoN Cg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRy b3BzLTA0LnR4dA0KRGF0ZTogU2F0LCAyNSBKdWwgMjAyMCAyMjoyODo1MCAtMDcwMA0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ DQpUbzogRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBz aTZuZXR3b3Jrcy5jb20+PiwgR2VydCBEb2VyaW5nIDxnZXJ0QHNwYWNlLm5ldDxtYWlsdG86Z2Vy dEBzcGFjZS5uZXQ+PiwgR2VvZmYgSHVzdG9uIDxnaWhAYXBuaWMubmV0PG1haWx0bzpnaWhAYXBu aWMubmV0Pj4sIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PG1haWx0bzp3YXJyZW5A a3VtYXJpLm5ldD4+LCBOaWNrIEhpbGxpYXJkIDxuaWNrQGluZXguaWU8bWFpbHRvOm5pY2tAaW5l eC5pZT4+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1l aHMtcGFja2V0LWRyb3BzLTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBGZXJuYW5kbyBHb250IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICAgICAgIGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzDQpSZXZp c2lvbjogICAgICAgMDQNClRpdGxlOiAgICAgICAgICBPcGVyYXRpb25hbCBJbXBsaWNhdGlvbnMg b2YgSVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5zaW9uIEhlYWRlcnMNCkRvY3VtZW50IGRhdGU6ICAy MDIwLTA3LTI1DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczog ICAgICAgICAgMTUNClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQNClN0YXR1czoNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMt cGFja2V0LWRyb3BzLw0KSHRtbGl6ZWQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMtMDQNCkh0bWxpemVkOg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhz LXBhY2tldC1kcm9wcw0KRGlmZjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNA0KDQpBYnN0cmFjdDoNCiAg ICBUaGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgdGhlIHNlY3VyaXR5IGFuZCBvcGVyYXRpb25hbCBp bXBsaWNhdGlvbnMgb2YNCiAgICBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzLCBhbmQgYXR0ZW1wdHMg dG8gYW5hbHl6ZSByZWFzb25zIHdoeSBwYWNrZXRzDQogICAgd2l0aCBJUHY2IGV4dGVuc2lvbiBo ZWFkZXJzIG1heSBiZSBkcm9wcGVkIGluIHRoZSBwdWJsaWMgSW50ZXJuZXQuDQoNCg0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFp bHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5n IGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== --_000_d234e38e9c6a4b1f9a20e7c6d181f203huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SXQgaXMgbm90IHRlY2hub2xvZ3kgcHJvYmxlbSAtIE5vIGFkZGl0aW9uYWwgc3Rh bmRhcmQgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGlmIHNvbWVib2R5IHdvdWxk IHVzZSDigJxmbG93IGxhYmVs4oCdIG5vdCBwcm9wZXJseSDigJMgTEIgc2hvdWxkIHN0aWxsIGRl bGl2ZXIgZXhwZWN0ZWQgcmVzdWx0cy4gSGVuY2UsIGl0IHNob3VsZCBwYXJzZSBMNCBhbnl3YXku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEJyaWFuIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNyDQuNGO0LvRjyAyMDIwINCzLiAxMzoyMTxicj4N CjxiPlRvOjwvYj4gVmFzaWxlbmtvIEVkdWFyZCAmbHQ7dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWku Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRmVybmFuZG8gR29udCAmbHQ7ZmdvbnRAc2k2bmV0d29y a3MuY29tJmd0OzsgSVB2NiBPcGVyYXRpb25zICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRyYWZ0 LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIE9wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tl dHMgd2l0aCBFeHRlbnNpb24gSGVhZGVycyAtIExvYWQgQmFsYW5jZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5XaHkgaXNuJ3QgdGhlIGZsb3cgbGFiZWwgcmVsaWFibGUsIG5vdyB0aGF0IGl0J3Mgc2V0IGJ5 IHRoZSBtYWpvciBjbGllbnQgby9zPyBCdXQgSSBhZ3JlZSwgc2VydmVyIGxvYWQgYmFsYW5jaW5n IGlzIHNldmVyZWx5IGJyb2tlbiBpZiB0aGUgYmFsYW5jZXIgaXMgaW5jYXBhYmxlIG9mIHBhcnNp bmcgdGhlIGhlYWRlciBjaGFpbi4gVGhhdCdzIGEgZGVzaWduIGVycm9yDQogaW4gdGhlIGJhbGFu Y2VyLiBTZWUgUkZDNzA5OCBmb3IgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEJyaWFu PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICh2aWEgdGlueSBzY3JlZW4gJmFtcDsga2V5Ym9hcmQp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIDI3 IEp1bCAyMDIwLCAyMTowOCBWYXNpbGVua28gRWR1YXJkLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZh c2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVh cmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRmVybmFuZG8sPGJyPg0KSGVuY2UgYWdh aW4sIGZvbGxvd2luZyB0aGUgbG9naWMgb2YgdGhpcyBkcmFmdCAodGhlIGxldmVsIG9mIGRldGFs aXphdGlvbiB0aGF0IHlvdSBoYXZlIGdpdmVuIHRvIDUuMSkgLSBtYXkgYmUgeW91IG5lZWQgYWRk aXRpb25hbCBzZWN0aW9uIDUuMS54OiBMb2FkIEJhbGFuY2VyIGhhdmUgdG8gbG9vayBpbnRvIFRD UC9VRFAgcG9ydHMuIE1vcmVvdmVyLCBpdCBjb3VsZCBub3QgdHJ1c3QgJnF1b3Q7RmxvdyBsYWJl bCZxdW90OyAtIGl0IGlzIG5vdCByZWxpYWJsZSBwcmFjdGljZQ0KIGZvciBMQi48YnI+DQpPciBh bHRlcm5hdGl2ZWx5IHlvdSBjb3VsZCBzYXkgc29tZXRoaW5nIGFib3V0IExCIGluIHNlY3Rpb24g NS4xLjIsIGJ1dCBiZWNhdXNlIGl0IGlzIGEgbGl0dGxlIHNwZWNpYWwgY2FzZSAtIG1heSBiZSBi ZXR0ZXIgdG8gaGF2ZSBzZXBhcmF0ZSA1LjEueDxicj4NCjxicj4NCkVkdWFyZDxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogdjZvcHMgW21haWx0bzo8YSBocmVmPSJt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRmVybmFuZG8gR29udDxicj4NClNlbnQ6IDI2 INC40Y7Qu9GPIDIwMjAg0LMuIDg6NDY8YnI+DQpUbzogSVB2NiBPcGVyYXRpb25zICZsdDs8YSBo cmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1nb250LXY2b3BzLWlwdjYt ZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtZ29udC12 Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW3Y2 b3BzXSBPcGVyYXRpb25hbCBJbXBsaWNhdGlvbnMgb2YgSVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5z aW9uIEhlYWRlcnMgKEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nb250 LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQpPGJyPg0KPGJyPg0KRm9sa3MsPGJy Pg0KPGJyPg0KV2UgaGF2ZSBwb3N0ZWQgYSByZXYgb2Ygb3VyIElFVEYgSS1EICZxdW90O09wZXJh dGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24gSGVhZGVy cyZxdW90Oy48YnI+DQo8YnI+DQpUaGUgSS1EIGlzIGF2YWlsYWJsZSBhdDogPGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQtdjZvcHMt aXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tl dC1kcm9wcy0wNC50eHQ8L2E+PGJyPg0KPGJyPg0KWW91ciBmZWVkYmFjayB3aWxsIGJlIGFwcHJl Y2lhdGVkLjxicj4NCjxicj4NClRoYW5rcyE8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KRmVybmFu ZG88YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2Fn ZSAtLS0tLS0tLTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+ DQpkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQ8YnI+DQpEYXRl OiBTYXQsIDI1IEp1bCAyMDIwIDIyOjI4OjUwIC0wNzAwPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpUbzogRmVybmFuZG8gR29udCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZnb250QHNpNm5ldHdv cmtzLmNvbTwvYT4mZ3Q7LCBHZXJ0IERvZXJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpnZXJ0QHNw YWNlLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmdlcnRAc3BhY2UubmV0PC9hPiZndDssIEdlb2ZmIEh1 c3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpaEBhcG5pYy5uZXQiIHRhcmdldD0iX2JsYW5rIj5n aWhAYXBuaWMubmV0PC9hPiZndDssDQogV2FycmVuIEt1bWFyaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OndhcnJlbkBrdW1hcmkubmV0IiB0YXJnZXQ9Il9ibGFuayI+d2FycmVuQGt1bWFyaS5uZXQ8L2E+ Jmd0OywgTmljayBIaWxsaWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY2tAaW5leC5pZSIgdGFy Z2V0PSJfYmxhbmsiPm5pY2tAaW5leC5pZTwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0 LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRmVybmFuZG8gR29u dCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWdvbnQtdjZvcHMtaXB2 Ni1laHMtcGFja2V0LWRyb3BzPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7MDQ8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9wZXJh dGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24gSGVhZGVy czxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMjAtMDctMjU8YnI+DQpHcm91cDombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBh Z2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTU8YnI+DQpVUkw6IDxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250 LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVo cy1wYWNrZXQtZHJvcHMtMDQudHh0PC9hPjxicj4NClN0YXR1czogPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1w YWNrZXQtZHJvcHMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMvPC9hPjxicj4NCkh0 bWxpemVkOiA8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMtMDQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQt ZHJvcHMtMDQ8L2E+PGJyPg0KSHRtbGl6ZWQ6IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQt ZHJvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzPC9hPjxicj4NCkRpZmY6 IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1n b250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBh Y2tldC1kcm9wcy0wNDwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7 IFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyB0aGUgc2VjdXJpdHkgYW5kIG9wZXJhdGlvbmFsIGlt cGxpY2F0aW9ucyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgSVB2NiBleHRlbnNpb24gaGVhZGVycywg YW5kIGF0dGVtcHRzIHRvIGFuYWx5emUgcmVhc29ucyB3aHkgcGFja2V0czxicj4NCiZuYnNwOyAm bmJzcDsgd2l0aCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIG1heSBiZSBkcm9wcGVkIGluIHRoZSBw dWJsaWMgSW50ZXJuZXQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29s cy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9w cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_d234e38e9c6a4b1f9a20e7c6d181f203huaweicom_-- From nobody Mon Jul 27 03:47:26 2020 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 AE7623A187B; Mon, 27 Jul 2020 03:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK8mUkc8bpoW; Mon, 27 Jul 2020 03:47:23 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6473A1854; Mon, 27 Jul 2020 03:47:22 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef] (unknown [IPv6:2800:810:464:1f7:4ccc:6def:a83b:96ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2947C280CE7; Mon, 27 Jul 2020 10:47:17 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <556c9c3a-b8e5-eb3d-cecb-dfe66cf98ac2@si6networks.com> <16647bab75e0466794ab711b960770fd@huawei.com> From: Fernando Gont Message-ID: <2a4e0970-f2f2-710b-6081-fbf7e9085285@si6networks.com> Date: Mon, 27 Jul 2020 07:17:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <16647bab75e0466794ab711b960770fd@huawei.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - OAM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 10:47:25 -0000 On 27/7/20 06:56, Vasilenko Eduard wrote: > Hi Fernando, > May be me misunderstood the point of the draft in 1st place. > I do see it as a warning list for potential issues that admin should research a little deeper before he/she would enable some EHs. Nope. What this document tries to do is to shed some light into why packets with EHs are largely dropped in the public Internet. And essentially it notes that in many cases operators don't have many other options. RFC7872 (as well as other studies referenced in our draft) have provided data about the extent to which packets with EHs are dropped in the public Internet. And this document elaborates on the operational reality that many operators have not much of a choce than resorting to dropping them. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 04:03:51 2020 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 4FC713A18AB; Mon, 27 Jul 2020 04:03:50 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5nhI8zvgaeD; Mon, 27 Jul 2020 04:03:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 430DC3A18A8; Mon, 27 Jul 2020 04:03:47 -0700 (PDT) Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C5749EE009058043554D; Mon, 27 Jul 2020 12:03:45 +0100 (IST) Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 12:03:45 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 14:03:44 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 14:03:44 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations CC: "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: Operational Implications of IPv6 Packets with Extension Headers - OAM Thread-Index: AdZj+M7rylVBEZ48S5ifVJiJzMekB///0ZqA///Ln6CAAD0bgP//weaA Date: Mon, 27 Jul 2020 11:03:44 +0000 Message-ID: References: <556c9c3a-b8e5-eb3d-cecb-dfe66cf98ac2@si6networks.com> <16647bab75e0466794ab711b960770fd@huawei.com> <2a4e0970-f2f2-710b-6081-fbf7e9085285@si6networks.com> In-Reply-To: <2a4e0970-f2f2-710b-6081-fbf7e9085285@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.200.156] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - OAM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 11:03:51 -0000 Hi Fernando, Then may be OAM is out of the scope (for this draft). It is definitely not the reason for a drop itself, But It may be needed to investigate drop reason. If "drop reason" is not needed to be investigated ... Eduard -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com]=20 Sent: 27 =C9=C0=CC=D1 2020 =C7. 13:17 To: Vasilenko Eduard ; IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: Re: Operational Implications of IPv6 Packets with Extension Header= s - OAM On 27/7/20 06:56, Vasilenko Eduard wrote: > Hi Fernando, > May be me misunderstood the point of the draft in 1st place. > I do see it as a warning list for potential issues that admin should rese= arch a little deeper before he/she would enable some EHs. Nope. What this document tries to do is to shed some light into why packets with = EHs are largely dropped in the public Internet. And essentially it notes that in many cases operators don't have many other= options. RFC7872 (as well as other studies referenced in our draft) have provided da= ta about the extent to which packets with EHs are dropped in the public Int= ernet. And this document elaborates on the operational reality that many operators= have not much of a choce than resorting to dropping them. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 27 07:15:13 2020 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 BA0D53A19BD for ; Mon, 27 Jul 2020 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SqB_iRLA8xI for ; Mon, 27 Jul 2020 07:15:08 -0700 (PDT) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467CB3A0EB9 for ; Mon, 27 Jul 2020 07:15:08 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id c15so2602988edj.3 for ; Mon, 27 Jul 2020 07:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C3aTXNZ8oSfS7c0q5tkE9OuXubDMsdzCDpHwBKKNj70=; b=mK6I4P18kmW0hxnhcXsRTGQDtDfJB9WrI+lSHqP7rXIdqCXUGpejeIyEWATZjLeEME 6SHx9YMyOPj1zh3mekb1lxM8rjUi1gHvZ5FZhGHixi0CrpDbvt5ukd6bGhSeRlqpMRsl ej1vxXkIo8kqfp6kNMPBzTingZvJwO2U/OtspeKiocQ362UEfM9SCD7/VUMRpcu8PJB1 ZjVmMbU2jnuNDwzYsTe0eJgwqhIzdKfSTAifcjO/AunvuF4SkI2u1VQVRKuuLh+MfUJa nWpcl3aVq4m35M6KJYcV2Fh4eEGMCqcWFZX9HgvkUPXXlqHYlwU1ptYKl5G98ZDrre1r ZXfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C3aTXNZ8oSfS7c0q5tkE9OuXubDMsdzCDpHwBKKNj70=; b=QC3IVheqk5XiRFNk2AFEoU4KFNC4lHSe3id/A4uDfPG505IQturc+EcAZoYryWnFec m5JRsRzI4vpSFOn0jpCQkha/+o7fn/fw4rIYyasDLBkV84Kk1Ed1ec+FR2o1u7YBGyCM 0n9/wxvxnvYl5MPHAGJCyUFQRK0QTph4nxSljazrCNM84mWbMtZNJgUDurkE0b3Sgqp2 DoGerWESVBjBn6R3shtaar9k1M+xtrbhiuwBoJpHEkEbcc+zwgVPFoOmw57fFzHfT1FD DYLllFVM26NxNImAPrJlX/4zpVi7Y75PLPozFDGSK3tuLGvz6Drm69vHdWqRFDJMjQu4 32qQ== X-Gm-Message-State: AOAM533xFMviWCk8NKjCiwEE5BVucI4zo+GvhV6Efbq1gZzSaY76twp2 XcsgUH3hZYAWj2H+/0nEkpfkVVfgBk9o3xsBPYj3Cw== X-Google-Smtp-Source: ABdhPJw4rkklI1tLTH5ESb3aQTWx/Svrshe7C1dNxK4EWhh3ROzaRoQ9adYsgS4U45GOkNVWMU0FfUsVsLhj5pt6ZtM= X-Received: by 2002:a50:cfc6:: with SMTP id i6mr5612198edk.88.1595859306206; Mon, 27 Jul 2020 07:15:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 27 Jul 2020 07:14:55 -0700 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 14:15:11 -0000 On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard wrote: > > Hi Fernando, > Hence again, following the logic of this draft (the level of detalization= that you have given to 5.1) - may be you need additional section 5.1.x: Lo= ad Balancer have to look into TCP/UDP ports. Moreover, it could not trust "= Flow label" - it is not reliable practice for LB. Eduard, What exactly does "not reliable practice for LB" mean.? If this means that the flow label might change during the flow's lifetime then I will point out that UDP is equally unreliable for that reason (i.e. the UDP ports for a QUIC connection can change during the connection's lifetime). For that matter, a TCP header might be encrypted or in an encapsulation that the LB doesn't understand so the LB can't access the TCP ports at all-- in the this case the flow label is actually more reliable than TCP since it's never encrypted and is purposely designed to be consumed by intermediate nodes without the need for expensive DPI. Tom > Or alternatively you could say something about LB in section 5.1.2, but b= ecause it is a little special case - may be better to have separate 5.1.x > > Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > To: IPv6 Operations > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: [v6ops] Operational Implications of IPv6 Packets with Extension = Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet= -drops-04.txt) > > Folks, > > We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pa= ckets with Extension Headers". > > The I-D is available at: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > > Your feedback will be appreciated. > > Thanks! > > Cheers, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Date: Sat, 25 Jul 2020 22:28:50 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering ,= Geoff Huston , Warren Kumari , Nick Hill= iard > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > has been successfully submitted by Fernando Gont and posted to the IETF r= epository. > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > Revision: 04 > Title: Operational Implications of IPv6 Packets with Extension H= eaders > Document date: 2020-07-25 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-dr= ops > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drop= s-04 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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 nobody Mon Jul 27 07:39:41 2020 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 14A9E3A1DB5 for ; Mon, 27 Jul 2020 07:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtpRUGdhN1RB for ; Mon, 27 Jul 2020 07:39:32 -0700 (PDT) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AD03A2170 for ; Mon, 27 Jul 2020 07:36:35 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id d6so3485828ejr.5 for ; Mon, 27 Jul 2020 07:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=X7Wi19RqcHJequXKL7m6dmXIERvuwS5qxD7WAUsDtwc=; b=awlk8v770Gt1SXM0Fz/OWJXaxv3DWGoZmojgJKRjQS7WWm4+4Ia8M6tR09ZhxKcYZD BCf1iufPthuRVRfarAYmhACUF+Nq2tCQvOMvNXVSPlh3fY5sq0BGr4yOi99PHO8AYw7d 0/nQQfKCuREzP3dSBd+Urf9LzaVT46Ad91oiwzgO8ux3vFlwhqaSrajwrQQlqOJ7104p L4gz2hpGt2x53+eUO8iV3aFE2E5yD8OkD+U07BeQnhixygqGQ4Lv2pwnTMkRVPtcRCNu lskh11wcdLcKt3GmzsRYx56O1lwWWrmOtRUXKOAVe7eI4YrraPMDc2gZsm7jkc3enNhx YzhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X7Wi19RqcHJequXKL7m6dmXIERvuwS5qxD7WAUsDtwc=; b=LGw4dz885PIULRtOkeqcCyeK9AeyUyjK/3Thdh+kwZ89PhjCTGDgGtyYiqHYlFfwTt aOEzF4Ow3J0WimvYCJ1kvTd8lkSKYs6JE939qr/Jg0Q1W/+gldLZ4Ycm2YOJqY1XThup WkknNJz6+wvhllMLtOWuE7avIOWSUVfazDALkHGqeyargDpfvyiFAporVX89rkvUAEK+ Po32kl8qEdCHnlpzNcYUFxlxp1tGbVZvG70YenVEUWLN4pfiVe+gcNNP10pT9+9j0it8 tt27o7RgTAcoz6Dg0BmiRSOzwojgowIrjeF/ouptI4T82c+OOe1EE2T8tkwDnXILyrsx m2jQ== X-Gm-Message-State: AOAM533YRJnEotUQCK6EuoHb5oBgrBS/7FuLIJ8m41fHOPSL0S+20DRq hpVtMtslLyJt5KytDKcx0yFhSbdZZR65LtfDE0LxVDVj X-Google-Smtp-Source: ABdhPJzbfeDXdCm93FjokM1ElHBZ3d+QbyPBOIRNTnvIQvk1n0qBGkTHLqM1UW+Bc4LqGGiMKMmniAedT9pRoLS8tts= X-Received: by 2002:a17:906:b146:: with SMTP id bt6mr21228570ejb.138.1595860594346; Mon, 27 Jul 2020 07:36:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 27 Jul 2020 07:36:23 -0700 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 14:39:40 -0000 On Mon, Jul 27, 2020 at 1:57 AM Vasilenko Eduard wrote: > > Hi Fernando, > Security is sometimes functionality, not vulnerability or attack vector. = The good example is Firewall. Firewall needs to parse all headers to be use= ful. > Hence, I believe it is in the logic of this draft to have section 5.1.5: = one additional "use case" when parsing of ALL headers are mandatory. FW, ID= PS Eduard, I would love to see the firewall device that is capable of processing ALL protocol headers in the IETF protocol suite! Reality is that firewalls can only process what they are programmed to process which is typically a very small subset of the possible protocols a host might want to use. The effect of this model is protocol ossification since firewalls drop anything that they don't understand even if the protocols are otherwise useful to the host endpoints. EH is one victim of protocol ossification in this regard, but it's not the only the one. For instance QUIC and any future transport protocols will encrypt as much as the packet as possible expressly for the purpose of avoiding ossification of these protocols by middleboxes. Tom > Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > To: IPv6 Operations > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: [v6ops] Operational Implications of IPv6 Packets with Extension = Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet= -drops-04.txt) > > Folks, > > We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pa= ckets with Extension Headers". > > The I-D is available at: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > > Your feedback will be appreciated. > > Thanks! > > Cheers, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Date: Sat, 25 Jul 2020 22:28:50 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering ,= Geoff Huston , Warren Kumari , Nick Hill= iard > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > has been successfully submitted by Fernando Gont and posted to the IETF r= epository. > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > Revision: 04 > Title: Operational Implications of IPv6 Packets with Extension H= eaders > Document date: 2020-07-25 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-dr= ops > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drop= s-04 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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 nobody Mon Jul 27 08:25:31 2020 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 C19E53A1A4A; Mon, 27 Jul 2020 08:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhjNbWtSr57z; Mon, 27 Jul 2020 08:25:26 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 14C813A1721; Mon, 27 Jul 2020 08:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bfrC65OnSto5vkMwlGnlUa23okq3RRwutzbB6c9H5uA=; b=ZBNc3VOtGgMpfLhj9ajJm0GPD NnF9wStvpw4vBVVYrABy1/UdOUIK4E9/g8iINBC3+qEz9jmwTdpJyWn8pVxhznS7V2KUVXVwilw/Q QCMTu8L2aCvlYzVnwAqQdcpO3rMZ6FAyXsaUQIiHsJ5Q6gmqSp7pgKbX/YsVHfXXTAwagMoyFvCOL F7au8Ab4n3/Fdt/UI49z5VlbQGZUCHOp8Ar1G61Aaa267rmXfSwXQDgYOIxilQWdEG5fq9cWJE4s3 fULA+/gTpd/OwMrC5DNGvB4d+QmPLazfOkwIX/TgrbKlagT5L2xNaaElF1qjGlGwQgE/xLywgIql0 1rgexYqsw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59099 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k04zX-004KT9-UG; Mon, 27 Jul 2020 11:24:44 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Mon, 27 Jul 2020 08:24:39 -0700 Cc: Vasilenko Eduard , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Herbert X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 15:25:28 -0000 > On Jul 27, 2020, at 7:36 AM, Tom Herbert wrote: >=20 > On Mon, Jul 27, 2020 at 1:57 AM Vasilenko Eduard > wrote: >>=20 >> Hi Fernando, >> Security is sometimes functionality, not vulnerability or attack = vector. The good example is Firewall. Firewall needs to parse all = headers to be useful. >> Hence, I believe it is in the logic of this draft to have section = 5.1.5: one additional "use case" when parsing of ALL headers are = mandatory. FW, IDPS >=20 > Eduard, >=20 > I would love to see the firewall device that is capable of processing > ALL protocol headers in the IETF protocol suite! Reality is that > firewalls can only process what they are programmed to process =E2=80=A6= . A firewall NEEDS to balance protection with functionality. I.e., a trivial firewall drops all packets. That=E2=80=99s 100% = protection but 0% utility. Dropping unknown headers protects against unknown attacks, but is not = needed to protect against known ones. I wonder whether most firewalls would provide sufficiently similar = protection with increased utility by passing unknown options rather than = blocking them. Joe=20= From nobody Mon Jul 27 09:03:32 2020 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 0F70E3A1B47 for ; Mon, 27 Jul 2020 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3UOAkhqpHI9 for ; Mon, 27 Jul 2020 09:03:19 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BB23A1ABF for ; Mon, 27 Jul 2020 09:03:17 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id kq25so4672365ejb.3 for ; Mon, 27 Jul 2020 09:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4HWMPNmTT8APIVV1fMPztbGKD0QeG8aAmF0n53udmWo=; b=QySNDHq4mqGv60U1jSRKWVPil1Jtm3fiED3VZIxpWgQppcVzxoS/FvwR44rI1ZhA8f 6Nk8JXKlWYZwOxaPoN1nfE39cUI26nH/XmX+6bh1l07TF7oQF5cffble4MPuO+Azg1nu c/kYj+PgFmRZz1ko/Wv49yVYT7TbQhbBy8wgZRiob+zANzi0SLrEgUrOgPxG34iThmpJ 0RT/CR6RpWDJx682DcqCPC3ipV3lQNiJorw1zXRYDsN97xXZdRjydxD2TJjH5RHD/6OU eaAzB8M8pakg2jYlvpBKdrN33nPstuxeNoyjCWLUYICbK47xnx9035NJ0E9bA2qO8pGM RFjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4HWMPNmTT8APIVV1fMPztbGKD0QeG8aAmF0n53udmWo=; b=IqTjSncB3LsHoDH0Mh2AYUHt6QPCtN/0Z60nOr+vC+1HP0g6L3oeRPg4oJKOCzQx9k DkoAVt0LfLL4lo9JKVQwxwN/M5cFFFPJkM9qNuDnv4pOfmT8HW5YhLfKdDpOqnQwFt4j cjOE4s2OpQzlCns/GiJEngRgjCg5yRLv3OJTsDhWR7BXsoxRHlpAS4PMKM7Amx10duJf FoNm1kFcuyN8ECGcx5oU3DJyfPEqDuAFitp9B0bQzlnOGRmmQRfAs1ogR1NMoVmRjsTD cAU755bMArPwleJsF3VtZy1Bplr8mRjLID4hWPIQbFepoQlqmfwfvSJXqSAW038jD45s MFZA== X-Gm-Message-State: AOAM532fnhk7K3TdhxLSMhGLXpytfjfGJj8BsW1eQAgg6jgXL/Pznajb 7D++5dgFMFb/SEuiD0UYvt+sOTWV9O1Sz/ugbHmiOQ== X-Google-Smtp-Source: ABdhPJx4GZVKc0KEAIVC+hZcWHEXcj2uW47QfR2yg/QDNsV0Guvd6sX8cWcSbdfwQKSJAJEqDRFDHl5WumbXnBOSnTI= X-Received: by 2002:a17:907:104a:: with SMTP id oy10mr15092594ejb.267.1595865796352; Mon, 27 Jul 2020 09:03:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Mon, 27 Jul 2020 09:03:05 -0700 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implementation-dependency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 16:03:29 -0000 On Mon, Jul 27, 2020 at 2:22 AM Vasilenko Eduard wrote: > > Hi Fernando, > You did mention "implementation-dependent" in security section. But major= ity of people would bypass security section on the 1st pass of reading your= draft. > Except security people, others would look to functionality 1st, them may = be security (may be not:-(). Hence, you almost ignore "implementation-depen= dency" in such a way (putting it into security section). > I propose to introduce additional 5.x, because (IMHO) "implementation-dep= endency" is the biggest problem in this draft - it is related to money/expe= nses (especially to replace hardware). > It would be even bigger problem on next years with proliferation of SRv6,= iFit, iOAM, BIERv6 and other abuses of IPv6 headers extensibility. I really hope by " abuses of IPv6 headers extensibility" you meant " uses of IPv6 headers extensibility". > People need to check hardware (and software) capability far in advance, o= r else could be negative surprise. Warn them. Within several IETF working groups we have been pointing out all the issues around these "negative surprises" for several years, like middebox protocol non-conformance and ossification (see discussions about extension headers, discussions about IP fragmentation, discussion about using alternative transport protocols, and wider use of encryption). Instead of just warning people that things probably won't work, can vendors fix these problems? For instance, RFC8200 allows intermediate nodes to ignore HBH EH. Has this been implemented by router vendors in lieu of dropping packets with or relegating them so some slow path that basically renders them useless? Tom > Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > To: IPv6 Operations > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: [v6ops] Operational Implications of IPv6 Packets with Extension = Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet= -drops-04.txt) > > Folks, > > We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pa= ckets with Extension Headers". > > The I-D is available at: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > > Your feedback will be appreciated. > > Thanks! > > Cheers, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > Date: Sat, 25 Jul 2020 22:28:50 -0700 > From: internet-drafts@ietf.org > To: Fernando Gont , Gert Doering ,= Geoff Huston , Warren Kumari , Nick Hill= iard > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > has been successfully submitted by Fernando Gont and posted to the IETF r= epository. > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > Revision: 04 > Title: Operational Implications of IPv6 Packets with Extension H= eaders > Document date: 2020-07-25 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-dro= ps-04.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-dr= ops > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drop= s-04 > > Abstract: > This document summarizes the security and operational implications of > IPv6 extension headers, and attempts to analyze reasons why packets > with IPv6 extension headers may be dropped in the public Internet. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > 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 nobody Mon Jul 27 10:14:25 2020 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 238923A1AD9 for ; Mon, 27 Jul 2020 10:14:24 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFyFr-ouc9QH for ; Mon, 27 Jul 2020 10:14:22 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 536763A1ADB for ; Mon, 27 Jul 2020 10:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1595870062; x=1627406062; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sQKQ9+iJh3+OmZsqU3bnLSq7COuSAOwnHIjbqTUz6GI=; b=Cp5G2l43k1emjwu4BttVTZQdVhk4APt843SfRaC3r7497Scxldp5ARH0 ykzm9K1BEC1ifc5T/VZtK5cl3MN5I23KGc32uoJQZY1Md27nscThuwTN/ yFxhXcfEnZhfyevGiYXHX58So3p6S6giZcHYJQiNVwfndRWdMP2groKJt IxThln0+7PEWYrLU9Zd0QeaN0yaJI09OdX+aN2ecc3HxgfhDhp54rPynd XWE+COW4kNiFgITrJiVgFeAKd1nioaZ4VNtKeU2EgUPmJ6Em+JVxkn0NT rHDX+ATSjwUhRNlEhIn8jNqQEDGvOw6rZNGIvDUD4kpx6GHQxM6xSebYc g==; IronPort-SDR: v856mOx0b/6mI/+pxq4QTnSe5M0YRcvrrSsBbcwWMlbLjT3EVnW6mYykXbLXF6U/zcGrcWgpHU clvbpYbtg3wfnhAH7VNcAle1RMazT58QIj6P+lnJANuSp9KAO7mTHg8IfznE+8lsb/dI/joqAZ wu0jQnZWNBVEq2lRiVFFOkMkEb4caqEQo3rQo+t6x3gCJJ2s+quuXmvExdpd12ZxoluMQbLRjd ALd+RirH0GP4K/uqiBokg+RHPNdy9UM05R4UCH+Vfra+qbNY04F1ouEWmVI33Tt5OHGJcSoDYi tSY= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2020 19:14:16 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 04B2941C04 for ; Mon, 27 Jul 2020 19:14:16 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B8F1541B91; Mon, 27 Jul 2020 19:14:15 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id B3F2A151CB; Mon, 27 Jul 2020 19:14:15 +0200 (CEST) Date: Mon, 27 Jul 2020 19:14:15 +0200 From: Gert Doering To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Message-ID: <20200727171415.GJ2485@Space.Net> References: <678838bf6f0549689268a571498332d1@huawei.com> <9e9bf619-28fe-7238-6d62-53d5a814935a@si6networks.com> <446331e9ebc84c88a9197a27b169710e@huawei.com> <62bddb45-a88b-48f1-ff78-ea587e6ef75e@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - MTU X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 17:14:24 -0000 Hi, On Mon, Jul 27, 2020 at 10:25:33AM +0000, Vasilenko Eduard wrote: > If User would lose connectivity > Because additional EH increased packet size > And packet would be dropped. > Then it is the problem of Carrier. > > There are a lot of recommendation how to avoid drop that happen as a result of bigger MTU demands. MTU issues (and any other sort of IPv6 misconfiguration at the end systems) are out of scope of this documents. There are many reasons why an end system would want to send a packet that is too big, and EH-or-not does not make a material difference to "application requests too-big UDP packet" (like, DNS). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Jul 27 11:05:51 2020 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 734643A1B7E; Mon, 27 Jul 2020 11:05:49 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mlT2nLOGxWg; Mon, 27 Jul 2020 11:05:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 54D1E3A1CFE; Mon, 27 Jul 2020 11:05:20 -0700 (PDT) Received: from lhreml711-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BDF5AADCF141CD3596F1; Mon, 27 Jul 2020 19:05:17 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 19:05:17 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Jul 2020 21:05:16 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 27 Jul 2020 21:05:16 +0300 From: Vasilenko Eduard To: Tom Herbert CC: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AQHWZCBNgvrnr0hITbeSprlQeXLX06kbuR9A Date: Mon, 27 Jul 2020 18:05:16 +0000 Message-ID: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.199.194] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 18:05:50 -0000 SGkgVG9tLA0KSSBiZWxpZXZlIHRoYXQgcmlzayBzdGlsbCBleGlzdCB0aGF0IHNvbWUgYXBwbGlj YXRpb24gd291bGQgbm8gdXNlIGZsb3cgbGFiZWwgcHJvcGVybHkuDQpIZW5jZSwgaXQgaXMgYmV0 dGVyIG9uIExCIHRvIGRlZXAgZGl2ZSBpbnRvIFVEUC9UQ1AuIE1vcmUgcHJlZGljdGFibGUvcmVs aWFibGUgcmVzdWx0Lg0KRWR1YXJkDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog VG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXSANClNlbnQ6IDI3INC40Y7Q u9GPIDIwMjAg0LMuIDE3OjE1DQpUbzogVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFy ZEBodWF3ZWkuY29tPg0KQ2M6IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT47 IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyBkcmFmdC1nb250LXY2b3BzLWlwdjYt ZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gT3BlcmF0aW9u YWwgSW1wbGljYXRpb25zIG9mIElQdjYgUGFja2V0cyB3aXRoIEV4dGVuc2lvbiBIZWFkZXJzIC0g TG9hZCBCYWxhbmNlcg0KDQpPbiBNb24sIEp1bCAyNywgMjAyMCBhdCAyOjA4IEFNIFZhc2lsZW5r byBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+IEhpIEZl cm5hbmRvLA0KPiBIZW5jZSBhZ2FpbiwgZm9sbG93aW5nIHRoZSBsb2dpYyBvZiB0aGlzIGRyYWZ0 ICh0aGUgbGV2ZWwgb2YgZGV0YWxpemF0aW9uIHRoYXQgeW91IGhhdmUgZ2l2ZW4gdG8gNS4xKSAt IG1heSBiZSB5b3UgbmVlZCBhZGRpdGlvbmFsIHNlY3Rpb24gNS4xLng6IExvYWQgQmFsYW5jZXIg aGF2ZSB0byBsb29rIGludG8gVENQL1VEUCBwb3J0cy4gTW9yZW92ZXIsIGl0IGNvdWxkIG5vdCB0 cnVzdCAiRmxvdyBsYWJlbCIgLSBpdCBpcyBub3QgcmVsaWFibGUgcHJhY3RpY2UgZm9yIExCLg0K DQpFZHVhcmQsDQoNCldoYXQgZXhhY3RseSBkb2VzICJub3QgcmVsaWFibGUgcHJhY3RpY2UgZm9y IExCIiBtZWFuLj8gSWYgdGhpcyBtZWFucyB0aGF0IHRoZSBmbG93IGxhYmVsIG1pZ2h0IGNoYW5n ZSBkdXJpbmcgdGhlIGZsb3cncyBsaWZldGltZSB0aGVuIEkgd2lsbCBwb2ludCBvdXQgdGhhdCBV RFAgaXMgZXF1YWxseSB1bnJlbGlhYmxlIGZvciB0aGF0IHJlYXNvbiAoaS5lLg0KdGhlIFVEUCBw b3J0cyBmb3IgYSBRVUlDIGNvbm5lY3Rpb24gY2FuIGNoYW5nZSBkdXJpbmcgdGhlIGNvbm5lY3Rp b24ncyBsaWZldGltZSkuIEZvciB0aGF0IG1hdHRlciwgYSBUQ1AgaGVhZGVyIG1pZ2h0IGJlIGVu Y3J5cHRlZCBvciBpbiBhbiBlbmNhcHN1bGF0aW9uIHRoYXQgdGhlIExCIGRvZXNuJ3QgdW5kZXJz dGFuZCBzbyB0aGUgTEIgY2FuJ3QgYWNjZXNzIHRoZSBUQ1AgcG9ydHMgYXQgYWxsLS0gaW4gdGhl IHRoaXMgY2FzZSB0aGUgZmxvdyBsYWJlbCBpcyBhY3R1YWxseSBtb3JlIHJlbGlhYmxlIHRoYW4g VENQIHNpbmNlIGl0J3MgbmV2ZXIgZW5jcnlwdGVkIGFuZCBpcyBwdXJwb3NlbHkgZGVzaWduZWQg dG8gYmUgY29uc3VtZWQgYnkgaW50ZXJtZWRpYXRlIG5vZGVzIHdpdGhvdXQgdGhlIG5lZWQgZm9y IGV4cGVuc2l2ZSBEUEkuDQoNClRvbQ0KPiBPciBhbHRlcm5hdGl2ZWx5IHlvdSBjb3VsZCBzYXkg c29tZXRoaW5nIGFib3V0IExCIGluIHNlY3Rpb24gNS4xLjIsIA0KPiBidXQgYmVjYXVzZSBpdCBp cyBhIGxpdHRsZSBzcGVjaWFsIGNhc2UgLSBtYXkgYmUgYmV0dGVyIHRvIGhhdmUgDQo+IHNlcGFy YXRlIDUuMS54DQo+DQo+IEVkdWFyZA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBG ZXJuYW5kbyBHb250DQo+IFNlbnQ6IDI2INC40Y7Qu9GPIDIwMjAg0LMuIDg6NDYNCj4gVG86IElQ djYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1nb250LXY2b3BzLWlw djYtZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdjZvcHNdIE9wZXJhdGlv bmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCANCj4gRXh0ZW5zaW9uIEhlYWRl cnMgKEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtZ29udC12Nm9w cy1pcHY2LWVocy1wYWNrZXQtZHJvcHMtMDQudHh0KQ0KPg0KPiBGb2xrcywNCj4NCj4gV2UgaGF2 ZSBwb3N0ZWQgYSByZXYgb2Ygb3VyIElFVEYgSS1EICJPcGVyYXRpb25hbCBJbXBsaWNhdGlvbnMg b2YgSVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5zaW9uIEhlYWRlcnMiLg0KPg0KPiBUaGUgSS1EIGlz IGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LQ0KPiBkcm9wcy0wNC50eHQNCj4NCj4gWW91 ciBmZWVkYmFjayB3aWxsIGJlIGFwcHJlY2lhdGVkLg0KPg0KPiBUaGFua3MhDQo+DQo+IENoZWVy cywNCj4gRmVybmFuZG8NCj4NCj4NCj4NCj4NCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2Ug LS0tLS0tLS0NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFm dC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcy0wNC50eHQNCj4gRGF0ZTogU2F0LCAy NSBKdWwgMjAyMCAyMjoyODo1MCAtMDcwMA0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcNCj4gVG86IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4sIEdlcnQgRG9l cmluZyANCj4gPGdlcnRAc3BhY2UubmV0PiwgR2VvZmYgSHVzdG9uIDxnaWhAYXBuaWMubmV0Piwg V2FycmVuIEt1bWFyaSANCj4gPHdhcnJlbkBrdW1hcmkubmV0PiwgTmljayBIaWxsaWFyZCA8bmlj a0BpbmV4LmllPg0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ29udC12Nm9w cy1pcHY2LWVocy1wYWNrZXQtZHJvcHMtMDQudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgRmVybmFuZG8gR29udCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQo+DQo+IE5hbWU6ICAgICAgICAgICBkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tl dC1kcm9wcw0KPiBSZXZpc2lvbjogICAgICAgMDQNCj4gVGl0bGU6ICAgICAgICAgIE9wZXJhdGlv bmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNpb24gSGVhZGVycw0K PiBEb2N1bWVudCBkYXRlOiAgMjAyMC0wNy0yNQ0KPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgICAgICAxNQ0KPiBVUkw6DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tl dC0NCj4gZHJvcHMtMDQudHh0DQo+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcA0KPiBzLw0KPiBI dG1saXplZDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMt aXB2Ni1laHMtcGFja2V0LWRyb3BzLTA0DQo+IEh0bWxpemVkOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0DQo+ IC1kcm9wcw0KPiBEaWZmOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvDQo+IHBzLTA0DQo+DQo+IEFic3RyYWN0 Og0KPiAgICAgVGhpcyBkb2N1bWVudCBzdW1tYXJpemVzIHRoZSBzZWN1cml0eSBhbmQgb3BlcmF0 aW9uYWwgaW1wbGljYXRpb25zIG9mDQo+ICAgICBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzLCBhbmQg YXR0ZW1wdHMgdG8gYW5hbHl6ZSByZWFzb25zIHdoeSBwYWNrZXRzDQo+ICAgICB3aXRoIElQdjYg ZXh0ZW5zaW9uIGhlYWRlcnMgbWF5IGJlIGRyb3BwZWQgaW4gdGhlIHB1YmxpYyBJbnRlcm5ldC4N Cj4NCj4NCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPiBUaGUg SUVURiBTZWNyZXRhcmlhdA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Mon Jul 27 12:23:59 2020 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 0F6863A0B34 for ; Mon, 27 Jul 2020 12:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Y0dvX80FFi for ; Mon, 27 Jul 2020 12:23:53 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3F33A0B32 for ; Mon, 27 Jul 2020 12:23:52 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id kq25so5263780ejb.3 for ; Mon, 27 Jul 2020 12:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/XtRS7aumB+6lTFzaAv+6+nrKqvByt+LZbb9S5hcMFA=; b=d+wzNcZ3YF2X/Pe4UvaS6Ojqmlpb+T98iDQqeI1/2F4/wNejHmoo/CXxf28qG4InhN 0IZi7PbpKiJyH3qwgYy4SRK4cR6u8RfpBx88hKuXK3vDVzXHjcWLJ+luk3uYVcHqWfdP irFCsGfAAqpPRnQ9svTOJNPs2OKp3T2TXx/XxsLUpvXKDD+l3uXLsMV3QeKx3eG0l2LA co5t21NXIO15j2L3cLVIMkMSsw7eb4s9ejj7ORIv32EfN6DGaSt+Vh//wy8otKAbyk+z G/XpFa7s8VjzdHGjaEi4JBZFrfwOhlW1+yywXPiL4Xo3E6MuQiiDUcfZvpSW4hm3nzeM yEvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/XtRS7aumB+6lTFzaAv+6+nrKqvByt+LZbb9S5hcMFA=; b=oPGx+pnPeZKWJFQOZKA8yZKngp25CoxH6A48FDqcXu687gEuExGK0ibIZcewUztiDh RAV5GhqOhf2sTQGPT1Nm2anJv+l8gCm8iVRtCYOl4r1d4VKyDtqBpD9XWMrltt7n8ny3 prbC6zpLlygOF12FCBYrCSZ3XEKrlpNE2ZGsBcGJO/sVhH4p9FFtwGY6+GJX6I9y/xZ9 o2Cy7cWfY/jSXpFFmrBm1bCAL64Gs1DyQgoXYR4JZgyRgxVs5PSykeRf7EbfY2e42ZnI ifUjhMHUS88DWZ0YcGs9Ey6ppoJCebrhmPsLett8bvdadMZkE7PWUol7ILuctCScNME4 EWyw== X-Gm-Message-State: AOAM531/9VXNs3BRCm4PWGRpeJmzxH4GUoBJ/CiblSmBUfmd7J4XL/d1 68s0sGRn8fZKHsWGoYhHfPm0pYlF9d2Wp0Xcfz6kfw== X-Google-Smtp-Source: ABdhPJxK/fuOPCDmjiD0cbYsBLh5LilRZWUUIbWmL7r+dwFiJ91R3SgJGSQ/8y2BcdB30bWKVlW9hGNcV/04z7WWmq4= X-Received: by 2002:a17:906:fac1:: with SMTP id lu1mr23462399ejb.427.1595877830917; Mon, 27 Jul 2020 12:23:50 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> In-Reply-To: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> From: Tom Herbert Date: Mon, 27 Jul 2020 12:23:39 -0700 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 19:23:56 -0000 On Mon, Jul 27, 2020 at 11:05 AM Vasilenko Eduard wrote: > > Hi Tom, > I believe that risk still exist that some application would no use flow l= abel properly. Exactly which applications are you concerned about? > Hence, it is better on LB to deep dive into UDP/TCP. More predictable/rel= iable result. You seem to be assuming a very limited traffic profile that consists only of plain UDP/TCP packets. Any use case that deviates from that then breaks your LB (i.e. encapsulation, tunneled encryption, SCTP, IPSec, etc.). Flow label is in all IPv6 packets and is mostly set properly for the vast majority of packets on the Internet and processing it is completely independent of the protocols, so when taking the full scope of the problem into account it is actually more generic and more predictable/reliable. Tom > Eduard > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 17:15 > To: Vasilenko Eduard > Cc: Fernando Gont ; IPv6 Operations ; draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extens= ion Headers - Load Balancer > > On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard wrote: > > > > Hi Fernando, > > Hence again, following the logic of this draft (the level of detalizati= on that you have given to 5.1) - may be you need additional section 5.1.x: = Load Balancer have to look into TCP/UDP ports. Moreover, it could not trust= "Flow label" - it is not reliable practice for LB. > > Eduard, > > What exactly does "not reliable practice for LB" mean.? If this means tha= t the flow label might change during the flow's lifetime then I will point = out that UDP is equally unreliable for that reason (i.e. > the UDP ports for a QUIC connection can change during the connection's li= fetime). For that matter, a TCP header might be encrypted or in an encapsul= ation that the LB doesn't understand so the LB can't access the TCP ports a= t all-- in the this case the flow label is actually more reliable than TCP = since it's never encrypted and is purposely designed to be consumed by inte= rmediate nodes without the need for expensive DPI. > > Tom > > Or alternatively you could say something about LB in section 5.1.2, > > but because it is a little special case - may be better to have > > separate 5.1.x > > > > Eduard > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont > > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > > To: IPv6 Operations > > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > > Subject: [v6ops] Operational Implications of IPv6 Packets with > > Extension Headers (Fwd: New Version Notification for > > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) > > > > Folks, > > > > We have posted a rev of our IETF I-D "Operational Implications of IPv6 = Packets with Extension Headers". > > > > The I-D is available at: > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet- > > drops-04.txt > > > > Your feedback will be appreciated. > > > > Thanks! > > > > Cheers, > > Fernando > > > > > > > > > > -------- Forwarded Message -------- > > Subject: New Version Notification for > > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > > Date: Sat, 25 Jul 2020 22:28:50 -0700 > > From: internet-drafts@ietf.org > > To: Fernando Gont , Gert Doering > > , Geoff Huston , Warren Kumari > > , Nick Hilliard > > > > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > > has been successfully submitted by Fernando Gont and posted to the IETF= repository. > > > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > > Revision: 04 > > Title: Operational Implications of IPv6 Packets with Extension= Headers > > Document date: 2020-07-25 > > Group: Individual Submission > > Pages: 15 > > URL: > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet- > > drops-04.txt > > Status: > > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drop > > s/ > > Htmlized: > > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet > > -drops > > Diff: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-dr= o > > ps-04 > > > > Abstract: > > This document summarizes the security and operational implications = of > > IPv6 extension headers, and attempts to analyze reasons why packets > > with IPv6 extension headers may be dropped in the public Internet. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > 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 nobody Mon Jul 27 13:52:09 2020 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 A4F723A0407 for ; Mon, 27 Jul 2020 13:51:58 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0gWPcC4OTqp for ; Mon, 27 Jul 2020 13:51:55 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422893A07E8 for ; Mon, 27 Jul 2020 13:51:55 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id n5so10622128pgf.7 for ; Mon, 27 Jul 2020 13:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=0dxXAScwMazYaXVgKlZSpqrE9IaQ3D2b0AWSCdXxmIQ=; b=qRKQUtAkUJlAvGD6S3Y12mQvBl/oTcaI+uOsid3eGIVhvYhzmRowWEcUTbfqKobAop r7gaDC2o9fZz8nzKd4aiyuUMZA2IVf7c7iBajyBxNc82bH4yDAnbNEVXz2vTgk92MkR1 Bkc5x5recYNHn7pFurvYiNrZJDgUG+ObY1Lmkw6kob49SKSzSEZjM9qehQLVZ+JtOm0s OzC2ugZwAF6+3or3iKs0QfZ+yoEa3wLgbqRfResQsHzkV1tPP1yVR+iyyI85+yHH/DCd 5AgF3oR2zVfDiK9/4qhW5FZDTv3LJL2t6eVKoXStt7Pn/Jrgz8c1rwG11KGxcwHTkSVb KY7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0dxXAScwMazYaXVgKlZSpqrE9IaQ3D2b0AWSCdXxmIQ=; b=Qf8NowLaSES0lL3NIFpCpRlJ+oZsMX76YDF9mtedhlHnZ2sCMtMN7dnMXfc6EOzjl6 Rr68MK+JJaunKukrg7H2KeSaRRrNFvMOeFoaoMyrjMmF6glr79iRlJrcoEdqLtu5+RzD aL0C9S1+/asMFNRY20lDWRqIF8NlUckavyJljnTnOA7SLwWvJV09QV8mjxk9m2EO2dfw YFWptUcVPxxfkZfYx8lFF1UemkL37CYm8kp0f9TRrQ26IjlCxpU6+BefMUR60aplPI9w wUVwIEDi60wtWiSkluPpsN0EEkcLJpkzBAVnynQnVC1SwgotA6iub6ZOK1xzFfJlg8NJ ZB1w== X-Gm-Message-State: AOAM532mtTPZ/xrjb7AnwyAxQj0MKY5c1x+4tWS6YJogCincx424zfXd VPek0sgjzGgCTQeo91PqjtDY7VlD X-Google-Smtp-Source: ABdhPJxvyD0MSlwCPlu5iqSS9DfBdEKBQuCJGbR4ccbobeoDSICU013Hxez9g7B5fsCaD96ghOZtSw== X-Received: by 2002:a65:6086:: with SMTP id t6mr20731424pgu.342.1595883113985; Mon, 27 Jul 2020 13:51:53 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id nk22sm476363pjb.51.2020.07.27.13.51.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 13:51:53 -0700 (PDT) To: Fernando Gont , IPv6 Operations References: <159574132870.611.12077598721404194383@ietfa.amsl.com> <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> From: Brian E Carpenter Message-ID: <53a8e94d-dfc3-23f9-2dac-b70eb4f203a8@gmail.com> Date: Tue, 28 Jul 2020 08:51:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 20:51:59 -0000 On 27-Jul-20 18:49, Fernando Gont wrote: > On 26/7/20 19:14, Brian E Carpenter wrote: >> Hi, >> >> IMHO this is useful work. >> >>> A number of recent RFCs have discussed issues related to IPv6 extension headers, >> >> I suggest to add RFC7045 to the bullet list, and delete the reference to it >> in the previous paragraph. In fact, the structure of the "Previous Work" >> section is a bit strange, with a prose paragraph followed by a bullet list. >> Maybe restructure that (e.g. transform it into a single longer bullet list)? > > That's a good point. > > I wonder if we could somehow separate: > * Std work that has become incorporated into the core spec. > > * Other Std work that affects EHs but hasn't been incorporated into the > core spec (e.g., RFC6980) Sure, if binary separation is really possible. > BTW... it seems that RFC7045 has not really been incorporated into > RFC8200? Well, yes and no. Firstly the point about HbH header processing being essentially optional was adopted. Similarly, RFC7045 says "This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future." and that, I believe, is reflected in RFC8200. The other new thing in RFC7045 was the IANA restructuring of https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml That was not moved into RFC8200, and IANA still uses RFC7045 as the primary reference. So I think it's appropriate that RFC8200 doesn't obsolete RFC7045. You are correct that it is still relevant, but I'm not sure there is any need for RFC7045bis. We could have a long discussion about refactoring the IPv6 document set in some way, but I'm not sure there's any value in that either. Frequent updates of "Node Requirements" is another thing we could discuss... > I mean, other work (e.g. RFC6946 has been incorporated into > RFC8200, and currently their raison d'etre is mostly for the reader to > find additional information -- but from the pov of RFC8200 is not really > necessary to read RFC6946). OTOH, it would seem that RFC7045 still > applies to RFC8200 in the very same way it applies/applied to RFC2460? > So in a way it should be in the bulleted list, but otoh it doesn't seem > to have been incorporated into RFC8200 -- while it still applies to it? > > > Modulo RFC6980 (and RFC7045), it would seem that the first para (prose) > could also be arranged as a set of bullets, noting something along the > lines of "documents that discuss operational implications of EHs"? Yes. > And I guess we could also arrange the measurements stuff (last para) in > their own set of bullets? A uniform structure would certainly be easier to read. Regards Brian From nobody Mon Jul 27 14:01:29 2020 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 D7DF23A0475; Mon, 27 Jul 2020 14:01: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8oB6tD_53OW; Mon, 27 Jul 2020 14:01:24 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BFC3A044E; Mon, 27 Jul 2020 14:01:24 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id 74so1503588pfx.13; Mon, 27 Jul 2020 14:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M0ZkQaq91+SjFOwp/9LTVOJhEA03k0egab4MeQ+TrsM=; b=GLksJB42onbSJd2tUlgtHCMZWqHlxaN4E6HaAW+wCodl7VYXHNYKmQpQTPotsoUGz6 vQyjwF/h5SWz/HNKEzBNBRTTA4t+mOupUn1ThfCGQaScYUmJ4xIkOs8yb6OUkvZThQnn UogcuWTuFF4XlTVSo3GXmJcxXdgvxgk/PMsw8X/lVY85RtQcqIoEbFf5RqCdVXuI/468 L+xbi4TyesUU/iEOFMsLrsWhwIaSGLt/2F39nMXJM1R9Ga3Wmgpf6uuYQPzK5ibPM+cL rweT52RheWh2MfN/fitIS5/bVKMDTqfYefTvephZ2Z1whkKV7pizhDOJUMugaobxF3GC 4swQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M0ZkQaq91+SjFOwp/9LTVOJhEA03k0egab4MeQ+TrsM=; b=H5rMagdauDOQEcGgwUFyhd6FvrXFl5hWMo5a+IFM5/MiWe03cRl1cvCDFRd4kMMCxI QQOUDbPftLnOUw5TsBN++sTvOsuImFjFgiXi6HJ1L5w4d7avovoeWNg3kmb0OTgMcaof U8+H+4QH1gZll+VOpnCqgtegSvJqrU6GxHOFz42j2Jk65XeNxQUq07KOttmvrn4xDEIb hcv/l38FwQSpHU6DVuINVxqUlFGbwVoPfXSCKb4qXLH/MtxQpOQo0J8L5fmm8SdtkTVW 0aKJtiAyIp/75W3XIp8klYMJEuyKRxWxuoEhEVqfbGRTU7YVhSjcIUm2YeYUYGwkzIzt nckg== X-Gm-Message-State: AOAM532mXN9hfBcz5ztPG5BavgvsQPAKXsjnHD9N1wrUEFkiGL+8uyuu XyfjChMs0905gfcpZ65GYc/Yl9jO X-Google-Smtp-Source: ABdhPJxpvpCacN6Ghki4kXFCSzpmfvfJwjiHmA9cpu2g/TzWWhzdSxl3PEgNPYsy4Nqzv6+5x5xOOQ== X-Received: by 2002:a65:6150:: with SMTP id o16mr20993952pgv.237.1595883683283; Mon, 27 Jul 2020 14:01:23 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id q10sm3188864pfs.75.2020.07.27.14.01.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 14:01:21 -0700 (PDT) To: Tom Herbert , Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> From: Brian E Carpenter Message-ID: Date: Tue, 28 Jul 2020 09:01:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 21:01:27 -0000 On 28-Jul-20 07:23, Tom Herbert wrote: > On Mon, Jul 27, 2020 at 11:05 AM Vasilenko Eduard > wrote: >> >> Hi Tom, >> I believe that risk still exist that some application would no use flo= w label properly. >=20 > Exactly which applications are you concerned about? Given that the most widespread socket APIs (POSIX and WinSock) do not all= ow an application to set the flow label, I too have that question. And again: please read RFC7098 where these issues are discussed in some depth. If that RFC is now out of date due to changing reality (such as TLS 1.3), please let us know. Brian >=20 >> Hence, it is better on LB to deep dive into UDP/TCP. More predictable/= reliable result. >=20 > You seem to be assuming a very limited traffic profile that consists > only of plain UDP/TCP packets. Any use case that deviates from that > then breaks your LB (i.e. encapsulation, tunneled encryption, SCTP, > IPSec, etc.). Flow label is in all IPv6 packets and is mostly set > properly for the vast majority of packets on the Internet and > processing it is completely independent of the protocols, so when > taking the full scope of the problem into account it is actually more > generic and more predictable/reliable. >=20 > Tom >=20 >> Eduard >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 17:15 >> To: Vasilenko Eduard >> Cc: Fernando Gont ; IPv6 Operations ; draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org >> Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Ext= ension Headers - Load Balancer >> >> On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard wrote: >>> >>> Hi Fernando, >>> Hence again, following the logic of this draft (the level of detaliza= tion that you have given to 5.1) - may be you need additional section 5.1= =2Ex: Load Balancer have to look into TCP/UDP ports. Moreover, it could n= ot trust "Flow label" - it is not reliable practice for LB. >> >> Eduard, >> >> What exactly does "not reliable practice for LB" mean.? If this means = that the flow label might change during the flow's lifetime then I will p= oint out that UDP is equally unreliable for that reason (i.e. >> the UDP ports for a QUIC connection can change during the connection's= lifetime). For that matter, a TCP header might be encrypted or in an enc= apsulation that the LB doesn't understand so the LB can't access the TCP = ports at all-- in the this case the flow label is actually more reliable = than TCP since it's never encrypted and is purposely designed to be consu= med by intermediate nodes without the need for expensive DPI. >> >> Tom >>> Or alternatively you could say something about LB in section 5.1.2, >>> but because it is a little special case - may be better to have >>> separate 5.1.x >>> >>> Eduard >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gon= t >>> Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 >>> To: IPv6 Operations >>> Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org >>> Subject: [v6ops] Operational Implications of IPv6 Packets with >>> Extension Headers (Fwd: New Version Notification for >>> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) >>> >>> Folks, >>> >>> We have posted a rev of our IETF I-D "Operational Implications of IPv= 6 Packets with Extension Headers". >>> >>> The I-D is available at: >>> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet= - >>> drops-04.txt >>> >>> Your feedback will be appreciated. >>> >>> Thanks! >>> >>> Cheers, >>> Fernando >>> >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt >>> Date: Sat, 25 Jul 2020 22:28:50 -0700 >>> From: internet-drafts@ietf.org >>> To: Fernando Gont , Gert Doering >>> , Geoff Huston , Warren Kumari >>> , Nick Hilliard >>> >>> >>> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt >>> has been successfully submitted by Fernando Gont and posted to the IE= TF repository. >>> >>> Name: draft-gont-v6ops-ipv6-ehs-packet-drops >>> Revision: 04 >>> Title: Operational Implications of IPv6 Packets with Extensi= on Headers >>> Document date: 2020-07-25 >>> Group: Individual Submission >>> Pages: 15 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet= - >>> drops-04.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-dro= p >>> s/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04= >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packe= t >>> -drops >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-= dro >>> ps-04 >>> >>> Abstract: >>> This document summarizes the security and operational implication= s of >>> IPv6 extension headers, and attempts to analyze reasons why packe= ts >>> with IPv6 extension headers may be dropped in the public Internet= =2E >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission until the htmlized version and diff are available at tools.ietf.o= rg. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Jul 27 14:58:18 2020 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 57E143A094E; Mon, 27 Jul 2020 14:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5ilPWXJf16K; Mon, 27 Jul 2020 14:58:07 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300049.outbound.protection.outlook.com [40.107.130.49]) (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 201ED3A08E9; Mon, 27 Jul 2020 14:58:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KJw/66sbNnx0ALqLXAfnrgN77BUL+FbVE1K5hjbu839WwrvqeKZdFwCE8Ayn7qMObNU/6BrqlXOSlt5QlgYE1iDBSdrUjo1uDBsO1OMmC2bJzGeJ6dYXkVoq09O9atd8bcgeaS0gJP20ev1OXUCLdh2ga/ZL3Wx481KT/Naaj9aRQ5CbSCwh3j17Y9xUn0naEwzZjPmXGYqEX3gMnhg1qDMqPhCOaXvgUpxsJUSskfkKF2LGqiLrofDv3xq8RP+cuY/feCSgL8BjwghZmDeQUpMnuLHotjyrzcVtynBjpV4eFu8InwaWs9Ps9SubEA5z/gG3/IAlDQh61bJL58Ndmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFfq2Kqdghx4faAQevsuIUr/CEiNY8l5ktnnMjCu88o=; b=eqsUYesoHxR6Y2AUZpTXcH67PZoXwEyCX005oVOvCOIkbtz+m3X9TIsZRHnzPLlPQVUUArxysRsd2Jogyuue7OSh/sFw2ufDXE4u/cIJwKamilgTB1dku3HkJS2SANVUMNvdPefAhZ7wpp7EMh9Fbsxn4bV+Zd1q39soYnFYO6lUNfN+maVVltdTnR48AkgGsd1xZRF1VJsc9tBi+n5hrA1vy0HiC8wgBCV3o/mr4iUE6vzqug1kWyGkorc8c8V/cTIURR+588vNUyDskKzK7MGVKSgUIbeAWcyRZV1vgdzejCNCkVPmGQp7PK+Q1kTVtHh6IM2BPCi3l8y8CLpoXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFfq2Kqdghx4faAQevsuIUr/CEiNY8l5ktnnMjCu88o=; b=WX1fbQztRrbAfvC3U4AFhviLi8cAzroVM67pPY3fBzmnrYrpVhDgLgJ2M9DCPCiIQkID2//8CXm7Ru/KtXpEtiscHH3BV82Rwc3P5bG1ZlaL1lKmaKvJKubr1SruYeURzuHk7ULDpb+CCGiwHC6kvk7lRJ3OP0HaKK1RCB2YJiY= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=apnic.net; Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TY2PR04MB3997.apcprd04.prod.outlook.com (2603:1096:404:8004::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.31; Mon, 27 Jul 2020 21:58:04 +0000 Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24%6]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 21:58:04 +0000 Content-Type: text/plain; charset=utf-8 From: Geoff Huston In-Reply-To: Date: Tue, 28 Jul 2020 07:57:57 +1000 Cc: Vasilenko Eduard , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ClientProxiedBy: SY3PR01CA0133.ausprd01.prod.outlook.com (2603:10c6:0:1b::18) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:44b8:110b:5100:61ef:4c7b:bb6c:9627] (2001:44b8:110b:5100:61ef:4c7b:bb6c:9627) by SY3PR01CA0133.ausprd01.prod.outlook.com (2603:10c6:0:1b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Mon, 27 Jul 2020 21:58:02 +0000 X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Originating-IP: [2001:44b8:110b:5100:61ef:4c7b:bb6c:9627] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c1d66074-b7d9-43e6-fc55-08d8327822f6 X-MS-TrafficTypeDiagnostic: TY2PR04MB3997: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +RPmumFa1a9JRocLuv/KnxbbxtnYFfVDJSwLc5B9EMtLFlyhrRoHgbqOdINcYZe7NDYZSFsg4MD236ZoJzmusHITqFzr6HTMfgEqx19pMG6SiO+u2H2BhC9Dqg7wL1RXZlCmCRhWn9LDMRTls45sNhnbhmgxyXU+lajoSN//IgNpb3013rYRndA5el8GyH4WEXzpJ0JU17xteLRl+HtL7qbCcRRLAb8u0+5DYyf+z9nPDEUttQCuVbD2zoF5LLwqfSPPevYn22bacl+qIY1QJp2z49MwVWJ3RV/l6om4URO1BaeHiGRdCraOGsiu0pTTc/yM6ZoF6rKPEBxt8JqXVGU6IoQXKbJ/jaeCfKN9Hmv3OdCMyQB1FzOGV0tTNUJwHPQ8zkZz+ksiPICGjwdL4A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(396003)(39850400004)(136003)(8936002)(6666004)(83380400001)(53546011)(8676002)(52116002)(66574015)(86362001)(6486002)(33656002)(16526019)(186003)(66476007)(66946007)(36756003)(508600001)(316002)(2906002)(4326008)(2616005)(54906003)(966005)(6916009)(66556008)(5660300002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: OSRhTgrC3qWQYFokxh7ZLEW/ZoRu+liYYO6+BndeEmGF4z8IofD+aFJ+0dMavKBKhcrdP5SPlkWIvfg3jGLJbfY1qdynO08xAtKqrU+XaIDmaxhWKv2CPMubCn+0c7JarNgYHX39De5f3l6ANzu0asch6/pk0Qv8VZ3zknz1xSP3En7LPN/tin3tbMALyU3EKtbB3p2v0terDiMceUmypt0kToVa8xu68oUeWOa5y4C2BaPLo7N3Zn9QX9J/CAxIgKoUPU51/BM6uDBXwIQIgdejwJOZkDzS5I8DT0lzSsr1fZ3my6YMIQZaPz6AfScEJLAnCws88+cAx671SU1NTF/jIqWCPEZNewPeMhdMJmFWKHqprru2byFnj0kZ4HXWJFjgNXo7lHlsJ18WOii59tCD4KAQt1qKl27gMM2W72Fw5TKJRvjez0ndu9NcIppLYHihaRJtrShJprMTC4hOwhaLWY1M1bcsgdKg2/7vQmJD0YZaGtrWBiBqeOB3q7nB2IoYuGJSnyGO2Nd+owU6nynIdP7s+f2u5C9R6+aV4Dy5UuPCJqre9wswPak4SahA X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: c1d66074-b7d9-43e6-fc55-08d8327822f6 X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2020 21:58:03.9050 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EMUKvqsv8HUFob45n+TsfO+5K3HJl4Njidye7UR24JzJxKvLYGqQBG/RnLxId7dy X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR04MB3997 Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 21:58:17 -0000 It might be useful to appreciate how load balancers are actually used in th= e public Internet before quoting RFC and drafts at each other. A good start= ing point is https://www.cmand.org/workshops/202006-v6/slides/cunha.pdf whi= ch describes recent work by UFMG=E2=80=99s Italo Cunha. > On 27 Jul 2020, at 7:47 pm, Mark Smith wrote: >=20 > Hi, >=20 > If load balancers are going to be discussed, it also needs to be pointed = out that they don't follow the definition of unicast addresses. >=20 > A unicast address is to uniquely identify a single node. >=20 > Load balancers share a single unicast address between multiple nodes, con= tradictory to the unique and single node identification purpose of unicast = addresses. >=20 > That is why they need to do non-RFC compliant things like digging into tr= ansport layer headers to work with unicast protocols like UDP, TCP and ICMP= , trying to make them work across a fleet of nodes sharing a single unicast= address. >=20 > An anycast address, combined with a multi-path transport layer protocol i= s the way to do service load balancing in an RFC compliant way. >=20 > See Section 5.7.7 of this draft for how. >=20 > https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-= 01#section-5.7.7 >=20 > Regards, > Mark. >=20 >=20 > On Mon, 27 Jul 2020, 19:08 Vasilenko Eduard, wrote: > Hi Fernando, > Hence again, following the logic of this draft (the level of detalization= that you have given to 5.1) - may be you need additional section 5.1.x: Lo= ad Balancer have to look into TCP/UDP ports. Moreover, it could not trust "= Flow label" - it is not reliable practice for LB. > Or alternatively you could say something about LB in section 5.1.2, but b= ecause it is a little special case - may be better to have separate 5.1.x >=20 > Eduard From nobody Mon Jul 27 15:25:16 2020 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 BCDE83A08DB for ; Mon, 27 Jul 2020 15:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buBilHF48fmI for ; Mon, 27 Jul 2020 15:25:08 -0700 (PDT) Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D704C3A08F5 for ; Mon, 27 Jul 2020 15:25:07 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id g19so4842798ejc.9 for ; Mon, 27 Jul 2020 15:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S/43cs8fWlQyVrBglEA7HU2kuuCyoPwnjKtI32L9I6c=; b=xRvSU/oyUQamWfWBMXGYjvuFc667PYZAlVYaBv+0Qwid/CdSlkA7AdDtZ7sMS9kvxw Kv2058/ztsjTnDwF7YnF536DAdgrPenl7CJp/HNwOJ93Hf6FmDW07FMIGsLR/VuQ9C6E H0XRyKpf8IP0jXEz55HKeM/auTrGt2jUq9a+zsv6NWL0BTlEuX+IIKF9wojTHkELjf3j NIvA1p1qcMi3gmK7r7ZU5EQ54twbGEgg/bj3wDqmMFA6kaSDaPoUFBCIET7US8w9lXD4 rVMvjspXbMVhB0bJvt/tGOs/b3hXWaqOTq1DSZPeBmoKClLIHku3txyBEWc+LnaU4N9y WodA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=S/43cs8fWlQyVrBglEA7HU2kuuCyoPwnjKtI32L9I6c=; b=Z5jpY2uUkJzc9trbxL0UCEB4J/v+ncE7/BY0AISiFT6PegyLHsDrsxIwBlJs0Lm0ja Vza9s8DKPLe3wBfG6un2shwrmyo1csgJd4xqZtcIDciuDzF9WmBhZd7X14SPzwFo4CZM ZSs2zJt3Fv8LVHWVrTAz0HwTO7JyBR0u2dSMto14fFEJVz/20NITdosnVR7j03mA7cNt LxBozzAqpsgz/t3MLbMOPo62ENyxQNBMMWw0uLSUSstAd+AyArQQQqIfeQlYJ7bsORvy fHl2/c4ngiaoqCuIyCm3WpK0ffMH8IUUS2aEg7zBzw6N79VTQxl33t60WsV8mb+VAVwP rU0g== X-Gm-Message-State: AOAM5333iZyezf0QmcbQeD/nR8GbkLwT30BBCS3VB42Yq9xu/E4/OfG3 VM+Jn12szIjd1N+Mjy9sfal7r0M8Et1WJqE+Xl1Q8DBN X-Google-Smtp-Source: ABdhPJy4vArDsniO+hJ8rAjJRJZXD8ODIf5KO1b3zqqWnIlZmIHELvJbkFQXuXtcOqYWO7V8S6DvYJPUZ95KcO+jOVY= X-Received: by 2002:a17:907:aaa:: with SMTP id bz10mr2942108ejc.304.1595888706165; Mon, 27 Jul 2020 15:25:06 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> In-Reply-To: From: Tom Herbert Date: Mon, 27 Jul 2020 15:24:55 -0700 Message-ID: To: Brian E Carpenter Cc: Vasilenko Eduard , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 22:25:14 -0000 On Mon, Jul 27, 2020 at 2:01 PM Brian E Carpenter wrote: > > On 28-Jul-20 07:23, Tom Herbert wrote: > > On Mon, Jul 27, 2020 at 11:05 AM Vasilenko Eduard > > wrote: > >> > >> Hi Tom, > >> I believe that risk still exist that some application would no use flo= w label properly. > > > > Exactly which applications are you concerned about? > > Given that the most widespread socket APIs (POSIX and WinSock) do not all= ow > an application to set the flow label, I too have that question. > Brian, Flow label is automatically set per flow. The easiest way to do this is to save a hash value in the connection context, in Linux that's simply intialized to a random number and when packets are sent the low order twenty bits of the value are simply copied into the flow label. In cases where we don't have a connection context, like when we're forwarding and encapsulating in IPv6, we hash over the packet four tuples and use bits from that hash value. In most cases we can either use the saved context hash or get a suitable 4-tuple hash from the receiving device for "free", but if those are not available then we will do the work to compute the hash in the CPU (expensive operations for CPU so we try to avoid that). Generally, we really don't want individual applications setting the flow label, it's just as easy to let the kernel do it as it can guarantee a proper uniform distribution, good waterfall properties in the hash, and consistent use of the same hash for the lifetime of the connection. The one exception is if the flow label has more semantics that just being an entropy identifier, in that case there are APIs that can be used. Tom > And again: please read RFC7098 where these issues are discussed in some > depth. If that RFC is now out of date due to changing reality (such > as TLS 1.3), please let us know. > > Brian > > > > >> Hence, it is better on LB to deep dive into UDP/TCP. More predictable/= reliable result. > > > > You seem to be assuming a very limited traffic profile that consists > > only of plain UDP/TCP packets. Any use case that deviates from that > > then breaks your LB (i.e. encapsulation, tunneled encryption, SCTP, > > IPSec, etc.). Flow label is in all IPv6 packets and is mostly set > > properly for the vast majority of packets on the Internet and > > processing it is completely independent of the protocols, so when > > taking the full scope of the problem into account it is actually more > > generic and more predictable/reliable. > > > > Tom > > > >> Eduard > >> -----Original Message----- > >> From: Tom Herbert [mailto:tom@herbertland.com] > >> Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 17:15 > >> To: Vasilenko Eduard > >> Cc: Fernando Gont ; IPv6 Operations ; draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > >> Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Ext= ension Headers - Load Balancer > >> > >> On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard wrote: > >>> > >>> Hi Fernando, > >>> Hence again, following the logic of this draft (the level of detaliza= tion that you have given to 5.1) - may be you need additional section 5.1.x= : Load Balancer have to look into TCP/UDP ports. Moreover, it could not tru= st "Flow label" - it is not reliable practice for LB. > >> > >> Eduard, > >> > >> What exactly does "not reliable practice for LB" mean.? If this means = that the flow label might change during the flow's lifetime then I will poi= nt out that UDP is equally unreliable for that reason (i.e. > >> the UDP ports for a QUIC connection can change during the connection's= lifetime). For that matter, a TCP header might be encrypted or in an encap= sulation that the LB doesn't understand so the LB can't access the TCP port= s at all-- in the this case the flow label is actually more reliable than T= CP since it's never encrypted and is purposely designed to be consumed by i= ntermediate nodes without the need for expensive DPI. > >> > >> Tom > >>> Or alternatively you could say something about LB in section 5.1.2, > >>> but because it is a little special case - may be better to have > >>> separate 5.1.x > >>> > >>> Eduard > >>> -----Original Message----- > >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gon= t > >>> Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > >>> To: IPv6 Operations > >>> Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > >>> Subject: [v6ops] Operational Implications of IPv6 Packets with > >>> Extension Headers (Fwd: New Version Notification for > >>> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) > >>> > >>> Folks, > >>> > >>> We have posted a rev of our IETF I-D "Operational Implications of IPv= 6 Packets with Extension Headers". > >>> > >>> The I-D is available at: > >>> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet= - > >>> drops-04.txt > >>> > >>> Your feedback will be appreciated. > >>> > >>> Thanks! > >>> > >>> Cheers, > >>> Fernando > >>> > >>> > >>> > >>> > >>> -------- Forwarded Message -------- > >>> Subject: New Version Notification for > >>> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > >>> Date: Sat, 25 Jul 2020 22:28:50 -0700 > >>> From: internet-drafts@ietf.org > >>> To: Fernando Gont , Gert Doering > >>> , Geoff Huston , Warren Kumari > >>> , Nick Hilliard > >>> > >>> > >>> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > >>> has been successfully submitted by Fernando Gont and posted to the IE= TF repository. > >>> > >>> Name: draft-gont-v6ops-ipv6-ehs-packet-drops > >>> Revision: 04 > >>> Title: Operational Implications of IPv6 Packets with Extensi= on Headers > >>> Document date: 2020-07-25 > >>> Group: Individual Submission > >>> Pages: 15 > >>> URL: > >>> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet= - > >>> drops-04.txt > >>> Status: > >>> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-dro= p > >>> s/ > >>> Htmlized: > >>> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > >>> Htmlized: > >>> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packe= t > >>> -drops > >>> Diff: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-= dro > >>> ps-04 > >>> > >>> Abstract: > >>> This document summarizes the security and operational implication= s of > >>> IPv6 extension headers, and attempts to analyze reasons why packe= ts > >>> with IPv6 extension headers may be dropped in the public Internet= . > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of sub= mission until the htmlized version and diff are available at tools.ietf.org= . > >>> > >>> The IETF Secretariat > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Tue Jul 28 01:37:11 2020 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 1D9543A08C0; Tue, 28 Jul 2020 01:37:09 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V4E9HSmqXQI; Tue, 28 Jul 2020 01:37:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 82D8B3A08D7; Tue, 28 Jul 2020 01:37:00 -0700 (PDT) Received: from lhreml711-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1D348444BD46870F8F5F; Tue, 28 Jul 2020 09:36:55 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 09:36:54 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 11:36:54 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 28 Jul 2020 11:36:54 +0300 From: Vasilenko Eduard To: Tom Herbert CC: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AQHWZCBNgvrnr0hITbeSprlQeXLX06kbuR9A///jMoCAAQipcA== Date: Tue, 28 Jul 2020 08:36:53 +0000 Message-ID: <947a50398cbb4bbcad85462a69d7dd45@huawei.com> References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.207.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 08:37:09 -0000 SGkgVG9tLA0KSXMgQVBOSUMgYSByZWxpYWJsZSBzb3VyY2UgZm9yIHlvdT8NCmh0dHBzOi8vYmxv Zy5hcG5pYy5uZXQvMjAxOC8wMS8xMS9pcHY2LWZsb3ctbGFiZWwtbWlzdXNlLWhhc2hpbmcvDQpS SVBFIGhhcyByZXBsaWNhdGVkIGl0IGhlcmU6IGh0dHBzOi8vbGFicy5yaXBlLm5ldC9NZW1iZXJz L2pvZWxfamFlZ2dsaS9pcHY2LWZsb3ctbGFiZWwtbWlzdXNlLWluLWhhc2hpbmcNCiJDYXNlcyBo YXZlIGJlZW4gb2JzZXJ2ZWQgd2hlcmUgZGV2aWNlcyB0aGF0IGNvbm5lY3QgdG8gaGFzaGVkIGVu ZHBvaW50cyBkbyBub3QgaW4gZmFjdCBob25vdXIgdGhpcyBiZWhhdmlvdXIuIEJ5IGluIGxhcmdl LCB0aGlzIGZsb3cgbGFiZWwgY2hhbmdpbmcgYmVoYXZpb3VyIGhhcyBiZWVuIHRyYWNlZCB0byBJ UHY2IHN1cHBvcnRpbmcgQ1BFL2ZpcmV3YWxscywgd2hpY2ggY2hhbmdlIHRoZSBmbG93IGxhYmVs IGJldHdlZW4gdGhlIGluaXRpYWwgc3luIGFuZCB0aGUgYWNrLiINClRoZXkgaGF2ZSBkaXNwdXRh YmxlIGNvbmNsdXNpb246ICJBdm9pZCB1c2luZyB0aGUgZmxvdyBsYWJlbCBhcyBhIGhhc2ggY29t cG9uZW50Ii4NCg0KQWRkaXRpb25hbCBjb3JuZXIgY2FzZTogaHR0cHM6Ly9naXRodWIuY29tL3B5 cGEvd2FyZWhvdXNlL2lzc3Vlcy81NDU0DQoNCkVkdWFyZA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0gDQpT ZW50OiAyNyDQuNGO0LvRjyAyMDIwINCzLiAyMjoyNA0KVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZh c2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4NCkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZu ZXR3b3Jrcy5jb20+OyBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPjsgZHJhZnQtZ29u dC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZv cHNdIE9wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJUHY2IFBhY2tldHMgd2l0aCBFeHRlbnNp b24gSGVhZGVycyAtIExvYWQgQmFsYW5jZXINCg0KT24gTW9uLCBKdWwgMjcsIDIwMjAgYXQgMTE6 MDUgQU0gVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPiB3cm90 ZToNCj4NCj4gSGkgVG9tLA0KPiBJIGJlbGlldmUgdGhhdCByaXNrIHN0aWxsIGV4aXN0IHRoYXQg c29tZSBhcHBsaWNhdGlvbiB3b3VsZCBubyB1c2UgZmxvdyBsYWJlbCBwcm9wZXJseS4NCg0KRXhh Y3RseSB3aGljaCBhcHBsaWNhdGlvbnMgYXJlIHlvdSBjb25jZXJuZWQgYWJvdXQ/DQoNCj4gSGVu Y2UsIGl0IGlzIGJldHRlciBvbiBMQiB0byBkZWVwIGRpdmUgaW50byBVRFAvVENQLiBNb3JlIHBy ZWRpY3RhYmxlL3JlbGlhYmxlIHJlc3VsdC4NCg0KWW91IHNlZW0gdG8gYmUgYXNzdW1pbmcgYSB2 ZXJ5IGxpbWl0ZWQgdHJhZmZpYyBwcm9maWxlIHRoYXQgY29uc2lzdHMgb25seSBvZiBwbGFpbiBV RFAvVENQIHBhY2tldHMuIEFueSB1c2UgY2FzZSB0aGF0IGRldmlhdGVzIGZyb20gdGhhdCB0aGVu IGJyZWFrcyB5b3VyIExCIChpLmUuIGVuY2Fwc3VsYXRpb24sIHR1bm5lbGVkIGVuY3J5cHRpb24s IFNDVFAsIElQU2VjLCBldGMuKS4gRmxvdyBsYWJlbCBpcyBpbiBhbGwgSVB2NiBwYWNrZXRzIGFu ZCBpcyBtb3N0bHkgc2V0IHByb3Blcmx5IGZvciB0aGUgdmFzdCBtYWpvcml0eSBvZiBwYWNrZXRz IG9uIHRoZSBJbnRlcm5ldCBhbmQgcHJvY2Vzc2luZyBpdCBpcyBjb21wbGV0ZWx5IGluZGVwZW5k ZW50IG9mIHRoZSBwcm90b2NvbHMsIHNvIHdoZW4gdGFraW5nIHRoZSBmdWxsIHNjb3BlIG9mIHRo ZSBwcm9ibGVtIGludG8gYWNjb3VudCBpdCBpcyBhY3R1YWxseSBtb3JlIGdlbmVyaWMgYW5kIG1v cmUgcHJlZGljdGFibGUvcmVsaWFibGUuDQoNClRvbQ0KDQo+IEVkdWFyZA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0 bGFuZC5jb21dDQo+IFNlbnQ6IDI3INC40Y7Qu9GPIDIwMjAg0LMuIDE3OjE1DQo+IFRvOiBWYXNp bGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+DQo+IENjOiBGZXJuYW5k byBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyBJUHY2IE9wZXJhdGlvbnMgDQo+IDx2Nm9w c0BpZXRmLm9yZz47IGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIE9wZXJhdGlvbmFsIEltcGxpY2F0aW9ucyBvZiBJ UHY2IFBhY2tldHMgd2l0aCANCj4gRXh0ZW5zaW9uIEhlYWRlcnMgLSBMb2FkIEJhbGFuY2VyDQo+ DQo+IE9uIE1vbiwgSnVsIDI3LCAyMDIwIGF0IDI6MDggQU0gVmFzaWxlbmtvIEVkdWFyZCA8dmFz aWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIEZlcm5hbmRvLA0K PiA+IEhlbmNlIGFnYWluLCBmb2xsb3dpbmcgdGhlIGxvZ2ljIG9mIHRoaXMgZHJhZnQgKHRoZSBs ZXZlbCBvZiBkZXRhbGl6YXRpb24gdGhhdCB5b3UgaGF2ZSBnaXZlbiB0byA1LjEpIC0gbWF5IGJl IHlvdSBuZWVkIGFkZGl0aW9uYWwgc2VjdGlvbiA1LjEueDogTG9hZCBCYWxhbmNlciBoYXZlIHRv IGxvb2sgaW50byBUQ1AvVURQIHBvcnRzLiBNb3Jlb3ZlciwgaXQgY291bGQgbm90IHRydXN0ICJG bG93IGxhYmVsIiAtIGl0IGlzIG5vdCByZWxpYWJsZSBwcmFjdGljZSBmb3IgTEIuDQo+DQo+IEVk dWFyZCwNCj4NCj4gV2hhdCBleGFjdGx5IGRvZXMgIm5vdCByZWxpYWJsZSBwcmFjdGljZSBmb3Ig TEIiIG1lYW4uPyBJZiB0aGlzIG1lYW5zIHRoYXQgdGhlIGZsb3cgbGFiZWwgbWlnaHQgY2hhbmdl IGR1cmluZyB0aGUgZmxvdydzIGxpZmV0aW1lIHRoZW4gSSB3aWxsIHBvaW50IG91dCB0aGF0IFVE UCBpcyBlcXVhbGx5IHVucmVsaWFibGUgZm9yIHRoYXQgcmVhc29uIChpLmUuDQo+IHRoZSBVRFAg cG9ydHMgZm9yIGEgUVVJQyBjb25uZWN0aW9uIGNhbiBjaGFuZ2UgZHVyaW5nIHRoZSBjb25uZWN0 aW9uJ3MgbGlmZXRpbWUpLiBGb3IgdGhhdCBtYXR0ZXIsIGEgVENQIGhlYWRlciBtaWdodCBiZSBl bmNyeXB0ZWQgb3IgaW4gYW4gZW5jYXBzdWxhdGlvbiB0aGF0IHRoZSBMQiBkb2Vzbid0IHVuZGVy c3RhbmQgc28gdGhlIExCIGNhbid0IGFjY2VzcyB0aGUgVENQIHBvcnRzIGF0IGFsbC0tIGluIHRo ZSB0aGlzIGNhc2UgdGhlIGZsb3cgbGFiZWwgaXMgYWN0dWFsbHkgbW9yZSByZWxpYWJsZSB0aGFu IFRDUCBzaW5jZSBpdCdzIG5ldmVyIGVuY3J5cHRlZCBhbmQgaXMgcHVycG9zZWx5IGRlc2lnbmVk IHRvIGJlIGNvbnN1bWVkIGJ5IGludGVybWVkaWF0ZSBub2RlcyB3aXRob3V0IHRoZSBuZWVkIGZv ciBleHBlbnNpdmUgRFBJLg0KPg0KPiBUb20NCj4gPiBPciBhbHRlcm5hdGl2ZWx5IHlvdSBjb3Vs ZCBzYXkgc29tZXRoaW5nIGFib3V0IExCIGluIHNlY3Rpb24gNS4xLjIsIA0KPiA+IGJ1dCBiZWNh dXNlIGl0IGlzIGEgbGl0dGxlIHNwZWNpYWwgY2FzZSAtIG1heSBiZSBiZXR0ZXIgdG8gaGF2ZSAN Cj4gPiBzZXBhcmF0ZSA1LjEueA0KPiA+DQo+ID4gRWR1YXJkDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBGZXJuYW5kbyANCj4gPiBHb250DQo+ID4gU2VudDogMjYg0LjRjtC7 0Y8gMjAyMCDQsy4gODo0Ng0KPiA+IFRvOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3Jn Pg0KPiA+IENjOiBkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFt2Nm9wc10gT3BlcmF0aW9uYWwgSW1wbGljYXRpb25zIG9mIElQdjYg UGFja2V0cyB3aXRoIA0KPiA+IEV4dGVuc2lvbiBIZWFkZXJzIChGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9w cy0wNC50eHQpDQo+ID4NCj4gPiBGb2xrcywNCj4gPg0KPiA+IFdlIGhhdmUgcG9zdGVkIGEgcmV2 IG9mIG91ciBJRVRGIEktRCAiT3BlcmF0aW9uYWwgSW1wbGljYXRpb25zIG9mIElQdjYgUGFja2V0 cyB3aXRoIEV4dGVuc2lvbiBIZWFkZXJzIi4NCj4gPg0KPiA+IFRoZSBJLUQgaXMgYXZhaWxhYmxl IGF0Og0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb250 LXY2b3BzLWlwdjYtZWhzLXBhY2tlDQo+ID4gdC0NCj4gPiBkcm9wcy0wNC50eHQNCj4gPg0KPiA+ IFlvdXIgZmVlZGJhY2sgd2lsbCBiZSBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IFRoYW5rcyENCj4g Pg0KPiA+IENoZWVycywNCj4gPiBGZXJuYW5kbw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0t LS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIA0KPiA+IGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0 LWRyb3BzLTA0LnR4dA0KPiA+IERhdGU6IFNhdCwgMjUgSnVsIDIwMjAgMjI6Mjg6NTAgLTA3MDAN Cj4gPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPiBUbzogRmVybmFuZG8gR29u dCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPiwgR2VydCBEb2VyaW5nIA0KPiA+IDxnZXJ0QHNwYWNl Lm5ldD4sIEdlb2ZmIEh1c3RvbiA8Z2loQGFwbmljLm5ldD4sIFdhcnJlbiBLdW1hcmkgDQo+ID4g PHdhcnJlbkBrdW1hcmkubmV0PiwgTmljayBIaWxsaWFyZCA8bmlja0BpbmV4LmllPg0KPiA+DQo+ ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1w YWNrZXQtZHJvcHMtMDQudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBGZXJuYW5kbyBHb250IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPg0K PiA+IE5hbWU6ICAgICAgICAgICBkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9w cw0KPiA+IFJldmlzaW9uOiAgICAgICAwNA0KPiA+IFRpdGxlOiAgICAgICAgICBPcGVyYXRpb25h bCBJbXBsaWNhdGlvbnMgb2YgSVB2NiBQYWNrZXRzIHdpdGggRXh0ZW5zaW9uIEhlYWRlcnMNCj4g PiBEb2N1bWVudCBkYXRlOiAgMjAyMC0wNy0yNQ0KPiA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4gPiBQYWdlczogICAgICAgICAgMTUNCj4gPiBVUkw6DQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1l aHMtcGFja2UNCj4gPiB0LQ0KPiA+IGRyb3BzLTA0LnR4dA0KPiA+IFN0YXR1czoNCj4gPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBh Y2tldC1kcg0KPiA+IG9wDQo+ID4gcy8NCj4gPiBIdG1saXplZDoNCj4gPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMtMA0K PiA+IDQNCj4gPiBIdG1saXplZDoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtcGFjaw0KPiA+IGV0DQo+ID4gLWRyb3Bz DQo+ID4gRGlmZjoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt Z29udC12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZA0KPiA+IHJvDQo+ID4gcHMtMDQNCj4gPg0KPiA+ IEFic3RyYWN0Og0KPiA+ICAgICBUaGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgdGhlIHNlY3VyaXR5 IGFuZCBvcGVyYXRpb25hbCBpbXBsaWNhdGlvbnMgb2YNCj4gPiAgICAgSVB2NiBleHRlbnNpb24g aGVhZGVycywgYW5kIGF0dGVtcHRzIHRvIGFuYWx5emUgcmVhc29ucyB3aHkgcGFja2V0cw0KPiA+ ICAgICB3aXRoIElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgbWF5IGJlIGRyb3BwZWQgaW4gdGhlIHB1 YmxpYyBJbnRlcm5ldC4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4NCj4gPg0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBs aXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Tue Jul 28 01:42:57 2020 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 438963A08C1; Tue, 28 Jul 2020 01:42:56 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1At5a6z84Xag; Tue, 28 Jul 2020 01:42:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7C6FA3A08C0; Tue, 28 Jul 2020 01:42:54 -0700 (PDT) Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2825BEBAD51C0760E459; Tue, 28 Jul 2020 09:42:53 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 28 Jul 2020 09:42:52 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 11:42:52 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 28 Jul 2020 11:42:52 +0300 From: Vasilenko Eduard To: Geoff Huston , Mark Smith CC: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AQHWZGD8gvrnr0hITbeSprlQeXLX06kcrYOg Date: Tue, 28 Jul 2020 08:42:51 +0000 Message-ID: <0e9c24106d2342459acb587de98eaff1@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.207.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 08:42:56 -0000 SGkgR2VvZmYsIHRoYW5rcy4gU3RyaWtpbmcgc3RhdGlzdGljcy4gSSBkaWQgbm90IGV4cGVjdCB0 aGF0IElQdjYgZmxvdyBsYWJlbCBpcyB1c2VkIG9ubHkgZm9yIDMlIG9mIHRyYWZmaWMuDQpFZC8N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHZW9mZiBIdXN0b24gW21haWx0bzpn aWhAYXBuaWMubmV0XSANClNlbnQ6IDI4INC40Y7Qu9GPIDIwMjAg0LMuIDA6NTgNClRvOiBNYXJr IFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KQ2M6IFZhc2lsZW5rbyBFZHVhcmQgPHZh c2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT47IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdv cmtzLmNvbT47IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyBkcmFmdC1nb250LXY2 b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10g T3BlcmF0aW9uYWwgSW1wbGljYXRpb25zIG9mIElQdjYgUGFja2V0cyB3aXRoIEV4dGVuc2lvbiBI ZWFkZXJzIC0gTG9hZCBCYWxhbmNlcg0KDQpJdCBtaWdodCBiZSB1c2VmdWwgdG8gYXBwcmVjaWF0 ZSBob3cgbG9hZCBiYWxhbmNlcnMgYXJlIGFjdHVhbGx5IHVzZWQgaW4gdGhlIHB1YmxpYyBJbnRl cm5ldCBiZWZvcmUgcXVvdGluZyBSRkMgYW5kIGRyYWZ0cyBhdCBlYWNoIG90aGVyLiBBIGdvb2Qg c3RhcnRpbmcgcG9pbnQgaXMgaHR0cHM6Ly93d3cuY21hbmQub3JnL3dvcmtzaG9wcy8yMDIwMDYt djYvc2xpZGVzL2N1bmhhLnBkZiB3aGljaCBkZXNjcmliZXMgcmVjZW50IHdvcmsgYnkgVUZNR+KA mXMgSXRhbG8gQ3VuaGEuDQoNCg0KDQo+IE9uIDI3IEp1bCAyMDIwLCBhdCA3OjQ3IHBtLCBNYXJr IFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4g SWYgbG9hZCBiYWxhbmNlcnMgYXJlIGdvaW5nIHRvIGJlIGRpc2N1c3NlZCwgaXQgYWxzbyBuZWVk cyB0byBiZSBwb2ludGVkIG91dCB0aGF0IHRoZXkgZG9uJ3QgZm9sbG93IHRoZSBkZWZpbml0aW9u IG9mIHVuaWNhc3QgYWRkcmVzc2VzLg0KPiANCj4gQSB1bmljYXN0IGFkZHJlc3MgaXMgdG8gdW5p cXVlbHkgaWRlbnRpZnkgYSBzaW5nbGUgbm9kZS4NCj4gDQo+IExvYWQgYmFsYW5jZXJzIHNoYXJl IGEgc2luZ2xlIHVuaWNhc3QgYWRkcmVzcyBiZXR3ZWVuIG11bHRpcGxlIG5vZGVzLCBjb250cmFk aWN0b3J5IHRvIHRoZSB1bmlxdWUgYW5kIHNpbmdsZSBub2RlIGlkZW50aWZpY2F0aW9uIHB1cnBv c2Ugb2YgdW5pY2FzdCBhZGRyZXNzZXMuDQo+IA0KPiBUaGF0IGlzIHdoeSB0aGV5IG5lZWQgdG8g ZG8gbm9uLVJGQyBjb21wbGlhbnQgdGhpbmdzIGxpa2UgZGlnZ2luZyBpbnRvIHRyYW5zcG9ydCBs YXllciBoZWFkZXJzIHRvIHdvcmsgd2l0aCB1bmljYXN0IHByb3RvY29scyBsaWtlIFVEUCwgVENQ IGFuZCBJQ01QLCB0cnlpbmcgdG8gbWFrZSB0aGVtIHdvcmsgYWNyb3NzIGEgZmxlZXQgb2Ygbm9k ZXMgc2hhcmluZyBhIHNpbmdsZSB1bmljYXN0IGFkZHJlc3MuDQo+IA0KPiBBbiBhbnljYXN0IGFk ZHJlc3MsIGNvbWJpbmVkIHdpdGggYSBtdWx0aS1wYXRoIHRyYW5zcG9ydCBsYXllciBwcm90b2Nv bCBpcyB0aGUgd2F5IHRvIGRvIHNlcnZpY2UgbG9hZCBiYWxhbmNpbmcgaW4gYW4gUkZDIGNvbXBs aWFudCB3YXkuDQo+IA0KPiBTZWUgU2VjdGlvbiA1LjcuNyBvZiB0aGlzIGRyYWZ0IGZvciBob3cu DQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc21pdGgtNm1hbi1mb3Jt LWZ1bmMtYW55Y2FzdC1hZGRyZXNzZXMtMDEjc2VjdGlvbi01LjcuNw0KPiANCj4gUmVnYXJkcywN Cj4gTWFyay4NCj4gDQo+IA0KPiBPbiBNb24sIDI3IEp1bCAyMDIwLCAxOTowOCBWYXNpbGVua28g RWR1YXJkLCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPiB3cm90ZToNCj4gSGkgRmVybmFu ZG8sDQo+IEhlbmNlIGFnYWluLCBmb2xsb3dpbmcgdGhlIGxvZ2ljIG9mIHRoaXMgZHJhZnQgKHRo ZSBsZXZlbCBvZiBkZXRhbGl6YXRpb24gdGhhdCB5b3UgaGF2ZSBnaXZlbiB0byA1LjEpIC0gbWF5 IGJlIHlvdSBuZWVkIGFkZGl0aW9uYWwgc2VjdGlvbiA1LjEueDogTG9hZCBCYWxhbmNlciBoYXZl IHRvIGxvb2sgaW50byBUQ1AvVURQIHBvcnRzLiBNb3Jlb3ZlciwgaXQgY291bGQgbm90IHRydXN0 ICJGbG93IGxhYmVsIiAtIGl0IGlzIG5vdCByZWxpYWJsZSBwcmFjdGljZSBmb3IgTEIuDQo+IE9y IGFsdGVybmF0aXZlbHkgeW91IGNvdWxkIHNheSBzb21ldGhpbmcgYWJvdXQgTEIgaW4gc2VjdGlv biA1LjEuMiwgYnV0IGJlY2F1c2UgaXQgaXMgYSBsaXR0bGUgc3BlY2lhbCBjYXNlIC0gbWF5IGJl IGJldHRlciB0byBoYXZlIHNlcGFyYXRlIDUuMS54DQo+IA0KPiBFZHVhcmQNCg0K From nobody Tue Jul 28 07:15:37 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADD23A0CB2; Tue, 28 Jul 2020 07:15:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <159594573523.13152.3914768057480139064@ietfa.amsl.com> Date: Tue, 28 Jul 2020 07:15:35 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:15:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/MAT-T Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-03.txt Pages : 24 Date : 2020-07-28 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only hosts or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network, increasing the performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 28 07:24:26 2020 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 3139B3A0CB8 for ; Tue, 28 Jul 2020 07:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2DfYKtfVn5o for ; Tue, 28 Jul 2020 07:24:23 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6B3A0CC8 for ; Tue, 28 Jul 2020 07:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1595945881; x=1596550681; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=MG/eSsqB KlIF8Ht+1v/lFSVuGulIUmIt+IpVEWFfLEo=; b=lqCIETuC4Ayan7mTEoBTwgNd W94HbpkdgEVb2GejSM5yeCFvOqlQdq5S2nwR9iBlFYmtCvIGe2dvLMSODxNc1xng LP69lHxIAf2ETBm1uD9Ce/nXD7alxNNofx3oZqBFaBSuD90aBdG/TiQmYTyQPgsZ q3g9RheWmKSDw7rtWlk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 28 Jul 2020 16:18:01 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 28 Jul 2020 16:18:00 +0200 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000333242.msg for ; Tue, 28 Jul 2020 16:18:00 +0200 X-MDRemoteIP: 2001:470:1f09:495:7552:f1fa:4e40:2b6c X-MDHelo: [10.10.10.144] X-MDArrival-Date: Tue, 28 Jul 2020 16:18:00 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=147892edb6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Tue, 28 Jul 2020 16:17:55 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <7975506A-9D32-490B-96C6-E4A1CF7EBFE1@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt References: <159594573523.13152.3914768057480139064@ietfa.amsl.com> In-Reply-To: <159594573523.13152.3914768057480139064@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:24:25 -0000 Hi all, Sorry, was a bit congested with other work last week to finish this version= . I'm still working in some of the previous emails, to make sure that this ve= rsion has addressed them. I will be responding ASAP. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 28/7/20 16:16, "v6ops-bounces@ietf.org en nombre de internet-dr= afts@ietf.org" escribi=C3=B3: A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : 464XLAT/MAT-T Optimization Authors : Jordi Palet Martinez Alejandro D'Egidio Filename : draft-ietf-v6ops-464xlat-optimization-03.txt Pages : 24 Date : 2020-07-28 Abstract: IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only hosts or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The propose= d solution would significantly reduce the NAT64 utilization in the operator's network, increasing the performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimiza= tion-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimizati= on-03 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Jul 28 07:32:21 2020 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 23F7A3A0B9B for ; Tue, 28 Jul 2020 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJjLzHUfOe5l for ; Tue, 28 Jul 2020 07:32:18 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641963A0CEA for ; Tue, 28 Jul 2020 07:32:18 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id 9so17510050wmj.5 for ; Tue, 28 Jul 2020 07:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WawqXvL7tBzyV9it/k2VuZpuGXRvi34S1zvs3NFvjVc=; b=BkuiuQKq9czscZFVGWi0nGfRwMT/MHuM0aUaQARE3NCIqlNUoBcipW58lUUwdjDBFn j9Sc7OKqWw1+9E2A8+BxgEJpncBHvOB8fG5cnMTrVm9vznNRKWeQXiNm8wo5jZb6TS7W AQsl7EFRvPZ+c2UeG2824mJEoU0+Uzm5XkNhbXp4Uvzo7du9gMXBvWYbeJDjWJVQRiiJ YtmsPiDnQEJctqyl5QLUiRKf4/NAEA51y/iX2mycszmyzj9PyJMNAAfgk17J65KcgJ8W uADgiNcfuBIk+Q0fo7igXfLV0k3+IFAyJOzvncSHtPlRtmUYsU/vTjHKkGqSpWEh+GPp IKyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WawqXvL7tBzyV9it/k2VuZpuGXRvi34S1zvs3NFvjVc=; b=Fo1Ut0XNONY2GnPg7nH7Onn0ok3/ujKBo8RRRq/JfXg2uScgw6kAyXWrjKyNHzXRWg Lxl75Crdd+zKSVrwxdT6iVBOge+5JC2USxG7ABtmkLkzdFxlvt2AKpnqFHxxFR340dXr AKIx7HbN8gVn/uuOY13FtfagMV0m8BF7JR4gFf5whTE9s/R6ZlG3LMeCvI0PQfr+qi5C GLXCsJKFAbF1hBYeO8bBgD6XI07s2h/8YlNZI4C3ppHAa+31/R8TW3stTfZt6sm9DMIS mQtiws+BtPlfj7BDpLp0YeDkHHTJs9K/CYTr0/2jo2YsCswMhbwE2H0KJT1ZYYLm6eMD 0Zhw== X-Gm-Message-State: AOAM533zxJfCyvCdOSu3SIXdEyc5n1MH82WMlZ/wjXwf8jgKeQJ5OG8T tBRRFE2D3rKgFcG7HBd2mPo= X-Google-Smtp-Source: ABdhPJxS+/4iyRNAvQLx2C1t7mqvBaDPe4noQiiSBBzi0OVpIDEec4Cjun1JRQZC2Y11Tbe6aiwZ8A== X-Received: by 2002:a1c:a9c6:: with SMTP id s189mr4033961wme.166.1595946737010; Tue, 28 Jul 2020 07:32:17 -0700 (PDT) Received: from [192.168.0.21] (tchowndsl.claranet.co.uk. [212.188.254.49]) by smtp.gmail.com with ESMTPSA id x11sm4317538wmc.33.2020.07.28.07.32.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 07:32:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Chown In-Reply-To: <53a8e94d-dfc3-23f9-2dac-b70eb4f203a8@gmail.com> Date: Tue, 28 Jul 2020 15:32:15 +0100 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <159574132870.611.12077598721404194383@ietfa.amsl.com> <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> <53a8e94d-dfc3-23f9-2dac-b70eb4f203a8@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:32:20 -0000 Hi, > On 27 Jul 2020, at 21:51, Brian E Carpenter = wrote: >=20 > On 27-Jul-20 18:49, Fernando Gont wrote: >=20 >> BTW... it seems that RFC7045 has not really been incorporated into=20 >> RFC8200? =20 >=20 > Well, yes and no. Firstly the point about HbH header processing > being essentially optional was adopted. Similarly, RFC7045 says > "This document updates RFC 2460 to > clarify how intermediate nodes should deal with such extension > headers and with any that are defined in the future." > and that, I believe, is reflected in RFC8200. It may be worth pointing out that RFC 7045 was included in the IPv6 Node = Requirements - bis work and thus into RFC 8504, with the =E2=80=9Cnodes = SHOULD forward packets regardless of EHs present=E2=80=9D text repeated = there. EH-related requirements in RFC 8504 are explicitly covered in = https://tools.ietf.org/html/rfc8504#section-5.2. Tim= From nobody Tue Jul 28 12:18:43 2020 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 F2E003A0B9B for ; Tue, 28 Jul 2020 12:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMRI71bTi9VP for ; Tue, 28 Jul 2020 12:18:25 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C13B3A0B98 for ; Tue, 28 Jul 2020 12:18:25 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id f24so1289659ejx.6 for ; Tue, 28 Jul 2020 12:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EXEmB3OlKl0h+iSqpRnG1wDnoJi5GMKJpA9zFRFhdQo=; b=UmFrozxC652feLmGV9kzepazcZR9cF6Bqun/63SDwonSMmuqHQ9s5+c762JoeMDrKB yN8tuuBjTZ4AE/W4bhXIx7Ho1lzKXCRQrSGPMd3VRYItEuzZqO3KBOvXcQNqWAH8Q3mV p9knz2XfaYi+RFJ3VrZjk6tvwBCfeA1DtsUfi36XkKfrW7RX9MNZkTrkQJ/MBA1zrAHa Ch2DLj5SCB6EF7xT/WA8ygvRvpet7uANmA0BYylgf6B5OteJoFbNsww0s7SxFCEnw4V6 3kwoHcheFTdE+6q+jIqzmD6n6PvRaJQ3EwPvCYtt+p/hibFwVyMKc6fBZYGlCIwZnmP6 nlHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EXEmB3OlKl0h+iSqpRnG1wDnoJi5GMKJpA9zFRFhdQo=; b=dmwya6samDLpyqYmGPz7dV3vRBiHYECZFEquhROqfA4ScFJHFf9zUb8wTBnrvUQ376 HpNKCmr8rpn0iCYGFn/X6z7k8SZUHrg+eFrvMeeHOvr2gKsiiZ2VKC2/E/9vmzDxzCz3 eCTaI/appHOFY0TctxL90y0kGV5epEfqrCQnoTsLvb5jfabRZSNUc/S0z0ESU5Chp07B h9KmvWPAdn9DlN6YhQCw5wrlMD+owDXY9qyF9vp8qU30K5ZJjIudg0cjwjiujtxHrk38 ThRaaDm5KMre+7NUZmLVg99EYyg4d89rBNzVvLQ8JD0I52bc/WJKZlYmcJC3doEoV3Ka c1Ew== X-Gm-Message-State: AOAM5318lzHTEcjRHcIu0it9cmwsmCnLI24SBvqmsUf7dSEEP9Sb3Exm Mnuv++WnIPgdakxB63wLccqLc5wwNOYOierbyjgOFA== X-Google-Smtp-Source: ABdhPJz8MSkcuQbEMnfTM/IYHW6vjlwVMFXs2JSF1Ph3wz9J44doOw2VG7bbm7zyojNsA6HXQheW9JRfHXMJdXxYhDo= X-Received: by 2002:a17:907:104a:: with SMTP id oy10mr20295968ejb.267.1595963903631; Tue, 28 Jul 2020 12:18:23 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> In-Reply-To: <947a50398cbb4bbcad85462a69d7dd45@huawei.com> From: Tom Herbert Date: Tue, 28 Jul 2020 12:18:12 -0700 Message-ID: To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:18:28 -0000 On Tue, Jul 28, 2020 at 1:36 AM Vasilenko Eduard wrote: > > Hi Tom, > Is APNIC a reliable source for you? > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > RIPE has replicated it here: https://labs.ripe.net/Members/joel_jaeggli/i= pv6-flow-label-misuse-in-hashing > "Cases have been observed where devices that connect to hashed endpoints = do not in fact honour this behaviour. By in large, this flow label changing= behaviour has been traced to IPv6 supporting CPE/firewalls, which change t= he flow label between the initial syn and the ack." The rationale for this is: "The use of the flow label as a hash element for any stateful application requires that the flow label remain unchanged over the life of the flow.". This is really directed towards stateful intermediate nodes like stateful firewalls. Yes, it's true that they will break if the flow label changes in flight. On the host, we've tried to ensure that the flow label is consistent for the lifetime of the flows, I don't know what firewalls are doing in changing them. > They have disputable conclusion: "Avoid using the flow label as a hash co= mponent". This guidance could just as easily be "Avoid fragmentation", "Avoid using any protocols other than UDP or TCP", "Avoid using extension headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using encryptions" as any of these can break some meddling device somewhere such that packet delivery becomes unreliable on the Internet. More generally, the guidance could simply be "Avoid doing anything that disrupts the status quo"! > > Additional corner case: https://github.com/pypa/warehouse/issues/5454 > > Eduard > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 22:24 > To: Vasilenko Eduard > Cc: Fernando Gont ; IPv6 Operations ; draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extens= ion Headers - Load Balancer > > On Mon, Jul 27, 2020 at 11:05 AM Vasilenko Eduard wrote: > > > > Hi Tom, > > I believe that risk still exist that some application would no use flow= label properly. > > Exactly which applications are you concerned about? > > > Hence, it is better on LB to deep dive into UDP/TCP. More predictable/r= eliable result. > > You seem to be assuming a very limited traffic profile that consists only= of plain UDP/TCP packets. Any use case that deviates from that then breaks= your LB (i.e. encapsulation, tunneled encryption, SCTP, IPSec, etc.). Flow= label is in all IPv6 packets and is mostly set properly for the vast major= ity of packets on the Internet and processing it is completely independent = of the protocols, so when taking the full scope of the problem into account= it is actually more generic and more predictable/reliable. > > Tom > > > Eduard > > -----Original Message----- > > From: Tom Herbert [mailto:tom@herbertland.com] > > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 17:15 > > To: Vasilenko Eduard > > Cc: Fernando Gont ; IPv6 Operations > > ; draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > > Subject: Re: [v6ops] Operational Implications of IPv6 Packets with > > Extension Headers - Load Balancer > > > > On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard wrote: > > > > > > Hi Fernando, > > > Hence again, following the logic of this draft (the level of detaliza= tion that you have given to 5.1) - may be you need additional section 5.1.x= : Load Balancer have to look into TCP/UDP ports. Moreover, it could not tru= st "Flow label" - it is not reliable practice for LB. > > > > Eduard, > > > > What exactly does "not reliable practice for LB" mean.? If this means t= hat the flow label might change during the flow's lifetime then I will poin= t out that UDP is equally unreliable for that reason (i.e. > > the UDP ports for a QUIC connection can change during the connection's = lifetime). For that matter, a TCP header might be encrypted or in an encaps= ulation that the LB doesn't understand so the LB can't access the TCP ports= at all-- in the this case the flow label is actually more reliable than TC= P since it's never encrypted and is purposely designed to be consumed by in= termediate nodes without the need for expensive DPI. > > > > Tom > > > Or alternatively you could say something about LB in section 5.1.2, > > > but because it is a little special case - may be better to have > > > separate 5.1.x > > > > > > Eduard > > > -----Original Message----- > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando > > > Gont > > > Sent: 26 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 8:46 > > > To: IPv6 Operations > > > Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org > > > Subject: [v6ops] Operational Implications of IPv6 Packets with > > > Extension Headers (Fwd: New Version Notification for > > > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt) > > > > > > Folks, > > > > > > We have posted a rev of our IETF I-D "Operational Implications of IPv= 6 Packets with Extension Headers". > > > > > > The I-D is available at: > > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packe > > > t- > > > drops-04.txt > > > > > > Your feedback will be appreciated. > > > > > > Thanks! > > > > > > Cheers, > > > Fernando > > > > > > > > > > > > > > > -------- Forwarded Message -------- > > > Subject: New Version Notification for > > > draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > > > Date: Sat, 25 Jul 2020 22:28:50 -0700 > > > From: internet-drafts@ietf.org > > > To: Fernando Gont , Gert Doering > > > , Geoff Huston , Warren Kumari > > > , Nick Hilliard > > > > > > > > > A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt > > > has been successfully submitted by Fernando Gont and posted to the IE= TF repository. > > > > > > Name: draft-gont-v6ops-ipv6-ehs-packet-drops > > > Revision: 04 > > > Title: Operational Implications of IPv6 Packets with Extensi= on Headers > > > Document date: 2020-07-25 > > > Group: Individual Submission > > > Pages: 15 > > > URL: > > > https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packe > > > t- > > > drops-04.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-dr > > > op > > > s/ > > > Htmlized: > > > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-0 > > > 4 > > > Htmlized: > > > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-pack > > > et > > > -drops > > > Diff: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-= d > > > ro > > > ps-04 > > > > > > Abstract: > > > This document summarizes the security and operational implication= s of > > > IPv6 extension headers, and attempts to analyze reasons why packe= ts > > > with IPv6 extension headers may be dropped in the public Internet= . > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of sub= mission until the htmlized version and diff are available at tools.ietf.org= . > > > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > > 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 nobody Tue Jul 28 13:03:36 2020 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 8E96A3A0C08; Tue, 28 Jul 2020 13:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWlSTsGUzqME; Tue, 28 Jul 2020 13:03:32 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320084.outbound.protection.outlook.com [40.107.132.84]) (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 40A943A0BF8; Tue, 28 Jul 2020 13:03:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HWtmVrwb91qMJBlU6cXDu8NjZiH3K2QJzhLwHKm4JlY9eBy7vy0u7gA9fp+dfD3YRK+bYVLRQIhjXG8SW4mlapk1iqk+YMThqx85g7pfBdhiixvZyn+i/rli6Y3eLPT+0ukdRtxlXoPqLtk/Lz4BRkQnI4DJRgLeYnF3Bhzqq3LkKNY5JI0uRYnNmPf/fEttNY1kd/OBAZ9pf5uu/n3/NCE+nT5s2CwA2lV+lDwUvh+hPZzo/nYDZrTySBjqwPLaqCgjCjy2AtmTAyxO7h4/mKmCvWE4glshKHdEKJEvwx7O6nptYH5FyiZFV91X0UlKdhSnE4bg9LEQ+DlJiKHQrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tJAYiV6uZJ1T5ii0Bj6iQ2onZ9M4hd/clk93qrN8Xfk=; b=KZZCDfraATm+ffpL5YH8OemS0M+c5X8DZtgSl4gvs015R+B+c4sdShAs/8uebEraoVpYWt4b0zXQIKxtSXhlh1dZ31gzO9jJ5NQufMnQd2YAyDpFpu8+lk6AjxmFWXSMsbj90+q0/9A5Lxhlk3lkMHPoIkE2JCaOwnr6LhuRe56lFEurhmYQ6KHbaM7X9cY8tY7ZLoNp0uPj3Edzq4kHHLtLzYyvovB49oyh0eKJsz0bi4GZIkjAn2M9DtsgoRKZHX4Es8CNOHOuqzyC1EZRjFsGX5ZhJOuV3CbgNN6kbQD0QrplAQ9FNfYcSdw6j0ScQ4MCaERJt4tJolmF7dja3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tJAYiV6uZJ1T5ii0Bj6iQ2onZ9M4hd/clk93qrN8Xfk=; b=Eztifay+uQv4Uwmlbqpc0TywIib0qcai9DVhFn1K2G8AjwCU8/O1FwYRjHkF11lamYdf2ppSUdDwGtJCWSWq6ULikZSlJpECbabgUtC4HtOQENmxJCpTH2FTJGdransAR5LciAORePnT758yrr1qPaEaJmABpyAb01JTa/Vxydo= Authentication-Results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=apnic.net; Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TY2PR04MB2624.apcprd04.prod.outlook.com (2603:1096:404:52::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Tue, 28 Jul 2020 20:03:28 +0000 Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24%6]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 20:03:28 +0000 Content-Type: text/plain; charset=utf-8 From: Geoff Huston In-Reply-To: Date: Wed, 29 Jul 2020 06:03:21 +1000 Cc: Vasilenko Eduard , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> To: Tom Herbert X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ClientProxiedBy: SYBPR01CA0193.ausprd01.prod.outlook.com (2603:10c6:10:16::13) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:44b8:110b:5100:25d3:b479:68c3:74b5] (2001:44b8:110b:5100:25d3:b479:68c3:74b5) by SYBPR01CA0193.ausprd01.prod.outlook.com (2603:10c6:10:16::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Tue, 28 Jul 2020 20:03:26 +0000 X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Originating-IP: [2001:44b8:110b:5100:25d3:b479:68c3:74b5] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 43dfd326-8549-48d7-9d00-08d833314aee X-MS-TrafficTypeDiagnostic: TY2PR04MB2624: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EaCLrN1Fjt9jtxb7U8GMY86BfXwwftEaRHP9Xfj6PlwWxAGTsaMd84CN3EJAZeDYKgssf/0BNFYiz/JVKYn9c9za+k5ZGjCOMsedYBZUg0CqthYdoT7COeazOGG9+nejFBj328l7Mt8HL2IAPvsBdUCKNAGKt1GNgSrVCxP8CYmzmUSNY7zJ8w7dqPvjcNPdZFGqOXXWsrHGeEn8V/q32DWxuynMb3ZkeH7lStHcKG8l1BbqP++vpjc3t65qFnDmkDHYQbs9DYWcuYMPt/XQ+6AuUB+m7M+rFeVmvzZpFlAgRhuVS1qe6wqzTrSzWgpnpImSuOpkelMeQ5iBsR23uA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(376002)(39850400004)(396003)(86362001)(36756003)(66476007)(66556008)(6916009)(52116002)(66574015)(508600001)(316002)(53546011)(6666004)(6486002)(186003)(5660300002)(8676002)(16526019)(2616005)(4326008)(8936002)(2906002)(66946007)(54906003)(33656002)(4744005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: xBlZhLGT9EqFP6kI+a3CLIrvedBskTJ/5Vw1l8W3e+Y2fSq3hf247OXqRCrqe8Va6ZgZFK59nOK/MFvmYyrllbV/zoSl9ydaHrNzNPxW7fU16YlxOYbtsk99XgDfnrxNKaQ4JUizjFo2sBVl3iqGoZXJpgJ6rrelITBa6zkFcUCg8MklTcSb1fDyzIScedj16EIg9PXKMmqA8/gdeyFKatATZy7K554uFNtVYKlVIvwe2nhuH3WOp/RFEHDQiblg9VTmYagG/hgbclC+UyC0gnIO1fc6NaOgZt0ml0u/hqDI6TVQsQ0sEX1Gzg3iJRJFw4R1CxcZN/2Z6rsOGNULnahDO9E++2a17kfTeTO4oP5LUNuKeqoltRmUbN48hWwBx5AxdwJSm2mFdW/DhddQDWC5HD0gGSwXtkHCfvNRSgWfWJtx3eRoEAQJxcCo8pS5Elea55cHCNC2JABgSCHCIBXyVT3P2nqStNrzEgQPyz81AyN2b71UuC/3srlbxRSOV6avG5CeO8D0V2YJrjQIsI6CoFvV5stYaqZnWHsLXuitGpl3KP/iqD/yqYL5H2JY X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: 43dfd326-8549-48d7-9d00-08d833314aee X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 20:03:27.8409 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yS1FGDpbzQDFqO+XNrrga8XpfetszdG8lkOX50tyyLITag/aPYvjBdOAdqfTKZKG X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR04MB2624 Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:03:35 -0000 > On 29 Jul 2020, at 5:18 am, Tom Herbert wrote: >=20 >=20 >=20 >> They have disputable conclusion: "Avoid using the flow label as a hash c= omponent". >=20 > This guidance could just as easily be "Avoid fragmentation", "Avoid > using any protocols other than UDP or TCP", "Avoid using extension > headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using > encryptions" as any of these can break some meddling device somewhere > such that packet delivery becomes unreliable on the Internet. More > generally, the guidance could simply be "Avoid doing anything that > disrupts the status quo=E2=80=9D! It all depends on the motivation Tom. If the motivation is =E2=80=9Cmaximis= e the likelihood of successful packet delivery on transit paths across the public= =20 Internet", then yes, all these are relevant considerations. And your point is? Geoff From nobody Tue Jul 28 13:20:25 2020 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 2D1453A0B45; Tue, 28 Jul 2020 13:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IKlftrBSrQF; Tue, 28 Jul 2020 13:20:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D003A0B3D; Tue, 28 Jul 2020 13:20:18 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F259C280C63; Tue, 28 Jul 2020 20:20:11 +0000 (UTC) To: Tom Herbert , Vasilenko Eduard Cc: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> From: Fernando Gont Message-ID: <3bc2b2a1-4f52-6ee0-87de-0a3198186f07@si6networks.com> Date: Tue, 28 Jul 2020 16:47:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:20:23 -0000 On 28/7/20 16:18, Tom Herbert wrote: > On Tue, Jul 28, 2020 at 1:36 AM Vasilenko Eduard > wrote: >> >> Hi Tom, >> Is APNIC a reliable source for you? >> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ >> RIPE has replicated it here: https://labs.ripe.net/Members/joel_jaeggli/ipv6-flow-label-misuse-in-hashing >> "Cases have been observed where devices that connect to hashed endpoints do not in fact honour this behaviour. By in large, this flow label changing behaviour has been traced to IPv6 supporting CPE/firewalls, which change the flow label between the initial syn and the ack." > > The rationale for this is: "The use of the flow label as a hash > element for any stateful application requires that the flow label > remain unchanged over the life of the flow.". This is really directed > towards stateful intermediate nodes like stateful firewalls. IIRC, FreeBSD used to change the Flow Label during the TCP 3WHS vs data transfer phase... >> They have disputable conclusion: "Avoid using the flow label as a hash component". > > This guidance could just as easily be "Avoid fragmentation", "Avoid > using any protocols other than UDP or TCP", "Avoid using extension > headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using > encryptions" as any of these can break some meddling device somewhere > such that packet delivery becomes unreliable on the Internet. More > generally, the guidance could simply be "Avoid doing anything that > disrupts the status quo"! Unfortunately, if one is in the "business" of getting data through, one would rather stick to whatever works. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 28 14:38:57 2020 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 0A40F3A090B for ; Tue, 28 Jul 2020 14:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usWxM5Wd3w5s for ; Tue, 28 Jul 2020 14:38:52 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C0A3A090D for ; Tue, 28 Jul 2020 14:38:52 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id z17so15873344edr.9 for ; Tue, 28 Jul 2020 14:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qfl2RgJzXOOjstkCpBepRkCWDrGxNZbOa7G2MPWWn5A=; b=yI8DTcgVHBlab3K8oGftOyx37jvnjhISPzD/anzkCR79Hld7TlPeLou9RLXdAqLLd1 ZyfM6zQ7ft7ZYxuR1Aysqzb3UsLKlgqK3KOEG8JmMNVuGy3FufWGHWcyC0mFQLYdlDj9 em3KAPve6rrQSyQ8L5IZmeKcU2Qu0BvADnZYsDDAuUD7jWcechGVk+SMwqBT+S95MGO2 XN9+EdxhCYwjTMs4jn8ZKSJipxrLtcsVb/n/Vla2XeXexv2B7kcWi0Crxm+Cr3PbxXH9 RX+5q4wAYeg5ZO5xeFqmkHBdTRFwcW0HgNG9rBpiB/PkZs8ZoRbpvKaVBeIciDU0AkwQ PUqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Qfl2RgJzXOOjstkCpBepRkCWDrGxNZbOa7G2MPWWn5A=; b=rOxlDg//xorUSV5Ry99xFT2oQkfSDuaVxUq7A98vtNpCFytkAV9rVbU84RdNack7nV Drlj1RlSTRbqG54OJJME7qFGryw6yCKuVSY/wTd1CSxv/OfEUBiOi2RvGXv6qHh65w4Z BRfWjVW32NY/ARIvN04kuTEiCtoUP2IZakFLgCUk3yimfs5u/ESApFt3nAeaYM1kC4PN UvpHMhmq+33PZkxglZdRrXU18Z2HLjLxdUJCssQXw4FgQ2Z3F4mo0dWxovDxGwy9kmYF 4BHoRcc8DB6MCMeVDO0SOvFInBz3B9TPLImth9mdGCsnRdeGreqBvMr40wURnpAJmO5q O2ng== X-Gm-Message-State: AOAM5320XzL1I5MTU68tppkdaICSmX+ChJsa1bgBFz+i6MZaJ5Prim6T XwK7rob1KadXcyeemO/bVds5qXFiRGA5au3qyVbj1w== X-Google-Smtp-Source: ABdhPJydNEX7jzdH9uP2DmVNFGs69qaNtN3q2be4UV7GERPuAs/9CSA3q9t+D2n0FmzBmxXZQeH57oWhaKSUArmsKV0= X-Received: by 2002:aa7:c2c6:: with SMTP id m6mr13226134edp.118.1595972330371; Tue, 28 Jul 2020 14:38:50 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <3bc2b2a1-4f52-6ee0-87de-0a3198186f07@si6networks.com> In-Reply-To: <3bc2b2a1-4f52-6ee0-87de-0a3198186f07@si6networks.com> From: Tom Herbert Date: Tue, 28 Jul 2020 14:38:38 -0700 Message-ID: To: Fernando Gont Cc: Vasilenko Eduard , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:38:55 -0000 On Tue, Jul 28, 2020 at 1:20 PM Fernando Gont wrote= : > > On 28/7/20 16:18, Tom Herbert wrote: > > On Tue, Jul 28, 2020 at 1:36 AM Vasilenko Eduard > > wrote: > >> > >> Hi Tom, > >> Is APNIC a reliable source for you? > >> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > >> RIPE has replicated it here: https://labs.ripe.net/Members/joel_jaeggl= i/ipv6-flow-label-misuse-in-hashing > >> "Cases have been observed where devices that connect to hashed endpoin= ts do not in fact honour this behaviour. By in large, this flow label chang= ing behaviour has been traced to IPv6 supporting CPE/firewalls, which chang= e the flow label between the initial syn and the ack." > > > > The rationale for this is: "The use of the flow label as a hash > > element for any stateful application requires that the flow label > > remain unchanged over the life of the flow.". This is really directed > > towards stateful intermediate nodes like stateful firewalls. > > IIRC, FreeBSD used to change the Flow Label during the TCP 3WHS vs data > transfer phase... > Fernando, We had an issue in Linux where the Flow Label can change when closing. This was causing bad interaction with FW. We treated this as a bug and fixed it promptly and now flow labels should be consistent for the lifetime of the flow. Software implementation can have much faster turnaround time to fix issues and I am still hoping, perhaps naively, that with the emergence of SDN and programmable datapaths in devices we can start to get that ability in other network devices and start to address some long standing issues of protocol non-conformance. > > > > >> They have disputable conclusion: "Avoid using the flow label as a hash= component". > > > > This guidance could just as easily be "Avoid fragmentation", "Avoid > > using any protocols other than UDP or TCP", "Avoid using extension > > headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using > > encryptions" as any of these can break some meddling device somewhere > > such that packet delivery becomes unreliable on the Internet. More > > generally, the guidance could simply be "Avoid doing anything that > > disrupts the status quo"! > > Unfortunately, if one is in the "business" of getting data through, one > would rather stick to whatever works. > Yep, this has driven host implementations to support the least common denominator in protocols. The only general workaround of protocol ossification to date is encrypting as much of the packet as possible like in QUIC, but when we do that networks visibility is reduced as is the opportunities for hosts and network to work in concert to solve users problems. Tom > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Tue Jul 28 16:11:42 2020 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 C344E3A0A7D; Tue, 28 Jul 2020 16:11:38 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E49mzpkzcHam; Tue, 28 Jul 2020 16:11:37 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DE23A0A8C; Tue, 28 Jul 2020 16:11:37 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id j19so13153768pgm.11; Tue, 28 Jul 2020 16:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PIe6LDDWhUTyl4BlbBZotFuiNOWbpUKIja57ORS2TGk=; b=hiAg9R6qYrXyrNMulDG+uYfJdseEOVNR3XpRdJuKYrrTYuC8UlKfb28SpytMor4kbI EhCYy0ugq39U7NSSIUIkOMs5kc8NhfOxXntKV1B1txCNuhOmPMBG2O7S3O930+u4mqF2 40AOJRSq/FbsvEg0Byp33e0QtUELOA1uBpN9S9rOjAMkxsvSwxLUTC7+iV6IOriN7l9z ++kj9CtQNlCENIeEl6M61Lul5KFHJqyxll/aCkL0yOQA2hTb1fhIZ3hlw0ueXdK575Ar vnD1hb1JFg29WLA3W5jMyLwnbBm2fRxPhyXKY+zflfoNf5dHe9ui/uEx50nQ4OQEZ4JX rLEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PIe6LDDWhUTyl4BlbBZotFuiNOWbpUKIja57ORS2TGk=; b=fnH3m7uHYIfXMZXqyFB5A2E6o18fZGafeJK1Tr03w8/MVLkjJdgfyR6hTjZjqVbWZt Jf5ZUgxgWHKjhD7xnHI72tKhu+u7MHaLuQzYIUe+8Ak3EL7k+L3gRpXo5ckG7meSqRjQ +UFAJjy6KQBessGnSOhPegUfY+DK9slqpRfCl6FuviXUHOJ+zErZs/MmI49r2p17cRv3 RtwA3Cc6fjgzkNSjRlDc8nt/nR6Cw5mkyb8aEKsrlaFJtmloe3EB74FVcW932LB+wxTm bATMyfiLO6kAsFZyMVmURwpEp2BMpd3/73+rM08Z5IIncmFs17OzVagy2gBi2W3EUJqw wQ/w== X-Gm-Message-State: AOAM533TxhNjRXY99z5uz7Ni6im2xipMhnW3C23x9QqOLTdDqrBSbz34 t5DtbK53kkrZ23KllGiZ86WGPEOq X-Google-Smtp-Source: ABdhPJwVCSec7TzGOpmFbMGA8C2hUs7ja1n+Nf3MwUsISc0BG8BQhlhfeCbhxb1xcwzfN3xLZrtECg== X-Received: by 2002:a63:4545:: with SMTP id u5mr26144588pgk.229.1595977896272; Tue, 28 Jul 2020 16:11:36 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id s89sm208453pjj.28.2020.07.28.16.11.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 16:11:35 -0700 (PDT) To: Geoff Huston , Tom Herbert Cc: Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> From: Brian E Carpenter Message-ID: <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> Date: Wed, 29 Jul 2020 11:11:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 23:11:39 -0000 Hi Geoff, We can do two things in the IETF: document reality, and try to make the best standards and guidelines we can. Unfortunately these two goals are sometimes contradictory. On the "document reality" side, thanks for your pointer. And that sort of factual input should probably be used in v6ops work starting with "Operational Implications...". But I believe that at the same time we need to do as much as we can on the standards & guidelines side of the house to make reality better in the long term. That was rather the point of RFC7098. Middleboxes that gratuitously change the flow label are faulty. That needs to be spelled out again, apparently. Regards Brian On 29-Jul-20 08:03, Geoff Huston wrote: >> On 29 Jul 2020, at 5:18 am, Tom Herbert wrote: >> >> >> >>> They have disputable conclusion: "Avoid using the flow label as a has= h component". >> >> This guidance could just as easily be "Avoid fragmentation", "Avoid >> using any protocols other than UDP or TCP", "Avoid using extension >> headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using >> encryptions" as any of these can break some meddling device somewhere >> such that packet delivery becomes unreliable on the Internet. More >> generally, the guidance could simply be "Avoid doing anything that >> disrupts the status quo=E2=80=9D! >=20 >=20 > It all depends on the motivation Tom. If the motivation is =E2=80=9Cmax= imise the > likelihood of successful packet delivery on transit paths across the pu= blic=20 > Internet", then yes, all these are relevant considerations. And your po= int > is? >=20 > Geoff >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Jul 28 16:50:20 2020 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 F370D3A0B98 for ; Tue, 28 Jul 2020 16:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNxiSfoH6XrN for ; Tue, 28 Jul 2020 16:50:16 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A133A0C0E for ; Tue, 28 Jul 2020 16:50:15 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id g19so8605050ejc.9 for ; Tue, 28 Jul 2020 16:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FsgjX02VySKcHdX9vX+5b/5Lh1dz9Be7OgBC3WyPn1U=; b=C+ufBnVrOmq9BGnhXIjzM2DepZEWMwsydxWc+V8qmk+gE84oLPz6Rz3AvNhiLFJOQ9 6PmJ5pfUsxjPXtm2JBfNVY14FA/B5WLav8UCv5i0JeUmZT7HZDzStr7IGz2VcyoT6xY7 0+QKPClIQqB3S1VHbbZUsR0RLzUMVG9OmvfANu5TyJD9KJmRKTlTfwX+hwyd3yvuIUtw ORDkede6HlKzeXlIL341/8VO5DyOOva4CGDEfx6qbWiOnl2H65jPsaeqexRglwny4W7e FBghZl+hkLSeHRoUowAuEEWudnytsGJUAq7LjoqkkBmZ0xNYqCBFGNun1smsj4S8ODY4 Kd6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FsgjX02VySKcHdX9vX+5b/5Lh1dz9Be7OgBC3WyPn1U=; b=c3oEzaGTHVmLNiCWRoyVLaaraTXVRUrriPA3fnVtXDL1sNJoZgUFM+t7u/gJDzXOcC z2GcdOnuaMgH1IMgFTRQkX39SG3AuQvPKx/E7tOSlvl6Pw8oCpB+lWx7Hwcjw+X0G1LA 6N6qmPQ7ent+XKMEuq0qnNWSl7qFi0zpP0MXPqUwIPIllMC+jIyT+4ZdvByNCy9qIBOl yNAwQ5Vfjs355hdLj9CvMYyKZuDSqFllwIFJqStURg4QmjGGb2+a+jxhdN/er/HelQrr AVYN0NIGNTl1JuN9F0IaIGBx8KyJjog9H86atj9Rb/fjlocE0eOya9fhho5XghSzgk9S 56YA== X-Gm-Message-State: AOAM531FU2IMT845rB8Ozz3l+jjfeYdBJuTnoEZ/QmOSvJMjEKQdhao0 YYtGdg1jbxQYvRGKlvOMrXQUZPRsE1AHH1BpQpPtOQ== X-Google-Smtp-Source: ABdhPJzs/02IMdErnq4X+VAc5J2WOIVsLhAf8+S+unDW542i1LjEsE1dqb7ZhJIfzR92zOVnyezAnZ0Pzn0zDrh2J08= X-Received: by 2002:a17:907:104a:: with SMTP id oy10mr21210341ejb.267.1595980214216; Tue, 28 Jul 2020 16:50:14 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> In-Reply-To: <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> From: Tom Herbert Date: Tue, 28 Jul 2020 16:50:02 -0700 Message-ID: To: Brian E Carpenter Cc: Geoff Huston , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 23:50:19 -0000 On Tue, Jul 28, 2020 at 4:11 PM Brian E Carpenter wrote: > > Hi Geoff, > > We can do two things in the IETF: document reality, and try to make the > best standards and guidelines we can. Unfortunately these two goals are > sometimes contradictory. > > On the "document reality" side, thanks for your pointer. And that sort > of factual input should probably be used in v6ops work starting with > "Operational Implications...". But I believe that at the same time we > need to do as much as we can on the standards & guidelines side of the > house to make reality better in the long term. That was rather the point > of RFC7098. > > Middleboxes that gratuitously change the flow label are faulty. That > needs to be spelled out again, apparently. I agree. My feedback on the APNIC guidance would be to ask if before recommending to disable a core protocol feature in an Internet standard, did they try to identify the malfunctioning devices and ask the responsible parties to fix them. Tom > > Regards > Brian > > On 29-Jul-20 08:03, Geoff Huston wrote: > >> On 29 Jul 2020, at 5:18 am, Tom Herbert wrote: > >> > >> > >> > >>> They have disputable conclusion: "Avoid using the flow label as a has= h component". > >> > >> This guidance could just as easily be "Avoid fragmentation", "Avoid > >> using any protocols other than UDP or TCP", "Avoid using extension > >> headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using > >> encryptions" as any of these can break some meddling device somewhere > >> such that packet delivery becomes unreliable on the Internet. More > >> generally, the guidance could simply be "Avoid doing anything that > >> disrupts the status quo=E2=80=9D! > > > > > > It all depends on the motivation Tom. If the motivation is =E2=80=9Cmax= imise the > > likelihood of successful packet delivery on transit paths across the pu= blic > > Internet", then yes, all these are relevant considerations. And your po= int > > is? > > > > Geoff > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Tue Jul 28 17:45:31 2020 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 361943A0D8B; Tue, 28 Jul 2020 17:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJkrb9kzcE_B; Tue, 28 Jul 2020 17:45:28 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320053.outbound.protection.outlook.com [40.107.132.53]) (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 B6CF73A0D7A; Tue, 28 Jul 2020 17:45:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gL9GYwc51yngRHNCDftKs55Br6qDZ3mfLNCVbKjpEyDThTMpWGp9XgtkfEHThcrz+XFn7u529D61rKQ0w8mNk9dEF6epfgN+Y+sxmGPeZ2mPFJ11drecPk39a2/K8N14UyegMQLmE2w5ulNGFATzsE3k1XYpSjAmTuY+z7NXkhFbEttJYXdWv7yyddwXb0tL15wTixb22lo+gHdT78Rf12A+s62GVPjnY1PD4UFCfrtsk8hcCnq/LJG4+2C+IVg0Z3Bmi+HiFgKy9oltyAPClJ3SAmQ1qR+OpIABzST1Qh6dv5G1AD3KD2AHuurHysquFa+nV30r58zVlw1Yk0KPvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pXEDJigJ7J92WXyiOdcEpz01fQZekMCDU+k2ap6wPiA=; b=MISjYUYI8Em5Fcxgt/L8Bql4I68j/OAjvqpx4SFK97gGSEqSWzrfUNIDdayhWfH+QnqFZhlEgsSvtMkX1UDh/mUxOh8b/5gNrs8ixBzKg+iFY9wAeIly0RGvk578E0n/3m8ZFid5hovulMg3SOTrzJYd6druldZrMooNxQ3ZXNsopZTl8vEOvx53D/j+dgXvSGVVXYgu1VAJa6/AMvDjh1kUt5cRhnlXEazd0soQwAZKITjQNvXq4etglmzThs4IFw9ztr//3O8K9LvP6UJPQUiVn+tBwCJiZGnLsnRgauz5MEzRLQ6Cvhc7D4jyWK3GjDvGaJFXxkOcOu5+520ZFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pXEDJigJ7J92WXyiOdcEpz01fQZekMCDU+k2ap6wPiA=; b=YxVDBmyOGs8iukneilpW7uDumCV8eWnwbHkt5pTcBAM8ag7rbpVQZxdf7EokQ4OkAbWkgh/3IzUEWiRNnRHyU1LunYVtMGxf3DQCPCrvpdPM68bUlNnR1hbask7M1ZsOZePESbWDrxID6P0bkvYM7wjZ2SOwLvxYAdTDFufbVGE= Authentication-Results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=apnic.net; Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TY2PR04MB2959.apcprd04.prod.outlook.com (2603:1096:404:35::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 00:45:25 +0000 Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24%6]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 00:45:25 +0000 Content-Type: text/plain; charset=utf-8 From: Geoff Huston In-Reply-To: Date: Wed, 29 Jul 2020 10:45:19 +1000 Cc: Brian E Carpenter , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ClientProxiedBy: SYCPR01CA0024.ausprd01.prod.outlook.com (2603:10c6:10:31::36) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:44b8:110b:5100:7430:4193:d6e9:1588] (2001:44b8:110b:5100:7430:4193:d6e9:1588) by SYCPR01CA0024.ausprd01.prod.outlook.com (2603:10c6:10:31::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.25 via Frontend Transport; Wed, 29 Jul 2020 00:45:23 +0000 X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Originating-IP: [2001:44b8:110b:5100:7430:4193:d6e9:1588] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 16483c5e-9b2f-4438-f083-08d83358ae5d X-MS-TrafficTypeDiagnostic: TY2PR04MB2959: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: me4tOBL553b/nXsP9+OEbtWUVOu5zOg7ilCwP41zLm4T6l1kWOx/+D9dGQ6rGBbZ5+ixLGCmEg2iO+iqClfbrbvCTr0wYS/xi0hcYxAjwkimY6diA8MOeAqoDzOHD8I/sVzvak63w0ptvbiAa/WcfzRDwrycgRjuVQU/N9HZNmuAKIgIsxoyfi7xvvhBb1RTUlTVrATWQxMFQxnxvLymahvIX8yspTXgvf7S3JM8GPoeMk7ls6MuvRkZZDUeZisfs5SsNtlGJUZXHjk7hnDLSTARDnN0b3NzFCIaJFzP1vXPS9s+IFcVxqoWw2MdM/RUVn3ZpsY9aeb11map/kOMbg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(6916009)(16526019)(66946007)(508600001)(186003)(66476007)(6486002)(66556008)(36756003)(53546011)(52116002)(2616005)(6666004)(54906003)(8676002)(8936002)(33656002)(5660300002)(2906002)(4744005)(86362001)(4326008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 0QdQiA6UMquE1LiMi1absSu/Kyq0VtAbGAa8kikyjQI6O22DCKE1Sdf8JBU6fUd8J5FI8BdtvoK8ohW0+gpug2Zug0auPxEXGSt3EY1+pwFlPPyUHXmB2x7EOqDIkDPNrVMmhSExHQwU8ccH43bqv8//VMe3H4IAt/Mx/+F9Otzg7/qy+huhwiRj06OZ4Yd5r7SNJdNECD5J6Roqvfy3ohmnAmobyNW3maDTOOGbc38U39Mr45qfDD5/Dr73+wArZPqlagRrdCDs0FzxRDc3SqzfAOf0OUHGTM6efYx8kzPBfU3/OwRI0OjdkUiwxxRvLBW9dkmCxqHtCSKAu3k8saaeiW5WFqF7hGiBpQv7BaM37ye3nsetzNnNxXarwTXl0oqOP9jMJjmhZfJYh0P8l5sqfLFVdawzVn9JAXPHFDtrUgZxxHiJVWHpkaLOC/okBz932f+2M9Piftp1yZcPSsCnND+py+2GDQrQMGrBFOlF0wPRIIREzSfGQVj8VPS4Fz8g0ZSZde8nu7oP5Av/bnhlSBYUMaYw2hyznJCrYZw= X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: 16483c5e-9b2f-4438-f083-08d83358ae5d X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 00:45:25.0334 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AuHzFRlcvrMEBtuWFFAoTu9t+9Y+58vSzd6RZ6cCUWA6J6xvkY8y/8E3ryEsMCJF X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR04MB2959 Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 00:45:30 -0000 > On 29 Jul 2020, at 9:50 am, Tom Herbert wrote: >=20 =E2=80=A6 >=20 > I agree. My feedback on the APNIC guidance =E2=80=A6. Oh please - APNIC publishes a blog that solicits contributions, and says clearly at the end of each of these articles: "The views expressed by the authors of this blog are their own and do not necessarily reflect=20 the views of APNIC.=E2=80=9D APNIC as a regional address registry has no views one way or the other as to what folk do with Extension Headers in IPv6 packets. Geoff = From nobody Tue Jul 28 18:20:28 2020 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 EBED23A0E1C for ; Tue, 28 Jul 2020 18:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JP_6u_rt8RD for ; Tue, 28 Jul 2020 18:20:25 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0829E3A0E16 for ; Tue, 28 Jul 2020 18:20:24 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id qc22so7787661ejb.4 for ; Tue, 28 Jul 2020 18:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R0tZaJsjWKlXEy3m5wrTkRPdJRY4ZnfeaqWZZmcSDfs=; b=SV/0wGZpO6DfIJzj4PYhMwh5W3Tu5anjvy1eijmWDKTw+qbGHbmjTSxhMEKqn2Oxg2 XHcYHpBTSP6IVTVzDZWz8F4IF6lP93ds4Yu62c4EBPTepJnEuzj5VbbWv9ZMLpFbSx9m pyQ9KIFIWQEPEIPkmTSZueqkz9yaOvMwa1JqfzBhr702bP2zHmWJCnEBZucIos5/Mr7U RpxlW5eLOdWHjMz0LuB5/ezkBoIZj1kcof2RRlNgLbSqCKv5QG+ptWTdX9XtQSRCUvmp 89C2istyoBey2b3J7oTTZPoooZ8lsywLK+DzBcktKadsdiiX/YY2MqpMSXOOZqDNXhvs RECA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R0tZaJsjWKlXEy3m5wrTkRPdJRY4ZnfeaqWZZmcSDfs=; b=DuOrKgm5gPNbmPW6XCOt+BhI8SoPFrBUPTAA+lpCbeTUsKozHY+MMNRCfE0JQ0svEx JOCSr8gytbPe6rN8ONpadF7axgv9U1PzE145745XDXJQpPWMrRsOyxYl92uGmTJGV5Zc L/ZElJRpOULTPKpHiNgNHjtXXeASvhNHfdQgOv1Lh+6O8l95xqw1Dl18eBo0iFYRpifw tVD8oKHoRsQhsWLqK2S1R+fACtBWbp1kbhVzv+YNmbeHFDCc/HbHyV0409r+SmXBCIgP 1Q/VYdO+vwbR1v4Kps3ulLRgHYfig2uU0LqDha/IVQ+qe8//K/TdYq4a1No3t0WiINmY sD5g== X-Gm-Message-State: AOAM533p0iCmHrQcfnoDVgNdxIi0CsZGM3N25tO7NtUlqV1gkPpPtwBf 4H1OfV040ewnVUlDK61KyAbqB1cECigBaYAzzJ9hRw== X-Google-Smtp-Source: ABdhPJwKyKneW/C3DnkaXPmFJqalKeT4OTKAeGxbBK3Y/iD6KIkAu3L0P0X4h3Objoxa63Bi21UKbSjrH8FaV5d05lI= X-Received: by 2002:a17:906:a242:: with SMTP id bi2mr27275976ejb.243.1595985623395; Tue, 28 Jul 2020 18:20:23 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> In-Reply-To: From: Tom Herbert Date: Tue, 28 Jul 2020 18:20:10 -0700 Message-ID: To: Geoff Huston Cc: Brian E Carpenter , Fernando Gont , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000026444b05ab8a5c40" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 01:20:27 -0000 --00000000000026444b05ab8a5c40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 28, 2020, 5:45 PM Geoff Huston wrote: > > > > On 29 Jul 2020, at 9:50 am, Tom Herbert wrote: > > > =E2=80=A6 > > > > > I agree. My feedback on the APNIC guidance =E2=80=A6. > > > Oh please - APNIC publishes a blog that solicits contributions, and > says clearly at the end of each of these articles: "The views expressed > by the authors of this blog are their own and do not necessarily reflect > the views of APNIC.=E2=80=9D > Thanks for the clarification! > APNIC as a regional address registry has no views one way or the other > as to what folk do with Extension Headers in IPv6 packets. > > Geoff > > --00000000000026444b05ab8a5c40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 28, 2020, 5:45 PM Geoff Huston <gih@apnic.net> wrote:


> On 29 Jul 2020, at 9:50 am, Tom Herbert <tom@herbertland.com&g= t; wrote:
>
=E2=80=A6

>
> I agree. My feedback on the APNIC guidance=C2=A0 =E2=80=A6.


Oh please - APNIC publishes a blog that solicits contributions, and
says clearly at the end of each of these articles: "The views expresse= d
by the authors of this blog are their own and do not necessarily reflect the views of APNIC.=E2=80=9D
=
Thanks for the clarification!


APNIC as a regional address registry has no views one way or the other
as to what folk do with Extension Headers in IPv6 packets.

Geoff

=C2=A0
--00000000000026444b05ab8a5c40-- From nobody Tue Jul 28 18:46:52 2020 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 D068F3A0E74; Tue, 28 Jul 2020 18:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDkO0vAG44ho; Tue, 28 Jul 2020 18:46:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BFD3A0E73; Tue, 28 Jul 2020 18:46:44 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A2009280278; Wed, 29 Jul 2020 01:46:40 +0000 (UTC) To: Tom Herbert , Brian E Carpenter Cc: Geoff Huston , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> From: Fernando Gont Message-ID: Date: Tue, 28 Jul 2020 22:45:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 01:46:49 -0000 On 28/7/20 20:50, Tom Herbert wrote: > On Tue, Jul 28, 2020 at 4:11 PM Brian E Carpenter > wrote: [...] >> >> On the "document reality" side, thanks for your pointer. And that sort >> of factual input should probably be used in v6ops work starting with >> "Operational Implications...". But I believe that at the same time we >> need to do as much as we can on the standards & guidelines side of the >> house to make reality better in the long term. That was rather the point >> of RFC7098. >> >> Middleboxes that gratuitously change the flow label are faulty. That >> needs to be spelled out again, apparently. > > I agree. My feedback on the APNIC guidance would be to ask if before > recommending to disable a core protocol feature in an Internet > standard, did they try to identify the malfunctioning devices and ask > the responsible parties to fix them. A problem with the assumption of "malfunctioning devices" is the assumption itself. It seems evident that the IPv6 packet structure makes a cost-effective implementation rather difficult. Since engineering does not only have to do with science, but also with economics, it follows that: * Folks (group #1) will not be willing to pay for features that their clients do not explicitly require. * Vendors (group #2) will not spend cycles on something which will not get them money in return. * Other set of folks (group #3) will not actively try to leverage features with a high failure rate, since they would also need to implement workarounds -- and if the workarounds already solve the problem, with a much higher success rate, there's not much of a point in spending time (and ultimately $$) in the feature that usually fails. * Users (group #4) use whatever solves their problem. We may be unhappy with the above fact. But unless we're willing to pay the bill :-), I'm not sure to what extent embarking into a Crusade would solve the "problem". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 28 21:03:37 2020 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 070333A0BE9; Tue, 28 Jul 2020 21:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaoDXZzR4COY; Tue, 28 Jul 2020 21:03:34 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443623A0BE5; Tue, 28 Jul 2020 21:03:34 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id p1so11207274pls.4; Tue, 28 Jul 2020 21:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wzcsuL8kfv6S4mekhDCfTmBfgLi/Egeb6A0Gjm2dx9s=; b=TSTK5NRS1r7bsG1KUnkPANvEx/BE54Cm4+eHPh5qlLb2g3DUP7ea1UnmE1PoD9XgHC XaQvaPywvB6Bw19/5MuGurx6NuPYBaal/mQIZEA6vf0al8LA9TowBNvMqabBy5jkqrU8 9k3X0FooJbT1Hhmu+mHUjLcTSuB36Stm2MmR9pP8f5L/PcUwEUsh3sjT+pRIQP/TKLOT 7U3DSO4zjLmcI8fsNcCEmQ8tbtdHlxyBsoZZijxfdp+sZWFjbcfWrerlBiJV1pf8FIux 5BFe0DME1++ZDSOzmFPLw+WeQWQyithUOtT5pOsbtyFThNfW3KtnufVjDbzml2BQ4eFp jcEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wzcsuL8kfv6S4mekhDCfTmBfgLi/Egeb6A0Gjm2dx9s=; b=bDoGYlRx0hDcnVGRohGhuZyFEa6mHq9J0EvOHID/d+CQOSV4Ne3x/gzMdxhxRw2U01 kc9KJlQrcjr/pD1pK/Y5r2UOmZ82v99nijZqgNVt4gHUUwkrqso6eq0BGHqv3B4GcdL0 a7btACDNkzGewNIzhSiDIMZAhArEuiCJDcEEwlQi1Z+xMm23MPuRtbIYE6RyKCefCESX TmWqPu0+HBp0LuM4241hb2M8uUb8jwAShVJIM/GS+l1Z6jMYwNa0D82DmMKFeZTLRq3x oLhy257FbRUWuPTka1CpwQxGtG8/hN/3xxEPhZZeNYPbcjNIzuRTNY3jnMdMgb+6fXt2 JW+g== X-Gm-Message-State: AOAM531vw6actK+3jmaf2l3iPDM+nUt9y9zNY3uuYGihDQL0jL9AuuRi xN6SbTgbOia7G3nsIwL1Nc/G+adJ X-Google-Smtp-Source: ABdhPJwc2anyn2uZT/X6j7tQQfpHx/9MeHcnhGbsxgUuZm66kqiLBp5evj+5yvXiu98y1SvekoE+9g== X-Received: by 2002:a17:902:a40f:: with SMTP id p15mr25359615plq.221.1595995413200; Tue, 28 Jul 2020 21:03:33 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id 9sm520576pfy.177.2020.07.28.21.03.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 21:03:32 -0700 (PDT) To: Fernando Gont , Tom Herbert Cc: Geoff Huston , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> From: Brian E Carpenter Message-ID: <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> Date: Wed, 29 Jul 2020 16:03:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 04:03:36 -0000 below... On 29-Jul-20 13:45, Fernando Gont wrote: > On 28/7/20 20:50, Tom Herbert wrote: >> On Tue, Jul 28, 2020 at 4:11 PM Brian E Carpenter >> wrote: > [...] >>> >>> On the "document reality" side, thanks for your pointer. And that sort >>> of factual input should probably be used in v6ops work starting with >>> "Operational Implications...". But I believe that at the same time we >>> need to do as much as we can on the standards & guidelines side of the >>> house to make reality better in the long term. That was rather the point >>> of RFC7098. >>> >>> Middleboxes that gratuitously change the flow label are faulty. That >>> needs to be spelled out again, apparently. >> >> I agree. My feedback on the APNIC guidance would be to ask if before >> recommending to disable a core protocol feature in an Internet >> standard, did they try to identify the malfunctioning devices and ask >> the responsible parties to fix them. > > A problem with the assumption of "malfunctioning devices" is the > assumption itself. > > It seems evident that the IPv6 packet structure makes a cost-effective > implementation rather difficult. Since engineering does not only have to > do with science, but also with economics, it follows that: > > * Folks (group #1) will not be willing to pay for features that their > clients do not explicitly require. > > * Vendors (group #2) will not spend cycles on something which will not > get them money in return. > > * Other set of folks (group #3) will not actively try to leverage > features with a high failure rate, since they would also need to > implement workarounds -- and if the workarounds already solve the > problem, with a much higher success rate, there's not much of a point in > spending time (and ultimately $$) in the feature that usually fails. > > * Users (group #4) use whatever solves their problem. > > > We may be unhappy with the above fact. But unless we're willing to pay > the bill :-), I'm not sure to what extent embarking into a Crusade would > solve the "problem". Not what I meant, really. All we can do here is write documents. So if the consensus is still what the standards track documents say, including Node Requirements, we have actually done our duty. And we have, in RFC8504: "All nodes SHOULD support the setting and use of the IPv6 Flow Label field as defined in the IPv6 Flow Label specification [RFC6437]. Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. It is RECOMMENDED that source hosts support the flow label by setting the Flow Label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution." After that it really is up to vendors and operators to do what is best for them. If it takes ten years for all products to meet the Node Requirements, so be it. Brian From nobody Tue Jul 28 22:55:50 2020 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 263FB3A0FDD for ; Tue, 28 Jul 2020 22:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxrT6p7mjokl for ; Tue, 28 Jul 2020 22:55:47 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81ADA3A0FDC for ; Tue, 28 Jul 2020 22:55:47 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id t15so1510335pjq.5 for ; Tue, 28 Jul 2020 22:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:reply-to:mime-version:subject :message-id:date:to; bh=2KdmrfjlTb/8VA+imm93LTzpYZKs6pfIaBzaLE5aCwA=; b=sw1+ZBxHbGBWdoWXxJWClmXhWeoeBUFtxTuS01EGGg4e8kB2XTZoALMgDGv3ZAhtBC UpSv76Iyy6mE1A0ZS1Cm7np+DDFLkt7BDfe9vxv/bubIN1AGNVC9kqJQlwH4A74gIx/I deUFT5apaQ0YuWJ0SlRjxL5J/cYITj3T08hqBqTFxfqLYfp+gOWsLFHFAI5MMP7w1x6v kswshAlNDtf91xdpGsrF5775BJuyeGofAZEehBXsWrAVZ9UYkyK+IY/+kdescb4FIrs4 YqnkIYkmnyPHDBpu4yBEHdd/jlm0dmp0R7TtP78U/1NrufPJRbpOCMQAMP1jo914MzAL uxVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:reply-to :mime-version:subject:message-id:date:to; bh=2KdmrfjlTb/8VA+imm93LTzpYZKs6pfIaBzaLE5aCwA=; b=B9NguMI570KxFl8C/v30p1w4UO5QlOuTv0A+0j9s/xySXxGp4zYV3ZHJ27UeNvMrNh M0u9OvPJOT2ON9OILrzLpteuv5oWRej+SASRL3Bw2JkgTigwxE/DInMCEayb5p6rjOsK +d7oIN9PPYFBgAUso2JodsqYgVSmYrHmcRXQHd1++MQtiDSHa8YAjA8NLl4F+mxcHW+L UZZjmXyWwJm8Hf4uEGE6/XwQyBGcrRFLa0F5EU2KTopIGRp3sIOVCU7RunmWYl9+q/Cv 2Shn9qmLKwrXmREd5u+ifgjjpYRMKfpudL2D0ifRvtsLM0fLmGSOJwd1V9DngduXQse9 fkGg== X-Gm-Message-State: AOAM5329qya0H8dFAhI/3XEiOrFwOw+EpmgSCYY7ePn+ZgdQ0kjCkbmM 0NnsuRrk7jtAm6wTA3ztcwY8GyuC8yA= X-Google-Smtp-Source: ABdhPJwTr07s0Dis2u1f9esPtR0HZY1uWqz8ZjYhu6VlPGdHBdR+9mJWYaUhKUPGEd6qkPVAYB61cw== X-Received: by 2002:a17:90a:a40d:: with SMTP id y13mr7988263pjp.110.1596002146541; Tue, 28 Jul 2020 22:55:46 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::1299? ([2600:8802:5800:652::1299]) by smtp.gmail.com with ESMTPSA id n2sm933779pfq.140.2020.07.28.22.55.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 22:55:46 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: V6Ops-Chairs Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <0A52BDF3-41AE-4A5C-A971-99D82769089D@gmail.com> Date: Tue, 28 Jul 2020 22:55:45 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 05:55:49 -0000 It looks like Fernando (et al) revised this and posted draft -04 on = Saturday, and there has been a flurry of discussion. I haven't been = through the document or the entire thread yet, but I do observe that a = number of people have comments, and several people have expressed = interest in the document. Let me ask the obvious question: you we want to adopt this as a working = group draft? I won't ask you to hum; whether you wish to say "yes", = "no", or "abstain", please reply to this email *privately* (which is to = say, to v6ops-chairs) with that word prepended on the subject line. I'll = give us 48 hours, which is to say that I will evaluate and state the = result Thursday evening Pacific time. = https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D%22draft-gont-v6ops-= ipv6-ehs-packet-drops%22 https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D%22Operational = Implications of IPv6 Packets with Extension Headers%22 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops "Operational Implications of IPv6 Packets with Extension Headers", = Fernando Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, = 2020-07-25, From nobody Tue Jul 28 23:14:15 2020 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 B37753A1005; Tue, 28 Jul 2020 23:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcL51014RtCN; Tue, 28 Jul 2020 23:13:57 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884623A0FF9; Tue, 28 Jul 2020 23:13:57 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 95772280974; Wed, 29 Jul 2020 06:13:52 +0000 (UTC) To: Brian E Carpenter , Tom Herbert Cc: Geoff Huston , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> From: Fernando Gont Message-ID: Date: Wed, 29 Jul 2020 01:59:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 06:14:01 -0000 Hi, Brian, On 29/7/20 01:03, Brian E Carpenter wrote: [....] >> It seems evident that the IPv6 packet structure makes a cost-effective >> implementation rather difficult. Since engineering does not only have to >> do with science, but also with economics, it follows that: >> >> * Folks (group #1) will not be willing to pay for features that their >> clients do not explicitly require. >> >> * Vendors (group #2) will not spend cycles on something which will not >> get them money in return. >> >> * Other set of folks (group #3) will not actively try to leverage >> features with a high failure rate, since they would also need to >> implement workarounds -- and if the workarounds already solve the >> problem, with a much higher success rate, there's not much of a point in >> spending time (and ultimately $$) in the feature that usually fails. >> >> * Users (group #4) use whatever solves their problem. >> >> >> We may be unhappy with the above fact. But unless we're willing to pay >> the bill :-), I'm not sure to what extent embarking into a Crusade would >> solve the "problem". > > Not what I meant, really. FWIW, I do agree with you. My comment was a response to Tom where he was objecting to folks that, for one reason or another, happen to drop packets. (in this particular case the advice given by JOel in his presentation) And what I meant is that rather that being mad about them, one should try to find the reasons for which they are resorting to that (which is what this document is meant to), and then figure out and do what we can from a protocol engineering perspective. > All we can do here is write documents. So if > the consensus is still what the standards track documents say, including > Node Requirements, we have actually done our duty. That's in part correct. However, for cases where standards track documents implementation become unfeasible or cost-ineffective, one may need to consider being more flexible and reconsider the spec. A good example was the IPsec requirement in an early revision of Node Reqs: it was words on paper that would never be complied with - so the spec was changed to reflect that. I'm not necessarily saying that this is the case here, but rather that that's an option that should be on the table. > And we have, in RFC8504: > "All nodes SHOULD support the setting and use of the IPv6 Flow Label > field as defined in the IPv6 Flow Label specification [RFC6437]. > Forwarding nodes such as routers and load distributors MUST NOT > depend only on Flow Label values being uniformly distributed. I retrospective, if it cannot depend on the FL (which I agree), is there much of a point in using it? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 00:31:51 2020 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 E4A2F3A0D3A; Wed, 29 Jul 2020 00:31:48 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REQVKfNjZxY2; Wed, 29 Jul 2020 00:31:47 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877C73A0D32; Wed, 29 Jul 2020 00:31:47 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id q76so696966wme.4; Wed, 29 Jul 2020 00:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vv/beJj8MfZaj0e/iPp8WSkobgJrj3loHRYgbnqu9QY=; b=hgCWZWHE1pn5Zs+FjJLLYkXRij/sXrzazH2iu+QlPXYjXHt1HxX1zDW1ZdIaeXVdS5 T4d3j/nfcc41WuF4jR/XKdqeTaSI+QAx5VWcG223QtUp+FN2YMaBHfIPgm8pj7Vpuvg7 9VkMHLMlwKC1+ZwvHvbb9yoO02fr4sWIW1wPUurF7lj1WKLW+9siUruALWEwRggcWK4I 6eKZM1SDDVUiQ4jTwjT+joyTid+BaozaNtwe6oUMpIWzP2hJ21R5Bhpu73r8UbK96Dv4 L3sFD3euaMEreW8NitVfJvfPBeEFa5mXenvoyWUyyvp8EXTGXMP9EwT0TI25pr2RggMw gSpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vv/beJj8MfZaj0e/iPp8WSkobgJrj3loHRYgbnqu9QY=; b=Uuv7KxTgai0aPwNBvVGy/AO1LV706ifH5QnvmSmZWAbXYYPmD49w1TQ0RVWyiWkgAH TZLOd57fRwqP0CRhqIePdAFEAGU/YfIr8FpruVvvC+7QwNecEw6vtshQHcBG2UdAxLW9 cLeC60L6QzP7F3Dza8DzGmY9RiWb1C0wUbogWGm/a+QjKTOTQyoLmOV50RGV6R0jJfb8 vRdi2ltQQ2ocziG59rJmCL3Ocana2KiLAI10qyErBfsQD/VX+yrKU/v2IajLIALyTEpt vvmKpKSx8Hvh7R0pU0r+OUYmIB0EBoEYBpYtoVXXxZlqxuehlI7Og0s0AmDfHS2awyo+ /R7Q== X-Gm-Message-State: AOAM533B+M4HYYPm3uoCaK67fTOzx5yQKaRJW5zct7CdU5c7auzCdtnc 9xm4FMYg1DnCqR7EPHCLSKY= X-Google-Smtp-Source: ABdhPJzokGRgghpTuwowcwrDes/l71hyQIU0RoBOGVnKTSE8x6hjGc0jUkkOD6Jb3NwE7QOtzDJDgQ== X-Received: by 2002:a05:600c:25cc:: with SMTP id 12mr7264209wml.120.1596007905929; Wed, 29 Jul 2020 00:31:45 -0700 (PDT) Received: from [192.168.0.21] (tchowndsl.claranet.co.uk. [212.188.254.49]) by smtp.gmail.com with ESMTPSA id t14sm3801230wrg.38.2020.07.29.00.31.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 00:31:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Chown In-Reply-To: <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> Date: Wed, 29 Jul 2020 08:31:44 +0100 Cc: Fernando Gont , Tom Herbert , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1938CB5B-B2CD-43DC-A24D-CE75BD56941E@gmail.com> References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 07:31:49 -0000 > On 29 Jul 2020, at 05:03, Brian E Carpenter = wrote: >=20 > >=20 > All we can do here is write documents. So if > the consensus is still what the standards track documents say, = including > Node Requirements, we have actually done our duty. And we have, in = RFC8504: > "All nodes SHOULD support the setting and use of the IPv6 Flow Label > field as defined in the IPv6 Flow Label specification [RFC6437]. > Forwarding nodes such as routers and load distributors MUST NOT > depend only on Flow Label values being uniformly distributed. It is > RECOMMENDED that source hosts support the flow label by setting the > Flow Label field for all packets of a given flow to the same value > chosen from an approximation to a discrete uniform distribution." >=20 > After that it really is up to vendors and operators to do what is best > for them. If it takes ten years for all products to meet the Node > Requirements, so be it. Worth noting that RFC8504 is the third iteration of the IPv6 node = requirements document, and what it says may and does change, partly as = new RFCs are published, partly with more operational experience. That said, the text above about flow label usage is the same in RFC8504 = as it was in RFC6434, so the guidance has been the same for at least ten = years or so. The flow label wasn=E2=80=99t explicitly mentioned in the = first node requirements document, RFC4294. Tim From nobody Wed Jul 29 00:59:25 2020 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 8F4353A0D23 for ; Wed, 29 Jul 2020 00:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwfT_PX4Uvka for ; Wed, 29 Jul 2020 00:59:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A5B3A0D22 for ; Wed, 29 Jul 2020 00:59:19 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 00F9D280B49; Wed, 29 Jul 2020 07:59:15 +0000 (UTC) To: Tim Chown , Brian E Carpenter Cc: IPv6 Operations , Fernando Gont References: <159574132870.611.12077598721404194383@ietfa.amsl.com> <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> <53a8e94d-dfc3-23f9-2dac-b70eb4f203a8@gmail.com> From: Fernando Gont Message-ID: Date: Wed, 29 Jul 2020 04:58:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 07:59:24 -0000 Hi, Tim, On 28/7/20 11:32, Tim Chown wrote: > Hi, > >> On 27 Jul 2020, at 21:51, Brian E Carpenter wrote: >> >> On 27-Jul-20 18:49, Fernando Gont wrote: >> >>> BTW... it seems that RFC7045 has not really been incorporated into >>> RFC8200? >> >> Well, yes and no. Firstly the point about HbH header processing >> being essentially optional was adopted. Similarly, RFC7045 says >> "This document updates RFC 2460 to >> clarify how intermediate nodes should deal with such extension >> headers and with any that are defined in the future." >> and that, I believe, is reflected in RFC8200. > > It may be worth pointing out that RFC 7045 was included in the IPv6 Node Requirements Maybe we can tweak the text to say something along the lines of: " A number of recent RFCs have discussed issues related to IPv6 extension headers, specifying updates to a previous revision of the IPv6 standard ([RFC2460]), most of which have now been incorporated into the current IPv6 core standard ([RFC8200]) or the IPv6 Node Requirements [RFC8504]). Namely," . . ? > - bis work and thus into RFC 8504, with the “nodes SHOULD forward packets regardless of EHs present” text repeated there. > > EH-related requirements in RFC 8504 are explicitly covered in https://tools.ietf.org/html/rfc8504#section-5.2. By the way, our working copy says: "[RFC8504] specifies processing rules for packets with extension headers, and also allows hosts to enforce limits on the number of options included in IPv6 EHs." Maybe we should say s/specifies/clarifies/ ? FWIW, I don't mind noting “nodes SHOULD forward packets regardless of EHs present”, but in a way wouldn't that misrepresent both RFC8504 and RFC7045 a bit, which essentially elaborate on the caveats for the SHOULD (and hence are way more than to eartg that RFC8200). Thoughts? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 01:07:05 2020 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 DAC6C3A109F; Wed, 29 Jul 2020 01:07:02 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBx1j7OJcaah; Wed, 29 Jul 2020 01:07:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 59C093A109E; Wed, 29 Jul 2020 01:07:00 -0700 (PDT) Received: from lhreml723-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 046CC78CE9C509DCF69B; Wed, 29 Jul 2020 09:06:59 +0100 (IST) Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml723-chm.china.huawei.com (10.201.108.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 09:06:58 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 11:06:57 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 29 Jul 2020 11:06:57 +0300 From: Vasilenko Eduard To: Fernando Gont , Brian E Carpenter , Tom Herbert CC: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer Thread-Index: AQHWZCBNgvrnr0hITbeSprlQeXLX06kbuR9A///jMoCAAQipcIAAiCYAgAAMnYCAADSSAIAACsQAgAAgWYCAACZ3gIAAD62AgABkoDA= Date: Wed, 29 Jul 2020 08:06:57 +0000 Message-ID: <28b5e1bf20ee43a9b583cf96a32798dc@huawei.com> References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@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.47.199.195] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:07:03 -0000 Thanks to Brian. After Brian has extracted " Forwarding nodes such as routers and load distr= ibutors MUST NOT depend only on Flow Label values being uniformly distribut= ed." from RFC 8504 (Node Requirement). I believe that original dispute about "should LB relay only on Flow Label" = is finished. LB should look deeper into headers. If somebody is going to dispute this - the only way is to push 8504bis wher= e Flow label "MAY be used as the only value" or "MUST be used". I was very happy about Fernando's explanation for business logic - I was lo= ng time in the business too - it is exactly like his said. Do not ignore the economy, because economy is very capable to ignore you. Ed/ -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 29 =C9=C0=CC=D1 2020 =C7. 8:00 To: Brian E Carpenter ; Tom Herbert Cc: IPv6 Operations ; draft-gont-v6ops-ipv6-ehs-packet-drop= s@ietf.org Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extensio= n Headers - Load Balancer Hi, Brian, On 29/7/20 01:03, Brian E Carpenter wrote: [....] >> It seems evident that the IPv6 packet structure makes a=20 >> cost-effective implementation rather difficult. Since engineering=20 >> does not only have to do with science, but also with economics, it follo= ws that: >> >> * Folks (group #1) will not be willing to pay for features that their=20 >> clients do not explicitly require. >> >> * Vendors (group #2) will not spend cycles on something which will=20 >> not get them money in return. >> >> * Other set of folks (group #3) will not actively try to leverage=20 >> features with a high failure rate, since they would also need to=20 >> implement workarounds -- and if the workarounds already solve the=20 >> problem, with a much higher success rate, there's not much of a point=20 >> in spending time (and ultimately $$) in the feature that usually fails. >> >> * Users (group #4) use whatever solves their problem. >> >> >> We may be unhappy with the above fact. But unless we're willing to=20 >> pay the bill :-), I'm not sure to what extent embarking into a=20 >> Crusade would solve the "problem". >=20 > Not what I meant, really.=20 FWIW, I do agree with you. My comment was a response to Tom where he was ob= jecting to folks that, for one reason or another, happen to drop packets. (= in this particular case the advice given by JOel in his presentation) And what I meant is that rather that being mad about them, one should try t= o find the reasons for which they are resorting to that (which is what this= document is meant to), and then figure out and do what we can from a proto= col engineering perspective. > All we can do here is write documents. So if the consensus is still=20 > what the standards track documents say, including Node Requirements,=20 > we have actually done our duty. That's in part correct. However, for cases where standards track documents = implementation become unfeasible or cost-ineffective, one may need to consi= der being more flexible and reconsider the spec. A good example was the IPsec requirement in an early revision of Node Reqs: it was words on paper that would never be complied with - so the spec= was changed to reflect that. I'm not necessarily saying that this is the case here, but rather that that= 's an option that should be on the table. > And we have, in RFC8504: > "All nodes SHOULD support the setting and use of the IPv6 Flow Label > field as defined in the IPv6 Flow Label specification [RFC6437]. > Forwarding nodes such as routers and load distributors MUST NOT > depend only on Flow Label values being uniformly distributed. I retrospective, if it cannot depend on the FL (which I agree), is there=20 much of a point in using it? Thanks, --=20 Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 29 01:26:47 2020 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 85CBD3A10B9 for ; Wed, 29 Jul 2020 01:26:45 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgUrphl0WJ4U for ; Wed, 29 Jul 2020 01:26:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3C6893A10B6 for ; Wed, 29 Jul 2020 01:26:41 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BED568D83C0B165B9031; Wed, 29 Jul 2020 09:26:38 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 09:26:35 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 11:26:35 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 29 Jul 2020 11:26:35 +0300 From: Vasilenko Eduard To: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs Thread-Index: AdZlgjwDgVHUhPinS+eOMr7pZRr/2Q== Date: Wed, 29 Jul 2020 08:26:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.199.195] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:26:46 -0000 Hi Fernando, IETF has many WGs that developing now many new EHs. iOAM, iFit, SRv6, AltMa= rking, APN6, and many others. Do you believe that it would increase IPv6 drop rate in midterm? I do assume that you do not want to make any comment in the draft, because = it is "speculation" (or "prediction"?). I am asking, because may be the question: what to do to mitigate anticipate= d problem? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 26 =C9=C0=CC=D1 2020 =C7. 8:46 To: IPv6 Operations Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension He= aders (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-d= rops-04.txt) Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Pack= ets with Extension Headers". The I-D is available at:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , G= eoff Huston , Warren Kumari , Nick Hillia= rd A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL:=20 https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops= -04.txt Status:=20 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized:=20 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drop= s Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops-= 04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 29 01:37:13 2020 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 5A1DA3A10C7 for ; Wed, 29 Jul 2020 01:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM8mwLuV-yA9 for ; Wed, 29 Jul 2020 01:37:10 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA6F3A10C5 for ; Wed, 29 Jul 2020 01:37:10 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id z18so17223874wrm.12 for ; Wed, 29 Jul 2020 01:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PcoT5GuXNlnoQAeilQah4NSxPySnb91secrE1PCZ3FY=; b=cqDBGe0dBZxJpxqH7+z+QoVLSE24hjzOY+ddJhTauMU2OMmETjZEMqBePYR1KuB7Er 9aYxK3KmnEVSh/6kGP6a7SK1b8J1rlWebIstYjX+olJuM9yy7/F3vUuOe+FOtPCeHFXb 9tImdCHP6BGp6xKkV1plzvDByTmIBKXru+gJqoXmFbYM2jm30jy8A5UdkJ/Kjnfw966t uLjSGw/zwxwo5LizjlAsdWSlOhosaduUAqFLdr8ZiOjodjytvWnUdoW4sVhnfCDymW0X 5Tg/lJ8NHP5VcGvAZoflh/YoqJ1owUspfmGQaTUSVZWutapPopjx+EmfilkqT4q3HIed XwAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PcoT5GuXNlnoQAeilQah4NSxPySnb91secrE1PCZ3FY=; b=eA+mZyji5wUYuGsaL74nWAag+3JvU0D52tKZedGEvoX8tm4ETQmg/LxpVWXkl1zl45 n7m8Db/9I9+c5TT3EhRgueHX7k7gWdhJ8pZop4RbW8aUcN5hz35d7dqEaAzRdd7L0EHT g621+hp1IC5fHkrurJhDZWsb6piNaJbVt0d0t4AGZZ+qPwKSpPwvfQOxJji8soRaBIq7 wCmkcpMBvONoO9RGJe4FHOkX4smhE6k7OhIVKNL5j22D+VaNwlfQmJG1afnEFZlaeAAy 48H6SAdV3zw57KSSAK6+IaJ07FcHToz0KpoZm9M4cFQqrjWMM90bUrfVobHaqT/ijkyN fz8Q== X-Gm-Message-State: AOAM533Bh1e7k9uOKWZE4JaXsLxDY6+r4lLZd22e/v0CrNLm+nqNzGZw XryOnSePk60iDjZhIhSz94Q= X-Google-Smtp-Source: ABdhPJy53pbtp3kJME6B3JfIG6fbvZ/a1keEtBAYcbr1vgI0f4UCY7JR3xFKN2t0mQkFe2dPOXXKwg== X-Received: by 2002:adf:97d3:: with SMTP id t19mr27021818wrb.138.1596011829048; Wed, 29 Jul 2020 01:37:09 -0700 (PDT) Received: from [192.168.0.21] (tchowndsl.claranet.co.uk. [212.188.254.49]) by smtp.gmail.com with ESMTPSA id l67sm4017222wml.13.2020.07.29.01.37.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 01:37:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Chown In-Reply-To: Date: Wed, 29 Jul 2020 09:37:07 +0100 Cc: Brian E Carpenter , IPv6 Operations , Fernando Gont Content-Transfer-Encoding: quoted-printable Message-Id: References: <159574132870.611.12077598721404194383@ietfa.amsl.com> <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> <53a8e94d-dfc3-23f9-2dac-b70eb4f203a8@gmail.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:37:12 -0000 Inline... > On 29 Jul 2020, at 08:58, Fernando Gont wrote: >=20 > Hi, Tim, >=20 > On 28/7/20 11:32, Tim Chown wrote: >> Hi, >>> On 27 Jul 2020, at 21:51, Brian E Carpenter = wrote: >>>=20 >>> On 27-Jul-20 18:49, Fernando Gont wrote: >>>=20 >>>> BTW... it seems that RFC7045 has not really been incorporated into >>>> RFC8200? >>>=20 >>> Well, yes and no. Firstly the point about HbH header processing >>> being essentially optional was adopted. Similarly, RFC7045 says >>> "This document updates RFC 2460 to >>> clarify how intermediate nodes should deal with such extension >>> headers and with any that are defined in the future." >>> and that, I believe, is reflected in RFC8200. >> It may be worth pointing out that RFC 7045 was included in the IPv6 = Node Requirements >=20 > Maybe we can tweak the text to say something along the lines of: > " A number of recent RFCs have discussed issues related to IPv6 > extension headers, specifying updates to a previous revision of the > IPv6 standard ([RFC2460]), most of which have now been incorporated > into the current IPv6 core standard ([RFC8200]) or the IPv6 Node > Requirements [RFC8504]). Namely," > . > . >=20 > ? Maybe. RFC8504 largely assembles text from elsewhere, e.g., from = RFC8200, but there are some examples where it adds more that isn=E2=80=99t= said in another RFC. >> - bis work and thus into RFC 8504, with the =E2=80=9Cnodes SHOULD = forward packets regardless of EHs present=E2=80=9D text repeated there. >> EH-related requirements in RFC 8504 are explicitly covered in = https://tools.ietf.org/html/rfc8504#section-5.2. >=20 > By the way, our working copy says: >=20 > "[RFC8504] specifies processing rules for packets with extension = headers, and also allows hosts to enforce limits on the number of = options included in IPv6 EHs." >=20 > Maybe we should say s/specifies/clarifies/ ? And this is one example of adding more. I believe the text about such = limits was put forward for section 5.3 of RFC8504 by Tom Herbert, and = there was good agreement to include this text. Ideally it might be in a = separate document, to which RFC8504-bis refers one day.=20 > FWIW, I don't mind noting =E2=80=9Cnodes SHOULD forward packets = regardless of EHs present=E2=80=9D, but in a way wouldn't that = misrepresent both RFC8504 and RFC7045 a bit, which essentially elaborate = on the caveats for the SHOULD (and hence are way more than to eartg that = RFC8200). What is included in Section 5.2 of RFC8504 on this subject is simply: " Further, [RFC7045] adds specific requirements for the processing of extension headers, in particular that any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present.=E2=80=9D The more specific notes on this are in Section 2.1 of RFC7045, so I=E2=80=99= d point to that as the authoritative source of the "SHOULD forward = regardless=E2=80=9D guidance. The subsequent words there about what = firewalls SHOULD do perhaps flies in the face of what vendors include by = default and operational practice though? Tim From nobody Wed Jul 29 01:44:21 2020 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 DFFFF3A10E1 for ; Wed, 29 Jul 2020 01:44:12 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hizbrjimsn0 for ; Wed, 29 Jul 2020 01:44:10 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 B2F463A10DB for ; Wed, 29 Jul 2020 01:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596012249; x=1627548249; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XP8w18xSfRCAY1ivansL5mq7Z1krU8k75d0glBGtPxI=; b=X4JA+4/AaaRk0+B4O3wi8r1zllPtK6uiONBFHtOzVu3WMKJYENCOEL7Q 4w9oXwJSkWhoHGfVMmPnOjjh/EK+ki5Gdobzibsg71fN0sLsKxsDxyCXO 6RBmD/dOc7OcnD3BphEc1CfsAxUqhA0Sx2VryZjRQjqx6N6UTMhwiR6RT 7o7qV7MiXrjg+ZxJkLC8EEXzl3tzH0vdDg6UsY3bwnjWIw8NWfipKsAJw DgF8t0JecozU1VHL6WxBuPWcBPWAOQngNvX94gJRjnC4Ay8Lhz10wbrQc WRjxn3D7MFUcFwtH7RVeh3TjjGa4wWGai9gl/TqUck7o5AGRMSClWArnP A==; IronPort-SDR: yDHO1O6GxK9bo044ZVG9OUsubdmRAL/XEY+UmNDI74xL5GoOavAWx7e/11NXYDVukLuIoRq2gr +DlKwdq/zk0t0rDt8vjVtfNU6C7AEu9MQeChKBp40R0bs2+cFiK6vurIydM0AoHdbX5UIZhlEO yzkScN8AFT4m9wS09Ito3rzgv4EGkiVB2zEJwy0PsQ5RM7Ju3avs5ulS7CE0fBQvNYQVeulDrG W3ubh92Uo6elAnKqHvpJcRI1FQVNrOeYr5xCwqGYJ6bvcL+CHidQ6Xqu2U+GB5JRU4RUUPaWW+ f4Y= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 10:43:51 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E50BA418BA for ; Wed, 29 Jul 2020 10:43:51 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D68194069F; Wed, 29 Jul 2020 10:43:51 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id CFCB111C15; Wed, 29 Jul 2020 10:43:51 +0200 (CEST) Date: Wed, 29 Jul 2020 10:43:51 +0200 From: Gert Doering To: Vasilenko Eduard Cc: Fernando Gont , IPv6 Operations Message-ID: <20200729084351.GG2485@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:44:19 -0000 Hi, On Wed, Jul 29, 2020 at 08:26:34AM +0000, Vasilenko Eduard wrote: > I am asking, because may be the question: what to do to mitigate anticipated problem? Do not assume EHs will work outside a very well-defined scope (SRv6 is an example of "will work, because won't leave the network where needed"). If you start work with the goal "must work across the wild Internet", abandon the idea to do this with EH. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jul 29 02:10:38 2020 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 B6E6C3A0898 for ; Wed, 29 Jul 2020 02:10:35 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7VnGWY7hzZS for ; Wed, 29 Jul 2020 02:10:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 209E93A087B for ; Wed, 29 Jul 2020 02:10:31 -0700 (PDT) Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 897CD281C6539C07255; Wed, 29 Jul 2020 10:10:29 +0100 (IST) Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 10:10:29 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 12:10:28 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 29 Jul 2020 12:10:28 +0300 From: Vasilenko Eduard To: Gert Doering CC: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs Thread-Index: AdZlgjwDgVHUhPinS+eOMr7pZRr/2f//0gGA///HZLA= Date: Wed, 29 Jul 2020 09:10:28 +0000 Message-ID: References: <20200729084351.GG2485@Space.Net> In-Reply-To: <20200729084351.GG2485@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.199.195] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 09:10:36 -0000 Hi Gert, This approach is not universal. We need something better. Some EHs (like APN6 or Network Token) do make sense only cross-border. Beca= use source to attach EH is assumed outside of administrative domain. Just t= oday was discussion about "how to make Alternative Marking cross-border". Moreover, "business" by definition is between different legal entities. If = all these new fancy features are not related to business - many people woul= d be very sorry. Eduard -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: 29 =C9=C0=CC=D1 2020 =C7. 11:44 To: Vasilenko Eduard Cc: Fernando Gont ; IPv6 Operations Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extensio= n Headers - implications from new development for EHs Hi, On Wed, Jul 29, 2020 at 08:26:34AM +0000, Vasilenko Eduard wrote: > I am asking, because may be the question: what to do to mitigate anticipa= ted problem? Do not assume EHs will work outside a very well-defined scope (SRv6 is an e= xample of "will work, because won't leave the network where needed"). If y= ou start work with the goal "must work across the wild Internet", abandon t= he idea to do this with EH. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jul 29 02:21:31 2020 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 3A5823A112A for ; Wed, 29 Jul 2020 02:21:23 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVEJ0YA0SEt7 for ; Wed, 29 Jul 2020 02:21:20 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 260993A1110 for ; Wed, 29 Jul 2020 02:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596014475; x=1627550475; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gt8ZFxd7wyCLkmBPOn0hvWV+FyerxLQkzbQRl/SdrFY=; b=crE79AozTIW5H5l5yoHhyQWlfaSNAPOXYILDVXCR7EtvnWEFua1mNZP8 Ps43EgzJ0tvUdjmrLrTWQMdCGtcN2UAJ0uYD/NVkmm3iPrjyUGrX3dSK8 /2kx1js4keOJNQOXMmSSNcH7MMubaWotw5oTvMyVSdF7R6maqnGq50Nkr kCKKftmxOEJ0pUNc3tZ/6KavRWTQIffAlqaTL8uXVMa3DOkj5+sRyZPac Hgf3uQpo9XFEEbBNSGTgGsOAhnXzRQPXor8c+GV6uLGTjti9RoB1HEUAT t1pNsnDoLgApKf6rg0usq48nht8Zy1dbF9XrnO+74HWBe8D4BuESE7guh w==; IronPort-SDR: vcG+JCyb0Ervt5JZdxJulYKwKHAsJ4Fpf3z/6HU+ZjE5IeW2YN3KOLM/4FBpkTRJO28Phdb7Kw XqdAXrm9qz0iA6WtEucNW1Phcw3Ma1XUrdbtH6KeyrFrLl1fwxIDmt00XjTVXxGzxuRo2OHPNx XojEs85hiqtBEnhLbUeHqLAc3k8QmbO9fExMu2AzQEfnn7HHuJMycc/DpKO78o834Q8K8mXBgo GG5gNWady7ODp7YLdnJRumSMX5eiO8sSWpZz0zJ9YIr5n+i4jJKLKlDaMHptLLijDZxeWUFDZh 6qM= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 11:21:11 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 63FE140CFB for ; Wed, 29 Jul 2020 11:21:11 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4ADDC40082; Wed, 29 Jul 2020 11:21:11 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 3F2D8126D1; Wed, 29 Jul 2020 11:21:11 +0200 (CEST) Date: Wed, 29 Jul 2020 11:21:11 +0200 From: Gert Doering To: Vasilenko Eduard Cc: Gert Doering , Fernando Gont , IPv6 Operations Message-ID: <20200729092111.GK2485@Space.Net> References: <20200729084351.GG2485@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZJyjsuEEfVDUfqWY" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 09:21:30 -0000 --ZJyjsuEEfVDUfqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 09:10:28AM +0000, Vasilenko Eduard wrote: > This approach is not universal. We need something better. > Some EHs (like APN6 or Network Token) do make sense only cross-border.=20 It might be possible to make this work between cooperating networks. For generic "across the wide internet, without underlying commercial relationships that ensure that a particular EH will work" EHs do not work well enough to be a suitable tool. Not my decision. =20 Just observation after 20 years of living with some of the ivory tower silliness that went into IPv6 protocol design. Like "it should be hard to handle EHs in middleboxes" and "make this an unbounded chain!=20 computers love unbounded work!" > Because source to attach EH is assumed outside of administrative domain. = Just today was discussion about "how to make Alternative Marking cross-bord= er". > Moreover, "business" by definition is between different legal entities. I= f all these new fancy features are not related to business - many people wo= uld be very sorry. The Internet is, generally speaking, in a very sorry state. Nothing new here. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ZJyjsuEEfVDUfqWY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl8hP4QACgkQ31bAZeTO f8UKSg/7BV6QpQOSE+cuO8JNknoaLcQWJ4nvVJWGwOqyAL0tp+xlA6G9mI/j7v0g 4wu/PA1On1lCcC8ijfVHY0DwMD1QSC0l4fhOYIzd4jtc5RPAlNGmUOIPh73gcwQE /qAzBJlFIQxeZHI2jL3IF/RWC5mABewZa2hkygF2YCXk3WQtSULedmaG6MZRItV2 RDGDvwNwbdqsjjcSbkYNCHXuyl6ThjcHGJLSNQYG/I2JfX7b3eJQsyrmdvCZjDOg pj+EdmlHef1jbNfvDtxnOupfjDIg6h07LJzO9rXSSAOIOkUsq5CMbmWJzeBqDExP G5t1XtLeXO1hN12mSLYP9of+d2+NrqdDFExzDmrAjvesF+ammQ13jVzU1WJacFnB IWLBkJWM1PuuCGCYjNdMoy7sfTQNScc0mFr94XLwXJT8Vx5Dtq+b1dcNJue/vuOV 7CDd9SN5zLGKAXMeCQzSsHxUhjTIjmZ5XusY9ubn53RxgNZDLSlUKQesBNcTE0Qk blZk/kiQD8rNG2r698EPTaCIGndCMAQ960wJVmnqEN0Ej1du3MCkVvDXLW7CbLuO 6YN/Z3D0dzN1mF6bmmTQW559rKmmcD5Drgh2e4FiyDvrhggcsrcsCA++3tDje+FO zAgClvSvfD+de8mRUFVAqgH2vZl1u96dhrWKgHRtU8JNHEFeT4s= =ZY1N -----END PGP SIGNATURE----- --ZJyjsuEEfVDUfqWY-- From nobody Wed Jul 29 03:13:10 2020 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 EB5B13A07B3 for ; Wed, 29 Jul 2020 03:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtASf9KhH6qf for ; Wed, 29 Jul 2020 03:13:07 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B643A07B1 for ; Wed, 29 Jul 2020 03:13:07 -0700 (PDT) Received: from astfgl.hanazo.no (77.16.208.113.tmi.telenormobil.no [77.16.208.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 5B7184E11A4F; Wed, 29 Jul 2020 10:13:06 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 6FF7039C84D0; Wed, 29 Jul 2020 12:13:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: <20200729084351.GG2485@Space.Net> Date: Wed, 29 Jul 2020 12:13:03 +0200 Cc: Vasilenko Eduard , Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> References: <20200729084351.GG2485@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:13:09 -0000 >> I am asking, because may be the question: what to do to mitigate = anticipated problem? >=20 > Do not assume EHs will work outside a very well-defined scope (SRv6=20 > is an example of "will work, because won't leave the network where > needed"). If you start work with the goal "must work across the=20 > wild Internet", abandon the idea to do this with EH. Is that significantly different from: "Do not assume ICMP, IP fragments, or any other transport protocol than = TCP port 80,443 or UDP port 53 will work. Do not assume anything but = IPv4 will work." I think the EHs suffer a bit from a chicken and egg problem. That is, if a cross the Internet EH ever got defined, then networks = would adopt to carry it transparently. I didn't see if this draft got into localising where the breakage = happens; at least previous wisdom was that it happened at the edges not = in the core. Anyway I don't quite understand what this document adds to work = describing ossification in general and the previous work on operational = considerations for EHs. Best regards, Ole= From nobody Wed Jul 29 03:13:29 2020 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 D78193A0895 for ; Wed, 29 Jul 2020 03:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OtPwqZwWkZu for ; Wed, 29 Jul 2020 03:13:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B21C3A07D1 for ; Wed, 29 Jul 2020 03:13:19 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 58F2D280A14; Wed, 29 Jul 2020 10:13:15 +0000 (UTC) To: Vasilenko Eduard , IPv6 Operations References: From: Fernando Gont Message-ID: Date: Wed, 29 Jul 2020 07:12:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:13:28 -0000 On 29/7/20 05:26, Vasilenko Eduard wrote: > Hi Fernando, > IETF has many WGs that developing now many new EHs. iOAM, iFit, SRv6, AltMarking, APN6, and many others. > Do you believe that it would increase IPv6 drop rate in midterm? All the measures that we have so far done seem to indicate that the use of IPv6 EHs greatly increase the packet drop rate when traversing the public Internet. You may be able to employ EHs within the so called "controlled domains", though. > I do assume that you do not want to make any comment in the draft, because it is "speculation" (or "prediction"?). What we are trying to do with this document is to report and elaborate on the current situation, more than trying to guess what might happen in the future. > I am asking, because may be the question: what to do to mitigate anticipated problem? My understanding is that technologies such as SRv6 are to be employed in controlled domains. In such cases, either you control your network or you cooperate with the folks controlling the network -- so you shoudl be fine (or should be able to be fine). OTOH, you are not that lucky when sending packets on the public Internet. To a large extent, the drops have to do with boxes not being able to do their work when packets contain EHs. So most likely the problem would how away if/when such boxes are replaced and if they are replaced that are able to handle packets with EHs more gracefully. So, that's functionality that vendors are not willing to provide for free, and operators are not willing to pay extra for. So the future doesn't look very promising in this respect... -- but you never know. But certainly, if there's any improvement in this respect, it will grow out of widespread awareness about the problem is question. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 03:28:38 2020 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 17B223A0887 for ; Wed, 29 Jul 2020 03:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9vEUm_mV4XR for ; Wed, 29 Jul 2020 03:28:28 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1F23A08FF for ; Wed, 29 Jul 2020 03:28:27 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EA0CC280BFD; Wed, 29 Jul 2020 10:28:24 +0000 (UTC) To: otroan@employees.org, Gert Doering Cc: Vasilenko Eduard , IPv6 Operations References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> From: Fernando Gont Message-ID: Date: Wed, 29 Jul 2020 07:28:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:28:36 -0000 On 29/7/20 07:13, otroan@employees.org wrote: >>> I am asking, because may be the question: what to do to mitigate anticipated problem? >> >> Do not assume EHs will work outside a very well-defined scope (SRv6 >> is an example of "will work, because won't leave the network where >> needed"). If you start work with the goal "must work across the >> wild Internet", abandon the idea to do this with EH. > > Is that significantly different from: > > "Do not assume ICMP, IP fragments, or any other transport protocol than TCP port 80,443 or UDP port 53 will work. Do not assume anything but IPv4 will work." The difference is that modulo fragments, non of those prevent boxes from doing their work. -- they may still be filtered, but folks don't necessarily have to resort to that. > I think the EHs suffer a bit from a chicken and egg problem. > That is, if a cross the Internet EH ever got defined, then networks would adopt to carry it transparently. There is indeed quite a bit of a "chicken and egg" problem here (*). But it's not simply an arbirtrary filtering policy, but rather the result of packet handling constraints. (*) There *are* cross-Internet EHs: ESP. But it suffers from the same problem -- so, ironically, you may need to encapsulate or do something else. Quite recently, I migrated a few IPv6-over-IPv4 tunnels I had to IPv6-over-IPv6. BUt things wouldn't work. After some debugging, it turned out that the "tunnel encapsulation limit" option was being automatically employs for v6 tunnels, which caused the resulting packets to be dropped. Of course, the workaround was to disable it. > I didn't see if this draft got into localising where the breakage happens; at least previous wisdom was that it happened at the edges not in the core. RFC7872 suggests that it happens both at the edge and at the core. > Anyway I don't quite understand what this document adds to work describing ossification in general Avoiding rehashing the same discussion everytime the issue of EHs comes up? > and the previous work on operational considerations for EHs. What's the "previous work on operational considerations for EHs"? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 03:40:45 2020 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 0DB853A082F for ; Wed, 29 Jul 2020 03:40:44 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKrXcaM4Q-I3 for ; Wed, 29 Jul 2020 03:40:41 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 73CAA3A0827 for ; Wed, 29 Jul 2020 03:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596019240; x=1627555240; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HuIucUOxJ0GwdqfUdmPtljAsE1TxV8HdNPQjiL4s9nM=; b=S+PoTM47ypmQy7yX0+QtwxVBqNOB4Z4Tm7Gylrnw8D4gpn4KVuX7Qx0f /TJBIKYW7NHOViZTMBpvJgi35PDlBR8KfDD4/gR6v1y04ApMtaQdx5kPD FvGCQuppr13nkN/I8QNQM5LZJ6aavCZWZHDQFJ63fcKZF8+usokucMn0t svbfHV5k1oHxIlL3G48bh7o6lxecSXVqoBuzCAohb/eHfCbkXLeBxioxB cqPG4mZfWyKzw5PQf07DHibVJBr7de7Ik4XFxxx7j099EZfd+9ig3vWR5 pF3orGYutcA0eO3nT9TI6IuFiig17AHf2mZkKoJpF8ZeQtOj7Djl0Xg5j w==; IronPort-SDR: 9I6bL0wwBJGjEhLnDAs+bzRO8BVN1DGTQxkb9aTrVHVeaDPwDqe1gU9sE8KqW8WuavLx4QSVSY 1wRYBcslsSFwXc0XZzbLtIZ7V5UsRuiQRgtb6FdFQAykUoQ6QLoWDGU9WfbEuEeoazOteRzeKf W8m5IPmH+dG+cTBnmRMBLIyKcUnKYuzWI868Eqlg0VU2pL2HXXI7osRA1cL7mJqqqEGIj93WRK kh5pguPf8LOdoEBFJuayizqDtdBMsgPtEW2cwoDcfgNaZ433wIy0Cfo9HZW8Hm7DR4UgNMPtxm IfQ= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 12:40:34 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CC8E740CFB for ; Wed, 29 Jul 2020 12:40:34 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 72C2E40B9D; Wed, 29 Jul 2020 12:40:34 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 6ADF813D56; Wed, 29 Jul 2020 12:40:34 +0200 (CEST) Date: Wed, 29 Jul 2020 12:40:34 +0200 From: Gert Doering To: otroan@employees.org Cc: Gert Doering , Vasilenko Eduard , Fernando Gont , IPv6 Operations Message-ID: <20200729104034.GR2485@Space.Net> References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Mtq/OFd6AHmyovWL" Content-Disposition: inline In-Reply-To: <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:40:44 -0000 --Mtq/OFd6AHmyovWL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 12:13:03PM +0200, otroan@employees.org wrote: > "Do not assume ICMP, IP fragments, or any other transport protocol than T= CP port 80,443 or UDP port 53 will work. Do not assume anything but IPv4 wi= ll work." I'm not *that* depressed yet. But yes, this seems to be reasonable advice to application programmers toda= y. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Mtq/OFd6AHmyovWL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl8hUh8ACgkQ31bAZeTO f8V3Mg/9GDVJdu5ex6HMf81Yo/TbvcNIeCoI5ziXRvK44J3djwG7dl9ZXM23nM4K sSHkxju9n0/SPxfb8Gdjtd2Fh+3ebUR21WxzYue6+Hz5ADuO2dGc2p7lcGK5eBey 4BSf44KJhPlPTowHILDKe9ClfT0yOvSX3e506c7iEHv1Ghu/IPgzVt5QxgymjYBH BLHNejIrbnr9gXOx1kP9+8/B5QFpGKeMnIcU9qIXaJWwzGplST79b/exjD71VUbb IoUdEjumahYgTuiplybELXR5ylzBefLvLUY/A9a5/1s4INmEeptIX9+pc+zvdUPH rhJzjmNkeRZOLg635zjCiE5WKrkgfK+dxIkSXLmgMJAas7U2lpqm9K6NRalAHZBf Giuap9qM1j9TZfCAPgtXOGWZ1igXvIflLX42kfpXumXCMRJL1SGmUGg7qecmVgBe izsvBipBq2sz6IjKH0kYJTSw3KH7Kml3uFaZLth91baF/P7JAptgPpI36YBavN8E +OO87B9VnE4egaaJi44m7kyLpkJrv0UetTtGE5V1wO4+QTmiG9gASFs2deAQPliE fZ9KKvFRuxfHHYb9C8JJYlnR2+OO1vmL5KLNkLddrhh0WmQZUAm3awfORznBCsBX 8v9p53Fcgnmcy2PN+lMqJryTwK+khEkV8LpCwFwv4EknxEWsDaQ= =szDp -----END PGP SIGNATURE----- --Mtq/OFd6AHmyovWL-- From nobody Wed Jul 29 03:43:31 2020 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 1F50E3A085A for ; Wed, 29 Jul 2020 03:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD9xKAxTnMGx for ; Wed, 29 Jul 2020 03:43:28 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6013A0855 for ; Wed, 29 Jul 2020 03:43:28 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a02:2121:28e:32dd:30b1:bc73:ae1:6a07]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 70D904E11A4F; Wed, 29 Jul 2020 10:43:27 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 56BF239CA9AB; Wed, 29 Jul 2020 12:43:23 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: otroan@employees.org In-Reply-To: Date: Wed, 29 Jul 2020 12:43:23 +0200 Cc: Gert Doering , Vasilenko Eduard , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> To: Fernando Gont X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:43:30 -0000 >> Anyway I don't quite understand what this document adds to work = describing ossification in general >=20 > Avoiding rehashing the same discussion everytime the issue of EHs = comes up? So you are proposing to fully embrace ossification and deprecate all = EHs? Ole= From nobody Wed Jul 29 03:51:12 2020 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 348823A08AB for ; Wed, 29 Jul 2020 03:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQH038RNwR2D for ; Wed, 29 Jul 2020 03:51:09 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71ABB3A0886 for ; Wed, 29 Jul 2020 03:51:09 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 59F5A280477; Wed, 29 Jul 2020 10:51:02 +0000 (UTC) To: otroan@employees.org Cc: Gert Doering , Vasilenko Eduard , IPv6 Operations References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> From: Fernando Gont Message-ID: <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> Date: Wed, 29 Jul 2020 07:50:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 10:51:11 -0000 On 29/7/20 07:43, otroan@employees.org wrote: >>> Anyway I don't quite understand what this document adds to work describing ossification in general >> >> Avoiding rehashing the same discussion everytime the issue of EHs comes up? > > So you are proposing to fully embrace ossification and deprecate all EHs? I'm proposing to document and acknowledge reality. Are you proposing to continue in denial? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 04:06:57 2020 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 CB9443A08FF for ; Wed, 29 Jul 2020 04:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WItKcC8Id648 for ; Wed, 29 Jul 2020 04:06:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5E03A08F8 for ; Wed, 29 Jul 2020 04:06:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1k0jv0-0000HjC; Wed, 29 Jul 2020 13:06:42 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> In-reply-to: Your message of "Wed, 29 Jul 2020 12:43:23 +0200 ." Date: Wed, 29 Jul 2020 13:06:39 +0200 Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 11:06:55 -0000 >So you are proposing to fully embrace ossification and deprecate all EHs? In my experience, any area where IPv6 is different from IPv4 is extremely annoying. As long as IPv6 is just IPv4 with bigger addresses, you write the code once, taking into account the difference in addresses and that's it. For the most part, todays internet is IPv4 with a bit of IPv6. So you have do the IPv4 part anyhow, and it needs to work well. There may be some isolated parts of the internet that can benefit from features that only exist in IPv6, but in general, I think those features are just going to be igored. Of course this may change when IPv6 becomes the default, dominant protocol and IPv4 is left to rot, but that may take a few years. From nobody Wed Jul 29 05:26:35 2020 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 5B3A33A0A2C for ; Wed, 29 Jul 2020 05:26:33 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9S4aDEC8P4G for ; Wed, 29 Jul 2020 05:26:30 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 73B373A0A12 for ; Wed, 29 Jul 2020 05:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596025590; x=1627561590; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mVFugjLzr9OTFLXWQGtC0VwgAJ7lIxMKFSp/7MTKveA=; b=beh0x4Y8pdC8ME0ToqSYl6QTNFDW6qIRZgZyWIuFKfwa2c8i6l2WWjRB 6QLEdu2+iHRYuouXuhg9C+/L8oCBBqyCeJXRTW7dSTb7Sz104nSwGlXuH SpXsJxXM1jRh5sA7HMJ2J2oYIDkcL4hAW+La7ajTp6x/lIGaOy3SGdlCU 80gnIddecw90JWQb/H4LpIS68XRTJqIJJzjvuRqDgRnAaWbx6dhnLuBkA mNBJtLol2y0yHHSAv8kvOQbdyq8/efdK5JD6hU/af/Ft4W7OOpLzVeydv kIWWQeQvDqJ9QBJ5VgLIiwvDKmxK5c+aKoyoFAQKYfKARhySVwbNuKbXa g==; IronPort-SDR: SU5FMPK1QhwYELi+UnyVAqIIO9lfIUmTPAiyl8MLC4CuPnpNMgyur099v3ERe2JWeTmoLBEBFQ Ge3p/UE36H8TKq2Lf5MfppKcmhzQ1LcNC5isBquprz+1bSI3k4AhBOc9YeuW1GIi3x+Q4chGhF jDZwZXDd5zu+Ud9ateypiungRStzZeOZdMTaPhIABBEVKjh/aFXg+tjKAfJBtCeTS7a2NKxvYe 8EEOjoqhdjkr8vvUE5tqUFN0/UoPGm7z2Pz5bVFYlHPCtH2xsGN9HzMG0/A7+G1TxM9HixuI9/ MQ0= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 14:26:28 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E71B941C02 for ; Wed, 29 Jul 2020 14:26:22 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D56FC40CFB; Wed, 29 Jul 2020 14:26:22 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D25CD15D9C; Wed, 29 Jul 2020 14:26:22 +0200 (CEST) Date: Wed, 29 Jul 2020 14:26:22 +0200 From: Gert Doering To: otroan@employees.org Cc: Fernando Gont , Gert Doering , Vasilenko Eduard , IPv6 Operations Message-ID: <20200729122622.GT2485@Space.Net> References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mWLiP9EtsNFnwsQG" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 12:26:34 -0000 --mWLiP9EtsNFnwsQG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 12:43:23PM +0200, otroan@employees.org wrote: > >> Anyway I don't quite understand what this document adds to work descri= bing ossification in general > > Avoiding rehashing the same discussion everytime the issue of EHs comes= up? >=20 > So you are proposing to fully embrace ossification and deprecate all EHs? Can you see a way to make them work? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --mWLiP9EtsNFnwsQG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl8hau4ACgkQ31bAZeTO f8W4XQ/8CcpQv7zmJ1Q12x5ybmxjKYkHZMsPLduUFPSGWxN/rRyrRjLhUOjwdVYZ GYlmOGZc05+IfRpCqS2Bn3bUPXAW/z+W/kgGJTArpsR3pap4L782Z/2BGZAzelTG 7nq5gXneHINwKw6fWPYKDrYQzeCR+Qgbxa0DwKKiFqQsahLhsraoRh9Idep1eR+M 191KBqDpVj7x7SKdDRL8J2iNPjDk84ZWYyK5XyVz/WqN6pPlCFppAwU+9ZjSHotZ tMxPXo9I3NVLEwjCmM0+8SecqFNcBAKtNhgauhBqxBq6kxZAKxf9+jNdpa0XhYyQ JwOEL5avDcrmKA15mJQdi3OcPiTI24s3XbxHnzRr2qn7dYJ+3THTE/T8jIQ8qd8f FmVvXu3SN1mYKcoHqx1j8kL/qa6cNn2LeIDR6ZKa/2uOK68rs+5FbS1q2MdhDKPx 65Q2i0GkY5qVmzBPyc4SyrkPEvFLPNT2o6HFOeKq+bB7nYpJFru8RfndXbqgX0hZ N7g3T7FKjgCwB7GqDKk0hCD9xvI7eVHC7uDxB5yATJI/l4iFA3nWNLEOy5OmYXl/ B/tMPX8crXL9z84ar7XaQhvjPqMDsBpVU6iNFidrZBDp45FxX/qqz7vgLDIpWmux oWBM8P/3oaPedInA5bIiBglgMp37OFzm7zd1mqsmoI8iq8nXz5I= =A6He -----END PGP SIGNATURE----- --mWLiP9EtsNFnwsQG-- From nobody Wed Jul 29 06:16:59 2020 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 D021F3A0AFB for ; Wed, 29 Jul 2020 06:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dimitrismaroulidis.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGwNDQJLt2m1 for ; Wed, 29 Jul 2020 06:16:44 -0700 (PDT) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 0A8953A0AD7 for ; Wed, 29 Jul 2020 06:16:43 -0700 (PDT) Date: Wed, 29 Jul 2020 13:16:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dimitrismaroulidis.com; s=protonmail2; t=1596028601; bh=e1RZi9D9+LXGr4e69uvDLnvRz+IcoZZfu5uwUBnMUbc=; h=Date:To:From:Reply-To:Subject:From; b=c8G/4hSaYeZfs34K5mDb+8i+5fCZKPdjcjzgmkZmJiBJQDFFBhTe/dMYDCPI/z/zH /+Es2qau3nsTNqqgcp3w/mA8NAhGzhm3xQhRO2/xcd5xu5oVNdebjXU1Uo+PTNXuhs CdPIyP6Z4cRYQjXUJ5MLgtg1PsEGBj7sxCy44OPLligaDN3LzP1F08UpWiFSbOB9wp tKI/CGciqnVk55kxppr8Il821iEPYrcT3z40bQ+Pm4uBGo86+wYLbr9MOscBi7aUNt grgGd3fL5dOVvUvEnS4ZwBo0s15pAlsDkG5P5C80DiY/RNGDfFeHksbKO1hT/JvwTp 4Lj5/bbFWN8dA== To: "v6ops@ietf.org" From: Dimitris Maroulidis Reply-To: Dimitris Maroulidis Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] YES Fw: [ipv6-wg] Fwd: Question about "Operational Implications of IPv6 Packets with Extension Headers" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 13:16:47 -0000 Dimitris Maroulidis President at Wyse Creative PGP Key Fingerprint: 0x9A3AF9E170FC870FA3406D0A507892A78ADEC769 MiniLock ID: YtxUsikChj33QEau5GAcMzJ2UEwpTrJrMocD4uUGdNs7X =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, 29 July 2020 1:00 PM, wrote: > Send ipv6-wg mailing list submissions to > ipv6-wg@ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request@ripe.net > > You can reach the person managing the list at > ipv6-wg-owner@ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > Today's Topics: > > 1. Fwd: [v6ops] Question about "Operational Implications of IPv6 > Packets with Extension Headers" (Fernando Gont) > > > Message: 1 > Date: Wed, 29 Jul 2020 03:57:40 -0300 > From: Fernando Gont fgont@si6networks.com > To: "ipv6-wg@ripe.net" ipv6-wg@ripe.net > Subject: [ipv6-wg] Fwd: [v6ops] Question about "Operational > Implications of IPv6 Packets with Extension Headers" > Message-ID: 349eccf9-2b19-980b-e3f9-4ba90c2bedbb@si6networks.com > Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed > > Folks, > > FYI. The document is this one: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 > > And the request input should be directed to v6ops-chairs@ietf.org, > following the instructions described bellow. > > Thanks! > > Cheers, > Fernando > > -------- Forwarded Message -------- > Subject: [v6ops] Question about "Operational Implications of IPv6 > Packets with Extension Headers" > Date: Tue, 28 Jul 2020 22:55:45 -0700 > From: Fred Baker fredbaker.ietf@gmail.com > Reply-To: V6Ops-Chairs v6ops-chairs@ietf.org > To: IPv6 Operations v6ops@ietf.org > > It looks like Fernando (et al) revised this and posted draft -04 on > Saturday, and there has been a flurry of discussion. I haven't been > through the document or the entire thread yet, but I do observe that a > number of people have comments, and several people have expressed > interest in the document. > > Let me ask the obvious question: you we want to adopt this as a working > group draft? I won't ask you to hum; whether you wish to say "yes", > "no", or "abstain", please reply to this email privately (which is to > say, to v6ops-chairs) with that word prepended on the subject line. I'll > give us 48 hours, which is to say that I will evaluate and state the > result Thursday evening Pacific time. > > https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D"draft-gont-v6ops-i= pv6-ehs-packet-drops" > https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D"Operational > Implications of IPv6 Packets with Extension Headers%22 > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops > "Operational Implications of IPv6 Packets with Extension Headers", > Fernando Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, > 2020-07-25, > > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > End of ipv6-wg Digest, Vol 102, Issue 1 From nobody Wed Jul 29 07:34:43 2020 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 5243D3A0BDC for ; Wed, 29 Jul 2020 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O-xZYe-AxRr for ; Wed, 29 Jul 2020 07:34:39 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5D53A0BDE for ; Wed, 29 Jul 2020 07:34:39 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id n2so17566647edr.5 for ; Wed, 29 Jul 2020 07:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0X7FPiP7LwaqqMTUP+JhC6eCc0B+5tDVcZR0JqshLeQ=; b=C++dh35LT30kRHDF3CCKmUjenwKuFQPPzWu5wD1GtmWosADam+McsokJpZx8qunfRJ 9IcyWUhfdv9ziSSBsrJy3GM5KzWjWbHza8Dtv3kZ9jRJXLYkeeI+CJG+sbHOCovj2sQ9 3zUX/VA4eNfm+1xEXdEgd94dl+dBtmwROS304XM7ZrJTPEklul+OEDuBoghyPGJAZZWC G6JZ7FMjC3ys71tyy+Z1y+1x/K90hxINEthsEqLdaGDMZJhMrMWoCXNYPkMy7xKR0Jan OwZtYyBQWO5nJiOme6qfHureRt7notf5sqLCKNWhOgk0tjzMbuyO2hoKoTwlfE51A4Y7 ZtFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0X7FPiP7LwaqqMTUP+JhC6eCc0B+5tDVcZR0JqshLeQ=; b=qyOy+cYVTAH5cwv71OfcZSRRIkZ/V3hDoZawSf0r4LgJZnrWJUxXPoqO6WF/Q8wsf+ kM8Ra8qsaUVjtKZ9AVGzuia2gUt8GnYlRIjnSPfEdLZW3JAn/Dons94RU0T1lgh7PPxg XaxWIp2NCnOzv4d93Up2EqdKKtHAtlq/YrrSfPp3FgY1uc7BFzhqZhNAchpy0Q4MGj+s n0gH0NlA5JovIWdi8Ei0Oki9RKfAauUP431ow3kWzWYnIZQ4nqSNCNpXkxq1MArSicmA FWaKlUKIS598T2KGAsRYoaa9TegkX8x4fnps2nCp6nJmzGff8El11DzMzRE987+r1CpU MXFw== X-Gm-Message-State: AOAM532UbXOBTJaf+7RuBmxGiiyDPeofLg/WmPRLpGKLaTaURaNZVbm6 iNyJMIiCfKIZJZTPYeEtMK5hJvkElqZaeQ4OL+4gcd+JQNM= X-Google-Smtp-Source: ABdhPJxvnt0w883b17XKsi31rxKbawjHkcZfShjnOepaYc5FpWDOU9GF4mAOPPwJ1GzJDjgkYVFWsec372YomcMjorY= X-Received: by 2002:a05:6402:785:: with SMTP id d5mr15333785edy.370.1596033277928; Wed, 29 Jul 2020 07:34:37 -0700 (PDT) MIME-Version: 1.0 References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <20200729122622.GT2485@Space.Net> In-Reply-To: <20200729122622.GT2485@Space.Net> From: Tom Herbert Date: Wed, 29 Jul 2020 07:34:26 -0700 Message-ID: To: Gert Doering Cc: Ole Troan , Fernando Gont , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 14:34:41 -0000 On Wed, Jul 29, 2020 at 5:26 AM Gert Doering wrote: > > Hi, > > On Wed, Jul 29, 2020 at 12:43:23PM +0200, otroan@employees.org wrote: > > >> Anyway I don't quite understand what this document adds to work describing ossification in general > > > Avoiding rehashing the same discussion everytime the issue of EHs comes up? > > > > So you are proposing to fully embrace ossification and deprecate all EHs? > > Can you see a way to make them work? > Gert, Yes. We can apply the same principles that helped IPv6 get any traction (even if it only took twenty years :-) ): Assume deployment of any new feature on the Internet will be incremental, Provide an automatic fallback to a lesser protocol when the feature doesn't work over some path at the possible cost of degraded service to the user, Collect real time data on status of feature support in different parts of the Internet and make it public, Ensure there is economic value in supporting the feature so it's not just an academic exercise, Be flexible in use of the feature (e.g. extension header insertion/removal). IETF can address issues in the protocols themselves that inhibit practical implementation. For instance, in retrospect wrt extension headers it's clear that requiring every node to process HBH options and requiring these devices to potentially process hundreds of TLVs in the fast path wasn't feasible-- we can provide practical guidance to mitigate these (which RFC8200 and RFC8504 does in these cases). There's still work to be done, for instance hardware limitations around how many bytes of headers a device can process is regularly raised (including by this drat) but what exactly is "too big" has yet to be quantified; it would be nice to provide guidance for host implementations so they can know when they're sending a packet with too many bytes of headers (draft-ietf-6man-icmp-limits-08 is a good direction but only to the extent that ICMP is usable). Tom > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 29 07:58:45 2020 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 C3E7B3A0C1C for ; Wed, 29 Jul 2020 07:58:43 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-8nEVMk4t-w for ; Wed, 29 Jul 2020 07:58:41 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 B3A383A0CB8 for ; Wed, 29 Jul 2020 07:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596034712; x=1627570712; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3QMsTa3eg7HzyO/wYF86ECP0gHmZrygWHKaVWElzVCw=; b=JL8ckuwkADkZ2Nod6McAYcECdojBR0CHAKyO9A8UhfpvcpaUsUSg1fYQ Ab4rl0ZiyktumrRhy3L29sI+bt0G5olsvr8jxpaHMS7H8dUiJQbRGajh+ D2aUiNEyj1PPMFfQrkU+FNZybInqsY9Bsi3SZPnhZkJPhc1pfHcfV/Mwz K2vv1LTPpZ8hX+xzoYTJY1iTS/OI/ZFO8qKFXDB8rsYaPAX4UP/bJvsKL GbGk7kyXGNoAtSoixq1QtE1sQVcZvF3VsrfRjHA3/wJFr3QdOKOkiOklG yVhjSScjrnihve2zjov/fQDIq8mmvWcy6dnbvA2yMtn2kHk0SFyt/KMzn Q==; IronPort-SDR: v8HQiU24pFK4KxAggojYRBvEBvzkKMRgKmTLn//N9n7x3JpzXN5U9OCkc2UETJo4OQx0gg//3w 9HqE7tINX/yhyUlDCjCa0JryFCF6BCq2MITK/xmJFTxQSQbHJDIfxtFX5qOAJcC2/omWs5E05G MGyAXaWewXcK8Rsyzt4BHS3tk34+5TqTklHDoS8xMzCerX2uS+qP5SlsH0MSMHMRbR/BbYT9ve 5x+vKkYS5yvBKn3ahHkljYH5VTGNwWlPa4JMU56Shik1OrCz7vJF+V9BefY/1G4cGkzyPJi87E N3s= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 16:58:29 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 095F841261 for ; Wed, 29 Jul 2020 16:58:29 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9EFC940CFB; Wed, 29 Jul 2020 16:58:28 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 98DB818679; Wed, 29 Jul 2020 16:58:28 +0200 (CEST) Date: Wed, 29 Jul 2020 16:58:28 +0200 From: Gert Doering To: Tom Herbert Cc: Gert Doering , Ole Troan , Fernando Gont , IPv6 Operations Message-ID: <20200729145828.GX2485@Space.Net> References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <20200729122622.GT2485@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t8zr4fefo56TD9MG" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 14:58:44 -0000 --t8zr4fefo56TD9MG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 07:34:26AM -0700, Tom Herbert wrote: > > Can you see a way to make them work? >=20 > Yes. We can apply the same principles that helped IPv6 get any > traction (even if it only took twenty years :-) ): Assume deployment > of any new feature on the Internet will be incremental, Provide an > automatic fallback to a lesser protocol when the feature doesn't work > over some path at the possible cost of degraded service to the user, > Collect real time data on status of feature support in different parts > of the Internet and make it public, Ensure there is economic value in > supporting the feature so it's not just an academic exercise, Be > flexible in use of the feature (e.g. extension header > insertion/removal). This looks like tremendous success story in the making. Just like=20 IETF succeeded with getting IPv6 and all the cool bits of it (look, ma, it has EH!!! AND IPSEC!!) out into the fields. There is no incentive for network operators to make sure their network can transport EHs if it works "without". There is no incentive for application developers to code support for "anything with EH" if they have to assume "it will need to work across networks without". Now, if IETF could find big bags of money somewhere to hand this over to network gear vendors to build EH-friendly equipment without extra costs, and give some more money to network operators operating in an increasingly low-margin market to replace all their gear with "new and full of EH support! same power consumption, same everything, same price, just more EH!", then there might be some hope. But even then people will happily use the no-longer-in-use non-EH compliant gear to build new networks with lower setup costs. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --t8zr4fefo56TD9MG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl8hjpMACgkQ31bAZeTO f8WBoA/7BZphjTgf2K9esU/Ki2FMI7JmQSOfQ1ZBfzKxASGQpaDIEMVBkqt6Lt22 RiT7Db+Q3GUBSTWWs+rh5+LwTwxAxsallT/IH0vGhX+pNDwrh7DE6VoE/Ef6l13j TGSi2Hpzzrau/c+lwgEL/89YW0qWAb4e/D7jK2huuWZz/IHkz0O3BH5SdJYoWgnM 0Ckl9OFWINSV7q7IOiGBnl/uEd4QSs4NupfkPKrmFfRNA5U3FPaYD+csf8y/sfpa jR9r834Vv/j2APkaE22lOo0ydrwwSol2cGGlvQ73ca7KMKCocJ+24HoU25qApfU1 qzSdBQZOUMTJXxxNRqaqxOfRCHdcCbCa4nUKPUOrifk4Na6ygscgEwhvlX5qdUyb TPT7Yk/bOLK0dnvuvNmsAeD0Mjt3cNnvGG4mDPJaQ7aHsX88WEu5n6qPIQTl8eTh cliDC/Ndq1Am/Jylwo5EhAdvOXcU731XvEcjRQa4KK8mJOas0iimJ8HLbvPcj2PQ 8LEfQF+RWpL4Rx2a3Z9wSWaVQF9nBPQx7CWG9kvz+cRsFhchHD9Li72EOr911cz9 9kXJF1b6VgkEcnRELCNrKQPIie0x5T7/ApQgkhtaVb6nr0ssb/4VlLv7r+pAqKFb RUixd6/bs1pZknpBKC0Hu/v7SY6zhihp7WwhncLSty8LBwHs4s0= =u+xj -----END PGP SIGNATURE----- --t8zr4fefo56TD9MG-- From nobody Wed Jul 29 08:18:45 2020 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 3D0853A0BC4 for ; Wed, 29 Jul 2020 08:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk_3yZJ9rBTB for ; Wed, 29 Jul 2020 08:18:41 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B08B3A0BD1 for ; Wed, 29 Jul 2020 08:18:41 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id c16so4367298ejx.12 for ; Wed, 29 Jul 2020 08:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6NDQSCPyF+uz9h5noAfk9fn5XoTaM/qcXutMfrzRh9g=; b=zULpKFfP7c8NguOMnNNohglbvDVFS0Ba6DaMOHxr+DwRwBQAMHoIJAfWeaK+7b1edu rQ/D0a04GWD6qRksM5zvYOVTbNm6fPz95DZR6wX8MucZ5bfhAYVv0TlBRhGASAGEhZQT rFc+cJv1P56pndbWM8+qYeA4Wr6640bEa9vpOhBxV8PEVxekn24OOKUXy4qsT1qKFqhH 5/woWX5qjD/snTX1hkglt/hDg6xlsUhFISdCG8te+ZNGufULtXqFyRM0tRA4TtSjOS+/ NkbRflT4pP797nNKVAE3sQH3r0rSee+PV78k4VvqXpjmLc4ETiThxfQ43SYOTtkJGaQV OlJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6NDQSCPyF+uz9h5noAfk9fn5XoTaM/qcXutMfrzRh9g=; b=csZ38Q41Tl7EYa9M4IcAgqXRjam1CVjC+CYGEtEuVb2yAPGOuqLCt9TN9bsWBveQzC Nh58MDfD6+Al41wCE7TPxX6XdZxAZ7w7fTf6QFc4dRoz9/oLBmhFK+NvpRMcWthzWBvo izbkNBmLi1Iv+FwPsdq+ShZefLPiZqntwE2HkoeGDwKewiG91tQnAVMWVXfP1YBCGCHf Wd6s5thGC2JgMWjQvHq7vTK//phJcT5tWeHSEQfDExb45414KHTKurWhxFJXTwjKYzPx xnE6BwMofgUD3TDSCyduhpeuCAthNJT0SfPdZydOWDnQRXwT5raHXvSULrQ9mQYrTk4w 2/9A== X-Gm-Message-State: AOAM533nwfQb85cjlrkAxW8s2HUT0I1YKjydTfcWhnHZCAh1f+mAOn+2 knNVpZRRguFTng3kL8W5KsWQECXNxJoPD3cU1otzaA== X-Google-Smtp-Source: ABdhPJz5OUZVe14XGixrA70TQaHOo+j5PDDtHWie9rEZzkLuTL/hvbvITMogNIKV7tuSkJQNbvDDGJcyMZB7W9vg9jY= X-Received: by 2002:a17:906:a242:: with SMTP id bi2mr30082791ejb.243.1596035919730; Wed, 29 Jul 2020 08:18:39 -0700 (PDT) MIME-Version: 1.0 References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <20200729122622.GT2485@Space.Net> <20200729145828.GX2485@Space.Net> In-Reply-To: <20200729145828.GX2485@Space.Net> From: Tom Herbert Date: Wed, 29 Jul 2020 08:18:28 -0700 Message-ID: To: Gert Doering Cc: Ole Troan , Fernando Gont , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 15:18:44 -0000 On Wed, Jul 29, 2020 at 7:58 AM Gert Doering wrote: > > Hi, > > On Wed, Jul 29, 2020 at 07:34:26AM -0700, Tom Herbert wrote: > > > Can you see a way to make them work? > > > > Yes. We can apply the same principles that helped IPv6 get any > > traction (even if it only took twenty years :-) ): Assume deployment > > of any new feature on the Internet will be incremental, Provide an > > automatic fallback to a lesser protocol when the feature doesn't work > > over some path at the possible cost of degraded service to the user, > > Collect real time data on status of feature support in different parts > > of the Internet and make it public, Ensure there is economic value in > > supporting the feature so it's not just an academic exercise, Be > > flexible in use of the feature (e.g. extension header > > insertion/removal). > > This looks like tremendous success story in the making. Just like > IETF succeeded with getting IPv6 and all the cool bits of it (look, > ma, it has EH!!! AND IPSEC!!) out into the fields. > > > There is no incentive for network operators to make sure their network > can transport EHs if it works "without". > > There is no incentive for application developers to code support for > "anything with EH" if they have to assume "it will need to work across > networks without". > > > Now, if IETF could find big bags of money somewhere to hand this over > to network gear vendors to build EH-friendly equipment without extra > costs, and give some more money to network operators operating in an > increasingly low-margin market to replace all their gear with "new and > full of EH support! same power consumption, same everything, same > price, just more EH!", then there might be some hope. > Gert, Then they won't be able to use segment routing, IOAM, or new QoS signaling like Network Tokens that are now being developed and being deployed. That's fine, it's their prerogative. Some operators will certainly make this decision to not invest in new technologies, like when they decided to defer on IPv6, but I don't believe all operators will come to that same conclusion. Even the data bears this out, the oft quoted RFC7872 still shows that even in the worst case of HBH options the majority of flows still made it to the destination. It's a given that we can't rely on much to always work 100% on the Internet, but IMO if we apply the right techniques we can opportunistically provide something that works and provides value to users. Tom Tom > But even then people will happily use the no-longer-in-use non-EH > compliant gear to build new networks with lower setup costs. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jul 29 08:35:29 2020 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 3DB3F3A0B9B for ; Wed, 29 Jul 2020 08:35: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP5qumG8TaBv for ; Wed, 29 Jul 2020 08:35:23 -0700 (PDT) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 C5E403A0CE2 for ; Wed, 29 Jul 2020 08:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1596036904; x=1627572904; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hKvJUONBP3k2XZOEuX+pPuB6lxh5GX5tJ9uz1nn5rTM=; b=R03pZEnrIoNGMyt2UAUX7CJBB457OozeJvzTcooeeRoahVbC2mYQElSG /htcMMAwhJYZ3wuyu478T42sHJrtGhzXtD0CwShks4f2qAt5uztXhemra reFgjYvMbBvPQGnUKG7imagGLdFneqO4Vijo6DZz1nm9XDsyggi+FMZoE y9VjRxrTBSQ4XXVjEbbZ0qoskN6jYHImj1IBf2wZJSD13xo19mPAKZyJ5 XPIO2Q3v1uog6wNgmswTXx0FPZxiE5EKNGzMULrUPuZfrbNBZLjoxx0RY hGKRyMuhfi1IaDOVpowwGzzVbQgS9Uo/7ZSD7AJCr6SiZDxqzfVVHckbI g==; IronPort-SDR: PA1yEephiuY4apcUI0J2yK9rJ6LBOSJAgDLvuXn/xsY21XaFpiGxPDRzRPAWnU75kk30hHONrF hJ5TRFWYvC0BfPRi/qbW1d0qbeLbeIjwacT1TKbp3sOIt67bdQOcMZXfcR3rwoGva/qVKmF+Qf /vyjy+UNY2jyJ76TofOdJ5IynFWoNpGJ1XsOTgpNNVhUU74jVF4VW/hxcAz+v21B7ByngWBePS jWBhQynA1l5JPY05G0W5YoGQ0pl1juf2XdThgggGvPi6dadcKla7OIUOSns3DRx7Ab/lH0ATR4 aEA= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 17:35:01 +0200 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0BF1F418BA for ; Wed, 29 Jul 2020 17:35:01 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B243240B9D; Wed, 29 Jul 2020 17:35:00 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id AC357193FA; Wed, 29 Jul 2020 17:35:00 +0200 (CEST) Date: Wed, 29 Jul 2020 17:35:00 +0200 From: Gert Doering To: Tom Herbert Cc: Gert Doering , Ole Troan , Fernando Gont , IPv6 Operations Message-ID: <20200729153500.GE2485@Space.Net> References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <20200729122622.GT2485@Space.Net> <20200729145828.GX2485@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pjzOFJWVSGBRI8Xq" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 15:35:26 -0000 --pjzOFJWVSGBRI8Xq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2020 at 08:18:28AM -0700, Tom Herbert wrote: > > There is no incentive for network operators to make sure their network > > can transport EHs if it works "without". > > > > There is no incentive for application developers to code support for > > "anything with EH" if they have to assume "it will need to work across > > networks without". >=20 > Then they won't be able to use segment routing, IOAM, or new QoS > signaling like Network Tokens that are now being developed and being > deployed. That's fine, it's their prerogative.=20 And by that, you acknowledge that using "EH across the wide Internet" is not going to work. Nobody challenged that the use of EH in a closely controlled environment ("my network and all the partner networks that I have a contract that governs that we'll cooperate regarding these EHs") will work. [..] > but IMO if we apply the right techniques we can opportunistically > provide something that works and provides value to users. EH has turned out to be costly to people that have no way to recover these costs as their customers have no interst. Now, if Google would show up and say "all web sites that demonstrate use of the TurboEH are ranked up by 20%", you can bet that SEOs would be the first to demand working and fully transparent EH support, no matter the cost... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --pjzOFJWVSGBRI8Xq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl8hlyEACgkQ31bAZeTO f8UffA//c+mI4COSTYTI6Nk8K8DgaPipBhQnPWIg4tfnUfLQRQOUMBUsD9MOnkKM VjhTCuoP1okEU1vJPngD4miP13EEQymKHaU89EGkMTAZpY8ydbJdAJyIwXvDhkSQ 43RlTQRX4kKFJc9EYj2qF3qbKmxz+OBADb3FRmkkQVhRYLZQuj7GVZpHDCRUX1wV d+4oZDtq4nAHMcul8xAfYs6aCpo6ztOQ6/vO4iRxPZLFObbj3gxOBLaQvQyXa6Wj mI+mqnkdeyAZlvXGCMC2bnGx68PwM9Tlx8EkeZMsIjwpX1D/tgjRENPpMu8XoTcG k3kH3LlcNMebYl09FZ5rfWAVvgGR0y5YYy0odYNJubJRL3ufYeTTQiNf5YkX+Our iDoC9MzlV5e5TqwyvAFE7IlBI+miAo1gaTpgTXB78WYZK8Wbv1E0vb1mtYzbwqnK OFZBtBLDXgmGmPvBv63Zy05YOKY/onjkZh47b910wv7zIyA4HSvFLJy5WMIVpY/2 DLaVsw4401DgzmlcSsBPD1Q1aiyrSvw9xNIxShfISgLos4RyitDD4zhty+DAdEcR UUGg4sqzAMxUgm7W9UObOT7yYRgZs8HVvyIWEm8+YPPDWJPno7axpfhjO8choS7E FcZaCl6RZ4thIJEeYlAHR+hC8dyJI8QxJdE+yxUxXprxB49fDD4= =p9zj -----END PGP SIGNATURE----- --pjzOFJWVSGBRI8Xq-- From nobody Wed Jul 29 08:59:54 2020 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 7B1F83A0BD8 for ; Wed, 29 Jul 2020 08:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlX80cTfMcd5 for ; Wed, 29 Jul 2020 08:59:50 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666603A0C1D for ; Wed, 29 Jul 2020 08:59:50 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id o18so24862315eje.7 for ; Wed, 29 Jul 2020 08:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=almEea5jX7oGnxFQkmWQD/jkTSLci2CSfrDB4XK6nbE=; b=EzFBIh7fbuqlENXGkP4+V5ACx5OWJNGJ0VC6Uboddjz0RA0hp/W+8EUyn1yhGeUm1q HX+npPf7ZKlPwlZ90h5pnvRStLSxEWLm9jysc9LWfWSbbGjoWq64JwKPFoUr0QZ6rJO2 GUurEUiNd2P91SqvP+InmmhNC+CfH9Fj8VdVTLHhJgUHUPINOCV8D4n7cSFpwsmn4bSG 6cRYhG5vshcjhxLykiN1yd+Vj3EY+6wXl8ngaPDmIQ3Yr8nZakjOXvVdIfGLwdrbJVqc MclVNxU6t1buV/y1h+lY18sIVqyB8rXKvB4v+tKdgqOOVuWfavKu5QopFjBlmf8irJTg kmXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=almEea5jX7oGnxFQkmWQD/jkTSLci2CSfrDB4XK6nbE=; b=HJHeOcGJbu5WKzwmnDLTXGf0gDK1zaugGJRrGxLcwToZQaQon6wYY087vI5qr3rJa9 RvQbVFXyfET2bOeyqgjL5fssaPpd0xBMq2shz409PQa+8Q55ymZAlyyV52cT6Kqfqv55 7aQ4U8aYz5bueoZn2/L7kptrtXvmEdaV2ZaMVFOSFZBMZ32XBzMJPbAJGaPEC+4kBexy oQm02l2WQR+kx9c3zsm4MSTxxpzW8ZPcSvhEzsz4lP26fOCktk6Vo4LE3D57neZxR6wc Y5jOAKaKLAnwUN5TkU120LKxiT2agfL7IF6hPy1lt9QG+Ng7Tp2C5I3nQzCvXst81+m9 wvkw== X-Gm-Message-State: AOAM532iBvCN+pkNqoVXDCZFlqd4gVJzZk9sMCcJ3u0XuhjJ/4KjQ60E ysLqcs3b/r9vc4c+Y/wUUoGb2zNUDl+kQ+OX672YBQa6 X-Google-Smtp-Source: ABdhPJzVsQWQjZGvNM8eqBxy2MN7euKY0dh14DD42kWl+hqudMCLfHB/5y9BaauqH690VLcYW325ANRvdyzZS4+lq5w= X-Received: by 2002:a17:906:a242:: with SMTP id bi2mr30250495ejb.243.1596038388683; Wed, 29 Jul 2020 08:59:48 -0700 (PDT) MIME-Version: 1.0 References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <20200729122622.GT2485@Space.Net> <20200729145828.GX2485@Space.Net> <20200729153500.GE2485@Space.Net> In-Reply-To: <20200729153500.GE2485@Space.Net> From: Tom Herbert Date: Wed, 29 Jul 2020 08:59:37 -0700 Message-ID: To: Gert Doering Cc: Ole Troan , Fernando Gont , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 15:59:53 -0000 On Wed, Jul 29, 2020 at 8:35 AM Gert Doering wrote: > > Hi, > > On Wed, Jul 29, 2020 at 08:18:28AM -0700, Tom Herbert wrote: > > > There is no incentive for network operators to make sure their network > > > can transport EHs if it works "without". > > > > > > There is no incentive for application developers to code support for > > > "anything with EH" if they have to assume "it will need to work across > > > networks without". > > > > Then they won't be able to use segment routing, IOAM, or new QoS > > signaling like Network Tokens that are now being developed and being > > deployed. That's fine, it's their prerogative. > > And by that, you acknowledge that using "EH across the wide Internet" > is not going to work. > Gert, Well, if by "works across the wide Internet" you mean that there is a 100% probability that packets with extension headers will reach every possible destination over every possible path then, yes, "EH across the wide Internet" is not going to work. However, by this same definition IPv6, UDP, SCTP, IP fragmentation, ICMP, and pretty much anything except possibly the most rudimentary plain TCP/IPv4 packet don't work "across the wide Internet" either. We know ubiquitous support for protocols across the whole Internet is not feasible, it's pointless to assume a requirement for a protocol that it must be universally supported everywhere before it can be useful. > Nobody challenged that the use of EH in a closely controlled environment > ("my network and all the partner networks that I have a contract that > governs that we'll cooperate regarding these EHs") will work. > > [..] > > but IMO if we apply the right techniques we can opportunistically > > provide something that works and provides value to users. > > EH has turned out to be costly to people that have no way to recover > these costs as their customers have no interst. > I don't expect customers to have any interest in extensions headers, I do expect they'll have interest in services they help provide. > Now, if Google would show up and say "all web sites that demonstrate > use of the TurboEH are ranked up by 20%", you can bet that SEOs would > be the first to demand working and fully transparent EH support, no > matter the cost... Yep. This was clearly demonstrated by Google's success in pushing operators to support QUIC. If I was endeavouring to bring up a new protocol or extension header on the Internet I'd certainly start with getting a major content provider on board even before service providers. Tom > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jul 29 09:04:34 2020 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 DB33D3A0D56 for ; Wed, 29 Jul 2020 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwBWk_Rl36QP for ; Wed, 29 Jul 2020 09:04:26 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 867843A0D26 for ; Wed, 29 Jul 2020 09:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e41sXS00/3KFfZSGnKYzD9lhXYcmk//0k4XaeMPuHNw=; b=GugDLSLv7IHEPZUIeeVCYqEbo icF2N4Tzrr/9VgFEZ0UKYKyx6nHutjkgsGu98tPXnm/HGKr1sct6G1jmgXulYjfDS4xuQYFvi8AjM exX9ySHPwpFMadixYh2MbGvNT19UVcPrf9DJ2dCf2pEPG2iNMYnqbD6MREfxLJ/GQbmdLEcQzz0Y7 n8O9Tqvmdv2Lj7lnwUnh1dVcnY3p7FOvknpAPpzhO8ocpNfrihCVg6ICPAVWzjV3eJxfiGb8ezw5i hhVVoSdWIDXPGqQFFebZ39sA6GJhrTpPqs6y7xmTPvD8h3EZC7E0AYv9I3taSM/2Bh8LMomD8Twl4 UB2u+HhPw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56368 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k0oYs-004ICv-SO; Wed, 29 Jul 2020 12:04:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_BBE0F248-F50A-4578-8362-C1DA93A80281" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> Date: Wed, 29 Jul 2020 09:04:10 -0700 Cc: otroan@employees.org, IPv6 Operations Message-Id: References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 16:04:29 -0000 --Apple-Mail=_BBE0F248-F50A-4578-8362-C1DA93A80281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 29, 2020, at 3:50 AM, Fernando Gont = wrote: >=20 > I'm proposing to document and acknowledge reality. We=E2=80=99ve spoken about this before, but for the group: There is a tension between =E2=80=9Cdocument and acknowledge reality=E2=80= =9D and =E2=80=9Cadhere to standards to ensure interoperation=E2=80=9D. Not every =E2=80=9Creality=E2=80=9D represents something that should = change a standard. Some can - and should - be declared as =E2=80=9Cbugs=E2= =80=9D or =E2=80=9Cerrors=E2=80=9D and called out for doing so. If we are merely documenting what happens to be implemented, we cease to = be a standards body and become merely reporters. Joe --Apple-Mail=_BBE0F248-F50A-4578-8362-C1DA93A80281 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 29, 2020, at 3:50 AM, Fernando Gont <fgont@si6networks.com> wrote:

I'm proposing to document and = acknowledge reality.

We=E2=80=99ve spoken about this before, but for = the group:

There is a tension = between =E2=80=9Cdocument and acknowledge reality=E2=80=9D and =E2=80=9Cad= here to standards to ensure interoperation=E2=80=9D.

Not every =E2=80=9Creality=E2=80=9D represents = something that should change a standard. Some can - and should - be = declared as =E2=80=9Cbugs=E2=80=9D or =E2=80=9Cerrors=E2=80=9D and = called out for doing so.

If we are = merely documenting what happens to be implemented, we cease to be a = standards body and become merely reporters.

Joe

= --Apple-Mail=_BBE0F248-F50A-4578-8362-C1DA93A80281-- From nobody Wed Jul 29 09:32:12 2020 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 8DFBD3A0C63 for ; Wed, 29 Jul 2020 09:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO8eYUVFCwB6 for ; Wed, 29 Jul 2020 09:32:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 816F33A0D23 for ; Wed, 29 Jul 2020 09:32:06 -0700 (PDT) Received: from [IPv6:2620::930:0:b15e:4b13:c156:790d] ([IPv6:2620:0:930:0:b15e:4b13:c156:790d]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 06TGW4NN1546135 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 09:32:04 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 06TGW4NN1546135 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1596040324; bh=jM3khG5jFOY++SXdcixa0BiApxcIZBYwpnHZv06yt3A=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=YGnQXk4I1NJHJ0X5+4CQMvtjdVF5rtvjv8VpiGjQ4doSMi1C+RbHcfA6uXviv/PAN QiDzGAN6xmj3ysbS2pnRwDawFOBXxVtdT7uVrBjOsfS+dIzE++wwAJ1wunfrdZj03h 2wmbC4A3aJcNgDr9LOAdfQLDIrwsLuWmp7EqWb0E= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3DFB6DB4-6B05-46CC-BFF7-CDCF1B1BFE4B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jul 2020 09:32:04 -0700 In-Reply-To: Cc: Fernando Gont , IPv6 Operations To: Joseph Touch References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 29 Jul 2020 09:32:04 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 16:32:10 -0000 --Apple-Mail=_3DFB6DB4-6B05-46CC-BFF7-CDCF1B1BFE4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 29, 2020, at 09:04 , Joseph Touch wrote: >=20 >=20 >=20 >> On Jul 29, 2020, at 3:50 AM, Fernando Gont > wrote: >>=20 >> I'm proposing to document and acknowledge reality. >=20 > We=E2=80=99ve spoken about this before, but for the group: >=20 > There is a tension between =E2=80=9Cdocument and acknowledge = reality=E2=80=9D and =E2=80=9Cadhere to standards to ensure = interoperation=E2=80=9D. >=20 > Not every =E2=80=9Creality=E2=80=9D represents something that should = change a standard. Some can - and should - be declared as =E2=80=9Cbugs=E2= =80=9D or =E2=80=9Cerrors=E2=80=9D and called out for doing so. Yes, so let=E2=80=99s do that=E2=80=A6 Let=E2=80=99s have this document = represent the current situation and then call out which parts of that = situation are considered to be bugs/errors and which parts we believe represent =E2=80=9Copportunities=E2=80=9D for = improvements in the standards. > If we are merely documenting what happens to be implemented, we cease = to be a standards body and become merely reporters. If we avoid any introspection or consideration of operational reality, = the cease to be a relevant standards body and become an ivory tower. Owen --Apple-Mail=_3DFB6DB4-6B05-46CC-BFF7-CDCF1B1BFE4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 29, 2020, at 09:04 , Joseph Touch <touch@strayalpha.com> wrote:



On Jul 29, 2020, at 3:50 AM, Fernando Gont <fgont@si6networks.com> wrote:

I'm proposing to document and = acknowledge reality.

We=E2=80=99ve spoken about this before, but for the = group:

There = is a tension between =E2=80=9Cdocument and acknowledge reality=E2=80=9D = and =E2=80=9Cadhere to standards to ensure interoperation=E2=80=9D.
<= div class=3D"">
Not every = =E2=80=9Creality=E2=80=9D represents something that should change a = standard. Some can - and should - be declared as =E2=80=9Cbugs=E2=80=9D = or =E2=80=9Cerrors=E2=80=9D and called out for doing = so.

Yes, so = let=E2=80=99s do that=E2=80=A6 Let=E2=80=99s have this document = represent the current situation and then call out which parts of that = situation are considered to be bugs/errors
and which parts we = believe represent =E2=80=9Copportunities=E2=80=9D for improvements in = the standards.

If we are merely documenting what happens to be implemented, = we cease to be a standards body and become merely = reporters.

If we = avoid any introspection or consideration of operational reality, the = cease to be a relevant standards body and become an ivory = tower.

Owen

= --Apple-Mail=_3DFB6DB4-6B05-46CC-BFF7-CDCF1B1BFE4B-- From nobody Wed Jul 29 09:37:58 2020 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 B656B3A0C77 for ; Wed, 29 Jul 2020 09:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugHqIsjX6RZs for ; Wed, 29 Jul 2020 09:37:55 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAA53A0C70 for ; Wed, 29 Jul 2020 09:37:55 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id a14so912822edx.7 for ; Wed, 29 Jul 2020 09:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LeNuW5i6UUE8+F2OrlGZGXri2WjFejoPetzMRME7NOM=; b=Ruz/7OmkSMXpzjtxMqaDuem8Kom9y41dvlMnXdemnUHQXBUDHp8ljCDrNvozSkUOsP ifmGpHEimk39dWQFbj4ijID0IqyrkLBPt/Bik0Uk+tZgDMxmtxUveX8Thi1B7Zu34OfD nxp8ZGwhiRnUF3IKjtFMB4Jsn7KXyYYO8NOc2t2QkB/qGC5+hmVuZRXG5585Cz/q5k28 Mwdzygx0L2I55IGtpvJzPs/NPxsPbBP9FKODFYWKfnR2grPpVLU7A86fTvhwCY0+YJWX BQmwAzjdgy+9gDC4JCoeRfjmSky0AQ5aL1Nh1PFMR+LMaCjdSlWSWTah8G05AowYlwML 5NgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LeNuW5i6UUE8+F2OrlGZGXri2WjFejoPetzMRME7NOM=; b=SiDmCM/wjzt+l7hKGM91/vlfhAX2BM1m9kI7f6+kOH94A+StXGKy0yY9DGIWOWkFmz PZ+ScAk0h09lsUUiIp1GoMumYjqL3698lyNTjNvkhmK6d4tPwINMBJXZE7jVVRxh4pm8 o78jSYUNfE6yZe6WEJ/HzYs3eIvgZRhB3TTMn+C4WDDN64Fx6urM6O7IU5kfpFzdFyQJ NjUJ5rBclH0yqfzmYoCjmuPoGLMzFm3+oypQLtJd05I7QrsnbYHSPZksAho0ofjhnK6d Qi5L2nSNrtS18fJv+KMX+WufEtu4w+yLWgP1zbhIXo6UV6Btdys3wAoHJ+TXJZdvc5qY JVHQ== X-Gm-Message-State: AOAM531VRj26utG2N59jSHyRmxjKNFg+UgTVS3SvibRwWl+GeerRMB5I 2EbfPLU8cFk4TEji32rySw1AxsFU1c+cAh7v6X9Log== X-Google-Smtp-Source: ABdhPJw+sc1ndxGvn0iroeF9uBJIuoZmobc6SXVgWQDnQSQp6CA8+s4EKeckdomNfwXaxnwFbbQYeVPYmEyo8rI+SZ8= X-Received: by 2002:aa7:d5d0:: with SMTP id d16mr1664765eds.212.1596040673474; Wed, 29 Jul 2020 09:37:53 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> In-Reply-To: From: Tom Herbert Date: Wed, 29 Jul 2020 09:37:42 -0700 Message-ID: To: Fernando Gont Cc: Brian E Carpenter , Geoff Huston , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 16:37:57 -0000 On Tue, Jul 28, 2020 at 11:14 PM Fernando Gont wrote: > > Hi, Brian, > > On 29/7/20 01:03, Brian E Carpenter wrote: > [....] > >> It seems evident that the IPv6 packet structure makes a cost-effective > >> implementation rather difficult. Since engineering does not only have to > >> do with science, but also with economics, it follows that: > >> > >> * Folks (group #1) will not be willing to pay for features that their > >> clients do not explicitly require. > >> > >> * Vendors (group #2) will not spend cycles on something which will not > >> get them money in return. > >> > >> * Other set of folks (group #3) will not actively try to leverage > >> features with a high failure rate, since they would also need to > >> implement workarounds -- and if the workarounds already solve the > >> problem, with a much higher success rate, there's not much of a point in > >> spending time (and ultimately $$) in the feature that usually fails. > >> > >> * Users (group #4) use whatever solves their problem. > >> > >> > >> We may be unhappy with the above fact. But unless we're willing to pay > >> the bill :-), I'm not sure to what extent embarking into a Crusade would > >> solve the "problem". > > > > Not what I meant, really. > > FWIW, I do agree with you. My comment was a response to Tom where he was > objecting to folks that, for one reason or another, happen to drop > packets. (in this particular case the advice given by JOel in his > presentation) > > And what I meant is that rather that being mad about them, one should > try to find the reasons for which they are resorting to that (which is > what this document is meant to), and then figure out and do what we can > from a protocol engineering perspective. > Fernando, I agree with that and I do appreciate that section 3 of the draft describes several of the mitigations to make EH processing more palatable like the provision of RFC8200 that allows nodes to ignore HBH and the limits in RFC8504. It might be helpful in the draft to mention the relevant mitigations when discussing specific reasons for drops. For instance, if DOS is being discussed then RFC8504 should be mentioned in reference since the one purpose of limits on number of options is to mitigate DOS attacks (i.e. without limits an attacker could fill an MTU with 100s of unknown HBH options that an implementation, SW or HW, will choke on it). Another area that should be elaborated here, or maybe necessitates a separate document, is the parsing buffer problem described in section 5.1.1 by "If an IPv6 header chain is sufficiently long that its header exceeds the packet look-up capacity of the router, then it may be dropped due to hardware inability to determine how it should be handled.". I believe this is a real problem, but it's never been quantified. For instance, when a host creates a packet how can it possibly guess than some router in the path will drop the packet because the header chain is too long (not just IPv6 header chain by the way, but really all headers a node needs to process which can include transport or even transport payload). The draft for sending ICMP errors when packets are dropped is in the RFC editor queue, but I believe we can provide some sort of guidance that intermediate nodes are expected to be able to process at least X bytes of headers. This probably needs to broken down by what headers nodes process: a forwarding node might just look at IPv6 header and HBH options, an intermediate destination needs to look at routing header, a stateful firewall needs to get transport header, and application layer firewall needs to go even farther, etc. Tom > > > > All we can do here is write documents. So if > > the consensus is still what the standards track documents say, including > > Node Requirements, we have actually done our duty. > > That's in part correct. However, for cases where standards track > documents implementation become unfeasible or cost-ineffective, one may > need to consider being more flexible and reconsider the spec. > > A good example was the IPsec requirement in an early revision of Node > Reqs: it was words on paper that would never be complied with - so the > spec was changed to reflect that. > > I'm not necessarily saying that this is the case here, but rather that > that's an option that should be on the table. > > > > > And we have, in RFC8504: > > "All nodes SHOULD support the setting and use of the IPv6 Flow Label > > field as defined in the IPv6 Flow Label specification [RFC6437]. > > Forwarding nodes such as routers and load distributors MUST NOT > > depend only on Flow Label values being uniformly distributed. > > I retrospective, if it cannot depend on the FL (which I agree), is there > much of a point in using it? > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Wed Jul 29 12:56:31 2020 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 A812F3A0EAD; Wed, 29 Jul 2020 12:56:29 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luitZy6exI35; Wed, 29 Jul 2020 12:56:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 61A043A0EA9; Wed, 29 Jul 2020 12:56:27 -0700 (PDT) Received: from lhreml707-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6E56C24BE8485A34F3CA; Wed, 29 Jul 2020 20:56:25 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 29 Jul 2020 20:56:24 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 29 Jul 2020 22:56:24 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 29 Jul 2020 22:56:24 +0300 From: Vasilenko Eduard To: Jen Linkova , 6man CC: "v6ops@ietf.org" Thread-Topic: I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AdZl2/KmEr6Lt/NERGGqFiMA7k1/CA== Date: Wed, 29 Jul 2020 19:56:24 +0000 Message-ID: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.199.195] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 19:56:30 -0000 Hi Jen, You did ask a feedback yesterday about severity of 7sec security hole that = has very low probability. I have intention here to show that probability is 100%, 7sec could be prolo= nged to forever, and the final result is the full interception of innocent = host traffic by intruder (successful "man-in-the-middle"). Pre-request for success: - no multicast snooping (MLD) and filtering on a switch, that is perfectly = possible - Intruder should be already on the same subnet (gained control over other = host by exploiting of different vulnerability) - intruder should suppress DAD on Intruder's controlled host (is Windows fi= rewall capable to filter out DAD?) - We assume that we are talking about the future when this draft is used by= majority of nodes (victim should use it) Procedure:=20 Intruder's controlled host does listen to all-routers multicast address (ff= 02::2). As soon as it would eavesdrop unsolicited NA from victim node (probably aft= er boot) - Intruder would immediately (a few milliseconds) duplicate NA in = router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override bit= set. Intruder has time only up to the point that response to victim's traffic wo= uld be returned from the Internet (from tens of milliseconds to many second= s if victim would not start sending immediately), - but it is enough time: = local communication should be faster. Theoretically, RetransTimer should be imposed on unsolicited NA (section 7.= 2.6), but low chances that this timer is checked on receiving side (router)= , because RetransTimer is specified for transmission side. According RFC 4681 section 7.2.5 clause II: O bit set should not just rewri= te ND cache, but additionally mark ND record as REACHABLE. According to sec= tion 7.2.6: " The Override flag (for unsolicited NA) MAY be set to either z= ero or one". Despite it contradicts to the logic of the whole RFC 4681 (O b= it should not be set in unsolicited NA - it is mentioned in a few places of= RFC 4681). But because section 7.2.5 and section 7.2.6 clearly permit to u= se Override flag - higher probability that particular implementation would = not just rewrite LLA on router, but additionally put it into REACHABLE. Intruder could be sure that at least STALE state would be created according= to section 7.2.5 clause I, - this ND record would be against his LLA anywa= y. After receiving return traffic (if it was created as STALE, not REACHABLE) = - router would ask intruder about reachability (solicited NS-NA) - intruder= would confirm his LLA - it would finally put ND cache record into REACHABL= E. That's it: upstream traffic of victim host is going to router, traffic back= is going through Intruder. I have consulted with penetration tests professional (these are people with= the same qualification as hackers but they play on legal side): what he wo= uld be doing next? He said that he would return traffic to legitimate host = - victim should not see performance degradation. He would collect cookies a= nd some other valuable information. He would finally see DNS response, chan= ge it and redirect everything to himself on the permanent basis - he does w= ant to see both directions of victim exchange. He has qualified Man-in-the-= middle as full fiasco - it does open many opportunities for him. He has men= tioned very good feature of this draft that there is no any interruption fo= r victim's traffic flow, no any excessive traffic to victim, that is very r= ear benefit for hacker's tool. What to do about it? 1. Potentially it is possible to do RPF-like check for Source LLA addresses= . Upstream traffic from victim's SLLA would not be in ND cache - such traff= ic could be discarded. It is better to block communication than permit intr= uder to exploit vulnerability. 2. Increase RetransTimer and ask receiver side (router) to check on sending= side delay between ND record override (for the same SLLA). But how long sh= ould be the timer? Host could wait a lo-o-o-ng time before it would request= 1st information from internet. It would decrease probability, but would no= t completely eliminate attack vector. My proposition for this draft is disruptive: I believe that ND is very complicated (some could say "fragile") - it is be= tter not to touch it. Additionally I do not like to wait till all hosts would refresh to new draf= t (to get new functionality). I propose to change only router behavior: check Source LLA (MAC) for every = packet, if this SLLA is absent in ND cache - then request solicited NS-NA i= mmediately. It would probably resolve faster than traffic would return from= the internet. Effectively I do proposed the same SLLA RPF that is needed to fix current s= olution, but: - without any modification to host OSes - without any modification of standard (it is local recommendation for rout= er, NS-NA is exactly the same from RFC 4681, NA is unicast - it is importan= t for security) - without any risk to break ND fragile algorithm - it could be optional, or even configurable on the router as "value add fe= ature" in competitive tender Because it is just best practice recommendation - may be it make sense to m= ove it to "v6ops"? PS: Looking to the above - unsolicited NA should be really delayed by addit= ional big timer (not by RetransTimer that is used for solicited NS/NA) and = checked on receiver side - this modification of standard is really needed t= o close Unsolicited NA vulnerability. Somebody said on the call that it is already a feature of some OS (Android?= ) - it is bad: it means that this OS is already vulnerable. It is just important to understand: do they practice it on tethering? I do = not see the reason to practice it on 3GPP link. Eduard -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova Sent: 27 =C9=C0=CC=D1 2020 =C7. 7:49 To: 6man Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt Hello, The -01 version addresses comments received (thanks everyone who provided f= eedback). Also, Section 3 (Avoiding Disruption) has been expanded and discu= ssed a corner case when two devices start using the same address almost at = the same time (the second device configures an optimistic address after the= rightful owner sent some packets but before the return traffic arrives). Feedback on the updated section 3.3 (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is very = much appreciated. On Sun, Jul 26, 2020 at 10:14 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > Title : Gratuitous Neighbor Discovery: Creating Neighbo= r Cache Entries on First-Hop Routers > Author : Jen Linkova > Filename : draft-ietf-6man-grand-01.txt > Pages : 12 > Date : 2020-07-25 > > Abstract: > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the > link-layer addresses of neighboring nodes as well as to discover and > maintain reachability information. This document updates RFC4861 to > allow routers to proactively create a Neighbor Cache entry when a new > IPv6 address is assigned to a node. It also updates RFC4861 and > recommends nodes to send unsolicited Neighbor Advertisements upon > assigning a new IPv6 address. The proposed change will minimize the > delay and packet loss when a node initiate connections to off-link > destination from a new IPv6 address. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-grand-01 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- SY, Jen Linkova aka Furry -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Wed Jul 29 13:17:03 2020 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 E752A3A0EC6 for ; Wed, 29 Jul 2020 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-EgMuz_1nf9 for ; Wed, 29 Jul 2020 13:16:59 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 D49B43A0EC5 for ; Wed, 29 Jul 2020 13:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ciCMpvvhWvf8xn+5s+EkfgX1gaxb8QJR69Ve3ial3Ic=; b=owNBa8F+twEttTV8O2VUVy9AI dBPi8WsoJRod1tCcrlotqYobFQDsE8LJO8z+1Edfdujjs2GEBhcqqYUUQRiBBk1ug1kZKmuEgs8e+ oRO4t9Ysm73Oda6zUQdApkrwA1maKYyOFwKcS22OoUU5XEpJqm8M18HOOc38jrdyo7JcNHutZpjPS xwfTp3ld1hiVVFiKIVFBFUhEE4Ccy9XD1Lo3P7Irqjh1PnuX0aaKWbnZqf35TLAaC6zeI7agHQreg zfTnuuqN3lafst1OX/N2OAoQHSATouVsooljwClPbypaAgYiApWuuSNb7ujUSCqJ6XiW4KcI+R137 UUeoxy5sA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56811 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k0sVP-0006Uc-9c; Wed, 29 Jul 2020 16:16:55 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Wed, 29 Jul 2020 13:16:47 -0700 Cc: Fernando Gont , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <44481FC7-6E3F-4D5A-A5A9-A338C1836EA1@strayalpha.com> References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> To: Owen DeLong X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 20:17:01 -0000 > On Jul 29, 2020, at 9:32 AM, Owen DeLong wrote: >=20 > ...Let=E2=80=99s have this document represent the current situation = and then call out which parts of that situation are considered to be = bugs/errors > and which parts we believe represent =E2=80=9Copportunities=E2=80=9D = for improvements in the standards. Agreed. >> If we are merely documenting what happens to be implemented, we cease = to be a standards body and become merely reporters. >=20 > If we avoid any introspection or consideration of operational reality, = the cease to be a relevant standards body and become an ivory tower.\ That=E2=80=99s why I said =E2=80=9Cmerely=E2=80=9D. Doing both and = appreciating the balance is fine - the point is that =E2=80=9Cwhat is = implemented/able TODAY=E2=80=9D is NOT the only consideration. Joe= From nobody Wed Jul 29 13:47:04 2020 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 253E03A0EF2; Wed, 29 Jul 2020 13:46:40 -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=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_8GXoT3yR-w; Wed, 29 Jul 2020 13:46:37 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDEA3A0EF4; Wed, 29 Jul 2020 13:46:37 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 06TKkXBq094749 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2020 21:46:34 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Tom Herbert Cc: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> From: Nick Hilliard Message-ID: Date: Wed, 29 Jul 2020 21:46:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.24 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 20:46:40 -0000 Tom Herbert wrote on 29/07/2020 17:37: > I agree with that and I do appreciate that section 3 of the draft > describes several of the mitigations to make EH processing more > palatable like the provision of RFC8200 that allows nodes to ignore > HBH and the limits in RFC8504. It might be helpful in the draft to > mention the relevant mitigations when discussing specific reasons for > drops. For instance, if DOS is being discussed then RFC8504 should be > mentioned in reference since the one purpose of limits on number of > options is to mitigate DOS attacks (i.e. without limits an attacker > could fill an MTU with 100s of unknown HBH options that an > implementation, SW or HW, will choke on it). there are often no mitigations as limits are often related to hardware. > Another area that should be elaborated here, or maybe necessitates a > separate document, is the parsing buffer problem described in section > 5.1.1 by "If an IPv6 header chain is sufficiently long that its header > exceeds the packet look-up capacity of the router, then it may be > dropped due to hardware inability to determine how it should be > handled.". I believe this is a real problem, but it's never been > quantified. For instance, when a host creates a packet how can it > possibly guess than some router in the path will drop the packet > because the header chain is too long (not just IPv6 header chain by > the way, but really all headers a node needs to process which can > include transport or even transport payload). First, only SRv6 proposes to add EHs and I think we're all familiar with the difficulties that were outlined in that discussion. So in the general case, it's up to the host to decide how many EHs to attach to a packet. Obviously as there's no EH negotiation mechanism, there's no way for a host to know what will work and what won't, and even if there were, intermediate paths change so what might work on setup might not work later on. We have the same problem with MTUs. There are some limits already defined in IETF standards track documents (e.g. that you can have no more than a single packet with EHs attached), but real life limits are much lower. It may be useful for a future document to quantify the problem. This aim of this document is to state that there's a problem. Nick From nobody Wed Jul 29 13:55:26 2020 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 A086F3A0DBF; Wed, 29 Jul 2020 13:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMOBHnc7DeSd; Wed, 29 Jul 2020 13:55:18 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320051.outbound.protection.outlook.com [40.107.132.51]) (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 16DE03A0DC5; Wed, 29 Jul 2020 13:55:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hZqS+zF4zlruzwNtEZyqPJ0yvX3o+CcNND8051OvcYjsT2baegsamvDYxoUA3UvJzwZETloasktQKWaTHPZzZNJXznI1Te3lJuOTS3GbbSBhHpocwDEyac2tzJrob/axhtKTYIdEus0hjenmfl24Vdf34w3kg6VKCIb8w3S65qZya6soHT1+TqqrhcbH4lRpUg/BLsSz+1f/d6XXFNr8kFsrgG3N7Q6cPz839Zj5ES2uEC2zSXps/Nl/sQNSty//CR/u7GizbAO5OEiNTRRIequPK+fQOOHV9JhQXFypbheq/MLPiqNh2FA4MKvqZWt4K0QDMNwwJMm8PJe/bnvf7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TwDYDiketSGcMPhiY2zfHHSMSyFsvG8LTzfN8lSE5w8=; b=N6QcJkbcdY6HdMVWng4wADtrWpofxQXP0b1ejsnfarE5nKdVOV/Lnw2xltokWVsWgM1b+mfzmEU3E+MaOpp/edCdO0iZ2x0+j7SPFluI1sGtZ4fo/rrCSSJxwc2GzpFXEkpmfUk74OE+N5tY8ljyN5dK3Il1o8NISkHIjyy/pOIZzSNg9U8oa060CrPtwu3smE361HgHWGxhuASHmsPYokDyTLh+5raDDlf+Ua3e0jmJl2zoaqvUI/cZBm8VAHehHtCBwFdL+2tbDHkpoX0sLHWUjT2IoccmIrbrLxRiF7zl0Z/0TgC7W9DTS7o+pSdjc63+O0yjAlELJ5NuSUH7zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TwDYDiketSGcMPhiY2zfHHSMSyFsvG8LTzfN8lSE5w8=; b=G3qdrl9aGmDWgcGKj/fXjU+sAAft5xnDuCryIPOPzAfPfjNu5AeJol2wu36itKrzhSfhVa06kqsuyn2GhB1Rkuy/yuy3GBIMp+vfKLo8eNoIAGRGraLMSxNa1FIeXaFpeyFNtLQurTuF7Ow15hxVg/TdVotJuprQ7V3gEhbzgRY= Authentication-Results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=apnic.net; Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TY2PR04MB3246.apcprd04.prod.outlook.com (2603:1096:404:9d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 20:55:05 +0000 Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::69aa:ca1d:4b48:1b24%6]) with mapi id 15.20.3239.017; Wed, 29 Jul 2020 20:55:05 +0000 Content-Type: text/plain; charset=utf-8 From: Geoff Huston In-Reply-To: Date: Thu, 30 Jul 2020 06:54:57 +1000 Cc: Tom Herbert , IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> To: Nick Hilliard X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ClientProxiedBy: SY2PR01CA0011.ausprd01.prod.outlook.com (2603:10c6:1:14::23) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:44b8:110b:5100:7430:4193:d6e9:1588] (2001:44b8:110b:5100:7430:4193:d6e9:1588) by SY2PR01CA0011.ausprd01.prod.outlook.com (2603:10c6:1:14::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Wed, 29 Jul 2020 20:55:03 +0000 X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Originating-IP: [2001:44b8:110b:5100:7430:4193:d6e9:1588] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4f37f1ae-3c5d-4d65-c23b-08d83401ab57 X-MS-TrafficTypeDiagnostic: TY2PR04MB3246: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xfzetEk9DlcJlxqUn25gU3JOQwdxmFIKwDuK6YcdLk4wo1A+qjYOjMSgt/rcWjGDwsgs6BUCbW5GbkHCF+EbyLYot15c0thSaj6CpKU2SxUReRZ2nU28j/CIlMPuUQunFQAnMrbjCr3XEqT3G5R6sR6e6vBEYD2F5C8y67PTedxgTIL0GIXPb9PVyemDbDgP+tjDucY2YgCBM+5FAn9o4JckRMcnwQkMtBgQrSauQcQJX0uxNxtdK+rubmBBJ5SxFljos8PljXBjys3ucK0MWAb97MBVHPtOiV/43qbxPh4ZUIdIjNw4973vEhcj72M7/BMDdzR/X/fe0bX3ofXiM5GE0oClRZa5x3ZuHqO1OgCs4mZurz+kG083zMQ0E0IOSDqW1SzbhLamKReOrJI55g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(366004)(136003)(376002)(39840400004)(966005)(4744005)(33656002)(8936002)(16526019)(2906002)(186003)(6916009)(8676002)(86362001)(6486002)(478600001)(5660300002)(2616005)(66556008)(66946007)(4326008)(36756003)(54906003)(52116002)(316002)(6666004)(66476007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: otorRsa7f0YqY6fBdki3pPaqulF/hM737Gn5lK3B3mH574SoTuCrHox8STJkm2dBisOQ7Gnx25hu7oPoVS/SOvhB3arzEYDqhSzDSUmuMWt/MbbZGsGfUpt1Qs478FKgP3IUp7AMpyAqvCMm7a58pzzjMCrvychJN3rzq0X7kKZsXOqDJyJtFr1oPMWa0TxtA4zyy4QfVa9SwLt3Ckk4FnmUn3UQWK5ca4aU0bfjqcOMGN/8d6YPIDmP6Zb5jeyEXV0gH6be378SvMbX7mQ2EgnDCIuwd0TlOuJe5YYC2f/8YwaFWT7jHGy9GPl9q/8Ktgdt1O0RpSNmnsx6KU3HRTdpGRUJ9Ujk0L+H47491Af2i4JNfQz9kjD6W6+bj2xCLDw6fyMhXc6oV6pdx3JAri+p/PJY+QiackuqzOWe3GNNRVNeAtGhok+oiLEr5rft8bINpWPgNion7W1kRl9OvZFPsAv//VkxP6qyGqgT288vb0ROJZR+6tzQW9wo7Bfgwb8GF2/UYwzgKtGxuX/yqSejXfd3HSMbQSHXCe93QkcjwsLTSZyXhnBXm8TplSDA X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4f37f1ae-3c5d-4d65-c23b-08d83401ab57 X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 20:55:05.1239 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: epjFj+xqIVIamytwgEicHrnBQzE/f5t/WAzovfmwMQsbVLR2pbNxno9uX88pkH8A X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR04MB3246 Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 20:55:22 -0000 >=20 > It may be useful for a future document to quantify the problem. This aim= of this document is to state that there's a problem. RFC7872? also some of my measurements: https://www.potaroo.net/ispcol/2017-08/xtn-hdrs-2.pdf https://www.potaroo.net/ispcol/2020-07/dns6.html Yes, there=E2=80=99s a problem. And yes, its a widespread problem and there= is documentation on measurements that substantiate this. Next? From nobody Wed Jul 29 14:06:26 2020 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 B674E3A0EFE; Wed, 29 Jul 2020 14:06:24 -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=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7yZzTzAPxny; Wed, 29 Jul 2020 14:06:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A548D3A0E5C; Wed, 29 Jul 2020 14:06:20 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 06TL6BYr097023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2020 22:06:12 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Geoff Huston Cc: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> From: Nick Hilliard Message-ID: <7bc3e01f-4f65-da52-46a0-9d24fe343c1d@foobar.org> Date: Wed, 29 Jul 2020 22:06:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.24 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 21:06:25 -0000 Geoff Huston wrote on 29/07/2020 21:54: > Next? next would be quantifying in cases where EHs are passed, how many EHs might, or mightn't get through. Nick From nobody Wed Jul 29 14:42:00 2020 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 582133A041A for ; Wed, 29 Jul 2020 14:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYAQ34LX81JG for ; Wed, 29 Jul 2020 14:41:51 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10643A07A0 for ; Wed, 29 Jul 2020 14:41:50 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id qc22so11061239ejb.4 for ; Wed, 29 Jul 2020 14:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z1SFOHaAg0vsZQP1bxnvp0uL7KDJuwnHoluiSLWb1UI=; b=G8yjDtjsJQX0ooG+85xTh/QK/5TCAHgKLusn4NcZUb56rxARLgnjTE62LP4TFNRja4 d17ZyvnCfz2Wz2+Tdqu/0aFcHeVmQpTtBH9hRofNZsP0ygp945lTsXjnlPZXTRsdokfc eOhgxiMcZV0QcGN1HHyCfHtgNOtJr5z/62K7HsfYXoeNDHIkMTnGlO5p8C3a6A3ktVhb /+emo3Fr7OWU8Kv14fH8kHi200EmzTBZdT36j7W00FI/9lTr8kIg+vWECwpM0neNi49o CYEqcmKhLNwAdf7snEbISqRb/abrq5YpcfzV7srX0RPB+0CVoyktqRdprMkXD7+DsbW7 hqxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z1SFOHaAg0vsZQP1bxnvp0uL7KDJuwnHoluiSLWb1UI=; b=g4oJnTfwnpAAvbLr1F4rSRFC2zdtLtFsZH53pi1OOg4V2bGQ1fDhbnIhGyBrrhxUzQ OKlpeWbBBNEzAkjXzMtlELn/fS+q7iO3guiefON97FPW7DoE8z6ruNPNrssfD2RP/EHs +4WXIrqwMB4cxmi2oQ7O7HgR5gLkWQNNJaQr9HqmIaTwUuEfHZ0ozp+Q9uF5zU5akka0 2PAphqHBurSAx49Sb9DchmiA2Ru5u28HNjhTLZei8M6yyIIW5Ys2Dy/Pbcea7sJ9McxS NfYVvYwHH3rnXcWmLwm15lihJX6eBuCXSWOUn5NnLJtPyvLdBQju6m3lEetpPndx3SVi /IPw== X-Gm-Message-State: AOAM533koQnReaaIfpz7uFvSsWdMChC37Enn49x3zPBWKgkiEqJr2cqr V3ngOqbKHpNJa7vg/0ZoWBZtPXjoz7ypFCdqcwdVVtwI X-Google-Smtp-Source: ABdhPJzp7kM+HYcMyVEneV6HweycJf3WbykSn0d1ncQSecw4tflDwXv0sqY2odwzjTrOrwZt//P/YMUiJC1SGTsxrqs= X-Received: by 2002:a17:907:aaa:: with SMTP id bz10mr350296ejc.304.1596058908587; Wed, 29 Jul 2020 14:41:48 -0700 (PDT) MIME-Version: 1.0 References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> In-Reply-To: From: Tom Herbert Date: Wed, 29 Jul 2020 14:41:37 -0700 Message-ID: To: Nick Hilliard Cc: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 21:41:59 -0000 On Wed, Jul 29, 2020 at 1:46 PM Nick Hilliard wrote: > > Tom Herbert wrote on 29/07/2020 17:37: > > I agree with that and I do appreciate that section 3 of the draft > > describes several of the mitigations to make EH processing more > > palatable like the provision of RFC8200 that allows nodes to ignore > > HBH and the limits in RFC8504. It might be helpful in the draft to > > mention the relevant mitigations when discussing specific reasons for > > drops. For instance, if DOS is being discussed then RFC8504 should be > > mentioned in reference since the one purpose of limits on number of > > options is to mitigate DOS attacks (i.e. without limits an attacker > > could fill an MTU with 100s of unknown HBH options that an > > implementation, SW or HW, will choke on it). > > there are often no mitigations as limits are often related to hardware. > > > Another area that should be elaborated here, or maybe necessitates a > > separate document, is the parsing buffer problem described in section > > 5.1.1 by "If an IPv6 header chain is sufficiently long that its header > > exceeds the packet look-up capacity of the router, then it may be > > dropped due to hardware inability to determine how it should be > > handled.". I believe this is a real problem, but it's never been > > quantified. For instance, when a host creates a packet how can it > possibly guess than some router in the path will drop the packet > > because the header chain is too long (not just IPv6 header chain by > > the way, but really all headers a node needs to process which can > > include transport or even transport payload). > > First, only SRv6 proposes to add EHs and I think we're all familiar with > the difficulties that were outlined in that discussion. > > So in the general case, it's up to the host to decide how many EHs to > attach to a packet. Obviously as there's no EH negotiation mechanism, > there's no way for a host to know what will work and what won't, and > even if there were, intermediate paths change so what might work on > setup might not work later on. We have the same problem with MTUs. > It's not really the same thing. There has been a lot of work in PMTU discovery mechanisms, but not a lot of work in Path-Parsing-Buffer-Size discovery. > There are some limits already defined in IETF standards track documents > (e.g. that you can have no more than a single packet with EHs attached), > but real life limits are much lower. > Okay, so then we recognize a gap between the protocol specification and reality. How do we close that gap? Seems like a first step is to quantify the problem. For instance, if you say real life limits are much lower then can you quantify exactly how much lower they are? > It may be useful for a future document to quantify the problem. This > aim of this document is to state that there's a problem. Sure, but our ability to analyze the problem is largely dependent on how well the problem is described. For instance, if we say some nodes drop packets because header chains are too long without defining what "too long" means, that isn't an actionable engineering description of a problem. Tom > > Nick From nobody Wed Jul 29 16:59:03 2020 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 D6BB03A0A55 for ; Wed, 29 Jul 2020 16:59: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFcvGsRqP4UG for ; Wed, 29 Jul 2020 16:59:00 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B173A09AC for ; Wed, 29 Jul 2020 16:59:00 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id h12so4093303pgf.7 for ; Wed, 29 Jul 2020 16:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9SUQs55rTYI8TVKGlSNf+f1VayMnh9QATINxt8oqY0g=; b=UOv/IxZsI4AXOsjd1USfihCpotV8zREs6URrAKiORsEV662aZGCc3lnbsNYHbfwO1z lwdlldiY7d/AbOyopERZ7guXd+X5ZsSLJclE9T6BXNgYaqbZHDkiiQmHIM0KLrlOe+SW XkRtEUYoc2Rki9U75U+m3y0f0ZggH4xZ5ov510cOqCXm8D1FDDgnz0QJt0qTMTYrTr2t CU8gYYlGnVPDmpUMVJ7DbjnHVgnrFEy242d2sw2u3x0xiOL30kEGIHPrrtB68cGTm76U NfmYOGHF+fHOZO9lLRg1MS4RFIl9+hF+Lzw17Mpces5zu1DbtcGU9KI39pyQxDMPAzBr 1BVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9SUQs55rTYI8TVKGlSNf+f1VayMnh9QATINxt8oqY0g=; b=Yes6UY149YZ7/PSA/ZGI2FL0wClOstnfxRUjSqzydiHywBf9jWKPRGIIkNBeR7KhYm 3U2aYYANupqdhDIHqAvft0d41PSPFhRnPHYl9oTQH2CoBbXlHC4jxMnFzNSWAgljbn10 jfuuN3gPtXO1RTvCKll0FIKIYTfFeQJchogcmZqojlM+uUR5KICpqKhsW2+JZsAEWpLD UvIHzcJIVA7sFOyN1r/Hz06FQvv919U4NFv/E7tpE7MPaJr34lN6RAaoSzLONYY1l5Ln xj6u0wnz/OxmDAgz7Yqv0QDCsYjg3DVxtg7vcoqSQFCOb99Pc7ZgmaKOiJTmI3Q1lk7e MknA== X-Gm-Message-State: AOAM533iMR6IMp6SX2hinSVKadH2qZS4RggamfcaW0v6jxKJ2NzsvgBK OTHuiZYuwAVBNBt0WstkYYo= X-Google-Smtp-Source: ABdhPJwsR1UYtCX+RKi7sBW9jf1XPvC+iiA7CIQ5L7qHNLWoyPgZJAPlBjfbrHDy2Arr6/EL/CVxAw== X-Received: by 2002:a63:338c:: with SMTP id z134mr31131530pgz.245.1596067139697; Wed, 29 Jul 2020 16:58:59 -0700 (PDT) Received: from [130.216.37.183] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.37.183]) by smtp.gmail.com with ESMTPSA id b13sm3555125pjl.7.2020.07.29.16.58.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 16:58:59 -0700 (PDT) To: Tim Chown , Fernando Gont Cc: IPv6 Operations , Fernando Gont References: <159574132870.611.12077598721404194383@ietfa.amsl.com> <5f0f7715-ff53-e5b2-6803-df1aac573060@gont.com.ar> <53a8e94d-dfc3-23f9-2dac-b70eb4f203a8@gmail.com> From: Brian E Carpenter Message-ID: <28cdd990-49e1-7b83-18bf-1599f69becf6@gmail.com> Date: Thu, 30 Jul 2020 11:58:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 23:59:02 -0000 Comment right at the end... On 29-Jul-20 20:37, Tim Chown wrote: > Inline... >=20 >> On 29 Jul 2020, at 08:58, Fernando Gont wrote:= >> >> Hi, Tim, >> >> On 28/7/20 11:32, Tim Chown wrote: >>> Hi, >>>> On 27 Jul 2020, at 21:51, Brian E Carpenter wrote: >>>> >>>> On 27-Jul-20 18:49, Fernando Gont wrote: >>>> >>>>> BTW... it seems that RFC7045 has not really been incorporated into >>>>> RFC8200? >>>> >>>> Well, yes and no. Firstly the point about HbH header processing >>>> being essentially optional was adopted. Similarly, RFC7045 says >>>> "This document updates RFC 2460 to >>>> clarify how intermediate nodes should deal with such extension >>>> headers and with any that are defined in the future." >>>> and that, I believe, is reflected in RFC8200. >>> It may be worth pointing out that RFC 7045 was included in the IPv6 N= ode Requirements >> >> Maybe we can tweak the text to say something along the lines of: >> " A number of recent RFCs have discussed issues related to IPv6 >> extension headers, specifying updates to a previous revision of the >> IPv6 standard ([RFC2460]), most of which have now been incorporated >> into the current IPv6 core standard ([RFC8200]) or the IPv6 Node >> Requirements [RFC8504]). Namely," >> . >> . >> >> ? >=20 > Maybe. RFC8504 largely assembles text from elsewhere, e.g., from RFC82= 00, but there are some examples where it adds more that isn=E2=80=99t sai= d in another RFC. >=20 >>> - bis work and thus into RFC 8504, with the =E2=80=9Cnodes SHOULD for= ward packets regardless of EHs present=E2=80=9D text repeated there. >>> EH-related requirements in RFC 8504 are explicitly covered in https:/= /tools.ietf.org/html/rfc8504#section-5.2. >> >> By the way, our working copy says: >> >> "[RFC8504] specifies processing rules for packets with extension heade= rs, and also allows hosts to enforce limits on the number of options incl= uded in IPv6 EHs." >> >> Maybe we should say s/specifies/clarifies/ ? >=20 > And this is one example of adding more. I believe the text about such = limits was put forward for section 5.3 of RFC8504 by Tom Herbert, and the= re was good agreement to include this text. Ideally it might be in a sep= arate document, to which RFC8504-bis refers one day.=20 >=20 >> FWIW, I don't mind noting =E2=80=9Cnodes SHOULD forward packets regard= less of EHs present=E2=80=9D, but in a way wouldn't that misrepresent bot= h RFC8504 and RFC7045 a bit, which essentially elaborate on the caveats f= or the SHOULD (and hence are way more than to eartg that RFC8200). >=20 > What is included in Section 5.2 of RFC8504 on this subject is simply: >=20 > " Further, [RFC7045] adds specific requirements for the processing of > extension headers, in particular that any forwarding node along an > IPv6 packet's path, which forwards the packet for any reason, SHOULD= > do so regardless of any extension headers that are present.=E2=80=9D= >=20 > The more specific notes on this are in Section 2.1 of RFC7045, so I=E2=80= =99d point to that as the authoritative source of the "SHOULD forward reg= ardless=E2=80=9D guidance. The subsequent words there about what firewa= lls SHOULD do perhaps flies in the face of what vendors include by defaul= t and operational practice though? Well yes, and that's the problem. Whether it's a problem in the real worl= d or in the RFC dream world is a separate question. The fact is that real= -world firewalls have not been dseigned to do their job properly at line = speed when a variety of extension headers is present. Brian From nobody Wed Jul 29 19:07:15 2020 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 DFFAA3A0B82; Wed, 29 Jul 2020 19:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lxdJ_Q77wlm; Wed, 29 Jul 2020 19:06:59 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554553A0B7D; Wed, 29 Jul 2020 19:06:59 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id u64so24254587qka.12; Wed, 29 Jul 2020 19:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nDQA/JAQTU7ESQ3iZJHC6BEyUvWgkGh8cA2HPNz0zPk=; b=fyGoqOJAJcccLM7CQfBbOVG6VqbOq/llYLbB+15//U6mwYM9PoJQNZkkXhkGNygA/+ N4tgRZRv0FsWzlPwCDG1t8vFOVTZ2UEXTn9gTjxuuOyUCo0AJBK/dzlOzMu36XxFkR2Z OCTeMoJ7gRONsL4rwYRr5r+h3H57kDJCEdP3RsXDJIM1iLKM7p8PO6Bl6eZ6olaB46i8 y+bz6we3tw6NEQpsv/wBbTi5DzLy9tNjuU3a7wR0bI5HB3J0F9wAAe3w9wF1TpDHeGhC RPR+Hx/ofvy4219sCMTZ6c7Nw/DdT26acJiM8sawSadyGK0Um9p65eDDGWGEBfUn/Jes IyHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nDQA/JAQTU7ESQ3iZJHC6BEyUvWgkGh8cA2HPNz0zPk=; b=a1GfVsbO5I+zHUTykw2bGGOh0yxlB8qvVc7lD/h5/iOapXkCjBFBQ5wwB7dpaAfijV g+kVFSpyN2WVpU7UtEXNjDbU/mRPC4Y/MEz9818d1GufIJOeGGj5tmuBuKCKzN0/zG+u VEaeTTUL+qXS05dSB7w3JxmMa0TO7LaBxfQm7Nqj5560D77Khn2ks1ZAd2c7eRAZqDnB 0wGT45t8jIPWV1RBAsO402/EGgdSbMKAR45FeM0zLn3lt3UVqGmtDde5ZlAcYIqL/qQP /SNHIT+Wa/F2ATR14Gn/ezbQ7v39vmjDBL1y048ZQD2rW4TzoOZpZbKrQV59+gH2G9bn Jn2w== X-Gm-Message-State: AOAM532PXkH0lyOFXp3sM4G2Ba+H+V56vc9cZNQruCgEhmpcbvPy45Nb udHX928XQtD4Fr1kXpzvLRZSqbx++g2yDA5TKlQ= X-Google-Smtp-Source: ABdhPJzDIV368QavdL9JCy05pgdTk7FkLHHZgD81lZC1VnyqmvPcQP7qMDIutLDm+qi2nrZJIEAQzT1TG6r/VTLLdUc= X-Received: by 2002:a05:620a:a05:: with SMTP id i5mr20262939qka.444.1596074818229; Wed, 29 Jul 2020 19:06:58 -0700 (PDT) MIME-Version: 1.0 References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> In-Reply-To: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> From: Jen Linkova Date: Thu, 30 Jul 2020 12:06:46 +1000 Message-ID: To: Vasilenko Eduard Cc: 6man , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 02:07:02 -0000 On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard wrote: > You did ask a feedback yesterday about severity of 7sec security hole tha= t has very low probability. > I have intention here to show that probability is 100%, 7sec could be pro= longed to forever, and the final result is the full interception of innocen= t host traffic by intruder (successful "man-in-the-middle"). > > Pre-request for success: > - no multicast snooping (MLD) and filtering on a switch, that is perfectl= y possible > - Intruder should be already on the same subnet (gained control over othe= r host by exploiting of different vulnerability) > - intruder should suppress DAD on Intruder's controlled host (is Windows = firewall capable to filter out DAD?) > - We assume that we are talking about the future when this draft is used = by majority of nodes (victim should use it) > > Procedure: > Intruder's controlled host does listen to all-routers multicast address (= ff02::2). > As soon as it would eavesdrop unsolicited NA from victim node (probably a= fter boot) - Intruder would immediately (a few milliseconds) duplicate NA i= n router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override b= it set. > Intruder has time only up to the point that response to victim's traffic = would be returned from the Internet (from tens of milliseconds to many seco= nds if victim would not start sending immediately), - but it is enough time= : local communication should be faster. > Theoretically, RetransTimer should be imposed on unsolicited NA (section = 7.2.6), but low chances that this timer is checked on receiving side (route= r), because RetransTimer is specified for transmission side. > According RFC 4681 section 7.2.5 clause II: O bit set should not just rew= rite ND cache, but additionally mark ND record as REACHABLE. According to s= ection 7.2.6: " The Override flag (for unsolicited NA) MAY be set to either= zero or one". Despite it contradicts to the logic of the whole RFC 4681 (O= bit should not be set in unsolicited NA - it is mentioned in a few places = of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly permit to= use Override flag - higher probability that particular implementation woul= d not just rewrite LLA on router, but additionally put it into REACHABLE. > Intruder could be sure that at least STALE state would be created accordi= ng to section 7.2.5 clause I, - this ND record would be against his LLA any= way. > After receiving return traffic (if it was created as STALE, not REACHABLE= ) - router would ask intruder about reachability (solicited NS-NA) - intrud= er would confirm his LLA - it would finally put ND cache record into REACHA= BLE. 1) the 7 seconds corner case was for 'preventing address collision for Optimistic DAD', not for any intentional attacks case. Because: 2) What you are describing could be done today, now, anytime w/o the changes described in the draft. If there is no MLD snooping then the intruder would see the DAD packet from the victim, so it would know the victim address anyway - no reason even to join ff02::2. Now all the attacker needs to do is to keep sending NA with S=3D1, O=3D1 - hoping that when the first packet of the return flows arrive and the router creates an INCOMPLETE entry and sends an NS, the attacker's packet would come before the victim's NA. Done, the entry is changed to REACHABLE, all traffic goes to the attacker. Actually even simpler. The attacker does not need to deal with timing. Let's say the router has an NC entry for the victim address in any other state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Target address =3D the victim's IPv6 address, the TLLA =3D the attacker MAC address. Done. The router updates the cache entry and changes it to REACHABLE state. There is nothing new here. We have the same issue with ARP - the attacker can override ARP entry on the router. > That's it: upstream traffic of victim host is going to router, traffic ba= ck is going through Intruder. > I have consulted with penetration tests professional (these are people wi= th the same qualification as hackers but they play on legal side): what he = would be doing next? He said that he would return traffic to legitimate hos= t - victim should not see performance degradation. He would collect cookies= and some other valuable information. He would finally see DNS response, ch= ange it and redirect everything to himself on the permanent basis - he does= want to see both directions of victim exchange. He has qualified Man-in-th= e-middle as full fiasco - it does open many opportunities for him. He has m= entioned very good feature of this draft that there is no any interruption = for victim's traffic flow, no any excessive traffic to victim, that is very= rear benefit for hacker's tool. For all that doom and gloom the attacker would also need to see the traffic *from* the victim. Assuming the network has RA Guard in place it would be a bit harder. If the network does not have RA Guard our poor victim has much bigger problems already. > What to do about it? > 1. Potentially it is possible to do RPF-like check for Source LLA address= es. Upstream traffic from victim's SLLA would not be in ND cache - such tra= ffic could be discarded. It is better to block communication than permit in= truder to exploit vulnerability. > 2. Increase RetransTimer and ask receiver side (router) to check on sendi= ng side delay between ND record override (for the same SLLA). But how long = should be the timer? Host could wait a lo-o-o-ng time before it would reque= st 1st information from internet. It would decrease probability, but would = not completely eliminate attack vector. > > My proposition for this draft is disruptive: > I believe that ND is very complicated (some could say "fragile") - it is = better not to touch it. > Additionally I do not like to wait till all hosts would refresh to new dr= aft (to get new functionality). Well, only hosts which want to connect to the network faster need to implement this. So host OS developers have pretty good incentive here. Please keep in mind that the proposed behavior is not currently prohibited. We are not changing any MUST NOT to anything else. All we are doing is to making some recommendations more explicit. > I propose to change only router behavior: check Source LLA (MAC) for ever= y packet, if this SLLA is absent in ND cache - then request solicited NS-NA= immediately. It would probably resolve faster than traffic would return fr= om the internet. Have you checked the problem statement draft? https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#sec= tion-3.7 specificatlly? What you are proposing does make sense, however it would not help in case of multiple routers. Also I recall some people having strong opinions on performance implications. > Effectively I do proposed the same SLLA RPF that is needed to fix current= solution, but: > - without any modification to host OSes > - without any modification of standard (it is local recommendation for ro= uter, NS-NA is exactly the same from RFC 4681, NA is unicast - it is import= ant for security) > - without any risk to break ND fragile algorithm > - it could be optional, or even configurable on the router as "value add = feature" in competitive tender > Because it is just best practice recommendation - may be it make sense to= move it to "v6ops"? See https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03 > PS: Looking to the above - unsolicited NA should be really delayed by add= itional big timer (not by RetransTimer that is used for solicited NS/NA) an= d checked on receiver side - this modification of standard is really needed= to close Unsolicited NA vulnerability. > Somebody said on the call that it is already a feature of some OS (Androi= d?) - it is bad: it means that this OS is already vulnerable. I was saying that some routing platforms have this already implemented. Search for 'glean' here: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/= 15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html AFAIK there are implementations which are also prepopulating NC from DAD packets but I can not find you a reference right now. > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49 > To: 6man > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt > > Hello, > > The -01 version addresses comments received (thanks everyone who provided= feedback). Also, Section 3 (Avoiding Disruption) has been expanded and dis= cussed a corner case when two devices start using the same address almost a= t the same time (the second device configures an optimistic address after t= he rightful owner sent some packets but before the return traffic arrives). > Feedback on the updated section 3.3 > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is ver= y much appreciated. > > On Sun, Jul 26, 2020 at 10:14 AM wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > > > Title : Gratuitous Neighbor Discovery: Creating Neigh= bor Cache Entries on First-Hop Routers > > Author : Jen Linkova > > Filename : draft-ietf-6man-grand-01.txt > > Pages : 12 > > Date : 2020-07-25 > > > > Abstract: > > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the > > link-layer addresses of neighboring nodes as well as to discover and > > maintain reachability information. This document updates RFC4861 to > > allow routers to proactively create a Neighbor Cache entry when a ne= w > > IPv6 address is assigned to a node. It also updates RFC4861 and > > recommends nodes to send unsolicited Neighbor Advertisements upon > > assigning a new IPv6 address. The proposed change will minimize the > > delay and packet loss when a node initiate connections to off-link > > destination from a new IPv6 address. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-6man-grand-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 SY, Jen Linkova aka Furry From nobody Wed Jul 29 19:33:35 2020 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 2F03F3A0BC1 for ; Wed, 29 Jul 2020 19:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOQ49rPqz3_o for ; Wed, 29 Jul 2020 19:33:31 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92AB3A0B89 for ; Wed, 29 Jul 2020 19:33:29 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370] (unknown [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 19B9C280956; Thu, 30 Jul 2020 02:33:25 +0000 (UTC) To: Joseph Touch , Owen DeLong Cc: IPv6 Operations References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> <44481FC7-6E3F-4D5A-A5A9-A338C1836EA1@strayalpha.com> From: Fernando Gont Message-ID: <2ad804a2-e714-6256-3afa-4d4a92fd6d3c@si6networks.com> Date: Wed, 29 Jul 2020 23:25:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <44481FC7-6E3F-4D5A-A5A9-A338C1836EA1@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 02:33:34 -0000 Hello, Joe, On 29/7/20 17:16, Joseph Touch wrote: [...] >>> If we are merely documenting what happens to be implemented, we cease to be a standards body and become merely reporters. >> >> If we avoid any introspection or consideration of operational reality, the cease to be a relevant standards body and become an ivory tower.\ > > That’s why I said “merely”. Doing both and appreciating the balance is fine - the point is that “what is implemented/able TODAY” is NOT the only consideration. FWIW, I don't think we should limit ourselves to documenting the problem.Indeed, documenting the problem can certainly be a starting point to consider possible ways to mitigate it. For a long time, the status quo was assuming that EHs work. More recently, thanks to a number of efforts (Geoff's measurements, what we did in RFC7872, and others), there has been increased awareness about the packet drops. I would expect that a common understanding that there are underlying issues that lead to the packet drops (and it's not just folks playing with "firewall" rules at random) can serve as a starting point to consider what can be done to make things better, closing the gap (to the extent that is possible) between what the IETF says IPv6 is, and the operational reality of it. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 20:52:08 2020 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 4BC763A0C99 for ; Wed, 29 Jul 2020 20:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znWf1uSwhsaV for ; Wed, 29 Jul 2020 20:52:06 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F371B3A0C97 for ; Wed, 29 Jul 2020 20:52:05 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id q17so13044225pls.9 for ; Wed, 29 Jul 2020 20:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/1oB02xiDkc+ORghd6hKI6y1hJm1WYmgIZXtsV8EaNQ=; b=raXa3y6va8kvgTC16ommedhK2CYpkx9RmsoxbEbymB2W+quDCeLIzwYVbSbo8EU/A6 XIRXIvRI0nThU8DGABW1eVK7QEFJkruZqoTZ2UakrLVCkLxA4isI3AtFBTIELvrNMTCi /5OQf+1W4QL8uxeGynUjArt3ggQwIPaa06NSVVJbBdd1a7zry1V8d3LocvdXM5t4s72r Kd33E98J/kW+8qhZk/FAEuSA9juf30RUZbOGx8A9zubse7PcmE5GcpIxvyEPSG1WgOeI 7AXWEKxNOavsc7bYwcL4gyeWqpqpMrBrA7Cw0K58hB8SHajVEp5vsriqSTMRkqCKBrfv /2cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/1oB02xiDkc+ORghd6hKI6y1hJm1WYmgIZXtsV8EaNQ=; b=btE6csme/59d/SMeC/Wp//CGa24AzfWodaX0aw9N8/Ri01KE12RnOND8yPAgatlkAS eS684t2o6qHLXIWBVpuDBlXnITFZceNTKnbAkAbojdZrlf95gdnVQ2TICJAWZWFfyImX CG0HmCrCwX60mSNbfqMkL8k8cMnLHyRR/DJYH+KI7owZplqWOl9ixIAzpyffNbmoRh0m QSmfFpoffQHFUT0r5LwiTeSFYGzm63LkwP7Mlexo+t/OIQVsy+qPYHbEBJM+Jitn0Xrl pupALea0SIgpH4f+w9fHwqvgkDZGNxugnKWoB22xfy7mxFUtNMFg9Cr9PEOZga0szUjH rZ0Q== X-Gm-Message-State: AOAM530T1oAh4gk4Mzqvfw1beOhnBjbcHU0I0vyN+DVv/WIybdPBYgMm ObkPpy27odkfxznTPoVGJn4pl3WRQs8xEA== X-Google-Smtp-Source: ABdhPJxctDGPcs+WIfrRBIpVhKvsclZ3YUwWAz5j+mtiY3Dk+M+Zd/Jx8MWLPtVFI7is3MnRVkhaEg== X-Received: by 2002:a17:902:a418:: with SMTP id p24mr32101026plq.55.1596081124919; Wed, 29 Jul 2020 20:52:04 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id f89sm3798056pje.11.2020.07.29.20.52.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 20:52:04 -0700 (PDT) To: Fernando Gont , Joseph Touch , Owen DeLong Cc: IPv6 Operations References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> <44481FC7-6E3F-4D5A-A5A9-A338C1836EA1@strayalpha.com> <2ad804a2-e714-6256-3afa-4d4a92fd6d3c@si6networks.com> From: Brian E Carpenter Message-ID: <9c026e30-149b-172f-0953-456fb2d1e715@gmail.com> Date: Thu, 30 Jul 2020 15:52:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2ad804a2-e714-6256-3afa-4d4a92fd6d3c@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 03:52:07 -0000 And it may be another unpopular fact of life, but I believe that RFC8799 = is relevant. Certainly some basic rethinking about interoperability is ne= eded. Regards Brian On 30-Jul-20 14:25, Fernando Gont wrote: > Hello, Joe, >=20 > On 29/7/20 17:16, Joseph Touch wrote: > [...] >>>> If we are merely documenting what happens to be implemented, we ceas= e to be a standards body and become merely reporters. >>> >>> If we avoid any introspection or consideration of operational reality= , the cease to be a relevant standards body and become an ivory tower.\ >> >> That=E2=80=99s why I said =E2=80=9Cmerely=E2=80=9D. Doing both and app= reciating the balance is fine - the point is that =E2=80=9Cwhat is implem= ented/able TODAY=E2=80=9D is NOT the only consideration. >=20 > FWIW, I don't think we should limit ourselves to documenting the=20 > problem.Indeed, documenting the problem can certainly be a starting=20 > point to consider possible ways to mitigate it. >=20 > For a long time, the status quo was assuming that EHs work. More=20 > recently, thanks to a number of efforts (Geoff's measurements, what we = > did in RFC7872, and others), there has been increased awareness about=20 > the packet drops. >=20 > I would expect that a common understanding that there are underlying=20 > issues that lead to the packet drops (and it's not just folks playing=20 > with "firewall" rules at random) can serve as a starting point to=20 > consider what can be done to make things better, closing the gap (to th= e=20 > extent that is possible) between what the IETF says IPv6 is, and the=20 > operational reality of it. >=20 > Thanks, >=20 From nobody Wed Jul 29 23:08:52 2020 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 4A0D03A0E54 for ; Wed, 29 Jul 2020 23:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qat0bCtmv4W1 for ; Wed, 29 Jul 2020 23:08:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE353A0E51 for ; Wed, 29 Jul 2020 23:08:41 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370] (unknown [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2265928380A; Thu, 30 Jul 2020 06:08:33 +0000 (UTC) To: Brian E Carpenter , Joseph Touch , Owen DeLong Cc: IPv6 Operations References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> <44481FC7-6E3F-4D5A-A5A9-A338C1836EA1@strayalpha.com> <2ad804a2-e714-6256-3afa-4d4a92fd6d3c@si6networks.com> <9c026e30-149b-172f-0953-456fb2d1e715@gmail.com> From: Fernando Gont Message-ID: <41c9c9ec-e77c-977e-8b09-33fe844a44a4@si6networks.com> Date: Thu, 30 Jul 2020 01:59:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <9c026e30-149b-172f-0953-456fb2d1e715@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 06:08:51 -0000 On 30/7/20 00:52, Brian E Carpenter wrote: > And it may be another unpopular fact of life, but I believe that RFC8799 is relevant. Certainly some basic rethinking about interoperability is needed. Indeed, of all the possible outcomes, the worst one is bury one's head into sand. I'm not sure what would be the best part for this particular case (whether to embrace the idea of limited domains, and spell out what's expected to work where, to constrain the IPv6 spec a bit such that we can somewhat close the gap between what 6man specifies and the real world, or what else). Of the possible options, the RFC8799 seems to be among the most conservative: acknowledges operational reality, while it doesn't close the door. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 30 01:05:15 2020 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 5DFA63A0F85; Thu, 30 Jul 2020 01:05:13 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjiIUtcPSuGs; Thu, 30 Jul 2020 01:05:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 10F0C3A0F82; Thu, 30 Jul 2020 01:05:10 -0700 (PDT) Received: from lhreml745-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E604B58694AB4D726226; Thu, 30 Jul 2020 09:05:07 +0100 (IST) Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml745-chm.china.huawei.com (10.201.108.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Jul 2020 09:05:07 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Jul 2020 11:05:06 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Thu, 30 Jul 2020 11:05:06 +0300 From: Vasilenko Eduard To: Jen Linkova CC: 6man , "v6ops@ietf.org" Thread-Topic: I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AdZl2/KmEr6Lt/NERGGqFiMA7k1/CAAIPvAAABH5AHA= Date: Thu, 30 Jul 2020 08:05:06 +0000 Message-ID: <37e2a7110f6b423eba0303811913f533@huawei.com> References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.196.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 08:05:14 -0000 VGhlbiBpdCBpcyBub3QgbG9naWNhbCBmb3IgbWU6DQpNYW55IHBlb3BsZSB1bmRlcnN0YW5kIHRo YXQgIlVuc29saWNpdGVkIE5BIiBpcyBhIGJpZyBzZWN1cml0eSBob2xlIHBlciBzZSwNCkJ1dCBp bnN0ZWFkIG9mIGZpeGluZyBpdCAobWF5IGJlIGV2ZW4gZGVwcmVjYXRlIC0gc2hvdWxkIGJlIGlu dmVzdGlnYXRlZCkNCkFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBpcyBidWlsZGluZyBvbiB0b3Ag b2YgaXQuDQpJdCB3b3VsZCBhZGRpdGlvbmFsbHkgY2hhbGxlbmdlIHRoaXMgc2VjdXJpdHkgcHJv YmxlbSByZXNvbHV0aW9uIGluIHRoZSBmdXR1cmUhDQoNCkFnYWluOiAiVW5zb2xpY2l0ZWQgTkEi IHdpdGggT3ZlcnJpZGUgYml0IHNldCAtIGlzIGEgZGlzYXN0ZXIgbm93Lg0KSU1ITzogaXQgaXMg YmV0dGVyIHRvIHByb2hpYml0ICJVbnNvbGljaXRlZCBOQSIuIExldCdzIHdhaXQgdGltZXJzIGZv ciB0aGUgY2FzZSBvZiBNQUMgYWRkcmVzcyBjaGFuZ2Ugb24gbGVnaXRpbWF0ZSBob3N0Lg0KTWF5 IGJlIHdlIGNvdWxkIHRoaW5rIGFib3V0IG90aGVyIHNvbHV0aW9ucy4NCkJ1dCBpZiBhZGRpdGlv bmFsIGZ1bmN0aW9uYWxpdHkgd291bGQgYmUgYnVpbHQgb24gdG9wIG9mICJVbnNvbGljaXRlZCBO QSIgLSBsZXNzIG9wdGlvbnMgd291bGQgYmUgYXZhaWxhYmxlICgiZGVwcmVjYXRlIiB3b3VsZCBi ZSBub3QgYSBjaG9pY2UgYW55bW9yZSkuDQoNCklmIHNvbWV0aGluZyBpcyBpbGwgLSBpdCBzaG91 bGQgYmUgY3VyZWQgZmlyc3QgLSBib2R5YnVpbGRpbmcgbWFrZSBzZW5zZSBvbmx5IGFmdGVyIHRo aXMuDQoNCkplbiwgSSBoYXZlIG5vdCB1bmRlcnN0b29kIGJlbG93IHdoeSB5b3UgZGlkIG1lbnRp b24gUkEgR3VhcmQuIEludHJ1ZGVyIGRvZXMgbm90IG5lZWQgaXQuIEhlIGp1c3QgY2xhaW0gKGJ5 IFVuc29saWNpdGVkIE5BKSB0aGF0IGhpcyBNQUMgaXMgY29ubmVjdGVkIHRvIEdVQSBvZiB2aWN0 aW0uDQpJbnRydWRlciBjb3VsZCBjbGFpbSBpdCBldmVyeSA1IHNlY29uZHMgdG8ga2VlcCBjYWNo ZSBpbiBTVEFMRSBzdGF0ZSAoZm9yIHRoZSBjYXNlIG9mIHZlcnkgY2FyZWZ1bCB2ZW5kb3IgaW1w bGVtZW50YXRpb24gb2YgTkQpLg0KQXMgeW91IG1lbnRpb25lZCAtIG5vIGhlbHAgZnJvbSBNTEQg c25vb3Bpbmcgb24gc3dpdGNoZXMgLSBpdCB3b3VsZCBiZSBlbm91Z2ggdG8ganVzdCBsaXN0ZW4g dG8gREFELiBTd2l0Y2ggY291bGQgbm90IGhlbHAgaW4gcHJpbmNpcGxlLg0KVGhlIGZpcnN0IG1v ZGlmaWVkIEROUyByZXNwb25zZSB3b3VsZCBjb252ZXJ0IHRyYWZmaWMgZmxvdyB0byBiaS1kaXJl Y3Rpb25hbCBmb3IgSW50cnVkZXIuDQoNCkVkLw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEplbiBMaW5rb3ZhIFttYWlsdG86ZnVycnkxM0BnbWFpbC5jb21dIA0KU2VudDogMzAg 0LjRjtC70Y8gMjAyMCDQsy4gNTowNw0KVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbT4NCkNjOiA2bWFuIDxpcHY2QGlldGYub3JnPjsgdjZvcHNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBh ZGRpdGlvbmFsIHNlY3VyaXR5IGNvbmNlcm5zDQoNCk9uIFRodSwgSnVsIDMwLCAyMDIwIGF0IDU6 NTYgQU0gVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPiB3cm90 ZToNCj4gWW91IGRpZCBhc2sgYSBmZWVkYmFjayB5ZXN0ZXJkYXkgYWJvdXQgc2V2ZXJpdHkgb2Yg N3NlYyBzZWN1cml0eSBob2xlIHRoYXQgaGFzIHZlcnkgbG93IHByb2JhYmlsaXR5Lg0KPiBJIGhh dmUgaW50ZW50aW9uIGhlcmUgdG8gc2hvdyB0aGF0IHByb2JhYmlsaXR5IGlzIDEwMCUsIDdzZWMg Y291bGQgYmUgcHJvbG9uZ2VkIHRvIGZvcmV2ZXIsIGFuZCB0aGUgZmluYWwgcmVzdWx0IGlzIHRo ZSBmdWxsIGludGVyY2VwdGlvbiBvZiBpbm5vY2VudCBob3N0IHRyYWZmaWMgYnkgaW50cnVkZXIg KHN1Y2Nlc3NmdWwgIm1hbi1pbi10aGUtbWlkZGxlIikuDQo+DQo+IFByZS1yZXF1ZXN0IGZvciBz dWNjZXNzOg0KPiAtIG5vIG11bHRpY2FzdCBzbm9vcGluZyAoTUxEKSBhbmQgZmlsdGVyaW5nIG9u IGEgc3dpdGNoLCB0aGF0IGlzIA0KPiBwZXJmZWN0bHkgcG9zc2libGUNCj4gLSBJbnRydWRlciBz aG91bGQgYmUgYWxyZWFkeSBvbiB0aGUgc2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXIg DQo+IG90aGVyIGhvc3QgYnkgZXhwbG9pdGluZyBvZiBkaWZmZXJlbnQgdnVsbmVyYWJpbGl0eSkN Cj4gLSBpbnRydWRlciBzaG91bGQgc3VwcHJlc3MgREFEIG9uIEludHJ1ZGVyJ3MgY29udHJvbGxl ZCBob3N0IChpcyANCj4gV2luZG93cyBmaXJld2FsbCBjYXBhYmxlIHRvIGZpbHRlciBvdXQgREFE PykNCj4gLSBXZSBhc3N1bWUgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgZnV0dXJlIHdo ZW4gdGhpcyBkcmFmdCBpcyANCj4gdXNlZCBieSBtYWpvcml0eSBvZiBub2RlcyAodmljdGltIHNo b3VsZCB1c2UgaXQpDQo+DQo+IFByb2NlZHVyZToNCj4gSW50cnVkZXIncyBjb250cm9sbGVkIGhv c3QgZG9lcyBsaXN0ZW4gdG8gYWxsLXJvdXRlcnMgbXVsdGljYXN0IGFkZHJlc3MgKGZmMDI6OjIp Lg0KPiBBcyBzb29uIGFzIGl0IHdvdWxkIGVhdmVzZHJvcCB1bnNvbGljaXRlZCBOQSBmcm9tIHZp Y3RpbSBub2RlIChwcm9iYWJseSBhZnRlciBib290KSAtIEludHJ1ZGVyIHdvdWxkIGltbWVkaWF0 ZWx5IChhIGZldyBtaWxsaXNlY29uZHMpIGR1cGxpY2F0ZSBOQSBpbiByb3V0ZXIncyBkaXJlY3Rp b24sIGJ1dCB3aXRoIDIgY2hhbmdlczogKDEpIGhpcyBMTEEgKE1BQyk7ICgyKSBPdmVycmlkZSBi aXQgc2V0Lg0KPiBJbnRydWRlciBoYXMgdGltZSBvbmx5IHVwIHRvIHRoZSBwb2ludCB0aGF0IHJl c3BvbnNlIHRvIHZpY3RpbSdzIHRyYWZmaWMgd291bGQgYmUgcmV0dXJuZWQgZnJvbSB0aGUgSW50 ZXJuZXQgKGZyb20gdGVucyBvZiBtaWxsaXNlY29uZHMgdG8gbWFueSBzZWNvbmRzIGlmIHZpY3Rp bSB3b3VsZCBub3Qgc3RhcnQgc2VuZGluZyBpbW1lZGlhdGVseSksIC0gYnV0IGl0IGlzIGVub3Vn aCB0aW1lOiBsb2NhbCBjb21tdW5pY2F0aW9uIHNob3VsZCBiZSBmYXN0ZXIuDQo+IFRoZW9yZXRp Y2FsbHksIFJldHJhbnNUaW1lciBzaG91bGQgYmUgaW1wb3NlZCBvbiB1bnNvbGljaXRlZCBOQSAo c2VjdGlvbiA3LjIuNiksIGJ1dCBsb3cgY2hhbmNlcyB0aGF0IHRoaXMgdGltZXIgaXMgY2hlY2tl ZCBvbiByZWNlaXZpbmcgc2lkZSAocm91dGVyKSwgYmVjYXVzZSBSZXRyYW5zVGltZXIgaXMgc3Bl Y2lmaWVkIGZvciB0cmFuc21pc3Npb24gc2lkZS4NCj4gQWNjb3JkaW5nIFJGQyA0NjgxIHNlY3Rp b24gNy4yLjUgY2xhdXNlIElJOiBPIGJpdCBzZXQgc2hvdWxkIG5vdCBqdXN0IHJld3JpdGUgTkQg Y2FjaGUsIGJ1dCBhZGRpdGlvbmFsbHkgbWFyayBORCByZWNvcmQgYXMgUkVBQ0hBQkxFLiBBY2Nv cmRpbmcgdG8gc2VjdGlvbiA3LjIuNjogIiBUaGUgT3ZlcnJpZGUgZmxhZyAoZm9yIHVuc29saWNp dGVkIE5BKSBNQVkgYmUgc2V0IHRvIGVpdGhlciB6ZXJvIG9yIG9uZSIuIERlc3BpdGUgaXQgY29u dHJhZGljdHMgdG8gdGhlIGxvZ2ljIG9mIHRoZSB3aG9sZSBSRkMgNDY4MSAoTyBiaXQgc2hvdWxk IG5vdCBiZSBzZXQgaW4gdW5zb2xpY2l0ZWQgTkEgLSBpdCBpcyBtZW50aW9uZWQgaW4gYSBmZXcg cGxhY2VzIG9mIFJGQyA0NjgxKS4gQnV0IGJlY2F1c2Ugc2VjdGlvbiA3LjIuNSBhbmQgc2VjdGlv biA3LjIuNiBjbGVhcmx5IHBlcm1pdCB0byB1c2UgT3ZlcnJpZGUgZmxhZyAtIGhpZ2hlciBwcm9i YWJpbGl0eSB0aGF0IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24gd291bGQgbm90IGp1c3QgcmV3 cml0ZSBMTEEgb24gcm91dGVyLCBidXQgYWRkaXRpb25hbGx5IHB1dCBpdCBpbnRvIFJFQUNIQUJM RS4NCj4gSW50cnVkZXIgY291bGQgYmUgc3VyZSB0aGF0IGF0IGxlYXN0IFNUQUxFIHN0YXRlIHdv dWxkIGJlIGNyZWF0ZWQgYWNjb3JkaW5nIHRvIHNlY3Rpb24gNy4yLjUgY2xhdXNlIEksIC0gdGhp cyBORCByZWNvcmQgd291bGQgYmUgYWdhaW5zdCBoaXMgTExBIGFueXdheS4NCj4gQWZ0ZXIgcmVj ZWl2aW5nIHJldHVybiB0cmFmZmljIChpZiBpdCB3YXMgY3JlYXRlZCBhcyBTVEFMRSwgbm90IFJF QUNIQUJMRSkgLSByb3V0ZXIgd291bGQgYXNrIGludHJ1ZGVyIGFib3V0IHJlYWNoYWJpbGl0eSAo c29saWNpdGVkIE5TLU5BKSAtIGludHJ1ZGVyIHdvdWxkIGNvbmZpcm0gaGlzIExMQSAtIGl0IHdv dWxkIGZpbmFsbHkgcHV0IE5EIGNhY2hlIHJlY29yZCBpbnRvIFJFQUNIQUJMRS4NCg0KMSkgdGhl IDcgc2Vjb25kcyBjb3JuZXIgY2FzZSB3YXMgZm9yICdwcmV2ZW50aW5nIGFkZHJlc3MgY29sbGlz aW9uIGZvciBPcHRpbWlzdGljIERBRCcsIG5vdCBmb3IgYW55IGludGVudGlvbmFsIGF0dGFja3Mg Y2FzZS4gQmVjYXVzZToNCjIpIFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGNvdWxkIGJlIGRvbmUg dG9kYXksIG5vdywgYW55dGltZSB3L28gdGhlIGNoYW5nZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFm dC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29waW5nIHRoZW4gdGhlIGludHJ1ZGVyIHdvdWxkIHNl ZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2aWN0aW0sIHNvIGl0IHdvdWxkIGtub3cgdGhlIHZp Y3RpbSBhZGRyZXNzIGFueXdheSAgLSBubyByZWFzb24gZXZlbiB0byBqb2luIGZmMDI6OjIuIE5v dyBhbGwgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGRvIGlzIHRvIGtlZXAgc2VuZGluZyBOQSB3aXRo IFM9MSwgTz0xIC0gaG9waW5nIHRoYXQgd2hlbiB0aGUgZmlyc3QgcGFja2V0IG9mIHRoZSByZXR1 cm4gZmxvd3MgYXJyaXZlIGFuZCB0aGUgcm91dGVyIGNyZWF0ZXMgYW4gSU5DT01QTEVURSBlbnRy eSBhbmQgc2VuZHMgYW4gTlMsIHRoZSBhdHRhY2tlcidzIHBhY2tldCB3b3VsZCBjb21lIGJlZm9y ZSB0aGUgdmljdGltJ3MgTkEuIERvbmUsIHRoZSAgZW50cnkgaXMgY2hhbmdlZCB0byBSRUFDSEFC TEUsIGFsbCB0cmFmZmljIGdvZXMgdG8gdGhlIGF0dGFja2VyLg0KQWN0dWFsbHkgZXZlbiBzaW1w bGVyLiBUaGUgYXR0YWNrZXIgZG9lcyBub3QgbmVlZCB0byBkZWFsIHdpdGggdGltaW5nLg0KTGV0 J3Mgc2F5IHRoZSByb3V0ZXIgaGFzIGFuIE5DIGVudHJ5IGZvciB0aGUgdmljdGltIGFkZHJlc3Mg aW4gYW55IG90aGVyIHN0YXRlIHRoYW4gSU5DT01QTEVURS4gVGhlIGF0dGFja2VyIHNlbmRzIGFu IE5BIHdpdGggUz0xLCBPPTEsIFRhcmdldCBhZGRyZXNzID0gdGhlIHZpY3RpbSdzIElQdjYgYWRk cmVzcywgdGhlIFRMTEEgPSB0aGUgYXR0YWNrZXIgTUFDIGFkZHJlc3MuICBEb25lLiBUaGUgcm91 dGVyIHVwZGF0ZXMgdGhlIGNhY2hlIGVudHJ5IGFuZCBjaGFuZ2VzIGl0IHRvIFJFQUNIQUJMRSBz dGF0ZS4NCg0KVGhlcmUgaXMgbm90aGluZyBuZXcgaGVyZS4gV2UgaGF2ZSB0aGUgc2FtZSBpc3N1 ZSB3aXRoIEFSUCAtIHRoZSBhdHRhY2tlciBjYW4gb3ZlcnJpZGUgQVJQIGVudHJ5IG9uIHRoZSBy b3V0ZXIuDQoNCj4gVGhhdCdzIGl0OiB1cHN0cmVhbSB0cmFmZmljIG9mIHZpY3RpbSBob3N0IGlz IGdvaW5nIHRvIHJvdXRlciwgdHJhZmZpYyBiYWNrIGlzIGdvaW5nIHRocm91Z2ggSW50cnVkZXIu DQo+IEkgaGF2ZSBjb25zdWx0ZWQgd2l0aCBwZW5ldHJhdGlvbiB0ZXN0cyBwcm9mZXNzaW9uYWwg KHRoZXNlIGFyZSBwZW9wbGUgd2l0aCB0aGUgc2FtZSBxdWFsaWZpY2F0aW9uIGFzIGhhY2tlcnMg YnV0IHRoZXkgcGxheSBvbiBsZWdhbCBzaWRlKTogd2hhdCBoZSB3b3VsZCBiZSBkb2luZyBuZXh0 PyBIZSBzYWlkIHRoYXQgaGUgd291bGQgcmV0dXJuIHRyYWZmaWMgdG8gbGVnaXRpbWF0ZSBob3N0 IC0gdmljdGltIHNob3VsZCBub3Qgc2VlIHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLiBIZSB3b3Vs ZCBjb2xsZWN0IGNvb2tpZXMgYW5kIHNvbWUgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIEhl IHdvdWxkIGZpbmFsbHkgc2VlIEROUyByZXNwb25zZSwgY2hhbmdlIGl0IGFuZCByZWRpcmVjdCBl dmVyeXRoaW5nIHRvIGhpbXNlbGYgb24gdGhlIHBlcm1hbmVudCBiYXNpcyAtIGhlIGRvZXMgd2Fu dCB0byBzZWUgYm90aCBkaXJlY3Rpb25zIG9mIHZpY3RpbSBleGNoYW5nZS4gSGUgaGFzIHF1YWxp ZmllZCBNYW4taW4tdGhlLW1pZGRsZSBhcyBmdWxsIGZpYXNjbyAtIGl0IGRvZXMgb3BlbiBtYW55 IG9wcG9ydHVuaXRpZXMgZm9yIGhpbS4gSGUgaGFzIG1lbnRpb25lZCB2ZXJ5IGdvb2QgZmVhdHVy ZSBvZiB0aGlzIGRyYWZ0IHRoYXQgdGhlcmUgaXMgbm8gYW55IGludGVycnVwdGlvbiBmb3Igdmlj dGltJ3MgdHJhZmZpYyBmbG93LCBubyBhbnkgZXhjZXNzaXZlIHRyYWZmaWMgdG8gdmljdGltLCB0 aGF0IGlzIHZlcnkgcmVhciBiZW5lZml0IGZvciBoYWNrZXIncyB0b29sLg0KDQpGb3IgYWxsIHRo YXQgZG9vbSBhbmQgZ2xvb20gdGhlIGF0dGFja2VyIHdvdWxkIGFsc28gbmVlZCB0byBzZWUgdGhl IHRyYWZmaWMgKmZyb20qIHRoZSB2aWN0aW0uIEFzc3VtaW5nIHRoZSBuZXR3b3JrIGhhcyBSQSBH dWFyZCBpbiBwbGFjZSBpdCB3b3VsZCBiZSBhIGJpdCBoYXJkZXIuIElmIHRoZSBuZXR3b3JrIGRv ZXMgbm90IGhhdmUgUkEgR3VhcmQgb3VyIHBvb3IgdmljdGltIGhhcyBtdWNoIGJpZ2dlciBwcm9i bGVtcyBhbHJlYWR5Lg0KDQo+IFdoYXQgdG8gZG8gYWJvdXQgaXQ/DQo+IDEuIFBvdGVudGlhbGx5 IGl0IGlzIHBvc3NpYmxlIHRvIGRvIFJQRi1saWtlIGNoZWNrIGZvciBTb3VyY2UgTExBIGFkZHJl c3Nlcy4gVXBzdHJlYW0gdHJhZmZpYyBmcm9tIHZpY3RpbSdzIFNMTEEgd291bGQgbm90IGJlIGlu IE5EIGNhY2hlIC0gc3VjaCB0cmFmZmljIGNvdWxkIGJlIGRpc2NhcmRlZC4gSXQgaXMgYmV0dGVy IHRvIGJsb2NrIGNvbW11bmljYXRpb24gdGhhbiBwZXJtaXQgaW50cnVkZXIgdG8gZXhwbG9pdCB2 dWxuZXJhYmlsaXR5Lg0KDQo+IDIuIEluY3JlYXNlIFJldHJhbnNUaW1lciBhbmQgYXNrIHJlY2Vp dmVyIHNpZGUgKHJvdXRlcikgdG8gY2hlY2sgb24gc2VuZGluZyBzaWRlIGRlbGF5IGJldHdlZW4g TkQgcmVjb3JkIG92ZXJyaWRlIChmb3IgdGhlIHNhbWUgU0xMQSkuIEJ1dCBob3cgbG9uZyBzaG91 bGQgYmUgdGhlIHRpbWVyPyBIb3N0IGNvdWxkIHdhaXQgYSBsby1vLW8tbmcgdGltZSBiZWZvcmUg aXQgd291bGQgcmVxdWVzdCAxc3QgaW5mb3JtYXRpb24gZnJvbSBpbnRlcm5ldC4gSXQgd291bGQg ZGVjcmVhc2UgcHJvYmFiaWxpdHksIGJ1dCB3b3VsZCBub3QgY29tcGxldGVseSBlbGltaW5hdGUg YXR0YWNrIHZlY3Rvci4NCj4NCj4gTXkgcHJvcG9zaXRpb24gZm9yIHRoaXMgZHJhZnQgaXMgZGlz cnVwdGl2ZToNCj4gSSBiZWxpZXZlIHRoYXQgTkQgaXMgdmVyeSBjb21wbGljYXRlZCAoc29tZSBj b3VsZCBzYXkgImZyYWdpbGUiKSAtIGl0IGlzIGJldHRlciBub3QgdG8gdG91Y2ggaXQuDQo+IEFk ZGl0aW9uYWxseSBJIGRvIG5vdCBsaWtlIHRvIHdhaXQgdGlsbCBhbGwgaG9zdHMgd291bGQgcmVm cmVzaCB0byBuZXcgZHJhZnQgKHRvIGdldCBuZXcgZnVuY3Rpb25hbGl0eSkuDQoNCldlbGwsIG9u bHkgaG9zdHMgd2hpY2ggd2FudCB0byBjb25uZWN0IHRvIHRoZSBuZXR3b3JrIGZhc3RlciBuZWVk IHRvIGltcGxlbWVudCB0aGlzLiBTbyBob3N0IE9TIGRldmVsb3BlcnMgaGF2ZSBwcmV0dHkgZ29v ZCBpbmNlbnRpdmUgaGVyZS4NClBsZWFzZSBrZWVwIGluIG1pbmQgdGhhdCB0aGUgcHJvcG9zZWQg YmVoYXZpb3IgaXMgbm90IGN1cnJlbnRseSBwcm9oaWJpdGVkLiBXZSBhcmUgbm90IGNoYW5naW5n IGFueSBNVVNUIE5PVCB0byBhbnl0aGluZyBlbHNlLiBBbGwgd2UgYXJlIGRvaW5nIGlzIHRvIG1h a2luZyBzb21lIHJlY29tbWVuZGF0aW9ucyBtb3JlIGV4cGxpY2l0Lg0KDQo+IEkgcHJvcG9zZSB0 byBjaGFuZ2Ugb25seSByb3V0ZXIgYmVoYXZpb3I6IGNoZWNrIFNvdXJjZSBMTEEgKE1BQykgZm9y IGV2ZXJ5IHBhY2tldCwgaWYgdGhpcyBTTExBIGlzIGFic2VudCBpbiBORCBjYWNoZSAtIHRoZW4g cmVxdWVzdCBzb2xpY2l0ZWQgTlMtTkEgaW1tZWRpYXRlbHkuIEl0IHdvdWxkIHByb2JhYmx5IHJl c29sdmUgZmFzdGVyIHRoYW4gdHJhZmZpYyB3b3VsZCByZXR1cm4gZnJvbSB0aGUgaW50ZXJuZXQu DQoNCkhhdmUgeW91IGNoZWNrZWQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0Pw0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW5kLWNhY2hl LWluaXQtMDMjc2VjdGlvbi0zLjcNCnNwZWNpZmljYXRsbHk/DQpXaGF0IHlvdSBhcmUgcHJvcG9z aW5nIGRvZXMgbWFrZSBzZW5zZSwgaG93ZXZlciBpdCB3b3VsZCBub3QgaGVscCBpbiBjYXNlIG9m IG11bHRpcGxlIHJvdXRlcnMuIEFsc28gSSByZWNhbGwgc29tZSBwZW9wbGUgaGF2aW5nIHN0cm9u ZyBvcGluaW9ucyBvbiBwZXJmb3JtYW5jZSBpbXBsaWNhdGlvbnMuDQoNCj4gRWZmZWN0aXZlbHkg SSBkbyBwcm9wb3NlZCB0aGUgc2FtZSBTTExBIFJQRiB0aGF0IGlzIG5lZWRlZCB0byBmaXggY3Vy cmVudCBzb2x1dGlvbiwgYnV0Og0KPiAtIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbiB0byBob3N0 IE9TZXMNCj4gLSB3aXRob3V0IGFueSBtb2RpZmljYXRpb24gb2Ygc3RhbmRhcmQgKGl0IGlzIGxv Y2FsIHJlY29tbWVuZGF0aW9uIGZvciANCj4gcm91dGVyLCBOUy1OQSBpcyBleGFjdGx5IHRoZSBz YW1lIGZyb20gUkZDIDQ2ODEsIE5BIGlzIHVuaWNhc3QgLSBpdCBpcyANCj4gaW1wb3J0YW50IGZv ciBzZWN1cml0eSkNCj4gLSB3aXRob3V0IGFueSByaXNrIHRvIGJyZWFrIE5EIGZyYWdpbGUgYWxn b3JpdGhtDQo+IC0gaXQgY291bGQgYmUgb3B0aW9uYWwsIG9yIGV2ZW4gY29uZmlndXJhYmxlIG9u IHRoZSByb3V0ZXIgYXMgInZhbHVlIA0KPiBhZGQgZmVhdHVyZSIgaW4gY29tcGV0aXRpdmUgdGVu ZGVyIEJlY2F1c2UgaXQgaXMganVzdCBiZXN0IHByYWN0aWNlIHJlY29tbWVuZGF0aW9uIC0gbWF5 IGJlIGl0IG1ha2Ugc2Vuc2UgdG8gbW92ZSBpdCB0byAidjZvcHMiPw0KDQpTZWUgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW5kLWNhY2hlLWlu aXQtMDMNCg0KPiBQUzogTG9va2luZyB0byB0aGUgYWJvdmUgLSB1bnNvbGljaXRlZCBOQSBzaG91 bGQgYmUgcmVhbGx5IGRlbGF5ZWQgYnkgYWRkaXRpb25hbCBiaWcgdGltZXIgKG5vdCBieSBSZXRy YW5zVGltZXIgdGhhdCBpcyB1c2VkIGZvciBzb2xpY2l0ZWQgTlMvTkEpIGFuZCBjaGVja2VkIG9u IHJlY2VpdmVyIHNpZGUgLSB0aGlzIG1vZGlmaWNhdGlvbiBvZiBzdGFuZGFyZCBpcyByZWFsbHkg bmVlZGVkIHRvIGNsb3NlIFVuc29saWNpdGVkIE5BIHZ1bG5lcmFiaWxpdHkuDQo+IFNvbWVib2R5 IHNhaWQgb24gdGhlIGNhbGwgdGhhdCBpdCBpcyBhbHJlYWR5IGEgZmVhdHVyZSBvZiBzb21lIE9T IChBbmRyb2lkPykgLSBpdCBpcyBiYWQ6IGl0IG1lYW5zIHRoYXQgdGhpcyBPUyBpcyBhbHJlYWR5 IHZ1bG5lcmFibGUuDQoNCkkgd2FzIHNheWluZyB0aGF0IHNvbWUgcm91dGluZyBwbGF0Zm9ybXMg aGF2ZSB0aGlzIGFscmVhZHkgaW1wbGVtZW50ZWQuIFNlYXJjaCBmb3IgJ2dsZWFuJyBoZXJlOg0K aHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2X2Jh c2ljL2NvbmZpZ3VyYXRpb24vMTUtZS9pcDZiLTE1LWUtYm9vay9pcDYtbmQtY2FjaGUtbWdtdC5o dG1sDQoNCkFGQUlLIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggYXJlIGFsc28gcHJl cG9wdWxhdGluZyBOQyBmcm9tIERBRCBwYWNrZXRzIGJ1dCBJIGNhbiBub3QgZmluZCB5b3UgYSBy ZWZlcmVuY2UgcmlnaHQgbm93Lg0KDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKZW4gTGlua292YQ0KPiBTZW50OiAyNyDQuNGO0LvRjyAy MDIwINCzLiA3OjQ5DQo+IFRvOiA2bWFuIDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxLnR4dA0KPg0KPiBIZWxsbywNCj4N Cj4gVGhlIC0wMSB2ZXJzaW9uIGFkZHJlc3NlcyBjb21tZW50cyByZWNlaXZlZCAodGhhbmtzIGV2 ZXJ5b25lIHdobyBwcm92aWRlZCBmZWVkYmFjaykuIEFsc28sIFNlY3Rpb24gMyAoQXZvaWRpbmcg RGlzcnVwdGlvbikgaGFzIGJlZW4gZXhwYW5kZWQgYW5kIGRpc2N1c3NlZCBhIGNvcm5lciBjYXNl IHdoZW4gdHdvIGRldmljZXMgc3RhcnQgdXNpbmcgdGhlIHNhbWUgYWRkcmVzcyBhbG1vc3QgYXQg dGhlIHNhbWUgdGltZSAodGhlIHNlY29uZCBkZXZpY2UgY29uZmlndXJlcyBhbiBvcHRpbWlzdGlj IGFkZHJlc3MgYWZ0ZXIgdGhlIHJpZ2h0ZnVsIG93bmVyIHNlbnQgc29tZSBwYWNrZXRzIGJ1dCBi ZWZvcmUgdGhlIHJldHVybiB0cmFmZmljIGFycml2ZXMpLg0KPiBGZWVkYmFjayBvbiB0aGUgdXBk YXRlZCBzZWN0aW9uIDMuMw0KPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtNm1hbi1ncmFuZC0wMSNzZWN0aW9uLTMuMykgaXMgdmVyeSBtdWNoIGFwcHJlY2lhdGVkLg0K Pg0KPiBPbiBTdW4sIEp1bCAyNiwgMjAyMCBhdCAxMDoxNCBBTSA8aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+ IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2Yg dGhlIElFVEYuDQo+ID4NCj4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEdyYXR1aXRvdXMg TmVpZ2hib3IgRGlzY292ZXJ5OiBDcmVhdGluZyBOZWlnaGJvciBDYWNoZSBFbnRyaWVzIG9uIEZp cnN0LUhvcCBSb3V0ZXJzDQo+ID4gICAgICAgICBBdXRob3IgICAgICAgICAgOiBKZW4gTGlua292 YQ0KPiA+ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAx LnR4dA0KPiA+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTINCj4gPiAgICAgICAgIERhdGUg ICAgICAgICAgICA6IDIwMjAtMDctMjUNCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIE5laWdo Ym9yIERpc2NvdmVyeSAoUkZDNDg2MSkgaXMgdXNlZCBieSBJUHY2IG5vZGVzIHRvIGRldGVybWlu ZSB0aGUNCj4gPiAgICBsaW5rLWxheWVyIGFkZHJlc3NlcyBvZiBuZWlnaGJvcmluZyBub2RlcyBh cyB3ZWxsIGFzIHRvIGRpc2NvdmVyIGFuZA0KPiA+ICAgIG1haW50YWluIHJlYWNoYWJpbGl0eSBp bmZvcm1hdGlvbi4gIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0ODYxIHRvDQo+ID4gICAgYWxs b3cgcm91dGVycyB0byBwcm9hY3RpdmVseSBjcmVhdGUgYSBOZWlnaGJvciBDYWNoZSBlbnRyeSB3 aGVuIGEgbmV3DQo+ID4gICAgSVB2NiBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIGEgbm9kZS4gIEl0 IGFsc28gdXBkYXRlcyBSRkM0ODYxIGFuZA0KPiA+ICAgIHJlY29tbWVuZHMgbm9kZXMgdG8gc2Vu ZCB1bnNvbGljaXRlZCBOZWlnaGJvciBBZHZlcnRpc2VtZW50cyB1cG9uDQo+ID4gICAgYXNzaWdu aW5nIGEgbmV3IElQdjYgYWRkcmVzcy4gIFRoZSBwcm9wb3NlZCBjaGFuZ2Ugd2lsbCBtaW5pbWl6 ZSB0aGUNCj4gPiAgICBkZWxheSBhbmQgcGFja2V0IGxvc3Mgd2hlbiBhIG5vZGUgaW5pdGlhdGUg Y29ubmVjdGlvbnMgdG8gb2ZmLWxpbmsNCj4gPiAgICBkZXN0aW5hdGlvbiBmcm9tIGEgbmV3IElQ djYgYWRkcmVzcy4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi02bWFuLWdyYW5kLw0KPiA+DQo+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6 ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDENCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMQ0KPiA+DQo+ID4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDENCj4gPg0KPiA+ DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YgDQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4gSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+ IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4NCj4gPg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0 Zi5vcmcgQWRtaW5pc3RyYXRpdmUgDQo+ID4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+DQo+IC0tDQo+ IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2 IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3Ry YXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0NClNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg== From nobody Thu Jul 30 02:59:16 2020 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 EDBF23A1048; Thu, 30 Jul 2020 02:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dicJdF3UU7t; Thu, 30 Jul 2020 02:58:38 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFE73A0CD8; Thu, 30 Jul 2020 02:58:37 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id w2so127864qvh.12; Thu, 30 Jul 2020 02:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fJjNje5GO82lA++WY9ZA2Z7sZMLpZ2W4A+MPc0OiAhA=; b=s/gh7gDMVT8EAgfiyjjT1XY5J5+L8oYb+6mZwLWVMLOtUIFqITTCfCHCi3dJDsuVQD t4v2rX6Ew5EfmK17D/Mx6KGl7WmKSrROrC/Kxk4dFWrCjoYh1is7aIEbwTJmVEwPhvqz lmRTOSASyHca9Z523nw0DzyAu7isYoc80jaXlduysX1YdutwFdQ/KubpKGIhM+MSu83s ngnXukrO1dIP3oUTRuEwCqXVXwxU/Ap+z4xRP6JsRF0KlD/ud+TkD1OwCNLCnhti6D2e zTZuoRVfL+QrbLaPzrjSQl8yfEkwuhCCJu+dPVMKKXkhdhc9HAL/5Vj6jEXeZfByB6VB Kn8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fJjNje5GO82lA++WY9ZA2Z7sZMLpZ2W4A+MPc0OiAhA=; b=G7yFuAGfk1hsLQsb9qj3P7S3t4Nb1BwdJOR1dP+GszIr+NtHDs60a7YdLt2g0jn7eB anM9zrFtCmw0Z3P83BVGdDDdGEM2f3C8F6b8S36rdkPdmVPzaH7fiQez3D4r/6VaKxdI xtbsjTjpiztNbiljz9zhHusicI2nm2dSEENdMRns9eOZcmwTm6N3as7ZKVqRjRZe0h9y bTLfmWDImpoiIwOBh0Yg8uEqjUFeunKOHfZZlKhD2e7d6ui3xo1D/jmlwJhyjI8VrTco 4YdMzkhQA0AYAWVCC61ytjAXB4CwM9/aeQZuSoFOeOza8+CyKhlARTm+I9rU/B1S4IpP qRBw== X-Gm-Message-State: AOAM531MWmWOcvx6J6MERctWF/hqxA7DUrbEZ/trh3CXXrvW08Lth6Fh wMu0xMWQ6HNMoeSgsWY5QelFto6Eu2lz8LjHsJIcniCA X-Google-Smtp-Source: ABdhPJwAx7W02uKYwDnXUlktgyUpBqdQ36ZrI1rGZgXUX10dq3Xv3nFGL7CPc5QBSz19AuYuI8fFFOXzJK8z00TBqwI= X-Received: by 2002:a05:6214:849:: with SMTP id dg9mr2078537qvb.165.1596103116650; Thu, 30 Jul 2020 02:58:36 -0700 (PDT) MIME-Version: 1.0 References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> In-Reply-To: <37e2a7110f6b423eba0303811913f533@huawei.com> From: Jen Linkova Date: Thu, 30 Jul 2020 19:58:25 +1000 Message-ID: To: Vasilenko Eduard Cc: 6man , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 09:58:41 -0000 On Thu, Jul 30, 2020 at 6:05 PM Vasilenko Eduard wrote: > Then it is not logical for me: > Many people understand that "Unsolicited NA" is a big security hole per s= e, > But instead of fixing it (may be even deprecate - should be investigated) There are many attacks possible within the same L2 segment. It's not new. That's why you shall either block p2p with the LAN (if you do not trust endpoints in general) or - better - hosts shall use end2end encryption. > Additional functionality is building on top of it. Sorry, I'm not sure I understand why unsolicited NA is the problem here. The mechanism I described in my previous email is using *solicited* NA to override the neighbor cache on the router. > It would additionally challenge this security problem resolution in the f= uture! > > Again: "Unsolicited NA" with Override bit set - is a disaster now. As well as Solicited, right? ;) Shall we look at SEND again? ;) It would be great but I'm not aware of implementations being widely deployed. > IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for th= e case of MAC address change on legitimate host. > May be we could think about other solutions. > But if additional functionality would be built on top of "Unsolicited NA"= - less options would be available ("deprecate" would be not a choice anymo= re). > > If something is ill - it should be cured first - bodybuilding make sense = only after this. > > Jen, I have not understood below why you did mention RA Guard. Intruder d= oes not need it. He just claim (by Unsolicited NA) that his MAC is connecte= d to GUA of victim. Yes, to intercept traffic *to* the victim. How is it going to intercept packets sent by the victim? > Intruder could claim it every 5 seconds to keep cache in STALE state (for= the case of very careful vendor implementation of ND). > As you mentioned - no help from MLD snooping on switches - it would be en= ough to just listen to DAD. Switch could not help in principle. Strictly speaking, if the switching infrastructure implements MLD snooping, the attacker would need either to guess the lower 24 bits of the victim's address or to join 2^24 solicited node multicast address groups. > The first modified DNS response would convert traffic flow to bi-directio= nal for Intruder. That's why DNSSEC and DNS over TLS and HTTPS are good for security. > -----Original Message----- > From: Jen Linkova [mailto:furry13@gmail.com] > Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07 > To: Vasilenko Eduard > Cc: 6man ; v6ops@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security c= oncerns > > On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard wrote: > > You did ask a feedback yesterday about severity of 7sec security hole t= hat has very low probability. > > I have intention here to show that probability is 100%, 7sec could be p= rolonged to forever, and the final result is the full interception of innoc= ent host traffic by intruder (successful "man-in-the-middle"). > > > > Pre-request for success: > > - no multicast snooping (MLD) and filtering on a switch, that is > > perfectly possible > > - Intruder should be already on the same subnet (gained control over > > other host by exploiting of different vulnerability) > > - intruder should suppress DAD on Intruder's controlled host (is > > Windows firewall capable to filter out DAD?) > > - We assume that we are talking about the future when this draft is > > used by majority of nodes (victim should use it) > > > > Procedure: > > Intruder's controlled host does listen to all-routers multicast address= (ff02::2). > > As soon as it would eavesdrop unsolicited NA from victim node (probably= after boot) - Intruder would immediately (a few milliseconds) duplicate NA= in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override= bit set. > > Intruder has time only up to the point that response to victim's traffi= c would be returned from the Internet (from tens of milliseconds to many se= conds if victim would not start sending immediately), - but it is enough ti= me: local communication should be faster. > > Theoretically, RetransTimer should be imposed on unsolicited NA (sectio= n 7.2.6), but low chances that this timer is checked on receiving side (rou= ter), because RetransTimer is specified for transmission side. > > According RFC 4681 section 7.2.5 clause II: O bit set should not just r= ewrite ND cache, but additionally mark ND record as REACHABLE. According to= section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to eith= er zero or one". Despite it contradicts to the logic of the whole RFC 4681 = (O bit should not be set in unsolicited NA - it is mentioned in a few place= s of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly permit = to use Override flag - higher probability that particular implementation wo= uld not just rewrite LLA on router, but additionally put it into REACHABLE. > > Intruder could be sure that at least STALE state would be created accor= ding to section 7.2.5 clause I, - this ND record would be against his LLA a= nyway. > > After receiving return traffic (if it was created as STALE, not REACHAB= LE) - router would ask intruder about reachability (solicited NS-NA) - intr= uder would confirm his LLA - it would finally put ND cache record into REAC= HABLE. > > 1) the 7 seconds corner case was for 'preventing address collision for Op= timistic DAD', not for any intentional attacks case. Because: > 2) What you are describing could be done today, now, anytime w/o the chan= ges described in the draft. If there is no MLD snooping then the intruder w= ould see the DAD packet from the victim, so it would know the victim addres= s anyway - no reason even to join ff02::2. Now all the attacker needs to d= o is to keep sending NA with S=3D1, O=3D1 - hoping that when the first pack= et of the return flows arrive and the router creates an INCOMPLETE entry an= d sends an NS, the attacker's packet would come before the victim's NA. Don= e, the entry is changed to REACHABLE, all traffic goes to the attacker. > Actually even simpler. The attacker does not need to deal with timing. > Let's say the router has an NC entry for the victim address in any other = state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Target a= ddress =3D the victim's IPv6 address, the TLLA =3D the attacker MAC address= . Done. The router updates the cache entry and changes it to REACHABLE sta= te. > > There is nothing new here. We have the same issue with ARP - the attacker= can override ARP entry on the router. > > > That's it: upstream traffic of victim host is going to router, traffic = back is going through Intruder. > > I have consulted with penetration tests professional (these are people = with the same qualification as hackers but they play on legal side): what h= e would be doing next? He said that he would return traffic to legitimate h= ost - victim should not see performance degradation. He would collect cooki= es and some other valuable information. He would finally see DNS response, = change it and redirect everything to himself on the permanent basis - he do= es want to see both directions of victim exchange. He has qualified Man-in-= the-middle as full fiasco - it does open many opportunities for him. He has= mentioned very good feature of this draft that there is no any interruptio= n for victim's traffic flow, no any excessive traffic to victim, that is ve= ry rear benefit for hacker's tool. > > For all that doom and gloom the attacker would also need to see the traff= ic *from* the victim. Assuming the network has RA Guard in place it would b= e a bit harder. If the network does not have RA Guard our poor victim has m= uch bigger problems already. > > > What to do about it? > > 1. Potentially it is possible to do RPF-like check for Source LLA addre= sses. Upstream traffic from victim's SLLA would not be in ND cache - such t= raffic could be discarded. It is better to block communication than permit = intruder to exploit vulnerability. > > > 2. Increase RetransTimer and ask receiver side (router) to check on sen= ding side delay between ND record override (for the same SLLA). But how lon= g should be the timer? Host could wait a lo-o-o-ng time before it would req= uest 1st information from internet. It would decrease probability, but woul= d not completely eliminate attack vector. > > > > My proposition for this draft is disruptive: > > I believe that ND is very complicated (some could say "fragile") - it i= s better not to touch it. > > Additionally I do not like to wait till all hosts would refresh to new = draft (to get new functionality). > > Well, only hosts which want to connect to the network faster need to impl= ement this. So host OS developers have pretty good incentive here. > Please keep in mind that the proposed behavior is not currently prohibite= d. We are not changing any MUST NOT to anything else. All we are doing is t= o making some recommendations more explicit. > > > I propose to change only router behavior: check Source LLA (MAC) for ev= ery packet, if this SLLA is absent in ND cache - then request solicited NS-= NA immediately. It would probably resolve faster than traffic would return = from the internet. > > Have you checked the problem statement draft? > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#s= ection-3.7 > specificatlly? > What you are proposing does make sense, however it would not help in case= of multiple routers. Also I recall some people having strong opinions on p= erformance implications. > > > Effectively I do proposed the same SLLA RPF that is needed to fix curre= nt solution, but: > > - without any modification to host OSes > > - without any modification of standard (it is local recommendation for > > router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is > > important for security) > > - without any risk to break ND fragile algorithm > > - it could be optional, or even configurable on the router as "value > > add feature" in competitive tender Because it is just best practice rec= ommendation - may be it make sense to move it to "v6ops"? > > See https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-= 03 > > > PS: Looking to the above - unsolicited NA should be really delayed by a= dditional big timer (not by RetransTimer that is used for solicited NS/NA) = and checked on receiver side - this modification of standard is really need= ed to close Unsolicited NA vulnerability. > > Somebody said on the call that it is already a feature of some OS (Andr= oid?) - it is bad: it means that this OS is already vulnerable. > > I was saying that some routing platforms have this already implemented. S= earch for 'glean' here: > https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuratio= n/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html > > AFAIK there are implementations which are also prepopulating NC from DAD = packets but I can not find you a reference right now. > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49 > > To: 6man > > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt > > > > Hello, > > > > The -01 version addresses comments received (thanks everyone who provid= ed feedback). Also, Section 3 (Avoiding Disruption) has been expanded and d= iscussed a corner case when two devices start using the same address almost= at the same time (the second device configures an optimistic address after= the rightful owner sent some packets but before the return traffic arrives= ). > > Feedback on the updated section 3.3 > > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is v= ery much appreciated. > > > > On Sun, Jul 26, 2020 at 10:14 AM wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > > > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > > > > > Title : Gratuitous Neighbor Discovery: Creating Nei= ghbor Cache Entries on First-Hop Routers > > > Author : Jen Linkova > > > Filename : draft-ietf-6man-grand-01.txt > > > Pages : 12 > > > Date : 2020-07-25 > > > > > > Abstract: > > > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine th= e > > > link-layer addresses of neighboring nodes as well as to discover a= nd > > > maintain reachability information. This document updates RFC4861 = to > > > allow routers to proactively create a Neighbor Cache entry when a = new > > > IPv6 address is assigned to a node. It also updates RFC4861 and > > > recommends nodes to send unsolicited Neighbor Advertisements upon > > > assigning a new IPv6 address. The proposed change will minimize t= he > > > delay and packet loss when a node initiate connections to off-link > > > destination from a new IPv6 address. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-6man-grand-01 > > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at tools= .ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -- > SY, Jen Linkova aka Furry --=20 SY, Jen Linkova aka Furry From nobody Thu Jul 30 03:36:27 2020 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 2E65E3A1063 for ; Thu, 30 Jul 2020 03:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrBMaZRdQEMc for ; Thu, 30 Jul 2020 03:36:20 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD31D3A0CF3 for ; Thu, 30 Jul 2020 03:36:20 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id g19so15622691ioh.8 for ; Thu, 30 Jul 2020 03:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZMndiK5S8kDkmi0xI/bMtsFEEg6Vjs0NQ/b+s2evWx0=; b=aAHTaxCTLLc9f1tIQF8OtJ55fgleUMYSr5FUeGdVL/vL3UBQu+LzczYs1LNSTh+X2E dPoSoVNjgJiMhZ1+Hei7u5FfEXD2w89teMslfa+muiT/w+/9S3SAYpyj+XQBUSiayk3D ySQrlQrvNp1Q4Q54+PlHLNuT5ds1p8NOubcHP97Q9u+QdtfKiCRWztOGZf+9DZQTvtqU aYzcN/+mAaKIMTl4fJSO1cYSDFKtxDn50/JaE9OoYDV8NSmOgpts6HIrbl1q6kE4b4Jx XVAo5ULtSTHv5q+PaXG554LzymmGcPllOxnNN13rzlNGfn716h5TLxMcYKbPrrDxBSoX u0Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZMndiK5S8kDkmi0xI/bMtsFEEg6Vjs0NQ/b+s2evWx0=; b=JZzNdW8+VxXxzn9+KqRJISoQrkXCwDiJlKlRS6itKFvPMcKJxariZZow/QaAry2WX2 yGOKoa1bNGOpu2eFE8gGnrVGwBBUGOGNXzpg1SpDvUFrBvBrMQty9AwYtnJFnsZtJI/U 5tpisopyCGdLvnmY9bLULw94JbzdhhULDkx33FtVFEKxddzQvxP2T+J+5VbuA3pemwHG 3odM4lSNFsMGXyuwUZwq5wEohibd7YuZkOXW0glz+u4pHyTVtTVBrn4NbXFWRVmphF7D yp/SFMqJJYLGmMeeoAMLwgYk9Tz9WTKTTS2votGfpLKlBUEO3QGin4gs4yTwD8iVHBLu J0CQ== X-Gm-Message-State: AOAM532v/hJ5LwqtpQmuGjQLD5t12vh92v3bXPMneNBJavs7dzglInhm 1eA5GPCrOtDQgFWtsJ5ZNBMN6FFPmeo0vRcqCeV1Vg== X-Google-Smtp-Source: ABdhPJw2JGKzztwHF3oGv7Ma5+d2dk1OrdtXQyRz48ojhvvwojjcMsTGofl+Qj9vbcG0/gPKB9p7UwECdy9oFLpAFjc= X-Received: by 2002:a5d:80cb:: with SMTP id h11mr27498545ior.189.1596105379602; Thu, 30 Jul 2020 03:36:19 -0700 (PDT) MIME-Version: 1.0 References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> In-Reply-To: <37e2a7110f6b423eba0303811913f533@huawei.com> From: Lorenzo Colitti Date: Thu, 30 Jul 2020 19:36:07 +0900 Message-ID: To: Vasilenko Eduard Cc: Jen Linkova , "v6ops@ietf.org" , 6man Content-Type: multipart/alternative; boundary="0000000000002d3c0b05aba63e7c" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 10:36:25 -0000 --0000000000002d3c0b05aba63e7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the fact is that ND is inherently insecure from on-link attacks. If security is desired, then it needs to be provided in other ways, such as via SEND or SAVI. But it's also not particularly desirable to provide security at this layer. Traffic snooping is not very useful (not zero utility, but difficult to use well) when all traffic is encrypted, and on-link DoS attacks just aren't very useful these days given that many devices have a variety of connectivity options. On Thu, Jul 30, 2020 at 5:05 PM Vasilenko Eduard < vasilenko.eduard@huawei.com> wrote: > Then it is not logical for me: > Many people understand that "Unsolicited NA" is a big security hole per s= e, > But instead of fixing it (may be even deprecate - should be investigated) > Additional functionality is building on top of it. > It would additionally challenge this security problem resolution in the > future! > > Again: "Unsolicited NA" with Override bit set - is a disaster now. > IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for th= e > case of MAC address change on legitimate host. > May be we could think about other solutions. > But if additional functionality would be built on top of "Unsolicited NA" > - less options would be available ("deprecate" would be not a choice > anymore). > > If something is ill - it should be cured first - bodybuilding make sense > only after this. > > Jen, I have not understood below why you did mention RA Guard. Intruder > does not need it. He just claim (by Unsolicited NA) that his MAC is > connected to GUA of victim. > Intruder could claim it every 5 seconds to keep cache in STALE state (for > the case of very careful vendor implementation of ND). > As you mentioned - no help from MLD snooping on switches - it would be > enough to just listen to DAD. Switch could not help in principle. > The first modified DNS response would convert traffic flow to > bi-directional for Intruder. > > Ed/ > -----Original Message----- > From: Jen Linkova [mailto:furry13@gmail.com] > Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07 > To: Vasilenko Eduard > Cc: 6man ; v6ops@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security > concerns > > On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard < > vasilenko.eduard@huawei.com> wrote: > > You did ask a feedback yesterday about severity of 7sec security hole > that has very low probability. > > I have intention here to show that probability is 100%, 7sec could be > prolonged to forever, and the final result is the full interception of > innocent host traffic by intruder (successful "man-in-the-middle"). > > > > Pre-request for success: > > - no multicast snooping (MLD) and filtering on a switch, that is > > perfectly possible > > - Intruder should be already on the same subnet (gained control over > > other host by exploiting of different vulnerability) > > - intruder should suppress DAD on Intruder's controlled host (is > > Windows firewall capable to filter out DAD?) > > - We assume that we are talking about the future when this draft is > > used by majority of nodes (victim should use it) > > > > Procedure: > > Intruder's controlled host does listen to all-routers multicast address > (ff02::2). > > As soon as it would eavesdrop unsolicited NA from victim node (probably > after boot) - Intruder would immediately (a few milliseconds) duplicate N= A > in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Overrid= e > bit set. > > Intruder has time only up to the point that response to victim's traffi= c > would be returned from the Internet (from tens of milliseconds to many > seconds if victim would not start sending immediately), - but it is enoug= h > time: local communication should be faster. > > Theoretically, RetransTimer should be imposed on unsolicited NA (sectio= n > 7.2.6), but low chances that this timer is checked on receiving side > (router), because RetransTimer is specified for transmission side. > > According RFC 4681 section 7.2.5 clause II: O bit set should not just > rewrite ND cache, but additionally mark ND record as REACHABLE. According > to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to > either zero or one". Despite it contradicts to the logic of the whole RFC > 4681 (O bit should not be set in unsolicited NA - it is mentioned in a fe= w > places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly > permit to use Override flag - higher probability that particular > implementation would not just rewrite LLA on router, but additionally put > it into REACHABLE. > > Intruder could be sure that at least STALE state would be created > according to section 7.2.5 clause I, - this ND record would be against hi= s > LLA anyway. > > After receiving return traffic (if it was created as STALE, not > REACHABLE) - router would ask intruder about reachability (solicited NS-N= A) > - intruder would confirm his LLA - it would finally put ND cache record > into REACHABLE. > > 1) the 7 seconds corner case was for 'preventing address collision for > Optimistic DAD', not for any intentional attacks case. Because: > 2) What you are describing could be done today, now, anytime w/o the > changes described in the draft. If there is no MLD snooping then the > intruder would see the DAD packet from the victim, so it would know the > victim address anyway - no reason even to join ff02::2. Now all the > attacker needs to do is to keep sending NA with S=3D1, O=3D1 - hoping tha= t when > the first packet of the return flows arrive and the router creates an > INCOMPLETE entry and sends an NS, the attacker's packet would come before > the victim's NA. Done, the entry is changed to REACHABLE, all traffic go= es > to the attacker. > Actually even simpler. The attacker does not need to deal with timing. > Let's say the router has an NC entry for the victim address in any other > state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Target > address =3D the victim's IPv6 address, the TLLA =3D the attacker MAC addr= ess. > Done. The router updates the cache entry and changes it to REACHABLE stat= e. > > There is nothing new here. We have the same issue with ARP - the attacker > can override ARP entry on the router. > > > That's it: upstream traffic of victim host is going to router, traffic > back is going through Intruder. > > I have consulted with penetration tests professional (these are people > with the same qualification as hackers but they play on legal side): what > he would be doing next? He said that he would return traffic to legitimat= e > host - victim should not see performance degradation. He would collect > cookies and some other valuable information. He would finally see DNS > response, change it and redirect everything to himself on the permanent > basis - he does want to see both directions of victim exchange. He has > qualified Man-in-the-middle as full fiasco - it does open many > opportunities for him. He has mentioned very good feature of this draft > that there is no any interruption for victim's traffic flow, no any > excessive traffic to victim, that is very rear benefit for hacker's tool. > > For all that doom and gloom the attacker would also need to see the > traffic *from* the victim. Assuming the network has RA Guard in place it > would be a bit harder. If the network does not have RA Guard our poor > victim has much bigger problems already. > > > What to do about it? > > 1. Potentially it is possible to do RPF-like check for Source LLA > addresses. Upstream traffic from victim's SLLA would not be in ND cache - > such traffic could be discarded. It is better to block communication than > permit intruder to exploit vulnerability. > > > 2. Increase RetransTimer and ask receiver side (router) to check on > sending side delay between ND record override (for the same SLLA). But ho= w > long should be the timer? Host could wait a lo-o-o-ng time before it woul= d > request 1st information from internet. It would decrease probability, but > would not completely eliminate attack vector. > > > > My proposition for this draft is disruptive: > > I believe that ND is very complicated (some could say "fragile") - it i= s > better not to touch it. > > Additionally I do not like to wait till all hosts would refresh to new > draft (to get new functionality). > > Well, only hosts which want to connect to the network faster need to > implement this. So host OS developers have pretty good incentive here. > Please keep in mind that the proposed behavior is not currently > prohibited. We are not changing any MUST NOT to anything else. All we are > doing is to making some recommendations more explicit. > > > I propose to change only router behavior: check Source LLA (MAC) for > every packet, if this SLLA is absent in ND cache - then request solicited > NS-NA immediately. It would probably resolve faster than traffic would > return from the internet. > > Have you checked the problem statement draft? > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#s= ection-3.7 > specificatlly? > What you are proposing does make sense, however it would not help in case > of multiple routers. Also I recall some people having strong opinions on > performance implications. > > > Effectively I do proposed the same SLLA RPF that is needed to fix > current solution, but: > > - without any modification to host OSes > > - without any modification of standard (it is local recommendation for > > router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is > > important for security) > > - without any risk to break ND fragile algorithm > > - it could be optional, or even configurable on the router as "value > > add feature" in competitive tender Because it is just best practice > recommendation - may be it make sense to move it to "v6ops"? > > See > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03 > > > PS: Looking to the above - unsolicited NA should be really delayed by > additional big timer (not by RetransTimer that is used for solicited NS/N= A) > and checked on receiver side - this modification of standard is really > needed to close Unsolicited NA vulnerability. > > Somebody said on the call that it is already a feature of some OS > (Android?) - it is bad: it means that this OS is already vulnerable. > > I was saying that some routing platforms have this already implemented. > Search for 'glean' here: > > https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuratio= n/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html > > AFAIK there are implementations which are also prepopulating NC from DAD > packets but I can not find you a reference right now. > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49 > > To: 6man > > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt > > > > Hello, > > > > The -01 version addresses comments received (thanks everyone who > provided feedback). Also, Section 3 (Avoiding Disruption) has been expand= ed > and discussed a corner case when two devices start using the same address > almost at the same time (the second device configures an optimistic addre= ss > after the rightful owner sent some packets but before the return traffic > arrives). > > Feedback on the updated section 3.3 > > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is > very much appreciated. > > > > On Sun, Jul 26, 2020 at 10:14 AM wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > > > > > Title : Gratuitous Neighbor Discovery: Creating > Neighbor Cache Entries on First-Hop Routers > > > Author : Jen Linkova > > > Filename : draft-ietf-6man-grand-01.txt > > > Pages : 12 > > > Date : 2020-07-25 > > > > > > Abstract: > > > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine th= e > > > link-layer addresses of neighboring nodes as well as to discover a= nd > > > maintain reachability information. This document updates RFC4861 = to > > > allow routers to proactively create a Neighbor Cache entry when a > new > > > IPv6 address is assigned to a node. It also updates RFC4861 and > > > recommends nodes to send unsolicited Neighbor Advertisements upon > > > assigning a new IPv6 address. The proposed change will minimize t= he > > > delay and packet loss when a node initiate connections to off-link > > > destination from a new IPv6 address. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-6man-grand-01 > > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -- > SY, Jen Linkova aka Furry > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000002d3c0b05aba63e7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the fact is that ND is inherently insecure fr= om on-link attacks. If security is desired, then it needs to be provided in= other ways, such as via SEND or SAVI. But it's also not particularly d= esirable to provide security at this layer. Traffic snooping is not very us= eful (not zero utility, but difficult to use well) when all traffic is encr= ypted, and on-link DoS attacks just aren't very useful these days given= that many devices have a variety of connectivity options.

On Thu, Jul 30, 2= 020 at 5:05 PM Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Then it is not logical for me:
Many people understand that "Unsolicited NA" is a big security ho= le per se,
But instead of fixing it (may be even deprecate - should be investigated) Additional functionality is building on top of it.
It would additionally challenge this security problem resolution in the fut= ure!

Again: "Unsolicited NA" with Override bit set - is a disaster now= .
IMHO: it is better to prohibit "Unsolicited NA". Let's wait t= imers for the case of MAC address change on legitimate host.
May be we could think about other solutions.
But if additional functionality would be built on top of "Unsolicited = NA" - less options would be available ("deprecate" would be = not a choice anymore).

If something is ill - it should be cured first - bodybuilding make sense on= ly after this.

Jen, I have not understood below why you did mention RA Guard. Intruder doe= s not need it. He just claim (by Unsolicited NA) that his MAC is connected = to GUA of victim.
Intruder could claim it every 5 seconds to keep cache in STALE state (for t= he case of very careful vendor implementation of ND).
As you mentioned - no help from MLD snooping on switches - it would be enou= gh to just listen to DAD. Switch could not help in principle.
The first modified DNS response would convert traffic flow to bi-directiona= l for Intruder.

Ed/
-----Original Message-----
From: Jen Linkova [mailto:furry13@gmail.com]
Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: 6man <ipv6@ietf.o= rg>; v6ops@ietf.= org
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security con= cerns

On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <vasilenko.eduard@huawei.com&= gt; wrote:
> You did ask a feedback yesterday about severity of 7sec security hole = that has very low probability.
> I have intention here to show that probability is 100%, 7sec could be = prolonged to forever, and the final result is the full interception of inno= cent host traffic by intruder (successful "man-in-the-middle"). >
> Pre-request for success:
> - no multicast snooping (MLD) and filtering on a switch, that is
> perfectly possible
> - Intruder should be already on the same subnet (gained control over <= br> > other host by exploiting of different vulnerability)
> - intruder should suppress DAD on Intruder's controlled host (is <= br> > Windows firewall capable to filter out DAD?)
> - We assume that we are talking about the future when this draft is > used by majority of nodes (victim should use it)
>
> Procedure:
> Intruder's controlled host does listen to all-routers multicast ad= dress (ff02::2).
> As soon as it would eavesdrop unsolicited NA from victim node (probabl= y after boot) - Intruder would immediately (a few milliseconds) duplicate N= A in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Ove= rride bit set.
> Intruder has time only up to the point that response to victim's t= raffic would be returned from the Internet (from tens of milliseconds to ma= ny seconds if victim would not start sending immediately), - but it is enou= gh time: local communication should be faster.
> Theoretically, RetransTimer should be imposed on unsolicited NA (secti= on 7.2.6), but low chances that this timer is checked on receiving side (ro= uter), because RetransTimer is specified for transmission side.
> According RFC 4681 section 7.2.5 clause II: O bit set should not just = rewrite ND cache, but additionally mark ND record as REACHABLE. According t= o section 7.2.6: " The Override flag (for unsolicited NA) MAY be set t= o either zero or one". Despite it contradicts to the logic of the whol= e RFC 4681 (O bit should not be set in unsolicited NA - it is mentioned in = a few places of RFC 4681). But because section 7.2.5 and section 7.2.6 clea= rly permit to use Override flag - higher probability that particular implem= entation would not just rewrite LLA on router, but additionally put it into= REACHABLE.
> Intruder could be sure that at least STALE state would be created acco= rding to section 7.2.5 clause I, - this ND record would be against his LLA = anyway.
> After receiving return traffic (if it was created as STALE, not REACHA= BLE) - router would ask intruder about reachability (solicited NS-NA) - int= ruder would confirm his LLA - it would finally put ND cache record into REA= CHABLE.

1) the 7 seconds corner case was for 'preventing address collision for = Optimistic DAD', not for any intentional attacks case. Because:
2) What you are describing could be done today, now, anytime w/o the change= s described in the draft. If there is no MLD snooping then the intruder wou= ld see the DAD packet from the victim, so it would know the victim address = anyway=C2=A0 - no reason even to join ff02::2. Now all the attacker needs t= o do is to keep sending NA with S=3D1, O=3D1 - hoping that when the first p= acket of the return flows arrive and the router creates an INCOMPLETE entry= and sends an NS, the attacker's packet would come before the victim= 9;s NA. Done, the=C2=A0 entry is changed to REACHABLE, all traffic goes to = the attacker.
Actually even simpler. The attacker does not need to deal with timing.
Let's say the router has an NC entry for the victim address in any othe= r state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Target= address =3D the victim's IPv6 address, the TLLA =3D the attacker MAC a= ddress.=C2=A0 Done. The router updates the cache entry and changes it to RE= ACHABLE state.

There is nothing new here. We have the same issue with ARP - the attacker c= an override ARP entry on the router.

> That's it: upstream traffic of victim host is going to router, tra= ffic back is going through Intruder.
> I have consulted with penetration tests professional (these are people= with the same qualification as hackers but they play on legal side): what = he would be doing next? He said that he would return traffic to legitimate = host - victim should not see performance degradation. He would collect cook= ies and some other valuable information. He would finally see DNS response,= change it and redirect everything to himself on the permanent basis - he d= oes want to see both directions of victim exchange. He has qualified Man-in= -the-middle as full fiasco - it does open many opportunities for him. He ha= s mentioned very good feature of this draft that there is no any interrupti= on for victim's traffic flow, no any excessive traffic to victim, that = is very rear benefit for hacker's tool.

For all that doom and gloom the attacker would also need to see the traffic= *from* the victim. Assuming the network has RA Guard in place it would be = a bit harder. If the network does not have RA Guard our poor victim has muc= h bigger problems already.

> What to do about it?
> 1. Potentially it is possible to do RPF-like check for Source LLA addr= esses. Upstream traffic from victim's SLLA would not be in ND cache - s= uch traffic could be discarded. It is better to block communication than pe= rmit intruder to exploit vulnerability.

> 2. Increase RetransTimer and ask receiver side (router) to check on se= nding side delay between ND record override (for the same SLLA). But how lo= ng should be the timer? Host could wait a lo-o-o-ng time before it would re= quest 1st information from internet. It would decrease probability, but wou= ld not completely eliminate attack vector.
>
> My proposition for this draft is disruptive:
> I believe that ND is very complicated (some could say "fragile&qu= ot;) - it is better not to touch it.
> Additionally I do not like to wait till all hosts would refresh to new= draft (to get new functionality).

Well, only hosts which want to connect to the network faster need to implem= ent this. So host OS developers have pretty good incentive here.
Please keep in mind that the proposed behavior is not currently prohibited.= We are not changing any MUST NOT to anything else. All we are doing is to = making some recommendations more explicit.

> I propose to change only router behavior: check Source LLA (MAC) for e= very packet, if this SLLA is absent in ND cache - then request solicited NS= -NA immediately. It would probably resolve faster than traffic would return= from the internet.

Have you checked the problem statement draft?
https://datatrack= er.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#section-3.7
specificatlly?
What you are proposing does make sense, however it would not help in case o= f multiple routers. Also I recall some people having strong opinions on per= formance implications.

> Effectively I do proposed the same SLLA RPF that is needed to fix curr= ent solution, but:
> - without any modification to host OSes
> - without any modification of standard (it is local recommendation for=
> router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is=
> important for security)
> - without any risk to break ND fragile algorithm
> - it could be optional, or even configurable on the router as "va= lue
> add feature" in competitive tender Because it is just best practi= ce recommendation - may be it make sense to move it to "v6ops"?
See https://datatracker.ietf.= org/doc/html/draft-ietf-v6ops-nd-cache-init-03

> PS: Looking to the above - unsolicited NA should be really delayed by = additional big timer (not by RetransTimer that is used for solicited NS/NA)= and checked on receiver side - this modification of standard is really nee= ded to close Unsolicited NA vulnerability.
> Somebody said on the call that it is already a feature of some OS (And= roid?) - it is bad: it means that this OS is already vulnerable.

I was saying that some routing platforms have this already implemented. Sea= rch for 'glean' here:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_bas= ic/configuration/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html

AFAIK there are implementations which are also prepopulating NC from DAD pa= ckets but I can not find you a reference right now.

> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova
> Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49
> To: 6man <ipv6@i= etf.org>
> Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt
>
> Hello,
>
> The -01 version addresses comments received (thanks everyone who provi= ded feedback). Also, Section 3 (Avoiding Disruption) has been expanded and = discussed a corner case when two devices start using the same address almos= t at the same time (the second device configures an optimistic address afte= r the rightful owner sent some packets but before the return traffic arrive= s).
> Feedback on the updated section 3.3
> (https://tools.ietf.org/html/dr= aft-ietf-6man-grand-01#section-3.3) is very much appreciated.
>
> On Sun, Jul 26, 2020 at 10:14 AM <internet-drafts@ietf.org> wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> > This draft is a work item of the IPv6 Maintenance WG of the IETF.=
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Gratuitous Neighbor Discovery: Creating Neighbor Cache Entr= ies on First-Hop Routers
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Jen Linkova
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-6man-grand-01.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: 12
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2020-07-25
> >
> > Abstract:
> >=C2=A0 =C2=A0 Neighbor Discovery (RFC4861) is used by IPv6 nodes t= o determine the
> >=C2=A0 =C2=A0 link-layer addresses of neighboring nodes as well as= to discover and
> >=C2=A0 =C2=A0 maintain reachability information.=C2=A0 This docume= nt updates RFC4861 to
> >=C2=A0 =C2=A0 allow routers to proactively create a Neighbor Cache= entry when a new
> >=C2=A0 =C2=A0 IPv6 address is assigned to a node.=C2=A0 It also up= dates RFC4861 and
> >=C2=A0 =C2=A0 recommends nodes to send unsolicited Neighbor Advert= isements upon
> >=C2=A0 =C2=A0 assigning a new IPv6 address.=C2=A0 The proposed cha= nge will minimize the
> >=C2=A0 =C2=A0 delay and packet loss when a node initiate connectio= ns to off-link
> >=C2=A0 =C2=A0 destination from a new IPv6 address.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/dr= aft-ietf-6man-grand/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf= -6man-grand-01
> > https://datatracker.ietf.org= /doc/html/draft-ietf-6man-grand-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-6man-grand-01
> >
> >
> > Please note that it may take a couple of minutes from the time of=
> > submission until the htmlized version and diff are available at <= a href=3D"http://tools.ietf.org" rel=3D"noreferrer" target=3D"_blank">tools= .ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > -----------------------------------------------------------------= ---
> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > Requests: https://www.ietf.org/mailman/listinfo/= ipv6
> > -----------------------------------------------------------------= ---
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> --------------------------------------------------------------------


--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000002d3c0b05aba63e7c-- From nobody Thu Jul 30 04:01:51 2020 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 362F43A1088; Thu, 30 Jul 2020 04:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SYLSjJXGney; Thu, 30 Jul 2020 04:01:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C463A081D; Thu, 30 Jul 2020 04:01:41 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 06UB1Pea001188 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2020 12:01:26 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Lorenzo Colitti Cc: Vasilenko Eduard , 6man , "v6ops@ietf.org" References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> From: Nick Hilliard Autocrypt: addr=nick@foobar.org; keydata= mQENBE5XyVsBCADeRjKMYehEt/qzcWEHVCg0OMY+wVM5wSrym1OpknH1YeIe5vaObSAID9ck ig676gCZ2YG4CHTmWb0tu7cMzf1Mx+K3FmRbTbk/6W4XXEJq1M4aiNY4BLbLqikMiXHY/pX/ LFj1SPjP+LWz0GLFm6LvijVBPs0P0ID6FW8BrKUqbOgzifHURKBQAwgAPvw1zjEzCNRf1B3y kCfTsnKI9HLwcjhdM49nrTYXAwQVHlxjQgIbX9zEH4j/pCb05UfygPi6+4gBLj6IsUiJJG2H eqN+P/w82IIN4WkU+akS5bAvVaytTbckABLTO8wSuc6I8RjpnNYCjSHQiHG/iei4QNS1ABEB AAG0H05pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZz6JAT4EEwECACgFAk5XyVsCGwMF CQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJECOxk/MZgyq9cnEH/iB2NY5DuNjN dO7qbakE8s2LCNRUGKcJ5Dhofw8StJUf6/IxldlLye3rAJCbkUS0amU6EBJM3g2rfStshPV8 FYDEzRYBRJstg/glyo58g65V0L5/nxkCBhXw8tgnVZbUQYITsoJj09cKmQCjZQqbG43dS0nQ 6tdPrb1A5IPjkIqBrTC9UOjZdTeAqwMxDZf1AEwKgqfC+V9ySlWTWyt8AhV69Rl7vVr91NT5 ssGC5p8ftsVYjz8zj9T2oMc8lGAiny/PpmveqsrCP5MOU4ljSFikwJxSQEJS71BRetsZ/1up dujliK7fCkJKlWGtsuoBOutN+IoBryZQ7T9EIKAlGbg= Message-ID: <1e34f59d-4355-9984-e3e9-8c3e4fffffbd@foobar.org> Date: Thu, 30 Jul 2020 12:01:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.24 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 11:01:44 -0000 Lorenzo Colitti wrote on 30/07/2020 11:36: > I think the fact is that ND is inherently insecure from on-link attacks. > If security is desired, then it needs to be provided in other ways, such > as via SEND or SAVI. But it's also not particularly desirable to provide > security at this layer. ND is particularly weak from a security point of view due to its approach to signalling, i.e. some bits use unicast udp with no token exchange and/or no acknowledgement. Without significant incompatible changes to the protocol, it's difficult to see how this can be improved. SEND has never been deployed widely and has bootstrap problems which are difficult to resolve. Most vendors never bothered implementing it. SAVI moves the complexity into the L2 forwarding device. This comes at a cost, and the more complexity that's thrown into the ND protocol, the more difficult this becomes. The ND assigned codepoint registry gives some clue as to the scale of this complexity: https://www.iana.org/assignments/icmpv6-parameters > Traffic snooping is not very useful (not zero > utility, but difficult to use well) when all traffic is encrypted, and > on-link DoS attacks just aren't very useful these days given that many > devices have a variety of connectivity options. Surely you're joking? Nick From nobody Thu Jul 30 04:06:35 2020 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 90B5F3A1088 for ; Thu, 30 Jul 2020 04:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9g2y5HPVc0z for ; Thu, 30 Jul 2020 04:06:27 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D244A3A10DB for ; Thu, 30 Jul 2020 04:06:24 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id d18so27791883ion.0 for ; Thu, 30 Jul 2020 04:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oips88OfXp4kZBO7bWWSDtPhb5jzr4mPCEOqaEd9nGI=; b=uFPMW46yy0KcssFfZXYGvInMOi3JhRrAarTKVV6g4ix9J/Ndl6WJYQPl8lX5ckE87W YY4UuKU2Z2jHbJF8M/dLPrMok9JKGYu0yq2dFq5uHnASjs66jrezSlm4Y5RmSQ0m7sYP wqV76Xs66S5dt5SAwXLr9KyY3rzRFS5ESklre3ivYv7jVB1JUA6oYcpXj219Wb19pkPn ZUR2EqI9j1cvOUPlyF2HG0zMNR3RiSpyrz+aplCmoFSqoN6VLioygTmkb3zpUo59pku7 9TmNN1mzS3XEtSd7Y/PsW+PKWmDUqjINgyTNyHso/U1MPtNDc8xo4/yr/+UKg9oJBHG+ ubNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oips88OfXp4kZBO7bWWSDtPhb5jzr4mPCEOqaEd9nGI=; b=ljDyoX/JZWvS3Ayf+rGTa2yIsPo57NxUQNtA8/Pjir/BQEsV2eRCKSWGorrPoWBxuB a2ymVURI9ajSZJ6b7TnKCuQyzTQmSOedeqfGnYeDYUCEvaGNllNLdmjBWAh5cHGYB6OY eIPUWARhKPVVRURbR0CE1rRzWuiHKvKhy5wQQ/VyBQJTu5Qr3LTNaMPIOzZ6f8jJJ1JS MeLgYnnF4XofGp1Fm6+YvF1piaPVrhG/uoQJn4B1ncIc44XRQ3YYsjyihirrBbDuufGa zF8YWpgmoMO0pifeh6e3h8CsgilidUs0Scu4y/W2++Bn6Tk5tUH+n+mx7A6DNBz8o6VF EghQ== X-Gm-Message-State: AOAM5329gkKfYS9hY/fMoyOiwEZJq3dD4DtoWBqgyF2Wos7kXkQIzC/2 26JjULG2ADhpgPFawLw2SH4BXz2zK7orXhEu56hsIw== X-Google-Smtp-Source: ABdhPJz3eh2sRsGtM3rbeQT/yEXJbZ0oTth9ivimD2yCNJhfRWC7UYKyN88q79V21TymMTiv4WyLbJHH8ScZr8Y2OnI= X-Received: by 2002:a5d:9a97:: with SMTP id c23mr39146912iom.179.1596107183921; Thu, 30 Jul 2020 04:06:23 -0700 (PDT) MIME-Version: 1.0 References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <1e34f59d-4355-9984-e3e9-8c3e4fffffbd@foobar.org> In-Reply-To: <1e34f59d-4355-9984-e3e9-8c3e4fffffbd@foobar.org> From: Lorenzo Colitti Date: Thu, 30 Jul 2020 20:06:11 +0900 Message-ID: To: Nick Hilliard Cc: Vasilenko Eduard , 6man , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b8efa605aba6a95e" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 11:06:31 -0000 --000000000000b8efa605aba6a95e Content-Type: text/plain; charset="UTF-8" On Thu, Jul 30, 2020 at 8:01 PM Nick Hilliard wrote: > > Traffic snooping is not very useful (not zero > > utility, but difficult to use well) when all traffic is encrypted, and > > on-link DoS attacks just aren't very useful these days given that many > > devices have a variety of connectivity options. > > Surely you're joking? > Actually I should say on-link snooping. Defeating on-link snooping doesn't seem very useful when it's possible for an on-path attacker to snoop the traffic at any point between the local link and the destination. --000000000000b8efa605aba6a95e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 30, 2020 at 8:01 PM Nick Hill= iard <nick@foobar.org> wrote:<= br>
> Traffic snooping is not very useful (not zero
> utility, but difficult to use well) when all traffic is encrypted, and=
> on-link DoS attacks just aren't very useful these days given that = many
> devices have a variety of connectivity options.

Surely you're joking?

Actually I sh= ould say on-link snooping. Defeating on-link snooping doesn't seem very= useful when it's possible for an on-path attacker to snoop the traffic= at any point between the local link and the destination.
--000000000000b8efa605aba6a95e-- From nobody Thu Jul 30 04:18:25 2020 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 840523A1091; Thu, 30 Jul 2020 04:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCVDHe7nhhkB; Thu, 30 Jul 2020 04:17:58 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC6A3A108F; Thu, 30 Jul 2020 04:17:31 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 06UBHFUh004234 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2020 12:17:15 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Lorenzo Colitti Cc: Vasilenko Eduard , 6man , "v6ops@ietf.org" References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <1e34f59d-4355-9984-e3e9-8c3e4fffffbd@foobar.org> From: Nick Hilliard Autocrypt: addr=nick@foobar.org; keydata= mQENBE5XyVsBCADeRjKMYehEt/qzcWEHVCg0OMY+wVM5wSrym1OpknH1YeIe5vaObSAID9ck ig676gCZ2YG4CHTmWb0tu7cMzf1Mx+K3FmRbTbk/6W4XXEJq1M4aiNY4BLbLqikMiXHY/pX/ LFj1SPjP+LWz0GLFm6LvijVBPs0P0ID6FW8BrKUqbOgzifHURKBQAwgAPvw1zjEzCNRf1B3y kCfTsnKI9HLwcjhdM49nrTYXAwQVHlxjQgIbX9zEH4j/pCb05UfygPi6+4gBLj6IsUiJJG2H eqN+P/w82IIN4WkU+akS5bAvVaytTbckABLTO8wSuc6I8RjpnNYCjSHQiHG/iei4QNS1ABEB AAG0H05pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZz6JAT4EEwECACgFAk5XyVsCGwMF CQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJECOxk/MZgyq9cnEH/iB2NY5DuNjN dO7qbakE8s2LCNRUGKcJ5Dhofw8StJUf6/IxldlLye3rAJCbkUS0amU6EBJM3g2rfStshPV8 FYDEzRYBRJstg/glyo58g65V0L5/nxkCBhXw8tgnVZbUQYITsoJj09cKmQCjZQqbG43dS0nQ 6tdPrb1A5IPjkIqBrTC9UOjZdTeAqwMxDZf1AEwKgqfC+V9ySlWTWyt8AhV69Rl7vVr91NT5 ssGC5p8ftsVYjz8zj9T2oMc8lGAiny/PpmveqsrCP5MOU4ljSFikwJxSQEJS71BRetsZ/1up dujliK7fCkJKlWGtsuoBOutN+IoBryZQ7T9EIKAlGbg= Message-ID: <5058abe1-cd3c-8268-10f8-7dff487f93c3@foobar.org> Date: Thu, 30 Jul 2020 12:17:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.24 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 11:18:02 -0000 Lorenzo Colitti wrote on 30/07/2020 12:06: > On Thu, Jul 30, 2020 at 8:01 PM Nick Hilliard > wrote: > > > Traffic snooping is not very useful (not zero > > utility, but difficult to use well) when all traffic is encrypted, and > > on-link DoS attacks just aren't very useful these days given that many > > devices have a variety of connectivity options. > > Surely you're joking? > > Actually I should say on-link snooping. Defeating on-link snooping > doesn't seem very useful when it's possible for an on-path attacker to > snoop the traffic at any point between the local link and the destination. on-link DoS is a significant security problem for ipv6, all the more so due to ND's protocol weaknesses. Nick From nobody Thu Jul 30 04:42:03 2020 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 3DC943A109D; Thu, 30 Jul 2020 04:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ve5IVSjoRQ2; Thu, 30 Jul 2020 04:41:32 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980203A1098; Thu, 30 Jul 2020 04:41:31 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id t7so6021128otp.0; Thu, 30 Jul 2020 04:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rO7XtgL8+CXREsx0vAK2ql9Ya+EO1MxjMEasEw4C2No=; b=SamYkSrOr++BPYH6CoX7Ax3XH7UZ2oK4EAV2YC/HVmfXifhwa76fC6a5L59eIdSEFe q4k4oq1/4GLLpp4GLG3j3LN0z1nBu3K/D1+x5etCRYmgI8uZbi3l7uD0YTXfZBIAI/j0 3w3KLElfEtWLV6jo53/MHEDgaU0xaluHqU5cxD7O84CwG8H5DqPHqfdaSHeG8AGV2yDm 3rNjsUG+qYkw23V+rAV1XIqSKvBrK987qRV4j1KicXT7Oh5wF9EnjbYgxO0Zxmv2xjgb kdNM5nn+nJu+KMWXI3cTRXRdYlL8eNrLh4m+6VTMzEKxbuGKrO/qDf4PDmb7huIL01Bt E31Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rO7XtgL8+CXREsx0vAK2ql9Ya+EO1MxjMEasEw4C2No=; b=dpTr/T6y39ztvnicHXy/m7GIuS5BUZBBgJUaQ1dEXj0ZbDr2no9Z86+F0/d4lMtRqW HLJNBFRz7KaayKvfTgPyaaQBUdujLiVASoFNVufyJJYoO02PILYOp7naKVVguUYtu0bW OXfaDWNjGU6xYHOw4MV/x8gI1nTZxmJwi+r0JoLVj3ZLav1wI+uRYdbhI/D0rLdgQp+V c5ORXCa+0v3jyxI3KQodDXHXqAXznc6NqrE0NAffAtOBaBvrXilKrLd66Ajz5jRekLoR t7wYdXSPRA57wahguWBqbojdEmYkGdafVEjvRaCdbXejM+jCNf71uVME1vuTHqimG4CP C41g== X-Gm-Message-State: AOAM533QaUMnw6ZJh3AJvj/Q6Kwc6DDI+XCnaz4mIm0AliGT+0hb9FzC FXGM9HjS4dVSBMDBL/AP3HInJuLcpDDZzQzFs1E= X-Google-Smtp-Source: ABdhPJxZncfme3rcsMkrkEj6UbD6GtlOkXdOp09Lf6vUEYD1/xtBJW+eDdUmfR3YxiAWjr0K0JYSbLVo+/53+Jf9UjE= X-Received: by 2002:a05:6830:4d9:: with SMTP id s25mr2012277otd.153.1596109290581; Thu, 30 Jul 2020 04:41:30 -0700 (PDT) MIME-Version: 1.0 References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> In-Reply-To: From: Mark Smith Date: Thu, 30 Jul 2020 21:41:18 +1000 Message-ID: To: Lorenzo Colitti Cc: Vasilenko Eduard , 6man , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000049b31c05aba72758" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 11:41:37 -0000 --00000000000049b31c05aba72758 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 30 Jul 2020, 20:37 Lorenzo Colitti, wrote: > I think the fact is that ND is inherently insecure from on-link attacks. > If security is desired, then it needs to be provided in other ways, such = as > via SEND or SAVI. But it's also not particularly desirable to provide > security at this layer. Traffic snooping is not very useful (not zero > utility, but difficult to use well) when all traffic is encrypted, and > on-link DoS attacks just aren't very useful these days given that many > devices have a variety of connectivity options. > +1 More fundamentally, LANs provide any to any connectivity between the set of attached nodes. That's specifically why they were invented. That any to any capability means assuming attached nodes will be good actors and can be trusted not to abuse the any to any capability. If nodes can't be assumed to be trusted with the any to any capability, you don't give it to them. You isolate them from each other at layer 2, so all of their communication goes through a layer 3 device like a router that can enforce individual host layer 2 isolation. Regards, Mark. > On Thu, Jul 30, 2020 at 5:05 PM Vasilenko Eduard < > vasilenko.eduard@huawei.com> wrote: > >> Then it is not logical for me: >> Many people understand that "Unsolicited NA" is a big security hole per >> se, >> But instead of fixing it (may be even deprecate - should be investigated= ) >> Additional functionality is building on top of it. >> It would additionally challenge this security problem resolution in the >> future! >> >> Again: "Unsolicited NA" with Override bit set - is a disaster now.. >> IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for >> the case of MAC address change on legitimate host. >> May be we could think about other solutions. >> But if additional functionality would be built on top of "Unsolicited NA= " >> - less options would be available ("deprecate" would be not a choice >> anymore). >> >> If something is ill - it should be cured first - bodybuilding make sense >> only after this. >> >> Jen, I have not understood below why you did mention RA Guard. Intruder >> does not need it. He just claim (by Unsolicited NA) that his MAC is >> connected to GUA of victim. >> Intruder could claim it every 5 seconds to keep cache in STALE state (fo= r >> the case of very careful vendor implementation of ND). >> As you mentioned - no help from MLD snooping on switches - it would be >> enough to just listen to DAD. Switch could not help in principle. >> The first modified DNS response would convert traffic flow to >> bi-directional for Intruder. >> >> Ed/ >> -----Original Message----- >> From: Jen Linkova [mailto:furry13@gmail.com] >> Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07 >> To: Vasilenko Eduard >> Cc: 6man ; v6ops@ietf.org >> Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security >> concerns >> >> On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard < >> vasilenko.eduard@huawei.com> wrote: >> > You did ask a feedback yesterday about severity of 7sec security hole >> that has very low probability. >> > I have intention here to show that probability is 100%, 7sec could be >> prolonged to forever, and the final result is the full interception of >> innocent host traffic by intruder (successful "man-in-the-middle"). >> > >> > Pre-request for success: >> > - no multicast snooping (MLD) and filtering on a switch, that is >> > perfectly possible >> > - Intruder should be already on the same subnet (gained control over >> > other host by exploiting of different vulnerability) >> > - intruder should suppress DAD on Intruder's controlled host (is >> > Windows firewall capable to filter out DAD?) >> > - We assume that we are talking about the future when this draft is >> > used by majority of nodes (victim should use it) >> > >> > Procedure: >> > Intruder's controlled host does listen to all-routers multicast addres= s >> (ff02::2). >> > As soon as it would eavesdrop unsolicited NA from victim node (probabl= y >> after boot) - Intruder would immediately (a few milliseconds) duplicate = NA >> in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Overri= de >> bit set. >> > Intruder has time only up to the point that response to victim's >> traffic would be returned from the Internet (from tens of milliseconds t= o >> many seconds if victim would not start sending immediately), - but it is >> enough time: local communication should be faster. >> > Theoretically, RetransTimer should be imposed on unsolicited NA >> (section 7.2.6), but low chances that this timer is checked on receiving >> side (router), because RetransTimer is specified for transmission side. >> > According RFC 4681 section 7.2.5 clause II: O bit set should not just >> rewrite ND cache, but additionally mark ND record as REACHABLE. Accordin= g >> to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to >> either zero or one". Despite it contradicts to the logic of the whole RF= C >> 4681 (O bit should not be set in unsolicited NA - it is mentioned in a f= ew >> places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly >> permit to use Override flag - higher probability that particular >> implementation would not just rewrite LLA on router, but additionally pu= t >> it into REACHABLE. >> > Intruder could be sure that at least STALE state would be created >> according to section 7.2.5 clause I, - this ND record would be against h= is >> LLA anyway. >> > After receiving return traffic (if it was created as STALE, not >> REACHABLE) - router would ask intruder about reachability (solicited NS-= NA) >> - intruder would confirm his LLA - it would finally put ND cache record >> into REACHABLE. >> >> 1) the 7 seconds corner case was for 'preventing address collision for >> Optimistic DAD', not for any intentional attacks case. Because: >> 2) What you are describing could be done today, now, anytime w/o the >> changes described in the draft. If there is no MLD snooping then the >> intruder would see the DAD packet from the victim, so it would know the >> victim address anyway - no reason even to join ff02::2. Now all the >> attacker needs to do is to keep sending NA with S=3D1, O=3D1 - hoping th= at when >> the first packet of the return flows arrive and the router creates an >> INCOMPLETE entry and sends an NS, the attacker's packet would come befor= e >> the victim's NA. Done, the entry is changed to REACHABLE, all traffic g= oes >> to the attacker. >> Actually even simpler. The attacker does not need to deal with timing. >> Let's say the router has an NC entry for the victim address in any other >> state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Targe= t >> address =3D the victim's IPv6 address, the TLLA =3D the attacker MAC add= ress. >> Done. The router updates the cache entry and changes it to REACHABLE sta= te. >> >> There is nothing new here. We have the same issue with ARP - the attacke= r >> can override ARP entry on the router. >> >> > That's it: upstream traffic of victim host is going to router, traffic >> back is going through Intruder. >> > I have consulted with penetration tests professional (these are people >> with the same qualification as hackers but they play on legal side): wha= t >> he would be doing next? He said that he would return traffic to legitima= te >> host - victim should not see performance degradation. He would collect >> cookies and some other valuable information. He would finally see DNS >> response, change it and redirect everything to himself on the permanent >> basis - he does want to see both directions of victim exchange. He has >> qualified Man-in-the-middle as full fiasco - it does open many >> opportunities for him. He has mentioned very good feature of this draft >> that there is no any interruption for victim's traffic flow, no any >> excessive traffic to victim, that is very rear benefit for hacker's tool= . >> >> For all that doom and gloom the attacker would also need to see the >> traffic *from* the victim. Assuming the network has RA Guard in place it >> would be a bit harder. If the network does not have RA Guard our poor >> victim has much bigger problems already. >> >> > What to do about it? >> > 1. Potentially it is possible to do RPF-like check for Source LLA >> addresses. Upstream traffic from victim's SLLA would not be in ND cache = - >> such traffic could be discarded. It is better to block communication tha= n >> permit intruder to exploit vulnerability. >> >> > 2. Increase RetransTimer and ask receiver side (router) to check on >> sending side delay between ND record override (for the same SLLA). But h= ow >> long should be the timer? Host could wait a lo-o-o-ng time before it wou= ld >> request 1st information from internet. It would decrease probability, bu= t >> would not completely eliminate attack vector. >> > >> > My proposition for this draft is disruptive: >> > I believe that ND is very complicated (some could say "fragile") - it >> is better not to touch it. >> > Additionally I do not like to wait till all hosts would refresh to new >> draft (to get new functionality). >> >> Well, only hosts which want to connect to the network faster need to >> implement this. So host OS developers have pretty good incentive here. >> Please keep in mind that the proposed behavior is not currently >> prohibited. We are not changing any MUST NOT to anything else. All we ar= e >> doing is to making some recommendations more explicit. >> >> > I propose to change only router behavior: check Source LLA (MAC) for >> every packet, if this SLLA is absent in ND cache - then request solicite= d >> NS-NA immediately. It would probably resolve faster than traffic would >> return from the internet. >> >> Have you checked the problem statement draft? >> >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#= section-3.7 >> specificatlly? >> What you are proposing does make sense, however it would not help in cas= e >> of multiple routers. Also I recall some people having strong opinions on >> performance implications. >> >> > Effectively I do proposed the same SLLA RPF that is needed to fix >> current solution, but: >> > - without any modification to host OSes >> > - without any modification of standard (it is local recommendation for >> > router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is >> > important for security) >> > - without any risk to break ND fragile algorithm >> > - it could be optional, or even configurable on the router as "value >> > add feature" in competitive tender Because it is just best practice >> recommendation - may be it make sense to move it to "v6ops"? >> >> See >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03 >> >> > PS: Looking to the above - unsolicited NA should be really delayed by >> additional big timer (not by RetransTimer that is used for solicited NS/= NA) >> and checked on receiver side - this modification of standard is really >> needed to close Unsolicited NA vulnerability. >> > Somebody said on the call that it is already a feature of some OS >> (Android?) - it is bad: it means that this OS is already vulnerable. >> >> I was saying that some routing platforms have this already implemented. >> Search for 'glean' here: >> >> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configurati= on/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html >> >> AFAIK there are implementations which are also prepopulating NC from DAD >> packets but I can not find you a reference right now. >> >> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova >> > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49 >> > To: 6man >> > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt >> > >> > Hello, >> > >> > The -01 version addresses comments received (thanks everyone who >> provided feedback). Also, Section 3 (Avoiding Disruption) has been expan= ded >> and discussed a corner case when two devices start using the same addres= s >> almost at the same time (the second device configures an optimistic addr= ess >> after the rightful owner sent some packets but before the return traffic >> arrives). >> > Feedback on the updated section 3.3 >> > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is >> very much appreciated. >> > >> > On Sun, Jul 26, 2020 at 10:14 AM wrote: >> > > >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > > This draft is a work item of the IPv6 Maintenance WG of the IETF. >> > > >> > > Title : Gratuitous Neighbor Discovery: Creating >> Neighbor Cache Entries on First-Hop Routers >> > > Author : Jen Linkova >> > > Filename : draft-ietf-6man-grand-01.txt >> > > Pages : 12 >> > > Date : 2020-07-25 >> > > >> > > Abstract: >> > > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine t= he >> > > link-layer addresses of neighboring nodes as well as to discover >> and >> > > maintain reachability information. This document updates RFC4861 >> to >> > > allow routers to proactively create a Neighbor Cache entry when a >> new >> > > IPv6 address is assigned to a node. It also updates RFC4861 and >> > > recommends nodes to send unsolicited Neighbor Advertisements upon >> > > assigning a new IPv6 address. The proposed change will minimize >> the >> > > delay and packet loss when a node initiate connections to off-lin= k >> > > destination from a new IPv6 address. >> > > >> > > >> > > The IETF datatracker status page for this draft is: >> > > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ >> > > >> > > There are also htmlized versions available at: >> > > https://tools.ietf.org/html/draft-ietf-6man-grand-01 >> > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01 >> > > >> > > A diff from the previous version is available at: >> > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01 >> > > >> > > >> > > Please note that it may take a couple of minutes from the time of >> > > submission until the htmlized version and diff are available at >> tools..ietf.org . >> > > >> > > Internet-Drafts are also available by anonymous FTP at: >> > > ftp://ftp.ietf.org/internet-drafts/ >> > > >> > > >> > > -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > > -------------------------------------------------------------------- >> > >> > >> > >> > -- >> > SY, Jen Linkova aka Furry >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> >> >> -- >> SY, Jen Linkova aka Furry >> _______________________________________________ >> 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 > --00000000000049b31c05aba72758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <= div dir=3D"auto">



=


On Thu, Jul 30, 2020 at 5:05 PM Vas= ilenko Eduard <vasi= lenko.eduard@huawei.com> wrote:
Then it is not logical for me:
Many people understand that "Unsolicited NA" is a big security ho= le per se,
But instead of fixing it (may be even deprecate - should be investigated) Additional functionality is building on top of it.
It would additionally challenge this security problem resolution in the fut= ure!

Again: "Unsolicited NA" with Override bit set - is a disaster now= ..
IMHO: it is better to prohibit "Unsolicited NA". Let's wait t= imers for the case of MAC address change on legitimate host.
May be we could think about other solutions.
But if additional functionality would be built on top of "Unsolicited = NA" - less options would be available ("deprecate" would be = not a choice anymore).

If something is ill - it should be cured first - bodybuilding make sense on= ly after this.

Jen, I have not understood below why you did mention RA Guard. Intruder doe= s not need it. He just claim (by Unsolicited NA) that his MAC is connected = to GUA of victim.
Intruder could claim it every 5 seconds to keep cache in STALE state (for t= he case of very careful vendor implementation of ND).
As you mentioned - no help from MLD snooping on switches - it would be enou= gh to just listen to DAD. Switch could not help in principle.
The first modified DNS response would convert traffic flow to bi-directiona= l for Intruder.

Ed/
-----Original Message-----
From: Jen Linkova [mailto:furry1= 3@gmail.com]
Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: 6man <ipv6@ietf.org>; = v6ops@ietf.org
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security con= cerns

On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: > You did ask a feedback yesterday about severity of 7sec security hole = that has very low probability.
> I have intention here to show that probability is 100%, 7sec could be = prolonged to forever, and the final result is the full interception of inno= cent host traffic by intruder (successful "man-in-the-middle"). >
> Pre-request for success:
> - no multicast snooping (MLD) and filtering on a switch, that is
> perfectly possible
> - Intruder should be already on the same subnet (gained control over <= br> > other host by exploiting of different vulnerability)
> - intruder should suppress DAD on Intruder's controlled host (is <= br> > Windows firewall capable to filter out DAD?)
> - We assume that we are talking about the future when this draft is > used by majority of nodes (victim should use it)
>
> Procedure:
> Intruder's controlled host does listen to all-routers multicast ad= dress (ff02::2).
> As soon as it would eavesdrop unsolicited NA from victim node (probabl= y after boot) - Intruder would immediately (a few milliseconds) duplicate N= A in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Ove= rride bit set.
> Intruder has time only up to the point that response to victim's t= raffic would be returned from the Internet (from tens of milliseconds to ma= ny seconds if victim would not start sending immediately), - but it is enou= gh time: local communication should be faster.
> Theoretically, RetransTimer should be imposed on unsolicited NA (secti= on 7.2.6), but low chances that this timer is checked on receiving side (ro= uter), because RetransTimer is specified for transmission side.
> According RFC 4681 section 7.2.5 clause II: O bit set should not just = rewrite ND cache, but additionally mark ND record as REACHABLE. According t= o section 7.2.6: " The Override flag (for unsolicited NA) MAY be set t= o either zero or one". Despite it contradicts to the logic of the whol= e RFC 4681 (O bit should not be set in unsolicited NA - it is mentioned in = a few places of RFC 4681). But because section 7.2.5 and section 7.2.6 clea= rly permit to use Override flag - higher probability that particular implem= entation would not just rewrite LLA on router, but additionally put it into= REACHABLE.
> Intruder could be sure that at least STALE state would be created acco= rding to section 7.2.5 clause I, - this ND record would be against his LLA = anyway.
> After receiving return traffic (if it was created as STALE, not REACHA= BLE) - router would ask intruder about reachability (solicited NS-NA) - int= ruder would confirm his LLA - it would finally put ND cache record into REA= CHABLE.

1) the 7 seconds corner case was for 'preventing address collision for = Optimistic DAD', not for any intentional attacks case. Because:
2) What you are describing could be done today, now, anytime w/o the change= s described in the draft. If there is no MLD snooping then the intruder wou= ld see the DAD packet from the victim, so it would know the victim address = anyway=C2=A0 - no reason even to join ff02::2. Now all the attacker needs t= o do is to keep sending NA with S=3D1, O=3D1 - hoping that when the first p= acket of the return flows arrive and the router creates an INCOMPLETE entry= and sends an NS, the attacker's packet would come before the victim= 9;s NA. Done, the=C2=A0 entry is changed to REACHABLE, all traffic goes to = the attacker.
Actually even simpler. The attacker does not need to deal with timing.
Let's say the router has an NC entry for the victim address in any othe= r state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Target= address =3D the victim's IPv6 address, the TLLA =3D the attacker MAC a= ddress.=C2=A0 Done. The router updates the cache entry and changes it to RE= ACHABLE state.

There is nothing new here. We have the same issue with ARP - the attacker c= an override ARP entry on the router.

> That's it: upstream traffic of victim host is going to router, tra= ffic back is going through Intruder.
> I have consulted with penetration tests professional (these are people= with the same qualification as hackers but they play on legal side): what = he would be doing next? He said that he would return traffic to legitimate = host - victim should not see performance degradation. He would collect cook= ies and some other valuable information. He would finally see DNS response,= change it and redirect everything to himself on the permanent basis - he d= oes want to see both directions of victim exchange. He has qualified Man-in= -the-middle as full fiasco - it does open many opportunities for him. He ha= s mentioned very good feature of this draft that there is no any interrupti= on for victim's traffic flow, no any excessive traffic to victim, that = is very rear benefit for hacker's tool.

For all that doom and gloom the attacker would also need to see the traffic= *from* the victim. Assuming the network has RA Guard in place it would be = a bit harder. If the network does not have RA Guard our poor victim has muc= h bigger problems already.

> What to do about it?
> 1. Potentially it is possible to do RPF-like check for Source LLA addr= esses. Upstream traffic from victim's SLLA would not be in ND cache - s= uch traffic could be discarded. It is better to block communication than pe= rmit intruder to exploit vulnerability.

> 2. Increase RetransTimer and ask receiver side (router) to check on se= nding side delay between ND record override (for the same SLLA). But how lo= ng should be the timer? Host could wait a lo-o-o-ng time before it would re= quest 1st information from internet. It would decrease probability, but wou= ld not completely eliminate attack vector.
>
> My proposition for this draft is disruptive:
> I believe that ND is very complicated (some could say "fragile&qu= ot;) - it is better not to touch it.
> Additionally I do not like to wait till all hosts would refresh to new= draft (to get new functionality).

Well, only hosts which want to connect to the network faster need to implem= ent this. So host OS developers have pretty good incentive here.
Please keep in mind that the proposed behavior is not currently prohibited.= We are not changing any MUST NOT to anything else. All we are doing is to = making some recommendations more explicit.

> I propose to change only router behavior: check Source LLA (MAC) for e= very packet, if this SLLA is absent in ND cache - then request solicited NS= -NA immediately. It would probably resolve faster than traffic would return= from the internet.

Have you checked the problem statement draft?
https://datatracker.ietf.org/doc/html= /draft-ietf-v6ops-nd-cache-init-03#section-3.7
specificatlly?
What you are proposing does make sense, however it would not help in case o= f multiple routers. Also I recall some people having strong opinions on per= formance implications.

> Effectively I do proposed the same SLLA RPF that is needed to fix curr= ent solution, but:
> - without any modification to host OSes
> - without any modification of standard (it is local recommendation for=
> router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is=
> important for security)
> - without any risk to break ND fragile algorithm
> - it could be optional, or even configurable on the router as "va= lue
> add feature" in competitive tender Because it is just best practi= ce recommendation - may be it make sense to move it to "v6ops"?
See https://datatracker.ietf.org/doc/html/draft-i= etf-v6ops-nd-cache-init-03

> PS: Looking to the above - unsolicited NA should be really delayed by = additional big timer (not by RetransTimer that is used for solicited NS/NA)= and checked on receiver side - this modification of standard is really nee= ded to close Unsolicited NA vulnerability.
> Somebody said on the call that it is already a feature of some OS (And= roid?) - it is bad: it means that this OS is already vulnerable.

I was saying that some routing platforms have this already implemented. Sea= rch for 'glean' here:
htt= ps://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/15-= e/ip6b-15-e-book/ip6-nd-cache-mgmt.html

AFAIK there are implementations which are also prepopulating NC from DAD pa= ckets but I can not find you a reference right now.

> From: ipv6 [mailto:ipv6= -bounces@ietf.org] On Behalf Of Jen Linkova
> Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49
> To: 6man <ipv6@ietf.org&= gt;
> Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt
>
> Hello,
>
> The -01 version addresses comments received (thanks everyone who provi= ded feedback). Also, Section 3 (Avoiding Disruption) has been expanded and = discussed a corner case when two devices start using the same address almos= t at the same time (the second device configures an optimistic address afte= r the rightful owner sent some packets but before the return traffic arrive= s).
> Feedback on the updated section 3.3
> (https://tools.ietf.org/html/draft-ietf-6man-grand-= 01#section-3.3) is very much appreciated.
>
> On Sun, Jul 26, 2020 at 10:14 AM <internet-drafts@ietf.org> wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> > This draft is a work item of the IPv6 Maintenance WG of the IETF.=
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Gratuitous Neighbor Discovery: Creating Neighbor Cache Entr= ies on First-Hop Routers
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Jen Linkova
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-6man-grand-01.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: 12
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2020-07-25
> >
> > Abstract:
> >=C2=A0 =C2=A0 Neighbor Discovery (RFC4861) is used by IPv6 nodes t= o determine the
> >=C2=A0 =C2=A0 link-layer addresses of neighboring nodes as well as= to discover and
> >=C2=A0 =C2=A0 maintain reachability information.=C2=A0 This docume= nt updates RFC4861 to
> >=C2=A0 =C2=A0 allow routers to proactively create a Neighbor Cache= entry when a new
> >=C2=A0 =C2=A0 IPv6 address is assigned to a node.=C2=A0 It also up= dates RFC4861 and
> >=C2=A0 =C2=A0 recommends nodes to send unsolicited Neighbor Advert= isements upon
> >=C2=A0 =C2=A0 assigning a new IPv6 address.=C2=A0 The proposed cha= nge will minimize the
> >=C2=A0 =C2=A0 delay and packet loss when a node initiate connectio= ns to off-link
> >=C2=A0 =C2=A0 destination from a new IPv6 address.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/=
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-6man-grand-01 > > https://datatracker.ietf.org/doc/html/draft-ietf= -6man-grand-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6ma= n-grand-01
> >
> >
> > Please note that it may take a couple of minutes from the time of=
> > submission until the htmlized version and diff are available at <= a href=3D"http://tools.ietf.org" rel=3D"noreferrer noreferrer noreferrer no= referrer noreferrer noreferrer" target=3D"_blank">tools..ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > = ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > -----------------------------------------------------------------= ---
> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > -----------------------------------------------------------------= ---
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------


--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/v6ops
--00000000000049b31c05aba72758-- From nobody Thu Jul 30 05:14:57 2020 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 70F833A0C15; Thu, 30 Jul 2020 05:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmgLGYAQbuEv; Thu, 30 Jul 2020 05:14:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 E83C33A0CCE; Thu, 30 Jul 2020 05:14:40 -0700 (PDT) Received: from mb.local ([73.63.242.69]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id 06UCEQEc023996; Thu, 30 Jul 2020 12:14:26 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [73.63.242.69] claimed to be mb.local To: Nick Hilliard , Lorenzo Colitti Cc: "v6ops@ietf.org" , 6man References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <1e34f59d-4355-9984-e3e9-8c3e4fffffbd@foobar.org> <5058abe1-cd3c-8268-10f8-7dff487f93c3@foobar.org> From: joel jaeggli Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= mQGiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfmrQfSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiauQQNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8GIRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: <4fd330c2-7024-71f8-c2f7-a1935468b2c9@bogus.com> Date: Thu, 30 Jul 2020 05:14:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5058abe1-cd3c-8268-10f8-7dff487f93c3@foobar.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eqrL3aK3OBy5MSMyh48bVVA0emeg6ndv5" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:14:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eqrL3aK3OBy5MSMyh48bVVA0emeg6ndv5 Content-Type: multipart/mixed; boundary="AHgsvujQ8hrasObelABbxbEQDjdtINqX5" --AHgsvujQ8hrasObelABbxbEQDjdtINqX5 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/30/20 04:17, Nick Hilliard wrote: > Lorenzo Colitti wrote on 30/07/2020 12:06: >> On Thu, Jul 30, 2020 at 8:01 PM Nick Hilliard > > wrote: >> >> > Traffic snooping is not very useful (not zero >> > utility, but difficult to use well) when all traffic is encrypte= d, and >> > on-link DoS attacks just aren't very useful these days given tha= t many >> > devices have a variety of connectivity options. >> >> Surely you're joking? >> >> Actually I should say on-link snooping. Defeating on-link snooping >> doesn't seem very useful when it's possible for an on-path attacker to= >> snoop the traffic at any point between the local link and the destinat= ion. >=20 > on-link DoS is a significant security problem for ipv6, all the more so= > due to ND's protocol weaknesses. The signifcant size of subnets and the mechanics or reserving resources have since inception created resource consumption threats. > Nick >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --AHgsvujQ8hrasObelABbxbEQDjdtINqX5-- --eqrL3aK3OBy5MSMyh48bVVA0emeg6ndv5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCXyK5nAAKCRDwADWrtn9W sqNNAJ49T5SgeDtxJQ6T8NdIfFvAJOUjiACePajGM8KDKXkmyMev3/4n6rOtSsA= =dnKw -----END PGP SIGNATURE----- --eqrL3aK3OBy5MSMyh48bVVA0emeg6ndv5-- From nobody Thu Jul 30 11:34:57 2020 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 CE3A73A0433; Thu, 30 Jul 2020 11:34:54 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg3RLGOAIm80; Thu, 30 Jul 2020 11:34:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0FDB83A041A; Thu, 30 Jul 2020 11:34:50 -0700 (PDT) Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 362C19433FD357A84401; Thu, 30 Jul 2020 19:34:46 +0100 (IST) Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Jul 2020 19:34:45 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Jul 2020 21:34:45 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Thu, 30 Jul 2020 21:34:45 +0300 From: Vasilenko Eduard To: Jen Linkova CC: 6man , "v6ops@ietf.org" Thread-Topic: I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AdZl2/KmEr6Lt/NERGGqFiMA7k1/CAAIPvAAABH5AHD///P/gP//vOig Date: Thu, 30 Jul 2020 18:34:44 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.196.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 18:34:56 -0000 SGkgSmVuLA0KT0suIElQdjYgU0xBQUMgc3VibmV0IGlzIG5vdCBzZWN1cmUgaW4gcHJpbmNpcGxl IGFuZCB3ZSBzaG91bGQgYWJhbmRvbiBhbnkgYXR0ZW1wdCB0byBpbXByb3ZlIGl0LiBCZWNhdXNl IHNvIG1hbnkgcGVvcGxlIGFscmVhZHkgc3BlbnQgc28gbXVjaCB0aW1lIG9uIHRoaXMgbWF0dGVy IC0gaXQgaXMganVzdCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIHRhbGsgYWdhaW4gYW5kIGFnYWlu Lg0KQW5kIHRoZSBwcmltYXJ5IHNvbHV0aW9uIHRoYXQgdGhleSBmb3VuZCBpcyB0aGUgc3RhdGVm dWwgImJpbmRpbmcgdGFibGUiIG9uIHRoZSBzd2l0Y2ggdG8gbW9uaXRvciBhbGwgTkRzIChsaWtl IERIQ1AvQVJQIGluIElQdjQpLCB0aGF0IG5vdCBtYW55IHVzZSBhbnl3YXkgLSB3ZSBuZWVkIHRv IGZpeCB1bnNlY3VyZSBzb2x1dGlvbi4NCg0KVGhlbiB5b3VyIGRpbGVtbWEgaXMgbm90IGltcG9y dGFudCwgN3NlYyB0cmFmZmljIGhpamFja2luZyBjb3VsZCBub3QgaGFwcGVuIHVuaW50ZW50aW9u YWxseSAtIHByb2JhYmlsaXR5IGZvciBhZGRyZXNzIGNvbGxpc2lvbiBvbiAvNjQgaXMgdG9vIGxv dywgd2hhdGV2ZXIgSW50ZXJmYWNlIElEcyB3b3VsZCBiZSB1c2VkIChjb2xsZWN0aW9uIG9mIFJG Q3MgZXhpc3QpLg0KRWR1YXJkDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmVu IExpbmtvdmEgW21haWx0bzpmdXJyeTEzQGdtYWlsLmNvbV0gDQpTZW50OiAzMCDQuNGO0LvRjyAy MDIwINCzLiAxMjo1OA0KVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVh d2VpLmNvbT4NCkNjOiA2bWFuIDxpcHY2QGlldGYub3JnPjsgdjZvcHNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBhZGRpdGlvbmFs IHNlY3VyaXR5IGNvbmNlcm5zDQoNCk9uIFRodSwgSnVsIDMwLCAyMDIwIGF0IDY6MDUgUE0gVmFz aWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPiB3cm90ZToNCj4gVGhl biBpdCBpcyBub3QgbG9naWNhbCBmb3IgbWU6DQo+IE1hbnkgcGVvcGxlIHVuZGVyc3RhbmQgdGhh dCAiVW5zb2xpY2l0ZWQgTkEiIGlzIGEgYmlnIHNlY3VyaXR5IGhvbGUgDQo+IHBlciBzZSwgQnV0 IGluc3RlYWQgb2YgZml4aW5nIGl0IChtYXkgYmUgZXZlbiBkZXByZWNhdGUgLSBzaG91bGQgYmUg DQo+IGludmVzdGlnYXRlZCkNCg0KVGhlcmUgYXJlIG1hbnkgYXR0YWNrcyBwb3NzaWJsZSB3aXRo aW4gdGhlIHNhbWUgTDIgc2VnbWVudC4gSXQncyBub3QgbmV3LiBUaGF0J3Mgd2h5IHlvdSBzaGFs bCBlaXRoZXIgYmxvY2sgcDJwIHdpdGggdGhlIExBTiAoaWYgeW91IGRvIG5vdCB0cnVzdCBlbmRw b2ludHMgaW4gZ2VuZXJhbCkgb3IgLSBiZXR0ZXIgLSBob3N0cyBzaGFsbCB1c2UgZW5kMmVuZCBl bmNyeXB0aW9uLg0KDQo+IEFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBpcyBidWlsZGluZyBvbiB0 b3Agb2YgaXQuDQoNClNvcnJ5LCBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoeSB1bnNvbGlj aXRlZCBOQSBpcyB0aGUgcHJvYmxlbSBoZXJlLiBUaGUgbWVjaGFuaXNtIEkgZGVzY3JpYmVkIGlu IG15IHByZXZpb3VzIGVtYWlsIGlzIHVzaW5nDQoqc29saWNpdGVkKiBOQSB0byBvdmVycmlkZSB0 aGUgbmVpZ2hib3IgY2FjaGUgb24gdGhlIHJvdXRlci4NCg0KPiBJdCB3b3VsZCBhZGRpdGlvbmFs bHkgY2hhbGxlbmdlIHRoaXMgc2VjdXJpdHkgcHJvYmxlbSByZXNvbHV0aW9uIGluIHRoZSBmdXR1 cmUhDQo+DQo+IEFnYWluOiAiVW5zb2xpY2l0ZWQgTkEiIHdpdGggT3ZlcnJpZGUgYml0IHNldCAt IGlzIGEgZGlzYXN0ZXIgbm93Lg0KDQpBcyB3ZWxsIGFzIFNvbGljaXRlZCwgcmlnaHQ/IDspIFNo YWxsIHdlIGxvb2sgYXQgU0VORCBhZ2Fpbj8gOykgSXQgd291bGQgYmUgZ3JlYXQgYnV0IEknbSBu b3QgYXdhcmUgb2YgaW1wbGVtZW50YXRpb25zIGJlaW5nIHdpZGVseSBkZXBsb3llZC4NCg0KPiBJ TUhPOiBpdCBpcyBiZXR0ZXIgdG8gcHJvaGliaXQgIlVuc29saWNpdGVkIE5BIi4gTGV0J3Mgd2Fp dCB0aW1lcnMgZm9yIHRoZSBjYXNlIG9mIE1BQyBhZGRyZXNzIGNoYW5nZSBvbiBsZWdpdGltYXRl IGhvc3QuDQo+IE1heSBiZSB3ZSBjb3VsZCB0aGluayBhYm91dCBvdGhlciBzb2x1dGlvbnMuDQo+ IEJ1dCBpZiBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgd291bGQgYmUgYnVpbHQgb24gdG9wIG9m ICJVbnNvbGljaXRlZCBOQSIgLSBsZXNzIG9wdGlvbnMgd291bGQgYmUgYXZhaWxhYmxlICgiZGVw cmVjYXRlIiB3b3VsZCBiZSBub3QgYSBjaG9pY2UgYW55bW9yZSkuDQo+DQo+IElmIHNvbWV0aGlu ZyBpcyBpbGwgLSBpdCBzaG91bGQgYmUgY3VyZWQgZmlyc3QgLSBib2R5YnVpbGRpbmcgbWFrZSBz ZW5zZSBvbmx5IGFmdGVyIHRoaXMuDQo+DQo+IEplbiwgSSBoYXZlIG5vdCB1bmRlcnN0b29kIGJl bG93IHdoeSB5b3UgZGlkIG1lbnRpb24gUkEgR3VhcmQuIEludHJ1ZGVyIGRvZXMgbm90IG5lZWQg aXQuIEhlIGp1c3QgY2xhaW0gKGJ5IFVuc29saWNpdGVkIE5BKSB0aGF0IGhpcyBNQUMgaXMgY29u bmVjdGVkIHRvIEdVQSBvZiB2aWN0aW0uDQoNClllcywgdG8gaW50ZXJjZXB0IHRyYWZmaWMgKnRv KiB0aGUgdmljdGltLiBIb3cgaXMgaXQgZ29pbmcgdG8gaW50ZXJjZXB0IHBhY2tldHMgc2VudCBi eSB0aGUgdmljdGltPw0KDQo+IEludHJ1ZGVyIGNvdWxkIGNsYWltIGl0IGV2ZXJ5IDUgc2Vjb25k cyB0byBrZWVwIGNhY2hlIGluIFNUQUxFIHN0YXRlIChmb3IgdGhlIGNhc2Ugb2YgdmVyeSBjYXJl ZnVsIHZlbmRvciBpbXBsZW1lbnRhdGlvbiBvZiBORCkuDQo+IEFzIHlvdSBtZW50aW9uZWQgLSBu byBoZWxwIGZyb20gTUxEIHNub29waW5nIG9uIHN3aXRjaGVzIC0gaXQgd291bGQgYmUgZW5vdWdo IHRvIGp1c3QgbGlzdGVuIHRvIERBRC4gU3dpdGNoIGNvdWxkIG5vdCBoZWxwIGluIHByaW5jaXBs ZS4NCg0KU3RyaWN0bHkgc3BlYWtpbmcsIGlmIHRoZSBzd2l0Y2hpbmcgaW5mcmFzdHJ1Y3R1cmUg aW1wbGVtZW50cyBNTEQgc25vb3BpbmcsIHRoZSBhdHRhY2tlciB3b3VsZCBuZWVkIGVpdGhlciB0 byBndWVzcyB0aGUgbG93ZXIgMjQgYml0cyBvZiB0aGUgdmljdGltJ3MgYWRkcmVzcyBvciB0byBq b2luIDJeMjQgc29saWNpdGVkIG5vZGUgbXVsdGljYXN0IGFkZHJlc3MgZ3JvdXBzLg0KDQo+IFRo ZSBmaXJzdCBtb2RpZmllZCBETlMgcmVzcG9uc2Ugd291bGQgY29udmVydCB0cmFmZmljIGZsb3cg dG8gYmktZGlyZWN0aW9uYWwgZm9yIEludHJ1ZGVyLg0KDQpUaGF0J3Mgd2h5IEROU1NFQyBhbmQg RE5TIG92ZXIgVExTIGFuZCBIVFRQUyBhcmUgZ29vZCBmb3Igc2VjdXJpdHkuDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmVuIExpbmtvdmEgW21haWx0bzpmdXJyeTEz QGdtYWlsLmNvbV0NCj4gU2VudDogMzAg0LjRjtC70Y8gMjAyMCDQsy4gNTowNw0KPiBUbzogVmFz aWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPg0KPiBDYzogNm1hbiA8 aXB2NkBpZXRmLm9yZz47IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBhZGRpdGlvbmFsIA0KPiBzZWN1cml0eSBjb25j ZXJucw0KPg0KPiBPbiBUaHUsIEp1bCAzMCwgMjAyMCBhdCA1OjU2IEFNIFZhc2lsZW5rbyBFZHVh cmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gWW91IGRpZCBhc2sg YSBmZWVkYmFjayB5ZXN0ZXJkYXkgYWJvdXQgc2V2ZXJpdHkgb2YgN3NlYyBzZWN1cml0eSBob2xl IHRoYXQgaGFzIHZlcnkgbG93IHByb2JhYmlsaXR5Lg0KPiA+IEkgaGF2ZSBpbnRlbnRpb24gaGVy ZSB0byBzaG93IHRoYXQgcHJvYmFiaWxpdHkgaXMgMTAwJSwgN3NlYyBjb3VsZCBiZSBwcm9sb25n ZWQgdG8gZm9yZXZlciwgYW5kIHRoZSBmaW5hbCByZXN1bHQgaXMgdGhlIGZ1bGwgaW50ZXJjZXB0 aW9uIG9mIGlubm9jZW50IGhvc3QgdHJhZmZpYyBieSBpbnRydWRlciAoc3VjY2Vzc2Z1bCAibWFu LWluLXRoZS1taWRkbGUiKS4NCj4gPg0KPiA+IFByZS1yZXF1ZXN0IGZvciBzdWNjZXNzOg0KPiA+ IC0gbm8gbXVsdGljYXN0IHNub29waW5nIChNTEQpIGFuZCBmaWx0ZXJpbmcgb24gYSBzd2l0Y2gs IHRoYXQgaXMgDQo+ID4gcGVyZmVjdGx5IHBvc3NpYmxlDQo+ID4gLSBJbnRydWRlciBzaG91bGQg YmUgYWxyZWFkeSBvbiB0aGUgc2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXIgDQo+ID4g b3RoZXIgaG9zdCBieSBleHBsb2l0aW5nIG9mIGRpZmZlcmVudCB2dWxuZXJhYmlsaXR5KQ0KPiA+ IC0gaW50cnVkZXIgc2hvdWxkIHN1cHByZXNzIERBRCBvbiBJbnRydWRlcidzIGNvbnRyb2xsZWQg aG9zdCAoaXMgDQo+ID4gV2luZG93cyBmaXJld2FsbCBjYXBhYmxlIHRvIGZpbHRlciBvdXQgREFE PykNCj4gPiAtIFdlIGFzc3VtZSB0aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBmdXR1cmUg d2hlbiB0aGlzIGRyYWZ0IGlzIA0KPiA+IHVzZWQgYnkgbWFqb3JpdHkgb2Ygbm9kZXMgKHZpY3Rp bSBzaG91bGQgdXNlIGl0KQ0KPiA+DQo+ID4gUHJvY2VkdXJlOg0KPiA+IEludHJ1ZGVyJ3MgY29u dHJvbGxlZCBob3N0IGRvZXMgbGlzdGVuIHRvIGFsbC1yb3V0ZXJzIG11bHRpY2FzdCBhZGRyZXNz IChmZjAyOjoyKS4NCj4gPiBBcyBzb29uIGFzIGl0IHdvdWxkIGVhdmVzZHJvcCB1bnNvbGljaXRl ZCBOQSBmcm9tIHZpY3RpbSBub2RlIChwcm9iYWJseSBhZnRlciBib290KSAtIEludHJ1ZGVyIHdv dWxkIGltbWVkaWF0ZWx5IChhIGZldyBtaWxsaXNlY29uZHMpIGR1cGxpY2F0ZSBOQSBpbiByb3V0 ZXIncyBkaXJlY3Rpb24sIGJ1dCB3aXRoIDIgY2hhbmdlczogKDEpIGhpcyBMTEEgKE1BQyk7ICgy KSBPdmVycmlkZSBiaXQgc2V0Lg0KPiA+IEludHJ1ZGVyIGhhcyB0aW1lIG9ubHkgdXAgdG8gdGhl IHBvaW50IHRoYXQgcmVzcG9uc2UgdG8gdmljdGltJ3MgdHJhZmZpYyB3b3VsZCBiZSByZXR1cm5l ZCBmcm9tIHRoZSBJbnRlcm5ldCAoZnJvbSB0ZW5zIG9mIG1pbGxpc2Vjb25kcyB0byBtYW55IHNl Y29uZHMgaWYgdmljdGltIHdvdWxkIG5vdCBzdGFydCBzZW5kaW5nIGltbWVkaWF0ZWx5KSwgLSBi dXQgaXQgaXMgZW5vdWdoIHRpbWU6IGxvY2FsIGNvbW11bmljYXRpb24gc2hvdWxkIGJlIGZhc3Rl ci4NCj4gPiBUaGVvcmV0aWNhbGx5LCBSZXRyYW5zVGltZXIgc2hvdWxkIGJlIGltcG9zZWQgb24g dW5zb2xpY2l0ZWQgTkEgKHNlY3Rpb24gNy4yLjYpLCBidXQgbG93IGNoYW5jZXMgdGhhdCB0aGlz IHRpbWVyIGlzIGNoZWNrZWQgb24gcmVjZWl2aW5nIHNpZGUgKHJvdXRlciksIGJlY2F1c2UgUmV0 cmFuc1RpbWVyIGlzIHNwZWNpZmllZCBmb3IgdHJhbnNtaXNzaW9uIHNpZGUuDQo+ID4gQWNjb3Jk aW5nIFJGQyA0NjgxIHNlY3Rpb24gNy4yLjUgY2xhdXNlIElJOiBPIGJpdCBzZXQgc2hvdWxkIG5v dCBqdXN0IHJld3JpdGUgTkQgY2FjaGUsIGJ1dCBhZGRpdGlvbmFsbHkgbWFyayBORCByZWNvcmQg YXMgUkVBQ0hBQkxFLiBBY2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIuNjogIiBUaGUgT3ZlcnJpZGUg ZmxhZyAoZm9yIHVuc29saWNpdGVkIE5BKSBNQVkgYmUgc2V0IHRvIGVpdGhlciB6ZXJvIG9yIG9u ZSIuIERlc3BpdGUgaXQgY29udHJhZGljdHMgdG8gdGhlIGxvZ2ljIG9mIHRoZSB3aG9sZSBSRkMg NDY4MSAoTyBiaXQgc2hvdWxkIG5vdCBiZSBzZXQgaW4gdW5zb2xpY2l0ZWQgTkEgLSBpdCBpcyBt ZW50aW9uZWQgaW4gYSBmZXcgcGxhY2VzIG9mIFJGQyA0NjgxKS4gQnV0IGJlY2F1c2Ugc2VjdGlv biA3LjIuNSBhbmQgc2VjdGlvbiA3LjIuNiBjbGVhcmx5IHBlcm1pdCB0byB1c2UgT3ZlcnJpZGUg ZmxhZyAtIGhpZ2hlciBwcm9iYWJpbGl0eSB0aGF0IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24g d291bGQgbm90IGp1c3QgcmV3cml0ZSBMTEEgb24gcm91dGVyLCBidXQgYWRkaXRpb25hbGx5IHB1 dCBpdCBpbnRvIFJFQUNIQUJMRS4NCj4gPiBJbnRydWRlciBjb3VsZCBiZSBzdXJlIHRoYXQgYXQg bGVhc3QgU1RBTEUgc3RhdGUgd291bGQgYmUgY3JlYXRlZCBhY2NvcmRpbmcgdG8gc2VjdGlvbiA3 LjIuNSBjbGF1c2UgSSwgLSB0aGlzIE5EIHJlY29yZCB3b3VsZCBiZSBhZ2FpbnN0IGhpcyBMTEEg YW55d2F5Lg0KPiA+IEFmdGVyIHJlY2VpdmluZyByZXR1cm4gdHJhZmZpYyAoaWYgaXQgd2FzIGNy ZWF0ZWQgYXMgU1RBTEUsIG5vdCBSRUFDSEFCTEUpIC0gcm91dGVyIHdvdWxkIGFzayBpbnRydWRl ciBhYm91dCByZWFjaGFiaWxpdHkgKHNvbGljaXRlZCBOUy1OQSkgLSBpbnRydWRlciB3b3VsZCBj b25maXJtIGhpcyBMTEEgLSBpdCB3b3VsZCBmaW5hbGx5IHB1dCBORCBjYWNoZSByZWNvcmQgaW50 byBSRUFDSEFCTEUuDQo+DQo+IDEpIHRoZSA3IHNlY29uZHMgY29ybmVyIGNhc2Ugd2FzIGZvciAn cHJldmVudGluZyBhZGRyZXNzIGNvbGxpc2lvbiBmb3IgT3B0aW1pc3RpYyBEQUQnLCBub3QgZm9y IGFueSBpbnRlbnRpb25hbCBhdHRhY2tzIGNhc2UuIEJlY2F1c2U6DQo+IDIpIFdoYXQgeW91IGFy ZSBkZXNjcmliaW5nIGNvdWxkIGJlIGRvbmUgdG9kYXksIG5vdywgYW55dGltZSB3L28gdGhlIGNo YW5nZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29waW5n IHRoZW4gdGhlIGludHJ1ZGVyIHdvdWxkIHNlZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2aWN0 aW0sIHNvIGl0IHdvdWxkIGtub3cgdGhlIHZpY3RpbSBhZGRyZXNzIGFueXdheSAgLSBubyByZWFz b24gZXZlbiB0byBqb2luIGZmMDI6OjIuIE5vdyBhbGwgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGRv IGlzIHRvIGtlZXAgc2VuZGluZyBOQSB3aXRoIFM9MSwgTz0xIC0gaG9waW5nIHRoYXQgd2hlbiB0 aGUgZmlyc3QgcGFja2V0IG9mIHRoZSByZXR1cm4gZmxvd3MgYXJyaXZlIGFuZCB0aGUgcm91dGVy IGNyZWF0ZXMgYW4gSU5DT01QTEVURSBlbnRyeSBhbmQgc2VuZHMgYW4gTlMsIHRoZSBhdHRhY2tl cidzIHBhY2tldCB3b3VsZCBjb21lIGJlZm9yZSB0aGUgdmljdGltJ3MgTkEuIERvbmUsIHRoZSAg ZW50cnkgaXMgY2hhbmdlZCB0byBSRUFDSEFCTEUsIGFsbCB0cmFmZmljIGdvZXMgdG8gdGhlIGF0 dGFja2VyLg0KPiBBY3R1YWxseSBldmVuIHNpbXBsZXIuIFRoZSBhdHRhY2tlciBkb2VzIG5vdCBu ZWVkIHRvIGRlYWwgd2l0aCB0aW1pbmcuDQo+IExldCdzIHNheSB0aGUgcm91dGVyIGhhcyBhbiBO QyBlbnRyeSBmb3IgdGhlIHZpY3RpbSBhZGRyZXNzIGluIGFueSBvdGhlciBzdGF0ZSB0aGFuIElO Q09NUExFVEUuIFRoZSBhdHRhY2tlciBzZW5kcyBhbiBOQSB3aXRoIFM9MSwgTz0xLCBUYXJnZXQg YWRkcmVzcyA9IHRoZSB2aWN0aW0ncyBJUHY2IGFkZHJlc3MsIHRoZSBUTExBID0gdGhlIGF0dGFj a2VyIE1BQyBhZGRyZXNzLiAgRG9uZS4gVGhlIHJvdXRlciB1cGRhdGVzIHRoZSBjYWNoZSBlbnRy eSBhbmQgY2hhbmdlcyBpdCB0byBSRUFDSEFCTEUgc3RhdGUuDQo+DQo+IFRoZXJlIGlzIG5vdGhp bmcgbmV3IGhlcmUuIFdlIGhhdmUgdGhlIHNhbWUgaXNzdWUgd2l0aCBBUlAgLSB0aGUgYXR0YWNr ZXIgY2FuIG92ZXJyaWRlIEFSUCBlbnRyeSBvbiB0aGUgcm91dGVyLg0KPg0KPiA+IFRoYXQncyBp dDogdXBzdHJlYW0gdHJhZmZpYyBvZiB2aWN0aW0gaG9zdCBpcyBnb2luZyB0byByb3V0ZXIsIHRy YWZmaWMgYmFjayBpcyBnb2luZyB0aHJvdWdoIEludHJ1ZGVyLg0KPiA+IEkgaGF2ZSBjb25zdWx0 ZWQgd2l0aCBwZW5ldHJhdGlvbiB0ZXN0cyBwcm9mZXNzaW9uYWwgKHRoZXNlIGFyZSBwZW9wbGUg d2l0aCB0aGUgc2FtZSBxdWFsaWZpY2F0aW9uIGFzIGhhY2tlcnMgYnV0IHRoZXkgcGxheSBvbiBs ZWdhbCBzaWRlKTogd2hhdCBoZSB3b3VsZCBiZSBkb2luZyBuZXh0PyBIZSBzYWlkIHRoYXQgaGUg d291bGQgcmV0dXJuIHRyYWZmaWMgdG8gbGVnaXRpbWF0ZSBob3N0IC0gdmljdGltIHNob3VsZCBu b3Qgc2VlIHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLiBIZSB3b3VsZCBjb2xsZWN0IGNvb2tpZXMg YW5kIHNvbWUgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIEhlIHdvdWxkIGZpbmFsbHkgc2Vl IEROUyByZXNwb25zZSwgY2hhbmdlIGl0IGFuZCByZWRpcmVjdCBldmVyeXRoaW5nIHRvIGhpbXNl bGYgb24gdGhlIHBlcm1hbmVudCBiYXNpcyAtIGhlIGRvZXMgd2FudCB0byBzZWUgYm90aCBkaXJl Y3Rpb25zIG9mIHZpY3RpbSBleGNoYW5nZS4gSGUgaGFzIHF1YWxpZmllZCBNYW4taW4tdGhlLW1p ZGRsZSBhcyBmdWxsIGZpYXNjbyAtIGl0IGRvZXMgb3BlbiBtYW55IG9wcG9ydHVuaXRpZXMgZm9y IGhpbS4gSGUgaGFzIG1lbnRpb25lZCB2ZXJ5IGdvb2QgZmVhdHVyZSBvZiB0aGlzIGRyYWZ0IHRo YXQgdGhlcmUgaXMgbm8gYW55IGludGVycnVwdGlvbiBmb3IgdmljdGltJ3MgdHJhZmZpYyBmbG93 LCBubyBhbnkgZXhjZXNzaXZlIHRyYWZmaWMgdG8gdmljdGltLCB0aGF0IGlzIHZlcnkgcmVhciBi ZW5lZml0IGZvciBoYWNrZXIncyB0b29sLg0KPg0KPiBGb3IgYWxsIHRoYXQgZG9vbSBhbmQgZ2xv b20gdGhlIGF0dGFja2VyIHdvdWxkIGFsc28gbmVlZCB0byBzZWUgdGhlIHRyYWZmaWMgKmZyb20q IHRoZSB2aWN0aW0uIEFzc3VtaW5nIHRoZSBuZXR3b3JrIGhhcyBSQSBHdWFyZCBpbiBwbGFjZSBp dCB3b3VsZCBiZSBhIGJpdCBoYXJkZXIuIElmIHRoZSBuZXR3b3JrIGRvZXMgbm90IGhhdmUgUkEg R3VhcmQgb3VyIHBvb3IgdmljdGltIGhhcyBtdWNoIGJpZ2dlciBwcm9ibGVtcyBhbHJlYWR5Lg0K Pg0KPiA+IFdoYXQgdG8gZG8gYWJvdXQgaXQ/DQo+ID4gMS4gUG90ZW50aWFsbHkgaXQgaXMgcG9z c2libGUgdG8gZG8gUlBGLWxpa2UgY2hlY2sgZm9yIFNvdXJjZSBMTEEgYWRkcmVzc2VzLiBVcHN0 cmVhbSB0cmFmZmljIGZyb20gdmljdGltJ3MgU0xMQSB3b3VsZCBub3QgYmUgaW4gTkQgY2FjaGUg LSBzdWNoIHRyYWZmaWMgY291bGQgYmUgZGlzY2FyZGVkLiBJdCBpcyBiZXR0ZXIgdG8gYmxvY2sg Y29tbXVuaWNhdGlvbiB0aGFuIHBlcm1pdCBpbnRydWRlciB0byBleHBsb2l0IHZ1bG5lcmFiaWxp dHkuDQo+DQo+ID4gMi4gSW5jcmVhc2UgUmV0cmFuc1RpbWVyIGFuZCBhc2sgcmVjZWl2ZXIgc2lk ZSAocm91dGVyKSB0byBjaGVjayBvbiBzZW5kaW5nIHNpZGUgZGVsYXkgYmV0d2VlbiBORCByZWNv cmQgb3ZlcnJpZGUgKGZvciB0aGUgc2FtZSBTTExBKS4gQnV0IGhvdyBsb25nIHNob3VsZCBiZSB0 aGUgdGltZXI/IEhvc3QgY291bGQgd2FpdCBhIGxvLW8tby1uZyB0aW1lIGJlZm9yZSBpdCB3b3Vs ZCByZXF1ZXN0IDFzdCBpbmZvcm1hdGlvbiBmcm9tIGludGVybmV0LiBJdCB3b3VsZCBkZWNyZWFz ZSBwcm9iYWJpbGl0eSwgYnV0IHdvdWxkIG5vdCBjb21wbGV0ZWx5IGVsaW1pbmF0ZSBhdHRhY2sg dmVjdG9yLg0KPiA+DQo+ID4gTXkgcHJvcG9zaXRpb24gZm9yIHRoaXMgZHJhZnQgaXMgZGlzcnVw dGl2ZToNCj4gPiBJIGJlbGlldmUgdGhhdCBORCBpcyB2ZXJ5IGNvbXBsaWNhdGVkIChzb21lIGNv dWxkIHNheSAiZnJhZ2lsZSIpIC0gaXQgaXMgYmV0dGVyIG5vdCB0byB0b3VjaCBpdC4NCj4gPiBB ZGRpdGlvbmFsbHkgSSBkbyBub3QgbGlrZSB0byB3YWl0IHRpbGwgYWxsIGhvc3RzIHdvdWxkIHJl ZnJlc2ggdG8gbmV3IGRyYWZ0ICh0byBnZXQgbmV3IGZ1bmN0aW9uYWxpdHkpLg0KPg0KPiBXZWxs LCBvbmx5IGhvc3RzIHdoaWNoIHdhbnQgdG8gY29ubmVjdCB0byB0aGUgbmV0d29yayBmYXN0ZXIg bmVlZCB0byBpbXBsZW1lbnQgdGhpcy4gU28gaG9zdCBPUyBkZXZlbG9wZXJzIGhhdmUgcHJldHR5 IGdvb2QgaW5jZW50aXZlIGhlcmUuDQo+IFBsZWFzZSBrZWVwIGluIG1pbmQgdGhhdCB0aGUgcHJv cG9zZWQgYmVoYXZpb3IgaXMgbm90IGN1cnJlbnRseSBwcm9oaWJpdGVkLiBXZSBhcmUgbm90IGNo YW5naW5nIGFueSBNVVNUIE5PVCB0byBhbnl0aGluZyBlbHNlLiBBbGwgd2UgYXJlIGRvaW5nIGlz IHRvIG1ha2luZyBzb21lIHJlY29tbWVuZGF0aW9ucyBtb3JlIGV4cGxpY2l0Lg0KPg0KPiA+IEkg cHJvcG9zZSB0byBjaGFuZ2Ugb25seSByb3V0ZXIgYmVoYXZpb3I6IGNoZWNrIFNvdXJjZSBMTEEg KE1BQykgZm9yIGV2ZXJ5IHBhY2tldCwgaWYgdGhpcyBTTExBIGlzIGFic2VudCBpbiBORCBjYWNo ZSAtIHRoZW4gcmVxdWVzdCBzb2xpY2l0ZWQgTlMtTkEgaW1tZWRpYXRlbHkuIEl0IHdvdWxkIHBy b2JhYmx5IHJlc29sdmUgZmFzdGVyIHRoYW4gdHJhZmZpYyB3b3VsZCByZXR1cm4gZnJvbSB0aGUg aW50ZXJuZXQuDQo+DQo+IEhhdmUgeW91IGNoZWNrZWQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRy YWZ0Pw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt djZvcHMtbmQtY2FjaGUtaW5pdC0wDQo+IDMjc2VjdGlvbi0zLjcNCj4gc3BlY2lmaWNhdGxseT8N Cj4gV2hhdCB5b3UgYXJlIHByb3Bvc2luZyBkb2VzIG1ha2Ugc2Vuc2UsIGhvd2V2ZXIgaXQgd291 bGQgbm90IGhlbHAgaW4gY2FzZSBvZiBtdWx0aXBsZSByb3V0ZXJzLiBBbHNvIEkgcmVjYWxsIHNv bWUgcGVvcGxlIGhhdmluZyBzdHJvbmcgb3BpbmlvbnMgb24gcGVyZm9ybWFuY2UgaW1wbGljYXRp b25zLg0KPg0KPiA+IEVmZmVjdGl2ZWx5IEkgZG8gcHJvcG9zZWQgdGhlIHNhbWUgU0xMQSBSUEYg dGhhdCBpcyBuZWVkZWQgdG8gZml4IGN1cnJlbnQgc29sdXRpb24sIGJ1dDoNCj4gPiAtIHdpdGhv dXQgYW55IG1vZGlmaWNhdGlvbiB0byBob3N0IE9TZXMNCj4gPiAtIHdpdGhvdXQgYW55IG1vZGlm aWNhdGlvbiBvZiBzdGFuZGFyZCAoaXQgaXMgbG9jYWwgcmVjb21tZW5kYXRpb24gDQo+ID4gZm9y IHJvdXRlciwgTlMtTkEgaXMgZXhhY3RseSB0aGUgc2FtZSBmcm9tIFJGQyA0NjgxLCBOQSBpcyB1 bmljYXN0IC0gDQo+ID4gaXQgaXMgaW1wb3J0YW50IGZvciBzZWN1cml0eSkNCj4gPiAtIHdpdGhv dXQgYW55IHJpc2sgdG8gYnJlYWsgTkQgZnJhZ2lsZSBhbGdvcml0aG0NCj4gPiAtIGl0IGNvdWxk IGJlIG9wdGlvbmFsLCBvciBldmVuIGNvbmZpZ3VyYWJsZSBvbiB0aGUgcm91dGVyIGFzICJ2YWx1 ZSANCj4gPiBhZGQgZmVhdHVyZSIgaW4gY29tcGV0aXRpdmUgdGVuZGVyIEJlY2F1c2UgaXQgaXMg anVzdCBiZXN0IHByYWN0aWNlIHJlY29tbWVuZGF0aW9uIC0gbWF5IGJlIGl0IG1ha2Ugc2Vuc2Ug dG8gbW92ZSBpdCB0byAidjZvcHMiPw0KPg0KPiBTZWUgDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1uZC1jYWNoZS1pbml0LTANCj4gMw0K Pg0KPiA+IFBTOiBMb29raW5nIHRvIHRoZSBhYm92ZSAtIHVuc29saWNpdGVkIE5BIHNob3VsZCBi ZSByZWFsbHkgZGVsYXllZCBieSBhZGRpdGlvbmFsIGJpZyB0aW1lciAobm90IGJ5IFJldHJhbnNU aW1lciB0aGF0IGlzIHVzZWQgZm9yIHNvbGljaXRlZCBOUy9OQSkgYW5kIGNoZWNrZWQgb24gcmVj ZWl2ZXIgc2lkZSAtIHRoaXMgbW9kaWZpY2F0aW9uIG9mIHN0YW5kYXJkIGlzIHJlYWxseSBuZWVk ZWQgdG8gY2xvc2UgVW5zb2xpY2l0ZWQgTkEgdnVsbmVyYWJpbGl0eS4NCj4gPiBTb21lYm9keSBz YWlkIG9uIHRoZSBjYWxsIHRoYXQgaXQgaXMgYWxyZWFkeSBhIGZlYXR1cmUgb2Ygc29tZSBPUyAo QW5kcm9pZD8pIC0gaXQgaXMgYmFkOiBpdCBtZWFucyB0aGF0IHRoaXMgT1MgaXMgYWxyZWFkeSB2 dWxuZXJhYmxlLg0KPg0KPiBJIHdhcyBzYXlpbmcgdGhhdCBzb21lIHJvdXRpbmcgcGxhdGZvcm1z IGhhdmUgdGhpcyBhbHJlYWR5IGltcGxlbWVudGVkLiBTZWFyY2ggZm9yICdnbGVhbicgaGVyZToN Cj4gaHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2 X2Jhc2ljL2NvbmZpZ3VyYQ0KPiB0aW9uLzE1LWUvaXA2Yi0xNS1lLWJvb2svaXA2LW5kLWNhY2hl LW1nbXQuaHRtbA0KPg0KPiBBRkFJSyB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHdoaWNoIGFy ZSBhbHNvIHByZXBvcHVsYXRpbmcgTkMgZnJvbSBEQUQgcGFja2V0cyBidXQgSSBjYW4gbm90IGZp bmQgeW91IGEgcmVmZXJlbmNlIHJpZ2h0IG5vdy4NCj4NCj4gPiBGcm9tOiBpcHY2IFttYWlsdG86 aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmVuIExpbmtvdmENCj4gPiBTZW50 OiAyNyDQuNGO0LvRjyAyMDIwINCzLiA3OjQ5DQo+ID4gVG86IDZtYW4gPGlwdjZAaWV0Zi5vcmc+ DQo+ID4gU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMS50 eHQNCj4gPg0KPiA+IEhlbGxvLA0KPiA+DQo+ID4gVGhlIC0wMSB2ZXJzaW9uIGFkZHJlc3NlcyBj b21tZW50cyByZWNlaXZlZCAodGhhbmtzIGV2ZXJ5b25lIHdobyBwcm92aWRlZCBmZWVkYmFjayku IEFsc28sIFNlY3Rpb24gMyAoQXZvaWRpbmcgRGlzcnVwdGlvbikgaGFzIGJlZW4gZXhwYW5kZWQg YW5kIGRpc2N1c3NlZCBhIGNvcm5lciBjYXNlIHdoZW4gdHdvIGRldmljZXMgc3RhcnQgdXNpbmcg dGhlIHNhbWUgYWRkcmVzcyBhbG1vc3QgYXQgdGhlIHNhbWUgdGltZSAodGhlIHNlY29uZCBkZXZp Y2UgY29uZmlndXJlcyBhbiBvcHRpbWlzdGljIGFkZHJlc3MgYWZ0ZXIgdGhlIHJpZ2h0ZnVsIG93 bmVyIHNlbnQgc29tZSBwYWNrZXRzIGJ1dCBiZWZvcmUgdGhlIHJldHVybiB0cmFmZmljIGFycml2 ZXMpLg0KPiA+IEZlZWRiYWNrIG9uIHRoZSB1cGRhdGVkIHNlY3Rpb24gMy4zDQo+ID4gKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEjc2VjdGlvbi0z LjMpIGlzIHZlcnkgbXVjaCBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IE9uIFN1biwgSnVsIDI2LCAy MDIwIGF0IDEwOjE0IEFNIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID4N Cj4gPiA+DQo+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ID4gPiBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE1haW50ZW5hbmNlIFdHIG9mIHRoZSBJRVRGLg0KPiA+ ID4NCj4gPiA+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogR3JhdHVpdG91cyBOZWlnaGJvciBE aXNjb3Zlcnk6IENyZWF0aW5nIE5laWdoYm9yIENhY2hlIEVudHJpZXMgb24gRmlyc3QtSG9wIFJv dXRlcnMNCj4gPiA+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogSmVuIExpbmtvdmENCj4gPiA+ ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxLnR4dA0K PiA+ID4gICAgICAgICBQYWdlcyAgICAgICAgICAgOiAxMg0KPiA+ID4gICAgICAgICBEYXRlICAg ICAgICAgICAgOiAyMDIwLTA3LTI1DQo+ID4gPg0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4gPiAgICBO ZWlnaGJvciBEaXNjb3ZlcnkgKFJGQzQ4NjEpIGlzIHVzZWQgYnkgSVB2NiBub2RlcyB0byBkZXRl cm1pbmUgdGhlDQo+ID4gPiAgICBsaW5rLWxheWVyIGFkZHJlc3NlcyBvZiBuZWlnaGJvcmluZyBu b2RlcyBhcyB3ZWxsIGFzIHRvIGRpc2NvdmVyIGFuZA0KPiA+ID4gICAgbWFpbnRhaW4gcmVhY2hh YmlsaXR5IGluZm9ybWF0aW9uLiAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzQ4NjEgdG8NCj4g PiA+ICAgIGFsbG93IHJvdXRlcnMgdG8gcHJvYWN0aXZlbHkgY3JlYXRlIGEgTmVpZ2hib3IgQ2Fj aGUgZW50cnkgd2hlbiBhIG5ldw0KPiA+ID4gICAgSVB2NiBhZGRyZXNzIGlzIGFzc2lnbmVkIHRv IGEgbm9kZS4gIEl0IGFsc28gdXBkYXRlcyBSRkM0ODYxIGFuZA0KPiA+ID4gICAgcmVjb21tZW5k cyBub2RlcyB0byBzZW5kIHVuc29saWNpdGVkIE5laWdoYm9yIEFkdmVydGlzZW1lbnRzIHVwb24N Cj4gPiA+ICAgIGFzc2lnbmluZyBhIG5ldyBJUHY2IGFkZHJlc3MuICBUaGUgcHJvcG9zZWQgY2hh bmdlIHdpbGwgbWluaW1pemUgdGhlDQo+ID4gPiAgICBkZWxheSBhbmQgcGFja2V0IGxvc3Mgd2hl biBhIG5vZGUgaW5pdGlhdGUgY29ubmVjdGlvbnMgdG8gb2ZmLWxpbmsNCj4gPiA+ICAgIGRlc3Rp bmF0aW9uIGZyb20gYSBuZXcgSVB2NiBhZGRyZXNzLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiA+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC8NCj4g PiA+DQo+ID4gPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQo+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLWdyYW5k LTAxDQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtNm1hbi1ncmFuZC0wMQ0KPiA+ID4NCj4gPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDENCj4gPiA+DQo+ID4gPg0KPiA+ID4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YgDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4gPg0KPiA+ID4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+ID4g ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPiA+DQo+ID4gPg0KPiA+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gPiAtLSBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Qg aXB2NkBpZXRmLm9yZyANCj4gPiA+IEFkbWluaXN0cmF0aXZlDQo+ID4gPiBSZXF1ZXN0czogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiA+IC0tDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBTWSwgSmVuIExpbmtvdmEgYWth IEZ1cnJ5DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZlIA0KPiA+IFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPg0KPg0KPg0KPiAtLQ0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQoNCg0KDQot LQ0KU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0K From nobody Thu Jul 30 11:40:42 2020 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 71BC03A0433 for ; Thu, 30 Jul 2020 11:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqQ2BEXC8yQG for ; Thu, 30 Jul 2020 11:40:36 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D083A041A for ; Thu, 30 Jul 2020 11:40:35 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id l2so15268910wrc.7 for ; Thu, 30 Jul 2020 11:40:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f3DyCB7dP96QNAhUGUVlVT71IR1A0f/86roL/J+wzgc=; b=S6Dbc+HtGO/Rn/P6T9UWDw+j3neUjVVtWxiMvMbqxAtb7bUeDrj00tpv2vwkPDMcZT 6y/8xd+Xn2LlWQVrB3szYpEoJmH7pWPJgQ357ejU2+P6iZAyTpJfpZp8sUnANihOIpW+ WTf/6NSbFjVwIHXwS2uAca0K0OxKjVcXuG7VsrcQc9s9FA7IwD9BH3O+PmsE224Z89on e+of5RAiYR5IxPs/ihBbKa2Q+LvqeHh6BGFKH01q+hyvfcPYpkY9PyH0MOVmUWH5BQUa wnv9hDAaWDkv8IXcFM3HteYTfNd+C9ix/mM3HC9NjzKmWUVrsM94Ed20IiXHRxykjlPA 0/uw== X-Gm-Message-State: AOAM532SlrJqQrpFGiRH+VCpWXk5rh6tpaahZ6UEo3zKAYO2mVltff1B CD3Mxw0KiZIrwPl0Z9Oq2AQkHYBpgi53l8i8os/7Cr4v X-Google-Smtp-Source: ABdhPJzCJRTaqj3vBU0+9xkhBknCrLQPK6Hye6nMOkrkIy/wNGZjpuJ9M/CsuaWgxwYv57OgXd8rMX4EUlbpNDazexE= X-Received: by 2002:a5d:514c:: with SMTP id u12mr123368wrt.90.1596134433947; Thu, 30 Jul 2020 11:40:33 -0700 (PDT) MIME-Version: 1.0 References: <159594573523.13152.3914768057480139064@ietfa.amsl.com> <7975506A-9D32-490B-96C6-E4A1CF7EBFE1@consulintel.es> In-Reply-To: <7975506A-9D32-490B-96C6-E4A1CF7EBFE1@consulintel.es> From: Erik Nygren Date: Thu, 30 Jul 2020 14:40:22 -0400 Message-ID: To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000f3059505abad01df" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 18:40:41 -0000 --000000000000f3059505abad01df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This version improves, but still seems to be missing some important items. I'm also still worried that it may not be safe enough and may still cause more problems than it solves, especially if implementations are buggy. (Buggy implementations in CPEs will be really hard to debug or trace back for people outside the network, will be hard/impossible to get fixed, and will result in dual-stack content getting switched to IPv4-only to work around issues. Some specific thoughts: * Would it make sense to change away from the "MUST" implement and instead require all modes to be used only with configuration by the network operator? (Having that configuration include an allowlist of IP(v4) prefixes which are candidates for the optimization may further help.) This at least allows this to get disabled in cases where it causing problems while still letting network operators use it for content they want to optimize in coordination with CDN partners. Using this with off-the-shelf CPEs seems dangerous as bugs there can have high damage risk to IPv6 content deployment without a good path to fix. * I don't see a mention about risks of clients ignoring TTL yet? Maybe I missed it or maybe this is next version? Keeping entries in a stale state for some time past their TTL expiry helps. * We should add the security risk discussed previously to Security Considerations. (ie, clients/apps ignoring DNS TTL can still be hijacked to other IPs even without DNS spoofing if an app with the same MAC (same device or behind a NAT/router) does a DNS lookup to an attacker-controlled hostname.) * It would be good to mention that some consumer electronics ship with alternate resolvers configured (eg, Chromecast). * It would be good to clarify that even if a hostname is IPv4-only (ie, AAAA returns a DNS64-synthesized address) that the entry must still be marked invalid if the A record matches but the FQDN mismatches. (Maybe I missed this in there?) On Tue, Jul 28, 2020 at 10:24 AM JORDI PALET MARTINEZ wrote: > Hi all, > > Sorry, was a bit congested with other work last week to finish this > version. > > I'm still working in some of the previous emails, to make sure that this > version has addressed them. I will be responding ASAP. > > Regards, > Jordi > @jordipalet > > > > =EF=BB=BFEl 28/7/20 16:16, "v6ops-bounces@ietf.org en nombre de > internet-drafts@ietf.org" internet-drafts@ietf.org> escribi=C3=B3: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : 464XLAT/MAT-T Optimization > Authors : Jordi Palet Martinez > Alejandro D'Egidio > Filename : draft-ietf-v6ops-464xlat-optimization-03.txt > Pages : 24 > Date : 2020-07-28 > > Abstract: > IP/ICMP Translation Algorithm (SIIT) can be used to provide access > for IPv4-only hosts or applications to IPv4-only or dual-stack > destinations over IPv6-only infrastructure. In that case, the > traffic flows are translated twice: first from IPv4 to IPv6 > (stateless NAT46 at the ingress point to the IPv6-only > infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, a= t > the egress point). When the destination is IPv6-enabled, the seco= nd > translation might be avoided. This document describes a possible > optimization to 464XLAT and MAP-T to avoid translating IPv6 flows > back to IPv4 if the destination is reachable over IPv6. The > proposed > solution would significantly reduce the NAT64 utilization in the > operator's network, increasing the performance. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimizati= on-03 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimization= -03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000f3059505abad01df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This version improves, but still seems to be missing some import= ant items.
I'm also still worried that it may not be safe enough and may= still cause
more problems than it solves, especially if implementations are= buggy.
(Buggy implementations in CPEs will be really hard to debug or trace= back
for people outside the network, will be hard/impossible to get fixed,= =C2=A0 and will
result in dual-stack content getting switched to IPv4-only t= o work around issues.

Some specific thoughts:

* Would it make sen= se to change away from the "MUST" implement
=C2=A0 and instead req= uire all modes to be used only with configuration by
=C2=A0 the network oper= ator?=C2=A0 (Having that configuration include an allowlist
=C2=A0 of I= P(v4) prefixes which are candidates for the optimization may further help.)=
= =C2=A0 This at least allows this to get disabled in cases where it causing = problems
=C2=A0 while still letting network operators use it for content the= y want to optimize
=C2=A0 in coordination with CDN partners.=C2=A0 Using thi= s with off-the-shelf CPEs seems
=C2=A0 dangerous as bugs there can have high= damage risk to IPv6 content deployment
=C2=A0 without a good path to fix.

* I don't see a mention about risks of clients ignoring TTL yet?= =C2=A0 Maybe I missed
=C2=A0 it or maybe this is next version?=C2=A0 Keeping= entries in a stale state for some time
=C2=A0 past their TTL expiry helps.<= br>

* We should add the security risk discussed previously to Security C= onsiderations.
=C2=A0 (ie, clients/apps ignoring DNS TTL can still be hijack= ed to other IPs even without
=C2=A0 DNS spoofing if an app with the same MAC= (same device or behind a NAT/router)=C2=A0
=C2=A0 does a DNS lookup to= an attacker-controlled hostname.) =C2=A0

* It would be good to men= tion that some consumer electronics ship with
=C2=A0 alternate resolvers con= figured (eg, Chromecast).

* It would be good to clarify that even if a h= ostname is IPv4-only (ie, AAAA returns
=C2=A0 a DNS64-synthesized address) t= hat the entry must still be marked=C2=A0
=C2=A0 invalid if the A record= matches but the FQDN mismatches.
=C2=A0 (Maybe I missed this in there?)=
=








=C2=A0=C2=A0 =C2=A0
=C2=A0

=
=


On Tue, Jul 28, 2020 at 10:24 AM JORDI PALET MARTINEZ <j= ordi.palet=3D40consulint= el.es@dmarc.ietf.org> wrote:
Hi all,

Sorry, was a bit congested with other work last week to finish this version= .

I'm still working in some of the previous emails, to make sure that thi= s version has addressed them. I will be responding ASAP.

Regards,
Jordi
@jordipalet



=EF=BB=BFEl 28/7/20 16:16, "v6ops-bounces@ietf.org en nombre de internet-drafts@ietf.org&q= uot; <v6ops-= bounces@ietf.org en nombre de internet-drafts@ietf.org> escribi=C3=B3:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 464XLAT/MAT-T Optimization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Jordi Palet Martinez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alejandro D'Egidio
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-464xlat-optimization-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 24
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-07-28

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0IP/ICMP Translation Algorithm (SIIT) can be used= to provide access
=C2=A0 =C2=A0 =C2=A0 =C2=A0for IPv4-only hosts or applications to IPv4-only= or dual-stack
=C2=A0 =C2=A0 =C2=A0 =C2=A0destinations over IPv6-only infrastructure.=C2= =A0 In that case, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0traffic flows are translated twice: first from I= Pv4 to IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0(stateless NAT46 at the ingress point to the IPv= 6-only
=C2=A0 =C2=A0 =C2=A0 =C2=A0infrastructure) and then from IPv6 back to IPv4 = (stateful NAT64, at
=C2=A0 =C2=A0 =C2=A0 =C2=A0the egress point).=C2=A0 When the destination is= IPv6-enabled, the second
=C2=A0 =C2=A0 =C2=A0 =C2=A0translation might be avoided.=C2=A0 This documen= t describes a possible
=C2=A0 =C2=A0 =C2=A0 =C2=A0optimization to 464XLAT and MAP-T to avoid trans= lating IPv6 flows
=C2=A0 =C2=A0 =C2=A0 =C2=A0back to IPv4 if the destination is reachable ove= r IPv6.=C2=A0 The proposed
=C2=A0 =C2=A0 =C2=A0 =C2=A0solution would significantly reduce the NAT64 ut= ilization in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0operator's network, increasing the performan= ce.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://datatra= cker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://tools.ietf= .org/html/draft-ietf-v6ops-464xlat-optimization-03
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03<= br>
=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 https://ww= w.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-optimization-03


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

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


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6o= ps



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000f3059505abad01df-- From nobody Thu Jul 30 14:23:30 2020 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 899813A0D0A; Thu, 30 Jul 2020 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am7rJ2z_2SwG; Thu, 30 Jul 2020 14:23:25 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5BA3A0D01; Thu, 30 Jul 2020 14:23:25 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id v6so10410610ota.13; Thu, 30 Jul 2020 14:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bRSxF+uV0UPmIpkj4gcOjNIYqfK7PqCYocB+AFoUYeE=; b=PrCZxRs1ED8poaOrpw1sEpGFKP2FJcM6KzjezD8gum1llzEIDD5LKh2+qNAOv7U+yd gqPw+SRaoAzK0WZlqiVzRprHeR1Uo/JV98hH8T/SFdxZpK12Jsjl6G8di+JD8Gt0F/rn ZThjKTF9nIRkxtUMaTmBpWQ+QPAOBumbKUFPYFpZuwt9+5dGEqp8xKjaLPg/SX8WtxiH doEmaiEABkuMYaNtn6A6vTH+8/h8bfh/X8uoLEL4lwveAQe6X4CEfUAZBBMjMib4StDF NqfKrGf1OfL4YMWDkCW/XP19CdU/nbC0ORfYfu5lC2SqljL8kfsQpD7lwGqsrivJIapH yolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bRSxF+uV0UPmIpkj4gcOjNIYqfK7PqCYocB+AFoUYeE=; b=dteaD3ckbYpApgbiCPPdROg/o+BZIa5o8Q+aPmaJSIwuvTOrYO9/Ovi4O+lHb9lvnG X+ZWBVd+e11XhYzXQIUbcn3Wpkgz8/hx3BRZQq4wE6nzyEMhvYytEMlekf6r9i0bL6mR 2KzgfxC0kOp6b8VCsxK3VsupGaKIZG27Ar+dWGBMCVWSRxAXJXMNEOygu3kZ1EDt/G8y AgrX2ri78SXSAljPVC4URjV2TiSWsz6vg100zwTukoDrX3a0QVgCRZNFD0pds5DbMCxg vbAYwXbYiYyf9Y/hqiqVBo9I2q6jnU299SbRBdUKtmTHEMnnDEuL4UMFAvVhr3PaWhfB C/jQ== X-Gm-Message-State: AOAM533TPIzWrAovVNKkTOy3MFo4lTqyXAxvCH4d1FDHUcXgxHdaIP7F rWMJOHrlULF4k9nVGxnvJt9EgRz6RacOXoDRpq8= X-Google-Smtp-Source: ABdhPJwubCl++VuZdisrUYa+Jp+QPIpK/7fSGXSTEcmk/3kCDylJ4YgKHkgUdS7qoYq0LLke+UXWI9UUK9kySILrPCY= X-Received: by 2002:a9d:2661:: with SMTP id a88mr532702otb.74.1596144204510; Thu, 30 Jul 2020 14:23:24 -0700 (PDT) MIME-Version: 1.0 References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> In-Reply-To: From: Mark Smith Date: Fri, 31 Jul 2020 07:23:12 +1000 Message-ID: To: Vasilenko Eduard Cc: Jen Linkova , v6ops list , 6man Content-Type: multipart/alternative; boundary="00000000000051facf05abaf4847" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 21:23:29 -0000 --00000000000051facf05abaf4847 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 31 Jul 2020, 04:35 Vasilenko Eduard, wrote: > Hi Jen, > OK. IPv6 SLAAC subnet is not secure in principle and we should abandon an= y > attempt to improve it. GRAND's goal is not and has never been to improve the security of ND. There is no statement such as "The goal of GRAND is to improve the security of ND." This draft describes the problem space. https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/ There are some useful security benefits of the way it will prepopulate routers' ND caches with nodes' new addresses. However, if none of those benefits existed, it wouldn't invalidate GRAND as a solution to the problem GTAND is designed to solve. Making the primary criticism of GRAND being about ND security is like criticising a spoon for being a terrible knife. Regards, Mark. Because so many people already spent so much time on this matter - it is > just does not make sense to talk again and again. > And the primary solution that they found is the stateful "binding table" > on the switch to monitor all NDs (like DHCP/ARP in IPv4), that not many u= se > anyway - we need to fix unsecure solution. > > Then your dilemma is not important, 7sec traffic hijacking could not > happen unintentionally - probability for address collision on /64 is too > low, whatever Interface IDs would be used (collection of RFCs exist). > Eduard > -----Original Message----- > From: Jen Linkova [mailto:furry13@gmail.com] > Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 12:58 > To: Vasilenko Eduard > Cc: 6man ; v6ops@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security > concerns > > On Thu, Jul 30, 2020 at 6:05 PM Vasilenko Eduard < > vasilenko.eduard@huawei.com> wrote: > > Then it is not logical for me: > > Many people understand that "Unsolicited NA" is a big security hole > > per se, But instead of fixing it (may be even deprecate - should be > > investigated) > > There are many attacks possible within the same L2 segment. It's not new. > That's why you shall either block p2p with the LAN (if you do not trust > endpoints in general) or - better - hosts shall use end2end encryption. > > > Additional functionality is building on top of it. > > Sorry, I'm not sure I understand why unsolicited NA is the problem here. > The mechanism I described in my previous email is using > *solicited* NA to override the neighbor cache on the router. > > > It would additionally challenge this security problem resolution in the > future! > > > > Again: "Unsolicited NA" with Override bit set - is a disaster now. > > As well as Solicited, right? ;) Shall we look at SEND again? ;) It would > be great but I'm not aware of implementations being widely deployed. > > > IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for > the case of MAC address change on legitimate host. > > May be we could think about other solutions. > > But if additional functionality would be built on top of "Unsolicited > NA" - less options would be available ("deprecate" would be not a choice > anymore). > > > > If something is ill - it should be cured first - bodybuilding make sens= e > only after this. > > > > Jen, I have not understood below why you did mention RA Guard. Intruder > does not need it. He just claim (by Unsolicited NA) that his MAC is > connected to GUA of victim. > > Yes, to intercept traffic *to* the victim. How is it going to intercept > packets sent by the victim? > > > Intruder could claim it every 5 seconds to keep cache in STALE state > (for the case of very careful vendor implementation of ND). > > As you mentioned - no help from MLD snooping on switches - it would be > enough to just listen to DAD. Switch could not help in principle. > > Strictly speaking, if the switching infrastructure implements MLD > snooping, the attacker would need either to guess the lower 24 bits of th= e > victim's address or to join 2^24 solicited node multicast address groups. > > > The first modified DNS response would convert traffic flow to > bi-directional for Intruder. > > That's why DNSSEC and DNS over TLS and HTTPS are good for security. > > > -----Original Message----- > > From: Jen Linkova [mailto:furry13@gmail.com] > > Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07 > > To: Vasilenko Eduard > > Cc: 6man ; v6ops@ietf.org > > Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional > > security concerns > > > > On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard < > vasilenko.eduard@huawei.com> wrote: > > > You did ask a feedback yesterday about severity of 7sec security hole > that has very low probability. > > > I have intention here to show that probability is 100%, 7sec could be > prolonged to forever, and the final result is the full interception of > innocent host traffic by intruder (successful "man-in-the-middle"). > > > > > > Pre-request for success: > > > - no multicast snooping (MLD) and filtering on a switch, that is > > > perfectly possible > > > - Intruder should be already on the same subnet (gained control over > > > other host by exploiting of different vulnerability) > > > - intruder should suppress DAD on Intruder's controlled host (is > > > Windows firewall capable to filter out DAD?) > > > - We assume that we are talking about the future when this draft is > > > used by majority of nodes (victim should use it) > > > > > > Procedure: > > > Intruder's controlled host does listen to all-routers multicast > address (ff02::2). > > > As soon as it would eavesdrop unsolicited NA from victim node > (probably after boot) - Intruder would immediately (a few milliseconds) > duplicate NA in router's direction, but with 2 changes: (1) his LLA (MAC)= ; > (2) Override bit set. > > > Intruder has time only up to the point that response to victim's > traffic would be returned from the Internet (from tens of milliseconds to > many seconds if victim would not start sending immediately), - but it is > enough time: local communication should be faster. > > > Theoretically, RetransTimer should be imposed on unsolicited NA > (section 7.2.6), but low chances that this timer is checked on receiving > side (router), because RetransTimer is specified for transmission side. > > > According RFC 4681 section 7.2.5 clause II: O bit set should not just > rewrite ND cache, but additionally mark ND record as REACHABLE. According > to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to > either zero or one". Despite it contradicts to the logic of the whole RFC > 4681 (O bit should not be set in unsolicited NA - it is mentioned in a fe= w > places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly > permit to use Override flag - higher probability that particular > implementation would not just rewrite LLA on router, but additionally put > it into REACHABLE. > > > Intruder could be sure that at least STALE state would be created > according to section 7.2.5 clause I, - this ND record would be against hi= s > LLA anyway. > > > After receiving return traffic (if it was created as STALE, not > REACHABLE) - router would ask intruder about reachability (solicited NS-N= A) > - intruder would confirm his LLA - it would finally put ND cache record > into REACHABLE. > > > > 1) the 7 seconds corner case was for 'preventing address collision for > Optimistic DAD', not for any intentional attacks case. Because: > > 2) What you are describing could be done today, now, anytime w/o the > changes described in the draft. If there is no MLD snooping then the > intruder would see the DAD packet from the victim, so it would know the > victim address anyway - no reason even to join ff02::2. Now all the > attacker needs to do is to keep sending NA with S=3D1, O=3D1 - hoping tha= t when > the first packet of the return flows arrive and the router creates an > INCOMPLETE entry and sends an NS, the attacker's packet would come before > the victim's NA. Done, the entry is changed to REACHABLE, all traffic go= es > to the attacker. > > Actually even simpler. The attacker does not need to deal with timing. > > Let's say the router has an NC entry for the victim address in any othe= r > state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, Target > address =3D the victim's IPv6 address, the TLLA =3D the attacker MAC addr= ess. > Done. The router updates the cache entry and changes it to REACHABLE stat= e. > > > > There is nothing new here. We have the same issue with ARP - the > attacker can override ARP entry on the router. > > > > > That's it: upstream traffic of victim host is going to router, traffi= c > back is going through Intruder. > > > I have consulted with penetration tests professional (these are peopl= e > with the same qualification as hackers but they play on legal side): what > he would be doing next? He said that he would return traffic to legitimat= e > host - victim should not see performance degradation. He would collect > cookies and some other valuable information. He would finally see DNS > response, change it and redirect everything to himself on the permanent > basis - he does want to see both directions of victim exchange. He has > qualified Man-in-the-middle as full fiasco - it does open many > opportunities for him. He has mentioned very good feature of this draft > that there is no any interruption for victim's traffic flow, no any > excessive traffic to victim, that is very rear benefit for hacker's tool. > > > > For all that doom and gloom the attacker would also need to see the > traffic *from* the victim. Assuming the network has RA Guard in place it > would be a bit harder. If the network does not have RA Guard our poor > victim has much bigger problems already. > > > > > What to do about it? > > > 1. Potentially it is possible to do RPF-like check for Source LLA > addresses. Upstream traffic from victim's SLLA would not be in ND cache - > such traffic could be discarded. It is better to block communication than > permit intruder to exploit vulnerability. > > > > > 2. Increase RetransTimer and ask receiver side (router) to check on > sending side delay between ND record override (for the same SLLA). But ho= w > long should be the timer? Host could wait a lo-o-o-ng time before it woul= d > request 1st information from internet. It would decrease probability, but > would not completely eliminate attack vector. > > > > > > My proposition for this draft is disruptive: > > > I believe that ND is very complicated (some could say "fragile") - it > is better not to touch it. > > > Additionally I do not like to wait till all hosts would refresh to ne= w > draft (to get new functionality). > > > > Well, only hosts which want to connect to the network faster need to > implement this. So host OS developers have pretty good incentive here. > > Please keep in mind that the proposed behavior is not currently > prohibited. We are not changing any MUST NOT to anything else. All we are > doing is to making some recommendations more explicit. > > > > > I propose to change only router behavior: check Source LLA (MAC) for > every packet, if this SLLA is absent in ND cache - then request solicited > NS-NA immediately. It would probably resolve faster than traffic would > return from the internet. > > > > Have you checked the problem statement draft? > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-0 > > 3#section-3.7 > > specificatlly? > > What you are proposing does make sense, however it would not help in > case of multiple routers. Also I recall some people having strong opinion= s > on performance implications. > > > > > Effectively I do proposed the same SLLA RPF that is needed to fix > current solution, but: > > > - without any modification to host OSes > > > - without any modification of standard (it is local recommendation > > > for router, NS-NA is exactly the same from RFC 4681, NA is unicast - > > > it is important for security) > > > - without any risk to break ND fragile algorithm > > > - it could be optional, or even configurable on the router as "value > > > add feature" in competitive tender Because it is just best practice > recommendation - may be it make sense to move it to "v6ops"? > > > > See > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-0 > > 3 > > > > > PS: Looking to the above - unsolicited NA should be really delayed by > additional big timer (not by RetransTimer that is used for solicited NS/N= A) > and checked on receiver side - this modification of standard is really > needed to close Unsolicited NA vulnerability. > > > Somebody said on the call that it is already a feature of some OS > (Android?) - it is bad: it means that this OS is already vulnerable. > > > > I was saying that some routing platforms have this already implemented. > Search for 'glean' here: > > https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configura > > tion/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html > > > > AFAIK there are implementations which are also prepopulating NC from DA= D > packets but I can not find you a reference right now. > > > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > > > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49 > > > To: 6man > > > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt > > > > > > Hello, > > > > > > The -01 version addresses comments received (thanks everyone who > provided feedback). Also, Section 3 (Avoiding Disruption) has been expand= ed > and discussed a corner case when two devices start using the same address > almost at the same time (the second device configures an optimistic addre= ss > after the rightful owner sent some packets but before the return traffic > arrives). > > > Feedback on the updated section 3.3 > > > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is > very much appreciated. > > > > > > On Sun, Jul 26, 2020 at 10:14 AM wrote: > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > > > > > > > Title : Gratuitous Neighbor Discovery: Creating > Neighbor Cache Entries on First-Hop Routers > > > > Author : Jen Linkova > > > > Filename : draft-ietf-6man-grand-01.txt > > > > Pages : 12 > > > > Date : 2020-07-25 > > > > > > > > Abstract: > > > > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine > the > > > > link-layer addresses of neighboring nodes as well as to discover > and > > > > maintain reachability information. This document updates RFC486= 1 > to > > > > allow routers to proactively create a Neighbor Cache entry when = a > new > > > > IPv6 address is assigned to a node. It also updates RFC4861 and > > > > recommends nodes to send unsolicited Neighbor Advertisements upo= n > > > > assigning a new IPv6 address. The proposed change will minimize > the > > > > delay and packet loss when a node initiate connections to off-li= nk > > > > destination from a new IPv6 address. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-6man-grand-01 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- IETF IPv6 working group mailing list ipv6@ietf.org > > > > Administrative > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > ------------------------------------------------------------------ > > > > -- > > > > > > > > > > > > -- > > > SY, Jen Linkova aka Furry > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > -- > SY, Jen Linkova aka Furry > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000051facf05abaf4847 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 31 Jul 2020, 04:35 Vasilenko Eduard, <vasilenko.eduard@huawei.com> wrote:
Hi Jen,
OK. IPv6 SLAAC subnet is not secure in principle and we should abandon any = attempt to improve it.

=
GRAND's goal is not and has never been to improve the= security of ND. There is no statement such as "The goal of GRAND is t= o improve the security of ND."

This draft describes the problem space.
=

There are some useful security benefits of the way it will prepopulate = routers' ND caches with nodes' new addresses. However, if none of t= hose benefits existed, it wouldn't invalidate GRAND as a solution to th= e problem GTAND is designed to solve.

Making the primary criticism of GRAND being about ND security= is like criticising a spoon for being a terrible knife.

Regards,
Mark.


=
Because so many people already spent so much time on this matte= r - it is just does not make sense to talk again and again.
And the primary solution that they found is the stateful "binding tabl= e" on the switch to monitor all NDs (like DHCP/ARP in IPv4), that not = many use anyway - we need to fix unsecure solution.

Then your dilemma is not important, 7sec traffic hijacking could not happen= unintentionally - probability for address collision on /64 is too low, wha= tever Interface IDs would be used (collection of RFCs exist).
Eduard
-----Original Message-----
From: Jen Linkova [mailto:furry13@gmail.com]
Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 12:58
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: 6man <ipv6@ietf.org>; v6ops@ietf.org
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security con= cerns

On Thu, Jul 30, 2020 at 6:05 PM Vasilenko Eduard <va= silenko.eduard@huawei.com> wrote:
> Then it is not logical for me:
> Many people understand that "Unsolicited NA" is a big securi= ty hole
> per se, But instead of fixing it (may be even deprecate - should be > investigated)

There are many attacks possible within the same L2 segment. It's not ne= w. That's why you shall either block p2p with the LAN (if you do not tr= ust endpoints in general) or - better - hosts shall use end2end encryption.=

> Additional functionality is building on top of it.

Sorry, I'm not sure I understand why unsolicited NA is the problem here= . The mechanism I described in my previous email is using
*solicited* NA to override the neighbor cache on the router.

> It would additionally challenge this security problem resolution in th= e future!
>
> Again: "Unsolicited NA" with Override bit set - is a disaste= r now.

As well as Solicited, right? ;) Shall we look at SEND again? ;) It would be= great but I'm not aware of implementations being widely deployed.

> IMHO: it is better to prohibit "Unsolicited NA". Let's w= ait timers for the case of MAC address change on legitimate host.
> May be we could think about other solutions.
> But if additional functionality would be built on top of "Unsolic= ited NA" - less options would be available ("deprecate" woul= d be not a choice anymore).
>
> If something is ill - it should be cured first - bodybuilding make sen= se only after this.
>
> Jen, I have not understood below why you did mention RA Guard. Intrude= r does not need it. He just claim (by Unsolicited NA) that his MAC is conne= cted to GUA of victim.

Yes, to intercept traffic *to* the victim. How is it going to intercept pac= kets sent by the victim?

> Intruder could claim it every 5 seconds to keep cache in STALE state (= for the case of very careful vendor implementation of ND).
> As you mentioned - no help from MLD snooping on switches - it would be= enough to just listen to DAD. Switch could not help in principle.

Strictly speaking, if the switching infrastructure implements MLD snooping,= the attacker would need either to guess the lower 24 bits of the victim= 9;s address or to join 2^24 solicited node multicast address groups.

> The first modified DNS response would convert traffic flow to bi-direc= tional for Intruder.

That's why DNSSEC and DNS over TLS and HTTPS are good for security.

> -----Original Message-----
> From: Jen Linkova [mailto:furry13@gmail.com]
> Sent: 30 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 5:07
> To: Vasilenko Eduard <vasilenko.eduard@huawei.c= om>
> Cc: 6man <ipv6@ietf.org>; v6ops@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional
> security concerns
>
> On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
> > You did ask a feedback yesterday about severity of 7sec security = hole that has very low probability.
> > I have intention here to show that probability is 100%, 7sec coul= d be prolonged to forever, and the final result is the full interception of= innocent host traffic by intruder (successful "man-in-the-middle"= ;).
> >
> > Pre-request for success:
> > - no multicast snooping (MLD) and filtering on a switch, that is =
> > perfectly possible
> > - Intruder should be already on the same subnet (gained control o= ver
> > other host by exploiting of different vulnerability)
> > - intruder should suppress DAD on Intruder's controlled host = (is
> > Windows firewall capable to filter out DAD?)
> > - We assume that we are talking about the future when this draft = is
> > used by majority of nodes (victim should use it)
> >
> > Procedure:
> > Intruder's controlled host does listen to all-routers multica= st address (ff02::2).
> > As soon as it would eavesdrop unsolicited NA from victim node (pr= obably after boot) - Intruder would immediately (a few milliseconds) duplic= ate NA in router's direction, but with 2 changes: (1) his LLA (MAC); (2= ) Override bit set.
> > Intruder has time only up to the point that response to victim= 9;s traffic would be returned from the Internet (from tens of milliseconds = to many seconds if victim would not start sending immediately), - but it is= enough time: local communication should be faster.
> > Theoretically, RetransTimer should be imposed on unsolicited NA (= section 7.2.6), but low chances that this timer is checked on receiving sid= e (router), because RetransTimer is specified for transmission side.
> > According RFC 4681 section 7.2.5 clause II: O bit set should not = just rewrite ND cache, but additionally mark ND record as REACHABLE. Accord= ing to section 7.2.6: " The Override flag (for unsolicited NA) MAY be = set to either zero or one". Despite it contradicts to the logic of the= whole RFC 4681 (O bit should not be set in unsolicited NA - it is mentione= d in a few places of RFC 4681). But because section 7.2.5 and section 7.2.6= clearly permit to use Override flag - higher probability that particular i= mplementation would not just rewrite LLA on router, but additionally put it= into REACHABLE.
> > Intruder could be sure that at least STALE state would be created= according to section 7.2.5 clause I, - this ND record would be against his= LLA anyway.
> > After receiving return traffic (if it was created as STALE, not R= EACHABLE) - router would ask intruder about reachability (solicited NS-NA) = - intruder would confirm his LLA - it would finally put ND cache record int= o REACHABLE.
>
> 1) the 7 seconds corner case was for 'preventing address collision= for Optimistic DAD', not for any intentional attacks case. Because: > 2) What you are describing could be done today, now, anytime w/o the c= hanges described in the draft. If there is no MLD snooping then the intrude= r would see the DAD packet from the victim, so it would know the victim add= ress anyway=C2=A0 - no reason even to join ff02::2. Now all the attacker ne= eds to do is to keep sending NA with S=3D1, O=3D1 - hoping that when the fi= rst packet of the return flows arrive and the router creates an INCOMPLETE = entry and sends an NS, the attacker's packet would come before the vict= im's NA. Done, the=C2=A0 entry is changed to REACHABLE, all traffic goe= s to the attacker.
> Actually even simpler. The attacker does not need to deal with timing.=
> Let's say the router has an NC entry for the victim address in any= other state than INCOMPLETE. The attacker sends an NA with S=3D1, O=3D1, T= arget address =3D the victim's IPv6 address, the TLLA =3D the attacker = MAC address.=C2=A0 Done. The router updates the cache entry and changes it = to REACHABLE state.
>
> There is nothing new here. We have the same issue with ARP - the attac= ker can override ARP entry on the router.
>
> > That's it: upstream traffic of victim host is going to router= , traffic back is going through Intruder.
> > I have consulted with penetration tests professional (these are p= eople with the same qualification as hackers but they play on legal side): = what he would be doing next? He said that he would return traffic to legiti= mate host - victim should not see performance degradation. He would collect= cookies and some other valuable information. He would finally see DNS resp= onse, change it and redirect everything to himself on the permanent basis -= he does want to see both directions of victim exchange. He has qualified M= an-in-the-middle as full fiasco - it does open many opportunities for him. = He has mentioned very good feature of this draft that there is no any inter= ruption for victim's traffic flow, no any excessive traffic to victim, = that is very rear benefit for hacker's tool.
>
> For all that doom and gloom the attacker would also need to see the tr= affic *from* the victim. Assuming the network has RA Guard in place it woul= d be a bit harder. If the network does not have RA Guard our poor victim ha= s much bigger problems already.
>
> > What to do about it?
> > 1. Potentially it is possible to do RPF-like check for Source LLA= addresses. Upstream traffic from victim's SLLA would not be in ND cach= e - such traffic could be discarded. It is better to block communication th= an permit intruder to exploit vulnerability.
>
> > 2. Increase RetransTimer and ask receiver side (router) to check = on sending side delay between ND record override (for the same SLLA). But h= ow long should be the timer? Host could wait a lo-o-o-ng time before it wou= ld request 1st information from internet. It would decrease probability, bu= t would not completely eliminate attack vector.
> >
> > My proposition for this draft is disruptive:
> > I believe that ND is very complicated (some could say "fragi= le") - it is better not to touch it.
> > Additionally I do not like to wait till all hosts would refresh t= o new draft (to get new functionality).
>
> Well, only hosts which want to connect to the network faster need to i= mplement this. So host OS developers have pretty good incentive here.
> Please keep in mind that the proposed behavior is not currently prohib= ited. We are not changing any MUST NOT to anything else. All we are doing i= s to making some recommendations more explicit.
>
> > I propose to change only router behavior: check Source LLA (MAC) = for every packet, if this SLLA is absent in ND cache - then request solicit= ed NS-NA immediately. It would probably resolve faster than traffic would r= eturn from the internet.
>
> Have you checked the problem statement draft?
> htt= ps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-0
> 3#section-3.7
> specificatlly?
> What you are proposing does make sense, however it would not help in c= ase of multiple routers. Also I recall some people having strong opinions o= n performance implications.
>
> > Effectively I do proposed the same SLLA RPF that is needed to fix= current solution, but:
> > - without any modification to host OSes
> > - without any modification of standard (it is local recommendatio= n
> > for router, NS-NA is exactly the same from RFC 4681, NA is unicas= t -
> > it is important for security)
> > - without any risk to break ND fragile algorithm
> > - it could be optional, or even configurable on the router as &qu= ot;value
> > add feature" in competitive tender Because it is just best p= ractice recommendation - may be it make sense to move it to "v6ops&quo= t;?
>
> See
> htt= ps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-0
> 3
>
> > PS: Looking to the above - unsolicited NA should be really delaye= d by additional big timer (not by RetransTimer that is used for solicited N= S/NA) and checked on receiver side - this modification of standard is reall= y needed to close Unsolicited NA vulnerability.
> > Somebody said on the call that it is already a feature of some OS= (Android?) - it is bad: it means that this OS is already vulnerable.
>
> I was saying that some routing platforms have this already implemented= . Search for 'glean' here:
> htt= ps://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configura
> tion/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html
>
> AFAIK there are implementations which are also prepopulating NC from D= AD packets but I can not find you a reference right now.
>
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On = Behalf Of Jen Linkova
> > Sent: 27 =D0=B8=D1=8E=D0=BB=D1=8F 2020 =D0=B3. 7:49
> > To: 6man <ipv6@ietf.org>
> > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt
> >
> > Hello,
> >
> > The -01 version addresses comments received (thanks everyone who = provided feedback). Also, Section 3 (Avoiding Disruption) has been expanded= and discussed a corner case when two devices start using the same address = almost at the same time (the second device configures an optimistic address= after the rightful owner sent some packets but before the return traffic a= rrives).
> > Feedback on the updated section 3.3
> > (htt= ps://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is very = much appreciated.
> >
> > On Sun, Jul 26, 2020 at 10:14 AM <internet-dr= afts@ietf.org> wrote:
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-= Drafts directories.
> > > This draft is a work item of the IPv6 Maintenance WG of the = IETF.
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: Gratuitous Neighbor Discovery: Creating Neighbor Cach= e Entries on First-Hop Routers
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : Jen Linkova
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2= =A0 =C2=A0 : draft-ietf-6man-grand-01.txt
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: 12
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : 2020-07-25
> > >
> > > Abstract:
> > >=C2=A0 =C2=A0 Neighbor Discovery (RFC4861) is used by IPv6 no= des to determine the
> > >=C2=A0 =C2=A0 link-layer addresses of neighboring nodes as we= ll as to discover and
> > >=C2=A0 =C2=A0 maintain reachability information.=C2=A0 This d= ocument updates RFC4861 to
> > >=C2=A0 =C2=A0 allow routers to proactively create a Neighbor = Cache entry when a new
> > >=C2=A0 =C2=A0 IPv6 address is assigned to a node.=C2=A0 It al= so updates RFC4861 and
> > >=C2=A0 =C2=A0 recommends nodes to send unsolicited Neighbor A= dvertisements upon
> > >=C2=A0 =C2=A0 assigning a new IPv6 address.=C2=A0 The propose= d change will minimize the
> > >=C2=A0 =C2=A0 delay and packet loss when a node initiate conn= ections to off-link
> > >=C2=A0 =C2=A0 destination from a new IPv6 address.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://= datatracker.ietf.org/doc/draft-ietf-6man-grand/
> > >
> > > There are also htmlized versions available at:
> > > https://too= ls.ietf.org/html/draft-ietf-6man-grand-01
> > > h= ttps://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01
> > >
> > > A diff from the previous version is available at:
> > > htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-grand-01
> > >
> > >
> > > Please note that it may take a couple of minutes from the ti= me of
> > > submission until the htmlized version and diff are available= at tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-= drafts/
> > >
> > >
> > > ------------------------------------------------------------= ------
> > > -- IETF IPv6 working group mailing list ipv6@ietf.org<= /a>
> > > Administrative
> > > Requests: https://www= .ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= ------
> > > --
> >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > -----------------------------------------------------------------= ---
> > IETF IPv6 working group mailing list ipv6@ietf.org Admi= nistrative
> > Requests: https://www.ietf= .org/mailman/listinfo/ipv6
> > -----------------------------------------------------------------= ---
>
>
>
> --
> SY, Jen Linkova aka Furry



--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--00000000000051facf05abaf4847-- From nobody Thu Jul 30 15:26:38 2020 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 18D313A0A8F; Thu, 30 Jul 2020 15:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VrTGR+D0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mCmtZZRP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh_W14RGK80q; Thu, 30 Jul 2020 15:26:27 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E29D3A0A88; Thu, 30 Jul 2020 15:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60311; q=dns/txt; s=iport; t=1596147987; x=1597357587; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7agFTpbFp/Tn4sUp9jwk75tIkjUz8pFFD/pV159Rzfk=; b=VrTGR+D0AOB11oL6AqT+ZC/omdPVr1gbu8SHawXdXlENI8zff12Ihs/J 6hqd1GZgXXxDvtVmzbkNLptXlsjUu3x4hluRyWemV6HBm0jhix6JUauYm p/0HBaMXWeJflrL85CjPPmKoeldrt2KuGSkcfP9+KZtpa0BY2w5YNqXQU k=; IronPort-PHdr: =?us-ascii?q?9a23=3AdqPDeh/M4CFICP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfBwAvSCNf/51dJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoFSKSgHb1gvLIQ1g0YDjSolgQKJAY5fgUKBEQNQBQsBAQE?= =?us-ascii?q?MAQEYAQoKAgQBAYMXgTUCF4IXAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQE?= =?us-ascii?q?BAQECAQEBEAgBCB0BASoCCwEEBwQCAQYCEQQBAQEgAQYDAgICHwYLFAMBBQg?= =?us-ascii?q?CBA4FGweDBAGBfk0DDiABDpRjkGgCgTmIYXaBMoMBAQEFgTMBAwIOQYMVDQu?= =?us-ascii?q?CDgmBOIJvglISOUKBAYJzgksagUE/gRABJwwQgU9JNT6CGkIBAQIBARWBCAk?= =?us-ascii?q?BEgFHBxGCWDOCLY9ZIg4BAoJmhl2LVpAYTgqCX4hbhW+GPIR5Ax6Ce4EiiCm?= =?us-ascii?q?BKJIGhU+XA4JhjWaEJQIEAgQFAg4BAQWBQCojZ3BwFRohKgGCPglHFwINV40?= =?us-ascii?q?lIwwXgQIBAoJJhRSFQnQCNQIGAQcBAQMJfI9ZAQE?= X-IronPort-AV: E=Sophos;i="5.75,415,1589241600"; d="scan'208,217";a="520158353" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2020 22:26:25 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 06UMQP7Q012285 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2020 22:26:25 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 17:26:24 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 18:26:23 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 30 Jul 2020 17:26:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k7df0QpFd06BcqTkpjZuFtP36/+BCzsBMTOdLKR4UdupwfcvTeOl3kBlMxWRsRXnFwN0QfkLMtesMGPUq0zLRdstPrE/T+8YZuORpVS1zVcUKY/3a4kqpRHmD/kudTWZSp9BxbsfIYWCsQWHJ1DC0fq2ofRVwInudxOr/IujUp9KerUOJA1OIkV5XpYFVHoA/1c1S3Ft0VO8lTOZd/q0t4I2gRtuSWS825AvdjslFc2hvEcxvDEjBe/eDjPRSkAUrrjSQ6cUIb8Saqlx/BRWaMQiDo7cwfhfCy2Vlc/2qkMgAN247UZ6o0k7Rtg3dxZJheC/8s4/fjGV7TxRAHCtWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7agFTpbFp/Tn4sUp9jwk75tIkjUz8pFFD/pV159Rzfk=; b=AV7C2NS+xJzwQYQg+0GF46E9kt/jtF5L0UoV7iWjknXoWa6w5cObWp17f5ORMacf2xnsmjfB+xkfvsmPxXFAzljZWYWbYg1sGN8YeDCdl9DqNCOkzXj2UDUqwU6FG41eAdeWIy+MzCWinc74sfakgJTO81rd3IQ8wGzwWw7TliaAx1U079KRZW96htQnHHq0npXVT8nkwPcqx6Ht/aJFW9JGu2TgZ6AjiMsVJDvNN/2RAKqG6Qs+f9fLhNU0q1I8o8QSI8R5xCo6XMXU8shqBNtBCB8QrtmNSaMt4ILwvt+JHUVvaidUVCeehKbKHZE9MeiYs6aLnSdpzUNjiWl1wA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7agFTpbFp/Tn4sUp9jwk75tIkjUz8pFFD/pV159Rzfk=; b=mCmtZZRPJfMnf04hvHQ3v4Mhk96wYgUbSEAsuf9QU8d14mmU3bf/qOl5YSTNpg5EpruIEKz7SCWeRkeiJXDN0Q+37DTAOGuj9e2gjUsBpz1bF685BrX0Lw+5yo8IzANRleurGpQ3gqySDhF7Orbi5IPXoqTmoPcYnl+mpewlXxw= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (2603:10b6:a03:b3::11) by BYAPR11MB3446.namprd11.prod.outlook.com (2603:10b6:a03:1a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Thu, 30 Jul 2020 22:26:22 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e8eb:b823:20a3:94ac]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e8eb:b823:20a3:94ac%7]) with mapi id 15.20.3239.019; Thu, 30 Jul 2020 22:26:22 +0000 From: "Pascal Thubert (pthubert)" To: Mark Smith CC: Vasilenko Eduard , 6man , v6ops list Thread-Topic: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AQHWZkg+bCqL1AqpGEC9totP9gCMpakf412AgACQQgCAAC8SAIAAEaZd Date: Thu, 30 Jul 2020 22:26:21 +0000 Message-ID: <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:400a:4073:1505:4ef9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 242d4c7c-d0ab-4e79-4814-08d834d79689 x-ms-traffictypediagnostic: BYAPR11MB3446: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lzkHqiAYPeO942SZeaxFMz4NCeYjZesCGO+3BZbX0qwLbJuYfPP6u81n0lRvVBLM+2P0Jt7Yno0Ug8VczjhHHbdFsVVd+OAeiJp5uK/sH8NeKlKbkcTZR5KmNsh5SuunvdcboIAXwLMGhKcEdhkBW/EzkqzgXmzjLCMOzAxw7FGbDjv3l65ZB2I+h3pwMClyXyg60hERodGLLZSD0tywQcbXcXlLJLp9NiLRLWlh270vMQ+35/CpQvehuqhw0ja0S3e8u4Gv2qqE/K9E2wEyNHShuwAohIQGK5AFcan/S4kL38Ptj01DM5ZreTMXXAjFFblJczs4lPU18Wq+L99w3Ak0NX3H23DvsDOeKzqRpG7OZLYlccjtNQEaAAVF2+x4e+yz/aQJVFQFLTm9//kLNTTAn5k73/pS4Isgo0rOCf/xoUKACGxPfEOgL3ujli7K+vQTnqtLSyw8UW2CP1wUuQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3558.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(366004)(396003)(39860400002)(136003)(36756003)(478600001)(66446008)(64756008)(166002)(966005)(8936002)(4326008)(6512007)(86362001)(66556008)(2906002)(15650500001)(6916009)(33656002)(66476007)(8676002)(66574015)(66946007)(186003)(54906003)(30864003)(91956017)(5660300002)(316002)(76116006)(83380400001)(6486002)(71200400001)(53546011)(2616005)(6506007)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /rJnQDRfvcuPC9M/4DEpB2L+1ycUN47Y/9He2kHMEhvcCJGJcm7ojSxtQtbP/740QS/XiursNsvbvcREg9Y69mFA5pzz53RBqEdZ/HFQH0No6T/ceDVtSrdIUExDh9ElYT/un1U0KA+3nvoofgo+1pcbiFP6iYYcvF5iuVThFYk8hBhS2NsMFdyR6fXL2JtY8m1PuhEf5KmKnjdw3vEugsJ3Ma21EmmYNtzY5uH6bPg1NGFB1oJ281FC+Ns75dS9eGUPtAgy3n71gW6mPQ9cpzlZqBsPTArPNO5fRFAwRUWhZbU7YIaZLqBu3GBVnRRUzKJ1cqX7msa9pr+vTuG6xR4ORubFh+vrP+yPS1X4NosyrnhraHxxzUCGa68lG3XeidJonZ7/W94d0N/Ep3n96Ek0rKp4dn2b//lZ6l+JSA/qkwavMMWWCNm7dUbr82r9dbddlOpwu7R8EbpNUNbKeCxPMJ0ONmLZYk/Ell4tUvqN5kZinttpy3bMd/eke4TzTcZDOXXnRBjmAX5IV28hejsYEblHMHFvkRJwZ4O3ImiFeJXsk/ftH/lVc8+KRo4T x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3C1ECB6FE6674200964FAB233A0A56E9ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3558.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 242d4c7c-d0ab-4e79-4814-08d834d79689 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 22:26:22.0048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dXsERFoLU9Abor4c/FxtLewOiozAkvSilZjrvYaKZjMte3aNeA4XLPNZiNZ8t7Z+vlrhmZcT6wAHWN3Q2ayt6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3446 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 22:26:31 -0000 --_000_3C1ECB6FE6674200964FAB233A0A56E9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaXNhZ3JlZSB3aXRoIHRoZSBhbmFsb2d5LCBNYXJrLg0KDQpJIHN1cHBvcnQgR1JBTkQgYmVj YXVzZSBpdCBpcyBiZXR0ZXIgdGhhbiBub3RoaW5nIGFuZCBwcm9ncmVzc2luZyBqdXN0IHRoYXQg YXQgNk1BTiBzZWVtcyB0byBiZSBhbiBpbmNyZWRpYmxlIGFjaGlldmVtZW50IGFscmVhZHkuDQoN CkJ1dCBpbiBhIHdvcmxkIHdl4oCZcmUgYWxsIGFkZHJlc3NlcyBhcmUgcHJvYWN0aXZlbHkgaW5z dGFsbGVkIHRoZSByb3V0ZXIgY291bGQgZWFzaWx5IGRlZmVhdCB0aGUgcmVtb3RlIERPUyBhZ2Fp bnN0IHRoZSBjYWNoZSAodGhhdOKAmXMgYW4gUkZDIDg1MDUtb25seSBuZXR3b3JrIGFuZCBkaGNw djYgdnMgYXV0b2NvbmYgaXMgb3J0aG9nb25hbCB0byB0aGF0LCB3ZSBhcmUgdGFsa2luZyBhYm91 dCBwcm92aXNpb25pbmcgdGhlIGNhY2hlIG5vdCBmb3JtaW5nIHRoZSBhZGRyZXNzKQ0KDQpGb3Ig dGhlIGluc2lkZXIgaW1wZXJzb25hdGlvbiBhdHRhY2ssIFNlTkQgbWF5IGJlIGRlYWQgYnV0IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNmxvLWFwLW5kLyBJcyB2 ZXJ5IG11Y2ggYWxpdmUuIFRoZSBzYWQgcG9pbnQgZnJvbSBhbiBJRVRGIHBlcnNwZWN0aXZlIGlz IHRoYXQgaXQgZGlkIG5vdCBjb21lIGZyb20gNk1BTi4NCg0KQm90dG9tIGxpbmUgaXMgdGhhdCB0 aGUgc3Bvb24gZG9uZSByaWdodCB3b3VsZCBub3QgbGVhayB0aGUgc291cC4NCg0KVG8gSmVu4oCZ cyByZWZlcmVuY2Ugd2UgZGlkIG5vdCBvbmx5IGRvIGdsZWFuaW5nIGluIHRoZSBzd2l0Y2guIFdl IGFsc28gZG8gZW5mb3JjZW1lbnQuIEFuZCBSQSBndWFyZC4gQW5kIFJBIHRocm90dGxpbmcuIEJ1 dCBhbiBlbmZvcmNlbWVudCBiYXNlZCBvbiBhIHNub29wZWQgc3RhdGUgaXMgaW1wZXJmZWN0IGJl Y2F1c2Ugd2UgY291bGQgbWlzcyBzdHVmZi4gQW5kIGl04oCZcyBhbGwgcHJvcHJpZXRhcnkgc28g aXQgbWlnaHQgYmVjb21lIGEgYmFkIGlkZWEgcmV0cm9zcGVjdGl2ZWx5IHNob3VsZCB0aGUgcHJv dG9jb2wgY2hhbmdlLiBUaGlzIGlzIHdoeSAxMCsgeWVhcnMgYWdvIHdlICh0aGUgZ3JvdXAgd2hv IGRlc2lnbmVkIGFuZCBpbXBsZW1lbnRlZCBhbGwgdGhpcyBpbiBDaXNjbyByb3V0ZXJzKSBwcm9w b3NlZCB0aGUgcmVnaXN0cmF0aW9uIG1vZGVsIHRoYXQgZW5kZWQgdXAgYXMgUkZDIDg1MDUuDQoN Ckkgd2lzaCB0aGlzIGdyb3VwIGNvdWxkIG9wZW4gaXRzIGV5ZXMuIE5EIGFzIGRlZmluZWQgaW4g dGhlIGxhc3QgY2VudHVyeSBpcyBub3Qgc3VpdGVkIGZvciBtb2Rlcm4gZmFicmljcywgdmlydHVh bCBtYWNoaW5lcyBhbmQgd2lyZWxlc3MuIEl0IGlzIGEgcGFpbiBmb3Igc2lsaWNvbi1iYXNlZCBm b3J3YXJkaW5nLiBUaW1lIHRvIHVwZ3JhZGUgaXMgb3ZlcmR1ZS4NCg0KSW4gdGhlIG1lYW50aW1l LCBrZWVwIHNhZmUuDQoNClBhc2NhbA0KDQpMZSAzMCBqdWlsLiAyMDIwIMOgIDIzOjI0LCBNYXJr IFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPiBhIMOpY3JpdCA6DQoNCu+7vw0KDQoNCk9u IEZyaSwgMzEgSnVsIDIwMjAsIDA0OjM1IFZhc2lsZW5rbyBFZHVhcmQsIDx2YXNpbGVua28uZWR1 YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4+IHdyb3Rl Og0KSGkgSmVuLA0KT0suIElQdjYgU0xBQUMgc3VibmV0IGlzIG5vdCBzZWN1cmUgaW4gcHJpbmNp cGxlIGFuZCB3ZSBzaG91bGQgYWJhbmRvbiBhbnkgYXR0ZW1wdCB0byBpbXByb3ZlIGl0Lg0KDQpH UkFORCdzIGdvYWwgaXMgbm90IGFuZCBoYXMgbmV2ZXIgYmVlbiB0byBpbXByb3ZlIHRoZSBzZWN1 cml0eSBvZiBORC4gVGhlcmUgaXMgbm8gc3RhdGVtZW50IHN1Y2ggYXMgIlRoZSBnb2FsIG9mIEdS QU5EIGlzIHRvIGltcHJvdmUgdGhlIHNlY3VyaXR5IG9mIE5ELiINCg0KVGhpcyBkcmFmdCBkZXNj cmliZXMgdGhlIHByb2JsZW0gc3BhY2UuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC8NCg0KVGhlcmUgYXJlIHNvbWUgdXNl ZnVsIHNlY3VyaXR5IGJlbmVmaXRzIG9mIHRoZSB3YXkgaXQgd2lsbCBwcmVwb3B1bGF0ZSByb3V0 ZXJzJyBORCBjYWNoZXMgd2l0aCBub2RlcycgbmV3IGFkZHJlc3Nlcy4gSG93ZXZlciwgaWYgbm9u ZSBvZiB0aG9zZSBiZW5lZml0cyBleGlzdGVkLCBpdCB3b3VsZG4ndCBpbnZhbGlkYXRlIEdSQU5E IGFzIGEgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gR1RBTkQgaXMgZGVzaWduZWQgdG8gc29sdmUu DQoNCk1ha2luZyB0aGUgcHJpbWFyeSBjcml0aWNpc20gb2YgR1JBTkQgYmVpbmcgYWJvdXQgTkQg c2VjdXJpdHkgaXMgbGlrZSBjcml0aWNpc2luZyBhIHNwb29uIGZvciBiZWluZyBhIHRlcnJpYmxl IGtuaWZlLg0KDQpSZWdhcmRzLA0KTWFyay4NCg0KDQoNCkJlY2F1c2Ugc28gbWFueSBwZW9wbGUg YWxyZWFkeSBzcGVudCBzbyBtdWNoIHRpbWUgb24gdGhpcyBtYXR0ZXIgLSBpdCBpcyBqdXN0IGRv ZXMgbm90IG1ha2Ugc2Vuc2UgdG8gdGFsayBhZ2FpbiBhbmQgYWdhaW4uDQpBbmQgdGhlIHByaW1h cnkgc29sdXRpb24gdGhhdCB0aGV5IGZvdW5kIGlzIHRoZSBzdGF0ZWZ1bCAiYmluZGluZyB0YWJs ZSIgb24gdGhlIHN3aXRjaCB0byBtb25pdG9yIGFsbCBORHMgKGxpa2UgREhDUC9BUlAgaW4gSVB2 NCksIHRoYXQgbm90IG1hbnkgdXNlIGFueXdheSAtIHdlIG5lZWQgdG8gZml4IHVuc2VjdXJlIHNv bHV0aW9uLg0KDQpUaGVuIHlvdXIgZGlsZW1tYSBpcyBub3QgaW1wb3J0YW50LCA3c2VjIHRyYWZm aWMgaGlqYWNraW5nIGNvdWxkIG5vdCBoYXBwZW4gdW5pbnRlbnRpb25hbGx5IC0gcHJvYmFiaWxp dHkgZm9yIGFkZHJlc3MgY29sbGlzaW9uIG9uIC82NCBpcyB0b28gbG93LCB3aGF0ZXZlciBJbnRl cmZhY2UgSURzIHdvdWxkIGJlIHVzZWQgKGNvbGxlY3Rpb24gb2YgUkZDcyBleGlzdCkuDQpFZHVh cmQNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKZW4gTGlua292YSBbbWFpbHRv OmZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT5dDQpTZW50OiAzMCDQ uNGO0LvRjyAyMDIwINCzLiAxMjo1OA0KVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4NCkNj OiA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj47IHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbmNlcm5zDQoNCk9u IFRodSwgSnVsIDMwLCAyMDIwIGF0IDY6MDUgUE0gVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtv LmVkdWFyZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiB3 cm90ZToNCj4gVGhlbiBpdCBpcyBub3QgbG9naWNhbCBmb3IgbWU6DQo+IE1hbnkgcGVvcGxlIHVu ZGVyc3RhbmQgdGhhdCAiVW5zb2xpY2l0ZWQgTkEiIGlzIGEgYmlnIHNlY3VyaXR5IGhvbGUNCj4g cGVyIHNlLCBCdXQgaW5zdGVhZCBvZiBmaXhpbmcgaXQgKG1heSBiZSBldmVuIGRlcHJlY2F0ZSAt IHNob3VsZCBiZQ0KPiBpbnZlc3RpZ2F0ZWQpDQoNClRoZXJlIGFyZSBtYW55IGF0dGFja3MgcG9z c2libGUgd2l0aGluIHRoZSBzYW1lIEwyIHNlZ21lbnQuIEl0J3Mgbm90IG5ldy4gVGhhdCdzIHdo eSB5b3Ugc2hhbGwgZWl0aGVyIGJsb2NrIHAycCB3aXRoIHRoZSBMQU4gKGlmIHlvdSBkbyBub3Qg dHJ1c3QgZW5kcG9pbnRzIGluIGdlbmVyYWwpIG9yIC0gYmV0dGVyIC0gaG9zdHMgc2hhbGwgdXNl IGVuZDJlbmQgZW5jcnlwdGlvbi4NCg0KPiBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgaXMgYnVp bGRpbmcgb24gdG9wIG9mIGl0Lg0KDQpTb3JyeSwgSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3 aHkgdW5zb2xpY2l0ZWQgTkEgaXMgdGhlIHByb2JsZW0gaGVyZS4uIFRoZSBtZWNoYW5pc20gSSBk ZXNjcmliZWQgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgdXNpbmcNCipzb2xpY2l0ZWQqIE5BIHRv IG92ZXJyaWRlIHRoZSBuZWlnaGJvciBjYWNoZSBvbiB0aGUgcm91dGVyLg0KDQo+IEl0IHdvdWxk IGFkZGl0aW9uYWxseSBjaGFsbGVuZ2UgdGhpcyBzZWN1cml0eSBwcm9ibGVtIHJlc29sdXRpb24g aW4gdGhlIGZ1dHVyZSENCj4NCj4gQWdhaW46ICJVbnNvbGljaXRlZCBOQSIgd2l0aCBPdmVycmlk ZSBiaXQgc2V0IC0gaXMgYSBkaXNhc3RlciBub3cuDQoNCkFzIHdlbGwgYXMgU29saWNpdGVkLCBy aWdodD8gOykgU2hhbGwgd2UgbG9vayBhdCBTRU5EIGFnYWluPyA7KSBJdCB3b3VsZCBiZSBncmVh dCBidXQgSSdtIG5vdCBhd2FyZSBvZiBpbXBsZW1lbnRhdGlvbnMgYmVpbmcgd2lkZWx5IGRlcGxv eWVkLg0KDQo+IElNSE86IGl0IGlzIGJldHRlciB0byBwcm9oaWJpdCAiVW5zb2xpY2l0ZWQgTkEi LiBMZXQncyB3YWl0IHRpbWVycyBmb3IgdGhlIGNhc2Ugb2YgTUFDIGFkZHJlc3MgY2hhbmdlIG9u IGxlZ2l0aW1hdGUgaG9zdC4NCj4gTWF5IGJlIHdlIGNvdWxkIHRoaW5rIGFib3V0IG90aGVyIHNv bHV0aW9ucy4NCj4gQnV0IGlmIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSB3b3VsZCBiZSBidWls dCBvbiB0b3Agb2YgIlVuc29saWNpdGVkIE5BIiAtIGxlc3Mgb3B0aW9ucyB3b3VsZCBiZSBhdmFp bGFibGUgKCJkZXByZWNhdGUiIHdvdWxkIGJlIG5vdCBhIGNob2ljZSBhbnltb3JlKS4NCj4NCj4g SWYgc29tZXRoaW5nIGlzIGlsbCAtIGl0IHNob3VsZCBiZSBjdXJlZCBmaXJzdCAtIGJvZHlidWls ZGluZyBtYWtlIHNlbnNlIG9ubHkgYWZ0ZXIgdGhpcy4NCj4NCj4gSmVuLCBJIGhhdmUgbm90IHVu ZGVyc3Rvb2QgYmVsb3cgd2h5IHlvdSBkaWQgbWVudGlvbiBSQSBHdWFyZC4gSW50cnVkZXIgZG9l cyBub3QgbmVlZCBpdC4gSGUganVzdCBjbGFpbSAoYnkgVW5zb2xpY2l0ZWQgTkEpIHRoYXQgaGlz IE1BQyBpcyBjb25uZWN0ZWQgdG8gR1VBIG9mIHZpY3RpbS4NCg0KWWVzLCB0byBpbnRlcmNlcHQg dHJhZmZpYyAqdG8qIHRoZSB2aWN0aW0uIEhvdyBpcyBpdCBnb2luZyB0byBpbnRlcmNlcHQgcGFj a2V0cyBzZW50IGJ5IHRoZSB2aWN0aW0/DQoNCj4gSW50cnVkZXIgY291bGQgY2xhaW0gaXQgZXZl cnkgNSBzZWNvbmRzIHRvIGtlZXAgY2FjaGUgaW4gU1RBTEUgc3RhdGUgKGZvciB0aGUgY2FzZSBv ZiB2ZXJ5IGNhcmVmdWwgdmVuZG9yIGltcGxlbWVudGF0aW9uIG9mIE5EKS4NCj4gQXMgeW91IG1l bnRpb25lZCAtIG5vIGhlbHAgZnJvbSBNTEQgc25vb3Bpbmcgb24gc3dpdGNoZXMgLSBpdCB3b3Vs ZCBiZSBlbm91Z2ggdG8ganVzdCBsaXN0ZW4gdG8gREFELiBTd2l0Y2ggY291bGQgbm90IGhlbHAg aW4gcHJpbmNpcGxlLg0KDQpTdHJpY3RseSBzcGVha2luZywgaWYgdGhlIHN3aXRjaGluZyBpbmZy YXN0cnVjdHVyZSBpbXBsZW1lbnRzIE1MRCBzbm9vcGluZywgdGhlIGF0dGFja2VyIHdvdWxkIG5l ZWQgZWl0aGVyIHRvIGd1ZXNzIHRoZSBsb3dlciAyNCBiaXRzIG9mIHRoZSB2aWN0aW0ncyBhZGRy ZXNzIG9yIHRvIGpvaW4gMl4yNCBzb2xpY2l0ZWQgbm9kZSBtdWx0aWNhc3QgYWRkcmVzcyBncm91 cHMuDQoNCj4gVGhlIGZpcnN0IG1vZGlmaWVkIEROUyByZXNwb25zZSB3b3VsZCBjb252ZXJ0IHRy YWZmaWMgZmxvdyB0byBiaS1kaXJlY3Rpb25hbCBmb3IgSW50cnVkZXIuDQoNClRoYXQncyB3aHkg RE5TU0VDIGFuZCBETlMgb3ZlciBUTFMgYW5kIEhUVFBTIGFyZSBnb29kIGZvciBzZWN1cml0eS4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKZW4gTGlua292YSBbbWFp bHRvOmZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT5dDQo+IFNlbnQ6 IDMwINC40Y7Qu9GPIDIwMjAg0LMuIDU6MDcNCj4gVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2ls ZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29t Pj4NCj4gQ2M6IDZtYW4gPGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+PjsgdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYuLm9yZz4NCj4gU3ViamVjdDogUmU6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwNCj4gc2VjdXJpdHkg Y29uY2VybnMNCj4NCj4gT24gVGh1LCBKdWwgMzAsIDIwMjAgYXQgNTo1NiBBTSBWYXNpbGVua28g RWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVh cmRAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPiA+IFlvdSBkaWQgYXNrIGEgZmVlZGJhY2sgeWVzdGVy ZGF5IGFib3V0IHNldmVyaXR5IG9mIDdzZWMgc2VjdXJpdHkgaG9sZSB0aGF0IGhhcyB2ZXJ5IGxv dyBwcm9iYWJpbGl0eS4NCj4gPiBJIGhhdmUgaW50ZW50aW9uIGhlcmUgdG8gc2hvdyB0aGF0IHBy b2JhYmlsaXR5IGlzIDEwMCUsIDdzZWMgY291bGQgYmUgcHJvbG9uZ2VkIHRvIGZvcmV2ZXIsIGFu ZCB0aGUgZmluYWwgcmVzdWx0IGlzIHRoZSBmdWxsIGludGVyY2VwdGlvbiBvZiBpbm5vY2VudCBo b3N0IHRyYWZmaWMgYnkgaW50cnVkZXIgKHN1Y2Nlc3NmdWwgIm1hbi1pbi10aGUtbWlkZGxlIiku DQo+ID4NCj4gPiBQcmUtcmVxdWVzdCBmb3Igc3VjY2VzczoNCj4gPiAtIG5vIG11bHRpY2FzdCBz bm9vcGluZyAoTUxEKSBhbmQgZmlsdGVyaW5nIG9uIGEgc3dpdGNoLCB0aGF0IGlzDQo+ID4gcGVy ZmVjdGx5IHBvc3NpYmxlDQo+ID4gLSBJbnRydWRlciBzaG91bGQgYmUgYWxyZWFkeSBvbiB0aGUg c2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXINCj4gPiBvdGhlciBob3N0IGJ5IGV4cGxv aXRpbmcgb2YgZGlmZmVyZW50IHZ1bG5lcmFiaWxpdHkpDQo+ID4gLSBpbnRydWRlciBzaG91bGQg c3VwcHJlc3MgREFEIG9uIEludHJ1ZGVyJ3MgY29udHJvbGxlZCBob3N0IChpcw0KPiA+IFdpbmRv d3MgZmlyZXdhbGwgY2FwYWJsZSB0byBmaWx0ZXIgb3V0IERBRD8pDQo+ID4gLSBXZSBhc3N1bWUg dGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgZnV0dXJlIHdoZW4gdGhpcyBkcmFmdCBpcw0K PiA+IHVzZWQgYnkgbWFqb3JpdHkgb2Ygbm9kZXMgKHZpY3RpbSBzaG91bGQgdXNlIGl0KQ0KPiA+ DQo+ID4gUHJvY2VkdXJlOg0KPiA+IEludHJ1ZGVyJ3MgY29udHJvbGxlZCBob3N0IGRvZXMgbGlz dGVuIHRvIGFsbC1yb3V0ZXJzIG11bHRpY2FzdCBhZGRyZXNzIChmZjAyOjoyKS4NCj4gPiBBcyBz b29uIGFzIGl0IHdvdWxkIGVhdmVzZHJvcCB1bnNvbGljaXRlZCBOQSBmcm9tIHZpY3RpbSBub2Rl IChwcm9iYWJseSBhZnRlciBib290KSAtIEludHJ1ZGVyIHdvdWxkIGltbWVkaWF0ZWx5IChhIGZl dyBtaWxsaXNlY29uZHMpIGR1cGxpY2F0ZSBOQSBpbiByb3V0ZXIncyBkaXJlY3Rpb24sIGJ1dCB3 aXRoIDIgY2hhbmdlczogKDEpIGhpcyBMTEEgKE1BQyk7ICgyKSBPdmVycmlkZSBiaXQgc2V0Lg0K PiA+IEludHJ1ZGVyIGhhcyB0aW1lIG9ubHkgdXAgdG8gdGhlIHBvaW50IHRoYXQgcmVzcG9uc2Ug dG8gdmljdGltJ3MgdHJhZmZpYyB3b3VsZCBiZSByZXR1cm5lZCBmcm9tIHRoZSBJbnRlcm5ldCAo ZnJvbSB0ZW5zIG9mIG1pbGxpc2Vjb25kcyB0byBtYW55IHNlY29uZHMgaWYgdmljdGltIHdvdWxk IG5vdCBzdGFydCBzZW5kaW5nIGltbWVkaWF0ZWx5KSwgLSBidXQgaXQgaXMgZW5vdWdoIHRpbWU6 IGxvY2FsIGNvbW11bmljYXRpb24gc2hvdWxkIGJlIGZhc3Rlci4NCj4gPiBUaGVvcmV0aWNhbGx5 LCBSZXRyYW5zVGltZXIgc2hvdWxkIGJlIGltcG9zZWQgb24gdW5zb2xpY2l0ZWQgTkEgKHNlY3Rp b24gNy4yLjYpLCBidXQgbG93IGNoYW5jZXMgdGhhdCB0aGlzIHRpbWVyIGlzIGNoZWNrZWQgb24g cmVjZWl2aW5nIHNpZGUgKHJvdXRlciksIGJlY2F1c2UgUmV0cmFuc1RpbWVyIGlzIHNwZWNpZmll ZCBmb3IgdHJhbnNtaXNzaW9uIHNpZGUuDQo+ID4gQWNjb3JkaW5nIFJGQyA0NjgxIHNlY3Rpb24g Ny4yLjUgY2xhdXNlIElJOiBPIGJpdCBzZXQgc2hvdWxkIG5vdCBqdXN0IHJld3JpdGUgTkQgY2Fj aGUsIGJ1dCBhZGRpdGlvbmFsbHkgbWFyayBORCByZWNvcmQgYXMgUkVBQ0hBQkxFLiBBY2NvcmRp bmcgdG8gc2VjdGlvbiA3LjIuNjogIiBUaGUgT3ZlcnJpZGUgZmxhZyAoZm9yIHVuc29saWNpdGVk IE5BKSBNQVkgYmUgc2V0IHRvIGVpdGhlciB6ZXJvIG9yIG9uZSIuIERlc3BpdGUgaXQgY29udHJh ZGljdHMgdG8gdGhlIGxvZ2ljIG9mIHRoZSB3aG9sZSBSRkMgNDY4MSAoTyBiaXQgc2hvdWxkIG5v dCBiZSBzZXQgaW4gdW5zb2xpY2l0ZWQgTkEgLSBpdCBpcyBtZW50aW9uZWQgaW4gYSBmZXcgcGxh Y2VzIG9mIFJGQyA0NjgxKS4gQnV0IGJlY2F1c2Ugc2VjdGlvbiA3LjIuNSBhbmQgc2VjdGlvbiA3 LjIuNiBjbGVhcmx5IHBlcm1pdCB0byB1c2UgT3ZlcnJpZGUgZmxhZyAtIGhpZ2hlciBwcm9iYWJp bGl0eSB0aGF0IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24gd291bGQgbm90IGp1c3QgcmV3cml0 ZSBMTEEgb24gcm91dGVyLCBidXQgYWRkaXRpb25hbGx5IHB1dCBpdCBpbnRvIFJFQUNIQUJMRS4N Cj4gPiBJbnRydWRlciBjb3VsZCBiZSBzdXJlIHRoYXQgYXQgbGVhc3QgU1RBTEUgc3RhdGUgd291 bGQgYmUgY3JlYXRlZCBhY2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIuNSBjbGF1c2UgSSwgLSB0aGlz IE5EIHJlY29yZCB3b3VsZCBiZSBhZ2FpbnN0IGhpcyBMTEEgYW55d2F5Lg0KPiA+IEFmdGVyIHJl Y2VpdmluZyByZXR1cm4gdHJhZmZpYyAoaWYgaXQgd2FzIGNyZWF0ZWQgYXMgU1RBTEUsIG5vdCBS RUFDSEFCTEUpIC0gcm91dGVyIHdvdWxkIGFzayBpbnRydWRlciBhYm91dCByZWFjaGFiaWxpdHkg KHNvbGljaXRlZCBOUy1OQSkgLSBpbnRydWRlciB3b3VsZCBjb25maXJtIGhpcyBMTEEgLSBpdCB3 b3VsZCBmaW5hbGx5IHB1dCBORCBjYWNoZSByZWNvcmQgaW50byBSRUFDSEFCTEUuDQo+DQo+IDEp IHRoZSA3IHNlY29uZHMgY29ybmVyIGNhc2Ugd2FzIGZvciAncHJldmVudGluZyBhZGRyZXNzIGNv bGxpc2lvbiBmb3IgT3B0aW1pc3RpYyBEQUQnLCBub3QgZm9yIGFueSBpbnRlbnRpb25hbCBhdHRh Y2tzIGNhc2UuIEJlY2F1c2U6DQo+IDIpIFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGNvdWxkIGJl IGRvbmUgdG9kYXksIG5vdywgYW55dGltZSB3L28gdGhlIGNoYW5nZXMgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29waW5nIHRoZW4gdGhlIGludHJ1ZGVyIHdv dWxkIHNlZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2aWN0aW0sIHNvIGl0IHdvdWxkIGtub3cg dGhlIHZpY3RpbSBhZGRyZXNzIGFueXdheSAgLSBubyByZWFzb24gZXZlbiB0byBqb2luIGZmMDI6 OjIuIE5vdyBhbGwgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGRvIGlzIHRvIGtlZXAgc2VuZGluZyBO QSB3aXRoIFM9MSwgTz0xIC0gaG9waW5nIHRoYXQgd2hlbiB0aGUgZmlyc3QgcGFja2V0IG9mIHRo ZSByZXR1cm4gZmxvd3MgYXJyaXZlIGFuZCB0aGUgcm91dGVyIGNyZWF0ZXMgYW4gSU5DT01QTEVU RSBlbnRyeSBhbmQgc2VuZHMgYW4gTlMsIHRoZSBhdHRhY2tlcidzIHBhY2tldCB3b3VsZCBjb21l IGJlZm9yZSB0aGUgdmljdGltJ3MgTkEuIERvbmUsIHRoZSAgZW50cnkgaXMgY2hhbmdlZCB0byBS RUFDSEFCTEUsIGFsbCB0cmFmZmljIGdvZXMgdG8gdGhlIGF0dGFja2VyLg0KPiBBY3R1YWxseSBl dmVuIHNpbXBsZXIuIFRoZSBhdHRhY2tlciBkb2VzIG5vdCBuZWVkIHRvIGRlYWwgd2l0aCB0aW1p bmcuDQo+IExldCdzIHNheSB0aGUgcm91dGVyIGhhcyBhbiBOQyBlbnRyeSBmb3IgdGhlIHZpY3Rp bSBhZGRyZXNzIGluIGFueSBvdGhlciBzdGF0ZSB0aGFuIElOQ09NUExFVEUuIFRoZSBhdHRhY2tl ciBzZW5kcyBhbiBOQSB3aXRoIFM9MSwgTz0xLCBUYXJnZXQgYWRkcmVzcyA9IHRoZSB2aWN0aW0n cyBJUHY2IGFkZHJlc3MsIHRoZSBUTExBID0gdGhlIGF0dGFja2VyIE1BQyBhZGRyZXNzLiAgRG9u ZS4gVGhlIHJvdXRlciB1cGRhdGVzIHRoZSBjYWNoZSBlbnRyeSBhbmQgY2hhbmdlcyBpdCB0byBS RUFDSEFCTEUgc3RhdGUuDQo+DQo+IFRoZXJlIGlzIG5vdGhpbmcgbmV3IGhlcmUuIFdlIGhhdmUg dGhlIHNhbWUgaXNzdWUgd2l0aCBBUlAgLSB0aGUgYXR0YWNrZXIgY2FuIG92ZXJyaWRlIEFSUCBl bnRyeSBvbiB0aGUgcm91dGVyLg0KPg0KPiA+IFRoYXQncyBpdDogdXBzdHJlYW0gdHJhZmZpYyBv ZiB2aWN0aW0gaG9zdCBpcyBnb2luZyB0byByb3V0ZXIsIHRyYWZmaWMgYmFjayBpcyBnb2luZyB0 aHJvdWdoIEludHJ1ZGVyLg0KPiA+IEkgaGF2ZSBjb25zdWx0ZWQgd2l0aCBwZW5ldHJhdGlvbiB0 ZXN0cyBwcm9mZXNzaW9uYWwgKHRoZXNlIGFyZSBwZW9wbGUgd2l0aCB0aGUgc2FtZSBxdWFsaWZp Y2F0aW9uIGFzIGhhY2tlcnMgYnV0IHRoZXkgcGxheSBvbiBsZWdhbCBzaWRlKTogd2hhdCBoZSB3 b3VsZCBiZSBkb2luZyBuZXh0PyBIZSBzYWlkIHRoYXQgaGUgd291bGQgcmV0dXJuIHRyYWZmaWMg dG8gbGVnaXRpbWF0ZSBob3N0IC0gdmljdGltIHNob3VsZCBub3Qgc2VlIHBlcmZvcm1hbmNlIGRl Z3JhZGF0aW9uLiBIZSB3b3VsZCBjb2xsZWN0IGNvb2tpZXMgYW5kIHNvbWUgb3RoZXIgdmFsdWFi bGUgaW5mb3JtYXRpb24uIEhlIHdvdWxkIGZpbmFsbHkgc2VlIEROUyByZXNwb25zZSwgY2hhbmdl IGl0IGFuZCByZWRpcmVjdCBldmVyeXRoaW5nIHRvIGhpbXNlbGYgb24gdGhlIHBlcm1hbmVudCBi YXNpcyAtIGhlIGRvZXMgd2FudCB0byBzZWUgYm90aCBkaXJlY3Rpb25zIG9mIHZpY3RpbSBleGNo YW5nZS4gSGUgaGFzIHF1YWxpZmllZCBNYW4taW4tdGhlLW1pZGRsZSBhcyBmdWxsIGZpYXNjbyAt IGl0IGRvZXMgb3BlbiBtYW55IG9wcG9ydHVuaXRpZXMgZm9yIGhpbS4gSGUgaGFzIG1lbnRpb25l ZCB2ZXJ5IGdvb2QgZmVhdHVyZSBvZiB0aGlzIGRyYWZ0IHRoYXQgdGhlcmUgaXMgbm8gYW55IGlu dGVycnVwdGlvbiBmb3IgdmljdGltJ3MgdHJhZmZpYyBmbG93LCBubyBhbnkgZXhjZXNzaXZlIHRy YWZmaWMgdG8gdmljdGltLCB0aGF0IGlzIHZlcnkgcmVhciBiZW5lZml0IGZvciBoYWNrZXIncyB0 b29sLg0KPg0KPiBGb3IgYWxsIHRoYXQgZG9vbSBhbmQgZ2xvb20gdGhlIGF0dGFja2VyIHdvdWxk IGFsc28gbmVlZCB0byBzZWUgdGhlIHRyYWZmaWMgKmZyb20qIHRoZSB2aWN0aW0uIEFzc3VtaW5n IHRoZSBuZXR3b3JrIGhhcyBSQSBHdWFyZCBpbiBwbGFjZSBpdCB3b3VsZCBiZSBhIGJpdCBoYXJk ZXIuIElmIHRoZSBuZXR3b3JrIGRvZXMgbm90IGhhdmUgUkEgR3VhcmQgb3VyIHBvb3IgdmljdGlt IGhhcyBtdWNoIGJpZ2dlciBwcm9ibGVtcyBhbHJlYWR5Lg0KPg0KPiA+IFdoYXQgdG8gZG8gYWJv dXQgaXQ/DQo+ID4gMS4gUG90ZW50aWFsbHkgaXQgaXMgcG9zc2libGUgdG8gZG8gUlBGLWxpa2Ug Y2hlY2sgZm9yIFNvdXJjZSBMTEEgYWRkcmVzc2VzLiBVcHN0cmVhbSB0cmFmZmljIGZyb20gdmlj dGltJ3MgU0xMQSB3b3VsZCBub3QgYmUgaW4gTkQgY2FjaGUgLSBzdWNoIHRyYWZmaWMgY291bGQg YmUgZGlzY2FyZGVkLiBJdCBpcyBiZXR0ZXIgdG8gYmxvY2sgY29tbXVuaWNhdGlvbiB0aGFuIHBl cm1pdCBpbnRydWRlciB0byBleHBsb2l0IHZ1bG5lcmFiaWxpdHkuDQo+DQo+ID4gMi4gSW5jcmVh c2UgUmV0cmFuc1RpbWVyIGFuZCBhc2sgcmVjZWl2ZXIgc2lkZSAocm91dGVyKSB0byBjaGVjayBv biBzZW5kaW5nIHNpZGUgZGVsYXkgYmV0d2VlbiBORCByZWNvcmQgb3ZlcnJpZGUgKGZvciB0aGUg c2FtZSBTTExBKS4gQnV0IGhvdyBsb25nIHNob3VsZCBiZSB0aGUgdGltZXI/IEhvc3QgY291bGQg d2FpdCBhIGxvLW8tby1uZyB0aW1lIGJlZm9yZSBpdCB3b3VsZCByZXF1ZXN0IDFzdCBpbmZvcm1h dGlvbiBmcm9tIGludGVybmV0LiBJdCB3b3VsZCBkZWNyZWFzZSBwcm9iYWJpbGl0eSwgYnV0IHdv dWxkIG5vdCBjb21wbGV0ZWx5IGVsaW1pbmF0ZSBhdHRhY2sgdmVjdG9yLg0KPiA+DQo+ID4gTXkg cHJvcG9zaXRpb24gZm9yIHRoaXMgZHJhZnQgaXMgZGlzcnVwdGl2ZToNCj4gPiBJIGJlbGlldmUg dGhhdCBORCBpcyB2ZXJ5IGNvbXBsaWNhdGVkIChzb21lIGNvdWxkIHNheSAiZnJhZ2lsZSIpIC0g aXQgaXMgYmV0dGVyIG5vdCB0byB0b3VjaCBpdC4NCj4gPiBBZGRpdGlvbmFsbHkgSSBkbyBub3Qg bGlrZSB0byB3YWl0IHRpbGwgYWxsIGhvc3RzIHdvdWxkIHJlZnJlc2ggdG8gbmV3IGRyYWZ0ICh0 byBnZXQgbmV3IGZ1bmN0aW9uYWxpdHkpLg0KPg0KPiBXZWxsLCBvbmx5IGhvc3RzIHdoaWNoIHdh bnQgdG8gY29ubmVjdCB0byB0aGUgbmV0d29yayBmYXN0ZXIgbmVlZCB0byBpbXBsZW1lbnQgdGhp cy4gU28gaG9zdCBPUyBkZXZlbG9wZXJzIGhhdmUgcHJldHR5IGdvb2QgaW5jZW50aXZlIGhlcmUu DQo+IFBsZWFzZSBrZWVwIGluIG1pbmQgdGhhdCB0aGUgcHJvcG9zZWQgYmVoYXZpb3IgaXMgbm90 IGN1cnJlbnRseSBwcm9oaWJpdGVkLiBXZSBhcmUgbm90IGNoYW5naW5nIGFueSBNVVNUIE5PVCB0 byBhbnl0aGluZyBlbHNlLiBBbGwgd2UgYXJlIGRvaW5nIGlzIHRvIG1ha2luZyBzb21lIHJlY29t bWVuZGF0aW9ucyBtb3JlIGV4cGxpY2l0Lg0KPg0KPiA+IEkgcHJvcG9zZSB0byBjaGFuZ2Ugb25s eSByb3V0ZXIgYmVoYXZpb3I6IGNoZWNrIFNvdXJjZSBMTEEgKE1BQykgZm9yIGV2ZXJ5IHBhY2tl dCwgaWYgdGhpcyBTTExBIGlzIGFic2VudCBpbiBORCBjYWNoZSAtIHRoZW4gcmVxdWVzdCBzb2xp Y2l0ZWQgTlMtTkEgaW1tZWRpYXRlbHkuIEl0IHdvdWxkIHByb2JhYmx5IHJlc29sdmUgZmFzdGVy IHRoYW4gdHJhZmZpYyB3b3VsZCByZXR1cm4gZnJvbSB0aGUgaW50ZXJuZXQuDQo+DQo+IEhhdmUg eW91IGNoZWNrZWQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0Pw0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC0w DQo+IDMjc2VjdGlvbi0zLjcNCj4gc3BlY2lmaWNhdGxseT8NCj4gV2hhdCB5b3UgYXJlIHByb3Bv c2luZyBkb2VzIG1ha2Ugc2Vuc2UsIGhvd2V2ZXIgaXQgd291bGQgbm90IGhlbHAgaW4gY2FzZSBv ZiBtdWx0aXBsZSByb3V0ZXJzLiBBbHNvIEkgcmVjYWxsIHNvbWUgcGVvcGxlIGhhdmluZyBzdHJv bmcgb3BpbmlvbnMgb24gcGVyZm9ybWFuY2UgaW1wbGljYXRpb25zLg0KPg0KPiA+IEVmZmVjdGl2 ZWx5IEkgZG8gcHJvcG9zZWQgdGhlIHNhbWUgU0xMQSBSUEYgdGhhdCBpcyBuZWVkZWQgdG8gZml4 IGN1cnJlbnQgc29sdXRpb24sIGJ1dDoNCj4gPiAtIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbiB0 byBob3N0IE9TZXMNCj4gPiAtIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbiBvZiBzdGFuZGFyZCAo aXQgaXMgbG9jYWwgcmVjb21tZW5kYXRpb24NCj4gPiBmb3Igcm91dGVyLCBOUy1OQSBpcyBleGFj dGx5IHRoZSBzYW1lIGZyb20gUkZDIDQ2ODEsIE5BIGlzIHVuaWNhc3QgLQ0KPiA+IGl0IGlzIGlt cG9ydGFudCBmb3Igc2VjdXJpdHkpDQo+ID4gLSB3aXRob3V0IGFueSByaXNrIHRvIGJyZWFrIE5E IGZyYWdpbGUgYWxnb3JpdGhtDQo+ID4gLSBpdCBjb3VsZCBiZSBvcHRpb25hbCwgb3IgZXZlbiBj b25maWd1cmFibGUgb24gdGhlIHJvdXRlciBhcyAidmFsdWUNCj4gPiBhZGQgZmVhdHVyZSIgaW4g Y29tcGV0aXRpdmUgdGVuZGVyIEJlY2F1c2UgaXQgaXMganVzdCBiZXN0IHByYWN0aWNlIHJlY29t bWVuZGF0aW9uIC0gbWF5IGJlIGl0IG1ha2Ugc2Vuc2UgdG8gbW92ZSBpdCB0byAidjZvcHMiPw0K Pg0KPiBTZWUNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLXY2b3BzLW5kLWNhY2hlLWluaXQtMA0KPiAzDQo+DQo+ID4gUFM6IExvb2tpbmcgdG8gdGhl IGFib3ZlIC0gdW5zb2xpY2l0ZWQgTkEgc2hvdWxkIGJlIHJlYWxseSBkZWxheWVkIGJ5IGFkZGl0 aW9uYWwgYmlnIHRpbWVyIChub3QgYnkgUmV0cmFuc1RpbWVyIHRoYXQgaXMgdXNlZCBmb3Igc29s aWNpdGVkIE5TL05BKSBhbmQgY2hlY2tlZCBvbiByZWNlaXZlciBzaWRlIC0gdGhpcyBtb2RpZmlj YXRpb24gb2Ygc3RhbmRhcmQgaXMgcmVhbGx5IG5lZWRlZCB0byBjbG9zZSBVbnNvbGljaXRlZCBO QSB2dWxuZXJhYmlsaXR5Lg0KPiA+IFNvbWVib2R5IHNhaWQgb24gdGhlIGNhbGwgdGhhdCBpdCBp cyBhbHJlYWR5IGEgZmVhdHVyZSBvZiBzb21lIE9TIChBbmRyb2lkPykgLSBpdCBpcyBiYWQ6IGl0 IG1lYW5zIHRoYXQgdGhpcyBPUyBpcyBhbHJlYWR5IHZ1bG5lcmFibGUuDQo+DQo+IEkgd2FzIHNh eWluZyB0aGF0IHNvbWUgcm91dGluZyBwbGF0Zm9ybXMgaGF2ZSB0aGlzIGFscmVhZHkgaW1wbGVt ZW50ZWQuLiBTZWFyY2ggZm9yICdnbGVhbicgaGVyZToNCj4gaHR0cHM6Ly93d3cuY2lzY28uY29t L2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2X2Jhc2ljL2NvbmZpZ3VyYQ0KPiB0aW9u LzE1LWUvaXA2Yi0xNS1lLWJvb2svaXA2LW5kLWNhY2hlLW1nbXQuaHRtbA0KPg0KPiBBRkFJSyB0 aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHdoaWNoIGFyZSBhbHNvIHByZXBvcHVsYXRpbmcgTkMg ZnJvbSBEQUQgcGFja2V0cyBidXQgSSBjYW4gbm90IGZpbmQgeW91IGEgcmVmZXJlbmNlIHJpZ2h0 IG5vdy4NCj4NCj4gPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmVuIExpbmtvdmENCj4g PiBTZW50OiAyNyDQuNGO0LvRjyAyMDIwINCzLiA3OjQ5DQo+ID4gVG86IDZtYW4gPGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+Pg0KPiA+IFN1YmplY3Q6IFJlOiBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEudHh0DQo+ID4NCj4gPiBIZWxsbywNCj4gPg0KPiA+ IFRoZSAtMDEgdmVyc2lvbiBhZGRyZXNzZXMgY29tbWVudHMgcmVjZWl2ZWQgKHRoYW5rcyBldmVy eW9uZSB3aG8gcHJvdmlkZWQgZmVlZGJhY2spLiBBbHNvLCBTZWN0aW9uIDMgKEF2b2lkaW5nIERp c3J1cHRpb24pIGhhcyBiZWVuIGV4cGFuZGVkIGFuZCBkaXNjdXNzZWQgYSBjb3JuZXIgY2FzZSB3 aGVuIHR3byBkZXZpY2VzIHN0YXJ0IHVzaW5nIHRoZSBzYW1lIGFkZHJlc3MgYWxtb3N0IGF0IHRo ZSBzYW1lIHRpbWUgKHRoZSBzZWNvbmQgZGV2aWNlIGNvbmZpZ3VyZXMgYW4gb3B0aW1pc3RpYyBh ZGRyZXNzIGFmdGVyIHRoZSByaWdodGZ1bCBvd25lciBzZW50IHNvbWUgcGFja2V0cyBidXQgYmVm b3JlIHRoZSByZXR1cm4gdHJhZmZpYyBhcnJpdmVzKS4NCj4gPiBGZWVkYmFjayBvbiB0aGUgdXBk YXRlZCBzZWN0aW9uIDMuMw0KPiA+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi02bWFuLWdyYW5kLTAxI3NlY3Rpb24tMy4zKSBpcyB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQu DQo+ID4NCj4gPiBPbiBTdW4sIEp1bCAyNiwgMjAyMCBhdCAxMDoxNCBBTSA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCj4g PiA+DQo+ID4gPg0KPiA+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+ID4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBNYWludGVuYW5jZSBXRyBvZiB0aGUgSUVURi4N Cj4gPiA+DQo+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEdyYXR1aXRvdXMgTmVpZ2hi b3IgRGlzY292ZXJ5OiBDcmVhdGluZyBOZWlnaGJvciBDYWNoZSBFbnRyaWVzIG9uIEZpcnN0LUhv cCBSb3V0ZXJzDQo+ID4gPiAgICAgICAgIEF1dGhvciAgICAgICAgICA6IEplbiBMaW5rb3ZhDQo+ ID4gPiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMS50 eHQNCj4gPiA+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTINCj4gPiA+ICAgICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAyMC0wNy0yNQ0KPiA+ID4NCj4gPiA+IEFic3RyYWN0Og0KPiA+ID4g ICAgTmVpZ2hib3IgRGlzY292ZXJ5IChSRkM0ODYxKSBpcyB1c2VkIGJ5IElQdjYgbm9kZXMgdG8g ZGV0ZXJtaW5lIHRoZQ0KPiA+ID4gICAgbGluay1sYXllciBhZGRyZXNzZXMgb2YgbmVpZ2hib3Jp bmcgbm9kZXMgYXMgd2VsbCBhcyB0byBkaXNjb3ZlciBhbmQNCj4gPiA+ICAgIG1haW50YWluIHJl YWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4gIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0ODYxIHRv DQo+ID4gPiAgICBhbGxvdyByb3V0ZXJzIHRvIHByb2FjdGl2ZWx5IGNyZWF0ZSBhIE5laWdoYm9y IENhY2hlIGVudHJ5IHdoZW4gYSBuZXcNCj4gPiA+ICAgIElQdjYgYWRkcmVzcyBpcyBhc3NpZ25l ZCB0byBhIG5vZGUuICBJdCBhbHNvIHVwZGF0ZXMgUkZDNDg2MSBhbmQNCj4gPiA+ICAgIHJlY29t bWVuZHMgbm9kZXMgdG8gc2VuZCB1bnNvbGljaXRlZCBOZWlnaGJvciBBZHZlcnRpc2VtZW50cyB1 cG9uDQo+ID4gPiAgICBhc3NpZ25pbmcgYSBuZXcgSVB2NiBhZGRyZXNzLiAgVGhlIHByb3Bvc2Vk IGNoYW5nZSB3aWxsIG1pbmltaXplIHRoZQ0KPiA+ID4gICAgZGVsYXkgYW5kIHBhY2tldCBsb3Nz IHdoZW4gYSBub2RlIGluaXRpYXRlIGNvbm5lY3Rpb25zIHRvIG9mZi1saW5rDQo+ID4gPiAgICBk ZXN0aW5hdGlvbiBmcm9tIGEgbmV3IElQdjYgYWRkcmVzcy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4g PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQv DQo+ID4gPg0KPiA+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxl IGF0Og0KPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1n cmFuZC0wMQ0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLTZtYW4tZ3JhbmQtMDENCj4gPiA+DQo+ID4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxDQo+ID4gPg0KPiA+ID4NCj4gPiA+ IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYu b3JnPi4NCj4gPiA+DQo+ID4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+ID4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0tIElFVEYgSVB2NiB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPg0KPiA+ID4gQWRtaW5pc3RyYXRpdmUNCj4gPiA+IFJlcXVlc3RzOiBodHRwczovL3d3dy4u aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2Nj4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPg0KPiA+DQo+ ID4NCj4gPiAtLQ0KPiA+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4gPg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+IEFkbWluaXN0cmF0aXZlDQo+ID4gUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2Pg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+ DQo+IC0tDQo+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg0KDQoNCi0tDQpTWSwgSmVuIExp bmtvdmEgYWthIEZ1cnJ5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFp bGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0K --_000_3C1ECB6FE6674200964FAB233A0A56E9ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpJ IGRpc2FncmVlIHdpdGggdGhlIGFuYWxvZ3ksIE1hcmsuDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5JIHN1cHBvcnQgR1JBTkQgYmVjYXVzZSBpdCBpcyBiZXR0ZXIgdGhhbiBub3RoaW5nIGFuZCBw cm9ncmVzc2luZyBqdXN0IHRoYXQgYXQgNk1BTiBzZWVtcyB0byBiZSBhbiBpbmNyZWRpYmxlIGFj aGlldmVtZW50IGFscmVhZHkuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5C dXQgaW4gYSB3b3JsZCB3ZeKAmXJlIGFsbCBhZGRyZXNzZXMgYXJlIHByb2FjdGl2ZWx5IGluc3Rh bGxlZCB0aGUgcm91dGVyIGNvdWxkIGVhc2lseSBkZWZlYXQgdGhlIHJlbW90ZSBET1MgYWdhaW5z dCB0aGUgY2FjaGUgKHRoYXTigJlzIGFuIFJGQyA4NTA1LW9ubHkgbmV0d29yayBhbmQgZGhjcHY2 IHZzIGF1dG9jb25mIGlzIG9ydGhvZ29uYWwgdG8gdGhhdCwgd2UgYXJlIHRhbGtpbmcgYWJvdXQg cHJvdmlzaW9uaW5nIHRoZSBjYWNoZSBub3QNCiBmb3JtaW5nIHRoZSBhZGRyZXNzKTxicj4NCjxi cj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5Gb3IgdGhlIGluc2lkZXIgaW1wZXJzb25hdGlvbiBh dHRhY2ssIFNlTkQgbWF5IGJlIGRlYWQgYnV0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bG8tYXAtbmQvIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZsby1hcC1uZC88L2E+Jm5ic3A7SXMgdmVyeSBt dWNoIGFsaXZlLiBUaGUgc2FkIHBvaW50IGZyb20gYW4gSUVURiBwZXJzcGVjdGl2ZSBpcyB0aGF0 IGl0DQogZGlkIG5vdCBjb21lIGZyb20gNk1BTi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkJvdHRvbSBsaW5lIGlzIHRoYXQgdGhlIHNwb29uIGRvbmUgcmlnaHQgd291bGQgbm90IGxl YWsgdGhlIHNvdXAuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UbyBKZW7igJlzIHJl ZmVyZW5jZSB3ZSBkaWQgbm90IG9ubHkgZG8gZ2xlYW5pbmcgaW4gdGhlIHN3aXRjaC4gV2UgYWxz byBkbyBlbmZvcmNlbWVudC4gQW5kIFJBIGd1YXJkLiBBbmQgUkEgdGhyb3R0bGluZy4gQnV0IGFu IGVuZm9yY2VtZW50IGJhc2VkIG9uIGEgc25vb3BlZCBzdGF0ZSBpcyBpbXBlcmZlY3QgYmVjYXVz ZSB3ZSBjb3VsZCBtaXNzIHN0dWZmLiBBbmQgaXTigJlzIGFsbCBwcm9wcmlldGFyeSBzbyBpdCBt aWdodCBiZWNvbWUgYSBiYWQNCiBpZGVhIHJldHJvc3BlY3RpdmVseSBzaG91bGQgdGhlIHByb3Rv Y29sIGNoYW5nZS4gVGhpcyBpcyB3aHkgMTArIHllYXJzIGFnbyB3ZSAodGhlIGdyb3VwIHdobyBk ZXNpZ25lZCBhbmQgaW1wbGVtZW50ZWQgYWxsIHRoaXMgaW4gQ2lzY28gcm91dGVycykgcHJvcG9z ZWQgdGhlIHJlZ2lzdHJhdGlvbiBtb2RlbCB0aGF0IGVuZGVkIHVwIGFzIFJGQyA4NTA1LjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB3aXNoIHRoaXMgZ3JvdXAgY291bGQgb3BlbiBp dHMgZXllcy4gTkQgYXMgZGVmaW5lZCBpbiB0aGUgbGFzdCBjZW50dXJ5IGlzIG5vdCBzdWl0ZWQg Zm9yIG1vZGVybiBmYWJyaWNzLCB2aXJ0dWFsIG1hY2hpbmVzIGFuZCB3aXJlbGVzcy4gSXQgaXMg YSBwYWluIGZvciBzaWxpY29uLWJhc2VkIGZvcndhcmRpbmcuIFRpbWUgdG8gdXBncmFkZSBpcyBv dmVyZHVlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhlIG1lYW50aW1lLCBr ZWVwIHNhZmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYXNjYWw8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TGUgMzAg anVpbC4gMjAyMCDDoCAyMzoyNCwgTWFyayBTbWl0aCAmbHQ7bWFya3p6enNtaXRoQGdtYWlsLmNv bSZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gRnJpLCAzMSBKdWwgMjAyMCwgMDQ6MzUgVmFz aWxlbmtvIEVkdWFyZCwgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIiPnZhc2lsZW5rby5lZHVhcmRA aHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpIaSBKZW4sPGJyPg0KT0suIElQdjYgU0xBQUMg c3VibmV0IGlzIG5vdCBzZWN1cmUgaW4gcHJpbmNpcGxlIGFuZCB3ZSBzaG91bGQgYWJhbmRvbiBh bnkgYXR0ZW1wdCB0byBpbXByb3ZlIGl0LjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+R1JBTkQncyBnb2Fs IGlzIG5vdCBhbmQgaGFzIG5ldmVyIGJlZW4gdG8gaW1wcm92ZSB0aGUgc2VjdXJpdHkgb2YgTkQu IFRoZXJlIGlzIG5vIHN0YXRlbWVudCBzdWNoIGFzICZxdW90O1RoZSBnb2FsIG9mIEdSQU5EIGlz IHRvIGltcHJvdmUgdGhlIHNlY3VyaXR5IG9mIE5ELiZxdW90OzwvZGl2Pg0KPGRpdiBkaXI9ImF1 dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPlRoaXMgZHJhZnQgZGVzY3JpYmVzIHRo ZSBwcm9ibGVtIHNwYWNlLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRp diBkaXI9ImF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC88L2E+PGJyPg0KPC9kaXY+DQo8 ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+VGhlcmUgYXJlIHNv bWUgdXNlZnVsIHNlY3VyaXR5IGJlbmVmaXRzIG9mIHRoZSB3YXkgaXQgd2lsbCBwcmVwb3B1bGF0 ZSByb3V0ZXJzJyBORCBjYWNoZXMgd2l0aCBub2RlcycgbmV3IGFkZHJlc3Nlcy4gSG93ZXZlciwg aWYgbm9uZSBvZiB0aG9zZSBiZW5lZml0cyBleGlzdGVkLCBpdCB3b3VsZG4ndCBpbnZhbGlkYXRl IEdSQU5EIGFzIGEgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gR1RBTkQgaXMgZGVzaWduZWQgdG8g c29sdmUuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0 byI+TWFraW5nIHRoZSBwcmltYXJ5IGNyaXRpY2lzbSBvZiBHUkFORCBiZWluZyBhYm91dCBORCBz ZWN1cml0eSBpcyBsaWtlIGNyaXRpY2lzaW5nIGEgc3Bvb24gZm9yIGJlaW5nIGEgdGVycmlibGUg a25pZmUuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0 byI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5NYXJrLjwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBk aXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQpCZWNhdXNlIHNvIG1hbnkgcGVvcGxlIGFscmVhZHkgc3BlbnQgc28gbXVjaCB0aW1lIG9uIHRo aXMgbWF0dGVyIC0gaXQgaXMganVzdCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIHRhbGsgYWdhaW4g YW5kIGFnYWluLjxicj4NCkFuZCB0aGUgcHJpbWFyeSBzb2x1dGlvbiB0aGF0IHRoZXkgZm91bmQg aXMgdGhlIHN0YXRlZnVsICZxdW90O2JpbmRpbmcgdGFibGUmcXVvdDsgb24gdGhlIHN3aXRjaCB0 byBtb25pdG9yIGFsbCBORHMgKGxpa2UgREhDUC9BUlAgaW4gSVB2NCksIHRoYXQgbm90IG1hbnkg dXNlIGFueXdheSAtIHdlIG5lZWQgdG8gZml4IHVuc2VjdXJlIHNvbHV0aW9uLjxicj4NCjxicj4N ClRoZW4geW91ciBkaWxlbW1hIGlzIG5vdCBpbXBvcnRhbnQsIDdzZWMgdHJhZmZpYyBoaWphY2tp bmcgY291bGQgbm90IGhhcHBlbiB1bmludGVudGlvbmFsbHkgLSBwcm9iYWJpbGl0eSBmb3IgYWRk cmVzcyBjb2xsaXNpb24gb24gLzY0IGlzIHRvbyBsb3csIHdoYXRldmVyIEludGVyZmFjZSBJRHMg d291bGQgYmUgdXNlZCAoY29sbGVjdGlvbiBvZiBSRkNzIGV4aXN0KS48YnI+DQpFZHVhcmQ8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEplbiBMaW5rb3ZhIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmZ1cnJ5MTNAZ21haWwuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmZ1cnJ5MTNAZ21haWwuY29tPC9hPl0NCjxicj4NClNl bnQ6IDMwINC40Y7Qu9GPIDIwMjAg0LMuIDEyOjU4PGJyPg0KVG86IFZhc2lsZW5rbyBFZHVhcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20iIHJlbD0ibm9y ZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+dmFzaWxlbmtvLmVkdWFyZEBodWF3 ZWkuY29tPC9hPiZndDs8YnI+DQpDYzogNm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0 Zi5vcmciIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBp ZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiByZWw9Im5v cmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBh ZGRpdGlvbmFsIHNlY3VyaXR5IGNvbmNlcm5zPGJyPg0KPGJyPg0KT24gVGh1LCBKdWwgMzAsIDIw MjAgYXQgNjowNSBQTSBWYXNpbGVua28gRWR1YXJkICZsdDs8YSBocmVmPSJtYWlsdG86dmFzaWxl bmtvLmVkdWFyZEBodWF3ZWkuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsgVGhlbiBpdCBpcyBub3QgbG9naWNhbCBmb3IgbWU6PGJyPg0KJmd0OyBNYW55IHBlb3Bs ZSB1bmRlcnN0YW5kIHRoYXQgJnF1b3Q7VW5zb2xpY2l0ZWQgTkEmcXVvdDsgaXMgYSBiaWcgc2Vj dXJpdHkgaG9sZSA8YnI+DQomZ3Q7IHBlciBzZSwgQnV0IGluc3RlYWQgb2YgZml4aW5nIGl0ICht YXkgYmUgZXZlbiBkZXByZWNhdGUgLSBzaG91bGQgYmUgPGJyPg0KJmd0OyBpbnZlc3RpZ2F0ZWQp PGJyPg0KPGJyPg0KVGhlcmUgYXJlIG1hbnkgYXR0YWNrcyBwb3NzaWJsZSB3aXRoaW4gdGhlIHNh bWUgTDIgc2VnbWVudC4gSXQncyBub3QgbmV3LiBUaGF0J3Mgd2h5IHlvdSBzaGFsbCBlaXRoZXIg YmxvY2sgcDJwIHdpdGggdGhlIExBTiAoaWYgeW91IGRvIG5vdCB0cnVzdCBlbmRwb2ludHMgaW4g Z2VuZXJhbCkgb3IgLSBiZXR0ZXIgLSBob3N0cyBzaGFsbCB1c2UgZW5kMmVuZCBlbmNyeXB0aW9u Ljxicj4NCjxicj4NCiZndDsgQWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGlzIGJ1aWxkaW5nIG9u IHRvcCBvZiBpdC48YnI+DQo8YnI+DQpTb3JyeSwgSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3 aHkgdW5zb2xpY2l0ZWQgTkEgaXMgdGhlIHByb2JsZW0gaGVyZS4uIFRoZSBtZWNoYW5pc20gSSBk ZXNjcmliZWQgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgdXNpbmc8YnI+DQoqc29saWNpdGVkKiBO QSB0byBvdmVycmlkZSB0aGUgbmVpZ2hib3IgY2FjaGUgb24gdGhlIHJvdXRlci48YnI+DQo8YnI+ DQomZ3Q7IEl0IHdvdWxkIGFkZGl0aW9uYWxseSBjaGFsbGVuZ2UgdGhpcyBzZWN1cml0eSBwcm9i bGVtIHJlc29sdXRpb24gaW4gdGhlIGZ1dHVyZSE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBZ2Fpbjog JnF1b3Q7VW5zb2xpY2l0ZWQgTkEmcXVvdDsgd2l0aCBPdmVycmlkZSBiaXQgc2V0IC0gaXMgYSBk aXNhc3RlciBub3cuPGJyPg0KPGJyPg0KQXMgd2VsbCBhcyBTb2xpY2l0ZWQsIHJpZ2h0PyA7KSBT aGFsbCB3ZSBsb29rIGF0IFNFTkQgYWdhaW4/IDspIEl0IHdvdWxkIGJlIGdyZWF0IGJ1dCBJJ20g bm90IGF3YXJlIG9mIGltcGxlbWVudGF0aW9ucyBiZWluZyB3aWRlbHkgZGVwbG95ZWQuPGJyPg0K PGJyPg0KJmd0OyBJTUhPOiBpdCBpcyBiZXR0ZXIgdG8gcHJvaGliaXQgJnF1b3Q7VW5zb2xpY2l0 ZWQgTkEmcXVvdDsuIExldCdzIHdhaXQgdGltZXJzIGZvciB0aGUgY2FzZSBvZiBNQUMgYWRkcmVz cyBjaGFuZ2Ugb24gbGVnaXRpbWF0ZSBob3N0Ljxicj4NCiZndDsgTWF5IGJlIHdlIGNvdWxkIHRo aW5rIGFib3V0IG90aGVyIHNvbHV0aW9ucy48YnI+DQomZ3Q7IEJ1dCBpZiBhZGRpdGlvbmFsIGZ1 bmN0aW9uYWxpdHkgd291bGQgYmUgYnVpbHQgb24gdG9wIG9mICZxdW90O1Vuc29saWNpdGVkIE5B JnF1b3Q7IC0gbGVzcyBvcHRpb25zIHdvdWxkIGJlIGF2YWlsYWJsZSAoJnF1b3Q7ZGVwcmVjYXRl JnF1b3Q7IHdvdWxkIGJlIG5vdCBhIGNob2ljZSBhbnltb3JlKS48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJZiBzb21ldGhpbmcgaXMgaWxsIC0gaXQgc2hvdWxkIGJlIGN1cmVkIGZpcnN0IC0gYm9keWJ1 aWxkaW5nIG1ha2Ugc2Vuc2Ugb25seSBhZnRlciB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEpl biwgSSBoYXZlIG5vdCB1bmRlcnN0b29kIGJlbG93IHdoeSB5b3UgZGlkIG1lbnRpb24gUkEgR3Vh cmQuIEludHJ1ZGVyIGRvZXMgbm90IG5lZWQgaXQuIEhlIGp1c3QgY2xhaW0gKGJ5IFVuc29saWNp dGVkIE5BKSB0aGF0IGhpcyBNQUMgaXMgY29ubmVjdGVkIHRvIEdVQSBvZiB2aWN0aW0uPGJyPg0K PGJyPg0KWWVzLCB0byBpbnRlcmNlcHQgdHJhZmZpYyAqdG8qIHRoZSB2aWN0aW0uIEhvdyBpcyBp dCBnb2luZyB0byBpbnRlcmNlcHQgcGFja2V0cyBzZW50IGJ5IHRoZSB2aWN0aW0/PGJyPg0KPGJy Pg0KJmd0OyBJbnRydWRlciBjb3VsZCBjbGFpbSBpdCBldmVyeSA1IHNlY29uZHMgdG8ga2VlcCBj YWNoZSBpbiBTVEFMRSBzdGF0ZSAoZm9yIHRoZSBjYXNlIG9mIHZlcnkgY2FyZWZ1bCB2ZW5kb3Ig aW1wbGVtZW50YXRpb24gb2YgTkQpLjxicj4NCiZndDsgQXMgeW91IG1lbnRpb25lZCAtIG5vIGhl bHAgZnJvbSBNTEQgc25vb3Bpbmcgb24gc3dpdGNoZXMgLSBpdCB3b3VsZCBiZSBlbm91Z2ggdG8g anVzdCBsaXN0ZW4gdG8gREFELiBTd2l0Y2ggY291bGQgbm90IGhlbHAgaW4gcHJpbmNpcGxlLjxi cj4NCjxicj4NClN0cmljdGx5IHNwZWFraW5nLCBpZiB0aGUgc3dpdGNoaW5nIGluZnJhc3RydWN0 dXJlIGltcGxlbWVudHMgTUxEIHNub29waW5nLCB0aGUgYXR0YWNrZXIgd291bGQgbmVlZCBlaXRo ZXIgdG8gZ3Vlc3MgdGhlIGxvd2VyIDI0IGJpdHMgb2YgdGhlIHZpY3RpbSdzIGFkZHJlc3Mgb3Ig dG8gam9pbiAyXjI0IHNvbGljaXRlZCBub2RlIG11bHRpY2FzdCBhZGRyZXNzIGdyb3Vwcy48YnI+ DQo8YnI+DQomZ3Q7IFRoZSBmaXJzdCBtb2RpZmllZCBETlMgcmVzcG9uc2Ugd291bGQgY29udmVy dCB0cmFmZmljIGZsb3cgdG8gYmktZGlyZWN0aW9uYWwgZm9yIEludHJ1ZGVyLjxicj4NCjxicj4N ClRoYXQncyB3aHkgRE5TU0VDIGFuZCBETlMgb3ZlciBUTFMgYW5kIEhUVFBTIGFyZSBnb29kIGZv ciBzZWN1cml0eS48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyBGcm9tOiBKZW4gTGlua292YSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpmdXJyeTEz QGdtYWlsLmNvbSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5m dXJyeTEzQGdtYWlsLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiAzMCDQuNGO0LvRjyAyMDIwINCz LiA1OjA3PGJyPg0KJmd0OyBUbzogVmFzaWxlbmtvIEVkdWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj52YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4N CiZndDsgQ2M6IDZtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiByZWw9Im5v cmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLi5vcmciIHJlbD0ibm9yZWZlcnJlciBub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJq ZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxIC0gYWRkaXRpb25h bCA8YnI+DQomZ3Q7IHNlY3VyaXR5IGNvbmNlcm5zPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVGh1 LCBKdWwgMzAsIDIwMjAgYXQgNTo1NiBBTSBWYXNpbGVua28gRWR1YXJkICZsdDs8YSBocmVmPSJt YWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgJmd0OyBZb3UgZGlkIGFzayBhIGZlZWRiYWNrIHllc3RlcmRheSBh Ym91dCBzZXZlcml0eSBvZiA3c2VjIHNlY3VyaXR5IGhvbGUgdGhhdCBoYXMgdmVyeSBsb3cgcHJv YmFiaWxpdHkuPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBpbnRlbnRpb24gaGVyZSB0byBzaG93IHRo YXQgcHJvYmFiaWxpdHkgaXMgMTAwJSwgN3NlYyBjb3VsZCBiZSBwcm9sb25nZWQgdG8gZm9yZXZl ciwgYW5kIHRoZSBmaW5hbCByZXN1bHQgaXMgdGhlIGZ1bGwgaW50ZXJjZXB0aW9uIG9mIGlubm9j ZW50IGhvc3QgdHJhZmZpYyBieSBpbnRydWRlciAoc3VjY2Vzc2Z1bCAmcXVvdDttYW4taW4tdGhl LW1pZGRsZSZxdW90OykuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFByZS1yZXF1ZXN0 IGZvciBzdWNjZXNzOjxicj4NCiZndDsgJmd0OyAtIG5vIG11bHRpY2FzdCBzbm9vcGluZyAoTUxE KSBhbmQgZmlsdGVyaW5nIG9uIGEgc3dpdGNoLCB0aGF0IGlzIDxicj4NCiZndDsgJmd0OyBwZXJm ZWN0bHkgcG9zc2libGU8YnI+DQomZ3Q7ICZndDsgLSBJbnRydWRlciBzaG91bGQgYmUgYWxyZWFk eSBvbiB0aGUgc2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXIgPGJyPg0KJmd0OyAmZ3Q7 IG90aGVyIGhvc3QgYnkgZXhwbG9pdGluZyBvZiBkaWZmZXJlbnQgdnVsbmVyYWJpbGl0eSk8YnI+ DQomZ3Q7ICZndDsgLSBpbnRydWRlciBzaG91bGQgc3VwcHJlc3MgREFEIG9uIEludHJ1ZGVyJ3Mg Y29udHJvbGxlZCBob3N0IChpcyA8YnI+DQomZ3Q7ICZndDsgV2luZG93cyBmaXJld2FsbCBjYXBh YmxlIHRvIGZpbHRlciBvdXQgREFEPyk8YnI+DQomZ3Q7ICZndDsgLSBXZSBhc3N1bWUgdGhhdCB3 ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgZnV0dXJlIHdoZW4gdGhpcyBkcmFmdCBpcyA8YnI+DQom Z3Q7ICZndDsgdXNlZCBieSBtYWpvcml0eSBvZiBub2RlcyAodmljdGltIHNob3VsZCB1c2UgaXQp PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFByb2NlZHVyZTo8YnI+DQomZ3Q7ICZndDsg SW50cnVkZXIncyBjb250cm9sbGVkIGhvc3QgZG9lcyBsaXN0ZW4gdG8gYWxsLXJvdXRlcnMgbXVs dGljYXN0IGFkZHJlc3MgKGZmMDI6OjIpLjxicj4NCiZndDsgJmd0OyBBcyBzb29uIGFzIGl0IHdv dWxkIGVhdmVzZHJvcCB1bnNvbGljaXRlZCBOQSBmcm9tIHZpY3RpbSBub2RlIChwcm9iYWJseSBh ZnRlciBib290KSAtIEludHJ1ZGVyIHdvdWxkIGltbWVkaWF0ZWx5IChhIGZldyBtaWxsaXNlY29u ZHMpIGR1cGxpY2F0ZSBOQSBpbiByb3V0ZXIncyBkaXJlY3Rpb24sIGJ1dCB3aXRoIDIgY2hhbmdl czogKDEpIGhpcyBMTEEgKE1BQyk7ICgyKSBPdmVycmlkZSBiaXQgc2V0Ljxicj4NCiZndDsgJmd0 OyBJbnRydWRlciBoYXMgdGltZSBvbmx5IHVwIHRvIHRoZSBwb2ludCB0aGF0IHJlc3BvbnNlIHRv IHZpY3RpbSdzIHRyYWZmaWMgd291bGQgYmUgcmV0dXJuZWQgZnJvbSB0aGUgSW50ZXJuZXQgKGZy b20gdGVucyBvZiBtaWxsaXNlY29uZHMgdG8gbWFueSBzZWNvbmRzIGlmIHZpY3RpbSB3b3VsZCBu b3Qgc3RhcnQgc2VuZGluZyBpbW1lZGlhdGVseSksIC0gYnV0IGl0IGlzIGVub3VnaCB0aW1lOiBs b2NhbCBjb21tdW5pY2F0aW9uIHNob3VsZCBiZQ0KIGZhc3Rlci48YnI+DQomZ3Q7ICZndDsgVGhl b3JldGljYWxseSwgUmV0cmFuc1RpbWVyIHNob3VsZCBiZSBpbXBvc2VkIG9uIHVuc29saWNpdGVk IE5BIChzZWN0aW9uIDcuMi42KSwgYnV0IGxvdyBjaGFuY2VzIHRoYXQgdGhpcyB0aW1lciBpcyBj aGVja2VkIG9uIHJlY2VpdmluZyBzaWRlIChyb3V0ZXIpLCBiZWNhdXNlIFJldHJhbnNUaW1lciBp cyBzcGVjaWZpZWQgZm9yIHRyYW5zbWlzc2lvbiBzaWRlLjxicj4NCiZndDsgJmd0OyBBY2NvcmRp bmcgUkZDIDQ2ODEgc2VjdGlvbiA3LjIuNSBjbGF1c2UgSUk6IE8gYml0IHNldCBzaG91bGQgbm90 IGp1c3QgcmV3cml0ZSBORCBjYWNoZSwgYnV0IGFkZGl0aW9uYWxseSBtYXJrIE5EIHJlY29yZCBh cyBSRUFDSEFCTEUuIEFjY29yZGluZyB0byBzZWN0aW9uIDcuMi42OiAmcXVvdDsgVGhlIE92ZXJy aWRlIGZsYWcgKGZvciB1bnNvbGljaXRlZCBOQSkgTUFZIGJlIHNldCB0byBlaXRoZXIgemVybyBv ciBvbmUmcXVvdDsuIERlc3BpdGUgaXQgY29udHJhZGljdHMNCiB0byB0aGUgbG9naWMgb2YgdGhl IHdob2xlIFJGQyA0NjgxIChPIGJpdCBzaG91bGQgbm90IGJlIHNldCBpbiB1bnNvbGljaXRlZCBO QSAtIGl0IGlzIG1lbnRpb25lZCBpbiBhIGZldyBwbGFjZXMgb2YgUkZDIDQ2ODEpLiBCdXQgYmVj YXVzZSBzZWN0aW9uIDcuMi41IGFuZCBzZWN0aW9uIDcuMi42IGNsZWFybHkgcGVybWl0IHRvIHVz ZSBPdmVycmlkZSBmbGFnIC0gaGlnaGVyIHByb2JhYmlsaXR5IHRoYXQgcGFydGljdWxhciBpbXBs ZW1lbnRhdGlvbg0KIHdvdWxkIG5vdCBqdXN0IHJld3JpdGUgTExBIG9uIHJvdXRlciwgYnV0IGFk ZGl0aW9uYWxseSBwdXQgaXQgaW50byBSRUFDSEFCTEUuPGJyPg0KJmd0OyAmZ3Q7IEludHJ1ZGVy IGNvdWxkIGJlIHN1cmUgdGhhdCBhdCBsZWFzdCBTVEFMRSBzdGF0ZSB3b3VsZCBiZSBjcmVhdGVk IGFjY29yZGluZyB0byBzZWN0aW9uIDcuMi41IGNsYXVzZSBJLCAtIHRoaXMgTkQgcmVjb3JkIHdv dWxkIGJlIGFnYWluc3QgaGlzIExMQSBhbnl3YXkuPGJyPg0KJmd0OyAmZ3Q7IEFmdGVyIHJlY2Vp dmluZyByZXR1cm4gdHJhZmZpYyAoaWYgaXQgd2FzIGNyZWF0ZWQgYXMgU1RBTEUsIG5vdCBSRUFD SEFCTEUpIC0gcm91dGVyIHdvdWxkIGFzayBpbnRydWRlciBhYm91dCByZWFjaGFiaWxpdHkgKHNv bGljaXRlZCBOUy1OQSkgLSBpbnRydWRlciB3b3VsZCBjb25maXJtIGhpcyBMTEEgLSBpdCB3b3Vs ZCBmaW5hbGx5IHB1dCBORCBjYWNoZSByZWNvcmQgaW50byBSRUFDSEFCTEUuPGJyPg0KJmd0Ozxi cj4NCiZndDsgMSkgdGhlIDcgc2Vjb25kcyBjb3JuZXIgY2FzZSB3YXMgZm9yICdwcmV2ZW50aW5n IGFkZHJlc3MgY29sbGlzaW9uIGZvciBPcHRpbWlzdGljIERBRCcsIG5vdCBmb3IgYW55IGludGVu dGlvbmFsIGF0dGFja3MgY2FzZS4gQmVjYXVzZTo8YnI+DQomZ3Q7IDIpIFdoYXQgeW91IGFyZSBk ZXNjcmliaW5nIGNvdWxkIGJlIGRvbmUgdG9kYXksIG5vdywgYW55dGltZSB3L28gdGhlIGNoYW5n ZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29waW5nIHRo ZW4gdGhlIGludHJ1ZGVyIHdvdWxkIHNlZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2aWN0aW0s IHNvIGl0IHdvdWxkIGtub3cgdGhlIHZpY3RpbSBhZGRyZXNzIGFueXdheSZuYnNwOyAtIG5vIHJl YXNvbiBldmVuIHRvIGpvaW4NCiBmZjAyOjoyLiBOb3cgYWxsIHRoZSBhdHRhY2tlciBuZWVkcyB0 byBkbyBpcyB0byBrZWVwIHNlbmRpbmcgTkEgd2l0aCBTPTEsIE89MSAtIGhvcGluZyB0aGF0IHdo ZW4gdGhlIGZpcnN0IHBhY2tldCBvZiB0aGUgcmV0dXJuIGZsb3dzIGFycml2ZSBhbmQgdGhlIHJv dXRlciBjcmVhdGVzIGFuIElOQ09NUExFVEUgZW50cnkgYW5kIHNlbmRzIGFuIE5TLCB0aGUgYXR0 YWNrZXIncyBwYWNrZXQgd291bGQgY29tZSBiZWZvcmUgdGhlIHZpY3RpbSdzIE5BLg0KIERvbmUs IHRoZSZuYnNwOyBlbnRyeSBpcyBjaGFuZ2VkIHRvIFJFQUNIQUJMRSwgYWxsIHRyYWZmaWMgZ29l cyB0byB0aGUgYXR0YWNrZXIuPGJyPg0KJmd0OyBBY3R1YWxseSBldmVuIHNpbXBsZXIuIFRoZSBh dHRhY2tlciBkb2VzIG5vdCBuZWVkIHRvIGRlYWwgd2l0aCB0aW1pbmcuPGJyPg0KJmd0OyBMZXQn cyBzYXkgdGhlIHJvdXRlciBoYXMgYW4gTkMgZW50cnkgZm9yIHRoZSB2aWN0aW0gYWRkcmVzcyBp biBhbnkgb3RoZXIgc3RhdGUgdGhhbiBJTkNPTVBMRVRFLiBUaGUgYXR0YWNrZXIgc2VuZHMgYW4g TkEgd2l0aCBTPTEsIE89MSwgVGFyZ2V0IGFkZHJlc3MgPSB0aGUgdmljdGltJ3MgSVB2NiBhZGRy ZXNzLCB0aGUgVExMQSA9IHRoZSBhdHRhY2tlciBNQUMgYWRkcmVzcy4mbmJzcDsgRG9uZS4gVGhl IHJvdXRlciB1cGRhdGVzIHRoZSBjYWNoZSBlbnRyeQ0KIGFuZCBjaGFuZ2VzIGl0IHRvIFJFQUNI QUJMRSBzdGF0ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBpcyBub3RoaW5nIG5ldyBoZXJl LiBXZSBoYXZlIHRoZSBzYW1lIGlzc3VlIHdpdGggQVJQIC0gdGhlIGF0dGFja2VyIGNhbiBvdmVy cmlkZSBBUlAgZW50cnkgb24gdGhlIHJvdXRlci48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRo YXQncyBpdDogdXBzdHJlYW0gdHJhZmZpYyBvZiB2aWN0aW0gaG9zdCBpcyBnb2luZyB0byByb3V0 ZXIsIHRyYWZmaWMgYmFjayBpcyBnb2luZyB0aHJvdWdoIEludHJ1ZGVyLjxicj4NCiZndDsgJmd0 OyBJIGhhdmUgY29uc3VsdGVkIHdpdGggcGVuZXRyYXRpb24gdGVzdHMgcHJvZmVzc2lvbmFsICh0 aGVzZSBhcmUgcGVvcGxlIHdpdGggdGhlIHNhbWUgcXVhbGlmaWNhdGlvbiBhcyBoYWNrZXJzIGJ1 dCB0aGV5IHBsYXkgb24gbGVnYWwgc2lkZSk6IHdoYXQgaGUgd291bGQgYmUgZG9pbmcgbmV4dD8g SGUgc2FpZCB0aGF0IGhlIHdvdWxkIHJldHVybiB0cmFmZmljIHRvIGxlZ2l0aW1hdGUgaG9zdCAt IHZpY3RpbSBzaG91bGQgbm90IHNlZSBwZXJmb3JtYW5jZQ0KIGRlZ3JhZGF0aW9uLiBIZSB3b3Vs ZCBjb2xsZWN0IGNvb2tpZXMgYW5kIHNvbWUgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIEhl IHdvdWxkIGZpbmFsbHkgc2VlIEROUyByZXNwb25zZSwgY2hhbmdlIGl0IGFuZCByZWRpcmVjdCBl dmVyeXRoaW5nIHRvIGhpbXNlbGYgb24gdGhlIHBlcm1hbmVudCBiYXNpcyAtIGhlIGRvZXMgd2Fu dCB0byBzZWUgYm90aCBkaXJlY3Rpb25zIG9mIHZpY3RpbSBleGNoYW5nZS4gSGUgaGFzIHF1YWxp ZmllZCBNYW4taW4tdGhlLW1pZGRsZQ0KIGFzIGZ1bGwgZmlhc2NvIC0gaXQgZG9lcyBvcGVuIG1h bnkgb3Bwb3J0dW5pdGllcyBmb3IgaGltLiBIZSBoYXMgbWVudGlvbmVkIHZlcnkgZ29vZCBmZWF0 dXJlIG9mIHRoaXMgZHJhZnQgdGhhdCB0aGVyZSBpcyBubyBhbnkgaW50ZXJydXB0aW9uIGZvciB2 aWN0aW0ncyB0cmFmZmljIGZsb3csIG5vIGFueSBleGNlc3NpdmUgdHJhZmZpYyB0byB2aWN0aW0s IHRoYXQgaXMgdmVyeSByZWFyIGJlbmVmaXQgZm9yIGhhY2tlcidzIHRvb2wuPGJyPg0KJmd0Ozxi cj4NCiZndDsgRm9yIGFsbCB0aGF0IGRvb20gYW5kIGdsb29tIHRoZSBhdHRhY2tlciB3b3VsZCBh bHNvIG5lZWQgdG8gc2VlIHRoZSB0cmFmZmljICpmcm9tKiB0aGUgdmljdGltLiBBc3N1bWluZyB0 aGUgbmV0d29yayBoYXMgUkEgR3VhcmQgaW4gcGxhY2UgaXQgd291bGQgYmUgYSBiaXQgaGFyZGVy LiBJZiB0aGUgbmV0d29yayBkb2VzIG5vdCBoYXZlIFJBIEd1YXJkIG91ciBwb29yIHZpY3RpbSBo YXMgbXVjaCBiaWdnZXIgcHJvYmxlbXMgYWxyZWFkeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IFdoYXQgdG8gZG8gYWJvdXQgaXQ/PGJyPg0KJmd0OyAmZ3Q7IDEuIFBvdGVudGlhbGx5IGl0IGlz IHBvc3NpYmxlIHRvIGRvIFJQRi1saWtlIGNoZWNrIGZvciBTb3VyY2UgTExBIGFkZHJlc3Nlcy4g VXBzdHJlYW0gdHJhZmZpYyBmcm9tIHZpY3RpbSdzIFNMTEEgd291bGQgbm90IGJlIGluIE5EIGNh Y2hlIC0gc3VjaCB0cmFmZmljIGNvdWxkIGJlIGRpc2NhcmRlZC4gSXQgaXMgYmV0dGVyIHRvIGJs b2NrIGNvbW11bmljYXRpb24gdGhhbiBwZXJtaXQgaW50cnVkZXIgdG8gZXhwbG9pdCB2dWxuZXJh YmlsaXR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgMi4gSW5jcmVhc2UgUmV0cmFuc1RpbWVy IGFuZCBhc2sgcmVjZWl2ZXIgc2lkZSAocm91dGVyKSB0byBjaGVjayBvbiBzZW5kaW5nIHNpZGUg ZGVsYXkgYmV0d2VlbiBORCByZWNvcmQgb3ZlcnJpZGUgKGZvciB0aGUgc2FtZSBTTExBKS4gQnV0 IGhvdyBsb25nIHNob3VsZCBiZSB0aGUgdGltZXI/IEhvc3QgY291bGQgd2FpdCBhIGxvLW8tby1u ZyB0aW1lIGJlZm9yZSBpdCB3b3VsZCByZXF1ZXN0IDFzdCBpbmZvcm1hdGlvbiBmcm9tIGludGVy bmV0Lg0KIEl0IHdvdWxkIGRlY3JlYXNlIHByb2JhYmlsaXR5LCBidXQgd291bGQgbm90IGNvbXBs ZXRlbHkgZWxpbWluYXRlIGF0dGFjayB2ZWN0b3IuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IE15IHByb3Bvc2l0aW9uIGZvciB0aGlzIGRyYWZ0IGlzIGRpc3J1cHRpdmU6PGJyPg0KJmd0 OyAmZ3Q7IEkgYmVsaWV2ZSB0aGF0IE5EIGlzIHZlcnkgY29tcGxpY2F0ZWQgKHNvbWUgY291bGQg c2F5ICZxdW90O2ZyYWdpbGUmcXVvdDspIC0gaXQgaXMgYmV0dGVyIG5vdCB0byB0b3VjaCBpdC48 YnI+DQomZ3Q7ICZndDsgQWRkaXRpb25hbGx5IEkgZG8gbm90IGxpa2UgdG8gd2FpdCB0aWxsIGFs bCBob3N0cyB3b3VsZCByZWZyZXNoIHRvIG5ldyBkcmFmdCAodG8gZ2V0IG5ldyBmdW5jdGlvbmFs aXR5KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZWxsLCBvbmx5IGhvc3RzIHdoaWNoIHdhbnQgdG8g Y29ubmVjdCB0byB0aGUgbmV0d29yayBmYXN0ZXIgbmVlZCB0byBpbXBsZW1lbnQgdGhpcy4gU28g aG9zdCBPUyBkZXZlbG9wZXJzIGhhdmUgcHJldHR5IGdvb2QgaW5jZW50aXZlIGhlcmUuPGJyPg0K Jmd0OyBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgdGhlIHByb3Bvc2VkIGJlaGF2aW9yIGlzIG5v dCBjdXJyZW50bHkgcHJvaGliaXRlZC4gV2UgYXJlIG5vdCBjaGFuZ2luZyBhbnkgTVVTVCBOT1Qg dG8gYW55dGhpbmcgZWxzZS4gQWxsIHdlIGFyZSBkb2luZyBpcyB0byBtYWtpbmcgc29tZSByZWNv bW1lbmRhdGlvbnMgbW9yZSBleHBsaWNpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgcHJv cG9zZSB0byBjaGFuZ2Ugb25seSByb3V0ZXIgYmVoYXZpb3I6IGNoZWNrIFNvdXJjZSBMTEEgKE1B QykgZm9yIGV2ZXJ5IHBhY2tldCwgaWYgdGhpcyBTTExBIGlzIGFic2VudCBpbiBORCBjYWNoZSAt IHRoZW4gcmVxdWVzdCBzb2xpY2l0ZWQgTlMtTkEgaW1tZWRpYXRlbHkuIEl0IHdvdWxkIHByb2Jh Ymx5IHJlc29sdmUgZmFzdGVyIHRoYW4gdHJhZmZpYyB3b3VsZCByZXR1cm4gZnJvbSB0aGUgaW50 ZXJuZXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSGF2ZSB5b3UgY2hlY2tlZCB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQgZHJhZnQ/PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC0wIiByZWw9Im5v cmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUt aW5pdC0wPC9hPjxicj4NCiZndDsgMyNzZWN0aW9uLTMuNzxicj4NCiZndDsgc3BlY2lmaWNhdGxs eT88YnI+DQomZ3Q7IFdoYXQgeW91IGFyZSBwcm9wb3NpbmcgZG9lcyBtYWtlIHNlbnNlLCBob3dl dmVyIGl0IHdvdWxkIG5vdCBoZWxwIGluIGNhc2Ugb2YgbXVsdGlwbGUgcm91dGVycy4gQWxzbyBJ IHJlY2FsbCBzb21lIHBlb3BsZSBoYXZpbmcgc3Ryb25nIG9waW5pb25zIG9uIHBlcmZvcm1hbmNl IGltcGxpY2F0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEVmZmVjdGl2ZWx5IEkgZG8g cHJvcG9zZWQgdGhlIHNhbWUgU0xMQSBSUEYgdGhhdCBpcyBuZWVkZWQgdG8gZml4IGN1cnJlbnQg c29sdXRpb24sIGJ1dDo8YnI+DQomZ3Q7ICZndDsgLSB3aXRob3V0IGFueSBtb2RpZmljYXRpb24g dG8gaG9zdCBPU2VzPGJyPg0KJmd0OyAmZ3Q7IC0gd2l0aG91dCBhbnkgbW9kaWZpY2F0aW9uIG9m IHN0YW5kYXJkIChpdCBpcyBsb2NhbCByZWNvbW1lbmRhdGlvbiA8YnI+DQomZ3Q7ICZndDsgZm9y IHJvdXRlciwgTlMtTkEgaXMgZXhhY3RseSB0aGUgc2FtZSBmcm9tIFJGQyA0NjgxLCBOQSBpcyB1 bmljYXN0IC0gPGJyPg0KJmd0OyAmZ3Q7IGl0IGlzIGltcG9ydGFudCBmb3Igc2VjdXJpdHkpPGJy Pg0KJmd0OyAmZ3Q7IC0gd2l0aG91dCBhbnkgcmlzayB0byBicmVhayBORCBmcmFnaWxlIGFsZ29y aXRobTxicj4NCiZndDsgJmd0OyAtIGl0IGNvdWxkIGJlIG9wdGlvbmFsLCBvciBldmVuIGNvbmZp Z3VyYWJsZSBvbiB0aGUgcm91dGVyIGFzICZxdW90O3ZhbHVlIDxicj4NCiZndDsgJmd0OyBhZGQg ZmVhdHVyZSZxdW90OyBpbiBjb21wZXRpdGl2ZSB0ZW5kZXIgQmVjYXVzZSBpdCBpcyBqdXN0IGJl c3QgcHJhY3RpY2UgcmVjb21tZW5kYXRpb24gLSBtYXkgYmUgaXQgbWFrZSBzZW5zZSB0byBtb3Zl IGl0IHRvICZxdW90O3Y2b3BzJnF1b3Q7Pzxicj4NCiZndDs8YnI+DQomZ3Q7IFNlZSA8YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi12Nm9wcy1uZC1jYWNoZS1pbml0LTAiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1uZC1jYWNoZS1pbml0LTA8L2E+PGJyPg0KJmd0OyAz PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBQUzogTG9va2luZyB0byB0aGUgYWJvdmUgLSB1bnNv bGljaXRlZCBOQSBzaG91bGQgYmUgcmVhbGx5IGRlbGF5ZWQgYnkgYWRkaXRpb25hbCBiaWcgdGlt ZXIgKG5vdCBieSBSZXRyYW5zVGltZXIgdGhhdCBpcyB1c2VkIGZvciBzb2xpY2l0ZWQgTlMvTkEp IGFuZCBjaGVja2VkIG9uIHJlY2VpdmVyIHNpZGUgLSB0aGlzIG1vZGlmaWNhdGlvbiBvZiBzdGFu ZGFyZCBpcyByZWFsbHkgbmVlZGVkIHRvIGNsb3NlIFVuc29saWNpdGVkIE5BIHZ1bG5lcmFiaWxp dHkuPGJyPg0KJmd0OyAmZ3Q7IFNvbWVib2R5IHNhaWQgb24gdGhlIGNhbGwgdGhhdCBpdCBpcyBh bHJlYWR5IGEgZmVhdHVyZSBvZiBzb21lIE9TIChBbmRyb2lkPykgLSBpdCBpcyBiYWQ6IGl0IG1l YW5zIHRoYXQgdGhpcyBPUyBpcyBhbHJlYWR5IHZ1bG5lcmFibGUuPGJyPg0KJmd0Ozxicj4NCiZn dDsgSSB3YXMgc2F5aW5nIHRoYXQgc29tZSByb3V0aW5nIHBsYXRmb3JtcyBoYXZlIHRoaXMgYWxy ZWFkeSBpbXBsZW1lbnRlZC4uIFNlYXJjaCBmb3IgJ2dsZWFuJyBoZXJlOjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9p cHY2X2Jhc2ljL2NvbmZpZ3VyYSIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9j cy9pb3MteG1sL2lvcy9pcHY2X2Jhc2ljL2NvbmZpZ3VyYTwvYT48YnI+DQomZ3Q7IHRpb24vMTUt ZS9pcDZiLTE1LWUtYm9vay9pcDYtbmQtY2FjaGUtbWdtdC5odG1sPGJyPg0KJmd0Ozxicj4NCiZn dDsgQUZBSUsgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB3aGljaCBhcmUgYWxzbyBwcmVwb3B1 bGF0aW5nIE5DIGZyb20gREFEIHBhY2tldHMgYnV0IEkgY2FuIG5vdCBmaW5kIHlvdSBhIHJlZmVy ZW5jZSByaWdodCBub3cuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBGcm9tOiBpcHY2IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVy IG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5pcHY2LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2YgSmVuIExpbmtvdmE8YnI+DQomZ3Q7ICZndDsgU2VudDogMjcg0LjRjtC70Y8g MjAyMCDQsy4gNzo0OTxicj4NCiZndDsgJmd0OyBUbzogNm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlwdjZAaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+aXB2NkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEudHh0PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEhlbGxvLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgLTAxIHZl cnNpb24gYWRkcmVzc2VzIGNvbW1lbnRzIHJlY2VpdmVkICh0aGFua3MgZXZlcnlvbmUgd2hvIHBy b3ZpZGVkIGZlZWRiYWNrKS4gQWxzbywgU2VjdGlvbiAzIChBdm9pZGluZyBEaXNydXB0aW9uKSBo YXMgYmVlbiBleHBhbmRlZCBhbmQgZGlzY3Vzc2VkIGEgY29ybmVyIGNhc2Ugd2hlbiB0d28gZGV2 aWNlcyBzdGFydCB1c2luZyB0aGUgc2FtZSBhZGRyZXNzIGFsbW9zdCBhdCB0aGUgc2FtZSB0aW1l ICh0aGUgc2Vjb25kIGRldmljZQ0KIGNvbmZpZ3VyZXMgYW4gb3B0aW1pc3RpYyBhZGRyZXNzIGFm dGVyIHRoZSByaWdodGZ1bCBvd25lciBzZW50IHNvbWUgcGFja2V0cyBidXQgYmVmb3JlIHRoZSBy ZXR1cm4gdHJhZmZpYyBhcnJpdmVzKS48YnI+DQomZ3Q7ICZndDsgRmVlZGJhY2sgb24gdGhlIHVw ZGF0ZWQgc2VjdGlvbiAzLjM8YnI+DQomZ3Q7ICZndDsgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEjc2VjdGlvbi0zLjMiIHJlbD0i bm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxI3NlY3Rpb24tMy4z PC9hPikgaXMgdmVyeSBtdWNoIGFwcHJlY2lhdGVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBPbiBTdW4sIEp1bCAyNiwgMjAyMCBhdCAxMDoxNCBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuPGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiBHcmF0dWl0b3VzIE5laWdoYm9yIERpc2NvdmVyeTogQ3JlYXRpbmcgTmVpZ2hib3IgQ2FjaGUg RW50cmllcyBvbiBGaXJzdC1Ib3AgUm91dGVyczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgOiBKZW4gTGlua292YTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0ZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog ZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxLnR4dDxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs6IDEyPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDogMjAyMC0wNy0yNTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg QWJzdHJhY3Q6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IE5laWdoYm9yIERpc2Nv dmVyeSAoUkZDNDg2MSkgaXMgdXNlZCBieSBJUHY2IG5vZGVzIHRvIGRldGVybWluZSB0aGU8YnI+ DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgbGluay1sYXllciBhZGRyZXNzZXMgb2YgbmVp Z2hib3Jpbmcgbm9kZXMgYXMgd2VsbCBhcyB0byBkaXNjb3ZlciBhbmQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgbWFpbnRhaW4gcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLiZuYnNw OyBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNDg2MSB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyBhbGxvdyByb3V0ZXJzIHRvIHByb2FjdGl2ZWx5IGNyZWF0ZSBhIE5laWdoYm9y IENhY2hlIGVudHJ5IHdoZW4gYSBuZXc8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg SVB2NiBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIGEgbm9kZS4mbmJzcDsgSXQgYWxzbyB1cGRhdGVz IFJGQzQ4NjEgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IHJlY29tbWVuZHMg bm9kZXMgdG8gc2VuZCB1bnNvbGljaXRlZCBOZWlnaGJvciBBZHZlcnRpc2VtZW50cyB1cG9uPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGFzc2lnbmluZyBhIG5ldyBJUHY2IGFkZHJl c3MuJm5ic3A7IFRoZSBwcm9wb3NlZCBjaGFuZ2Ugd2lsbCBtaW5pbWl6ZSB0aGU8YnI+DQomZ3Q7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgZGVsYXkgYW5kIHBhY2tldCBsb3NzIHdoZW4gYSBub2Rl IGluaXRpYXRlIGNvbm5lY3Rpb25zIHRvIG9mZi1saW5rPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7IGRlc3RpbmF0aW9uIGZyb20gYSBuZXcgSVB2NiBhZGRyZXNzLjxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLTZtYW4tZ3JhbmQvIiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLTZtYW4tZ3JhbmQvPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLTZtYW4tZ3JhbmQtMDEiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LTZtYW4tZ3JhbmQtMDE8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEiIHJl bD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi02bWFuLWdyYW5k LTAxPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgJmd0OyAm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LTZtYW4tZ3JhbmQtMDEiIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLTZtYW4tZ3JhbmQtMDE8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciBub3Jl ZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgcmVsPSJub3Jl ZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0 OyAmZ3Q7IC0tIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCA8YSBocmVmPSJt YWlsdG86aXB2NkBpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj4NCmlwdjZAaWV0Zi5vcmc8L2E+IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFkbWluaXN0 cmF0aXZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJy ZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2NjwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQomZ3Q7ICZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBTWSwgSmVuIExpbmtvdmEg YWthIEZ1cnJ5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K Jmd0OyAmZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCA8YSBocmVmPSJt YWlsdG86aXB2NkBpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj4NCmlwdjZAaWV0Zi5vcmc8L2E+IEFkbWluaXN0cmF0aXZlIDxicj4NCiZndDsgJmd0 OyBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxi cj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgLS08YnI+DQomZ3Q7IFNZLCBKZW4gTGlua292YSBha2EgRnVycnk8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQotLTxicj4NClNZLCBKZW4gTGlua292YSBha2EgRnVycnk8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgcmVsPSJub3Jl ZmVycmVyIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiBy ZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3Bhbj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj52Nm9wcyBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+djZvcHNAaWV0Zi5vcmc8L3NwYW4+PGJyPg0KPHNw YW4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvc3Bhbj48YnI+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3C1ECB6FE6674200964FAB233A0A56E9ciscocom_-- From nobody Thu Jul 30 22:21:16 2020 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 DA6733A0DDF for ; Thu, 30 Jul 2020 22:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB2TJJmS-b7k for ; Thu, 30 Jul 2020 22:21:13 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE29E3A0D65 for ; Thu, 30 Jul 2020 22:21:12 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id c6so6286514pje.1 for ; Thu, 30 Jul 2020 22:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=cEfP621HQ1gy2PKepEiuAI0tcXBebjRtQtHyuwioOz8=; b=JnEb8p5tAHGuJUlFKqe4Dc2O2g765AUzO+6cAzuNeQIM3gFPVdevonUOTlHqQlUGGs 9R4dL0+1NzoKKeZMFVqVRQMk/gvAuKMWsQc9lb8D5O6dMu/KsVSazHrC53EABNXJvbKc clGliTOsxhdQ2uK8m1haJfbUdEM3YR1tBIUxM4hAYQja2TPIsY032x0wvcvRKiB3bEZx RHSoWig1KWL+cbSMAeoVU2lbqCBLzV9l4SEKYF6chA1OMIewF25O7WCRDWcVFfWKs+Ca BbrvcOubXZ1JqVL5jP4O8uXm3wK04/FV2Sun036Px+fKj3RAAm4E+nHKLgOdzdz9CRYE X5GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=cEfP621HQ1gy2PKepEiuAI0tcXBebjRtQtHyuwioOz8=; b=aXvqAR1pXf1wYiMim4Uyk/hlOmQ6sbMfPQXzXsBUwwV1KaAeROl1HJslG8BvbLvci9 DlJ7apbtXrfeeQVVPMFhqIwuWBSPPbCVVZE/9PpHubrWGuACYX/20XSsC6sqWcFUMYbX M8TmcKHF4vMgodBN61xsdYVgBADChvCcsmsmnHbmmePv5OHH3y5nNZ8N8x2ACyxx31wN hBZjD3RTggWJuesg1gjs+/gJSXcLkZnzzyzu8Lyo9sSVPXixIU4FdvRl57ArnCd6Ps91 InAFPdnuiL5fizWIYTOiZxMvrb84c02Dgqy2KH0N7nLPFKqxEdw5SPHgaVWp036y6Qat +hBA== X-Gm-Message-State: AOAM533+M1mL4ENJpaEagLMcGHP6vHFYtXP9oOGpa1Rj3n3hYaof8WLE pB6uJ4snfBJzgas2oiEBLRaTDd/UJiU= X-Google-Smtp-Source: ABdhPJwO7phG8SLsKo6ZaO+4y9efHiCZPQgn0E0qnnEjpHUYgQUmf9cLwZ6zyr5Sw9V/S6Xty3lZOg== X-Received: by 2002:a17:902:6bc5:: with SMTP id m5mr2317696plt.150.1596172872129; Thu, 30 Jul 2020 22:21:12 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::199f? ([2600:8802:5800:652::199f]) by smtp.gmail.com with ESMTPSA id y4sm8173852pff.44.2020.07.30.22.21.11 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 22:21:11 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 30 Jul 2020 22:21:10 -0700 References: <0A52BDF3-41AE-4A5C-A971-99D82769089D@gmail.com> To: IPv6 Operations In-Reply-To: <0A52BDF3-41AE-4A5C-A971-99D82769089D@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 05:21:15 -0000 I see a few emails supporting adoption, and none saying "no" or = "abstain". Taking the ground rule in a hum that it is imprecise = (otherwise, this might be mistaken for a vote), I take that as support, = but there is not a groundswell of opinion presented. While adoption as a = working group draft says that we want to collectively consider this, = adoption doesn't imply that we are done, and comments in some of the = emails suggested specifically that the draft continues to need work. Jordi, et al, please upload a version named = draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt. In doing so, please tell = the tool that it replaces draft-gont-v6ops-ipv6-ehs-packet-drops. I have asked several people for reviews of the uploaded draft when it is = available, and I would encourage discussion. > On Jul 28, 2020, at 10:55 PM, Fred Baker = wrote: >=20 > It looks like Fernando (et al) revised this and posted draft -04 on = Saturday, and there has been a flurry of discussion. I haven't been = through the document or the entire thread yet, but I do observe that a = number of people have comments, and several people have expressed = interest in the document. >=20 > Let me ask the obvious question: you we want to adopt this as a = working group draft? I won't ask you to hum; whether you wish to say = "yes", "no", or "abstain", please reply to this email *privately* (which = is to say, to v6ops-chairs) with that word prepended on the subject = line. I'll give us 48 hours, which is to say that I will evaluate and = state the result Thursday evening Pacific time. >=20 > = https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D%22draft-gont-v6ops-= ipv6-ehs-packet-drops%22 > https://mailarchive.ietf.org/arch/search/?qdr=3Da&q=3D%22Operational = Implications of IPv6 Packets with Extension Headers%22 > = https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops > "Operational Implications of IPv6 Packets with Extension Headers", = Fernando Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, = 2020-07-25, >=20 From nobody Fri Jul 31 05:23:01 2020 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 8F8C43A116E; Fri, 31 Jul 2020 05:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CvbCG1t-e5t; Fri, 31 Jul 2020 05:22:58 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7F13A10F7; Fri, 31 Jul 2020 05:22:55 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b] (unknown [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C1BA7280B5A; Fri, 31 Jul 2020 12:22:50 +0000 (UTC) To: Tom Herbert , Nick Hilliard Cc: IPv6 Operations , "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" References: <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com> From: Fernando Gont Message-ID: <9f8d77c4-f2b5-2ba3-98d5-4c21770a1bd7@si6networks.com> Date: Fri, 31 Jul 2020 08:55:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 12:23:00 -0000 Hi, Tom, On 29/7/20 18:41, Tom Herbert wrote: [....] >> > > It's not really the same thing. There has been a lot of work in PMTU > discovery mechanisms, but not a lot of work in > Path-Parsing-Buffer-Size discovery. FWIW, some rough measurements I've performed indicate that the drop rate is proportional to the EH length. At the time, I did measurements with lengths such as 8, 256, and 512. If the group thinks more finer-grained data would be of help, then I could run these measurements again, in more detail, and report back to the working group. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jul 31 07:01:45 2020 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 F24893A0B53 for ; Fri, 31 Jul 2020 07:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZb45zEs9yW9 for ; Fri, 31 Jul 2020 07:01:33 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AA63A0A55 for ; Fri, 31 Jul 2020 07:01:33 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id t15so7903745pjq.5 for ; Fri, 31 Jul 2020 07:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JtrjPct49JUf7V7QdyUMcfYpeIH5JQes0Ui2dXrtE/k=; b=jPdT5S+ju7eDV4EHvyu/Ne/VKAAkBOMswjv8b0J6G6e985Rv8KPEzilDiM9BCTaP1z TCTpxO1Hdh+dFdX0Im/tL37rM1yI7QIAzJN+F+zYqMraAZmg7sNpHjO5sovlASzt/LgK srP8IiwTzoNigRcAM8zSyazvrGqSQ1cvA1uaZuuQBiVc6vdV10GHtsJbAO9bM4LMrLAo FKr+qlxzZxYQQqzdMSkOG/+htBGq0QORHY9xl64908/60yRKaWgBjyRbWrm3RW+Cgja2 Ct/kCDsHWlmYNOxK3Zk6Jal+4OKeWz70QkrSPHhXwm4btnRz93nYOIM0yHUl2M0vppOU 5v0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JtrjPct49JUf7V7QdyUMcfYpeIH5JQes0Ui2dXrtE/k=; b=O1Bb7CfoUEJeocdsQxne2mdIgbNjO2AKZ4Wt3Pd1Y9tEuMJ2HiX5/pSiDsIfrrohxF pWsFz5lerLOBoBGcaxAnKabRwCCBdQJUOL++uvV+MrfBm8xqpyIb+qcwdnLEL+4D6HiF eQYGc9P7ZlaywSCRUOLHx2kI0jUSnEk4pI+NzOVtI2Df0JqrtMqDhj7an0nJCMpnsCsY itjao/KXh/Tvzrka5oVEu4QC8j1SQA4+MC6bxzdWJ6hOB5o3EV2e5v6Bk9AQwrHpWmIS CLOY7yuFgYzNysdWKVH4lfmDkMw0ZqN/vp4t8YJVpanyxSAoYVZAiDCcwZNqjZPtUVCW 5XmA== X-Gm-Message-State: AOAM532W1z5Iu4LQe1Rvsgf8t3B/VxlmHMHrzxzFg1G19CCmdsVW0/Pr kfq0AnL4iYVDDGQo3mrsJZc83/0z7xM= X-Google-Smtp-Source: ABdhPJxQ1aEbOedwiZvkTG2FHBrXWwPrZLaBIelLKsQNyituTobm7kW47bSix/GfpjJTQLqGN0u1wA== X-Received: by 2002:a17:902:6f:: with SMTP id 102mr3700118pla.163.1596204092600; Fri, 31 Jul 2020 07:01:32 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:652::199f? ([2600:8802:5800:652::199f]) by smtp.gmail.com with ESMTPSA id c9sm8983096pjr.35.2020.07.31.07.01.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 07:01:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Fred Baker In-Reply-To: <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> Date: Fri, 31 Jul 2020 07:01:31 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <28BE382F-E455-4B22-95FE-18924DF0FCFE@gmail.com> References: <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> To: Fernando Gont , otroan@employees.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 14:01:41 -0000 If I may make a minor suggestion... If you're going to throw brickbats at each other, that seems to be more = appropriate to private exchanges.=20 In 6man, there is a discussion regarding draft-ietf-6man-mtu-option, = which looks at the issue of extension headers, and - based on data - = makes suggestions of how one might use them in a manner that is not = filtered by the network. Their approach seems to not start from "let's = deprecate everything" or "any opinion that disagrees with mine is = idiocy". Frankly, I think there might be value in it. > On Jul 29, 2020, at 3:50 AM, Fernando Gont = wrote: >=20 > On 29/7/20 07:43, otroan@employees.org wrote: >>>> Anyway I don't quite understand what this document adds to work = describing ossification in general >>>=20 >>> Avoiding rehashing the same discussion everytime the issue of EHs = comes up? >> So you are proposing to fully embrace ossification and deprecate all = EHs? >=20 > I'm proposing to document and acknowledge reality. >=20 > Are you proposing to continue in denial? >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 31 07:37:40 2020 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 691963A13C7; Fri, 31 Jul 2020 07:37: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGMn8LOoS0wG; Fri, 31 Jul 2020 07:37:21 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 774243A13AE; Fri, 31 Jul 2020 07:37:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VEbGZO016274; Fri, 31 Jul 2020 10:37:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596206237; bh=iw0hVFkc4Mtq5Gqp4q+Dk/EeKv6rpDxRKobRbFyj+fE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Adyi/qP965/PqVIEMN8snAMLyKpFUQSVN/9leG1pgL8By3THYqG7fW05ALsWdXdoP /+lPxIe89EVsAylBDXlREaGzz4h62weMU42J1DbGyLrjswybjKG+fixwC42sgsma2G 1mZ2+75NkQcZn3zW7J0M5yuOjfFVsQ7FQ9QmOmELcEm6akxU0F28uLdUgGS0t6h3c0 /xIJNSjS5visk6o0/0K49rKkMLliHC/r0zvITRvCEn7XaGcn/Dyjy638PmBg6MRwEF gjXduVq4jLj4yZ0ryets6MrhWTFxx/b7TGOUKtyMXbB0+8xLu+s7YUOMGAqrbVdnx2 CNwL0rL10A5Gg== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VEaxRp013690 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 10:36:59 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 07:36:57 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 07:36:57 -0700 From: "Templin (US), Fred L" To: "Pascal Thubert (pthubert)" , "Mark Smith" CC: v6ops list , 6man Thread-Topic: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AQHWZkg+bCqL1AqpGEC9totP9gCMpakf412AgACQQgCAAC8SAIAAEaZdgAENTIA= Date: Fri, 31 Jul 2020 14:36:57 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> , <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> In-Reply-To: <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 1BA0310AC6AFFFE9EAE76A6711E033F667EF2FEFE4976ABB5531A987A7C4CC902000:8 Content-Type: multipart/alternative; boundary="_000_dfb9ccbfd87140cfba01c69447581aefboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 14:37:29 -0000 --_000_dfb9ccbfd87140cfba01c69447581aefboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGFzY2FsLA0KDQpJIHdpc2ggdGhpcyBncm91cCBjb3VsZCBvcGVuIGl0cyBleWVzLiBORCBh cyBkZWZpbmVkIGluIHRoZSBsYXN0IGNlbnR1cnkgaXMgbm90IHN1aXRlZCBmb3IgbW9kZXJuIGZh YnJpY3MsIHZpcnR1YWwgbWFjaGluZXMgYW5kIHdpcmVsZXNzLiBJdCBpcyBhIHBhaW4gZm9yIHNp bGljb24tYmFzZWQgZm9yd2FyZGluZy4gVGltZSB0byB1cGdyYWRlIGlzIG92ZXJkdWUuDQoNClRo ZXJlIGlzIG5vdGhpbmcgYnJva2VuIHdpdGggSVB2NiBORCB0aGF0IG5lZWRzIGNoYW5naW5nOyBp dCBqdXN0IG5lZWRzIGEgbmV3IG9wdGlvbi4NCldlIGhhdmUgc2VlbiBob3cgdGhhdCBpcyBwb3Nz aWJsZSB0aHJvdWdoIHB1YmxpY2F0aW9ucyBsaWtlIFJGQzg4MDEuDQoNCkJUVywgSVB2NiBpdHNl bGYgaXMgYSBsYXN0LWNlbnR1cnkgdGVjaG5vbG9neSBidXQgdGhlIGFyY2hpdGVjdHMgaGFkIHRo ZSB3aXNkb20gdG8gYWxsb3cNCmZvciBmdXR1cmUgZXh0ZW5zaW9ucyB3aXRob3V0IG5lZWRpbmcg dG8gbW9kaWZ5IHRoZSBjb3JlIGFyY2hpdGVjdHVyZS4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9t OiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMzAsIDIwMjAgMzoyNiBQ TQ0KVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+DQpDYzogdjZvcHMgbGlz dCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogW0VYVEVS TkFMXSBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBh ZGRpdGlvbmFsIHNlY3VyaXR5IGNvbmNlcm5zDQoNCg0KVGhpcyBtZXNzYWdlIHdhcyBzZW50IGZy b20gb3V0c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBh dHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoYXQg dGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQoNCg0KSSBkaXNhZ3JlZSB3aXRoIHRoZSBhbmFsb2d5 LCBNYXJrLg0KDQpJIHN1cHBvcnQgR1JBTkQgYmVjYXVzZSBpdCBpcyBiZXR0ZXIgdGhhbiBub3Ro aW5nIGFuZCBwcm9ncmVzc2luZyBqdXN0IHRoYXQgYXQgNk1BTiBzZWVtcyB0byBiZSBhbiBpbmNy ZWRpYmxlIGFjaGlldmVtZW50IGFscmVhZHkuDQoNCkJ1dCBpbiBhIHdvcmxkIHdl4oCZcmUgYWxs IGFkZHJlc3NlcyBhcmUgcHJvYWN0aXZlbHkgaW5zdGFsbGVkIHRoZSByb3V0ZXIgY291bGQgZWFz aWx5IGRlZmVhdCB0aGUgcmVtb3RlIERPUyBhZ2FpbnN0IHRoZSBjYWNoZSAodGhhdOKAmXMgYW4g UkZDIDg1MDUtb25seSBuZXR3b3JrIGFuZCBkaGNwdjYgdnMgYXV0b2NvbmYgaXMgb3J0aG9nb25h bCB0byB0aGF0LCB3ZSBhcmUgdGFsa2luZyBhYm91dCBwcm92aXNpb25pbmcgdGhlIGNhY2hlIG5v dCBmb3JtaW5nIHRoZSBhZGRyZXNzKQ0KRm9yIHRoZSBpbnNpZGVyIGltcGVyc29uYXRpb24gYXR0 YWNrLCBTZU5EIG1heSBiZSBkZWFkIGJ1dCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLTZsby1hcC1uZC8gSXMgdmVyeSBtdWNoIGFsaXZlLiBUaGUgc2FkIHBvaW50 IGZyb20gYW4gSUVURiBwZXJzcGVjdGl2ZSBpcyB0aGF0IGl0IGRpZCBub3QgY29tZSBmcm9tIDZN QU4uDQoNCkJvdHRvbSBsaW5lIGlzIHRoYXQgdGhlIHNwb29uIGRvbmUgcmlnaHQgd291bGQgbm90 IGxlYWsgdGhlIHNvdXAuDQoNClRvIEplbuKAmXMgcmVmZXJlbmNlIHdlIGRpZCBub3Qgb25seSBk byBnbGVhbmluZyBpbiB0aGUgc3dpdGNoLiBXZSBhbHNvIGRvIGVuZm9yY2VtZW50LiBBbmQgUkEg Z3VhcmQuIEFuZCBSQSB0aHJvdHRsaW5nLiBCdXQgYW4gZW5mb3JjZW1lbnQgYmFzZWQgb24gYSBz bm9vcGVkIHN0YXRlIGlzIGltcGVyZmVjdCBiZWNhdXNlIHdlIGNvdWxkIG1pc3Mgc3R1ZmYuIEFu ZCBpdOKAmXMgYWxsIHByb3ByaWV0YXJ5IHNvIGl0IG1pZ2h0IGJlY29tZSBhIGJhZCBpZGVhIHJl dHJvc3BlY3RpdmVseSBzaG91bGQgdGhlIHByb3RvY29sIGNoYW5nZS4gVGhpcyBpcyB3aHkgMTAr IHllYXJzIGFnbyB3ZSAodGhlIGdyb3VwIHdobyBkZXNpZ25lZCBhbmQgaW1wbGVtZW50ZWQgYWxs IHRoaXMgaW4gQ2lzY28gcm91dGVycykgcHJvcG9zZWQgdGhlIHJlZ2lzdHJhdGlvbiBtb2RlbCB0 aGF0IGVuZGVkIHVwIGFzIFJGQyA4NTA1Lg0KDQpJIHdpc2ggdGhpcyBncm91cCBjb3VsZCBvcGVu IGl0cyBleWVzLiBORCBhcyBkZWZpbmVkIGluIHRoZSBsYXN0IGNlbnR1cnkgaXMgbm90IHN1aXRl ZCBmb3IgbW9kZXJuIGZhYnJpY3MsIHZpcnR1YWwgbWFjaGluZXMgYW5kIHdpcmVsZXNzLiBJdCBp cyBhIHBhaW4gZm9yIHNpbGljb24tYmFzZWQgZm9yd2FyZGluZy4gVGltZSB0byB1cGdyYWRlIGlz IG92ZXJkdWUuDQoNCkluIHRoZSBtZWFudGltZSwga2VlcCBzYWZlLg0KDQpQYXNjYWwNCg0KDQpM ZSAzMCBqdWlsLiAyMDIwIMOgIDIzOjI0LCBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwu Y29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0K77u/DQoNCk9u IEZyaSwgMzEgSnVsIDIwMjAsIDA0OjM1IFZhc2lsZW5rbyBFZHVhcmQsIDx2YXNpbGVua28uZWR1 YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4+IHdyb3Rl Og0KSGkgSmVuLA0KT0suIElQdjYgU0xBQUMgc3VibmV0IGlzIG5vdCBzZWN1cmUgaW4gcHJpbmNp cGxlIGFuZCB3ZSBzaG91bGQgYWJhbmRvbiBhbnkgYXR0ZW1wdCB0byBpbXByb3ZlIGl0Lg0KDQpH UkFORCdzIGdvYWwgaXMgbm90IGFuZCBoYXMgbmV2ZXIgYmVlbiB0byBpbXByb3ZlIHRoZSBzZWN1 cml0eSBvZiBORC4gVGhlcmUgaXMgbm8gc3RhdGVtZW50IHN1Y2ggYXMgIlRoZSBnb2FsIG9mIEdS QU5EIGlzIHRvIGltcHJvdmUgdGhlIHNlY3VyaXR5IG9mIE5ELiINCg0KVGhpcyBkcmFmdCBkZXNj cmliZXMgdGhlIHByb2JsZW0gc3BhY2UuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC8NCg0KVGhlcmUgYXJlIHNvbWUgdXNl ZnVsIHNlY3VyaXR5IGJlbmVmaXRzIG9mIHRoZSB3YXkgaXQgd2lsbCBwcmVwb3B1bGF0ZSByb3V0 ZXJzJyBORCBjYWNoZXMgd2l0aCBub2RlcycgbmV3IGFkZHJlc3Nlcy4gSG93ZXZlciwgaWYgbm9u ZSBvZiB0aG9zZSBiZW5lZml0cyBleGlzdGVkLCBpdCB3b3VsZG4ndCBpbnZhbGlkYXRlIEdSQU5E IGFzIGEgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gR1RBTkQgaXMgZGVzaWduZWQgdG8gc29sdmUu DQoNCk1ha2luZyB0aGUgcHJpbWFyeSBjcml0aWNpc20gb2YgR1JBTkQgYmVpbmcgYWJvdXQgTkQg c2VjdXJpdHkgaXMgbGlrZSBjcml0aWNpc2luZyBhIHNwb29uIGZvciBiZWluZyBhIHRlcnJpYmxl IGtuaWZlLg0KDQpSZWdhcmRzLA0KTWFyay4NCg0KDQoNCkJlY2F1c2Ugc28gbWFueSBwZW9wbGUg YWxyZWFkeSBzcGVudCBzbyBtdWNoIHRpbWUgb24gdGhpcyBtYXR0ZXIgLSBpdCBpcyBqdXN0IGRv ZXMgbm90IG1ha2Ugc2Vuc2UgdG8gdGFsayBhZ2FpbiBhbmQgYWdhaW4uDQpBbmQgdGhlIHByaW1h cnkgc29sdXRpb24gdGhhdCB0aGV5IGZvdW5kIGlzIHRoZSBzdGF0ZWZ1bCAiYmluZGluZyB0YWJs ZSIgb24gdGhlIHN3aXRjaCB0byBtb25pdG9yIGFsbCBORHMgKGxpa2UgREhDUC9BUlAgaW4gSVB2 NCksIHRoYXQgbm90IG1hbnkgdXNlIGFueXdheSAtIHdlIG5lZWQgdG8gZml4IHVuc2VjdXJlIHNv bHV0aW9uLg0KDQpUaGVuIHlvdXIgZGlsZW1tYSBpcyBub3QgaW1wb3J0YW50LCA3c2VjIHRyYWZm aWMgaGlqYWNraW5nIGNvdWxkIG5vdCBoYXBwZW4gdW5pbnRlbnRpb25hbGx5IC0gcHJvYmFiaWxp dHkgZm9yIGFkZHJlc3MgY29sbGlzaW9uIG9uIC82NCBpcyB0b28gbG93LCB3aGF0ZXZlciBJbnRl cmZhY2UgSURzIHdvdWxkIGJlIHVzZWQgKGNvbGxlY3Rpb24gb2YgUkZDcyBleGlzdCkuDQpFZHVh cmQNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKZW4gTGlua292YSBbbWFpbHRv OmZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT5dDQpTZW50OiAzMCDQ uNGO0LvRjyAyMDIwINCzLiAxMjo1OA0KVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4NCkNj OiA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj47IHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbmNlcm5zDQoNCk9u IFRodSwgSnVsIDMwLCAyMDIwIGF0IDY6MDUgUE0gVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtv LmVkdWFyZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiB3 cm90ZToNCj4gVGhlbiBpdCBpcyBub3QgbG9naWNhbCBmb3IgbWU6DQo+IE1hbnkgcGVvcGxlIHVu ZGVyc3RhbmQgdGhhdCAiVW5zb2xpY2l0ZWQgTkEiIGlzIGEgYmlnIHNlY3VyaXR5IGhvbGUNCj4g cGVyIHNlLCBCdXQgaW5zdGVhZCBvZiBmaXhpbmcgaXQgKG1heSBiZSBldmVuIGRlcHJlY2F0ZSAt IHNob3VsZCBiZQ0KPiBpbnZlc3RpZ2F0ZWQpDQoNClRoZXJlIGFyZSBtYW55IGF0dGFja3MgcG9z c2libGUgd2l0aGluIHRoZSBzYW1lIEwyIHNlZ21lbnQuIEl0J3Mgbm90IG5ldy4gVGhhdCdzIHdo eSB5b3Ugc2hhbGwgZWl0aGVyIGJsb2NrIHAycCB3aXRoIHRoZSBMQU4gKGlmIHlvdSBkbyBub3Qg dHJ1c3QgZW5kcG9pbnRzIGluIGdlbmVyYWwpIG9yIC0gYmV0dGVyIC0gaG9zdHMgc2hhbGwgdXNl IGVuZDJlbmQgZW5jcnlwdGlvbi4NCg0KPiBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgaXMgYnVp bGRpbmcgb24gdG9wIG9mIGl0Lg0KDQpTb3JyeSwgSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3 aHkgdW5zb2xpY2l0ZWQgTkEgaXMgdGhlIHByb2JsZW0gaGVyZS4uIFRoZSBtZWNoYW5pc20gSSBk ZXNjcmliZWQgaW4gbXkgcHJldmlvdXMgZW1haWwgaXMgdXNpbmcNCipzb2xpY2l0ZWQqIE5BIHRv IG92ZXJyaWRlIHRoZSBuZWlnaGJvciBjYWNoZSBvbiB0aGUgcm91dGVyLg0KDQo+IEl0IHdvdWxk IGFkZGl0aW9uYWxseSBjaGFsbGVuZ2UgdGhpcyBzZWN1cml0eSBwcm9ibGVtIHJlc29sdXRpb24g aW4gdGhlIGZ1dHVyZSENCj4NCj4gQWdhaW46ICJVbnNvbGljaXRlZCBOQSIgd2l0aCBPdmVycmlk ZSBiaXQgc2V0IC0gaXMgYSBkaXNhc3RlciBub3cuDQoNCkFzIHdlbGwgYXMgU29saWNpdGVkLCBy aWdodD8gOykgU2hhbGwgd2UgbG9vayBhdCBTRU5EIGFnYWluPyA7KSBJdCB3b3VsZCBiZSBncmVh dCBidXQgSSdtIG5vdCBhd2FyZSBvZiBpbXBsZW1lbnRhdGlvbnMgYmVpbmcgd2lkZWx5IGRlcGxv eWVkLg0KDQo+IElNSE86IGl0IGlzIGJldHRlciB0byBwcm9oaWJpdCAiVW5zb2xpY2l0ZWQgTkEi LiBMZXQncyB3YWl0IHRpbWVycyBmb3IgdGhlIGNhc2Ugb2YgTUFDIGFkZHJlc3MgY2hhbmdlIG9u IGxlZ2l0aW1hdGUgaG9zdC4NCj4gTWF5IGJlIHdlIGNvdWxkIHRoaW5rIGFib3V0IG90aGVyIHNv bHV0aW9ucy4NCj4gQnV0IGlmIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSB3b3VsZCBiZSBidWls dCBvbiB0b3Agb2YgIlVuc29saWNpdGVkIE5BIiAtIGxlc3Mgb3B0aW9ucyB3b3VsZCBiZSBhdmFp bGFibGUgKCJkZXByZWNhdGUiIHdvdWxkIGJlIG5vdCBhIGNob2ljZSBhbnltb3JlKS4NCj4NCj4g SWYgc29tZXRoaW5nIGlzIGlsbCAtIGl0IHNob3VsZCBiZSBjdXJlZCBmaXJzdCAtIGJvZHlidWls ZGluZyBtYWtlIHNlbnNlIG9ubHkgYWZ0ZXIgdGhpcy4NCj4NCj4gSmVuLCBJIGhhdmUgbm90IHVu ZGVyc3Rvb2QgYmVsb3cgd2h5IHlvdSBkaWQgbWVudGlvbiBSQSBHdWFyZC4gSW50cnVkZXIgZG9l cyBub3QgbmVlZCBpdC4gSGUganVzdCBjbGFpbSAoYnkgVW5zb2xpY2l0ZWQgTkEpIHRoYXQgaGlz IE1BQyBpcyBjb25uZWN0ZWQgdG8gR1VBIG9mIHZpY3RpbS4NCg0KWWVzLCB0byBpbnRlcmNlcHQg dHJhZmZpYyAqdG8qIHRoZSB2aWN0aW0uIEhvdyBpcyBpdCBnb2luZyB0byBpbnRlcmNlcHQgcGFj a2V0cyBzZW50IGJ5IHRoZSB2aWN0aW0/DQoNCj4gSW50cnVkZXIgY291bGQgY2xhaW0gaXQgZXZl cnkgNSBzZWNvbmRzIHRvIGtlZXAgY2FjaGUgaW4gU1RBTEUgc3RhdGUgKGZvciB0aGUgY2FzZSBv ZiB2ZXJ5IGNhcmVmdWwgdmVuZG9yIGltcGxlbWVudGF0aW9uIG9mIE5EKS4NCj4gQXMgeW91IG1l bnRpb25lZCAtIG5vIGhlbHAgZnJvbSBNTEQgc25vb3Bpbmcgb24gc3dpdGNoZXMgLSBpdCB3b3Vs ZCBiZSBlbm91Z2ggdG8ganVzdCBsaXN0ZW4gdG8gREFELiBTd2l0Y2ggY291bGQgbm90IGhlbHAg aW4gcHJpbmNpcGxlLg0KDQpTdHJpY3RseSBzcGVha2luZywgaWYgdGhlIHN3aXRjaGluZyBpbmZy YXN0cnVjdHVyZSBpbXBsZW1lbnRzIE1MRCBzbm9vcGluZywgdGhlIGF0dGFja2VyIHdvdWxkIG5l ZWQgZWl0aGVyIHRvIGd1ZXNzIHRoZSBsb3dlciAyNCBiaXRzIG9mIHRoZSB2aWN0aW0ncyBhZGRy ZXNzIG9yIHRvIGpvaW4gMl4yNCBzb2xpY2l0ZWQgbm9kZSBtdWx0aWNhc3QgYWRkcmVzcyBncm91 cHMuDQoNCj4gVGhlIGZpcnN0IG1vZGlmaWVkIEROUyByZXNwb25zZSB3b3VsZCBjb252ZXJ0IHRy YWZmaWMgZmxvdyB0byBiaS1kaXJlY3Rpb25hbCBmb3IgSW50cnVkZXIuDQoNClRoYXQncyB3aHkg RE5TU0VDIGFuZCBETlMgb3ZlciBUTFMgYW5kIEhUVFBTIGFyZSBnb29kIGZvciBzZWN1cml0eS4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKZW4gTGlua292YSBbbWFp bHRvOmZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT5dDQo+IFNlbnQ6 IDMwINC40Y7Qu9GPIDIwMjAg0LMuIDU6MDcNCj4gVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2ls ZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29t Pj4NCj4gQ2M6IDZtYW4gPGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+PjsgdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYuLm9yZz4NCj4gU3ViamVjdDogUmU6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwNCj4gc2VjdXJpdHkg Y29uY2VybnMNCj4NCj4gT24gVGh1LCBKdWwgMzAsIDIwMjAgYXQgNTo1NiBBTSBWYXNpbGVua28g RWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVh cmRAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPiA+IFlvdSBkaWQgYXNrIGEgZmVlZGJhY2sgeWVzdGVy ZGF5IGFib3V0IHNldmVyaXR5IG9mIDdzZWMgc2VjdXJpdHkgaG9sZSB0aGF0IGhhcyB2ZXJ5IGxv dyBwcm9iYWJpbGl0eS4NCj4gPiBJIGhhdmUgaW50ZW50aW9uIGhlcmUgdG8gc2hvdyB0aGF0IHBy b2JhYmlsaXR5IGlzIDEwMCUsIDdzZWMgY291bGQgYmUgcHJvbG9uZ2VkIHRvIGZvcmV2ZXIsIGFu ZCB0aGUgZmluYWwgcmVzdWx0IGlzIHRoZSBmdWxsIGludGVyY2VwdGlvbiBvZiBpbm5vY2VudCBo b3N0IHRyYWZmaWMgYnkgaW50cnVkZXIgKHN1Y2Nlc3NmdWwgIm1hbi1pbi10aGUtbWlkZGxlIiku DQo+ID4NCj4gPiBQcmUtcmVxdWVzdCBmb3Igc3VjY2VzczoNCj4gPiAtIG5vIG11bHRpY2FzdCBz bm9vcGluZyAoTUxEKSBhbmQgZmlsdGVyaW5nIG9uIGEgc3dpdGNoLCB0aGF0IGlzDQo+ID4gcGVy ZmVjdGx5IHBvc3NpYmxlDQo+ID4gLSBJbnRydWRlciBzaG91bGQgYmUgYWxyZWFkeSBvbiB0aGUg c2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXINCj4gPiBvdGhlciBob3N0IGJ5IGV4cGxv aXRpbmcgb2YgZGlmZmVyZW50IHZ1bG5lcmFiaWxpdHkpDQo+ID4gLSBpbnRydWRlciBzaG91bGQg c3VwcHJlc3MgREFEIG9uIEludHJ1ZGVyJ3MgY29udHJvbGxlZCBob3N0IChpcw0KPiA+IFdpbmRv d3MgZmlyZXdhbGwgY2FwYWJsZSB0byBmaWx0ZXIgb3V0IERBRD8pDQo+ID4gLSBXZSBhc3N1bWUg dGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgZnV0dXJlIHdoZW4gdGhpcyBkcmFmdCBpcw0K PiA+IHVzZWQgYnkgbWFqb3JpdHkgb2Ygbm9kZXMgKHZpY3RpbSBzaG91bGQgdXNlIGl0KQ0KPiA+ DQo+ID4gUHJvY2VkdXJlOg0KPiA+IEludHJ1ZGVyJ3MgY29udHJvbGxlZCBob3N0IGRvZXMgbGlz dGVuIHRvIGFsbC1yb3V0ZXJzIG11bHRpY2FzdCBhZGRyZXNzIChmZjAyOjoyKS4NCj4gPiBBcyBz b29uIGFzIGl0IHdvdWxkIGVhdmVzZHJvcCB1bnNvbGljaXRlZCBOQSBmcm9tIHZpY3RpbSBub2Rl IChwcm9iYWJseSBhZnRlciBib290KSAtIEludHJ1ZGVyIHdvdWxkIGltbWVkaWF0ZWx5IChhIGZl dyBtaWxsaXNlY29uZHMpIGR1cGxpY2F0ZSBOQSBpbiByb3V0ZXIncyBkaXJlY3Rpb24sIGJ1dCB3 aXRoIDIgY2hhbmdlczogKDEpIGhpcyBMTEEgKE1BQyk7ICgyKSBPdmVycmlkZSBiaXQgc2V0Lg0K PiA+IEludHJ1ZGVyIGhhcyB0aW1lIG9ubHkgdXAgdG8gdGhlIHBvaW50IHRoYXQgcmVzcG9uc2Ug dG8gdmljdGltJ3MgdHJhZmZpYyB3b3VsZCBiZSByZXR1cm5lZCBmcm9tIHRoZSBJbnRlcm5ldCAo ZnJvbSB0ZW5zIG9mIG1pbGxpc2Vjb25kcyB0byBtYW55IHNlY29uZHMgaWYgdmljdGltIHdvdWxk IG5vdCBzdGFydCBzZW5kaW5nIGltbWVkaWF0ZWx5KSwgLSBidXQgaXQgaXMgZW5vdWdoIHRpbWU6 IGxvY2FsIGNvbW11bmljYXRpb24gc2hvdWxkIGJlIGZhc3Rlci4NCj4gPiBUaGVvcmV0aWNhbGx5 LCBSZXRyYW5zVGltZXIgc2hvdWxkIGJlIGltcG9zZWQgb24gdW5zb2xpY2l0ZWQgTkEgKHNlY3Rp b24gNy4yLjYpLCBidXQgbG93IGNoYW5jZXMgdGhhdCB0aGlzIHRpbWVyIGlzIGNoZWNrZWQgb24g cmVjZWl2aW5nIHNpZGUgKHJvdXRlciksIGJlY2F1c2UgUmV0cmFuc1RpbWVyIGlzIHNwZWNpZmll ZCBmb3IgdHJhbnNtaXNzaW9uIHNpZGUuDQo+ID4gQWNjb3JkaW5nIFJGQyA0NjgxIHNlY3Rpb24g Ny4yLjUgY2xhdXNlIElJOiBPIGJpdCBzZXQgc2hvdWxkIG5vdCBqdXN0IHJld3JpdGUgTkQgY2Fj aGUsIGJ1dCBhZGRpdGlvbmFsbHkgbWFyayBORCByZWNvcmQgYXMgUkVBQ0hBQkxFLiBBY2NvcmRp bmcgdG8gc2VjdGlvbiA3LjIuNjogIiBUaGUgT3ZlcnJpZGUgZmxhZyAoZm9yIHVuc29saWNpdGVk IE5BKSBNQVkgYmUgc2V0IHRvIGVpdGhlciB6ZXJvIG9yIG9uZSIuIERlc3BpdGUgaXQgY29udHJh ZGljdHMgdG8gdGhlIGxvZ2ljIG9mIHRoZSB3aG9sZSBSRkMgNDY4MSAoTyBiaXQgc2hvdWxkIG5v dCBiZSBzZXQgaW4gdW5zb2xpY2l0ZWQgTkEgLSBpdCBpcyBtZW50aW9uZWQgaW4gYSBmZXcgcGxh Y2VzIG9mIFJGQyA0NjgxKS4gQnV0IGJlY2F1c2Ugc2VjdGlvbiA3LjIuNSBhbmQgc2VjdGlvbiA3 LjIuNiBjbGVhcmx5IHBlcm1pdCB0byB1c2UgT3ZlcnJpZGUgZmxhZyAtIGhpZ2hlciBwcm9iYWJp bGl0eSB0aGF0IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24gd291bGQgbm90IGp1c3QgcmV3cml0 ZSBMTEEgb24gcm91dGVyLCBidXQgYWRkaXRpb25hbGx5IHB1dCBpdCBpbnRvIFJFQUNIQUJMRS4N Cj4gPiBJbnRydWRlciBjb3VsZCBiZSBzdXJlIHRoYXQgYXQgbGVhc3QgU1RBTEUgc3RhdGUgd291 bGQgYmUgY3JlYXRlZCBhY2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIuNSBjbGF1c2UgSSwgLSB0aGlz IE5EIHJlY29yZCB3b3VsZCBiZSBhZ2FpbnN0IGhpcyBMTEEgYW55d2F5Lg0KPiA+IEFmdGVyIHJl Y2VpdmluZyByZXR1cm4gdHJhZmZpYyAoaWYgaXQgd2FzIGNyZWF0ZWQgYXMgU1RBTEUsIG5vdCBS RUFDSEFCTEUpIC0gcm91dGVyIHdvdWxkIGFzayBpbnRydWRlciBhYm91dCByZWFjaGFiaWxpdHkg KHNvbGljaXRlZCBOUy1OQSkgLSBpbnRydWRlciB3b3VsZCBjb25maXJtIGhpcyBMTEEgLSBpdCB3 b3VsZCBmaW5hbGx5IHB1dCBORCBjYWNoZSByZWNvcmQgaW50byBSRUFDSEFCTEUuDQo+DQo+IDEp IHRoZSA3IHNlY29uZHMgY29ybmVyIGNhc2Ugd2FzIGZvciAncHJldmVudGluZyBhZGRyZXNzIGNv bGxpc2lvbiBmb3IgT3B0aW1pc3RpYyBEQUQnLCBub3QgZm9yIGFueSBpbnRlbnRpb25hbCBhdHRh Y2tzIGNhc2UuIEJlY2F1c2U6DQo+IDIpIFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGNvdWxkIGJl IGRvbmUgdG9kYXksIG5vdywgYW55dGltZSB3L28gdGhlIGNoYW5nZXMgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29waW5nIHRoZW4gdGhlIGludHJ1ZGVyIHdv dWxkIHNlZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2aWN0aW0sIHNvIGl0IHdvdWxkIGtub3cg dGhlIHZpY3RpbSBhZGRyZXNzIGFueXdheSAgLSBubyByZWFzb24gZXZlbiB0byBqb2luIGZmMDI6 OjIuIE5vdyBhbGwgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGRvIGlzIHRvIGtlZXAgc2VuZGluZyBO QSB3aXRoIFM9MSwgTz0xIC0gaG9waW5nIHRoYXQgd2hlbiB0aGUgZmlyc3QgcGFja2V0IG9mIHRo ZSByZXR1cm4gZmxvd3MgYXJyaXZlIGFuZCB0aGUgcm91dGVyIGNyZWF0ZXMgYW4gSU5DT01QTEVU RSBlbnRyeSBhbmQgc2VuZHMgYW4gTlMsIHRoZSBhdHRhY2tlcidzIHBhY2tldCB3b3VsZCBjb21l IGJlZm9yZSB0aGUgdmljdGltJ3MgTkEuIERvbmUsIHRoZSAgZW50cnkgaXMgY2hhbmdlZCB0byBS RUFDSEFCTEUsIGFsbCB0cmFmZmljIGdvZXMgdG8gdGhlIGF0dGFja2VyLg0KPiBBY3R1YWxseSBl dmVuIHNpbXBsZXIuIFRoZSBhdHRhY2tlciBkb2VzIG5vdCBuZWVkIHRvIGRlYWwgd2l0aCB0aW1p bmcuDQo+IExldCdzIHNheSB0aGUgcm91dGVyIGhhcyBhbiBOQyBlbnRyeSBmb3IgdGhlIHZpY3Rp bSBhZGRyZXNzIGluIGFueSBvdGhlciBzdGF0ZSB0aGFuIElOQ09NUExFVEUuIFRoZSBhdHRhY2tl ciBzZW5kcyBhbiBOQSB3aXRoIFM9MSwgTz0xLCBUYXJnZXQgYWRkcmVzcyA9IHRoZSB2aWN0aW0n cyBJUHY2IGFkZHJlc3MsIHRoZSBUTExBID0gdGhlIGF0dGFja2VyIE1BQyBhZGRyZXNzLiAgRG9u ZS4gVGhlIHJvdXRlciB1cGRhdGVzIHRoZSBjYWNoZSBlbnRyeSBhbmQgY2hhbmdlcyBpdCB0byBS RUFDSEFCTEUgc3RhdGUuDQo+DQo+IFRoZXJlIGlzIG5vdGhpbmcgbmV3IGhlcmUuIFdlIGhhdmUg dGhlIHNhbWUgaXNzdWUgd2l0aCBBUlAgLSB0aGUgYXR0YWNrZXIgY2FuIG92ZXJyaWRlIEFSUCBl bnRyeSBvbiB0aGUgcm91dGVyLg0KPg0KPiA+IFRoYXQncyBpdDogdXBzdHJlYW0gdHJhZmZpYyBv ZiB2aWN0aW0gaG9zdCBpcyBnb2luZyB0byByb3V0ZXIsIHRyYWZmaWMgYmFjayBpcyBnb2luZyB0 aHJvdWdoIEludHJ1ZGVyLg0KPiA+IEkgaGF2ZSBjb25zdWx0ZWQgd2l0aCBwZW5ldHJhdGlvbiB0 ZXN0cyBwcm9mZXNzaW9uYWwgKHRoZXNlIGFyZSBwZW9wbGUgd2l0aCB0aGUgc2FtZSBxdWFsaWZp Y2F0aW9uIGFzIGhhY2tlcnMgYnV0IHRoZXkgcGxheSBvbiBsZWdhbCBzaWRlKTogd2hhdCBoZSB3 b3VsZCBiZSBkb2luZyBuZXh0PyBIZSBzYWlkIHRoYXQgaGUgd291bGQgcmV0dXJuIHRyYWZmaWMg dG8gbGVnaXRpbWF0ZSBob3N0IC0gdmljdGltIHNob3VsZCBub3Qgc2VlIHBlcmZvcm1hbmNlIGRl Z3JhZGF0aW9uLiBIZSB3b3VsZCBjb2xsZWN0IGNvb2tpZXMgYW5kIHNvbWUgb3RoZXIgdmFsdWFi bGUgaW5mb3JtYXRpb24uIEhlIHdvdWxkIGZpbmFsbHkgc2VlIEROUyByZXNwb25zZSwgY2hhbmdl IGl0IGFuZCByZWRpcmVjdCBldmVyeXRoaW5nIHRvIGhpbXNlbGYgb24gdGhlIHBlcm1hbmVudCBi YXNpcyAtIGhlIGRvZXMgd2FudCB0byBzZWUgYm90aCBkaXJlY3Rpb25zIG9mIHZpY3RpbSBleGNo YW5nZS4gSGUgaGFzIHF1YWxpZmllZCBNYW4taW4tdGhlLW1pZGRsZSBhcyBmdWxsIGZpYXNjbyAt IGl0IGRvZXMgb3BlbiBtYW55IG9wcG9ydHVuaXRpZXMgZm9yIGhpbS4gSGUgaGFzIG1lbnRpb25l ZCB2ZXJ5IGdvb2QgZmVhdHVyZSBvZiB0aGlzIGRyYWZ0IHRoYXQgdGhlcmUgaXMgbm8gYW55IGlu dGVycnVwdGlvbiBmb3IgdmljdGltJ3MgdHJhZmZpYyBmbG93LCBubyBhbnkgZXhjZXNzaXZlIHRy YWZmaWMgdG8gdmljdGltLCB0aGF0IGlzIHZlcnkgcmVhciBiZW5lZml0IGZvciBoYWNrZXIncyB0 b29sLg0KPg0KPiBGb3IgYWxsIHRoYXQgZG9vbSBhbmQgZ2xvb20gdGhlIGF0dGFja2VyIHdvdWxk IGFsc28gbmVlZCB0byBzZWUgdGhlIHRyYWZmaWMgKmZyb20qIHRoZSB2aWN0aW0uIEFzc3VtaW5n IHRoZSBuZXR3b3JrIGhhcyBSQSBHdWFyZCBpbiBwbGFjZSBpdCB3b3VsZCBiZSBhIGJpdCBoYXJk ZXIuIElmIHRoZSBuZXR3b3JrIGRvZXMgbm90IGhhdmUgUkEgR3VhcmQgb3VyIHBvb3IgdmljdGlt IGhhcyBtdWNoIGJpZ2dlciBwcm9ibGVtcyBhbHJlYWR5Lg0KPg0KPiA+IFdoYXQgdG8gZG8gYWJv dXQgaXQ/DQo+ID4gMS4gUG90ZW50aWFsbHkgaXQgaXMgcG9zc2libGUgdG8gZG8gUlBGLWxpa2Ug Y2hlY2sgZm9yIFNvdXJjZSBMTEEgYWRkcmVzc2VzLiBVcHN0cmVhbSB0cmFmZmljIGZyb20gdmlj dGltJ3MgU0xMQSB3b3VsZCBub3QgYmUgaW4gTkQgY2FjaGUgLSBzdWNoIHRyYWZmaWMgY291bGQg YmUgZGlzY2FyZGVkLiBJdCBpcyBiZXR0ZXIgdG8gYmxvY2sgY29tbXVuaWNhdGlvbiB0aGFuIHBl cm1pdCBpbnRydWRlciB0byBleHBsb2l0IHZ1bG5lcmFiaWxpdHkuDQo+DQo+ID4gMi4gSW5jcmVh c2UgUmV0cmFuc1RpbWVyIGFuZCBhc2sgcmVjZWl2ZXIgc2lkZSAocm91dGVyKSB0byBjaGVjayBv biBzZW5kaW5nIHNpZGUgZGVsYXkgYmV0d2VlbiBORCByZWNvcmQgb3ZlcnJpZGUgKGZvciB0aGUg c2FtZSBTTExBKS4gQnV0IGhvdyBsb25nIHNob3VsZCBiZSB0aGUgdGltZXI/IEhvc3QgY291bGQg d2FpdCBhIGxvLW8tby1uZyB0aW1lIGJlZm9yZSBpdCB3b3VsZCByZXF1ZXN0IDFzdCBpbmZvcm1h dGlvbiBmcm9tIGludGVybmV0LiBJdCB3b3VsZCBkZWNyZWFzZSBwcm9iYWJpbGl0eSwgYnV0IHdv dWxkIG5vdCBjb21wbGV0ZWx5IGVsaW1pbmF0ZSBhdHRhY2sgdmVjdG9yLg0KPiA+DQo+ID4gTXkg cHJvcG9zaXRpb24gZm9yIHRoaXMgZHJhZnQgaXMgZGlzcnVwdGl2ZToNCj4gPiBJIGJlbGlldmUg dGhhdCBORCBpcyB2ZXJ5IGNvbXBsaWNhdGVkIChzb21lIGNvdWxkIHNheSAiZnJhZ2lsZSIpIC0g aXQgaXMgYmV0dGVyIG5vdCB0byB0b3VjaCBpdC4NCj4gPiBBZGRpdGlvbmFsbHkgSSBkbyBub3Qg bGlrZSB0byB3YWl0IHRpbGwgYWxsIGhvc3RzIHdvdWxkIHJlZnJlc2ggdG8gbmV3IGRyYWZ0ICh0 byBnZXQgbmV3IGZ1bmN0aW9uYWxpdHkpLg0KPg0KPiBXZWxsLCBvbmx5IGhvc3RzIHdoaWNoIHdh bnQgdG8gY29ubmVjdCB0byB0aGUgbmV0d29yayBmYXN0ZXIgbmVlZCB0byBpbXBsZW1lbnQgdGhp cy4gU28gaG9zdCBPUyBkZXZlbG9wZXJzIGhhdmUgcHJldHR5IGdvb2QgaW5jZW50aXZlIGhlcmUu DQo+IFBsZWFzZSBrZWVwIGluIG1pbmQgdGhhdCB0aGUgcHJvcG9zZWQgYmVoYXZpb3IgaXMgbm90 IGN1cnJlbnRseSBwcm9oaWJpdGVkLiBXZSBhcmUgbm90IGNoYW5naW5nIGFueSBNVVNUIE5PVCB0 byBhbnl0aGluZyBlbHNlLiBBbGwgd2UgYXJlIGRvaW5nIGlzIHRvIG1ha2luZyBzb21lIHJlY29t bWVuZGF0aW9ucyBtb3JlIGV4cGxpY2l0Lg0KPg0KPiA+IEkgcHJvcG9zZSB0byBjaGFuZ2Ugb25s eSByb3V0ZXIgYmVoYXZpb3I6IGNoZWNrIFNvdXJjZSBMTEEgKE1BQykgZm9yIGV2ZXJ5IHBhY2tl dCwgaWYgdGhpcyBTTExBIGlzIGFic2VudCBpbiBORCBjYWNoZSAtIHRoZW4gcmVxdWVzdCBzb2xp Y2l0ZWQgTlMtTkEgaW1tZWRpYXRlbHkuIEl0IHdvdWxkIHByb2JhYmx5IHJlc29sdmUgZmFzdGVy IHRoYW4gdHJhZmZpYyB3b3VsZCByZXR1cm4gZnJvbSB0aGUgaW50ZXJuZXQuDQo+DQo+IEhhdmUg eW91IGNoZWNrZWQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0Pw0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC0w DQo+IDMjc2VjdGlvbi0zLjcNCj4gc3BlY2lmaWNhdGxseT8NCj4gV2hhdCB5b3UgYXJlIHByb3Bv c2luZyBkb2VzIG1ha2Ugc2Vuc2UsIGhvd2V2ZXIgaXQgd291bGQgbm90IGhlbHAgaW4gY2FzZSBv ZiBtdWx0aXBsZSByb3V0ZXJzLiBBbHNvIEkgcmVjYWxsIHNvbWUgcGVvcGxlIGhhdmluZyBzdHJv bmcgb3BpbmlvbnMgb24gcGVyZm9ybWFuY2UgaW1wbGljYXRpb25zLg0KPg0KPiA+IEVmZmVjdGl2 ZWx5IEkgZG8gcHJvcG9zZWQgdGhlIHNhbWUgU0xMQSBSUEYgdGhhdCBpcyBuZWVkZWQgdG8gZml4 IGN1cnJlbnQgc29sdXRpb24sIGJ1dDoNCj4gPiAtIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbiB0 byBob3N0IE9TZXMNCj4gPiAtIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbiBvZiBzdGFuZGFyZCAo aXQgaXMgbG9jYWwgcmVjb21tZW5kYXRpb24NCj4gPiBmb3Igcm91dGVyLCBOUy1OQSBpcyBleGFj dGx5IHRoZSBzYW1lIGZyb20gUkZDIDQ2ODEsIE5BIGlzIHVuaWNhc3QgLQ0KPiA+IGl0IGlzIGlt cG9ydGFudCBmb3Igc2VjdXJpdHkpDQo+ID4gLSB3aXRob3V0IGFueSByaXNrIHRvIGJyZWFrIE5E IGZyYWdpbGUgYWxnb3JpdGhtDQo+ID4gLSBpdCBjb3VsZCBiZSBvcHRpb25hbCwgb3IgZXZlbiBj b25maWd1cmFibGUgb24gdGhlIHJvdXRlciBhcyAidmFsdWUNCj4gPiBhZGQgZmVhdHVyZSIgaW4g Y29tcGV0aXRpdmUgdGVuZGVyIEJlY2F1c2UgaXQgaXMganVzdCBiZXN0IHByYWN0aWNlIHJlY29t bWVuZGF0aW9uIC0gbWF5IGJlIGl0IG1ha2Ugc2Vuc2UgdG8gbW92ZSBpdCB0byAidjZvcHMiPw0K Pg0KPiBTZWUNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLXY2b3BzLW5kLWNhY2hlLWluaXQtMA0KPiAzDQo+DQo+ID4gUFM6IExvb2tpbmcgdG8gdGhl IGFib3ZlIC0gdW5zb2xpY2l0ZWQgTkEgc2hvdWxkIGJlIHJlYWxseSBkZWxheWVkIGJ5IGFkZGl0 aW9uYWwgYmlnIHRpbWVyIChub3QgYnkgUmV0cmFuc1RpbWVyIHRoYXQgaXMgdXNlZCBmb3Igc29s aWNpdGVkIE5TL05BKSBhbmQgY2hlY2tlZCBvbiByZWNlaXZlciBzaWRlIC0gdGhpcyBtb2RpZmlj YXRpb24gb2Ygc3RhbmRhcmQgaXMgcmVhbGx5IG5lZWRlZCB0byBjbG9zZSBVbnNvbGljaXRlZCBO QSB2dWxuZXJhYmlsaXR5Lg0KPiA+IFNvbWVib2R5IHNhaWQgb24gdGhlIGNhbGwgdGhhdCBpdCBp cyBhbHJlYWR5IGEgZmVhdHVyZSBvZiBzb21lIE9TIChBbmRyb2lkPykgLSBpdCBpcyBiYWQ6IGl0 IG1lYW5zIHRoYXQgdGhpcyBPUyBpcyBhbHJlYWR5IHZ1bG5lcmFibGUuDQo+DQo+IEkgd2FzIHNh eWluZyB0aGF0IHNvbWUgcm91dGluZyBwbGF0Zm9ybXMgaGF2ZSB0aGlzIGFscmVhZHkgaW1wbGVt ZW50ZWQuLiBTZWFyY2ggZm9yICdnbGVhbicgaGVyZToNCj4gaHR0cHM6Ly93d3cuY2lzY28uY29t L2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2X2Jhc2ljL2NvbmZpZ3VyYQ0KPiB0aW9u LzE1LWUvaXA2Yi0xNS1lLWJvb2svaXA2LW5kLWNhY2hlLW1nbXQuaHRtbA0KPg0KPiBBRkFJSyB0 aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHdoaWNoIGFyZSBhbHNvIHByZXBvcHVsYXRpbmcgTkMg ZnJvbSBEQUQgcGFja2V0cyBidXQgSSBjYW4gbm90IGZpbmQgeW91IGEgcmVmZXJlbmNlIHJpZ2h0 IG5vdy4NCj4NCj4gPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmVuIExpbmtvdmENCj4g PiBTZW50OiAyNyDQuNGO0LvRjyAyMDIwINCzLiA3OjQ5DQo+ID4gVG86IDZtYW4gPGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+Pg0KPiA+IFN1YmplY3Q6IFJlOiBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEudHh0DQo+ID4NCj4gPiBIZWxsbywNCj4gPg0KPiA+ IFRoZSAtMDEgdmVyc2lvbiBhZGRyZXNzZXMgY29tbWVudHMgcmVjZWl2ZWQgKHRoYW5rcyBldmVy eW9uZSB3aG8gcHJvdmlkZWQgZmVlZGJhY2spLiBBbHNvLCBTZWN0aW9uIDMgKEF2b2lkaW5nIERp c3J1cHRpb24pIGhhcyBiZWVuIGV4cGFuZGVkIGFuZCBkaXNjdXNzZWQgYSBjb3JuZXIgY2FzZSB3 aGVuIHR3byBkZXZpY2VzIHN0YXJ0IHVzaW5nIHRoZSBzYW1lIGFkZHJlc3MgYWxtb3N0IGF0IHRo ZSBzYW1lIHRpbWUgKHRoZSBzZWNvbmQgZGV2aWNlIGNvbmZpZ3VyZXMgYW4gb3B0aW1pc3RpYyBh ZGRyZXNzIGFmdGVyIHRoZSByaWdodGZ1bCBvd25lciBzZW50IHNvbWUgcGFja2V0cyBidXQgYmVm b3JlIHRoZSByZXR1cm4gdHJhZmZpYyBhcnJpdmVzKS4NCj4gPiBGZWVkYmFjayBvbiB0aGUgdXBk YXRlZCBzZWN0aW9uIDMuMw0KPiA+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi02bWFuLWdyYW5kLTAxI3NlY3Rpb24tMy4zKSBpcyB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQu DQo+ID4NCj4gPiBPbiBTdW4sIEp1bCAyNiwgMjAyMCBhdCAxMDoxNCBBTSA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCj4g PiA+DQo+ID4gPg0KPiA+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiA+ID4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBNYWludGVuYW5jZSBXRyBvZiB0aGUgSUVURi4N Cj4gPiA+DQo+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEdyYXR1aXRvdXMgTmVpZ2hi b3IgRGlzY292ZXJ5OiBDcmVhdGluZyBOZWlnaGJvciBDYWNoZSBFbnRyaWVzIG9uIEZpcnN0LUhv cCBSb3V0ZXJzDQo+ID4gPiAgICAgICAgIEF1dGhvciAgICAgICAgICA6IEplbiBMaW5rb3ZhDQo+ ID4gPiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMS50 eHQNCj4gPiA+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTINCj4gPiA+ICAgICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAyMC0wNy0yNQ0KPiA+ID4NCj4gPiA+IEFic3RyYWN0Og0KPiA+ID4g ICAgTmVpZ2hib3IgRGlzY292ZXJ5IChSRkM0ODYxKSBpcyB1c2VkIGJ5IElQdjYgbm9kZXMgdG8g ZGV0ZXJtaW5lIHRoZQ0KPiA+ID4gICAgbGluay1sYXllciBhZGRyZXNzZXMgb2YgbmVpZ2hib3Jp bmcgbm9kZXMgYXMgd2VsbCBhcyB0byBkaXNjb3ZlciBhbmQNCj4gPiA+ICAgIG1haW50YWluIHJl YWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4gIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0ODYxIHRv DQo+ID4gPiAgICBhbGxvdyByb3V0ZXJzIHRvIHByb2FjdGl2ZWx5IGNyZWF0ZSBhIE5laWdoYm9y IENhY2hlIGVudHJ5IHdoZW4gYSBuZXcNCj4gPiA+ICAgIElQdjYgYWRkcmVzcyBpcyBhc3NpZ25l ZCB0byBhIG5vZGUuICBJdCBhbHNvIHVwZGF0ZXMgUkZDNDg2MSBhbmQNCj4gPiA+ICAgIHJlY29t bWVuZHMgbm9kZXMgdG8gc2VuZCB1bnNvbGljaXRlZCBOZWlnaGJvciBBZHZlcnRpc2VtZW50cyB1 cG9uDQo+ID4gPiAgICBhc3NpZ25pbmcgYSBuZXcgSVB2NiBhZGRyZXNzLiAgVGhlIHByb3Bvc2Vk IGNoYW5nZSB3aWxsIG1pbmltaXplIHRoZQ0KPiA+ID4gICAgZGVsYXkgYW5kIHBhY2tldCBsb3Nz IHdoZW4gYSBub2RlIGluaXRpYXRlIGNvbm5lY3Rpb25zIHRvIG9mZi1saW5rDQo+ID4gPiAgICBk ZXN0aW5hdGlvbiBmcm9tIGEgbmV3IElQdjYgYWRkcmVzcy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4g PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQv DQo+ID4gPg0KPiA+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxl IGF0Og0KPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1n cmFuZC0wMQ0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLTZtYW4tZ3JhbmQtMDENCj4gPiA+DQo+ID4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxDQo+ID4gPg0KPiA+ID4NCj4gPiA+ IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYu b3JnPi4NCj4gPiA+DQo+ID4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+ID4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0tIElFVEYgSVB2NiB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPg0KPiA+ID4gQWRtaW5pc3RyYXRpdmUNCj4gPiA+IFJlcXVlc3RzOiBodHRwczovL3d3dy4u aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2Nj4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPg0KPiA+DQo+ ID4NCj4gPiAtLQ0KPiA+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4gPg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+IEFkbWluaXN0cmF0aXZlDQo+ID4gUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2Pg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+ DQo+IC0tDQo+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg0KDQoNCi0tDQpTWSwgSmVuIExp bmtvdmEgYWthIEZ1cnJ5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFp bGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= --_000_dfb9ccbfd87140cfba01c69447581aefboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFBhc2NhbCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkgd2lzaCB0aGlzIGdyb3VwIGNvdWxkIG9w ZW4gaXRzIGV5ZXMuIE5EIGFzIGRlZmluZWQgaW4gdGhlIGxhc3QgY2VudHVyeSBpcyBub3Qgc3Vp dGVkIGZvciBtb2Rlcm4gZmFicmljcywgdmlydHVhbCBtYWNoaW5lcyBhbmQgd2lyZWxlc3MuIEl0 IGlzIGEgcGFpbiBmb3Igc2lsaWNvbi1iYXNlZCBmb3J3YXJkaW5nLiBUaW1lIHRvIHVwZ3JhZGUg aXMgb3ZlcmR1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo ZXJlIGlzIG5vdGhpbmcgYnJva2VuIHdpdGggSVB2NiBORCB0aGF0IG5lZWRzIGNoYW5naW5nOyBp dCBqdXN0IG5lZWRzIGEgbmV3IG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBzZWVu IGhvdyB0aGF0IGlzIHBvc3NpYmxlIHRocm91Z2ggcHVibGljYXRpb25zIGxpa2UgUkZDODgwMS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJUVywgSVB2NiBpdHNl bGYgaXMgYSBsYXN0LWNlbnR1cnkgdGVjaG5vbG9neSBidXQgdGhlIGFyY2hpdGVjdHMgaGFkIHRo ZSB3aXNkb20gdG8gYWxsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Zm9yIGZ1dHVyZSBleHRlbnNpb25z IHdpdGhvdXQgbmVlZGluZyB0byBtb2RpZnkgdGhlIGNvcmUgYXJjaGl0ZWN0dXJlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gaXB2NiBbbWFpbHRvOmlwdjYtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAzMCwgMjAyMCAzOjI2IFBNPGJy Pg0KPGI+VG86PC9iPiBNYXJrIFNtaXRoICZsdDttYXJrenp6c21pdGhAZ21haWwuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gdjZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyA2bWFuICZs dDtpcHY2QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBb djZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwg c2VjdXJpdHkgY29uY2VybnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0 IC43NXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0eWxl PSJ3aWR0aDoxMDAuMCU7bWFyZ2luLWxlZnQ6Ljc1cHQ7bWFyZ2luLXJpZ2h0Oi43NXB0Ij4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3VuZDojOTEwQTE5O3BhZGRpbmc6NS4yNXB0 IDEuNXB0IDUuMjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRo OjEwMC4wJTtiYWNrZ3JvdW5kOiNGREYyRjQ7cGFkZGluZzo1LjI1cHQgMy43NXB0IDUuMjVwdCAx MS4yNXB0O3dvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjEyMSI+VGhpcyBtZXNzYWdlIHdhcyBz ZW50IGZyb20gb3V0c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBub3QgY2xpY2sgbGlua3Mgb3Ig b3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93 IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5JIGRpc2FncmVlIHdpdGggdGhlIGFuYWxvZ3ksIE1hcmsuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5JIHN1cHBvcnQgR1JBTkQgYmVjYXVzZSBpdCBpcyBiZXR0ZXIgdGhhbiBub3RoaW5nIGFu ZCBwcm9ncmVzc2luZyBqdXN0IHRoYXQgYXQgNk1BTiBzZWVtcyB0byBiZSBhbiBpbmNyZWRpYmxl IGFjaGlldmVtZW50IGFscmVhZHkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPkJ1dCBpbiBhIHdvcmxkIHdl4oCZcmUgYWxsIGFkZHJlc3NlcyBhcmUg cHJvYWN0aXZlbHkgaW5zdGFsbGVkIHRoZSByb3V0ZXIgY291bGQgZWFzaWx5IGRlZmVhdCB0aGUg cmVtb3RlIERPUyBhZ2FpbnN0IHRoZSBjYWNoZSAodGhhdOKAmXMgYW4gUkZDIDg1MDUtb25seSBu ZXR3b3JrIGFuZCBkaGNwdjYgdnMgYXV0b2NvbmYNCiBpcyBvcnRob2dvbmFsIHRvIHRoYXQsIHdl IGFyZSB0YWxraW5nIGFib3V0IHByb3Zpc2lvbmluZyB0aGUgY2FjaGUgbm90IGZvcm1pbmcgdGhl IGFkZHJlc3MpPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Rm9yIHRoZSBpbnNpZGVy IGltcGVyc29uYXRpb24gYXR0YWNrLCBTZU5EIG1heSBiZSBkZWFkIGJ1dCZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNmxvLWFwLW5kLyI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bG8tYXAtbmQvPC9h PiZuYnNwO0lzIHZlcnkgbXVjaCBhbGl2ZS4gVGhlDQogc2FkIHBvaW50IGZyb20gYW4gSUVURiBw ZXJzcGVjdGl2ZSBpcyB0aGF0IGl0IGRpZCBub3QgY29tZSBmcm9tIDZNQU4uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5Cb3R0b20gbGluZSBpcyB0aGF0IHRoZSBzcG9vbiBkb25lIHJpZ2h0IHdvdWxkIG5vdCBs ZWFrIHRoZSBzb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VG8gSmVu4oCZcyByZWZlcmVuY2Ugd2UgZGlk IG5vdCBvbmx5IGRvIGdsZWFuaW5nIGluIHRoZSBzd2l0Y2guIFdlIGFsc28gZG8gZW5mb3JjZW1l bnQuIEFuZCBSQSBndWFyZC4gQW5kIFJBIHRocm90dGxpbmcuIEJ1dCBhbiBlbmZvcmNlbWVudCBi YXNlZCBvbiBhIHNub29wZWQgc3RhdGUgaXMgaW1wZXJmZWN0IGJlY2F1c2Ugd2UgY291bGQgbWlz cyBzdHVmZi4NCiBBbmQgaXTigJlzIGFsbCBwcm9wcmlldGFyeSBzbyBpdCBtaWdodCBiZWNvbWUg YSBiYWQgaWRlYSByZXRyb3NwZWN0aXZlbHkgc2hvdWxkIHRoZSBwcm90b2NvbCBjaGFuZ2UuIFRo aXMgaXMgd2h5IDEwJiM0MzsgeWVhcnMgYWdvIHdlICh0aGUgZ3JvdXAgd2hvIGRlc2lnbmVkIGFu ZCBpbXBsZW1lbnRlZCBhbGwgdGhpcyBpbiBDaXNjbyByb3V0ZXJzKSBwcm9wb3NlZCB0aGUgcmVn aXN0cmF0aW9uIG1vZGVsIHRoYXQgZW5kZWQgdXAgYXMgUkZDIDg1MDUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5JIHdpc2ggdGhpcyBncm91cCBjb3VsZCBvcGVuIGl0cyBleWVzLiBORCBhcyBkZWZpbmVkIGlu IHRoZSBsYXN0IGNlbnR1cnkgaXMgbm90IHN1aXRlZCBmb3IgbW9kZXJuIGZhYnJpY3MsIHZpcnR1 YWwgbWFjaGluZXMgYW5kIHdpcmVsZXNzLiBJdCBpcyBhIHBhaW4gZm9yIHNpbGljb24tYmFzZWQg Zm9yd2FyZGluZy4gVGltZSB0byB1cGdyYWRlIGlzIG92ZXJkdWUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5J biB0aGUgbWVhbnRpbWUsIGtlZXAgc2FmZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlBhc2NhbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TGUgMzAganVpbC4gMjAyMCDD oCAyMzoyNCwgTWFyayBTbWl0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFp bC5jb20iPm1hcmt6enpzbWl0aEBnbWFpbC5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj7vu788L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5PbiBGcmksIDMxIEp1bCAyMDIwLCAwNDozNSBWYXNpbGVua28gRWR1YXJkLCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5IaSBKZW4sPGJyPg0KT0suIElQdjYgU0xBQUMgc3Vi bmV0IGlzIG5vdCBzZWN1cmUgaW4gcHJpbmNpcGxlIGFuZCB3ZSBzaG91bGQgYWJhbmRvbiBhbnkg YXR0ZW1wdCB0byBpbXByb3ZlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5HUkFORCdzIGdvYWwgaXMgbm90IGFuZCBoYXMgbmV2ZXIgYmVlbiB0byBpbXByb3ZlIHRo ZSBzZWN1cml0eSBvZiBORC4gVGhlcmUgaXMgbm8gc3RhdGVtZW50IHN1Y2ggYXMgJnF1b3Q7VGhl IGdvYWwgb2YgR1JBTkQgaXMgdG8gaW1wcm92ZSB0aGUgc2VjdXJpdHkgb2YgTkQuJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5UaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgcHJvYmxlbSBzcGFjZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC88L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5UaGVyZSBhcmUgc29tZSB1c2VmdWwgc2VjdXJpdHkgYmVuZWZpdHMgb2YgdGhlIHdheSBpdCB3 aWxsIHByZXBvcHVsYXRlIHJvdXRlcnMnIE5EIGNhY2hlcyB3aXRoIG5vZGVzJyBuZXcgYWRkcmVz c2VzLiBIb3dldmVyLCBpZiBub25lIG9mIHRob3NlIGJlbmVmaXRzIGV4aXN0ZWQsIGl0IHdvdWxk bid0IGludmFsaWRhdGUgR1JBTkQgYXMgYSBzb2x1dGlvbiB0bw0KIHRoZSBwcm9ibGVtIEdUQU5E IGlzIGRlc2lnbmVkIHRvIHNvbHZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TWFraW5nIHRoZSBwcmltYXJ5 IGNyaXRpY2lzbSBvZiBHUkFORCBiZWluZyBhYm91dCBORCBzZWN1cml0eSBpcyBsaWtlIGNyaXRp Y2lzaW5nIGEgc3Bvb24gZm9yIGJlaW5nIGEgdGVycmlibGUga25pZmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NYXJrLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJlY2F1 c2Ugc28gbWFueSBwZW9wbGUgYWxyZWFkeSBzcGVudCBzbyBtdWNoIHRpbWUgb24gdGhpcyBtYXR0 ZXIgLSBpdCBpcyBqdXN0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gdGFsayBhZ2FpbiBhbmQgYWdh aW4uPGJyPg0KQW5kIHRoZSBwcmltYXJ5IHNvbHV0aW9uIHRoYXQgdGhleSBmb3VuZCBpcyB0aGUg c3RhdGVmdWwgJnF1b3Q7YmluZGluZyB0YWJsZSZxdW90OyBvbiB0aGUgc3dpdGNoIHRvIG1vbml0 b3IgYWxsIE5EcyAobGlrZSBESENQL0FSUCBpbiBJUHY0KSwgdGhhdCBub3QgbWFueSB1c2UgYW55 d2F5IC0gd2UgbmVlZCB0byBmaXggdW5zZWN1cmUgc29sdXRpb24uPGJyPg0KPGJyPg0KVGhlbiB5 b3VyIGRpbGVtbWEgaXMgbm90IGltcG9ydGFudCwgN3NlYyB0cmFmZmljIGhpamFja2luZyBjb3Vs ZCBub3QgaGFwcGVuIHVuaW50ZW50aW9uYWxseSAtIHByb2JhYmlsaXR5IGZvciBhZGRyZXNzIGNv bGxpc2lvbiBvbiAvNjQgaXMgdG9vIGxvdywgd2hhdGV2ZXIgSW50ZXJmYWNlIElEcyB3b3VsZCBi ZSB1c2VkIChjb2xsZWN0aW9uIG9mIFJGQ3MgZXhpc3QpLjxicj4NCkVkdWFyZDxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSmVuIExpbmtvdmEgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZnVycnkxM0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mdXJyeTEzQGdt YWlsLmNvbTwvYT5dDQo8YnI+DQpTZW50OiAzMCDQuNGO0LvRjyAyMDIwINCzLiAxMjo1ODxicj4N ClRvOiBWYXNpbGVua28gRWR1YXJkICZsdDs8YSBocmVmPSJtYWlsdG86dmFzaWxlbmtvLmVkdWFy ZEBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29t PC9hPiZndDs8YnI+DQpDYzogNm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pcHY2QGlldGYub3JnPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdjZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0K U3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0 aW9uYWwgc2VjdXJpdHkgY29uY2VybnM8YnI+DQo8YnI+DQpPbiBUaHUsIEp1bCAzMCwgMjAyMCBh dCA2OjA1IFBNIFZhc2lsZW5rbyBFZHVhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28u ZWR1YXJkQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj52YXNpbGVua28uZWR1YXJkQGh1YXdl aS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRoZW4gaXQgaXMgbm90IGxvZ2ljYWwgZm9y IG1lOjxicj4NCiZndDsgTWFueSBwZW9wbGUgdW5kZXJzdGFuZCB0aGF0ICZxdW90O1Vuc29saWNp dGVkIE5BJnF1b3Q7IGlzIGEgYmlnIHNlY3VyaXR5IGhvbGUgPGJyPg0KJmd0OyBwZXIgc2UsIEJ1 dCBpbnN0ZWFkIG9mIGZpeGluZyBpdCAobWF5IGJlIGV2ZW4gZGVwcmVjYXRlIC0gc2hvdWxkIGJl IDxicj4NCiZndDsgaW52ZXN0aWdhdGVkKTxicj4NCjxicj4NClRoZXJlIGFyZSBtYW55IGF0dGFj a3MgcG9zc2libGUgd2l0aGluIHRoZSBzYW1lIEwyIHNlZ21lbnQuIEl0J3Mgbm90IG5ldy4gVGhh dCdzIHdoeSB5b3Ugc2hhbGwgZWl0aGVyIGJsb2NrIHAycCB3aXRoIHRoZSBMQU4gKGlmIHlvdSBk byBub3QgdHJ1c3QgZW5kcG9pbnRzIGluIGdlbmVyYWwpIG9yIC0gYmV0dGVyIC0gaG9zdHMgc2hh bGwgdXNlIGVuZDJlbmQgZW5jcnlwdGlvbi48YnI+DQo8YnI+DQomZ3Q7IEFkZGl0aW9uYWwgZnVu Y3Rpb25hbGl0eSBpcyBidWlsZGluZyBvbiB0b3Agb2YgaXQuPGJyPg0KPGJyPg0KU29ycnksIEkn bSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2h5IHVuc29saWNpdGVkIE5BIGlzIHRoZSBwcm9ibGVt IGhlcmUuLiBUaGUgbWVjaGFuaXNtIEkgZGVzY3JpYmVkIGluIG15IHByZXZpb3VzIGVtYWlsIGlz IHVzaW5nPGJyPg0KKnNvbGljaXRlZCogTkEgdG8gb3ZlcnJpZGUgdGhlIG5laWdoYm9yIGNhY2hl IG9uIHRoZSByb3V0ZXIuPGJyPg0KPGJyPg0KJmd0OyBJdCB3b3VsZCBhZGRpdGlvbmFsbHkgY2hh bGxlbmdlIHRoaXMgc2VjdXJpdHkgcHJvYmxlbSByZXNvbHV0aW9uIGluIHRoZSBmdXR1cmUhPGJy Pg0KJmd0Ozxicj4NCiZndDsgQWdhaW46ICZxdW90O1Vuc29saWNpdGVkIE5BJnF1b3Q7IHdpdGgg T3ZlcnJpZGUgYml0IHNldCAtIGlzIGEgZGlzYXN0ZXIgbm93Ljxicj4NCjxicj4NCkFzIHdlbGwg YXMgU29saWNpdGVkLCByaWdodD8gOykgU2hhbGwgd2UgbG9vayBhdCBTRU5EIGFnYWluPyA7KSBJ dCB3b3VsZCBiZSBncmVhdCBidXQgSSdtIG5vdCBhd2FyZSBvZiBpbXBsZW1lbnRhdGlvbnMgYmVp bmcgd2lkZWx5IGRlcGxveWVkLjxicj4NCjxicj4NCiZndDsgSU1ITzogaXQgaXMgYmV0dGVyIHRv IHByb2hpYml0ICZxdW90O1Vuc29saWNpdGVkIE5BJnF1b3Q7LiBMZXQncyB3YWl0IHRpbWVycyBm b3IgdGhlIGNhc2Ugb2YgTUFDIGFkZHJlc3MgY2hhbmdlIG9uIGxlZ2l0aW1hdGUgaG9zdC48YnI+ DQomZ3Q7IE1heSBiZSB3ZSBjb3VsZCB0aGluayBhYm91dCBvdGhlciBzb2x1dGlvbnMuPGJyPg0K Jmd0OyBCdXQgaWYgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IHdvdWxkIGJlIGJ1aWx0IG9uIHRv cCBvZiAmcXVvdDtVbnNvbGljaXRlZCBOQSZxdW90OyAtIGxlc3Mgb3B0aW9ucyB3b3VsZCBiZSBh dmFpbGFibGUgKCZxdW90O2RlcHJlY2F0ZSZxdW90OyB3b3VsZCBiZSBub3QgYSBjaG9pY2UgYW55 bW9yZSkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgc29tZXRoaW5nIGlzIGlsbCAtIGl0IHNob3Vs ZCBiZSBjdXJlZCBmaXJzdCAtIGJvZHlidWlsZGluZyBtYWtlIHNlbnNlIG9ubHkgYWZ0ZXIgdGhp cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBKZW4sIEkgaGF2ZSBub3QgdW5kZXJzdG9vZCBiZWxvdyB3 aHkgeW91IGRpZCBtZW50aW9uIFJBIEd1YXJkLiBJbnRydWRlciBkb2VzIG5vdCBuZWVkIGl0LiBI ZSBqdXN0IGNsYWltIChieSBVbnNvbGljaXRlZCBOQSkgdGhhdCBoaXMgTUFDIGlzIGNvbm5lY3Rl ZCB0byBHVUEgb2YgdmljdGltLjxicj4NCjxicj4NClllcywgdG8gaW50ZXJjZXB0IHRyYWZmaWMg KnRvKiB0aGUgdmljdGltLiBIb3cgaXMgaXQgZ29pbmcgdG8gaW50ZXJjZXB0IHBhY2tldHMgc2Vu dCBieSB0aGUgdmljdGltPzxicj4NCjxicj4NCiZndDsgSW50cnVkZXIgY291bGQgY2xhaW0gaXQg ZXZlcnkgNSBzZWNvbmRzIHRvIGtlZXAgY2FjaGUgaW4gU1RBTEUgc3RhdGUgKGZvciB0aGUgY2Fz ZSBvZiB2ZXJ5IGNhcmVmdWwgdmVuZG9yIGltcGxlbWVudGF0aW9uIG9mIE5EKS48YnI+DQomZ3Q7 IEFzIHlvdSBtZW50aW9uZWQgLSBubyBoZWxwIGZyb20gTUxEIHNub29waW5nIG9uIHN3aXRjaGVz IC0gaXQgd291bGQgYmUgZW5vdWdoIHRvIGp1c3QgbGlzdGVuIHRvIERBRC4gU3dpdGNoIGNvdWxk IG5vdCBoZWxwIGluIHByaW5jaXBsZS48YnI+DQo8YnI+DQpTdHJpY3RseSBzcGVha2luZywgaWYg dGhlIHN3aXRjaGluZyBpbmZyYXN0cnVjdHVyZSBpbXBsZW1lbnRzIE1MRCBzbm9vcGluZywgdGhl IGF0dGFja2VyIHdvdWxkIG5lZWQgZWl0aGVyIHRvIGd1ZXNzIHRoZSBsb3dlciAyNCBiaXRzIG9m IHRoZSB2aWN0aW0ncyBhZGRyZXNzIG9yIHRvIGpvaW4gMl4yNCBzb2xpY2l0ZWQgbm9kZSBtdWx0 aWNhc3QgYWRkcmVzcyBncm91cHMuPGJyPg0KPGJyPg0KJmd0OyBUaGUgZmlyc3QgbW9kaWZpZWQg RE5TIHJlc3BvbnNlIHdvdWxkIGNvbnZlcnQgdHJhZmZpYyBmbG93IHRvIGJpLWRpcmVjdGlvbmFs IGZvciBJbnRydWRlci48YnI+DQo8YnI+DQpUaGF0J3Mgd2h5IEROU1NFQyBhbmQgRE5TIG92ZXIg VExTIGFuZCBIVFRQUyBhcmUgZ29vZCBmb3Igc2VjdXJpdHkuPGJyPg0KPGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSmVuIExpbmtvdmEgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86ZnVycnkxM0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mdXJy eTEzQGdtYWlsLmNvbTwvYT5dPGJyPg0KJmd0OyBTZW50OiAzMCDQuNGO0LvRjyAyMDIwINCzLiA1 OjA3PGJyPg0KJmd0OyBUbzogVmFzaWxlbmtvIEVkdWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZh c2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVh cmRAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogNm1hbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHY2QGlldGYub3JnPC9hPiZndDs7 IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnY2b3Bz QGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWll dGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwgPGJyPg0KJmd0OyBzZWN1cml0eSBjb25jZXJu czxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgSnVsIDMwLCAyMDIwIGF0IDU6NTYgQU0gVmFz aWxlbmtvIEVkdWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgJmd0OyBZb3UgZGlkIGFzayBhIGZlZWRiYWNrIHllc3RlcmRheSBh Ym91dCBzZXZlcml0eSBvZiA3c2VjIHNlY3VyaXR5IGhvbGUgdGhhdCBoYXMgdmVyeSBsb3cgcHJv YmFiaWxpdHkuPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBpbnRlbnRpb24gaGVyZSB0byBzaG93IHRo YXQgcHJvYmFiaWxpdHkgaXMgMTAwJSwgN3NlYyBjb3VsZCBiZSBwcm9sb25nZWQgdG8gZm9yZXZl ciwgYW5kIHRoZSBmaW5hbCByZXN1bHQgaXMgdGhlIGZ1bGwgaW50ZXJjZXB0aW9uIG9mIGlubm9j ZW50IGhvc3QgdHJhZmZpYyBieSBpbnRydWRlciAoc3VjY2Vzc2Z1bCAmcXVvdDttYW4taW4tdGhl LW1pZGRsZSZxdW90OykuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFByZS1yZXF1ZXN0 IGZvciBzdWNjZXNzOjxicj4NCiZndDsgJmd0OyAtIG5vIG11bHRpY2FzdCBzbm9vcGluZyAoTUxE KSBhbmQgZmlsdGVyaW5nIG9uIGEgc3dpdGNoLCB0aGF0IGlzIDxicj4NCiZndDsgJmd0OyBwZXJm ZWN0bHkgcG9zc2libGU8YnI+DQomZ3Q7ICZndDsgLSBJbnRydWRlciBzaG91bGQgYmUgYWxyZWFk eSBvbiB0aGUgc2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXIgPGJyPg0KJmd0OyAmZ3Q7 IG90aGVyIGhvc3QgYnkgZXhwbG9pdGluZyBvZiBkaWZmZXJlbnQgdnVsbmVyYWJpbGl0eSk8YnI+ DQomZ3Q7ICZndDsgLSBpbnRydWRlciBzaG91bGQgc3VwcHJlc3MgREFEIG9uIEludHJ1ZGVyJ3Mg Y29udHJvbGxlZCBob3N0IChpcyA8YnI+DQomZ3Q7ICZndDsgV2luZG93cyBmaXJld2FsbCBjYXBh YmxlIHRvIGZpbHRlciBvdXQgREFEPyk8YnI+DQomZ3Q7ICZndDsgLSBXZSBhc3N1bWUgdGhhdCB3 ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgZnV0dXJlIHdoZW4gdGhpcyBkcmFmdCBpcyA8YnI+DQom Z3Q7ICZndDsgdXNlZCBieSBtYWpvcml0eSBvZiBub2RlcyAodmljdGltIHNob3VsZCB1c2UgaXQp PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFByb2NlZHVyZTo8YnI+DQomZ3Q7ICZndDsg SW50cnVkZXIncyBjb250cm9sbGVkIGhvc3QgZG9lcyBsaXN0ZW4gdG8gYWxsLXJvdXRlcnMgbXVs dGljYXN0IGFkZHJlc3MgKGZmMDI6OjIpLjxicj4NCiZndDsgJmd0OyBBcyBzb29uIGFzIGl0IHdv dWxkIGVhdmVzZHJvcCB1bnNvbGljaXRlZCBOQSBmcm9tIHZpY3RpbSBub2RlIChwcm9iYWJseSBh ZnRlciBib290KSAtIEludHJ1ZGVyIHdvdWxkIGltbWVkaWF0ZWx5IChhIGZldyBtaWxsaXNlY29u ZHMpIGR1cGxpY2F0ZSBOQSBpbiByb3V0ZXIncyBkaXJlY3Rpb24sIGJ1dCB3aXRoIDIgY2hhbmdl czogKDEpIGhpcyBMTEEgKE1BQyk7ICgyKSBPdmVycmlkZSBiaXQgc2V0Ljxicj4NCiZndDsgJmd0 OyBJbnRydWRlciBoYXMgdGltZSBvbmx5IHVwIHRvIHRoZSBwb2ludCB0aGF0IHJlc3BvbnNlIHRv IHZpY3RpbSdzIHRyYWZmaWMgd291bGQgYmUgcmV0dXJuZWQgZnJvbSB0aGUgSW50ZXJuZXQgKGZy b20gdGVucyBvZiBtaWxsaXNlY29uZHMgdG8gbWFueSBzZWNvbmRzIGlmIHZpY3RpbSB3b3VsZCBu b3Qgc3RhcnQgc2VuZGluZyBpbW1lZGlhdGVseSksIC0gYnV0IGl0IGlzIGVub3VnaCB0aW1lOiBs b2NhbCBjb21tdW5pY2F0aW9uIHNob3VsZCBiZQ0KIGZhc3Rlci48YnI+DQomZ3Q7ICZndDsgVGhl b3JldGljYWxseSwgUmV0cmFuc1RpbWVyIHNob3VsZCBiZSBpbXBvc2VkIG9uIHVuc29saWNpdGVk IE5BIChzZWN0aW9uIDcuMi42KSwgYnV0IGxvdyBjaGFuY2VzIHRoYXQgdGhpcyB0aW1lciBpcyBj aGVja2VkIG9uIHJlY2VpdmluZyBzaWRlIChyb3V0ZXIpLCBiZWNhdXNlIFJldHJhbnNUaW1lciBp cyBzcGVjaWZpZWQgZm9yIHRyYW5zbWlzc2lvbiBzaWRlLjxicj4NCiZndDsgJmd0OyBBY2NvcmRp bmcgUkZDIDQ2ODEgc2VjdGlvbiA3LjIuNSBjbGF1c2UgSUk6IE8gYml0IHNldCBzaG91bGQgbm90 IGp1c3QgcmV3cml0ZSBORCBjYWNoZSwgYnV0IGFkZGl0aW9uYWxseSBtYXJrIE5EIHJlY29yZCBh cyBSRUFDSEFCTEUuIEFjY29yZGluZyB0byBzZWN0aW9uIDcuMi42OiAmcXVvdDsgVGhlIE92ZXJy aWRlIGZsYWcgKGZvciB1bnNvbGljaXRlZCBOQSkgTUFZIGJlIHNldCB0byBlaXRoZXIgemVybyBv ciBvbmUmcXVvdDsuIERlc3BpdGUgaXQgY29udHJhZGljdHMNCiB0byB0aGUgbG9naWMgb2YgdGhl IHdob2xlIFJGQyA0NjgxIChPIGJpdCBzaG91bGQgbm90IGJlIHNldCBpbiB1bnNvbGljaXRlZCBO QSAtIGl0IGlzIG1lbnRpb25lZCBpbiBhIGZldyBwbGFjZXMgb2YgUkZDIDQ2ODEpLiBCdXQgYmVj YXVzZSBzZWN0aW9uIDcuMi41IGFuZCBzZWN0aW9uIDcuMi42IGNsZWFybHkgcGVybWl0IHRvIHVz ZSBPdmVycmlkZSBmbGFnIC0gaGlnaGVyIHByb2JhYmlsaXR5IHRoYXQgcGFydGljdWxhciBpbXBs ZW1lbnRhdGlvbg0KIHdvdWxkIG5vdCBqdXN0IHJld3JpdGUgTExBIG9uIHJvdXRlciwgYnV0IGFk ZGl0aW9uYWxseSBwdXQgaXQgaW50byBSRUFDSEFCTEUuPGJyPg0KJmd0OyAmZ3Q7IEludHJ1ZGVy IGNvdWxkIGJlIHN1cmUgdGhhdCBhdCBsZWFzdCBTVEFMRSBzdGF0ZSB3b3VsZCBiZSBjcmVhdGVk IGFjY29yZGluZyB0byBzZWN0aW9uIDcuMi41IGNsYXVzZSBJLCAtIHRoaXMgTkQgcmVjb3JkIHdv dWxkIGJlIGFnYWluc3QgaGlzIExMQSBhbnl3YXkuPGJyPg0KJmd0OyAmZ3Q7IEFmdGVyIHJlY2Vp dmluZyByZXR1cm4gdHJhZmZpYyAoaWYgaXQgd2FzIGNyZWF0ZWQgYXMgU1RBTEUsIG5vdCBSRUFD SEFCTEUpIC0gcm91dGVyIHdvdWxkIGFzayBpbnRydWRlciBhYm91dCByZWFjaGFiaWxpdHkgKHNv bGljaXRlZCBOUy1OQSkgLSBpbnRydWRlciB3b3VsZCBjb25maXJtIGhpcyBMTEEgLSBpdCB3b3Vs ZCBmaW5hbGx5IHB1dCBORCBjYWNoZSByZWNvcmQgaW50byBSRUFDSEFCTEUuPGJyPg0KJmd0Ozxi cj4NCiZndDsgMSkgdGhlIDcgc2Vjb25kcyBjb3JuZXIgY2FzZSB3YXMgZm9yICdwcmV2ZW50aW5n IGFkZHJlc3MgY29sbGlzaW9uIGZvciBPcHRpbWlzdGljIERBRCcsIG5vdCBmb3IgYW55IGludGVu dGlvbmFsIGF0dGFja3MgY2FzZS4gQmVjYXVzZTo8YnI+DQomZ3Q7IDIpIFdoYXQgeW91IGFyZSBk ZXNjcmliaW5nIGNvdWxkIGJlIGRvbmUgdG9kYXksIG5vdywgYW55dGltZSB3L28gdGhlIGNoYW5n ZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29waW5nIHRo ZW4gdGhlIGludHJ1ZGVyIHdvdWxkIHNlZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2aWN0aW0s IHNvIGl0IHdvdWxkIGtub3cgdGhlIHZpY3RpbSBhZGRyZXNzIGFueXdheSZuYnNwOyAtIG5vIHJl YXNvbiBldmVuIHRvIGpvaW4NCiBmZjAyOjoyLiBOb3cgYWxsIHRoZSBhdHRhY2tlciBuZWVkcyB0 byBkbyBpcyB0byBrZWVwIHNlbmRpbmcgTkEgd2l0aCBTPTEsIE89MSAtIGhvcGluZyB0aGF0IHdo ZW4gdGhlIGZpcnN0IHBhY2tldCBvZiB0aGUgcmV0dXJuIGZsb3dzIGFycml2ZSBhbmQgdGhlIHJv dXRlciBjcmVhdGVzIGFuIElOQ09NUExFVEUgZW50cnkgYW5kIHNlbmRzIGFuIE5TLCB0aGUgYXR0 YWNrZXIncyBwYWNrZXQgd291bGQgY29tZSBiZWZvcmUgdGhlIHZpY3RpbSdzIE5BLg0KIERvbmUs IHRoZSZuYnNwOyBlbnRyeSBpcyBjaGFuZ2VkIHRvIFJFQUNIQUJMRSwgYWxsIHRyYWZmaWMgZ29l cyB0byB0aGUgYXR0YWNrZXIuPGJyPg0KJmd0OyBBY3R1YWxseSBldmVuIHNpbXBsZXIuIFRoZSBh dHRhY2tlciBkb2VzIG5vdCBuZWVkIHRvIGRlYWwgd2l0aCB0aW1pbmcuPGJyPg0KJmd0OyBMZXQn cyBzYXkgdGhlIHJvdXRlciBoYXMgYW4gTkMgZW50cnkgZm9yIHRoZSB2aWN0aW0gYWRkcmVzcyBp biBhbnkgb3RoZXIgc3RhdGUgdGhhbiBJTkNPTVBMRVRFLiBUaGUgYXR0YWNrZXIgc2VuZHMgYW4g TkEgd2l0aCBTPTEsIE89MSwgVGFyZ2V0IGFkZHJlc3MgPSB0aGUgdmljdGltJ3MgSVB2NiBhZGRy ZXNzLCB0aGUgVExMQSA9IHRoZSBhdHRhY2tlciBNQUMgYWRkcmVzcy4mbmJzcDsgRG9uZS4gVGhl IHJvdXRlciB1cGRhdGVzIHRoZSBjYWNoZSBlbnRyeQ0KIGFuZCBjaGFuZ2VzIGl0IHRvIFJFQUNI QUJMRSBzdGF0ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBpcyBub3RoaW5nIG5ldyBoZXJl LiBXZSBoYXZlIHRoZSBzYW1lIGlzc3VlIHdpdGggQVJQIC0gdGhlIGF0dGFja2VyIGNhbiBvdmVy cmlkZSBBUlAgZW50cnkgb24gdGhlIHJvdXRlci48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRo YXQncyBpdDogdXBzdHJlYW0gdHJhZmZpYyBvZiB2aWN0aW0gaG9zdCBpcyBnb2luZyB0byByb3V0 ZXIsIHRyYWZmaWMgYmFjayBpcyBnb2luZyB0aHJvdWdoIEludHJ1ZGVyLjxicj4NCiZndDsgJmd0 OyBJIGhhdmUgY29uc3VsdGVkIHdpdGggcGVuZXRyYXRpb24gdGVzdHMgcHJvZmVzc2lvbmFsICh0 aGVzZSBhcmUgcGVvcGxlIHdpdGggdGhlIHNhbWUgcXVhbGlmaWNhdGlvbiBhcyBoYWNrZXJzIGJ1 dCB0aGV5IHBsYXkgb24gbGVnYWwgc2lkZSk6IHdoYXQgaGUgd291bGQgYmUgZG9pbmcgbmV4dD8g SGUgc2FpZCB0aGF0IGhlIHdvdWxkIHJldHVybiB0cmFmZmljIHRvIGxlZ2l0aW1hdGUgaG9zdCAt IHZpY3RpbSBzaG91bGQgbm90IHNlZSBwZXJmb3JtYW5jZQ0KIGRlZ3JhZGF0aW9uLiBIZSB3b3Vs ZCBjb2xsZWN0IGNvb2tpZXMgYW5kIHNvbWUgb3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIEhl IHdvdWxkIGZpbmFsbHkgc2VlIEROUyByZXNwb25zZSwgY2hhbmdlIGl0IGFuZCByZWRpcmVjdCBl dmVyeXRoaW5nIHRvIGhpbXNlbGYgb24gdGhlIHBlcm1hbmVudCBiYXNpcyAtIGhlIGRvZXMgd2Fu dCB0byBzZWUgYm90aCBkaXJlY3Rpb25zIG9mIHZpY3RpbSBleGNoYW5nZS4gSGUgaGFzIHF1YWxp ZmllZCBNYW4taW4tdGhlLW1pZGRsZQ0KIGFzIGZ1bGwgZmlhc2NvIC0gaXQgZG9lcyBvcGVuIG1h bnkgb3Bwb3J0dW5pdGllcyBmb3IgaGltLiBIZSBoYXMgbWVudGlvbmVkIHZlcnkgZ29vZCBmZWF0 dXJlIG9mIHRoaXMgZHJhZnQgdGhhdCB0aGVyZSBpcyBubyBhbnkgaW50ZXJydXB0aW9uIGZvciB2 aWN0aW0ncyB0cmFmZmljIGZsb3csIG5vIGFueSBleGNlc3NpdmUgdHJhZmZpYyB0byB2aWN0aW0s IHRoYXQgaXMgdmVyeSByZWFyIGJlbmVmaXQgZm9yIGhhY2tlcidzIHRvb2wuPGJyPg0KJmd0Ozxi cj4NCiZndDsgRm9yIGFsbCB0aGF0IGRvb20gYW5kIGdsb29tIHRoZSBhdHRhY2tlciB3b3VsZCBh bHNvIG5lZWQgdG8gc2VlIHRoZSB0cmFmZmljICpmcm9tKiB0aGUgdmljdGltLiBBc3N1bWluZyB0 aGUgbmV0d29yayBoYXMgUkEgR3VhcmQgaW4gcGxhY2UgaXQgd291bGQgYmUgYSBiaXQgaGFyZGVy LiBJZiB0aGUgbmV0d29yayBkb2VzIG5vdCBoYXZlIFJBIEd1YXJkIG91ciBwb29yIHZpY3RpbSBo YXMgbXVjaCBiaWdnZXIgcHJvYmxlbXMgYWxyZWFkeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IFdoYXQgdG8gZG8gYWJvdXQgaXQ/PGJyPg0KJmd0OyAmZ3Q7IDEuIFBvdGVudGlhbGx5IGl0IGlz IHBvc3NpYmxlIHRvIGRvIFJQRi1saWtlIGNoZWNrIGZvciBTb3VyY2UgTExBIGFkZHJlc3Nlcy4g VXBzdHJlYW0gdHJhZmZpYyBmcm9tIHZpY3RpbSdzIFNMTEEgd291bGQgbm90IGJlIGluIE5EIGNh Y2hlIC0gc3VjaCB0cmFmZmljIGNvdWxkIGJlIGRpc2NhcmRlZC4gSXQgaXMgYmV0dGVyIHRvIGJs b2NrIGNvbW11bmljYXRpb24gdGhhbiBwZXJtaXQgaW50cnVkZXIgdG8gZXhwbG9pdCB2dWxuZXJh YmlsaXR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgMi4gSW5jcmVhc2UgUmV0cmFuc1RpbWVy IGFuZCBhc2sgcmVjZWl2ZXIgc2lkZSAocm91dGVyKSB0byBjaGVjayBvbiBzZW5kaW5nIHNpZGUg ZGVsYXkgYmV0d2VlbiBORCByZWNvcmQgb3ZlcnJpZGUgKGZvciB0aGUgc2FtZSBTTExBKS4gQnV0 IGhvdyBsb25nIHNob3VsZCBiZSB0aGUgdGltZXI/IEhvc3QgY291bGQgd2FpdCBhIGxvLW8tby1u ZyB0aW1lIGJlZm9yZSBpdCB3b3VsZCByZXF1ZXN0IDFzdCBpbmZvcm1hdGlvbiBmcm9tIGludGVy bmV0Lg0KIEl0IHdvdWxkIGRlY3JlYXNlIHByb2JhYmlsaXR5LCBidXQgd291bGQgbm90IGNvbXBs ZXRlbHkgZWxpbWluYXRlIGF0dGFjayB2ZWN0b3IuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IE15IHByb3Bvc2l0aW9uIGZvciB0aGlzIGRyYWZ0IGlzIGRpc3J1cHRpdmU6PGJyPg0KJmd0 OyAmZ3Q7IEkgYmVsaWV2ZSB0aGF0IE5EIGlzIHZlcnkgY29tcGxpY2F0ZWQgKHNvbWUgY291bGQg c2F5ICZxdW90O2ZyYWdpbGUmcXVvdDspIC0gaXQgaXMgYmV0dGVyIG5vdCB0byB0b3VjaCBpdC48 YnI+DQomZ3Q7ICZndDsgQWRkaXRpb25hbGx5IEkgZG8gbm90IGxpa2UgdG8gd2FpdCB0aWxsIGFs bCBob3N0cyB3b3VsZCByZWZyZXNoIHRvIG5ldyBkcmFmdCAodG8gZ2V0IG5ldyBmdW5jdGlvbmFs aXR5KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZWxsLCBvbmx5IGhvc3RzIHdoaWNoIHdhbnQgdG8g Y29ubmVjdCB0byB0aGUgbmV0d29yayBmYXN0ZXIgbmVlZCB0byBpbXBsZW1lbnQgdGhpcy4gU28g aG9zdCBPUyBkZXZlbG9wZXJzIGhhdmUgcHJldHR5IGdvb2QgaW5jZW50aXZlIGhlcmUuPGJyPg0K Jmd0OyBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgdGhlIHByb3Bvc2VkIGJlaGF2aW9yIGlzIG5v dCBjdXJyZW50bHkgcHJvaGliaXRlZC4gV2UgYXJlIG5vdCBjaGFuZ2luZyBhbnkgTVVTVCBOT1Qg dG8gYW55dGhpbmcgZWxzZS4gQWxsIHdlIGFyZSBkb2luZyBpcyB0byBtYWtpbmcgc29tZSByZWNv bW1lbmRhdGlvbnMgbW9yZSBleHBsaWNpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgcHJv cG9zZSB0byBjaGFuZ2Ugb25seSByb3V0ZXIgYmVoYXZpb3I6IGNoZWNrIFNvdXJjZSBMTEEgKE1B QykgZm9yIGV2ZXJ5IHBhY2tldCwgaWYgdGhpcyBTTExBIGlzIGFic2VudCBpbiBORCBjYWNoZSAt IHRoZW4gcmVxdWVzdCBzb2xpY2l0ZWQgTlMtTkEgaW1tZWRpYXRlbHkuIEl0IHdvdWxkIHByb2Jh Ymx5IHJlc29sdmUgZmFzdGVyIHRoYW4gdHJhZmZpYyB3b3VsZCByZXR1cm4gZnJvbSB0aGUgaW50 ZXJuZXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSGF2ZSB5b3UgY2hlY2tlZCB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQgZHJhZnQ/PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC0wIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtdjZvcHMtbmQtY2FjaGUtaW5pdC0wPC9hPjxicj4NCiZndDsgMyNzZWN0aW9uLTMuNzxicj4N CiZndDsgc3BlY2lmaWNhdGxseT88YnI+DQomZ3Q7IFdoYXQgeW91IGFyZSBwcm9wb3NpbmcgZG9l cyBtYWtlIHNlbnNlLCBob3dldmVyIGl0IHdvdWxkIG5vdCBoZWxwIGluIGNhc2Ugb2YgbXVsdGlw bGUgcm91dGVycy4gQWxzbyBJIHJlY2FsbCBzb21lIHBlb3BsZSBoYXZpbmcgc3Ryb25nIG9waW5p b25zIG9uIHBlcmZvcm1hbmNlIGltcGxpY2F0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEVmZmVjdGl2ZWx5IEkgZG8gcHJvcG9zZWQgdGhlIHNhbWUgU0xMQSBSUEYgdGhhdCBpcyBuZWVk ZWQgdG8gZml4IGN1cnJlbnQgc29sdXRpb24sIGJ1dDo8YnI+DQomZ3Q7ICZndDsgLSB3aXRob3V0 IGFueSBtb2RpZmljYXRpb24gdG8gaG9zdCBPU2VzPGJyPg0KJmd0OyAmZ3Q7IC0gd2l0aG91dCBh bnkgbW9kaWZpY2F0aW9uIG9mIHN0YW5kYXJkIChpdCBpcyBsb2NhbCByZWNvbW1lbmRhdGlvbiA8 YnI+DQomZ3Q7ICZndDsgZm9yIHJvdXRlciwgTlMtTkEgaXMgZXhhY3RseSB0aGUgc2FtZSBmcm9t IFJGQyA0NjgxLCBOQSBpcyB1bmljYXN0IC0gPGJyPg0KJmd0OyAmZ3Q7IGl0IGlzIGltcG9ydGFu dCBmb3Igc2VjdXJpdHkpPGJyPg0KJmd0OyAmZ3Q7IC0gd2l0aG91dCBhbnkgcmlzayB0byBicmVh ayBORCBmcmFnaWxlIGFsZ29yaXRobTxicj4NCiZndDsgJmd0OyAtIGl0IGNvdWxkIGJlIG9wdGlv bmFsLCBvciBldmVuIGNvbmZpZ3VyYWJsZSBvbiB0aGUgcm91dGVyIGFzICZxdW90O3ZhbHVlIDxi cj4NCiZndDsgJmd0OyBhZGQgZmVhdHVyZSZxdW90OyBpbiBjb21wZXRpdGl2ZSB0ZW5kZXIgQmVj YXVzZSBpdCBpcyBqdXN0IGJlc3QgcHJhY3RpY2UgcmVjb21tZW5kYXRpb24gLSBtYXkgYmUgaXQg bWFrZSBzZW5zZSB0byBtb3ZlIGl0IHRvICZxdW90O3Y2b3BzJnF1b3Q7Pzxicj4NCiZndDs8YnI+ DQomZ3Q7IFNlZSA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1uZC1jYWNoZS1pbml0LTAiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12 Nm9wcy1uZC1jYWNoZS1pbml0LTA8L2E+PGJyPg0KJmd0OyAzPGJyPg0KJmd0Ozxicj4NCiZndDsg Jmd0OyBQUzogTG9va2luZyB0byB0aGUgYWJvdmUgLSB1bnNvbGljaXRlZCBOQSBzaG91bGQgYmUg cmVhbGx5IGRlbGF5ZWQgYnkgYWRkaXRpb25hbCBiaWcgdGltZXIgKG5vdCBieSBSZXRyYW5zVGlt ZXIgdGhhdCBpcyB1c2VkIGZvciBzb2xpY2l0ZWQgTlMvTkEpIGFuZCBjaGVja2VkIG9uIHJlY2Vp dmVyIHNpZGUgLSB0aGlzIG1vZGlmaWNhdGlvbiBvZiBzdGFuZGFyZCBpcyByZWFsbHkgbmVlZGVk IHRvIGNsb3NlIFVuc29saWNpdGVkIE5BIHZ1bG5lcmFiaWxpdHkuPGJyPg0KJmd0OyAmZ3Q7IFNv bWVib2R5IHNhaWQgb24gdGhlIGNhbGwgdGhhdCBpdCBpcyBhbHJlYWR5IGEgZmVhdHVyZSBvZiBz b21lIE9TIChBbmRyb2lkPykgLSBpdCBpcyBiYWQ6IGl0IG1lYW5zIHRoYXQgdGhpcyBPUyBpcyBh bHJlYWR5IHZ1bG5lcmFibGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB3YXMgc2F5aW5nIHRoYXQg c29tZSByb3V0aW5nIHBsYXRmb3JtcyBoYXZlIHRoaXMgYWxyZWFkeSBpbXBsZW1lbnRlZC4uIFNl YXJjaCBmb3IgJ2dsZWFuJyBoZXJlOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuY2lz Y28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2X2Jhc2ljL2NvbmZpZ3VyYSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9p b3MteG1sL2lvcy9pcHY2X2Jhc2ljL2NvbmZpZ3VyYTwvYT48YnI+DQomZ3Q7IHRpb24vMTUtZS9p cDZiLTE1LWUtYm9vay9pcDYtbmQtY2FjaGUtbWdtdC5odG1sPGJyPg0KJmd0Ozxicj4NCiZndDsg QUZBSUsgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB3aGljaCBhcmUgYWxzbyBwcmVwb3B1bGF0 aW5nIE5DIGZyb20gREFEIHBhY2tldHMgYnV0IEkgY2FuIG5vdCBmaW5kIHlvdSBhIHJlZmVyZW5j ZSByaWdodCBub3cuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBGcm9tOiBpcHY2IFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlw djYtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKZW4gTGlua292YTxicj4NCiZn dDsgJmd0OyBTZW50OiAyNyDQuNGO0LvRjyAyMDIwINCzLiA3OjQ5PGJyPg0KJmd0OyAmZ3Q7IFRv OiA2bWFuICZsdDs8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlwdjZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxLnR4dDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBIZWxsbyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIC0wMSB2ZXJz aW9uIGFkZHJlc3NlcyBjb21tZW50cyByZWNlaXZlZCAodGhhbmtzIGV2ZXJ5b25lIHdobyBwcm92 aWRlZCBmZWVkYmFjaykuIEFsc28sIFNlY3Rpb24gMyAoQXZvaWRpbmcgRGlzcnVwdGlvbikgaGFz IGJlZW4gZXhwYW5kZWQgYW5kIGRpc2N1c3NlZCBhIGNvcm5lciBjYXNlIHdoZW4gdHdvIGRldmlj ZXMgc3RhcnQgdXNpbmcgdGhlIHNhbWUgYWRkcmVzcyBhbG1vc3QgYXQgdGhlIHNhbWUgdGltZSAo dGhlIHNlY29uZCBkZXZpY2UNCiBjb25maWd1cmVzIGFuIG9wdGltaXN0aWMgYWRkcmVzcyBhZnRl ciB0aGUgcmlnaHRmdWwgb3duZXIgc2VudCBzb21lIHBhY2tldHMgYnV0IGJlZm9yZSB0aGUgcmV0 dXJuIHRyYWZmaWMgYXJyaXZlcykuPGJyPg0KJmd0OyAmZ3Q7IEZlZWRiYWNrIG9uIHRoZSB1cGRh dGVkIHNlY3Rpb24gMy4zPGJyPg0KJmd0OyAmZ3Q7ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxI3NlY3Rpb24tMy4zIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFu ZC0wMSNzZWN0aW9uLTMuMzwvYT4pIGlzIHZlcnkgbXVjaCBhcHByZWNpYXRlZC48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gU3VuLCBKdWwgMjYsIDIwMjAgYXQgMTA6MTQgQU0gJmx0 OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtU aXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBHcmF0dWl0b3Vz IE5laWdoYm9yIERpc2NvdmVyeTogQ3JlYXRpbmcgTmVpZ2hib3IgQ2FjaGUgRW50cmllcyBvbiBG aXJzdC1Ib3AgUm91dGVyczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0F1dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBK ZW4gTGlua292YTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0ZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi02 bWFuLWdyYW5kLTAxLnR4dDxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1BhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IDEyPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0w Ny0yNTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWJzdHJhY3Q6PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IE5laWdoYm9yIERpc2NvdmVyeSAoUkZDNDg2 MSkgaXMgdXNlZCBieSBJUHY2IG5vZGVzIHRvIGRldGVybWluZSB0aGU8YnI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgbGluay1sYXllciBhZGRyZXNzZXMgb2YgbmVpZ2hib3Jpbmcgbm9k ZXMgYXMgd2VsbCBhcyB0byBkaXNjb3ZlciBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgbWFpbnRhaW4gcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLiZuYnNwOyBUaGlzIGRvY3Vt ZW50IHVwZGF0ZXMgUkZDNDg2MSB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBh bGxvdyByb3V0ZXJzIHRvIHByb2FjdGl2ZWx5IGNyZWF0ZSBhIE5laWdoYm9yIENhY2hlIGVudHJ5 IHdoZW4gYSBuZXc8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgSVB2NiBhZGRyZXNz IGlzIGFzc2lnbmVkIHRvIGEgbm9kZS4mbmJzcDsgSXQgYWxzbyB1cGRhdGVzIFJGQzQ4NjEgYW5k PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IHJlY29tbWVuZHMgbm9kZXMgdG8gc2Vu ZCB1bnNvbGljaXRlZCBOZWlnaGJvciBBZHZlcnRpc2VtZW50cyB1cG9uPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7IGFzc2lnbmluZyBhIG5ldyBJUHY2IGFkZHJlc3MuJm5ic3A7IFRo ZSBwcm9wb3NlZCBjaGFuZ2Ugd2lsbCBtaW5pbWl6ZSB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgZGVsYXkgYW5kIHBhY2tldCBsb3NzIHdoZW4gYSBub2RlIGluaXRpYXRlIGNv bm5lY3Rpb25zIHRvIG9mZi1saW5rPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGRl c3RpbmF0aW9uIGZyb20gYSBuZXcgSVB2NiBhZGRyZXNzLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4tZ3Jh bmQvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLTZtYW4tZ3JhbmQvPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxi cj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDE8L2E+PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLTZtYW4tZ3JhbmQtMDEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxPC9hPjxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLTZtYW4tZ3JhbmQtMDE8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7 IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAtLSBJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCmlwdjZAaWV0Zi5vcmc8L2E+IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IEFkbWluaXN0cmF0aXZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVxdWVzdHM6IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly93d3cuLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48YnI+DQom Z3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAtLTxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4N CiZndDsgJmd0OyBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdCA8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KaXB2NkBpZXRmLm9yZzwvYT4gQWRtaW5pc3RyYXRpdmUgPGJyPg0KJmd0OyAmZ3Q7 IFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjY8L2E+PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgU1ksIEplbiBMaW5rb3ZhIGFr YSBGdXJyeTxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KU1ksIEplbiBMaW5rb3ZhIGFr YSBGdXJyeTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_dfb9ccbfd87140cfba01c69447581aefboeingcom_-- From nobody Fri Jul 31 08:13:32 2020 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 65F2F3A1247 for ; Fri, 31 Jul 2020 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiCZUmsnhQ9d for ; Fri, 31 Jul 2020 08:13:29 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20ED83A1155 for ; Fri, 31 Jul 2020 08:13:29 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id ed14so14272658qvb.2 for ; Fri, 31 Jul 2020 08:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OWVOxLRstSPGty7A+CBWdG4BJrIDPtSLRDzA9b2oi5A=; b=QV4sCfZkpI0/l2y9aY+Ku7pSwXSEoDqSQGBtPZSpsT0c3ApLUOTlyS95pxIV30EE5I n0xw+IrCb/Y07+7NcxX9p+pvLvTgsg6RK7/qbAli4FMqll++eK3yue5IuJFPEg3HAUhR vjM8BybP6WipJYbp8/0aw0H8LPPJ7s8+eKWQ/sm6cEB8ACtgeHPuXJnEiZscBZnAQwmM ljWUIwGxjzRYd+zF0f4hWZMXTYSLAnxTO25A0s9+VF7sFwhv9f+XvCblEl0Ro9S8ncsq JyJP04XjpUeLyaxKzax0TJbL2cTumE6yJ23h4ofSdj3Tvai99oI7zu06IAU9gZvx2+nI zcfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OWVOxLRstSPGty7A+CBWdG4BJrIDPtSLRDzA9b2oi5A=; b=RpjlhIDLmOpbYw4A4XrP6RXuneh/G6xY8+WCMDWNYc3qGc6hKp/injIq8zV6jQqrWh 8IsB/zYoJm9kKDXbyN0kcAaN1c9v7lO9z/13vMdelYmKE5AVaFsndsg70Nydp27VSDBW YLyNtsFgv1Bej5Tx1vqBQ2g0h7mEcqTGSIXbaKnPTY5o/lOHycwLXvhjHVbqDssuYmiI aoZgIKRL2Bdx3Slm9gtggRUFwgisyKL0fATzT9+a943snY4fsbLBKi/9TYn+nhRqOeKc cp1WqLkXDFy0PBbEBzXOlRFPqgznzmRHQAyRpaWQwe5wnUxZ5eCeW1AX+7AXQP7p4/tU RS1g== X-Gm-Message-State: AOAM532Nhr9wYXbm1a1XyMDtpsA8g4yPPKwtztl5qb5gHI+/QvH97qVf ilEbxIarHcbVOHaMIrfEhZc7iw== X-Google-Smtp-Source: ABdhPJwwdR4LQHiptwu26PwxzdA5BuiSWXqAi4jkr/Db+Q5nYYa2BuWYRnTyGXJ6VzgAS3j+xJlsig== X-Received: by 2002:a0c:d7c9:: with SMTP id g9mr4691767qvj.83.1596208404431; Fri, 31 Jul 2020 08:13:24 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id f31sm9672265qte.35.2020.07.31.08.13.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 08:13:23 -0700 (PDT) From: Ted Lemon Message-Id: <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2D08DCFE-0988-461D-938A-F4BDB9AA8389" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 11:13:21 -0400 In-Reply-To: <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> Cc: Mark Smith , v6ops list , 6man To: "Pascal Thubert (pthubert)" References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 15:13:31 -0000 --Apple-Mail=_2D08DCFE-0988-461D-938A-F4BDB9AA8389 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) = wrote: > I support GRAND because it is better than nothing and progressing just = that at 6MAN seems to be an incredible achievement already.=20 Indeed. GRAND seems like a thing that one would be tempted to add to a = stack even in the absence of a draft describing it. Having a draft that = describes how to do it is better, because we can then have a discussion = of what the benefits and drawbacks are, and mitigate the drawbacks. This = concern about ND security seems like a useless digression: yes, ND is = not secure, we know this. We=E2=80=99ve tried to address it with SEND, = but that hasn=E2=80=99t gotten any traction in the market.=20 Are we seeing L2 attacks on ND in the wild? What=E2=80=99s the threat = model? If this is a real concern, let=E2=80=99s confront it head-on, = rather than trying to address it piecemeal. --Apple-Mail=_2D08DCFE-0988-461D-938A-F4BDB9AA8389 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org> = wrote:
I = support GRAND because it is better than nothing and progressing just = that at 6MAN seems to be an incredible achievement = already. 

Indeed. =  GRAND seems like a thing that one would be tempted to add to a = stack even in the absence of a draft describing it. Having a draft that = describes how to do it is better, because we can then have a discussion = of what the benefits and drawbacks are, and mitigate the drawbacks. This = concern about ND security seems like a useless digression: yes, ND is = not secure, we know this. We=E2=80=99ve tried to address it with SEND, = but that hasn=E2=80=99t gotten any traction in the = market. 

Are we seeing L2 = attacks on ND in the wild? What=E2=80=99s the threat model? If this is a = real concern, let=E2=80=99s confront it head-on, rather than trying to = address it piecemeal.

= --Apple-Mail=_2D08DCFE-0988-461D-938A-F4BDB9AA8389-- From nobody Fri Jul 31 08:30:51 2020 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 22A163A05A7; Fri, 31 Jul 2020 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRSu6t69-arY; Fri, 31 Jul 2020 08:30:41 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 801703A09AC; Fri, 31 Jul 2020 08:30:36 -0700 (PDT) Received: from [IPv6:2620::930:0:210d:d9ed:30e1:81ab] ([IPv6:2620:0:930:0:210d:d9ed:30e1:81ab]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 06VFUTXP2912634 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 08:30:29 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 06VFUTXP2912634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1596209430; bh=uvpfd7pcdkt29QOzVeXGlUzrkveSzVLz+tMyg/OYph0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ddd0z4wmF15YYVe0LxeNtjLFyTw0OkOhsmn0DA0Qe7CyiPMDoCLRsymiIHuELvuYS 8MjtOQuoeouKvcLa71M5RGRzDnRkC5Ebd2shjD8U70mW4xQiB3GvvN2ZTZ9tEQvbxk 546RZGIRcabASfuyPy8wLdTS7pxTvIpwBuCW2CQ8= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E0326AA2-F8DC-411A-B248-0D3993288282" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jul 2020 08:30:29 -0700 In-Reply-To: <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: Ted Lemon References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 31 Jul 2020 08:30:30 -0700 (PDT) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 15:30:44 -0000 --Apple-Mail=_E0326AA2-F8DC-411A-B248-0D3993288282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 31, 2020, at 08:13 , Ted Lemon wrote: >=20 > On Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) = > wrote: >> I support GRAND because it is better than nothing and progressing = just that at 6MAN seems to be an incredible achievement already.=20 >=20 > Indeed. GRAND seems like a thing that one would be tempted to add to = a stack even in the absence of a draft describing it. Having a draft = that describes how to do it is better, because we can then have a = discussion of what the benefits and drawbacks are, and mitigate the = drawbacks. This concern about ND security seems like a useless = digression: yes, ND is not secure, we know this. We=E2=80=99ve tried to = address it with SEND, but that hasn=E2=80=99t gotten any traction in the = market.=20 >=20 > Are we seeing L2 attacks on ND in the wild? What=E2=80=99s the threat = model? If this is a real concern, let=E2=80=99s confront it head-on, = rather than trying to address it piecemeal. ND attacks are a concern in a very limited number of scenarios, most of = which have not had significant v6 penetration yet=E2=80=A6 1. Public wifi networks (e.g. coffee houses, etc.) 2. College/University settings (some v6 traction here, but often = not on student-device accessible LANs) 3. Other networks which must admit untrusted clients/devices In reality, ND is not significantly better or worse than ARP in terms of = attack surface. The primary difference with ND is the ability to overrun {switch, router, host} neighbor tables. This = doesn=E2=80=99t stem from the difference between ND and ARP, but rather from the difference between networks that rarely = have more than 256 possible L3 addresses and networks which routinely have more than 18 quintillion possible = addresses. There=E2=80=99s just not enough silicon on the planet for every switch to support an n x 2^64 bit neighbor = table. Indeed, as an operator, IMHO, if there=E2=80=99s a place we need to = focus on improving L2 attack surface in v6, it=E2=80=99s in finding better ways for {routers, hosts, switches} to mitigate/absorb = this type of resource exhaustion attack. Unfortunately, this is a hard problem to solve, so we focus on moving = the deck chairs we can move while ignoring the elephant-sized hole in the bulkheads that we don=E2=80=99t = know how to patch. Owen --Apple-Mail=_E0326AA2-F8DC-411A-B248-0D3993288282 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 31, 2020, at 08:13 , Ted Lemon <mellon@fugue.com> = wrote:

On Jul 30, 2020, at = 6:26 PM, Pascal Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org> wrote:
I = support GRAND because it is better than nothing and progressing just = that at 6MAN seems to be an incredible achievement = already. 

Indeed.  GRAND seems like a thing that one would be = tempted to add to a stack even in the absence of a draft describing it. = Having a draft that describes how to do it is better, because we can = then have a discussion of what the benefits and drawbacks are, and = mitigate the drawbacks. This concern about ND security seems like a = useless digression: yes, ND is not secure, we know this. We=E2=80=99ve = tried to address it with SEND, but that hasn=E2=80=99t gotten any = traction in the market. 

Are we seeing L2 attacks on ND in the = wild? What=E2=80=99s the threat model? If this is a real concern, = let=E2=80=99s confront it head-on, rather than trying to address it = piecemeal.

ND attacks are a concern in a very limited number = of scenarios, most of which have not had significant v6 penetration = yet=E2=80=A6

1. Public = wifi networks (e.g. coffee houses, etc.)
2. = College/University settings (some v6 traction here, but often not = on student-device accessible LANs)
3. Other = networks which must admit untrusted clients/devices

In reality, ND is not = significantly better or worse than ARP in terms of attack surface. The = primary difference with ND
is the ability to = overrun {switch, router, host} neighbor tables. This doesn=E2=80=99t = stem from the difference between ND
and ARP, but = rather from the difference between networks that rarely have more than = 256 possible L3 addresses
and networks which = routinely have more than 18 quintillion possible addresses. There=E2=80=99= s just not enough silicon
on the planet for every = switch to support an n x 2^64 bit neighbor table.
Indeed, as an operator, IMHO, if = there=E2=80=99s a place we need to focus on improving L2 attack surface = in v6, it=E2=80=99s in
finding better ways for = {routers, hosts, switches} to mitigate/absorb this type of resource = exhaustion attack.
Unfortunately, this is a hard = problem to solve, so we focus on moving the deck chairs we can move = while
ignoring the elephant-sized hole in the = bulkheads that we don=E2=80=99t know how to patch.

Owen

= --Apple-Mail=_E0326AA2-F8DC-411A-B248-0D3993288282-- From nobody Fri Jul 31 08:43:57 2020 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 DE4733A0A96 for ; Fri, 31 Jul 2020 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke9-mqp2_hGB for ; Fri, 31 Jul 2020 08:43:48 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2773A0A92 for ; Fri, 31 Jul 2020 08:43:48 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id e13so29151324qkg.5 for ; Fri, 31 Jul 2020 08:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=R3JTTuqhSsjNRvWvRoZIW94PZN1FRygOZr+ygTth6HY=; b=oIiLQ/SyYi2WbeJp5TrQyKFjnr8q4uItTlx/bsxxu9RIjzvz7vTZ3QnVwKvL8LPQDr WySb09jXt6Lcf1uuFR9iWiIAaI/debkebxfsDej6msP7fcblQMlyXIGcAl0UN8FDFyfe 0hqZBcokkjomsF0ju7+ca4cgG8+aKBD27bVebOL/X4kICiyUI76UR/YSGzbfpV60Q0ee UXq38ndtPo40A9tJtTyXpk9UvNmQk1PYo7QHwU9KgUuU6+IfrHvEvhHy3E87tWvZg/gv YZKkoriBtNvybTDMBSpjI7ru84aFi5RGMtW8NUzs5q5/ErwjuGPPNq/fCRmBA1/jFcku ULjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=R3JTTuqhSsjNRvWvRoZIW94PZN1FRygOZr+ygTth6HY=; b=P0U6FYhtH7zF3KEBa+fnTQ5dm1nqGYUx1w/+uYNj3rqHUNgyBOamBZYLeZqe01Szs1 YxLsJh0ULhx0fde914stO0SxrIUjfpWuQRfZtr7cE94C1/l0z1evgrKAqCGjrsEzO1ON vPquLQYcOS9a1DHxagwANmkbc9jDJsVQctIU51z8/XONxk1bKGRCfBz5/PQX7iFUUh8a n605Q9dJbHqoaoMPjO67hN/yPwkHrJKhC67QRKMCdk0Bl3+9IjdVQepNdIVwh0Is3Th1 2Wiiv6EU1BpHSZoFnqObexZsgugNNJ93UU/NNo6nHs1b+ah9fGBQqtjagNwou+kvrD2h CiBA== X-Gm-Message-State: AOAM532AGu3RvZcqTL8E0aojxRXBx6/8RY3UuDhElzkKkUfTh3z4A1XQ gPWp47M1bV0pcgIng//BlzU9/WuGa/U= X-Google-Smtp-Source: ABdhPJyFxX4322zAukZMCDX5wJ2aP/zJxHqgQfMsSztjHO6nvAnFaqGCLb6Uxa6SHmivTfUWnKDSvA== X-Received: by 2002:a05:620a:1653:: with SMTP id c19mr4701836qko.501.1596210227220; Fri, 31 Jul 2020 08:43:47 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id 71sm8571539qkk.125.2020.07.31.08.43.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 08:43:46 -0700 (PDT) From: Ted Lemon Message-Id: <94D12FD5-3A0A-4278-A229-F0D88EC906D6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C56CFD96-5308-45A1-AE94-1270A1AED052" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 11:43:45 -0400 In-Reply-To: Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: Owen DeLong References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 15:43:52 -0000 --Apple-Mail=_C56CFD96-5308-45A1-AE94-1270A1AED052 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2020, at 11:30 AM, Owen DeLong wrote: > 1. Public wifi networks (e.g. coffee houses, etc.) The BCP for this case is to isolate clients. > 2. College/University settings (some v6 traction here, but often = not on student-device accessible LANs) For this it would be to give each dorm room its own subnet. > 3. Other networks which must admit untrusted clients/devices E.g. home networks? Or something else? --Apple-Mail=_C56CFD96-5308-45A1-AE94-1270A1AED052 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jul 31, 2020, at 11:30 AM, Owen DeLong <owen@delong.com> = wrote:
1. = Public wifi networks (e.g. coffee houses, = etc.)

The BCP for = this case is to isolate clients.

2. = College/University settings (some v6 traction here, but often not = on student-device accessible LANs)

For this it would be to give each dorm room its = own subnet.

3. Other networks which must admit = untrusted clients/devices

E.g. home networks? Or something = else?

= --Apple-Mail=_C56CFD96-5308-45A1-AE94-1270A1AED052-- From nobody Fri Jul 31 08:51:24 2020 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 C22F53A07B0; Fri, 31 Jul 2020 08:51:21 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D04tfgl2TheP; Fri, 31 Jul 2020 08:51:20 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 949F63A0786; Fri, 31 Jul 2020 08:51:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VFpG7t009089; Fri, 31 Jul 2020 11:51:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596210677; bh=aJbiTGq+7JAxZKLx6JuL3EThzbxvA2JqIH6BXW2I/HM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=godm1QpwDbkc4s4GUB9cs49AFGrE7u22vlUPc4JH8kdFFJhZAWlUxSnNhWBlf6aTW bFwTIjTGyKKrB1X/AXJ1GjZOrZXTuO026oQ5jJCZ+G63azSdN9AWQj8VIHOvmBFJBO aUYrESlGZM8UWCc5VotWk5E3KHyGOa37aeXSKrBJ+Ef+hk3mh4HnOBGdoTPgdZN9Hq 6lqwqAagBE4gWuDMHipv+6nhLfZ46RbmsOpfp5c27gKBwAeR63Ij7bdr9nuYKRs9rW 7TfpxcLi7YY5BNohMJI05hNLeWr25169a1qbyaWyJ9NrDOoc8WoTHmb5osQ6L/ZiX7 jMCC+tRe/Xz7g== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VFp9f4007984 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 11:51:09 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 08:51:08 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 08:51:08 -0700 From: "Templin (US), Fred L" To: Ted Lemon , "Pascal Thubert (pthubert)" CC: v6ops list , 6man Thread-Topic: [EXTERNAL] Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AQHWZ003hR9jbtEykkiWN8sYE2hmLqkh1XxA Date: Fri, 31 Jul 2020 15:51:08 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> In-Reply-To: <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 8911F0BE76BA9D1A62A98EF218E2A5157B4664534583AB5AC2A80AEDA720F2AB2000:8 Content-Type: multipart/alternative; boundary="_000_a43ffd94d6364a0f869cd4c694ab7432boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 15:51:22 -0000 --_000_a43ffd94d6364a0f869cd4c694ab7432boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLCBldCBhbCwNCg0KV2XigJl2ZSB0cmllZCB0byBhZGRyZXNzIGl0IHdpdGggU0VORCwg YnV0IHRoYXQgaGFzbuKAmXQgZ290dGVuIGFueSB0cmFjdGlvbiBpbiB0aGUgbWFya2V0Lg0KDQpJ IHRoaW5rIHRoYXQgbWVhbnMgdGhhdCBlaXRoZXIgU0VORCB3YXMgYWhlYWQgb2YgaXRzIHRpbWUg YW5kIHRoZSBtYXJrZXQgZm9yIGl0IGlzIG9ubHkNCm5vdyBiZWdpbm5pbmcgdG8gbWF0ZXJpYWxp emUsIG9yIFNFTkQgaXMgc29tZWhvdyBicm9rZW4gYW5kIHNob3VsZCBiZSBkZXByZWNhdGVkLg0K SSBhbSBpbnRlcmVzdGVkIHRvIGtub3cgd2hpY2gsIHNpbmNlIEkgYmVsaWV2ZSBJIHNlZSBhIHJv bGUgZm9yIFNFTkQuDQoNClRoYW5rcyAtIEZyZWQNCg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZWQgTGVtb24NClNlbnQ6IEZyaWRh eSwgSnVseSAzMSwgMjAyMCA4OjEzIEFNDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8 cHRodWJlcnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogdjZvcHMgbGlzdCA8djZv cHNAaWV0Zi5vcmc+OyA2bWFuIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogW0VYVEVSTkFMXSBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEgLSBhZGRpdGlv bmFsIHNlY3VyaXR5IGNvbmNlcm5zDQoNCg0KDQoNCk9uIEp1bCAzMCwgMjAyMCwgYXQgNjoyNiBQ TSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnQ9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOnB0aHViZXJ0PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv dGU6DQpJIHN1cHBvcnQgR1JBTkQgYmVjYXVzZSBpdCBpcyBiZXR0ZXIgdGhhbiBub3RoaW5nIGFu ZCBwcm9ncmVzc2luZyBqdXN0IHRoYXQgYXQgNk1BTiBzZWVtcyB0byBiZSBhbiBpbmNyZWRpYmxl IGFjaGlldmVtZW50IGFscmVhZHkuDQoNCkluZGVlZC4gIEdSQU5EIHNlZW1zIGxpa2UgYSB0aGlu ZyB0aGF0IG9uZSB3b3VsZCBiZSB0ZW1wdGVkIHRvIGFkZCB0byBhIHN0YWNrIGV2ZW4gaW4gdGhl IGFic2VuY2Ugb2YgYSBkcmFmdCBkZXNjcmliaW5nIGl0LiBIYXZpbmcgYSBkcmFmdCB0aGF0IGRl c2NyaWJlcyBob3cgdG8gZG8gaXQgaXMgYmV0dGVyLCBiZWNhdXNlIHdlIGNhbiB0aGVuIGhhdmUg YSBkaXNjdXNzaW9uIG9mIHdoYXQgdGhlIGJlbmVmaXRzIGFuZCBkcmF3YmFja3MgYXJlLCBhbmQg bWl0aWdhdGUgdGhlIGRyYXdiYWNrcy4gVGhpcyBjb25jZXJuIGFib3V0IE5EIHNlY3VyaXR5IHNl ZW1zIGxpa2UgYSB1c2VsZXNzIGRpZ3Jlc3Npb246IHllcywgTkQgaXMgbm90IHNlY3VyZSwgd2Ug a25vdyB0aGlzLiBXZeKAmXZlIHRyaWVkIHRvIGFkZHJlc3MgaXQgd2l0aCBTRU5ELCBidXQgdGhh dCBoYXNu4oCZdCBnb3R0ZW4gYW55IHRyYWN0aW9uIGluIHRoZSBtYXJrZXQuDQoNCkFyZSB3ZSBz ZWVpbmcgTDIgYXR0YWNrcyBvbiBORCBpbiB0aGUgd2lsZD8gV2hhdOKAmXMgdGhlIHRocmVhdCBt b2RlbD8gSWYgdGhpcyBpcyBhIHJlYWwgY29uY2VybiwgbGV04oCZcyBjb25mcm9udCBpdCBoZWFk LW9uLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWRkcmVzcyBpdCBwaWVjZW1lYWwuDQoNCg== --_000_a43ffd94d6364a0f869cd4c694ab7432boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SGkgVGVkLCBldCBhbCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPldl4oCZdmUgdHJpZWQgdG8gYWRkcmVzcyBpdCB3aXRo IFNFTkQsIGJ1dCB0aGF0IGhhc27igJl0IGdvdHRlbiBhbnkgdHJhY3Rpb24gaW4gdGhlIG1hcmtl dC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkgdGhp bmsgdGhhdCBtZWFucyB0aGF0IGVpdGhlciBTRU5EIHdhcyBhaGVhZCBvZiBpdHMgdGltZSBhbmQg dGhlIG1hcmtldCBmb3IgaXQgaXMgb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5ub3cgYmVnaW5uaW5n IHRvIG1hdGVyaWFsaXplLCBvciBTRU5EIGlzIHNvbWVob3cgYnJva2VuIGFuZCBzaG91bGQgYmUg ZGVwcmVjYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SSBhbSBpbnRlcmVzdGVkIHRvIGtub3cgd2hp Y2gsIHNpbmNlIEkgYmVsaWV2ZSBJIHNlZSBhIHJvbGUgZm9yIFNFTkQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5U ZWQgTGVtb248YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDMxLCAyMDIwIDg6MTMgQU08 YnI+DQo8Yj5Ubzo8L2I+IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgJmx0O3B0aHViZXJ0PTQw Y2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gdjZvcHMgbGlzdCAm bHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyA2bWFuICZsdDtpcHY2QGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uY2VybnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48YnI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIEp1bCAzMCwgMjAyMCwgYXQgNjoyNiBQTSwgUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0PTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnIj5wdGh1YmVydD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgc3VwcG9ydCBHUkFO RCBiZWNhdXNlIGl0IGlzIGJldHRlciB0aGFuIG5vdGhpbmcgYW5kIHByb2dyZXNzaW5nIGp1c3Qg dGhhdCBhdCA2TUFOIHNlZW1zIHRvIGJlIGFuIGluY3JlZGlibGUgYWNoaWV2ZW1lbnQgYWxyZWFk eS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JbmRlZWQuICZuYnNwO0dS QU5EIHNlZW1zIGxpa2UgYSB0aGluZyB0aGF0IG9uZSB3b3VsZCBiZSB0ZW1wdGVkIHRvIGFkZCB0 byBhIHN0YWNrIGV2ZW4gaW4gdGhlIGFic2VuY2Ugb2YgYSBkcmFmdCBkZXNjcmliaW5nIGl0LiBI YXZpbmcgYSBkcmFmdCB0aGF0IGRlc2NyaWJlcyBob3cgdG8gZG8gaXQgaXMgYmV0dGVyLCBiZWNh dXNlIHdlIGNhbiB0aGVuIGhhdmUgYQ0KIGRpc2N1c3Npb24gb2Ygd2hhdCB0aGUgYmVuZWZpdHMg YW5kIGRyYXdiYWNrcyBhcmUsIGFuZCBtaXRpZ2F0ZSB0aGUgZHJhd2JhY2tzLiBUaGlzIGNvbmNl cm4gYWJvdXQgTkQgc2VjdXJpdHkgc2VlbXMgbGlrZSBhIHVzZWxlc3MgZGlncmVzc2lvbjogeWVz LCBORCBpcyBub3Qgc2VjdXJlLCB3ZSBrbm93IHRoaXMuIFdl4oCZdmUgdHJpZWQgdG8gYWRkcmVz cyBpdCB3aXRoIFNFTkQsIGJ1dCB0aGF0IGhhc27igJl0IGdvdHRlbiBhbnkgdHJhY3Rpb24gaW4N CiB0aGUgbWFya2V0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QXJlIHdlIHNlZWluZyBMMiBhdHRh Y2tzIG9uIE5EIGluIHRoZSB3aWxkPyBXaGF04oCZcyB0aGUgdGhyZWF0IG1vZGVsPyBJZiB0aGlz IGlzIGEgcmVhbCBjb25jZXJuLCBsZXTigJlzIGNvbmZyb250IGl0IGhlYWQtb24sIHJhdGhlciB0 aGFuIHRyeWluZyB0byBhZGRyZXNzIGl0IHBpZWNlbWVhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_a43ffd94d6364a0f869cd4c694ab7432boeingcom_-- From nobody Fri Jul 31 08:52:10 2020 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 EB4013A0A20; Fri, 31 Jul 2020 08:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbxZ4fRJeEIj; Fri, 31 Jul 2020 08:51:55 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EF63A0BD0; Fri, 31 Jul 2020 08:51:47 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id p14so8937725wmg.1; Fri, 31 Jul 2020 08:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=t84pnbmpmpPA+lTeT8QRhbojyA5i/sOyFAEdupOzB08=; b=JRRKnlGFVW3lz0iYNBrrc3l/LphNfOpW71WrsSIIvK2V3AsPt6PIILv/hpE4SCvayL 17IjxzDmx3vBU746fbvadAamaW7y5p6SYZNHI0o26YcqT6NfzzLHrwW2zICr1XIhjaMD 4jzwJaaFd/UatLZJyGcXGAK3/HXylY2708eY+a8rKS1JmWh9tgSMe5BxhbUmY6im9ubC ITwVDeZ59YnOr1G95hq1BHy9RuUCDk4GUMuaCxRHpPqecHWEe0IifXNmEKAMfasIgrTd 1N0l/8IqdnOqrROmjwFp7R/Tcxwq285JYJQgxBiezdFDypUMThetA3eeX0rjQS1Etoqd +5jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=t84pnbmpmpPA+lTeT8QRhbojyA5i/sOyFAEdupOzB08=; b=Rvdef85AObEU6GGvNk7QpSEY271erpPUlhAumNsEL2A4Xbr04VSk9CYhMb3cSt+Od5 8I/PXrwTcTH/z1Dww4borFiU5/4QEWmopaH/LsP6HrH8vPt1YrvfMYbvhESrs6aCYHkK 3xOI/ASWwM4rktGGhYJA3gV9ngGGyUferfz70B9XzUCcut0y5zR0SpcU05tNjooApwNW BPTC2xEUfFfUQfH9YhYzeOc3CgkJLRgtqgwFGuvE6k5JFlzidOl73VqpdxLp0PrO4JCI L6hg76MzLO6RMuXGE8gLwD6GLch9K6ZtqD/mWyEb65LGBP3Sn+KVJWC2d8VyoRN++5gL li9Q== X-Gm-Message-State: AOAM530rwvUzEy3hrPJVvqSnzZGxLSWRYBwfhyf/09Rdiz32BKnVlWbD PQm6uATxSp9Dueo1A+jJX5Zs54MQ X-Google-Smtp-Source: ABdhPJxNZSGTeSk+uPAWlPhoTvPd3PLyZb4eG+q7QKz0g+mMaDtVpGzcDdZNr0E1fYsAQI7aoQXMhQ== X-Received: by 2002:a1c:5416:: with SMTP id i22mr4469672wmb.172.1596210705736; Fri, 31 Jul 2020 08:51:45 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id u1sm15314777wrb.78.2020.07.31.08.51.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 08:51:45 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_67C18D59-6431-4ABE-8CB5-C6350AD4B6F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Fri, 31 Jul 2020 08:51:40 -0700 In-Reply-To: <94D12FD5-3A0A-4278-A229-F0D88EC906D6@fugue.com> Cc: Bob Hinden , Owen DeLong , Ted Lemon , "Pascal Thubert (pthubert)" , v6ops list To: IPv6 List References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <94D12FD5-3A0A-4278-A229-F0D88EC906D6@fugue.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 15:52:04 -0000 --Apple-Mail=_67C18D59-6431-4ABE-8CB5-C6350AD4B6F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, It=E2=80=99s fine to talk about how to improve ND in this list. However, please change the subject, I don=E2=80=99t think it=E2=80=99s = relevant to "I-D Action: draft-ietf-6man-grand-01=E2=80=9D Bob > On Jul 31, 2020, at 8:43 AM, Ted Lemon wrote: >=20 > On Jul 31, 2020, at 11:30 AM, Owen DeLong wrote: >> 1. Public wifi networks (e.g. coffee houses, etc.) >=20 > The BCP for this case is to isolate clients. >=20 >> 2. College/University settings (some v6 traction here, but often = not on student-device accessible LANs) >=20 > For this it would be to give each dorm room its own subnet. >=20 >> 3. Other networks which must admit untrusted clients/devices >=20 > E.g. home networks? Or something else? >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_67C18D59-6431-4ABE-8CB5-C6350AD4B6F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl8kPgwACgkQrut0EXfn u6iUuQf+MwMa+0beX9egMPi167hzIIXiK6udUme/ebNRiDXJQItT5VDYqhnpeKZP d+R53UIqJGMxD/ZOWtn5wnKl1gbun7chMhsa4v1UwEufJE6kxqmFChegeb/fhsGJ SDHz6TlJ/Xhe3EBx59JjAsLaStiUeVrCEr0A7jLZ8bnbIihMVolHgkkXJ/R8gTO7 nS/+pm35vadcLy0FN5UcVSxPgB8Av5jteRFrk5XgQwecSoSbbsiL0iIKJyodT1H6 vGcY1K6GHhLceKAmiV31pDx256Is0Z2GAOCZy6rNeh/Ghv90WopOdcSfhKGztj+0 aPzKx+Adu0pvymS/PkPR/no7fS2XJw== =YLd7 -----END PGP SIGNATURE----- --Apple-Mail=_67C18D59-6431-4ABE-8CB5-C6350AD4B6F4-- From nobody Fri Jul 31 08:54:15 2020 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 395A03A08C6 for ; Fri, 31 Jul 2020 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 926H2fuZ-gGQ for ; Fri, 31 Jul 2020 08:54:10 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A543A0EB8 for ; Fri, 31 Jul 2020 08:53:30 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id r19so5808881qvw.11 for ; Fri, 31 Jul 2020 08:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6IIynSuAndmkNL11taltJg3Jcr4QGplkjzw/dksWoDE=; b=twIYQ2D/8dWqIRCY8vDIftLaJjRCgKk3YW/ZIM8/mnC0L7leASMehUIvo8FMvk+Jof JwDFDsH9NeZG7UOpAJhGPYJGXhohQJy8Dbt/gEtiXMoSZUKPGrPE1xH5m9QymFcDIYXh 8VOKy7QXHmr2SmrCeJZh+5Mcn3Ru+DkHdH/zJilF40A3Cm7gjgDlbgW2yzWxV2XsfYIa P6c2H4sVECaNnJBCoQOA+eqhurLKA1QkkfAwatk5YNoSi+L6GDXrVxPu3IIPDBeQQUjh Nj+JbDIYPnLtbs5afjy9jOzh6AjWkl2fDrOJn+lyFWbeMZya95DkxYDyOIM/pnvNx2Jc CVVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6IIynSuAndmkNL11taltJg3Jcr4QGplkjzw/dksWoDE=; b=c1EYox/Fe2fMgscV5TQh5kdkc92eQntIOAgQFLeaf48aJNiKU/wGQDi4o8frzqjX+L kL30dGblYsKso2GzFSoPpFcclnZHj+/JnUf5O8PxdgsHHHE1meyX8+tzh5LELInB0Xo7 GzuojmYCp56x5pp0TzhYPWj42ZY5LJwjFn5taUFONDp4bmGDFJJ9L99xbqipQV2GH6kq FC1u9y7/8XaZ8JF4Pq8a5nQrDptmBjz28LAvcxEjM7Th4tqL2V9W2LIpovffmhuWaUgP tJf9B7ks7tOBW30Lu4AnkWr4uO7C5VhfH4Gwa3rnEVGxVxvsfeZP+O/pcq0B2DDwersr UbOQ== X-Gm-Message-State: AOAM5306WF42lKOCe+ZndoXCVuszwVNtRjH9PsYVztJoLHZm7GZ0HQTk /QUmELb7qv87lLrYh+MTrfNIeA== X-Google-Smtp-Source: ABdhPJxGM62jyvAYZXos3Uy+GZUaiQLnIgXx4ds5hmjB0q0G1/aoQxORWnmoPYJpyR8yfhanyWfM6g== X-Received: by 2002:a0c:b791:: with SMTP id l17mr4883168qve.44.1596210809906; Fri, 31 Jul 2020 08:53:29 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id t65sm7529831qkf.119.2020.07.31.08.53.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 08:53:29 -0700 (PDT) From: Ted Lemon Message-Id: <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B67D32EE-1699-404F-B189-A506157B3E8F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 11:53:27 -0400 In-Reply-To: Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: "Templin (US), Fred L" References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [v6ops] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 15:54:13 -0000 --Apple-Mail=_B67D32EE-1699-404F-B189-A506157B3E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 31, 2020, at 11:51 AM, Templin (US), Fred L = wrote: > I think that means that either SEND was ahead of its time and the = market for it is only > now beginning to materialize, or SEND is somehow broken and should be = deprecated. > I am interested to know which, since I believe I see a role for SEND. Yes, it will be interesting to see how this unfolds. I don=E2=80=99t see = anybody pushing for SEND at the moment. --Apple-Mail=_B67D32EE-1699-404F-B189-A506157B3E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 31, 2020, at 11:51 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
I think that means that either = SEND was ahead of its time and the market for it is only
now = beginning to materialize, or SEND is somehow broken and should be = deprecated.
I am = interested to know which, since I believe I see a role for = SEND.

Yes, it will be interesting to see how this unfolds. I = don=E2=80=99t see anybody pushing for SEND at the moment.

= --Apple-Mail=_B67D32EE-1699-404F-B189-A506157B3E8F-- From nobody Fri Jul 31 09:10:34 2020 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 877413A0B4C; Fri, 31 Jul 2020 09:10:32 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diTph4k7mYWc; Fri, 31 Jul 2020 09:10:31 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 3A19D3A0B39; Fri, 31 Jul 2020 09:10:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VGAR8m027002; Fri, 31 Jul 2020 12:10:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596211829; bh=YQ95+76eahGGbRBNwWNbpN9f952Ec/12SYpAjj2LVoQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JGowg+dt5YTDdVkjE3e5Dca/6KANKUgMrcV7vF7Dz1Vdt6YVx/OWE1P+4y2JmBFYA TT5ZRN3W4TarTXdMAauitG2e9nKKAAuapU9Um7OE732MPFJ4GNGK/FsO+X+1l77haJ GWQrlMHjc9gWZPQVWm5KvOD+bQL3q3hxssPlMv39ukaiKcc8rT/FUy9MFi40iKy4tU 3Fw8TVwv4j/fCxTBZHdCikYceSS6KNEiOF96kuBEclWoOm65Vx4YuOC5mVNEvLdkks z0G5hkJUuRREKbltja7zQDZVXZeZDgld4vMLAOP51Ln8qntnx/CPFqbq9n2iVwwOEJ 9E31wlhR7nOHA== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VGANds026696 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 12:10:23 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 09:10:21 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 09:10:21 -0700 From: "Templin (US), Fred L" To: Ted Lemon CC: "Pascal Thubert (pthubert)" , "v6ops list" , 6man Thread-Topic: [EXTERNAL] Improving ND security Thread-Index: AQHWZ1UXpJjqh6zAPESbZadyenD7WQ== Date: Fri, 31 Jul 2020 16:10:21 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> In-Reply-To: <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: A03966C4C2C4E29242B39E541CAC93AFFC9FBF2F4AEB6516BD557096DFC453E72000:8 Content-Type: multipart/alternative; boundary="_000_caa62d8d93594f7ea445a403fac8c140boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 16:10:33 -0000 --_000_caa62d8d93594f7ea445a403fac8c140boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gWWVzLCBpdCB3aWxsIGJlIGludGVyZXN0aW5nIHRvIHNlZSBob3cgdGhpcyB1bmZvbGRzLiBJ IGRvbuKAmXQgc2VlIGFueWJvZHkgcHVzaGluZyBmb3IgU0VORCBhdCB0aGUgbW9tZW50Lg0KWz5d DQpJIGxpa2UgU0VORCwgYW5kIGl0IGlzIHdyaXR0ZW4gaW50byBteSBkb2N1bWVudHMg4oCTIGlz IHRoYXQgZW5vdWdoIG9mIGEgcHVzaCwgb3IgZG8gSSBuZWVkDQp0byBkbyBtb3JlIGFnZ3Jlc3Np dmUgbWFya2V0aW5nPyBJbnRlcmVzdGVkIGluIGhlbHBpbmc/DQoNClRoYW5rcyAtIEZyZWQNCg0K --_000_caa62d8d93594f7ea445a403fac8c140boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE3NDQ4MzMwODI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0zNDcwMjIyMDIgLTE5MTQ1MjQ0MTIgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsgPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5ZZXMsIGl0IHdpbGwgYmUgaW50ZXJl c3RpbmcgdG8gc2VlIGhvdyB0aGlzIHVuZm9sZHMuIEkgZG9u4oCZdCBzZWUgYW55Ym9keSBwdXNo aW5nIGZvciBTRU5EIGF0IHRoZSBtb21lbnQuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WyZndDtdDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JIGxpa2UgU0VORCwgYW5kIGl0IGlzIHdyaXR0ZW4gaW50byBteSBkb2N1 bWVudHMg4oCTIGlzIHRoYXQgZW5vdWdoIG9mIGEgcHVzaCwgb3IgZG8gSSBuZWVkPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dG8gZG8gbW9yZSBhZ2dyZXNzaXZlIG1hcmtldGluZz8g SW50ZXJlc3RlZCBpbiBoZWxwaW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+ PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_caa62d8d93594f7ea445a403fac8c140boeingcom_-- From nobody Fri Jul 31 09:13:39 2020 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 14C9D3A0C66 for ; Fri, 31 Jul 2020 09:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzpVyXovTcx7 for ; Fri, 31 Jul 2020 09:13:29 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1F13A0BCE for ; Fri, 31 Jul 2020 09:12:52 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id b14so27552449qkn.4 for ; Fri, 31 Jul 2020 09:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZFSKm57tuKvxfUZf26XprYQTFg4PePDFcGTmsAp679I=; b=d7Ji/8eNQlD4tkBzL2vk1rwdwCX6C/0SBCdZHy7zygko1KVa1Guai9nrHt9RSJBijH /LsDdSKuiPzPlE+daF9q12vKjZ3NimvkJJxZBU8UPt5OOGGITaZZUpdGh06tm5+OSbL6 Z4do7pKCTKJyjJlj4As6kDyduIpKT2dAPCnndZ26l2zmVW7qPUbbLSzAEfyZigX+6GHt XdjZDfDjRJITS5ov8m0brew7lTmlt5cSgU74j4NKfrw6aLAETghDVb2JLOfp2NJsATTU MwsylyQ/VOet+FFDrkMAIl+lFOulgX1ncNmO71TsXsgAyPT22tl2k9wOFtb6PcFRHN+R Tueg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZFSKm57tuKvxfUZf26XprYQTFg4PePDFcGTmsAp679I=; b=nLkIX0gzKqiByZFJi4b9V5Shdf5HLNEQa/lpfGoPDe/3ZRrny/mD8FGR+MJxJixf0a XmlYTAhhzetJpfCsfyfEnvRJuwtdZt/uKRmoFUg3eyV4LFW0ZrfrMyzx6yiIdiYIBlzN /pKfYKHhfXVZ6d7NE572RtnQwP9yqoYJR3uD3K2T2yh9qORZwk1Qc1ioATg5XmiAUV8+ LOUjB8eXqWr7oFf2fXSUYaWGkRQQGLHTHkUP3dF3BL2Kc2vhLf6M36uJEPGdsdNUTbHO TbDGSsp84PYFgWQTXPjkQ0fIVfoe0N/K581A11QE0zQreX8rDV6ZGlgyohP1jg7m5WxJ Ic9Q== X-Gm-Message-State: AOAM5338PtBvOj0OGJGlHdo9oT7Yd5qNkPzyz/jDikaIhdq+11hLzNvp RrmMptnvRlkw9rIuRtE4iQ5gkQ== X-Google-Smtp-Source: ABdhPJy7H1ZjLEUExzgL3Jv1EgQV1FT7fDv7kVaSeS9bHWqURgwaR5CHCd2ypcELQYi4MgzP4RjPXw== X-Received: by 2002:a05:620a:15e9:: with SMTP id p9mr5056716qkm.38.1596211971436; Fri, 31 Jul 2020 09:12:51 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id c9sm8339449qkm.44.2020.07.31.09.12.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 09:12:51 -0700 (PDT) From: Ted Lemon Message-Id: <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_781F7F06-DE41-4D90-83CC-D5F4F2D3C17B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 12:12:49 -0400 In-Reply-To: Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: "Templin (US), Fred L" References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 16:13:37 -0000 --Apple-Mail=_781F7F06-DE41-4D90-83CC-D5F4F2D3C17B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 31, 2020, at 12:10 PM, Templin (US), Fred L = wrote: > I like SEND, and it is written into my documents =E2=80=93 is that = enough of a push, or do I need > to do more aggressive marketing? Interested in helping? The push would have to be from somebody producing software that has = broad reach. And it would have to solve a real problem or nobody with = that reach would try to do it. Does it solve the problem Owen was talking about (overloading neighbor = tables as an attack)? Is there agreement that this is a serious problem = in any case? --Apple-Mail=_781F7F06-DE41-4D90-83CC-D5F4F2D3C17B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 31, 2020, at 12:10 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
I like SEND, and it is written into my documents =E2=80=93 is = that enough of a push, or do I need
to do more aggressive marketing? Interested in = helping?

The push would have to be from somebody producing software = that has broad reach. And it would have to solve a real problem or = nobody with that reach would try to do it.

Does it solve the problem Owen was = talking about (overloading neighbor tables as an attack)?  Is there = agreement that this is a serious problem in any case?

= --Apple-Mail=_781F7F06-DE41-4D90-83CC-D5F4F2D3C17B-- From nobody Fri Jul 31 09:14:26 2020 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 513713A1056; Fri, 31 Jul 2020 09:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0MG0olgN__l; Fri, 31 Jul 2020 09:14:12 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (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 D75903A0F1C; Fri, 31 Jul 2020 09:13:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42710) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1k1Xet-000KX2-mV (Exim 4.92.3) (return-path ); Fri, 31 Jul 2020 17:13:23 +0100 Date: Fri, 31 Jul 2020 17:13:22 +0100 From: Tony Finch To: Owen DeLong cc: Ted Lemon , "Pascal Thubert (pthubert)" , v6ops list , 6man In-Reply-To: Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1870870841-315556031-1596212003=:16320" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 16:14:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-315556031-1596212003=:16320 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Owen DeLong wrote: > > Indeed, as an operator, IMHO, if there=E2=80=99s a place we need to focus= on > improving L2 attack surface in v6, it=E2=80=99s in finding better ways fo= r > {routers, hosts, switches} to mitigate/absorb this type of resource > exhaustion attack. Unfortunately, this is a hard problem to solve, so we > focus on moving the deck chairs we can move while ignoring the > elephant-sized hole in the bulkheads that we don=E2=80=99t know how to pa= tch. If GRAND is deployed, would that allow routers to assume their neighbour tables are complete, so they can just drop ND exhaustion attacks? Tony. --=20 f.anthony.n.finch http://dotat.at/ Shannon, Southeast Rockall: Westerly or southwesterly 4 or 5. Moderate or rough. Showers. Good, occasionally moderate. --1870870841-315556031-1596212003=:16320-- From nobody Fri Jul 31 09:21:22 2020 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 E09313A0AEF; Fri, 31 Jul 2020 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DBfsgrvO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HPImW4IL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NcXaUo4TafR; Fri, 31 Jul 2020 09:21:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8683A08CD; Fri, 31 Jul 2020 09:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48625; q=dns/txt; s=iport; t=1596212476; x=1597422076; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TH3m3B1fbTljmBDYNcnWOv1PoM4g82tSsZy4GtwHPvc=; b=DBfsgrvOMXzpmEJa+WXlDoLXmzqt7NNUG90J9KFENvSSue/0f5Ap3548 r2HoWQoD1GBZOps575rERTzCWLmhsXAZLAUSo9PS/mop1IT+uvamwoCLr SW67IThAgcpDsXlB6H17YUH7715GSj/J8yTUXVLzPJDvWUl+UqlVh1Vkj Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A8kOCABOPSbk37nHXKhUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeBgA7QyRf/5pdJa1gHAMDBxYEBII?= =?us-ascii?q?MgVIpKAdvWC8shDWDRgONToECiQGOX4FCgREDUAULAQEBDAEBGAEOBgIEAQG?= =?us-ascii?q?ETAIXghwCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAwEBARAICR0BASo?= =?us-ascii?q?CCwEEBwQCAQYQAwQBAQEgBwMCAgIfBgsUAwEFCAIEDgUbB4MEAYF+TQMOIAE?= =?us-ascii?q?OlSuQaAKBOYhhdoEygwEBAQWBMwEDAgENQUKCTQ0Lgg4JgTiCcIJSEjlCgQG?= =?us-ascii?q?Cc4IuHRqBQT+BEAEnHIFPSXOCGkIBAQEBAQEVgQhkBxGCWDOCLY9aIg4Dgma?= =?us-ascii?q?GXZtwTgqCYIhcjC+EeQMVCYJ7gSKIKpMwjGiPboJhjWqEJQIEAgQFAg4BAQW?= =?us-ascii?q?BQCojgVdwFRohKgGCPglHFwINV41UF4ECAQKCSYUUhUJ0AjUCBgEHAQEDCXy?= =?us-ascii?q?QIwEB?= X-IronPort-AV: E=Sophos;i="5.75,418,1589241600"; d="scan'208,217";a="520501837" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jul 2020 16:21:14 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 06VGLE40003370 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jul 2020 16:21:14 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 11:21:13 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 12:21:12 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 11:21:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYDblxi6fE4R70Kk/kLTNmGXKHz9F1aWoA3ZKGPmQLBFyng4aCZFhP7MZwfqJDDLZeuFbjnfrYC3uEvabQqAbaNfHef7leO52uY8VjkS/Ui1b7qVji8B26FmiBZrxbCaj0ywzi7HdCxEX5+L1x51LXLaLs12ivxztDh0mzHFXwwakkUzKFP8h3srRKSKTa/LNXUp0omvdHeQjO1lYzUec5RXBhOvdY9+jATVxpbFto9j6o/3aPcNrD4186FfSPR+KBz6BHNwamaPkjAZEMbirSlzQZGRb8tPulBrkujOUr6CMMzDmV8zM/JYcpUN8bFjhrRO/GYj4hiZ5fMoFXQOrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TH3m3B1fbTljmBDYNcnWOv1PoM4g82tSsZy4GtwHPvc=; b=J6zz1PxYn+OuBXS5Sa9erd3hrYyp4jvZr7fNEvtojWx8gsXOyxkpDV4Ul88m56gvK/dvuRvBS+dXV0CHe9wor7XXaYsEwscLci5F5Nbju4tosknOZzlUe6X4Oh8HeHK9US+RK4Mm1ejhWCUF07S6p6ydvnAPEM0D4ODW4coTcxX3ZdxvQlJ7O1x/1ZIabUoTrpfvosht3DxjEocZJF1fZcFM3NnIjXPcel+qytqM7Bl45TjN7CrTtgw6PopdtLIvPrd9x8YQA3ZlXDaqdCN370Z0Fow79McOX/7b76wDXACrdt6llfGdd2GqIj9sK8mVqh6bRzyj/g5wPkfTakulfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TH3m3B1fbTljmBDYNcnWOv1PoM4g82tSsZy4GtwHPvc=; b=HPImW4IL9gIWHekoGS1f3xtWMc8ufme8fYMIRS4vICHuiF9Adyh13twDsHbQZd8CGEKl8UuxzeQg5YSSYKe0vPEHl82iKAwyCYEVXWl9uKS3QwZGnNkTYBAkH0oZxeKgDC1GFF0wcpXeuAeQc8qXnX21EqOtIVJwPPoAVtKVQnQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4518.namprd11.prod.outlook.com (2603:10b6:208:24f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.18; Fri, 31 Jul 2020 16:21:11 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::a53e:5801:92cc:3204]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::a53e:5801:92cc:3204%5]) with mapi id 15.20.3239.020; Fri, 31 Jul 2020 16:21:11 +0000 From: "Pascal Thubert (pthubert)" To: Jen Linkova CC: 6man , IPv6 Operations Thread-Topic: draft-ietf-6man-grand : saving lookups Thread-Index: AQHWZ1aaeJpnUJSV20aes48tEhFRoA== Date: Fri, 31 Jul 2020 16:21:11 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:605b:dc17:3a62:afa7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a336d89-4ff0-46fa-0670-08d8356dbd69 x-ms-traffictypediagnostic: MN2PR11MB4518: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GMcazggmb1mdLw9IRIk3rYMd8NkQkdjzbwEUPPoIUJBfv4UBFEo8md+YQHU7wsOK0CBYE3u9ZoFKYBnEh3uQQJfO42R4ahYKlw1283P4cUpiRm9vpzJRz+l6VT0Vj9xrXddrR0GxA0Rn3bcSiUb0JN77B3RHzMV9oSj3EyF+NkHzJgo00F0Wd/QrAf6n3ZO/RAGEsA4anuOrBtgxCDRxeIuRx8CBsYU4m4qt8ei+BwOfpNc/CEvMsNxwdSt4GWZA08Ax8C7kpIo5gfC7BWXeGAP6b0lSeMee01oMz+K9s+2qwtuxJybjBx85X66vUGTs+xZZ26PHb+5shlKAqlV9HYVAw4tDxfTVPPlHy/hw/CAftyYmR+vrrYRcQGHuA7GiKafV+fpVKjjLvEY1Nd/Yu4W8fbClfmPv78RsTBBGqehy1Xf1cEs/L9aInmI9DOj7GRLN5l8SDwUmOkVu6C4b5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(39860400002)(346002)(366004)(136003)(2906002)(5660300002)(33656002)(30864003)(66574015)(6916009)(83380400001)(2616005)(186003)(4326008)(66476007)(66556008)(64756008)(66446008)(66946007)(76116006)(316002)(91956017)(53546011)(71200400001)(6486002)(4743002)(166002)(478600001)(966005)(86362001)(8676002)(6512007)(54906003)(21615005)(6506007)(36756003)(8936002)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qug1LWb18JJMPorLoGtAVQxA2IG/O34VbRJNiWCSUxja53O+POR/kkuqwF37qTC2Tyz8ICdHSEUbdoJgWCrhTCuEwaVEaQEi4yNxVqF5t/hurg7jc5Er1kKgTQgNytD0oNYui52z6rUlsoOCsYSiLrZOq2X6+zfEV7GfNKNhlchNAdSRvVdZr3ffl02IFPB3Wy8hSpgo9lWmASnpv0W1/nWzBzUHR8m/0tixG1hiUVnCU35QCWSvsQxsSlirJovnBMiyUCJtMsfuSKyfDVeKgFLUu1aNAC8FXZJdgrkCzaYnsXRfAWbThfFBuLklflIS6f4jo4TZCae5mlZa5uVZSNc8mDEmafTe4+JONLi3bnNEcy2p79N36xtquoea87xP1Xz/GwPuMehO1Ct2XupXWLttvFxbshCds2PfVh2uIQ7PgMPT2VW7w1q52qFz/yLzejP/4zqyJiaBnLcXm3DoJHBW03nBn9CuYLEsyCKaJxAjZJ04jN9gIJV/g1KsIMzyVU2sZx2IyYErH+Xqywut9yFs5FjcLEah41rOESzo5zwzAqv0ovQ/Equ5RuKht1ICUGC4qYQXp9WyqRoMiR3xjSjO4A7ozqXtrzBmMmN7rlGfmJj30da6agiSp2JFfhBsYvYrFOdY7N/l3Dj8tJi27tZIRcK+idS0c14jU0n/bIjDYvia6KeD1XPLQYdfWHB0k/S9rIxExdxFAuvV4/zKZQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E176B08424E1434DB15CF364F64807BBciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a336d89-4ff0-46fa-0670-08d8356dbd69 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 16:21:11.6360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SGAs9B3fe25F5LED39UNbxp7jlJwrB+Ou5P/ryftXgMhfogBeBIQUo8O02lFBx/sjhjG2hfOysrIfpYa26g9mw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4518 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: [v6ops] draft-ietf-6man-grand : saving lookups X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 16:21:21 -0000 --_000_E176B08424E1434DB15CF364F64807BBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSmVuDQoNClNpbmNlIHRoZSByb3V0ZXIgaXMgcHJlcG9wdWxhdGVkLCBpdCBrbm93cyB0 aGUgTkQgcmVzb2x1dGlvbiBiZWZvcmUgaG9zdHMgZG8uDQoNClNvIHNheSBhIHRoaXJkIHBhcnR5 IGhvc3QgaGFzIHRyYWZmaWMgdG8gc2VuZCBhbmQgdGhlIHByZWZpeCBpcyBvbmxpbmUuIEl0IHdp bGwgc3RvcmUgb25lIHBhY2tldCBhbmQgbXVsdGljYXN0IGEgbG9va3VwIHRvIHRoZSBzbm1hIG9m IHRoaXMgbm9kZS4gSXQgd2lsbCBkcm9wIHRoZSBvdGhlciBwYWNrZXRzLg0KDQpBbiBhbHRlcm5h dGUgYmVoYXZpb3IgaW4gYSBuZXR3b3JrIHdoZXJlIEdSQU5EIGlzIGVuYWJsZWQgY291bGQgYmUg dG8gc3RhcnQgYnkgZm9yd2FyZGluZyB0aGUgcGFja2V0cyB0byB0aGUgcm91dGVyIGluIGNhc2Ug b2YgYU4gTkQgY2FjaGUgbWlzcy4NCg0KSWYgdGhlIHJvdXRlciBhbHJlYWR5IGhhcyBhbiBOQ0Ug dGhlcmUgd2lsbCBub3QgYmUgYSBsb29rdXAgYXQgYWxsLiBUaGUgcm91dGVyIHdpbGwgcmVkaXJl Y3QgaW1tZWRpYXRlbHkgYW5kIHJlbGF5IHRoZSBwYWNrZXRzIGluIHRoZSBtZWFudGltZS4gTm8g ZGVsYXksIG5vIGxvc3MuIEFuZCBubyBtdWx0aWNhc3QuLi4NCg0KSWYgdGhlIHJvdXRlciBkb2Vz IG5vdCBoYXZlIGEgY2FjaGUsIGl0IHdpbGwgZG8gdGhlIE5TIGxvb2t1cC4gQW5kIGV2ZW50dWFs bHkgcmVkaXJlY3QgYW55d2F5IGlmIHRoZSB0cmFmZmljIGNvbnRpbnVlcy4gU2FtZSBvdmVyYWxs IGNvc3QsIHdpdGggdGhlIGJlbmVmaXQgdGhhdCB0aGUgcm91dGVyIG5vdyBoYXMgdGhlIGNhY2hl IHJlYWR5IGluIGNhc2UgeWV0IGFub3RoZXIgaG9zdCBuZWVkcyBpdC4NCg0KT3ZlcmFsbCBiZW5l Zml0cyBkYXkgMSwgaW5jcmVtZW50YWxseSB1c2VmdWwgYXMgR1JBTkQgZ2V0cyBkZXBsb3llZC4N Cg0KQ2hlcnJ5IG9uIHRoZSBjYWtlOiB0aGUgcm91dGVyIG1heSBiZSBtb3JlIFNBVkktc2F2dnkg dGhhbiB0aGlzIGhvc3Qgc28gaXQgbWF5IHJlZGlyZWN0IHRvIHRoZSByZWFsIGZpcnN0LWNvbWUg bm9kZS4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNClBhc2NhbA0KDQpMZSAzMCBqdWlsLiAyMDIw IMOgIDEyOjM3LCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem89NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnPiBhIMOpY3JpdCA6DQoNCu+7vw0KSSB0aGluayB0aGUgZmFjdCBpcyB0aGF0IE5EIGlz IGluaGVyZW50bHkgaW5zZWN1cmUgZnJvbSBvbi1saW5rIGF0dGFja3MuIElmIHNlY3VyaXR5IGlz IGRlc2lyZWQsIHRoZW4gaXQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgaW4gb3RoZXIgd2F5cywgc3Vj aCBhcyB2aWEgU0VORCBvciBTQVZJLiBCdXQgaXQncyBhbHNvIG5vdCBwYXJ0aWN1bGFybHkgZGVz aXJhYmxlIHRvIHByb3ZpZGUgc2VjdXJpdHkgYXQgdGhpcyBsYXllci4gVHJhZmZpYyBzbm9vcGlu ZyBpcyBub3QgdmVyeSB1c2VmdWwgKG5vdCB6ZXJvIHV0aWxpdHksIGJ1dCBkaWZmaWN1bHQgdG8g dXNlIHdlbGwpIHdoZW4gYWxsIHRyYWZmaWMgaXMgZW5jcnlwdGVkLCBhbmQgb24tbGluayBEb1Mg YXR0YWNrcyBqdXN0IGFyZW4ndCB2ZXJ5IHVzZWZ1bCB0aGVzZSBkYXlzIGdpdmVuIHRoYXQgbWFu eSBkZXZpY2VzIGhhdmUgYSB2YXJpZXR5IG9mIGNvbm5lY3Rpdml0eSBvcHRpb25zLg0KDQpPbiBU aHUsIEp1bCAzMCwgMjAyMCBhdCA1OjA1IFBNIFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4gd3Jv dGU6DQpUaGVuIGl0IGlzIG5vdCBsb2dpY2FsIGZvciBtZToNCk1hbnkgcGVvcGxlIHVuZGVyc3Rh bmQgdGhhdCAiVW5zb2xpY2l0ZWQgTkEiIGlzIGEgYmlnIHNlY3VyaXR5IGhvbGUgcGVyIHNlLA0K QnV0IGluc3RlYWQgb2YgZml4aW5nIGl0IChtYXkgYmUgZXZlbiBkZXByZWNhdGUgLSBzaG91bGQg YmUgaW52ZXN0aWdhdGVkKQ0KQWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGlzIGJ1aWxkaW5nIG9u IHRvcCBvZiBpdC4NCkl0IHdvdWxkIGFkZGl0aW9uYWxseSBjaGFsbGVuZ2UgdGhpcyBzZWN1cml0 eSBwcm9ibGVtIHJlc29sdXRpb24gaW4gdGhlIGZ1dHVyZSENCg0KQWdhaW46ICJVbnNvbGljaXRl ZCBOQSIgd2l0aCBPdmVycmlkZSBiaXQgc2V0IC0gaXMgYSBkaXNhc3RlciBub3cuLg0KSU1ITzog aXQgaXMgYmV0dGVyIHRvIHByb2hpYml0ICJVbnNvbGljaXRlZCBOQSIuIExldCdzIHdhaXQgdGlt ZXJzIGZvciB0aGUgY2FzZSBvZiBNQUMgYWRkcmVzcyBjaGFuZ2Ugb24gbGVnaXRpbWF0ZSBob3N0 Lg0KTWF5IGJlIHdlIGNvdWxkIHRoaW5rIGFib3V0IG90aGVyIHNvbHV0aW9ucy4NCkJ1dCBpZiBh ZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgd291bGQgYmUgYnVpbHQgb24gdG9wIG9mICJVbnNvbGlj aXRlZCBOQSIgLSBsZXNzIG9wdGlvbnMgd291bGQgYmUgYXZhaWxhYmxlICgiZGVwcmVjYXRlIiB3 b3VsZCBiZSBub3QgYSBjaG9pY2UgYW55bW9yZSkuDQoNCklmIHNvbWV0aGluZyBpcyBpbGwgLSBp dCBzaG91bGQgYmUgY3VyZWQgZmlyc3QgLSBib2R5YnVpbGRpbmcgbWFrZSBzZW5zZSBvbmx5IGFm dGVyIHRoaXMuDQoNCkplbiwgSSBoYXZlIG5vdCB1bmRlcnN0b29kIGJlbG93IHdoeSB5b3UgZGlk IG1lbnRpb24gUkEgR3VhcmQuIEludHJ1ZGVyIGRvZXMgbm90IG5lZWQgaXQuIEhlIGp1c3QgY2xh aW0gKGJ5IFVuc29saWNpdGVkIE5BKSB0aGF0IGhpcyBNQUMgaXMgY29ubmVjdGVkIHRvIEdVQSBv ZiB2aWN0aW0uDQpJbnRydWRlciBjb3VsZCBjbGFpbSBpdCBldmVyeSA1IHNlY29uZHMgdG8ga2Vl cCBjYWNoZSBpbiBTVEFMRSBzdGF0ZSAoZm9yIHRoZSBjYXNlIG9mIHZlcnkgY2FyZWZ1bCB2ZW5k b3IgaW1wbGVtZW50YXRpb24gb2YgTkQpLg0KQXMgeW91IG1lbnRpb25lZCAtIG5vIGhlbHAgZnJv bSBNTEQgc25vb3Bpbmcgb24gc3dpdGNoZXMgLSBpdCB3b3VsZCBiZSBlbm91Z2ggdG8ganVzdCBs aXN0ZW4gdG8gREFELiBTd2l0Y2ggY291bGQgbm90IGhlbHAgaW4gcHJpbmNpcGxlLg0KVGhlIGZp cnN0IG1vZGlmaWVkIEROUyByZXNwb25zZSB3b3VsZCBjb252ZXJ0IHRyYWZmaWMgZmxvdyB0byBi aS1kaXJlY3Rpb25hbCBmb3IgSW50cnVkZXIuDQoNCkVkLw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEplbiBMaW5rb3ZhIFttYWlsdG86ZnVycnkxM0BnbWFpbC5jb208bWFpbHRv OmZ1cnJ5MTNAZ21haWwuY29tPl0NClNlbnQ6IDMwINC40Y7Qu9GPIDIwMjAg0LMuIDU6MDcNClRv OiBWYXNpbGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnZh c2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4+DQpDYzogNm1hbiA8aXB2NkBpZXRmLm9yZzxtYWls dG86aXB2NkBpZXRmLm9yZz4+OyB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxIC0gYWRk aXRpb25hbCBzZWN1cml0eSBjb25jZXJucw0KDQpPbiBUaHUsIEp1bCAzMCwgMjAyMCBhdCA1OjU2 IEFNIFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTxtYWlsdG86 dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4gd3JvdGU6DQo+IFlvdSBkaWQgYXNrIGEgZmVl ZGJhY2sgeWVzdGVyZGF5IGFib3V0IHNldmVyaXR5IG9mIDdzZWMgc2VjdXJpdHkgaG9sZSB0aGF0 IGhhcyB2ZXJ5IGxvdyBwcm9iYWJpbGl0eS4NCj4gSSBoYXZlIGludGVudGlvbiBoZXJlIHRvIHNo b3cgdGhhdCBwcm9iYWJpbGl0eSBpcyAxMDAlLCA3c2VjIGNvdWxkIGJlIHByb2xvbmdlZCB0byBm b3JldmVyLCBhbmQgdGhlIGZpbmFsIHJlc3VsdCBpcyB0aGUgZnVsbCBpbnRlcmNlcHRpb24gb2Yg aW5ub2NlbnQgaG9zdCB0cmFmZmljIGJ5IGludHJ1ZGVyIChzdWNjZXNzZnVsICJtYW4taW4tdGhl LW1pZGRsZSIpLg0KPg0KPiBQcmUtcmVxdWVzdCBmb3Igc3VjY2VzczoNCj4gLSBubyBtdWx0aWNh c3Qgc25vb3BpbmcgKE1MRCkgYW5kIGZpbHRlcmluZyBvbiBhIHN3aXRjaCwgdGhhdCBpcw0KPiBw ZXJmZWN0bHkgcG9zc2libGUNCj4gLSBJbnRydWRlciBzaG91bGQgYmUgYWxyZWFkeSBvbiB0aGUg c2FtZSBzdWJuZXQgKGdhaW5lZCBjb250cm9sIG92ZXINCj4gb3RoZXIgaG9zdCBieSBleHBsb2l0 aW5nIG9mIGRpZmZlcmVudCB2dWxuZXJhYmlsaXR5KQ0KPiAtIGludHJ1ZGVyIHNob3VsZCBzdXBw cmVzcyBEQUQgb24gSW50cnVkZXIncyBjb250cm9sbGVkIGhvc3QgKGlzDQo+IFdpbmRvd3MgZmly ZXdhbGwgY2FwYWJsZSB0byBmaWx0ZXIgb3V0IERBRD8pDQo+IC0gV2UgYXNzdW1lIHRoYXQgd2Ug YXJlIHRhbGtpbmcgYWJvdXQgdGhlIGZ1dHVyZSB3aGVuIHRoaXMgZHJhZnQgaXMNCj4gdXNlZCBi eSBtYWpvcml0eSBvZiBub2RlcyAodmljdGltIHNob3VsZCB1c2UgaXQpDQo+DQo+IFByb2NlZHVy ZToNCj4gSW50cnVkZXIncyBjb250cm9sbGVkIGhvc3QgZG9lcyBsaXN0ZW4gdG8gYWxsLXJvdXRl cnMgbXVsdGljYXN0IGFkZHJlc3MgKGZmMDI6OjIpLg0KPiBBcyBzb29uIGFzIGl0IHdvdWxkIGVh dmVzZHJvcCB1bnNvbGljaXRlZCBOQSBmcm9tIHZpY3RpbSBub2RlIChwcm9iYWJseSBhZnRlciBi b290KSAtIEludHJ1ZGVyIHdvdWxkIGltbWVkaWF0ZWx5IChhIGZldyBtaWxsaXNlY29uZHMpIGR1 cGxpY2F0ZSBOQSBpbiByb3V0ZXIncyBkaXJlY3Rpb24sIGJ1dCB3aXRoIDIgY2hhbmdlczogKDEp IGhpcyBMTEEgKE1BQyk7ICgyKSBPdmVycmlkZSBiaXQgc2V0Lg0KPiBJbnRydWRlciBoYXMgdGlt ZSBvbmx5IHVwIHRvIHRoZSBwb2ludCB0aGF0IHJlc3BvbnNlIHRvIHZpY3RpbSdzIHRyYWZmaWMg d291bGQgYmUgcmV0dXJuZWQgZnJvbSB0aGUgSW50ZXJuZXQgKGZyb20gdGVucyBvZiBtaWxsaXNl Y29uZHMgdG8gbWFueSBzZWNvbmRzIGlmIHZpY3RpbSB3b3VsZCBub3Qgc3RhcnQgc2VuZGluZyBp bW1lZGlhdGVseSksIC0gYnV0IGl0IGlzIGVub3VnaCB0aW1lOiBsb2NhbCBjb21tdW5pY2F0aW9u IHNob3VsZCBiZSBmYXN0ZXIuDQo+IFRoZW9yZXRpY2FsbHksIFJldHJhbnNUaW1lciBzaG91bGQg YmUgaW1wb3NlZCBvbiB1bnNvbGljaXRlZCBOQSAoc2VjdGlvbiA3LjIuNiksIGJ1dCBsb3cgY2hh bmNlcyB0aGF0IHRoaXMgdGltZXIgaXMgY2hlY2tlZCBvbiByZWNlaXZpbmcgc2lkZSAocm91dGVy KSwgYmVjYXVzZSBSZXRyYW5zVGltZXIgaXMgc3BlY2lmaWVkIGZvciB0cmFuc21pc3Npb24gc2lk ZS4NCj4gQWNjb3JkaW5nIFJGQyA0NjgxIHNlY3Rpb24gNy4yLjUgY2xhdXNlIElJOiBPIGJpdCBz ZXQgc2hvdWxkIG5vdCBqdXN0IHJld3JpdGUgTkQgY2FjaGUsIGJ1dCBhZGRpdGlvbmFsbHkgbWFy ayBORCByZWNvcmQgYXMgUkVBQ0hBQkxFLiBBY2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIuNjogIiBU aGUgT3ZlcnJpZGUgZmxhZyAoZm9yIHVuc29saWNpdGVkIE5BKSBNQVkgYmUgc2V0IHRvIGVpdGhl ciB6ZXJvIG9yIG9uZSIuIERlc3BpdGUgaXQgY29udHJhZGljdHMgdG8gdGhlIGxvZ2ljIG9mIHRo ZSB3aG9sZSBSRkMgNDY4MSAoTyBiaXQgc2hvdWxkIG5vdCBiZSBzZXQgaW4gdW5zb2xpY2l0ZWQg TkEgLSBpdCBpcyBtZW50aW9uZWQgaW4gYSBmZXcgcGxhY2VzIG9mIFJGQyA0NjgxKS4gQnV0IGJl Y2F1c2Ugc2VjdGlvbiA3LjIuNSBhbmQgc2VjdGlvbiA3LjIuNiBjbGVhcmx5IHBlcm1pdCB0byB1 c2UgT3ZlcnJpZGUgZmxhZyAtIGhpZ2hlciBwcm9iYWJpbGl0eSB0aGF0IHBhcnRpY3VsYXIgaW1w bGVtZW50YXRpb24gd291bGQgbm90IGp1c3QgcmV3cml0ZSBMTEEgb24gcm91dGVyLCBidXQgYWRk aXRpb25hbGx5IHB1dCBpdCBpbnRvIFJFQUNIQUJMRS4NCj4gSW50cnVkZXIgY291bGQgYmUgc3Vy ZSB0aGF0IGF0IGxlYXN0IFNUQUxFIHN0YXRlIHdvdWxkIGJlIGNyZWF0ZWQgYWNjb3JkaW5nIHRv IHNlY3Rpb24gNy4yLjUgY2xhdXNlIEksIC0gdGhpcyBORCByZWNvcmQgd291bGQgYmUgYWdhaW5z dCBoaXMgTExBIGFueXdheS4NCj4gQWZ0ZXIgcmVjZWl2aW5nIHJldHVybiB0cmFmZmljIChpZiBp dCB3YXMgY3JlYXRlZCBhcyBTVEFMRSwgbm90IFJFQUNIQUJMRSkgLSByb3V0ZXIgd291bGQgYXNr IGludHJ1ZGVyIGFib3V0IHJlYWNoYWJpbGl0eSAoc29saWNpdGVkIE5TLU5BKSAtIGludHJ1ZGVy IHdvdWxkIGNvbmZpcm0gaGlzIExMQSAtIGl0IHdvdWxkIGZpbmFsbHkgcHV0IE5EIGNhY2hlIHJl Y29yZCBpbnRvIFJFQUNIQUJMRS4NCg0KMSkgdGhlIDcgc2Vjb25kcyBjb3JuZXIgY2FzZSB3YXMg Zm9yICdwcmV2ZW50aW5nIGFkZHJlc3MgY29sbGlzaW9uIGZvciBPcHRpbWlzdGljIERBRCcsIG5v dCBmb3IgYW55IGludGVudGlvbmFsIGF0dGFja3MgY2FzZS4gQmVjYXVzZToNCjIpIFdoYXQgeW91 IGFyZSBkZXNjcmliaW5nIGNvdWxkIGJlIGRvbmUgdG9kYXksIG5vdywgYW55dGltZSB3L28gdGhl IGNoYW5nZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSWYgdGhlcmUgaXMgbm8gTUxEIHNub29w aW5nIHRoZW4gdGhlIGludHJ1ZGVyIHdvdWxkIHNlZSB0aGUgREFEIHBhY2tldCBmcm9tIHRoZSB2 aWN0aW0sIHNvIGl0IHdvdWxkIGtub3cgdGhlIHZpY3RpbSBhZGRyZXNzIGFueXdheSAgLSBubyBy ZWFzb24gZXZlbiB0byBqb2luIGZmMDI6OjIuIE5vdyBhbGwgdGhlIGF0dGFja2VyIG5lZWRzIHRv IGRvIGlzIHRvIGtlZXAgc2VuZGluZyBOQSB3aXRoIFM9MSwgTz0xIC0gaG9waW5nIHRoYXQgd2hl biB0aGUgZmlyc3QgcGFja2V0IG9mIHRoZSByZXR1cm4gZmxvd3MgYXJyaXZlIGFuZCB0aGUgcm91 dGVyIGNyZWF0ZXMgYW4gSU5DT01QTEVURSBlbnRyeSBhbmQgc2VuZHMgYW4gTlMsIHRoZSBhdHRh Y2tlcidzIHBhY2tldCB3b3VsZCBjb21lIGJlZm9yZSB0aGUgdmljdGltJ3MgTkEuIERvbmUsIHRo ZSAgZW50cnkgaXMgY2hhbmdlZCB0byBSRUFDSEFCTEUsIGFsbCB0cmFmZmljIGdvZXMgdG8gdGhl IGF0dGFja2VyLg0KQWN0dWFsbHkgZXZlbiBzaW1wbGVyLiBUaGUgYXR0YWNrZXIgZG9lcyBub3Qg bmVlZCB0byBkZWFsIHdpdGggdGltaW5nLg0KTGV0J3Mgc2F5IHRoZSByb3V0ZXIgaGFzIGFuIE5D IGVudHJ5IGZvciB0aGUgdmljdGltIGFkZHJlc3MgaW4gYW55IG90aGVyIHN0YXRlIHRoYW4gSU5D T01QTEVURS4gVGhlIGF0dGFja2VyIHNlbmRzIGFuIE5BIHdpdGggUz0xLCBPPTEsIFRhcmdldCBh ZGRyZXNzID0gdGhlIHZpY3RpbSdzIElQdjYgYWRkcmVzcywgdGhlIFRMTEEgPSB0aGUgYXR0YWNr ZXIgTUFDIGFkZHJlc3MuICBEb25lLiBUaGUgcm91dGVyIHVwZGF0ZXMgdGhlIGNhY2hlIGVudHJ5 IGFuZCBjaGFuZ2VzIGl0IHRvIFJFQUNIQUJMRSBzdGF0ZS4NCg0KVGhlcmUgaXMgbm90aGluZyBu ZXcgaGVyZS4gV2UgaGF2ZSB0aGUgc2FtZSBpc3N1ZSB3aXRoIEFSUCAtIHRoZSBhdHRhY2tlciBj YW4gb3ZlcnJpZGUgQVJQIGVudHJ5IG9uIHRoZSByb3V0ZXIuDQoNCj4gVGhhdCdzIGl0OiB1cHN0 cmVhbSB0cmFmZmljIG9mIHZpY3RpbSBob3N0IGlzIGdvaW5nIHRvIHJvdXRlciwgdHJhZmZpYyBi YWNrIGlzIGdvaW5nIHRocm91Z2ggSW50cnVkZXIuDQo+IEkgaGF2ZSBjb25zdWx0ZWQgd2l0aCBw ZW5ldHJhdGlvbiB0ZXN0cyBwcm9mZXNzaW9uYWwgKHRoZXNlIGFyZSBwZW9wbGUgd2l0aCB0aGUg c2FtZSBxdWFsaWZpY2F0aW9uIGFzIGhhY2tlcnMgYnV0IHRoZXkgcGxheSBvbiBsZWdhbCBzaWRl KTogd2hhdCBoZSB3b3VsZCBiZSBkb2luZyBuZXh0PyBIZSBzYWlkIHRoYXQgaGUgd291bGQgcmV0 dXJuIHRyYWZmaWMgdG8gbGVnaXRpbWF0ZSBob3N0IC0gdmljdGltIHNob3VsZCBub3Qgc2VlIHBl cmZvcm1hbmNlIGRlZ3JhZGF0aW9uLiBIZSB3b3VsZCBjb2xsZWN0IGNvb2tpZXMgYW5kIHNvbWUg b3RoZXIgdmFsdWFibGUgaW5mb3JtYXRpb24uIEhlIHdvdWxkIGZpbmFsbHkgc2VlIEROUyByZXNw b25zZSwgY2hhbmdlIGl0IGFuZCByZWRpcmVjdCBldmVyeXRoaW5nIHRvIGhpbXNlbGYgb24gdGhl IHBlcm1hbmVudCBiYXNpcyAtIGhlIGRvZXMgd2FudCB0byBzZWUgYm90aCBkaXJlY3Rpb25zIG9m IHZpY3RpbSBleGNoYW5nZS4gSGUgaGFzIHF1YWxpZmllZCBNYW4taW4tdGhlLW1pZGRsZSBhcyBm dWxsIGZpYXNjbyAtIGl0IGRvZXMgb3BlbiBtYW55IG9wcG9ydHVuaXRpZXMgZm9yIGhpbS4gSGUg aGFzIG1lbnRpb25lZCB2ZXJ5IGdvb2QgZmVhdHVyZSBvZiB0aGlzIGRyYWZ0IHRoYXQgdGhlcmUg aXMgbm8gYW55IGludGVycnVwdGlvbiBmb3IgdmljdGltJ3MgdHJhZmZpYyBmbG93LCBubyBhbnkg ZXhjZXNzaXZlIHRyYWZmaWMgdG8gdmljdGltLCB0aGF0IGlzIHZlcnkgcmVhciBiZW5lZml0IGZv ciBoYWNrZXIncyB0b29sLg0KDQpGb3IgYWxsIHRoYXQgZG9vbSBhbmQgZ2xvb20gdGhlIGF0dGFj a2VyIHdvdWxkIGFsc28gbmVlZCB0byBzZWUgdGhlIHRyYWZmaWMgKmZyb20qIHRoZSB2aWN0aW0u IEFzc3VtaW5nIHRoZSBuZXR3b3JrIGhhcyBSQSBHdWFyZCBpbiBwbGFjZSBpdCB3b3VsZCBiZSBh IGJpdCBoYXJkZXIuIElmIHRoZSBuZXR3b3JrIGRvZXMgbm90IGhhdmUgUkEgR3VhcmQgb3VyIHBv b3IgdmljdGltIGhhcyBtdWNoIGJpZ2dlciBwcm9ibGVtcyBhbHJlYWR5Lg0KDQo+IFdoYXQgdG8g ZG8gYWJvdXQgaXQ/DQo+IDEuIFBvdGVudGlhbGx5IGl0IGlzIHBvc3NpYmxlIHRvIGRvIFJQRi1s aWtlIGNoZWNrIGZvciBTb3VyY2UgTExBIGFkZHJlc3Nlcy4gVXBzdHJlYW0gdHJhZmZpYyBmcm9t IHZpY3RpbSdzIFNMTEEgd291bGQgbm90IGJlIGluIE5EIGNhY2hlIC0gc3VjaCB0cmFmZmljIGNv dWxkIGJlIGRpc2NhcmRlZC4gSXQgaXMgYmV0dGVyIHRvIGJsb2NrIGNvbW11bmljYXRpb24gdGhh biBwZXJtaXQgaW50cnVkZXIgdG8gZXhwbG9pdCB2dWxuZXJhYmlsaXR5Lg0KDQo+IDIuIEluY3Jl YXNlIFJldHJhbnNUaW1lciBhbmQgYXNrIHJlY2VpdmVyIHNpZGUgKHJvdXRlcikgdG8gY2hlY2sg b24gc2VuZGluZyBzaWRlIGRlbGF5IGJldHdlZW4gTkQgcmVjb3JkIG92ZXJyaWRlIChmb3IgdGhl IHNhbWUgU0xMQSkuIEJ1dCBob3cgbG9uZyBzaG91bGQgYmUgdGhlIHRpbWVyPyBIb3N0IGNvdWxk IHdhaXQgYSBsby1vLW8tbmcgdGltZSBiZWZvcmUgaXQgd291bGQgcmVxdWVzdCAxc3QgaW5mb3Jt YXRpb24gZnJvbSBpbnRlcm5ldC4gSXQgd291bGQgZGVjcmVhc2UgcHJvYmFiaWxpdHksIGJ1dCB3 b3VsZCBub3QgY29tcGxldGVseSBlbGltaW5hdGUgYXR0YWNrIHZlY3Rvci4NCj4NCj4gTXkgcHJv cG9zaXRpb24gZm9yIHRoaXMgZHJhZnQgaXMgZGlzcnVwdGl2ZToNCj4gSSBiZWxpZXZlIHRoYXQg TkQgaXMgdmVyeSBjb21wbGljYXRlZCAoc29tZSBjb3VsZCBzYXkgImZyYWdpbGUiKSAtIGl0IGlz IGJldHRlciBub3QgdG8gdG91Y2ggaXQuDQo+IEFkZGl0aW9uYWxseSBJIGRvIG5vdCBsaWtlIHRv IHdhaXQgdGlsbCBhbGwgaG9zdHMgd291bGQgcmVmcmVzaCB0byBuZXcgZHJhZnQgKHRvIGdldCBu ZXcgZnVuY3Rpb25hbGl0eSkuDQoNCldlbGwsIG9ubHkgaG9zdHMgd2hpY2ggd2FudCB0byBjb25u ZWN0IHRvIHRoZSBuZXR3b3JrIGZhc3RlciBuZWVkIHRvIGltcGxlbWVudCB0aGlzLiBTbyBob3N0 IE9TIGRldmVsb3BlcnMgaGF2ZSBwcmV0dHkgZ29vZCBpbmNlbnRpdmUgaGVyZS4NClBsZWFzZSBr ZWVwIGluIG1pbmQgdGhhdCB0aGUgcHJvcG9zZWQgYmVoYXZpb3IgaXMgbm90IGN1cnJlbnRseSBw cm9oaWJpdGVkLiBXZSBhcmUgbm90IGNoYW5naW5nIGFueSBNVVNUIE5PVCB0byBhbnl0aGluZyBl bHNlLiBBbGwgd2UgYXJlIGRvaW5nIGlzIHRvIG1ha2luZyBzb21lIHJlY29tbWVuZGF0aW9ucyBt b3JlIGV4cGxpY2l0Lg0KDQo+IEkgcHJvcG9zZSB0byBjaGFuZ2Ugb25seSByb3V0ZXIgYmVoYXZp b3I6IGNoZWNrIFNvdXJjZSBMTEEgKE1BQykgZm9yIGV2ZXJ5IHBhY2tldCwgaWYgdGhpcyBTTExB IGlzIGFic2VudCBpbiBORCBjYWNoZSAtIHRoZW4gcmVxdWVzdCBzb2xpY2l0ZWQgTlMtTkEgaW1t ZWRpYXRlbHkuIEl0IHdvdWxkIHByb2JhYmx5IHJlc29sdmUgZmFzdGVyIHRoYW4gdHJhZmZpYyB3 b3VsZCByZXR1cm4gZnJvbSB0aGUgaW50ZXJuZXQuDQoNCkhhdmUgeW91IGNoZWNrZWQgdGhlIHBy b2JsZW0gc3RhdGVtZW50IGRyYWZ0Pw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLXY2b3BzLW5kLWNhY2hlLWluaXQtMDMjc2VjdGlvbi0zLjcNCnNwZWNp ZmljYXRsbHk/DQpXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIGRvZXMgbWFrZSBzZW5zZSwgaG93ZXZl ciBpdCB3b3VsZCBub3QgaGVscCBpbiBjYXNlIG9mIG11bHRpcGxlIHJvdXRlcnMuIEFsc28gSSBy ZWNhbGwgc29tZSBwZW9wbGUgaGF2aW5nIHN0cm9uZyBvcGluaW9ucyBvbiBwZXJmb3JtYW5jZSBp bXBsaWNhdGlvbnMuDQoNCj4gRWZmZWN0aXZlbHkgSSBkbyBwcm9wb3NlZCB0aGUgc2FtZSBTTExB IFJQRiB0aGF0IGlzIG5lZWRlZCB0byBmaXggY3VycmVudCBzb2x1dGlvbiwgYnV0Og0KPiAtIHdp dGhvdXQgYW55IG1vZGlmaWNhdGlvbiB0byBob3N0IE9TZXMNCj4gLSB3aXRob3V0IGFueSBtb2Rp ZmljYXRpb24gb2Ygc3RhbmRhcmQgKGl0IGlzIGxvY2FsIHJlY29tbWVuZGF0aW9uIGZvcg0KPiBy b3V0ZXIsIE5TLU5BIGlzIGV4YWN0bHkgdGhlIHNhbWUgZnJvbSBSRkMgNDY4MSwgTkEgaXMgdW5p Y2FzdCAtIGl0IGlzDQo+IGltcG9ydGFudCBmb3Igc2VjdXJpdHkpDQo+IC0gd2l0aG91dCBhbnkg cmlzayB0byBicmVhayBORCBmcmFnaWxlIGFsZ29yaXRobQ0KPiAtIGl0IGNvdWxkIGJlIG9wdGlv bmFsLCBvciBldmVuIGNvbmZpZ3VyYWJsZSBvbiB0aGUgcm91dGVyIGFzICJ2YWx1ZQ0KPiBhZGQg ZmVhdHVyZSIgaW4gY29tcGV0aXRpdmUgdGVuZGVyIEJlY2F1c2UgaXQgaXMganVzdCBiZXN0IHBy YWN0aWNlIHJlY29tbWVuZGF0aW9uIC0gbWF5IGJlIGl0IG1ha2Ugc2Vuc2UgdG8gbW92ZSBpdCB0 byAidjZvcHMiPw0KDQpTZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1pZXRmLXY2b3BzLW5kLWNhY2hlLWluaXQtMDMNCg0KPiBQUzogTG9va2luZyB0byB0aGUg YWJvdmUgLSB1bnNvbGljaXRlZCBOQSBzaG91bGQgYmUgcmVhbGx5IGRlbGF5ZWQgYnkgYWRkaXRp b25hbCBiaWcgdGltZXIgKG5vdCBieSBSZXRyYW5zVGltZXIgdGhhdCBpcyB1c2VkIGZvciBzb2xp Y2l0ZWQgTlMvTkEpIGFuZCBjaGVja2VkIG9uIHJlY2VpdmVyIHNpZGUgLSB0aGlzIG1vZGlmaWNh dGlvbiBvZiBzdGFuZGFyZCBpcyByZWFsbHkgbmVlZGVkIHRvIGNsb3NlIFVuc29saWNpdGVkIE5B IHZ1bG5lcmFiaWxpdHkuDQo+IFNvbWVib2R5IHNhaWQgb24gdGhlIGNhbGwgdGhhdCBpdCBpcyBh bHJlYWR5IGEgZmVhdHVyZSBvZiBzb21lIE9TIChBbmRyb2lkPykgLSBpdCBpcyBiYWQ6IGl0IG1l YW5zIHRoYXQgdGhpcyBPUyBpcyBhbHJlYWR5IHZ1bG5lcmFibGUuDQoNCkkgd2FzIHNheWluZyB0 aGF0IHNvbWUgcm91dGluZyBwbGF0Zm9ybXMgaGF2ZSB0aGlzIGFscmVhZHkgaW1wbGVtZW50ZWQu IFNlYXJjaCBmb3IgJ2dsZWFuJyBoZXJlOg0KaHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMv dGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2X2Jhc2ljL2NvbmZpZ3VyYXRpb24vMTUtZS9pcDZiLTE1 LWUtYm9vay9pcDYtbmQtY2FjaGUtbWdtdC5odG1sDQoNCkFGQUlLIHRoZXJlIGFyZSBpbXBsZW1l bnRhdGlvbnMgd2hpY2ggYXJlIGFsc28gcHJlcG9wdWxhdGluZyBOQyBmcm9tIERBRCBwYWNrZXRz IGJ1dCBJIGNhbiBub3QgZmluZCB5b3UgYSByZWZlcmVuY2UgcmlnaHQgbm93Lg0KDQo+IEZyb206 IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwdjYtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKZW4gTGlua292YQ0KPiBTZW50OiAyNyDQuNGO0LvRjyAy MDIwINCzLiA3OjQ5DQo+IFRvOiA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPj4NCj4gU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0w MS50eHQNCj4NCj4gSGVsbG8sDQo+DQo+IFRoZSAtMDEgdmVyc2lvbiBhZGRyZXNzZXMgY29tbWVu dHMgcmVjZWl2ZWQgKHRoYW5rcyBldmVyeW9uZSB3aG8gcHJvdmlkZWQgZmVlZGJhY2spLiBBbHNv LCBTZWN0aW9uIDMgKEF2b2lkaW5nIERpc3J1cHRpb24pIGhhcyBiZWVuIGV4cGFuZGVkIGFuZCBk aXNjdXNzZWQgYSBjb3JuZXIgY2FzZSB3aGVuIHR3byBkZXZpY2VzIHN0YXJ0IHVzaW5nIHRoZSBz YW1lIGFkZHJlc3MgYWxtb3N0IGF0IHRoZSBzYW1lIHRpbWUgKHRoZSBzZWNvbmQgZGV2aWNlIGNv bmZpZ3VyZXMgYW4gb3B0aW1pc3RpYyBhZGRyZXNzIGFmdGVyIHRoZSByaWdodGZ1bCBvd25lciBz ZW50IHNvbWUgcGFja2V0cyBidXQgYmVmb3JlIHRoZSByZXR1cm4gdHJhZmZpYyBhcnJpdmVzKS4N Cj4gRmVlZGJhY2sgb24gdGhlIHVwZGF0ZWQgc2VjdGlvbiAzLjMNCj4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDEjc2VjdGlvbi0zLjMpIGlzIHZl cnkgbXVjaCBhcHByZWNpYXRlZC4NCj4NCj4gT24gU3VuLCBKdWwgMjYsIDIwMjAgYXQgMTA6MTQg QU0gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gPiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE1haW50ZW5hbmNlIFdHIG9mIHRo ZSBJRVRGLg0KPiA+DQo+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBHcmF0dWl0b3VzIE5l aWdoYm9yIERpc2NvdmVyeTogQ3JlYXRpbmcgTmVpZ2hib3IgQ2FjaGUgRW50cmllcyBvbiBGaXJz dC1Ib3AgUm91dGVycw0KPiA+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogSmVuIExpbmtvdmEN Cj4gPiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMS50 eHQNCj4gPiAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDEyDQo+ID4gICAgICAgICBEYXRlICAg ICAgICAgICAgOiAyMDIwLTA3LTI1DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBOZWlnaGJv ciBEaXNjb3ZlcnkgKFJGQzQ4NjEpIGlzIHVzZWQgYnkgSVB2NiBub2RlcyB0byBkZXRlcm1pbmUg dGhlDQo+ID4gICAgbGluay1sYXllciBhZGRyZXNzZXMgb2YgbmVpZ2hib3Jpbmcgbm9kZXMgYXMg d2VsbCBhcyB0byBkaXNjb3ZlciBhbmQNCj4gPiAgICBtYWludGFpbiByZWFjaGFiaWxpdHkgaW5m b3JtYXRpb24uICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNDg2MSB0bw0KPiA+ICAgIGFsbG93 IHJvdXRlcnMgdG8gcHJvYWN0aXZlbHkgY3JlYXRlIGEgTmVpZ2hib3IgQ2FjaGUgZW50cnkgd2hl biBhIG5ldw0KPiA+ICAgIElQdjYgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byBhIG5vZGUuICBJdCBh bHNvIHVwZGF0ZXMgUkZDNDg2MSBhbmQNCj4gPiAgICByZWNvbW1lbmRzIG5vZGVzIHRvIHNlbmQg dW5zb2xpY2l0ZWQgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudHMgdXBvbg0KPiA+ICAgIGFzc2lnbmlu ZyBhIG5ldyBJUHY2IGFkZHJlc3MuICBUaGUgcHJvcG9zZWQgY2hhbmdlIHdpbGwgbWluaW1pemUg dGhlDQo+ID4gICAgZGVsYXkgYW5kIHBhY2tldCBsb3NzIHdoZW4gYSBub2RlIGluaXRpYXRlIGNv bm5lY3Rpb25zIHRvIG9mZi1saW5rDQo+ID4gICAgZGVzdGluYXRpb24gZnJvbSBhIG5ldyBJUHY2 IGFkZHJlc3MuDQo+ID4NCj4gPg0KPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtNm1hbi1ncmFuZC8NCj4gPg0KPiA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tZ3JhbmQtMDENCj4gPg0KPiA+IEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxDQo+ID4NCj4gPg0K PiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLi5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0 Zi5vcmc+Lg0KPiA+DQo+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+IEFkbWluaXN0 cmF0aXZlDQo+ID4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2Ng0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+DQo+IC0tDQo+IFNZLCBKZW4gTGlua292 YSBha2EgRnVycnkNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQo+IEFk bWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0tDQpTWSwgSmVuIExpbmtvdmEgYWthIEZ1 cnJ5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZv cHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2 Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0K --_000_E176B08424E1434DB15CF364F64807BBciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBKZW4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNpbmNlIHRoZSByb3V0ZXIgaXMgcHJl cG9wdWxhdGVkLCBpdCBrbm93cyB0aGUgTkQgcmVzb2x1dGlvbiBiZWZvcmUgaG9zdHMgZG8uPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TbyBzYXkgYSB0aGlyZCBwYXJ0eSBob3N0IGhh cyB0cmFmZmljIHRvIHNlbmQgYW5kIHRoZSBwcmVmaXggaXMgb25saW5lLiBJdCB3aWxsIHN0b3Jl IG9uZSBwYWNrZXQgYW5kIG11bHRpY2FzdCBhIGxvb2t1cCB0byB0aGUgc25tYSBvZiB0aGlzIG5v ZGUuIEl0IHdpbGwgZHJvcCB0aGUgb3RoZXIgcGFja2V0cy48YnI+DQo8YnI+DQpBbiBhbHRlcm5h dGUgYmVoYXZpb3IgaW4gYSBuZXR3b3JrIHdoZXJlIEdSQU5EIGlzIGVuYWJsZWQgY291bGQgYmUg dG8gc3RhcnQgYnkgZm9yd2FyZGluZyB0aGUgcGFja2V0cyB0byB0aGUgcm91dGVyIGluIGNhc2Ug b2YgYU4gTkQgY2FjaGUgbWlzcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklmIHRo ZSByb3V0ZXIgYWxyZWFkeSBoYXMgYW4gTkNFIHRoZXJlIHdpbGwgbm90IGJlIGEgbG9va3VwIGF0 IGFsbC4gVGhlIHJvdXRlciB3aWxsIHJlZGlyZWN0IGltbWVkaWF0ZWx5IGFuZCByZWxheSB0aGUg cGFja2V0cyBpbiB0aGUgbWVhbnRpbWUuIE5vIGRlbGF5LCBubyBsb3NzLiBBbmQgbm8gbXVsdGlj YXN0Li4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGUgcm91dGVyIGRvZXMg bm90IGhhdmUgYSBjYWNoZSwgaXQgd2lsbCBkbyB0aGUgTlMgbG9va3VwLiBBbmQgZXZlbnR1YWxs eSByZWRpcmVjdCBhbnl3YXkgaWYgdGhlIHRyYWZmaWMgY29udGludWVzLiBTYW1lIG92ZXJhbGwg Y29zdCwgd2l0aCB0aGUgYmVuZWZpdCB0aGF0IHRoZSByb3V0ZXIgbm93IGhhcyB0aGUgY2FjaGUg cmVhZHkgaW4gY2FzZSB5ZXQgYW5vdGhlciBob3N0IG5lZWRzIGl0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+T3ZlcmFsbCBiZW5lZml0cyBkYXkgMSwgaW5jcmVtZW50YWxseSB1c2Vm dWwgYXMgR1JBTkQgZ2V0cyBkZXBsb3llZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkNoZXJyeSBvbiB0aGUgY2FrZTogdGhlIHJvdXRlciBtYXkgYmUgbW9yZSBTQVZJLXNhdnZ5IHRo YW4gdGhpcyBob3N0IHNvIGl0IG1heSByZWRpcmVjdCB0byB0aGUgcmVhbCBmaXJzdC1jb21lIG5v ZGUuPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KV2hh dCBkbyB5b3UgdGhpbms/PGJyPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGFzY2FsPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkxl IDMwIGp1aWwuIDIwMjAgw6AgMTI6MzcsIExvcmVuem8gQ29saXR0aSAmbHQ7bG9yZW56bz00MGdv b2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj4NCjxicj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0i bHRyIj7vu78NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5JIHRoaW5rIHRoZSBmYWN0IGlzIHRoYXQg TkQgaXMgaW5oZXJlbnRseSBpbnNlY3VyZSBmcm9tIG9uLWxpbmsgYXR0YWNrcy4gSWYgc2VjdXJp dHkgaXMgZGVzaXJlZCwgdGhlbiBpdCBuZWVkcyB0byBiZSBwcm92aWRlZCBpbiBvdGhlciB3YXlz LCBzdWNoIGFzIHZpYSBTRU5EIG9yIFNBVkkuIEJ1dCBpdCdzIGFsc28gbm90IHBhcnRpY3VsYXJs eSBkZXNpcmFibGUgdG8gcHJvdmlkZSBzZWN1cml0eSBhdCB0aGlzIGxheWVyLiBUcmFmZmljIHNu b29waW5nDQogaXMgbm90IHZlcnkgdXNlZnVsIChub3QgemVybyB1dGlsaXR5LCBidXQgZGlmZmlj dWx0IHRvIHVzZSB3ZWxsKSB3aGVuIGFsbCB0cmFmZmljIGlzIGVuY3J5cHRlZCwgYW5kIG9uLWxp bmsgRG9TIGF0dGFja3MganVzdCBhcmVuJ3QgdmVyeSB1c2VmdWwgdGhlc2UgZGF5cyBnaXZlbiB0 aGF0IG1hbnkgZGV2aWNlcyBoYXZlIGEgdmFyaWV0eSBvZiBjb25uZWN0aXZpdHkgb3B0aW9ucy48 L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBUaHUsIEp1bCAzMCwgMjAyMCBhdCA1OjA1IFBNIFZhc2lsZW5r byBFZHVhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20i PnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4 IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVm dDoxZXgiPg0KVGhlbiBpdCBpcyBub3QgbG9naWNhbCBmb3IgbWU6PGJyPg0KTWFueSBwZW9wbGUg dW5kZXJzdGFuZCB0aGF0ICZxdW90O1Vuc29saWNpdGVkIE5BJnF1b3Q7IGlzIGEgYmlnIHNlY3Vy aXR5IGhvbGUgcGVyIHNlLDxicj4NCkJ1dCBpbnN0ZWFkIG9mIGZpeGluZyBpdCAobWF5IGJlIGV2 ZW4gZGVwcmVjYXRlIC0gc2hvdWxkIGJlIGludmVzdGlnYXRlZCk8YnI+DQpBZGRpdGlvbmFsIGZ1 bmN0aW9uYWxpdHkgaXMgYnVpbGRpbmcgb24gdG9wIG9mIGl0Ljxicj4NCkl0IHdvdWxkIGFkZGl0 aW9uYWxseSBjaGFsbGVuZ2UgdGhpcyBzZWN1cml0eSBwcm9ibGVtIHJlc29sdXRpb24gaW4gdGhl IGZ1dHVyZSE8YnI+DQo8YnI+DQpBZ2FpbjogJnF1b3Q7VW5zb2xpY2l0ZWQgTkEmcXVvdDsgd2l0 aCBPdmVycmlkZSBiaXQgc2V0IC0gaXMgYSBkaXNhc3RlciBub3cuLjxicj4NCklNSE86IGl0IGlz IGJldHRlciB0byBwcm9oaWJpdCAmcXVvdDtVbnNvbGljaXRlZCBOQSZxdW90Oy4gTGV0J3Mgd2Fp dCB0aW1lcnMgZm9yIHRoZSBjYXNlIG9mIE1BQyBhZGRyZXNzIGNoYW5nZSBvbiBsZWdpdGltYXRl IGhvc3QuPGJyPg0KTWF5IGJlIHdlIGNvdWxkIHRoaW5rIGFib3V0IG90aGVyIHNvbHV0aW9ucy48 YnI+DQpCdXQgaWYgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IHdvdWxkIGJlIGJ1aWx0IG9uIHRv cCBvZiAmcXVvdDtVbnNvbGljaXRlZCBOQSZxdW90OyAtIGxlc3Mgb3B0aW9ucyB3b3VsZCBiZSBh dmFpbGFibGUgKCZxdW90O2RlcHJlY2F0ZSZxdW90OyB3b3VsZCBiZSBub3QgYSBjaG9pY2UgYW55 bW9yZSkuPGJyPg0KPGJyPg0KSWYgc29tZXRoaW5nIGlzIGlsbCAtIGl0IHNob3VsZCBiZSBjdXJl ZCBmaXJzdCAtIGJvZHlidWlsZGluZyBtYWtlIHNlbnNlIG9ubHkgYWZ0ZXIgdGhpcy48YnI+DQo8 YnI+DQpKZW4sIEkgaGF2ZSBub3QgdW5kZXJzdG9vZCBiZWxvdyB3aHkgeW91IGRpZCBtZW50aW9u IFJBIEd1YXJkLiBJbnRydWRlciBkb2VzIG5vdCBuZWVkIGl0LiBIZSBqdXN0IGNsYWltIChieSBV bnNvbGljaXRlZCBOQSkgdGhhdCBoaXMgTUFDIGlzIGNvbm5lY3RlZCB0byBHVUEgb2YgdmljdGlt Ljxicj4NCkludHJ1ZGVyIGNvdWxkIGNsYWltIGl0IGV2ZXJ5IDUgc2Vjb25kcyB0byBrZWVwIGNh Y2hlIGluIFNUQUxFIHN0YXRlIChmb3IgdGhlIGNhc2Ugb2YgdmVyeSBjYXJlZnVsIHZlbmRvciBp bXBsZW1lbnRhdGlvbiBvZiBORCkuPGJyPg0KQXMgeW91IG1lbnRpb25lZCAtIG5vIGhlbHAgZnJv bSBNTEQgc25vb3Bpbmcgb24gc3dpdGNoZXMgLSBpdCB3b3VsZCBiZSBlbm91Z2ggdG8ganVzdCBs aXN0ZW4gdG8gREFELiBTd2l0Y2ggY291bGQgbm90IGhlbHAgaW4gcHJpbmNpcGxlLjxicj4NClRo ZSBmaXJzdCBtb2RpZmllZCBETlMgcmVzcG9uc2Ugd291bGQgY29udmVydCB0cmFmZmljIGZsb3cg dG8gYmktZGlyZWN0aW9uYWwgZm9yIEludHJ1ZGVyLjxicj4NCjxicj4NCkVkLzxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSmVuIExpbmtvdmEgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZnVycnkxM0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mdXJyeTEzQGdt YWlsLmNvbTwvYT5dDQo8YnI+DQpTZW50OiAzMCDQuNGO0LvRjyAyMDIwINCzLiA1OjA3PGJyPg0K VG86IFZhc2lsZW5rbyBFZHVhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJk QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj52YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208 L2E+Jmd0Ozxicj4NCkNjOiA2bWFuICZsdDs8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp2Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQpT dWJqZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxIC0gYWRkaXRp b25hbCBzZWN1cml0eSBjb25jZXJuczxicj4NCjxicj4NCk9uIFRodSwgSnVsIDMwLCAyMDIwIGF0 IDU6NTYgQU0gVmFzaWxlbmtvIEVkdWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVhcmRAaHVhd2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgWW91IGRpZCBhc2sgYSBmZWVkYmFjayB5ZXN0 ZXJkYXkgYWJvdXQgc2V2ZXJpdHkgb2YgN3NlYyBzZWN1cml0eSBob2xlIHRoYXQgaGFzIHZlcnkg bG93IHByb2JhYmlsaXR5Ljxicj4NCiZndDsgSSBoYXZlIGludGVudGlvbiBoZXJlIHRvIHNob3cg dGhhdCBwcm9iYWJpbGl0eSBpcyAxMDAlLCA3c2VjIGNvdWxkIGJlIHByb2xvbmdlZCB0byBmb3Jl dmVyLCBhbmQgdGhlIGZpbmFsIHJlc3VsdCBpcyB0aGUgZnVsbCBpbnRlcmNlcHRpb24gb2YgaW5u b2NlbnQgaG9zdCB0cmFmZmljIGJ5IGludHJ1ZGVyIChzdWNjZXNzZnVsICZxdW90O21hbi1pbi10 aGUtbWlkZGxlJnF1b3Q7KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQcmUtcmVxdWVzdCBmb3Igc3Vj Y2Vzczo8YnI+DQomZ3Q7IC0gbm8gbXVsdGljYXN0IHNub29waW5nIChNTEQpIGFuZCBmaWx0ZXJp bmcgb24gYSBzd2l0Y2gsIHRoYXQgaXMgPGJyPg0KJmd0OyBwZXJmZWN0bHkgcG9zc2libGU8YnI+ DQomZ3Q7IC0gSW50cnVkZXIgc2hvdWxkIGJlIGFscmVhZHkgb24gdGhlIHNhbWUgc3VibmV0IChn YWluZWQgY29udHJvbCBvdmVyIDxicj4NCiZndDsgb3RoZXIgaG9zdCBieSBleHBsb2l0aW5nIG9m IGRpZmZlcmVudCB2dWxuZXJhYmlsaXR5KTxicj4NCiZndDsgLSBpbnRydWRlciBzaG91bGQgc3Vw cHJlc3MgREFEIG9uIEludHJ1ZGVyJ3MgY29udHJvbGxlZCBob3N0IChpcyA8YnI+DQomZ3Q7IFdp bmRvd3MgZmlyZXdhbGwgY2FwYWJsZSB0byBmaWx0ZXIgb3V0IERBRD8pPGJyPg0KJmd0OyAtIFdl IGFzc3VtZSB0aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBmdXR1cmUgd2hlbiB0aGlzIGRy YWZ0IGlzIDxicj4NCiZndDsgdXNlZCBieSBtYWpvcml0eSBvZiBub2RlcyAodmljdGltIHNob3Vs ZCB1c2UgaXQpPGJyPg0KJmd0Ozxicj4NCiZndDsgUHJvY2VkdXJlOjxicj4NCiZndDsgSW50cnVk ZXIncyBjb250cm9sbGVkIGhvc3QgZG9lcyBsaXN0ZW4gdG8gYWxsLXJvdXRlcnMgbXVsdGljYXN0 IGFkZHJlc3MgKGZmMDI6OjIpLjxicj4NCiZndDsgQXMgc29vbiBhcyBpdCB3b3VsZCBlYXZlc2Ry b3AgdW5zb2xpY2l0ZWQgTkEgZnJvbSB2aWN0aW0gbm9kZSAocHJvYmFibHkgYWZ0ZXIgYm9vdCkg LSBJbnRydWRlciB3b3VsZCBpbW1lZGlhdGVseSAoYSBmZXcgbWlsbGlzZWNvbmRzKSBkdXBsaWNh dGUgTkEgaW4gcm91dGVyJ3MgZGlyZWN0aW9uLCBidXQgd2l0aCAyIGNoYW5nZXM6ICgxKSBoaXMg TExBIChNQUMpOyAoMikgT3ZlcnJpZGUgYml0IHNldC48YnI+DQomZ3Q7IEludHJ1ZGVyIGhhcyB0 aW1lIG9ubHkgdXAgdG8gdGhlIHBvaW50IHRoYXQgcmVzcG9uc2UgdG8gdmljdGltJ3MgdHJhZmZp YyB3b3VsZCBiZSByZXR1cm5lZCBmcm9tIHRoZSBJbnRlcm5ldCAoZnJvbSB0ZW5zIG9mIG1pbGxp c2Vjb25kcyB0byBtYW55IHNlY29uZHMgaWYgdmljdGltIHdvdWxkIG5vdCBzdGFydCBzZW5kaW5n IGltbWVkaWF0ZWx5KSwgLSBidXQgaXQgaXMgZW5vdWdoIHRpbWU6IGxvY2FsIGNvbW11bmljYXRp b24gc2hvdWxkIGJlDQogZmFzdGVyLjxicj4NCiZndDsgVGhlb3JldGljYWxseSwgUmV0cmFuc1Rp bWVyIHNob3VsZCBiZSBpbXBvc2VkIG9uIHVuc29saWNpdGVkIE5BIChzZWN0aW9uIDcuMi42KSwg YnV0IGxvdyBjaGFuY2VzIHRoYXQgdGhpcyB0aW1lciBpcyBjaGVja2VkIG9uIHJlY2VpdmluZyBz aWRlIChyb3V0ZXIpLCBiZWNhdXNlIFJldHJhbnNUaW1lciBpcyBzcGVjaWZpZWQgZm9yIHRyYW5z bWlzc2lvbiBzaWRlLjxicj4NCiZndDsgQWNjb3JkaW5nIFJGQyA0NjgxIHNlY3Rpb24gNy4yLjUg Y2xhdXNlIElJOiBPIGJpdCBzZXQgc2hvdWxkIG5vdCBqdXN0IHJld3JpdGUgTkQgY2FjaGUsIGJ1 dCBhZGRpdGlvbmFsbHkgbWFyayBORCByZWNvcmQgYXMgUkVBQ0hBQkxFLiBBY2NvcmRpbmcgdG8g c2VjdGlvbiA3LjIuNjogJnF1b3Q7IFRoZSBPdmVycmlkZSBmbGFnIChmb3IgdW5zb2xpY2l0ZWQg TkEpIE1BWSBiZSBzZXQgdG8gZWl0aGVyIHplcm8gb3Igb25lJnF1b3Q7LiBEZXNwaXRlIGl0IGNv bnRyYWRpY3RzDQogdG8gdGhlIGxvZ2ljIG9mIHRoZSB3aG9sZSBSRkMgNDY4MSAoTyBiaXQgc2hv dWxkIG5vdCBiZSBzZXQgaW4gdW5zb2xpY2l0ZWQgTkEgLSBpdCBpcyBtZW50aW9uZWQgaW4gYSBm ZXcgcGxhY2VzIG9mIFJGQyA0NjgxKS4gQnV0IGJlY2F1c2Ugc2VjdGlvbiA3LjIuNSBhbmQgc2Vj dGlvbiA3LjIuNiBjbGVhcmx5IHBlcm1pdCB0byB1c2UgT3ZlcnJpZGUgZmxhZyAtIGhpZ2hlciBw cm9iYWJpbGl0eSB0aGF0IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24NCiB3b3VsZCBub3QganVz dCByZXdyaXRlIExMQSBvbiByb3V0ZXIsIGJ1dCBhZGRpdGlvbmFsbHkgcHV0IGl0IGludG8gUkVB Q0hBQkxFLjxicj4NCiZndDsgSW50cnVkZXIgY291bGQgYmUgc3VyZSB0aGF0IGF0IGxlYXN0IFNU QUxFIHN0YXRlIHdvdWxkIGJlIGNyZWF0ZWQgYWNjb3JkaW5nIHRvIHNlY3Rpb24gNy4yLjUgY2xh dXNlIEksIC0gdGhpcyBORCByZWNvcmQgd291bGQgYmUgYWdhaW5zdCBoaXMgTExBIGFueXdheS48 YnI+DQomZ3Q7IEFmdGVyIHJlY2VpdmluZyByZXR1cm4gdHJhZmZpYyAoaWYgaXQgd2FzIGNyZWF0 ZWQgYXMgU1RBTEUsIG5vdCBSRUFDSEFCTEUpIC0gcm91dGVyIHdvdWxkIGFzayBpbnRydWRlciBh Ym91dCByZWFjaGFiaWxpdHkgKHNvbGljaXRlZCBOUy1OQSkgLSBpbnRydWRlciB3b3VsZCBjb25m aXJtIGhpcyBMTEEgLSBpdCB3b3VsZCBmaW5hbGx5IHB1dCBORCBjYWNoZSByZWNvcmQgaW50byBS RUFDSEFCTEUuPGJyPg0KPGJyPg0KMSkgdGhlIDcgc2Vjb25kcyBjb3JuZXIgY2FzZSB3YXMgZm9y ICdwcmV2ZW50aW5nIGFkZHJlc3MgY29sbGlzaW9uIGZvciBPcHRpbWlzdGljIERBRCcsIG5vdCBm b3IgYW55IGludGVudGlvbmFsIGF0dGFja3MgY2FzZS4gQmVjYXVzZTo8YnI+DQoyKSBXaGF0IHlv dSBhcmUgZGVzY3JpYmluZyBjb3VsZCBiZSBkb25lIHRvZGF5LCBub3csIGFueXRpbWUgdy9vIHRo ZSBjaGFuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuIElmIHRoZXJlIGlzIG5vIE1MRCBzbm9v cGluZyB0aGVuIHRoZSBpbnRydWRlciB3b3VsZCBzZWUgdGhlIERBRCBwYWNrZXQgZnJvbSB0aGUg dmljdGltLCBzbyBpdCB3b3VsZCBrbm93IHRoZSB2aWN0aW0gYWRkcmVzcyBhbnl3YXkmbmJzcDsg LSBubyByZWFzb24gZXZlbiB0byBqb2luDQogZmYwMjo6Mi4gTm93IGFsbCB0aGUgYXR0YWNrZXIg bmVlZHMgdG8gZG8gaXMgdG8ga2VlcCBzZW5kaW5nIE5BIHdpdGggUz0xLCBPPTEgLSBob3Bpbmcg dGhhdCB3aGVuIHRoZSBmaXJzdCBwYWNrZXQgb2YgdGhlIHJldHVybiBmbG93cyBhcnJpdmUgYW5k IHRoZSByb3V0ZXIgY3JlYXRlcyBhbiBJTkNPTVBMRVRFIGVudHJ5IGFuZCBzZW5kcyBhbiBOUywg dGhlIGF0dGFja2VyJ3MgcGFja2V0IHdvdWxkIGNvbWUgYmVmb3JlIHRoZSB2aWN0aW0ncyBOQS4N CiBEb25lLCB0aGUmbmJzcDsgZW50cnkgaXMgY2hhbmdlZCB0byBSRUFDSEFCTEUsIGFsbCB0cmFm ZmljIGdvZXMgdG8gdGhlIGF0dGFja2VyLjxicj4NCkFjdHVhbGx5IGV2ZW4gc2ltcGxlci4gVGhl IGF0dGFja2VyIGRvZXMgbm90IG5lZWQgdG8gZGVhbCB3aXRoIHRpbWluZy48YnI+DQpMZXQncyBz YXkgdGhlIHJvdXRlciBoYXMgYW4gTkMgZW50cnkgZm9yIHRoZSB2aWN0aW0gYWRkcmVzcyBpbiBh bnkgb3RoZXIgc3RhdGUgdGhhbiBJTkNPTVBMRVRFLiBUaGUgYXR0YWNrZXIgc2VuZHMgYW4gTkEg d2l0aCBTPTEsIE89MSwgVGFyZ2V0IGFkZHJlc3MgPSB0aGUgdmljdGltJ3MgSVB2NiBhZGRyZXNz LCB0aGUgVExMQSA9IHRoZSBhdHRhY2tlciBNQUMgYWRkcmVzcy4mbmJzcDsgRG9uZS4gVGhlIHJv dXRlciB1cGRhdGVzIHRoZSBjYWNoZSBlbnRyeQ0KIGFuZCBjaGFuZ2VzIGl0IHRvIFJFQUNIQUJM RSBzdGF0ZS48YnI+DQo8YnI+DQpUaGVyZSBpcyBub3RoaW5nIG5ldyBoZXJlLiBXZSBoYXZlIHRo ZSBzYW1lIGlzc3VlIHdpdGggQVJQIC0gdGhlIGF0dGFja2VyIGNhbiBvdmVycmlkZSBBUlAgZW50 cnkgb24gdGhlIHJvdXRlci48YnI+DQo8YnI+DQomZ3Q7IFRoYXQncyBpdDogdXBzdHJlYW0gdHJh ZmZpYyBvZiB2aWN0aW0gaG9zdCBpcyBnb2luZyB0byByb3V0ZXIsIHRyYWZmaWMgYmFjayBpcyBn b2luZyB0aHJvdWdoIEludHJ1ZGVyLjxicj4NCiZndDsgSSBoYXZlIGNvbnN1bHRlZCB3aXRoIHBl bmV0cmF0aW9uIHRlc3RzIHByb2Zlc3Npb25hbCAodGhlc2UgYXJlIHBlb3BsZSB3aXRoIHRoZSBz YW1lIHF1YWxpZmljYXRpb24gYXMgaGFja2VycyBidXQgdGhleSBwbGF5IG9uIGxlZ2FsIHNpZGUp OiB3aGF0IGhlIHdvdWxkIGJlIGRvaW5nIG5leHQ/IEhlIHNhaWQgdGhhdCBoZSB3b3VsZCByZXR1 cm4gdHJhZmZpYyB0byBsZWdpdGltYXRlIGhvc3QgLSB2aWN0aW0gc2hvdWxkIG5vdCBzZWUgcGVy Zm9ybWFuY2UNCiBkZWdyYWRhdGlvbi4gSGUgd291bGQgY29sbGVjdCBjb29raWVzIGFuZCBzb21l IG90aGVyIHZhbHVhYmxlIGluZm9ybWF0aW9uLiBIZSB3b3VsZCBmaW5hbGx5IHNlZSBETlMgcmVz cG9uc2UsIGNoYW5nZSBpdCBhbmQgcmVkaXJlY3QgZXZlcnl0aGluZyB0byBoaW1zZWxmIG9uIHRo ZSBwZXJtYW5lbnQgYmFzaXMgLSBoZSBkb2VzIHdhbnQgdG8gc2VlIGJvdGggZGlyZWN0aW9ucyBv ZiB2aWN0aW0gZXhjaGFuZ2UuIEhlIGhhcyBxdWFsaWZpZWQgTWFuLWluLXRoZS1taWRkbGUNCiBh cyBmdWxsIGZpYXNjbyAtIGl0IGRvZXMgb3BlbiBtYW55IG9wcG9ydHVuaXRpZXMgZm9yIGhpbS4g SGUgaGFzIG1lbnRpb25lZCB2ZXJ5IGdvb2QgZmVhdHVyZSBvZiB0aGlzIGRyYWZ0IHRoYXQgdGhl cmUgaXMgbm8gYW55IGludGVycnVwdGlvbiBmb3IgdmljdGltJ3MgdHJhZmZpYyBmbG93LCBubyBh bnkgZXhjZXNzaXZlIHRyYWZmaWMgdG8gdmljdGltLCB0aGF0IGlzIHZlcnkgcmVhciBiZW5lZml0 IGZvciBoYWNrZXIncyB0b29sLjxicj4NCjxicj4NCkZvciBhbGwgdGhhdCBkb29tIGFuZCBnbG9v bSB0aGUgYXR0YWNrZXIgd291bGQgYWxzbyBuZWVkIHRvIHNlZSB0aGUgdHJhZmZpYyAqZnJvbSog dGhlIHZpY3RpbS4gQXNzdW1pbmcgdGhlIG5ldHdvcmsgaGFzIFJBIEd1YXJkIGluIHBsYWNlIGl0 IHdvdWxkIGJlIGEgYml0IGhhcmRlci4gSWYgdGhlIG5ldHdvcmsgZG9lcyBub3QgaGF2ZSBSQSBH dWFyZCBvdXIgcG9vciB2aWN0aW0gaGFzIG11Y2ggYmlnZ2VyIHByb2JsZW1zIGFscmVhZHkuPGJy Pg0KPGJyPg0KJmd0OyBXaGF0IHRvIGRvIGFib3V0IGl0Pzxicj4NCiZndDsgMS4gUG90ZW50aWFs bHkgaXQgaXMgcG9zc2libGUgdG8gZG8gUlBGLWxpa2UgY2hlY2sgZm9yIFNvdXJjZSBMTEEgYWRk cmVzc2VzLiBVcHN0cmVhbSB0cmFmZmljIGZyb20gdmljdGltJ3MgU0xMQSB3b3VsZCBub3QgYmUg aW4gTkQgY2FjaGUgLSBzdWNoIHRyYWZmaWMgY291bGQgYmUgZGlzY2FyZGVkLiBJdCBpcyBiZXR0 ZXIgdG8gYmxvY2sgY29tbXVuaWNhdGlvbiB0aGFuIHBlcm1pdCBpbnRydWRlciB0byBleHBsb2l0 IHZ1bG5lcmFiaWxpdHkuPGJyPg0KPGJyPg0KJmd0OyAyLiBJbmNyZWFzZSBSZXRyYW5zVGltZXIg YW5kIGFzayByZWNlaXZlciBzaWRlIChyb3V0ZXIpIHRvIGNoZWNrIG9uIHNlbmRpbmcgc2lkZSBk ZWxheSBiZXR3ZWVuIE5EIHJlY29yZCBvdmVycmlkZSAoZm9yIHRoZSBzYW1lIFNMTEEpLiBCdXQg aG93IGxvbmcgc2hvdWxkIGJlIHRoZSB0aW1lcj8gSG9zdCBjb3VsZCB3YWl0IGEgbG8tby1vLW5n IHRpbWUgYmVmb3JlIGl0IHdvdWxkIHJlcXVlc3QgMXN0IGluZm9ybWF0aW9uIGZyb20gaW50ZXJu ZXQuDQogSXQgd291bGQgZGVjcmVhc2UgcHJvYmFiaWxpdHksIGJ1dCB3b3VsZCBub3QgY29tcGxl dGVseSBlbGltaW5hdGUgYXR0YWNrIHZlY3Rvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNeSBwcm9w b3NpdGlvbiBmb3IgdGhpcyBkcmFmdCBpcyBkaXNydXB0aXZlOjxicj4NCiZndDsgSSBiZWxpZXZl IHRoYXQgTkQgaXMgdmVyeSBjb21wbGljYXRlZCAoc29tZSBjb3VsZCBzYXkgJnF1b3Q7ZnJhZ2ls ZSZxdW90OykgLSBpdCBpcyBiZXR0ZXIgbm90IHRvIHRvdWNoIGl0Ljxicj4NCiZndDsgQWRkaXRp b25hbGx5IEkgZG8gbm90IGxpa2UgdG8gd2FpdCB0aWxsIGFsbCBob3N0cyB3b3VsZCByZWZyZXNo IHRvIG5ldyBkcmFmdCAodG8gZ2V0IG5ldyBmdW5jdGlvbmFsaXR5KS48YnI+DQo8YnI+DQpXZWxs LCBvbmx5IGhvc3RzIHdoaWNoIHdhbnQgdG8gY29ubmVjdCB0byB0aGUgbmV0d29yayBmYXN0ZXIg bmVlZCB0byBpbXBsZW1lbnQgdGhpcy4gU28gaG9zdCBPUyBkZXZlbG9wZXJzIGhhdmUgcHJldHR5 IGdvb2QgaW5jZW50aXZlIGhlcmUuPGJyPg0KUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBw cm9wb3NlZCBiZWhhdmlvciBpcyBub3QgY3VycmVudGx5IHByb2hpYml0ZWQuIFdlIGFyZSBub3Qg Y2hhbmdpbmcgYW55IE1VU1QgTk9UIHRvIGFueXRoaW5nIGVsc2UuIEFsbCB3ZSBhcmUgZG9pbmcg aXMgdG8gbWFraW5nIHNvbWUgcmVjb21tZW5kYXRpb25zIG1vcmUgZXhwbGljaXQuPGJyPg0KPGJy Pg0KJmd0OyBJIHByb3Bvc2UgdG8gY2hhbmdlIG9ubHkgcm91dGVyIGJlaGF2aW9yOiBjaGVjayBT b3VyY2UgTExBIChNQUMpIGZvciBldmVyeSBwYWNrZXQsIGlmIHRoaXMgU0xMQSBpcyBhYnNlbnQg aW4gTkQgY2FjaGUgLSB0aGVuIHJlcXVlc3Qgc29saWNpdGVkIE5TLU5BIGltbWVkaWF0ZWx5LiBJ dCB3b3VsZCBwcm9iYWJseSByZXNvbHZlIGZhc3RlciB0aGFuIHRyYWZmaWMgd291bGQgcmV0dXJu IGZyb20gdGhlIGludGVybmV0Ljxicj4NCjxicj4NCkhhdmUgeW91IGNoZWNrZWQgdGhlIHByb2Js ZW0gc3RhdGVtZW50IGRyYWZ0Pzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1uZC1jYWNoZS1pbml0LTAzI3NlY3Rpb24t My43IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmQtY2FjaGUtaW5pdC0wMyNzZWN0 aW9uLTMuNzwvYT48YnI+DQpzcGVjaWZpY2F0bGx5Pzxicj4NCldoYXQgeW91IGFyZSBwcm9wb3Np bmcgZG9lcyBtYWtlIHNlbnNlLCBob3dldmVyIGl0IHdvdWxkIG5vdCBoZWxwIGluIGNhc2Ugb2Yg bXVsdGlwbGUgcm91dGVycy4gQWxzbyBJIHJlY2FsbCBzb21lIHBlb3BsZSBoYXZpbmcgc3Ryb25n IG9waW5pb25zIG9uIHBlcmZvcm1hbmNlIGltcGxpY2F0aW9ucy48YnI+DQo8YnI+DQomZ3Q7IEVm ZmVjdGl2ZWx5IEkgZG8gcHJvcG9zZWQgdGhlIHNhbWUgU0xMQSBSUEYgdGhhdCBpcyBuZWVkZWQg dG8gZml4IGN1cnJlbnQgc29sdXRpb24sIGJ1dDo8YnI+DQomZ3Q7IC0gd2l0aG91dCBhbnkgbW9k aWZpY2F0aW9uIHRvIGhvc3QgT1Nlczxicj4NCiZndDsgLSB3aXRob3V0IGFueSBtb2RpZmljYXRp b24gb2Ygc3RhbmRhcmQgKGl0IGlzIGxvY2FsIHJlY29tbWVuZGF0aW9uIGZvciA8YnI+DQomZ3Q7 IHJvdXRlciwgTlMtTkEgaXMgZXhhY3RseSB0aGUgc2FtZSBmcm9tIFJGQyA0NjgxLCBOQSBpcyB1 bmljYXN0IC0gaXQgaXMgPGJyPg0KJmd0OyBpbXBvcnRhbnQgZm9yIHNlY3VyaXR5KTxicj4NCiZn dDsgLSB3aXRob3V0IGFueSByaXNrIHRvIGJyZWFrIE5EIGZyYWdpbGUgYWxnb3JpdGhtPGJyPg0K Jmd0OyAtIGl0IGNvdWxkIGJlIG9wdGlvbmFsLCBvciBldmVuIGNvbmZpZ3VyYWJsZSBvbiB0aGUg cm91dGVyIGFzICZxdW90O3ZhbHVlIDxicj4NCiZndDsgYWRkIGZlYXR1cmUmcXVvdDsgaW4gY29t cGV0aXRpdmUgdGVuZGVyIEJlY2F1c2UgaXQgaXMganVzdCBiZXN0IHByYWN0aWNlIHJlY29tbWVu ZGF0aW9uIC0gbWF5IGJlIGl0IG1ha2Ugc2Vuc2UgdG8gbW92ZSBpdCB0byAmcXVvdDt2Nm9wcyZx dW90Oz88YnI+DQo8YnI+DQpTZWUgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW5kLWNhY2hlLWluaXQtMDMiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLXY2b3BzLW5kLWNhY2hlLWluaXQtMDM8L2E+PGJyPg0KPGJyPg0KJmd0 OyBQUzogTG9va2luZyB0byB0aGUgYWJvdmUgLSB1bnNvbGljaXRlZCBOQSBzaG91bGQgYmUgcmVh bGx5IGRlbGF5ZWQgYnkgYWRkaXRpb25hbCBiaWcgdGltZXIgKG5vdCBieSBSZXRyYW5zVGltZXIg dGhhdCBpcyB1c2VkIGZvciBzb2xpY2l0ZWQgTlMvTkEpIGFuZCBjaGVja2VkIG9uIHJlY2VpdmVy IHNpZGUgLSB0aGlzIG1vZGlmaWNhdGlvbiBvZiBzdGFuZGFyZCBpcyByZWFsbHkgbmVlZGVkIHRv IGNsb3NlIFVuc29saWNpdGVkIE5BIHZ1bG5lcmFiaWxpdHkuPGJyPg0KJmd0OyBTb21lYm9keSBz YWlkIG9uIHRoZSBjYWxsIHRoYXQgaXQgaXMgYWxyZWFkeSBhIGZlYXR1cmUgb2Ygc29tZSBPUyAo QW5kcm9pZD8pIC0gaXQgaXMgYmFkOiBpdCBtZWFucyB0aGF0IHRoaXMgT1MgaXMgYWxyZWFkeSB2 dWxuZXJhYmxlLjxicj4NCjxicj4NCkkgd2FzIHNheWluZyB0aGF0IHNvbWUgcm91dGluZyBwbGF0 Zm9ybXMgaGF2ZSB0aGlzIGFscmVhZHkgaW1wbGVtZW50ZWQuIFNlYXJjaCBmb3IgJ2dsZWFuJyBo ZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3RkL2RvY3Mv aW9zLXhtbC9pb3MvaXB2Nl9iYXNpYy9jb25maWd1cmF0aW9uLzE1LWUvaXA2Yi0xNS1lLWJvb2sv aXA2LW5kLWNhY2hlLW1nbXQuaHRtbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9pcHY2X2Jh c2ljL2NvbmZpZ3VyYXRpb24vMTUtZS9pcDZiLTE1LWUtYm9vay9pcDYtbmQtY2FjaGUtbWdtdC5o dG1sPC9hPjxicj4NCjxicj4NCkFGQUlLIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2gg YXJlIGFsc28gcHJlcG9wdWxhdGluZyBOQyBmcm9tIERBRCBwYWNrZXRzIGJ1dCBJIGNhbiBub3Qg ZmluZCB5b3UgYSByZWZlcmVuY2UgcmlnaHQgbm93Ljxicj4NCjxicj4NCiZndDsgRnJvbTogaXB2 NiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pcHY2LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmVuIExpbmtv dmE8YnI+DQomZ3Q7IFNlbnQ6IDI3INC40Y7Qu9GPIDIwMjAg0LMuIDc6NDk8YnI+DQomZ3Q7IFRv OiA2bWFuICZsdDs8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlwdjZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMS50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZWxsbyw8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgLTAxIHZlcnNpb24gYWRkcmVzc2VzIGNvbW1lbnRzIHJl Y2VpdmVkICh0aGFua3MgZXZlcnlvbmUgd2hvIHByb3ZpZGVkIGZlZWRiYWNrKS4gQWxzbywgU2Vj dGlvbiAzIChBdm9pZGluZyBEaXNydXB0aW9uKSBoYXMgYmVlbiBleHBhbmRlZCBhbmQgZGlzY3Vz c2VkIGEgY29ybmVyIGNhc2Ugd2hlbiB0d28gZGV2aWNlcyBzdGFydCB1c2luZyB0aGUgc2FtZSBh ZGRyZXNzIGFsbW9zdCBhdCB0aGUgc2FtZSB0aW1lICh0aGUgc2Vjb25kIGRldmljZQ0KIGNvbmZp Z3VyZXMgYW4gb3B0aW1pc3RpYyBhZGRyZXNzIGFmdGVyIHRoZSByaWdodGZ1bCBvd25lciBzZW50 IHNvbWUgcGFja2V0cyBidXQgYmVmb3JlIHRoZSByZXR1cm4gdHJhZmZpYyBhcnJpdmVzKS48YnI+ DQomZ3Q7IEZlZWRiYWNrIG9uIHRoZSB1cGRhdGVkIHNlY3Rpb24gMy4zPGJyPg0KJmd0OyAoPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC0w MSNzZWN0aW9uLTMuMyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSNzZWN0aW9uLTMuMzwv YT4pIGlzIHZlcnkgbXVjaCBhcHByZWNpYXRlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBTdW4s IEp1bCAyNiwgMjAyMCBhdCAxMDoxNCBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Rp dGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEdyYXR1aXRvdXMg TmVpZ2hib3IgRGlzY292ZXJ5OiBDcmVhdGluZyBOZWlnaGJvciBDYWNoZSBFbnRyaWVzIG9uIEZp cnN0LUhvcCBSb3V0ZXJzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0F1dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBKZW4gTGlu a292YTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxl bmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0w MS50eHQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFn ZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTI8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMC0wNy0yNTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IE5laWdo Ym9yIERpc2NvdmVyeSAoUkZDNDg2MSkgaXMgdXNlZCBieSBJUHY2IG5vZGVzIHRvIGRldGVybWlu ZSB0aGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGxpbmstbGF5ZXIgYWRkcmVzc2VzIG9m IG5laWdoYm9yaW5nIG5vZGVzIGFzIHdlbGwgYXMgdG8gZGlzY292ZXIgYW5kPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyBtYWludGFpbiByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uJm5ic3A7 IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0ODYxIHRvPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyBhbGxvdyByb3V0ZXJzIHRvIHByb2FjdGl2ZWx5IGNyZWF0ZSBhIE5laWdoYm9yIENhY2hl IGVudHJ5IHdoZW4gYSBuZXc8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IElQdjYgYWRkcmVz cyBpcyBhc3NpZ25lZCB0byBhIG5vZGUuJm5ic3A7IEl0IGFsc28gdXBkYXRlcyBSRkM0ODYxIGFu ZDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgcmVjb21tZW5kcyBub2RlcyB0byBzZW5kIHVu c29saWNpdGVkIE5laWdoYm9yIEFkdmVydGlzZW1lbnRzIHVwb248YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7IGFzc2lnbmluZyBhIG5ldyBJUHY2IGFkZHJlc3MuJm5ic3A7IFRoZSBwcm9wb3Nl ZCBjaGFuZ2Ugd2lsbCBtaW5pbWl6ZSB0aGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGRl bGF5IGFuZCBwYWNrZXQgbG9zcyB3aGVuIGEgbm9kZSBpbml0aWF0ZSBjb25uZWN0aW9ucyB0byBv ZmYtbGluazxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgZGVzdGluYXRpb24gZnJvbSBhIG5l dyBJUHY2IGFkZHJlc3MuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxi cj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLTZtYW4tZ3JhbmQvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC88 L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi02bWFuLWdyYW5kLTAxPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMTwvYT48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Ojxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLWdyYW5kLTAxIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LTZtYW4tZ3JhbmQtMDE8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIDxicj4NCiZndDsgJmd0OyBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLi5p ZXRmLm9yZzwvYT4uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7ICZndDsg PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy88L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dCA8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaXB2NkBp ZXRmLm9yZzwvYT4gQWRtaW5pc3RyYXRpdmUgPGJyPg0KJmd0OyAmZ3Q7IFJlcXVlc3RzOiA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2PC9hPjxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFNZLCBKZW4gTGlua292YSBh a2EgRnVycnk8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86 aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48YnI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpTWSwgSmVuIExpbmtv dmEgYWthIEZ1cnJ5PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8c3Bh bj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 YnI+DQo8c3Bhbj52Nm9wcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+djZvcHNAaWV0 Zi5vcmc8L3NwYW4+PGJyPg0KPHNwYW4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wczwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_E176B08424E1434DB15CF364F64807BBciscocom_-- From nobody Fri Jul 31 10:17:57 2020 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 43F2B3A0BB0; Fri, 31 Jul 2020 10:17:54 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5h1Yo1M8faq; Fri, 31 Jul 2020 10:17:51 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 42DAB3A0BA5; Fri, 31 Jul 2020 10:17:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VHHmh9028232; Fri, 31 Jul 2020 13:17:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596215868; bh=mwqlFzSrV2IEh8y+hf5nTiQmnd60SSghdtKX4fqKyUQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=hDMrdNBZo3CK8Tf/m8/rtK9oIuYFeYdPJHWRxCvQR7lllCNEnxvhzuj3x9wVfq2Gc EJ5LwASJp79V3UNXgTiNzGq/QtlqRpS2IVF98I+8DIj2plPpeU1yevkJmOdvMSlkRj QiJ26nwlmHB+E8+wpMnfuMZk5mEM0rcrNUOFkKBqHr+JV0dqJJvFdAHRJkyD1LoksE ZYqI0De6j8s7765zkmTQP5yFJ4tcd34iq4f2VTsbmhV8ZTaCrw98wh7HVkjTFntKnJ HSM0kS8PtraFIZi54N2mscfQx5evqflwXtx3xdDtEllybNtoKtrjkaIM6mz4AP6GvB PydSrkG0u1MUw== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VHHj6O028208 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 13:17:45 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 10:17:43 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 10:17:43 -0700 From: "Templin (US), Fred L" To: Ted Lemon CC: "Pascal Thubert (pthubert)" , "v6ops list" , 6man Thread-Topic: [EXTERNAL] Improving ND security Thread-Index: AQHWZ1UXpJjqh6zAPESbZadyenD7WakiUY2A//+bayA= Date: Fri, 31 Jul 2020 17:17:43 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> In-Reply-To: <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 17A50C88FD721F11942461EC3E5915BA33D6A042C6BE6FA66AB40AFAF0C23D592000:8 Content-Type: multipart/alternative; boundary="_000_a1881d0c6d3748fa8cec8ea2b2c6559bboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:17:55 -0000 --_000_a1881d0c6d3748fa8cec8ea2b2c6559bboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lcyBpdCBzb2x2ZSB0aGUgcHJvYmxlbSBPd2VuIHdhcyB0YWxraW5nIGFib3V0IChvdmVybG9h ZGluZyBuZWlnaGJvciB0YWJsZXMgYXMgYW4gYXR0YWNrKT8gIElzIHRoZXJlIGFncmVlbWVudCB0 aGF0IHRoaXMgaXMgYSBzZXJpb3VzIHByb2JsZW0gaW4gYW55IGNhc2U/DQoNClRlZCwgSSB0aGlu ayBTRU5EIHdvdWxkIHNvbHZlIHRoZSBuZWlnaGJvciBjYWNoZSByZXNvdXJjZSBleGhhdXN0aW9u IGF0dGFjayBzaW5jZSBhIE5DRSBpcw0Kb25seSBjcmVhdGVkIG9uIHJlY2VpcHQgb2YgYW4gYXV0 aGVudGljIChTRU5ELXByb3RlY3RlZCkgSVB2NiBORCBtZXNzYWdlLg0KDQpJIGJlbGlldmUgdGhh dCBmb3IgYXZpYXRpb24gbmV0d29ya3MsIGludGVsbGlnZW50IHRyYW5zcG9ydGF0aW9uIHN5c3Rl bXMsIGFuZCBvdGhlciBtb2JpbGUgbm9kZQ0KdXNlIGNhc2VzIHRoZXJlIHdpbGwgY2VydGFpbmx5 IGJlIGNhc2VzIHdoZXJlIHRoZSBtb2JpbGUgbm9kZSBjb21lcyBvbnRvIHRoZSBuZXR3b3JrIHZp YSBhbg0KdW5wcm90ZWN0ZWQgb3Blbi1hY2Nlc3Mgd2lyZWxlc3MgYWNjZXNzIG5ldHdvcmsuIElu IHRoYXQgY2FzZSwgdGhlIG9ubHkgbWl0aWdhdGlvbnMgd291bGQgYmUNCmZvciB0aGUgTU4gdG8g c3RhbmQgdXAgYSBWUE4gKHdoaWNoIGlzIGV4cGVuc2l2ZSBvdmVya2lsbCkgb3Igc29tZWhvdyB1 c2UgSVB2NiBORCB3aXRoDQphcHByb3ByaWF0ZSBhdXRoZW50aWNhdGlvbiBjb250cm9scyBhcHBs aWVkLiBTRU5EIHNlZW1zIGxpa2UgYWdvb2QgZml0IGZvciB0aGUgbGF0dGVyLg0KDQpUaGFua3Mg LSBGcmVkDQoNCg0KRnJvbTogVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NClNl bnQ6IEZyaWRheSwgSnVseSAzMSwgMjAyMCA5OjEzIEFNDQpUbzogVGVtcGxpbiAoVVMpLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogUGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KSA8cHRodWJlcnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2 Nm9wc0BpZXRmLm9yZz47IDZtYW4gPGlwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0VYVEVS TkFMXSBJbXByb3ZpbmcgTkQgc2VjdXJpdHkNCg0KDQoNCg0KT24gSnVsIDMxLCAyMDIwLCBhdCAx MjoxMCBQTSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208 bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCkkgbGlrZSBTRU5ELCBh bmQgaXQgaXMgd3JpdHRlbiBpbnRvIG15IGRvY3VtZW50cyDigJMgaXMgdGhhdCBlbm91Z2ggb2Yg YSBwdXNoLCBvciBkbyBJIG5lZWQNCnRvIGRvIG1vcmUgYWdncmVzc2l2ZSBtYXJrZXRpbmc/IElu dGVyZXN0ZWQgaW4gaGVscGluZz8NCg0KVGhlIHB1c2ggd291bGQgaGF2ZSB0byBiZSBmcm9tIHNv bWVib2R5IHByb2R1Y2luZyBzb2Z0d2FyZSB0aGF0IGhhcyBicm9hZCByZWFjaC4gQW5kIGl0IHdv dWxkIGhhdmUgdG8gc29sdmUgYSByZWFsIHByb2JsZW0gb3Igbm9ib2R5IHdpdGggdGhhdCByZWFj aCB3b3VsZCB0cnkgdG8gZG8gaXQuDQoNCkRvZXMgaXQgc29sdmUgdGhlIHByb2JsZW0gT3dlbiB3 YXMgdGFsa2luZyBhYm91dCAob3ZlcmxvYWRpbmcgbmVpZ2hib3IgdGFibGVzIGFzIGFuIGF0dGFj ayk/ICBJcyB0aGVyZSBhZ3JlZW1lbnQgdGhhdCB0aGlzIGlzIGEgc2VyaW91cyBwcm9ibGVtIGlu IGFueSBjYXNlPw0KDQo= --_000_a1881d0c6d3748fa8cec8ea2b2c6559bboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+RG9lcyBpdCBzb2x2ZSB0aGUgcHJvYmxlbSBPd2VuIHdhcyB0YWxraW5nIGFib3V0 IChvdmVybG9hZGluZyBuZWlnaGJvciB0YWJsZXMgYXMgYW4gYXR0YWNrKT8gJm5ic3A7SXMgdGhl cmUgYWdyZWVtZW50IHRoYXQgdGhpcyBpcyBhIHNlcmlvdXMgcHJvYmxlbSBpbiBhbnkgY2FzZT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRlZCwgSSB0aGluayBT RU5EIHdvdWxkIHNvbHZlIHRoZSBuZWlnaGJvciBjYWNoZSByZXNvdXJjZSBleGhhdXN0aW9uIGF0 dGFjayBzaW5jZSBhIE5DRSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5vbmx5IGNyZWF0ZWQgb24gcmVj ZWlwdCBvZiBhbiBhdXRoZW50aWMgKFNFTkQtcHJvdGVjdGVkKSBJUHY2IE5EIG1lc3NhZ2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JIGJlbGlldmUgdGhhdCBm b3IgYXZpYXRpb24gbmV0d29ya3MsIGludGVsbGlnZW50IHRyYW5zcG9ydGF0aW9uIHN5c3RlbXMs IGFuZCBvdGhlciBtb2JpbGUgbm9kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij51c2UgY2FzZXMgdGhlcmUg d2lsbCBjZXJ0YWlubHkgYmUgY2FzZXMgd2hlcmUgdGhlIG1vYmlsZSBub2RlIGNvbWVzIG9udG8g dGhlIG5ldHdvcmsgdmlhIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnVucHJvdGVjdGVkIG9wZW4tYWNj ZXNzIHdpcmVsZXNzIGFjY2VzcyBuZXR3b3JrLiBJbiB0aGF0IGNhc2UsIHRoZSBvbmx5IG1pdGln YXRpb25zIHdvdWxkIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmZvciB0aGUgTU4gdG8gc3RhbmQgdXAg YSBWUE4gKHdoaWNoIGlzIGV4cGVuc2l2ZSBvdmVya2lsbCkgb3Igc29tZWhvdyB1c2UgSVB2NiBO RCB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmFwcHJvcHJpYXRlIGF1dGhlbnRpY2F0aW9uIGNvbnRy b2xzIGFwcGxpZWQuIFNFTkQgc2VlbXMgbGlrZSBhZ29vZCBmaXQgZm9yIHRoZSBsYXR0ZXIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGFua3MgLSBGcmVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEp1bHkgMzEsIDIwMjAgOToxMyBBTTxicj4NCjxiPlRvOjwvYj4gVGVt cGxpbiAoVVMpLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDtwdGh1YmVydD00MGNpc2Nv LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IHY2b3BzIGxpc3QgJmx0O3Y2b3BzQGlldGYub3JnJmd0 OzsgNm1hbiAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtF WFRFUk5BTF0gSW1wcm92aW5nIE5EIHNlY3VyaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7cGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pk9uIEp1bCAzMSwgMjAyMCwgYXQgMTI6MTAgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDs8 YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkkgbGlrZSBTRU5ELCBhbmQgaXQgaXMgd3JpdHRlbiBpbnRvIG15IGRv Y3VtZW50cyDigJMgaXMgdGhhdCBlbm91Z2ggb2YgYSBwdXNoLCBvciBkbyBJIG5lZWQ8L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50byBkbyBtb3JlIGFnZ3Jl c3NpdmUgbWFya2V0aW5nPyBJbnRlcmVzdGVkIGluIGhlbHBpbmc/PC9zcGFuPjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGUgcHVzaCB3b3VsZCBoYXZlIHRvIGJlIGZyb20gc29t ZWJvZHkgcHJvZHVjaW5nIHNvZnR3YXJlIHRoYXQgaGFzIGJyb2FkIHJlYWNoLiBBbmQgaXQgd291 bGQgaGF2ZSB0byBzb2x2ZSBhIHJlYWwgcHJvYmxlbSBvciBub2JvZHkgd2l0aCB0aGF0IHJlYWNo IHdvdWxkIHRyeSB0byBkbyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkRvZXMgaXQgc29sdmUgdGhlIHBy b2JsZW0gT3dlbiB3YXMgdGFsa2luZyBhYm91dCAob3ZlcmxvYWRpbmcgbmVpZ2hib3IgdGFibGVz IGFzIGFuIGF0dGFjayk/ICZuYnNwO0lzIHRoZXJlIGFncmVlbWVudCB0aGF0IHRoaXMgaXMgYSBz ZXJpb3VzIHByb2JsZW0gaW4gYW55IGNhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_a1881d0c6d3748fa8cec8ea2b2c6559bboeingcom_-- From nobody Fri Jul 31 10:20:41 2020 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 C5EAF3A0BB0; Fri, 31 Jul 2020 10:20:39 -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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFFtU8CARfsr; Fri, 31 Jul 2020 10:20:36 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A37193A0BAA; Fri, 31 Jul 2020 10:20:36 -0700 (PDT) Received: from lhreml706-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 58AC78829FDB946E3515; Fri, 31 Jul 2020 18:20:31 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 31 Jul 2020 18:20:30 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 31 Jul 2020 20:20:30 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 31 Jul 2020 20:20:30 +0300 From: Vasilenko Eduard To: Tony Finch , Owen DeLong CC: "Pascal Thubert (pthubert)" , "v6ops list" , 6man Thread-Topic: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AdZl2/KmEr6Lt/NERGGqFiMA7k1/CAAIPvAAABH5AHD///P/gP//vOiggAECawCAABGlgIABGVqAgAAEyoCAAAv7AP//vkZQ Date: Fri, 31 Jul 2020 17:20:30 +0000 Message-ID: <4f29ab2dd1a0467791d9304d85369f75@huawei.com> References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.204.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:20:40 -0000 SGkgVG9uZSwNCg0KPiBJZiBHUkFORCBpcyBkZXBsb3llZCwgd291bGQgdGhhdCBhbGxvdyByb3V0 ZXJzIHRvIGFzc3VtZSB0aGVpciBuZWlnaGJvdXIgdGFibGVzIGFyZSBjb21wbGV0ZSwgc28gdGhl eSBjYW4ganVzdCBkcm9wIE5EIGV4aGF1c3Rpb24gYXR0YWNrcz8NCg0KSG93IGlzIGl0IHBvc3Np YmxlIHRvIGJlIHN1cmUgdGhhdCBhbGwgaG9zdHMgZG8gc3VwcG9ydCBuZXcgZHJhZnQ/DQooMSkg ZHJhZnQgZG9lcyBub3QgcHJvcG9zZSB0byBzaWduYWwgTkQgdmVyc2lvbiBpbiBhbnkgd2F5ICgi Q29kZSIgaXMgc3RpbGwgMCkNCigyKSBPbmx5IGJ5IHNlcGFyYXRlIGFkbWluIGNvbmZpZ3VyYXRp b24gb24gcm91dGVyLCB0aGVuIGl0IGlzIG9wZXJhdGlvbmFsIHByYWN0aWNlLiBObyBuZWVkIGZv ciBzdGFuZGFyZGl6YXRpb24uDQoNCk1heSBiZSB5b3UgaGF2ZSBhc2tlZDogaXMgcG9zc2libGUg aW4gcHJpbmNpcGxlPw0KTm8sIGJlY2F1c2UgTkQgY2FjaGUgY291bGQgYmUgb3ZlcndoZWxtZWQg YnkgVW5zb2xpY2l0ZWQgTkRzLCBidXQgVW5zb2xpY2l0ZWQgTkQgaXMgcHJpbWFyeSB2ZWhpY2xl IGluIHRoZSBkcmFmdC4NCg0KUFM6IEkgd2FzIG1vcmUgY29uY2VybmVkIGFib3V0ICJNYW4taW4t dGhlIG1pZGRsZSIgLSBpdCBpcyB0aGUgYmlnZ2VyIHNlY3VyaXR5IHByb2JsZW0sIG5vdCBERG9T IC0gYWxiZWl0IGl0IGlzIGEgYmlnIHByb2JsZW0gdG9vLg0KRWQvDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFRvbnkgRmluY2gNClNlbnQ6IDMxINC40Y7Qu9GPIDIwMjAg0LMuIDE5OjEzDQpU bzogT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4NCkNjOiBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpIDxwdGh1YmVydD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IHY2b3BzIGxpc3Qg PHY2b3BzQGlldGYub3JnPjsgNm1hbiA8aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZv cHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwgc2Vj dXJpdHkgY29uY2VybnMNCg0KT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4gd3JvdGU6DQo+ DQo+IEluZGVlZCwgYXMgYW4gb3BlcmF0b3IsIElNSE8sIGlmIHRoZXJl4oCZcyBhIHBsYWNlIHdl IG5lZWQgdG8gZm9jdXMgb24gDQo+IGltcHJvdmluZyBMMiBhdHRhY2sgc3VyZmFjZSBpbiB2Niwg aXTigJlzIGluIGZpbmRpbmcgYmV0dGVyIHdheXMgZm9yIA0KPiB7cm91dGVycywgaG9zdHMsIHN3 aXRjaGVzfSB0byBtaXRpZ2F0ZS9hYnNvcmIgdGhpcyB0eXBlIG9mIHJlc291cmNlIA0KPiBleGhh dXN0aW9uIGF0dGFjay4gVW5mb3J0dW5hdGVseSwgdGhpcyBpcyBhIGhhcmQgcHJvYmxlbSB0byBz b2x2ZSwgc28gDQo+IHdlIGZvY3VzIG9uIG1vdmluZyB0aGUgZGVjayBjaGFpcnMgd2UgY2FuIG1v dmUgd2hpbGUgaWdub3JpbmcgdGhlIA0KPiBlbGVwaGFudC1zaXplZCBob2xlIGluIHRoZSBidWxr aGVhZHMgdGhhdCB3ZSBkb27igJl0IGtub3cgaG93IHRvIHBhdGNoLg0KDQpJZiBHUkFORCBpcyBk ZXBsb3llZCwgd291bGQgdGhhdCBhbGxvdyByb3V0ZXJzIHRvIGFzc3VtZSB0aGVpciBuZWlnaGJv dXIgdGFibGVzIGFyZSBjb21wbGV0ZSwgc28gdGhleSBjYW4ganVzdCBkcm9wIE5EIGV4aGF1c3Rp b24gYXR0YWNrcz8NCg0KVG9ueS4NCi0tDQpmLmFudGhvbnkubi5maW5jaCAgPGRvdEBkb3RhdC5h dD4gIGh0dHA6Ly9kb3RhdC5hdC8gU2hhbm5vbiwgU291dGhlYXN0IFJvY2thbGw6IFdlc3Rlcmx5 IG9yIHNvdXRod2VzdGVybHkgNCBvciA1LiBNb2RlcmF0ZSBvciByb3VnaC4gU2hvd2Vycy4gR29v ZCwgb2NjYXNpb25hbGx5IG1vZGVyYXRlLg0K From nobody Fri Jul 31 10:22:23 2020 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 E1A0B3A0BB0 for ; Fri, 31 Jul 2020 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJUdv7AsK8nT for ; Fri, 31 Jul 2020 10:22:14 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A7D3A0EA7 for ; Fri, 31 Jul 2020 10:21:43 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id c9so755571qvu.5 for ; Fri, 31 Jul 2020 10:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mgakV/e+Xe/pDWYCynq1XvCMgkDuyeBkqpmOca3bTD8=; b=M2QtYVH9OeWeaHcC3A86q4ak+ASyqSeV7QmKBRhSCR5t63tXO9/3Oq0vdQJ60xijun JrLAMa3S/V94P54ml8BzDFYRHuVYiDPMFVcuE4SOHjw1Sbh5Wq8/i2WIH6Gf8eVzWCpv weHhBDXeepnZdomxEV0EbJ87KTEVD2dWnCkIvhIDO/h23sgBO7SokqQ3VLY17aRcW4p4 R522Fji75ISnWE1sT8lSpMdu3UeHWIkC80ar3HDjdnumG0+gqzdJIbL2IRcDQ92+4UZY 87sLvJbqH7rcJ4br8/O9lbv1kePlQPbnBvzBw7V6PwaL9Zag814N43YtN4YwZg6SCTEW kQ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mgakV/e+Xe/pDWYCynq1XvCMgkDuyeBkqpmOca3bTD8=; b=h2ZbVf6ofzoTHMWmyRDlklP9cmsoqPWSRh0CCJRmBpzjELNJbUALssKO1CkPOYhIYm /vxjo2/EmdGWe2kGhQIIwS+P6aJZlst6o9kuQI5izicrLqOBKqrOEG1+SPwwbjE4RYOX y/bDs0vDMo4wTPLDmbtXuYk2Mzjtpq4wL6zY22GoX4VjtBmTIzvZtFU9bfJUDToOBtDU ow1ljbf3MiJ0p2Mfizxf+zlvFI5DsEu+x+2bER/QKWy3Zu67ujs3kcRR8XI2rxM7v+Sg ACFsbi6BZa7dz5HTXyMha5mZ3Ik2oQN+T2oqRKU2R/2VqELQ92XEqg6gVAvtQzGp3ILX pKog== X-Gm-Message-State: AOAM531Cm7l/oWmL/k0wAlu38YdP3SGgz2XDsWqoExuqYPIqpnZaUflK ka/y3evdnci83DKD+hDX1WoJSQ== X-Google-Smtp-Source: ABdhPJx7QSdXn8Yh8iokpe8QACHj4oeuAWcD5wMrC2DYTIF+AKbho4iHw75qalzq0/p+myzKp3nbzQ== X-Received: by 2002:a0c:fc07:: with SMTP id z7mr5273314qvo.65.1596216103025; Fri, 31 Jul 2020 10:21:43 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id q17sm2106417qte.61.2020.07.31.10.21.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 10:21:42 -0700 (PDT) From: Ted Lemon Message-Id: <1766B530-1683-403B-BC7D-90C4B056B739@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F15FC8F9-8E18-4A40-9311-D8315C9DEE05" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 13:21:40 -0400 In-Reply-To: Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: "Templin (US), Fred L" References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:22:16 -0000 --Apple-Mail=_F15FC8F9-8E18-4A40-9311-D8315C9DEE05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2020, at 1:17 PM, Templin (US), Fred L = wrote: > Ted, I think SEND would solve the neighbor cache resource exhaustion = attack since a NCE is > only created on receipt of an authentic (SEND-protected) IPv6 ND = message. OK, but an attacker can just generate a bazillion key pairs, right? So = it can still exhaust the cache, at the cost of some computation work. --Apple-Mail=_F15FC8F9-8E18-4A40-9311-D8315C9DEE05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jul 31, 2020, at 1:17 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
Ted, I = think SEND would solve the neighbor cache resource exhaustion attack = since a NCE is
only created on receipt of an authentic (SEND-protected) IPv6 = ND message.

OK, = but an attacker can just generate a bazillion key pairs, right? So it = can still exhaust the cache, at the cost of some computation = work.


= --Apple-Mail=_F15FC8F9-8E18-4A40-9311-D8315C9DEE05-- From nobody Fri Jul 31 10:23:44 2020 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 976F13A0BAA for ; Fri, 31 Jul 2020 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf0vcIdS51Yt for ; Fri, 31 Jul 2020 10:23:39 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF013A0C89 for ; Fri, 31 Jul 2020 10:23:17 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id l64so22662452qkb.8 for ; Fri, 31 Jul 2020 10:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J2Nxe0CGSwOnb/iLof+JdHMkIM4+RKywsefb04zvlL8=; b=dNGE2REol4rLfJAiI6Fy84xOzXimyrxlrPUf7z5I/p3u2unQwDMxXZ2NtEk5AIJYQe Go9dKcF3QV1w+y4cKjqOyUCvBf6L/tXUva4DC4RsFJeMaaa/I+L7erW9B9yWA14sftjE PjvPyo9nVlIReZ08AJvqRl4GIPQlJ6pV/qfTTdhNM36d5czmnOcI41B3/5REPNi9NZet 0L5dGRvpwOqGoI+SMCBEtLJUyBXU4s439dsYTMweTVtyoXqzK41FruA8GXN7YBu57hi3 73uOuk+7Rx/nGW6Z0WVNNwRi7FoP3rJUqJ0UKd+qEq2Xc2mz/kDwQEQxUGlTMLvFVWSM fDNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J2Nxe0CGSwOnb/iLof+JdHMkIM4+RKywsefb04zvlL8=; b=FymipEu7/RFhy/1nnP26haLR5FxRtpp4np5OLXGIaLn8/4IUXZRiIdjz6sZg6fri1Q 0NfFmm54OYN4m0MJGw4s7XY1QHtVqeNv2jkVvPlredvNp7fJpLx01RmFojUEhjShHCJ0 dPxAzveZqvybhFGt6rPG12gHz3kY4FbkpZjyU/9CXw4Vcq4O2404otQJS1BqoSX6I4N/ Gk8eZKyae/busgm6/obctqZDlBuhdW1Im33SJUQu4AJ6JviWakEO/h9CY/Tun9osv7nE RiLCIF6wUB6Sji5wEQxP7CV3jdSClnaxDLf6kLG7vFmwAzDjHRkgJmTpoNrDsRxx6uR0 LGtQ== X-Gm-Message-State: AOAM533bv/1R3dENg8eOIUkAaFzDMSbXAWywKfy7LDUC6AWZy5rDvWsG /V8z/lEHt0IrCZNbnSIC9bD+wA== X-Google-Smtp-Source: ABdhPJycogseB/N/cDoZNE2zs36oXaKjiw924YLdo+l/Ve9RzXWUfGMoQLmEFR42JgfI63G1gBZoEw== X-Received: by 2002:a37:a543:: with SMTP id o64mr5152632qke.177.1596216196664; Fri, 31 Jul 2020 10:23:16 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id w32sm8437347qtw.66.2020.07.31.10.23.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 10:23:16 -0700 (PDT) From: Ted Lemon Message-Id: <80FADCA7-8CB3-486F-A679-B747413831D6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_175E221D-9683-48AC-B6FF-BF6C47847CD0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 13:23:14 -0400 In-Reply-To: <4f29ab2dd1a0467791d9304d85369f75@huawei.com> Cc: Tony Finch , Owen DeLong , "Pascal Thubert (pthubert)" , v6ops list , 6man To: Vasilenko Eduard References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <4f29ab2dd1a0467791d9304d85369f75@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:23:41 -0000 --Apple-Mail=_175E221D-9683-48AC-B6FF-BF6C47847CD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 31, 2020, at 1:20 PM, Vasilenko Eduard = wrote: > (2) Only by separate admin configuration on router, then it is = operational practice. No need for standardization. I think I explained why it was worth standardizing from my perspective. = Perhaps you disagree with that perspective, but you haven=E2=80=99t said = why. The way you say this makes it sound like you think there=E2=80=99s = a downside to standardizing. Can you explain what that downside is? --Apple-Mail=_175E221D-9683-48AC-B6FF-BF6C47847CD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 31, 2020, at 1:20 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
(2) Only by separate admin configuration on router, then it = is operational practice. No need for standardization.

I think I explained why it was worth standardizing from my = perspective. Perhaps you disagree with that perspective, but you = haven=E2=80=99t said why.   The way you say this makes it sound = like you think there=E2=80=99s a downside to standardizing.  Can = you explain what that downside is?

= --Apple-Mail=_175E221D-9683-48AC-B6FF-BF6C47847CD0-- From nobody Fri Jul 31 10:36:02 2020 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 534483A0C50; Fri, 31 Jul 2020 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWuQAPM96vus; Fri, 31 Jul 2020 10:35:47 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 377C03A0C8E; Fri, 31 Jul 2020 10:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VHZf58005314; Fri, 31 Jul 2020 13:35:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596216943; bh=DUo7ww1w/pv0NZ4byUp+8C9ofUkcKdC9ID8ydkZwfiU=; h=From:To:CC:Subject:Date:From; b=EYxYgq4rAfdjiMaB96a0d1vOt9v0zLJCbIzWupTUaZyv6qG4OtR+ZsrBHirnNwHM7 91RGaJTeGvT664WPgRCeoRavX06mLR3T98iAUeD3k4ibT8NGSoYvYtxeqFbdAirXar KE+Y3ku5w8Thpj3azV+bqewmg2wy1KR6NPQO45cM64aggNs90vxtEf48QtSVclzlY2 7EsR1UyOstCh1RCzNwp6v9/Y0KNA+qRBivOFozBo5DmKBXtEAveHO7WiwOag0weHax cOEpcjYpep7cEzztSyC67tciVdFHpRQxYeciHUUlxYPggxqYmzWNlkLCQWSiDSjqEb lvrMVken7iNtw== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VHZWrC004749 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 13:35:32 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 10:35:31 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 10:35:31 -0700 From: "Templin (US), Fred L" To: Ted Lemon CC: "Pascal Thubert (pthubert)" , "v6ops list" , 6man Thread-Topic: Improving ND security Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6g== Date: Fri, 31 Jul 2020 17:35:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 987A15763C39FB47C81163C67172A664484305430C429B3FB5955EE3A62918892000:8 Content-Type: multipart/alternative; boundary="_000_d5c245f216c3409f826f8132e532a882boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:35:53 -0000 --_000_d5c245f216c3409f826f8132e532a882boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gSnVsIDMxLCAyMDIwLCBhdCAxOjE3IFBNLCBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdy b3RlOg0KVGVkLCBJIHRoaW5rIFNFTkQgd291bGQgc29sdmUgdGhlIG5laWdoYm9yIGNhY2hlIHJl c291cmNlIGV4aGF1c3Rpb24gYXR0YWNrIHNpbmNlIGEgTkNFIGlzDQpvbmx5IGNyZWF0ZWQgb24g cmVjZWlwdCBvZiBhbiBhdXRoZW50aWMgKFNFTkQtcHJvdGVjdGVkKSBJUHY2IE5EIG1lc3NhZ2Uu DQoNCk9LLCBidXQgYW4gYXR0YWNrZXIgY2FuIGp1c3QgZ2VuZXJhdGUgYSBiYXppbGxpb24ga2V5 IHBhaXJzLCByaWdodD8gU28gaXQgY2FuIHN0aWxsIGV4aGF1c3QgdGhlIGNhY2hlLCBhdCB0aGUg Y29zdCBvZiBzb21lIGNvbXB1dGF0aW9uIHdvcmsuDQpbPl0NCg0KSSB0aGluayBhcyBsb25nIGFz IHRoZSBuZXR3b3JrIGhhcyBhIHdheSBvZiBhc3NvY2lhdGluZyB0aGUga2V5IHBhaXIgd2l0aCBh bm90aGVyIHBpZWNlDQpvZiBpbmZvcm1hdGlvbiB0aGF0IGFjY29tcGFuaWVzIHRoZSBJUHY2IE5E IG1lc3NhZ2UgdGhlbiB0aGUgbmV0d29yayB3b3VsZCBiZSBhYmxlDQp0byBrbm93IHdoZW4gdGhl IG1vYmlsZSBub2RlIGlzIHVzaW5nIGl0cyAoc2luZ2xlKSBhdXRob3JpemVkIGtleS4gU28sIGZv ciBleGFtcGxlLCBpZg0KdGhlIElQdjYgTkQgbWVzc2FnZSBpbmNsdWRlZCBhbiBpZGVudGl0eSBm b3IgdGhlIE1OIChzb3J0IG9mIGxpa2UgYSBESENQdjYgRFVJRCksIHRoZQ0KbmV0d29yayB3b3Vs ZCBrbm93IHdoZW4gdGhlIE1OIGlzIHVzaW5nIHRoZSBjb3JyZWN0IGtleSBwYWlyIOKAkyByaWdo dD8gKEJUVywgSSBhbQ0Kbm90IHNheWluZyB0byB1c2UgREhDUHY2IERVSUQg4oCTIHRoYXQgaXMg anVzdCBvbmUgZXhhbXBsZSBvZiBhIE1OIGlkZW50aXR54oCmKQ0KDQpUaGFua3MgLSBGcmVkDQoN Cg0K --_000_d5c245f216c3409f826f8132e532a882boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+T24gSnVsIDMxLCAyMDIwLCBhdCAxOjE3IFBNLCBUZW1wbGluIChVUyksIEZyZWQg TCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5UZWQsIEkgdGhpbmsgU0VORCB3b3VsZCBzb2x2ZSB0aGUgbmVpZ2hi b3IgY2FjaGUgcmVzb3VyY2UgZXhoYXVzdGlvbiBhdHRhY2sgc2luY2UgYSBOQ0UgaXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+b25seSBjcmVhdGVkIG9uIHJlY2VpcHQgb2YgYW4g YXV0aGVudGljIChTRU5ELXByb3RlY3RlZCkgSVB2NiBORCBtZXNzYWdlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPk9LLCBidXQgYW4gYXR0YWNrZXIgY2FuIGp1c3QgZ2VuZXJhdGUg YSBiYXppbGxpb24ga2V5IHBhaXJzLCByaWdodD8gU28gaXQgY2FuIHN0aWxsIGV4aGF1c3QgdGhl IGNhY2hlLCBhdCB0aGUgY29zdCBvZiBzb21lIGNvbXB1dGF0aW9uIHdvcmsuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlsmZ3Q7XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBhcyBsb25nIGFzIHRo ZSBuZXR3b3JrIGhhcyBhIHdheSBvZiBhc3NvY2lhdGluZyB0aGUga2V5IHBhaXIgd2l0aCBhbm90 aGVyIHBpZWNlPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+b2YgaW5mb3JtYXRpb24g dGhhdCBhY2NvbXBhbmllcyB0aGUgSVB2NiBORCBtZXNzYWdlIHRoZW4gdGhlIG5ldHdvcmsgd291 bGQgYmUgYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvIGtub3cgd2hlbiB0 aGUgbW9iaWxlIG5vZGUgaXMgdXNpbmcgaXRzIChzaW5nbGUpIGF1dGhvcml6ZWQga2V5LiBTbywg Zm9yIGV4YW1wbGUsIGlmPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIElQdjYg TkQgbWVzc2FnZSBpbmNsdWRlZCBhbiBpZGVudGl0eSBmb3IgdGhlIE1OIChzb3J0IG9mIGxpa2Ug YSBESENQdjYgRFVJRCksIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm5ldHdv cmsgd291bGQga25vdyB3aGVuIHRoZSBNTiBpcyB1c2luZyB0aGUgY29ycmVjdCBrZXkgcGFpciDi gJMgcmlnaHQ/IChCVFcsIEkgYW08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ub3Qg c2F5aW5nIHRvIHVzZSBESENQdjYgRFVJRCDigJMgdGhhdCBpcyBqdXN0IG9uZSBleGFtcGxlIG9m IGEgTU4gaWRlbnRpdHnigKYpPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDwvc3Bhbj48L2k+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_d5c245f216c3409f826f8132e532a882boeingcom_-- From nobody Fri Jul 31 10:40:52 2020 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 4056A3A096D for ; Fri, 31 Jul 2020 10:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BSCQ6yFlZHj for ; Fri, 31 Jul 2020 10:40:46 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDDB3A08E6 for ; Fri, 31 Jul 2020 10:40:45 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id c12so14529130qtn.9 for ; Fri, 31 Jul 2020 10:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YtwQ5dx3S1BB8hOkvC6e+3D0wguaHTW4Zph+6fBMuZg=; b=hxbadQ/L6ditv9NrQxxbmlrtUV1mFUB2UsH1CK/55Q0Dfkidc6+a+ybsiGKJy7RC8L rgB+ZB8HHxrERd7E7pE+ackgXLNBv/dfPeS0WY8BRB96vOTzC0sM7eRm3LMnhAL9FYnL XaQraCTOafysamNIPS0Pf95FN+5BbTvdsztQv0K41Zb4jOuN5cebqsFoP9f79viDnVwt boP0rEKv+fm9Hk3sdl2sKEUpwRMx0qz3zaVHWoQMhuslTYLPel0Gs75sZqy8GyBudoay bES01b2uHuI684Kg9/ESzLO0SxJ80mASEL5mwoDsjs/3+FMqobZ92JdFCIQf1PnHbz6c MhYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YtwQ5dx3S1BB8hOkvC6e+3D0wguaHTW4Zph+6fBMuZg=; b=UgpqohV7QYjAo0o29kb5N2pfZHb1RaW2ZNAOVVZD+HYL8md8guLjYy9bqMJwaLdKlA GMU5RNcJ0C/tDnF1blmECj5qBrcBxDa4NGUUwTwy9/9szC9zudJqm0OgWZvHZfacgT83 KLyBhKjOeuoH+A78yi2b6zYOV+kikCb5850pkfj1ZpJyt7ECcaBmRFVlgSVQl4WVdTz4 v/JZpzZZYsMA+TRTPMdx+uzT02xhIFzMtPrpW6ILasUYuHdYfUlSZl94ppffIOMxfhIi Pi89s3GaqvNYVEouYwuCOYWkhDDCfye7zYIeHd/JDderkXtAOnYDuJYF/ViEjU0tyjII sgqA== X-Gm-Message-State: AOAM531u4pb04L4qp9RtLJ9PeZBlnQBRu16KwpsHt3lwXk+dNKZ0xyxU hUIhJPKRFnyPpW2hm4e5cdMLrA== X-Google-Smtp-Source: ABdhPJy1Ptz7qCBPwdUaQEPHUOA0NK0EQqPS9xse9AmjozXL/4UkfRz4eUh5aWJ6zNM48jHxCn2GYA== X-Received: by 2002:ac8:1486:: with SMTP id l6mr4853530qtj.195.1596217244784; Fri, 31 Jul 2020 10:40:44 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:1d5e:d83c:760:89f9? ([2601:18b:300:36ee:1d5e:d83c:760:89f9]) by smtp.gmail.com with ESMTPSA id o17sm9092097qtr.13.2020.07.31.10.40.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 10:40:44 -0700 (PDT) From: Ted Lemon Message-Id: <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7951215C-D4FF-4301-B74D-C9BA0BA9FFB9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 31 Jul 2020 13:40:42 -0400 In-Reply-To: Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: "Templin (US), Fred L" References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:40:51 -0000 --Apple-Mail=_7951215C-D4FF-4301-B74D-C9BA0BA9FFB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 31, 2020, at 1:35 PM, Templin (US), Fred L = wrote: > I think as long as the network has a way of associating the key pair = with another piece > of information that accompanies the IPv6 ND message then the network = would be able > to know when the mobile node is using its (single) authorized key. So, = for example, if > the IPv6 ND message included an identity for the MN (sort of like a = DHCPv6 DUID), the > network would know when the MN is using the correct key pair =E2=80=93 = right? (BTW, I am > not saying to use DHCPv6 DUID =E2=80=93 that is just one example of a = MN identity=E2=80=A6) By =E2=80=9CNM=E2=80=9D I think you mean =E2=80=9CMobile Node?=E2=80=9D = That=E2=80=99s not really one of the use cases we=E2=80=99re talking = about here. Or am I missing something? In any case, you=E2=80=99re presuming some kind of trust establishment = for non-router nodes, right? SEND only talks about trust establishment = for routers. And, let=E2=80=99s be frank, doesn=E2=80=99t actually give = us enough operational guidance that we would expect what _is_ said to be = generally practicable. --Apple-Mail=_7951215C-D4FF-4301-B74D-C9BA0BA9FFB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 31, 2020, at 1:35 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
I think as long as the network has a way of associating the = key pair with another piece
of information = that accompanies the IPv6 ND message then the network would be able
to know when the mobile node is using its (single) authorized = key. So, for example, if
the IPv6 ND = message included an identity for the MN (sort of like a DHCPv6 DUID), = the
network would know when the MN is using the correct key pair = =E2=80=93 right? (BTW, I am
not saying to = use DHCPv6 DUID =E2=80=93 that is just one example of a MN = identity=E2=80=A6)

By =E2=80=9CNM=E2=80=9D I think you mean = =E2=80=9CMobile Node?=E2=80=9D That=E2=80=99s not really one of the use = cases we=E2=80=99re talking about here. Or am I missing = something?

In = any case, you=E2=80=99re presuming some kind of trust establishment for = non-router nodes, right? SEND only talks about trust establishment for = routers. And, let=E2=80=99s be frank, doesn=E2=80=99t actually give us = enough operational guidance that we would expect what _is_ said to be = generally practicable.

= --Apple-Mail=_7951215C-D4FF-4301-B74D-C9BA0BA9FFB9-- From nobody Fri Jul 31 10:49:38 2020 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 DFF4B3A08C0; Fri, 31 Jul 2020 10:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kQjA9EQLTAK; Fri, 31 Jul 2020 10:49:30 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 798963A094E; Fri, 31 Jul 2020 10:49:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VHnRub014483; Fri, 31 Jul 2020 13:49:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596217769; bh=0HeIFexssBvjEa0C/1Tq2wlMYidJdoGooEvPe4dL4iA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=j5um7jXZjDvVPNSz8Rbx9aG+3ZpcyMTBRmLkzHxnKUbeQO+pQDsvyzM35j7FjQe2F As1NgazNKdVOP0Gg2ceEhm4beKOCRDIzEKW4himRa+mjJ8/yVP+52Bi0ZEzQRZQ1E/ wdqppdr6HloNy6F7s3TdOkHWHoT4ew4WkDrm9bzFSM7BXE0Hc0LDEk/34F+DXq2LJL 81pV/0xw/t1gUaXgC2xviqrTU1om6SBRse768viajfnFSk2PpSeiNhxljO0HxZlTCm 1EF6SRJf4XWMRKcpU/paawBmX2HHKqzmixFnoQngGzs+vZZDVt/j2Y21lHW8bP8Hww wTT44ShQKsUuw== Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VHnMHb014340 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 13:49:22 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 10:49:21 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 10:49:21 -0700 From: "Templin (US), Fred L" To: Ted Lemon CC: "Pascal Thubert (pthubert)" , "v6ops list" , 6man Thread-Topic: [EXTERNAL] Re: Improving ND security Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6gAO/XoAAA6T6+A= Date: Fri, 31 Jul 2020 17:49:21 +0000 Message-ID: References: <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com> In-Reply-To: <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 44E41B8A5AB2B01F63DA0CE9A729BFA215DE43D7C90C0ED4042290D4A1513AF72000:8 Content-Type: multipart/alternative; boundary="_000_b66ce3d9c75d4a39b5336dcdf9929411boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:49:32 -0000 --_000_b66ce3d9c75d4a39b5336dcdf9929411boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KDQpCeSDigJxOTeKAnSBJIHRoaW5rIHlvdSBtZWFuIOKAnE1vYmlsZSBOb2RlP+KA nSBUaGF04oCZcyBub3QgcmVhbGx5IG9uZSBvZiB0aGUgdXNlIGNhc2VzIHdl4oCZcmUgdGFsa2lu ZyBhYm91dCBoZXJlLiBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KWz5dDQpPciwganVzdCBj YWxsIGl0IGEgKG1vYmlsZSkg4oCcU3R1Yi1OZXR3b3Jr4oCdIOKAkyBJIHRoaW5rIHdlIGFyZSB0 YWxraW5nIGFib3V0IHRoZSBzYW1lDQp0aGluZyBoZXJlLg0KDQpJbiBhbnkgY2FzZSwgeW914oCZ cmUgcHJlc3VtaW5nIHNvbWUga2luZCBvZiB0cnVzdCBlc3RhYmxpc2htZW50IGZvciBub24tcm91 dGVyIG5vZGVzLCByaWdodD8gU0VORCBvbmx5IHRhbGtzIGFib3V0IHRydXN0IGVzdGFibGlzaG1l bnQgZm9yIHJvdXRlcnMuIEFuZCwgbGV04oCZcyBiZSBmcmFuaywgZG9lc27igJl0IGFjdHVhbGx5 IGdpdmUgdXMgZW5vdWdoIG9wZXJhdGlvbmFsIGd1aWRhbmNlIHRoYXQgd2Ugd291bGQgZXhwZWN0 IHdoYXQgX2lzXyBzYWlkIHRvIGJlIGdlbmVyYWxseSBwcmFjdGljYWJsZS4NCls+XQ0KT0ssIHRo ZSBzcGVjcyBJIGhhdmUgYmVlbiB3b3JraW5nIGRpcCB0aGVpciB0b2VzIGludG8gdGhlIFNFTkQg cG9vbCBidXQgbWF5YmUgdGhleQ0Kc2hvdWxkIGJlIHVwZGF0ZWQgdG8gZGl2ZSBpbiBjb21wbGV0 ZWx5PyBXaXRoIGFuIGFkb3B0aW9uIGNhbGwgaW4gcHJvZ3Jlc3MsIEkgZG9u4oCZdA0Ka25vdyBp ZiBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBtYWtlIGNoYW5nZXMgcmlnaHQgbm93IGJ1dCBi ZSBhc3N1cmVkIHRoYXQgaXQNCndpbGwgYmUgYWRkZWQgdG8gdGhlIFRPRE8gbGlzdCDigJMgd291 bGQgdGhhdCBiZSBhY2NlcHRhYmxlIGZvciBub3c/DQoNClRoYW5rcyAtIEZyZWQNCg0K --_000_b66ce3d9c75d4a39b5336dcdf9929411boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjojMUY0OTdEIj5IaSBUZWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Qnkg4oCcTk3igJ0gSSB0aGluayB5b3UgbWVhbiDigJxN b2JpbGUgTm9kZT/igJ0gVGhhdOKAmXMgbm90IHJlYWxseSBvbmUgb2YgdGhlIHVzZSBjYXNlcyB3 ZeKAmXJlIHRhbGtpbmcgYWJvdXQgaGVyZS4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+WyZndDtdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5PciwganVzdCBjYWxsIGl0IGEgKG1vYmlsZSkg4oCcU3R1Yi1OZXR3b3Jr4oCdIOKAkyBJ IHRoaW5rIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBzYW1lPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+dGhpbmcgaGVyZS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JbiBhbnkgY2FzZSwgeW914oCZcmUgcHJlc3Vt aW5nIHNvbWUga2luZCBvZiB0cnVzdCBlc3RhYmxpc2htZW50IGZvciBub24tcm91dGVyIG5vZGVz LCByaWdodD8gU0VORCBvbmx5IHRhbGtzIGFib3V0IHRydXN0IGVzdGFibGlzaG1lbnQgZm9yIHJv dXRlcnMuIEFuZCwgbGV04oCZcyBiZSBmcmFuaywgZG9lc27igJl0IGFjdHVhbGx5IGdpdmUgdXMg ZW5vdWdoIG9wZXJhdGlvbmFsDQogZ3VpZGFuY2UgdGhhdCB3ZSB3b3VsZCBleHBlY3Qgd2hhdCBf aXNfIHNhaWQgdG8gYmUgZ2VuZXJhbGx5IHByYWN0aWNhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bJmd0O10NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9LLCB0aGUgc3Bl Y3MgSSBoYXZlIGJlZW4gd29ya2luZyBkaXAgdGhlaXIgdG9lcyBpbnRvIHRoZSBTRU5EIHBvb2wg YnV0IG1heWJlIHRoZXk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zaG91bGQgYmUg dXBkYXRlZCB0byBkaXZlIGluIGNvbXBsZXRlbHk/IFdpdGggYW4gYWRvcHRpb24gY2FsbCBpbiBw cm9ncmVzcywgSSBkb27igJl0PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+a25vdyBp ZiBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBtYWtlIGNoYW5nZXMgcmlnaHQgbm93IGJ1dCBi ZSBhc3N1cmVkIHRoYXQgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj53aWxsIGJl IGFkZGVkIHRvIHRoZSBUT0RPIGxpc3Qg4oCTIHdvdWxkIHRoYXQgYmUgYWNjZXB0YWJsZSBmb3Ig bm93PzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b66ce3d9c75d4a39b5336dcdf9929411boeingcom_-- From nobody Fri Jul 31 10:56:07 2020 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 B1A463A0B73; Fri, 31 Jul 2020 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTnn6L898e97; Fri, 31 Jul 2020 10:56:02 -0700 (PDT) Received: from tools.si6networks.com (v6toolkit.go6lab.si [91.239.96.57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BB83A0B94; Fri, 31 Jul 2020 10:56:01 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b] (unknown [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tools.si6networks.com (Postfix) with ESMTPSA id 555A23FFE8; Fri, 31 Jul 2020 19:55:57 +0200 (CEST) To: Ted Lemon , "Templin (US), Fred L" Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> From: Fernando Gont Message-ID: <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> Date: Fri, 31 Jul 2020 13:58:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:56:05 -0000 On 31/7/20 13:12, Ted Lemon wrote: > On Jul 31, 2020, at 12:10 PM, Templin (US), Fred L > > wrote: >> */I like SEND, and it is written into my documents – is that enough of >> a push, or do I need/* >> */to do more aggressive marketing? Interested in helping?/* > > The push would have to be from somebody producing software that has > broad reach. And it would have to solve a real problem or nobody with > that reach would try to do it. > > Does it solve the problem Owen was talking about (overloading neighbor > tables as an attack)? No, it doesn't. > Is there agreement that this is a serious problem in any case? It is a problem... which seems to be more cost-effective solved with smaller prefixes for P2P links and/or better management of the neighbor cache (e.g. be more aggressive flushing/policing NC entries in the incomplete state). SEND seems to me like a nice idea, but overly complex for the problem it's trying to address. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Jul 31 11:45:14 2020 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 BC45A3A0CB8 for ; Fri, 31 Jul 2020 11:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPO8jFq7nE6D for ; Fri, 31 Jul 2020 11:45:10 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7513A0CB7 for ; Fri, 31 Jul 2020 11:45:10 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id s16so23699979qtn.7 for ; Fri, 31 Jul 2020 11:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ycQ7pLZsGWE4F30QFQUi3Uw42F517eZaIKTvxq+fws0=; b=Z9xiT3wHYu1Sc6FIWA42/ljdGOdxzZxbUvbJqyrsJUw86Frz/vAWyAKbIFOWQoIMCa T/Q/E6hIlMmqxNSJAJlDvBLvwn45/N9nRq8C2oFXbXXt9BOQcHKIEudDBlnZE8VCa9n9 BjAaAq4Wy8NxRd78SnSjsSCU2tQYZjC+bMIl2AeVlu7Z2vHGO56bZ39zCXc2eCybGhn0 Ul2JMsYSzmxwqzbqzRzuftyomlPGBZp3JtkKLLproU4ZEc2Ou2TnINabf2a7+1uoc2GI LWsfGmU3ifvchkOWwSlbm1K5FqvVn08TnxOls/X4Omy6xAoej/dLV48btLj2mXzfr/FR 3kMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ycQ7pLZsGWE4F30QFQUi3Uw42F517eZaIKTvxq+fws0=; b=dQPsXLPNclRDdhU3QePV39N1Y3R016ezYKWx3edtBn96Sar7QtMnmmfwWBBXvMTY5A sEopjhFeBGRinbbE/tAbiDMbWSdLGkk4bZ9MK9cbphOPL+iuz+4VD65UVvTGpg8r6T0l au74b4a6S7ro4cXB26VGGFqsuZjG090eHhvkKenlGZSoth6sgmJo4GhuiB7BwbDSEjy9 DgIoerrOAcpiEP2C0OmD2mUdtJ5PzKkVhWRz6Vuf0ytLvDC0svG39LWBcjUpRS7n4gqT Lmr1eiLuMAeHm0Tr7lM99dNZWGciFKlWBtcrkX3WrtD9gLfFPFibzWab2J8CPq7FhNpw FcCQ== X-Gm-Message-State: AOAM533OY1IX3y6Sh6VWDW1vgVIIhxEBmRl2Q98bpP1nJWiFgx2lFE4z F64rFTOVgqY17b6+Exk4gCx2a0diASr6/afCZcJP5A== X-Google-Smtp-Source: ABdhPJy94CZ7eiL1X92yYSCtZ4d5vJ2QR9S/Yf94Pd/PZjppvTkMXeTGXSh/i/wvDyuPEz59Wt2GrZj3qW1jF2Xfk8E= X-Received: by 2002:ac8:1788:: with SMTP id o8mr4851122qtj.330.1596221109261; Fri, 31 Jul 2020 11:45:09 -0700 (PDT) MIME-Version: 1.0 From: Joe Keenan Date: Fri, 31 Jul 2020 19:45:02 +0100 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000003358a405abc130e2" Archived-At: Subject: [v6ops] (no subject) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 18:45:12 -0000 --0000000000003358a405abc130e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 xblYesW6IMW5WHrFuiA3LOKCrHM1c3phYyAgLCxfDQo= --0000000000003358a405abc130e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9ImF1dG8iPsW5WHrFuiDFuVh6xbogNyzigqxzNXN6YWPCoCAsLF88L2Rpdj4NCg== --0000000000003358a405abc130e2-- From nobody Fri Jul 31 12:04:17 2020 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 5E86D3A044E; Fri, 31 Jul 2020 12:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrfQSMI0oIKQ; Fri, 31 Jul 2020 12:03:55 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A783A0476; Fri, 31 Jul 2020 12:03:10 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EFC7D8D4A161; Fri, 31 Jul 2020 19:03:08 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 3D9E4E707B7; Fri, 31 Jul 2020 19:03:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id S6f1v5dinMGa; Fri, 31 Jul 2020 19:03:06 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:582a:9aa7:5038:eec3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4E0E0E707AD; Fri, 31 Jul 2020 19:03:06 +0000 (UTC) From: "Bjoern A. Zeeb" To: "v6ops list" Cc: 6man Date: Fri, 31 Jul 2020 19:03:05 +0000 X-Mailer: MailMate (2.0BETAr6146) Message-ID: <88AD0E70-071A-4E51-AB4B-19F7F4571769@lists.zabbadoz.net> In-Reply-To: <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:03:58 -0000 On 31 Jul 2020, at 16:58, Fernando Gont wrote: >> Is there agreement that this is a serious problem in any case? > > It is a problem... which seems to be more cost-effective solved with = > smaller prefixes for P2P links and/or better management of the = > neighbor cache (e.g. be more aggressive flushing/policing NC entries = > in the incomplete state). I agree that there are quite a few intelligent things which can be done = on neighbour tables under attack to a certain level. People had this = discussions [felt] like a decade ago as well and they should be in the = archives. > SEND seems to me like a nice idea, but overly complex for the problem = > it's trying to address. It is these unbacked statements which people will use to reason against = it. =E2=80=9Ccomplex=E2=80=9D is not a cause unless it is backed by proper ar= guments. =E2=80=9Ctrust distribution=E2=80=9D is a thing, which doesn=E2=80=99t re= ally work in a = coffee shop around the corner. I do agree that SeND does not solve all the problems either but having = had it running since Ana Kukec (some might remember her from IETF) did = this in 2009/2010 for FreeBSD [1] we=E2=80=99ve been shipping a mixed = kernel/user space solution based on the DoCoMo NTT works which alos run = on Linux and others. People later produced WinSeND for Windows [2] and = their paper read a lot like Ana=E2=80=99s. I have no idea how the support for major OSes and router vendors is a = decade later, but I=E2=80=99d be curious if someone would do a proper sur= vey = and post the results. I think that would be super helpful (not as an = RFC, but as a =E2=80=9Cstate snapshot=E2=80=9D); could be a blog post or= a cloud = based spreadsheet somewhere. /bz [1] https://wiki.freebsd.org/SOC2009AnaKukec [2] = https://hpi.de/meinel/security-tech/next-generation-security-engineering/= ipv6-security/winsend.html = (I hope the link is good, I cannot currently reach their site) From nobody Fri Jul 31 12:21:22 2020 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 AE1123A0895; Fri, 31 Jul 2020 12:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFQXnpG7HHY9; Fri, 31 Jul 2020 12:21:08 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 7EC663A090B; Fri, 31 Jul 2020 12:21:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VJL38n008195; Fri, 31 Jul 2020 15:21:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596223264; bh=/ljDi5/CxBKW3bQtKtOqcAXPOVshKm6RVnuGuHWLthw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=m+v6JTFgMbM17q3o0RHdjS242Hq4X8WgcWMcWqofJNjk/hH0dYyGBGDiwbI8PAa6h A1JSbLUVxKPALtB62cY0d+3+uY4OmiHFOmGMQzci+pmhlzAQzdo7vCpPebrm2UMGH0 8OuRRaR4ZmBHQFEkb+MOqyx82lqCGzgP6rdEOhgp2h12g0/nZuDD6JSR4B80ULwZmi xP+5deAPWSj0xrgPKrDhViRWELBk2tk747iqhEcBsj8LQUTYKdrDhxam0QCLt+YwVP ry9sPBzY3Tb1ekXf3re4OrXaIdpagwSsOrN4d0GohBJveBJu7eozyTqsP+Rg3MlfXV Pj4GYztRHhijw== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VJKvok007069 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 15:20:58 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 12:20:56 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 12:20:56 -0700 From: "Templin (US), Fred L" To: Fernando Gont , Ted Lemon CC: "Pascal Thubert (pthubert)" , "v6ops list" , 6man Thread-Topic: [v6ops] [EXTERNAL] Improving ND security Thread-Index: AQHWZ1UXpJjqh6zAPESbZadyenD7WakiCyMEgAAE7IA= Date: Fri, 31 Jul 2020 19:20:56 +0000 Message-ID: References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> In-Reply-To: <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 59057C42C0DBDF620C3728EE1CEA5A0B26EC0F84CB81A7B8CA8FD2122BE88A792000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:21:16 -0000 RmVybmFuZG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmVybmFu ZG8gR29udCBbbWFpbHRvOmZlcm5hbmRvQGdvbnQuY29tLmFyXQ0KPiBTZW50OiBGcmlkYXksIEp1 bHkgMzEsIDIwMjAgOTo1OCBBTQ0KPiBUbzogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPjsg VGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydD00MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiA8aXB2NkBpZXRmLm9yZz4N Cj4gU3ViamVjdDogUmU6IFt2Nm9wc10gW0VYVEVSTkFMXSBJbXByb3ZpbmcgTkQgc2VjdXJpdHkN Cj4gDQo+IFRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQbGVh c2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNv Z25pemUgdGhlIHNlbmRlciBhbmQNCj4ga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+ IE9uIDMxLzcvMjAgMTM6MTIsIFRlZCBMZW1vbiB3cm90ZToNCj4gPiBPbiBKdWwgMzEsIDIwMjAs IGF0IDEyOjEwIFBNLCBUZW1wbGluIChVUyksIEZyZWQgTA0KPiA+IDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tIDxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KPiA+ PiAqL0kgbGlrZSBTRU5ELCBhbmQgaXQgaXMgd3JpdHRlbiBpbnRvIG15IGRvY3VtZW50cyDigJMg aXMgdGhhdCBlbm91Z2ggb2YNCj4gPj4gYSBwdXNoLCBvciBkbyBJIG5lZWQvKg0KPiA+PiAqL3Rv IGRvIG1vcmUgYWdncmVzc2l2ZSBtYXJrZXRpbmc/IEludGVyZXN0ZWQgaW4gaGVscGluZz8vKg0K PiA+DQo+ID4gVGhlIHB1c2ggd291bGQgaGF2ZSB0byBiZSBmcm9tIHNvbWVib2R5IHByb2R1Y2lu ZyBzb2Z0d2FyZSB0aGF0IGhhcw0KPiA+IGJyb2FkIHJlYWNoLiBBbmQgaXQgd291bGQgaGF2ZSB0 byBzb2x2ZSBhIHJlYWwgcHJvYmxlbSBvciBub2JvZHkgd2l0aA0KPiA+IHRoYXQgcmVhY2ggd291 bGQgdHJ5IHRvIGRvIGl0Lg0KPiA+DQo+ID4gRG9lcyBpdCBzb2x2ZSB0aGUgcHJvYmxlbSBPd2Vu IHdhcyB0YWxraW5nIGFib3V0IChvdmVybG9hZGluZyBuZWlnaGJvcg0KPiA+IHRhYmxlcyBhcyBh biBhdHRhY2spPw0KPiANCj4gTm8sIGl0IGRvZXNuJ3QuDQo+IA0KPiANCj4gPiBJcyB0aGVyZSBh Z3JlZW1lbnQgdGhhdCB0aGlzIGlzIGEgc2VyaW91cyBwcm9ibGVtIGluIGFueSBjYXNlPw0KPiAN Cj4gSXQgaXMgYSBwcm9ibGVtLi4uIHdoaWNoIHNlZW1zIHRvIGJlIG1vcmUgY29zdC1lZmZlY3Rp dmUgc29sdmVkIHdpdGgNCj4gc21hbGxlciBwcmVmaXhlcyBmb3IgUDJQIGxpbmtzIGFuZC9vciBi ZXR0ZXIgbWFuYWdlbWVudCBvZiB0aGUgbmVpZ2hib3INCj4gY2FjaGUgKGUuZy4gYmUgbW9yZSBh Z2dyZXNzaXZlIGZsdXNoaW5nL3BvbGljaW5nIE5DIGVudHJpZXMgaW4gdGhlDQo+IGluY29tcGxl dGUgc3RhdGUpLg0KWz5dIA0KDQoNClRoYXQgaXMgbm90IHRoZSBjYXNlIHdlIGFyZSBtZWFuaW5n IHRvIGFkZHJlc3MgaW4gdGhlIE9NTkkgc3BlYzsgdGhlDQpPTU5JIHNwZWMgbG9va3MgYXQgUDJN UCBsaW5rcyB3aXRoIG1hbnkgcHJvc3BlY3RpdmUgbmVpZ2hib3JzLiBXZQ0KbGlrZSBTRU5EIGZv ciB0aGlzIHVzZSBjYXNlLg0KDQpbPl0gDQo+IFNFTkQgc2VlbXMgdG8gbWUgbGlrZSBhIG5pY2Ug aWRlYSwgYnV0IG92ZXJseSBjb21wbGV4IGZvciB0aGUgcHJvYmxlbQ0KPiBpdCdzIHRyeWluZyB0 byBhZGRyZXNzLg0KWz5dIA0KDQpJdCBpcyBtb3JlIHRoYW4gYSBuaWNlIGlkZWE7IGl0IGlzIGEg a2V5IGVsZW1lbnQgdG8gdGhlIG5leHQtZ2VuZXJhdGlvbg0KKG1vYmlsZSkgSW50ZXJuZXQgYXJj aGl0ZWN0dXJlLg0KDQpUaGFua3MgLSBGcmVkDQoNCj4gVGhhbmtzLA0KPiAtLQ0KPiBGZXJuYW5k byBHb250DQo+IGUtbWFpbDogZmVybmFuZG9AZ29udC5jb20uYXIgfHwgZmdvbnRAc2k2bmV0d29y a3MuY29tDQo+IFBHUCBGaW5nZXJwcmludDogNzgwOSA4NEY1IDMyMkUgNDVDNyBGMUM5IDM5NDUg OTZFRSBBOUVGIEQwNzYgRkZGMQ0KPiANCj4gDQoNCg== From nobody Fri Jul 31 12:23:14 2020 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 A09823A0808; Fri, 31 Jul 2020 12:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTyBQLrIjaFq; Fri, 31 Jul 2020 12:23:09 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 2BA5A3A081C; Fri, 31 Jul 2020 12:22:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VJMgLE020925; Fri, 31 Jul 2020 15:22:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596223364; bh=6hK1GZ1NhyRZzdPN12rHaIpkQwKWj3AUPKQ9eRUCGGc=; h=From:To:CC:Subject:Date:From; b=AuGdpMP6Tt1ZaDI261Qf4ZaRsrKSk7TZnmUn3A8Y5eKfMApAXIuwGLGEUEGmHSLpU EtNuxRvjbeWSJtxEEbjQZ2ja356+zl6eoMoCvBRuFlUDpAkpDrObR2CPYug5CZDtnv k0VO6nWDIVsq9WfjevXFgCzNDWds4Xn3NgkrrcPLbq9Mpdn7fNFmae41+3+dYt3d75 rCo/ZBzLUQErlpFsdRrUOjsK6VxP692H/5uouaw136TPcRJSK67aAzunqrQmBBUTZz UbcR74BpdhQnKUBn7RsBxfP5QP2RUexI0qCIwW2dVo6KBL/GAWuYHAqF4KdLK6QiGd caPRbL+rPgI1w== Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VJMguj020913 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 15:22:42 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 12:22:40 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 12:22:40 -0700 From: "Templin (US), Fred L" To: "Bjoern A. Zeeb" , v6ops list CC: 6man Thread-Topic: [v6ops] Improving ND security Thread-Index: AdZnb9HwzApLuuqUTQWv8zR12jJtUg== Date: Fri, 31 Jul 2020 19:22:40 +0000 Message-ID: <5a0b92a370c8438ab8c0e318c3b60e34@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: BCF3A2B71E50AC4E6D05E1077F13522A9FCE8051784D120D9F11A3738225C0162000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:23:13 -0000 VGhpcyBpcyBhbGwgZ29vZCBkYXRhOyB0aGFuayB5b3UuIEkgZG9uJ3QgYnV5IHRoZSBhcmd1bWVu dCB0aGF0IFNFTkQgaXMgdG9vIGNvbXBsZXg7DQppbnN0ZWFkLCBJIHRoaW5rIGl0IHdhcyBzaW1w bHkgYSBzb2x1dGlvbiB0aGF0IHdhcyBhaGVhZCBvZiBpdHMgdGltZSwgYnV0IHBlcmhhcHMgaXRz DQp0aW1lIGhhcyBub3cgY29tZS4NCg0KRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCam9lcm4gQS4gWmVlYg0KPiBTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMjAgMTI6MDMg UE0NCj4gVG86IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KPiBDYzogNm1hbiA8aXB2NkBp ZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSW1wcm92aW5nIE5EIHNlY3VyaXR5DQo+ IA0KPiBPbiAzMSBKdWwgMjAyMCwgYXQgMTY6NTgsIEZlcm5hbmRvIEdvbnQgd3JvdGU6DQo+IA0K PiA+PiBJcyB0aGVyZSBhZ3JlZW1lbnQgdGhhdCB0aGlzIGlzIGEgc2VyaW91cyBwcm9ibGVtIGlu IGFueSBjYXNlPw0KPiA+DQo+ID4gSXQgaXMgYSBwcm9ibGVtLi4uIHdoaWNoIHNlZW1zIHRvIGJl IG1vcmUgY29zdC1lZmZlY3RpdmUgc29sdmVkIHdpdGgNCj4gPiBzbWFsbGVyIHByZWZpeGVzIGZv ciBQMlAgbGlua3MgYW5kL29yIGJldHRlciBtYW5hZ2VtZW50IG9mIHRoZQ0KPiA+IG5laWdoYm9y IGNhY2hlIChlLmcuIGJlIG1vcmUgYWdncmVzc2l2ZSBmbHVzaGluZy9wb2xpY2luZyBOQyBlbnRy aWVzDQo+ID4gaW4gdGhlIGluY29tcGxldGUgc3RhdGUpLg0KPiANCj4gSSBhZ3JlZSB0aGF0IHRo ZXJlIGFyZSBxdWl0ZSBhIGZldyBpbnRlbGxpZ2VudCB0aGluZ3Mgd2hpY2ggY2FuIGJlIGRvbmUN Cj4gb24gbmVpZ2hib3VyIHRhYmxlcyB1bmRlciBhdHRhY2sgdG8gYSBjZXJ0YWluIGxldmVsLiBQ ZW9wbGUgaGFkIHRoaXMNCj4gZGlzY3Vzc2lvbnMgW2ZlbHRdIGxpa2UgYSBkZWNhZGUgYWdvIGFz IHdlbGwgYW5kIHRoZXkgc2hvdWxkIGJlIGluIHRoZQ0KPiBhcmNoaXZlcy4NCj4gDQo+IA0KPiA+ IFNFTkQgc2VlbXMgdG8gbWUgbGlrZSBhIG5pY2UgaWRlYSwgYnV0IG92ZXJseSBjb21wbGV4IGZv ciB0aGUgcHJvYmxlbQ0KPiA+IGl0J3MgdHJ5aW5nIHRvIGFkZHJlc3MuDQo+IA0KPiBJdCBpcyB0 aGVzZSB1bmJhY2tlZCBzdGF0ZW1lbnRzIHdoaWNoIHBlb3BsZSB3aWxsIHVzZSB0byByZWFzb24g YWdhaW5zdA0KPiBpdC4NCj4g4oCcY29tcGxleOKAnSBpcyBub3QgYSBjYXVzZSB1bmxlc3MgaXQg aXMgYmFja2VkIGJ5IHByb3BlciBhcmd1bWVudHMuDQo+IOKAnHRydXN0IGRpc3RyaWJ1dGlvbuKA nSBpcyBhIHRoaW5nLCB3aGljaCBkb2VzbuKAmXQgcmVhbGx5IHdvcmsgaW4gYQ0KPiBjb2ZmZWUg c2hvcCBhcm91bmQgdGhlIGNvcm5lci4NCj4gDQo+IEkgZG8gYWdyZWUgdGhhdCBTZU5EIGRvZXMg bm90IHNvbHZlIGFsbCB0aGUgcHJvYmxlbXMgZWl0aGVyIGJ1dCBoYXZpbmcNCj4gaGFkIGl0IHJ1 bm5pbmcgc2luY2UgQW5hIEt1a2VjIChzb21lIG1pZ2h0IHJlbWVtYmVyIGhlciBmcm9tIElFVEYp IGRpZA0KPiB0aGlzIGluIDIwMDkvMjAxMCBmb3IgRnJlZUJTRCBbMV0gd2XigJl2ZSBiZWVuIHNo aXBwaW5nIGEgbWl4ZWQNCj4ga2VybmVsL3VzZXIgc3BhY2Ugc29sdXRpb24gYmFzZWQgb24gdGhl IERvQ29NbyBOVFQgd29ya3Mgd2hpY2ggYWxvcyBydW4NCj4gb24gTGludXggYW5kIG90aGVycy4g IFBlb3BsZSBsYXRlciBwcm9kdWNlZCBXaW5TZU5EIGZvciBXaW5kb3dzIFsyXSBhbmQNCj4gdGhl aXIgcGFwZXIgcmVhZCBhIGxvdCBsaWtlIEFuYeKAmXMuDQo+IA0KPiBJIGhhdmUgbm8gaWRlYSBo b3cgdGhlIHN1cHBvcnQgZm9yIG1ham9yIE9TZXMgYW5kIHJvdXRlciB2ZW5kb3JzIGlzIGENCj4g ZGVjYWRlIGxhdGVyLCBidXQgSeKAmWQgYmUgY3VyaW91cyBpZiBzb21lb25lIHdvdWxkIGRvIGEg cHJvcGVyIHN1cnZleQ0KPiBhbmQgcG9zdCB0aGUgcmVzdWx0cy4gIEkgdGhpbmsgdGhhdCB3b3Vs ZCBiZSBzdXBlciBoZWxwZnVsIChub3QgYXMgYW4NCj4gUkZDLCBidXQgYXMgYSDigJxzdGF0ZSBz bmFwc2hvdOKAnSk7ICBjb3VsZCBiZSBhIGJsb2cgcG9zdCBvciBhIGNsb3VkDQo+IGJhc2VkIHNw cmVhZHNoZWV0IHNvbWV3aGVyZS4NCj4gDQo+IC9ieg0KPiANCj4gDQo+IFsxXSBodHRwczovL3dp a2kuZnJlZWJzZC5vcmcvU09DMjAwOUFuYUt1a2VjDQo+IFsyXQ0KPiBodHRwczovL2hwaS5kZS9t ZWluZWwvc2VjdXJpdHktdGVjaC9uZXh0LWdlbmVyYXRpb24tc2VjdXJpdHktZW5naW5lZXJpbmcv aXB2Ni1zZWN1cml0eS93aW5zZW5kLmh0bWwNCj4gICAoSSBob3BlIHRoZSBsaW5rIGlzIGdvb2Qs IEkgY2Fubm90IGN1cnJlbnRseSByZWFjaCB0aGVpciBzaXRlKQ0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcN Cj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Fri Jul 31 12:31:41 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6423A081C; Fri, 31 Jul 2020 12:31:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <159622389491.12663.6529227245762732651@ietfa.amsl.com> Date: Fri, 31 Jul 2020 12:31:34 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:31:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Operational Implications of IPv6 Packets with Extension Headers Authors : Fernando Gont Nick Hilliard Gert Doering Warren Kumari Geoff Huston Will (Shucheng) Liu Filename : draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt Pages : 16 Date : 2020-07-31 Abstract: This document summarizes the operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 31 12:41:05 2020 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 09E9F3A0898; Fri, 31 Jul 2020 12:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcCucc23fzo6; Fri, 31 Jul 2020 12:40:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 200463A0861; Fri, 31 Jul 2020 12:40:56 -0700 (PDT) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AE8EA7DB3417B7EE5234; Fri, 31 Jul 2020 20:40:52 +0100 (IST) Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 31 Jul 2020 20:40:52 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 31 Jul 2020 22:40:51 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 31 Jul 2020 22:40:51 +0300 From: Vasilenko Eduard To: Ted Lemon CC: Tony Finch , Owen DeLong , "Pascal Thubert (pthubert)" , v6ops list , 6man Thread-Topic: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns Thread-Index: AdZl2/KmEr6Lt/NERGGqFiMA7k1/CAAIPvAAABH5AHD///P/gP//vOiggAECawCAABGlgIABGVqAgAAEyoCAAAv7AP//vkZQgABVPwD//6zUYA== Date: Fri, 31 Jul 2020 19:40:51 +0000 Message-ID: <16f520d2e6144de38303c7a9e6a2bc23@huawei.com> References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <4f29ab2dd1a0467791d9304d85369f75@huawei.com> <80FADCA7-8CB3-486F-A679-B747413831D6@fugue.com> In-Reply-To: <80FADCA7-8CB3-486F-A679-B747413831D6@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.204.150] Content-Type: multipart/alternative; boundary="_000_16f520d2e6144de38303c7a9e6a2bc23huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:40:58 -0000 --_000_16f520d2e6144de38303c7a9e6a2bc23huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KSSBkbyBub3QgdW5kZXJzdGFuZCB5b3UuDQoNCg0KWW91IGRpZCBjb3B5IG15IGNv bW1lbnQgdGhhdCB3YXMgcmVsYXRlZCB0byB0aGUgY2FwYWJpbGl0eSBvZiBHUkFORCB0byBhbGxl dmlhdGUgTkQgZXhoYXVzdGlvbiBhdHRhY2tzLiBJdCB3YXMgc2VwYXJhdGUgY29tbWVudCBmcm9t IFRvbnkgRmluY2guDQoNCkkgY291bGQgcmVwZWF0IGFnYWluOiBubywgaXQgd291bGQgbm90IGhl bHAgYWdhaW5zdCB0aGlzIHR5cGUgb2YgYXR0YWNrLCBldmVuIGlmIGl0IHdvdWxkIGJlIHNsaWdo dGx5IG1vZGlmaWVkLg0KDQpCdXQgRG9TIGlzIG5vdCBleHRyZW1lbHkgYmlnIHByb2JsZW0g4oCT IGl0IHdhcyBub3QgbXkgY29uY2Vybi4gVGhpcyBjb25jZXJuIGhhcyBiZWVuIG1lbnRpb25lZCBi eSBtYW55IG90aGVyIHBlb3BsZSBpbiB0aGlzIHRocmVhZCwgYnV0IG5vdCBtZS4gVGhpcyBwcm9i bGVtIGlzIG5vdCBnb29kIHRvbywgYnV0IEkgY291bGQgdG9sZXJhdGUgaXQgKGF0IGxlYXN0IEkg YW0gcmVhZHkgdG8gdHJhZGUtb2ZmIGl0IGZvciBwZXJmb3JtYW5jZSkuDQoNCkxlYWthZ2Ugb2Yg aW5mb3JtYXRpb24gaXMgbXVjaCBiaWdnZXIgcHJvYmxlbSB0aGF0IEkgY291bGQgbm90IHRvbGVy YXRlLg0KDQpNYXkgYmUgeW91IGFyZSBhc2tpbmcgbWUgYWJvdXQgR1JBTkQgaW4gZ2VuZXJhbCwN CnRoZW4gbm8gLSBJIGRvIG5vdCB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBpZGVhIHRvIGV4cGFu ZCBmdW5jdGlvbmFsaXR5IHVzaW5nIHRoZSBtb3N0IHZhbHVhYmxlIGZlYXR1cmUgb2YgTkQgKFVu c29saWNpdGVkIE5BKS4NClVuc29saWNpdGVkIE5BIGlzIHZlcnkgZWFzeSB0byBjcmVhdGUgYSBs ZWFrYWdlIG9mIGluZm9ybWF0aW9uLiBJTUhPOiBpdCBpcyB1bmFjY2VwdGFibGUgcHJvYmxlbSB0 aGF0IHNob3VsZCBiZSBmaXhlZCBmaXJzdC4NCklmIFVuc29saWNpdGVkIE5BIHdvdWxkIGJlIGNo YW5nZWQgYXMgYSByZXN1bHQgb2Ygc3VjaCBORCBtb2RpZmljYXRpb24g4oCTIHRoZW4gR1JBTkQg d291bGQgYmUgYmFzZWQgb24gbmV3IHZlcnNpb24gb2YgTkQuDQoNCkVkdWFyZA0KRnJvbTogVGVk IExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NClNlbnQ6IDMxINC40Y7Qu9GPIDIwMjAg 0LMuIDIwOjIzDQpUbzogVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWku Y29tPg0KQ2M6IFRvbnkgRmluY2ggPGRvdEBkb3RhdC5hdD47IE93ZW4gRGVMb25nIDxvd2VuQGRl bG9uZy5jb20+OyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydD00MGNpc2NvLmNv bUBkbWFyYy5pZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiA8aXB2 NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Nm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uY2VybnMNCg0KT24gSnVsIDMx LCAyMDIwLCBhdCAxOjIwIFBNLCBWYXNpbGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1 YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4+IHdyb3RlOg0KKDIp IE9ubHkgYnkgc2VwYXJhdGUgYWRtaW4gY29uZmlndXJhdGlvbiBvbiByb3V0ZXIsIHRoZW4gaXQg aXMgb3BlcmF0aW9uYWwgcHJhY3RpY2UuIE5vIG5lZWQgZm9yIHN0YW5kYXJkaXphdGlvbi4NCg0K SSB0aGluayBJIGV4cGxhaW5lZCB3aHkgaXQgd2FzIHdvcnRoIHN0YW5kYXJkaXppbmcgZnJvbSBt eSBwZXJzcGVjdGl2ZS4gUGVyaGFwcyB5b3UgZGlzYWdyZWUgd2l0aCB0aGF0IHBlcnNwZWN0aXZl LCBidXQgeW91IGhhdmVu4oCZdCBzYWlkIHdoeS4gICBUaGUgd2F5IHlvdSBzYXkgdGhpcyBtYWtl cyBpdCBzb3VuZCBsaWtlIHlvdSB0aGluayB0aGVyZeKAmXMgYSBkb3duc2lkZSB0byBzdGFuZGFy ZGl6aW5nLiAgQ2FuIHlvdSBleHBsYWluIHdoYXQgdGhhdCBkb3duc2lkZSBpcz8NCg0K --_000_16f520d2e6144de38303c7a9e6a2bc23huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRlZCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3QgdW5kZXJzdGFuZCB5b3UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Zb3UgZGlkIGNvcHkgbXkgY29tbWVudCB0aGF0 IHdhcyByZWxhdGVkIHRvIHRoZSBjYXBhYmlsaXR5IG9mIEdSQU5EIHRvIGFsbGV2aWF0ZSBORCBl eGhhdXN0aW9uIGF0dGFja3MuIEl0IHdhcyBzZXBhcmF0ZSBjb21tZW50IGZyb20gVG9ueSBGaW5j aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+SSBjb3VsZCByZXBlYXQgYWdhaW46IG5vLCBpdCB3b3VsZCBu b3QgaGVscCBhZ2FpbnN0IHRoaXMgdHlwZSBvZiBhdHRhY2ssIGV2ZW4gaWYgaXQgd291bGQgYmUg c2xpZ2h0bHkgbW9kaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJ1dCBEb1MgaXMgbm90IGV4dHJl bWVseSBiaWcgcHJvYmxlbSDigJMgaXQgd2FzIG5vdCBteSBjb25jZXJuLiBUaGlzIGNvbmNlcm4g aGFzIGJlZW4gbWVudGlvbmVkIGJ5IG1hbnkgb3RoZXIgcGVvcGxlIGluIHRoaXMgdGhyZWFkLCBi dXQgbm90IG1lLiBUaGlzIHByb2JsZW0gaXMgbm90IGdvb2QgdG9vLCBidXQgSSBjb3VsZCB0b2xl cmF0ZSBpdCAoYXQgbGVhc3QNCiBJIGFtIHJlYWR5IHRvIHRyYWRlLW9mZiBpdCBmb3IgcGVyZm9y bWFuY2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MZWFrYWdlIG9mIGluZm9ybWF0aW9uIGlzIG11Y2gg YmlnZ2VyIHByb2JsZW0gdGhhdCBJIGNvdWxkIG5vdCB0b2xlcmF0ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1heSBiZSB5b3UgYXJlIGFza2luZyBtZSBhYm91 dCBHUkFORCBpbiBnZW5lcmFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGVuIG5vIC0gSSBkbyBub3Qg dGhpbmsgdGhhdCBpdCBpcyBhIGdvb2QgaWRlYSB0byBleHBhbmQgZnVuY3Rpb25hbGl0eSB1c2lu ZyB0aGUgbW9zdCB2YWx1YWJsZSBmZWF0dXJlIG9mIE5EIChVbnNvbGljaXRlZCBOQSkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlVuc29saWNpdGVkIE5BIGlzIHZlcnkgZWFzeSB0byBjcmVhdGUgYSBsZWFr YWdlIG9mIGluZm9ybWF0aW9uLiBJTUhPOiBpdCBpcyB1bmFjY2VwdGFibGUgcHJvYmxlbSB0aGF0 IHNob3VsZCBiZSBmaXhlZCBmaXJzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgVW5zb2xpY2l0ZWQg TkEgd291bGQgYmUgY2hhbmdlZCBhcyBhIHJlc3VsdCBvZiBzdWNoIE5EIG1vZGlmaWNhdGlvbiDi gJMgdGhlbiBHUkFORCB3b3VsZCBiZSBiYXNlZCBvbiBuZXcgdmVyc2lvbiBvZiBORC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IDMxINC40Y7Qu9GPIDIwMjAg0LMuIDIwOjIzPGJyPg0KPGI+VG86PC9iPiBWYXNpbGVua28g RWR1YXJkICZsdDt2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBUb255IEZpbmNoICZsdDtkb3RAZG90YXQuYXQmZ3Q7OyBPd2VuIERlTG9uZyAmbHQ7b3dlbkBk ZWxvbmcuY29tJmd0OzsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7cHRodWJlcnQ9NDBj aXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyB2Nm9wcyBsaXN0ICZsdDt2Nm9wc0BpZXRmLm9y ZyZndDs7IDZtYW4gJmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1ncmFuZC0wMSAtIGFkZGl0aW9u YWwgc2VjdXJpdHkgY29uY2VybnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBKdWwgMzEsIDIwMjAsIGF0IDE6MjAgUE0sIFZhc2lsZW5rbyBFZHVhcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20iPnZhc2lsZW5r by5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPigyKSBPbmx5 IGJ5IHNlcGFyYXRlIGFkbWluIGNvbmZpZ3VyYXRpb24gb24gcm91dGVyLCB0aGVuIGl0IGlzIG9w ZXJhdGlvbmFsIHByYWN0aWNlLiBObyBuZWVkIGZvciBzdGFuZGFyZGl6YXRpb24uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgSSBleHBsYWluZWQgd2h5IGl0IHdhcyB3b3J0aCBzdGFuZGFyZGl6aW5nIGZy b20gbXkgcGVyc3BlY3RpdmUuIFBlcmhhcHMgeW91IGRpc2FncmVlIHdpdGggdGhhdCBwZXJzcGVj dGl2ZSwgYnV0IHlvdSBoYXZlbuKAmXQgc2FpZCB3aHkuICZuYnNwOyBUaGUgd2F5IHlvdSBzYXkg dGhpcyBtYWtlcyBpdCBzb3VuZCBsaWtlIHlvdSB0aGluayB0aGVyZeKAmXMgYSBkb3duc2lkZSB0 byBzdGFuZGFyZGl6aW5nLiAmbmJzcDtDYW4NCiB5b3UgZXhwbGFpbiB3aGF0IHRoYXQgZG93bnNp ZGUgaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_16f520d2e6144de38303c7a9e6a2bc23huaweicom_-- From nobody Fri Jul 31 12:43:57 2020 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 3F1653A0796; Fri, 31 Jul 2020 12:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPpwWwrIMrmP; Fri, 31 Jul 2020 12:43:54 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4A63A0861; Fri, 31 Jul 2020 12:43:53 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b] (unknown [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1B3B9283A3E; Fri, 31 Jul 2020 19:43:49 +0000 (UTC) To: "Bjoern A. Zeeb" , v6ops list Cc: 6man References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> <88AD0E70-071A-4E51-AB4B-19F7F4571769@lists.zabbadoz.net> From: Fernando Gont Message-ID: <0c73e349-32aa-1fc6-79d3-7822c24f44e9@si6networks.com> Date: Fri, 31 Jul 2020 16:30:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <88AD0E70-071A-4E51-AB4B-19F7F4571769@lists.zabbadoz.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:43:56 -0000 On 31/7/20 16:03, Bjoern A. Zeeb wrote: [...] >> SEND seems to me like a nice idea, but overly complex for the problem >> it's trying to address. > > It is these unbacked statements which people will use to reason against it. > “complex” is not a cause unless it is backed by proper arguments. > “trust distribution” is a thing, which doesn’t really work in a coffee > shop around the corner. SEND implies the use of a PKI. That's non-trivial. Besides, the expectations for IPv6 are similar to those for IPv4. Somehow folks have been able to secure the ipv4 first-hop (when/where needed) without the need of understanding something like SEND, or going through the hassle of deploying it. So the question "Why do I need this for IPv6 when I never required it for IPv4?" may not an easy one to respond. [...] > I have no idea how the support for major OSes and router vendors is a > decade later, but I’d be curious if someone would do a proper survey and > post the results.  I think that would be super helpful (not as an RFC, > but as a “state snapshot”);  could be a blog post or a cloud based > spreadsheet somewhere. I don't seem to remember any major OS that ships with SEND enabled by default -- e.g., that configures CGAs over traditional SLAAC or RFC7217. Additionally (and ironically), the use of IPv6 EHs tends to be rather unfriendly to first-hop security. [....] > [2] > https://hpi.de/meinel/security-tech/next-generation-security-engineering/ipv6-security/winsend.html >  (I hope the link is good, I cannot currently reach their site) The link is good. However, it claims "Download: Not available for public yet!" Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jul 31 12:55:27 2020 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 D84643A0836; Fri, 31 Jul 2020 12:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wlnr8nBTfpz; Fri, 31 Jul 2020 12:55:18 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 4C70F3A07F5; Fri, 31 Jul 2020 12:55:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VJtEuR007624; Fri, 31 Jul 2020 15:55:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596225315; bh=HViah2sTSr7DNvrB/YhL+iRkTYe0PIkcdOGdWpl4EB4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=dcv49BOk+qg0Llwqz5SUrGjtkye7tP77jihVN7T3K9oIlDCxAPKZd8BzFhia0XD+N avH2vNZbjyt5PDt63OwGb85zPvGs0Q3nS5wBuu/O3AnV/bMQ4mdHSBJfyu7F9fhcnt 4CtbzfIVv6sk4sCjGEiTq72WSFUIVZVwO2zEWEcRDI4o8jlspYL9ZPhYoKPOvyseeg eor61/nqvqG15+zryuDWAFmtjcTwLvBDV9B9JaF53ZyxVjfy7zQa4A8XS7m2Hxc13U ljtL3ZakRLA8WX7qP8G0jYQCC5Bo4d6kaE4kD3SKHnEcpSM9HR97CnWt1lZ5VAFw1S BT/T/O1rEL5Qg== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VJt59I006419 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 15:55:05 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 12:55:04 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 12:55:04 -0700 From: "Templin (US), Fred L" To: Fernando Gont , "Bjoern A. Zeeb" , v6ops list CC: 6man Thread-Topic: [v6ops] [EXTERNAL] Improving ND security Thread-Index: AQHWZ1UXpJjqh6zAPESbZadyenD7WakiF1W3gAACAVA= Date: Fri, 31 Jul 2020 19:55:04 +0000 Message-ID: <8c4b0bf58d694ee3ad84e98d9dc3427d@boeing.com> References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar> <88AD0E70-071A-4E51-AB4B-19F7F4571769@lists.zabbadoz.net> <0c73e349-32aa-1fc6-79d3-7822c24f44e9@si6networks.com> In-Reply-To: <0c73e349-32aa-1fc6-79d3-7822c24f44e9@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 43F210DA7BBA5DFE25AD63B39A716773882CC5310212287CF05E8FE4A02606882000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 19:55:20 -0000 RmVybmFuZG8sDQoNCj4gQmVzaWRlcywgdGhlIGV4cGVjdGF0aW9ucyBmb3IgSVB2NiBhcmUgc2lt aWxhciB0byB0aG9zZSBmb3IgSVB2NC4NCj4gU29tZWhvdyBmb2xrcyBoYXZlIGJlZW4gYWJsZSB0 byBzZWN1cmUgdGhlIGlwdjQgZmlyc3QtaG9wICh3aGVuL3doZXJlDQo+IG5lZWRlZCkgd2l0aG91 dCB0aGUgbmVlZCBvZiB1bmRlcnN0YW5kaW5nIHNvbWV0aGluZyBsaWtlIFNFTkQsIG9yIGdvaW5n DQo+IHRocm91Z2ggdGhlIGhhc3NsZSBvZiBkZXBsb3lpbmcgaXQuIFNvIHRoZSBxdWVzdGlvbiAi V2h5IGRvIEkgbmVlZCB0aGlzDQo+IGZvciBJUHY2IHdoZW4gSSBuZXZlciByZXF1aXJlZCBpdCBm b3IgSVB2ND8iIG1heSBub3QgYW4gZWFzeSBvbmUgdG8gcmVzcG9uZC4NCls+XSANCg0KV2UgYXJl IGVuZ2luZWVyaW5nIGZvciBhIG5ldyBsaW5rIG1vZGVsICh0aGUgT01OSSBsaW5rKSB3aGljaCB3 YXMgbm90IHByZXZpb3VzbHkNCnVzZWQuIFRoZSBsaW5rIG1vZGVsIGNhbiBzdXBwb3J0IGJvdGgg SVB2NCBhbmQgSVB2NiBub2RlcywgYnV0IGJvdGggY2FuIHVzZSBTRU5ELg0KDQpBZ2Fpbiwgd2Ug YXJlIGF0IHRoZSBkYXduaW5nIG9mIGEgbmV3IGVyYSB3aGVyZSBTRU5EIG1heSBmaW5hbGx5IGZp bmQgaXRzIHVzZS4NCg0KRnJlZA0K From nobody Fri Jul 31 13:54:19 2020 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 2460F3A0BD7; Fri, 31 Jul 2020 13:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyhmkAc12TSJ; Fri, 31 Jul 2020 13:53:37 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B7C213A0BCE; Fri, 31 Jul 2020 13:53:36 -0700 (PDT) Received: from [IPv6:2620::930:0:11e4:d8eb:346c:c2b8] ([IPv6:2620:0:930:0:11e4:d8eb:346c:c2b8]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 06VKrSTo3063342 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 13:53:28 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 06VKrSTo3063342 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1596228811; bh=8XEVuV0+mkm0tzpUnyZYWioW8douCkmddhFRH2nLaPc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=o+kBh5CbzF+hM6KOUYdTtl/RXXS4d0gZ4DWB+ZsJyPReFfhzplqdyEmpmBzvKFWIM qaNF0FahHAysFoxa0geKIGW2dQxyw2D/5X2mllnsfdy1heez4N7ct/tQ6Ozv6RBGsm LdiG4SRbPt2NTLOAQquswex2R3Gal1ap9B+N8WBU= From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_99086095-4D45-4A67-A75A-0F3BD7991C2A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jul 2020 13:53:28 -0700 In-Reply-To: <94D12FD5-3A0A-4278-A229-F0D88EC906D6@fugue.com> Cc: "Pascal Thubert (pthubert)" , v6ops list , 6man To: Ted Lemon References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <94D12FD5-3A0A-4278-A229-F0D88EC906D6@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 31 Jul 2020 13:53:31 -0700 (PDT) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 20:53:38 -0000 --Apple-Mail=_99086095-4D45-4A67-A75A-0F3BD7991C2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 31, 2020, at 08:43 , Ted Lemon wrote: >=20 > On Jul 31, 2020, at 11:30 AM, Owen DeLong > wrote: >> 1. Public wifi networks (e.g. coffee houses, etc.) >=20 > The BCP for this case is to isolate clients. That doesn=E2=80=99t prevent layer 2 attacks against the switch or = router. >=20 >> 2. College/University settings (some v6 traction here, but often = not on student-device accessible LANs) >=20 > For this it would be to give each dorm room its own subnet. This doesn=E2=80=99t cover networks in public areas used by students = (e.g. quads, cafeterias, student union, etc.). >=20 >> 3. Other networks which must admit untrusted clients/devices >=20 > E.g. home networks? Or something else? >=20 Something else. I don=E2=80=99t know of a home where one is required to = admit untrusted clients onto their network. Owen --Apple-Mail=_99086095-4D45-4A67-A75A-0F3BD7991C2A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 31, 2020, at 08:43 , Ted Lemon <mellon@fugue.com> = wrote:

On Jul 31, 2020, at = 11:30 AM, Owen DeLong <owen@delong.com> wrote:
1. Public = wifi networks (e.g. coffee houses, etc.)

The BCP for this case is = to isolate clients.

That doesn=E2=80=99t prevent layer 2 attacks against = the switch or router.


2. College/University settings (some = v6 traction here, but often not on student-device accessible = LANs)

For this it would be to give each dorm room its own = subnet.

This= doesn=E2=80=99t cover networks in public areas used by students (e.g. = quads, cafeterias, student union, etc.).


3. = Other networks which must admit untrusted = clients/devices

E.g. home networks? Or something else?

Something else. I don=E2=80=99t know of a home = where one is required to admit untrusted clients onto their = network.

Owen


= --Apple-Mail=_99086095-4D45-4A67-A75A-0F3BD7991C2A-- From nobody Fri Jul 31 14:47:20 2020 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 7B7623A0C55; Fri, 31 Jul 2020 14:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KATYn7kn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DtT+I62D Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaCcU_4Y3nBx; Fri, 31 Jul 2020 14:47:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34DA3A0C54; Fri, 31 Jul 2020 14:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10897; q=dns/txt; s=iport; t=1596232035; x=1597441635; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LW+Xd43ArDh/uW1eACNfVVPGn4g8rOMiRlefgh6px/0=; b=KATYn7kni1KEkG9xdih+OVrDPv2yB5v8aphYviIYtdN03KfgpX6GDdYI yDaoCCg0R9C7Qy8ivoJJvv438RHi5y6LACnx1AHce53NchUfxVNk4jaM4 IkHOy9UWiO9G/h+bMcNTicLRYGxm1rMC/ePvavHYxcb1HeEP8Y/TWw1jF k=; IronPort-PHdr: =?us-ascii?q?9a23=3ACmymtRNhxPumlbrCwNol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lHUUpjWrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtbBcnjahvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeDQAZkCRf/5xdJa1gHgEBCxIMgy0?= =?us-ascii?q?vUQeBRy8shDWDRgONK5QbhGyCUwNVCwEBAQwBAS0CBAEBhEwCF4IcAiQ4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBG2FXAyFcgIEEhEKEwEBNwEPAgEGAkICAgIwJQEBBA4?= =?us-ascii?q?FIoMEgX9NAy4BlhiQaAKBOYhhdoEygwEBAQWCSoJSGIIOCYE4gnCCUktCgjq?= =?us-ascii?q?BOoJLGoFBP4ERJwwQgk0+hEuDCDOCLY9ggxOGXYtYkGYKgmCaBAMen3etIYQ?= =?us-ascii?q?lAgQCBAUCDgEBBYFqI4FXcBU7KgGCPlAXAg2OHwwXg06KVnQCNQIGAQcBAQM?= =?us-ascii?q?JfI9nAQE?= X-IronPort-AV: E=Sophos;i="5.75,419,1589241600"; d="scan'208,217";a="806027021" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jul 2020 21:47:14 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 06VLlEVu003134 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jul 2020 21:47:14 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 16:47:14 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 16:47:14 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 16:47:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RkqiE7do/JGqD+g9UraY+CeM16qpFnWdLbqm9bIHFKIJXABmOFnIcQKNNIZBqQ7Atk2OuBziZrbPY/tEwLlU+OaCMuCLumDGcgM6t3i2QMvPbCYFKzG2NFgoow6Fa1LiMuyJnFyxa+4++JiLjggXNa10VTLXeXDGr4CEQxsOjUemC+bgKZBeFJcPtfCQRWN++d2qaWcKu12XqHMNG7umbCTa3GqBfy9pOYaTznWrsOAdqoOq/5egxuSzNnhWRIW1bF2O/LB5lUq76Hn22kJRRlo2Oe1d2ggPb2kPa9M5Rfxy6HypHIuKyTWDpVw90zzpabBE9iAmhKU7W52IjNKuAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LW+Xd43ArDh/uW1eACNfVVPGn4g8rOMiRlefgh6px/0=; b=aulriJqErJplN+ognLXncxk9ScXR/Ad5IhKXMC4wl+QU9O0LfFVymsetChA32OHjgCDhgnshgtjfaWsnedMRckgme2/6DJb7ufBFcWGdjgPnI5UCLqGSpcQA8lVF1hEu3hkthF6DVYdjswYD4Ds3qeDNPcNqBuSm9N0a8KpySo3fv6+9PcEO97kBgPu7vjk5gcBS+BgHR8tlFt3Kq681KNP9s4b9zkL2XIEGqge/kXzAPpuAKkdbEsVX3Nb4W+3WpSVQQpGTwFZqB9EXrJ3sA0IWYRgc0DlrcQHSWo+D5kD7sdw02zeBJtVeUwKdikikcNM7zDDOUobLWvm+xYWj+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LW+Xd43ArDh/uW1eACNfVVPGn4g8rOMiRlefgh6px/0=; b=DtT+I62DBRj3ncKZ4tpvgh98Odfob/m01g6TbeNGh/QSgaIFKYiOb/9kggDfNwTZ/uMECrGoNh1cMpiJA+bSpBS3q6h/U+HUFzHDT/NbZ0Yccj5xly9mAyM4iVNYeA7arvY5uc79X2jtYjdwRHicMrKNcrtIc64iS/rRht70854= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3726.namprd11.prod.outlook.com (2603:10b6:208:ef::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Fri, 31 Jul 2020 21:47:13 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::a53e:5801:92cc:3204]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::a53e:5801:92cc:3204%5]) with mapi id 15.20.3239.020; Fri, 31 Jul 2020 21:47:13 +0000 From: "Pascal Thubert (pthubert)" To: "Templin (US), Fred L" CC: Ted Lemon , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: Improving ND security Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6gAAUmIAAABNVoAACE6vdg== Date: Fri, 31 Jul 2020 21:47:13 +0000 Message-ID: <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com> References: <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:d36:e0ed:810e:7901] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 586c6df4-1ccc-4747-bd33-08d8359b48e8 x-ms-traffictypediagnostic: MN2PR11MB3726: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HeXUngqCciGdNbxFPqRhbCcaPMB/fWCfDY5oo4XNyl2Skz5c+3cUgAlHqv3lWgAoonDEYNjhD0lobgYO0tzJ7x+mXZyIX1QsCmIKmjvzI3aSD+0RKaxI8+pA406qKDqAqA0T9hz5hkPJNSF6QG5jMLrW3xkEScxTXV8BGIEgBVukxz6pEZhOsFOuN0gS5zwv9vFB2iZsdSVe3/NUZWfhIGaQvyrXCnQcgyP+ZwZIGg/OhcawKoi8cAaYH6dEAwYYVj6khDI3wLFzCan+wrCdLc5r4XkhcQqncZf05qQndBz5IZuSwQioSQmW6RiNftc3KaQ+ZDU7SjEkS8jAwnBtPDq9DefjHo4NfVZlE4ehF7/eJ7bPGPHDubad7KH3qTW5 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(396003)(366004)(376002)(346002)(186003)(2906002)(8936002)(66574015)(76116006)(91956017)(83380400001)(6506007)(33656002)(64756008)(66446008)(66556008)(66476007)(15650500001)(66946007)(8676002)(2616005)(478600001)(71200400001)(6916009)(5660300002)(6486002)(316002)(36756003)(54906003)(4326008)(6512007)(86362001)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fbqnhXhaYd+FEJJk4F6OereRLI20yv8ztwT6YJWn7fssi42Q8uVnAyb/5lhHpETkBhDHyGTrhc8WzTAIJRZQ/4Wv+mlSapHJMQSmJM0TjRJQYTEMFn63KAwNpUAU6agT7fBMgd10zAjqfLr94siaLccOHRa6aZOWAQI/M4+2NJmmJ4h1/tfBv+0hIH69/+GNwo23EAiflo/Iz9UbbDe4n1B5dAEei5417VzoEotl0OEXgMVexxaYVukfEz6BLM3pMjziv4yg67qdgbjthBSk2ykh7b0FRloWjX6oTuaHrSd0Zxxx/+LVW6IZD3Aq+7KJk7E4bQizXJ/tgv+CL7P/AccmqmLr6BNtkLvlo/x9rTz0Wxz13C/8X1Lr4LpPY7OiVC4nABwMcBDIjHjeGGqLE0notwCve3D6253aaKY1H9WDAdSoedqg8bX974BoAzSZzVM0cz/gt67RQMDCFIAChP4c6kcAWj2s54QZTJ3wZ3HIZ9mNY8fDEEi9l3OR7CFQ4qi5wnc2uSjCIoJ+fKqCBtMCFIaYhC269rs0v3TczO3hp6G+vmvA+85+ahVyN5b5NY4CcQZ5hDoF0ZRVxHNwWzN7s4oFoKfeOoqY+9vbCGgZyFVjE6S71b5YBRWrUZpPSlw+S5B9UrYNnstaa1IoQWPvQpHbtCff8/Pvc74GHEywV3151nOCQEMJ6rRiVvq8RrzbxukRvfI+QpGMR8sBXA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0DDEBA6C393340FCBB9C33FA59DC9D76ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 586c6df4-1ccc-4747-bd33-08d8359b48e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 21:47:13.0801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x6I3JMAGpEsqVCqfuPfSGZzVJkGbeyYweClbEG1WW6QwNEYVEDzdnX5VzL4OnYZluH4YJDRykbhClC5zYn1ODA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3726 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 21:47:19 -0000 --_000_0DDEBA6C393340FCBB9C33FA59DC9D76ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRnJlZA0KDQpBIG1ham9yIGF0dGFjayB2ZWN0b3IgaXMgYW4gZXh0ZXJuYWwgYXR0YWNr ZXIgc2VuZGluZyBwYWNrZXRzIHRvIHRoZSAyXjY0IG9yIHNvIHBvc3NpYmxlIGFkZHJlc3NlcyBp biB0aGUgc3VibmV0LiBUaGUgYXR0YWNrIGNhdXNlcyBhIGRlbmlhbCBvZiBzZXJ2aWNlIGF0IHRo ZSByb3V0ZXIgdGhhdCBNVVNUIHN0b3JlIG9uZSBwYWNrZXQgZm9yIG9uZSBzZWNvbmQgYW5kIG11 bHRpY2FzdCBhIE5TIGxvb2t1cCwgd2hpY2ggbXVsdGlwbGllcyB0aGUgZWZmZWN0LiBUaGUgYXR0 YWNrIGlzIGVhc3kgdG8gcGVyZm9ybSBmcm9tIHRoZSBvdXRzaWRlIGFuZCBzZW5kIG9mZmVycyBu byBwcm90ZWN0aW9uLiBUaGUgb25seSBjbGVhciBwcm90ZWN0aW9uIGlzIHRvIGtub3cgaW4gYWR2 YW5jZSBhbGwgdGhlIGFkZHJlc3NlcyBwcmVzZW50IGluIHRoZSBuZXR3b3JrIGFuZCBkcm9wIHRo ZSByZXN0LiBHUkFORCBvZmZlcnMgYSB3YXkgdG8gcHJlc2V0IHRoZSBORCBjYWNoZSB3aGljaCBp cyBiZXR0ZXIgdGhhbiBub3RoaW5nIGJ1dCBpdCBvZmZlcnMgbm8gZ3VhcmFudGVlIHRoYXQgdGhl IHJvdXRlciBoYXMgdGhlIGZ1bGwgc2V0IG9mIGFkZHJlc3NlcyBJLiBDYWNoZS4gSW4gZmFjdCB0 aGUgY29uY2VwdCBvZiBhIGNhY2hlIGlzIGRhdGVkIGZyb20gdGhlIGRheXMgbWVtb3J5IHdhcyBz Y2FyY2UgYW5kIGV4cGVuc2l2ZS4gVGhpcyBjb25jZXB0IGlzIG5vdCBuZWVkZWQgQW5kIHJhdGhl ciBoYXJtZnVsIGluIG1vZGVybiBuZXR3b3Jrcy4NCg0KDQpSZWdhcmRzLA0KDQpQYXNjYWwNCg0K TGUgMzEganVpbC4gMjAyMCDDoCAxOTo0OSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+IGEgw6ljcml0IDoNCg0K77u/DQpIaSBUZWQsDQoNCkJ5IOKAnE5N 4oCdIEkgdGhpbmsgeW91IG1lYW4g4oCcTW9iaWxlIE5vZGU/4oCdIFRoYXTigJlzIG5vdCByZWFs bHkgb25lIG9mIHRoZSB1c2UgY2FzZXMgd2XigJlyZSB0YWxraW5nIGFib3V0IGhlcmUuIE9yIGFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQpbPl0NCk9yLCBqdXN0IGNhbGwgaXQgYSAobW9iaWxlKSDi gJxTdHViLU5ldHdvcmvigJ0g4oCTIEkgdGhpbmsgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNh bWUNCnRoaW5nIGhlcmUuDQoNCkluIGFueSBjYXNlLCB5b3XigJlyZSBwcmVzdW1pbmcgc29tZSBr aW5kIG9mIHRydXN0IGVzdGFibGlzaG1lbnQgZm9yIG5vbi1yb3V0ZXIgbm9kZXMsIHJpZ2h0PyBT RU5EIG9ubHkgdGFsa3MgYWJvdXQgdHJ1c3QgZXN0YWJsaXNobWVudCBmb3Igcm91dGVycy4gQW5k LCBsZXTigJlzIGJlIGZyYW5rLCBkb2VzbuKAmXQgYWN0dWFsbHkgZ2l2ZSB1cyBlbm91Z2ggb3Bl cmF0aW9uYWwgZ3VpZGFuY2UgdGhhdCB3ZSB3b3VsZCBleHBlY3Qgd2hhdCBfaXNfIHNhaWQgdG8g YmUgZ2VuZXJhbGx5IHByYWN0aWNhYmxlLg0KWz5dDQpPSywgdGhlIHNwZWNzIEkgaGF2ZSBiZWVu IHdvcmtpbmcgZGlwIHRoZWlyIHRvZXMgaW50byB0aGUgU0VORCBwb29sIGJ1dCBtYXliZSB0aGV5 DQpzaG91bGQgYmUgdXBkYXRlZCB0byBkaXZlIGluIGNvbXBsZXRlbHk/IFdpdGggYW4gYWRvcHRp b24gY2FsbCBpbiBwcm9ncmVzcywgSSBkb27igJl0DQprbm93IGlmIGl0IHdvdWxkIGJlIGEgZ29v ZCBpZGVhIHRvIG1ha2UgY2hhbmdlcyByaWdodCBub3cgYnV0IGJlIGFzc3VyZWQgdGhhdCBpdA0K d2lsbCBiZSBhZGRlZCB0byB0aGUgVE9ETyBsaXN0IOKAkyB3b3VsZCB0aGF0IGJlIGFjY2VwdGFi bGUgZm9yIG5vdz8NCg0KVGhhbmtzIC0gRnJlZA0KDQo= --_000_0DDEBA6C393340FCBB9C33FA59DC9D76ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBGcmVkDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIG1ham9yIGF0dGFjayB2ZWN0b3Ig aXMgYW4gZXh0ZXJuYWwgYXR0YWNrZXIgc2VuZGluZyBwYWNrZXRzIHRvIHRoZSAyXjY0IG9yIHNv IHBvc3NpYmxlIGFkZHJlc3NlcyBpbiB0aGUgc3VibmV0LiBUaGUgYXR0YWNrIGNhdXNlcyBhIGRl bmlhbCBvZiBzZXJ2aWNlIGF0IHRoZSByb3V0ZXIgdGhhdCBNVVNUIHN0b3JlIG9uZSBwYWNrZXQg Zm9yIG9uZSBzZWNvbmQgYW5kIG11bHRpY2FzdCBhIE5TIGxvb2t1cCwgd2hpY2ggbXVsdGlwbGll cw0KIHRoZSBlZmZlY3QuIFRoZSBhdHRhY2sgaXMgZWFzeSB0byBwZXJmb3JtIGZyb20gdGhlIG91 dHNpZGUgYW5kIHNlbmQgb2ZmZXJzIG5vIHByb3RlY3Rpb24uIFRoZSBvbmx5IGNsZWFyIHByb3Rl Y3Rpb24gaXMgdG8ga25vdyBpbiBhZHZhbmNlIGFsbCB0aGUgYWRkcmVzc2VzIHByZXNlbnQgaW4g dGhlIG5ldHdvcmsgYW5kIGRyb3AgdGhlIHJlc3QuIEdSQU5EIG9mZmVycyBhIHdheSB0byBwcmVz ZXQgdGhlIE5EIGNhY2hlIHdoaWNoIGlzIGJldHRlcg0KIHRoYW4gbm90aGluZyBidXQgaXQgb2Zm ZXJzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSByb3V0ZXIgaGFzIHRoZSBmdWxsIHNldCBvZiBhZGRy ZXNzZXMgSS4gQ2FjaGUuIEluIGZhY3QgdGhlIGNvbmNlcHQgb2YgYSBjYWNoZSBpcyBkYXRlZCBm cm9tIHRoZSBkYXlzIG1lbW9yeSB3YXMgc2NhcmNlIGFuZCBleHBlbnNpdmUuIFRoaXMgY29uY2Vw dCBpcyBub3QgbmVlZGVkIEFuZCByYXRoZXIgaGFybWZ1bCBpbiBtb2Rlcm4gbmV0d29ya3MuPGJy Pg0KPGJyPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KUmVnYXJkcywNCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRy Ij48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5MZSAzMSBqdWlsLiAyMDIwIMOgIDE5OjQ5 LCBUZW1wbGluIChVUyksIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDsg YSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQogPHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy IDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPkhpIFRlZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5CeSDigJxOTeKAnSBJIHRoaW5rIHlvdSBtZWFu IOKAnE1vYmlsZSBOb2RlP+KAnSBUaGF04oCZcyBub3QgcmVhbGx5IG9uZSBvZiB0aGUgdXNlIGNh c2VzIHdl4oCZcmUgdGFsa2luZyBhYm91dCBoZXJlLiBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5n PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bJmd0O10NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPk9yLCBqdXN0IGNhbGwgaXQgYSAobW9iaWxlKSDigJxTdHViLU5ldHdvcmvigJ0g 4oCTIEkgdGhpbmsgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWU8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj50aGluZyBoZXJlLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkluIGFueSBjYXNlLCB5b3XigJlyZSBw cmVzdW1pbmcgc29tZSBraW5kIG9mIHRydXN0IGVzdGFibGlzaG1lbnQgZm9yIG5vbi1yb3V0ZXIg bm9kZXMsIHJpZ2h0PyBTRU5EIG9ubHkgdGFsa3MgYWJvdXQgdHJ1c3QgZXN0YWJsaXNobWVudCBm b3Igcm91dGVycy4gQW5kLCBsZXTigJlzIGJlIGZyYW5rLCBkb2VzbuKAmXQgYWN0dWFsbHkgZ2l2 ZSB1cyBlbm91Z2ggb3BlcmF0aW9uYWwNCiBndWlkYW5jZSB0aGF0IHdlIHdvdWxkIGV4cGVjdCB3 aGF0IF9pc18gc2FpZCB0byBiZSBnZW5lcmFsbHkgcHJhY3RpY2FibGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlsmZ3Q7XQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T0ssIHRo ZSBzcGVjcyBJIGhhdmUgYmVlbiB3b3JraW5nIGRpcCB0aGVpciB0b2VzIGludG8gdGhlIFNFTkQg cG9vbCBidXQgbWF5YmUgdGhleTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNob3Vs ZCBiZSB1cGRhdGVkIHRvIGRpdmUgaW4gY29tcGxldGVseT8gV2l0aCBhbiBhZG9wdGlvbiBjYWxs IGluIHByb2dyZXNzLCBJIGRvbuKAmXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5r bm93IGlmIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRvIG1ha2UgY2hhbmdlcyByaWdodCBub3cg YnV0IGJlIGFzc3VyZWQgdGhhdCBpdDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndp bGwgYmUgYWRkZWQgdG8gdGhlIFRPRE8gbGlzdCDigJMgd291bGQgdGhhdCBiZSBhY2NlcHRhYmxl IGZvciBub3c/PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_0DDEBA6C393340FCBB9C33FA59DC9D76ciscocom_-- From nobody Fri Jul 31 15:13:24 2020 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 544BD3A0C78; Fri, 31 Jul 2020 15:13:19 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31I96VmFcF6R; Fri, 31 Jul 2020 15:13:17 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 7B5543A0C68; Fri, 31 Jul 2020 15:13:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VMDDbu008008; Fri, 31 Jul 2020 18:13:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596233593; bh=f8+ayfROWdmq4rdE0+JGz8/wI+mJQP1EG5L/68paT6Q=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=HWNbTxAnbvqLV3ap8M2gvsAueb9FbIQpQ3CGyY30S9Atzwx1hEOYZB0Dbn2Y/gmJp bKiuWjsQOpy0An3OsehhVoW/FJR5lVkz4iYZzmHOs8iuA6+a2hZKcdsyaIdG86SBkJ ot18G4TUN1Ac2RPJ2hQvY+s5dsvsQnjEYyDlCcuP6h7InMplu7JIYRuEMQ7F3J00Up tgkwkC2YaPDnX55HRtvwg3c0jtTNMUSeNnc+7HevtUYcuVi1FCA6spPqnHVZVOeTF9 0y7xVlkKIwsBxLXuMk1OHL30M3jCowu9x9ElGx3y+P5jA5ECw+7p/P315Zwyb4i2NF vpQAFnm85NQ+A== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VMD6Dk006965 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 18:13:06 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 15:13:05 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 15:13:05 -0700 From: "Templin (US), Fred L" To: "Pascal Thubert (pthubert)" CC: Ted Lemon , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: Improving ND security Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6gAO/XoAAA6T6+D//9BAgIAAcUNg Date: Fri, 31 Jul 2020 22:13:05 +0000 Message-ID: <4907a159683346789bef5c495f03f95d@boeing.com> References: <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com>, <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com> In-Reply-To: <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 58D04A679D3548070B2CE19C830C6E20DB18B25CCB3267F92982369E5D4E23AF2000:8 Content-Type: multipart/alternative; boundary="_000_4907a159683346789bef5c495f03f95dboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 22:13:20 -0000 --_000_4907a159683346789bef5c495f03f95dboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGFzY2FsLCBzZWUgYmVsb3c6DQoNCkEgbWFqb3IgYXR0YWNrIHZlY3RvciBpcyBhbiBleHRl cm5hbCBhdHRhY2tlciBzZW5kaW5nIHBhY2tldHMgdG8gdGhlIDJeNjQgb3Igc28gcG9zc2libGUg YWRkcmVzc2VzIGluIHRoZSBzdWJuZXQuDQpbPl0gU3VibmV0Pz8gQXMgaW4sIGFuIG9uLWxpbmsg SVB2NiBwcmVmaXg/IFRoZSBsYXJnZSBOQk1BIGxpbmsgdGhhdCBJIHdhbnQgdG8gdXNlIFNFTkQN Cm9uIHdpbGwgbm90IGhhdmUgYW55IG9mIHRob3NlIOKAkyBsaW5rLWxvY2FsIG9ubHkuDQoNClRo ZSBhdHRhY2sgY2F1c2VzIGEgZGVuaWFsIG9mIHNlcnZpY2UgYXQgdGhlIHJvdXRlciB0aGF0IE1V U1Qgc3RvcmUgb25lIHBhY2tldCBmb3Igb25lIHNlY29uZCBhbmQgbXVsdGljYXN0IGEgTlMgbG9v a3VwLCB3aGljaCBtdWx0aXBsaWVzIHRoZSBlZmZlY3QuDQpbPl0gQWdhaW4sIHdlIGFyZSB0YWxr aW5nIGFib3V0IGRpZmZlcmVudCBraW5kcyBvZiBsaW5rczsgdGhlcmUgd2lsbCBub3QgYmUgYW55 IHNvcnQgb2YNCm11bHRpY2FzdCBleHBsb3Npb24gb24gdGhlIE5CTUEgbGluayBiYXNlZCBvbiBh IHJvdXRlciByZWNlaXZpbmcgYSBTRU5ELXByb3RlY3RlZA0KSVB2NiBORCBtZXNzYWdlLg0KDQpU aGUgYXR0YWNrIGlzIGVhc3kgdG8gcGVyZm9ybSBmcm9tIHRoZSBvdXRzaWRlIGFuZCBzZW5kIG9m ZmVycyBubyBwcm90ZWN0aW9uLg0KWz5dIEZvciB0aGUgT01OSSBOQk1BIGxpbmssIHRoZSBwcm9j ZXNzIGlzIGJhc2VkIG9uIGEgQ2xpZW50IHNlbmRpbmcgYSBTRU5ELXByb3RlY3RlZA0KUlMgbWVz c2FnZSB0byBleGFjdGx5IG9uZSByb3V0ZXIuIFRoZSByb3V0ZXIgYXV0aGVudGljYXRlcyB0aGUg UlMgYmVmb3JlIHByb2Nlc3NpbmcgaXQNCmZ1cnRoZXIsIHdoaWNoIG1heSBpbmNsdWRlIHJldHVy bmluZyBhIHVuaWNhc3RlZCBSQS4gTm8gTkNFcyBhcmUgY3JlYXRlZCB1bnRpbCB0aGUgUlMNCmhh cyBiZWVuIGF1dGhlbnRpY2F0ZWQsIGFuZCBubyBtdWx0aWNhc3Qgc3Rvcm1zIGFyZSBpbml0aWF0 ZWQuDQoNClRoZSBvbmx5IGNsZWFyIHByb3RlY3Rpb24gaXMgdG8ga25vdyBpbiBhZHZhbmNlIGFs bCB0aGUgYWRkcmVzc2VzIHByZXNlbnQgaW4gdGhlIG5ldHdvcmsgYW5kIGRyb3AgdGhlIHJlc3Qu IEdSQU5EIG9mZmVycyBhIHdheSB0byBwcmVzZXQgdGhlIE5EIGNhY2hlIHdoaWNoIGlzIGJldHRl ciB0aGFuIG5vdGhpbmcgYnV0IGl0IG9mZmVycyBubyBndWFyYW50ZWUgdGhhdCB0aGUgcm91dGVy IGhhcyB0aGUgZnVsbCBzZXQgb2YgYWRkcmVzc2VzIEkuIENhY2hlLiBJbiBmYWN0IHRoZSBjb25j ZXB0IG9mIGEgY2FjaGUgaXMgZGF0ZWQgZnJvbSB0aGUgZGF5cyBtZW1vcnkgd2FzIHNjYXJjZSBh bmQgZXhwZW5zaXZlLiBUaGlzIGNvbmNlcHQgaXMgbm90IG5lZWRlZCBBbmQgcmF0aGVyIGhhcm1m dWwgaW4gbW9kZXJuIG5ldHdvcmtzLg0KWz5dIFRoZSBPTU5JIHJvdXRlcnMgYXJlIG5vdCBnb2lu ZyB0byByZXF1aXJlIGFueSBraW5kIG9mIE5EIGNhY2hlIHByZXNldHM7IHRoZXkNCnNpbXBseSBl c3RhYmxpc2ggTkNFcyB1cG9uIHJlY2VpcHQgKmFuZCogYXV0aGVudGljYXRpb24gb2YgZ29vZCBS UyBtZXNzYWdlcy4NCg0KVGhhbmtzIC0gRnJlZA0KDQpSZWdhcmRzLA0KDQpQYXNjYWwNCg0KDQpM ZSAzMSBqdWlsLiAyMDIwIMOgIDE5OjQ5LCBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IGEgw6lj cml0IDoNCu+7vw0KSGkgVGVkLA0KDQpCeSDigJxOTeKAnSBJIHRoaW5rIHlvdSBtZWFuIOKAnE1v YmlsZSBOb2RlP+KAnSBUaGF04oCZcyBub3QgcmVhbGx5IG9uZSBvZiB0aGUgdXNlIGNhc2VzIHdl 4oCZcmUgdGFsa2luZyBhYm91dCBoZXJlLiBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KWz5d DQpPciwganVzdCBjYWxsIGl0IGEgKG1vYmlsZSkg4oCcU3R1Yi1OZXR3b3Jr4oCdIOKAkyBJIHRo aW5rIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBzYW1lDQp0aGluZyBoZXJlLg0KDQpJbiBhbnkg Y2FzZSwgeW914oCZcmUgcHJlc3VtaW5nIHNvbWUga2luZCBvZiB0cnVzdCBlc3RhYmxpc2htZW50 IGZvciBub24tcm91dGVyIG5vZGVzLCByaWdodD8gU0VORCBvbmx5IHRhbGtzIGFib3V0IHRydXN0 IGVzdGFibGlzaG1lbnQgZm9yIHJvdXRlcnMuIEFuZCwgbGV04oCZcyBiZSBmcmFuaywgZG9lc27i gJl0IGFjdHVhbGx5IGdpdmUgdXMgZW5vdWdoIG9wZXJhdGlvbmFsIGd1aWRhbmNlIHRoYXQgd2Ug d291bGQgZXhwZWN0IHdoYXQgX2lzXyBzYWlkIHRvIGJlIGdlbmVyYWxseSBwcmFjdGljYWJsZS4N Cls+XQ0KT0ssIHRoZSBzcGVjcyBJIGhhdmUgYmVlbiB3b3JraW5nIGRpcCB0aGVpciB0b2VzIGlu dG8gdGhlIFNFTkQgcG9vbCBidXQgbWF5YmUgdGhleQ0Kc2hvdWxkIGJlIHVwZGF0ZWQgdG8gZGl2 ZSBpbiBjb21wbGV0ZWx5PyBXaXRoIGFuIGFkb3B0aW9uIGNhbGwgaW4gcHJvZ3Jlc3MsIEkgZG9u 4oCZdA0Ka25vdyBpZiBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBtYWtlIGNoYW5nZXMgcmln aHQgbm93IGJ1dCBiZSBhc3N1cmVkIHRoYXQgaXQNCndpbGwgYmUgYWRkZWQgdG8gdGhlIFRPRE8g bGlzdCDigJMgd291bGQgdGhhdCBiZSBhY2NlcHRhYmxlIGZvciBub3c/DQoNClRoYW5rcyAtIEZy ZWQNCg0K --_000_4907a159683346789bef5c495f03f95dboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPkhpIFBhc2NhbCwgc2VlIGJlbG93Ojwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5BIG1ham9yIGF0dGFjayB2ZWN0b3IgaXMgYW4gZXh0ZXJuYWwgYXR0YWNrZXIgc2VuZGlu ZyBwYWNrZXRzIHRvIHRoZSAyXjY0IG9yIHNvIHBvc3NpYmxlIGFkZHJlc3NlcyBpbiB0aGUgc3Vi bmV0LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlsmZ3Q7XSBTdWJuZXQ/PyBBcyBpbiwgYW4gb24tbGluayBJUHY2IHByZWZpeD8gVGhl IGxhcmdlIE5CTUEgbGluayB0aGF0IEkgd2FudCB0byB1c2UgU0VORDxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPm9uIHdpbGwgbm90IGhhdmUgYW55IG9mIHRob3NlIOKAkyBsaW5rLWxv Y2FsIG9ubHkuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGUgYXR0YWNr IGNhdXNlcyBhIGRlbmlhbCBvZiBzZXJ2aWNlIGF0IHRoZSByb3V0ZXIgdGhhdCBNVVNUIHN0b3Jl IG9uZSBwYWNrZXQgZm9yIG9uZSBzZWNvbmQgYW5kIG11bHRpY2FzdCBhIE5TIGxvb2t1cCwgd2hp Y2ggbXVsdGlwbGllcyB0aGUgZWZmZWN0LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlsmZ3Q7XSBBZ2Fpbiwgd2UgYXJlIHRhbGtpbmcg YWJvdXQgZGlmZmVyZW50IGtpbmRzIG9mIGxpbmtzOyB0aGVyZSB3aWxsIG5vdCBiZSBhbnkgc29y dCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm11bHRpY2FzdCBleHBsb3Npb24g b24gdGhlIE5CTUEgbGluayBiYXNlZCBvbiBhIHJvdXRlciByZWNlaXZpbmcgYSBTRU5ELXByb3Rl Y3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklQdjYgTkQgbWVzc2FnZS48bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSBhdHRhY2sgaXMgZWFzeSB0byBw ZXJmb3JtIGZyb20gdGhlIG91dHNpZGUgYW5kIHNlbmQgb2ZmZXJzIG5vIHByb3RlY3Rpb24uPHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ WyZndDtdIEZvciB0aGUgT01OSSBOQk1BIGxpbmssIHRoZSBwcm9jZXNzIGlzIGJhc2VkIG9uIGEg Q2xpZW50IHNlbmRpbmcgYSBTRU5ELXByb3RlY3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlJTIG1lc3NhZ2UgdG8gZXhhY3RseSBvbmUgcm91dGVyLiBUaGUgcm91dGVyIGF1dGhl bnRpY2F0ZXMgdGhlIFJTIGJlZm9yZSBwcm9jZXNzaW5nIGl0PG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+ZnVydGhlciwgd2hpY2ggbWF5IGluY2x1ZGUgcmV0dXJuaW5nIGEgdW5pY2Fz dGVkIFJBLiBObyBOQ0VzIGFyZSBjcmVhdGVkIHVudGlsIHRoZSBSUzxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPmhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQsIGFuZCBubyBtdWx0aWNhc3Qg c3Rvcm1zIGFyZSBpbml0aWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5UaGUgb25seSBjbGVhciBwcm90ZWN0aW9uIGlzIHRvIGtub3cgaW4gYWR2YW5jZSBhbGwgdGhl IGFkZHJlc3NlcyBwcmVzZW50IGluIHRoZSBuZXR3b3JrIGFuZCBkcm9wIHRoZSByZXN0LiBHUkFO RCBvZmZlcnMgYSB3YXkgdG8gcHJlc2V0IHRoZSBORCBjYWNoZSB3aGljaCBpcyBiZXR0ZXIgdGhh biBub3RoaW5nDQogYnV0IGl0IG9mZmVycyBubyBndWFyYW50ZWUgdGhhdCB0aGUgcm91dGVyIGhh cyB0aGUgZnVsbCBzZXQgb2YgYWRkcmVzc2VzIEkuIENhY2hlLiBJbiBmYWN0IHRoZSBjb25jZXB0 IG9mIGEgY2FjaGUgaXMgZGF0ZWQgZnJvbSB0aGUgZGF5cyBtZW1vcnkgd2FzIHNjYXJjZSBhbmQg ZXhwZW5zaXZlLiBUaGlzIGNvbmNlcHQgaXMgbm90IG5lZWRlZCBBbmQgcmF0aGVyIGhhcm1mdWwg aW4gbW9kZXJuIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bJmd0O10gVGhlIE9N Tkkgcm91dGVycyBhcmUgbm90IGdvaW5nIHRvIHJlcXVpcmUgYW55IGtpbmQgb2YgTkQgY2FjaGUg cHJlc2V0czsgdGhleTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNpbXBseSBlc3Rh Ymxpc2ggTkNFcyB1cG9uIHJlY2VpcHQgKmFuZCogYXV0aGVudGljYXRpb24gb2YgZ29vZCBSUyBt ZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjwvaT48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlJlZ2FyZHMsIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlBhc2Nh bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TGUgMzEganVp bC4gMjAyMCDDoCAxOTo0OSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0 bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9h PiZndDsgYSDDqWNyaXQmbmJzcDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ 77u/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+ SGkgVGVkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PkJ5IOKAnE5N4oCdIEkgdGhpbmsgeW91IG1lYW4g4oCcTW9iaWxlIE5vZGU/4oCdIFRoYXTigJlz IG5vdCByZWFsbHkgb25lIG9mIHRoZSB1c2UgY2FzZXMgd2XigJlyZSB0YWxraW5nIGFib3V0IGhl cmUuIE9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlsm Z3Q7XQ0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T3IsIGp1c3QgY2FsbCBpdCBh IChtb2JpbGUpIOKAnFN0dWItTmV0d29ya+KAnSDigJMgSSB0aGluayB3ZSBhcmUgdGFsa2luZyBh Ym91dCB0aGUgc2FtZTwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoaW5nIGhlcmUu PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkluIGFueSBjYXNlLCB5b3XigJlyZSBwcmVzdW1pbmcg c29tZSBraW5kIG9mIHRydXN0IGVzdGFibGlzaG1lbnQgZm9yIG5vbi1yb3V0ZXIgbm9kZXMsIHJp Z2h0PyBTRU5EIG9ubHkgdGFsa3MgYWJvdXQgdHJ1c3QgZXN0YWJsaXNobWVudCBmb3Igcm91dGVy cy4gQW5kLCBsZXTigJlzIGJlIGZyYW5rLCBkb2VzbuKAmXQgYWN0dWFsbHkgZ2l2ZSB1cyBlbm91 Z2ggb3BlcmF0aW9uYWwNCiBndWlkYW5jZSB0aGF0IHdlIHdvdWxkIGV4cGVjdCB3aGF0IF9pc18g c2FpZCB0byBiZSBnZW5lcmFsbHkgcHJhY3RpY2FibGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlsmZ3Q7XQ0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T0ssIHRoZSBzcGVjcyBJ IGhhdmUgYmVlbiB3b3JraW5nIGRpcCB0aGVpciB0b2VzIGludG8gdGhlIFNFTkQgcG9vbCBidXQg bWF5YmUgdGhleTwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNob3VsZCBiZSB1cGRh dGVkIHRvIGRpdmUgaW4gY29tcGxldGVseT8gV2l0aCBhbiBhZG9wdGlvbiBjYWxsIGluIHByb2dy ZXNzLCBJIGRvbuKAmXQ8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5rbm93IGlmIGl0 IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRvIG1ha2UgY2hhbmdlcyByaWdodCBub3cgYnV0IGJlIGFz c3VyZWQgdGhhdCBpdDwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndpbGwgYmUgYWRk ZWQgdG8gdGhlIFRPRE8gbGlzdCDigJMgd291bGQgdGhhdCBiZSBhY2NlcHRhYmxlIGZvciBub3c/ PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4907a159683346789bef5c495f03f95dboeingcom_--