The standard interface defined by Microsoft is the Network Device Interface Specification (NDIS).
The standard interface defined by Novell is the Open Datalink Interface (ODI).
These are different and incompatible specifications. Both of these driver interface standards allow multiple protocol stacks to be run on the same PC. This means that TCP/IP can share a single network interface with another protocol. such as NetWare, when an NDIS or ODI driver is used.
Multiple Protocol Stacks:
Figure 109 shows Multiple Protocol Stacks.
To build complex static routes, use the ROUTE command:
To build complex dynamic routes, use IP Routing:
NetBIOS and the associated protocol NetBEUI (NetBIOS Extended User Interface) have long been the basis of Microsoft's networking strategy.
Basic Input Output System (BIOS ):
It is the part of DOS that defines the I/O calls that applications use to request DOS I/O services. NetBIOS extends this to include calls that support I/O over a network. NetBIOS is an Application Programming Interface (API) that defines how an application program request services from the underlying network. NetBEUI includes the NetBIOS API, the Service Message Block (SMB) protocol, and the NetBIOS Frame (NBF) protocol. SMB is an API that defines how applications ask for network services, but NetBEUI is not just an API. It also includes the NBF protocol that builds NetBIOS frames for transmission over the network. NetBIOS is not just used to refer to the API, it is frequently used to refer to any network that uses NetBIOS.
NetBIOS requires very little memory and runs on any type of PC equipment. It is a fast, lightweight protocol suitable for small LANs. NetBIOS is only suitable for LAN applications, it cannot be used by itself for a WAN or an enterprise network because it is a non-routable protocol (the protocol cannot be passed through routers, she can only be passed on a single physical network, it has no routing protocol and no independent address structure), and it depends on an underlying broadcast medium (it cannot be used over serial lines, point-to-point networks, or internets built from dissimilar physical networks).
NetBIOS over TCP/IP (NBT):
Is a standard protocol, by encapsulating the NetBIOS messages inside TCP/IP datagrams. It is based on the B-node (is an end node that uses broadcast messages to register its name and to request the names of other systems on the network) architecture. The NetBIOS messages are encapsulated in UDP messages and sent using the IP broadcast address. In effect, IP acts as the broadcast medium for the NetBIOS protocol.
The B-node architecture doesn't address the problem of broadcast dependence, so NBT loads a cache with NetBIOS-name-to-IP-address mappings from the LMHOSTS file.
In the B-node model, broadcast are only needed for name resolution. Other messages are addressed directly to the remote host. Therefore, broadcasts are only needed for names that cannot be resolved by other means. NBT also uses a name cache to further improve performance. The name cache provides information about computers that cannot respond to a broadcast. These are computers located outside of the broadcast area, including computers located behind routers or on non-broadcast links. Broadcasts continue to be used to local computers, so no entries need to be made for them in the LMHOSTS file. This keeps the file small and permits it to be cached in memory.
Encapsulating NetBIOS inside IP datagrams reduces the performance and increase the complexity of the protocol. Both protocols requires some level of configuration, whether it is the address for IP or he LMHOSTS file for NetBIOS.
NetBIOS-specific information are the hostname, and are the workgroup name.
NBT-specific information are the scope ID (limits communication between NBT hosts, it limits access and prevents the resources being offered by a system from being seen by systems with a different scope ID), and the location from which the LMHOSTS file should be imported.
Windows Internet Name Service (WINS):
It is a protocol to provide name service for NetBIOS names. The advantage of WINS is that it dynamically learns names and addresses from the transmission on the network, and that it can be dynamically updated by DHCP. The disadvantage is that it requires an NT server, and it is primarily a NetBIOS service. It is generally not used on TCP/IP networks.
DNS Windows Name Resolution:
Can be used to map a NetBIOS name to an IP address, but only if the NetBIOS name and the Internet hostname of the computer are the same. It is a good idea to always make the NetBIOS name and the hostname the same on every system
LMHOSTS File Lookup:
Is a simple flat file that associates NetBIOS names with IP addresses.
#PRE Causes the entry to be pre-loaded into the cache and permanently retained there. Normally entries are only cached when they are used for name resolution and are only retained in the cache for a few minutes. Use #PRE to speed up address resolution for frequently used hostnames.
#DOM Domain identifies NT domain controllers.
#INCLUDE File specifies a remote file that should be incorporated in the local LMHOSTS file. This allows a centrally maintained LMHOSTS file to be automatically loaded. To provide redundant sources for LMHOSTS, enclose a group of #INCLUDE commands inside a pair of #BEGIN_ALTERNATE and #END_ALTERNATE statements. The system tries the various sources in order and stops as soon it successfully downloads one copy of the LMHOSTS file.
134.268.67.1 SERVER01 #PRE
134.268.67.2 SERVER02 #PRE #DOM:DOMAIN01
#INCLUDE \\ SERVER01 \ADMIN\lmhosts
#INCLUDE \\ SERVER02\ADMIN\lmhosts
The system first checks the LMHOSTS file and then issues a DNS query if the NetBIOS name is not found in the file. Many systems use a small LMHOSTS file to provide the addresses of important servers.
Ping, Telnet, FTP, NFS, SMTP, enz..
Reverse Address Resolution Protocol (RARP):
Is a protocol that converts a physical network address into an IP address. This is the reverse of what Address Resolution Protocol (ARP) does. Address Resolution Protocol maps an IP address to a physical address so that data can be delivered over a physical network. It does this by broadcasting an ARP packet that contains the IP address in question. When a system receives an ARP packet that contains its IP address, it responds with a packet that contains its physical network address, e.g. its Ethernet address.
Reverse Address Resolution Protocol (RARP) maps a physical address to an IP address for a system that doesn't know its own IP address. The client uses the broadcast services of the physical network to send out a packet that contains the client's physical network address, and asks if any system on the network knows what IP address is associated with the address. The RARP server responds with a packet that contains the client's IP address.
RARP is a useful tool, but it only provides the IP address. There are still several other values (the subnet mask, default gateway, the list of name servers, and the broadcast address) that need to be manually configured.
Is an alternative to RARP, and when is used, RARP is not needed. BOOTP is a more comprehensive configuration protocol than RARP. It provides much more configuration information, and it continues to evolve to provide ever more comprehensive information. Over time they have expanded to become the Dynamic Host Configuration Protocol (DHCP).
The BOOTP client broadcasts a single packet called a BOOTREQUEST packet that contains, at a minimum, the client's physical network address. The client sends the broadcast using the address 255.255.255.255, which is a special address called the limited broadcast address. The clients wait for a response from the server, and if one is not received within a specified time interval, the client retransmits the request. The server responds to the client's request with a BOOTREPLY packet.
Figure 110 shows the BOOTP message format.
BOOTP uses UDP as a transport protocol and, unlike RARP, it does not require any special Network Access Layer protocols. It uses two different well-known port numbers: UDP port number 67 is used for the server, and UDP port number 68 is used for the client. This is very unusual. Most software uses a well-know port on the server side and a randomly generated port on the client side. The random port number ensures that each pair of source/destination ports identifies a unique path for exchanging information. A BOOTP client, however, is still in the process of booting, it may not know its IP address. Even if the client generates a source port for the BOOTREQUEST packet, a server response addressed to that port and the client's IP address won't be read by a client that doesn't recognise the address. Therefore BOOTP sends the response to a specific port on all hosts. A broadcast set to UDP port 68 is read by all hosts, even by a system that doesn't know its specific address. The system then determines if it is the intended recipient by checking the physical network address embedded in the response. The server fills in all of the fields in the packet for which it has data. There are many different values a server can provide.
Parameter Description Example
bf Bootfile :bf=null
bs Bootfile size :bs=22050
cs Cookie servers list :cs=134.268.xxx.xxx
ds Domain name servers list :ds=134.268.xxx.xxx
gw Gateway list :gw=134.268.xxx.xxx
ha Hardware address :ha=7FF8100000AF
hd Bootfile directory :hd=/usr/boot
hn Send hostname boolean :hn
ht Hardware type :th=ethernet
im Impress server list :im=134.268.xxx.xxx
ip Host IP address :ip=134.268.xxx.xxx
lg Log servers list :lg=134.268.xxx.xxx
lp LPR servers list :lp=134.268.xxx.xxx
ns IEN-116 name servers list :ns=134.268.xxx.xxx
rl Resource location servers :rl=134.268.xxx.xxx
sm Subnet mask :sm=255.255.255.0
tc Template continuation :tc=default1
to Time offset :to=18000
ts Time servers list :ts=134.268.xxx.xxx
vm Vendor magic cookie selector :vm=auto
Tn Vendor extension n :T132="1234597AD3B"
:ds=134.268.67.1 18.104.22.168: \
It is possible to configure a BOOTP server to handle a very large number of clients. One server for each subnet is a good design because it eliminates the need to pass BOOTP information through a router, which requires a special router configuration.
Dynamic Host Configuration Protocol (DHCP):
Is the latest generation of BOOTP. It is designed to be compatible with earlier versions. DHCP is only a proposed standard. DHCP uses the same UDP ports, 67 and 68, as BOOTP, and the same BOOTREQUEST and BOOTREPLY packet format. But DHCP is more than just an update of BOOTP.
The new protocol expands the functions of BOOTP:
The configuration parameters provided by DHCP server include everything defined in the Requirements for Internet Hosts. DHCP provides a client with a complete set of TCP/IP configuration values.
DHCP permits automated allocation of IP addresses.
DHCP uses the portion of the BOOTP packet originally set aside for vendor extensions to indicate the DHCP packet type and to carry a complete set of configuration information. DHCP calls the values in this part of the packet options instead of vendor extensions. This is a more accurate description because DHCP defines how the options are used and does not leave their definition up to the vendors. To handle the full set of configuration values from the Requirements for Internet Hosts, the option field is expanded to 312 bytes from the original 64 bytes of the BOOTP vendor extension field.
DHCP allows addresses to be assigned Manual-, Automatic- and Dynamic allocation:
Manual allocation: The network administrator keeps complete control over addresses by specifically assigning them to clients. This is exactly the same way that addresses are handled by BOOTP.
Automatic allocation: The DHCP server permanently assign an address from a pool of addresses. The administrator is not involved in the details of assigning a client an address.
Dynamic allocation: The server assigns an address to a DHCP client for a limited period of time. The client can return the address to the server at any time, but the client must request an extension from the server to retain the address longer than the time permitted. The server automatically reclaims the address after the lease expires if the client has not requested an extension.
Dynamic allocation is useful in a large distributed network where many PCs are being added and deleted. Unused addresses are returned to the pool of addresses without relying on users or system administrators to take action to return them. Addresses are only used when and where they're needed. Dynamic allocation allows a network to make the maximum use of a limited set of addresses.
DHCP is based on DHCP servers, which assign IP addresses, and DHCP clients, to which addresses are assigned.
Figure 111 illustrates an example of a network running DHCP.
In figure 111, it consists of a single DHCP server and a few clients. As shown, a single DHCP server can supply addresses for more than one network. To support DHCP on an internetwork, routers must be configured with BOOTP forwarding.
The DHCP server maintains pools of IP addresses, called scopes. When a DHCP client enters a network, it requests and granted a lease to use an address from an appropriate scope.
The concept of leasing is important, because DHCP clients are not ordinarily granted permanent use of an address. Instead, they receive a lease of limited duration. When the lease expires, it must be renegotiated. This approach ensures that unused addresses become available for use by other clients.
A single DHCP server can support clients on several networks in an internetwork. Clients moved to different networks are assigned IP addresses appropriate to the new network.
Figure 112 shows a DHCP client obtaining a lease. It shows the dialogue that takes place when a DHCP client obtains a lease from a DHCP server.
Figure 113 shows the life cycle of a DHCP address lease.
The stages in the life cycle are as follow:
1) A DHCP client hosts that enters a network enters an initialising state and broadcasts a discover message on the local network. This message may be relayed to other networks to deliver it to DHCP servers in the Internet.
2) Each DHCP server that receives the discover message and can service the request responds with an offer message that consists of an IP address and associated configuration information.
3) The DHCP client enters a selecting state and examines the offer message that it receives.
4) When the DHCP client selects an offer, it enters a requesting state and sends a request message to the appropriate DHCP server, requesting the offered configuration.
5) The DHCP server grants the configuration with an acknowledgement message that consists of the IP address and configuration along with a lease to use the configuration for a specific time. The local network administrator establishes lease policies.
6) The DHCP client receives the acknowledgement and enters a bound state in which the IP configuration is applied to the local TCP/IP protocols. Client computers retain the configuration for the duration of the lease and may be restarted without negotiating a new lease.
7) When the lease approaches expiration, the client attempts to renew its lease with the DHCP server.
8) If the lease cannot be renewed, the client reenters the binding process and is assigned a lease to a new address. Non-renewed addresses return to the available address pool.
This process is completely transparent to the client and requires little ongoing maintenance on the part of the network administrator.
DHCP can be configured to assign specific addresses to specific hosts, which enables administrators to use DHCP to set host protocol options while retaining fixed address assignments.
Several types of hosts must assigned fixed, manual addresses so that other hosts can enter the addresses into their configurations.
Network File System (NFS):
Is a TCP/IP file sharing protocol that allows a server to export files that are mounted by clients and used as if they are local files. NFS is a client/server application. The server makes part of its filesystem available for use by its clients, and the client uses the remote filesystem as if it were part of its local filesystem. Attaching a remote directory to the local filesystem (a client function) is called mounting a directory. Offering a directory for remote access (a server function) is called exporting a directory.
NFS is a distributed filesystem. An NFS server has one ore more filesystems that are mounted by NFS clients, to the NFS clients, the remote disks look like local disks. NFS filesystems are mounted using the standard UNIX mount command, and all UNIX utilities work just as well with NFS-mounted files as they do with files on local disks. NFS makes system administration easier because it eliminates the need to maintain multiple copies of files on several machines: All NFS clients share the single copy of the file on the NFS server. NFS also makes life easier for users: Instead of logging on to many different systems and moving files from one system to another, a user can stay on one system and access all the files that he or she needs within one consistent file tree.
The Network File System is a distributed file system that provides transparent access to remote disks. Just as NIS allows you to centralise administration of user and host information, NFS allows you to centralise administration of disks. Instead of duplicating common directories on every system, NFS provides a single copy of the directory that is shared by all systems on the network. To a host running NFS, remote filesystems are indistinguishable from local ones. For the user, NFS means that he/she doesn't have to log into other systems to access files. There is no need to use RCP or tapes to move files onto the local system. Once NFS has been set up properly, users should be able to do all their work on their local system, remote files will appear to be local to their own system. NFS and NIS are frequently used together: NIS makes sure that configuration information is propagated to all hosts, and NFS ensures that the files a user needs are accessible from these hosts.
NFS is also built on the RPC protocol and imposes a client-server relationship on the hosts that use it. An NFS server is a host that owns one ore more filesystems and makes them available on the network, NFS clients mount filesystems from one or more servers. This allows the normal client-server model where the server owns a resource that is used by the client. In the case of NFS, the resource is a physical disk drive that is shared by all clients of the server.
Simple Mail Transfer Protocol (SNMP):
Is the TCP/IP mail delivery protocol. It moves mail across the Internet and across your local network. It runs over the reliable, connection-oriented service provided by Transmission Control Protocol (TCP), and it uses well known port number 25.
Command Syntax Function
Hello HELLO <sending-host> Identify sending SMTP
From MAIL FROM <from-addresses> Sender address
Recipient RCPT TO:<to-address> Recipient address
Data DATA Begin a message
Reset RSET Abort a message
Verify VRFY <string> Verify a username
Expand EXPN <string> Expand a mailing list
Help HELP <string> Request on-line help
Quit QUIT End the SMPT session
SMPT is such a simple protocol you can literally do it yourself. You telnet to port 25 (telnet alex.firm.be 25) on a remote host and type mail in from the command line using the SMTP commands.
SMTP provides direct end-to-end mail delivery. This is unusual, most mail systems use store and forward protocols that move mail toward its destination one hop at a time, storing the complete message at each hop and then forwarding it on the next system until final delivery is made. If the direct end-to-end mail delivery fails, the local system knows it right away.
Post Office Protocol (POP):
Is used to transfer the contents of the user's mailbox from the server to the users desktop. POP2 uses port 109 and POP3 uses port 110. These are incompatible protocols that use different commands, but they perform the same basic functions. The POP protocols verify the PC user's login name and password, and move the user's mail from the server to the PC where it is read using a local PC mail reader.
Command Syntax Function POP2
Hello HELLO user password Identify user account
Folder FOLD mail-folder Select mail folder
Read READ [n] Read mail, start with message n
Retrieve RETR Retrieve message
Save ACKS Acknowledge and save
Delete ACKD Acknowledge and delete
Failed NACK Negative acknowledge
Quit QUIT End the POP2 session
Syntax Function POP3
USER username The user's account name
PASS password The user's password
STAT Display the number of unread messages/bytes
RETR n Retrieve message number n
DELE n Delete message number n
LAST Display the number of the last message accessed
LIST [n] Display the size of message n or of all messages
RSET Undelete all message, reset message number to 1
TOP n l Print the header and l lines of message n
NOOP Do nothing
QUIT End the POP3 session
Multipurpose Internet Mail Extensions (MIME):
Is an extension of the TCP/IP mail system, not a replacement for it. MIME is more concerned with what the mail system delivers than it is with the mechanics of delivery. It doesn't attempt to replace SMTP or POP, it extends the definition of what constitutes mail.
A true file sharing system allows files to be accessed at the record level. This makes it possible for a client to read a record from a file located on a remote server, update that record, and write it back to the server without moving the full file from the server to the client.
File sharing is transparent to the user and to the application software running on the user's system. Through file sharing, users and programs access files located on the remote systems as if they were local. In a perfect file sharing environment, the user neither knows nor cares where the files are actually stored.
Remote File System (RFS): Is a TCP/IP file sharing protocol.
Andrew File System (AFS): Is a TCP/IP file sharing protocol.
Network File System (NFS): Is the only TCP/IP file sharing protocol widely available for PC's.
Distributed File System (DFS): Is a new TCP/IP file sharing protocol.