RE: [Technical Errata Reported] RFC5952 (2872)

["Rich Smith (rjsmith2)" <[e-mail]>]

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/                
========================================