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

RFC Errata System <rfc-editor@rfc-editor.org> Sun, 16 February 2020 03:35 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9B12002F for <behave@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9yFC9dJ5EqyO for <behave@ietfa.amsl.com>; Sat, 15 Feb 2020 19:35:48 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org []) (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 <behave@ietf.org>; 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 <rfc-editor@rfc-editor.org>
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: <https://mailarchive.ietf.org/arch/msg/behave/fO04oV7rX8IpinAnDq4tsagi2g0>
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 <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 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:

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.

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.

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