Hi Richard, >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.
Exactly. >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. Your code is correct. Moreover, except merely loopback address from the embedded address. Many codes(like a inet_ntop) are same behavior, or do nothing. But, I've never heard any trouble about "loopback" and "unspecified". Thus, it is reasonable code. Regards, Masanobu >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:kawashi...@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:kawashi...@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 <rjsmi...@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 >> kawashi...@vx.jp.nec.com >> http://www.necat.co.jp/ >>======================================== >> > >¢(._.) >======================================== > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashi...@vx.jp.nec.com > http://www.necat.co.jp/ >======================================== > ¢(._.) ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashi...@vx.jp.nec.com http://www.necat.co.jp/ ======================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
