IP packet

from Wikipedia, the free encyclopedia

The IP packet, or more precisely the Internet Protocol Datagram, is the basic element of Internet data communication. It always consists of two parts: the header , which contains information about the source, destination, status, fragmentation , etc., and the user data . The protocol TCP , for example, is located exclusively in the payload of the IP packet - a layer higher up in the OSI model .

The information of an IP packet that is exclusively relevant to the protocol is in the header data. Just like the rest of the entire Internet Protocol, the structure of the header data area is specified in the widespread version 4 of the protocol ( IPv4 ) in RFC 791 . The newer protocol version 6 ( IPv6 ) has a different header data area.

Structure of the header data area (IP header)

The IPv4 header data area comprises 20 bytes plus up to 40 bytes of optional fields, the length of the header must not exceed 60 bytes. The IPv6 header is 40 bytes long. Options are shown here in their own extension headers.

IPv4
0 4th 8th 12 16 20th 24 28 31 bit
version IHL TOS Total length
Identification Flags Fragment offset
TTL Protocol Header checksum
Source Address
Destination Address
Options and Padding (optional)
IPv6
0 4th 8th 12 16 20th 24 28 31 bit
version Traffic class Flow label
Payload Length Next header Hop limit
Source Address (128 Bit)
Destination Address (128 Bit)

Explanation for IPv4

The fields for IPv4 are described below. IPv6 is described in the Header Format section of the IPv6 article.

version

4 bits in size. The IP version. Here, version 4 and version 6 is currently possible with Version 4, the most widely used on the Internet.

IHL (IP Header Length)

4 bits in size. The entire length of the IP header data area is specified in multiples of 32 bits. If there is a 5 here, the header data area is 5 times 32 bits equal to 160 bits or 20 bytes long, which is also the minimum length for the IP header data area (the option field is optional) and thus indicates where the user data begins.

n1 through nx are options

Total length of the header = (532) + (length (n1) +… + length (nx) + padding on 32 bits)

TOS (Type of Service)

8 bits in size. The field can be set and evaluated for the prioritization of IP data packets ( Quality of Service ).

Previously ( RFC 791 ) the bits were interpreted as follows: 

Bits 0-2:  Precedence.
Bit    3:  0 = Normal Delay,      1 = Low Delay.
Bit    4:  0 = Normal Throughput, 1 = High Throughput.
Bit    5:  0 = Normal Reliability, 1 = High Reliability.
Bits 6-7:  Reserved for Future Use.

Since December 1998 ( RFC 2474 ) the following breakdown applies: 

Bits 0-5:   DSCP (Differentiated Services Code Point)
Bits 6-7:   CU (Currently unused)

Since September 2001 ( RFC 3168 ) the following division applies: 

Bits 0-5:   DSCP (Differentiated Services Code Point)
Bits 6-7:   ECN (Explicit Congestion Notification – IP-Staukontrolle)

more about DSCP and ECN , cf. IANA's DSCP registry

The two standards RFC 791 and RFC 2474 are compatible if the first 6 bits are set to zero.

Total length

16 bits in size. Specifies the length of the entire packet (including header data) in bytes. This results in a maximum packet length of 65535 bytes (64 KiB - 1 B). All hosts must be able to process datagrams with a length of at least 576 bytes.

Identification

16 bits in size. This and the two following fields, Flags and Fragment Offset, control the reassembly (assembly of previously fragmented IP data packets). Unique identifier of a datagram. Using this field and the 'Source Address', the recipient can detect whether fragments belong together and reassemble them using the fragment offset .

Flags

3 bits in size. The bits have the following meaning:

Bit 0
reserved, must be 0
Bit 1 - DF (Don't Fragment)
If set to 1, it indicates that the packet must not be broken up into fragments (fragmented)
Bit 2 - MF (More Fragments)
If set to 1, it indicates that more fragments will follow. If at 0, this packet is the last (or only) fragment.

Fragment offset

13 bits in size. A number that, in the case of fragmented packets, indicates the position within the packet from which the fragment begins. The numbering refers to data blocks of 64 bits or 8 bytes in size and is independent of the fragmentation. If necessary, a package can be divided into smaller and smaller fragments several times in a row. Only the number of the first data block contained (offset) and the total length field need to be adapted to the length of the fragment. The first fragment, or a non-fragmented packet, contains the value zero as an offset. If a packet with 800 bytes of user data (offset numbering from 0 to 99) is divided into two fragments, the offset of the second fragment is number 50. Since the offset does not contain any information about the size of the original packet, the very last fragment must be the Set the MF flag to zero.

Time to Live (lifetime)

8 bits in size. A value that indicates the lifetime of the package. If this field has the value zero, the packet is discarded. Each station (router) on the way of the packet reduces this value by one. This is to prevent packets from being forwarded forever (for example if the packet is incorrectly routed in a circle and would overload the network).

The 1981 standard stipulates that each station reduces the TTL value by the number of seconds the packet remains at the station, but at least by one. Today it is de facto implemented as a hop count .

Protocol

8 bits in size. This field designates the subsequent protocol to which the user data transported in the relevant IPv4 packet belong. For example, if the IP packet contains a TCP packet, the value 6 stands for a UDP packet 17. These values ​​have been defined by the IANA in an online database for protocol numbers since RFC 3232 .

This field also exists in the IPv6 header, but it is called Next Header . The allowed values ​​are the same as for IPv4.

Header checksum

16 bits in size. A checksum only secures the header data area. IP itself has no mechanisms for checking the payload for correctness; this is ensured in the TCP / IP reference model by the transport layer . This value is verified anew at each station and - because the TTL changes per hop - recalculated. All 16-bit half-words of the header data area are added according to the rules of one's complement (add carry to the LSB) and the one's complement is formed from the sum. The result should be 1111 1111 1111 1111 (Hex: 0xFFFF), otherwise there is an error in the header. The advantage here is that the checksum only increases by one per hop. The calculation can therefore be carried out quickly in the hardware. With a more reliable test method such as CRC, on the other hand, the checksum would have to be recalculated for each hop. Nevertheless, checking the checksum takes a relatively long time. Modern routers do not check the checksum for reasons of processing speed and only increment it. These circumstances have led to the fact that this field no longer exists in IPv6.

Source Address

32 bits in size. Contains the source address of the IP packet in network byte order ( byte order , first byte is the most significant byte ).

Destination Address

Contains the destination address in the same format as the source address.

Options and padding

Additional information for the specific package. The options are only optional in the header, but they must be supported by all IP modules. The format of the options is described in RFC 791 . The maximum number of bytes that can be assigned with options in the specific package results from (IHL * 4) -20. Since a value range from 0 to 15 is coded with the 4 bits in IHL, up to 40 bytes can be occupied by options. The individual options themselves can have different lengths; there are both fixed-length options and options with variable length. Since the total length of the IP header is only specified in multiples of 4 bytes by the IHL field, unused bytes are padded with zeros (padding).

Strict routing
Option specifies the entire path that the package must traverse
Free routing
Option specifies a list of routers that the packet must not miss
Record route
Lets the entire route be recorded (today the size of the option field is usually no longer sufficient)
Time stamp
time stamp
Security
Indicates how secret the package is

See also

Web links

Individual evidence

  1. ↑ Differentiated Services Field Codepoints (DSCP) ( English ) iana.org. Retrieved May 10, 2019.
  2. ^ Protocol Numbers ( English ) iana.org. Retrieved May 10, 2019.