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

RFC Errata System <rfc-editor@rfc-editor.org> Sun, 01 July 2018 13:45 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 8262A12785F for <behave@ietfa.amsl.com>; Sun, 1 Jul 2018 06:45:57 -0700 (PDT)
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 PdxF7pqDcaHg for <behave@ietfa.amsl.com>; Sun, 1 Jul 2018 06:45:55 -0700 (PDT)
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 DBB351277CC for <behave@ietf.org>; Sun, 1 Jul 2018 06:45:55 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0E7B2B80CCA; Sun, 1 Jul 2018 06:45:49 -0700 (PDT)
To: congxiao@cernet.edu.cn, huitema@microsoft.com, marcelo@it.uc3m.es, mohamed.boucadair@orange-ftgroup.com, xing@cernet.edu.cn, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, 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: worley@ariadne.com, behave@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180701134549.0E7B2B80CCA@rfc-editor.org>
Date: Sun, 1 Jul 2018 06:45:49 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/tlztngSlrpIs6Gk7QfRuJ-nppnk>
Subject: [BEHAVE] [Technical Errata Reported] RFC6052 (5415)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.26
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, 01 Jul 2018 13:45:58 -0000

The following errata report has been submitted for RFC6052,
"IPv6 Addressing of IPv4/IPv6 Translators".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5415

--------------------------------------
Type: Technical
Reported by: Dale R. Worley <worley@ariadne.com>;

Section: 2.2

Original Text
-------------
   Bits 64 to 71 of the address are reserved for compatibility with the
   host identifier format defined in the IPv6 addressing architecture
   [RFC4291].  These bits MUST be set to zero.  When using a /96
   Network-Specific Prefix, the administrators MUST ensure that the bits
   64 to 71 are set to zero.  A simple way to achieve that is to
   construct the /96 Network-Specific Prefix by picking a /64 prefix,
   and then adding 4 octets set to zero.

[and other parts of the text]


Corrected Text
--------------
[This paragraph should be removed and corresponding changes made to
the rest of section 2.2.]

Notes
-----
Section 2.2 says that bits 64 to 71 of the Ipv6 address MUST be set to zero and references RFC 4291 as the authority.  However, RFC 7136 says:

   In particular, RFC 4291 defines a method by which the
   Universal and Group bits of an IEEE link-layer address are mapped
   into an IPv6 unicast interface identifier.  This document clarifies
   that those two bits are significant only in the process of deriving
   interface identifiers from an IEEE link-layer address, and it updates
   RFC 4291 accordingly.

Thus, the text I've referenced in RFC 6052 is to enforce a requirement that was not correctly applied, and RFC 6052's statement about bits 64 to 71 should be removed.  In addition, there are consequent changes in other parts of RFC 6052, including Figure 1, where the "u" field should be removed from the address formats.

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