RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

RFC 7915, "IP/ICMP Translation Algorithm", June 2016

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: ops

Errata ID: 4818
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wrong IPv4-to-IPv6 translations
Date Reported: 2016-10-04
Rejected by: Benoit Claise
Date Rejected: 2017-03-10

Section Appendix A says: 

Example contains following IPv4-to-IPv6 translations:
   192.0.2.33   -> 2001:db8:1c0:2:21::
   198.51.100.2 -> 2001:db8:1c6:3364:2::

It should say:

The correct translations are:
   192.0.2.33   -> 2001:db8:1c0:2:2100::
   198.51.100.2 -> 2001:db8:1c6:3364:200::

Notes:


--VERIFIER NOTES--

This errata should be rejected. RFC7915 is correct as published.

When using 40-bit translation prefixes (as RFC7915 appendix A does),
bits 64 thru 71 is zero while the eight least significant bits of the
IPv4 address is stored in bits 72 thru 79 of the resulting
IPv4-embedded IPv6 address.

The errata appears to based on the false assumption that the entire 32
bits of the IPv4 address should be stored in bits 40-71 of the
resulting IPv4-embedded IPv6 address.

Relevant quotes from RFC6052 section 2.2:

> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> |40| prefix |v4(24) | u |(8)| suffix |
> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

> The IPv4 address is encoded following the prefix, most significant
> bits first. Depending of the prefix length, the 4 octets of the
> address may be separated by the reserved octet "u", whose 8 bits MUST
> be set to zero. In particular:

> o When the prefix is 40 bits long, 24 bits of the IPv4 address are
> encoded in positions 40 to 63, with the remaining 8 bits in
> position 72 to 79.

Report New Errata



Advanced Search