Subject: [BEHAVE] [Errata Rejected] RFC6052 (5984)

From: RFC Errata System <[email-masked]>
Date: Mon, 17 Feb 2020 01:26:25 -0800 (PST)

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 <[email-masked]>
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