internetworking 1 - the basics about ipv4, icmp and igmp

********************************************************

[ copyright (c) 2003 by rattle ]

[ http://www.awarenetwork.org/ ]

__________
[ contents ]
����������
::[0] intro
::[1] the internet protocol version 4
:..
: ::(1.1) the ipv4 header
: ::(1.2) fragmentation
:
::[2] internet control message protocol
:..
: ::(2.1) the icmp header
: :..
: : ::{2.1.1} echo
: : ::{2.1.2} destination unreachable
: : ::{2.1.3} source quench
: : ::{2.1.4} redirect
: : ::{2.1.5} time exceeded
: : ::{2.1.6} parameter problem
: : ::{2.1.7} address mask
: :
: ::[2.2] traceroute
: ::[2.3] ping
:
::[3] internet group management protocol
:..
: ::(3.1) mutlticasting && groups
: ::(3.2) the igmp header
: ::(3.3) the igmp bug
:
::[a] networking byte order
::[b] bits && bytes
:..
: :: (b-1) binary calculations
: :: (b-2) units && values
:
::[c] dod reference model
:
::[4] further reading
::[5] last words

___ _______
[ 0 ] :: [ intro ]
��� �������
peace to all the windows survivors in the linux-dominated world of computer
security!

so, what is this tutorial about - it is about the low level aspects of
communication between computers, especially
across the internet. this will not yet cover all aspects and all layers of
networking and network traffic and i
 will not explain any kind of transport protocol such as tcp or udp here, this
paper is actually about ip. i plan
to continue this paper by writing a tutorial abot the transport layer, about
ipv6 and about how to use raw sockets
in windows 2000 and windows xp. however, i realized that fundamental knowledge
about ip is important for a good
understanding of networking in general, and since i haven't seen many indepth
papers yet, i decided to write one.

this is not ment for total experts, neither is it ment for total newbies. you
should have an average knowledge of
high level networking, coding in c and that's about it. i won't let you write a
device driver or similar stuff.
if you think you are not ready to read this, just buy a good book and learn
some basic c/c++ coding at first.
then dig the internet for some basic tutorials on ip addressing, routing,
subnets and some common protocols like
http just to get the idea. if you think you are to l337 to read this, go play
hide and go fuck yourself.

be sure to check [appendix b] whenever you do not understand the relation of

bits, bytes, words and dwords.
[appendix a] is required for better understanding of the code samples that will
follow. [appendix c] is also a
very important appendix since i will often refer to different networking layers
in the tutorial. you should
definitely check the appendixes at first if you are not familliar with their
contents.

___ _________________________________
[ 1 ] :: [ the internet protocol version 4 ]
��� ���������������������������������
the internet protocol version 4 is the current standard, and it's the most
basic protocol that we, as a software
developer, can make use of. ip is what actually brings the data from one
computer to another one. as a protocol,
"it" is responsible for addressing and delivery. saying that the protocol
itself does this is not really easy to
understand, and it's not really correct anyway. not the protocol, but the
routers all over the globe transport the
data by applying the internet protocol. it's basically like this: you send a
packet of data with an internet
protocol header (which will be discussed later) and the next router routes this
packet by the information he finds
in the ip header. after some hops from one router to the next one, your packet
finally reaches its destination. i
already mentioned it, ip has a header just like any hight-level protocol that
you know. and honestly, it's the only
thing we should care about in this tutorial.

_____ _________________
( 1.1 ) : ( the ipv4 header )
����� �����������������

the ip header works in the same way all headers of all protocols work - it
gives some information about the
exchange of information. if you send data, you first send the header which
contains this information and
 afterwards, the actual data follows. pictures help the human mind to
understand a certain matter better,
and since the presentation within the rfc's sucks, i thought i would make yet
another ascii visualization of
the ip header:

<-------------------------------------------- bits
--------------------------------------------->
_________________________________________________________________________
______________________
|00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|20|21|22|23|
24|25|26|27|28|29|30|31|
|�����������|�����������|�����������������������|
�����������������������������������������������|
| version | length | type of service | total length
|
|___________|___________|_______________________|
_______________________________________________|
|�����������������������������������������������|��������|
��������������������������������������|
| identification | flags | fragment offset
|
|_______________________________________________|________|
______________________________________|
|�����������������������|�����������������������|
�����������������������������������������������|
| time to live | protocol | header checksum
|
|_______________________|_______________________|
_______________________________________________|
|
����������������������������������������������������������������������������������
�������������|
| source address
|
|
__________________________________________________________________________________
_____________|
|
����������������������������������������������������������������������������������
�������������|
| destination address
|
|
__________________________________________________________________________________
_____________|
|�����������������������������������������������������������������������|
�����������������������|
| options |
padding |
|_______________________________________________________________________|
_______________________|
|
##################################################################################
#############|
|###########################################[ data ]
############################################|
|
##################################################################################
#############|
�������������������������������������������������������������������������
����������������������
(figure 1.1.1: the ip header format as explained in rfc 791, part 3.1:
http://www.rfc-editor.org/rfc/rfc791.txt)

every little box with a number in it stands for one binary digit. the version,
for example, has 3 binary digits
and since this is an ipv4 tutorial, these 4 digits will always be "0100" in
our examples since "100" is "4" in
decimal. as always, refer to [appendix b] if you feel mentally threatened by
the word "bit".

here's a brief explaination of all the differen header fields:

version
~~~~~~~
the version field contains the version number of the internet protocoll
currently used. the current standard is
version 4, but due to its disadvantages concerning the ammount of available
addresses, security problems,
complicated system configuration and several other issues, the new ipv6 will
be made global standard soon i think.

interne header length - ihl

~~~~~~~~~~~~~~~~~~~~~~~~~~~
this value defines the length of the actual header (not the data body),
expressed as a multiple of 4. why 4?
because 4 bytes are one double word and the ip header always ends on such a
double word boundary. this field
is required since the length of the header can vary due to the possibility of
adding options. the smallest
valid value is 5, which means 20 bytes (5*4=20), in this case, no options are
set. by adding options, the header
lenght can grow to up to 60 byte (maximum value for the ihl field: 15)

type of service - tos

~~~~~~~~~~~~~~~~~~~~~
the tos field defines the service requested by an ip - datagram. this field
allows you to specify, how the routers
have to deal with your precious packet once you sent it. this is very usefull
when sending data over large
networks but unfortunately, most commercial products do not support the tos
field at all or only by using a tacky
implementation. have a look at the picture of the complete ip header (figure
1.1.1), this is where you will find
the tos ocet (ocet: eight values, or eight bits). here is a more detailed
representation:

_______________________________________________________
| 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 |
|�������������������������������������������������������|
| complete tos ocet within ip header |
|_______________________________________________________|
 and this is what the ocet itself looks like, if we have a
closer look at it:
_______________________________________________________
| 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 |
|��������������������|������|������|������|�������������|
| precedence | d | t | r | mbz |
|____________________|______|______|______|_____________|

(figure 1.1.2 - the tos ocet)

the precedence -field consists of 3 bits which can have the following,
different meanings:

+--------+---------+------------------------+
| binary | decimal | description |
+--------+---------+------------------------+
| 000 | 0 | routing |
| 001 | 1 | priority |
| 010 | 2 | immediate |
| 011 | 3 | flash |
| 100 | 4 | flash override |
| 101 | 5 | critical |
| 110 | 6 | internetwork control |
| 111 | 7 | network control |
+--------+---------+------------------------+

d stands for delay, and if it is set to 1, the delay is being minimized. t

stands for throughput and if it is set
to 1, the throughput is being maximized. finally, r stands for reliability,
and setting it to 1 maximizes the
reliability.

the mbz bits stand for "must be zero" and that says it all - these are
reserved values that have to be zero and
which were planned to be used for further implementations ... i don't think
that these reserved values will be
used at any time in any way for any new implementation since ipv6 already has
a completely different header
structure, but that's only my opinion. i hate reserved values.

total length
~~~~~~~~~~~~
this is the total length of the complete datagram to be sent. it includes the
length of the ip header and the
length of all the data that follows the ip header, including headers of high-
level protocols. a computer has to
be capable of receiving and handling packets with a length of 576 bytes,
datagrams that are larger than that
have to be fragmented in order to be delivered correctly. (see (1.2) for more
information about fragmented
packets)

identification
 ~~~~~~~~~~~~~~
this is a unique number which allows the destination host to find out what
packet belongs to which datagram so
that he can reassemble the single packets to form the complete datagram he
received. all fragmented packets of
one datagram have the same identification number, which is set by the sender.

flags
~~~~~
this field is 3 bits long, the first bit is reserved and not used in any
implementation yet, to my knowledge.
did i ever mention i hate reserved values?? anyway, the second two bits
determine whether a packet is
fragmented and/or may be fragmented. the field is structured as follows:

____________________
| 01 | 02 | 03 |
|������|������|������|
| res. | df | mf |
|______|______|______|

the df bit stands for "don't fragment" and prevents packets from being
fragmented at all if it is set to 1.
the mf bit stands for "more fragments" and is set in all but the last packet
in the sequence of fragments
which are to be reassembled by the destination host.

fragment offset
~~~~~~~~~~~~~~~
when a datagram has been fragmented, the destination host has to reassemble
the fragmened packets to get the
data. "well", you will say, "he can identify them by the identification flag
to put them together". yeah,
but in what order? imagine you recevie a text document over the web and your
computer just puts the packets
together randomly, then you would certainly not be able to read it, eh? well
the fragment offset is just a
number that specifies to which position, relative to the beginning of the
complete datagram, this packet belongs.

all fragments except the last one have to be a multible of 8 bytes in size -
this is the elementary fragment
unit. i did not make this up, this is an open standard and i have no idea why
it is exactly 8 bytes and not 4.
check [appendix b]

ttl - time to live

~~~~~~~~~~~~~~~~~~
remember how packets reach their destination host? they get routed through to
it by being sent from one router
to the next one, over a couple of nodes all over the globe. now sometimes
packets get lost, and if they
wouldn't be discarded somehow and sometime, they would forever be roaming
about in the world wide web. thus,
the ttl flag was implemented to represent the time that a packet has until it
will be discarded. by definition,
 the ttl value represents the number of seconds that a packet has until it
will die [rfc791]. every node that
routes the packet has to decrease the value by at least one. if the packet
remains stored in this node for a
longer time, the value has to be decreased multiple times. of course, the
packet is discarded once the value
reaches 0. the sender of the packet will be informed about a discarded packet
by an icmp message. [rfc1700]
defines a default value of 64.

[rfc791] - http://www.rfc-editor.org/rfc/rfc791.txt
[rfc1700] - http://www.rfc-editor.org/rfc/rfc791.txt

protocol
~~~~~~~~
this flag contains the number of the transport protocol that follows this ip
header - ip only performst the
most basic task of sending and routing the datagram, the transport layer has
to use this service provided by
ip and perform the next task. for example, ip does not guarantee that all
packets reach their destination -
the underlaying transport protocol tcp (transmission control protocol)
ensures that all data that reaches the
destination host is the same that has been sent by the sender. not all
transport protocols do ensure this,
and if you want to know more about the whole achitecture and how the
different layers interact with each
other, please refer to [appendix c].

so anyway, you will deal with tcp in most cases, although i will also explain
the icmp and igmp (yehaw, the
famous windows igmp bug!) protocols in this tutorial. for all up-to-date
protocol names and related values,
refer to the homepage of the internet assigned numbers authority:
http://www.iana.org/

some common values:

+----------+---------+-------------+------------------------------------+
| binary | decimal | protocol | detailed description |
+----------+---------+-------------+------------------------------------+
| 00000001 | 1 | icmp | internet contol message protocol |
| 00000010 | 2 | igmp | internet group management protocol |
| 00000110 | 6 | tcp | transmission control protocol |
| 00010001 | 17 | udp | user datagram protocol |
+----------+---------+-------------+------------------------------------+

all values:

+----------+---------+-------------+------------------------------------+
| binary | decimal | protocol | detailed description |
+----------+---------+-------------+------------------------------------+
| 00000001 | 1 | icmp | internet contol message protocol |
| 00000010 | 2 | igmp | internet group management protocol |
| 00000011 | 3 | ggp | gateway-to-gateway protocol |
| 00000101 | 5 | st | stream |
| 00000110 | 6 | tcp | transmission control protocol |
 | 00000111 | 7 | ucl | ucl |
| 00001000 | 8 | egp | external gateway protocol |
| 00001001 | 9 | igp | interior gateway protocol |
| 00001010 | 10 | bnn-rcc-mon | bbn rcc monitoring |
| 00001011 | 11 | nvp-ii | network voice protocol |
| 00001100 | 12 | pup | pup |
| 00001101 | 13 | argus | argus |
| 00001110 | 14 | emcon | emcon |
| 00001111 | 15 | xnet | cross net debugger |
| 00010000 | 16 | chaos | chaos |
| 00010001 | 17 | udp | user datagram protocol |
| 00010010 | 18 | mux | multiplexing |
| 00010011 | 19 | dcn-meas | dcn measurement subsystems |
| 00010100 | 20 | hmp | host monitoring protocol |
| 00010101 | 21 | prm | packet radio measurement |
| 00010110 | 22 | xns-idp | xerox ns idp |
| 00010111 | 23 | trunk-1 | trunk 1 |
| 00011000 | 24 | trunk-2 | trunk 2 |
| 00011001 | 25 | leaf-1 | leaf 1 |
| 00011010 | 26 | leaf-2 | leaf 2 |
| 00011011 | 27 | rdp | reliable data prococol |
| 00011100 | 28 | irtp | internet reliable transaction |
| 00011101 | 29 | iso-tp4 | iso transport protocol class 4 |
| 00011110 | 30 | netblt | bulk data transfer protocol |
| 00011111 | 31 | mfe-nsp | mfe network services protocol |
| 00100000 | 32 | merit-inp | merit internodal protocol |
| 00100001 | 33 | sep | sequential exchange protocol |
| 00111110 | 62 | cftp | cftp |
| 01000000 | 64 | sat-expak | satnet and backroom expak |
| 01000001 | 65 | mit-subnet | mit subnet support |
| 01000010 | 66 | rvd | mit remote virtual disk protocol |
| 01000011 | 67 | ippc | internet pluribus packet core |
| 01000101 | 69 | sat-mon | satnet monitoring |
| 01000111 | 71 | ipcv | internet packet core utility |
| 01001100 | 76 | br-sat-mon | backroom satnet monitoring |
| 01001110 | 78 | wb-mon | wideband monitoring |
| 01001111 | 79 | wb-expak | wideband expak |
+----------+---------+-------------+------------------------------------+

header checksum
~~~~~~~~~~~~~~~

from the free online dictionary of computing

(http://foldoc.doc.ic.ac.uk/foldoc/index.html, 01/25/2003)

"a computed value which depends on the contents of a block of data and
which is
transmitted or stored along with the data in order to detect corruption
of the
data. the receiving system recomputes the checksum based upon the
received data
and compares this value with the one sent with the data. if the two
values are
the same, the receiver has some confidence that the data was received
correctly. "
 the checksum field contains the 16-bit one's complement of the one's
complement sum of the whole
datagram including ip header. for computing the checksum, the checksum field
is first set to zero.
so basically, the checksum is a pain in the ass since you have to calculate
it absolutely correct
depending on the datagram you are about to send if you want that your packet
reaches its
destination. the algorithm for calculating a checksum looks like this:

unsigned short calculatechecksum(

const unsigned short *usbuf,
int isize
) {
unsigned long uschksum=0;

while (isize>1) {
uschksum += *usbuf++;
isize -= sizeof(unsigned short);
}

if (isize) uschksum += *(unsigned char*)usbuf;

uschksum = (uschksum >> 0x10) + (uschksum & 0xffff);

uschksum += (uschksum >> 0x10);

return (unsigned short)(~uschksum);

}

update on february the 17th, 2004: i wrote a checksum function in python

which i would like to
add here. python has some amazing advantages for building custom packets (by
using the struct
module, for instance):

from types import *

def ensureint(c):
if (type(c)==stringtype): return ord(c[0])
else: return int(c)

def checksum(buffer):

chk = 0; iter = 0

while (iter <= (len(buffer)-2)):

chk += ensureint(buffer[iter]) << 8
chk += ensureint(buffer[iter+1])
iter += 2

if (iter!=len(buffer)): chk += ensureint(buffer[iter])

chk = (chk>>0x10)+(chk&0xffff)
chk += (chk>>0x10)

return ((~chk)&0xffff);
 source ip address
~~~~~~~~~~~~~~~~~
that's the ip that sends the data - yep, the sender defines this value. and
this is the point where ip
spoofing is theoretically possible: we just change the value to anything we
want. what? sample source code? be
patient, there's some source code later. now ip spoofing has a major problem
when the transport
protocol is more complex (like tcp) - in this case, you will not get any
reply since the ip that you are
sending the datagram to will reply to the spoofed ip address you have set in
this field of the header.
well, in some cases, we do not need to get any reply, though ...

destination ip address
~~~~~~~~~~~~~~~~~~~~~~
contains the ip address of the computer that the datagram will be sent to.

some info about ip addresses: you probably know ip addresses as

they are written in the dotted decimal notation, eg: 192.168.0.1
now wtf is this in binary, what will this look like in an ip
header? that's actually quite simple:

192 is 11000000 in binary.

168 is 10101000 in binary.
0 is 00000000 in binary.
1 is 00000001 in binary.

=> 192.168.0.1 is 11000000.10101000.00000000.00000001 in binary.

=> leaving out the dots, we get:

11000000101010000000000000000001

i think you got the point. this binary value can be expressed as
a decimal number as well btw, but i am too lazy to calculate that.

options
~~~~~~~
this flag was added to provide the possibility of adding more different
information to the ip header which
was not part of the original ip header dessign. the option field has a
variable length, it is not always
24 bits long. options are an interesting topic, but i do not think that they
are of any interest for
this tutorial. you will certainly find detailed information on options on the
web.

_____ _______________
( 1.2 ) : ( fragmentation )
����� ���������������
i have talked a lot about this whole fragmentation stuff, but what does it
actually mean? to ensure that a
datagram can be sent across any type of network, the internet protocl has to
suit the packet size to the
 respective network. every kind of network has its own maximum packet size
(maximum transfer unit - mtu),
which defines the maximum size for packets that are to be sent through the
network. for instance, the mtu
of x.25 networks is 128 bytes, and an ethernet-packet may not be larger than
1500 bytes. if the mtu of the
network is smaller than the size of the datagram, then the datagram has to be
fragmented.

however, it is not sufficiant that the transport layer (tcp) uses smaller
packets - a packet on its way from
the source host to its destination will be routed thought different networks
with different mtu's. because
of that, a more flexible mechanism which allows fragmentation at the ip level
is necessary. well, and this
mechanism is called fragmentation ;d. fragmentation means that ever single
router on this globe has to be
able to fragment and reassemble received packets.

___________________________________________________________________
| | |
| ip-header | data |
|_____________|_____________________________________________________|
/ /| |
\
/ / | |
\
/ / | |
\
___________/__________/ |______________________|
_____________________\
| |##########| | |##########| | |
##########|
| ip-header |#fragment#| | ip-header |#fragment#| | ip-header |
#fragment#|
| |##########| | |##########| | |
##########|
���������������������� ����������������������
����������������������
(figure 1.2.1: fragmentation sheme)

every fragment of a framgented datagram contains its own, complete ip header.

by using the identification field,
all packets can be recognized as part of the originating datagram. each of the
respective packets can indeed
use different ways to get from the sender to the destination host. thus, the
fragment offset field of the ip
header was implemented to indicate at what position relative to the beginning
of the complete datagram the
respective fragment is located.

___ __________________________________________
[ 2 ] :: [ icmp - internet control message protocol ]
��� ������������������������������������������
besides the internet protocol, there are some additional protocols at the lower
level. one of these is the
internet control message protocol, icmp, which is used for notification and
error messages. icmp's are always
sent embedded to an ip datagram. icmp is mainly used for information purpose,
but sometimes it is also used
for checking whether a host is reachable, this is known as ping.

the complete icmp protocol is a very flexible protocl with many options and
even fields that can contain
miscellaneous data. therefore, icmp can also be used as a "tunnel" to transmit
information that it was not
intended to be used for. however, this technique (obviously called "icmp
tunneling") has not been a real
issue to the computer security world, since network layer firewalls are able to
simply block all icmp
requests reaching a network from the outside. and since icmp is not offering
any necessary services like
tcp does, it can merely be ignored.

icmp is not a transport layer protocol, but it is sent encapsulated within an

ip datagram:

____________________________________________________________
| |#######################################|
| ip-header |# datagram data #######################|
| |#######################################|
������������������������������������������������������������
^ ^
| |
|_______________________________________|
| |#########################|
| icmp-header |# icmp-data #############|
| |#########################|
���������������������������������������
(figure 2.0.1: encapsulation of icmp messages)

refer to [appendix c] for information about "layers" and the complete dod
reference model.

_____ _________________
( 2.1 ) : ( the icmp header )
����� �����������������
icmp is an error reporting and diagnostic utility - it is considered a
required part of any ip implementation.
since the information carried by the icmp message is always different,
according to the big ammount of possible
ways of use, the underlaying structure of the icmp header is always the same,
although the respective fields
have a very variable meaning.

remember this representation of icmp is relative to the ammount of bytes used

for each field, not to the
ammount of bits. refer to [appendix b].

<------------------------ bytes ------------------------> - - - - - - - - - -

- - - - - - >
_____________________________________________________________________________
_____________
| | | | | | | | | | | |
|
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
11 | ....
| | | | | | | | | | | |
|
|������|������|�������������|���������������������������|
����������������������������������
| type | code | checksum | miscellaneous | optional variable
appendix
|______|______|_____________|___________________________|
__________________________________

(figure 2.1.1: a generalized icmp header)

icmp type
~~~~~~~~~
the type of the message defines what the message is actually about, it gives
broad information about what
has happened. possible values are:

+------+--------------------------------+
| 0 | echo reply |
| 3 | destination unreachable |
| 4 | source quench |
| 5 | redirect |
| 8 | echo |
| 9 | router advertisement |
| 10 | router solicitation |
| 11 | time exceeded |
| 12 | parameter problem |
| 13 | time-stamp request |
| 14 | time-stamp reply |
| 15 | information request (obsolete) |
| 16 | information reply (obsolete) |
| 17 | address mask request |
| 18 | address mask reply |
| 30 | traceroute |
| 31 | datagram conversion error |
| 32 | mobile host redirect |
| 33 | ipv6 where-are-you |
| 34 | ipv6 i-am-here |
| 35 | mobile registration request |
| 36 | mobile registration reply |
| 37 | domain name request |
| 38 | domain name reply |
| 39 | skip |
| 40 | photuris |
+------+--------------------------------+

icmp code
~~~~~~~~~
 the meaning of this value depends on the icmp type. for instance, in an echo
or echo reply message, the code is
always 0 and has no meaning whereas in a "destination unreachable" message,
it can specify a more detailed error
code. i will discuss most of the possible icmp messages and replies later
which will include explainations of
the respective codes.

checksum
~~~~~~~~
this is the same checksum as ip uses, calculated in the same way and the same
pain in the ass. it is calculated
by calculating the 16-bit one's complement of the one's complement sum of the
whole icmp message, excluding the
ip header, of course. for computing the checksum, the checksum field is first
set to zero.

miscellaneous
~~~~~~~~~~~~~
well, the contents of this field once again differ, depending on the type of
message sent. the echo and echo
reply messages, for instance, split this field up into two words that specify
a uinque identifier and a
sequence number. other icmp messages don't use this miscellaneous data at
all, it's once again a completely
variable field - however, it is included in all icmp message, in contrast to
the optional appendix. if the
miscellaneous data is not used, the field is set to zero.

optional variable appendix

~~~~~~~~~~~~~~~~~~~~~~~~~~
depending on the icmp message, the miscellaneous field can be expanded to
include more information. in some
cases, this field contains the ip header of the datagram that caused the
message and further 64 bits of it's
data, to give the receiver of the control message better possibilities to
process the error. in other cases
that will be discussed later, it is used for completely different purposes.

as you can see, icmp can be used for a lot of different purposes. because of
that, i listed several ways of use,
along with the according icmp header structure below. you do not have to read
these sections for a better
understanding of networking as whole, but it might come in handy when
programming actual applications which
apply icmp functions such as echo. also remember that i did not include all
possible icmp messages to this
list - if you are interested in the messages that were not included, please
refer to other sources, you should
find enough information on the net by using any search engine. and if nothing
helps, drop me an email and
i will try to help good as possible.

_______ ______
{ 2.1.1 } � { echo }
������� ������
echo and echo reply messages are used to examine the speed of a certain
network and also if a certain host
is reachable or not. a host is often examined by using an icmp echo message
before the client connects, this
way he can be sure that the host is available. these days, icmp can be
blocked by firewalls and thus, echo
is not a clear indicator for the availability of a certain host. however,
most servers still support the
complete variety of icmp messages sufficiantly, of course.

to perform an echo examination, the client computer sends an icmp echo

message - icmp type 8. once the echo
request reaches the server computer, it replies by sending an icmp echo reply
(icmp type 0) message to the
client computer. the identification field is used for a clear and unique
identification of the process that
sent the message. under windows, you can quite simply apply the return value
of this macro to the
identification field:

#define getprocid_16 ((unsigned short)(getcurrentprocessid()&0xffff))

the client computer numbers the echo requests that he sends sequentially. the
server that replies to an
echo request uses exactly the same sequence number when sending the
appropriate echo reply. this way, the
client computer can check the correctness of the reply easiely. the remaining
part of the icmp datagram
contains variable data, which usually consists of characters like
"1234567890". however, the size of this
variable data can be changed to about any value which can be used to examine
the behavious of a network
in relation to differently sized packets sent through it.

<------------------------ bytes ------------------------> - - - - - - - -

- - - - - - - - >
_________________________________________________________________________
_________________
| | | | | | | | | | |
| |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 | ....
| | | | | | | | | | |
| |
|������|������|�������������|�������������|�������������|
����������������������������������
| type | code | checksum | identifier | sequence | optional data
....
|______|______|_____________|_____________|_____________|
__________________________________

types: codes:
+-------+-----------------------------------+ +-------
+----------------------------------+
| value | meaning | | value | meaning
|
+-------+-----------------------------------+ +-------
+----------------------------------+
| 8 | echo | | 0 | only possible
value |
| 0 | echo reply | +-------
+----------------------------------+
+-------+-----------------------------------+

_______ _________________________
{ 2.1.2 } � { destination unreachable }
������� �������������������������
the name says it all - whenever any sort of ip datagram, no matter what
underlaying protocol or data it
contains, cannot be routed through to the destination host specified in the
destination ip address field,
this icmp message is generated and sent to the origin of the message. since
there are a lot of possible
reasons why a packet cannot be delivered, the unreachable message has the
largest ammount of possible
code parameters as far as i know. the destination unreachable icmp message
does not use the miscellaneous
field and thus, the field is set to zero. the variable appendix of the icmp
message is used to include
the ip header and 64 bits of data belonging to the packet that could not be
delivered.

- the icmp header is 8 bytes long.

- the ip header has a length of 5 dwords, thats ((5 * 32) = 160) bits or
((160 / 8) = 20) bytes.
- 64 bits of further data equal 8 bytes, just if you have problems with the
figure below. refer to
[appendix b]

=> the complete destination unreachable icmp message has a length of (8+8+20)
or 36 bytes which
equals 288 bits.

<---------------------------------------------------- bytes
-------------------------------------->
_________________________________________________________________________
________________________
| | | | | | | | | | |
| | | |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 | .... | 36 |
| | | | | | | | | | |
| | | |
|������|������|�������������|���������������������������|
�����������������������������������������|
| type | code | checksum | unused (must be zero) | ip header + 8
more bytes .... |
|______|______|_____________|___________________________|
_________________________________________|

types:
 +-------+----------------------------------------------------------+
| value | meaning |
+-------+----------------------------------------------------------+
| 3 | destinatiopn unreachable |
+-------+----------------------------------------------------------+

codes:
+-------+----------------------------------------------------------+
| value | meaning |
+-------+----------------------------------------------------------+
| 0 | network unreachable |
| 1 | host unreachable |
| 2 | protocol unreachable |
| 3 | port unreachable |
| 4 | fragmentation needed but don't fragment (df) bit was set |
| 5 | source route failed |
| 6 | dest. network unknown |
| 7 | dest. host unknown |
| 8 | source host isolated (obsolete) |
| 9 | destination network administratively prohibited |
| 10 | destination host administratively prohibited |
| 11 | network unreachable for this type of service |
| 12 | host unreachable for this type of service |
| 13 | communication prohibited by filter |
| 14 | host precedence violation |
| 15 | precedence cutoff in effect |
+-------+----------------------------------------------------------+

_______ _______________
{ 2.1.3 } � { source quench }
������� ���������������
sometimes, a router's resources are not sufficiant to route a certain load of
data. this usually
happens when a computer sends data from a fast network through a slower one
to the destination network
or when several different routers are sending their datagrams through a
single router - the router
cannot process the packets fast enough. once this overflow exceeds the entire
resources of such a
router, the router starts to discard packets. for each discarded packet, the
router sends a source
quench icmp message to the sender of the datagram. the sender regulates the
ammount of packets sent
according to the source quench messages he receives. the main problem of this
mechanism is the fact
that these icmp messages themselves use the routers resources and thus they
are hardly being used
these days. the packet flow regulation is commonly a task of the transport
layer. refer to
[appendix c]

<---------------------------------------------------- bytes
-------------------------------------->
_________________________________________________________________________
________________________
| | | | | | | | | | |
| | | |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 | .... | 36 |
| | | | | | | | | | |
| | | |
|������|������|�������������|���������������������������|
�����������������������������������������|
| type | code | checksum | unused (must be zero) | ip header + 8
more bytes .... |
|______|______|_____________|___________________________|
_________________________________________|

types: codes:
+-------+-------------------------------------+ +-------
+-------------------------------------+
| value | meaning | | value | meaning
|
+-------+-------------------------------------+ +-------
+-------------------------------------+
| 4 | source quench - only possible value | | 0 | only
possible value |
+-------+-------------------------------------+ +-------
+-------------------------------------+

_______ __________
{ 2.1.4 } � { redirect }
������� ����������
when a router receives an ip packet that cannot be routed to its destination
since the router can't reach
the destination network for some reason, the packet has to be sent by using a
different route. the router
that notices the problem usually knows a correct route for the packet to be
used instead, and in this
case, it sends an icmp redirect message to the sender of the packet informing
him about the correct route.
the sender can now send the packet throught the correct router to the
destination network.

"correct route" is a bit optimistic in this case - imagine you would simply
(well, this should me more or
less simple) spoof an icmp redirect message to a certain computer which tells
this computer to use your
ip as the correct router. this is a possible way to establish spoofed
connections, launch man in the middle
attacks and similar stuff. the topic of spoofing could fill a tutorial
itself, so i won't go indepth here ...

the redirect header also includes the ip header and the first 64 bits of the
datagram that caused the
message, refer to {2.1.2} for calculations regarding the resulting icmp
message size.

<---------------------------------------------------- bytes
-------------------------------------->
 _________________________________________________________________________
________________________
| | | | | | | | | | |
| | | |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 | .... | 36 |
| | | | | | | | | | |
| | | |
|������|������|�������������|���������������������������|
�����������������������������������������|
| type | code | checksum | router ip address | ip header + 8
more bytes .... |
|______|______|_____________|___________________________|
_________________________________________|

types:
+-------
+----------------------------------------------------------------------------+
| value | meaning
|
+-------
+----------------------------------------------------------------------------+
| 5 | redirect
|
+-------
+----------------------------------------------------------------------------+

codes:
+-------
+----------------------------------------------------------------------------+
| value | meaning
|
+-------
+----------------------------------------------------------------------------+
| 0 | redirect all datagrams directed to this network
|
| 1 | redirect all datagrams directed to this host
|
| 2 | redirect all datagrams with this type of service, directed to
this network |
| 3 | redirect all datagrams with this type of service, directed to
this host |
+-------
+----------------------------------------------------------------------------+

_______ _______________
{ 2.1.5 } � { time exceeded }
������� ���������������
whenever an ip datagram cannot be delivered because the time to live of the
packet exceeded or because the
reassembly of the packet fragment exceeded a certain time limit, the icmp
time exceeded message is sent to
the origin of the packet that caused the problem. there are several reasons
for such an event, including
the procedure of generating packets with very low ttl values by intent - this
method is used for traceroute
applications. refer to (2.2).

<---------------------------------------------------- bytes
-------------------------------------->
_________________________________________________________________________
________________________
| | | | | | | | | | |
| | | |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 | .... | 36 |
| | | | | | | | | | |
| | | |
|������|������|�������������|���������������������������|
�����������������������������������������|
| type | code | checksum | unused (must be zero) | ip header + 8
more bytes .... |
|______|______|_____________|___________________________|
_________________________________________|

types: codes:
+-------+-------------------------------------+ +-------
+-------------------------------------+
| value | meaning | | value | meaning
|
+-------+-------------------------------------+ +-------
+-------------------------------------+
| 11 | time exceeded - only possible value | | 0 | time to live
(ttl) exceeded |
+-------+-------------------------------------+ | 1 | fragment
reassembly took too long |
+-------
+-------------------------------------+

_______ ___________________
{ 2.1.6 } � { parameter problem }
������� �������������������
this icmp message informs the sender when the ip header of a datagram
contains an error and when this datagram
had to be discarded due to this problem. a pointer (ptr.) is included to the
icmp header that defines the
position of the ocet (byte) within the ip header where the error was found.

<---------------------------------------------------- bytes
-------------------------------------->
_________________________________________________________________________
________________________
| | | | | | | | | | |
| | | |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 | .... | 36 |
| | | | | | | | | | |
| | | |
|������|������|�������������|������|��������������������|
�����������������������������������������|
| type | code | checksum | ptr. | unused (zero) | ip header + 8
more bytes .... |
|______|______|_____________|______|____________________|
_________________________________________|

types: codes:
+-------+-------------------------------------+ +-------
+-------------------------------------+
| value | meaning | | value | meaning
|
+-------+-------------------------------------+ +-------
+-------------------------------------+
| 12 | parameter problem | | 0 | unspecified
error |
+-------+-------------------------------------+ | 1 | required
option missing |
+-------
+-------------------------------------+

_______ ______________
{ 2.1.7 } � { address mask }
������� ��������������
this icmp message is used by computers within large networks to receive their
subnet mask. in this case, a client
computer sends an icmp address mask request (icmp type 17) to the router with
a unique sequence number and am
empty address mask field (set to zero). the router then replies to the
message with an icmp address mask reply
message that contains the address mask and the same sequence number that the
client had chosen. the function of
the identifier field is, once again, to identify the process that sent the
icmp message. refer to {2.1.1} since
the fields are used in the same way when sending an echo request / reply.

<--------------------------------------------- bytes
------------------------------->
_________________________________________________________________________
__________
| | | | | | | | | | |
| |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
10 | 11 |
| | | | | | | | | | |
| |
|������|������|�������������|�������������|�������������|
���������������������������|
| type | code | checksum | identifier | sequence | address mask
|
|______|______|_____________|_____________|_____________|
___________________________|

types: codes:
+-------+-------------------------------+ +-------
+-------------------------------+
 | value | meaning | | value | meaning
|
+-------+-------------------------------+ +-------
+-------------------------------+
| 17 | address mask request | | 0 | only possible value
|
| 18 | address mask reply | +-------
+-------------------------------+
+-------+-------------------------------+

_____ ____________
( 2.2 ) : ( traceroute )
����� ������������
traceroute is a tool that does what the name already indicates - it traces the
complete route a packet takes
from you to a destination host you specify. this feature can be expanded to
what some of you might already
know as a visual traceroute, a traceroute program that also derives
geographical information from the ip
address of each node that the packets run through.

so, how does it work? quite simple. a traceroute application sends packets to
a port on the remote machine
that does not exist. these packets are send with an increasing ttl (time to
live), starting at a value of
1. so, when the first packet (which has a ttl of 1) reaches the first node,
it's ttl is reduced by one and
becomes zero: the packet is discarded. now an icmp message is generated from
the node that discarded the
packet which informs you (the sender of the packet) that the packet was
discarded. this message will be a
"time exceeded" message with a code of 0 (this means that the time to live of
a packet expired). once the
traceroute application receives this icmp message, it knows the ip address of
the node. after having stored
this value, the next packet is sent with an increased value for the ttl field.
this way, the traceroute
application is informed about each router that the packets run through since
every node sends an icmp
message when the packet is discarded which contains the routers address within
the ip header. however, once
the packet reaches the target computer, a "destination unreachable" message is
generated with a code of 3
(which means "port unreachable"). this way, the traceroute application knows
that the route is finished
and notes the origin of this icmp message as the last host. it's ip should
equal the ip of the host that
had to be traced.

traceroute is available on most systems as a commandline application. for

windows 2000, call cmd.exe and
type "tracert [host]".

_____ ______
( 2.3 ) : ( ping )
 ����� ������
ping has a rather simple concept. a ping application sends an icmp message
with type 8 and code 0 to the
target host. the target host will reply to this packet by copying its contents
completely and only setting
the type to 0 (echo reply) - provided that he is set up to reply to icmp
messages, which can be blocked
by most modern firewalls. now once the ping application receives the reply,
the ping is done. ping usually
starts a timer once the first packet is sent and displays the time that the
packet needed to reach the
remote host and return. that's about it.

___ ___________________________________________
[ 3 ] :: [ igmp - internet group management protocol ]
��� �������������������������������������������

igmp is a protocol which was invented to manage host groups within networks
that support multicasting. if you
already know what multicasting and host groups are, you don't have to read the
next part since it will only
discuss these very basics.

_____ ________________________
( 3.1 ) : ( multicasting && groups )
����� ������������������������

there are currently three ways to send a packet - unicast, broadcast and
multicast. i will give a brief
explaination of the first two methods, and then i will tell you why
multicasting is better. while discussing
this topic, keep in mind that we are talking about situations where it is
required to send a set of
information not only to one single remote host, but to many computers within
the same network. a good
example is a network with one centralized server performing a certain task
that reports its status to
several other servers which relay on this information while processing their
own tasks.

unicast is the most primitive way to achieve this - it means that the
information is sent to each respective
machine that relays on the information, ony by one.

sending a broadcast datagram basically means that the server sends sends the
information once, but the data
will reach every computer within a complete network. the respective computers
within the network then have
to decide themselves if they need this data or not. of course, this means that
the sender saves a lot of
resources as he only has to send the data once with the nice effect that all
computers within a network will
receive it.

while unicast consumes a lot of the sender's resources, broadcast messages

consume the resources of the
complete network in a horrible way. multicast is a solution that combines the
advantages of both systems,
 in a way. a multicast message is sent to a certain "host group" within the
network once. all members of
this group will receive the message, respectively.

group membership is not static, the respective computers have to be able to

join and leave groups dynamically.
for this purpose, igmp was invented for the ipv4 protocol to manage group
membership within modern networks
with multicasting support.

for more informationm refer to the following rfc's:

host extensions for ip multicasting:

http://www.rfc-editor.org/rfc/rfc1112.txt
(intro & pages 1-3 are important for you)

multicast transport protocol:

http://www.rfc-editor.org/rfc/rfc1301.txt
(read it only if you became curious)

_____ _________________
( 3.2 ) : ( the igmp header )
����� �����������������
the igmp header actually does not differ from the icmp header very much. it
looks like this:

<------------------------ bytes ------------------------>

_______________________________________________________
| | | | | | | | |
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
| | | | | | | | |
|������|������|�������������|���������������������������|
| type | code | checksum | group address |
|______|______|_____________|___________________________|

(figure 5: the igmp header)

regarding figure 5: i refer to the newer definition of the igmp header, as it

is presented by the iana
(internet assigned numbers authority):

"the internet group message protocol (igmp) has many messages

that are identified by a 'type' field.

note that the original definition of igmp in [rfc1112] divided

this field into two 4-byte values, 'version' and 'type'. this
was decided to be too restrictive, so the fields were combined
into a single 8-bit type space."

(http://www.iana.org/assignments/igmp-type-numbers [02/09/03])

igmp type
~~~~~~~~~
similar to icmp, this field defines what the message is actually about.
possible values are:

+------+------+---------+-------------------------------+------------+
| dec. | hex | binary | name | reference |
+------+------+---------+-------------------------------+------------+
| 17 | 0x11 | 0010001 | igmp membership query | [rfc1112] |
| 18 | 0x12 | 0010010 | igmpv1 membership report | [rfc1112] |
| 19 | 0x13 | 0010011 | dvmrp | [rfcdvmrp] |
| 20 | 0x14 | 0010100 | pim version 1 | [pimv1] |
| 21 | 0x15 | 0010101 | cisco trace messages | |
| 22 | 0x16 | 0010110 | igmpv2 membership report | [rfc2236] |
| 23 | 0x17 | 0010111 | igmpv2 leave group | [rfc2236] |
| 23 | 0x17 | 0010111 | igmpv2 leave group | [rfc2236] |
| 30 | 0x1e | 0011110 | multicast traceroute response | [fenner] |
| 31 | 0x1f | 0011111 | multicast traceroute | [fenner] |
| 34 | 0x22 | 0100010 | igmpv3 membership report | [rfc3376] |
+------+------+---------+-------------------------------+------------+

igmp code
~~~~~~~~~
some of the igmp messages also contain a certain code that gives more
detailed information about what event
the message is indicating. currently, only dvmrp and pim version 1 have
codes at all, though:

+--------+-------+-----------------------+
| type | code | meaning |
+--------+-------+-----------------------+
| dvmrp | 1 | probe |
| dvmrp | 2 | route report |
| dvmrp | 3 | old ask neighbors |
| dvmrp | 4 | old neighbors reply |
| dvmrp | 5 | ask neighbors |
| dvmrp | 6 | neighbors reply |
| dvmrp | 7 | prune |
| dvmrp | 8 | graft |
| dvmrp | 9 | graft ack |
+--------+-------+-----------------------+
| pim v1 | 0 | query |
| pim v1 | 1 | register |
| pim v1 | 2 | register-stop |
| pim v1 | 3 | join/prune |
| pim v1 | 4 | rp-reachable |
| pim v1 | 5 | assert |
| pim v1 | 6 | graft |
| pim v1 | 7 | graft ack |
| pim v1 | 8 | mode |
+--------+-------+-----------------------+

checksum
~~~~~~~~
this is the same checksum as icmp uses, calculated almost exactly the same
way this time. the 16-bit one's
complement of the one's complement sum of the whole igmp message is
calculated, excluding the ip header.
for computing the checksum, the checksum field is first set to zero, as
always.

group address
~~~~~~~~~~~~~
also explained in [rfc1112] on page 2. a host groupt within a network has its
own class d ip address.
converting this to the commonly used dotted decimal notation of ip addresses,
host group addresses range
from 224.0.0.0 to 239.255.255.255 where the address 244.0.0.0 is never used
and 244.0.0.1 represents
the "permanent group of all ip hosts". basically, this is an identifier for
the group that a certain
computer is member of. it is used to address all computers within a host
group.

_____ ______________
( 3.3 ) : ( the igmp bug )
����� ��������������
also known as the "kiss of death", a vulnerability within the processing
mechanism of fragmented igmp
packets was found in windows 9x and also windows 2000. the effects of an
attempt to reassemble the packet
are a crash within the tcp/ip stack of windows which forces dialup users to
reconnect to their isp, while
tcp network users will have to reboot their computer entirely. sometimes, the
attack also results in
blue or completely freezed screens. in this case, the user will be able to
press return and continue his
work with the computer - however, the machine will not be able to receive data
from the internet. indeed,
the machine will still be able to send data, but it cannot receive packets any
more.

actually, it's no effort to exploit the bug at all. the problem occurs even
with correctly fragmented
packets - the first exploit for this problem which would compile with any
windows compiler that i saw
did not even use raw sockets to modify the ip or igmp header, it merely sent a
very big igmp packet to
the remote host which would then be automatically be fragmented by the kernel
since it was too large to
send it through the network without further fragmentation.

so, the interesting fact about this bug is this very matter - we can send a
fully valid igmp packet to a
windows pc and merely due to the fragmentation, the remote computer crashes. i
have not yet seen any
information about what happens within the tcp/ip stack of windows to cause
such a problem, but i also
believe that there is no such information available.

i saw a tcpdump log that shows a kod attack on some website i can't remember,
and it looks like this:

15:53:37.899412 12.13.14.15 > localhost: (frag 48648:200@14800)

15:53:37.901212 12.13.14.15 > localhost: (frag 48648:1480@13320+)
 15:53:37.901392 12.13.14.15 > localhost: (frag 48648:1480@11840+)
15:53:37.901534 12.13.14.15 > localhost: (frag 48648:1480@10360+)
15:53:37.901681 12.13.14.15 > localhost: (frag 48648:1480@8880+)
15:53:37.901828 12.13.14.15 > localhost: (frag 48648:1480@7400+)
15:53:37.901972 12.13.14.15 > localhost: (frag 48648:1480@5920+)
15:53:37.902117 12.13.14.15 > localhost: (frag 48648:1480@4440+)
15:53:37.902262 12.13.14.15 > localhost: (frag 48648:1480@2960+)
15:53:37.902401 12.13.14.15 > localhost: (frag 48648:1480@1480+)
15:53:37.902541 12.13.14.15 > localhost: igmp-0 [v0][|igmp] (frag
48648:1480@0+)

____________ _______________________
[ appendix a ] :: [ networking byte order ]
������������ �����������������������
when sending an ip datagram, all information within this datagram is stored in
big endian format. if you
know what this means, you can stop reading this part since it's all you need to
know. however, you might
as well have no idea about the terms "big endian" and "little endian" - in this
case, i will try to explain
it to you. it is actually not complicated but you should be familliar with the
expressions for many of
the code samples and for a better understanding.

due to whatever strange reason, two different architectures for handling memory
storage are used when dessiging
computers and operating systems. these two architectures were called "big
endian" and "little endian". these
terms were derived from the phrases "big end in" and "little end in" and they
specify the way in which bytes
(not bits) are ordered when being stored in memory. on an intel computer, the
little end is stored first -
this means a hexadecimal word like 0x1234 is stored in memory as two blocks:
0x34 and 0x12. the little end,
or lower end, is stored first. here is another example for a dword: 0x12345678
would be stored as
0x78 0x56 0x34 0x12. "big end in" does this in the reverse fashion, so 0x1234
would be stored as 0x12 0x34 in
memory.

now windows 2k was designed around little endian architecture, whereas ip

datagrams use the big endian
architecture. if you have already coded with sockets, you should be familliar
with the functions htons, ntohs,
htonl and ntohl - these functions convert from one architecture to the other
one. this little piece of
code helps a lot in my opinion:

#ifdef win32
#ifndef big_endian
#define little_endian
#endif
#endif

#if defined(big_endian)
#define network_order_16(__x) htons(__x)
 #define network_order_32(__x) htonl(__x)
#define host_order_16(__x) (__x)
#define host_order_32(__x) (__x)
#elif defined(little_endian)
#define network_order_16(__x) (__x)
#define network_order_32(__x) (__x)
#define host_order_16(__x) ntohs(__x)
#define host_order_32(__x) ntohl(__x)
#else
#error could not determine byte order.
#endif

// overloaded functions for greater comfort:

dword bigendian(dword ipfield) { return network_order_32(ipfield); }
word bigendian(word ipfield) { return network_order_16(ipfield); }
dword littleendian(dword ipfield) { return host_order_32(ipfield); }
word littleendian(word ipfield) { return host_order_16(ipfield); }

____________ _______________
[ appendix b ] :: [ bits && bytes ]
������������ ���������������
well it's really some fundamental stuff, but i thought i might include it as an
appendix to make sure that
this paper is as complete as possible.

a bit is the most basic unit, and it is the only unit that computers actually
understand. a bit can be either
one or zero, plus or minus - a bit only has two states. you say that a bit is
"set" when it's value is 1, and
the bit is "not set" when the bit's value is zero. since bits only have two
possible values, calculations
based on bits are always based on binary number systems.

___ ___________________
(b-1) : (binary calculations)
��� �������������������
how do you calculate in binary? it is actually quite easy, and i will
illustrate it by showng you a small
sample - we want to know the decimal value of 10111:

+---------+---+---+---+---+---+
| bits: | 4 | 3 | 2 | 1 | 0 |
+---------+---+---+---+---+---+
| values: | 1 | 0 | 1 | 1 | 1 |
+---------+---+---+---+---+---+

bit 0 (is set): (2 ^ 0) * 1 = 1

bit 1 (is set): + (2 ^ 1) * 1 = 2
bit 2 (is set): + (2 ^ 2) * 1 = 4
bit 3 (not set): + (2 ^ 3) * 0 = 0
bit 4 (is set): + (2 ^ 4) * 1 = 16
-------------------
23

the decimal value of 10111 is 23. the difference between decimal and binary is
merely the base - in binary,
 the base is 2 and in decimal, it's 10.

decimal: you count 0,1,2,3,4,5,6,7,8,9 and now you have to add another digit:
10.
binary: you count 0,1 and now you already have to add another digit: 10

+---------+---------+
| decimal | binary |
+---------+---------+
| 0 | 0 |
| 1 | 1 |
| 2 | 10 |
| 3 | 11 |
| 4 | 100 |
| 5 | 101 |
| 6 | 110 |
| 7 | 111 |
| 8 | 1000 |
| 9 | 1001 |
| 10 | 1010 |
+---------+---------+

___ _______________
(b-2) : (units && values)
��� ���������������
we cannot only rely on the numbers one and zero in modern computing, we need
larger units. we get those by
simply using blocks of bits if we need larger numbers, and the commonly
smallest block used by a programmer
is the byte. it consists of 8 bits and thus, its largest possible value is
11111111 - which is (100000000-1)
and that's ((2^8)-1), which is 256-1, which means that the largest possible
value for a byte in decimal
is 255. actually, this is the largest value for an ascii char, and this should
ring a bell. indeed, one single
character is also one single byte. other values that you should know are:

1 byte = 8 bits
1 word = 2 bytes = 16 bits
1 dword = 4 bytes = 32 bits (double word)

____________ _________________________
[ appendix c ] [ the dod reference model ]
������������ �������������������������
the us department of defense (dod) developed in the beginning of the seventies
a reference model for
internetwork communication between computers. this was way before the osi model
was developed and i
honestly don't care about the osi model since it has no practical use. the dod
reference model consists
of four layers:

|��������������������������������|
| application layer |
|________________________________|
| |
 | transport layer (host-to-host) |
|________________________________|
| |
| internet layer |
|________________________________|
| |
| network layer (physical) |
|________________________________|

(figure c-1: the dod reference model)

every layer uses the services provided by the underlaying layer. it is the
common idea of interfaces -
every layer uses these services without knowing how the underlaying layer
performs the task. in real
life, ip performs the task of the internet layer and tcp represents the
transport layer - and this
combination is a horrible violation of the protocol hirachy, in fact. this will
be elaborated in the
following tutorial.

the different layers communicate with each other by their vertical order as
described in figure c-1,
but the logical communication between two computers is performed between the
same layer respectively:

[ host 1 ] [ router ] [ host 2 ]

|��������������������| |
��������������������|
| application layer | <=================================> | application
layer |
|_________||_________| |
_________/\_________|
|| ||
|���������\/���������| |���������||
���������|
| transport layer | <=================================> | transport layer
|
|_________||_________| |
_________/\_________|
|| ||
|���������\/���������| |�������������������| |���������||
���������|
| internet layer | <===> | internet layer | <===> | internet layer
|
|_________||_________| |___________________| |
_________/\_________|
|| ||
|���������\/���������| |�������������������| |���������||
���������|
| network layer | <===> | network layer | <===> | network layer
|
|____________________| |___________________| |
____________________|
 (figure c-2: communication between two computers)

when information is transmitted from one host to another one, this information
is always information
that is of importance for an application, running on both hosts. the
application layer now takes the
information and gives it to the transport layer - the transport layer now adds
its header information
to the beginning of the information and gives the complete new package of
header+data to the internet
layer. the internet layer adds its own header to the beginning of the complete
package as well and
the network layer which receives this package also adds its own header. this
process is called
encapsulation.

the complete package is now send across the net, routed by different routers
and finally reaches the
destination host. once this host receives this complete package, the different
layers respectively
remove their header by evaluating the information contained within it and give
the remaining data to
the overlaying layer.

___ _________________
[ 4 ] :: [ further reading ]
��� �����������������
i am going to continue this paper by writing an appropriate tutorial about the
transport layer and
about how to implement the use of raw sockets in a windows applicaiton.
however, at the point of time
when i published this paper here, no other paper by me about the topic existed
and thus i want to
provide some links and possibilities for further reading.

first of all, do buy a good book if you want to learn about really complex
stuff. one single book
about tcp/ip will give you a lot of background and you should find one in your
language at the local
book store. another thing is reading the rfc's i referred to within the
tutorial. the rfc's are an
essential source of information for anyone who is interested in networking
issues.

however, you might want to read a bit more light stuff that explains some basic
theory first - if
this is what you want, check this article from neworder about "the very basics
of tcp/ip - layers
and what they do.":

http://neworder.box.sk/newsread.php?newsid=6319

also make sure to check other papers like this from the neworder links
archieve:

http://neworder.box.sk/codebox.links.php?key=tcpgui
 an interesting little paper about ipv6 which might be interesting after having
read an ipv4 tutorial
can be found here:

http://www.garykessler.net/library/ipv6_exp.html

however, you should definitely continue reading about the transport layer as it
is the layer that
follows the ip layer described within this tutorial particularly:

http://www.etcs.ipfw.edu/~lin/cpet355/s2000/lectures/udp-tcp_files/frame.htm
http://www-net.cs.umass.edu/kurose/transport/udp.html
http://www-net.cs.umass.edu/kurose/transport/congestion.html

and, since some of you might actually want to code a packet sniffer, a syn
scanner or similar tools -
check out the great tcp/ip library from komodia. it is an extremely large,
open-source,
object-oriented library that supports windows developers with anything that
they might need to code
applications that make use of raw sockets. however, i would suggest you to dig
the source code and
try to understand it instead of simply using the interface. that helps a lot.

http://www.komodia.com/tools.htm

and, since some of the links might be dead when you read this or since i might
have already published
the next few parts of this series - do use your brain and a search engine to
find more information
yourself.

___ ____________
[ 5 ] :: [ last words ]
��� ������������
well, i am about to continue this paper by writing another one about the
transport layer, maybe a
special one about spoofing (arp-spoofing, icmp redirect spoofing) and similar
stuff. however, this
tutorial represents the fundamentals required to understand most of the other
topics that might follow
and whether or not i will continue this as a series depends on the feedback
that i will get. if only
few people understood this tutorial or if it was written badly, any attempt to
continue it would be
sneseless. so, just tell me what you think and also give me advice if you think
i could make this or
that feature better by using different words or elaborating something that i
left out.

for in time, sit back, relax and taste the real thing.
yours, rattlesnake@box.sk