RE: [Technical Errata Reported] RFC5952 (2872)
"Rich Smith (rjsmith2)" <rjsmith2@cisco.com> Fri, 29 July 2011 20:05 UTC
Return-Path: <rjsmith2@cisco.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 A405121F8A62 for <ipv6@ietfa.amsl.com>; Fri, 29 Jul 2011 13:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ZC8DFXQWLGmd for <ipv6@ietfa.amsl.com>; Fri, 29 Jul 2011 13:05:05 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 775C421F8A56 for <ipv6@ietf.org>; Fri, 29 Jul 2011 13:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rjsmith2@cisco.com; l=11181; q=dns/txt; s=iport; t=1311969905; x=1313179505; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m+Cffy4f7zMzLB+pNGVdiw9YyUY19CBJNYdLyaW9VeA=; b=ReUFP5Ctd17LyNCH/a5EB+pzo6zM0ed88Z0HEj6k6r3x29fD4V2JENIj KCNCAuqmA66Hs8gmqJIX1R14e8nkGeqESxRRHlE8ncR5JVItOaMwrbkqK tVWzld9AdXzJ+K23nxxu+bMZ5KOccAL9dQascuNMaRl6rZ7IkhHtax7ro w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtgAADURM06rRDoI/2dsb2JhbAA0AQEBAQMLCQESAQ5PDAUCAQkRAQMBAQIDBgUBBg0CAQ0BAQMCARM7AwsIAQEFFwwbhDCTRo9Zd4kAI6B7jR8BkRKBKIF7KwSBXDRfBIdakC+LdEk
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7905194"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 20:05:04 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TK54A4011082; Fri, 29 Jul 2011 20:05:04 GMT
Received: from xmb-sjc-21a.amer.cisco.com ([171.70.151.152]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 13:05:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Subject: RE: [Technical Errata Reported] RFC5952 (2872)
Date: Fri, 29 Jul 2011 13:05:02 -0700
Message-ID: <CDAC1B8268BBD34582332CE9183D6FD30FF55050@xmb-sjc-21a.amer.cisco.com>
In-Reply-To: <20110730034136kawashimam@mail.jp.nec.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Technical Errata Reported] RFC5952 (2872)
Thread-Index: AcxOH0hHQ81nfyCSSNeLLl1pI+cVzQACVLNA
References: <CDAC1B8268BBD34582332CE9183D6FD30FF54F80@xmb-sjc-21a.amer.cisco.com> <20110730034136kawashimam@mail.jp.nec.com>
From: "Rich Smith (rjsmith2)" <rjsmith2@cisco.com>
To: Masanobu Kawashima <kawashimam@vx.jp.nec.com>
X-OriginalArrivalTime: 29 Jul 2011 20:05:04.0320 (UTC) FILETIME=[CE462C00:01CC4E2A]
X-Mailman-Approved-At: Sun, 31 Jul 2011 08:57:04 -0700
Cc: ipv6@ietf.org
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 20:05:11 -0000
I understand your point, which is that regardless of the prefix, if the embedded address is not a globally unique IPv4 address, then the special formatting does not apply. I still think it is not clear that this is the intended interpretation of RFC-5952 given the phrase "solely... through the use of a well-known prefix". Now the algorithm cannot actually rely solely on the prefix, but in fact must also examine the embedded address to make sure it is a valid IPv4 unicast address. This interpretation presents other irritations when coding RFC-5952's recommendations as an algorithm because the algorithm must make a special case for at least the following other addresses beyond :: and ::1. ::ffff:ffff (not ::255.255.255.255) ::ffff:0:0 (not ::ffff:0.0.0.0) ::ffff:0:1 (not ::ffff:0.0.0.1) ::ffff:ffff:ffff (not ::ffff:255.255.255.255) It would be much easier to code the algorithm to check only for the prefixes "::" and "::ffff" (from RFC-4291), and then specifically make an exception for the well-known IPv6 "::" (unknown) and "::1" (loopback) addresses. This is what I have done now in my code, which leaves the above mentioned four addresses (supposedly) incorrectly formatted. Thanks for your prompt replies, and I will now leave you alone :-) --Rich -----Original Message----- From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] Sent: Friday, July 29, 2011 11:42 AM To: Rich Smith (rjsmith2) Cc: ipv6@ietf.org Subject: RE: [Technical Errata Reported] RFC5952 (2872) Hi Richard, Thank you for your reply. >These sections clearly indicate that addresses with the first 96 bits > all-zero have embedded IPv4 addresses. I don't think so. You have missed note below in Section 2.5.5.1. =================================================================== Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" must be a globally-unique IPv4 unicast address. =================================================================== ::(Unspecified Address) and ::1(Loopback Address) are not globally-unique IPv4 unicast address. We should not use the 96-bit all-zeros prefix to identify embedded IPv4 addresses. We have to check last 32 bits of the address. Thus, we don't need any addition. It is not an error. >By the way, I want to thank you for authoring this RFC, since it solves > a major problem we have, which is searching for and matching IPv6 addresses > that are represented as text. Thank you for your feedback. I'm so glad to hear that. :-) Regards, Masanobu >RFC-4291 (IP Version 6 Addressing Architecture), which RFC-5952 references, has a section 2.5.5 called "IPv6 Addresses with Embedded IPv4 Addresses". Presumably, this is what RFC-5952 is referring to. Section 2.5.5 two subsections. The first subsection 2.5.5.1 is called "IPv4-Compatible IPv6 Address". Let me copy it here: > >2.5.5.1. IPv4-Compatible IPv6 Address > > The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 > transition. The format of the "IPv4-Compatible IPv6 address" is as > follows: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > The "IPv4-Compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use these addresses. > New or updated implementations are not required to support this > address type. > >In addition, in RFC-4291 has a section 2.2 called "Text Representation of Addresses", which has the following paragraph regarding mixed IPv6 / IPv4 addresses: > > 3. An alternative form that is sometimes more convenient when dealing > with a mixed environment of IPv4 and IPv6 nodes is > x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of > the six high-order 16-bit pieces of the address, and the 'd's are > the decimal values of the four low-order 8-bit pieces of the > address (standard IPv4 representation). Examples: > > 0:0:0:0:0:0:13.1.68.3 > > 0:0:0:0:0:FFFF:129.144.52.38 > > or in compressed form: > > ::13.1.68.3 > > ::FFFF:129.144.52.38 > >These sections clearly indicate that addresses with the first 96 bits all-zero have embedded IPv4 addresses. It does say that this prefix is deprecated, but deprecated or not, RFC-4291 clearly defines 96 bits of zero to contain an embedded IPv4 address, and then shows it in at least two examples. > >Thus my confusion from this paragraph in RFC-5952, section 5: > >5. Text Representation of Special Addresses > > Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and > IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses > embedded in the low-order 32 bits of the address. These addresses > have a special representation that may mix hexadecimal and dot > decimal notations. The decimal notation may be used only for the > last 32 bits of the address. 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. > Such prefixes are defined in [RFC4291] and [RFC2765] at the time of > this writing. If it is known by some external method that a given > prefix is used to embed IPv4, it MAY be represented as mixed > notation. Tools that provide options to specify prefixes that are > (or are not) to be represented as mixed notation may be useful. > >specifically "solely... through the use of a well-known prefix" then citing RFC-4291. > >RFC-4291 does define 96 bits of zero as a well-known IPv4 address prefix, as I've pasted above. > >If it was your intention that readers of RFC-5952 IGNORE section 2.5.5.1 of RFC-4291, then YOU MUST MAKE THAT CLEAR because NOTHING in RFC-5952 says to do that. In fact, just the opposite is at least implied, and implied because sections 2.2 and 2.5.5.1 clearly show 96-bit all-zeros prefix indicate an embedded IPv4 address, and RFC-5952 references this standard with no additional clarification other than to go solely by the address prefix. > >So, I want it made clear EITHER: a) Ignore section 2.5.5.1 of RFC-4291, which is to say that the 96-bit all-zero prefix is NOT intended to indicate an embedded IPv4 address, or b) make it clear that at least :: and ::1 are not to be treated as embedded IPv4 addresses because they are, in fact, well-known IPv6 addresses. The latter was my suggestion from the original errata. > >If you require further clarification, then let me know. I don't know if I can make it any clearer. I've pasted the relevant sections of RFC-5952 and RFC-4291. But, if this is not enough, then I can try to provide more information if you need it. > >By the way, I want to thank you for authoring this RFC, since it solves a major problem we have, which is searching for and matching IPv6 addresses that are represented as text. > >Thanks. > > --Rich > > >-----Original Message----- >From: Masanobu Kawashima [mailto:kawashimam@vx.jp.nec.com] >Sent: Thursday, July 28, 2011 5:04 PM >To: Rich Smith (rjsmith2); ipv6@ietf.org >Subject: Re: [Technical Errata Reported] RFC5952 (2872) > > >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/ >======================================== > ¢(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ========================================
- [Technical Errata Reported] RFC5952 (2872) RFC Errata System
- Re: [Technical Errata Reported] RFC5952 (2872) Masanobu Kawashima
- RE: [Technical Errata Reported] RFC5952 (2872) Masanobu Kawashima
- RE: [Technical Errata Reported] RFC5952 (2872) Masanobu Kawashima
- RE: [Technical Errata Reported] RFC5952 (2872) Rich Smith (rjsmith2)
- RE: [Technical Errata Reported] RFC5952 (2872) Rich Smith (rjsmith2)