Recognize application and fragmentation boundaries
06A packet header rewrite cannot by itself repair every address embedded in an application or distinguish every fragmented datagram.
The receiver sees an outside address, not the private source address. Payload confidentiality, peer authentication and firewall rules require separate mechanisms; a mapping row alone provides none of them.
Source for this drawing: RFC 3022 · Read RFC section 4.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The historical collision example is distinct from later UDP NAT requirements to handle fragments in either arrival order. RFC 4787 is related guidance, not a formal update of RFC 3022.
Read the updated RFC section ↗Translation state and application knowledge have limits; neither supplies cryptographic protection.
- An Application Level Gateway (ALG) can inspect application-specific data. RFC 3022 section 4.4 explains FTP PORT/PASV address and port rewriting and the associated TCP sequence/acknowledgment adjustment.
- If an FTP rewrite changes payload length by delta, following sequence numbers and acknowledgments require consistent correction. The helper formats one chosen ASCII PORT command; it is not a complete FTP parser or TCP stream translator.
- Section 1 notes that an ALG cannot inspect an encrypted payload without decryption capability. This does not authorize decrypting anyone’s traffic or imply that all NAT requires an ALG.
- Section 6.3 describes a collision when different private hosts use the same IPv4 fragmentation identifier and destination but are translated to the same source address. Later fragments lack transport ports. The scene shows this specific historical hazard, not a universal claim that modern NAT cannot process fragments.
- Later UDP NAT guidance RFC 4787 section 11 requires support for in-order and out-of-order fragments (MUST). It is related later guidance, not an official Updates/Obsoletes edge for RFC 3022.
- Address masking does not encrypt payloads, authenticate peers or define firewall policy. Static inbound maps and application exceptions exist; outbound-only examples do not establish an absolute security boundary.
Other documented boundaries include private/global address overlap (section 5.1), address pools and optional Basic-NAT-to-NAPT fallback (section 5.4), address-dependent IP options (section 4.6), DNS deployment choices (section 4.5), and conditional ARP support when mapped addresses share the outside LAN subnet (section 6.2). These are explained as limits rather than implemented as a full router or current NAT conformance suite.
Read the RFC section ↗