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 highlevel 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) which is of the "a computed value which depends on the contents of a block of data and transmitted or stored along with the data in order to detect corruption

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 168 0 1 is is is is 11000000 10101000 00000000 00000001 in in in in binary. binary. binary. 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: +-------+-----------------------------------+ +----------------------------------+ | value | meaning | | +-------+-----------------------------------+ codes: +------| value | meaning +-------

+----------------------------------+ | 8 | echo | value | | 0 | echo reply | +----------------------------------+ +-------+-----------------------------------+

|

0 | only possible

+-------

_______ _________________________ { 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: +-------+-------------------------------------+ +-------------------------------------+ | value | meaning | | +-------+-------------------------------------+ +-------------------------------------+ | 4 | source quench - only possible value | possible value | +-------+-------------------------------------+ +-------------------------------------+ codes: +------| value | meaning +------| 0 | only

+-------

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

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: +-------+-------------------------------------+ +-------------------------------------+ | value | meaning | | +-------+-------------------------------------+ +-------------------------------------+ | 11 | time exceeded - only possible value | (ttl) exceeded | +-------+-------------------------------------+ reassembly took too long | +-------------------------------------+ codes: +------| value | meaning +------| | 0 | time to live 1 | fragment

+-------

_______ ___________________ { 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: +-------+-------------------------------------+ +-------------------------------------+ | value | meaning | | +-------+-------------------------------------+ +-------------------------------------+ | 12 | parameter problem | error | +-------+-------------------------------------+ 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: +------codes: +------| value | meaning +------| | 0 | unspecified 1 | required

+-------

| value | meaning |

|

| value | meaning +------| 0 | only possible value

+-------+-------------------------------+ +-------------------------------+ | 17 | address mask request | | | 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 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])

much. it

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 15:53:37.901534 15:53:37.901681 15:53:37.901828 15:53:37.901972 15:53:37.902117 15:53:37.902262 15:53:37.902401 15:53:37.902541 48648:1480@0+)

12.13.14.15 12.13.14.15 12.13.14.15 12.13.14.15 12.13.14.15 12.13.14.15 12.13.14.15 12.13.14.15 12.13.14.15

> > > > > > > > >

localhost: localhost: localhost: localhost: localhost: localhost: localhost: localhost: localhost:

(frag 48648:1480@11840+) (frag 48648:1480@10360+) (frag 48648:1480@8880+) (frag 48648:1480@7400+) (frag 48648:1480@5920+) (frag 48648:1480@4440+) (frag 48648:1480@2960+) (frag 48648:1480@1480+) igmp-0 [v0][|igmp] (frag

____________ _______________________ [ 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: bigendian(dword ipfield) { return network_order_32(ipfield); bigendian(word ipfield) { return network_order_16(ipfield); littleendian(dword ipfield) { return host_order_32(ipfield); littleendian(word ipfield) { return host_order_16(ipfield);

dword word dword word

} } } }

____________ _______________ [ 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) : ��� how do illustrate sample ___________________ (binary calculations) ������������������� you calculate in binary? it is actually quite easy, and i will it by showng you a small - we want to know the decimal value of 10111:

+---------+---+---+---+---+---+ | bits: | 4 | 3 | 2 | 1 | 0 | +---------+---+---+---+---+---+ | values: | 1 | 0 | 1 | 1 | 1 | +---------+---+---+---+---+---+ bit bit bit bit bit 0 1 2 3 4 (is set): (is set): (is set): (not set): (is set): (2 ^ 0) * 1 = 1 + (2 ^ 1) * 1 = 2 + (2 ^ 2) * 1 = 4 + (2 ^ 3) * 0 = 0 + (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 ] |��������������������| ��������������������| | application layer | layer | |_________||_________| _________/\_________| || |���������\/���������| ���������| | transport layer | | |_________||_________| _________/\_________| || |���������\/���������| ���������| | internet layer | | |_________||_________| _________/\_________| || |���������\/���������| ���������| | network layer | | |____________________| ____________________| [ router ] | <=================================> | application | || |���������|| <=================================> | transport layer | |�������������������| <===> | internet layer | <===> || |���������|| | internet layer | || |���������|| <===> | network layer | [ host 2 ]

|___________________| |�������������������| <===> | 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

Sign up to vote on this title
UsefulNot useful