Re: [BEHAVE] [Technical Errata Reported] RFC6052 (5984)

Christian Huitema <huitema@huitema.net> Sun, 16 February 2020 20:05 UTC

Return-Path: <huitema@huitema.net>
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 <behave@ietfa.amsl.com>; 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 <behave@ietfa.amsl.com>; 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 <behave@ietf.org>; 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 <huitema@huitema.net>) 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 <behave@ietf.org>; 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 <huitema@huitema.net>) 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 <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <behave@ietf.org>; 16 Feb 2020 20:04:48 -0000
To: RFC Errata System <rfc-editor@rfc-editor.org>, 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 <huitema@huitema.net>
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: <https://mailarchive.ietf.org/arch/msg/behave/NW_ltvIgjPX0zjZ1BfdZBkzAPa8>
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 <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=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 <jordi.palet@theipv6company.com>
>
> 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