Network Address Translation and Port Address Translation allow private not publicly routable addresses to connect with external public addresses.
The information and data required to map the connections is illustrated below
To allow A to communicate with B a mechanism is required to replace it’s private IP with that of I2, which is an interface on a NAPT enabled device, for example a router or firewall. I2 is routable so replies from B can get back to I2. The Private Source IP is mapped to the public IP address of I2. There could be many hosts behind I1 so to allow the edge device to forward any replies to the correct host, in the event that two different hosts have used the same source port number, the Private Source Port is mapped to a unique Mapped Source Port.
In terms of what happens in the stack of I and omitting details on checksums, a frame arrives from Host A and the fame header and footer are removed and the datagram is passed up to layer 3. A determination is made that the datagram needs to be forwarded to a next hop and the datagram is switched over to I2. The NAPT software will create an entry in the table and rewrite the source IP, in this case to 31.32.33.34 in the IP header. The IP datagram has no port field, so the NAPT implementation will also need to modify the layer 4 header and rewrite the port number, in this case to 50001. When a frame arrives from Web Server B addressed to 31.32.33.34:50001 the NAPT implementation will look in the table and match on the mapped source port, foreign IP address, foreign port and protocol and perform the reverse translation (Internetworking with TCP/IP Principles).
But there are issues with some types of traffic, for example an ICMP query header does not have a port field, that is it has no concept of port numbers.
However the ICMP query identifier field is set by the sender and is returned unchanged in replies such as pings. Because it remains unchanged it can be used and mapped in the same way as port numbers. Given that ICMP queries are encapsulated in an IP datagram when NAPT is performed for ICMP query messages the source IP address is mapped and changed in the IP header and the ID field in the ICMP header is mapped and changed. Because the query ID field is changed a new checksum must be calculated on the ICMP header. The protocol field in the NAPT entry would be set to ICMP (RFC 3022).
ICMP error messages complicate matters further in that there is a copy of the frame that caused the error in the ICMP error message payload (RFC 5508). The ICMP error is of course also encapsulated in an IP datagram and a frame. To return an ICMP error message to the correct host the NAPT implementation would need to look at the ID field of the ICMP query that caused the error, to illustrate and with the frame header received by the NAPT that originated the query on the left.
Works Cited
Comer, Douglas E. Internetworking with TCP/IP Principles, Protocols and Architecture, 6th Edition, 2014
P. Srisuresh, K. Egevang , Request for Comments: 3022, September 1981, rfc-editor.org/rfc/ rfc3022.txt
P. Srisuresh, et al, Request for Comments: 5508, April 2009, rfc-editor.org/rfc/rfc5508.txt