Re: [Technical Errata Reported] RFC5952 (2872)

Masanobu Kawashima <kawashimam@vx.jp.nec.com> Fri, 29 July 2011 00:05 UTC

Return-Path: <kawashimam@vx.jp.nec.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06B511E80A2 for <ipv6@ietfa.amsl.com>; Thu, 28 Jul 2011 17:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTYOfomv8uUN for <ipv6@ietfa.amsl.com>; Thu, 28 Jul 2011 17:05:08 -0700 (PDT)
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id CC5FD11E809C for <ipv6@ietf.org>; Thu, 28 Jul 2011 17:05:07 -0700 (PDT)
Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6T0551T021642; Fri, 29 Jul 2011 09:05:05 +0900 (JST)
Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p6T055M00379; Fri, 29 Jul 2011 09:05:05 +0900 (JST)
Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id p6T04Y3p005089; Fri, 29 Jul 2011 09:05:04 +0900 (JST)
Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-99623; Fri, 29 Jul 2011 09:04:10 +0900
Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-9556; Fri, 29 Jul 2011 09:04:10 +0900
To: rjsmith2@cisco.com, ipv6@ietf.org
Subject: Re: [Technical Errata Reported] RFC5952 (2872)
In-reply-to: <20110728201942.E9C0E98C4EF@rfc-editor.org>
Message-Id: <20110729090410kawashimam@mail.jp.nec.com>
References: <20110728201942.E9C0E98C4EF@rfc-editor.org>
Mime-Version: 1.0
X-Mailer: StarOffice21/MailClient[4.65 Step9]
From: Masanobu Kawashima <kawashimam@vx.jp.nec.com>
Date: Fri, 29 Jul 2011 09:04:10 +0900
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 00:05:08 -0000

Hi Richard,

Thank you for your report.
I think this is better discussed in 6man.

But I think it is not an error.
Section 5 describes "Embedded IPv4 Addresses" for mixed notation.
IPv6 unspecified address and IPv6 loopback address are out of scope.

Moreover, the 80-bit all-zeros prefix is not "IPv4-compatible IPv6 address".
We should not use the 80-bit all-zeros prefix to identify embedded IPv4 addresses.

I didn't understand what you mean.
Please describe more detail.

Regards,
Masanobu


>
>The following errata report has been submitted for RFC5952,
>"A Recommendation for IPv6 Address Text Representation".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=2872
>
>--------------------------------------
>Type: Technical
>Reported by: Richard J. Smith <rjsmith2@cisco.com>
>
>Section: 5
>
>Original Text
>-------------
>For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix.
>
>
>Corrected Text
>--------------
>For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1".
>
>
>Notes
>-----
>RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable.
>
>Instructions:
>-------------
>This errata 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 (IESG)
>can log in to change the status and edit the report, if necessary. 
>
>--------------------------------------
>RFC5952 (draft-ietf-6man-text-addr-representation-07)
>--------------------------------------
>Title               : A Recommendation for IPv6 Address Text Representation
>Publication Date    : August 2010
>Author(s)           : S. Kawamura, M. Kawashima
>Category            : PROPOSED STANDARD
>Source              : IPv6 Maintenance
>Area                : Internet
>Stream              : IETF
>Verifying Party     : IESG

ยข(._.)
========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 kawashimam@vx.jp.nec.com               
 http://www.necat.co.jp/                
========================================