I see examples where the source
and destination IPs are on same
network were used to illustrate the IP header.

If you send a packet to a destination
on a different network, meaning through
the Internet and finally reaching another
network, NAT (network address translation)
at router occurs.

The source IP of local host, e.g. 192.168.1.100,
is a private IP address, and the receiver
cannot just send a respond to 192.168.1.100
because there are thousands if not millions
of such private IP addresses.

How is the source IP preserved (embedded) in the
IP packet by the time the packet reached the
destination network (which is not the same
network as the sender's network) just before
it is unpacked by the destination router?

The NATting router needs to replace the original source IP by a public source IP, then forward the packet to the outer network.
And vice versa when it receives the answer.

The Private IP is not preserved in the Packet. It is preserved with Connection Tracking.

This does not necessarily have to employ NAT either, the function of the router is to allow public access for the local private network, by using the public IP and keeping track of the individual MAC addresses of your local stations for all communications that go through the router.

To clarify, (Source ...) NAT ("Network Address Translation") uses a randomly-assigned source port-number to disambiguate the returning traffic. When it makes a connection to the outside world, it associates a randomly-assigned port-number with your internal IP-address, and includes that number in all traffic that "you" are sending. This is what enables it to return the replies to "you."

The public never knows your internal IP-address within your home network. All outbound traffic appears to originate from your router and will be returned to your router. (Where it goes from there is unknown to the outside world.) The assignment of source port-numbers is random and meaningless, and never intrudes into the range of "well-known port numbers."

- - - - -

If inbound traffic, which is not a reply to something that you previously sent, is being sent to your IP, then port forwarding is required to cause the traffic to be delivered to the proper internal IP. For instance, if you are running an HTTP server on your box, your router must have a port-forwarding rule that says that inbound traffic to "port 80" must be sent to "your box" and not your sister's iPhone.

In Linux, at least, it assigns a new source port if necessary to disambiguate the connection. If the tuple of (SPORT, DEST, DPORT) is not currently present in connection tracking, the source port is left as it is.

Thank you for all your responses.
I also read this link:

Here are what I know when a tcp packet leaves the router from sender:

In tcp header, you have the sender's port and destination port.
In ip header, the sender's IP address was replaced by router's IP address.

When the destination server respond, it send back these information:
In tcp header, you have the respondent's port and destination port.
In ip header, the respondent's IP address was replaced by router's IP address. You also have destination (public) IP address.


Now if you have two local hosts using same port number, and sending a tcp packet to same server's IP address at same port number, and when the local host' router receives a packet from respondent, it was not clear to me these information (respondent's public IP address and its port as well as destination (local host) port number and its public (router) IP address) are adequate to determine the correct destination of the packet since we now have two local hosts using the same port number.

Summary of question:
Respondent (server) sends tcp packet that has:
(respondent IP, respondent port, destination router IP and port number of original sender. )

Destination router has to resolve above tcp packet
from respondent to two local hosts which coincidentally use same port number and tcp protocol when sending packets to same server..
Inadequate information for local hosts' router to resolve destination local host for incoming tcp packet.

What did I missed?

From wikipedia:

The important part is that the mappings, internal and external port, protocol and address; are unique.

For at least one of those connections, NAT will have substituted a different source port number so that the tuple (SPORT, DST, DPORT) uniquely identifies the connection. When a reply packet comes back, the (DPORT, SRC, SPORT) tuple of the reply packet will match the translated (SPORT, DST, DPORT) of exactly one tracked connection, and the destination address and port number can be translated back to the original source address and port number.

1 members found this post helpful.

That solves the posted question.
Thank you.

If I am not mistaking the only time this will happen is when you have 2 internal hosts talking to the same external host using the same internal ports. Now your are talking PAT and not NAT.

Exactly. The NAT modules will also do port translation automatically if necessary to disambiguate the connection.