Internet+Protocols

=Introduction= toc

Internet protocols are the foundation upon which the internet operates; because of this, a basic understanding of their function is key to any CCIT student, as background on our information technology infrastructure.

In an acedemic sense, all internet related activities function on what is called an Open Systems Interconnection (OSI) model. Without becoming too complex, this model posits that all internet functions are performed on "layers", which in a perfect world function perfectly and transparently from the hardware level (layer 1) up to the application layer (layer 7). Each layer (there are seven) has protocols associated with it, though some protocols encompass more than one layer in practice. Note that as protocols progress towards less user transparancy, functioning upon more and more other protocols, the more complex they tend to become in terms of implimentation. While the IP protocol is essentially unnoticable on the standard computer, the HTTP protocol must work with several implimentations in order to function (client and server protocols, html, cgi, etc), as well as user based interferance and errors. The following is a brief introduction to the most important protocols used on the internet, in their order on the OSI model. In the included pictures, the numbers in brackets refer to that section's size, in bits (a one or a zero).

=Preface=

Protocols are only used by a computer to send and recieve data. Readers of this article should remember how data is actually being sent once it leaves the computer. Computers are named by their IP Address, a 4 digit set of numbers from 0 to 255. A common example: www.yahoo.com is actually 68.142.197.83. Try copying that in to your browser - you'll see it loads the same site. The names we use on the internet are looked up to their ip addresses using a protocol called DNS (domain name system). No computer on the network knows how to get to the ip address that the data is being sent to. Instead, the computer sends data out to it's closest link, which sends it to another computer that is "a bit closer", knowing only that the ip address it is sending the data to is "pretty close to this IP". The next packet switching computer does the same thing, and now the packet is one step closer to it's destination. This happens again and again until finally a computer that does know where the machine in question is is finally reached. Note a common tracert (trace route) log. Trace route traces what computers the data you send goes through to get to it's final destination.

C:\>tracert www.google.com

Tracing route to www.google.com [72.14.203.99] over a maximum of 30 hops:

1 5 ms 4 ms 4 ms **192.168.2.* (removed)** 2 14 ms 13 ms 13 ms **removed** 3 11 ms 12 ms 11 ms 64.230.221.201 **my** **ISP (sympatico)** 4 12 ms 11 ms 11 ms 64.230.234.249 **another sympatico server** 5 12 ms 12 ms 11 ms 64.230.233.93 **another sympatico server** 6 22 ms 21 ms 22 ms core1-chicago23-pos0-0.in.bellnexxia.net [206.108.103.130] 7 23 ms 22 ms 22 ms 64.230.223.42 8 23 ms 22 ms 22 ms 206.108.108.166 9 24 ms 23 ms 22 ms cer-core-02.inet.qwest.net [205.171.139.149] **a large internet "traffic station"** 10 23 ms 23 ms 22 ms chx-edge-01.inet.qwest.net [205.171.139.166] **another large internet hub** 11 24 ms 24 ms 23 ms 65.112.69.202 12 23 ms 30 ms 23 ms 66.249.95.249 13 24 ms 24 ms 26 ms 72.14.238.89 **almost there!** 14 25 ms 25 ms 25 ms 72.14.203.99 **here's google!**

Trace complete.

As you can see, the data this user has sent to google went through 12 other computers before it reached their server.

=Protocols=

Description
Please note that this data refers mostly to IPv4, not the newest IPv6, which has many differences from IPv4 but is still not widely used. This is the base protocol on which the internet operates. The major idea of this protocol is that data sent over the internet should be transmitted as "packets", that is data should be cut up into a set size, with a start, a header, and an end, then sent and reassembled at the end; this packet can contain any chunk of a set of data, in any format. The header contains enough information to allow a packet to be fragmented (broken up) and recieved in the proper order by the computer it was sent to. This helps allow a set of data to be sent in parts through many different paths to get to the same location. A path is defined as data sent from one packet switching device in the network to another, attempting to get progressively closer to the destination. The computer sending the data sets the time to live, which sets how many "hops" (or computers) to go through before a packet is considered to have been sent in the wrong direction and deleted. Depending on the next level protocol used (TCP or UDP, generally), this data may or may not be recognised as lost and resent.

Format
(c) 2006 Philip Hudson. Based on [|RFC 791].

Note that the | is a seperator that stands for the next section. The bit lengths in those sections are maximums. The header is indeed a maximum size of 192 bits (or 24 bytes), but can be shorter, as small as 40 bytes if nothing but the IHL, the destination address and the seperators are included.

Meanings

 * Version is the IP protocol version. This is currently either IP version 4 (IPv4) or IP version 6 (IPv6). IPv6 allows for many more computer to be connected to the internet, and is backwards compatible with IPv4. This is important because IPv4 only allows a maximum of 4,294,967,296 (that's 256^4) IPs. Considering many ranges are allocated in a way that disallows the use of large chunks of that number, and some computers have multiple IPs, the internet is rapidly approaching this limit.
 * IHL is the size of the header. The minimum size is 5 bytes (40 bits). This tells the computers where the header ends, and the data begins
 * Service Type indicates how important speed and accuracy is to the switches. It ranges from high speed to high reliability
 * Total packet length is the length of the whole packet, including header and data.
 * Identification is the number that this packet represents in the series of packets
 * Fl. stands for flags, and is used in practice to indicate whether and how much a router can fragment (further break up) a packet
 * Fragment offset is used if the original packet was broken up even more. It tells the computer what part of the fragment this packet is
 * Time to live specifies the maximum computers that this packet can pass through before being considered dead
 * Protocol specifies the higher level protocol (such as UDP or TCP) that this packet is going to use
 * Header checksum makes sure that the header (NOT THE DATA - this is done later) has arrived at the packet switching device correctly
 * Source and destination address specify the computer sending and recieving the data
 * Options are completely optional.
 * Padding is used to make sure that the packet ends up being a multiple of 8 bits (1 byte) This is because the smallest divisable section of computer data is recognised as being 8 ones and zeros, by design. You can not send a number of ones and zeros not divisable by 8.

Uses
This protocol is used in all other protocols on the internet. You cannot not use this protocol, as it describes the most basic function of data transfer throughout a network.

Description
The ICMP protocol was created to let computers and administrators know that some kind of data problem is occuring, as well as perform network troubleshooting. These packets are sent when packet congestion is high, and the packet switching computer becomes overloaded, for instance. They are sent if a packet of data is recieved that is malformed, or if the maximum amount of hops are reached and a packet is disgarded. They are sent back if the computer in question can not be found, or if that computer isn't open to that packet (i.e. the tcp specified port is closed - see below for details). These packets can be sent by routing computers if the packets are being sent to them in error (i.e. a shorter path to the target exists and is available to the sending switch). In any case, the new packet is returned to the sender with the appropriate data response. The most common use of this protocol by far is for ping requests. This command gives the time it took for a packet of data to be recieved by the host, and the ICMP response packet to be sent back. To execute a ping request, open a dos box (start > run, type cmd and press enter; type ping www.yahoo.com). Common output:

C:\>ping www.yahoo.com

Pinging www.yahoo.akadns.net [68.142.226.38] with 32 bytes of data:

Reply from 68.142.226.38: bytes=32 time=36ms TTL=52 Reply from 68.142.226.38: bytes=32 time=37ms TTL=52 Reply from 68.142.226.38: bytes=32 time=36ms TTL=52 Reply from 68.142.226.38: bytes=32 time=36ms TTL=52

Ping statistics for 68.142.226.38: Packets: Sent: 4, Received: 4, Lost: 0 (0% loss), Approximate round trip times in milli-seconds: Minimum: 36ms, Maximum: 37ms, Average: 36ms

Header Format
(c) 2006 Philip Hudson. Based on [|RFC 792].

Note that this header is being sent in the body of the IP protocol, that is within an IP 'packet' of data. After that, the original header and the first part of the data being sent are included, allowing for further analysis of whatever the issue seems to be.

Meanings

 * Type is an overarching code refering to what the error was. This can be looked up [|here]
 * Code is a subcode that refers to a specific type within the type. For instance, if type is set to 3 (destination unreachable), code can be any number from 0-5, indicating at what point the destination could not be reached (a closed port on the target computer, for instance)
 * As with IP, the checksum here is related only to the actual header of the ICMP data, not the data being sent with it. The goal here is to have the ICMP error data arrive completely intact, not nessesarily the attached IP header.

Description
UDP is an incredibly lightweight protocol. It is designed to send time sensitive data from one computer to another, in situations where accuracy and arrival of a specific packet is not as much of an issue as the size of the overhead (the header, etc) and how fast it gets there. This might seem like a strange idea: why would anyone want to send data that may not get to the recipient, that could arrive in the wrong order? If data is send via UDP as packets in the order of 1 through 5, these packets take different paths of different times and packet 5 could be recieved before packet 1. The major use for this protocol is in fast streaming applications, where massive amounts of data are sent, possibly from a large number of users. UDP has major use in multiplayer videogames, and also in many audio and video streaming programs. The size of the header is always the size of the IP header + 32 bits. UDP is as simple as one computer sending a packet to another computer. When reviewing TCP below, one can see why this is a much faster protocol. There is no handshake, no acknowledgement, and no confirmation of reciept.

Header Format
(c) 2006 Philip Hudson. Based on [|RFC 768].

Meanings

 * Source and destination ports are numbers indicating which port a specific packet of data is meant to go to, as well as to which port return data should be sent. Note that the port is set to 16 bits, which means there can be 65536 ports (2^16).
 * Length is the length of the packet
 * Checksum is the checksum of both the header and the data being transmitted. This provides protection against the data, instead of just the header as seen with the IP and ICMP protocols.

Description
TCP was developed as a lossless and definate method of transfering data. The information provided with the packet allows the reciever to be completely sure that they are recieving their data in sequence, and that the data is accounted for and correct. The data is sent after a "handshake", which is basically three empty, flagged packets sent back and forth confirming that the two computers want to establish a connection. The first establishes intent to connect, the second establishes that the first was recieved and the third establishes that this confirmation was recieved; data can then be sent. As with UDP, the data is sent with port numbers. In it's most basic form, ports are just numbers written down in the header of the packet. Within a computer, however, ports are bound to specific programs, and may not be used by another program until freed. This allows computers to specify and decode which program the recieved data should be relayed to. A reciept of a recieved packet is always sent back to the sending computer, confirming whether a packet has been recieved successfully. If a packet is not recieved successfully, it can be resent by the sender.

Header Format
(c) 2006 Philip Hudson. Based on [|RFC 793].

Meanings

 * Source and destination ports are numbers indicating which port a specific packet of data is meant to go to, as well as to which port return data should be sent (which is established beforehand in the handshake). Note that the port is set to 16 bits, which means there can be 65536 ports (2^16).
 * Sequence number represents the start offset of this set of data's position. for instance, if I was sending the data 12345678 in seperate packets, but each packet contained 2 numbers, then i'd have 4 packets: 1 & 2,3 & 4,5 & 6, and 7 & 8. If 3 & 4 was recieved, then sequence would be 3, as it starts at the third position in the data.
 * Acknowledgment number represents the next acknowledgement reciept the sender is expecting to get back. This helps the reciever confirm whether the acknowledgements it's sending are being recieved by the sender, and resend an acknowledgement packet if data has been recieved but not confirmed
 * The data offset specifies where the data in this packet actually starts, after the header
 * The reserved section is an empty (zero'd) section that is left empty incase it needs to be used in the future
 * Control is a set of control features specifying the type of packet being sent. These include
 * acknowledge, which is sent on every packet after the handshake. This asks for an acknowledgement of reciept
 * syncronisation, which tells the other computer which packet acknowledge number it is on. In a handshake, this sets the starting syncronisation number.
 * finished sending, telling the computer that a flow of data is finished
 * reset, which tells the other computer to stop the connection and start handshake procedure again. This is used when something goes wrong on the connection
 * Window refers to the size of data that the sender is sending. In our 1 to 8 pseudo example above, window would be 2
 * Checksum is the checksum of both the header and the data being transmitted. This provides protection against the data, instead of just the header as seen with the IP and ICMP protocols.

Description
DNS systems are possibly one of the most important and completely transparent mid-level internet protocols in use today. DNS runs from TCP/IP (that is, tcp over IP; that is to say it uses TCP, and TCP uses IP), putting it on the same level as http and email. However, without DNS both of those protocols would be functionally useless. This is because DNS provides users with an IP lookup service, changing www.yahoo.com into the correct IP associated with that URL. Without DNS, there would be no URLs. Users would have to input IPs to go to websites, or else develop another system. DNS is currently controlled by the [|Network Information Centre], though in theory anyone can run a DNS server. Software abounds (including many free applications) allowing users to run their own DNS server, and by registering with the Network Information Centre and paying a fee, anyone with a dedicated connection can become a registrar and register domain names.

Format
This protocol is mid level in nature. Clients send a request to a server on TCP port 53, containing a URL to be looked up in the question section. The server (which is also a client itself) relays this information around if it does not know the answer, and responds with the information it gained in the answer section. The other sections are for exclusive use between two servers, telling them where else to look and if the answer they recieved is from an authorised (i.e. registrar) server or just a random internet DNS server. (c) 2006 Philip Hudson. Based on [|RFC 883].
 * **Name** || **Function** ||
 * Header || States which of the following sections are present, how many queries are being made, how many answers are contained in the following sections (if any), etc. ||
 * Question || The domain being looked up (or the IP to be reverse-looked up) is entered here, as well as what type and range ||
 * Answer || The data found about the information submitted in the question ||
 * Authority || If the DNS agent is the authority on this domain (i.e. it registered the domain, or else holds control of the top level domain) then this section will contain information such as whether the domain exists or not ||
 * Additional || Contains data that is related to the query, but doesn't nessesarily answer the question, such as a dns server that might know the answer ||

Note that "var." stands for variable length. These sections depend completely on the length of the URL being looked up.

Header Meanings (Major items)

 * QT sets this message as either a query (0) or a response (1)
 * Opcode specifies what type of query or response this is. Most importantly, this sets the message as either a regular or inverse lookup (from url to ip or ip to url)
 * RCode specifies whether there was an error with the lookup
 * QDCount is the amount of entries being questioned
 * AnCount is the amount of entries being answered in this message

**Question Section**
Note that there can be more than one addresses questioned, each of which would have a different section. The count of this section should be equal to that of qdcount
 * Query name is the name of the domain being looked up. This is dynamic in size
 * Query type is now depreciated, indicating what network type (ARPANET, CANET, etc) was to be searched
 * Query class is the type of the record being looked up (a simple address, a mail server, etc)

Additional
In order to impliment the DNS protocol, a distributive server/client interface is established. The same packet form is used between servers and clients, however

Description
This is the first example of a high level protocol. It is much different in execution from the previous protocols. In order to function, the HTTP protocol requires IP, TCP, and DNS protocols. It also requires a complete client and server interface, where each has a different set of commands to be sent back and forth. Instead of commands being sent in the cryptic forms above, they are sent in a human readable form, recognised by the computer, and responded to. There are literally hundreds of different aspects to the http protocol. Because of this, only the most important implimented items will be itinerated below.

Basic Protocol Rules
Servers and clients are given certain strings and arguements to give and respond to. If the data transfered between the two was made to mimic a conversation, it would be something along the lines of: "Hi, this is who I am. I want this page. Do you have it?" "Hello, I'm a server. I have that page. Here is the page." or perhaps "Hello, I'm a server. I don't have that page."

The specifications of the protocol allow for the client to make a get, post, or head related request. The most common for simply viewing a page or downloading a file is get. Since HTTP 1.1 the client only needs to submit 2 items: the name of the file the client wants, and the name of the website it expects to get it from. HTTP 1.0 didn't require the second item; it has been made manditory because many servers host multiple websites with different URLs from the same IP. The second item allows them to figure out which site the client wants to read from.

Lines must be ended by the codes corresponding to hitting the enter key in window, CR+LF. As an interesting side note, these codes stand for Cartridge Return and Line Feed. They come from the old days of typewriters. The cartridge return was what's now called the enter key, and line feed meant to go down one line on the paper. In any case, once a request is finished it is ended with a blank line followed by the code for enter, described above.

Basic Header (Client and Server)
Now lets see an example of what happens when we go to yahoo.com, after the address has been looked up and a connection established via tcp. Note that is used instead of the more proper #13#10 or CR+LF, to avoid confusion.


 * GET /index.html HTTP/1.1 **
 * Host: www.yahoo.com **
 * Connection: close **
 * Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 **
 * Accept-Language: en-us,en;q=0.5 **
 * Accept-Charset: ISO-8859-1,utf-8; **
 * User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 **

Things to note: The first line asks for the path and file the client wants to get. The second mentions what host the client is connecting through (taken from the URL you type in). The only things explicitly required by HTTP protocols are these first two lines. Look at all the extra data your browser sends to the server, as it can be easily viewed by anyone whos server you read from. Some interesting information: This user is using Windows XP (NT 5.1 = XP), and they're using a firefox browser, version 1.5. They're in north america, because their main language is set to "en-us" (US english). They came from a site called softwarecreations.net.

// // //// // // //var now=new Date,t1=0,t2=0,t3=0,t4=0,t5=0,t6=0,cc=,ylp=;t1=now.getTime;// // // // Yahoo! // //...//
 * HTTP/1.1 200 OK**
 * Date: Mon, 27 Feb 2006 19:08:14 GMT **
 * Set-Cookie: FPB=69uafn57f1206jgu; expires=Thu, 01 Jun 2006 19:00:00 GMT; path=/; domain=www.yahoo.com **
 * Connection: close **
 * Content-Type: text/html **

Only the main lines of the response have been kept, for brevity. Note that the server gives you its current date and time, any cookies, and the type of file it's sending to you (so your client knows whether it can display the file or ask you if you want to download it, generally). It sends a final empty line to note that its header is finished, and then sends the html data.

The first line is of specific importance: HTTP/1.1 200 OK. This tells your browser what version of http the server is using, and the code related to the request it sent, and occasionally the message associated with that code. For instance, if you asked for something that didn't exist, it would return HTTP/1.1 404. The html error codes can be found [|here].

=DNS on TCP/IP Example=

If all of this sounds very complex, it is. Perhaps a good way of looking at it would be in an actual example. Lets imagine that we wish to contact the site www.wikispaces.com. The first thing to do is to figure out the IP number of the computer we're sending our data to. Remember that this occurs in less than a tenth of a second, and doesn't even involve talking to the server we want to contact. Whereever you see an alternating binary set (10101010101), the value has been made up because it is incalculable for the purpose of this example.

Our computer sends a dns query to our dns server, which is specified by our Internet Service Provider. After the TCP handshakes, which are numerous and thus will not be itinerated, the data sent looks something like:

IP Header:


 * **Hex** || **Binary** || **Name** || **Description** ||
 * 4E40AAAA || **0100**1110010000001010101010101010 || **Ver** | IHL | Service | Packet Length || Version = 4 (IPv4) (binary 100) ||
 * 00CD0000 || 0000000011001101**0000**000000000000 || ID | **Flags** | Frag Offset || This is set to allow fragmenting ||
 * 4006AAAA || 01000000**00000110**1010101010101010 || TTL | **Protocol** | Checksum || Set to tcp protocol (6), as stated in [|RFC 790] ||
 * CDCDCDCD || 11001101110011011100110111001101 || source address || address is set to 205.205.205.205 ||
 * C0A80201 || 11000000101010000000001000000001 || destination address || address is set to 192.168.2.1, as if we are behind a fireall ||
 * 00000000 || 00000000000000000000000000000000 || options | padding || no options, padded to finish the set. ||

TCP Header:


 * **Hex** || **Binary** || **Name** || **Description** ||
 * 00330035 || 0000000000110011**0000000000110101** || Source | **Dest** || source port is set to 51 (but could be anything). Destination must be **port 53**, as this has been set as the port for DNS ||
 * 00000065 || 00000000000000000000000001100101 || Sequence No. || This is the first data packet in the sequence, where data was synced in the handshake phase to 100 (making this packet sequence 101). ||
 * 0000012D || 00000000000000000000000100101101 || Ack. No. || Requires that the next packet to be confirmed is one already sent with sync number 301 ||
 * F0100200 || 1111000000**010000**0000001000000000 || Offset | Reserved | **Ctrl** | Window || offset is at 192 bytes, ctrl is set to ack, window is set to 512 bytes ||
 * AAAA0000 || **101010101010101**00000000000000000 || **checksum** | urgency || made up checksum, urgency is zero'd ||
 * 00000000 || 00000000000000000000000000000000 || options | padding || no options, padded to finish the set. ||

DNS Header:
 * **Hex** || **Binary** || **Name** || **Description** ||
 * CD || 0000000011001101 || ID # || ID # set as 205 (this is a random #) ||
 * 00 || 0000000000000000 || **Query** | Op | AA | TC | RD | RA | RC || query = 0 (we're asking). Everything else is zero'd ||
 * 01 || 0000000000000001 || QDCount || we want to know about 1 domain ||
 * 00 || 0000000000000000 || ADCount || we don't have an answer (that's why we're asking!) ||
 * 00 || 0000000000000000 || NSCount || unnessesary for a query ||
 * 00 || 0000000000000000 || ARCount || see above ||

DNS Body (You don't want to see the below in binary.. it'd be scary.)

This is all that the body requires on the request. The ISP does it's work and looks up the ip. They send something back which indicates the IP is 64.34.180.40. It looks the same as above, only with the proper responses in the header; in the body would be the original question we posted, along with an answer in the answer field.
 * Hex || Name || Description ||
 * 7777770077696b6973706163657300636f6d || qname || this is www.wikispaces.com ||
 * 01 || qtype || we want to look up the IP of the domain name ||
 * 01 || qclass || constant ||

If you were able to look at the entire packet of data as a hexidecimal stream flowing through the net, it would look like this:


 * 8e || 40 || AA || AA || 00 || CD || 00 || 00 ||
 * 00 || CD || 00 || 00 || 40 || 06 || AA || AA ||
 * CD || CD || CD || CD || C0 || A8 || 02 || 01 ||
 * 00 || 00 || 00 || 00 || 00 || 33 || 00 || 35 ||
 * 00 || 00 || 00 || 65 || 00 || 00 || 01 || 2D ||
 * F0 || 10 || 02 || 00 || AA || AA || 00 || 00 ||
 * 00 || 00 || 00 || 00 || 00 || CD || 00 || 00 ||
 * 00 || 02 || 00 || 00 || 00 || 00 || 00 || 00 ||
 * 77 || 77 || 77 || 00 || 77 || 69 || 6B || 69 ||
 * 73 || 70 || 61 || 63 || 65 || 73 || 00 || 63 ||
 * 6F || 6D || 01 || 01 || 49 || 66 || 20 || 79 ||
 * 6f || 75 || 20 || 63 || 61 || 6e || 20 || 72 ||
 * 65 || 61 || 64 || 20 || 74 || 68 || 69 || 73 ||
 * 20 || 79 || 6f || 75 || 20 || 68 || 61 || 76 ||
 * 65 || 20 || 77 || 61 || 79 || 79 || 79 || 79 ||
 * 20 || 74 || 6F || 6F || 20 || 6D || 75 || 63 ||
 * 68 || 20 || 74 || 69 || 6D || 65 || 20 || 6F ||
 * 6E || 20 || 79 || 6F || 75 || 72 || 20 || 68 ||
 * 61 || 6E || 64 || 73 || 21 || 21 || 21 || 21 ||

It looks very cryptic, but you should now know what the above means (or do you?). You should also have a good appritiation for the function of packet sniffing and filtering technology, which looks through reams of the above for the correct data.

=Works Cited=

"RFC 768 - User Datagram Protocol" __RFC Search__. Sept. 1981. Defense Advanced Research Projects Agency. 26 Feb. 2006 <[|http://www.rfcsearch.org/rfcview/RFC/768.html]>.

"RFC 791 - Internet Protocol." __RFC Search__. Sept. 1981. Defense Advanced Research Projects Agency. 26 Feb. 2006 .

"RFC 792 - Internet Control Message Protocol." __RFC Search__. Sept. 1981. Defense Advanced Research Projects Agency. 26 Feb. 2006 .

"RFC 793 - Transmission Control Protocol." __RFC Search__. Sept. 1981. Defense Advanced Research Projects Agency. 26 Feb. 2006 .

"RFC 883 - Domain Name System" __RFC Search__. 28 Aug. 1980. Defense Advanced Research Projects Agency. 26 Feb. 2006 .

"RFC 1945 - Hypertext Transfer Protocol" __RFC Search__. May. 1996. Defense Advanced Research Projects Agency. 26 Feb. 2006 .

"RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1" __RFC Search__. June. 1999. Defense Advanced Research Projects Agency. 26 Feb. 2006 .