476 TCP/IP Tutorial and Technical Overview LDAP interface for the GDA One way LDAP is being integrated into DCE is to allow DCE cells to be registered in LDAP directories. The GDA in a cell that wants to connect to remote cells is configured to enable access to the LDAP directory (see Figure 12-17). Figure 12-17 The LDAP interface for GDA DCE originally only supported X.500 and DNS name syntax for cell names. LDAP and X.500 names both follow the same hierarchical naming model, but their syntax is slightly different. X.500 names are written in reverse order and use a slash (/) rather than a comma (,) to separated relative distinguished names. When the GDA is configured to use LDAP, it converts cell names in X.500 format into the LDAP format. LDAP interface for the CDS DCE provides two programming interfaces to the Directory Service; Name Service Interface (NSI) and the X/Open Directory Service (XDS). XDS is an X.500-compatible interface used to access information in the GDS, and it can also be used to access information in the CDS. However, the use of NSI is much more common in DCE applications. The NSI API provides functionality that is specifically tailored for use with DCE client and server programs that use RPC. NSI allows servers to register their address and the type of RPC interface they support. This address/interface information is called an RPC binding, and is Chapter 12. Directory and naming protocols 477 needed by clients that want to contact the server. NSI allows clients to search the CDS for RPC binding information. NSI was designed to be independent of the directory where the RPC bindings are stored. However, the only supported directory to date has been CDS. NSI will be extended to also support adding and retrieving RPC bindings from an LDAP directory. This will allow servers to advertise their RPC binding information in either CDS or an LDAP directory. Application programs can use either the NSI or the LDAP API when an LDAP directory is used (see Figure 12-18). Figure 12-18 The LDAP interface for NSI 12.4.8 The Directory-Enabled Networks (DEN) initiative In September 1997, Cisco Systems Inc. and Microsoft® Corp. announced the so-called Directory-Enabled Networks (DEN) initiative as a result of a collaborative work. Many companies, such as IBM, either support this initiative or actively participate in ad hoc working groups (ADWGs). DEN represents an information model specification for an integrated directory that stores information about people, network devices, and applications. The DEN schema defines the object classes and their related attributes for those objects. As such, DEN is a 478 TCP/IP Tutorial and Technical Overview key piece to building intelligent networks, where products from multiple vendors can store and retrieve topology and configuration-related data. Of special interest is that the DEN specification defines LDAPv3 as the core protocol for accessing DEN information, which makes information available to LDAP-enabled clients or network devices, or both. DEN makes use of the Common information Model (CIM). CIM details a way of integrating different management models such as SNMP MIBs and DMTF MIFs. At the time of writing, the most current CIM schema was version 2.12, released in April of 2006. More information about the DEN initiative can be found on the founder’s Web at: http://www.dmtf.org/standards/wbem/den/ http://www.dmtf.org/standards/cim/ 12.4.9 Web-Based Enterprise Management (WBEM) WBEM is a set of standards designed to deliver an integrated set of management tools for the enterprise. By making use of XML and CIM, it becomes possible to manage network devices, desktop systems, telecom systems and application systems, all from a Web browser. For further information, see: http://www.dmtf.org/standards/wbem/ 12.5 RFCs relevant to this chapter The following RFCs provide detailed information about the directory and naming protocols and architectures presented throughout this chapter: RFC 1032 – Domain administrators guide (November 1987) RFC 1033 – Domain administrators operations guide (November 1987) RFC 1034 – Domain names - concepts and facilities (November 1987) RFC 1035 – Domain names - implementation and specifications (November 1987) RFC 1101 – DNS encoding of network names and other types (April 1989) RFC 1183 – New DNS RR Definitions (October 1990) RFC 1202 – Directory Assistance service (February 1991) RFC 1249 – DIXIE Protocol Specification (August 1991) RFC 1348 – DNS NSAP RRs (July 1992) Chapter 12. Directory and naming protocols 479 RFC 1480 – The US Domain (June 1993) RFC 1706 – DNS NSAP Resource Records (October 1994) RFC 1823 – The LDAP Application Programming Interface (August 1995) RFC 1876 – A Means for Expressing Location Information in the Domain Name System (January 1996) RFC 1995 – Incremental Zone Transfer in DNS (August 1996) RFC 1996 – A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (August 1996) RFC 2136 – Dynamic Updates in the Domain Name System (DNS UPDATE) (April 1997) RFC 2444 – The One-time-Password SASL Mechanism (October 1998) RFC 4592 – The Role of Wildcards in the Domain Name System (July 2006) RFC 2743 – Generic Security Service Application Program Interface Version 2, Update 1 (January 2000) RFC 2874 – DNS Extensions to Support IPv6 Address Aggregation and Renumbering (July 2000) RFC 3007 – Secure Domain Name Systems (DNS) Dynamic Update (November 2000) RFC 3494 – Lightweight Directory Access protocol version 2 (LDAPv2) (March 2003) RFC 3596 – DNS Extensions to Support IP Version 6 (October 2003) RFC 3645 – Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) (October 2003) RFC 3901 – DNS IPv6 Transport Operational Guidelines (September 2004) RFC 4033 – DNS Security Introduction and Requirements (March 2005) RFC 4034 – Resource Records for the DNS Security Extensions (March 2005) RFC 4035 – Protocol Modifications for the DNS Security Extensions (March 2005) RFC 4339 – IPv6 Host Configuration of DNS Server Information Approaches (February 2006) RFC 4398 – Storing Certificates in the Domain Name System (DNS) (March 2006) RFC 4422 – Simple Authentication and Security Layer (SASL) (June 2006) RFC 4501 – Domain Name System Uniform Resource Identifiers (May 2006) 480 TCP/IP Tutorial and Technical Overview RFC 4505 – Anonymous Simple Authentication and Security Layer (SASL) (June 2006) RFC 4510 – Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map (June 2006) RFC 4511 – Lightweight Directory Access Protocol (LDAP): The Protocol (June 2006) RFC 4512 – Lightweight Directory Access Protocol (LDAP): Directory Information Models (June 2006) RFC 4513 – Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms (June 2006) RFC 4514 – Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names (June 2006) RFC 4515 – Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters (June 2006) RFC 4516 – Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator (June 2006) RFC 4517 – Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules (June 2006) RFC 4518 – Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation (June 2006) RFC 4519 – Lightweight Directory Access Protocol (LDAP): Schema for User Applications (June 2006) RFC 4520 – Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (June 2006) RFC 4521 – Considerations for Lightweight Directory Access Protocol (LDAP) (June 2006) RFC 4522 – Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option (June 2006) RFC 4523 – Lightweight Directory Access Protocol (LDAP): Schema Definitions for X.509 Certificates (June 2006) RFC 4524 – Lightweight Directory Access Protocol (LDAP): COSINE/LDAP X.500 Schema (June 2006) RFC 4525 – Lightweight Directory Access Protocol (LDAP): Modify-Increment Extension (June 2006) RFC 4526 – Lightweight Directory Access Protocol (LDAP): Absolute True and False Filters (June 2006) Chapter 12. Directory and naming protocols 481 RFC 4527 – Lightweight Directory Access Protocol (LDAP): Read Entry Controls (June 2006) RFC 4528 – Lightweight Directory Access Protocol (LDAP): Assertion Control (June 2006) RFC 4529 – Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP) (June 2006) RFC 4530 – Lightweight Directory Access Protocol (LDAP): entryUUID Operational Attribute (June 2006) RFC 4531 – Lightweight Directory Access Protocol (LDAP): Turn Operation (June 2006) RFC 4532 – Lightweight Directory Access Protocol (LDAP): “Who Am I?” Operation (June 2006) RFC 4533 – Lightweight Directory Access Protocol (LDAP): Content Synchronization Operation (June 2006) 482 TCP/IP Tutorial and Technical Overview © Copyright IBM Corp. 1989-2006. All rights reserved. 483 Chapter 13. Remote execution and distributed computing One of the most fundamental mechanisms employed on networked computers is the ability to execute on the remote systems. That is, a user wants to invoke an application on a remote machine. A number of application protocols exist to allow this remote execution capability, most notably the Telnet protocol. This chapter discusses some of these protocols. In addition, we discuss the concept of distributed computing. 13 484 TCP/IP Tutorial and Technical Overview 13.1 Telnet Telnet is a standard protocol with STD number 8. Its status is recommended. It is described in RFC 854 – Telnet Protocol Specifications and RFC 855 – Telnet Option Specifications. The Telnet protocol provides a standardized interface, through which a program on one host (the Telnet client) can access the resources of another host (the Telnet server) as though the client were a local terminal connected to the server. See Figure 13-1 for more details. For example, a user on a workstation on a LAN can connect to a host attached to the LAN as though the workstation were a terminal attached directly to the host. Of course, Telnet can be used across WANs as well as LANs. Figure 13-1 Telnet operation Most Telnet implementations do not provide you with graphics capabilities. 13.1.1 Telnet operation Telnet protocol is based on three ideas: The Network Virtual Terminal (NVT) concept. An NVT is an imaginary device with a basic structure common to a wide range of real terminals. Each host maps its own terminal characteristics to those of an NVT and assumes that every other host will do the same. Workstation Terminal Host LAN Remote Login Local Login Chapter 13. Remote execution and distributed computing 485 A symmetric view of terminals and processes. Negotiation of terminal options. The principle of negotiated options is used by the Telnet protocol, because many hosts want to provide additional services, beyond those available with the NVT. Various options can be negotiated. The server and client use a set of conventions to establish the operational characteristics of their Telnet connection through the “DO, DONT, WILL, WONT” mechanism discussed later in this chapter. The two hosts begin by verifying their mutual understanding. After this initial negotiation is complete, they are capable of working on the minimum level implemented by the NVT. After this minimum understanding is achieved, they can negotiate additional options to extend the capabilities of the NVT to reflect more accurately the capabilities of the real hardware in use. Because of the symmetric model used by Telnet (see Figure 13-2), both the host and the client can propose additional options to be used. Figure 13-2 Telnet negotiations 13.1.2 Network Virtual Terminal The NVT has a printer (or display) and a keyboard. The keyboard produces outgoing data, which is sent over the Telnet connection. The printer receives the incoming data. The basic characteristics of an NVT, unless they are modified by mutually agreed options, are: The data representation is 7-bit ASCII transmitted in 8-bit bytes. The NVT is a half-duplex device operating in a line-buffered mode. Operating System Operating System TCP/IP TCP/IP TelnetTelnet Telnet NVT NVT Host A Host B Negotiations [...]... options, and the reader should consult STD 1 – Official Internet Protocol Standards for the standardization state and status for each of them At the time of writing, the following options were defined (Table 13-2) Table 13-2 Telnet options Number Name State RFC STD 0 Binary transmission Standard 8 56 27 1 Echo Standard 857 28 3 Suppress Go Ahead Standard 858 29 5 Status Standard 859 30 6 Timing mark Standard... 164 7 37 488 Name Telnet authentication option Experimental 14 16 TCP/IP Tutorial and Technical Overview STD Number Name State 41 Telnet xauth Experimental 42 Telnet charset Experimental 43 Telnet remote serial port Experimental 44 Telnet com port control Experimental RFC STD 2 066 2217 All of the standard options have a status of recommended and the remainder have a status of elective There is a historic... a set of open standard services and associated APIs, used to support the development and administration of distributed applications in a multiplatform, multivendor environment 4 96 TCP/IP Tutorial and Technical Overview DCE is the result of work from the Open Systems Foundation, or OSF (now called The Open Group), a collaboration of many hardware vendors, software vendors, clients, and consulting firms... characters Command Action NULL (NUL) 0 No operation Line feed (LF) 10 Moves printer to next line, keeping the same horizontal position Carriage return (CR) 13 Moves the printer to the next left margin BELL (BEL) 7 Produces and audible or visible signal Backspace (BS) 4 86 ASCII 8 Moves print head one character position towards the left margin TCP/IP Tutorial and Technical Overview Command ASCII Action... Telnet commands consist of 2- or 3-byte sequences, depending on the command type Chapter 13 Remote execution and distributed computing 489 The Interpret As Command (IAC) character is followed by a command code If this command deals with option negotiation, the command will have a third byte to show the code for the referenced option See Figure 13-4 for more details Interpret as Command Command Code byte... 43 row x 80 col display IBM-3278-5 IBM-3278-5-E 27 row x 132 col display IBM-DYNAMIC n/a n/a Table 13 -6 TN3270E device-type: Printer Printer IBM-3287-1 494 TCP/IP Tutorial and Technical Overview Because the 3278 and 3287 are commonly used devices, device-types are restricted to 3278 and 3287 terminal and printer types to simplify the negotiation This does not mean that other types of devices cannot be... Output horizontal tab disposition Proposed 65 4 13 Output form feed disposition Proposed 65 5 14 Output vertical tab stops Proposed 65 6 15 Output vertical tab disposition Proposed 65 7 16 Output line feed disposition Proposed 65 8 17 Extended ASCII Proposed 69 8 18 Logout Proposed 727 19 Byte macro Proposed 735 20 Data entry terminal Proposed 1043 21 SUPDUP Proposed 7 36 22 SUPDUP output Proposed 749 23 Send... Telnet option 36 and was defined in RFC 1408 Full-screen capability Full-screen Telnet is possible provided the client and server have compatible full-screen capabilities For example, VM and MVS provide a TN3270-capable server To use this facility, a Telnet client must support TN3270 13.1.4 Telnet command structure The communication between client and server is handled with internal commands, which are... automatic login and user authentication when a user ID and password are entered The REXEC command is used to define the user ID, password, host address, and the process to be started on the remote host However, RSH does not require you to send a user name and password; it uses a host access file instead Both server and client are linked over the TCP/IP network REXEC uses TCP port 512 and RSH uses TCP... mark Standard 860 31 255 Extended options list Standard 861 32 34 Linemode Draft 1184 2 Reconnection Proposed 4 Approximate, message size negotiation Proposed 7 Remote controlled trans and echo Proposed 8 Output line width Proposed 9 Output page size Proposed 10 Output carriage-return disposition Proposed 65 2 11 Output horizontal tab stops Proposed 65 3 7 26 Chapter 13 Remote execution and distributed . position. Command ASCII Action Number Name State RFC STD 0 Binary transmission Standard 8 56 27 1 Echo Standard 857 28 3 Suppress Go Ahead Standard 858 29 5 Status Standard 859 30 6 Timing mark Standard 860 . disposition Proposed 65 2 11 Output horizontal tab stops Proposed 65 3 488 TCP/IP Tutorial and Technical Overview 12 Output horizontal tab disposition Proposed 65 4 13 Output form feed disposition Proposed 65 5 14. RFC STD 490 TCP/IP Tutorial and Technical Overview The Interpret As Command (IAC) character is followed by a command code. If this command deals with option negotiation, the command will have