Document revision date: 24 June 2002

CompaqTCP/IP Services for OpenVMS

Concepts andPlanning

AA-Q06TF-TE

This manual supersedes DIGITALTCP/IP Services for OpenVMS Concepts and Planning, Version 5.0.

Compaq TCP/IP Servicesfor OpenVMS Version 5.3

OpenVMS Alpha Version 7.2–2, 7.3;
OpenVMS VAX Version7.2, 7.3

April 2002

Compaq Computer Corporation

Houston Texas

This manual describes concepts and planningtasks to prepare you to use the Compaq TCP/IP Services for OpenVMS product.

Compaq, the Compaq logo, Alpha, OpenVMS, Tru64, VAX, VMS, andthe DIGITAL logo are trademarks of Compaq Information Technologies Group,L.P. in the U.S. and/or other countries.

Microsoft, MS-DOS, Visual C++, Windows, and Windows NT are trademarks of Microsoft Corporation in the U.S. and/or other countries.

Intel,Intel Inside, and Pentium are trademarks of Intel Corporation in the U.S.and/or other countries.

Motif, OSF/1, and UNIX are trademarks of The Open Group in theU.S. and/or other countries.

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and other countries.

Allother product names mentioned herein may be trademarks of their respectivecompanies.

Confidential computer software. Valid license from Compaq requiredfor possession, use, or copying. Consistent with FAR 12.211 and 12.212, CommercialComputer Software, Computer Software Documentation, and Technical Data forCommercial Items are licensed to the U.S. Government under vendor’sstandard commercial license.

Compaq shall not be liable for technical or editorial errors oromissions contained herein. The information in this document is provided "asis" without warranty of any kind and is subject to change without notice.The warranties for Compaq products are set forth in the express limited warrantystatements accompanying such products. Nothing herein should be construedas constituting an additional warranty.

ZK6523

The Compaq OpenVMS documentation set is available on CD-ROM.

Contents

Compaq TCP/IP Services for OpenVMS

Reader’sComments

Compaq welcomes your comments on this manual.Please send comments to either of the following addresses:

Internet: openvmsdoc@compaq.com

Mail: Compaq Computer Corporation

OSSG Documentation Group, ZKO3-4/U08

110 Spit Brook Rd.

Nashua, NH 03062-2698

How to Order Additional Documentation

Visitthe following World Wide Web address for information about how to order additionaldocumentation:

http://www.openvms.compaq.com

Conventions

Thefollowing conventions are used in this manual:

Ctrl/ x

Indicates that you must hold down the key labeledCtrl while you press another key or a pointing device button.

PF1x

A sequence such as PF1x indicatesthat you must first press and release the key labeled PF1 and then pressand release another key or a pointing device button.

[Return]

In an example, a key name enclosed in a box indicatesthat you press that key.

…

A horizontal ellipsis in examples indicates oneof the following possibilities:

• Additional optional argumentsin a statement have been omitted.

• The preceding item or items can berepeated one or more times.

• Additional parameters, values, orother information can be entered.

⋮

A vertical ellipsis indicates the omission of items from a code example orcommand format; the items are omitted because they are not important to thetopic being discussed.

( )

In command format descriptions, parentheses indicate that you must enclose choices in parentheses if you specify more than one.

[ ]

In command format descriptions, brackets indicateoptional choices. You can choose one or more items or no items. Do not typethe brackets on the command line. However, you must include the bracketsin the syntax for OpenVMS directory specifications and for a substring specificationin an assignment statement.

In command format descriptions, vertical barsseparate choices within brackets or braces. Within brackets, the choicesare optional; within braces, at least one choice is required. Do not typethe vertical bars on the command line.

{ }

In command format descriptions, braces indicaterequired choices; you must choose at least one of the items listed. Do nottype the braces on the command line.

Type

This typeface represents the introduction of anew term. It also represents the name of an argument, an attribute, or areason.

italics

Italic text indicates important information, completetitles of manuals, or variables. Variables include information that variesin system output (Internal error number),in command lines (/PRODUCER=name), and in command parameters in text (where (dd)represents the predefined par code for the device type).UPPERCASE TEXT

Uppercase text indicates a command, the name ofa routine, the name of a file, or the abbreviation for a system privilege.

Monospace text

Monospacetype indicates code examples and interactive screen displays.

In the C programming language, monospace typein text identifies the following elements: keywords, the names of independentlycompiled external functions and files, syntax summaries, and references tovariables or identifiers introduced in an example.

–

A hyphen at the end of a command format description,command line, or code line indicates that the command or statement continueson the following line.

numbers

All numbers in text are assumed to be decimalunless otherwise noted. Nondecimal radixes—binary, octal, or hexadecimal—areexplicitly indicated.

1 Introducing Compaq TCP/IP Services for OpenVMS

TheCompaq TCP/IP Services for OpenVMS product is the OpenVMS implementation ofthe industry-standard TCP/IP suite of communications protocols. With TCP/IPServices, users, administrators, and programmers can perform tasks from anywherein the network, such as:

• Network file access: accessing fileson remote hosts

• Sending e-mail: exchanging messagesbetween hosts

• Application development: developingTCP/IP applications for communication between local and remote hosts

• File transfer: exchanging files betweenhosts

• Accessing user information: accessinginformation about other users logged onto local or remote hosts

• Remote management: managing and monitoringthe network and applications from remote hosts

• TELNET: logging on to a remotehost

• Remote command execution: issuingcommands to remote hosts

• Remote printing: sending print jobsto a remote printer, and receiving print jobs from a remote host

• Networking booting: providing bootservice for a remote host

Users can perform internetworking tasks seamlesslywithout worrying about the hardware details of each individual network. TheTCP/IP Services provides interoperability and resource sharing between OpenVMSsystems, UNIX systems, and other systems that support the TCP/IP protocolsuite and Sun Microsystems Network File System (NFS). Internet hosts sharedata and resources by using standard TCP/IP protocols over a number of networkhardware configurations including Ethernet, Fiber Distributed Data Interface(FDDI), Token Ring, and asynchronous transfer mode (ATM).

This chapter discusses the following topics. Moredetails about these topics are provided elsewhere in this manual and in otherCompaq TCP/IP Services for OpenVMS and OpenVMS documentation set manuals.

• Overview of TCP/IP Services

• Other Compaq OpenVMS products thatrequire TCP/IP

• Application programming interfaces(APIs)

• Requests for Comments (RFCs)

1.1 Overview of TCP/IP Services

TCP/IPServices provides support for several protocols at every level of the TCP/IPmodel’s protocol layers.

• Data Link layer

• Internet layer

• Transport layer

• Application layerFigure1–1 shows the various layers and protocols of the TCP/IP model. A descriptionof each layer and protocol follows the figure.

Figure 1–1 The TCP/IP Model

$Q:\ati-artlib\gif\vm-0402a.gif$

1.1.1 Data Link Layer

At the base of the TCP/IP layers, the Data Linklayer formats data and provides services that directly access the physicalnetwork.

This layer also receives data that is routed fromthe Internet layer and transmits the data to its destination, converting logicalIP addresses to physical addressesof the network adapter or network interface cards (NICs) usingthe Address Resolution Protocol (ARP).

Some commonly used network architectures designedfor the physical network are Ethernet and its variants, Token Ring, FDDI,and ATM .

Asingle host computer can have multiple NICs. This configuration is termeda multihomed host.Depending on your network setup, the Data Link layer’s configurationmay vary. For more information, see Chapter 3.

1.1.2 InternetLayer

The Internet layer moves data around the internet.The Internet Protocol uses addressing to deliver and route packetsacross networks independently of the network cabling.

Atthis level, the protocols are:

• Internet Protocol (IP)

• Internet Control Message Protocol(ICMP)

• Address Resolution Protocol (ARP)

Theprotocol also encapsulates datagram headers, sends ICMP error and controlmessages, and maps ARP address conversions.

Routing protocols at this layer are:

• Routing Information Protocol (RIP)Versions 1 and 2

• Open Shortest Path First (OSPF) Version2

• Exterior Gateway Protocol (EGP)

• Border Gateway Protocol (BGP)

• Router DiscoveryFormore information about these protocols, see Chapter 5.

1.1.3 TransportLayer

The Transport layer enables a flow of data betweentwo hosts. The protocols at this layer are either connectionoriented , in whichthe protocol establishes and maintains the connection between communicatinghosts to prevent errors, or connectionless, in which a one-way datagram is sent to a destinationhost.

The TCP/IP Services supports both transport protocols:

• Theconnection-oriented protocol, Transmission Control Protocol (TCP) providesa reliable data flow between two hosts. TCP is used for complex, large packetsthat have an IP address.

• Theconnectionless protocol, User Datagram Protocol (UDP) provides a much simplerservice to the Application layer than TCP but does not guarantee reliability.UDP is used for simple, small packets and requests for dynamic IP addressassignment. UDP packets have a MAC address.

1.1.4 ApplicationLayer

The top layer of the TCP/IP protocol suite, theApplication layer handles the details of the particular application, protocol,or user command; it is not concerned with the movement of data across thenetwork.

TCP/IP Services supports the following TCP/IP applications,protocols, and user services:

Remote Computing Services

Remotecomputing applications enable networked users to run software on remote systems.TCP/IP Services include the following remote computing application components:

• TELNET enablesremote login to other hosts in the network. Compaq TCP/IP Services providessimultaneous multiple sessions, IBM3270 terminal emulation (TN3270) and twointerface formats: DCL style and UNIX style.

• Remote, or R, commands are use for the following:

– RLOGIN for remote login

– RSH for remote shell capabilities

– REXEC to execute commands to a remotehost

– RMT/RCD to read magnetic tapes orCD-ROMs from remote hosts

• XDM is a network-based graphics window system based on theclient/server application model. It enables a system to display informationoutput from an application that is running on another system in the network.

• The FINGER utility is used to display userinformation for the network.

File Transfer Services

TCP/IPServices includes the following components that let users transfer data filesbetween local and remote hosts:

File Transfer Protocol (FTP) transfersfiles between hosts.

Trivial File Transfer Protocol (TFTP) downloadsand transfers files. Compaq TCP/IP Services supports downloading of systemimage and other information to client hosts.

ResourceServices

Line printer/line printer daemon (LPR/LPD) providesprinting services to local and remote hosts.

TELNET print symbiont (TELNETSYM) provides remote printing servicesthat enable OpenVMS printing features not available with the LPR/LPD printservice. Network File System (NFS) is a protocol that allows computersto access remote files as if they were local files, regardless of operatingsystem, hardware type, or architectural differences between the local andremote systems. This is accomplished in a client/server environment wherespecific implementations on NFS exist on both the client and server machines.PC-NFS is a daemon that enables accessto the NFS server from a PC by providing authentication services to PC-NFSclients.

ElectronicMail Services

Communication functions such a electronic mailare vital both within an organizational internet and across the Internet worldwide.The electronic mail components of TCP/IP Services are:

SimpleMail Transfer Protocol (SMTP) is the TCP/IP standard protocol for transferring electronicmail messages from one system to another.

IMAP is the Internet Message AccessProtocol. IMAP enables clients to access email messages and folders from anIMAP server and synchronize them locally. This enables a client to organizeemail messages and folders without continuous access to the server.

Post Office Protocol (POP) is a mail repository used primarilyby PCs.

1.2 Application Support

Beyond the industry-standardTCP/IP application services, TCP/IP Services provides support for the followingCompaq products:

• PATHWORKS or Advanced Server

• DECnet-Plus

1.2.1 PATHWORKS and DECnet-over-TCP/IP Support

TheCompaq TCP/IP Services for OpenVMS software includes the PWIP driver and the PWIPACP networkancillary control process (ACP).The PWIP driver enables communication between OpenVMS systems running bothPATHWORKS server and TCP/IP Services software, and personal computers runningPATHWORKS client software. It also enables the DECnet-over-TCP/IP feature,which is included with the DECnet-Plus for OpenVMS Version 6.0 and later software.For more information, see Chapter 7.

1.3 APIs

Networkapplications specific to the Compaq TCP/IP Services can use the followingapplication programming interfaces (APIs):

• Berkeley Sockets Interface

• OpenVMS QIO System Services interface

• ONC RPC programming interface

• SNMP programming interface1.3.1 Berkeley Sockets Interface

Socketshave become a popular programming interface. The Berkeley Sockets Interfaceis a programming interface that provides applications with access to networkcommunication protocols. A socket is a generalized UNIX communication endpoint on which the TCP/IP protocolshave been implemented. Using the socket programming interface makes it easyto implement network applications.

OpenVMS provides support for the socket interfacethrough the C programming language and the Compaq C Run-Time Library. Thebenefits of using the socket interface on the OpenVMS platform include:

• Ease of porting network applicationsfrom other platforms to the OpenVMS platform. A sockets interface can be generic.

• Many application developers are familiarwith the programming environment.

• In addition to the TCP/IP protocols,there are options for other types of protocols.

Formore details, refer to the Compaq TCP/IPServices for OpenVMS Sockets API and System Services Programming manual.

1.3.2 OpenVMS QIO System Service InterfaceThestandard I/O programming interface on OpenVMS uses the QIO (queue input/output)system services. QIO services provide a rich set of functions for controllingdevices, and connections and for performing input (read) and output (write)operations.

The benefits of using the OpenVMS QIO interfaceinclude:

• Support for the QIO interface in thefollowing programming languages:

MACRO-32

Compaq C

Compaq Fortran

Compaq Ada

Compaq and VAX BASIC

VAX BLISS-32

Compaq COBOL

VAX Pascal

Compaq PL/1

• Ability to handle complex applicationswith many concurrent connections.

• Efficient input/output operations.

• Robust asynchronous event handling.(While sockets offer the ability to do nonblocking I/O operations, they donot offer the ability to perform asynchronous I/O.)

• Ease of DECnet applicationsportability to TCP/IP protocols.

For more details, refer to the CompaqTCP/IP Services for OpenVMS Sockets API and System Services Programming manual.

SRIQIO Compatibility

TCP/IP Services provides support for customer applicationsusing the INETDRIVER QIO interface developed at Stanford Research Institute(SRI) in 1980-81. An SRI QIO emulator that translates non-TCP/IP ServicesQIO interfaces into TCP/IP Services QIO programming interfaces can be configuredby using the TCPIP$CONFIG procedure.

1.3.3 ONC RPC Programming Interface

TheRPC programming interface is an industry-standard, portable API that is anefficient alternative to using sockets for application development. Programmersdo not need an in-depth knowledge of networking protocols to use RPC.

Onestrong point of the RPC interface is its ability to distribute functions acrossthe network. This is done in an architecture-independent manner, thereby avoidingproblems with floating-point formats and byte-address ordering that oftenoccur when interacting between architectures.

ThisAPI includes:

• Library of RPC function calls.

• Portmapper service, which is a service that clientprograms can use to determine the port number that another service uses. Clientsuse the Portmapper Service for NFC, PC-NFS, and RPC applications.

• External data representation (XDR)routines.

For more details, refer to the CompaqTCP/IP Service ONC RPC Programming manual.

1.3.4 SNMPProgramming Interface

The Extensible Simple Network Management Protocol(eSNMP) API provides routines for developing applications that remotely manageand collect data from network devices such as routers, bridges, and hosts.

Thesenetwork devices run software that carries out management commands that eitherget information from devices or set operating parameters for devices.Othernetwork applications send commands to network devices to perform configurationmanagement, monitor network traffic, or troubleshoot network problems.TheSNMP API provides routines for the following functions:

• Establish, maintain, and terminatecommunication with the master agent

• Manipulate, reformat, extract, andcompare data

• Control information that is writtento log files

The SNMP API routines are almost identical in functionand interface with the routines in the Compaq Tru64 UNIXAPI.

For more details, refer to the CompaqTCP/IP Services for OpenVMS SNMP Programming and Reference manual.

1.4 UnderstandingRFCs

Although TCP/IP is monitored by a number of organizations,no single entity owns this protocol; its specifications are publicly availableand are constantly growing as communications requirements evolve.

Theprocess by which the specifications evolve is through a mechanism called Requestsfor Comments (RFCs). When someone has an idea for a new or improved capabilityfor TCP/IP, he or she writes a proposal, posts it on the Internet as an Internetdraft, and requests comments from the networking community. After a reviewand revision cycle, working code is developed and an RFC becomes a standardprotocol.

RFCs are available on the Internet from the InternetNetwork Information Center (InterNIC). The following web site provides linksto several RFC international repositories, lists all RFCs, and explains howyou can obtain copies:

http://www.rfc-editor.org

Notethat, although RFCs recommend implementation guidelines, the actual implementationof an RFC can and must differ from the RFC in minor ways. When product documentationrefers to specific RFCs, be aware that the RFC only sets the standard fordevelopment. Product developers must design their software for the specificenvironment and requirements of their customers.

2 Understanding OpenVMS and UNIX Implementations

An important step in planninga network host implementation is to gain an understanding of the computingenvironments in which the network services will run. Compaq Tru64 UNIXimplementations of TCP/IP Services are often ported to OpenVMS. As a result,they often appear to be identical. However, there are many significant differences.This chapter describes key implementation differences between UNIX and OpenVMSnetworks. The following topics are discussed:

• Evaluating the computing environment

• File compatibility

• Portability

• Determining which file systemto use

Things to Consider

In planning your TCP/IP Services environment, considerthe following:

• Do I need to migrate from one operatingsystem to the other?

• Do I need to set up a system thatcoexists with multiple operating systems?

• Should I choose a Files–11file system or a container file system?

2.1 Evaluating the Computing Environment

Theissues of working in a heterogeneous computing environment that includes OpenVMSand Tru64 UNIX operating systems are complex. Consider these concepts whenevaluating or implementing an interoperability strategy:

• Migration occurs when software applicationsare rewritten as necessary to be ported from one operating system to the other.In a general sense, not only the applications but also the users migrate toanother system. Migration implies a gradual replacement of the original systemwith the new system.

• Coexistence occurs when two or more systems,such as OpenVMS and Tru64 UNIX, are maintained as part of a larger, heterogeneouscomputing environment. The amount of interoperability varies with the individualconfigurations. It is possible to set up nearly identical network configurations,thereby reducing maintenance.

2.1.1 Understandingthe Open Systems Concept

The client/server model of computing means thatusers running applications on their PCs and workstations are networked withlarger departmental systems. The departmental systems provide a variety ofservices to the clients, such as access to common database, print, and backup/archiveservices.

To best serve this model of computing, the systemsmust be open. Open environments support interoperability and application portabilityand enable developers and users to easily use different platforms. The OpenVMSoperating system is an open system with an extensive list of functions.

Anopen system allows the OpenVMS operating system, whether powered by Alphaor VAX, to interoperate efficiently with Compaq Tru64 UNIX and with othervendors’ operating systems, particularly with Windows NT and other UNIXoperating systems.

2.1.2 Understandingthe Middleware Concept

Implementing open systems means using the right middleware betweenthe operating system and the hardware platform and applications. Consistentmiddleware affords interoperability and portability when and where it is needed.An open systems strategy involves a consistent middleware approach that isbased on standards and is embodied in layered software and in individual operatingsystems, such as OpenVMS and UNIX. Compaq DCE is an example of middleware, with standard interfacessupported on both OpenVMS and UNIX. Compaq DCE, or Distributed ComputingEnvironment, is an architecture of standard programming interfaces, conventions,and server functions that transparently distributes applications across heterogeneousnetworks.

As shown in Figure 2-1, OpenVMS and UNIX interoperateefficiently, especially in areas that are common to both platforms: windowinginterface, standard POSIX and DCE programming interfaces, compilers, networkingproducts, and applications.

Figure 2–1 Comparisonof OpenVMS and UNIX

$Q:\ati-artlib\gif\vm-0896a.gif$

2.2 File Compatibility

The Network File System, or (NFS) provides a standardfor the exchange of data between machines running different operating systems.NFS enables users to access directories and files on remote computers transparently,as if they were on the local system. NFS accomplishes this because it is implementedon the both the remote and the local computer.

NFSprotocol achieves portability between different machines, operating systems,network architectures, and transport protocols through the use of Remote ProcedureCall (RPC) and External DataRepresentation (XDR). Formore information about RPCs and XDR, refer to the CompaqTCP/IP Services for OpenVMS ONC RPC Programming manual.

UsingNFS is simple. Configuring and implementing NFS, however, are more complex.For NFS concepts and considerations, as well as detailed configuration andimplementation information, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

TCP/IPServices accommodates the numerous key differences between UNIX and OpenVMSto make user interaction between the two operating systems appear transparent.This enables all systems on a heterogeneous network to store and share filesand applications regardless of file specification and structure differences.

Thissection discusses:

• Directory hierarchies

• File specifications

• Linking files

• File structures

• File ownership

• File protection

• UNIX style file system on TCP/IP Serviceshosts

2.2.1 DirectoryHierarchies

Unlike OpenVMS, the UNIX hierarchy appears as onetree (starting from the root directory, or “/”) that can be locatedon more than one device. Table 2-1 describes the differences between the OpenVMSand Tru64 UNIX directory hierarchies.

Table 2–1 DirectoryHierarchy Differences

OpenVMS	UNIX
Resideon one volume having one root above all directories on the volume.	Canreside on multiple volumes.
Devicenames included in file specifications.	Devicenames not included in file specifications.

Figure 2-2 illustrates the differences betweena UNIX file structure and an OpenVMS file structure.

Figure 2–2 Comparison of UNIX Directory and OpenVMS Directory Hierarchies

2.2.2 FileSpecifications

There are basic differences between OpenVMS andUNIX file specifications. Table 2–2 summarizes the differences.

Table 2–2 File Specification Differences

OpenVMS

UNIX

Filesare delimited in the following way:

• A colon (:) separates the device fromthe directory.

• Square brackets ([ ]) or angle brackets(< >) enclose the directory and any subdirectories.

• A period (.) separates directoriesfrom subdirectories and separates the file name from the file type.

• A semicolon (;) or period (.) separatesthe file type from the version number.

The ODS-5 file system implements extended filespecifications and is a step toward improving interoperability. ODS-5 is describedlater in this chapter.

For complete details about the ODS-5 file specification,refer to the OpenVMS product documentation.

Theslash (/) is the only delimiter that the UNIX file specification format uses.

Thefirst slash in a UNIX file specification represents the root directory. Subsequentslashes separate each element of the file specification (the directories fromthe other directories and the file name). In theory, there is no limit tothe number of directory levels in a UNIX file specification.

OpenVMS file specification format

Ona standard Files-11 On-Disk Structure Level 2 (ODS-2) volume,an OpenVMS file specification has the following format:

device:[directory.subdirectory]filename.type;version

UNIX file specification format

Ona UNIX system, the file specification has the following format:/directory/subdirectory/filename 2.2.3 Absoluteand Relative File Specifications

OpenVMS and UNIX both have two types of file specificationsor pathnames: absolute and relative. Table 2–3 describes the differencesbetween the two platforms.

Table 2–3 Absoluteand Relative File Specification Differences

OpenVMS

UNIX

Therelative path for file calc;1 indirectory usr:[jones] is:

[.accounting.calc;1]Theabsolute path is:

usr:[jones.accounting.calc;1]

Therelative pathname for file calc indirectory /usr/jones is

accounting/calcTheabsolute pathname is

/usr/jones/accounting/calc

On UNIX systems, absolute pathnames use the entiredirectory path that leads to the file, beginning with the root, which is representedby an initial slash.

The root directory is the first directory in thefile system. All other files and directories trace their ancestry back tothe root. Relative pathnames begin the directory path with the current workingdirectory and exclude the current working directory name in the pathname.There is no initial slash in a relative pathname.

2.2.4 File Specifications

There are fundamental differences between filenames specified in OpenVMS and in UNIX. Table 2–4 describes those differences.

Table 2–4 File Specification Differences

OpenVMS(ODS-2)

UNIX

Includes,in this order:

1. the file name

2. the file type

3. an optional version number

An OpenVMSfile specification can have a maximum of 255 characters.

Thefile name and file type can have up to 39 characters each and are separatedby a period. For example:

FILE_NAME.TXT;1

Valid characters in an OpenVMS file name or typeinclude: A–Z, a–z, 0–9, underscore (_), hyphen (-), anddollar sign ($). The version number (preceded by a semicolon) is a decimalnumber from 1 to 32767; it differentiates versions of the same file.

Containsup to 1024 characters, with each element of the pathname containing up to255 characters. UNIX file specifications have the following format:

file_name.txtSomeolder versions of the UNIX operating system limit the size of one elementto 14 characters, or have other limits that you can change if you recompilethe kernel.

Intheory, you can use any ASCII character in a UNIX pathname except for theslash (/) and null characters. For example, a valid file name in UNIX canbe:

report.from.january_24

However,avoid characters (such as the pipe (|) character) that can have special meaningto the UNIX shell.

2.2.5 Case Sensitivity

Case sensitivity differs between the two operatingsystems. Table 2–5 describes the difference.

Table 2–5 Case-Sensitivity Differences

OpenVMS(ODS-2)

UNIX

Storeseverything in uppercase. For example, any case variations of the followingfile name is stored in uppercase: CHAPTER_ONE.TXT;1

Regardsuppercase and lowercase characters as different characters.

Forexample, on a UNIX system, the following file names represent three differentfiles:

• CHAPTER_ONE.TXT

• Chapter_One.Txt

• chapter_one.txt

2.2.6 File Types

Table 2–6 describes the file type differencesbetween OpenVMS and UNIX.

Table 2–6 FileType Differences

OpenVMS	UNIX
Importantin OpenVMS file identification The file type usually describes the kind of datain the file.	UNIXsystems do not use file types. However, UNIX has certain naming conventionsthat resemble OpenVMS file types.
Forexample, a text file typically has a file type of .TXT. AllOpenVMS directories have a file type of .DIR.	Forexample, file names ending in txt aretext files. UNIXdirectories do not have file types.

2.2.7 VersionNumbers

Table 2–7 describes file version number differencesbetween OpenVMS and UNIX.

Table 2–7 VersionNumber Differences

OpenVMS	UNIX
Everyfile has a version number. When a file is created, the system assigns it aversion number of 1. Subsequently, when a file is edited or when subsequentversions of that file are created, the version number automatically increasesby 1. Therefore, many versions of a file with the same file name can existin the same directory.	TheUNIX file system does not support automatic creation of multiple versions.In most cases, if you edit a UNIX file, the system saves only the most recentlyedited copy.
Forexample: FILE_NAME.TXT;1 FILE_NAME.TXT;2 FILE_NAME.TXT;3	Forexample: file_name.txt

2.2.8 Linking Files

A link is a directory entry that refers to a fileor another directory. Table 2–8 describes the differences between OpenVMSand UNIX file linking.

Table 2–8 LinkFiles Differences

OpenVMS	UNIX
Filescan exist without links.	Filescannot exist without links.
HardLinks OpenVMSsystems allows you to perform a function similar to hard links with the SETFILE/ENTER and SET FILE/REMOVE commands. The OpenVMS operating system does not maintaina count of links to a file. As a result, you can delete a file without deletingits links.	HardLinks Hardlinks allow users to share the same file under different pathnames. A hardlink cannot span file systems. On UNIX systems, any changes to the file are independentof the link used to refer to the file. The UNIX system maintains a count ofthe number of links to each file. If removing a link results in the link countbecoming zero, the file is deleted. A file can be deleted only by removingall of its links.
SymbolicLinks OpenVMSfile systems do not support symbolic links.	Symbolic Links A symbolic link is a file that contains the nameof the file to which it is connected. Symbolic links provide a path to theoriginal file. A UNIX symbolic link can span file systems. Unlikea hard link, a symbolic link does not maintain a link count. In addition,symbolic links can exist after the file is deleted. However, the system returnsan error if the symbolic link file is accessed after the file it names isdeleted.

2.2.9 FileStructures

Table 2–9 describes the differences betweenthe OpenVMS and UNIX file structures.

Table 2–9 FileStructure Differences

OpenVMS	UNIX
Supportsthree file structures: indexed, relative, and sequential. OpenVMS also supportsthe following record formats and record attributes: • Fixedlength • Variable length • Variable with fixed-length control(VFC) • Stream (including STREAM_LF and STREAM_CR) • Undefined • Carriage return/carriage control • Fortran carriage control • VFC carriage control	Supportsbyte streams only. The records in UNIX text files have the same formatas the OpenVMS Record Management Services (RMS) STREAM_LF record format.

2.2.10 FileOwnership

The OpenVMS and UNIX operating systems use differentmechanisms for file ownership. Table 2–10 describes those differences.

Table 2–10 File Ownership Differences

OpenVMS

UNIX

TheOpenVMS operating system controls file ownership and access through a useridentification code (UIC). A UIC is a 32-bit value that consists of a 14-bitgroup number, a 16-bit member number, and 2 reserved bits. Each user of thesystem has a UIC defined in the SYSUAF file. Access to objects depends onthe relationship between the UIC of the accessing process and the UIC of theobject (the file or directory).

OpenVMS controls file access through an accesscontrol list (ACL). You candeny or grant read, write, execute, delete, and control access to a user orgroup of users who have the identifier specified by the ACL. For additionalACL information, refer to the OpenVMS documentation set.

The NFS protocol does not provide ACL support. Therefore,the NFS client is unaware of ACLs that the NFS server applies to the file.Consequently, the NFS client cannot use an ACL to control file access. Accesscontrol is determined through standard file protections. For more information,see Chapter 2.

TheUNIX operating system controls access to files with user identification (UID)and group identification (GID). Tru64 UNIX uses 32-bit UIDs and GIDs. Forcompatibility, NFS also recognizes 32–bit UIDs and GIDs.

2.2.11 FileProtections

The OpenVMS and UNIX operating systems use similarfile protection schemes, as shown in Table 2–11.

Table 2–11 Comparison of File Protection

Mechanism

OpenVMS

UNIX

Userclassifications

SYSTEM(S)

OWNER(O)

GROUP(G)

WORLD(W)

Classificationdepends on the relationship between the UIC of the accessing process and theobject.

user(u) --- The user has a matching UID

group (g)

--- The user has a matching GID

other (o)

--- Any other user

System categoryis not used; system administrators always have access to UNIX files.

Protectionlevels

READ(R)

WRITE(W)

EXECUTE(E) – Controls file execution and directory search access

DELETE(D)

read(r) — The user has a matchingUIC

write(w) — Controls unlinking filesto the directory.

execute (x) — Controlsfile execution and directory search access

A file is deleted if it is unlinked from the directoryand had no links in other directories. Write access to the directory is refused.

Syntax

s:rwed,o:rwed, g:rwed, w:rwed

rwxrwxrwx

Theprotection levels are divided into groups of three characters:

• First three characters: protectionlevels for the owner.

• Second three characters: protectionlevels for the group.

• Last three characters: protectionlevels for all other users.

2.3 Portability

The TCP/IP Services allows you to create a logicalUNIX style file system on an OpenVMS host. Remote UNIX hosts that have NFSsoftware can then access this file system. When a remote UNIX system accessesfiles, these files conform to UNIX file system rules, not to the OpenVMS rules.This ensures that existing UNIX applications work without change. The logicalUNIX file system resides on a Files-11 formatted disk and is represented asa set of Files-11 files called a container file system. For information about creatinga UNIX file system on an OpenVMS host, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

TheUNIX file names and attributes are catalogued in the container file, one ofthe files in the container file system. The container file also has a representationof the UNIX directory hierarchy and a pointer to the data file for each filename. In addition to its UNIX name, each file in the container file systemhas a valid Files-11 file name assigned by the system. An OpenVMS directoryexists for each UNIX directory stored in the container file. All files cataloguedin a UNIX directory are also catalogued in the corresponding OpenVMS directory.However, the UNIX directory hierarchy is not duplicated in the OpenVMS directoryhierarchy. Each UNIX file is represented as an OpenVMS data file. Therefore,OpenVMS utilities, such as BACKUP, can use standard methods to access thesefiles.

2.4 Determining Which File System to Use

Thefirst step in managing your TCP/IP Services system is to decide which filesystem to use. NFS on OpenVMS enables you to set up and export three differentkinds of file systems:

• OpenVMS On-Disk Structure(ODS-2) file system ,in which devices, directories, and files are stored on a Files-11 formatteddisk

• OpenVMS On-Disk Structure(ODS-5) file system ,which enables creation and storage of files with extended file names for compatibilitywith other file systems, such as Windows.

• UNIX, or container, file system,built on top of an OpenVMS system. If you are not familiar with OpenVMS filesystems, refer to the OpenVMS System Manager’sManual: Essentials to learn how to set up and initialize a Files-11disk. As Figure 2–2 shows, both file systems are structured as hierarchical,multilevel directories. On OpenVMS systems, the top level is called the master file directory, or MFD. This directory contains all the directories and reservedsystem files. The directory is named [000000]. On UNIX systems, the top-leveldirectory is called the root, or / .

Table 2–12 lists the NFS server featuresavailable to non-OpenVMS clients based on file system choice.

Table 2–12 NFS Server Features Available to Non-OpenVMS Clients

Features

ODS-2

OD2–2with name conversion

ODS-5

Containerfile system

Fileseasily shared between remote clients and local OpenVMS users

Yes

Mixedcase, special characters, and extra dots in file names

Yes

Longfile names

Yes

Filenames look the same to remote clients and local OpenVMS users

Uppercaseto local users, lowercase to remote clients

Yes

N/A

Supportfor hard links, symbolic links, special files

Yes

UNIXcompatible timestamps

Yes

Case-sensitivelookup

N/A

Yes

The dual cataloguing of files to both OpenVMS filesystems limits the set of DCL commands. OpenVMS utilities, such as BACKUP,can use standard methods to access the files. However, except for backingup and restoring files, you should not use DCL commands to manipulate filesin a container file system.

DecisionPoint

Your file system choice depends on your environmentand the user needs on the NFS client host. Consider using an OpenVMS filesystem if:

• Your users share most files betweenyour OpenVMS system and another OpenVMS host, or between your OpenVMS systemand a UNIX client.

• Your client users need to maintainmultiple versions of files.

• You share files between users on OpenVMSand users on NFS clients.

• File sharing between your OpenVMSsystem and a UNIX client is minimal.

• Client applications use symbolicor hard links or special files.

For More Information

Formore information about the following topics, refer to the CompaqTCP/IP Services for OpenVMS Management manual:

• Setting up container file systems

• Configuring and implementing the NFSserver

For a list of commonly used Tru64 UNIX commandsand their equivalents on OpenVMS, refer to the CompaqTCP/IP Services for OpenVMS Tuning and Troubleshooting manual.

Formore details about interoperability between UNIX and OpenVMS, refer to the OpenVMS and Compaq UNIX Interoperability and MigrationGuide. This guide discusses products and services, available both fromCompaq and from other vendors, that might provide solutions to interoperabilityproblems.

For more information about RPCs and XDR, referto the Compaq TCP/IP Services for OpenVMSONC RPC Programming manual.

For additional ACL information, refer to the OpenVMSdocumentation set.

3 OpenVMSServer and Network Configurations

There are several server and network configurationsto consider before installing TCP/IP Services for OpenVMS. This chapter describesthe following concepts that will enable you to make informed decisions aboutthese configuration options:

• OpenVMS VAX and Alpha similaritiesand differences

• Cluster environments

• Multiple interfaces and multihoming

• Pseudointerfaces

• Serial lines

$Q:\adept8\entities\note.eps$ Note

VAX development has limited continued support.VAX users should consider migrating to Alpha, if possible.

Thingsto Consider

In planning your TCP/IP Services for OpenVMS configurations,consider the following:

• Does the network contain VAX or Alphasystems, or both?

• Is my system running a DHCP server?

• Is my system running a DHCP client?

• How many interfaces does the systemhave?

• Do I have serial lines in my network?If so, for which systems are they used?

3.1 Understanding OpenVMS VAX and Alpha Systems

Youneed to consider several issues when you plan to add one or more OpenVMS Alphasystems to your OpenVMS VAX computing environment. For full details aboutthe similarities and differences between OpenVMS Alpha and OpenVMS VAX, referto the OpenVMS Compatibility Between VAXand Alpha guide, which is available on line at:

http://www.openvms.compaq.com/doc

3.1.1 User Environment

The user environment on OpenVMS Alpha is virtuallythe same as that on OpenVMS VAX. Table 3–1 describes the similaritiesand differences.

Table 3–1 OpenVMSVAX and OpenVMS Alpha Similarities and Differences

ComponentSimilarities

OpenVMSVAX Differences

OpenVMSAlpha Differences

DIGITALCommand Language (DCL)

Essentially the same on both systems.

None

Referto the few exceptions in the OpenVMS CompatibilityBetween VAX and Alpha guides available on line.

DCLHelp

MostDCL help text is common to both systems.

System-specificinformation is identified by the phrase “On VAX.”

System-specificinformation is identified by the phrase “On Alpha.”

DCLcommand procedures

Most DCL command procedures, with commands, qualifiers,and lexical functions, work on both systems.

None

Afew command procedures contain qualifiers not available on OpenVMS Alpha.

Databases

Standarddatabases, such as Oracle Rdb, function the same on both systems.

None

Mostthird-party databases available for OpenVMS VAX are also available for OpenVMSAlpha.

Formore information, refer to the OpenVMS CompatibilityBetween VAX and Alpha guide, available on line.

3.1.2 System Management Environment

MostOpenVMS VAX system management utilities, command formats, and tasks are identicalon OpenVMS Alpha, with the following exceptions:

• On VAX, use of the POLYCENTER SoftwareInstallation utility is limited to the installation of layered products, suchas Compaq TCP/IP Services for OpenVMS.

• On Alpha, the POLYCENTER SoftwareInstallation utility is also used to install both the OpenVMS operating systemand layered products.

For more information about implementation differencesbetween OpenVMS VAX and OpenVMS Alpha, refer to the OpenVMSSystem Manager’s Manual.

3.1.3 ProgrammingEnvironment

The same types of programming development toolsthat OpenVMS VAX programmers use are available on OpenVMS Alpha systems, suchas the Linker utility, the Librarian utility, the OpenVMS Debugger (also knownas the symbolic debugger), the Delta/XDelta Debugger, and run-time libraries.However, some TCP/IP Services components are available only on OpenVMS Alpha,including:

• BIND Version 9

• IMAP

• PPP

These components are introduced later in this manual.

Fordetails about the similarities and differences between the programming environmenton VAX and Alpha, refer to A Comparison ofSystem Management on OpenVMS AXP and OpenVMS VAX, which provides guidelinesfor developing applications that run on both OpenVMS VAX and OpenVMS Alpha,as well as additional guidelines for systems that run in a mixed-architectureOpenVMS Cluster.

3.2 OpenVMSCluster Configuration

Compaq TCP/IP Services for OpenVMS supports OpenVMSCluster systems and the use of cluster aliases. The network sees the clusteras one system with one name, the cluster alias. A remote host can use the cluster alias to addressthe cluster as one host, or it can use the host name of a cluster member toaddress a cluster member individually.

In a DECnet network, it is convenient to be ableto treat nodes within a homogeneous OpenVMS Cluster as though they were asingle node. You can do this by establishing an alias nodeidentifier for thecluster. You can specify the alias node identifier as either a unique nodeaddress or a corresponding node name. Any member node can elect to use thisspecial node identifier as an alias while retaining its own unique node identification.For more information on the use of the optional cluster alias node identifier,refer to the DECnet for OpenVMS NetworkingManual.

$Q:\adept8\entities\note.eps$ Note

DECnet–Plus software is not required in anOpenVMS Cluster configuration. However, DECnet–Plus is necessary ifinternode process-to-process communication using DECnet mailboxes is needed.For more information about DECnet-Plus in an OpenVMS Cluster configuration,refer to the Guidelines for OpenVMS ClusterConfigurations manual.

For load balancing, anOpenVMS Cluster can consist entirely of OpenVMS Alpha nodes or of a combinationof OpenVMS VAX and OpenVMS Alpha nodes.

You can have numerous OpenVMS Cluster configurations.For complete information about supported devices and configurations, referto Guidelines for OpenVMS Cluster Configurations andthe OpenVMS Cluster Software Software ProductDescription (SPD). For complete information about setting up and usingan OpenVMS Cluster environment, refer to the OpenVMSCluster Systems manual.

3.2.1 Failover Capability

Failover capability is the hallmark of a clusterenvironment. If one computer , or node, in the cluster fails, the others canassume its functionality and continue. This is called automaticfailover .

Each node (asa member of the host configuration in the cluster) retains a separate IP address.This is beneficial for troubleshooting the individual node because you can ping the specific node tosee whether it is running.

All of the TCP/IP services support automatic failoverand can run on multiple nodes in an OpenVMS Cluster. For example, if morethan one node in the cluster is running the NFS server, the cluster can appearto the NFS client as a single host. For more information about configuringa specific service for cluster failover, refer to the particular service inthe Compaq TCP/IP Services for OpenVMS Management guide.

3.2.2 Connection Load Balancing

Loadbalancing using the TCP/IP Services is defined by the loadbroker . The load brokeris a configurable, calculated, load-balancing mechanism for distributing thework load among DNS (DomainName System, which maintains and distributes information about Internet hosts)cluster members. For more information about DNS, see Chapter 5.

Unlike round-robin scheduling (thedefault method used by most DNS name servers, in which each individual nodein the cluster is polled in a continual, specific order), the load brokertakes into account the load on all DNS cluster participants. The load brokerpolls DNS cluster members and updates the metric server accordingly.Whenthe load broker starts, it reads its configuration file and starts pollingDNS cluster members. The load broker exchanges messages with DNS cluster membersthat run the metric server, which calculates the current load on a DNS clusterhost by using a specific equation. The metric server calculates the currentrating and reports it when polled by the load broker. Periodically, the loadbroker sorts the list of addresses based on metric rating reports, drops thesystems that do not respond after being polled three times, and compares asubset of the list with the name server information.

Todo the comparison, the load broker sends a host lookup request to the specifiedname server. If the lists are the same, the load broker does not make changes.If the lists are different, the load broker updates the name server data bysending a dynamic update request to the specified name server. The name serveruses round-robin scheduling to further balance the load across the membersof a DNS cluster. Thus, every consecutive request for translating the DNScluster name results in a returned list, is rotated by one.

Forspecific information about configuring the load broker, starting and stoppingthe metric server, and troubleshooting, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

3.3 Multihomingand Multiple Interfaces

Although host computers can have several networkinterface cards (NICs) installed, you can configure the host through a single,primary interface. This section introduces the following concepts:

• Multihomed computers

• Primary interface

• Pseudointerfaces

3.3.1 Multihomed Computers

Individual host computers can have multiple networkinterface cards per computer.Such a computer is called multihomed. These physical interfaces can be connected to differenttypes of networks, such as Ethernet, FDDI, Token Ring, asynchronous transfermode (ATM), Gigabit Ethernet, and serial communications lines. Each physicalinterface is associated with one device driver (network interface). A singlenetwork interface can have more than one IP address.

$Q:\adept8\entities\note.eps$ Note

If a host has multiple interfaces under DHCP (DynamicHost Configuration Protocol) control and receives a different host name froma DHCP server on each of the DHCP-controlled interfaces, the DHCP client usesthe host name it receives on the primary interface to configure the host namefor the client. For more information about DHCP, see Chapter 5.

3.3.2 Primary Interface

Although you can have multiple physical interfaceson a single computer, some of the parameters that are configurable by DHCPare interface specific. Examples of interface-specific parameters are theIP address and subnet mask. However, most DHCP configurable parameters aresystemwide configurable parameters. Examples of systemwide parameters arethe host name and DNS domain name. The TCP/IP Services DHCP client supportscontrolled configuration of systemwide configurable items by designation ofa primary interface .

Theprimary interface is the interface on which the DHCP client uses systemwideparameters received from the DHCP server to configure the system. Systemwideparameters received on an interface that is not designated as primary arenot configured on your system by the server. Although only one interface ona system is designated as the primary DHCP interface, the system is not requiredto have any interface designated as primary.

If a system has multiple interfaces and only oneis under DHCP control, you can configure the systemwide parameters manually.DHCP client uses the following rules to resolve conflicts:

• The only-one-primary-interface rule

This rule solves the potential conflict betweentwo DHCP controlled interfaces on a host getting different systemwide parametervalues. To resolve the conflict, you designate one interface to be the primaryinterface and the parameters that you receive on that interface are the valuesthe DHCP client uses to configure the system. TCP/IP Services does not letyou designate two primary interfaces.

• The primary-interface-not-requiredrule

This rule solves the problem of DHCP configuringinterfaces with an IP addressbut also keeping manual control of the systemwide parameters. In this case,the DHCP client does not designate the interface as the primary interface,and it ignores any systemwide parameters it receives from a DHCP server.

Fordetails about configuring multiple interfaces, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

3.3.3 Pseudointerfaces

To use extended routing, you can define pseudointerfaces.A pseudointerface is a data structure that extendssubnet routing using a network interface. Each network interface has one nameand at most nine pseudointerface names. Each network interface and pseudointerfacehas its own IP address, network mask, and broadcast mask.

Likean interface, the name of an internet pseudointerface consists of three alphabeticcharacters, followed by the pseudointerface unit number in the range of 0through 255. The first two characters are the same as the two characters inthe internet interface name (interface type and interface class). The thirdcharacter identifies the controller letter that corresponds to the OpenVMShardware controller. For more information about interface names, refer tothe Compaq TCP/IP Services for OpenVMS Management guide.3.4 Serial Line Connections

A serial connection is made between two systems using modems and telephonelines or other serial lines. TCP/IP Services supports serial connections usingPPP (Point-to-Point Protocol) and SLIP (Serial Line Internet Protocol). SLIPincludes CSLIP (compressed SLIP). You can use any standard OpenVMS terminaldevice as a PPP or a SLIP line. However, PPP is available for OpenVMS Alphasystems only.

One of the largest applications for IP over seriallines is dialup access. With this type of configuration, your OpenVMS hostanswers calls and establishes a connection initiated by a user on a clienthost. The client host can be another OpenVMS system, a UNIX system, or a PC.Alternatively, users on your host can originate the dialup connection to aremote host or terminal server that is running the same protocol. Dedicatedserial lines running PPP or SLIP can also be used to connect separate LANsinto a single WAN. In such a configuration, the host at each end of the serialconnection is always the same; no other hosts are allowed to connect to eitherserial device.

If your OpenVMS system is part of a large network,you will probably use both PPP and SLIP for your serial connections. As anInternet standard, PPP is often preferred because it ensures interoperabilitybetween systems from a wide variety of vendors. PPP provides a way for yourOpenVMS Alpha system to establish a dynamic IP network connection over a serialline without additional router or server hardware.

SLIPhas been in use for a longer period of time than PPP and is available formost terminal servers and in most PC implementations of TCP/IP. Because SLIPand PPP do not communicate with each other, hosts must use the same protocolin order to communicate. For example, if your terminal server supports onlySLIP, remote hosts that connect through this server must also use SLIP. Formore information about configuring serial lines, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

ForMore Information

For more information about the following topics,refer to the Compaq TCP/IP Services for OpenVMSManagement guide.

• Configuring and troubleshooting OpenVMSClusters, including load balancing and failover configurations

• Configuring multiple interfaces andmultihomed systems

• Details about pseudointerfaces

• Configuring serial linesFordetailed descriptions of OpenVMS Alpha and VAX similarities and differences,refer to A Comparison of System Managementon OpenVMS AXP and OpenVMS VAX.

For complete information about supported devicesand configurations, refer to the Guidelinesfor OpenVMS Cluster Configurations and the OpenVMSCluster Software Software Product Description (SPD). For complete informationabout setting up and using an OpenVMS Cluster environment, refer to the OpenVMS Cluster Systems manual.

4 OpenVMSOperating System TCP/IP Features

The OpenVMS operating system contains a numberof features that are of specific benefit to the TCP/IP environment. This chapterdiscusses the following topics related to these features:

• TCP/IP management commands

• Using logical names

• OpenVMS System Dump Analysis (SDA)Tool

• Accessing system messages throughoperator communication manager (OPCOM) and log files

• Comparison of ODS-5 and ODS-2file structures

• Print queues (network printers)

Thingsto Consider

In planning your TCP/IP Services for OpenVMS, considerthe following:

• Should I use ODS-5? For which disks?

• Where should I store the log files?

• Which printers in my system are networkshareable? How will users access them?

• Which printers in my systemare on a serial line?

• Should I configure PATHWORKS sharesfor printers?

4.1 TCP/IP Management Control Program

TheTCP/IP Services Management Control Program is a comprehensive, easy-to-usenetwork management tool that includes more than 100 OpenVMS commands. TCP/IPServices provides this management command interface to configure and modifyparameters of components, configure customer-developed services, enable anddisable running components, and monitor the running software

Tostart the management control program, enter the following command:$TCPIP
TCPIP>

At the TCPIP>

prompt, you can enter commands such as the following:

SHOWSERVICES

SHOWCONFIGURATION

HELP

SETHOST

COPY

DIR

You can also use UNIX management commands to managesome components of TCP/IP Services.

To use UNIX management commands at the DCL prompt,run the following command procedure:

$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS

Thenenter UNIX commands as you would on a Tru64 UNIX system.

TCP/IPmanagement commands are described fully in the CompaqTCP/IP Services for OpenVMS Management Command Reference manual, andin the TCP/IP Services online help.

TCPIP> HELP

To exit the management control program, enter thefollowing command:

TCPIP> EXIT

To obtain information about TCP/IP Services, enterthe following command at the DCL prompt:

$ HELP TCPIP_SERVICES

4.2 Defining Logical Names

Logical names allow you to customize componentbehavior. Logical names can point to directories, database files, and logfiles.

To define a logical name, enter the following DCLcommand:

$ DEFINE logical-name

Formore information about these logical names, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

TheTCPIP$CONFIG database predefines logical names for various databases. Duringthe menu-driven installation procedure, the software configures either thecomponents you select or all of the TCP/IP Services software components. Thesedefaults are designed to get your system up and running as an internet hostwith minimal effort. TCPIP$CONFIG creates the database files.

Afterthe initial configuration of a component, you can use logical names to modifythe settings of the component-specific parameters. Many logical names aredefined as “existence logical names”; that is, they can be eitheron or off. Any value associated with them is ignored. Others require a valueof text string as a definition. Every logical name has a default setting.Formore information about how TCP/IP Services components uses logical names,see relevant chapters in this manual and refer to the CompaqTCP/IP Services for OpenVMS Management guide.

4.3 OpenVMSSystem Dump Analysis (SDA) Tool

TCP/IP Services for OpenVMS provides network-specificenhancements to the OpenVMS System Dump Analysis (SDA) tool. For more informationabout SDA enhancements, refer to DCL online help.

Ifyour system fails, you can run the SDA tool on system reboot to analyze thesystem crash dump. You can do this by adding command lines to the SYSTARTUP_VMS.COMprocedure.

If you are unable to analyze a process dump withthe debugger, use the System Dump Analyzer (SDA) utility. Refer to the ANALYZE/CRASHcommand in online help for more information. For example:

$ANALYZE/CRASH billsystem.dmp

OpenVMS (TM) Alpha systemdump analyzer
...analyzing a compressed processdump...

Dump taken on 24-JUL-2002 12:03:40.95
SDA>

Fordetails, refer to the OpenVMS VAX SystemDump Analyzer Utility Manual and the OpenVMSAlpha System Dump Analyzer Utility Manual.

4.4 SystemMessages

You can keep log files of events, changes, andother configuration data in two ways.

• Using OPCOM (operator communication manager) —available only if you have system privileges.

• Using log files that most componentsestablish when they are configured.

System messages are saved to either one of theseutilities. Both are described in this section.

4.4.1 OPCOM

Any terminal that is connected to the operatingsystem can be established as an operator’s terminal if OPCOM (operatorcommunication manager) is running. When an operator who is logged in to anaccount with OPER privilege enters the REPLY/ENABLE command at the designatedterminal, that terminal can be used to respond to user requests and to monitordevice status. Operator messages are displayed on the system console terminalunless the terminal is explicitly disabled as an operator’s terminal.

Toset up a terminal to receive OPCOM messages, enter the following command:$REPLY/ENABLE

4.4.2 Log Files

Eventlogging can help you manage the TCP/IP Services software. By default, user-definedservices do not log events, but event logging is enabled by default for allsupplied services. You can configure the product to log events to the operator’sconsole or to a log file, or to both. Every component has a default log file.For more information about log files, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

Toset up event logging, enter the following command:

TCPIP> SETSERVICE service-name /LOG_OPTIONS=ALL

Fora list of all the logging options, refer to the SET SERVICE command descriptionin the Compaq TCP/IP Services for OpenVMSManagement Command Reference manual.

Some product components provide additional eventlogging capabilities. For more information, see the relevant chapters in thismanual.

4.5 ODS-5 and ODS-2 File Structures

OpenVMSimplements On-Disk Structure Level 5 (ODS-5). This structure provides thebasis for creating and storing files with extended file names. The formatwas introduced for compatibility with other file systems, such as Windows.You can choose whether or not to convert a volume to ODS-5 on your OpenVMSAlpha systems.

The ODS-5 volume structure provides the followingfeatures:

• Long file names

• More legal characters in filenames

• Preservation of case in file names

Thesefeatures are described in detail in the OpenVMS product documentation.ODS-5provides enhanced file-sharing capabilities for TCP/IP Services as well asfor Advanced Server for OpenVMS (or PATHWORKS for OpenVMS), DCOM, and Java™applications. Once ODS-5 volumes are enabled, some of the new capabilitiescan impact certain applications or layered products as well as some areasof system management.

The following sections summarize how the enablingof ODS-5 volumes can impact system management, users, and applications.

4.5.1 Considerations for System ManagementRMSaccess to deep directories and extended file names is available only on ODS-5volumes mounted on OpenVMS Alpha Version 7.2 systems and higher. Compaq recommendsthat ODS-5 volumes be enabled only on homogeneous OpenVMS Alpha clusters.If ODS-5 is enabled in a mixed-version or mixed-architecture OpenVMS Cluster,the system manager must follow special procedures and must be aware of thefollowing specific restriction: users must access ODS-5 files and deep directoriesfrom OpenVMS Alpha systems only because these capabilities are not supportedon earlier versions of the operating system.

4.5.2 Considerations for Users

Users on OpenVMS Alpha systems can take advantageof all Extended File Specifications capabilities on ODS-5 volumes that aremounted on those systems. A user on a mixed-version or mixed-architectureOpenVMS Cluster is subject to some limitations in ODS-5 functionality.

Fordetailed information about mixed-version or mixed-architecture support, referto the OpenVMS product documentation.

4.5.3 Considerationsfor Applications

You can select ODS-5 functionality on a volume-by-volumebasis. If ODS-5 volumes are not enabled on your system, all existing applicationswill continue to function as before. If ODS-5 volumes are enabled, be awareof the following changes:

• OpenVMS file handling and command-lineparsing are modified to enable them to work with extended file names on ODS-5volumes and maintain compatibility with existing applications. The majorityof existing, unprivileged applications will work with most extended file names,but some applications might need modifications to work with all extended filenames.

• Privileged applications that performfilename parsing and need to access ODS-5 file names or volumes should beanalyzed to determine whether they require modification.

OnODS-5 volumes, existing applications and layered products that are coded todocumented interfaces, as well as most DCL command procedures, should continueto work without modification.

However, applications that are coded to undocumentedinterfaces or that include any of the following might need to be modifiedto function as expected on an ODS-5 volume:

• Internal knowledge of the filesystem, including knowledge of:

Data layout on the disk

Contents of file headers

Contents of directory files

• File name parsing tailoredto a particular on-disk structure.

• Assumptions about the syntax of filespecifications, such as the placement of delimiters and legal characters.

• Assumptions about the case of filespecifications. Mixed-case and lowercase file specifications are not convertedto uppercase. This can affect string-matching operations.4.6 Network Printers

Resource sharing lets users access network printersas if they were directly connected to the user’s local systems. Withresource sharing, users can access these resources directly after making theinitial connection. This is different from file transfer programs in whichfiles must be transferred completely from the remote system before they canbe used.

The printer-sharing components of TCP/IP Servicesinclude:

• Line printer/line printer daemon (LPR/LPD),which provides print services to remote and local hosts.

• The TELNET print symbiont (TELNETSYM)provides remote printing services that enables OpenVMS printing features notavailable with the LPR/LPD print service.

• Serial line connection.

• PC-NFS, which provides authenticationand print services for personal computers running PC-NFS.Ifa printer is on the network, you must set it up like any OpenVMS printer.For information about setting up OpenVMS printers, refer to the relevant OpenVMSdocumentation.

4.6.1 Line PrinterDaemon (LPD) Service

The Compaq TCP/IP Services for OpenVMS softwareprovides network printing through LPR/LPD. The LPR/LPD service has both aclient component (LPR) and a server component (LPD). LPD provides remote printingservices for many client hosts, including OpenVMS, UNIX, and Windows NT clienthosts. Each print queue is either local or remote. Local print queues handleinbound jobs; remote print queues handle outbound jobs for remote printers.

Theprint setup utility (TCPIP$LPRSETUP) does the following:

• Updates the related printcap database.

• Creates and starts queues.

• Allows you to add commands to theautomatic startup and shutdown command procedures.

To print, users at an OpenVMS client enter theDCL command PRINT.

Users working on UNIX clients typically enter the lpr command.

Touse the Compaq TCP/IP Services for OpenVMS network printer services, you needthe following:

• The remote host name.

• The name of the remote print queueor the local queue name. (LPD accepts both local and remote entries.)

• Compaq PrintServer extensions to usethe PRINT/PARAMETERS=options=value command.

• TCP/IP Services for OpenVMSinstalled and LPR/LPD enabled on your OpenVMS system.

Boththe client component (LPR) and the server component (LPD) are partially includedin an OpenVMS queue symbiont. The client is activated when you use one ofthe following commands

• PRINT—to submit a print jobto a remote printer whose queue is managed by the LPD symbiont.

• LPRM—to remove (cancel) a pendingprint job that was previously spooled.

• LPQ—to view the queueof pending jobs for a remote printer

The LPD server is activated when a remote usersubmits a print job to a printer that is configured on the OpenVMS server.The LPD server consists of the following two components:

• LPD receiver—a process thathandles the incoming request from the remote system over the network. TheLPD receiver copies the control file (CF) and data file (DF) that representthe print job to the requested printer’s LPD spool directory, and placesthe control file in the print queue for further processing. The receiver alsohandles LPQ and LPRM functions from remote clients.

• LPD symbiont—parses theprint job’s control file, and submits the data files to the designatedlocal printer’s print queue.

The same LPD symbiont image is used for both clientand server. It acts as the client on queues that are set up for remote printers,and it acts as the server on the local LPD queue. The LPD uses the printcapdatabase to process print requests. The printcap database, located in SYS$SPECIFIC:[TCPIP$LPD]TCPIP$PRINTCAP.DAT,is an ASCII text file that defines the print queues. The printcap entriesare similar in syntax to the entries in a UNIX /etc/printcap

file.

Use the printer setup program LPRSETUP to configureor modify printers. The setup program creates spool directories and log filesbased on the information you supply. For more information and example setuplistings, refer to the Compaq TCP/IP Servicesfor OpenVMS Management guide.

For more information about the following networkprinting services, refer to the Compaq TCP/IPServices for OpenVMS User’s Guide:

• Sending print jobs to a printer connectedto a remote internet host

• Displaying print queue status

• Canceling print jobs

• Receiving on local (OpenVMS system)print queues print jobs initiated from a user on a UNIX system

• Getting a "finished" notificationthrough SMTP mail

4.6.2 TELNETPrint Symbiont

The TELNET print symbiont (TELNETSYM) providesremote printing services that enables OpenVMS printing features not availablewith the LPR/LPD print service. With TELNETSYM, the local OpenVMS system drivesa remote printer as if it were directly connected. This is achieved by attachinga printer to a remote TCP/IP terminal server. The TELNET print symbiont hasthe following functions:

• Transfers record-oriented data toand from disks and printers.

• Configures printers attached to terminalservers that support TELNET.

• Supports outbound functions (to aremote printer), and offers preformatting to outbound print jobs.

Note

TELNET does not work with terminal servers thatuse only the local area transport (LAT) protocol. The terminal server mustsupport TCP/IP.

The system that originates the print jobs handlesthe standard print control functions, such as header-page generation, pagination,queuing, and handling of multiple forms. TELNETSYM extends the OpenVMS printsymbiont by redirecting its output to a network channel.

EachTELNETSYM process can control up to 16 print queues. You can control the maximumnumber of print queues by defining the TCPIP$TELNETSYM_STREAMS logical.Fordetailed information about configuring and managing TELNETSYM, refer to the Compaq TCP/IP Services for OpenVMS Management guide.4.6.3 Serial Line Printer Connections

Aserial connection for a remote printer is made between a system and a serialline printer. Compaq TCP/IP Services for OpenVMS supports serial connectionsusing the PPP (Point-to-Point Protocol) and SLIP (Serial Line IP), or CSLIPprotocols. You can use any standard OpenVMS terminal device as a PPP or aSLIP line. If the remote system is configured as a gateway to a network, localusers can also reach other systems on that network through the serial connection.For more information about serial line configurations, see Chapter 3.

4.6.4 Sharing Network Printers Using PATHWORKS (Advanced Server)Becauseeveryone on a network uses print services, make sure that network print operationsare set up efficiently and cost effectively. The choices that you need tomake might include the following:

• Which printers to use

• Which computers to use as print servers

• How to configure shared printers formaximum use

Determine which printers you want to make availableto your server community. Some considerations regarding printers include:

• Location

Selectprinters that are closest to the physical location of users who require theiroutput.

• Cost of use

Youmight want to restrict access to expensive-to-use printers rather than makethem available to all network users. Conversely, using one network printerfor several groups in a building is less expensive than using separate printersfor each group in the building.

• Resolution

Userswho frequently print graphics require printers with higher resolution. Groupswho usually print text files can use lower-resolution printers.

Acomputer can act simultaneously as a print server and a file server. The decisionto combine print and file servers might depend on security concerns. Althoughprinters should always be available to their users, you might want to locatea file server in a secure place. Regardless of the size of your network, youmost likely will install printers on a few select computers. The only specialhardware requirement for print servers is that, if you are using parallelor serial printers, the print servers must have the correct output ports.Unlikeparallel and serial devices, printers with built-in network adapter cardsdo not have to be adjacent to the print server. Network-interface printersare attached to the network through a built-in adapter card. The locationof this type of printer has no effect on printing performance, provided thatusers and printers are not on opposite sides of a network bridge. A CompaqAdvanced Server print server can control a virtually unlimited number of network-interfaceprinters.

The Compaq Advanced Server makes printers availableto network users through print shares. In addition, you can use a genericqueue when several like printers are available to the user. A generic queuecan point to several execution queues and is used to distribute printer workload among several like printers by routing a print job to the first availableprinter through that printer’s execution queue. (If you manage the sharedprinters from Windows NT, the Advanced Server allows you to set up a printerpool, which is similar in function to an OpenVMS generic queue.)

Youcan use the Advanced Server ADMINISTER command line interface to add printers(as print queues) and print shares to the Advanced Server and to manage them.Alternatively, beginning with Version 7.3 of the Advanced Server for OpenVMS,you can configure the server to allow management of shared printers from WindowsNT using the Windows NT print services. The default is to use the AdvancedServer ADMINISTER command line interface.

Each print share points to a single print queuewith the same name as the share. Permissions that you assign to the shareare applied automatically to the associated print queue. As with any othershared resource, a share can be accessed over the network by users who havethe appropriate permissions. Four types of permissions apply to print shares:Print (the default), None (no access), Manage Documents, and Full (full control).

Formore information about sharing network printers, refer to the CompaqAdvanced Server for OpenVMS Concepts and Planning Guide.4.6.5 PC-NFS

The PC-NFS server provides authentication and printservices for PCs running NFS. Users on a PC client can associate the nameof the PC printer with an OpenVMS print queue and can print files to the associatedqueue. However, Compaq recommends that PC clients use other mechanisms foraccessing OpenVMS print queues.

To access the NFS server, PC users must have anentry in the proxy database and must have corresponding OpenVMS accounts onthe server. For more information about configuring PC-NFS, refer to the Compaq TCP/IP Services for OpenVMS Management guide.

ForMore Information

For detailed information about configuring andmanaging TELNETSYM, LPD, and PC-NFS, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

Formore information about network printing services, refer to the CompaqTCP/IP Services for OpenVMS User’s Guide.

Formore information about the management control commands and for a list of allthe logging options within the SET SERVICE command, refer to the CompaqTCP/IP Services for OpenVMS Management Command Reference manual orto online help.

For complete information about ODS-5 features,refer to the OpenVMS documentation set.

For more information about sharing network printers,refer to the Compaq Advanced Server for OpenVMSConcepts and Planning Guide.

For more information about preinstallation tasksand the step-by-step installation, refer to the CompaqTCP/IP Services for OpenVMS Installation and Configuration guide.

5 NetworkServer Services

This chapter describes key concepts for the followingnetwork server features:

• Network Time Protocol (NTP)

• Routing

• Remote client management (BOOTP/DHCP)

• File Transfer Protocol (FTP)

• SNMP

Thingsto Consider

In planning your TCP/IP Services for OpenVMS, considerthe following:

• Will the system serve as a time serverand at what stratum? Where does the authoritative time come from?

• Do I need to remote boot any clients?Which kinds?

• Will the system serve as a router?What kind?

• Which file transfer method shouldI use: FTP or RCP? What are the security needs, client types, and the purposesof the transfer?

• Will I need to service SNMP programs?

5.1 Network Time Protocol (NTP)

TheNetwork Time Protocol (NTP) synchronizes time and coordinates time distributionthroughout a TCP/IP network. TCP/IP Services NTP software is an implementationof the NTP Version 4 specification and maintains compatibility with NTP Versions1, 2, and 3.

Time synchronization is important in client/servercomputing. For example, systems that share common databases require coordinatedtransaction processing and timestamping of instrumental data.

Synchronizedtimekeeping means that hosts with accurate system timestamps send time quotesto each other. Hosts running NTP can be either a time server or a time client,although they often are both a server and a client. NTP does not attempt tosynchronize clocks to each other. Rather, each server attempts to synchronizeto Coordinated Universal Time (UTC) using the best available source and thebest available transmission paths to that source. NTP expects that the timebeing distributed from the root of the synchronization subnet is derived fromsome external source of UTC (for example, a radio clock). Ifyour network is isolated and you cannot access other NTP servers on the internet,you can designate one of your nodes as the reference clock to which all otherhosts will synchronize.

Running an NTP server is optional. If you do setup an NTP server, you must decide whether it will be the authoritative serveror whether you will get time from another server.

5.1.1 Time Distributed Through a Hierarchy of Servers

Inthe NTP environment, time is distributed through a hierarchy of NTP time servers.Each server adopts a stratum that indicates how far away it is operating froman external source of UTC. NTP times are an offset of UTC. Stratum 1 servershave access to an external time source, usually a radio clock. A stratum 2server is one that is currently obtaining time from a stratum 1 server; astratum 3 server gets its time from a stratum 2 server, and so on. To avoidlong-lived synchronization loops, the number of strata is limited to 15. Stratum2 (and higher) hosts might be company or campus servers that obtain time fromsome number of primary servers and provide time to many local clients. Ingeneral:

• Lower-stratum hosts act as time servers.

• Higher-stratum hosts are clients thatadjust their time clocks according to the servers.

Internettime servers are usually stratum 1 servers. Other hosts connected to an internettime server have stratum numbers of 2 or higher and may act as time serversfor other hosts on the network. Clients usually choose one of the lowest accessiblestratum servers from which to synchronize.

5.1.2 How the OpenVMS System Maintains the System Clock

TheOpenVMS system clock is maintained as a software timer with a resolution of100 nanoseconds, updated at 10-millisecond intervals. A clock update is triggeredwhen a register, loaded with a predefined value, has decremented to zero.Upon reaching zero, an interrupt is triggered that reloads the register, andrepeats the process.

The smaller the value loaded into this register,the more quickly it reaches zero and triggers an update. In such an instance,the clock runs more quickly. A larger value means more time between updates;therefore, the clock runs more slowly. The amount of time between clock updatesis known as a clock tick.

5.1.3 How NTPAdjusts System Time

Once NTP has selected a suitable synchronizationsource, NTP compares the source’s time with that of the local clock.If NTP determines that the local clock is running ahead of or behind the synchronizationsource, NTP uses a general drift mechanism to slow down or speed up the clockas needed. NTP accomplishes this by issuing a series of new clock ticks. Forexample, if NTP detects that the local clock is drifting ahead by +0.1884338second, it issues a series of new ticks to reduce the difference between thesynchronization source and the local clock.

If the local system time is not reasonably correct,NTP does not set the local clock. For example, if the new time is more than1000 seconds off in either direction, NTP does not set the clock. In thiscase, NTP logs the error and shuts down.

NTP maintains a record of the resets it makes alongwith informational messages in the NTP log file, TCPIP$NTP_RUN.LOG. For moredetails about event logging and for help interpreting an NTP log file, referto the Compaq TCP/IP Services for OpenVMSManagement guide.

Fore information regarding operating system anddaylight saving time issues, refer to the OpenVMS documentation set.

5.1.4 Configuring the Local Host

Asthe system manager of the local host, you determine which network hosts touse for synchronization and for populating an NTP configuration file witha list of the participating hosts.

You can configure NTP hosts in one or more of thefollowing modes:

• Client/server mode

This mode indicates that the local host wants toobtain time from the remote server and is willing to supply time to the remoteserver, if necessary. This mode is appropriate in configurations that involvea number of redundant time servers interconnected through diverse networkpaths. Most internet time servers use this mode.

• Client mode

This mode indicates that the local host wants toobtain time from the remote server but it is not willing to provide time tothe remote server. Client mode is appropriate for file server and workstationclients that do not provide synchronization to other local clients. In general,hosts with a higher stratum use this mode.

• Broadcast mode

This mode indicates that the local server willsend periodic broadcast messages to a client population at the broadcast/multicastaddress specified. Normally, this specification applies to the local serverthat is operating as a sender. To specify broadcast mode, use a broadcastdeclaration in the configuration file.

For information about additional modes, refer tothe TCP/IP Services release notes.

5.1.5 Using theDistributed Time Synchronization Service (DTSS)

Yoursystem might be using the Distributed Time Synchronization Service (DTSS).DTSS is provided as an option with DECnet-Plus and the Distributed ComputingEnvironment (DCE). If you are using DTSS, you must use the procedures suppliedwith DTSS to set time zone information.

If you are running Version 7.3 or later, you candisable DTSS in favor of running NTP. Define the logical name NET$DISABLE_DTSSto keep DECnet-Plus DECdts from starting.

5.2 Routing

Routing is the act of forwarding datagrams basedon information stored in a routing table. Routing allows traffic from yourlocal network to reach its destination elsewhere on the internet. Hosts andgateways on a network use routing protocols to exchange and store routinginformation.

If the hosts on your network need to communicatewith computers on other networks, a route through a gateway must be defined.All hosts and gateways on a network store information about routes in routingtables. With TCP/IP Services, routing tables are maintained on the disk andin dynamic memory.

The TCP/IP Services product provides two typesof routing. You can define routes manually (static routing), or you can enable routing protocolsthat exchange information and build routing tables based on the exchangedinformation (dynamic routing).

5.2.1 Static Routing

Because static routing requires manual configuration,it is most useful when the number of gateways is limited and when routes donot change frequently. For information about manually configuring routing,refer to the Compaq TCP/IP Services for OpenVMSManagement guide.

5.2.2 DynamicRouting

Complex environments require a more flexible approachto routing than a static routing table provides. Routing protocols distributeinformation that reflect changing network conditions and update the routingtable accordingly. Routing protocols can switch to a backup route when a primaryroute becomes unavailable, and can determine the best route to a given destination.

Dynamicrouting tables use information that is received by means of routing protocolupdates; when routes change, the routing protocol provides information aboutthe changes.

Routing daemons implement a routing policy, thatis, a set of rules that specify which routes go into the routing table. Arouting daemon writes routing messages to a routing socket, which causes thekernel to add a new route or delete , or modify, an existing route.

Thekernel also generates routing messages that can be read by any routing socketwhen events occur that might be of interest to the process (for example, theinterface has gone down or a redirect has been received).TCP/IPServices implements two routing daemons: the Routing Daemon(ROUTED) and the Gateway Routing Daemon (GATED). The following sections provide more information aboutthese daemons.

Routing Daemon (ROUTED)

TheROUTED daemon (pronounced “route-dee”) supports the Routing InformationProtocol (RIP). When ROUTED starts, it issues routing update requests andthen listens for responses. A system that is configured to supply RIP informationresponds to the request with an update packet. The update packet containsdestination addresses and routing metrics associated with each destination.After receiving a RIP update, the ROUTED uses the information to update itsrouting table.

For details about how to configure dynamic routingwith ROUTED, refer to the Compaq TCP/IP Servicesfor OpenVMS Management guide.

$Q:\adept8\entities\note.eps$ Note

ROUTED supports Routing Information Protocol (RIP)V1 only. ROUTED is considered older technology, and many system administratorsare replacing it with GATED.

Gateway Routing Daemon (GATED)

TheGATED daemon (pronounced “gate-dee”) supports interior and exteriorgateway protocols. It obtains information from several routing protocols andselects the best routes based on that information. You can configure GATEDto use one or more of the protocols described in Table 5–1.Table 5–1 GATED Protocols and RFCs

Protocol	Description	Describedin this RFC
RoutingInformation Protocol (RIP) supports both Versions 1 and 2	RIPis a commonly used interior protocol that selects the route with the lowestmetric (hop count) as the best route.	RFCs1058, 1723
OpenShortest Path First (OSPF) Version 2	Anotherinterior routing protocol, OSPF is a link state protocol (shortest path first).It is better suited than RIP for use in complex networks with many routers.	RFC1583
ExteriorGateway Protocol (EGP)	EGPexchanges reachability information between autonomous systems. An autonomoussystem is usually defined as a set of routers under a single administration,using an interior gateway protocol and common metric to route packets. Autonomoussystems use exterior routing protocols to route packets to other autonomoussystems.	RFC904
BorderGateway Protocol (BGP)	LikeEGP, BGP exchanges reachability information between autonomous systems butsupports nonhierarchical topologies. BGP uses path attributes to provide moreinformation about each route. Path attributes can include, for example, administrativepreferences based on political, organizational, or security considerations.	RFCs1163, 1267, 1771
RouterDiscovery	Thisprotocol is used to inform hosts of the availability of routers that it cansend packets to, and to supplement a statically configured default router.	RFC1256

Note

The list in Table 5–1 is continually updated.For the latest details, refer to the CompaqTCP/IP Services for OpenVMS Software Product Description (SPD 46.46.xx).

The routing protocols described in Table 5–1are configured in the GATED configuration file, TCPIP$GATED.CONF. This filecontains statements that control tracing options, select routing protocols,manage routing information, and manage independent system routing.

UnderGATED, load balancing provides for identical routes based on the referencecount and use count (you can observe this through netstat-r). GATED chooses from among identicalroutes the one with the lowest reference count. If there is more than onelowest reference count, it uses the lowest use count.

AlthoughROUTED allows multiple default routes, it does not monitor interface states.Conversely, GATED monitors interface status changes; however, it does notallow multiple default routes.

For information about configuring dynamic routingwith GATED, refer to the Compaq TCP/IP Servicesfor OpenVMS Management guide.

5.3 Remote Client Management (BOOTP/DHCP)

DynamicHost Configuration Protocol (DHCP), a superset of the Bootstrap Protocol (BOOTP),provides a centralized approach to the configuration and maintenance of IPaddress space. DHCP allows system managers to configure various clients ona network from a single location.

DHCP allocates temporary or permanent IP addressesfrom an address pool to client hosts on the network. DHCP can also configureclient parameters (such as default gateway parameter), domain name server(DNS) parameters, and subnet masks for each host running a DHCP client.

WithDHCP, system managers can centralize TCP/IP network configurations and managementtasks involved with network connections. DHCP makes network administrationeasier by allowing:

• Consistent application of networkparameters, such as subnet masks and default routers, to all hosts on a network

• Support for both DHCP and BOOTP clients

• Static (permanent) mapping of hardwareaddresses to IP addresses

• Dynamic (temporary) mapping of hardwareaddresses to IP addresses, where the client leases the IP address for a definedlength of time

$Q:\adept8\entities\note.eps$ Note

An OpenVMS system running TCP/IP Services can beconfigured as either a DHCP server or a client, but not as both. Moreover,do not attempt to configure both BOOTP and DHCP; if you do, the configurationgenerates a warning message.

In addition, the TCP/IP Services implementationof DHCP includes support for DHCP server failover in an OpenVMS Cluster environment.For more information about the OpenVMS Cluster environment, refer to Chapter3.

As a superset of BOOTP functionality, DHCP offersrobust configuration services, including IP addresses, subnet masks, and defaultgateways.

DHCP is built on the client/server model in thefollowing respects:

• The DHCP server is a host that providesinitialization parameters.

• The DHCP client is a host that requestsinitialization parameters from a DHCP server. A router cannot be a DHCP client.

5.3.1 How DHCP Operates

DHCP consists of two components:

• A mechanism for allocating networkaddresses to clients

• A set of rules for delivering client-specificconfiguration parameters from a DHCP server to a client

The server and client communicate to accomplishthe following steps:

1. When a DHCP client boots, it broadcastsa DHCP request, asking that any DHCP server on the network provide it withan IP address and configuration parameters.

2. A DHCP server on the network thatis authorized to configure this client sends the client a reply that offersan IP address.

3. When the client receives the offer, itcan accept it or wait for other offers from other servers on the network.

4. Once the client accepts an offer, it sendsan acceptance message to the server.

5. When the server receives the acceptancemessage, it sends an acknowledgment with the offered IP address and any otherconfiguration parameters that the client requested. (The server only respondsto specific client requests; it does not impose any parameters on the client.)

6. If the dynamic address allocation methodis used, the IP address offered to the client has a specific lease time thatdetermines how long the IP address is valid.

During the lifetime of the lease, the client repeatedlyasks the server to renew. If the client does not renew it, the lease expires.

Oncethe lease expires, the IP address can be recycled and given to another client.When the client reboots, it can be given the old address, if available, orit can be assigned a new address.

For more information about how DHCP operates, referto RFC 2131 and RFC 1534.

5.3.2 How DHCPAllocates IP Addresses

With TCP/IP Services, DHCP uses dynamic and staticIP address-mapping methods. Table 5–2 describes the allocation methodsthat service DHCP and BOOTP-only client requests.

Table 5–2 DHCP IP Address Allocation Methods

Method

ApplicableClient

Description

Dynamic

DHCPand BOOTP

TheDHCP server assigns an IP address from an address pool to a client for a specifiedamount of time (or until the client explicitly relinquishes the address).Addresses no longer needed by clients can be reused.

Use dynamic allocationwhen:

• Clients will be connected to the networkonly temporarily.

• You have a limited pool of IP addressesthat must be shared among clients that do not need permanent IP addresses.

• IP address are scare, and you needto reclaim retired addresses so you can assign them the new clients beingpermanently connected to the network.

For BOOTP clients, DHCP assigns dynamic IP addressesfrom the address pool and stores the addresses in the lease database by assigningeach lease a time of infinity.

Static

DHCPand BOOTP

Thesystem manager manually assigns an IP address to a client and uses DHCP topass the assigned address to the client.

Use static allocation in an error-prone environmentwhere it is desirable to manage IP address assignment outside of DHCP control.

Finite

BOOTP-only

TheDHCP server assigns an IP address from the pool to the BOOTP client and definesa lease time based on certain parameters you define in the SERVER.PCY file.When the lease expires, the DHCP server pings the IP address. If the serverreceives a reply, it extends the lease and does not offer the address to anew client. If not, the address is free and can be assigned to a new client.

The typical network uses a combination of staticand dynamic DHCP addressing. As the local system manager or network administrator,you must decide which IP addressing methods are appropriate for your specificpolicies and environment.

For detailed information about configuring thedifferent types of addressing for clients on your network, refer to the Compaq TCP/IP Services for OpenVMS Management guide.

5.3.3 Relationship Between DHCP and BOOTP

Fromthe client’s perspective, DHCP is an extension of the BOOTP functionality.DHCP allows existing BOOTP clients to operate with DHCP servers without havingto change the client’s initialization software.

Basedon the format of BOOTP messages, the DHCP message format does the following:

• Captures the BOOTP relay agents andeliminates the need for a DHCP server on each physical network segment.

• Allows existing BOOTP clients to operatewith DHCP servers.

Messages that include a DHCP message-type optionare assumed to have been sent by a DHCP client. Messages without the DHCPmessage-type option are assumed to have been sent by a BOOTP client.

DHCPimproves the BOOTP-only functionality in the following ways:

• DHCP allows the serial reassignmentof network addresses to different clients by assigning a network address fora finite lease period.

• DHCP allows clients to acquire allof the IP configuration parameters they need to operate.

Note

BOOTP is considered older technology and many systemadministrators are replacing it with DHCP.

5.3.4 Client ID

With BOOTP, a client is identified by its uniquemedia access control (MAC) address,which is associated with the network adapter card.

DHCPuses a client identifier (ID) to uniquely identify the client and to associateit with a lease. The client creates the client ID from one of the followingtypes of addresses:

• The MAC address.

• A variation of the MAC address. Forexample, Windows clients create the client ID by prepending the hardware typeto the hardware address.

If the client does not include a client ID in therequest, the server uses the client’s MAC address.

5.4 File TransferServices

TCP/IP Services includes the following componentsenable users to transfer data files between local and remote hosts:

• FTP (File Transfer Protocol), whichtransfers files between hosts.

• Trivial File Transfer Protocol (TFTP),which downloads and transfers files.

• R commands, which copy filesto or from remote hosts.

5.4.1 FTP (FileTransfer Protocol)

FTP is a TCP/IP standard, high-level protocol usedto transfer files bidirectionally. FTP enables users to access files interactively,list directories on a remote host, delete and rename files on the remote host,and transfer files between hosts.

FTP also provides authentication control, whichrequires users or clients to correctly enter a login name and password tothe server before requesting file transfers. The server can refuse accessif login and password combinations are invalid.

FTPallows users who do not have a login name or a password to access certainfiles on a system using an anonymous login name. This functionality is called Anonymous FTP andmight include one or more of the following restrictions:

• Limited browsing through the filesystem. Users can access only the anonymous guest (or home) directory anda public directory. The public directory might contain general bulletin informationto which the user has read-only access.

• Access to files from (get)or copying files to (put) the guest directory only.

• Access to files (get) fromthe public directory only.

• Delete privileges for files in theguest directory that are owned by the anonymous account.

Formore information about setting up FTP, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

5.4.2 Trivial FTP (TFTP)

TFTP provides a simple, unsophisticated file transferservice. It is intended for applications that do not need complex interactionsbetween a client and server. TFTP can be hardcoded in read-only memory toexecute a network bootstrap program. Once it begins execution, TFTP allowsthe bootstrap program to use the same underlying protocols that the operatingsystem uses. This makes it possible for one host to boot from a server onanother physical network.

TCP/IP Services supports downloading of systemimages and other types of information for client hosts with TFTP.

TFTPtransfers files from a TFTP server to diskless clients or other remote systems.The client initiates the file transfer. If the client sends a read requestto the TFTP server, the server attempts to locate this file. TFTPhas the following characteristics:

• TFTP clients are not registeredin a database.

• TFTP runs as an unprivileged userin the TCPIP$TFTP account and therefore is restricted to files that the unprivilegeduser can access.

• TFTP clients are not regulated bythe usual OpenVMS user security methods.

• No user name or password isrequired to use the TFTP service.

For information about how to set up TFTP, referto the Compaq TCP/IP Services for OpenVMSInstallation and Configuration manual.

5.4.3 R Commands

TheTCP/IP Services software includes client and server implementations of theBerkeley Remote (R) command applications. These applications provide userswith the following capabilities:

• RCP – Allows files tobe copied between remote hosts.

• RLOGIN — Provides interactiveaccess to remote hosts.

• RSH — Passes a command to aremote host for execution.

• REXEC – Authenticates and executesRCP and other commands.

• RMT/RCD – Provides remote accessto magnetic tape and CD-ROM drives.

In addition to password authentication, the R commandsuse a system based on trusted hosts and users. Trusted users on trusted hostsare allowed to access the local system without providing a password.

Trustedhosts are also called equivalent hosts because the software assumes that users who have accessto a remote host should be given equivalent access to the local host. Thesystem assumes that user accounts withthe same name on both hosts are ‘‘owned’’ by the sameuser. For example, the user logged in as BETHANY on a trusted system is grantedthe same access as a user logged in as BETHANY on the local system.Thisauthentication system requires databases that define the trusted hosts andthe trusted users. On UNIX systems, these databases are:

• /etc/hosts.equiv

— defines the trusted hosts and users forthe entire system.

• rhosts

— defines the trusted hosts and users foran individual user account. This file is located in the user’s homedirectory.

On OpenVMS hosts, the proxy database TCPIP$PROXY.DATdefines trusted hosts and trusted users for the entire system.

Eachof these topics is covered in detail in the CompaqTCP/IP Services for OpenVMS Management guide.

5.4.4 Differences Between FTP and RCP

UnlikeFTP, the RCP protocol provides no method of transferring file type informationbetween the sender and the recipient. It transfers only length, a modifiedand created timestamp, protection mode, and the byte stream of file data.As a result, RCP is unable to determine the file type of a file it receives.

Torevert the file type to a usable format in transfers between OpenVMS systems,if the original file is fixed length or undefined, you can change the attributeson the Stream_LF copy to correspond to the format of the original file. Todo so, enter the DCL command SET FILE in the following format:SETFILE/ATTR=(file-attribute[...])

For example, the following command transfers anOpenVMS executable image file (with a fixed record length of 512-bytes, andmakes the file executable again.

$ SET FILE/ATTR=(rfm:fix, lrl:512) rcp-copied-file.exe

Youcan also use a logical name to change the behavior set by the options.AlthoughRCP uses secure authentication for security, it has file size limitationsthat FTP does not have. FTP has no security; passwords are sent in ASCII.RCP sends only the length of the file (in ASCII format). OpenVMS interpretsthis length as a signed 32-bit integer. Therefore, files transferred usingRCP must no more than (2 GB -1) bytes (0x7FFFFFF=2147483647 bytes or roughly1 byte less than 4194304 RMS 512-byte blocks).

5.5 SimpleNetwork Management Protocol (SNMP)

The Simple Network Management Protocol (SNMP) isnetwork management technology that facilitates the management of a TCP/IPnetwork or internet in a vendor-independent manner. SNMP enables a networkadministrator to manage the various network components using a set of well-knownprocedures understood by all components, regardless of the original manufacturers.

ConfiguringSNMP on your OpenVMS system allows a remote SNMP management client to obtaininformation about your host and to set system and network parameters.5.5.1 Configuring SNMP

Systems using SNMP fall into two categories:

• Management consoles (sometimes calledclients, network management stations, or directors)

• Agents (sometimes called servers)

Themanagement console is the system that issues a query; the agents run on thesystem being queried. Queries are sent and received in the form of protocoldata units (PDUs) inside SNMP messages, which are carried in user data protocol(UDP) datagrams. You can configure your host so that an SNMP client can obtaininformation about your host and perform updates on your host’s managementinformation base (MIB) data items. For example, you can configure your hostto:

• Respond to a client’s read requests(Gets) for network information.

• Process client write requests (Sets)on your host’s MIB data items.

• Send alert messages (Traps)to a client as a result of events that might need to be monitored (for example,an authentication failure).

Table 5–3 describes the SNMP components andthe sample code supplied for custom subagent development.

Table 5–3 SNMP Components

Component	Description
Masteragent SNMP Version 2	Processname: TCPIP$SNMP_n. Keeps track ofmanaged objects and allows objects to register themselves. Sends informationabout these objects to remote SNMP management consoles. Also maintains a smallset of variables for the MIB II component.
MIBII	Processname: TCPIP$OS_MIBS. Provides information about the TCP/IP protocol stackand other network activity.
HostResources MIB	Processname: TCPIP$HR_MIB. Provides information about the host system.
MIBconverter	Extractsa MIB definition in ASN.1 notation into a MIB definition (.MY) file.
MIBcompiler	Compilesa MIB-definition files (for example, CHESS_MIB.MY) into source code templatesfor use in building subagents.
SNMPutility programs	Actsas a simple client to obtain a set of values for a MIB and to listen for andsend trap messages. For information about using the MIB utility programs,refer to the Compaq TCP/IP Services for OpenVMSSNMP Programming and Reference guide.
SNMPsubagent example	Implementsan example based on the chess game; includes executable and source code.

5.5.2 Ensuring Access to Mounted Data

Ifthe proxy setup between the SNMP server and the NFS server is not correct,the host resources MIB subagent cannot access data that has been mounted.

Toensure access to mounted data, set up a proxy to an anonymous user (for example, to TCPIP$NOBODY) on the NFS server system.For more information about adding proxy entries, refer to the CompaqTCP/IP Services for OpenVMS Management guide.

ForMore Information

For detailed information about the following topics,refer to the Compaq TCP/IP Services for OpenVMSManagement guide:

• Event logging

• Help interpreting an NTP logfile

• Configuring static routing

• Configuring dynamic routing

• Configuring the different types ofaddressing for clients on your network

• Configuring FTP

• Using R commandsFormore information about NTP OpenVMS issues, visit the OpenVMS FAQ web siteat:

http://www.openvms.compaq.com/wizard/

Searchon keyword NTP.For information about NTP time settings, refer to the OpenVMSSystem Manager’s Manual.

6 MailServices

Mail Services are an extremely important part ofTCP/IP Services. Everyone who uses the network — from administrators,to programmers, to users accesses — this service on a regular basis.This chapter describes Post Office Protocol (POP), SMTP, and IMAP.

Thingsto Consider

• What types of mail clients will Isupport?

• What types and sizes of files willthe mail system encounter?

6.1 Post Office Protocol (POP)

TheCompaq TCP/IP Services for OpenVMS Post Office Protocol (POP) server and theSMTP server work together to provide a reliable mail service. POP is a mailrepository used primarily by PCs to ensure that mail is accepted even whenthe PC is turned off. With POP, the PC user need not be concerned with configuringthe system as an SMTP server. The user logs on to the client system’smail application, and the POP server forwards any new mail messages from theOpenVMS NEWMAIL folder to the PC. The POP server is an OpenVMS implementationof the Post Office Protocol, Version 3 (RFC 1725) and is based on the IndianaUniversity POP server (IUPOP3).

The POP server is assigned port 110, and all POPclient connections are made to this port.

6.1.1 POP Server Process

The POP server is installed with SYSPRV and BYPASSprivileges and runs in the TCPIP$POP account, which receives the correct quotasfrom the TCPIP$CONFIG procedure. The POP server is invoked by the auxiliaryserver .

TCP/IPServices implements the UNIX internet daemon inetd

function, through the security and event loggingof the auxiliary server process. The auxiliary server simplifies applicationwriting and manages overhead by reducing simultaneous server processes onthe system. In addition, the auxiliary server does the following:

Manual	Contents
CompaqTCP/IP Services for OpenVMS Concepts and Planning	Thismanual introduces TCP/IP Services and provides conceptual and planning informationto help you configure and manage the product. This manual alsoprovides a glossary of terms and acronyms, lists the RFCs associated withthis product, and documents how to register your network and domain and nameservers.
CompaqTCP/IP Services for OpenVMS Release Notes	Thistext file describes new features and changes to the software, including installation,upgrade, configuration, and compatibility information. These notes also describenew and existing software problems and restrictions, and software and documentationcorrections. Printthis text file at the beginning of the installation procedure and read itbefore you install Compaq TCP/IP Services for OpenVMS.
CompaqTCP/IP Services for OpenVMS Installation and Configuration	Thismanual explains how to install and configure the Compaq TCP/IP Services forOpenVMS product.
CompaqTCP/IP Services for OpenVMS User’s Guide	Thismanual describes how to use the applications available with Compaq TCP/IPServices for OpenVMS, such as remote file operations, e-mail, TELNET, TN3270,and network printing. This manual also explains how to use these servicesto communicate with systems on private internets or on the worldwide Internet.
CompaqTCP/IP Services for OpenVMS Management	Thismanual describes how to configure and manage the Compaq TCP/IP Services forOpenVMS product. Use this manual with the CompaqTCP/IP Services for OpenVMS Management Command Reference manual.
CompaqTCP/IP Services for OpenVMS Management Command Reference	Thismanual describes the Compaq TCP/IP Services for OpenVMS management commands. Usethis manual with the Compaq TCP/IP Servicesfor OpenVMS Management manual.
CompaqTCP/IP Services for OpenVMS ONC RPC Programming	Thismanual presents an overview of high-level programming using open network computingremote procedure calls (ONC RPC). This manual also describes the RPC programminginterface and how to use the RPCGEN protocol compiler to create applications.
CompaqTCP/IP Services for OpenVMS Sockets API and System Services Programming	Thismanual describes how to use the Sockets API and OpenVMS system services todevelop network-based applications.
CompaqTCP/IP Services for OpenVMS SNMP Programming and Reference	Thismanual describes the Simple Network Management Protocol (SNMP) and the SNMPapplication programming interface (eSNMP). It describes the subagents providedwith TCP/IP Services, utilities provided for managing agents, and how to buildyour own subagents.
CompaqTCP/IP Services for OpenVMS Management Command Quick Reference Card	Thisreference card lists the TCP/IP management commands by component and describesthe purpose of each command.
CompaqTCP/IP Services for OpenVMS UNIX Command Reference Card	Thisreference card contains information about commonly performed network managementtasks and their corresponding TCP/IP management and Compaq Tru64 UNIX commandformats.
CompaqTCP/IP Services for OpenVMS Tuning and Troubleshooting	Thismanual provides information about how to isolate the causes of network problemsand how to tune the TCP/IP Services software for the best performance.
CompaqTCP/IP Services for OpenVMS Guide to IPv6	Thismanual describes the IPv6 environment, the roles of systems in this environment,the types and function of the different IPv6 addresses, and how to configureTCP/IP Services to access the 6bone network.

Method	Description
Sharedsecret password	Mostsecure POP server access method. Initiated by the client system through theAPOP command. Allows a user to become authorized by the POP serverwithout having to send a password over the network. Eliminates a potentialpath for unauthorized users to obtain a password and break into the system. POPrequires a shared secret password from any user who wants to read mail usingthe APOP authorization method. For information about creating the shared secretpassword, refer to the Compaq TCP/IP Servicesfor OpenVMS User’s Guide.
Username and password	Leastsecure POP server access method. Initiated by the client system through theUSER and PASS commands. The POP server authorizes the client to accessthe desired mailbox based on receipt of a valid user name and password.
OpenVMS SYSUAF settings on useraccounts	Accessto the POP server is not permitted if: • Either the DISMAIL or DISUSER flagsare set for the account. • The account has expired accordingto the SYSUAF expiration date. • Access has been denied because ofan incorrect user name and password.
Abilityto disable the USER and PASS commands	Allowsthe system manager to use the APOP authorization method for all POP clients,the more secure means of user authorization. When you disable the USER andPASS commands (by defining the logical name TCPIP$POP_DISUSERPASS), the POPserver responds to the commands with a failure message.

POPMessage Header	ObtainedFrom
Date:	Arrivaldate of message. Changed to UNIX format.
From:	OpenVMSmessage From: field.Rebuilt to ensure RFC 822 compatibility.
To:	OpenVMSMail To: field.Not rebuilt.
CC:	OpenVMSMail CC: field.Not rebuilt.
Subject:	OpenVMSMail Subj: field.Not rebuilt.
X-VMS-From:	OpenVMSMail From: field.Not rebuilt.
X-POP3-Server:	Serverhost name and POP version information. Sent only if logical name TCPIP$POP_SEND_ID_HEADERSis defined.
X-POP3-ID:	MessageUID. Sent only if logical name TCPIP$POP_SEND_ID_HEADERS is defined.

AddressType	AddressFormat
SMTP	SMTP%legal-address, where legal-address isan address that is compliant with RFC 822 and is commonly in the user@domain format.
DECnet	node::username
Username	username
DECnetaddress within quotation marks	node::"user@host"
Cluster-forwardingSMTP address	node::SMTP%”user@domain"

Command	Description
HELLO	Identifiesthe originating host to the server host. Use the /DOMAIN qualifier to providethe name of the originating host.
MAILFROM:<reverse-path>	Identifiesthe address at which undeliverable mail should be returned. Usually is theoriginating host.
RCPTTO:<forward-path>	Addressof the intended receiver. If sending mail to multiple recipients, use oneRCPT TO command for each recipient.
DATA	Signalsthe end of the RCPT TO commands and tells the recipient to prepare to receivethe message.
QUIT	Signalsthe end of the RCPT TO commands and tells the recipient to prepare to receivethe message.

IMAPMessage Header	ObtainedFrom
Date:	Arrivaldate of message. Changed to Internet format, which shows the day of the week,the date, the time, and the time zone offset from Greenwich Mean Time (GMT).An example of the format is Wed, 30 May 01 16:19:53 +0100.
From:	OpenVMSmessage From: field.Rebuilt to ensure RFC 822 compatibility.
To:	OpenVMSMail To: field.Rebuilt to ensure RFC 822 compatibility.
CC:	OpenVMSMail CC: field.Rebuilt to ensure RFC 822 compatibility.
Subject:	OpenVMSMail Subj: field.Accented characters are RFC 2047 encoded, but the change is not visible tousers because IMAP clients reverse the encoding.
X-VMS-From:	OpenVMSMail From: field.Not rebuilt.
X-IMAP4-Server:	Serverhost name and IMAP version information. Sent only if configuration optionSend-ID-Headers is set to True.
X-IMAP4-ID:	MessageUID. Sent only if configuration option Send-ID-Headers is set to True.

Character	Function	HexadecimalValue	DecimalValue
END	Marksthe end of the datagram. When the receiving SLIP encounters the END character,SLIP knows that it has a complete datagram.	C0	192
ESC	Indicatesthe end of the SLIP control characters.	DB	219

OpenVMSUser_name	TypeUser_ID	Group_ID	Host_name
ACCOUNT2	OND	15	15 *

TunnelConfiguration	Description	Describedin...
Router-to-routertunnel	Thev4/v6 routers are connected by an IPv4 infrastructure. For end-to-end communications,this represents only one segment of the total path.	Section9.3.3
Host-to-routertunnel	Thev4/v6 host and v4/v6 router are connected by an IPv4 infrastructure. For end-to-endcommunications, this represents the first segment of the total path.	Section9.3.1
Host-to-hosttunnel	Thev4/v6 hosts are connected by an IPv4 infrastructure. For end-to-end communications,this represents the total path since the tunnel spans the total path.
Router-to-hosttunnel	Thev4/v6 router and v4/v6 host are connected by an IPv4 infrastructure. For end-to-endcommunications, this represents the final segment of the total path.	Section9.3.2