1 10-DayInLifeOfPacket

Previous: 08-Wireless.html

• Merge the second example here with the first?

1.1 Review

• Consider your knowledge of networking at the beginning of the semester.
• We have learned a lot this semester!
• Review this in-full: 01-Overview.html

1.2 A day in the life of a packet

1.3 Traffic example 1:

• In this section we will do a complete step-by-step walk-through of a traffic example, showing which steps that a computer will go through when it wants to communicate over a computer network.
• This example will incorporate a lot of information from the other sections and serves as an all-inclusive example.
• In the example below we will display a small home network where a computer has just booted up.
• The computer has a manually configured IP address, and has not yet communicated on the network.
• A user sits down by the computer and opens up a Web Browser and tries to browse to www.iis.se
• This image shows the network topology in the example.
• Within a lot of the steps, we will zoom in on just the most relevant part of the network to avoid having to draw the whole picture every single time.
  
  Now let’s start with the traffic example walk-through!

1.3.1 Step 1: The computer wants to send traffic

• A computer connected to the home network has just booted up.
• The computer has a manually configured IP address, Subnet Mask, DNS server and a Default Gateway.
• Both the DNS server and the Default Gateway address is pointing at the LAN IP address of the home router.
• The user of the computer opens a web browser and goes to www.iis.se
• The first thing that happens is that the Web Browser instructs the OS on the computer to set up the communication between the computer and www.iis.se
  

1.3.2 Step 2: DNS

This part is divided into numerous sub-steps

1.3.2.1 Step 2a: DNS cache

• The computer OS checks its DNS cache to see if it already knows the IP address of www.iis.se
• Since the computer just started up, and it hasn’t previously contacted www.iis.se, the DNS cache is completely empty.
  
  The computer must now ask its DNS server what IP address that www.iis.se has.

1.3.2.2 Step 2b: Putting a DNS query together

• The computer will construct a DNS query that it can send off to the DNS server, 192.168.1.1, that it was pre-configured to use.
• The destination address of the DNS query is 192.168.1.1, and the source IP address is the IP address of the computer itself, 192.168.1.5
• DNS uses UDP as its transport protocol.
• The destination port for DNS queries is 53/UDP.
• Later when the DNS query reaches the DNS server, the DNS server will be able to tell by looking at the destination port 53/UDP that the message is intended for a DNS server program, and can forward the message to the running DNS program.
• The computer OS must also randomize a source port which is also written into the message.
  
• But when the computer puts the DNS query together, it notices that it must check what destination MAC address that it should send the packet to.
• So for now, the OS puts the packet in a queue in memory, and then starts working on figuring out what destination MAC address to use.

1.3.2.3 Step 2c: Check the ARP table for a valid MAC address

• The computer will now check its ARP table, to see if it knows what MAC address that is associated with the IP address of the router, 192.168.1.1
• But the computer has a completely empty ARP table, since it just booted up, and hasn’t yet learned any ARP entries.
• Computer checks its ARP table:
  

1.3.2.4 Step 2d: ARP request to the network

• Now the computer must construct an ARP request to the rest of the network.
• The request will be sent to destination MAC address FF:FF:FF:FF:FF:FF, which is the broadcast address.
• The result is that every other computer and device on the LAN will receive the request, and read the contents.
  
• The home router receives the ARP request, and reads the message, since the request is sent to the broadcast MAC address FF:FF:FF:FF:FF:FF
• The home router can see in the message that the computer is asking for the MAC of the device with IP address 192.168.1.1.
• Because the router is configured to use that IP address, the home router will respond to this message by constructing an ARP reply, and then sending it back to the computer.

1.3.2.5 Step 2e: ARP reply from the router

• When the ARP reply is received by the computer, the OS will read the reply.
• It will enter the reply into its ARP table, to remember for a few minutes which MAC address that is associated with 192.168.1.1
  
  Now the computer finally has gathered all the information it requires to be able to send off the DNS message.

1.3.2.6 Step 2f: Send off the DNS query

• The DNS query is now going to be sent from the computer to the DNS server, which exists as a service that is running on the home router 192.168.1.1
• The home router receives the query, sees that it is a DNS query aimed at the router’s own IP address and MAC address, and understands that it must handle this DNS query and send back an answer.
  

1.3.2.7 Step 2g: The home router checks its DNS cache

• The home router is a DNS server, but it is also dependent on other DNS servers on the Internet.
• The home router can’t know every single DNS address host/IP binding on the Internet.
• Instead, it will ask those DNS servers that are responsible for different domains (such as example.com) as needed.
• The home router also has a DNS cache, just like the computer.
• Every time the home router handles a DNS query from a computer, it will also save the DNS reply in its own DNS cache for some time.
• This is to avoid having to handle the same DNS queries over and over, thus speeding up response time.
  
• In this case, the home router has not received any question about www.iis.se in a long time, so it doesn’t exist in the DNS cache on the router.
• Therefore, the router must ask its configured DNS servers on the Internet to answer this DNS query.

1.3.2.8 Step 2h: The home router prepares and sends away its DNS query

• Now the router prepares a DNS query that it will send to its DNS server.
• The router learned about available DNS servers via DHCP from the Internet Service Provider when the home router first booted up, and received its own public IP address from the ISP.
• So the home router will prepare a DNS query for transmission by putting the query inside a UDP message with destination port 53/UDP, and a random UDP source port.
• It will then put the message inside an IP packet.
• The IP packet is sent from the home router’s public IP address, to the DNS server address.
• Home router sends a DNS query
  
• When the home router has prepared the packet, and is ready to send it, then the home router will look in its routing table, to see which way it should send the packet.
• It can see in the routing table
  • that the best path to the inside LAN 192.168.1.0 is via the LAN ports, but
  • this externally directed packet should be sent to another IP network on the Internet.
• So the home router picks the WAN port as the best destination.
• At this stage of the process, it is possible that the home router would have to perform an ARP request to find out which MAC address of the next hop router 115.20.97.113, but we assume that the home router already has this information in its ARP cache.

1.3.2.9 Step 2i: The DNS query is routed over the Internet

• Here a number of steps have been somewhat simplified and shortened.
• Each router on the Internet that receives the DNS request will perform the following:
  • Receive the packet
  • Looks at the destination IP address to see where the packet is going
  • Looks in its routing table to see which path that is best for the packet
  • Removes the old MAC addresses from the packet and adds new ones.
  • It will use its own MAC address on the outbound interface as the Source MAC address for the traffic, and will put the next-hop router’s MAC address as the destination MAC address
  • Sends off the packet to the next hop router
    

1.3.2.10 Step 2j: The DNS server responds

• Eventually, the packet reaches the DNS server, which will handle the packet and prepare a response.
• Just like a regular computer, the server has an IP address, a Subnet Mask, and a Default Gateway.
• So, it works in much the same way as a regular computer.
• The DNS server replies back to the Home Router
  

1.3.2.11 Step 2k: The home router can send a DNS reply to the computer

• Now after receiving the DNS reply from the DNS server, the home router can finally create a DNS reply, and send it to the computer, to let the computer know which IP address that www.iis.se has.
  

1.3.3 Step 3: The computer sets up a session to www.iis.se

• During this part, a lot of things happen at once.
• Mainly the computer will initialize something called a “TCP 3-way Handshake” which is a setup phase of TCP communication that consists of three messages between the computer and the server.
• When TCP is being used, as is the case with web browsing, TCP sets up a reliable connection, which includes setting up a session via a handshake.
• This is done to prepare the server for an incoming session, and to decide which ports that should be used for the communication.
• The TCP 3-way Handshake consists of three messages:
  1. The first one is sent from the computer, and is called “SYN” which stands for Synchronize.
     • It lets the other side know that we want to Synchronize settings for a TCP session.
     • The message also contains the random source TCP port that the computer has chosen.
  2. The second message is the reply back from the server and is called “SYN-ACK”, which stands for Synchronize Acknowledgment.
     • This simply means that the server acknowledges that it received the message and that it also is prepared to set up a session for communication
  3. The third message is sent by the computer and finalizes the session by sending “ACK” or Acknowledgment.
     • This means that everything is now fully prepared.
• The computer has the correct ARP information for the IP address of the home router in its ARP cache.
• So the computer can send off any packets it wants to the Internet via the home router without first having to go through ARP lookups.
• But this is also the first time so far in this example that the computer wants to communicate directly with something that is located beyond the router.
• The TCP 3-way handshake will take place directly between the computer and the Web Server on the Internet.
• Earlier during the DNS lookup process, the computer just talked with the Home Router.
• The home router, in turn, talked with the DNS servers on the Internet.
• But no communication was traveling directly between the computer and any IP address on the Internet.
• The difference is that now that the computer wants to communicate directly with something on the Internet then the home router has to perform Address Translation for the traffic.

1.3.3.1 Step 3a: The computer sends a TCP SYN message

• Here we take a closer look at what happens when the computer is establishing the TCP session by initializing the TCP 3-way handshake.
• To do so, the computer OS will randomize a TCP source port that it will use for the communication.
• Then it assembles the TCP SYN message and sends it to the Web Server.
• The TCP message doesn’t contain any other data.
• It is just an empty TCP message.
• When the TCP SYN message passes through the router, the router will perform NAT on the message.
• The router will also save information about the performed NAT in its NAT table, so that it can keep track of the session, and perform reverse NAT on any replies.
  
  The picture shows a TCP SYN traveling from the computer to the web server:
  “I would like to Synchronize a TCP session with you”

1.3.3.2 Step 3b: The Web Server replies with TCP SYN-ACK

Here you can see the returning TCP SYN-ACK response from the Web Server to the computer:
“Okay, I’m good to set up a session and I confirm that I got your message”

The packet matches the NAT table entry on the router, so that the router can see which LAN computer it should forward the packet to and how it should perform NAT on the packet.

1.3.3.3 Step 3c: The computer sends a TCP ACK

Finally, a TCP ACK is sent from the computer to the Web Server
“Then I confirm that we have established a session!”

• As long as the computer and the server keep on communicating with each other, they will keep using the same session for the communication.
• This also includes using the same TCP ports, which lets all devices along the way keep track of the session, the address translation, and so on.
• The session could last just long enough to download the web page, or the web server and the computer could choose to keep the session alive for longer, in case the user wants to keep browsing around on that web page.

1.3.4 Step 4: The web browser talks with the Web Server

• Once the TCP session is established by the OS, then the OS will let the Web Browser know that it is now alright for it to start communicating with the Web Server.
• The web browser will communicate by using the HTTP protocol, which is the standard protocol for transferring web pages on the Internet

• From now on the computer and the server can communicate with each other to transmit the web pages until they are done.
• Then they can choose to end the session, either with a graceful termination using FIN-ACKs, or by sending a so-called TCP RESET message if they want, which lets all devices know that the session has now ended.

1.4 Traffic example 2:

• Now that we’ve covered the link layer in this chapter, and the network, transport and application layers in earlier chapters, our journey down the protocol stack is complete!
• In the very beginning, we wrote “much of this class is concerned with computer network protocols,” and in the first five chapters, we’ve certainly seen that this is indeed the case!
• Before heading into the topical chapters in second part of this book, we’d like to wrap up our journey down the protocol stack by taking an integrated, holistic view of the protocols we’ve learned about so far.
• One way then to take this “big picture” view is to identify the many (many!) protocols that are involved in satisfying even the simplest request: downloading a Web page.
• We illustrate our setting:
  • a student, Bob, connects a laptop to his school’s Ethernet switch and downloads a Web page (say the home page of www.google.com).
• As we now know, there’s a lot going on “under the hood” to satisfy this seemingly simple request.
• A Wireshark lab at the end of this chapter examines trace files containing a number of the packets involved in similar scenarios in more detail.
  
  (open this image tiled to one side, with text to the other side).

1.4.1 Getting Started: DHCP, UDP, IP, and Ethernet

• Let’s suppose that Bob boots up his laptop and then connects it to an Ethernet cable connected to the school’s Ethernet switch, which in turn is connected to the school’ s router.
• The school’s router is connected to an ISP, in this example, comcast.net. In this example, comcast.net is providing the DNS service for the school;
  • thus, the DNS server resides in the Comcast network, rather than the school network.
• We’ll assume that the DHCP server is running within the router, as is often the case.
• When Bob first connects his laptop to the network, he can’t do anything (e.g., download a Web page) without an IP address.
• Thus, the first network-related action taken by Bob’s laptop is to run the DHCP protocol to obtain an IP address, as well as other information, from the local DHCP server:

1. The operating system on Bob’s laptop creates a DHCP request message, and puts this message within a UDP segment, with destination port 67 (DHCP server) and source port 68 (DHCP client).
   • The UDP segment is then placed within an IP datagram, with a broadcast IP destination address (255.255.255.255) and a source IP address of 0.0.0.0, since Bob’s laptop doesn’t yet have an IP address.
2. The IP datagram containing the DHCP request message is then placed within an Ethernet frame.
   • The Ethernet frame has a destination MAC addresses of FF:FF:FF:FF:FF:FF so that the frame will be broadcast to all devices connected to the switch (hopefully including a DHCP server);
   • the frame’s source MAC address is that of Bob’s laptop, 00: 16:D3:23:68:8A.
3. The broadcast Ethernet frame containing the DHCP request is the first frame sent by Bob’s laptop to the Ethernet switch.
   • The switch broadcasts the incoming frame on all outgoing ports, including the port connected to the router.
4. The router receives the broadcast Ethernet frame containing the DHCP request on its interface with MAC address 00:22:6B:45:IF:1B and the IP datagram is extracted from the Ethernet frame.
   • The datagram’s broadcast IP destination address indicates that this IP datagram should be processed by upper layer protocols at this node, so the datagram’ s payload (a UDP segment) is thus de-multiplexed up to UDP, and the DHCP request message is extracted from the UDP segment.
   • The DHCP server now has the DHCP request message.
5. Let’s suppose that the DHCP server running within the router can allocate IP addresses in the CIDR block 68.85.2.0/24.
   • In this example, all IP addresses used within the school are thus within Comcast’s address block.
   • Let’s suppose the DHCP server allocates address 68.85.2.101 to Bob’ s laptop.
   • The DHCP server creates a DHCP ACK message containing this IP address, as well as the IP address of the DNS server (68.87.71.226), the IP address for the default gateway router (68.85 .2.1), and the subnet block (68.85.2.0/24) (equivalently, the “network mask”).
   • The DHCP message is put inside a UDP segment, which is put inside an IP datagram, which is put inside an Ethernet frame.
   • The Ethernet frame has a source MAC address of the router’ s interface to the home network (00:22:6B:45:1F:IB) and a destination MAC address of Bob’ s laptop (00: 16:D3:23:68:8A).
6. The Ethernet frame containing the DHCP ACK is sent (unicast) by the router to the switch.
   • Because the switch is self-learning and previously received an Ethernet frame (containing the DHCP request) from Bob’ s laptop, the switch knows to forward a frame addressed to 00:16:D3:23:68:8A only to the output port leading to Bob’ s laptop.
7. Bob’s laptop receives the Ethernet frame containing the DHCP ACK, extracts the IP datagram from the Ethernet frame, extracts the UDP segment from the IP datagram, and extracts the DHCP ACK message from the UDP segment.
   • Bob’ s DHCP client then records its IP address and the IP address of its DNS server.
   • It also installs the address of the default gateway into its IP forward- ing table.
   • Bob’s laptop will send all datagrams with destination address outside of its subnet 68.85 .2.0/24 to the default gateway.
   • At this point, Bob’ s laptop has initialized its networking components and is ready to begin processing the Web page fetch.
   • (Note that only the last two DHCP steps of the four presented in Chapter 4 are actually necessary.)
     

1.4.2 Still Getting Started: DNS and ARP

• When Bob types the URL for www.google.com into his Web browser, he begins the long chain of events that will eventually result in Google’s home page being displayed by his Web browser.
• Bob’s Web browser begins the process by creating a TCP socket that will be used to send the HTTP request to www.google.com.
• In order to create the socket, Bob’s laptop will need to know the IP address of www.google.com.
• We learned that the DNS protocol is used to provide this name-to-IP-address translation service.

8. The operating system on Bob’s laptop thus creates a DNS query message, putting the string “www.google.com” in the question section of the DNS message.

   • This DNS message is then placed within a UDP segment with a destination port of 53 (DNS server).
   • The UDP segment is then placed within an IP datagram with an IP destination address of 68.87.71.226 (the address of the DNS server returned in the DHCP ACK in step 5) and a source IP address of68.85.2.101.

9. Bob’s laptop then places the datagram containing the DNS query message in an Ethernet frame.

   • This frame will be sent (addressed, at the link layer) to the gateway router in Bob’ s school’s network.
   • However, even though Bob’s laptop knows the IP address of the school’s gateway router (68.85.2.1) via the DHCP ACK message in step 5 above, it doesn’t know the gateway router’s MAC address. In order to obtain the MAC address of the gateway router, Bob’s laptop will need to use the ARP protocol.

10. Bob’s laptop creates an ARP query message with a target IP address of 68.85.2.1 (the default gateway), places the ARP message within an Ethernet frame with a broadcast destination address (FF:FF:FF:FF:FF:FF) and sends the Ethernet frame to the switch, which delivers the frame to all connected devices, including the gateway router.

11. The gateway router receives the frame containing the ARP query message on the interface to the school network, and finds that the target IP address of 68.85.2.1 in the ARP message matches the IP address of its interface.

    • The gateway router thus prepares an ARP reply, indicating that its MAC address of 00:22:6B:45: IF: 1B corresponds to IP address 68.85 .2.1.
    • It places the ARP reply message in an Ethernet frame, with a destination address of 00:l6:D3:23:68:8A (Bob’s laptop) and sends the frame to the switch, which delivers the frame to Bob’s laptop.

12. Bob’s laptop receives the frame containing the ARP reply message and extracts the MAC address of the gateway router (00:22:6B:45:1F:1B) from the ARP reply message.

13. Bob’s laptop can now (finally!) address the Ethernet frame containing the DNS query to the gateway router’ s MAC address.

    • Note that the IP datagram in this frame has an IP destination address of 68.87 .71.226 (the DNS server), while the frame has a destination address of 00:22:6B:45:IF:1B (the gateway router).
    • Bob’s laptop sends this frame to the switch, which delivers the frame to the gateway router.
      

1.4.3 Still Getting Started: Intra-Domain Routing to the DNS Server

14. The gateway router receives the frame and extracts the IP datagram containing the DNS query.

    • The router looks up the destination address of this datagram (68.87.71.226) and determines from its forwarding table that the datagram should be sent to the leftmost router in the Comcast network in Figure 6.32.
    • The IP datagram is placed inside a link-layer frame appropriate for the link connecting the school’s router to the leftmost Comcast router and the frame is sent over this link.

15. The leftmost router in the Comcast network receives the frame, extracts the IP datagram, examines the datagram’s destination address (68.87.71.226) and determines the outgoing interface on which to forward the datagram toward the DNS server from its forwarding table, which has been filled in by Comcast’s intra-domain protocol (such as RIP, OSPF or IS-IS) as well as the Internet’s inter-domain protocol, BGP.

16. Eventually the IP datagram containing the DNS query arrives at the DNS server.

    • The DNS server extracts the DNS query message, looks up the name www.google.com in its DNS database, and finds the DNS resource record that contains the IP address (64.233.169.105) for www.google.com.
    • (assuming that it is currently cached in the DNS server).
    • Recall that this cached data originated in the authoritative DNS server for www.google.com.
    • The DNS server forms a DNS reply message containing this hostname-to-IP- address mapping, and places the DNS reply message in a UDP segment, and the segment within an IP datagram addressed to Bob’s laptop (68.85.2.101).
    • This datagram will be forwarded back through the Comcast network to the school’s router and from there, via the Ethernet switch to Bob’s laptop.

17. Bob’s laptop extracts the IP address of the server www.google.com from the DNS message.

• Finally, after a lot of work, Bob’s laptop is now ready to contact the www.google.com server!
  

1.4.4 Web Client-Server Interaction: TCP and HTTP

18. Now that Bob’s laptop has the IP address of www.google.com, it can create the TCP socket that will be used to send the HTTP GET message to www.google.com.

    • When Bob creates the TCP socket, the TCP in Bob’s laptop must first perform a three-way handshake with the TCP in www.google.com.
    • Bob’s laptop thus first creates a TCP SYN segment with destination port 80 (for HTTP), places the TCP segment inside an IP datagram with a destination IP address of 64.233.169.105 (www.google.com), places the datagram inside a frame with a destination MAC address of 00:22:6B:45:1F:1B (the gateway router) and sends the frame to the switch.

19. The routers in the school network, Comcast’s network, and Google’s network forward the datagram containing the TCP SYN toward www.google.com, using the forwarding table in each router, as in steps 14-16 above.

    • Recall that the router forwarding table entries governing forwarding of packets over the inter-domain link between the Comcast and Google networks are determined by the BGP protocol (Chapter 5).

20. Eventually, the datagram containing the TCP SYN arrives at www.google.com.

    • The TCP SYN message is extracted from the datagram and de-multiplexed to the welcome socket associated with port 80.
    • A connection socket is created for the TCP connection between the Google HTTP server and Bob’s laptop.
    • A TCP SYNACK segment is generated, placed inside a datagram addressed to Bob’s laptop, and finally placed inside a link-layer frame appropriate for the link connecting www.google.com to its first-hop router.

21. The datagram containing the TCP SYN ACK segment is forwarded through the Google, Comcast, and school networks, eventually arriving at the Ethernet card in Bob’s laptop.

    • The datagram is de-multiplexed within the operating system to the TCP socket created in step 18, which enters the connected state.

22. With the socket on Bob’s laptop now (finally!) ready to send bytes to www.google.com, Bob’ s browser creates the HTTP GET message containing the URL to be fetched.

    • The HTTP GET message is then written into the socket, with the GET message becoming the payload of a TCP segment.
    • The TCP segment is placed in a datagram and sent and delivered to www.google.com as in steps 18-20 above.

23. The HTTP server at www.google.com reads the HTTP GET message from the TCP socket, creates an HTTP response message, places the requested Web page content in the body of the HTTP response message, and sends the message into the TCP socket.

24. The datagram containing the HTTP reply message is forwarded through the Google, Comcast, and school networks, and arrives at Bob’s laptop.

    • Bob’s Web browser program reads the HTTP response from the socket, extracts the html for the Web page from the body of the HTTP response, and finally (finally!) displays the Web page!
      

1.4.5 Conclusions

• Our scenario above has covered a lot of networking ground!
• If you’ve understood most or all of the above example, then you’ve also covered a lot of ground since you first started the class, where we said “much of this book is concerned with computer network protocols” and you may have wondered what a protocol actually was!
• As detailed as the above example might seem, we’ve omitted a number of possible additional protocols (e.g., NAT running in the school’s gateway router, wireless access to the school’s network, security protocols for accessing the school network or encrypting segments or datagrams, network management protocols), and considerations (Web caching, the DNS hierarchy) that one would encounter in the public Internet.
• We’ll cover a number of these topics and more in the second part of this book.
• Lastly, we note that our example above was an integrated and holistic, but also very “nuts and bolts,” view of many of the protocols that we’ve studied in the first part of this book.
• The example focused more on the “how” than the “why.”