RFC Errata
Found 4 records.
Status: Verified (2)
RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012
Source of RFC: INDEPENDENT
Errata ID: 3384
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-18
Verifier Name: Nevil Brownlee
Date Verified: 2014-01-20
Section 6.5.3 says:
CR-2 IPv6/IPv4 PACKET FROM A HOST OF THE SAME SITE
<figure omitted>
If ALL the following conditions are satisfied (i.e., the packet comes
from a 6a44 client of the same site), the 6a44 client MUST
decapsulate the inner packet and treat it as a received IPv6 packet:
(1) the IPv4 packet contains a complete UDP datagram (protocol = 17,
offset = 0, more-fragment bit = 0); (2) both ports of the UDP
datagram are the 6a44 port, and the UDP payload is an IPv6 packet
(UDP length of at least 40 octets, version = 6); (3) the IPv6 source
address is one of the same site (the first 80 bits match those of the
6a44-client IPv6 address; (4) its last 32 bits are equal to the IPv4
source address; (5) the IPv6 destination address is the 6a44-client
IPv6 address.
It should say:
CR-2 IPv6/IPv4 PACKET FROM A HOST OF THE SAME SITE
<figure omitted>
If ALL the following conditions are satisfied (i.e., the packet comes
from a 6a44 client of the same site), the 6a44 client MUST
decapsulate the inner packet and treat it as a received IPv6 packet:
(1) the IPv4 packet contains a complete IPv6 packet (protocol = 41,
offset = 0, more-fragment bit = 0); (2) the IPv6 source
address is one of the same site (the first 80 bits match those of the
6a44-client IPv6 address); (3) its last 32 bits are equal to the IPv4
source address and the IPv4 source address starts with the IPv4 link
prefix; (4) the IPv6 destination address is the 6a44-client
IPv6 address; (5) its last 32 bits are equal to the IPv4 destination
address.
Notes:
Bullet (2) in the original text has to be discarded because UDP is not used for IPv6 encapsulation in the case described by CR-2. The following bullet numbers got decremented by 1. Bullets (1) and (2)-(4) (after renumbering) were changed and bullet (5) was added taking information from CT-2 in section 6.5.2.
Thanks to Andreas for finding this.
In CR-2 of page 21 the text is inconsistent with the figure, which is right.
The proposed correction does eliminate this bug.
Errata ID: 3388
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-18
Verifier Name: Nevil Brownlee
Date Verified: 2014-01-20
Section 6.6.2 says:
RR4-5 INVALID IPv6/UDP/IPv4 PACKET
For ANY other case, the 6a44 relay MUST discard the packet.
It should say:
RR4-5 INVALID IPv6/UDP/IPv4 PACKET
For ANY other case, the 6a44 relay MUST discard the packet,
and return to the UDP/IPv4 source an error-signalling bubble
formatted according to Section 6.3
Notes:
Erratum modified by ISE after discussion with RFC authors.
The above has the advantage of error signaling in all cases where packets
from 6a44 clients cannot be forwarded, including if due to a change of
6a44-network IPv6 prefix.
The original Errata submission said:
RR4-5 INVALID IPv6/UDP/IPv4 PACKET: INCONSISTENT SOURCE ADDRESSES
If ALL the following conditions are satisfied, the 6a44 relay
MUST discard the packet and return to the source an
error-signaling bubble (i.e., with the "Bubble ID" field set
to 0) which conveys the up-to-date IPv6 prefix of the client:
(1) the IPv4 packet contains a complete UDP datagram (protocol
= 17, offset = 0, more-fragment bit = 0); (2) the UDP payload
is an IPv6 packet (length of at least 40 octets, version = 6);
(3) the IPv6 source address starts with the 6a44-network IPv6
prefix followed by a value (in the field that is composed of
bits 48-95) that is different from the UDP/IPv4 source address
of the received packet; (4) the IPv6 destination address is
not a Teredo address whose embedded IPv4 address is the
6a44-relay anycast address.
RR4-6 INVALID IPv6/UDP/IPv4 PACKET: ANY OTHER INVALID PACKET
For ANY other case, the 6a44 relay MUST silently discard the
packet.
The conditions when to send an error-signaling bubble must be exactly specified. This is done by the modified RR4-5 rule. The orginal rule has moved to RR4-6 and changed from "discard" to "silently discard", i.e. without returning an error-signaling bubble to the source.
The reference "(i.e., not conforming to R44-2 condition (3) in Section 6.6.2)" in section 6.3 (which is wrong anyway because rule R44-2 doesn't exist) should be replaced by "(i.e., conformig to RR4-5 condition in Section 6.6.2)"
This Errata replaces Errata ID 3385 with the wrong phrase "(in the field that is composed of bits 48-79)" being replaced by the correct one "(in the field that is composed of bits 48-95)".
Status: Held for Document Update (1)
RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012
Source of RFC: INDEPENDENT
Errata ID: 3390
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-19
Held for Document Update by: Nevil Brownlee
Date Held: 2014-01-20
Section 6.6.2 says:
RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT (IPv4, N1, B, UDP(Z1, W, [IPv6, <C.N1.Z1...>, <C.N2.Z2...>, ...])) <figure omitted> If ALL the following conditions are satisfied, the 6a44 relay MUST return back via its downstream IPv4 interface an IPv6/ UDP/IPv4 packet containing the same encapsulated packet, having its UDP/IPv4 destination set to the UDP/IPv4 address found in the 6a44 destination address, and having its UDP/IPv4 source set to the 6a44-relay UDP/IPv4 address: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6 packet (length of at least 40 octets, version = 6); (3) the IPv6 source address starts with the 6a44-network IPv6 prefix followed by the UDP/IPv4 source address of the received packet; (4) the IPv6 destination address starts with the 6a44-network IPv6 prefix.
It should say:
RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT (IPv4, N1, B, UDP(Z1, W, [IPv6, <C.N1.Z1...>, <C.N2 != B .Z2...>, ...])) <figure omitted> If ALL the following conditions are satisfied, the 6a44 relay MUST return back via its downstream IPv4 interface an IPv6/UDP/IPv4 packet containing the same encapsulated packet, having its UDP/IPv4 destination set to the UDP/IPv4 address found in the 6a44 destination address, and having its UDP/IPv4 source set to the 6a44-relay UDP/IPv4 address: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6 packet (length of at least 40 octets, version = 6); (3) the IPv6 source address starts with the 6a44-network IPv6 prefix followed by the UDP/IPv4 source address of the received packet; (4) the IPv6 destination address starts with the 6a44-network IPv6 prefix and the embedded IPv4 address (bits 48-79) MUST be different from the 6a44-relay anycast address.
Notes:
Requesting N2 != B prevents unwanted packets sent from the 6a44 relay to itself and makes the system more robust against DOS attacks.
This is really an enhancement, not an error, so it's Held (rather than Verified)
Status: Rejected (1)
RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012
Source of RFC: INDEPENDENT
Errata ID: 3385
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Cudok
Date Reported: 2012-10-18
Rejected by: Nevil Brownlee
Date Rejected: 2014-01-20
Section 6.6.2 says:
RR4-5 INVALID IPv6/UDP/IPv4 PACKET
For ANY other case, the 6a44 relay MUST discard the packet.
It should say:
RR4-5 INVALID IPv6/UDP/IPv4 PACKET: INCONSISTENT SOURCE ADDRESSES
If ALL the following conditions are satisfied, the 6a44 relay
MUST discard the packet and return to the source an
error-signaling bubble (i.e., with the "Bubble ID" field set
to 0) which conveys the up-to-date IPv6 prefix of the client:
(1) the IPv4 packet contains a complete UDP datagram (protocol
= 17, offset = 0, more-fragment bit = 0); (2) the UDP payload
is an IPv6 packet (length of at least 40 octets, version = 6);
(3) the IPv6 source address starts with the 6a44-network IPv6
prefix followed by a value (in the field that is composed of
bits 48-79) that is different from the UDP/IPv4 source address
of the received packet; (4) the IPv6 destination address is
not a Teredo address whose embedded IPv4 address is the
6a44-relay anycast address.
RR4-6 INVALID IPv6/UDP/IPv4 PACKET: ANY OTHER INVALID PACKET
For ANY other case, the 6a44 relay MUST silently discard the
packet.
Notes:
The conditions when to send an error-signaling bubble must be exactly specified. This is done by the modified RR4-5 rule. The orginal rule has moved to RR4-6 and changed from "discard" to "silently discard", i.e. without returning an error-signaling bubble to the source.
The reference "(i.e., not conforming to R44-2 condition (3) in Section 6.6.2)" in section 6.3 (which is wrong anyway because rule R44-2 doesn't exist) should be replaced by "(i.e., conformig to RR4-5 condition in Section 6.6.2)"
--VERIFIER NOTES--
Replaced bby Erratum 3388