The Internet Layer Protocols

The Internet Layer Protocols
The Internet layer of the DoD model is made up of various protocols, with the three main protocols being the Internet Protocol (IP), the Internet Control Message Protocol (ICMP), and the
Address Resolution Protocol (ARP). The following sections introduce these three protocols and provide more detail. And no discussion of things layer 3 would be complete without mentioning
routers and the process of routing.

The Internet Protocol
The Network layer portion of the DoD model is called the Internet layer. Not surprisingly, the main protocol at this layer is the Internet Protocol (IP). IP is what actually moves the data from point A to point B, a process that is called routing. IP is considered connectionless; that is, it does not swap control information (or handshaking information) in order to establish an end-to-end connection before starting a transmission. This is also known as best effort transmission. Additionally, if a packet is lost in transmission, IP must rely on TCP to determine if the data did not arrive successfully at its destination and, if not, to retransmit the entire segment, which could be more data than was carried by the lost packet

if IP had to fragment the segment. IP’s only job is to route the data to its destination. In this effort, IP inserts its own header in the datagram once it is received from TCP (or UDP or another
higher-layer protocol). The main contents of the IP header are the source and destination addresses, the protocol number, and a checksum.

Note:
IP is considered unreliable. This is because it contains no error detection or recovery capability, not because it is  ndependable. For these reasons, UDP is also an unreliable protocol. Conversely, TCP is considered reliable.

      Without the header provided by IP, intermediate routers between the source and destination— originally called gateways in the RFCs—would not be able to determine where to route the datagram. Figure 3.3 shows the layout of the datagram with the IP header in place, followed by the upper-layer header and data, which IP sees as just upper-layer information.

FIGURE 3 . 3 A datagram with TCP and IP headers

The fields in the IP header include the following:

      Version Defines the IP version number. Version 4 is the current standard. IP version 6 is currently supported by the newest equipment and may quickly become the new standard.

IHL (Internet Header Length) Defines the length of the header information. The header length can vary; the standard header is five 32-bit words, and the sixth and subsequent words are for options and padding.

TOS (Type of Service) Originally, these eight bits were broken into four fields in the first six bits, with 0s in the last two bits. The first three bits are called the precedence bits and allow the specification of eight levels of priority, with 0 being lowest and 7 being highest. The next three bits specify normal or low delay, normal or high throughput, and normal or high reliability, depending on values of 0 or 1, respectively, meaning 0 is normal for each field. Note that a value of 1 for each of these bits would be preferred. In some implementations, the first six bits are collectively used for prioritization of traffic. When used for this purpose, the first six bits are called  Differentiated Services Code Point (DSCP) bits. In still other implementations, the last two bits can be used to give TCP the ability to communicate congestion details, in which case they are

referred to as Explicit Congestion Notification (ECN) bits.

Note:

While all of this detail is pertinent to the TOS field, only a basic understanding is necessary for Network+ proficiency.

Total Length Specifies the total length of the datagram, which has no specified minimum but should be supported in all implementations up to 576 bytes. Being 16 bits, the length field can

specify a maximum packet length of 65,535 bytes.

Identification An identifying number that the receiving system can use to reassemble fragmented datagrams. Each fragment produced from the same datagram will bear the same identifying number in this field.

Flags When set to 1, the second flag bit specifies that the datagram should not be fragmented and must therefore travel over subnetworks that can handle the size without fragmenting it; the

third flag bit being set indicates that the packet is the last of a fragmented segment. When reset to 0, these two flags have the opposite meanings. The first flag bit is not used and always must

be set to 0.

Fragmentation Offset Indicates, in units of 8 octets (64 bits), the original position of the fragmented data and is used during reassembly. The first fragment of a set of fragmented packets

or non-fragmented packets have a value of 0 in this field, as you might expect.

Time to Live (TTL) Originally, the time in seconds that the datagram could be in transit; if this time was exceeded, the datagram was considered lost. Now interpreted as a hop count and

usually set to the default value of 32 (for 32 hops), this number is decremented by each router through which the packet passes. The router that decrements this field to 0, which is known as the executioner, drops the packet and sends an ICMP time exceeded message back to the original source of the packet.

Protocol Identifies the protocol whose header and data follow the IP header, allowing the interleaving or multiplexing of multiple protocols. For example, a value of 6 indicates TCP, a

value of 17 indicates User Datagram Protocol (UDP), and a value of 1 indicates ICMP. Multiplexing of upper-layer information means that one protocol, such as TCP, does not need to finish

its transmission before another, such as UDP, begins using the services of IP. Without the use of such a field, only one protocol could be used in any given implementation of IP.

Header Checksum An error-checking value that is recalculated at each packet processing point (for example, each router). Recalculation is necessary because certain IP header fields change, such as TTL. The checksum is computed only on the bits of the IP header, with the checksum field initially set to all 0s before the computation.

Source Address The 32-bit IP address of the original transmitting device. Note that this value can change along the path of transmission if certain technologies, such as Network Address

Translation (NAT), are in use.

Note:

NAT is the process of converting between the IP addresses used on a corporate intranet or other private network and Internet IP addresses. This process makes it possible to use a large number of addresses within the private network without depleting the limited number of available registered IP addresses. NAT is

usually performed within a router or firewall.

Destination Address      The 32-bit IP address of the original destination device. This address can be altered along the transmission path in the same way as noted for the source address.

Options and Padding      IP options are a set of variable fields that may or may not be present in each IP packet. While the presence of options is not mandatory, the support of all possible IP

options is required by each IP implementation. This means that if an IP host includes an option, all IP devices will understand it. Examples of standards-based options are Security, Record

Route, and Internet Timestamp. If any options are included in the IP header, it is necessary to verify that the IP header ends on a 32-bit boundary. If not, it is necessary to pad with 0s at the end of the last option, until the total length of the IP header is a multiple of 32 bits.

Upper-Layer Information The header and user data handed down by a protocol, such as TCP. The header will not appear for non-initial IP fragments. The data in the packet immediately follows this header information, which may correspond to a complete TCP segment, UDP datagram, or other IP-supported PDU or to a portion thereof when fragmentation has occurred.