In the TCP/IP model, how does the application layer inform the Internet layer of the destination IP address?

Question

New to networking.

1. How does the application layer inform the Internet layer of the destination IP address? Let's say I make a Http request to www.google.com, which the application layer resolves to 8.8.8.8 via DNS. How does this IP address get passed to the Internet layer if data is incapsulated between layers?

2. How does the application layer of a server know the source IP address of the client in a HTTP request? I understand that the Internet layer of the client adds the source IP address to the IP packet, but how is it appended to incoming HTTP request headers (eg XForwardedFor) Does the Internet layer somehow append the source IP to the application data in the form of HTTP headers? If so, how does the Internet layer even know the protocol the Application layer is using?

Answer 1

In addition to the data some metadata must be communicated betwen the application, transport and internet layers.

Technically how metadata is communicated between layers is an implementation detail. In practice the application layer nearly always uses some variant of the berkerly sockets API to talk to the transport layer.

For TCP clients the destination IP and port are specified to the transport layer as part of the "connect" API call. For UDP clients either "connect" can be used to create a psuedo-connnection or the destination IP and port can be specified on a per-packet basis with the "sendto" api call.

For TCP servers the application can read the IP and port by using by calling getpeername after accepting a connection. UDP servers can read the IP and port for each packet by reading packets using the recvfrom API call.

Unfortunately sendto and recvfrom have a design flaw. They only pass the remote address, not the local one which can cause problems for servers on multihomed hosts. The server may send replies from the wrong IP address causing them to be dropped, either by the network or the client. There are newer APIs to deal with this but the details vary between operating systems.

The transport layer will in turn inform the internet layer of the IP addresses for outgoing packets and the internet layer will inform the transport layer of the IP addresses for incoming packets. Since both the transport and internet layers are typically part of the TCP/IP stack the details of how this is done is an implementation detail inside the stack.

x-forwarded-for is a http header used by http proxies. The proxy will retrieve the client IP address using getpeername, it will then encode it into a http header to pass it on to the next server.

Answer 2

1. On the client, information flows downward through each layer. I.e. your browser forms a HTTP request and pushes it down to transport layer as application payload with additional information such as transport protocol (TCP) destination port (80) and destination address.

Transport layer protocol (TCP) incapsulates application payload to a segment and uses some of the information received from application layer (destination port) to add transport layer header. It than passes the segment down to network layer, together with some additional information, such as destination address.

Network layer protocol (IP) incapsulates transport layer segment in an IP packet/datagram and uses some of the additional information it received from the transport layer (destination address) to add the IP header. It than pushes it down to link layer.

Link layer protocol (Ethernet) incapsulates network layer datagram in a frame. It than uses some of the data it gets from other protocols (ARP) to populate the link layer protocol header with correct destination address (MAC address).

Described process is typically done by OS implementation (such as Unix sockets) and NIC drivers.

2. Because on the server end the above described procedure is reversed. Application does not only receive the application data from underlying layers, but also some of the additional information, such as source IP address and source port.

Please note that OS TCP/IP implementation and NIC drivers do not alter the application payload. Therefore they do not populate X-Forwarded-For HTTP header with any kind of data. IP address data is passed along the payload. In your case this was done by a Proxy between the client and the server. As the proxy is seen as a source IP address in network layer, proxy ensured the original source IP address is passed to the server in the application data payload.

3. As you can see above, TCP/IP layer implementation is not as clean as in ISO/OSI theory - applications do need to be aware of some of the data that in theory should be contained in the lower layers. This is why applications need to be rewritten to support IPv6 (even though this is supposed to be a transparent network layer transport change, that does not affect application layer).

Answer 3

I think you're not understanding that the DNS query and the HTTP request are different packets and thats whats confusing you.

If you try to visit www.cool-site.com and you do not know its IP address then DNS happens first. The DNS process follows the whole encapsulation/decapsulation process like any other packet would.

Your machine will realise it does not have an IP for www.cool-site.com. Your machine will build a DNS query and send it to the DNS servers you have specified (statically or ones it obtained via DHCP). Assuming the DNS server knows the address it will respond back to you with a DNS response containing the domain name and the IP address. Now the machine knows the IP address it can build a new packet for a HTTP request and put the IP address as the destination IP in the packet.

The server knows where to respond because in the HTTP request packet there is a source and destination IP within the IP header (like all packets). The server will respond and put its own IP as the source and use the source IP in the previous packet as the destination.

How exactly the packet is built in regards to grabbing the IP that was received from the DNS query and putting that in to a packets destination IP field I'm not clear on. The operating systems network stack obviously handles this but I can't give more information than that because I'm not sure on the whole process. Maybe someone can comment with some extra information.

Answer 4

Simplified:

1. The application opens a TCP connection using a socket call. One of the arguments to this call is a pointer to a socket descriptor structure. The socket descriptor is partially poulated by the client application (including the server IP address) before the connection is made. The structure is available to the application and to the IP stack (software) within the OS.

2. The server also has a socket structure associated with its listening socket. The IP stack populates the source IP address and port when the connection is established. The application can read values from the socket structure.