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

Errata ID: 8513
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.4 says:

A MAP-T BR receiving IPv4 packets uses a longest match IPv4 +
   transport-layer port lookup to identify the target MAP-T domain and
   select the FMR and DMR rules.  The MAP-T BR MUST then compute and
   apply the IPv6 destination addresses from the IPv4 destination
   address and port as per the selected FMR.  The MAP-T BR MUST also
   compute and apply the IPv6 source addresses from the IPv4 source
   address as per Section 5.1 (i.e., using the IPv4 source and the BR's
   IPv6 prefix, it forms an IPv6-embedded IPv4 address).  The generic
   IPv4-to-IPv6 header translation procedures outlined in [RFC6145]
   apply throughout.  The resulting IPv6 packets are then passed to
   regular IPv6 forwarding.

   Note that the operation of a BR, when forwarding to/from MAP-T
   domains that are defined without IPv4 address sharing, is the same as
   that of stateless NAT64 IPv4/IPv6 translation.

It should say:

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 BR MAY calculate valid IPv6 UDP checksums for any IPv4 UDP 
datagrams where the checksum is zero as described in Section 4.5 of [RFC7915]. 

Notes:

This is list as MAY since this could be an unreasonable burden on the BR as opposed to the CE.

--- Verifier Note (Éric Vyncke) ---

While the appended text is correct (as exhibited in real life deployment) and should have been added in the original document; this does not reflect the view of the Working Group at time of publication, i.e., this is not stricto sensu an errata.

Report New Errata