新旧 IPv4 映射 IPv6 表示的等效性？
Equivalence of old & new IPv4-Mapped IPv6 representation?
IPv4 作为 IPv6 地址的旧定义是（使用 127.0.0.1）：
0000:0000:0000:0000:0000:0000:7f00:0001
而当前定义的第 6 个分量为 FFFF：
0000:0000:0000:0000:0000:ffff:7f00:0001
这些应该被认为是等效的，还是在对待它们的方式上有一些微妙的区别？目前，我正在研究价值持续存在的背景以及对假设的影响。
您的第一个示例是 IPv4 兼容的 IPv6 地址，这些地址已被弃用。
您的第二个示例是 IPv4 映射的 IPv6 地址。允许并鼓励您使用混合表示法（例如 ::ffff:127.0.0.1）或 IPv6 表示法（例如 ::ffff:7f00:0001）。
RFC 5952, A Recommendation for IPv6 Address Text Representation，是一个讨论 IPv6 表示的标准。它指出：
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.
There is a trade-off here where a recommendation to achieve an
exact match in a search (no dot decimals whatsoever) and a
recommendation to help the readability of an address (dot decimal
whenever possible) does not result in the same solution. The above
recommendation is aimed at fixing the representation as much as
possible while leaving the opportunity for future well-known
prefixes to be represented in a human-friendly manner as tools
adjust to newly assigned prefixes.
The text representation method noted in Section 4 should be applied
for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of
0:0:0:0:0:ffff:192.0.2.1).
IPv4 作为 IPv6 地址的旧定义是（使用 127.0.0.1）：
0000:0000:0000:0000:0000:0000:7f00:0001
而当前定义的第 6 个分量为 FFFF：
0000:0000:0000:0000:0000:ffff:7f00:0001
这些应该被认为是等效的，还是在对待它们的方式上有一些微妙的区别？目前，我正在研究价值持续存在的背景以及对假设的影响。
您的第一个示例是 IPv4 兼容的 IPv6 地址，这些地址已被弃用。
您的第二个示例是 IPv4 映射的 IPv6 地址。允许并鼓励您使用混合表示法（例如 ::ffff:127.0.0.1）或 IPv6 表示法（例如 ::ffff:7f00:0001）。
RFC 5952, A Recommendation for IPv6 Address Text Representation，是一个讨论 IPv6 表示的标准。它指出：
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.
There is a trade-off here where a recommendation to achieve an exact match in a search (no dot decimals whatsoever) and a recommendation to help the readability of an address (dot decimal whenever possible) does not result in the same solution. The above recommendation is aimed at fixing the representation as much as possible while leaving the opportunity for future well-known prefixes to be represented in a human-friendly manner as tools adjust to newly assigned prefixes.
The text representation method noted in Section 4 should be applied for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of 0:0:0:0:0:ffff:192.0.2.1).