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

Errata ID: 8512
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Overcash
Date Reported: 2025-07-14
Held for Document Update by: Éric Vyncke
Date Held: 2025-11-06

Section 8.1 says:

 A MAP-T CE receiving IPv4 packets SHOULD perform NAPT44 processing
   and create any necessary NAPT44 bindings.  The source address and
   source port range of packets resulting from the NAPT44 processing
   MUST correspond to the source IPv4 address and source transport port
   range assigned to the CE by means of the MAP Basic Mapping Rule
   (BMR).

   The IPv4 packet is subject to a longest IPv4 destination address +
   port match MAP Rule selection, which then determines the parameters
   for the subsequent NAT64 operation.  By default, all traffic is
   matched to the DMR and is subject to the stateless NAT64 operation
   using the DMR parameters for NAT64 (Section 5.1).  Packets that are
   matched to (optional) Forwarding Mapping Rules (FMRs) are subject to
   the stateless NAT64 operation using the FMR parameters (Section 5)
   for the MAP algorithm.  In all cases, the CE's MAP IPv6 address
   (Section 6) is used as a source address.

   A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one
   or more Forwarding Mapping Rules.

It should say:

Append new paragraph:
Some older IPv4 hosts may send UDP datagrams with the UDP checksum set to 
zero, however a zero checksum is not allowed for IPv6. To avoid datagram 
drops, the CE SHOULD calculate valid IPv6 UDP checksums for any IPv4 UDP 
datagrams where the checksum is zero as described in Section 4.5 of [RFC7915]. 

Notes:

Also add normative reference to RFC 7915 in the references section.

--- Verifier note (Éric Vyncke) ---

The appended text is correct (as verified in real life deployments), but does not reflect the status of the Working Group at time of publication, i.e., it is not stricto sensu an errata.

Report New Errata