How could a response be sent to the requestor without requestor's address?

Question

I'm reading this talking about the differences between two fire-and-forget message (for example, under UDP) and a request-response communication (for example, under TCP). I came across this:

The responder has an address, and the requestor uses it to address the request. The requestor need not in general have an address. We see this all the time in NAT'd HTTP environments.

The above is an answer to why two fire-and-forget messages, one sent from client and other sent from server, cannot simulate communication over a protocol intended for request-response.

How could the responder actually respond if it doesn't know which address to send the response to (as the requestor doesn't need to provide an address)?

Answer 1

Any IP packet received with have the IP address of the sender. A host receiving a request will have the IP address to which it can send a response. The IP packet header will have both the source and destination IP addresses.

For IPv4, the IP header is defined in RFC 792, Internet Protocol:

3.1. Internet Header Format

A summary of the contents of the internet header follows:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Example Internet Datagram Header

                            Figure 4.

For IPv6, the IP header is defined in RFC 3460, Internet Protocol, Version 6 (IPv6) Specification:

3. IPv6 Header Format

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   

Answer 2

The paper you've linked to tries to come up with a general approach to map a fire-and-forget protocol over a request-response protocol and vice versa. This creates various implications that are not quite easy to understand and (imho) not really helpful for understanding the basic paradigms.

I'd suggest looking at UDP, as a connection-less, fire-and-forget protocol and TCP, as a connection-oriented protocol. Check out a few application-layer protocols making use of the L4 protocols, like e.g. HTTP or DNS.

When you see the practical use, things are usually easier to understand. Once you've grasped the general concepts you can dive in deeper. Or put another way: understand L3 / IP first, then check out a few application protocols and how they interact with L4 and then come back to TCP and UDP. UDP is very simple but TCP is rather complex and very hard to grasp if you haven't fully realized what's on top and what's below.