+1 862 207 3288 Internet Protocol (IP) is the primary internet communication protocol. Other protocols and processes are embedded within this framework. In particular, transport protocols like the transmission control protocol (TCP) or the user
datagram protocol (UDP) work together within IP to implement robust packet-based networking. TCP is so prevalent that Internet communications protocols are often called the TCP/IP protocol stack.
Networks in general and the Internet in particular are packet-based. Anything sent over the network is divided up into small packets of data. Each packet is sent independently, and then all of the packets are reassembled by the
receiver.
The main content of each packet is the data being sent; however, there is other information that is also needed. The packet needs to know where to go and how to merge its contents with the content in other packets when it
reaches its destination. Protocol headers provide this information in a systematic, standardized manner.
The table below shows the header information for an IPv4 packet:
Bits
Bytes
0 1 2 3 4 5 6 7 8 9 10 11 12 13 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 Version Header Length Type of Service Total Length
4 Identification Flags Fragment Offset
8 Time to Live Protocol Header Checksum12 Source Address
16 Destination IP Address20 Options
In this Lab, you will dissect each piece (there are 13) of the IPv4 header to understand how it helps the packet to get to wear it belongs. You will also consider how TCP or UDP facilitate this process. If interested in furthering
your knowledge, consider downloading a packet sniffing software to view the packets being sent and received by your computer.
Complete the Lab and submit responses to all sections in a single document by Day 7.
There are several segments that will not be considered in the Lab. The first two segments are fairly simple. Version always contains 0100, binary for the number 4, to indicate that the packet is IPv4. Internet header length (IHL)
just tells how long the header is so that it is easy to tell where the header stops and the content starts. Likewise, later segments for total length and options serve largely to give information about the packet itself. You have also
already considered the IP addresses to identify the sender and receiver.
The other segments for differentiated services, identification, flag, fragment offset, time to live, protocol, checksum, source, and destination will each be considered in this Lab.
Part 1 – Packets (TCP anf UDP)
Data being sent over a network is broken up into data segments by the transport layer data protocol. Each segment is then placed in an IP packet to send. In the IPv4 header, the protocol section indicates what protocol was
utilized to break up the data being sent. The two most common transport protocols are TCP and UDP. They break data into segments similarly, but they put it together differently. TCP ensures that all packets are put back in
order, and if a packet is missing, it asks the sender to resend the packet. UDP puts back the packets in the order that they are received and does not check that all are received.
Imagine that a sender’s message is “ABCDEFG”. It is broken into seven data packets so packet 1 contains A, packet 2 contains B, packet 3 contains C, packet 4 contains D, packet 5 contains E, packet 6 contains F, and packet
7 contains G. The receiver gets the packets in the following order: 1-2-4-5-3-7-6.
1a) If the data was segmented and reassembled using UDP, what message would be received?
1b) If the data was segmented and reassembled using TCP, what message would be received?
Because it includes steps to ensure data integrity, TCP is utilized for segmenting and reassembling most communications. However, this creates a delay in the information both to establish a sender-receiver handshake and to
request and resend any missing packets. Without such checks, UDP has significantly fewer transmission delays.
1c) What is one example where UDP would be preferred to TCP? Explain why.
1d) Identify another transport protocol other than UDP and TCP. Briefly explain when it is utilized and how it segments and reassembles data segments.
Part 2 – Fragments
Depending on the data placed in it by the transport data protocol, an IPv4 packet may range in size from 20 bytes to 65,536 bytes. However, not all components of a network are able to handle packets this big. For example,
Ethernet connections can handle a maximum packet size of only 1,500 bytes. This means that a packet too large for a connection must be fragmented in order to send it.
When a packet needs to be fragmented, each fragment is put in its own IP packet, and the identification, flag, and fragment offset work together to ensure the original packet can be rebuilt. The identification is the same for every
fragment packet. The fragment offset tells where in the fragment the packet goes. And, all but the last fragment are flagged for “more fragments”. The flag on the last fragment will remain 0 to identify when the packet is
complete.
Imagine a packet contains the message “This is the full message.”, but it passes through a part of the network where only four characters can be sent at a time. The first fragment will contain “This” with a fragment offset of 0
and a flag of “more fragments”. The second segment will contain “ is “ with a fragment offset of 4 and a flag of “more fragments”. The very last packet will contain “.” with a fragment offset of 24 and no flag.
2a) What would the third packet contain? What will its fragment offset be? Will it be flagged, and if so with what? Explain.
Next imagine that the first fragment with “This” passes into a connection where only two characters can be sent at a time. Again, the identification would remain the same as before. One new fragment would contain “Th” with a
fragment offset of 0 and a flag of “more fragments”. The other new fragment would contain “is” with a fragment offset of 2 and a flag of “more fragments”.
2b) When the fragment is broken into more fragments, why does the last new fragment keep the “more fragments” flag rather than being set to 0 or no flag?
For real IP packets, the information is measured in bytes rather than in characters like this example, but this is how IP fragmentation proceeds. Then, the original packet has to be put back together.
Again, consider an example using character offsets instead of the bytes offset. The following packets are received.
Identification Character Offset Flag Content
412 6 more fragments “eas”
412 0 more fragments “Well r”
9843 0 more fragments “Goo”
9843 3 more fragments “d w”
412 12 0 / none “bled!”
412 9 more fragments “sem”
9843 6 0 / none “ork!”
2c) What are the original packet contents?
Part 3 – Differentiated Services
The differentiated service code point (DSCP), also called the traffic class, provides an indicator for how a packet should be prioritized and handled. DSCP contains 6 bits. The first three bits tell routing queue priority. The second
three bits are called the drop probability and effectively tell whether speed or accuracy is more important. These allow a router to manage the packet queue both by reordering the line based on priority and by dropping some
packets if the queue becomes too long. This helps to ensure quality of service and is particularly helpful in routing gateway traffic or high bandwidth server applications in a local area network (LAN). Most routers recognize
seven different precedence levels and four different drop probability levels in addition to being able to flag a packet as 000 000 for “best effort”. Some networks also use two additional bits for explicit congestion notification
(ECN) to further manage endpoint to endpoint traffic.
Here, you will consider just three levels of precedence (expedited, regular, or delayed) and two levels of drop probability (high or low) according to the following table.
Low Drop Probability
(all packets maintained) High Drop Probability
(packets will be systematically dropped when queue is too long)
Expedited (packet prioritized ahead of regular traffic in queue) Not Feasible 101 110
Regular 010 010 010 110
Delayed (packet waits for regular traffic to be sent before being sent) 001 010 001 110
Given these choice, a live stream video packet would likely be classified as 101 110. The media stream needs to be expedited in order to avoid latency or jitter; however, an occasional dropped packet is not an issue as even a full
missing frame does not significantly disrupt video.
In contrast, an e-mail would likely be classified as 001 010. A minor delay in receiving an e-mail is unimportant; so, other traffic can be prioritized ahead of it, but it is essential to receive all information from all packets.
3a) Using this framework, what classification would you propose for voice over IP (VoIP)? Why?
3b) Using this framework, what classification would you propose for a peer-to-peer file sharing transfer? Why?
3c) Using this framework, what classification would you propose for a general web page transaction? Why?
3d) Although prioritization based on DSCP classification is common on LANs, prioritization of packets on the Internet is often a contentious issue particularly as it may be based on originating IP address or similar rather than just
DSCP. What are arguments in support of “net neutrality”? What are arguments in support of offering an Internet “fast lane”? You may identify your personal position, but be sure you give arguments in support of both positions.
Part 4 – Data Checks
In the previous sections of this lab, you have already looked at one problem that may corrupt data on the Internet or other networks, packet loss. However, this is relatively rare and is easily handled as with TCP handshaking to
establish a connection and request replacements for missing packets. Except in rare cases, an issue only arises if there is a bad connection with packet loss of 5% or more.
Another issue that can arise is corruption of the data within the packet. With data communicated in bits of 0 or 1, even one packet contains up to half a million bits. Even if only one in a billion bits has an error, this still means that
about one out of every thousand packets will have an error.
Bit errors like these are impossible to catch without an extra data check. Both IP and TCP implement a data check process called checksum in order to catch errors. IP checks only the header and is focused on making sure this
information that is crucial to directing the packet is correct. TCP checks the data carried in the packet, and if a problem is identified, a request for a new copy of the packet is sent just like if the packet was missing.
Checksums are relatively simple. Consider a set of data consisting of 31 bits. The data might be 1001011101101001111001110000101. A checksum just counts the number of 1’s. Here, that would be a checksum value of 17 or
10001 in binary. If one bit is corrupted in the data like 1001011101101001111001110000001 then there are only 16 1’s rather than 17; so, the checksum does not match, and a problem is identified.
4A) A 31-bit message received is 0010011110010110101000111011000. The checksum received is 10000. How many 1’s are in the message received? What is the decimal value of the checksum? Does the checksum identify a
problem?
4B) A 31-bit message received is 1001001110101010111001010000110. The checksum received is 01111. How many 1’s are in the message received? What is the decimal value of the checksum? Does the checksum identify a
problem?
4C) A 31-bit message received is 0000000010001000011001000000001. The checksum received is 00110. How many 1’s are in the message received? What is the decimal value of the checksum? Does the checksum identify a
problem? Explain how you know.
The checksum calculations for the IP header or for the data with TCP include some additional mathematics designed to reduce the size of the checksum value, but the end result of identifying bit errors is the same as these
examples.
Checksum identifies errors, but it cannot correct them. When an error is identified, there is no way to tell from the checksum at which bit the error occurred. Instead, the solution is to ask the server to resend the information. An
alternative to this is a process called lockstep where multiple copies of the message are sent and compared. If three copies are sent, triple modular redundancy, then even when an error occurs, the two that agree can be assumed
to be correct.
4D) Why is checksum the preferred form of error checking even though lockstep techniques could specifically identify and correct the error?
Part 5 – Time to Live
Another issue that can occur with IP packets involves the addressing and routing rather than the information itself. It may be impossible to route a packet to its destination. The time to live helps to identify this problem rather than
leaving a packet circling the Internet indefinitely. The time to live value is initially set for a maximum number of hops, and each time it is processed by a router, that value is reduced by 1. If the value gets to 0, the packet is
terminated, and an error is sent to the sender.
5) Trace route makes use of time to live to follow the location of a packet. Explain how the hop count and error allow the location to be tracked.
Refer to the Week 2 Assignment 1 Lab Guide and Exemplar as well as the Week 2 Assignment 1 Lab Rubric, found in the Course Information area of the course navigation menu, for guidance on completing this week’s Lab
assignment. If you have additional questions regarding Lab requirements, please contact your Instructor.
Complete the Lab and submit.
Required Resources
Readings
• Chan, M. L., Holznagel, F., &Krantz, M. (2010). 20 things I learned about browsers and the web. Retrieved from http://www.20thingsilearned.com
o IP Address and DNS
o Evolving to a Faster Web
o Malware, Phishing, and Security Risks
o Using Web Addresses to Stay Safe
• Fiedler, K., Humeau, M., Maisuradze, S., & McNamee, J. (2012). How the Internet works. The EDRi Papers (3). Retrieved from http://www.edri.org/files/2012EDRiPapers/how_the_internet_works.pdf
o The IP Address
o The Domain Name System
o Deep Packet Inspection
• Information Sciences Institute, University of Southern California. (1981). Transmission control protocol – DARPA Internet program protocol specification [Request for comments: TCP-793]. Retrieved from the Internet
Engineering Task Force (IETF®) website http://www.ietf.org/rfc/rfc793.txt
• Mockapetris, P. (1987). Domain names – concepts and facilities [Request for comments: DNS-1034]. Retrieved from the Internet Engineering Task Force (IETF®) website http://www.ietf.org/rfc/rfc1034.txt
• Mockapetris, P. (1987). Domain names – implementation and specification [Request for comments: DNS-1035]. Retrieved from the Internet Engineering Task Force (IETF®) website http://www.ietf.org/rfc/rfc1035.txt
• Postel, J. (1980). User datagram protocol [Request for comments: UDP-768]. Retrieved from the Internet Engineering Task Force (IETF®) website https://www.ietf.org/rfc/rfc768.txt
