The IP packet contains several different parts in the header as you have
understood from the previous introduction to the IP protocol. The whole header
is meticuluously divided into different parts, and each part of the header is
allocated as small of a piece as possible to do it's work, just to give the
protocol as little overhead as possible. You will see the exact configuration of
the IP headers in the IP headers image.
 | Understand that the explanations of the different headers are very brief and
that we will only discuss the absolute basics of them. For each type of header
that we discuss, we will also list the proper RFC's that you should read for
further understanding and technical explanations of the protocol in question.
As a sidenote to this note, RFC stands for Request For Comments, but these
days, they have a totally different meaning to the Internet community. They
are what defines and standardises the whole Internet, compared to what they
were when the researchers started writing RFC's to each other. Back then,
they were simply requests for comments and a way of asking other researchers
about their opinions.
|
The IP protocol is mainly described in RFC 791 - Internet Protocol. However, this RFC is also updated by RFC 1349 - Type of Service in the Internet Protocol
Suite, which was obsoleted by
RFC 2474 - Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers, and which was updated
by RFC 3168 - The Addition of Explicit Congestion Notification
(ECN) to IP and
RFC 3260 - New Terminology and Clarifications for
Diffserv.
 | As you can see, all of these standards can get a little bit hard to follow at
times. One tip for finding the different RFC's that are related to each other
is to use the search functions available at RFC-editor.org. In the case of IP, consider that the
RFC 791 is the basic RFC, and all of the other are simply updates and changes
to that standard. We will discuss these more in detail when we get to the
specific headers that are changed by these newer RFC's.
One thing to remember is, that sometimes, an RFC can be obsoleted (not used at
all). Normally this means that the RFC has been so drastically updated and that
it is better to simply replace the whole thing. It may also become obsolete for
other reasons as well. When an RFC becomes obsoleted, a field is added to the
original RFC that points to the new RFC instead.
|
Version - bits 0-3. This is a version number of the IP protocol in binary. IPv4
iscalled 0100, while IPv6 is called 0110. This field is generally not used for
filtering very much. The version described in RFC 791 is IPv4.
IHL (Internet Header Length) - bits 4-7. This field tells us how long the IP
header is in 32 bit words. As you can see, we have split the header up in this
way (32 bits per line) in the image as well. Since the Options field is of
optional length, we can never be absolutely sure of how long the whole header
is, without this field. The minimum length of this of the header is 5 words.
Type of Service, DSCP, ECN - bits 8-15. This is one of the most complex areas
of the IP header for the simple reason that it has been updated 3 times. It
has always had the same basic usage, but the implementation has changed
several times. First the field was called the Type of Service field. Bit 0-2
of the field was called the Precedence field. Bit 3 was Normal/Low delay, Bit
4 was Normal/High throughput, Bit 5 was Normal/High reliability and bit 6-7
was reserved for future usage. This is still used in a lot of places with
older hardware, and it still causes some problems for the Internet. Among
other things, bit 6-7 are specified to be set to 0. In the ECN updates (RFC ,
we start using these reserved bits and hence set other values than 0 to these
bits. But a lot of old firewalls and routers have built in checks looking if
these bits are set to 1, and if the packets do, the packet is discarded.
Today, this is clearly a violation of RFC's, but there is not much you can do
about it, except to complain.
The second iteration of this field was when the field was changed into the DS
field as defined in RFC 2474. DS stands for Differentiated Services. According
to this standard bits 8-14 is Differentiated Services Code Point (DSCP) and the
remaining two bits (15-16) are still unused. The DSCP field is pretty much used
the same as in how the ToS field was used before, to mark what kind of service
this packet should be treated like if the router in question makes any
difference between them. One big change is that a device must ignore the
unused bits to be fully RFC 2474 compliant, which means we get rid of the
previous hassle as explained previously, as long as the device creators follow
this RFC.
The third, and almost last, change of the ToS field was when the two,
previously, unused bits were used for ECN (Explicit Congestion Notification),
as defined in RFC 3168. ECN is used to let the end nodes know about a routers
congestion, before it actually starts dropping packets, so that the end nodes
will be able to slow down their data transmissions, before the router actually
needs to start dropping data. Previously, dropping data was the only way that a
router had to tell that it was overloaded, and the end nodes had to do a slow
restart for each dropped packet, and then slowly gather up speed again. The two
bits are named ECT (ECNCapable Transport) and CE (Congestion Experienced)
codepoints.
The final iteration of the whole mess is RFC 3260 which gives some new
terminology and clarifications to the usage of the DiffServ system. It doesn't
involve too many new updates or changes, except in the terminology. The RFC is
also used to clarify some points that were discussed between developers.
Total Length - bits 16 - 31. This field tells us how large the packet is in
octets, including headers and everything. The maximum size is 65535 octets, or
bytes, for a single packet. The minimum packet size is 576 bytes, not caring if
the packet arrives in fragments or not. It is only recommended to send larger
packets than this limit if it can be guaranteed that the host can receive it,
according to RFC 791. However, these days most networks runs at 1500 byte packet
size. This includes almost all ethernet connections, and most Internet
connections.
Identification - bits 32 - 46. This field is used in aiding the reassembly of
fragmented packets.
Flags - bits 47 - 49. This field contains a few miscellaneous flags pertaining
to fragmentation. The first bit is reserved, but still not used, and must be
set to 0. The second bit is set to 0 if the packet may be fragmented, and to 1
if it may not be fragmented. The third and last bit can be set to 0 if this was
the last fragment, and 1 if there are more fragments of this same packet.
Fragment Offset - bits 50 - 63. The fragment offset field shows where in the
datagram that this packet belongs. The fragments are calculated in 64 bits, and
the first fragment has offset zero.
Time to live - bits 64 - 72. The TTL field tells us how long the packet may
live, or rather how many "hops" it may take over the Internet. Every process
that touches the packet must remove one point from the TTL field, and if the
TTL reaches zero, the whole packet must be destroyed and discarded. This is
basically used as a safety trigger so that a packet may not end up in an
uncontrollable loop between one or several hosts. Upon destruction the host
should return an ICMP Destination Unreachable message to the sender.
Protocol - bits 73 - 80. In this field the protocol of the next level layer is
indicated. For example, this may be TCP, UDP or ICMP among others. All of these
numbers are defined by the Internet Assigned Numbers Authority. All numbers can
befound on their homepage Internet Assigned
Numbers Authority.
Header checksum - bits 81 - 96. This is a checksum of the IP header of the
packet.This field is recomputed at every host that changes the header, which
means pretty much every host that the packet traverses over, since they most
often change the packets TTL field or some other.
Source address - bits 97 - 128. This is the source address field. It is
generally written in 4 octets, translated from binary to decimal numbers with
dots in between. That is for example, 127.0.0.1. The field lets the receiver
know where the packet came from.
Destination address - bits 129 - 160. The destination address field contains the
destination address, and what a surprise, it is formatted the same way as the
source address.
Options - bits 161 - 192 <> 478. The options field is not optional, as it
may sound. Actually, this is one of the more complex fields in the IP header.
The options field contains different optional settings within the header, such
as Internet timestamps, SACK or record route options. Since these options are
all optional, the Options field can have different lengths, and hence the whole
IP header. However, since we always calculate the IP header in 32 bit words, we
must always end the header on an even number, that is the multiple of 32. The
field may contain zero or more options.
The options field starts with a brief 8 bit field that lets us know which
options are used in the packet. The options are all listed in the TCP Options table, in
the TCP options appendix.
For more information about the different options, read the proper RFC's. For an
updated listing of the IP options, check at Internet Assigned
Numbers Authority.
Padding - bits variable. This is a padding field that is used to make the header
end at an even 32 bit boundary. The field must always be set to zeroes straight
through to the end.
