From nobody Sat Feb 15 19:35:51 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9B12002F for ; Sat, 15 Feb 2020 19:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9yFC9dJ5EqyO for ; Sat, 15 Feb 2020 19:35:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF55120013 for ; Sat, 15 Feb 2020 19:35:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9D51EF406CE; Sat, 15 Feb 2020 19:35:19 -0800 (PST) To: congxiao@cernet.edu.cn, huitema@microsoft.com, marcelo@it.uc3m.es, mohamed.boucadair@orange-ftgroup.com, xing@cernet.edu.cn, ietf@kuehlewind.net, magnus.westerlund@ericsson.com, dwing@cisco.com, dthaler@microsoft.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: jordi.palet@theipv6company.com, behave@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200216033519.9D51EF406CE@rfc-editor.org> Date: Sat, 15 Feb 2020 19:35:19 -0800 (PST) Archived-At: Subject: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 03:35:50 -0000 The following errata report has been submitted for RFC6052, "IPv6 Addressing of IPv4/IPv6 Translators". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5984 -------------------------------------- Type: Technical Reported by: Jordi Palet Martinez Section: 3.3 Original Text ------------- Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service. Corrected Text -------------- Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix for the exclusive use of their IPv4/IPv6 translation service. Notes ----- This seems obvious but is not. The NSP must only be used for the translation service. If the NSP is used only, for example in an enterprise network, in the LANs, and the translator allows it, it may create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may be the same as a host inside the LAN has been configured with (either manually, or with SLAAC, DHCPv6), etc. It has been confirmed that at least one vendor already realized this and the implementation doesn't work if the prefix is used both for the translator service and one of the LANs, but there is no explicit documentation on that. So if configured, the box doesn't work, but doesn't report is an an "invalid" config. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6052 (draft-ietf-behave-address-format-10) -------------------------------------- Title : IPv6 Addressing of IPv4/IPv6 Translators Publication Date : October 2010 Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From nobody Sun Feb 16 12:05:08 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B08C12001B for ; Sun, 16 Feb 2020 12:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IgfHN3lihnAp for ; Sun, 16 Feb 2020 12:05:03 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 A08B5120048 for ; Sun, 16 Feb 2020 12:05:03 -0800 (PST) Received: from xse278.mail2web.com ([66.113.197.24] helo=xse.mail2web.com) by mx36.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j3Q9r-0004Te-My for behave@ietf.org; Sun, 16 Feb 2020 21:05:03 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48LJ4J5PqRzwkN for ; Sun, 16 Feb 2020 12:04:48 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j3Q9o-0000S7-Kc for behave@ietf.org; Sun, 16 Feb 2020 12:04:48 -0800 Received: (qmail 15611 invoked from network); 16 Feb 2020 20:04:48 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.46.153]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Feb 2020 20:04:48 -0000 To: RFC Errata System , congxiao@cernet.edu.cn, huitema@microsoft.com, marcelo@it.uc3m.es, mohamed.boucadair@orange-ftgroup.com, xing@cernet.edu.cn, ietf@kuehlewind.net, magnus.westerlund@ericsson.com, dwing@cisco.com, dthaler@microsoft.com Cc: jordi.palet@theipv6company.com, behave@ietf.org References: <20200216033519.9D51EF406CE@rfc-editor.org> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> Date: Sun, 16 Feb 2020 12:04:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200216033519.9D51EF406CE@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.24 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0QHHUXH8HYgJuwhvgiygxCWpSDasLI4SayDByyq9LIhVx62w2pIOVQFO 0Y54fR3FR0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDE0VDNa+7voHheyvK5k2Z0sRX qYbtEQV1z/L435ZRxFRDCv/EXnE42jMmyoMPsbvG+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxpgwWbxrOZCJSMpTl/yE2fo2ANRUfkFjthfvkYMyqnVcYgZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLZ8DTogwQ+H /c7sp+LxSn98rXrButjEZ1mypazCztWY4nuZrRf7bMi0WRR6pZ+nWeoe8xwjfwkcg9UL+w+S/HNX 0SU68ek9wyYNR7nSKrZbQsAM8hGlAkv+YXlQiOyIRazNjLvclnGzlTC8ZgkR3laIWqvAxiBHuIuS y5fCAlEkQcPgd8T/HNBdWvilR5kDIVACVO3tx78u0bG7If2TCVShJs7Pc7Fk0HSZEwJJv9GNt7vJ ARVknfOPvWEpmfhK0FffncYFDRVcOLM39ai6q8vmTBTpnbNAWsjoa2lMG/HqJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 20:05:07 -0000 Jordi, The errata process is not the right way to handle this issue. You are asking for a change in the specification, and such changes should go through the working group, as part of a standard discussion. To go to the specific technical point: it is indeed completely doable to use the same /64 prefix for a local subnet and for a NAT service. The only requirement is that the NAT be capable to distinguishing between a translated address and a local address, and that requirement is implicit in RFC6502. For example, the NAT could reserve <64bit>:dead:beef::/96 for the 6to4 service, and use DUD to defend against hosts configuring an address in the same /64 prefix. That may not be a perfect solution, but that's something the working group should discuss, not something to be handled summarily through the errata process. -- Christian Huitema On 2/15/2020 7:35 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6052, > "IPv6 Addressing of IPv4/IPv6 Translators". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5984 > > -------------------------------------- > Type: Technical > Reported by: Jordi Palet Martinez > > Section: 3.3 > > Original Text > ------------- > Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a= Network-Specific Prefix to their IPv4/IPv6 translation service. > > Corrected Text > -------------- > Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a= Network-Specific Prefix for the exclusive use of their IPv4/IPv6 transla= tion service. > > Notes > ----- > This seems obvious but is not. The NSP must only be used for the transl= ation service. If the NSP is used only, for example in an enterprise netw= ork, in the LANs, and the translator allows it, it may create conflicts, = as the resulting IPv6 address (NSP+IPv4 address) may be the same as a hos= t inside the LAN has been configured with (either manually, or with SLAAC= , DHCPv6), etc. > > It has been confirmed that at least one vendor already realized this an= d the implementation doesn't work if the prefix is used both for the tran= slator service and one of the LANs, but there is no explicit documentatio= n on that. So if configured, the box doesn't work, but doesn't report is = an an "invalid" config. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 > > -------------------------------------- > RFC6052 (draft-ietf-behave-address-format-10) > -------------------------------------- > Title : IPv6 Addressing of IPv4/IPv6 Translators > Publication Date : October 2010 > Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. = Li > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Feb 17 18:29:00 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15B2120274; Mon, 17 Feb 2020 01:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6BABdqhxwkRU; Mon, 17 Feb 2020 01:26:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE7812025D; Mon, 17 Feb 2020 01:26:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BF3B6F406F5; Mon, 17 Feb 2020 01:26:25 -0800 (PST) To: jordi.palet@theipv6company.com, congxiao@cernet.edu.cn, huitema@microsoft.com, marcelo@it.uc3m.es, mohamed.boucadair@orange-ftgroup.com, xing@cernet.edu.cn X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, behave@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200217092625.BF3B6F406F5@rfc-editor.org> Date: Mon, 17 Feb 2020 01:26:25 -0800 (PST) Archived-At: Subject: [BEHAVE] [Errata Rejected] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 09:26:29 -0000 The following errata report has been rejected for RFC6052, "IPv6 Addressing of IPv4/IPv6 Translators". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5984 -------------------------------------- Status: Rejected Type: Technical Reported by: Jordi Palet Martinez Date Reported: 2020-02-16 Rejected by: Magnus Westerlund (IESG) Section: 3.3 Original Text ------------- Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service. Corrected Text -------------- Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix for the exclusive use of their IPv4/IPv6 translation service. Notes ----- This seems obvious but is not. The NSP must only be used for the translation service. If the NSP is used only, for example in an enterprise network, in the LANs, and the translator allows it, it may create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may be the same as a host inside the LAN has been configured with (either manually, or with SLAAC, DHCPv6), etc. It has been confirmed that at least one vendor already realized this and the implementation doesn't work if the prefix is used both for the translator service and one of the LANs, but there is no explicit documentation on that. So if configured, the box doesn't work, but doesn't report is an an "invalid" config. --VERIFIER NOTES-- This Errata requests requires WG consensus decision and thus outside of the Errata process. The specification does not prevent what is propsed as the appropriate way of assigning a NSP. The RFC does not restrict the usage, and as commented on the mailing list, there are ways to make even using the same prefix for both clients and the NAT64 device. -------------------------------------- RFC6052 (draft-ietf-behave-address-format-10) -------------------------------------- Title : IPv6 Addressing of IPv4/IPv6 Translators Publication Date : October 2010 Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Feb 17 18:29:23 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FFE1207FD for ; Mon, 17 Feb 2020 01:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 itKGjfciqANU for ; Mon, 17 Feb 2020 01:43:21 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BC8120639 for ; Mon, 17 Feb 2020 01:43:20 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 48LfDh6y5mz8t3h; Mon, 17 Feb 2020 10:43:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581932597; bh=9w2oTWZi+WOuiuelIMivPr68cOWDi6oMKvzmvWOmQs0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xct7M4TJuxbhe97Rme2K1OO7cdJYrjYew/yPfcweLR7+erX/SSRBwLQpAHkk1AxJO SPJUKQqKIXPH38qhnic2kZwl1gsnmSzL+LxVXIH23aKxIsAmsBiJXCXh3RAVgMWK+E i51j3MROUCQHT8oVytPjPN9oVZ34iZvALQvj/bkvHuaWwvb5rnzFxQRh+8HyfPBF6R 4FuNfBs/dz6HLuXNWX8PVXngT9pwSjDkcPZtAwSnntRzC5hQjZvZHAOdTqj92mJdCI XH4ur6SedgWfeZ7I/nTQ9TTC5Pm8GCzHOiZaGSlFPuC4rMsqUDuVS3379a9cAqyYDt 7EtgyZXUiiSeQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48LfDh4L1KzBrMT; Mon, 17 Feb 2020 10:43:16 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([fe80::74f6:8fc8:b1b8:dbba%21]) with mapi id 14.03.0468.000; Mon, 17 Feb 2020 10:43:15 +0100 From: To: Christian Huitema , RFC Errata System , "congxiao@cernet.edu.cn" , "huitema@microsoft.com" , "marcelo@it.uc3m.es" , "mohamed.boucadair@orange-ftgroup.com" , "xing@cernet.edu.cn" , "ietf@kuehlewind.net" , "magnus.westerlund@ericsson.com" , "dwing@cisco.com" , "dthaler@microsoft.com" CC: "jordi.palet@theipv6company.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) Thread-Index: AQHV5Ho1i5WTlqabqkO/th8ePGNftKgeLvYAgADvV5A= Date: Mon, 17 Feb 2020 09:43:14 +0000 Message-ID: <73fff6ba-dc6d-4360-ac4d-339265c9a09d@OPEXCAUBM8F.corporate.adroot.infra.ftgroup> References: <20200216033519.9D51EF406CE@rfc-editor.org> <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> In-Reply-To: <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 09:43:24 -0000 Hi all,=20 One further comment: the assumption we have for "stateless translation" is = as follows In these deployments, internal IPv6 nodes are addressed using IPv4-translatable IPv6 addresses, which enable them to be accessed by IPv4 nodes. I don't see any issue with the current text under such assumption. Cheers, Med > -----Message d'origine----- > De=A0: Behave [mailto:behave-bounces@ietf.org] De la part de Christian > Huitema > Envoy=E9=A0: dimanche 16 f=E9vrier 2020 21:05 > =C0=A0: RFC Errata System; congxiao@cernet.edu.cn; huitema@microsoft.com; > marcelo@it.uc3m.es; mohamed.boucadair@orange-ftgroup.com; > xing@cernet.edu.cn; ietf@kuehlewind.net; > magnus.westerlund@ericsson.com; dwing@cisco.com; dthaler@microsoft.com > Cc=A0: jordi.palet@theipv6company.com; behave@ietf.org > Objet=A0: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) >=20 > Jordi, >=20 > The errata process is not the right way to handle this issue. You are > asking for a change in the specification, and such changes should go > through the working group, as part of a standard discussion. >=20 > To go to the specific technical point: it is indeed completely doable > to > use the same /64 prefix for a local subnet and for a NAT service. The > only requirement is that the NAT be capable to distinguishing between > a > translated address and a local address, and that requirement is > implicit > in RFC6502. For example, the NAT could reserve <64bit>:dead:beef::/96 > for the 6to4 service, and use DUD to defend against hosts configuring > an > address in the same /64 prefix. That may not be a perfect solution, > but > that's something the working group should discuss, not something to be > handled summarily through the errata process. >=20 > -- Christian Huitema >=20 > On 2/15/2020 7:35 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC6052, > > "IPv6 Addressing of IPv4/IPv6 Translators". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5984 > > > > -------------------------------------- > > Type: Technical > > Reported by: Jordi Palet Martinez > > > > Section: 3.3 > > > > Original Text > > ------------- > > Organizations deploying stateless IPv4/IPv6 translation SHOULD > assign a Network-Specific Prefix to their IPv4/IPv6 translation > service. > > > > Corrected Text > > -------------- > > Organizations deploying stateless IPv4/IPv6 translation SHOULD > assign a Network-Specific Prefix for the exclusive use of their > IPv4/IPv6 translation service. > > > > Notes > > ----- > > This seems obvious but is not. The NSP must only be used for the > translation service. If the NSP is used only, for example in an > enterprise network, in the LANs, and the translator allows it, it may > create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may > be the same as a host inside the LAN has been configured with (either > manually, or with SLAAC, DHCPv6), etc. > > > > It has been confirmed that at least one vendor already realized this > and the implementation doesn't work if the prefix is used both for the > translator service and one of the LANs, but there is no explicit > documentation on that. So if configured, the box doesn't work, but > doesn't report is an an "invalid" config. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6052 (draft-ietf-behave-address-format-10) > > -------------------------------------- > > Title : IPv6 Addressing of IPv4/IPv6 Translators > > Publication Date : October 2010 > > Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, > X. Li > > Category : PROPOSED STANDARD > > Source : Behavior Engineering for Hindrance Avoidance > > Area : Transport > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Feb 17 18:29:29 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3542A120800; Mon, 17 Feb 2020 01:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kue-iztPPkzL; Mon, 17 Feb 2020 01:48:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8227F1207FF; Mon, 17 Feb 2020 01:48:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3C885F40710; Mon, 17 Feb 2020 01:48:40 -0800 (PST) To: shakeeb@eyeball.com, rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@jdrosen.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, behave@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200217094840.3C885F40710@rfc-editor.org> Date: Mon, 17 Feb 2020 01:48:40 -0800 (PST) Archived-At: Subject: [BEHAVE] [Errata Rejected] RFC5766 (4933) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 09:48:45 -0000 The following errata report has been rejected for RFC5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid4933 -------------------------------------- Status: Rejected Type: Technical Reported by: shakeeb Date Reported: 2017-02-15 Rejected by: Magnus Westerlund (IESG) Section: 17.3.3 Original Text ------------- An attacker might attempt to disrupt service to other users of the TURN server by sending Refresh requests or CreatePermission requests that (through source address spoofing) appear to be coming from another user of the TURN server. TURN prevents this by requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match those used to create the initial allocation. Thus, the fake requests from the attacker will be rejected. Corrected Text -------------- Notes ----- When using short-term, credentials expire after a specific amount of time (such as 5 minutes) and clients get new credentials. The restriction imposed at section 17.3.3 prevents from refreshing allocation or permission using the new credentials. This RFC approves RFC 5389. So one can use short-term credentials. But short-term credentials are useless if it can not be used to refresh allocation or permission. The goal of 17.3.3 can be achieved by sending 438 with the new nonce. --VERIFIER NOTES-- So TURN does not actually specify the usage of short-term credentials. It mandates support of long-term credentials as authentication mechanism. Also RFC 7635 (STUN for Third party Authorization) specifies how to handle expire of the access token. This is clearer in the replacement of RFC 5766 that will soon be published that specifies the following in Section 7.2: If the request is authenticated, the authentication MUST be done either using the long-term credential mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for Third-Party Authorization [RFC7635] unless the client and server agree to use another mechanism through some procedure outside the scope of this document. -------------------------------------- RFC5766 (draft-ietf-behave-turn-16) -------------------------------------- Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Publication Date : April 2010 Author(s) : R. Mahy, P. Matthews, J. Rosenberg Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Feb 17 18:32:12 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56F71200DB for ; Mon, 17 Feb 2020 04:46:44 -0800 (PST) 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, 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 4UodPwaQ_o8A for ; Mon, 17 Feb 2020 04:46:39 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 50A1A12008C for ; Mon, 17 Feb 2020 04:46:39 -0800 (PST) Received: from [129.192.10.2] (helo=[164.48.40.174]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3fn2-0007dI-5R; Mon, 17 Feb 2020 13:46:20 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <73fff6ba-dc6d-4360-ac4d-339265c9a09d@OPEXCAUBM8F.corporate.adroot.infra.ftgroup> Date: Mon, 17 Feb 2020 13:46:19 +0100 Cc: "congxiao@cernet.edu.cn" , "huitema@microsoft.com" , "marcelo@it.uc3m.es" , "mohamed.boucadair@orange-ftgroup.com" , "xing@cernet.edu.cn" , "magnus.westerlund@ericsson.com" , "dwing@cisco.com" , "dthaler@microsoft.com" , "jordi.palet@theipv6company.com" , "behave@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7D8AF4CC-81F6-4238-B6FD-585ED9F4B275@kuehlewind.net> References: <20200216033519.9D51EF406CE@rfc-editor.org> <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> <73fff6ba-dc6d-4360-ac4d-339265c9a09d@OPEXCAUBM8F.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com, Christian Huitema X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581943599;6ea05df6; X-HE-SMSGID: 1j3fn2-0007dI-5R Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 12:46:45 -0000 Hi all, I agree that this is probably not an errata. However, we could mark this = as =E2=80=9CHold for next Document Update=E2=80=9D? I guess if there = every will be an update, this need further discussion, however, having = it in the errata system can help to remember it. Or do think people it = should just be rejected for now? Mirja > On 17. Feb 2020, at 10:43, = wrote: >=20 > Hi all,=20 >=20 > One further comment: the assumption we have for "stateless = translation" is as follows >=20 > In these deployments, internal IPv6 nodes are addressed > using IPv4-translatable IPv6 addresses, which enable them to be > accessed by IPv4 nodes. >=20 > I don't see any issue with the current text under such assumption. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Behave [mailto:behave-bounces@ietf.org] De la part de Christian >> Huitema >> Envoy=C3=A9 : dimanche 16 f=C3=A9vrier 2020 21:05 >> =C3=80 : RFC Errata System; congxiao@cernet.edu.cn; = huitema@microsoft.com; >> marcelo@it.uc3m.es; mohamed.boucadair@orange-ftgroup.com; >> xing@cernet.edu.cn; ietf@kuehlewind.net; >> magnus.westerlund@ericsson.com; dwing@cisco.com; = dthaler@microsoft.com >> Cc : jordi.palet@theipv6company.com; behave@ietf.org >> Objet : Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) >>=20 >> Jordi, >>=20 >> The errata process is not the right way to handle this issue. You are >> asking for a change in the specification, and such changes should go >> through the working group, as part of a standard discussion. >>=20 >> To go to the specific technical point: it is indeed completely doable >> to >> use the same /64 prefix for a local subnet and for a NAT service. The >> only requirement is that the NAT be capable to distinguishing between >> a >> translated address and a local address, and that requirement is >> implicit >> in RFC6502. For example, the NAT could reserve <64bit>:dead:beef::/96 >> for the 6to4 service, and use DUD to defend against hosts configuring >> an >> address in the same /64 prefix. That may not be a perfect solution, >> but >> that's something the working group should discuss, not something to = be >> handled summarily through the errata process. >>=20 >> -- Christian Huitema >>=20 >> On 2/15/2020 7:35 PM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC6052, >>> "IPv6 Addressing of IPv4/IPv6 Translators". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid5984 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Jordi Palet Martinez >>>=20 >>> Section: 3.3 >>>=20 >>> Original Text >>> ------------- >>> Organizations deploying stateless IPv4/IPv6 translation SHOULD >> assign a Network-Specific Prefix to their IPv4/IPv6 translation >> service. >>>=20 >>> Corrected Text >>> -------------- >>> Organizations deploying stateless IPv4/IPv6 translation SHOULD >> assign a Network-Specific Prefix for the exclusive use of their >> IPv4/IPv6 translation service. >>>=20 >>> Notes >>> ----- >>> This seems obvious but is not. The NSP must only be used for the >> translation service. If the NSP is used only, for example in an >> enterprise network, in the LANs, and the translator allows it, it may >> create conflicts, as the resulting IPv6 address (NSP+IPv4 address) = may >> be the same as a host inside the LAN has been configured with (either >> manually, or with SLAAC, DHCPv6), etc. >>>=20 >>> It has been confirmed that at least one vendor already realized this >> and the implementation doesn't work if the prefix is used both for = the >> translator service and one of the LANs, but there is no explicit >> documentation on that. So if configured, the box doesn't work, but >> doesn't report is an an "invalid" config. >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC6052 (draft-ietf-behave-address-format-10) >>> -------------------------------------- >>> Title : IPv6 Addressing of IPv4/IPv6 Translators >>> Publication Date : October 2010 >>> Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, >> X. Li >>> Category : PROPOSED STANDARD >>> Source : Behavior Engineering for Hindrance Avoidance >>> Area : Transport >>> Stream : IETF >>> Verifying Party : IESG >>>=20 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 From nobody Mon Feb 17 18:38:55 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A340120853 for ; Mon, 17 Feb 2020 07:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 oNv9QqxWYYdx for ; Mon, 17 Feb 2020 07:51:33 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.71]) (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 44B83120086 for ; Mon, 17 Feb 2020 07:51:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L5VrFVSO7oFzfx+ucVgeL94O1h+lFIsp3DCuTU04+k8Z73Xfdf1FLNKgBRpBewwCSIuMHopAmWTRefIxx7HfQyG+xp2Mt6sbzQq0l3hOLQ++u0NANSenI5tQv9AkTYyYr6kz7OIdPOEKkjGKThhzIwe5dwp/SXLydGq7pVTT1SATyQ9MlHlfzSfzFwNN1MtnTG1zW9cRhJP5upY8mMqdcXu3OurLL3gsxUJwK5NGitq1vD66cjiin/zjgkwfDrWrMrWoEhBdYcBERUItmKx8ApDPjm/NhdTpfoR36gGytKVW4GfY44IOJ1E6DlCJLj40mbLJ5IWCIVIHJOp7is1ztw== 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=co6mlp6aCxcHp3NmnwlJqkq58djbqsbJYWki93c/HPo=; b=cRY5JKo+HqSyp4jjr8qbDmidMXsBfZpZZ48qw7cSjBVsVL6ltwrD8ERjBtWH3GhGz8qbz0ifBBTES/vQ559vKOIvPbt1aYgg86wt6aH/dikDu4UG+ox/6OATn/Eu3RWsHBty5MkrACCZkQg+7lmzFUCYTtYaBiwfeua/DDBwcuASWnwvzUOwoCt2731h6qZ92Sscex5MpLE9uVFLr3dCywyA/ZWexT++TyCsGD0ev0j73SVGCrM2ffbZBErjNmoTTMxzUZChNzVikgh64YSXB8CotEhCZHervEPSmdzTD8/bovAQGiVExo1s7+yVvByzTDjxSVf5vZd2xISSTJbWdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=co6mlp6aCxcHp3NmnwlJqkq58djbqsbJYWki93c/HPo=; b=bs5pVIDf4SrNTGBJoEelM5gDWWsgDWuEzpLtSVgd9+GiB/NYxiMruyReeLPSA+Q6d4VKPrbcEaWL/qSthcl6EIfhehbPlhSEhyIzeV6QMqxMDQ+W5xhCQqehnCKN1XScyFww0GqmQ0pjxNz5ftvGIoE0KKZgodGOEIaM07i5mGA= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB6011.eurprd07.prod.outlook.com (20.178.108.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Mon, 17 Feb 2020 15:51:30 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::5dc9:9b70:83a1:cbfd]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::5dc9:9b70:83a1:cbfd%7]) with mapi id 15.20.2750.016; Mon, 17 Feb 2020 15:51:30 +0000 From: Magnus Westerlund To: "huitema@huitema.net" , "mohamed.boucadair@orange.com" , "ietf@kuehlewind.net" CC: "jordi.palet@theipv6company.com" , "dthaler@microsoft.com" , "behave@ietf.org" , "congxiao@cernet.edu.cn" , "xing@cernet.edu.cn" , "marcelo@it.uc3m.es" , "dwing@cisco.com" , "huitema@microsoft.com" , "mohamed.boucadair@orange-ftgroup.com" Thread-Topic: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) Thread-Index: AQHV5Ho5KX7cRRsL5EG4ih4G2wN306geP7kAgADkqwCAADMngIAAM7qA Date: Mon, 17 Feb 2020 15:51:29 +0000 Message-ID: <403203c107e6472a140409db337c791ff5be13f6.camel@ericsson.com> References: <20200216033519.9D51EF406CE@rfc-editor.org> <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> <73fff6ba-dc6d-4360-ac4d-339265c9a09d@OPEXCAUBM8F.corporate.adroot.infra.ftgroup> <7D8AF4CC-81F6-4238-B6FD-585ED9F4B275@kuehlewind.net> In-Reply-To: <7D8AF4CC-81F6-4238-B6FD-585ED9F4B275@kuehlewind.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e81c9e94-ef40-4bc1-42a8-08d7b3c14137 x-ms-traffictypediagnostic: DB7PR07MB6011: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(189003)(199004)(7416002)(5660300002)(966005)(45080400002)(36756003)(66946007)(91956017)(6512007)(2906002)(478600001)(71200400001)(76116006)(316002)(66446008)(2616005)(4326008)(64756008)(44832011)(54906003)(66616009)(66476007)(66556008)(8676002)(81166006)(81156014)(110136005)(26005)(53546011)(8936002)(6486002)(66574012)(186003)(6506007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB6011; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HotcAXu5IJOmHVmfJ4J67O6EBqV+JKpgaJjw18evyhU5tAba+jFHg1mLQIhbHOitVu50Upqx3qKQv+F6pToQ/voZeRs6XRDPBCS8l2Vov3EVwJFzXp+p6cv4niYxBFWY8xnfOBaHai/NLPFe2pAyPdoXkXGMz3qGXiJOljNgpgNtm8sLPThoFt3fHj172zvBC60mwpH505Ql46195/0JJe0tazSacKPhG1+CnmSLZwMFT/EBP293X0G9VHflkM7GrQA0rKgB5v4WV62YQGcazkTKU9sJ0XtrcLe5XBX1BdNI/3pKncDJglZ67iRoyzvbCVb6mU0DP07//k0+CJ3uPQCnxICDt99xnqCx3eCJs+j5kTn+rhEw+zh+xc6hTlSUyHPN2b3xU4FIYwG6G8JO/D4ECUWiEpd5lXY/jxxpwqXG/mepObdfal15jmzetQA3SLIlp0UhMYepJmGXUJN8jgmMhW8McSvhRasjttjW7jlsyFvh2BBd/IeKpv8utVI9k0vgfvV1KUNiRzRnTETFjQ== x-ms-exchange-antispam-messagedata: PA5VIGK5vFgJWyuttB29T1nq5I0JwmmhIip9ZHahSN37zskZXhD8U2mEms/qhel2z8fNJVvqgqIwRZghBt0DXIBcaI3Q7xhW3ZHdzZMvJGNUO9/clk4sIPfG/QZOP9Y6plU6GVDR9JOrkRMkRVbPBg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-f67dnYYHhoKSwErPzUg9" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e81c9e94-ef40-4bc1-42a8-08d7b3c14137 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 15:51:29.9225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a7MEpNJUn60nfqWBK3b9uMck6g0mKum2aMnkMPG4SZyWiMLlYp04XIpg/u/NGUvhBFbmaS6ckxOShDRbV4SkSay/Z4lFJ4YH8ySUuw+l114= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6011 Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 15:51:46 -0000 --=-f67dnYYHhoKSwErPzUg9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have already rejected it on the grounds that what is proposed is not some= thing unclear or that gets wrongly interpreted of what is intended. The proposed behavior appears to me also to be within what is allowed by the specificati= on. So it is really only a proposal for further guidance. Something that may be relevant, but only if a new version of the document is defined. Maybe this should be changed for Hold for document update.=20 Cheers Magnus On Mon, 2020-02-17 at 13:46 +0100, Mirja Kuehlewind wrote: > Hi all, >=20 > I agree that this is probably not an errata. However, we could mark this = as > =E2=80=9CHold for next Document Update=E2=80=9D? I guess if there every w= ill be an update, > this need further discussion, however, having it in the errata system can= help > to remember it. Or do think people it should just be rejected for now? >=20 > Mirja >=20 >=20 >=20 > > On 17. Feb 2020, at 10:43, < > > mohamed.boucadair@orange.com> wrote: > >=20 > > Hi all,=20 > >=20 > > One further comment: the assumption we have for "stateless translation"= is > > as follows > >=20 > > In these deployments, internal IPv6 nodes are addressed > > using IPv4-translatable IPv6 addresses, which enable them to be > > accessed by IPv4 nodes. > >=20 > > I don't see any issue with the current text under such assumption. > >=20 > > Cheers, > > Med > >=20 > > > -----Message d'origine----- > > > De : Behave [mailto:behave-bounces@ietf.org] De la part de Christian > > > Huitema > > > Envoy=C3=A9 : dimanche 16 f=C3=A9vrier 2020 21:05 > > > =C3=80 : RFC Errata System; congxiao@cernet.edu.cn; huitema@microsoft= .com; > > > marcelo@it.uc3m.es; mohamed.boucadair@orange-ftgroup.com; > > > xing@cernet.edu.cn; ietf@kuehlewind.net; > > > magnus.westerlund@ericsson.com; dwing@cisco.com; dthaler@microsoft.co= m > > > Cc : jordi.palet@theipv6company.com; behave@ietf.org > > > Objet : Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) > > >=20 > > > Jordi, > > >=20 > > > The errata process is not the right way to handle this issue. You are > > > asking for a change in the specification, and such changes should go > > > through the working group, as part of a standard discussion. > > >=20 > > > To go to the specific technical point: it is indeed completely doable > > > to > > > use the same /64 prefix for a local subnet and for a NAT service. The > > > only requirement is that the NAT be capable to distinguishing between > > > a > > > translated address and a local address, and that requirement is > > > implicit > > > in RFC6502. For example, the NAT could reserve <64bit>:dead:beef::/96 > > > for the 6to4 service, and use DUD to defend against hosts configuring > > > an > > > address in the same /64 prefix. That may not be a perfect solution, > > > but > > > that's something the working group should discuss, not something to b= e > > > handled summarily through the errata process. > > >=20 > > > -- Christian Huitema > > >=20 > > > On 2/15/2020 7:35 PM, RFC Errata System wrote: > > > > The following errata report has been submitted for RFC6052, > > > > "IPv6 Addressing of IPv4/IPv6 Translators". > > > >=20 > > > > -------------------------------------- > > > > You may review the report below and at: > > > >=20 https://protect2.fireeye.com/v1/url?k=3D244c0d64-7898013a-244c4dff-8691959e= d9b7-c65f53b92dad5084&q=3D1&e=3Df4738ef5-d2a3-4f09-87e8-099582e1d0ef&u=3Dht= tps%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5984 > > > >=20 > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Jordi Palet Martinez > > > >=20 > > > > Section: 3.3 > > > >=20 > > > > Original Text > > > > ------------- > > > > Organizations deploying stateless IPv4/IPv6 translation SHOULD > > >=20 > > > assign a Network-Specific Prefix to their IPv4/IPv6 translation > > > service. > > > >=20 > > > > Corrected Text > > > > -------------- > > > > Organizations deploying stateless IPv4/IPv6 translation SHOULD > > >=20 > > > assign a Network-Specific Prefix for the exclusive use of their > > > IPv4/IPv6 translation service. > > > >=20 > > > > Notes > > > > ----- > > > > This seems obvious but is not. The NSP must only be used for the > > >=20 > > > translation service. If the NSP is used only, for example in an > > > enterprise network, in the LANs, and the translator allows it, it may > > > create conflicts, as the resulting IPv6 address (NSP+IPv4 address) ma= y > > > be the same as a host inside the LAN has been configured with (either > > > manually, or with SLAAC, DHCPv6), etc. > > > >=20 > > > > It has been confirmed that at least one vendor already realized thi= s > > >=20 > > > and the implementation doesn't work if the prefix is used both for th= e > > > translator service and one of the LANs, but there is no explicit > > > documentation on that. So if configured, the box doesn't work, but > > > doesn't report is an an "invalid" config. > > > >=20 > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, pleas= e > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party > > > > can log in to change the status and edit the report, if necessary. > > > >=20 > > > > -------------------------------------- > > > > RFC6052 (draft-ietf-behave-address-format-10) > > > > -------------------------------------- > > > > Title : IPv6 Addressing of IPv4/IPv6 Translators > > > > Publication Date : October 2010 > > > > Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, > > >=20 > > > X. Li > > > > Category : PROPOSED STANDARD > > > > Source : Behavior Engineering for Hindrance Avoidance > > > > Area : Transport > > > > Stream : IETF > > > > Verifying Party : IESG > > > >=20 > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > >=20 > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-f67dnYYHhoKSwErPzUg9 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIxNzE1NTEyN1owLwYJKoZIhvcN AQkEMSIEIOQEQ3HhpDiiOzZRiRWiRcxrwo1DGuI3jPBzY7EyuTpQMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAGgrLtJZd6BUN aIrYT9vyfVFYN4yTONpH9/9hgXXFSYztLKarjZ3xgW45Ov5D9AKcQBr7Yl3MLzaPwOmqRZrSe46N 0gqH3H8ctmhx/uypzXLVrPJBNyJ2X44a+jjuLmVsKyetS6QUCmvgWtutAKv35ExXe/xbwampMDhK 0pzuK6FRW6ghufpBYsvoZW7VTMZn4gZ+UYBRkTe9oH1qa4o+o25KvlzsjHfn+2imu7h6j/N0B1Z5 3xrbfzPDG+7zWM7nefhHBQSjZEPaY8+tpKgExIOAxR45jXtmbtSncB5DC4qdKjBXoEhd3b1Z6XvU ZgSPahmZIGqCZ1g9PxWhrYgwaQAAAAAAAA== --=-f67dnYYHhoKSwErPzUg9-- From nobody Mon Feb 17 19:23:00 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43DD1200C5 for ; Mon, 17 Feb 2020 19:22:58 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 aDVWcISOb-RX for ; Mon, 17 Feb 2020 19:22:55 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C1E1200A3 for ; Mon, 17 Feb 2020 19:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1581996147; x=1582600947; 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=33BylefqueNMgoZL/2sA6oyuCgCgbZ30fJD8YP7luHY=; b=Fth4olTIjmYCg rNkmt7odUM7dzk/EUvXuBgZfRT3YwwrINPFSYh2vpwMsPDh2fRIZLNp/bCwImZ25 RJuA0xGHBhTumw7w6kLx4sBmTDwrJ0Z62PZxrwCTSv82UZBFx3j4l5ZU4XfMov8A 5Yt+SxqYZByehomEGBC/wq9findnFE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 18 Feb 2020 04:22:27 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 18 Feb 2020 04:22:26 +0100 Received: from [220.247.146.70] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000061943.msg for ; Tue, 18 Feb 2020 04:22:24 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [220.247.146.70] X-MDArrival-Date: Tue, 18 Feb 2020 04:22:24 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=131740a8d0=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: behave@ietf.org User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Tue, 18 Feb 2020 14:22:03 +1100 From: JORDI PALET MARTINEZ To: Magnus Westerlund , "huitema@huitema.net" , "mohamed.boucadair@orange.com" , "ietf@kuehlewind.net" CC: "congxiao@cernet.edu.cn" , "behave@ietf.org" , "mohamed.boucadair@orange-ftgroup.com" , "dthaler@microsoft.com" , "xing@cernet.edu.cn" , "dwing@cisco.com" , "huitema@microsoft.com" Message-ID: <2CE85161-C5F4-4737-B1D7-D44FF830C531@consulintel.es> Thread-Topic: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) References: <20200216033519.9D51EF406CE@rfc-editor.org> <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> <73fff6ba-dc6d-4360-ac4d-339265c9a09d@OPEXCAUBM8F.corporate.adroot.infra.ftgroup> <7D8AF4CC-81F6-4238-B6FD-585ED9F4B275@kuehlewind.net> <403203c107e6472a140409db337c791ff5be13f6.camel@ericsson.com> In-Reply-To: <403203c107e6472a140409db337c791ff5be13f6.camel@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 03:22:59 -0000 Just to respond in a single email. I've read Christian, Med, and Mirja emails. Happy with that and I agree, if= we need to fix it, it should be a new version. Clearly it may be a misinterpretation of the actual document at least from = one vendor implementation, as they don't allow it. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 18/2/20 2:52, "Behave en nombre de Magnus Westerlund" escribi=C3=B3: Hi, =20 I have already rejected it on the grounds that what is proposed is not = something unclear or that gets wrongly interpreted of what is intended. The propo= sed behavior appears to me also to be within what is allowed by the specifi= cation. So it is really only a proposal for further guidance. Something that ma= y be relevant, but only if a new version of the document is defined. Maybe t= his should be changed for Hold for document update.=20 =20 =20 Cheers =20 Magnus =20 On Mon, 2020-02-17 at 13:46 +0100, Mirja Kuehlewind wrote: > Hi all, >=20 > I agree that this is probably not an errata. However, we could mark t= his as > =E2=80=9CHold for next Document Update=E2=80=9D? I guess if there eve= ry will be an update, > this need further discussion, however, having it in the errata system= can help > to remember it. Or do think people it should just be rejected for now= ? >=20 > Mirja >=20 >=20 >=20 > > On 17. Feb 2020, at 10:43, < > > mohamed.boucadair@orange.com> wrote: > >=20 > > Hi all,=20 > >=20 > > One further comment: the assumption we have for "stateless translat= ion" is > > as follows > >=20 > > In these deployments, internal IPv6 nodes are addressed > > using IPv4-translatable IPv6 addresses, which enable them to be > > accessed by IPv4 nodes. > >=20 > > I don't see any issue with the current text under such assumption. > >=20 > > Cheers, > > Med > >=20 > > > -----Message d'origine----- > > > De : Behave [mailto:behave-bounces@ietf.org] De la part de Christ= ian > > > Huitema > > > Envoy=C3=A9 : dimanche 16 f=C3=A9vrier 2020 21:05 > > > =C3=80 : RFC Errata System; congxiao@cernet.edu.cn; huitema@micro= soft..com; > > > marcelo@it.uc3m.es; mohamed.boucadair@orange-ftgroup.com; > > > xing@cernet.edu.cn; ietf@kuehlewind.net; > > > magnus.westerlund@ericsson.com; dwing@cisco.com; dthaler@microsof= t.com > > > Cc : jordi.palet@theipv6company.com; behave@ietf.org > > > Objet : Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) > > >=20 > > > Jordi, > > >=20 > > > The errata process is not the right way to handle this issue. You= are > > > asking for a change in the specification, and such changes should= go > > > through the working group, as part of a standard discussion. > > >=20 > > > To go to the specific technical point: it is indeed completely do= able > > > to > > > use the same /64 prefix for a local subnet and for a NAT service.= The > > > only requirement is that the NAT be capable to distinguishing bet= ween > > > a > > > translated address and a local address, and that requirement is > > > implicit > > > in RFC6502. For example, the NAT could reserve <64bit>:dead:beef:= :/96 > > > for the 6to4 service, and use DUD to defend against hosts configu= ring > > > an > > > address in the same /64 prefix. That may not be a perfect solutio= n, > > > but > > > that's something the working group should discuss, not something = to be > > > handled summarily through the errata process. > > >=20 > > > -- Christian Huitema > > >=20 > > > On 2/15/2020 7:35 PM, RFC Errata System wrote: > > > > The following errata report has been submitted for RFC6052, > > > > "IPv6 Addressing of IPv4/IPv6 Translators". > > > >=20 > > > > -------------------------------------- > > > > You may review the report below and at: > > > >=20 https://protect2.fireeye.com/v1/url?k=3D244c0d64-7898013a-244c4dff-8691= 959ed9b7-c65f53b92dad5084&q=3D1&e=3Df4738ef5-d2a3-4f09-87e8-099582e1d0ef&u= =3Dhttps%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5984 > > > >=20 > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Jordi Palet Martinez > > > >=20 > > > > Section: 3.3 > > > >=20 > > > > Original Text > > > > ------------- > > > > Organizations deploying stateless IPv4/IPv6 translation SHOULD > > >=20 > > > assign a Network-Specific Prefix to their IPv4/IPv6 translation > > > service. > > > >=20 > > > > Corrected Text > > > > -------------- > > > > Organizations deploying stateless IPv4/IPv6 translation SHOULD > > >=20 > > > assign a Network-Specific Prefix for the exclusive use of their > > > IPv4/IPv6 translation service. > > > >=20 > > > > Notes > > > > ----- > > > > This seems obvious but is not. The NSP must only be used for th= e > > >=20 > > > translation service. If the NSP is used only, for example in an > > > enterprise network, in the LANs, and the translator allows it, it= may > > > create conflicts, as the resulting IPv6 address (NSP+IPv4 address= ) may > > > be the same as a host inside the LAN has been configured with (ei= ther > > > manually, or with SLAAC, DHCPv6), etc. > > > >=20 > > > > It has been confirmed that at least one vendor already realized= this > > >=20 > > > and the implementation doesn't work if the prefix is used both fo= r the > > > translator service and one of the LANs, but there is no explicit > > > documentation on that. So if configured, the box doesn't work, bu= t > > > doesn't report is an an "invalid" config. > > > >=20 > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, p= lease > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party > > > > can log in to change the status and edit the report, if necessa= ry. > > > >=20 > > > > -------------------------------------- > > > > RFC6052 (draft-ietf-behave-address-format-10) > > > > -------------------------------------- > > > > Title : IPv6 Addressing of IPv4/IPv6 Translators > > > > Publication Date : October 2010 > > > > Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucad= air, > > >=20 > > > X. Li > > > > Category : PROPOSED STANDARD > > > > Source : Behavior Engineering for Hindrance Avoida= nce > > > > Area : Transport > > > > Stream : IETF > > > > Verifying Party : IESG > > > >=20 > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > >=20 > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 --=20 Cheers =20 Magnus Westerlund=20 =20 =20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- =20 =20 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave =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 Mon Feb 17 22:50:49 2020 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8671200D8 for ; Mon, 17 Feb 2020 22:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 xb1qGQcbEj7Y for ; Mon, 17 Feb 2020 22:50:46 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E9E1200B5 for ; Mon, 17 Feb 2020 22:50:45 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48MBM73M15z2y0q; Tue, 18 Feb 2020 07:50:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582008643; bh=fEKp2sZsrentAIqiI+RUBS3blVPAKSwlFeX4N+O1Ac8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JXI1y9jQGHUqt1uE9ygL5xuwPlSgl8/r+Rg9fln5dmF9zVfyhprwsGVrv37IUWxrF dJeKFpVSBwPuVJzpTxQSgSe4xiNyvtWondl6s6hRSpdxGl/fP5BVAT5hF4bqXJrkku hy65CCNx3iHZJpZCbEZUBVNzqC9Qm4FKKKaC3oiSoWmiMEzD7V1aq5VrGGivVeAdb4 kvX3x2xgSXh1UbMX5W3jhF03SAW4iogA1n0I9ewUvTxGtITRhqWlTIVOWy2oFu720A +En6AUxN8Yd5Uy7b7ppsbbmqERv+plwpwBVn9Ohtqi6PDRZgl9XXY8rBDhKi2vLJqG 6bCaG/g0sjvLA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48MBM70yRQzBrM1; Tue, 18 Feb 2020 07:50:43 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Tue, 18 Feb 2020 07:50:38 +0100 From: To: Magnus Westerlund , "huitema@huitema.net" , "ietf@kuehlewind.net" CC: "jordi.palet@theipv6company.com" , "dthaler@microsoft.com" , "behave@ietf.org" , "congxiao@cernet.edu.cn" , "xing@cernet.edu.cn" , "marcelo@it.uc3m.es" , "dwing@cisco.com" , "huitema@microsoft.com" , "mohamed.boucadair@orange-ftgroup.com" Thread-Topic: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) Thread-Index: AQHV5Ho1i5WTlqabqkO/th8ePGNftKgeLvYAgADvV5CAACh7gIAAM7yAgAEK8LA= Date: Tue, 18 Feb 2020 06:50:38 +0000 Message-ID: <5c6a39f2-ca23-4e6f-837f-9d2e3e784291@OPEXCAUBMA1.corporate.adroot.infra.ftgroup> References: <20200216033519.9D51EF406CE@rfc-editor.org> <4bbe1633-3313-bdfb-8bb8-6d2ad571c724@huitema.net> <73fff6ba-dc6d-4360-ac4d-339265c9a09d@OPEXCAUBM8F.corporate.adroot.infra.ftgroup> <7D8AF4CC-81F6-4238-B6FD-585ED9F4B275@kuehlewind.net> <403203c107e6472a140409db337c791ff5be13f6.camel@ericsson.com> In-Reply-To: <403203c107e6472a140409db337c791ff5be13f6.camel@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 06:50:48 -0000 SGkgTWFnbnVzLCBhbGwsDQoNCkkgZG8gYWdyZWUgd2l0aCByZWplY3RpbmcgdGhlIGVycmF0YSAo cmF0aGVyIHRoYXQgaG9sZCBmb3IgZG9jdW1lbnQgdXBkYXRlKS4gDQoNCklNTywgdGhlcmUgaXMg bm8gY29uZnVzaW9uIHVuZGVyIHRoZSBhc3N1bXB0aW9uIG9mIFNlY3Rpb24gMy4zICgiaW50ZXJu YWwgSVB2NiBub2RlcyBhcmUgYWRkcmVzc2VkIHVzaW5nIElQdjQtdHJhbnNsYXRhYmxlIElQdjYg YWRkcmVzc2VzIikuIE1heSBiZSB5b3UgbWF5IGNvbnNpZGVyIHVwZGF0aW5nIHRoZSAidmVyaWZp ZXIgbm90ZSIgdG8gcG9pbnQgdG8gdGhhdCBwYXJ0LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1hZ251cyBXZXN0ZXJsdW5kIFttYWls dG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDE3 IGbDqXZyaWVyIDIwMjAgMTY6NTENCj4gw4DCoDogaHVpdGVtYUBodWl0ZW1hLm5ldDsgQk9VQ0FE QUlSIE1vaGFtZWQgVEdJL09MTjsNCj4gaWV0ZkBrdWVobGV3aW5kLm5ldA0KPiBDY8KgOiBqb3Jk aS5wYWxldEB0aGVpcHY2Y29tcGFueS5jb207IGR0aGFsZXJAbWljcm9zb2Z0LmNvbTsNCj4gYmVo YXZlQGlldGYub3JnOyBjb25neGlhb0BjZXJuZXQuZWR1LmNuOyB4aW5nQGNlcm5ldC5lZHUuY247 DQo+IG1hcmNlbG9AaXQudWMzbS5lczsgZHdpbmdAY2lzY28uY29tOyBodWl0ZW1hQG1pY3Jvc29m dC5jb207DQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS1mdGdyb3VwLmNvbQ0KPiBPYmpldMKg OiBSZTogW0JFSEFWRV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzYwNTIgKDU5ODQp DQo+IA0KPiBIaSwNCj4gDQo+IEkgaGF2ZSBhbHJlYWR5IHJlamVjdGVkIGl0IG9uIHRoZSBncm91 bmRzIHRoYXQgd2hhdCBpcyBwcm9wb3NlZCBpcyBub3QNCj4gc29tZXRoaW5nDQo+IHVuY2xlYXIg b3IgdGhhdCBnZXRzIHdyb25nbHkgaW50ZXJwcmV0ZWQgb2Ygd2hhdCBpcyBpbnRlbmRlZC4gVGhl DQo+IHByb3Bvc2VkDQo+IGJlaGF2aW9yIGFwcGVhcnMgdG8gbWUgYWxzbyB0byBiZSB3aXRoaW4g d2hhdCBpcyBhbGxvd2VkIGJ5IHRoZQ0KPiBzcGVjaWZpY2F0aW9uLg0KPiBTbyBpdCBpcyByZWFs bHkgb25seSBhIHByb3Bvc2FsIGZvciBmdXJ0aGVyIGd1aWRhbmNlLiBTb21ldGhpbmcgdGhhdA0K PiBtYXkgYmUNCj4gcmVsZXZhbnQsIGJ1dCBvbmx5IGlmIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRv Y3VtZW50IGlzIGRlZmluZWQuIE1heWJlDQo+IHRoaXMNCj4gc2hvdWxkIGJlIGNoYW5nZWQgZm9y IEhvbGQgZm9yIGRvY3VtZW50IHVwZGF0ZS4NCj4gDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251 cw0KPiANCj4gT24gTW9uLCAyMDIwLTAyLTE3IGF0IDEzOjQ2ICswMTAwLCBNaXJqYSBLdWVobGV3 aW5kIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IEkgYWdyZWUgdGhhdCB0aGlzIGlzIHBy b2JhYmx5IG5vdCBhbiBlcnJhdGEuIEhvd2V2ZXIsIHdlIGNvdWxkIG1hcmsNCj4gdGhpcyBhcw0K PiA+IOKAnEhvbGQgZm9yIG5leHQgRG9jdW1lbnQgVXBkYXRl4oCdPyBJIGd1ZXNzIGlmIHRoZXJl IGV2ZXJ5IHdpbGwgYmUgYW4NCj4gdXBkYXRlLA0KPiA+IHRoaXMgbmVlZCBmdXJ0aGVyIGRpc2N1 c3Npb24sIGhvd2V2ZXIsIGhhdmluZyBpdCBpbiB0aGUgZXJyYXRhDQo+IHN5c3RlbSBjYW4gaGVs cA0KPiA+IHRvIHJlbWVtYmVyIGl0LiBPciBkbyB0aGluayBwZW9wbGUgaXQgc2hvdWxkIGp1c3Qg YmUgcmVqZWN0ZWQgZm9yDQo+IG5vdz8NCj4gPg0KPiA+IE1pcmphDQo+ID4NCj4gPg0KPiA+DQo+ ID4gPiBPbiAxNy4gRmViIDIwMjAsIGF0IDEwOjQzLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4gPA0KPiA+ID4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4g Pg0KPiA+ID4gSGkgYWxsLA0KPiA+ID4NCj4gPiA+IE9uZSBmdXJ0aGVyIGNvbW1lbnQ6IHRoZSBh c3N1bXB0aW9uIHdlIGhhdmUgZm9yICJzdGF0ZWxlc3MNCj4gdHJhbnNsYXRpb24iIGlzDQo+ID4g PiBhcyBmb2xsb3dzDQo+ID4gPg0KPiA+ID4gICBJbiB0aGVzZSBkZXBsb3ltZW50cywgaW50ZXJu YWwgSVB2NiBub2RlcyBhcmUgYWRkcmVzc2VkDQo+ID4gPiAgIHVzaW5nIElQdjQtdHJhbnNsYXRh YmxlIElQdjYgYWRkcmVzc2VzLCB3aGljaCBlbmFibGUgdGhlbSB0byBiZQ0KPiA+ID4gICBhY2Nl c3NlZCBieSBJUHY0IG5vZGVzLg0KPiA+ID4NCj4gPiA+IEkgZG9uJ3Qgc2VlIGFueSBpc3N1ZSB3 aXRoIHRoZSBjdXJyZW50IHRleHQgdW5kZXIgc3VjaCBhc3N1bXB0aW9uLg0KPiA+ID4NCj4gPiA+ IENoZWVycywNCj4gPiA+IE1lZA0KPiA+ID4NCj4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+ID4gPiA+IERlIDogQmVoYXZlIFttYWlsdG86YmVoYXZlLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUNCj4gQ2hyaXN0aWFuDQo+ID4gPiA+IEh1aXRlbWENCj4gPiA+ID4g RW52b3nDqSA6IGRpbWFuY2hlIDE2IGbDqXZyaWVyIDIwMjAgMjE6MDUNCj4gPiA+ID4gw4AgOiBS RkMgRXJyYXRhIFN5c3RlbTsgY29uZ3hpYW9AY2VybmV0LmVkdS5jbjsNCj4gaHVpdGVtYUBtaWNy b3NvZnQuY29tOw0KPiA+ID4gPiBtYXJjZWxvQGl0LnVjM20uZXM7IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS1mdGdyb3VwLmNvbTsNCj4gPiA+ID4geGluZ0BjZXJuZXQuZWR1LmNuOyBpZXRmQGt1 ZWhsZXdpbmQubmV0Ow0KPiA+ID4gPiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb207IGR3 aW5nQGNpc2NvLmNvbTsNCj4gZHRoYWxlckBtaWNyb3NvZnQuY29tDQo+ID4gPiA+IENjIDogam9y ZGkucGFsZXRAdGhlaXB2NmNvbXBhbnkuY29tOyBiZWhhdmVAaWV0Zi5vcmcNCj4gPiA+ID4gT2Jq ZXQgOiBSZTogW0JFSEFWRV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzYwNTIgKDU5 ODQpDQo+ID4gPiA+DQo+ID4gPiA+IEpvcmRpLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgZXJyYXRh IHByb2Nlc3MgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gaGFuZGxlIHRoaXMgaXNzdWUuDQo+IFlv dSBhcmUNCj4gPiA+ID4gYXNraW5nIGZvciBhIGNoYW5nZSBpbiB0aGUgc3BlY2lmaWNhdGlvbiwg YW5kIHN1Y2ggY2hhbmdlcw0KPiBzaG91bGQgZ28NCj4gPiA+ID4gdGhyb3VnaCB0aGUgd29ya2lu ZyBncm91cCwgYXMgcGFydCBvZiBhIHN0YW5kYXJkIGRpc2N1c3Npb24uDQo+ID4gPiA+DQo+ID4g PiA+IFRvIGdvIHRvIHRoZSBzcGVjaWZpYyB0ZWNobmljYWwgcG9pbnQ6IGl0IGlzIGluZGVlZCBj b21wbGV0ZWx5DQo+IGRvYWJsZQ0KPiA+ID4gPiB0bw0KPiA+ID4gPiB1c2UgdGhlIHNhbWUgLzY0 IHByZWZpeCBmb3IgYSBsb2NhbCBzdWJuZXQgYW5kIGZvciBhIE5BVA0KPiBzZXJ2aWNlLiBUaGUN Cj4gPiA+ID4gb25seSByZXF1aXJlbWVudCBpcyB0aGF0IHRoZSBOQVQgYmUgY2FwYWJsZSB0byBk aXN0aW5ndWlzaGluZw0KPiBiZXR3ZWVuDQo+ID4gPiA+IGENCj4gPiA+ID4gdHJhbnNsYXRlZCBh ZGRyZXNzIGFuZCBhIGxvY2FsIGFkZHJlc3MsIGFuZCB0aGF0IHJlcXVpcmVtZW50IGlzDQo+ID4g PiA+IGltcGxpY2l0DQo+ID4gPiA+IGluIFJGQzY1MDIuIEZvciBleGFtcGxlLCB0aGUgTkFUIGNv dWxkIHJlc2VydmUNCj4gPDY0Yml0PjpkZWFkOmJlZWY6Oi85Ng0KPiA+ID4gPiBmb3IgdGhlIDZ0 bzQgc2VydmljZSwgYW5kIHVzZSBEVUQgdG8gZGVmZW5kIGFnYWluc3QgaG9zdHMNCj4gY29uZmln dXJpbmcNCj4gPiA+ID4gYW4NCj4gPiA+ID4gYWRkcmVzcyBpbiB0aGUgc2FtZSAvNjQgcHJlZml4 LiBUaGF0IG1heSBub3QgYmUgYSBwZXJmZWN0DQo+IHNvbHV0aW9uLA0KPiA+ID4gPiBidXQNCj4g PiA+ID4gdGhhdCdzIHNvbWV0aGluZyB0aGUgd29ya2luZyBncm91cCBzaG91bGQgZGlzY3Vzcywg bm90IHNvbWV0aGluZw0KPiB0byBiZQ0KPiA+ID4gPiBoYW5kbGVkIHN1bW1hcmlseSB0aHJvdWdo IHRoZSBlcnJhdGEgcHJvY2Vzcy4NCj4gPiA+ID4NCj4gPiA+ID4gLS0gQ2hyaXN0aWFuIEh1aXRl bWENCj4gPiA+ID4NCj4gPiA+ID4gT24gMi8xNS8yMDIwIDc6MzUgUE0sIFJGQyBFcnJhdGEgU3lz dGVtIHdyb3RlOg0KPiA+ID4gPiA+IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVl biBzdWJtaXR0ZWQgZm9yIFJGQzYwNTIsDQo+ID4gPiA+ID4gIklQdjYgQWRkcmVzc2luZyBvZiBJ UHY0L0lQdjYgVHJhbnNsYXRvcnMiLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiBZb3UgbWF5IHJldmlldyB0aGUg cmVwb3J0IGJlbG93IGFuZCBhdDoNCj4gPiA+ID4gPg0KPiBodHRwczovL3Byb3RlY3QyLmZpcmVl eWUuY29tL3YxL3VybD9rPTI0NGMwZDY0LTc4OTgwMTNhLTI0NGM0ZGZmLQ0KPiA4NjkxOTU5ZWQ5 YjctYzY1ZjUzYjkyZGFkNTA4NCZxPTEmZT1mNDczOGVmNS1kMmEzLTRmMDktODdlOC0NCj4gMDk5 NTgyZTFkMGVmJnU9aHR0cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZlcnJhdGElMkZl aWQ1OTg0DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+ID4gPiA+IFR5cGU6IFRlY2huaWNhbA0KPiA+ID4gPiA+IFJlcG9ydGVk IGJ5OiBKb3JkaSBQYWxldCBNYXJ0aW5leg0KPiA8am9yZGkucGFsZXRAdGhlaXB2NmNvbXBhbnku Y29tPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU2VjdGlvbjogMy4zDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBPcmlnaW5hbCBUZXh0DQo+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+IE9y Z2FuaXphdGlvbnMgZGVwbG95aW5nIHN0YXRlbGVzcyBJUHY0L0lQdjYgdHJhbnNsYXRpb24gU0hP VUxEDQo+ID4gPiA+DQo+ID4gPiA+IGFzc2lnbiBhIE5ldHdvcmstU3BlY2lmaWMgUHJlZml4IHRv IHRoZWlyIElQdjQvSVB2NiB0cmFuc2xhdGlvbg0KPiA+ID4gPiBzZXJ2aWNlLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gQ29ycmVjdGVkIFRleHQNCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLQ0KPiA+ ID4gPiA+IE9yZ2FuaXphdGlvbnMgZGVwbG95aW5nIHN0YXRlbGVzcyBJUHY0L0lQdjYgdHJhbnNs YXRpb24gU0hPVUxEDQo+ID4gPiA+DQo+ID4gPiA+IGFzc2lnbiBhIE5ldHdvcmstU3BlY2lmaWMg UHJlZml4IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGVpcg0KPiA+ID4gPiBJUHY0L0lQdjYg dHJhbnNsYXRpb24gc2VydmljZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE5vdGVzDQo+ID4gPiA+ ID4gLS0tLS0NCj4gPiA+ID4gPiBUaGlzIHNlZW1zIG9idmlvdXMgYnV0IGlzIG5vdC4gVGhlIE5T UCBtdXN0IG9ubHkgYmUgdXNlZCBmb3INCj4gdGhlDQo+ID4gPiA+DQo+ID4gPiA+IHRyYW5zbGF0 aW9uIHNlcnZpY2UuIElmIHRoZSBOU1AgaXMgdXNlZCBvbmx5LCBmb3IgZXhhbXBsZSBpbiBhbg0K PiA+ID4gPiBlbnRlcnByaXNlIG5ldHdvcmssIGluIHRoZSBMQU5zLCBhbmQgdGhlIHRyYW5zbGF0 b3IgYWxsb3dzIGl0LA0KPiBpdCBtYXkNCj4gPiA+ID4gY3JlYXRlIGNvbmZsaWN0cywgYXMgdGhl IHJlc3VsdGluZyBJUHY2IGFkZHJlc3MgKE5TUCtJUHY0DQo+IGFkZHJlc3MpIG1heQ0KPiA+ID4g PiBiZSB0aGUgc2FtZSBhcyBhIGhvc3QgaW5zaWRlIHRoZSBMQU4gaGFzIGJlZW4gY29uZmlndXJl ZCB3aXRoDQo+IChlaXRoZXINCj4gPiA+ID4gbWFudWFsbHksIG9yIHdpdGggU0xBQUMsIERIQ1B2 NiksIGV0Yy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEl0IGhhcyBiZWVuIGNvbmZpcm1lZCB0aGF0 IGF0IGxlYXN0IG9uZSB2ZW5kb3IgYWxyZWFkeQ0KPiByZWFsaXplZCB0aGlzDQo+ID4gPiA+DQo+ ID4gPiA+IGFuZCB0aGUgaW1wbGVtZW50YXRpb24gZG9lc24ndCB3b3JrIGlmIHRoZSBwcmVmaXgg aXMgdXNlZCBib3RoDQo+IGZvciB0aGUNCj4gPiA+ID4gdHJhbnNsYXRvciBzZXJ2aWNlIGFuZCBv bmUgb2YgdGhlIExBTnMsIGJ1dCB0aGVyZSBpcyBubyBleHBsaWNpdA0KPiA+ID4gPiBkb2N1bWVu dGF0aW9uIG9uIHRoYXQuIFNvIGlmIGNvbmZpZ3VyZWQsIHRoZSBib3ggZG9lc24ndCB3b3JrLA0K PiBidXQNCj4gPiA+ID4gZG9lc24ndCByZXBvcnQgaXMgYW4gYW4gImludmFsaWQiIGNvbmZpZy4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluc3RydWN0aW9uczoNCj4gPiA+ID4gPiAtLS0tLS0tLS0t LS0tDQo+ID4gPiA+ID4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9y dGVkIi4gSWYgbmVjZXNzYXJ5LA0KPiBwbGVhc2UNCj4gPiA+ID4gPiB1c2UgIlJlcGx5IEFsbCIg dG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiA+ID4gPiA+IHJl amVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eQ0K PiA+ID4gPiA+IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJl cG9ydCwgaWYNCj4gbmVjZXNzYXJ5Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiBSRkM2MDUyIChkcmFmdC1pZXRm LWJlaGF2ZS1hZGRyZXNzLWZvcm1hdC0xMCkNCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+IFRpdGxlICAgICAgICAgICAgICAgOiBJUHY2 IEFkZHJlc3Npbmcgb2YgSVB2NC9JUHY2IFRyYW5zbGF0b3JzDQo+ID4gPiA+ID4gUHVibGljYXRp b24gRGF0ZSAgICA6IE9jdG9iZXIgMjAxMA0KPiA+ID4gPiA+IEF1dGhvcihzKSAgICAgICAgICAg OiBDLiBCYW8sIEMuIEh1aXRlbWEsIE0uIEJhZ251bG8sIE0uDQo+IEJvdWNhZGFpciwNCj4gPiA+ ID4NCj4gPiA+ID4gWC4gTGkNCj4gPiA+ID4gPiBDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9T RUQgU1RBTkRBUkQNCj4gPiA+ID4gPiBTb3VyY2UgICAgICAgICAgICAgIDogQmVoYXZpb3IgRW5n aW5lZXJpbmcgZm9yIEhpbmRyYW5jZQ0KPiBBdm9pZGFuY2UNCj4gPiA+ID4gPiBBcmVhICAgICAg ICAgICAgICAgIDogVHJhbnNwb3J0DQo+ID4gPiA+ID4gU3RyZWFtICAgICAgICAgICAgICA6IElF VEYNCj4gPiA+ID4gPiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+ID4gPiBCZWhhdmUgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gQmVoYXZlQGlldGYub3JnDQo+ ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCj4g PiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+ID4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBCZWhhdmVAaWV0Zi5v cmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUN Cj4gPg0KPiA+DQo+IC0tDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IE5ldHdvcmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAg NzE0ODI4Nw0KPiBUb3JzaGFtbnNnYXRhbiAyMyAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5 NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCg0K