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:[email protected]]
Sent: Friday, July 29, 2011 11:42 AM
To: Rich Smith (rjsmith2)
Cc: [email protected]
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:[email protected]]
>Sent: Thursday, July 28, 2011 5:04 PM
>To: Rich Smith (rjsmith2); [email protected]
>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 <[email protected]>
>>
>>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
> [email protected]
> http://www.necat.co.jp/
>========================================
>
¢(._.)
========================================
NEC AccessTechnica, Ltd.
Product Development Department
Masanobu Kawashima
[email protected]
http://www.necat.co.jp/
========================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
