Skip to main content
Engineering LibreTexts

7.1: The IPv4 Header

  • Page ID
    11140
  • The IPv4 Header needs to contain the following information:

    • destination and source addresses

    • indication of ipv4 versus ipv6

    • a Time To Live (TTL) value, to prevent infinite routing loops

    • a field indicating what comes next in the packet (eg TCP v UDP)

    • fields supporting fragmentation and reassembly.

    The header is organized as a series of 32-bit words as follows:

    ip4header.svg

    The IPv4 header, and basics of IPv4 protocol operation, were originally defined in RFC 791 [https://tools.ietf.org/html/rfc791.html]; some minor changes have since occurred. Most of these changes were documented in RFC 1122 [https://tools.ietf.org/html/rfc1122.html], though the DS field was defined in RFC 2474 [https://tools.ietf.org/html/rfc2474.html] and the ECN bits were first proposed in RFC 2481 [https://tools.ietf.org/html/rfc2481.html].

    The Version field is, for IPv4, the number 4: 0100. The IHL field represents the total IPv4 Header Length, in 32-bit words; an IPv4 header can thus be at most 15 words long. The base header takes up five words, so the IPv4 Options can consist of at most ten words. If one looks at IPv4 packets using a packet-capture tool that displays the packets in hex, the first byte will most often be 0x45.

    The Differentiated Services (DS) field is used by the Differentiated Services suite to specify preferential handling for designated packets, eg those involved in VoIP or other real-time protocols. The Explicit Congestion Notification bits are there to allow routers experiencing congestion to mark packets, thus indicating to the sender that the transmission rate should be reduced. We will address these in 14.8.3   Explicit Congestion Notification (ECN). These two fields together replace the old 8-bit Type of Service field.

    The Total Length field is present because an IPv4 packet may be smaller than the minimum LAN packet size (see Exercise 1) or larger than the maximum (if the IPv4 packet has been fragmented over several LAN packets. The IPv4 packet length, in other words, cannot be inferred from the LAN-level packet size. Because the Total Length field is 16 bits, the maximum IPv4 packet size is 216 bytes. This is probably much too large, even if fragmentation were not something to be avoided (though see IPv6 “jumbograms” in 8.5.1   Hop-by-Hop Options Header).

    The second word of the header is devoted to fragmentation, discussed below.

    The Time-to-Live (TTL) field is decremented by 1 at each router; if it reaches 0, the packet is discarded. A typical initial value is 64; it must be larger than the total number of hops in the path. In most cases, a value of 32 would work. The TTL field is there to prevent routing loops – always a serious problem should they occur – from consuming resources indefinitely. Later we will look at various IP routing-table update protocols and how they minimize the risk of routing loops; they do not, however, eliminate it. By comparison, Ethernet headers have no TTL field, but Ethernet also disallows cycles in the underlying topology.

    The Protocol field contains a value to identify the contents of the packet body. A few of the more common values are

    A list of assigned protocol numbers is maintained by the IANA [http://www.iana.org/assignments/prot...numbers.xhtml].

    The Header Checksum field is the “Internet checksum” applied to the header only, not the body. Its only purpose is to allow the discarding of packets with corrupted headers. When the TTL value is decremented the router must update the header checksum. This can be done “algebraically” by adding a 1 in the correct place to compensate, but it is not hard simply to re-sum the 8 halfwords of the average header. The header checksum must also be updated when an IPv4 packet header is rewritten by a NAT router.

    The Source and Destination Address fields contain, of course, the IPv4 addresses. These would normally be updated only by NAT firewalls.

    The source-address field is supposed to be the sender’s IPv4 address, but hardly any ISP checks that traffic they send out has a source address matching one of their customers, despite the call to do so in RFC 2827 [https://tools.ietf.org/html/rfc2827.html]. As a result, IP spoofing – the sending of IP packets with a faked source address – is straightforward. For some examples, see 12.10.1   ISNs and spoofing, and SYN flooding at 12.3   TCP Connection Establishment.

    IP-address spoofing also facilitates an all-too-common IP-layer denial-of-service attack in which a server is flooded with a huge volume of traffic so as to reduce the bandwidth available to legitimate traffic to a trickle. This flooding traffic typically originates from a large number of compromised machines. Without spoofing, even a lengthy list of sources can be blocked, but, with spoofing, this becomes quite difficult.

    One IPv4 option is the Record Route option, in which routers are to insert their own IPv4 address into the IPv4 header option area. Unfortunately, with only ten words available, there is not enough space to record most longer routes (but see 7.11.1   Traceroute and Time Exceeded, below). The Timestamp option is related; intermediate routers are requested to mark packets with their address and a local timestamp (to save space, the option can request only timestamps). There is room for only four ⟨address,timestamp⟩ pairs, but addresses can be prespecified; that is, the sender can include up to four IPv4 addresses and only those routers will fill in a timestamp.

    Another option, now deprecated as security risk, is to support source routing. The sender would insert into the IPv4 header option area a list of IPv4 addresses; the packet would be routed to pass through each of those IPv4 addresses in turn. With strict source routing, the IPv4 addresses had to represent adjacent neighbors; no router could be used if its IPv4 address were not on the list. With loose source routing, the listed addresses did not have to represent adjacent neighbors and ordinary IPv4 routing was used to get from one listed IPv4 address to the next. Both forms are essentially never used, again for security reasons: if a packet has been source-routed, it may have been routed outside of the at-least-somewhat trusted zone of the Internet backbone.

    Finally, the IPv4 header was carefully laid out with memory alignment in mind. The 4-byte address fields are aligned on 4-byte boundaries, and the 2-byte fields are aligned on 2-byte boundaries. All this was once considered important enough that incoming packets were stored following two bytes of padding at the head of their containing buffer, so the IPv4 header, starting after the 14-byte Ethernet header, would be aligned on a 4-byte boundary. Today, however, the architectures for which this sort of alignment mattered have mostly faded away; alignment is a non-issue for ARM [https://en.wikipedia.org/wiki/ARM_architecture] and Intel x86 [https://en.wikipedia.org/wiki/X86] processors.