RE: [Technical Errata Reported] RFC5952 (2872)

[Masanobu Kawashima <[e-mail]>]

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:[e-mail]] 
>Sent: Friday, July 29, 2011 11:42 AM
>To: Rich Smith (rjsmith2)
>Cc: [e-mail]
>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:[e-mail]] 
>>Sent: Thursday, July 28, 2011 5:04 PM
>>To: Rich Smith (rjsmith2); [e-mail]
>>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 <[e-mail]>
>>>
>>>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                     
>> [e-mail]               
>> http://www.necat.co.jp/                
>>========================================
>>
>
>¢(._.)
>========================================
> NEC AccessTechnica, Ltd.               
> Product Development Department         
> Masanobu Kawashima                     
> [e-mail]               
> http://www.necat.co.jp/                
>========================================
>

¢(._.)
========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 [e-mail]               
 http://www.necat.co.jp/                
========================================