3    Networking

This chapter describes the components of Tru64 UNIX that enable a wide variety of networking capabilities. The following topics are discussed:

3.1    The Internet Protocol Suite

TCP/IP supports a suite of protocols, each of which provides a different service. These protocols allow networking communications to be independent of network hardware. The TCP/IP protocol suite (Figure 3-1) is organized into the following groups:

Applications programs send messages (streams or blocks of data) to transport protocols — UDP and TCP. These protocols receive the data from the application, divide it into packets, add a transport header, and then pass the packets along to the next protocol layer, the Internet layer.

The Internet layer encloses the packet in an IP datagram, adds the datagram header, decides where to send the datagram (either directly to a destination or else to a gateway), and passes the datagram on to the network interface layer. The network interface layer accepts IP datagrams and transmits them as frames over specific network hardware.

Frames received by a network go through the protocol layers in reverse. Each layer strips off the corresponding header information until the data is back at the application level. Frames are received by the network interface layer (for example, an Ethernet adapter), which strips off the physical layer header and sends the datagram to the Internet layer. In the Internet layer, the Internet protocol strips off the IP header and sends the packet to the transport layer. The transport layer strips off the TCP or UDP header and sends the data to the application layer.

Figure 3-1:  TCP/IP Protocols

3.1.1    Application-Layer Protocols

When an application needs to send data to an application on another host, the application sends the information through transport layer protocols to prepare the information for transmission. These protocols include DNS, EGP, BGP, RIP, OSPF, FTP, NFS, TELNET, TFTP, FINGER, SMTP, and SNMP.

3.1.1.1    Domain Name System Protocol

The Domain Name System (DNS) allows one or more hosts in a domain to act as a name server for other hosts within the domain. DNS uses UDP or TCP as its underlying protocol and allows a local network to assign host names within its domain independently from other domains. UDP is the preferred protocol for use with DNS; however, if the UDP response is truncated, TCP can be used.

For more information on DNS, see Section 3.5.1.

3.1.1.2    Routing Protocols

Routing Protocols allow systems on either internal or external LANs to share routing information. In addition to the Exterior Gateway Protocol (EGP), Tru64 UNIX supports the Border Gateway Protocol (BGP) and both the Routing Information Protocol (RIP) and Open Shortest Path First Protocol (OSPF) as part of the gated V4.0.6 routing daemon from NextHop Technologies, Inc. For more information on gated, see Section 3.4.6.

Exterior Gateway Protocol (EGP)

The Exterior Gateway Protocol (EGP) allows the exterior gateway of an autonomous system to share routing information with exterior gateways on other autonomous systems.

An autonomous system is a group of networks and gateways for which one administrative authority has responsibility. Gateways are interior neighbors if they reside on the same autonomous system and exterior neighbors if they reside on different autonomous systems. Gateways that exchange routing information using EGP are said to be EGP peers (neighbors). Autonomous system gateways use EGP to provide reachability information to their EGP neighbors.

EGP allows an exterior gateway to provide remote communications among systems as follows:

EGP restricts exterior gateways by allowing them to advertise only those destination networks reachable entirely within that gateway's autonomous system. Thus, an exterior gateway using EGP passes on information to its EGP neighbors but does not advertise reachability information about its EGP neighbors.

EGP does not interpret the distance metrics that appear in routing update messages from other protocols. EGP uses the distance field to specify whether a path exists. (A value of 255 means that the network is unreachable.) The value cannot be used to compute the shorter of two routes, unless those routes are both contained within a single autonomous system. For this reason, EGP cannot be used as a routing algorithm. As a result, there is only one path from an exterior gateway to any network.

EGP routes are predetermined in the /etc/gated.conf file. This contrasts with the Routing Information Protocol (RIP), which can be used within (that is, interior to) an autonomous system of Internet networks that dynamically reconfigure routes. EGP assumes that IP is the underlying protocol. See the gated(8) reference page for further information.

Border Gateway Protocol

The Border Gateway Protocol (BGP) is an exterior routing protocol used for exchanging routing information between autonomous systems that are either multiple transit autonomous systems or transit and stub autonomous systems. BGP operates with more capability, greater flexibility, and less required bandwidth than EGP. For example, BGP uses path attributes to provide more information about each route and, unlike EGP, maintains an autonomous system (AS) path, which provides enough information (such as the AS number of each autonomous system the route has traversed) to prevent routing loops in an arbitrary topology.

Like EGP, BGP supports both internal and external sessions. When sending routes to an external peer, BGP prepends the local AS number to the AS path so that routes received from an external peer are guaranteed to have the AS number of that peer at the start of the path.

Routes received from an internal neighbor will not in general have the local AS number prepended to the AS path and in general have the same AS path that the route had when the originating internal neighbor received the route from an external peer. Routes with no AS numbers in the path may be legitimately received from internal neighbors; these indicate that the received route should be considered internal to your own AS.

The Tru64 UNIX implementation of BGP supports three versions of the BGP protocol (Versions 2, 3, and 4). BGP Versions 2 and 3 are similar in capability and function. They will propagate only classed network routes, and the AS path is a simple array of AS numbers. BGP Version 4 will propagate fully general address-and-mask routes, and the AS path has some structure to represent the results of aggregating dissimilar routes.

Routing Information Protocol (RIP)

The Routing Information Protocol (RIP) is an implementation of a distance-vector or Bellman-Ford routing protocol for local networks. In Tru64 UNIX it is contained in the gated daemon from NextHop Technologies, Inc. RIP classifies routers as active and passive: active routers advertise their routes to other routers; passive routers listen and update their routes based on the advertisements they receive but do not advertise themselves. Typically, routers run RIP in active mode, while hosts use passive mode.

A router running RIP in active mode broadcasts updates at set intervals. Each update contains paired values, where each pair consists of an IP network address and an integer distance to that network. RIP uses a hop count metric to measure the distance to a destination. The number of hops along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path.

For example, a router advertises directly connected networks as having a hop count of one. Networks that are reachable through another gateway are two hops away, networks that are reachable through two gateways are three hops away, and so forth. RIP chooses the path with the shortest hop count.

Of course, using hop counts to calculate shortest paths between networks may not always produce optimal results. For example, a path with a hop count of three that crosses three Ethernet connections may be substantially faster than a path with a hop count of 2 that crosses two slow-speed serial lines. To compensate for differences in network and serial line rates of transfer, administrators can configure RIP routers to advertise artificially high hop counts for slow links.

Routing Information Protocol for IPv6 (RIPng)

The Routing Information Protocol for IPv6 (RIPng) is based on the Routing Information Protocol (RIP). RIPng allows routers to exchange information for computing routes through an IPv6-based network. In Tru64 UNIX, RIPng is contained in the ip6rtrd daemon. The ip6rtrd daemon supports only active mode and should be run only on Tru64 UNIX nodes acting as IPv6 routers. Tru64 UNIX IPv6 hosts should run the nd6hostd daemon.

Open Shortest Path First

Open Shortest Path First (OSPF) routing protocol is a shortest path first or link-state interior gateway protocol that distributes routing information between routers in a single autonomous system. Suitable for complex networks with a large number of routers, OSPF provides equal cost multipath routing whereby packets to a single destination can be sent simultaneously by more than one network interface.

A link-state protocol dictates that each router maintains a database describing the entire AS topology, which it builds out of the collected link-state advertisements of all routers. Each participating router distributes its local state (that is, the router's usable interfaces and reachable neighbors) throughout the AS by flooding. Each multiaccess network that has at least two attached routers has a designated router and a backup designated router. The designated router floods a link-state advertisement for the multiaccess network and has other special responsibilities. The designated router concept reduces the number of adjacencies required on a multiaccess network.

OSPF allows networks to be grouped into areas. Routing information passed between areas is abstracted, potentially allowing a significant reduction in routing traffic. OSPF uses four different types of routes, listed in order of preference:

Intra-area paths have destinations within the same area and inter-area paths have destinations external to the AS.

Routes imported into OSPF as type 1 routes are supposed to be from EGPs whose external metrics are directly comparable to OSPF metrics. When a routing decision is being made, OSPF will add the internal cost to the AS border router to the external metric.

Type 2 ASEs are used for EGPs whose metrics are not comparable to OSPF metrics. In this case, only the internal OSPF cost to the AS Border router is used in the routing decision.

From the topology database, each router constructs a tree of the shortest paths with itself as the root. This shortest-path tree gives the route to each destination in the AS. Externally derived routing information appears on the tree as leaves. The link-state advertisement format distinguishes between information acquired from external sources and information acquired from internal routers, so there is no ambiguity about the source or reliability of routes. Externally derived routing information (for example, routes learned from EGP or BGP) is passed transparently through the autonomous system and is kept separate from OSPF's internally derived data. Each external route can also be tagged by the advertising router, enabling a passing of additional information between routers on the borders of the autonomous system.

3.1.1.3    File Transfer Protocol

File Transfer Protocol (FTP) allows hosts to transfer files, and provides such tasks as listing remote directories, changing the current remote directory, creating and removing remote directories, and transferring multiple files in a single request. FTP maintains a secure transport by passing user and account passwords to the foreign host. FTP allows interactive user-oriented sessions.

FTP uses reliable stream transport (TCP/IP) to send the files and uses a TELNET-like connection to transfer commands and replies. FTP also understands several basic file formats, including ASCII, IMAGE, and Local 8. TCP/IP implements FTP in the ftp user command and the ftpd daemon.

3.1.1.4    Network File System Protocol over UDP Transport

The Network File System (NFS) provides access to files via standard UNIX system calls, thereby allowing any program to access files across the network. NFS uses the UDP transport layer; therefore, it has to handle lost datagrams. NFS does this by retransmitting requests if a reply has not been received within a reasonable amount of time.

Some requests can be reexecuted on the server without problems, but others (such as file deletion) cause an error if the first request reaches the server but the reply is lost. If the second request is executed, the server finds that the file does not exist and returns an error. NFS servers hold on to such replies and retransmit them if they see a duplicate request.

On the other hand, the protocol is designed so that the servers need no other state information. Server performance is improved by running multiple copies of the server daemon. Server crashes are tolerated with no special code on either client or server.

For more information on NFS, see Section 4.6.

3.1.1.5    Network File System Protocol over TCP Transport

Tru64 UNIX contains NFS support over the TCP transport. UDP may still be the preferred transport in local area networks, but for NFS access over wide area, congested, or lossy networks, TCP may perform better.

Separate threads are used to maintain performance optimizations made to the UDP code paths. The nfsiod daemon spawns kernel threads, instead of forking multiple processes. Each nfsiod thread can handle UDP or TCP mounts, so the nfsiod command accepts one argument.

For more information on NFS, see Section 4.6.

3.1.1.6    Telnet Protocol

The Telnet Protocol (TELNET) provides a standard method for terminal devices and terminal-oriented processes to communicate. TELNET is commonly used by terminal emulation programs that allow you to log in to a remote host. However, TELNET can also be used for terminal-to-terminal communications and interprocess communications.

TCP/IP implements TELNET in the telnet user command and the telnetd daemon.

3.1.1.7    Trivial File Transfer Protocol

The Trivial File Transfer Protocol (TFTP) can read and write files to and from a foreign host. Like FTP, TFTP can transfer files as either 8-bit NETASCII characters or as 8-bit binary data. Unlike FTP, TFTP cannot be used to list or change directories at a foreign host and it has no provisions for security, such as password protection. Data usually can be written or retrieved only in public directories.

TCP/IP implements TFTP in the tftp user command and in the tftpd daemon.

3.1.1.8    Finger Protocol

The Finger Protocol (FINGER) is an application-level Internet protocol that provides an interface between the finger command and the fingerd daemon. The fingerd daemon returns information about the users currently logged in to a specified remote host. If you execute the finger command specifying a user at a particular host, you obtain specific information about that user. The Finger Protocol must be present at the remote host and at the requesting host. FINGER uses TCP as its underlying protocol.

3.1.1.9    Simple Mail Transfer Protocol

The Simple Mail Transfer Protocol (SMTP) is the standard for mail exchange between machines attached to the Internet. It specifies the format of control messages sent between two machines to exchange electronic mail.

As its name implies, SMTP is simple in design and purpose. Its objective is to provide a reliable and efficient mail delivery system across the links between machines. SMTP does not specify the user interface.

3.1.1.10    Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) is the Internet standard protocol for exchanging network management information. The SNMP agent provides a local or remote network manager with information by accessing Management Information Bases (MIBs). The snmpd(8) reference page discusses the configuration, security, cluster support, and supported RFCs for the SNMP agent.

Tru64 UNIX supports both industry standard (IETF RFCs) and HP enterprise-specific MIBs. (See Section 3.4.5 for more details.) HP enterprise-specific MIB specifications are located in the /usr/share/sysman/mibs directory.

The daemons that provide MIB support are /usr/sbin/os_mibs, /usr/sbin/srvSystem_mib, /usr/sbin/svrMgt_mib, /usr/sbin/cpq_mibs, and /usr/sbin/clu_mibs.

Tru64 UNIX includes HP Insight Manager, which uses Web-based access to SNMP MIB data. Section 2.6.1 discusses HP Insight Manager.

See Section 3.3.6 for information about the extensible SNMP programming interface.

3.1.1.11    POP3

The Post Office Protocol (POP3) is a client/server protocol from Qualcomm, Inc. that allows users to download their email from a mail server to a remote client. After messages are delivered to a server, the user connects to the server and downloads the messages to the client machine (a desktop or laptop computer running Windows, MacOS, UNIX, or another operating system). Thereafter, all message processing is local to the client machine and environment. This is the protocol used widely today by Internet Service Providers (ISP) to provide e-mail services for their consumers. For more information, see the Network Administration: Services manual.

Tru64 UNIX supports POP3 Version 3.0.2. The protocol is described in RFC 1939.

3.1.1.12    IMAP4

The Internet Message Access Protocol (IMAP4) is a client/server protocol, based on the Cyrus IMAP4 Revision 1 server from Carnegie Mellon University, that allows mail clients to access mail messages on a server. With it, a user can access his or her mail folders and manipulate the contents remotely without having to log in to the server. The protocol allows clients to create, delete, and rename mail folders, to check for new messages and remove old messages, and to retrieve messages selectively for local viewing. In addition, the user can select messages by attributes and parse messages in the RFC 822 and MIME formats. For more information, see the Network Administration: Services manual.

Tru64 UNIX supports IMAP4 Version 1.6.24. The protocol is described in RFC 2060.

3.1.1.13    Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) is an Internet network layer defined in RFC 2205. It is one of the components in the management of network bandwidth and provides a mechanism in which quality-of-service requests for specific application data streams or flows, simplex unicast or multicast, can be sent and received through a network. If accepted, these requests reserve a specific amount of network bandwidth for the flow.

Applications can use the RSVP API (RAPI) to request enhanced quality-of-service when the default best effort delivery is unacceptable; for example, for video and audio. The types of quality-of-service that applications may request are defined by Internet Integrated Services ( RFC 1633 and RFC 2210).

RSVP on Tru64 UNIX supports FDDI and Ethernet interfaces and unicast and multicast data flows. For more information, see the Network Programmer's Guide.

3.1.2    Transport-Level Protocols

The TCP/IP transport-level protocols (UDP and TCP) allow application programs to communicate with other application programs. The User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP) are the basic transport-level protocols for making connections between Internet hosts. When an application sends a message to the transport layer, UDP and TCP break the information into packets, add a packet header including the destination address, and send the information to the network layer for further processing.

Other protocols and applications use UDP to make datagram connections and TCP to make stream connections. The socket interface implements these protocols.

3.1.2.1    User Datagram Protocol

The User Datagram Protocol (UDP) uses datagrams to communicate between applications on Internet hosts. UDP uses destination protocol ports (abstract destination points within a machine), identified by positive integers, to send messages to one of multiple destinations on a host. The protocol ports receive and hold messages in queues until applications on the receiving host can retrieve them.

UDP relies on the underlying Internet Protocol to send its datagrams and provides the same connectionless message delivery as IP. It offers no assurance of datagram delivery or duplication protection. However, UDP allows the sender to specify source and destination port numbers for the message and also calculates a checksum of both the data and header. These two features allow the sending and receiving applications to ensure the correct delivery of a message.

3.1.2.2    Transmission Control Protocol

The Transmission Control Protocol (TCP) provides reliable stream delivery of data between Internet hosts. Like UDP, TCP relies on the underlying Internet Protocol to transport datagrams and supports the block transmission of a continuous stream of datagrams between process ports. Unlike UDP, TCP provides reliable message delivery and ensures that data is not damaged, lost, duplicated, or delivered out of order to a receiving process. Because of this transport reliability, application programmers are not required to build communication safeguards into their software.

Both TCP and UDP allow programs to send messages to and receive messages from applications on other hosts, and both use protocol ports on the host to identify the specific destination of the message. The TCP retransmission time-out value is dynamically determined for each connection, based on round-trip time.

TCP has the following operational characteristics:

3.1.3    Internet Network-Level Protocols

The Internet network-level protocols (IP, ARP, ICMP) handle machine-to-machine communications. These protocols provide for transmission and reception of transport requests and handle network-level control.

3.1.3.1    Internet Protocol Version 4

The Internet Protocol Version 4 (IPv4) is the primary network-level protocol and the format of all the data sent over the Internet. IPv4 also specifies packet processing and error handling.

IP is connectionless because it treats each packet independently. It is unreliable because it does not guarantee delivery or the order of arrival of packets. However, underlying mechanisms guarantee data integrity, assuming the packet arrives.

IP provides the interface to the network interface level protocols. The physical connections of a network transfer information in a frame with a header and data. IP uses an Internet datagram, which contains a source host address, along with sequencing and control information.

IP automatically adds an IP header to outgoing packets and removes the IP header from incoming packets before sending them to higher level protocols. IP provides for the universal addressing of hosts in the Internet network.

IP is not a reliable communications facility because it does not require acknowledgments from the sending host, the receiving host, or intermediate hosts.

The total length of IP packets can be configured independently for each interface. Packets that are too large for a given interface can be split into multiple, smaller packets (fragments). The original packet is reassembled from the fragments when they reach their destination.

IPv4 Multicasting

The operating system supports IPv4 multicasting on a Local Area Network (LAN), as described in RFC 1112, and also supports Version 3.5 of the IPv4 multicast kernel and Version 3.6 of the mrouted implementation of the Distance Vector Multicast Routing Protocol (DVMRP), which provides support for "tunnelling" and "pruning."

Unlike IPv4 broadcasting, IPv4 multicasting allows packets to be taken off the network only by those clients who have configured their systems to receive the packets. Packets are accepted or rejected at the hardware level, thereby greatly reducing processing overhead. In addition, IPv4 multicasting does not consume much network bandwidth, because applications do not have to send separate packets with identical data to reach several destinations, as they do with point-to-point connections. With IPv4 multicasting, one packet is sent to all interested hosts.

As a result, IPv4 multicasting is valuable to video conferencing applications and applications that provide constant updates to ever-changing information, like applications that provide stock market quotes.

The IPv4 multicasting code was taken from the public domain and is supported on all Ethernet and FDDI adapters.

3.1.3.2    Internet Protocol Version 6

The Internet Protocol Version 6 (IPv6) is the emerging network-level protocol and the format of data sent over the Internet. IPv6 also specifies packet processing and error handling.

IPv6 is supported over the following network interface types:

Neighbor Discovery

IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.

Nodes (hosts and routers) use the Neighbor Discovery protocol to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. Nodes also use the protocol to actively keep track of which neighbors are reachable and which are not and to detect changed link-layer addresses.

Multicast Listener Discovery

Multicast Listener Discovery (MLD) enables each IPv6 router to discover the presence of multicast listeners (nodes that want to receive multicast packets) on its directly attached links and to discover specifically which multicast addresses are of interest to those neighboring nodes. This information is then provided to whichever multicast routing protocol is being used by the router, to ensure that multicast packets are delivered to all links where there are interested receivers.

Internet Control Message Protocol Version 6 (ICMPv6)

The Internet Control Message Protocol Version 6 (ICMPv6) is a required part of every IPv6 implementation. ICMPv6 handles error and control messages for IPv6.

ICMPv6 does the following:

ICMPv6 provides feedback about problems in the communications environment but does not make IPv6 reliable. That is, ICMPv6 does not guarantee that an IPv6 packet will be delivered reliably or that an ICMPv6 message will be returned to the source host when an IPv6 packet is not delivered or is incorrectly delivered.

Mobile IPv6

IPv6 was designed to support mobility through features like its extensible header structure, address autoconfiguration, security (IPsec), and tunneling. Mobile IPv6 builds upon these features and defines operations that enable a mobile node to move from one link to another without changing the node's IP address. In this way, packets can be routed to and from mobile nodes transparently when they are on another network.

The Mobile IPv6 implementation is based on Mobility Support in IPv6 and supports the following:

See the Network Administration: Connections manual for information on planning, configuring, and monitoring Mobile IPv6.

Commands and Daemons Supporting IPv6

The following commands and daemons have been modified to work in both an IPv6 and IPv4 environment:

/sbin/dump /sbin/ifconfig /sbin/init.d/inet /sbin/init.d/route
/sbin/named /sbin/ping /sbin/restore /sbin/route
/usr/bin/finger /usr/bin/ftp /usr/bin/nrdist /usr/bin/rcp
/usr/bin/rdist /usr/bin/rdistd /usr/bin/telnet /usr/sbin/dump
/usr/sbin/ftpd /usr/sbin/ifconfig /usr/sbin/inetd /usr/sbin/named
/usr/sbin/nd6hostd /usr/sbin/netstat /usr/sbin/ping /usr/sbin/pppd
/usr/sbin/rcinet /usr/sbin/rdump /usr/sbin/restore /usr/sbin/rexecd
/usr/sbin/rlogind /usr/sbin/route /usr/sbin/rrestore /usr/sbin/rshd
/usr/sbin/rsvpd /usr/sbin/rwhod /usr/sbin/tcpdump /usr/sbin/telnetd
/usr/sbin/traceroute      

3.1.3.3    Internet Protocol Security

Internet Protocol Security (IPsec) is a security framework that is designed to provide interoperable, high quality, cryptographically-based security for Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6).

The set of security services offered includes the following:

These services are provided at the Internet Protocol (IP) layer, offering protection for both IP and upper layer protocols.

On most systems that use IP as their network-layer protocol, datagrams are transmitted and received openly in a way that allows anyone to view, interpret, and manipulate them. On private networks, this is not a significant problem. However, on public networks this can present significant security problems. Some applications address this by providing their own security; for example, SOCKS, Secure Socket Layer (SSL), Secure HTTP (S-HTTP), and Secure Mail (S-MIME). IPsec enables you to protect all your data as it flows out onto the intranet and Internet.

This implementation supports the full set of IPsec protocols for IPv4 and IPv6, including:

See the Network Administration: Connections manual for information on configuring IPsec and solving IPsec problems.

3.1.3.4    Address Resolution Protocol

The Address Resolution Protocol (ARP) maps 32-bit IPv4 addresses into 48-bit hardware addresses for Ethernet and FDDI links. ARP does not translate addresses for the Serial Line Interface Protocol (SLIP) or Point-to-Point Protocol (PPP) because SLIP and PPP have no hardware addresses.

ARP dynamically traces IPv4 addresses to hardware addresses on local area networks. The result of this tracing is called a map. The mapped information is stored in mapping tables. TCP/IP uses ARP to collect and distribute the information for mapping tables.

The kernel maintains the mapping tables, and ARP is not directly available to users or applications. When an application sends an Internet packet to an interface driver, the driver requests the appropriate address mapping. If the mapping is not in the table, an ARP broadcast packet is sent through the requesting interface driver to the hosts on the local area network.

When a host that supports ARP receives an ARP request packet, the host notes the IPv4 and hardware addresses of the requesting system and updates its mapping table, if necessary. If the receiving host's IPv4 address does not match the requested address, the host ignores the request packet. If the IPv4 address does match, the receiving host sends a reply packet to the requesting system. The requesting system stores the new mapping and uses it to transmit future IPv4 packets.

Unlike most protocols, ARP packets do not have fixed-format headers. Instead, the message is designed to be useful with a variety of network technologies.

3.1.3.5    Internet Control Message Protocol

The Internet Control Message Protocol (ICMP) is a required part of every IPv4 implementation. ICMP handles error and control messages for IPv4.

ICMP does the following:

ICMP provides feedback about problems in the communications environment, but does not make IPv4 reliable. That is, ICMP does not guarantee that an IPv4 packet will be delivered reliably or that an ICMP message will be returned to the source host when an IPv4 packet is not delivered or is incorrectly delivered.

ICMP messages are sent in varying situations, including the following:

3.2    Network Interface Layer

Tru64 UNIX supports the following network transports:

3.2.1    Asynchronous Transfer Mode

Tru64 UNIX supports PCI on 155.5 Mb per second Asynchronous Transfer Mode (ATM) networks; there is also an adapter for the PCI bus that supports 622 Mb ATM networks. ATM is a high-speed, connection-based, cell-switched network that, unlike traditional packet switched networks, can carry different kinds of traffic (voice, video, and data) simultaneously. In addition, ATM provides predictable services to those classes of traffic that require bounded latencies and dedicated bandwidths, and, because ATM separates the physical interface from the datalink layer, the same cell and packet formats can be used over a wide variety of physical interfaces from 1 MB per second to 10 GB per second.

The Tru64 UNIX implementation of ATM consists of permanent virtual circuit support; switched virtual circuit support through ATM Forum UNI 3.0 and 3.1 signalling for point-to-point connections; ATM Forum Integrated Local Management Interface (ILMI) for dynamic network address registration; Classical IP (as defined by RFC 1577, RFC 1483, and RFC 1626); and LAN Emulation over ATM (as defined by The ATM Forum Version 1 standard). For more information on ATM, see the Asynchronous Transfer Mode manual and the Network Administration: Connections manual.

3.2.2    Ethernet Networks

Tru64 UNIX supports 10 MB per second Ethernet networks.

At the physical and IP levels, Tru64 UNIX supports an Ethernet network with a Maximum Transfer Unit (MTU) of 1500 bytes at a maximum of 10 MB per second.

The default MTU at the IP level is 1500 bytes at a maximum of 10 MB per second, although this value can be decreased using the ifconfig command.

In conformance with Ethernet standards, Tru64 UNIX always ensures a minimum packet size of 60 bytes.

3.2.3    Fast Ethernet Networks

Tru64 UNIX supports 100 MB per second Fast Ethernet (IEEE 802.3 100Base-TX) networks in full and half duplex.

MTU sizes at the physical and IP levels are the same as those for regular 10 MB per second Ethernet.

3.2.4    Gigabit Ethernet Networks

Tru64 UNIX supports 1000 MB per second Gigabit Ethernet (IEEE 802.3z 1000Base-T) networks. It supports symmetric and asymmetric Pause Frame Flow control (X-on/X-off) and Jumbo frame compatibility.

MTU sizes at the physical and IP levels are the same as those for regular Ethernet networks, although this value can be changed using the ifconfig command.

3.2.5    Fiber Distributed Data Interface Networks

Tru64 UNIX supports 100 MB per second Fiber Distributed Data Interface (FDDI) networks in conformance with RFC 1042 and RFC 1188.

At the physical level, Tru64 UNIX supports an FDDI network with a Maximum Transfer Unit (MTU) of 4500 bytes at a maximum of 100 MB per second. At the IP level, the MTU is 4352 bytes at a maximum of 100 MB per second.

The default MTU at the IP level is always 4,352 bytes at a maximum of 100 MB per second, although this value can be decreased using the ifconfig command.

3.2.6    Token Ring Networks

Tru64 UNIX supports 4 MB per second and 16 MB per second Token Ring networks and source routing in conformance with RFC 1042.

At the physical level, Tru64 UNIX supports a Token Ring network with a Maximum Transfer Unit (MTU) of 4472 bytes at a maximum of 4 MB per second and 17800 bytes at a maximum of 16 MB per second. At the IP level, the MTU is 4092 bytes at a maximum of 4 MB per second and 8188 bytes at a maximum of 16 MB per second.

The default MTU at the IP level is always 4092 for both 4 and 16 MB per second, although this value can be increased or decreased using the ifconfig command.

3.2.7    Serial Line IP and Compressed Serial Line IP

The operating system has complete IP support for a serial line, so that users can transfer files or NFS-mount file systems across phone lines. The CSLIP slattach command can compress headers to improve performance.

The SLIP/CSLIP code is from OSF/1 Version 1.0. However, because the OSF/1 code did not provide a way to access the CSLIP feature, the slattach command was modified to provide the necessary access to CSLIP.

3.2.8    Point-to-Point Protocol

The Point-to-Point (PPP) protocol provides a method for transmitting datagrams over serial point-to-point links. Unlike SLIP, PPP supports standard encapsulation, simultaneous multiplexing of different network layer protocols, an HDLC frame check sequence for error detection, an HDLC escaping mechanism for use with miscellaneous non-8-bit-transparent telephone and switching equipment, and the dynamic negotiation of IP addresses.

In addition, while SLIP supports only clist tty drivers, PPP supports both clist and STREAMS-based tty drivers, as well as remote logins over LANs.

Note that the PPP code was taken from the public domain and includes contributions identified by the footnoted copyright notices. [Footnote 1] Certain sections of the PPP code were derived from the RSA Data Security, Inc., MD5 Message-Digest Algorithm.

Tru64 UNIX supports PPP Version 2.3.1. ( RFC 1661)

For more information on PPP, see the Network Administration: Connections manual and the pppd(8), pppstats(8), and chat(8) reference pages.

3.2.9    Multiple Adapter Support

Tru64 UNIX supports single systems that have multiple active network adapters in the same subnet; for example, consider tu0 configured with IP address 192.24.156.20 and tu1 configured with IP address 192.24.156.21, both with the same netmask.

On connection establishment, the kernel chooses the interface that has the fewest number of connections. This connection-balancing effect could lead to greater throughput than on a system with just one network adapter per subnet. See the Network Administration: Connections manual for information on configuring multiple adapter support.

3.2.10    Link Aggregation

Link aggregation, also called trunking, enables administrators to combine two or more physical Ethernet Network Interface Cards (NICs) and create a single logical link. (Upper-layer software sees this link aggregation group as a single logical interface.) The single logical link can carry traffic at higher data rates than a single interface because the traffic is distributed across all the physical ports that make up the link aggregation group.

Using link aggregation provides the following capabilities:

You can use a link aggregation group virtual interface for the following point-to-point connections: server-to-server and server-to-switch.

See the Network Administration: Connections manual and lag(7) and lagconfig(8) for information on link aggregation configuration.

3.2.11    NetRAIN

NetRAIN (Redundant Array of Independent Network adapters) detects the physical loss of network connectivity and automatically switches network traffic to a working network interface.

The NetRAIN virtual interface configures two or more interfaces on the same LAN segment into a single interface. One of the physical interfaces is always active while the others remain idle. All interfaces, including the idle interfaces, are constantly monitored to ensure that traffic can flow on each.

If the active interface fails or loses network connectivity, NetRAIN switches network traffic to the next available, working interface. All the context of the previous interface is maintained (for example, hardware address and multicast addresses). The actual failover time is adjustable depending on your network configuration and operation.

Tru64 UNIX provides support for Ethernet, FDDI, and ATM controllers.

See the Network Administration manual and the nr(7) and ifconfig(8) reference pages for information on NetRAIN configuration.

3.2.12    Virtual Local Area Network

A Virtual Local Area Network (VLAN) provides administrators with the ability to create multiple logical networks on a given physical network. A VLAN is identified by a VLAN ID, which is contained in a special Ethernet frame called a tagged frame. This tagging format is defined in the IEEE 802.1q standard.

Each VLAN functions as if it were a physically separate network. All traffic, including broadcast traffic, originating in a particular VLAN is transmitted only to other links in that VLAN. See the Release Notes for Version 5.1B and the vlan(7) and vlanconfig(8) reference pages for more information.

3.3    Application Programming Interfaces

The network programming environment includes the programming interfaces for application, kernel, and driver developers who write network applications and implement network protocols. It also includes the kernel-level resources that an application requires to process and transmit data, some of which include libraries, data structures, header files, and transport protocols.

The following sections briefly discuss the supported application programming interfaces:

For more information on the network programming environment, see the Network Programmer's Guide.

3.3.1    X/Open Transport Interface

The X/Open Transport Interface (XTI) defines a transport layer application interface that is independent of any transport provider. This means that applications written to XTI can be run over a variety of transport providers, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The application specifies which transport provider to use.

Figure 3-2 illustrates the interaction between XTI and the STREAMS and sockets frameworks.

Figure 3-2:  Interaction Between XTI and STREAMS and Sockets Frameworks

Depending on the transport provider specified by the application, data can flow along one of two paths:

3.3.2    Sockets

Sockets are the industry standard programming interface. In Tru64 UNIX, sockets are the interface to the Internet Protocol suite; for example, TCP, UDP, IP, ARP, ICMP, and SLIP. Tru64 UNIX supports the 4.3BSD (the default), 4.4BSD, XNS5.0, XNS4.0, and POSIX 1003.1g Draft 6.6 interfaces.

The sockets framework consists of a series of system and library calls, header files, and data structures. Applications can access networking protocols through socket system calls and can use socket library calls to manipulate network information. For example, the getservent library call maps service names to service numbers, and the htonl library call translates the byte order of incoming data to that appropriate for the local system's architecture.

With sockets, the application in user space passes data to the appropriate socket system calls, which then pass it to the network layer. Finally, the network layer passes it, via the ifnet layer, to the BSD driver, which puts it on the network.

For more information on sockets, see the Network Programmer's Guide, X/Open CAE Specification, Networking Services (XNS), Issue 5; X/Open CAE Specification, Networking Services, Issue 4 (XNS4.0); Protocol Independent Interfaces (POSIX 1003.1g Draft 6.6, Section 5); and the netintro(7) reference page.

3.3.3    STREAMS

The STREAMS framework provides an alternative to sockets. The STREAMS interface consists of system calls, kernel routines, and kernel utilities that are used to implement everything from networking protocol suites to device drivers. Applications in user space access the kernel portions of the STREAMS framework using system calls, such as open, close, putmsg, getmsg and ioctl.

Tru64 UNIX supports System V Release 4.0 STREAMS from the OSF/1 Version 1.2 code base, which provides support for the STREAMS tty interface (although Tru64 UNIX continues to support the existing CLIST and Berkeley-based tty interface). For more information on STREAMS, see the Network Programmer's Guide.

3.3.4    Sockets and STREAMS Interaction

Tru64 UNIX provides the ifnet STREAMS module to allow programs using BSD-based TCP/IP to access STREAMS-based drivers. The module provides the Data Link Bridge (DLB) pseudodriver to allow programs using a STREAMS-based protocol stack to access BSD-based drivers.

3.3.5    Data Link Provider Interface

The Data Link Provider Interface (DLPI) is a kernel-level interface that maps to the data link layer of the OSI reference model. DLPI frees users from specific knowledge of the characteristics of the data link provider, allowing those characteristics to be implemented independently of a specific communications medium. It is primarily a kernel-level interface targeted for STREAMS modules that use or provide data link services.

Tru64 UNIX supports only a partial subset of the DLPI interface. For more information, see the Network Programmer's Guide.

3.3.6    Extensible SNMP Interface

Tru64 UNIX supports extensible SNMP (eSNMP), an application-layer Application Programming Interface (API) that permits user-written programs to function as part of a distributed SNMP agent on a Tru64 UNIX host system.

User programs (subagents) can dynamically register SNMP MIB objects with the eSNMP master agent (/usr/sbin/snmpd) and can subsequently handle the SNMP protocol operations for those objects.

The distribution of MIB objects between cooperating processes is transparent to SNMP applications, which can access all MIB objects using the standard transport endpoints specified in the SNMP RFCs. The eSNMP API (libesnmp.so) uses RFC 2741 (AgentX) to communicate with snmpd. This backward-compatible change permits subagents to interoperate with any SNMP agent conforming to RFC 2741.

The extensible SNMP development tools are contained in the optional programming subset (PMR). For more information, see the Network Programmer's Guide.

3.4    Network Administration Software

Tru64 UNIX supports a variety of network administration software, which is briefly described in the following sections.

3.4.1    Networking Commands and Utilities

Tru64 UNIX supports the entire suite of networking commands from OSF/1 Version 1.2, including finger, ftp, rdump, rdist, routed and gated, telnet, and tftp. The bootpd functions have been folded into the joind daemon, which provides configurations to clients using either the DHCP or BOOTP protocol.

Additionally, Tru64 UNIX supports the following Open Network Computing (ONC) Version 4.2 utility programs, which are invoked by the inetd daemon: rusers and rusersd, rwall and rwalld, spray and rsprayd, rup and rstatd, rquotad, and pcnfsd.

3.4.2    Ethernet Packet Filter and Packet Filter Applications

The Ethernet packet filter is a software driver interface that demultiplexes networking packet headers, as well as provides reception and transmission of packets containing user-defined network protocols. The packet filter can function also as an Ethernet monitor when used to filter specific network protocols.

Note

The Ethernet packet filter is an optional kernel subsystem; application programs that make calls to the packet filter kernel routines may fail if the packet filter is not configured in the currently running kernel. For more information, see the packetfilter(7) reference page.

Tru64 UNIX supports the following packet filter applications:

3.4.3    Dynamic Host Configuration Protocol

Tru64 UNIX supports the Dynamic Host Configuration Protocol (DHCP) based on JOIN Server Version 4.1 from JOIN Systems, Inc.; it is a client/server framework in which the DHCP server can dynamically assign an IP address to a client as the client boots on to the network. Additionally, a DHCP server can provide configuration information to the client, such as the name of the DNS server or the name of the default router for that client.

For example, when a new system is booted for the first time, the DHCP server assigns that system a unique IP address. If that system is moved to another location on the same LAN (perhaps on a different subnet), the DHCP server ensures that a new IP address appropriate to that subnet is assigned to the system, if necessary, when it boots up for the first time.

With DHCP (see Figure 3-3), customers with hundreds of clients no longer have to worry about the assignment of IP addresses; DHCP automatically assigns IP addresses and requires no intervention by a system administrator.

Figure 3-3:  DHCP Configuratrion

For more information on DHCP, see the Network Administration: Connections manual and the dhcp(7) reference page.

3.4.4    The Internet Boot Protocol Daemon

The Internet boot protocol daemon, bootpd, implements an Internet boot protocol (BOOTP) server as defined in RFC 951, RFC 1542, and RFC 2132.

BOOTP is an extensible UDP/IP-based protocol that allows a booting host to configure itself dynamically without having to rely on user intervention. The BOOTP protocol assigns IP addresses to hosts, makes available a file containing a boot program that can be downloaded from a server, provides the address of that server, and the address of an Internet gateway, if one is present.

Like DHCP, the BOOTP protocol supports the centralized management of network addresses.

The joind daemon provides the bootpd functions; the joind daemon also provides DHCP services.

3.4.5    SNMP Agent

The SNMP agent for Tru64 UNIX provides access to a great deal of management information typically used in network administration:

The extensible SNMP agent permits the dynamic addition of supported Management Information Bases (MIBs) on any Tru64 UNIX host.

The master agent, API, and base operating system MIB support are all contained in the standard networking subset (CLINET).

The extensible SNMP development tools are contained in the optional programming subset (PGMR).

3.4.6    The gated Daemon

The gated daemon allows any host with multiple network interfaces to function as an IP router by participating in various IP routing protocols (for example, RIP, OSPF, EGP, and BGP). Tru64 UNIX supports the GateD Release 4.0.6 gated daemon from NextHop Technologies, Inc., which contains support for the following:

For more information on the gated daemon, see the gated(8), gated.conf(4), gated.control(4), gated.proto(4), and gated_intro(7) reference pages.

3.4.7    The screend Daemon

The screend daemon is used with the gateway screen facility to decide which IP packets should be forwarded when the system is acting as an IP gateway.

The gateway packet screening facility, on a Tru64 UNIX system acting as a gateway, allows the system manager to control which packets are forwarded or rejected. As a result, the gateway packet screening facility can be used as one part of a comprehensive network security policy.

The facility consists of a kernel-resident mechanism and a user-level daemon, /usr/sbin/screend. When a packet is ready to be forwarded, the kernel mechanism submits the packet's headers to the daemon. The screend daemon then examines the headers and tells the kernel to forward or reject the packet, based on a set of rules defined in the configuration file, /etc/screend.conf.

Optionally, some or all decisions can be logged, thereby enabling the network manager to detect improper configurations or potential security problems.

3.4.8    UNIX-to-UNIX Copy Program

Tru64 UNIX supports the HoneyDanBer version of the UNIX-to-UNIX Copy Program (UUCP), which is a group of programs that supports communications between two computers running UNIX operating systems. UUCP enables batched, error-free file transfer and remote command execution between two UNIX systems. UUCP is most frequently used to transfer electronic mail, network news, and public domain software over low-speed, low-cost communications links.

UUCP supports only direct connections between two systems; electronic news and mail delivery depend on third-party forwarding. To facilitate mail and news delivery, most connected sites are willing to relay files for other sites. The UUCP network depends on direct distance dialing networks and off-peak long distance rates for its continued functioning. For more information on UUCP, see the uucp_setup(8) reference page.

3.4.9    Local Area Transport

Local Area Transport (LAT) is a protocol that supports communications between host computer systems and terminal servers with terminals, PCs, printers, modems, and other devices over local area networks (LANs). LAT software has the features required for a host to function as a service node, so requests for connections can be made by server users. The software also permits host applications to initiate connections to server ports, designated as application ports, to access remote devices. The LAT driver is STREAMS-based and supports up to 4000 incoming connections, with a theoretical limit of 5000 users.

In Tru64 UNIX, LAT supports both SVR4 and BSD-style terminal devices. Integral serial terminal devices and serial terminal options share the same BSD tty namespace as LAT, which means that if special files are allocated for serial lines, those special files will reduce the number of BSD LAT devices that can be configured.

For more information on LAT, see the lat_intro(7) reference page and the Network Administration: Connections manual.

3.4.10    Network Interface Monitoring

The niffconfig command arranges for one or more network interfaces to be monitored for possible loss of connectivity. Timing parameters that govern how quickly an interface can be declared suspect or dead can be manipulated with this command.

Once an interface has been specified for monitoring, the kernel Traffic Monitor Thread (TMT) checks the connectivity of the monitored interface and, if necessary, informs the Network Interface Failure Finder daemon (niffd) to generate traffic for the network interface that has been classified inactive. The niffd daemon's purpose is to get the interface packet counters to increment, signifying the interface is still alive and well.

See the Network Administration: Connections manual and the niffconfig(8), niffd(8), and nifftmt(7) reference pages.

3.5    Naming Services

Tru64 UNIX supports the following distributed naming services:

The library routines in /usr/lib/libc.so allow transparent access to DNS, NIS, and local /etc files. The name services configuration file, /etc/svc.conf, dictates which naming services are queried, and in what order, for a particular database.

Tru64 UNIX allows you to convert from an NIS-distributed environment to a DNS-distributed environment or to run both services in the same environment. Because the source files for both DNS and NIS can be /etc style files, a distributed Berkeley Software Distribution (BSD) source area can be shared between the two services by means of symbolic links.

3.5.1    Domain Name System

The Domain Name System (DNS) is a mechanism for resolving unknown host names and Internet Protocol (IP) addresses that originate from sites on your company's intranet or the Internet.

The implementation of DNS in Tru64 UNIX is based on the Berkeley Internet Name Domain (BIND) service, which is supported by the Internet Software Consortium. BIND service is a client/server model that allows client systems to obtain host names and addresses from DNS servers.

In this hierarchical naming system, local resolver routines may resolve Internet names and addresses using a local name resolution database maintained by the named daemon. If the name requested by the host is not in the local database, the resolver routine or the local named daemon queries the remote DNS name server.

Tru64 UNIX supports BIND Version 8.2.2 (based on RFC 1034 and RFC 1035), which includes the following features:

You can use DNS to replace or supplement the host table mapping provided by the local /etc/host file or NIS. You should use NIS for all other distributed database applications.

For more information about the DNS environment, DNS planning and configuration, and DNS management, see the Network Administration: Services manual, the BIND Configuration File Guide, and the bind_intro(7) reference page.

3.5.2    Network Information Service

The Network Information Service (NIS) is a distributed name service that allows participating hosts to share access to a common set of system and network files. NIS allows system administrators to manage these shared files on a single system.

NIS is intended for use in a secure environment only, where gateways do not allow outside access from the Internet to the NIS protocol.

3.6    Time Services

Tru64 UNIX supports the following time services:

Because NTP can be traced to clocks of high absolute accuracy, it provides a more accurate time service than TSP. By contrast, TSP synchronizes time to the average of the network host times. TSP is an acceptable time service if your system is not on the Internet and does not have access to a highly accurate time server; otherwise, NTP is recommended.

3.6.1    Network Time Protocol

The Network Time Protocol (NTP) provides accurate, dependable, and synchronized time for hosts on both wide area networks (like the Internet) and local area networks. In particular, NTP provides synchronization traceable to clocks of high absolute accuracy, and avoids synchronization to clocks keeping bad time.

Hosts running NTP periodically exchange datagrams querying each other about their current estimate of the time. Using the round-trip time of the packet, a host can estimate the one-way delay to the other host. (The delay is assumed to be roughly equal in both directions.) By measuring the one-way delay and examining the timestamps that are returned with the NTP packet, a host computes the difference between its clock time and that of the host it queried.

A host queries a remote host several times over a period and feeds the results from the multiple samples to a digital-filtering algorithm. The algorithm provides a more accurate estimate of the delay, clock offset, and clock stability than could be obtained with a single sample.

NTP messages also contain information about the accuracy and reliability of the time sources. An NTP host connected directly to a highly accurate time source, such as a radio receiver tuned to a time code signal broadcast by a government agency, is called a stratum 1 server. Every other NTP host adopts a stratum number that is one higher than the host from which it sets its own time. For example, a host synchronized to a stratum 1 server becomes a stratum 2 host. Stratum determination is done automatically, and the stratum of a host can vary as its connectivity changes.

A host running NTP collects information to decide which of the hosts it queries provides the most accurate time. This information includes the output of the digital-filtering algorithm and the stratum numbers of the hosts it queried. By communicating with several other hosts, an NTP host can usually detect those hosts that are keeping bad time and can stay synchronized even if some of the other hosts become unavailable for long periods.

In practice, NTP can synchronize clocks to within a few tens of milliseconds even over wide-area networks spanning thousands of miles.

Tru64 UNIX supports NTP Version 4.

The NTP protocol is described in RFC 1305. For more information, see the Network Programmer's Guide, ntp_intro(7), and ntp_conf(4).

3.6.2    Time Synchronization Protocol

The Time Synchronization Protocol (TSP) is the protocol used by the /usr/sbin/timed daemon. In its simplest application, the TSP servers on a broadcast network (for example, an Ethernet) periodically broadcast TSP packets. The hosts on the network elect one of the hosts on the network running TSP as a master.

The master then controls the further operation of the protocol until that master fails and a new master is elected. The master collects time values from the other hosts and computes the average of all the times reported. It then sets its own clock to this average and tells the other hosts to synchronize their clocks with it.

TSP quickly synchronizes all participating hosts. However, because TSP does not trace time back to sources of known accuracy, it is unable to correct for systematic errors. If a clock drifts significantly, or if a mistake is made in setting the time on a participating host, the average time calculated and distributed by the master can be affected significantly.