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

[Christian Huitema <[e-mail]>]

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 <[e-mail]>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave