IPv4 Header CCSP Bootcamp Training in Delhi Gurgaon

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

The best way to understand IPv4 is to know the IPv4 header and all its fields. Segments from TCP or the User Datagram Protocol (UDP) are passed on to IP for processing. The IP header is appended to the TCP or UDP segment. The TCP or UDP segment then becomes the IP data. The IPv4 header is 20 bytes in length when it uses no optional fields. The IP header includes the addresses of the sending host and destination host. It also includes the upper-layer protocol, a field for prioritization, and a field for fragmentation. Figure 7-1 shows the IP header format.

The following is a description of each field in the IP header:

• Version— This field is 4 bits in length. It indicates the IP header's format, based on the version number. Version 4 is the current version; therefore, this field is set to 0100 (4 in binary) for IPv4 packets. This field is set to 0110 (6 in binary) in IPv6 networks.
• IHL— Internet header length. This field is 4 bits in length. It indicates the length of the header in 32-bit words (4 bytes) so that the beginning of the data can be found in the IP header. The minimum value for a valid header (five 32-bit words) is 5 (0101).
• ToS— Type of Service. This field is 8 bits in length. Quality of Service (QoS) parameters such as IP precedence or DSCP are found in this field. These are explained further in this chapter.
• Total length— This field is 16 bits in length. It represents the length of the datagram or packet in bytes, including the header and data. The maximum length of an IP packet can be 2¹⁶ – 1 = 65,535 bytes. Routers use this field to determine whether fragmentation is necessary by comparing the total length with the outgoing MTU.
• Identification— This field is 16 bits in length. It identifies fragments for reassembly.
• Flags— This field is 3 bits in length. It indicates whether the packet can be fragmented and whether more fragments follow. Bit 0 is reserved and set to 0. Bit 1 indicates May Fragment (0) or Do Not Fragment (1). Bit 2 indicates Last Fragment (0) or More Fragments to follow (1).
• Fragment offset— This field is 13 bits in length. It indicates (in bytes) where in the packet this fragment belongs. The first fragment has an offset of 0.
• Time to live— This field is 8 bits in length. It indicates the maximum time the packet is to remain on the network. Each router decrements this field by 1 for loop avoidance. If this field is 0, the packet must be discarded. This scheme permits routers to discard undeliverable packets.
• Protocol— This field is 8 bits in length. It indicates the upper-layer protocol. The Internet Assigned Numbers Authority (IANA) is responsible for assigning IP protocol values. Table 7-2 shows some key protocol numbers. A full list can be found at http://www.iana.org/assignments/protocol-numbers.
  
  

  Table 7-2. IP Protocol Numbers

  Protocol Number	Protocol
  1	Internet Control Message Protocol (ICMP)
  2	Internet Group Management Protocol (IGMP)
  6	Transmission Control Protocol (TCP)
  17	User Datagram Protocol (UDP)
  88	Enhanced IGRP (EIGRP)
  89	Open Shortest Path First (OSPF)
  103	Protocol-Independent Multicast (PIM)

  
  
• Header checksum— This field is 16 bits in length. The checksum does not include the data portion of the packet in the calculation. The checksum is recomputed and verified at each point the IP header is processed.
• Source address— This field is 32 bits in length. It is the sender's IP address.
• Destination address— This field is 32 bits in length. It is the receiver's IP address.
• IP options— This field is variable in length. The options provide for control functions that are useful in some situations but unnecessary for the most common communications. Specific options are security, loose source routing, strict source routing, record route, and timestamp.
• Padding— This field is variable in length. It ensures that the IP header ends on a 32-bit boundary.

Table 7-3 summarizes the fields of the IP header.

Table 7-3. IPv4 Header Fields

Field	Length	Description
Version	4 bits	Indicates the IP header's format, based on the version number. Set to 0100 for IPv4.
IHL	4 bits	Length of the header in 32-bit words.
ToS	8 bits	QoS parameters.
Total length	16 bits	Length of the packet in bytes, including header and data.
Identification	16 bits	Identifies a fragment.
Flags	3 bits	Indicates whether a packet is fragmented and whether more fragments follow.
Fragment offset	13 bits	Location of the fragment in the total packet.
Time to live	8 bits	Decremented by 1 by each router. When this is 0, the router discards the packet.
Protocol	8 bits	Indicates the upper-layer protocol.
Header checksum	16 bits	Checksum of the IP header; does not include the data portion.
Source address	32 bits	IP address of the sending host.
Destination address	32 bits	IP address of the destination host.
IP options	Variable	Options for security, loose source routing, record route, and timestamp.
Padding	Variable	Added to ensure that the header ends in a 32-bit boundary.

ToS

The ToS field of the IP header is used to specify QoS parameters. Routers and layer 3 switches look at the ToS field to apply policies, such as priority, to IP packets based on the settings. The ToS field has undergone several definitions since RFC 791.

The first 3 (leftmost) bits are the IP precedence bits. These bits define values that are used by QoS methods. The precedence bits especially help in marking packets to give them differentiated treatment with different priorities. For example, Voice over IP (VoIP) packets can get preferential treatment over regular data packets. RFC 791 describes the precedence bits as shown in Table 7-4.

Table 7-4. IP Precedence Bit Values

Decimal	Binary	Description
0	000	Routine
1	001	Priority
2	010	Immediate
3	011	Flash
4	100	Flash override
5	101	Critical
6	110	Internetwork control
7	111	Network control

All default traffic is set with 000 in the precedence bits. Voice traffic is usually set to 101 (critical) to give it priority over normal traffic. Applications such as FTP are assigned a normal priority because it tolerates network latency and packet loss. Packet retransmissions are typically acceptable for normal traffic.

RFC 1349 redefined Bits 3 and 6 (expanding for ToS bits) to reflect a desired type of service optimization. Table 7-5 shows the ToS field values that indicate service parameters to use for IP packets.

Table 7-5. ToS Field Values

ToS Bits 3 to 6	Description
0000	Normal service
1000	Minimize delay
0100	Maximize throughput
0010	Maximize reliability
0001	Minimize monetary cost

In 1998, RFC 2474 redefined the ToS octet as the Differentiated Services (DS) field and further specified bits 0 through 5 as the Differentiated Services Codepoint (DSCP) to support differentiated services. RFC 3168 (2001) provides updates to RFC 2474 with the specification on an Explicit Congestion Notification (ECN) field.

The DS field takes the format shown in Figure 7-2. The DS field provides more granular levels of packet classification by using 6 bits for packet marking. DS has 2⁶ = 64 levels of classification, which is significantly higher than the eight levels of the IP precedence bits. These 64 levels are called codepoints, and they have been defined to be backward-compatible with IP precedence values. The network designer uses DSCP to give priority to IP packets using Cisco routers. Routers should be configured to map these codepoints to per-hop behaviors (PHB) with queuing or other bandwidth-management techniques. Table 7-6 compares DSCP and IP precedence values used to assign priority and apply policies to IP packets.

Table 7-6. DSCP and IP Precedence Values

IP Precedence			DSCP
Service Type	Decimal	Binary	Class	Decimal	Binary
Routine	0	000	Best effort	0	000 to 000
Priority	1	001	Assured Forwarding (AF) Class 1	8	001 to 000
Immediate	2	010	AF Class 2	16	010 to 000
Flash	3	011	AF Class 3	24	011 to 000
Flash override	4	100	AF Class 4	32	100 to 000
Critical	5	101	Express Forwarding (EF)	40	101 to 000
Internetwork control	6	110	Control	48	110 to 000
Network control	7	111	Control	56	111 to 000

RFC 2597 defines recommended values for AF codepoints with low, medium, and high packet drop precedence. Table 7-7 shows the recommended AF codepoint values.

Table 7-7. DSCP AF Packet Drop Precedence Values

Precedence	AF Class 1	AF Class 2	AF Class 3	AF Class 4
Low drop precedence	001010	010010	011010	100010
Medium drop precedence	001100	010100	011100	100100
High drop precedence	001110	010110	011110	100110

IPv4 Fragmentation

One of the key characteristics of IPv4 is fragmentation and reassembly. Although the maximum length of an IP packet is 65,535 bytes, most of the common lower-layer protocols do not support such large MTUs. For example, the MTU for Ethernet is approximately 1518 bytes. When the IP layer receives a packet to send, it first queries the outgoing interface to get its MTU. If the packet's size is greater than the interface's MTU, the layer fragments the packet.

When a packet is fragmented, it is not reassembled until it reaches the destination IP layer. The destination IP layer performs the reassembly. Any router in the path can fragment a packet, and any router in the path can fragment a fragmented packet again. Each fragmented packet receives its own IP header and is routed independently from other packets. Routers and layer 3 switches in the path do not reassemble the fragments. The destination host performs the reassembly and places the fragments in the correct order by looking at the identification and fragment offset fields.

If one or more fragments are lost, the entire packet must be retransmitted. Retransmission is the responsibility of the higher-layer protocol (such as TCP). Also, you can set the Flags field in the IP header to "Do Not Fragment" the packet. If the field indicates Do Not Fragment, the packet is discarded if the outgoing MTU is smaller than the packet.