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/
========================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
