Header fields in IPv4 datagram

Question 1

Identifies the version of IP used to generate the datagram. For IPv4, this is the number 4. This field ensures compatibility between devices that may be running different versions of IP. In general, a device running an older version of IP will reject datagrams created by newer implementations, under the assumption that the older version may not be able to interpret the newer datagram correctly.

Answer 1

Version (4 bits)

Question 2

Specifies the length of the IP header, in 32-bit words. This includes the length of any options fields and padding. The normal value of this field when no options are used is 5 (5 32-bit words = 5*4 = 20 bytes).

Answer 2

Internet Header Length (IHL) (4 bits)

Question 3

A field designed to carry information to provide quality-of-service features, such as prioritized delivery for IP datagrams. This had not been as widely used as originally defined, and its meaning had been redefined for use by a technique called Differential Services (DS).

Answer 3

Type of Service (ToS) (8 bits)

Question 4

Specifies the total length of the IP datagram, in bytes. Since this field is 16 bits wide, the maximum length of an IP datagram is 65,535 bytes, though most are much smaller.

Answer 4

Total Length (TL) (16 bits)

Question 5

This field contains a 16-bit value that is common to each of the fragments belonging to a particular message; for datagrams originally sent un-fragmented, it is still filled in so it can be used if the datagram must be fragmented by a router during delivery. The recipient uses this field to reassemble messages without accidentally mixing fragments from different messages. This is needed because fragments may arrive from multiple messages mixed together, since IP datagrams can be received out of order from any device.

Answer 5

Identification (16 bits)

Question 6

Three of these exist, two of which are used to manage fragmentation, and one that is reserved.

Answer 6

Flags (3 bits)

Question 7

When fragmentation of a message occurs, this field specifies the offset, or position, in the message where the data in this fragment goes in units of eight bytes (64 bits). The first fragment has an offset of 0.

Answer 7

Fragment Offset (13 bits)

Question 8

This specifies how long the datagram is allowed to live on the network, in router hops. Each router decrements the value of this field prior to transmitting it. If this field drops to zero, the datagram is assumed to have taken too long a route and is discarded.

Answer 8

Time To Live (TTL) (8 bits)

Question 9

Identifies the higher-layer protocol (generally either a transport layer protocol or encapsulated network layer protocol) carried in the datagram.

Answer 9

Protocol (8 bits)

Question 10

A checksum is computed over the header to provide basic protection against corruption in transmission. This is not the more complex cyclic redundancy check (CTC) code that’s typically used by data link layer technologies such as Ethernet; it’s just a 16-bit checksum. It is calculated by dividing the header bytes into words (a word is two bytes) and then adding them together. Only the header is checksummed; not the data. At each hop, the device receiving the datagram does the same checksum calculation, and if there is a mismatch, it discards the datagram as damaged.

Answer 10

Header Checksum (16 bits)

Question 11

This is the 32-bit IP address of the originator of the datagram. Note that even though intermediate devices such as routers may handle the datagram, they do not normally put their address in this field – the address is always that of the device that originally sent the datagram.

Answer 11

Source Address (32 bits)

Question 12

This is the 32-bit IP address of the intended recipient of the datagram. Again, even though devices such as routers may be the intermediate targets of the datagram, this field is always used to specify the ultimate destination.

Answer 12

Destination Address (32 bits)

Question 13

One or more of several types of options may be included after the standard headers in certain IP datagrams.

Answer 13

Options (Variable)

Question 14

If one or more options are included, and the number of bits used for them is not a multiple of 32, enough 0 bits are added to make the header length to a multiple of 32 bits.

Answer 14

Padding

Question 15

This is the data that will be transmitted in the datagram. It is either an entire higher-layer message or a fragment of one.

Answer 15

Data (Variable)

Question 16

Flag that is not used

Answer 16

Reserved (1 bit)

Question 17

When set to 1, this says that the datagram should not be fragmented. Since the fragmentation process is generally invisible to higher layers, most protocols don’t care about this and don’t set this flag. It is, however, used for testing the maximum transmission unit (MTU) of a link.

Answer 17

Don’t Fragment (DF) (1 bit)

Question 18

When set to 0, this indicates the last fragment in a message; when set to 1, it indicates that more fragments are yet to come in the fragmented message. If no fragmentation is used for a message, there is only one fragment (the whole message), and this flag is 0. If fragmentation is used, all fragments but the last set this flag to 1 so that the recipient knows when all fragments have been sent.

Answer 18

More Fragments (MF) (1 bit)

Question 19

Originally defined as the type of service, this field specifies differentiated services (DiffServ) per RFC 2474. Real-time data streaming makes use of this field. An example is Voice of IP (VoIP), which is used for interactive voice services.

Answer 19

Differentiated Services Code Point (DSCP) (6 bits)

Question 20

This field is defined in RFC 3168 and allows end-to-end notification of network congestion without dropping packets. This is an optional feature available when both endpoints support it and effective when also supported by the underlying network.

Answer 20

Explicit Congestion Notification (ECN) (2 bits)

Question 21

Available protocols under the ‘Protocol’ field

Answer 21

00000000 - Reserved
00000001 - ICMP
00000010 - IGMP
00000011 - GGP
00000100 - IP-in-IP Encapsulation
00000110 - TCP
00001000 - EGP
00001011 - UDP
00110010 - Encapsulating Security Payload (ESP) Extension Header
00110011 - Authentication Header (AH) Extension Header