Routing

The description above indicated that the IP implementation is responsible for getting
datagrams to the destination indicated by the destination address, but little was said about
how this would be
done. The task of finding how to get a datagram to its destination is referred to as
"routing". In fact many of the details depend upon the particular implementation.
However some general things can be said.
First, it is necessary to understand the model on which IP is based. IP assumes that a
system is attached to some local network. We assume that the system can send datagrams
to any other system on its own network. (In the case of Ethernet, it simply finds the
Ethernet address of the destination system, and puts the datagram out on the Ethernet.)
The problem comes when a system is asked to send a datagram to a system on a different
network. This problem is handled by gateways. A gateway is a system that connects a
network with one or more other networks. Gateways are often normal computers that
happen to have more than one network interface. For example, we have a Unix machine
that has two different Ethernet interfaces. Thus it is connected to networks 128.6.4 and
128.6.3. This machine can act as a gateway between those two networks. The software on
that machine must be set up so that it will forward datagrams from one network to the
other. That is, if a machine on network 128.6.4 sends a datagram to the gateway, and the
datagram is addressed to a machine on network
128.6.3, the gateway will forward the datagram to the destination. Major communications
centers often have gateways that connect a number of different networks. (In many cases,
special-purpose gateway systems provide better performance or reliability than generalpurpose
systems acting as gateways. A number of vendors sell such systems.)
Routing in IP is based entirely upon the network number of the destination address. Each
computer has a table of network numbers. For each network number, a gateway is listed.
This is the gateway to be
used to get to that network. Note that the gateway doesn't have to connect directly to the
network. It just has to be the best place to go to get there. For example at Rutgers, our
interface to NSFnet is at
the John von Neuman Supercomputer Center (JvNC). Our connection to JvNC is via a
high-speed serial line connected to a gateway whose address is 128.6.3.12. Systems on
net 128.6.3 will list 128.6.3.12 as
the gateway for many off-campus networks. However systems on net 128.6.4 will list
128.6.4.1 as the gateway to those same off-campus networks. 128.6.4.1 is the gateway
between networks 128.6.4 and
128.6.3, so it is the first step in getting to JvNC.
When a computer wants to send a datagram, it first checks to see if the destination
address is on the system's own local network. If so, the datagram can be sent directly.
Otherwise, the system expects to
find an entry for the network that the destination address is on. The datagram is sent to
the gateway listed in that entry. This table can get quite big. For example, the Internet
now includes several hundred
individual networks. Thus various strategies have been developed to reduce the size of
the routing table. One strategy is to depend upon "default routes". Often, there is only one
gateway out of a network. This gateway might connect a local Ethernet to a campus-wide
backbone network. In that case, we don't need to have a separate entry for every network
in the world. We simply define that gateway as a "default". When no specific route is
found for a datagram, the datagram is sent to the default gateway. A default gateway can
even be used when there are several gateways on a network. There are provisions for
gateways to send a message saying "I'm not the best gateway -- use this one instead."
(The message is sent via ICMP. See RFC 792.) Most network software is designed to use
these messages to add entries to their routing tables. Suppose network 128.6.4 has two
gateways, 128.6.4.59 and 128.6.4.1. 128.6.4.59 leads to several other internal Rutgers
networks. 128.6.4.1 leads indirectly to the NSFnet. Suppose we set 128.6.4.59 as a
default gateway, and have no other routing table entries. Now what happens when we
need to send a datagram to MIT? MIT is network 18. Since we have no entry for network
18, the datagram will be sent to the default, 128.6.4.59. As it happens, this gateway is the
wrong one. So it will forward the
datagram to 128.6.4.1. But it will also send back an error saying in effect: "to get to
network 18, use 128.6.4.1". Our software will then add an entry to the routing table. Any
future datagrams to MIT will then go directly to 128.6.4.1. (The error message is sent
using the ICMP protocol. The message type is called "ICMP redirect.")
Most IP experts recommend that individual computers should not try to keep track of the
entire network. Instead, they should start with default gateways, and let the gateways tell
them the routes, as just
described. However this doesn't say how the gateways should find out about the routes.
The gateways can't depend upon this strategy. They have to have fairly complete routing
tables. For this, some sort of
routing protocol is needed. A routing protocol is simply a technique for the gateways to
find each other, and keep up to date about the best way to get to every network. RFC
1009 contains a review of
gateway design and routing. However rip.doc is probably a better introduction to the
subject. It contains some tutorial material, and a detailed description of the most
commonly-used routing protocol.

Domain Name System

Keeping track of names and information: the domain system
As we indicated earlier, the network software generally needs a 32-bit Internet address in
order to open a connection or send a datagram. However users prefer to deal with
computer names rather than
numbers. Thus there is a database that allows the software to look up a name and find the
corresponding number. When the Internet was small, this was easy. Each system would
have a file that listed all of the
other systems, giving both their name and number. There are now too many computers
for this approach to be practical. Thus these files have been replaced by a set of name
servers that keep track of host
names and the corresponding Internet addresses. (In fact these servers are somewhat
more general than that. This is just one kind of information stored in the domain system.)
Note that a set of interlocking servers are used, rather than a single central one. There are
now so many different institutions connected to the Internet that it would be impractical
for them to notify a central
authority whenever they installed or moved a computer. Thus naming authority is
delegated to individual institutions. The name servers form a tree, corresponding to
institutional structure. The names
themselves follow a similar structure.
A typical example is the name BORAX.LCS.MIT.EDU. This is a computer at the
Laboratory for Computer Science (LCS) at MIT. In order to find its Internet address, you
might potentially have to consult 4
different servers. First, you would ask a central server (called the root) where the EDU
server is. EDU is a server that keeps track of educational institutions. The root server
would give you the names and
Internet addresses of several servers for EDU. (There are several servers at each level, to
allow for the possibly that one might be down.) You would then ask EDU where the
server for MIT is. Again, it
would give you names and Internet addresses of several servers for MIT. Generally, not
all of those servers would be at MIT, to allow for the possibility of a general power
failure at MIT. Then you would ask
MIT where the server for LCS is, and finally you would ask one of the LCS servers about
BORAX. The final result would be the Internet address for BORAX.LCS.MIT.EDU.
Each of these levels is referred to as
a "domain". The entire name, BORAX.LCS.MIT.EDU, is called a "domain name". (So
are the names of the higher-level domains, such as LCS.MIT.EDU, MIT.EDU, and
EDU.)
Fortunately, you don't really have to go through all of this most of the time. First of all,
the root name servers also happen to be the name servers for the top-level domains such
as EDU. Thus a single
query to a root server will get you to MIT. Second, software generally remembers
answers that it got before. So once we look up a name at LCS.MIT.EDU, our software
remembers where to find servers for
LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation of
BORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live"
associated with it. Typically this is a few days. After that,
the information expires and has to be looked up again. This allows institutions to change
things.
The domain system is not limited to finding out Internet addresses. Each domain name is
a node in a database. The node can have records that define a number of different
properties. Examples are
Internet address, computer type, and a list of services provided by a computer. A program
can ask for a specific piece of information, or all information about a given name. It is
possible for a node in the
database to be marked as an "alias" (or nickname) for another node. It is also possible to
use the domain system to store information about users, mailing lists, or other objects.
There is an Internet standard defining the operation of these databases, as well as the
protocols used to make queries of them. Every network utility has to be able to make
such queries, since this is now the official way to evaluate host names. Generally utilities
will talk to a server on their own system. This server will take care of contacting the other
servers for them. This keeps down the amount of code that has to be in each application
program.
The domain system is particularly important for handling computer mail. There are entry
types to define what computer handles mail for a given name, to specify where an
individual is to receive mail, and to
define mailing lists. (See RFC's 882, 883, and 973 for specifications of the domain
system. RFC 974 defines the use of the domain system in sending mail.)

Other IP Protocols

Protocols other than TCP: UDP and ICMP
So far, we have described only connections that use TCP. Recall that TCP is responsible
for breaking up messages into datagrams, and reassembling them properly. However in
many applications, we have
messages that will always fit in a single datagram. An example is name lookup. When a
user attempts to make a connection to another system, he will generally specify the
system by name, rather than Internet
address. His system has to translate that name to an address before it can do anything.
Generally, only a few systems have the database used to translate names to addresses. So
the user's system will want to send a query to one of the systems that has the database.
This query is going to be very short. It will certainly fit in one datagram. So will the
answer. Thus it seems silly to use TCP. Of course TCP does
more than just break things up into datagrams. It also makes sure that the data arrives,
resending datagrams where necessary. But for a question that fits in a single datagram,
we don't need all the
complexity of TCP to do this. If we don't get an answer after a few seconds, we can just
ask again. For applications like this, there are alternatives to TCP.
The most common alternative is UDP ("user datagram protocol"). UDP is designed for
applications where you don't need to put sequences of datagrams together. It fits into the
system much like TCP. There is a
UDP header. The network software puts the UDP header on the front of your data, just as
it would put a TCP header on the front of your data. Then UDP sends the data to IP,
which adds the IP header, putting
UDP's protocol number in the protocol field instead of TCP's protocol number. However
UDP doesn't do as much as TCP does. It doesn't split data into multiple datagrams. It
doesn't keep track of what it has
sent so it can resend if necessary. About all that UDP provides is port numbers, so that
several programs can use UDP at once. UDP port numbers are used just like TCP port
numbers. There are well-known port
numbers for servers that use UDP. Note that the UDP header is shorter than a TCP
header. It still has source and destination port numbers, and a checksum, but that's about
it. No sequence number, since it is not needed. UDP is used by the protocols that handle
name lookups (see IEN 116, RFC 882, and RFC 883), and a number of similar protocols.
Another alternative protocol is ICMP ("Internet Control Message Protocol"). ICMP is
used for error messages, and other messages intended for the TCP/IP software itself,
rather than any particular
user program. For example, if you attempt to connect to a host, your system may get back
an ICMP message saying "host unreachable". ICMP can also be used to find out some
information about the network. See RFC 792 for details of ICMP. ICMP is similar to
UDP, in that it handles messages that fit in one datagram. However it is even simpler than
UDP. It doesn't even have port numbers in its header. Since all ICMP messages are
interpreted by the network software itself, no port numbers are needed to say where a
ICMP message is supposed to go.

Well-Known Sockets And The Applications Layer

So far, we have described how a stream of data is broken up into datagrams, sent to
another computer, and put back together. However something more is needed in order to
accomplish anything useful. There
has to be a way for you to open a connection to a specified computer, log into it, tell it
what file you want, and control the transmission of the file. (If you have a different
application in mind, e.g. computer mail, some analogous protocol is needed.) This is done
by "application protocols".
The application protocols run "on top" of TCP/IP. That is, when they want to send a
message, they give the message to TCP. TCP makes sure it gets delivered to the other
end. Because TCP and IP take care of all the networking details, the applications
protocols can treat a network connection as if it were a simple byte stream, like a terminal
or phone line. Before going into more details about applications
programs, we have to describe how you find an application.
Suppose you want to send a file to a computer whose Internet address is 128.6.4.7. To
start the process, you need more than just the Internet address. You have to connect to the
FTP server at the other
end. In general, network programs are specialized for a specific set of tasks. Most
systems have separate programs to handle file transfers, remote terminal logins, mail, etc.
When you connect to
128.6.4.7, you have to specify that you want to talk to the FTP server. This is done by
having "well-known sockets" for each server. Recall that TCP uses port numbers to keep
track of individual conversations. User programs normally use more or less random port
numbers. However specific port numbers are assigned to the programs that sit waiting for
requests.
For example, if you want to send a file, you will start a program called "ftp". It will open
a connection using some random number, say 1234, for the port number on its end.
However it will specify port
number 21 for the other end. This is the official port number for the FTP server. Note that
there are two different programs involved. You run ftp on your side. This is a program
designed to accept commands
from your terminal and pass them on to the other end. The program that you talk to on the
other machine is the FTP server. It is designed to accept commands from the network
connection, rather than an
interactive terminal. There is no need for your program to use a well-known socket
number for itself. Nobody is trying to find it. However the servers have to have wellknown
numbers, so that people can open connections to them and start sending them
commands. The official port numbers for each program are given in "Assigned
Numbers".
Note that a connection is actually described by a set of 4 numbers: the Internet address at
each end, and the TCP port number at each end. Every datagram has all four of those
numbers in it. (The Internet
addresses are in the IP header, and the TCP port numbers are in the TCP header.) In order
to keep things straight, no two connections can have the same set of numbers. However it
is enough for any one number
to be different. For example, it is perfectly possible for two different users on a machine
to be sending files to the same other machine. This could result in connections with the
following parameters:
Internet addresses TCP ports
connection 1 128.6.4.194, 128.6.4.7 1234, 21
connection 2 128.6.4.194, 128.6.4.7 1235, 21
Since the same machines are involved, the Internet addresses are the same. Since they are
both doing file transfers, one end of the connection involves the well-known port number
for FTP. The only thing
that differs is the port number for the program that the users are running. That's enough of
a difference. Generally, at least one end of the connection asks the network software to
assign it a port number
that is guaranteed to be unique. Normally, it's the user's end, since the server has to use a
well-known number.
Now that we know how to open connections, let's get back to the applications programs.
As mentioned earlier, once TCP has opened a connection, we have something that might
as well be a simple wire. All
the hard parts are handled by TCP and IP. However we still need some agreement as to
what we send over this connection. In effect this is simply an agreement on what set of
commands the application will
understand, and the format in which they are to be sent. Generally, what is sent is a
combination of commands and data. They use context to differentiate.
For example, the mail protocol works like this: Your mail program opens a connection to
the mail server at the other end. Your program gives it your machine's name, the sender
of the message, and the
recipients you want it sent to. It then sends a command saying that it is starting the
message. At that point, the other end stops treating what it sees as commands, and starts
accepting the message. Your end then starts sending the text of the message. At the end
of the message, a special mark is sent (a dot in the first column). After that, both ends
understand that your program is again sending commands. This is the simplest way to do
things, and the one that most applications use.
File transfer is somewhat more complex. The file transfer protocol involves two different
connections. It starts out just like mail. The user's program sends commands like "log me
in as this user", "here is
my password", "send me the file with this name". However once the command to send
data is sent, a second connection is opened for the data itself. It would certainly be
possible to send the data on the
same connection, as mail does. However file transfers often take a long time. The
designers of the file transfer protocol wanted to allow the user to continue issuing
commands while the transfer is going
on. For example, the user might make an inquiry, or he might abort the transfer. Thus the
designers felt it was best to use a separate connection for the data and leave the original
command connection for
commands. (It is also possible to open command connections to two different computers,
and tell them to send a file from one to the other. In that case, the data couldn't go over
the command
connection.)
Remote terminal connections use another mechanism still. For remote logins, there is just
one connection. It normally sends data. When it is necessary to send a command (e.g. to
set the terminal type or to change some mode), a special character is used to indicate that
the next character is a command. If the user happens to type that special character as data,
two of them are sent.
We are not going to describe the application protocols in detail in this document. It's
better to read the RFC's yourself. However there are a couple of common conventions
used by applications that will be
described here. First, the common network representation: TCP/IP is intended to be
usable on any computer. Unfortunately, not all computers agree on how data is
represented. There are differences in
character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, line
feed, or a representation using counts), and in whether terminals expect characters to be
sent individually or a line
at a time. In order to allow computers of different kinds to communicate, each
applications protocol defines a standard representation.
Note that TCP and IP do not care about the representation. TCP simply sends octets.
However the programs at both ends have to agree on how the octets are to be interpreted.
The RFC for each application specifies the standard representation for that application.
Normally it is "net ASCII". This uses ASCII characters, with end of line denoted by a
carriage return followed by a line feed. For remote
login, there is also a definition of a "standard terminal", which turns out to be a halfduplex
terminal with echoing happening on the local machine. Most applications also
make provisions for the two
computers to agree on other representations that they may find more convenient. For
example, PDP-10's have 36-bit words. There is a way that two PDP-10's can agree to
send a 36-bit binary file. Similarly,
two systems that prefer full-duplex terminal conversations can agree on that. However
each application has a standard representation, which every machine must support.
Keep in mind that it has become common practice for some corporations to change a
services port number on the server side. If your client software is not configured with the
same port number, connection will not be successful. We will discuss later in this text
how you can perform port scanning on an entire IP address to see which ports are active.

The Ethernet level

Most of our networks these days use Ethernet. So now we have to describe Ethernet's
headers. Unfortunately, Ethernet has its own addresses. The people who designed
Ethernet wanted to make sure that no two machines would end up with the same Ethernet
address. Furthermore, they didn't want the user to have to worry about assigning
addresses. So each Ethernet controller comes with an address
builtin from the factory. In order to make sure that they would never have to reuse
addresses, the Ethernet designers allocated 48 bits for the Ethernet address. People who
make Ethernet equipment have to
register with a central authority, to make sure that the numbers they assign don't overlap
any other manufacturer.
Ethernet is a "broadcast medium". That is, it is in effect like an old party line telephone.
When you send a packet out on the Ethernet, every machine on the network sees the
packet. So something is needed
to make sure that the right machine gets it. As you might guess, this involves the Ethernet
header. Every Ethernet packet has a 14-octet header that includes the source and
destination Ethernet address, and
a type code. Each machine is supposed to pay attention only to packets with its own
Ethernet address in the destination field. (It's perfectly possible to cheat, which is one
reason that Ethernet communications are not terribly secure.)
Note that there is no connection between the Ethernet address and the Internet address.
Each machine has to have a table of what Ethernet address corresponds to what Internet
address. (We will describe how
this table is constructed a bit later.) In addition to the addresses, the header contains a
type code. The type code is to allow for several different protocol families to be used on
the same network. So you can
use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of them will put a different
value in the type field. Finally, there is a checksum. The Ethernet controller computes a
checksum of the entire
packet. When the other end receives the packet, it recomputes the checksum, and throws
the packet away if the answer disagrees with the original. The checksum is put on the end
of the packet, not in the
header.
When these packets are received by the other end, of course all the headers are removed.
The Ethernet interface removes the Ethernet header and the checksum. It looks at the type
code. Since the type
code is the one assigned to IP, the Ethernet device driver passes the datagram up to IP. IP
removes the IP header. It looks at the IP protocol field. Since the protocol type is TCP, it
passes the datagram
up to TCP. TCP now looks at the sequence number. It uses the sequence numbers and
other information to combine all the datagrams into the original file. The ends our initial
summary of TCP/IP. There are
still some crucial concepts we haven't gotten to, so we'll now go back and add details in
several areas. (For detailed descriptions of the items discussed here see, RFC 793 for
TCP, RFC 791 for IP, and RFC's
894 and 826 for sending IP over Ethernet.)

The IP level

TCP sends each of these datagrams to IP. Of course it has to tell IP the Internet address of
the computer at the other end. Note that this is all IP is concerned about. It doesn't care
about what is in the
datagram, or even in the TCP header. IP's job is simply to find a route for the datagram
and get it to the other end. In order to allow gateways or other intermediate systems to
forward the datagram, it
adds its own header.
The main things in this header are the source and destination Internet address (32-bit
addresses, like 128.6.4.194), the protocol number, and another checksum. The source
Internet address is simply the address of your machine. (This is necessary so the other
end knows where the datagram came from.) The destination Internet address is the
address of the other machine. (This is necessary so any gateways in the middle know
where you want the datagram to go.) The protocol number tells IP at the other end to send
the datagram to TCP. Although most IP traffic uses TCP, there are other protocols that
can use IP, so you have to tell IP which protocol to send the datagram to.
Finally, the checksum allows IP at the other end to verify that the header wasn't damaged
in transit. Note that TCP and IP have separate checksums. IP needs to be able to verify
that the header didn't get
damaged in transit, or it could send a message to the wrong place. For reasons not worth
discussing here, it is both more efficient and safer to have TCP compute a separate
checksum for the TCP header and data.
Again, the header contains some additional fields that have not been discussed. Most of
them are beyond the scope of this document. The flags and fragment offset are used to
keep track of the pieces when a
datagram has to be split up. This can happen when datagrams are forwarded through a
network for which they are too big. (This will be discussed a bit more below.) The time
to live is a number that is
decremented whenever the datagram passes through a system. When it goes to zero, the
datagram is discarded. This is done in case a loop develops in the system somehow. Of
course this should be impossible, but well-designed networks are built to cope with
"impossible" conditions.
At this point, it's possible that no more headers are needed. If your computer happens to
have a direct phone line connecting it to the destination computer, or to a gateway, it may
simply send the
datagrams out on the line (though likely a synchronous protocol such as HDLC would be
used, and it would add at least a few octets at the beginning and end).

The TCP Level

Two separate protocols are involved in handling TCP/IP datagrams. TCP (the
"transmission control protocol") is responsible for breaking up the message into
datagrams, reassembling them at the other end, resending anything that gets lost, and
putting things back in the right order. IP (the "internet protocol") is responsible for
routing individual datagrams. It may seem like TCP is doing all the work. And
in small networks that is true. However in the Internet, simply getting a datagram to its
destination can be a complex job. A connection may require the datagram to go through
several networks at Rutgers, a serial line to the John von Neuman Supercomputer Center,
a couple of Ethernets there, a series of 56Kbaud phone lines to another NSFnet site, and
more Ethernets on another campus. Keeping track of
the routes to all of the destinations and handling incompatibilities among different
transport media turns out to be a complex job.
Note that the interface between TCP and IP is fairly simple. TCP simply hands IP a
datagram with a destination. IP doesn't know how this datagram relates to any datagram
before it or after it. It may
have occurred to you that something is missing here. We have talked about Internet
addresses, but not about how you keep track of multiple connections to a given system.
Clearly it isn't enough to get a
datagram to the right destination. TCP has to know which connection this datagram is
part of.
This task is referred to as "demultiplexing." In fact, there are several levels of
demultiplexing going on in TCP/IP. The information needed to do this demultiplexing is
contained in a series of "headers". A header is simply a few extra octets tacked onto the
beginning of a datagram by some protocol in order to keep track of it. It's a lot like
putting a letter into an envelope and putting an address on the outside of the envelope.
Except with modern networks it happens several times. It's like you put the letter into a
little
envelope, your secretary puts that into a somewhat bigger envelope, the campus mail
center puts that envelope into a still bigger one, etc.
Here is an overview of the headers that get stuck on a message that passes through a
typical TCP/IP network:
We start with a single data stream, say a file you are trying to send to some other
computer:
TCP breaks it up into manageable chunks. (In order to do this, TCP has to know how
large a datagram your network can handle. Actually, the TCP's at each end say how big a
datagram they can handle, and then they pick the smallest size.)
TCP puts a header at the front of each datagram. This header actually contains at least 20
octets, but the most important ones are a source and destination "port number" and a
"sequence number". The port
numbers are used to keep track of different conversations. Suppose 3 different people are
transferring files. Your TCP might allocate port numbers 1000, 1001, and 1002 to these
transfers. When you are sending a datagram, this becomes the "source" port number,
since you are the source of the datagram. Of course the TCP at the other end has assigned
a port number of its own for the conversation. Your TCP has to know the port number
used by the other end as well. (It finds out when the connection starts, as we will explain
below.) It puts this in the "destination" port field. Of course if the other end sends a
datagram back to you, the source and destination port numbers will be reversed, since
then it will be the source and you will be the destination.
Each datagram has a sequence number. This is used so that the other end can make sure
that it gets the datagrams in the right order, and that it hasn't missed any. (See the TCP
specification for
details.) TCP doesn't number the datagrams, but the octets. So if there are 500 octets of
data in each datagram, the first datagram might be numbered 0, the second 500, the next
1000, the next 1500,
etc.
Finally, I will mention the Checksum. This is a number that is computed by adding up all
the octets in the datagram (more or less - see the TCP spec). The result is put in the
header. TCP at the other end computes the checksum again. If they disagree, then
something bad happened to the datagram in transmission, and it is thrown away.
The window is used to control how much data can be in transit at any one time. It is not
practical to wait for each datagram to be acknowledged before sending the next one. That
would slow things down
too much. On the other hand, you can't just keep sending, or a fast computer might
overrun the capacity of a slow one to absorb data. Thus each end indicates how much
new data it is currently prepared to
absorb by putting the number of octets in its "Window" field. As the computer receives
data, the amount of space left in its window decreases. When it goes to zero, the sender
has to stop. As the receiver processes the data, it increases its window, indicating that it is
ready to accept more data. Often the same datagram can be used to acknowledge receipt
of a set of data and to give permission for
additional new data (by an updated window).
The "Urgent" field allows one end to tell the other to skip ahead in its processing to a
particular octet. This is often useful for handling asynchronous events, for example when
you type a control character or other command that interrupts output. The other fields are
beyond the scope of this document.

General description of the TCP/IP protocols

TCP/IP is a layered set of protocols. In order to understand what this means, it is useful to
look at an example. A typical situation is sending mail. First, there is a protocol for mail.
This defines a set of commands which one machine sends to another, e.g. commands to
specify who the sender of the message is, who it is being sent to, and then the text of the
message. However this protocol assumes that there is a way to communicate reliably
between the two computers. Mail, like other application protocols, simply defines a set of
commands and messages to be sent. It is designed to be used together with TCP and IP.
TCP is responsible for making sure that the commands get through to the other end. It
keeps track of what is sent, and retransmits anything that did not get through. If any
message is too large for one
datagram, e.g. the text of the mail, TCP will split it up into several datagrams, and make
sure that they all arrive correctly. Since these functions are needed for many applications,
they are put together into
a separate protocol, rather than being part of the specifications for sending mail. You can
think of TCP as forming a library of routines that applications can use when they need
reliable network
communications with another computer.
Similarly, TCP calls on the services of IP. Although the services that TCP supplies are
needed by many applications, there are still some kinds of applications that don't need
them. However there are some
services that every application needs. So these services are put together into IP. As with
TCP, you can think of IP as a library of routines that TCP calls on, but which is also
available to applications that don't use TCP. This strategy of building several levels of
protocol is called "layering". We think of the applications programs such as mail, TCP,
and IP, as being separate "layers", each of which calls on the services of the layer below
it. Generally, TCP/IP applications use 4 layers: an application protocol such as mail, a
protocol such as TCP that provides services need by many applications IP, which
provides the basic service of getting datagrams to their destination the protocols needed
to manage a specific physical medium, such as Ethernet or a point to point line.
TCP/IP is based on the "catenet model". (This is described in more detail in IEN 48.)
This model assumes that there are a large number of independent networks connected
together by gateways. The user should be able to access computers or other resources on
any of these networks. Datagrams will often pass through a dozen different networks
before getting to their final destination.
The routing needed to accomplish this should be completely invisible to the user. As far
as the user is concerned, all he needs to know in order to access another system is an
"Internet address". This is an
address that looks like 128.6.4.194. It is actually a 32-bit number. However it is normally
written as 4 decimal numbers, each representing 8 bits of the address. (The term "octet" is
used by Internet documentation for such 8-bit chunks. The term "byte" is not used,
because TCP/IP is supported by some computers that have byte sizes other than 8 bits.)
Generally the structure of the address gives
you some information about how to get to the system. For example, 128.6 is a network
number assigned by a central authority to Rutgers University. Rutgers uses the next octet
to indicate which of the
campus Ethernets is involved. 128.6.4 happens to be an Ethernet used by the Computer
Science Department. The last octet allows for up to 254 systems on each Ethernet. (It is
254 because 0 and 255 are not allowed, for reasons that will be discussed later.) Note that
128.6.4.194 and 128.6.5.194 would be different systems. The structure of an Internet
address is described in a bit more detail later.
Of course we normally refer to systems by name, rather than by Internet address. When
we specify a name, the network software looks it up in a database, and comes up with the
corresponding Internet
address.
Most of the network software deals strictly in terms of the address. (RFC 882 describes
the name server technology used to handle this lookup.) TCP/IP is built on
"connectionless" technology. Information is transferred as a sequence of "datagrams". A
datagram is a collection of data that is sent as a single
message. Each of these datagrams is sent through the network individually. There are
provisions to open connections (i.e. to start a conversation that will continue for some
time). However at some level, information from those connections is broken up into
datagrams, and those datagrams are treated by the network as completely separate.
For example, suppose you want to transfer a 15000 octet file. Most networks can't handle
a 15000 octet datagram. So the protocols will break this up into something like 30 500-
octet datagrams. Each of these datagrams will be sent to the other end. At that point, they
will be put back together into the 15000-octet
file. However while those datagrams are in transit, the network doesn't know that there is
any connection between them. It is perfectly possible that datagram 14 will actually
arrive before datagram 13. It is also possible that somewhere in the network, an error will
occur, and some datagram won't get through at all. In that case, that datagram has to be
sent again.
Note by the way that the terms "datagram" and "packet" often seem to be nearly
interchangable. Technically, datagram is the right word to use when describing TCP/IP.
A datagram is a unit of data, which is what the protocols deal with. A packet is a physical
thing, appearing on an Ethernet or some wire. In most cases a packet simply contains a
datagram, so there is very little difference. However they can differ. When TCP/IP is
used on top of X.25, the X.25 interface breaks the datagrams up into 128-byte packets.
This is invisible to IP, because the packets are put back together into a single datagram at
the other end before being processed by TCP/IP. So in this case, one IP datagram would
be carried by several packets. However with most media, there are efficiency advantages
to sending one datagram per
packet, and so the distinction tends to vanish.

Network-Oriented Window Systems

Until recently, high- performance graphics programs had to
execute on a computer that had a bit-mapped graphics screen directly
attached to it. Network window systems allow a program to use a
display on a different computer. Full-scale network window systems
provide an interface that lets you distribute jobs to the systems that
are best suited to handle them, but still give you a single
graphically-based user interface. (The most widely-implemented window
system is X. A protocol description is available from MIT's Project
Athena. A reference implementation is publicly available from MIT. A
number of vendors are also supporting NeWS, a window system defined by
Sun. Both of these systems are designed to use TCP/IP.)
Note that some of the protocols described above were designed by Berkeley, Sun, or
other organizations. Thus they are not officially part of the Internet protocol suite.
However they are implemented
using TCP/IP, just as normal TCP/IP application protocols are. Since the protocol
definitions are not considered proprietary, and since commercially-support
implementations are widely available, it is
reasonable to think of these protocols as being effectively part of the Internet suite.
Also note that the list above is simply a sample of the sort of services available through
TCP/IP. However it does contain the majority of the "major" applications. The other
commonly-used protocols tend to be
specialized facilities for getting information of various kinds, such as who is logged in,
the time of day, etc. However if you need a facility that is not listed here, we encourage
you to look through the current edition of Internet Protocols (currently RFC 1011), which
lists all of the available protocols, and also to look at some of the major TCP/IP
implementations to see what various vendors have added.

Terminal Servers

Many installations no longer connect terminals directly to
computers. Instead they connect them to terminal servers. A terminal
server is simply a small computer that only knows how to run telnet
(or some other protocol to do remote login). If your terminal is
connected to one of these, you simply type the name of a computer, and
you are connected to it. Generally it is possible to have active
connections to more than one computer at the same time. The terminal
server will have provisions to switch between connections rapidly, and
to notify you when output is waiting for another connection. (Terminal
servers use the telnet protocol, already mentioned. However any real
terminal server will also have to support name service and a number of
other protocols.)

Name Servers

In large installations, there are a number of different
collections of names that have to be managed. This includes users and
their passwords, names and network addresses for computers, and
accounts. It becomes very tedious to keep this data up to date on all
of the computers. Thus the databases are kept on a small number of
systems. Other systems access the data over the network. (RFC 822 and
823 describe the name server protocol used to keep track of host names
and Internet addresses on the Internet. This is now a required part of
any TCP/IP implementation. IEN 116 describes an older name server
protocol that is used by a few terminal servers and other products to
look up host names. Sun's Yellow Pages system is designed as a general
mechanism to handle user names, file sharing groups, and other
databases commonly used by Unix systems. It is widely available
commercially. Its protocol definition is available from Sun.)
[

Remote Execution

This allows you to request that a particular program be run on
a different computer. This is useful when you can do most of your work
on a small computer, but a few tasks require the resources of a larger
system. There are a number of different kinds of remote execution.
Some operate on a command by command basis. That is, you request that
a specific command or set of commands should run on some specific
computer. (More sophisticated versions will choose a system that
happens to be free.) However there are also "remote procedure call"
systems that allow a program to call a subroutine that will run on
another computer. (There are many protocols of this sort. Berkeley
Unix contains two servers to execute commands remotely: rsh and
rexec. The man pages describe the protocols that they use. The
user-contributed software with Berkeley 4.3 contains a "distributed
shell" that will distribute tasks among a set of systems, depending
upon load. Remote procedure call mechanisms have been a topic for
research for a number of years, so many organizations have
implementations of such facilities. The most widespread
commercially-supported remote procedure call protocols seem to be
Xerox's Courier and Sun's RPC. Protocol documents are available from
Xerox and Sun. There is a public implementation of Courier over TCP as
part of the user-contributed software with Berkeley 4.3. An
implementation of RPC was posted to Usenet by Sun, and also appears as
part of the user-contributed software with Berkeley 4.3.)
[

Remote Printing

This allows you to access printers on other computers as if
they were directly attached to yours. (The most commonly used protocol
is the remote lineprinter protocol from Berkeley Unix. Unfortunately,
there is no protocol document for this. However the C code is easily
obtained from Berkeley, so implementations are common.)

Network File Systems

This allows a system to access files on another computer in a
somewhat more closely integrated fashion than FTP. A network file
system provides the illusion that disks or other devices from one
system are directly connected to other systems. There is no need to
use a special network utility to access a file on another system. Your
computer simply thinks it has some extra disk drives. These extra
"virtual" drives refer to the other system's disks. This capability is
useful for several different purposes. It lets you put large disks on
a few computers, but still give others access to the disk space. Aside
from the obvious economic benefits, this allows people working on
several computers to share common files. It makes system maintenance
and backup easier, because you don't have to worry about updating and
backing up copies on lots of different machines. A number of vendors
now offer high-performance diskless computers. These computers have no
disk drives at all. They are entirely dependent upon disks attached to
common "file servers". (See RFC's 1001 and 1002 for a description of
PC-oriented NetBIOS over TCP. In the workstation and minicomputer
area, Sun's Network File System is more likely to be used. Protocol
specifications for it are available from Sun Microsystems.)

Computer Mail

This allows you to send messages to users on other
computers. Originally, people tended to use only one or two specific
computers. They would maintain "mail files" on those machines. The
computer mail system is simply a way for you to add a message to
another user's mail file. There are some problems with this in an
environment where microcomputers are used. The most serious is that a
micro is not well suited to receive computer mail. When you send mail,
the mail software expects to be able to open a connection to the
addressee's computer, in order to send the mail. If this is a
microcomputer, it may be turned off, or it may be running an
application other than the mail system. For this reason, mail is
normally handled by a larger system, where it is practical to have a
mail server running all the time. Microcomputer mail software then
becomes a user interface that retrieves mail from the mail
server. (See RFC 821 and 822 for specifications for computer mail. See
RFC 937 for a protocol designed for microcomputers to use in reading
mail from a mail server.)
These services should be present in any implementation of TCP/IP, except that microoriented
implementations may not support computer mail. These traditional applications
still play a very important role in TCP/IP-based networks. However more recently, the
way in which networks are used has been changing. The older model of a number of
large, self-sufficient computers is beginning to change. Now many installations have
several kinds of computers, including microcomputers, workstations, minicomputers, and
mainframes. These computers are likely to be configured to perform specialized
tasks. Although people are still likely to work with one specific computer, that computer
will call on other systems on the net for specialized services. This has led to the
"server/client" model of network services. A server is a system that provides a specific
service for the rest of the network. A client is another system that uses that service. (Note
that the server and client need not be on different computers. They could be different
programs running on the same computer.)
Here are the kinds of servers typically present in a modern computer setup. Note that
these computer services can all be provided within the framework of TCP/IP.

Remote Login

The network terminal protocol (TELNET) allows a user to log in
on any other computer on the network. You start a remote session by
specifying a computer to connect to. From that time until you finish
the session, anything you type is sent to the other computer. Note
that you are really still talking to your own computer. But the telnet
program effectively makes your computer invisible while it is
running. Every character you type is sent directly to the other
system. Generally, the connection to the remote computer behaves much
like a dialup connection. That is, the remote system will ask you to
log in and give a password, in whatever manner it would normally ask a
user who had just dialed it up. When you log off of the other
computer, the telnet program exits, and you will find yourself talking
to your own computer. Microcomputer implementations of telnet
generally include a terminal emulator for some common type of
terminal. (See RFC's 854 and 855 for specifications for telnet. By the
way, the telnet protocol should not be confused with Telenet, a vendor
of commercial network services.)
[

File Transfer

The file transfer protocol (FTP) allows a user on any computer
to get files from another computer, or to send files to another
computer. Security is handled by requiring the user to specify a user
name and password for the other computer, or logging into a system that
allows for Anonymous logins. Provisions are made for
handling file transfer between machines with different character set,
end of line conventions, etc. This is not quite the same thing as more
recent "network file system" or "NetBIOS" protocols, which will be
described below. Rather, FTP is a utility that you run any time you
want to access a file on another system. You use it to copy the file
to your own system. You then work with the local copy. (See RFC 959
for specifications for FTP.)

What is TCP/IP?

TCP/IP is a set of protocols developed to allow cooperating computers to share resources
across a network. It was developed by a community of researchers centered around the
ARPAnet (Advanced Research Projects Agency). Certainly the ARPAnet is the bestknown
TCP/IP network. However as of June, 87, at least 130 different vendors had
products that support TCP/IP, and thousands of networks of all kinds use it.
First some basic definitions. The most accurate name for the set of protocols we are
describing is the "Internet protocol suite". TCP and IP are two of the protocols in this
suite. (They will be described below.) Because TCP and IP are the best known of the
protocols, it has become common to use the term TCP/IP to refer to the whole family.
The Internet is a collection of networks, including the Arpanet, NSFnet, regional
networks such as NYsernet, local networks at a number of University and research
institutions, and a number of military networks and a growing number of private
corporation owned networks. The term "Internet" applies to this entire set of network
The subset of them that is managed by the Department of Defense is referred to as the
"DDN" (Defense Data Network). This includes some research-oriented networks, such as
the Arpanet, as well as more strictly military ones. All of these networks are connected to
each other. Users can send messages from any of them to any other, except where there
are security or other policy restrictions on access.
Officially speaking, the Internet protocol documents are simply standards adopted by the
Internet community for its own use. More recently, the Department of Defense issued a
MILSPEC definition of
TCP/IP. This was intended to be a more formal definition, appropriate for use in
purchasing specifications. However most of the TCP/IP community continues to use the
Internet standards. The MILSPEC version is intended to be consistent with it.
Whatever it is called, TCP/IP is a family of protocols. A few provide "low-level"
functions needed for many applications. These include IP, TCP, and UDP. (These will be
described in a bit more detail later.)
Others are protocols for doing specific tasks, e.g. transferring files between computers,
sending mail, or finding out who is logged in on another computer. Initially TCP/IP was
used mostly between
minicomputers or mainframes. These machines had their own disks, and generally were
self-contained. Thus the most important "traditional" TCP/IP services.

The Redirector

The Redirector is the component that enables a client computer to gain access to
resources on another computer as if the remote resources were local to the client
computer. The Redirector communicates with other computers using the protocol stack.
The Redirectors primary function is to format remote requests so that they can be
understood by a remote station (such as a file server) and send them on their way through
the network.
The Redirector uses the Server Message Block (SMB) structure as the standard vehicle
for sending these requests. The SMB is also the vehicle by which stations return
responses to Redirector requests.
Each SMB contains a header consisting of the command code (which specifies the task
that the redirector wants the remote station to perform) and several environment and
parameter fields (which specify how the command should be carried out).
In addition to the header, the last field in the SMB may contain up to 64K of data to be
sent to the remote station.

What are SMB's?

Server Message Blocks are a type of "messaging protocol" that LAN Manager (and NT)
clients and servers use to communicate with each other. SMB's are a higher level protocol
that can be transported over NetBEUI, NetBIOS over IPX, and NetBIOS over TCP/IP (or
NBT).
SMBs are used by Windows 3.X, Win95, WintNT and OS/2. When it comes to security
and the compromise of security on an NT network, the one thing to remember about
SMBs is that it allows for remote access to shared directories, the registry, and other
system services, making it a deadly protocol in the eyes of security conscience people.
The SMB protocol was originally developed by IBM, and then jointly developed by
Microsoft and IBM. Network requests that are sent using SMB's are encoded as Network
Control Blocks (NCB) data structures. The NCB data structures are encoded in SMB
format for transmission across the network. SMB is used in many Microsoft and IBM
networking software:
* MS-Net
* IBM PC Network
* IBM LAN Server
* MS LAN Manager
* LAN Manager for Unix
* DEC Pathworks
* MS Windows for Workgroups
* Ungermann-Bass Net/1
* NT Networks through support for LAN Manager
SMB Messages can be categorized into four types:
Session Control: Used to establish or discontinue Redirector connections with a remote
network resource such as a directory or printer. (The redirector is explained below)
File: Used to access and manipulate file system resources on the remote computer.
Printer: Used by the Redirector to send print data to a remote printer or queue, and to
obtain the status of remote print devices.
Message: Used by applications and system components to send unicast or broadcast
messages.

Preface to SMB's

The reason I decided to write this section was because recently the rhino9 team has been
giving speeches and lectures. The two questions we most frequently come across is
"What is NetBIOS?" and "What are SMBs?". Well I hope I have already answered the
NetBIOS question with the section above. This particular section is being written to
better help people understand SMB's.

NetBIOS Scopes

A NetBIOS Scope ID provides an extended naming service for the NetBIOS over TCP/IP
(Known as NBT) module. The primary purpose of a NetBIOS scope ID is to isolate
NetBIOS traffic on a single network to only those nodes with the same NetBIOS scope
ID. The NetBIOS scope ID is a character string that is appended to the NetBIOS name.
The NetBIOS scope ID on two hosts must match, or the two hosts will not be able to
communicate. The NetBIOS Scope ID also allows computers to use the same computer
namee as they have different scope IDs. The Scope ID becomes a part of the NetBIOS
name, making the name unique.

NetBEUI Explained

NetBEUI is an enhanced version of the NetBIOS protocol used by network operating
systems. It formalizes the transport frame that was never standardized in NetBIOS and
adds additional functions. The transport layer driver frequently used by Microsofts LAN
Manager. NetBEUI implements the OSI LLC2 protocol. NetBEUI is the original PC
networking protocol and interface designed by IBM for the LanManger Server. This
protocol was later adopted by Microsoft for their networking products. It specifies the
way that higher level software sends and receives messages over the NetBIOS frame
protocol. This protocol runs over the standard 802.2 data-link protocol layer.

NetBIOS Datagrams

Datagrams can be sent to a specific name, sent to all members of a group, or broadcast to
the entire LAN. As with other datagram services, the NetBIOS datagrams are
connectionless and unreliable. The Send_Datagram command requires the caller to
specify the name of the destination. If the destination is a group name, then every
member of the group receives the datagram. The caller of the Receive_Datagram
command must specify the local name for which it wants to receive datagrams. The
Receive_Datagram command also returns the name of the sender, in addition to the actual
datagram data. If NetBIOS receives a datagram, but there are no Receive_Datagram
commands pending, then the datagram is discarded.
The Send_Broadcast_Datagram command sends the message to every NetBIOS system
on the local network. When a broadcast datagram is received by a NetBIOS node, every
process that has issued a Receive_Broadcast_Datagram command receives the datagram.
If none of these commands are outstanding when the broadcast datagram is received, the
datagram is discarded.
NetBIOS enables an application to establish a session with another device and lets the
network redirector and transaction protocols pass a request to and from another machine.
NetBIOS does not actually manipulate the data. The NetBIOS specification defines an
interface to the network protocol used to reach those services, not the protocol itself.
Historically, has been paired with a network protocol called NetBEUI (network extended
user interface). The association of the interface and the protocol has sometimes caused
confusion, but the two are different.
Network protocols always provide at least one method for locating and connecting to a
particular service on a network. This is usually accomplished by converting a node or
service name to a network address (name resolution). NetBIOS service names must be
resolved to an IP address before connections can be established with TCP/IP. Most
NetBIOS implementations for TCP/IP accomplish name address resolution by using
either broadcast or LMHOSTS files. In a Microsoft enviroment, you would probably also
use a NetBIOS Namer Server known as WINS.

NetBIOS Sessions

The NetBIOS session service provides a connection-oriented, reliable, full-duplex
message service to a user process. NetBIOS requires one process to be the client and the
other to be the server. NetBIOS session establishment requires a preordained cooperation
between the two stations. One application must have issued a Listen command when
another application issues a Call command. The Listen command references a name in its
NetBIOS name table (or WINS server), and also the remote name an application must use
to qualify as a session partner. If the receiver (listener) is not already listening, the Call
will be unsuccessful. If the call is successful, each application receives notification of
session establishment with the session-id. The Send and Receive commands the transfer
data. At the end of a session, either application can issue a Hang-Up command. There is
no real flow control for the session service because it is assumed a LAN is fast enough to
carry the required traffic.

NetBIOS suffixes

Name Number Type Usage
===============================================================
===========
<computername> 00 U Workstation Service
<computername> 01 U Messenger Service
<\\_MSBROWSE_> 01 G Master Browser
<computername> 03 U Messenger Service
<computername> 06 U RAS Server Service

<computername> 1F U NetDDE Service
<computername> 20 U File Server Service
<computername> 21 U RAS Client Service
<computername> 22 U Exchange Interchange
<computername> 23 U Exchange Store
<computername> 24 U Exchange Directory
<computername> 30 U Modem Sharing Server Service
<computername> 31 U Modem Sharing Client Service
<computername> 43 U SMS Client Remote Control
<computername> 44 U SMS Admin Remote Control Tool
<computername> 45 U SMS Client Remote Chat
<computername> 46 U SMS Client Remote Transfer
<computername> 4C U DEC Pathworks TCPIP Service
<computername> 52 U DEC Pathworks TCPIP Service
<computername> 87 U Exchange MTA
<computername> 6A U Exchange IMC
<computername> BE U Network Monitor Agent
<computername> BF U Network Monitor Apps
<username> 03 U Messenger Service
<domain> 00 G Domain Name
<domain> 1B U Domain Master Browser
<domain> 1C G Domain Controllers
<domain> 1D U Master Browser
<domain> 1E G Browser Service Elections
<INet~Services> 1C G Internet Information Server
<IS~Computer_name> 00 U Internet Information Server
<computername> [2B] U Lotus Notes Server
IRISMULTICAST [2F] G Lotus Notes
IRISNAMESERVER [33] G Lotus Notes
Forte_$ND800ZA [20] U

NetBIOS Names

NetBIOS names are used to identify resources on a network. Applications use these
names to start and end sessions. You can configure a single machine with multiple
applications, each of which has a unique NetBIOS name. Each PC that supports an
application also has a NetBIOS station name that is user defined or that NetBIOS derives
by internal means.
NetBIOS can consist of up to 16 alphanumeric characters. The combination of characters
must be unique within the entire source routing network. Before a PC that uses NetBIOS
can fully function on a network, that PC must register their NetBIOS name.
When a client becomes active, the client advertises their name. A client is considered to
be registered when it can successfully advertise itself without any other client claiming it
has the same name. The steps of the registration process is as follows:
1. Upon boot up, the client broadcasts itself and its NetBIOS information anywhere from
6 to 10 to ensure every other client on the network receives the information.
2. If another client on the network already has the name, that NetBIOS client issues its
own broadcast to indicate that the name is in use. The client who is trying to register the
already in use name, stop all attempts to register that name.
3. If no other client on the network objects to the name registration, the client will finish
the registration process.
There are two types of names in a NetBIOS enviroment: Unique and Group. A unique
name must be unique across the network. A group name does not have to be unique and
all processes that have a given group name belong to the group. Each NetBIOS node
maintains a table of all names currently owned by that node.
The NetBIOS naming convention allows for 16 characters in a NetBIOS name.
Microsoft, however, limits these names to 15 characters and uses the 16th character as a
NetBIOS suffix. A NetBIOS suffix is used by Microsoft Networking software to
indentify the functionality installed or the registered device or service.

Whats is NetBIOS?

NetBIOS (Network Basic Input/Output System) was originally developed by IBM and
Sytek as an Application Programming Interface (API) for client software to access LAN
resources. Since its creation, NetBIOS has become the basis for many other networking
applications. In its strictest sense, NetBIOS is an interface specification for acessing
networking services.

NetBIOS, a layer of software developed to link a network operating system with specific
hardware, was originally designed as THE network controller for IBM's Network LAN.
NetBIOS has now been extended to allow programs written using the NetBIOS interface
to operate on the IBM token ring architecture. NetBIOS has since been adopted as an
industry standard and now, it is common to refer to NetBIOS-compatible LANs.
It offers network applications a set of "hooks" to carry out inter-application
communication and data transfer. In a basic sense, NetBIOS allows applications to talk to
the network. Its intention is to isolate application programs from any type of hardware
dependancies. It also spares software developers the task of developing network error
recovery and low level message addressing or routing. The use of the NetBIOS interface
does alot of this work for them.
NetBIOS standardizes the interface between applications and a LANs operating
capabilities. With this, it can be specified to which levels of the OSI model the
application can write to, making the application transportable to other networks. In a
NetBIOS LAN enviroment, computers are known on the system by a name. Each
computer on the network has a permanent name that is programmed in various different
ways. These names will be discussed in more detail below.
PC's on a NetBIOS LAN communicate either by establishing a session or by using
NetBIOS datagram or broadcast methods. Sessions allow for a larger message to be sent
and handle error detection and correction. The communication is on a one-to-one basis.
Datagram and broadcast methods allow one computer to communicate with several other
computers at the same time, but are limited in message size. There is no error detection or
correction using these datagram or broadcast methods. However, datagram
communication allows for communication without having to establish a session.
All communication in these enviroments are presented to NetBIOS in a format called
Network Control Blocks (NCB). The allocation of these blocks in memory is dependant
on the user program. These NCB's are divided into fields, these are reserved for input and
output respectively.
NetBIOS is a very common protocol used in todays enviroments. NetBIOS is supported
on Ethernet, TokenRing, and IBM PC Networks. In its original induction, it was defined
as only an interface between the application and the network adapter. Since then,
transport like functions have been added to NetBIOS, making it more functional over
time.
In NetBIOS, connection (TCP) oriented and connectionless (UDP) communication are
both supported. It supports both broadcasts and multicasting and supports three distinct
services: Naming, Session, and Datagram.

Preface to NetBIOS

Before you begin reading this section, understand that this section was written for the
novice to the concept of NetBIOS, but - it also contains information the veteran might
find educational. I am prefacing this so that I do not get e-mail like "Why did you start
your NetBIOS section off so basic?" - Simple, its written for people that may be coming
from an enviroment that does not use NetBIOS, so they would need me to start with
basics, thanks.

Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground

Kevin Poulsen, "Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground"
ISBN: 0307588688 | 2011 | EPUB/MOBI | 288 pages | 2 MB/903 KB

Former hacker Kevin Poulsen has, over the past decade, built a reputation as one of the top investigative reporters on the cybercrime beat. In Kingpin, he pours his unmatched access and expertise into book form for the first time, delivering a gripping cat-and-mouse narrative—and an unprecedented view into the twenty-first century’s signature form of organized crime.


The word spread through the hacking underground like some unstoppable new virus: Someone—some brilliant, audacious crook—had just staged a hostile takeover of an online criminal network that siphoned billions of dollars from the US economy.

The FBI rushed to launch an ambitious undercover operation aimed at tracking down this new kingpin; other agencies around the world deployed dozens of moles and double agents. Together, the cybercops lured numerous unsuspecting hackers into their clutches. . . . Yet at every turn, their main quarry displayed an uncanny ability to sniff out their snitches and see through their plots.

The culprit they sought was the most unlikely of criminals: a brilliant programmer with a hippie ethic and a supervillain’s double identity. As prominent “white-hat” hacker Max “Vision” Butler, he was a celebrity throughout the programming world, even serving as a consultant to the FBI. But as the black-hat “Iceman,” he found in the world of data theft an irresistible opportunity to test his outsized abilities. He infiltrated thousands of computers around the country, sucking down millions of credit card numbers at will. He effortlessly hacked his fellow hackers, stealing their ill-gotten gains from under their noses. Together with a smooth-talking con artist, he ran a massive real-world crime ring.

And for years, he did it all with seeming impunity, even as countless rivals ran afoul of police.

Yet as he watched the fraudsters around him squabble, their ranks riddled with infiltrators, their methods inefficient, he began to see in their dysfunction the ultimate challenge: He would stage his coup and fix what was broken, run things as they should be run—even if it meant painting a bull’s-eye on his forehead.

Through the story of this criminal’s remarkable rise, and of law enforcement’s quest to track him down, Kingpin lays bare the workings of a silent crime wave still affecting millions of Americans. In these pages, we are ushered into vast online-fraud supermarkets stocked with credit card numbers, counterfeit checks, hacked bank accounts, dead drops, and fake passports. We learn the workings of the numerous hacks—browser exploits, phishing attacks, Trojan horses, and much more—these fraudsters use to ply their trade, and trace the complex routes by which they turn stolen data into millions of dollars. And thanks to Poulsen’s remarkable access to both cops and criminals, we step inside the quiet, desperate arms race that law enforcement continues to fight with these scammers today.

Ultimately, Kingpin is a journey into an underworld of startling scope and power, one in which ordinary American teenagers work hand in hand with murderous Russian mobsters and where a simple Wi-Fi connection can unleash a torrent of gold worth millions.

Download
http://extabit.com/file/27avaj2ew5j6t/0307588688Kingpin.epub
http://extabit.com/file/27avaj2ew5j6d/0307588688Kingpin.mobi
or
http://vip-file.com/download/02722.0084dbc288c3b56e73c52921b93d/0307588688Kingpin.epub.html
http://vip-file.com/download/43307.4a8c36cc78fee116754434b08de8/0307588688Kingpin.mobi.html

Link Box: Last Check Time :May 17, 2012, 11:21 am

http://extabit.com/file/27avaj2ew5j6t/0307588688Kingpin.epub

http://extabit.com/file/27avaj2ew5j6d/0307588688Kingpin.mobi

http://vip-file.com/download/02722.0084dbc288c3b56e73c52921b93d/0307588688Kingpin.epub.html

http://vip-file.com/download/43307.4a8c36cc78fee116754434b08de8/0307588688Kingpin.mobi.html

Accounts and Passwords---Types of Accounts

Active Directory (AD)

For UMBC employees, AD grants access to department computer workstations, printers, and shared network resources. Active Directory is a collective term for Microsoft's integrated set of directory services. Most significantly, Active Directory provides a central, search-able information repository (allowing simple sharing of network resource information), while acting as the central authority for network security.

All network resources are represented in Active Directory as objects and each object can be assigned certain attributes, which characterize the object. For example, a user object in Active Directory can have attributes such as First Name, Last Name, Phone Number etc.

Calendar (Oracle)

Oracle Calendar is the calendering and scheduling software used at UMBC. Calendar allows faculty and staff to maintain personal agendas, schedule meetings with each other on an invitational basis, and schedule resources (such as meeting rooms).

Mailing List (Sympa)

The list service runs on the lists.umbc.edu server and includes the following features: 1) built-in archiving, 2) automatic bounce processing, 3) spam filtering, 4) content filtering, and 5) digest delivery.

myUMBC

myUMBC portal is a web "supersite" with a collection of links to popular web services at UMBC. A kind of "doorway" into the University. The site provides a variety of services including course registration, directories, online shopping, discussion groups, Web searching, channels (small windows within a page that are dynamically updated and determined by the user) and links to other sites.

AFS

Grants access to computer labs, file storage, website publishing and more.

Blackboard

Blackboard is a Web-based course-management system designed to allow students and faculty to participate in classes delivered online or use online materials and activities to complement face-to-face teaching. Blackboard enables instructors to provide students with course materials, discussion boards, virtual chat, online quizzes, an academic resource center, and more. The degree to which Blackboard is used in a course varies. For example, instructors may supplement an on-campus class by putting their syllabus and handouts on their course sites. In contrast, other courses may be conducted entirely through Blackboard, without any on-campus sessions. If you’re enrolled in a course that uses Blackboard, be sure to find out how Blackboard will be used in that course.

Email

DoIT provides incoming and outgoing gateways for the passage of email to and from the University. Incoming gateways deliver to DoIT supported mail servers, from which users read their email, and also deliver to some departmental systems which support their own users. The gateways perform virus checking and spam email assessment. High spam scores are used to discard messages before delivery to user inbox servers; intermediate scores can be used to tag them for filtering according to user selected rules.

There are two systems for handling email at the University which are managed by DoIT. The new one is G-mail or Google email which is used for all new accounts that have their mail delivered to DoIT managed systems and a legacy Unix (Cyrus) service which is used for a all accounts prior to August, 2010.

Cyrus (Legacy system)

It manages access and storage of mail messages according to accepted internet standards, allowing users to access their mail with almost any standards-compliant mail program including Webmail, Pine, Outlook, Thunderbird, or Apple Mail.

G-mail (started August, 2010)

Google Apps is a package of online applications that makes communicating and collaborating at UMBC easier and more efficient. The cornerstone of Google Apps is Gmail, Google’s web-based email program, which integrates with Google Docs, for creating and sharing documents, and Google Calendar, for coordinating schedules. All of these services are hosted online, so email, documents, and calendars are always accessible from any computer, anywhere.

The Google contract was signed by the attorney general’s office in July 2010 under the Maryland Education Enterprise Consortium (MEEC) umbrella. UMBC was the first USM school to sign the new contract thus allowing UMBC to offer the Google collaborative tools to the UMBC community.

Portal

myUMBC is a personalized student web portal that your student will create and customize to their specific interests. Your student will need to create a myUMBC portal account not only to register to visit campus and apply, but also to take care of their business throughout the admission process. myUMBC will add your student to our mailing list and deliver personalized academic information; it’s the only place to register for campus visit events, and track their admissions status throughout the process.

ResNet

UMBC's Residential Network (ResNet) provides access to information resources, including computer networks and computer equipment to students living in the residence halls. Appropriate use of computing resources should always be legal and ethical, reflect academic honesty, uphold community standards, and prevent the over-consumption of shared resources such as network bandwidth. Appropriate use should demonstrate respect for intellectual property, ownership of data, system security mechanisms, and individual's right to privacy and to freedom from intimidation and harassment.

VPN

Secure remote access to campus computing resources including Library journals.

Wireless

Customers who use this can access the network from an average of up to 150 feet, or 50 meters, away from a wireless hub without cables or connectors. These radio frequencies pass through most building materials, allowing network access outdoors.

Wireless is a supplement to regular connections but is not a replacement. Although wireless is often convenient, physical connections are still faster, more secure, and more reliable.

Peoplesoft Finance/HR

The Financial database consists of general ledger, accounts payable, purchasing and reports. The PeopleSoft HRMS system consists of human resources and payroll. In order to obtain access to the various financial and HR applications, you must have a myUMBC account and be granted access to the application.

Research Computing

Research computing accounts provide access to the high performance computing platforms and software that DoIT maintains and are meant to be used for computation- and memory-intensive computing jobs.

Scheduling (R25)

Resource 25, or simply R25, is a campus-wide event and class scheduling system. R25 will assist the computing community by streamlining the way we schedule events and reserve spaces on campus. It also fosters more efficient use of space and simplify space planning processes across campus.

Student Administration

Student Administration (SA) is the corporate system that will be used to manage the student academic life cycle from application through to award.

About DoIT

The Division of Information Technology is headquartered in the Engineering building, room 125. We provide support to most academic buildings and have staff offices in Engineering, Administration, and Academic IV A and B. DoIT services touch every member of the UMBC community through our portal (myUMBC), networks (wired and wireless), instructional support (Blackboard and AV Services), or Internet (email and web).

In an average year, DoIT handles 25,000 helpdesk requests, 18,000 audio-visual service requests, supports over 60 million web hits, and delivers 100 million email messages.

The mission of the Division of Information technology is to facilitate and implement the educational, research and administrative goals of UMBC through the development and delivery of information and instructional technology services to our customers, the UMBC community.

DoIT's purpose is to provide an advanced and integrated set of information and instructional technology services to faculty, staff, and students that make major contributions to the educational, research and administrative activities of UMBC.

DoIT staff strive to provide the best possible information and instructional technology services that our customers consider to be:
Easy to use Reliable Robust Cost-effective Secure.

DoIT core values:

• We look to form partnerships within and outside the campus.
• We listen to and collaborate with our customers, who are the students, faculty and staff, to meet our collective goals.
• Our services are robust and reliable and we provide the highest quality support possible.
• We value technical innovation and creativity in developing cost-effective solutions to meeting campus goals.
• We value and respect each other, working as a team to leverage our individual strengths to deliver the best products and services possible.
• We strongly encourage professional development to keep our technical skills up to date as a means to minimize the complexity of technology for the campus.
• We are active in the UMBC, USM, and higher educational communities and participate in many ways to make UMBC the best it can be.

Office of the Vice President and CIO

Vice President for Information Technology and CIO  Mr. John (Jack) Suess  Jack@umbc.edu  410.455.2582  Homepage:  http://bit.ly/e6uDtT Blog:  http://bit.ly/felhWd Twitter: http://twitter.com/#!/jjsuess

Units

The Division of Information Technology has three major units: Business Technology, Infrastructure and Support, and Instructional Technology and New Media. These units work cooperatively with each other and with units outside of DoIT to provide high-quality services to the UMBC community.

Business  Technology Services  Mr. Joe Kirby  kirby@umbc.edu  Admin Building 627  410.455.3020

Business Technology services provides support for administrative and business applications used at UMBC. In particular, today they provide support for PeopleSoft HR and Finance, iStrategy data warehouse, and our legacy SIS.  New initiatives underway include the implementation of the PeopleSoft Student Administration modules, expected to be fully completed by fall 2009 and a new document imaging initiative designed to support better customer service for students and faculty.

Infrastructure and Support Services  Dr. Michael Carlin  mikec@umbc.edu  Engineering 201  410.455.2578

Infrastructure and Support Services is responsible for overseeing the technical operations of the campus IT infrastructure: servers, disk space, network, security, and computer labs. In addition, this unit provides support for our identity management system and for general campus IT support.  Initiatives underway include the following: Server virtualization Enhancements of campus WAN to  support 10GB connectivity off-campus; Mail system upgrade; Security enhancements; PeopleSoft SA technical environment; Identity Management enhancements

Instructional Technology and New Media  Mr. John Fritz  fritz@umbc.edu  Engineering 101  410.455.6596

Instructional Technology and New Media is responsible for overseeing the teaching and learning infrastructure and support for UMBC: audio-visual services, Blackboard course management system, the International Language Center, interactive video conferencing (IVN), and New Media Studio.  This unit works closely with the Faculty Development Center, Kuhn Library, and Continuing and Professional Studies.  Initiatives underway include the following: Faculty development, especially in hybrid and online courses; Upgrading classrooms so all have fixed projection technology; Supporting and refining the Blackboard course management system (CMS); myUMBC portal enhancements; Digital Storytelling initiative; Web and multi-media development.