Home
Handbook
Contents
Glossary
Transmission Control Protocol / Internet Protocol
This document covers TCP/IP networking basics, up to DNS. See Part 2 for details on common higher-level TCP/IP services, such as Email and the WWW, and part 3 for Intranetting.
To download freeware and shareware software referred to here, and sample configuration files, see the WCSN FTP site.
Every host (workstation, server, router or any other system which talks TCP/IP) has an IP address. IP addresses are 32-bit numbers, which are represented as four decimal numbers in the range 0-255, separated by dots (the dotted quad notation), for example
196.21.102.12
is the IP address of picasso.wcape.school.za.
An IP address comprises a network part and a host part.
For example, the WCSN's UCT systems are located on the network 196.21.102.0 and the host address of picasso specifically is indicated by the last number, .12.
IP numbers are unique across the whole Internet. No two hosts may share the same IP address (although a host may have more than one IP address).
IP numbers are assigned in the first instance by IANA, the Internet Assigned Numbers Authority. IANA assigns address space (blocks of network numbers) to ISPs (Internet Service Providers) or regional numbering authorities, who in turn assign them to smaller ISPs or directly to clients.
The WCSN assigns IP addresses to schools from the numbers assigned to us by Uninet, the South African national academic network.
An organization that needs IP addresses is assigned a network number. Historically, three different types of network numbers were assigned:
This is relatively wasteful of IP addresses however, and nowadays organizations with requirements that do not justify a Class B network may be assigned an intermediate-size network, for example 20 bits of network number, and 12 bits of host addresses.
Schools are typically assigned Class C networks (a 24-bit, or 3-digit, network number with 8 bits, ie. 255, host addresses).
Although an organization is assigned a continuous block of addresses, there may be many different network segments (typically ethernet segments) within the organization. So the single assigned network is divided into several subnetworks using a process called subnetting, which simply splits the assigned network into smaller networks by using some of the host address bits to indicate the local network part of the address.
For example a typical school assigned a class C network with network number 196.21.103.0 has 255 possible addresses. But if it has 4 ethernet segments, it needs at least four networks. Thus the 8 bits of host address are divided into 3 bits of network address, and 5 bits of host address. For example, if "h" indicates a bit used for the host address, and "N" indicates a bit used for the network address, then
A.B.C.hhhhhhhh
is divided into
A.B.C.NNNhhhhh
(A.B.C are the network numbers assigned to the school).
Networks are numbered by giving the decimal representation of the network adress (including the subnet part), and the rest zeros, so in the case of a school assigned a class C network of 196.21.103.0, the networks are
And when subnetted, 8 subnets are created, viz.
However subnet numbers using all zeros and all ones (subnets numbered 1 and 8 above) are not used, so this leaves the school with 6 possible subnets, each with 32 addresses. Again, host numbers with all zeros and all ones are not used, so the school actually has 30 IP addresses per subnet, ie. a total of 6 x 30 = 180 useable addresses from the allocated range of 255.
It is important to realise therefore that the physical network layout (ie. the way in which the network is constructed from a number of ethernet segments) determines the IP numbering and subnetting: each ethernet segment must have its own distinct subnet. Consequently, if the physical layout of a network changes (eg. an extra ethernet segment is added), this may have implications for IP numbering across the whole network.
Every IP host needs to know not only it's own IP address, but how the network is configured (ie. what network number it is on, which lets it know what range of addresses are directly accessible on the same network segment).
This information is given in the netmask, which is a number produced by allocating binary 1s to all part of the IP address which indicate the network number, and 0s for the rest.
Incorrectly specified netmasks can cause routing problems.
An IP router is any system which forwards packets from one interface to another, ie. from one network segment to another.
Unix servers such as FreeBSD systems can act as TCP/IP routers, routing between ethernet networks and serial lines (asynchronous modems connected to standard serial ports).
Large WANs are built with dedicated hardware such as Cisco routers, which have ethernet interfaces and synchronous serial ports for serial line speeds from 64kbps to 2Mbps and faster.
A typical WAN router has an ethernet interface and a serial interface. Netware servers can act as ethernet TCP/IP routers forwarding packets from one ethernet segment to another.
Routers make routing decisions about where to send data packets they receive based on what they know about the network. Routers use routing protocols to exchange routing information. The most common routing protocol is RIP (Routing Information Protocol).
Any IP host (workstation or server) can only communicate directly with other IP hosts that are on the same network(s). Thus all hosts are configured with a default gateway, which is the router to which IP packets for any other hosts are sent.
A ping request from one IP host to another means "please send me a reply". (Ping uses ICMP ECHO packets, which are defined as part of the Internet protocol.)
A series of ping packets (eg. 10-50) provides two important measures of network performance:
Ping is thus a simple test of network performance and congestion.
If a ping to an IP host produces no response at all, then it means that
Netware TCP/IP comes with PING.NLM. To ping a host by IP address, type on the server console (directly or using RCONSOLE)
ping is a standard unix utility. To use ping on FreeBSD system,
ping exists in a variety of forms on workstations.
Ethernet is simply one of the transmission mediums which can carry IP protocol packets. Ethernet is conceptually a bus toplogy, which can carry traffic from many different hosts using many different protocols, on the same wire.
An Ethernet Frame Type is a particular way of formatting data packets (specifically the header information) that go onto the ethernet.
Typical frame types in a Netware / ODI context are
The Novell IPX protocol usually uses either Ethernet 802.3 or Ethernet 802.2. TCP/IP requires the Ethernet II frame type.
This means that workstations which are communicating using both the TCP/IP protocols and another LAN protocol such as IPX communicate using two different frame types, which coexist on the ethernet.
Serial lines are conceptually networks with only two nodes, typically called point to point links.
In an IP context, this means that each end of a serial line is conceptually an interface and hence has an IP address.
The point-to-point protocol is a modern link-layer protocol for communications over serial lines. PPP supports the IP protocol and also other protocols such as IPX and NetBEUI.
The Serial Line Internet Protocol is an older method of framing (transmitting) IP packets over serial lines. It is less robust and versatile than PPP, and is usually only used when PPP is not available.
A protocol stack is a logical layering of network functions (protocols, drivers or support modules), from the application interface layer (at the top), to the hardware drivers (at the bottom).
Protocol stacks exist so that the different layers do not need to be concerned with the implementation details of the other layers. For example, an application interface (such as VLM.EXE, which provides access to Netware file and print services) does not need to be concerned with the specific implementation of the IPX protocol, and the IPX protocol implementation does not need to be concerned with the specific implementation of the driver for the network card.
This layering means that different components may be substituted in an "open" interface: for example almost all manufacturers of network cards provide an ODI driver for the card, which means that the card can be used in the Novell ODI protocol stack. The manufacturer's driver is responsible for interacting with the upper layers of the stack in a predefined way, and the hardware implementation details are mostly "invisible" to the upper layers.
The NDIS stack is a protocol stack developed by Microsoft. It is used in products such as Windows for Workgroups 3.11 and Windows 95 to provide Microsoft networking, typically using the NetBEUI protocol.
The Novell ODI (Open Datalink Interface) stack was developed by Novell for Novell Netware. It is typically used with the IPX protocol.
The Packet Driver interface is an early hardware-independent method of providing TCP/IP services to applications. It is similar to a rudimentary protocol stack in that hardware manufacturers provide packet drivers for specific network cards which provide a packet driver interface to applications.
Protocol stack converters (sometimes called shims) allow one to use applications (or upper protocol layers) which expect one type of protocol stack or interface, with another type of protocol stack. These are usually useful in mixed networking environments where network types or protocols are combined.
ODIPKT is a small freeware program which provides a packet-driver interface to applications using an existing ODI stack. Useful for running packet-driver applications (eg. Trumpet Winsock) in a Netware environment.
DISPKT is a freeware program which provides a packet-driver interface to applications using an existing NDIS stack. Useful for running packet-driver applications (eg. Trumpet Winsock) in an NDIS (Microsoft networking or LANtastic) environment.
ODIHLP provides an NDIS interface on top of an ODI stack. This is useful for using Microsoft networking or protocols (eg. Microsoft TCP/IP) in a Netware environment.
The WINSOCK application interface is a standard interface that enables applications to use TCP/IP services. TCP/IP implementations from different manufacturers (eg. Microsoft or Novell) provide a WINSOCK.DLL so that applications can use TCP/IP regardless of the underlying software.
Microsoft TCP/IP is provided with Windows 95, and can be installed with Control Panel / Network / Add Protocol.
MS TCP/IP is also available for Windows for Workgroups 3.11, using the NDIS stack (or NDIS on top of ODI).
Novell provides a TCP/IP implementation called LAN Workplace, a commercial product licensed separately to Netware, for the ODI protocol stack.
As of Netware 4.11 ("Intranetware"), a workstation TCP/IP protocol stack will be included with the Netware license.
Novell's TCP/IP operates as a protocol (parallel to IPXODI) in the ODI stack.
Trumpet Winsock, a shareware product, provides a WINSOCK TCP/IP interface, either over a dialup connection, or on top of a packet driver for Ethernet LANs.
This is typically provided using the freeware converters ODIPKT and WINPKT for an ODI stack, or DISPKT and WINPKT for an NDIS stack.
Artisoft provides a TCP/IP implementation as a commercial product.
Using other TCP/IP implementations requires LANtastic to be installed using the NDIS stack instead of LANtastic's native network-card drivers.
Trumpet Winsock can be used with the NDIS stack using DISPKT and WINPKT as above.
It should also be possible to use Microsoft TCP/IP.
Netware fileservers versions 3.1x and above support the TCP/IP protocol as a loadable protocol.
Netware servers are capable of acting as TCP/IP routers, ie. forwarding IP packets from one ethernet segment to another (and also support SNMP for TCP/IP network management).
There are a number of NLMs (Netware Loadable Modules) that run on Netware servers and provide high-level TCP/IP services.
Mercury is a free SMTP (mail server); NLMs also exist for BOOTP and DHCP (IP address allocation), FTPD (ftp server), and HTTPD (WWW server).
In most environments, it is undesirable to have to configure each workstation with its own IP address manually (for example in an .INI file or NET.CFG file specific to that workstation), because
For this reason, protocols have been developed to automatically allocate IP addresses to workstations from a central server. The two common protocols used for this are BOOTP and DHCP (Dynamic Host Control Protocol). DHCP is the more modern, flexible and preferred protocol.
There are two ways of allocating addresses to workstations.
Both DHCP and BOOTP work using broadcast messages. The client (workstation) sends out an ethernet broadcast message on the network with a request for an IP address, and then listens for a reply. The server hears the broadcast request, and sends a response. The client then configures itself with the returned information (which can also include further information such as netmasks, DNS servers and gateways).
Clients: Trumpet Winsock and LAN Workplace (Novell TCP/IP) can act as BOOTP clients.
Servers: There is a good free implementation of BOOTP for Netware from HellSoft. Almost all unix servers have BOOTP implementations. The ISC-DHCP package provides a good static and dynamic bootp implementation.
Clients: The Microsoft TCP/IP implementations (WinWorkgroups and Win95) only support DHCP.
Servers: Novell provides a DHCP implementation for Netware. For unix servers, the ISC-DHCP package is preferred.
Because the BOOTP/DHCP broadcast mechanism only broadcasts to the directly-attached ethernet segment, a BOOTP/DHCP server on a remote segment will not see the broadcasts unless some intermediate host is able to forward the requests and responses from one segment to another.
Novell provide a BOOTP forwarding NLM called BOOTPFWD.NLM for this purpose. As DHCP is a superset of BOOTP, BOOTPFWD will also forward DHCP requests.
This allows one to operate a unix DHCP server on one network segment, serving requests from workstations on several different remote segments (attached to a Netware fileserver).
DNS is the Internet's Domain Name Service. It provides the mechanism for translating between domain names (eg. "picasso.wcape.school.za") and associated information, primarily IP addresses (196.21.102.12), and vice versa.
DNS is a distributed, hierarchical system. It is a distributed system because no single server or servers contain all of the name information for the entire Internet: information on different parts of the domain name space is provided by different servers. It is hierarchical both because the naming semantics are hierarchical, and because the process of looking up (resolving) domain names may involve querying a hierarchy of nameservers, each of which is authoritative for a particular level of the hierarchy (eg. .za, school.za, wcape.school.za) and contains delegation information to servers that are authoritative for parts of the name space underneath them.
To most systems and users, the DNS is transparent, because DNS servers do all of this work when required.
Forward DNS lookups return different types of information for a particular domain name.
All workstations and servers should have DNS entries with their names and IP addresses (A records). An address lookup for "picasso.wcape.school.za" will thus return the IP address 196.21.102.12, and for "pc05.grove.wcape.school.za", 196.21.103.5.
Some DNS entries are in fact aliases for other system (CNAME records). Almost all names starting with "www" or "ftp" (eg. www.wcape.school.za) are aliases. (For example, "www.wcape.school.za" is presently an alias for "picasso.wcape.school.za").
This allows aliases associated with particular services (for example a Web or FTP server) to be used publicly, and allows the service to be moved transparently from one server to another. Some sophisticated DNS implementations return variable information for aliases (ie. they might return a different result for successive queries), which allows heavily-used services (such as "home.netscape.com") to be shared amongst a number of server.
Some sites (for example sites collecting mail by dial-up UUCP) have domain names but no systems directly connected to the Internet. Such sites make use of mail-forwarding entries (MX records) in the DNS.
An MX record tells other Internet systems where to send email for users at the domain name.
A specific nameserver may hold no information on a particular name, but if it is authoritative for the "parent" domain, it will hold delegation information (NS records) to servers providing information about the subdomain. (For example, the nameserver for "school.za" holds delegation records to picasso.wcape.school.za for the domain "wcape.school.za").
Reverse DNS lookups are a special-case mechanism used to translate IP addresses to domain names. This operates because sites provide reverse DNS tables for IP addresses under their control, as well as maintaining the corresponding forward lookup tables.
IP addresses are stored in network form in reverse order using the pseudo-domain "in-addr.arpa", for example the server handling the "domain"
103.21.196.in-addr.arpa
provides reverse lookup information for IP addresses in the range 196.21.103.0 to 196.21.103.255.
Thus connections from any host with a reverse entry in the DNS may be associated with a domain name. Lookups of this sort are usually used for logging and security reasons (for example only to allow access to some service to hosts that belong to a particular domain, or to record visitors to a Web site by domain rather than IP address).
The nslookup program comes standard with most unix servers, and lets one do DNS queries. To run nslookup, login to a unix server (as any user), and run "nslookup". nslookup will respond with a ">" prompt. You may enter any name or number, and nslookup will return corresponding information, eg.
galadriel /usr/home/scm # nslookup
Default Server: picasso.wcape.school.za Address: 196.21.102.12
> www.netscape.com
Server: picasso.wcape.school.za Address: 196.21.102.12
Name: www3.netscape.com Address: 205.218.156.44 Aliases: www.netscape.com
> 196.21.102.10
Server: picasso.wcape.school.za Address: 196.21.102.12
Name: marimba.wcape.school.za Address: 196.21.102.10