Internet Protocol version 4

This article may be deleted soon.
	To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions. For the monthly nomination lists, see Category:Articles for deletion. Version 4 of the Internet Protocol (IP), specifically IPv4 has been the principal internal data transfer of the Internet since 1980. It will gradually be replaced by Internet Protocol version 6 (IPv6). In the Internet Protocol Suite architecture, all traffic is broken up into IP packets, which are then routed over arbitrary data link protocols and physical media. Internet architects speak of both versons of IP as "medium agnostic"; an application can move from running over an Ethernet to point-to-point optical fibers with no changes to IP and the protocols above it. Since the routers do not retain knowledge of relationships (e.g., sessions or connections) between endpoints, each IP packet must contain a source and destination address. The role of the destination address is clearly necessary to forward the packet. The source address, however, has a number of housekeeping and security functions. For now, assume the source address is needed if the router or destination host needs to send an error message back to the source. Addressing IPv4 uses 32 bit binary addresses. At a given point in a network, some number of bits, starting with the leftmost, form the prefix, or the basic information a router needs to decide where to forward the packet. You could think of a prefix as the identifier of a highway or street. The bits that follow the prefix only become significant on the destination "street", where they identify the final destination of a "house on the street" or a "host on the subnet". Subnet, while a little dated as a term, still is in common use to describe the medium to which hosts connect. See Classless Inter-Domain Routing for a discussion of current address assignment and usage. Packet structure The first four bits establish the IP version number; the only valid values are 0100 for IPv4 and 0110 for IPv6. Should there be a successor to Version 6, under current conventions, that would be version 9, as the intervening numbers were assigned to experimental protocols to succeed Version 4. Of the several choices, version 6 were adopted. Option fields for IPv4 are rarely used. Their encoding imposed substantial overhead, and a very different option-handling technique is used in IPv6. It will be assumed, in this article, that the options fields are not used, and that the bytes following the 20-byte header all belong to the payload protocol indicated by the protocol identification field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Internet Header Length The next four bits are straightforward enough: they are the length of this specific packet's header in units of 32 bits. Since IP options are rarely used, the value is almost always binary 0101. Type of Service This field has undergone several revisions, and its current use is defined by differentiated services. Fragmentation fields The total length, identification, fragment offset, and flags work together to support the #fragmentation mechanism. Time to Live Rather than being a quote from a movie such as The Godfather, TTL is not actually a time, but a counter intended to prevent loops. Whenever a packet enters a router, the TTL field is decremented by 1. If the result is zero, it is assumed the packet is looping because it has exceeded the maximum plausible number of routers in the network. Protocol identification The next field identifies the type of protocol carried in this packet's data field. Most often, the value will be that of an end-to-end protocol, or a tunneling protocol. Otherwise, it is likely to be a control protocol internal to the layer at which IP operates. Internet Control Message Protocol (ICMP), used principally for troubleshooting and error reporting, will be common. Several routing protocols do not use a higher-level transport protocol, so the packet could be Open Shortest Path Firat or Cisco's (Enhanced) Interior Gateway Protocol. Common IPv4 payload types Protocol Function Value Internet Control Message Protocol Control: diagnostics and error reporting 1 Internet Group Management Protocol Control: multicast group membership 2 IP in IP Tunneling 4 Transmission Control Protocol End-to-end 6 User Datagram Protocol End-to-end 17 Generic Route Encapsulation Tunneling 47 Interior Gateway Routing Protocol Routing 88 Open Shortest Path First Routing 89 Header checksum This is an error control field of very limited power to detect bit errors. All modern medium-specific protocols below IP have much stronger error detection capability than the Fletcher algorithm used in IPv4. IPv6 recognized that this field is of little practical value, and does not support regular error checking of the header. End-to-end protocols above IPv4 use the same checksum algorithm, but they look at the overall data being delivered, not just the header. Since an errored packet header may very well fail routing and be dropped, if reliable delivery is needed, TCP can be used and will trigger retransmission. There are other alternatives for reliable delivery using the lower-overhead UDP, with error control in the application protocol. Maximum Transmission Unit issues Several fields work together to support fragmentation, but, over time, it was realized that fragmentation was a high-overhead process, and could be avoided through MTU path discovery. While every IPv4 packet contains the necessary header fields for a very general case of fragmentation; IPv6 makes it an option, and an option that is supported only at a limited number of points. Fragmentation Fragmentation takes place when a packet arrives at a router interface that supports a long packet. Let us assume the packet is 3000 bytes long. On consulting its forwarding information base, the router decides that the packet needs to be forwarded out a physical interface, which connects to a medium that will accept payloads of no longer than 1500 bytes. MTU path discovery If the sending host knew, before sending a packet, the minimum packet length supported on the end-to-end path, it could reduce its packet size to that minimum and avoid the need for fragmentation. The host can learn this through the technique of MTU path discovery. Tunneling MTU issues become complex when tunneling is involved. Tunneling, in principle, is invisible to the end user. Assume that the real MTU on a router interface is 1500 bytes. Using the simplest tunneling protocol, IP in IP, 20 bytes of overhead give the tunnel a 1480 byte maximum MTU. Without path MTU discovery, and without knowledge of the tunnel, there may be a performance impact. The severity of the performance impact depends on how many of the original packets have a payload between 1481 and 1500 bytes; if few do, there will be little degradation. A potential problem comes if the MTU discovery software, on discovering 1500 does not work, next tries a much smaller MTU, such as 1200 or 600. MTU path discovery software, on discovering a failure at the native MTU, would do well to try slightly smaller MTUs that reflect common tunneling protocol overhead, or even combinations of tunneling protocols. These include IP in IP, Generic Route Encapsulation, and IPSec. The IPSec case may involve either the Authentication Header alone, or the Authentication Header and Encapsulating Security Payload. References