RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 6751, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", October 2012

Source of RFC: INDEPENDENT
See Also: RFC 6751w/ inline errata

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)".

Report New Errata