RFC 791 pt2

 This week's post will cover the operation of the Internet Protocol. Specifically, Time to Live (TOL), Type of Service(TOS), the Header Checksum, and the other remaining options available when transmitting data across IP. While this post will cover the basic operations and provide descriptions of their functions and use, a more technical dive will be saved for next week's post, which will cover the specification section of RFC 791. The final post in this series will cover the security implications of the Internet Protocol, and briefly cover the updates made to the original document and protocol. 

Continuing from the last post, there are two main functions of the Internet Protocol. Addressing and Fragmentation. To begin,  the device you use to connect to the internet, or the internet module, uses the addressing function of IP to send and receive data. The internet module reads the address of the datagram and uses it to route to the desired endpoint. This address is carried in the header of the internet datagram. 

Information pertaining to the fragmentation of datagrams is also contained within the header. Much like the addressing information helps the internet modules route the datagrams, there is information inside the header that helps the modules assemble fragmented data. The fragments are transmitted asynchronously and are not necessarily received in assembly order. Thus, the internet datagram header contains both addressing information and assembly information. The addressing information ensures that the fragmented data is sent to the same destination and the assembly information gives instructions on the reconstruction of the fragmented data. 

Internet modules also share common rules for reading and formatting header information. This ensures that a datagram passed from one module to another can use the same addressing information. This applies to assembly as well. 

Aside from addressing and fragmentation, there are several other fields within the header. Starting off, Type of Service is the second byte contained in an IPv4 header. The TOS determines the datagrams' priority and routing. It can signify a request for low-latency, high-throughput, or high-reliability routing. It is a fairly obsolete system, having been redefined several times over the years. In modern applications, it sees little use. Even back in its more relevant days, the TOS field went relatively unused. 

Time to Live prevents datagrams from traveling endlessly. It provides a set value that decreases every time the datagram is processed while routing to its destination. When the value is set to 0, the datagram is destroyed. This helps to prevent undeliverable data from continuing to circulate on a network, causing congestion. Originally, TTL was measured in units of time, such as seconds. However, every host that processes the datagram must reduce the TTL limit, and thus in IPv6 the TTL field was renamed to hop limit. 

One of the more important fields in the header is the header checksum. The header checksum provides a method of verification for the datagram. Every host must validate the header checksum before sending the datagram to the next destination. The header checksum must also be changed every time the header is changed as well. As each host must decrease the TTL, they must also change the header checksum. The checksum first must be calculated and then verified. The calculation process works by adding the hex values of the 16-bit fields in the header, minus the checksum field. The first digit of the result is called the carry digit and is added to the sum. Next, you must take the ones' complement(flip every bit) of the sum and the result should be the value of the checksum field. The same process is used to verify the checksum. However, the checksum filed is now included in the calculation. The end result of the verification should equal 0. 

There are other minor optional fields in the internet datagram header. Control functions that may be necessary in certain specific situations for example. However, these options are not needed for more common applications and thus will not be expanded upon too much in this post. Some of the options, for example, include timestamping, increased security options, and special routing instructions. It is also possible to change the method of fragmentation of the data or to disallow fragmentation all together.