Internet Protocol version 4: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(Work on packet format, dinner snapshot)
imported>Howard C. Berkowitz
(MTU issues)
Line 10: Line 10:


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.
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|protocol identification]] field.
                                      
                                      
     0                  1                  2                  3   
     0                  1                  2                  3   
Line 31: Line 33:
===Type of Service===
===Type of Service===
This field has undergone several revisions, and its current use is defined by [[differentiated service]]s.  
This field has undergone several revisions, and its current use is defined by [[differentiated service]]s.  
===Fragmentation===
===Fragmentation fields===
Several fields work together to support '''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.
The total length, identification, fragment offset, and flags work together to support the [[#fragmentation]] mechanism.
 
===Time to Live===
===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.
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.
Line 78: Line 81:
| 89
| 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.
===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'''.

Revision as of 00:35, 25 August 2008

This article is developing and not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

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.

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 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Version|  IHL  |Type of Service|          Total Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Identification        |Flags|      Fragment Offset    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Time to Live |    Protocol   |         Header Checksum       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Source Address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Destination Address                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Options                    |    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.

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.