RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (3)

RFC 7599, "Mapping of Address and Port using Translation (MAP-T)", July 2015

Source of RFC: softwire (int)

Errata ID: 5225
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ole Troan
Date Reported: 2018-01-03
Verifier Name: Éric Vyncke
Date Verified: 2020-01-08

Section 6 says: 

In the case of an IPv4 prefix, the IPv4 address field is right-padded
with zeros up to 32 bits.  The PSID is left-padded with zeros to
create a 16-bit field.  For an IPv4 prefix or a complete IPv4
address, the PSID field is zero.

It should say:

The PSID is left-padded with zeros to
create a 16-bit field.  For an IPv4 prefix or a complete IPv4
address, the PSID field is zero.

Notes:

This text has been copied from RFC7597 (MAP-E). While it is correct in the context of MAP-E, for MAP-T the complete IPv4 source address must be embedded in the interface-identifier for correct translation in the case of an IPv4 prefix. Right padding the prefix with zeroes would lead to the translated packet having all zeroes in its source address.

Errata ID: 5324
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Shachar Rosenberg
Date Reported: 2018-04-11
Verifier Name: Eric Vyncke
Date Verified: 2019-12-25

Section Appendix A says: 

Example 5:

PSID:                    0x20 (provisioned with DHCPv6)

It should say:

Example 5:

PSID:                    0x34 (provisioned with DHCPv6)

Notes:

In IPv4, IPv6 and port ranges presented in the example the PSID matches to 0x34 and not 0x20:

PSID: 0x34
Available ports (63 ranges): 1232-1235, 2256-2259, ...... ,
63696-63699, 64720-64723
IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034

Errata ID: 7160
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Overcash
Date Reported: 2022-10-12
Verifier Name: Eric Vyncke
Date Verified: 2022-10-13

Section 10.1 says: 

Translating an IPv4 packet to carry it across the MAP domain will increase its size (typically by 20 bytes).

It should say:

Translating an IPv4 packet to carry it across the MAP domain will increase its size (typically either 20 or 28 bytes with fragmentation).

Notes:

In the context of MTU, it is important to account for packet fragmentation. If an IPv4 packet is fragmented, the size will increase by 28 bytes during translation. The IPv6 header is 20 bytes larger than the IPv4 header, and in addition the 8 byte IPv6 Fragmentation Header must be added.

----
Verifier note
==========
with help of Yong Cui: fragmentation indeed needs to be taken into account.

Status: Reported (1)

RFC 7599, "Mapping of Address and Port using Translation (MAP-T)", July 2015

Source of RFC: softwire (int)

Errata ID: 8062
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Freemire
Date Reported: 2024-08-01

Section 6 says: 

In the case of an IPv4 prefix, the IPv4 address field is right-padded
with zeros up to 32 bits.  The PSID is left-padded with zeros to
create a 16-bit field.  For an IPv4 prefix or a complete IPv4
address, the PSID field is zero.

It should say:

In the case of an IPv4 prefix, the IPv4 address field is right-padded
with zeros up to 32 bits.  The PSID is left-padded with zeros to
create a 16-bit field.  For an IPv4 prefix the PSID field is zero.

Notes:

When there is a complete IPv4 address, the PSID field should contain the PSID. This is shown in Appendix A, Example 1. It shows an End-user IPv6 prefix and BMR that result in a complete IPv4 address. The resulting "IPv6 address of MAP CE" includes the PSID value in the the IPv6 Interface Identifier field.

Status: Held for Document Update (3)

RFC 7599, "Mapping of Address and Port using Translation (MAP-T)", July 2015

Source of RFC: softwire (int)

Errata ID: 5323
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Shachar Rosenberg
Date Reported: 2018-04-11
Held for Document Update by: Eric Vyncke
Date Held: 2020-01-08

Section Appendix A says: 

Example 4:

IPv4 address:            192.0.2.18 (0xc0000212)

It should say:

Example 4:

IPv4 address:            192.0.2.1 (0xc0000201)

Notes:

BMR defines 0 EA bits and IPv4 prefix 192.0.2.1/32, shouldn't the IPv4 address be 192.0.2.1?

Another possible option perhaps would be to change the BMR IPv4 prefix to 192.0.2.18/32 and the IPv6 address of MAP CE to: 2001:db8:0012:3400:0000:c000:0212:0000

Errata ID: 5322
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shachar Rosenberg
Date Reported: 2018-04-11
Held for Document Update by: Eric Vyncke
Date Held: 2019-12-25

Section Appendix A says: 

Example 2 - BR:
PSID:  0                  x34 (1232)

Example 4:

It should say:

Example 2 - BR:

PSID:                     0x34 (1232)

Notes:

There is a long space between 0 and x34

Errata ID: 8063
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Scott Freemire
Date Reported: 2024-08-02
Held for Document Update by: RFC Editor
Date Held: 2024-08-02

Section 5 says: 

The MAP-T algorithmic mapping rules are identical to those in
Section 5(link #1) of the MAP-E specification [RFC7597](link #2), with the following
exception: the forwarding of traffic to and from IPv4 destinations
outside a MAP-T domain is to be performed as described in this
document, instead of Section 5.4(link #3) of the MAP-E specification.

link #1: https://datatracker.ietf.org/doc/html/rfc7599#section-5
link #2: https://datatracker.ietf.org/doc/html/rfc7597
link #3: https://datatracker.ietf.org/doc/html/rfc7599#section-5.4

It should say:

The MAP-T algorithmic mapping rules are identical to those in
Section 5(link #1) of the MAP-E specification [RFC7597](link #2), with the following
exception: the forwarding of traffic to and from IPv4 destinations
outside a MAP-T domain is to be performed as described in this
document, instead of Section 5.4(link #3) of the MAP-E specification.

link #1: https://datatracker.ietf.org/doc/html/rfc7597#section-5
link #2: https://datatracker.ietf.org/doc/html/rfc7597
link #3: https://datatracker.ietf.org/doc/html/rfc7597#section-5.4

Notes:

The text in section 5 is correct, but 2 of the URL links are incorrect.
All links in section 5 should point to RFC7597.

--VERIFIER NOTES--
This is regarding the link generated in the rfc2html output, not the RFC itself (https://www.rfc-editor.org/rfc/rfc7599.txt).

Report New Errata



Advanced Search