Web Site

Computerit-solutions.com



» Computer » Computer network » Topics begins with I » IP package


Page modified: Friday, June 23, 2006 20:28:28

The IP package or Datagram is accurate the basic element of Internet data communication. It always consists of two parts: the header (too German head), which the information about source, a goal, status, fragmenting, etc. contains, and the Payload (too German pay load), which corresponds to the data transported with the package. TCP minutes for example are exclusively in the Payload of the IP package - a layer further above in the OSI model.

In the header stand excluding minutes-relevant information of a IP package. Exactly like the remainder of all IP minutes the structure of the header is fixed in the common version 4 of minutes (IPv4) in the RFC 791. Newer minutes version 6 (IPv6) have another header.

Structure of the header

IPv4
048121620242831
VersionIHLTOSTotally length
IdentificationFlagFragment offset
Time to LiveProtocolHeader Checksum
SOURCE ADDRESS
Destination ADDRESS
Option and Padding
IPv6
048121620242831
VersionClassFlow label
Payload lengthNEXT headersHop limit
"  SOURCE ADDRESS (128 bits) " 
"  Destination ADDRESS (128 bits) " 

Explanation for IPv4

In the following the fields for IPv4 are described. For IPv6 see section IPv6#Neues header format and efficiency increase.

Version

4 bits long. The IP version. Here version 4 and version 6 are at present possible, whereby version 4 is in the Internet the usually-used.

IHL (IP header length)

4 bits long. The entire length of the IP header is indicated in multiples of 32 bits. Here thus if 5 stands, then the header 5 times 32 bits is long equal 160 bits or 20 byte, which also the minimum length for the IP header is (the option field is optional).

n = number option overall length = ((5+n) * 32)

TOS (type OF service)

8-bit broadly. The field can be set and evaluated for the prioritization by IP packets (quality OF service).

In former times (RFC 791) the bits were interpreted as follows: Bit 5-7: (Precedence) bit 4: 0/1 normal/small delay (D-bit: Delay) bit 3: 0/1 more normally/high throughput (T-bit: Throughput) bit 2: 0/1 normal/high reliability (R-bit: Reliability) bit 0&1: reserved for future applications

Since December 1998 (RFC 2474) the following allocation applies: Bit 2-7: DSCP (Differenciated services code POINT) bit 0-1: Cu (Currently unused)

Since September 2001 (RFC 3168) the following allocation applies: Bit 2-7: DSCP (Differenciated services code POINT) bit 0-1: ECN (Explicit Congestion Notification - IP river control)

Totally length

16 bits long. The length of the entire package (inclusive gives. Header) in bytes on. From it a maximum package length of 65536 bytes (64 KB) results.

Identification

16 bits long. The Reassembly steers this and the two following fields flags and fragment offset (build up from IP packets fragmented before). Clear identification of a datagram. On the basis this field and the "“SOURCE ADDRESS"” can detect the receiver the of fragments and reassemblieren it again.

Flag

3 bit long. Some control switches with the following meaning: Bit 0: reserved, 0 its bit 1 (DF) must: 0/1 may become not divided/may not (fragmented) bit 2 (MF): 0/1 last fragment/further fragments follows

Fragment offset

13 bits long. A number, which means with fragmented packages, which position within the fragments the package takes. The offset indicated in steps of 64 bits or 8 byte, whereby the first fragment has the value zero.

Time to Live

8-bit broadly. A value, which indicates the life span of the package. If this field has the value zero, then the package is rejected. Each station (rout) on the way of the package reduces this value by one. This is to prevent that packages are eternally passed on (for example if the package is falsely led in the circle and thus the net became overloads).

The standard of 1981 plans that each station reduces the TTL value by the number of seconds, like for a long time the package at the station stayed, at least however around one. Today it is implemented in fact as Hop COUNT.

Protocol

8-bit broadly. This field marks subsequent minutes. If the IP package e.g. contains a TCP package, here the value 0x06 stands. These values are defined of the IANA.

Header Checksum

16 bits long. A check total exclusive for the header (IP does not have mechanisms for the examination of the pay load on correctness, this in the TCP/IP reference model by the transport layer is guaranteed). This value is again verified with each station and - because e.g. TTL changes per Hop - again computes. All of the header in complement-on-one arithmetic is added and formed by the sum the complement-on-one. Advantage thereby is that the check sum per Hop increases only by one. The computation can be implemented therefore fast in hardware. With a more reliable testing method such as (carriage return character) against it the check total would have completely again to be computed with each Hop. Nevertheless updating the check total costs relatively much time. Modern ones do not rout examine the headers Checksum from reasons for performance and increment it only. These circumstances led to the fact that this field does not exist with IPv6 any longer.

SOURCE ADDRESS

32 bits long. The source address contains the IP package in network byte order (Big Endian, first byte is most significant byte).

Destination ADDRESS

The destination address contains in the same format as the source address.

Option and Padding

Additional information. The options must be long a multiple of 32 bits. If they are not that, with 0-Bits one fills up (Padding). Due to the restriction of size of the field Internet header length, the options can be maximally 40 byte long.

Related links

  • RFC 791 - Internet Protocol
  • RFC 790 - Assigned Numbers
  • www.iana.org IANA - Internet Assigned Numbers Authority

See also

  • Internet Protocol
  • Internet minutes family
  • IPv4
  • IPv6
  • Endianness and byte sequence

Related Websites

We found here 4 related websites.

Page cached: Wednesday, July 5, 2006 14:10:27
Valid XHTML 1.0!  Valid CSS!

Navigation

Related articles


Page copy protected against web site content infringement by Copyscape