Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
IP Datagram General Format
(Page 1 of 3)
Data transmitted over an internet
using IP is carried in messages called IP datagrams. Like all
network protocol messages, IP uses a specific format for its datagrams.
We are of course looking here at IP
version 4 and so we will examine the IPv4
datagram format, which was defined in RFC 791 along with the rest of
IPv4.
The IPv4 datagram is conceptually
divided into two pieces: the header and the payload. The
header contains addressing and control fields, while the payload carries
the actual data to be sent over the internetwork. Unlike some message
formats, IP datagrams do not have a footer following the payload.
Even though IP is a relatively simple,
connectionless, unreliable protocol, the IPv4 header carries
a fair bit of information, which makes it rather large. At a minimum,
it is 20 bytes long, and with options can be significantly longer. The
IP datagram format is described in Table 56
and illustrated in Figure 86.
Table 56: Internet Protocol Version 4 (IPv4) Datagram Format
Field
Name
|
Size (bytes)
|
Description
|
Version
|
1/2
(4 bits)
|
Version: Identifies
the version of IP used to generate the datagram. For IPv4, this is of
course the number 4. The purpose of this field is to ensure compatibility
between devices that may be running different versions of IP. In general,
a device running an older version of IP will reject datagrams created
by newer implementations, under the assumption that the older version
may not be able to interpret the newer datagram correctly.
|
IHL
|
1/2
(4 bits)
|
Internet
Header Length (IHL): Specifies the length of the IP header,
in 32-bit words. This includes the length of any options fields and
padding. The normal value of this field when no options are used is
5 (5 32-bit words = 5*4 = 20 bytes). Contrast to the longer Total
Length field below.
|
TOS
|
1
|
Type Of Service (TOS):
A field designed to carry information to provide quality of service
features, such as prioritized delivery, for IP datagrams. It was never
widely used as originally defined, and its meaning has been subsequently
redefined for use by a technique called Differentiated Services (DS).
See below for more information.
|
TL
|
2
|
Total
Length (TL): Specifies the total length of the IP datagram,
in bytes. Since this field is 16 bits wide, the maximum length of an
IP datagram is 65,535 bytes, though most are much smaller.
|
Identification
|
2
|
Identification:
This field contains a 16-bit value that is common to each of the fragments
belonging to a particular message; for datagrams originally sent unfragmented
it is still filled in, so it can be used if the datagram must be fragmented
by a router during delivery. This field is used by the recipient to
reassemble messages without accidentally mixing fragments from different
messages. This is needed because fragments may arrive from multiple
messages mixed together, since IP datagrams can be received out of order
from any device. See
the discussion of IP message fragmentation.
|
Flags
|
3/8
(3 bits)
|
|
Fragment
Offset
|
1 5/8
(13 bits)
|
Fragment Offset:
When fragmentation of a message occurs, this field specifies the offset,
or position, in the overall message where the data in this fragment
goes. It is specified in units of 8 bytes (64 bits). The first fragment
has an offset of 0. Again, see
the discussion of fragmentation for a
description of how the field is used.
|
TTL
|
1
|
Time
To Live (TTL): Short version: Specifies how long the datagram
is allowed to live on the network, in terms of router hops.
Each router decrements the value of the TTL field (reduces it by one)
prior to transmitting it. If the TTL field drops to zero, the datagram
is assumed to have taken too long a route and is discarded.
See below for the longer explanation of TTL.
|
Protocol
|
1
|
|
Header
Checksum
|
2
|
Header
Checksum: A checksum computed over the header to provide basic
protection against corruption in transmission. This is not the more
complex CRC code typically used by data link layer technologies such
as Ethernet; it's just a 16-bit checksum. It is calculated by dividing
the header bytes into words (a word is two bytes) and then adding them
together. The data is not checksummed, only the header. At each hop
the device receiving the datagram does the same checksum calculation
and on a mismatch, discards the datagram as damaged.
|
Source
Address
|
4
|
Source Address:
The 32-bit IP address of the originator of the datagram. Note that even
though intermediate devices such as routers may handle the datagram,
they do not normally put their address into this fieldit is always
the device that originally sent the datagram.
|
Destination
Address
|
4
|
Destination
Address: The 32-bit IP address of the intended recipient of
the datagram. Again, even though devices such as routers may be the
intermediate targets of the datagram, this field is always for the ultimate
destination.
|
Options
|
Variable
|
Options: One or
more of several types of options may be included after the standard
headers in certain IP datagrams. I discuss them in the
topic that follows this one.
|
Padding
|
Variable
|
Padding:
If one or more options are included, and the number of bits used for
them is not a multiple of 32, enough zero bits are added to pad
out the header to a multiple of 32 bits (4 bytes).
|
Data
|
Variable
|
Data: The data
to be transmitted in the datagram, either an entire higher-layer message
or a fragment of one.
|
Figure 86: Internet Protocol Version 4 (IPv4) Datagram Format This diagram shows graphically the all-important IPv4 datagram format. The first 20 bytes are the fixed IP header, followed by an optional Options section, and a variable-length Data area. Note that the Type Of Service field is shown as originally defined in the IPv4 standard.
|
Thats a pretty big
table, because the IP datagram format is pretty important and has a
lot of fields that need explaining. To keep it from being even longer,
I decided to move a couple of the more complex descriptions out of the
table.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|