Current Internet Drafts This summary sheet provides a short synopsis of each Internet Draft available within the "Internet-Drafts" Directory at the NIC and NNSC. These drafts are listed alphabetically by Working Group acronym and initial post date. Drafts not originating in a Working Group are listed first. Independant Submissions to Internet Drafts ------------------------------------------ "FTP-FTAM Gateway Specification", J.L. Mindel, R.L. Slaski, 06/18/1991, This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. The proposed application layer gateway is based on a set of mappings between the FTP and FTAM protocols. The gateway is comprised of a dual set of mappings: FTP to FTAM, and FTAM to FTP. Since the protocols have quite different command structures, the mappings between them are not one-to-one. "The IP Addressing Issue", Noel Chiappa, 03/27/1991, The packet layer of the IP architecture is about to enter a period of stress caused by deficiencies in the IP address. This stress is caused by a number of inter-related problems. This note describes these problems, lists some suggested solutions, and discusses pros and cons of each of those solutions. "Security Information Transfer Protocol (SITP)", J. Dempsey, C. Feil, N. Lewis,, 06/02/1992, This memo defines the Security Information Transfer Protocol (SITP) used to send and receive security information between systems in a TCP/IP network. An initiator can use SITP to request audit, discretionary access control lists, and other data from a responder. The responder handles the request and sets parameters or returns the requested data. SITP has been adopted by the Trusted System Interoperability Group as the protocol of choice for audit management. "Identity Server", D. Bernstein, 04/01/1992, It is common for Internet hosts to associate a relatively long-lived identifier, often called a username or owner name, to each TCP connection. The Identity Server announces the identifier associated with a particular TCP connection to the host on the other end of the connection. The Identity Server may be used on any host which associates a relatively long-lived identifier to each connection. Internet Accounting ------------------- "INTERNET ACCOUNTING: USAGE REPORTING ARCHITECTURE", C. Mills, K. Laube, G. Ruth,, 07/09/1992, This draft describes an architecture for Internet usage reporting. The usage reporting architecture specifies common metrics for measuring usage in an Internet environment. By using the same metrics, usage data can be exchanged and compared across multiple platforms. "Internet Accounting Meter Services MIB", C. Mills, C. Brooks, A. Owen,, 07/09/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining accounting information from network devices (meters). Applications Area ----------------- "THE TFTP PROTOCOL (REVISION 2)", K. Sollins, 05/13/1992, TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. IP over AppleTalk ----------------- "The Transmission of Internet Packets Over AppleTalk Networks", John Veizades, 03/12/1992, This document describes a protocol, called MacIP, that is used to transport IP datagrams on AppleTalk networks. This protocol was developed in order to connect Macintosh computers on AppleTalk networks to hosts on TCP/IP networks. Using the AppleTalk network layer protocol, IP datagrams can be transmitted through AppleTalk networks to gateways that decapsulate the IP datagrams and act as front-end protocol processors Macintosh hosts on AppleTalk internets. "SNMP over AppleTalk", G. Minshall, M. Ritter, 03/23/1992, This memo describes the method by which the Simple Network Management Protocol (SNMP) can be used over AppleTalk protocols instead of the Internet UDP/IP protocol stack. This specification is useful for network elements which have AppleTalk support but lack TCP/IP support. IP over Asynchronous Transfer Mode ---------------------------------- "Multiprotocol Interconnect over ATM", Juha Heinanen, 06/12/1992, ATM-based networks are of increasing interest for both local and wide area applications. This memo describes three different methods for carrying connectionless network interconnect traffic (routed and bridged PDUs) over an ATM network. The first method approaches ATM from the LAN perspective and does higher-layer protocol multiplexing by prefixing the carried PDU by an LLC/SNAP header. It is in the following called "LLC/SNAP Encapsulation". The second method is functionally equivalent to the first, but approaches ATM from the WAN perspective by prefixing the carried PDU by an NLPID/SNAP header. It is in the following called "NLPID/SNAP Encapsulation". The third method does the higher-layer protocol multiplexing implicitly by ATM Virtual Circuits (VCs) and is in the following called "VC Based Multiplexing". Border Gateway Protocol ----------------------- "Default Route Advertisement In The Border Gateway Protocol", Dimitry Haskin, 08/09/1991, The purpose of the default route advertisement capability is to advertise the IP address of a border gateway which can be used as the default next hop to destinations that are not listed explicitly in the BGP peer's routing table. This capability will allow hosts, that are unable to maintain a complete routing table (e.g. due to its size) to learn a border gateway that is ready to handle the default traffic. Also, in contrast to static defaults, if there is more than one default gateway, this would make it possible for a BGP speaker to express a preference for one over the other. "Multicast Communications Using BGP", Scott Brim, 09/09/1991, This Internet Draft is for information purposes, for use in the future. Based on initial explorations, the BGP Working Group of the IETF has decided not to make a permanent decision yet on how to route multicast packets, but to use Reverse Path Forwarding for the time being. This document describes the analysis done up to this point. It explores the most likely possibilities in detail and lays out the issues for examination, so that when and if the time comes that a decision is made to move away from Reverse Path Forwarding, the information needed to support the decision will be available. It does not attempt to compare the possible approaches exhaustively or to reach a conclusion about which is better. "BGP OSPF Interaction", Kannan Varadhan, 04/14/1992, This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will be run BGP with other ASBRs external to the AS, and OSPF as its IGP. "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, 06/17/1992, The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 and EGP usage in the NSFNET Backbone as described in RFC 1092 and RFC 1093. BGP-4 provides a new set of mechanisms for supporting classless interdomain routing. These mechanisms include support for advertising an IP prefix and eliminates the concept of network "class" within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. These changes provide support for the proposed supernetting scheme. Common Authentication Technology -------------------------------- "Generic Security Service Application Program Interface", John Linn, 06/19/1992, This Internet-Draft proposes a Generic Security Service Application Program Interface (GSS-API) definition, providing security services to callers in a generic fashion which is supportable with a range of underlying mechanisms and technologies. Security contexts are established between peers, accomplishing peer entity authentication and providing the basis for subsequent per-message data origin authentication, integrity, and confidentiality protection services in conjunction with those contexts. This memo defines GSS-API services and primitives at a level which is independent of underlying security mechanism and programming language environment, and is to be complemented by related documents defining parameter bindings for particular language environments and defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop a variety of underlying security mechanisms. "The Kerberos Network Authentication Service", John Kohl, B. Clifford Neuman, 07/01/1991, This DRAFT document gives an overview and specification of the Version 5 protocol for the Kerberos network authentication system. Version 4 is presently in production use at MIT's Project Athena, and at other Internet sites. "Generic Security Service Application Program Interface Overview and C bindings", John Wray, 07/10/1991, This draft document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other drafts. "Distributed Authentication Security Service", Charles Kaufman, 11/04/1991, This DRAFT document specifies the Services, Interfaces, Operation,and Protocols of the DASS Authentication Service. The DASS Authentication Service is used by applications to strongly authenticate and establish shared keys with peer applications. Distribution of this memo is unlimited. Connection IP ------------- "Notes for Application Implementors on ST-II Socket API", Charles Lynn, 03/11/1992, This memo presents the current specification of the Application Programming Interface used to access the services provided by the BBN implementation of the ST-II Protocol (RFC 1190). It is being circulated as a basis for discussion of a generic API. A generic API will allow application developers to implement applications capable of running on any ST-II implementation that conforms to the API. Comments and suggestions for the generic API are solicited from the community by the CIP Working Group. Some comments that have already been received are included in the Appendix. Commercial Internet Protocol Security Option -------------------------------------------- "Commercial IP Security Option", Trusted Sys Interop. Group (TSIG), 12/03/1991, This Internet Draft provides the high level specification for a Commercial IP Security Option (CIPSO). This new option is meant to complement, not replace, the existing IP security options and their successors. This draft reflects the version as approved by the CIPSO IETF Working Group. Dynamic Host Configuration -------------------------- "Clarifications and Extensions for the Bootstrap Protocol", Walt Wimer, 05/03/1991, Some aspects of the BOOTP protocol were rather loosely-defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthenthe specification in these areas. In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these. "Dynamic Host Configuration Protocol", R. Droms, 06/30/1992, The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of three components: a protocol for delivering host--specific configuration parameters from a DHCP server to a host; a mechanism for allocation of network addresses to hosts; and a protocol through which a collection of DHCP servers can cooperatively allocate network addresses from a shared pool of network addresses. "Interoperation Between DHCP and BOOTP", R. Droms, 06/30/1992, The Dynamic Host Configuration Protocol (DHCP) provides a superset of the functions provided by the Bootstrap Protocol (BOOTP). Some DHCP participants may not be configured so as to be compatible. This document describes the interactions between DHCP and BOOTP network participants and mechanisms for accommodating incompatibilities between DHCP participants. "DHCP Vendor Extensions", R. Droms, 06/30/1992, The Dynamic Host Configuration Protocol (DHCP) passes network configuration information to hosts on a TCP/IP network. This document defines the vendor extenstions that may appear in the 'vend' field in a DHCP message. Directory Information Services Infrastructure --------------------------------------------- "Interim Schema for Network Infrastructure Information in X.500 New name: Encoding Network Addresses to support operation ov", Chris Weider, Mark Knopper, 06/14/1991, As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory Information, it was perceived that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. This paper describes the interim schema used to contain this information. Domain Name System ------------------ "DNS MIB Extensions", Jon Saperia, 06/30/1992, This memo defines a set of DNS (Domain Name System) extensions that have been created for the Internet MIB. When used in conjunction with the Structure of Management Information (RFC1155), the Management Information Base for Network Management of TCP/IP-based internets (RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of DNS client and server software in standard TCP/IP based environments. This document was produced by the DNS working group. Ethernet MIB ------------ "Implementation Notes and Experience for The Internet Ethernet MIB", Frank Kastenholz, 03/24/1992, Abstract not provided. IEEE 802.3 Hub MIB ------------------ "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", Donna McMaster, Keith McCloghrie, 06/26/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs." Internet Architecture Board --------------------------- "IP Version 7", Internet Architecture Board, 07/01/1992, Internet growth has created serious problems of address space consumption and routing information explosion. A solution to these problems requires a new version of the Internet Protocol, which we call IP version 7 ("IPv7"). This memo presents architectural guidelines that any IPv7 should meet. It then discusses how an IPv7 based upon the OSI CLNP protocol would meet these requirements, and presents the reasons for the IAB's preference for this solution. Finally, it makes a three-part recommendation: (1) proceed at full speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3) continue to pursue research in advanced routing and other future extensions of the Internet architecture. TCP Client Identity Protocol ---------------------------- "Ident MIB", Michael St. Johns, Marshall Rose, 06/08/1992, This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 931. "Identification Server", Mike StJohns, 06/02/1992, The Identification Server Protocol provides a means to determine the identity of a user of a particular TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. The Identification Server Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. Inter-Domain Policy Routing --------------------------- "An Architecture for Inter-Domain Policy Routing", Marianne Lepp, Martha Steenstrup, 06/24/1992, We present an architecture for inter-domain policy routing (IDPR). The objective of inter-domain policy routing is to construct routes between source and destination administrative domains, that provide user traffic with the requested service within the constraints stipulated for the domains transited. The IDPR architecture is designed to accommodate an internetwork containing tens of thousands of administrative domains with heterogeneous service requirements and restrictions. "Inter-Domain Policy Routing Protocol Specification: Version 1", M. Steenstrup, 06/03/1992, We present the set of protocols and procedures that constitute inter-domain policy routing (IDPR). IDPR includes the virtual gateway protocol, the flooding protocol, the route server query protocol, the route generation procedure, the path control protocol, and the data message forwarding procedure. "Definitions of Managed Objects for the Inter-Domain Policy Routing Protocol (Version 1)", R.A. Woodburn, 04/01/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Inter-Domain Policy Routing Protocol. "Inter-Domain Policy Routing Configuration and Usage", H. Brown, M. Steenstrup, 07/25/1991, We present a set of configuration guidelines for inter-domain policy routing (IDPR). In particular, we discuss topology, addressing, policies, and interactions with both intra-domain and inter-domain routing. Also, we provide a copy of the IDPR configuration template and give examples of its use. "IDPR as a Proposed Standard", M. Steenstrup, 04/28/1992, The objective of IDPR is to construct and maintain routes between source and destination administrative domains, that provide user traffic with theand destination administrative domains, that provide user traffic with the services requested within the constraints stipulated for the domains transited. IETF Steering Group ------------------- "An Internet Evolution Plan for the IETF", Internet Engineering Steering Group, 07/23/1991, This document is a working paper by the IESG to guide future work in the Internet. The motivation for developing this document is to give specific shape and form to the general directions for IETF guidance that have developed in the IESG over the last 1-2 years. "IESG Recommendation for Internet Interior Gateway Routing Protocols", P. Gross, 07/25/1991, This document represents the consensus of the IESG in choosing a ``common'' Interior Gateway Protocol (IGP) for the TCP/IP protocol family. By ``common'', we simply mean a protocol that is ubiquitously available from all router vendors (as in `in common'). Users and network operators have expressed a strong need for routers from different vendors to have the capablity to interoperate within an AS through use of a common IGP. IP over Large Public Data Networks ---------------------------------- "Management Information Base for Frame Relay DTEs", Caralyn Brown, Fred Baker, Charles Carvalho,, 02/13/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Frame Relay. "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", A. G. Malis, D. Robinson, R. L. Ullmann,, 03/05/1992, This document was written to correct several ambiguities in the Internet Standard for IP/X.25 (RFC 877), aligning it with ISO/IEC standards that have been written following RFC 877, and adding some additional remarks based upon practical experience with the specification over the 8 years since that RFC. "Shortcut Routing: Discovery and Routing over Large Public Data Networks", P. Tsuchiya, J. Lawrence, 06/29/1992, Various RFCs and Internet Drafts specify how to run IP or CLNP over various public data network services. These documents specify the encapsulation to be used, and sometimes specify protocol techniques to aid in discovery and routing functions. None of the specifications, however, solve the problem of discovery and routing in the full, especially with respect to scaling. This RFC extends these specifications by describing a general and scalable technique, called shortcut routing, for discovery and routing of any connection-less internet protocol over any switched data network (connectionless or connection-oriented). "Directed ARP", John Garrett, John Hagan, Jeff Wong,, 06/19/1992, A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (via ICMP Redirects) and routers (via dynamic routing protocols). However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the "foreign" IP network to their corresponding link level addresses. Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. ISIS for IP Internets --------------------- "Integrated IS-IS Management Information Base", Chris Gunner, 11/13/1991, This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the operation of the Integrated IS-IS routing protocol. MHS-DS ------ "MHS use of the Directory to support distribution lists", S. Hardcastle-Kille, 07/07/1992, This document specifies a procedure for managing distribution lists using the directory. This is an extension of the mechanism defined in X.400. "Representing Tables and Subtrees in the Directory", S. Hardcastle-Kille, 07/07/1992, This document defines techniques for representing tables and subtrees in the OSI Directory. This technique is of general interest, but this work has been initiated towards the specific goal of supporting MHS use of Directory. "Use of the Directory to support routing for RFC 822 and related protocols", S. Hardcastle-Kille, 07/07/1992, This document defines a mechanism to route RFC 822 using the OSI Directory. The basic mechanisms are being developed for routing X.400. These offer a number of benefits relative to the mechanisms available for RFC 822 routing. The prime goal of this specification is to provide integrated routing management for sites using both RFC 822 and X.400. "Representing the O/R Address hierarchy in the Directory Information Tree", S. Hardcastle-Kille, 07/07/1992, This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. This is useful for a range of purposes, including Support for MHS Routing and Support for X.400/RFC 822 address mappings. "A simple profile for MHS use of Directory", S. Hardcastle-Kille, 07/07/1992, The document ``MHS Use of Directory to support MHS Routing'' describes a comprehensive approach to MHS use of directory to support routing. This document defines a strict subset of this document, which is intended to solve the most pressing problems. It also defines a practical first step for implementation, such that this subset can be deployed prior to fuller implementation. "Use of the Directory to support mapping between X.400 and RFC 822 Addresses", S. Hardcastle-Kille, 07/07/1992, This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1148. "MHS use of Directory to support MHS Routing", Steve Hardcastle-Kille, 07/07/1992, This document specifies an approach for X.400 Message Handling Systems to perform application level routing using the OSI Directory. Use of the directory in this manner is fundamental to enabling large scale deployment of X.400. MIME-MHS Interworking --------------------- "Equivalences between 1988 X.400 and RFC-822 Message Bodies", H. Alvestrand, S. Thomspon, 07/01/1992, Abstract not provided. "Mapping between X.400 and RFC-822 Message Bodies", H. Alvestrand, S. Hardcastle-Kille, R. Miles, M. Rose, S. Thompson,, 07/01/1992, Abstract not provided. Multicast Extensions to OSPF ---------------------------- "Multicast Extensions to OSPF", J. Moy, 11/12/1991, This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge. SNMP over a Multi-protocol Internet ----------------------------------- "SNMP over OSI", Marshall Rose, 07/07/1992, The document defines a mapping to allow the SNMP to be carried over the CLTS. The elements of procedure are identical to that of using the UDP. "SNMP over IPX", Steve Bostock, 06/23/1992, This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet (IPX) protocol. Network Database ---------------- "Network Database Protocol", Daisy Shen, 06/24/1992, This memo defines a protocol for use with relational database systems in a TCP/IP based internet environment. This protocol is intended to make interoperability among different database systems possible. It is built on RPC (Remote Procedure Call) with a client/server type of relationship. This document also defines the concept of Unit of Work. The work of Network Database is involved with Data Conversion, Security, I/O Buffer Management, and Transaction Management. They will be described one by one in this document. "Network Database Implementation Information Internet Draft", Daisy Shen, 06/24/1992, This document provides the implementation information of Network Database Protocol. The protocol is defined in the document of Network Database Protocol for use with relational database systems in a TCP/IP based Internet environment. This document will show readers some data structures and examples, and provide as much details information as possible. This document will go over each component one by one. Network Information Services Infrastructure ------------------------------------------- "Privacy and Accuracy Issues in Network Information Center Databases", J. Curran, A. Marine, 07/06/1992, This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. The purpose is to formalize procedures for the responsible handling of the personal and organizational information maintained by NICs in publically accessible databases, and to improve the accuracy and accessibility of such data where appropriate. Network News Transport Protocol ------------------------------- "Network News Transfer Protocol Version 2: A Protocol for the Stream-Based Transmission of News", Eliot Lear, 09/30/1991, This document is a revision based on RFC977 which it intends to obsolete. This draft contains a bunch of new ways for transport servers and clients to communicate with one another. Those interested in transport issues should comment on them without delay. This draft is mildly intertwined with a number of revisions going on in other areas, such as the IETF-SMTP and IETF-822 newsgroups. Dummy Working Group ------------------- "An Approach to CO/CL Interworking -- Part I: Introduction", COCL Workshop, M. Rose, 05/06/1991, The OSI transport service may be realized through a variety of transport/network protocol combinations. Regrettably, few of the combinations actually interoperate with each other. As such, even if all OSI-capable end-systems enjoyed full-connectivity, they would not be able to uniformly interoperate. This memo examines the problem and proposes an approach in order to develop solutions to this problem. "WORKSHOP ON CO/CL INTERWORKING", Phill Gross, Les Clyne, COCL Workshop,, 12/12/1990, On July 24-26, 1990, an invited panel met at the Corporation for National Research Initiatives in Reston Virginia to consider the issues involved with interworking between protocol stacks based on Connection-mode Network Service (CONS, or CO) and Connectionless-mode Network Service (CLNS, or CL). The main example of a CO stack is OSI TP0 over X.25. Examples of CL protocolstacks include OSI TP4 over CLNP and TCP over IP. The workshop was convened at the direction of RARE and the U.S. Federal Networking Council (FNC). The meeting was organized and co-chaired by Les Clyne (UK Joint Network Team) and Phillip Gross(Corporation for National Research Initiatives). An electronic mailing list was established for use by both attendees and a wider audience of experts. This report gives an overview and synopsis of the deliberations at the meeting, and it describes the outcome. "An Approach to CO/CL Interworking-- Part II: The Short-Term -- Conventions for Transport-Service Bridges in the Absence of Internetworking", COCL Workshop, M Rose, 04/23/1991, The Short-term approach outlined in ``An Approach to CO/CL Interworking: Part I: Introduction'' is based on the use of transport-layer relays known as transport service bridges, or TS-bridges. Further, the short-term approach also assumes that knowledge of the TS-bridges is present in the end-systems. The companion memo ``An Approach to CO/CL Interworking--Part III: The Intermediate-Term--Provision of the CONS over TCP and X.25 Subnetworks'' identifies solutions in which end-system knowledge of transport-layer relays is avoided. The purpose of this memo is two-fold: first, modifications to the operational characteristics of end-systems are described; and, second, the operational characteristics of TS-bridges are described. "The IP Network Address Translator (Nat): Preliminary Design", Paul Tsuchiya, 04/15/1991, The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. This paper discusses the characteristics of one of the proposed solutions-address reuse. The solution is to place Network Address Translators (Nat) at the borders of stub domains. Each Nat box has a small pool of globally unique IP addresses that are dynamically assigned to IP flows going through Nat. The dynamic assignment is coordinated with the Domain Name Servers. The IP addresses inside the stub domain are not globally unique-they are reused in other domains, thus solving the address depletion problem. The pool of IP addresses in Nat is from a subnet administered by the regional backbone, thus solving the scaling problem. The main advantage of Nat is that it can be installed without changes to routers or hosts. This paper presents a preliminary design for Nat, and discusses its pros and cons. "An Approach to CO/CL Interworking -- Part III: The Long-Term -- Conventions for Network-Layer Relays and Transport-Service Bridges in the presence of Internetworking", CO/CL Workshop, C. Huitema, 04/25/1991, The long-term approach is based on the use of transport-layer relays known as transport service bridges, or TS-bridges. Further, the long-term approach also assumes that knowledge of the TS-bridges is hidden from the end-systems. The companion memo identifies the short-term approach towards TS-bridges. The purpose of this memo is three-fold: first, to identify the infrastructure which is expected to exist in the long-term; second, to describe the use of NL-relays in such an environment. And, third, to describe the use of TS-bridges in such an environment. "An Approach to CO/CL Interworking -- Part II: Specification -- Conventions for Transport-Service Bridges", CO/CL Workshop, C. Huitema, 07/08/1991, This document outlines the conventions of Transport Service bridges following the approach described in "An Approach to CO/CL Interworking -- Part I: Introduction". This approach has been developed at the request of the FNC and RARE communities, but may be applicable to other communities. "International character support in SMTP", R. Ulmann, 10/18/1991, This memo describes an update to the SMTP protocol, and to the format of an Internet mail message, to provide support for the character sets used in the world's many languages. This memo documents existing usage as well as specifying some additional interoperability refinements. It updates RFCs 821, 822, and 1090. The Internet is no longer a creature of the United States, much less of DARPA (the US Defence Advance Research Projects Agency). It is now an international network, and the ability to communicate in any of the world languages on an equal footing is an imperative. "A New IP Routing and Addressing Architecture", J.N. Chiappa, 07/25/1991, This document presents one possible new IP routing and adressing architecture. By routing and addressing it is meant that part of the overall IP architecture which is responsible for identifying computing nodes, where they are in the Internet, and how to get traffic from one to another. It represents one person's view of a good overall system answer to this question, and is not to be taken as anything more than that. "IP and ARP on HIPPI", J. Renwick, A. Nicholson, 06/03/1992, The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. "Link Control Protocol", J. Young, A. Nicholson, 01/03/1992, While working with circuit-switched T3 networks, developers at Cray Research, Inc., defined a model wherein a host would generate control messages for a network switch. In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the control messages. To that end, a protocol was defined and implemented. This draft documents the Link Control Protocol (LCP), which is used for creation and control of downstream network links by a host. "A Method for the Transmission of IP Datagrams Over SNA Networks Using LU6.2 Conversations", H. Stevenson, S. Schwell, W. Siddall,, 05/29/1992, Proposes a method for the transmission of IP datagrams over SNA networks using Advanced Program to Program Communication (APPC) conversations, and requests discussion and suggestions for improvements. IP datagrams between two LU 6.2 nodes are transmitted as GDS records on a uni-directional conversation between a pair of sending and receiving transaction programs (TPs). "HYBRID NETBIOS END-NODES", F. Noon, 03/24/1992, STD-19/RFC-1001/RFC-1002 defines a "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport," or "NetBIOS-over-TCP" for short. STD-19 defines NetBIOS end-nodes as stations which "support NetBIOS service interfaces and contain applications." That standard describes three types of end-nodes: Broadcast nodes (B nodes), Point-to-point nodes (P nodes), and Mixed mode nodes (M nodes). This memo describes a fourth note type, a M node, which is basically a P node which can transmit UDP broadcasts to locate owners of NetBIOS names. "IDRP for IP", Susan Hares, 07/09/1992, IDRP is defined as the protocol for exchange of Inter-Domain routing information between routers to support forwarding of ISO 8473 PDUs (Connectionless Network Layer Protocol (CLNP)). This document contains the appropriate adaptation to the IDRP protocol definition that enables it to be used as protocol for exchange inter-autonomous system information among routers to support forwarding of IP packets across multiple autonomous systems. "Physical Link Security Type of Service", Donald Eastlake, III, 04/14/1992, This draft proposes a type of service to request maximum physical link security. This would be an addition to the types of service enumerated in draft-almquist-tos-02 (which is to be issued as a Proposed Standard). "A Revision to IP Address Classifications", F. Solensky, F. Kastenholz, 04/20/1992, This memo presents an extension to the method of classifying and assigning IP network numbers. It is intended to provide a work-around to the imminent exhaustion of assignable Class B network numbers (and, to a lesser extent, the recent growth of routes that need to be tracked in the NSFNet routing database) by defining the format of Class C-sharp (C#) IP addresses, consuming the upper half of the existing Class C numbering space. The manner in which these changes impact existing systems is also discussed. It is a product of a "birds-of-a-feather" (BoF) discussion held on July 31, 1991 at the twenty-first IETF conference in Atlanta, GA and subsequent discussions on the mailing list. It should be noted that this document does NOT solve the limitations inherent in the current routing architectures and technology that are discussed. These must wait until new architectures are developed. Specifically, the issue of scaling the size of future routing tables is only indirectly addressed. "UPS Management Information Base", M. Davison, R. Wasson, R. Draper, J. Case, 07/06/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing uninterruptable power supply (UPS) systems. "TAP", D. Bernstein, 05/19/1992, It is common for Internet hosts to associate a relatively long-lived identifier, commonly a "username" or "owner name," to each TCP connection. TAP announces the identifier associated with a particular TCP connection to the host on the other end of the connection. TAP may be used on any host which associates a relatively long-lived identifier to each connection. "Pip: The `P' Internet Protocol", P. Tsuchiya, 05/20/1992, Pip is an IP protocol that scales, encodes policy, and is high speed. The purpose of this draft is to explain the basic concepts behind Pip so that people can start thinking about potential pitfalls. I am proposing Pip as an alternative to the two "medium term" proposals that emerged from the Road (Routing and Addressing) group to deal with the dual IP problems of scaling and address depletion. Because this proposal, which represents new ideas, is competing with old (and therefore well thought-out) ideas, I wish to circulate it (and get the process started) as quickly as possible, albeit in not as complete a form as I would like. I expect to have a complete proposal by the beginning of September. There will be a plenary presentation and a BOF covering this material at the Boston meeting of IETF. "Guidelines for IP Address Allocation", Y. Rekhter, T. Li, 06/29/1992, This paper provides guidelines for allocating IP addresses in the Internet. These guidelines are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. "A Proposal for A Global Internet Addressing Scheme", Daniel Karrenberg, Bernhard Stockman, 05/28/1992, This is a proposal for a hierarchically based assignment of future IP addresses by distributed control of segments of the IP address space. "TN3287 Printer Specification", Cleve Graves, 06/05/1992, The purpose of the TN3287 protocol is to provide a general, bi-directional printer communications facility. It's primary goal is to allow a standard method of interfacing printer devices and printer-oriented processes to each other. This protocol will allow a TN3270 Client to process 3287 print data streams. This RFC supplements and extends the RFC 854, TELNET Protocol Specification. This RFC also presents an example of the correct implementation. "Pip Overview and Examples", Paul Tsuchiya, 06/28/1992, Pip is an internet protocol that scales efficiently encodes policy. It facilitates many advanced features, such as mobility and multiple defaults routing, and has a well-bounded routing table lookup, and is therefore fast. Pip is proposed as an alternative to the two "medium term" proposals that emerged from the Road (Routing and Addressing) group to deal with the dual IP problems of scaling and address depletion. "NET-UTF: International character set", R. L. Ullmann, 06/17/1992, The Internet is no longer a creature of the United States, much less of DARPA (the US Defence Advance Research Projects Agency). It is now an international network, and the ability to communicate in any of the world languages on an equal footing is an imperative. This draft attempts to track the development of ISO 10646, a moving target at this writing. The reference citation below is to the 2nd 10646 draft, for which balloting has just concluded. (June 1992). It is therefore expected that this memo will potentially change until the publication of IS 10646. Some of the following text refers to 10646 in the present tense, as if it is IS now; it should be understood in this context. "Son of IPSO A Generic IP Sensitivity Labeling Option", Michael C. StJohns, 06/17/1992, This document is a direct descendent of RFC1038 and RFC1108 and is a close cousin to the work done in the Commercial IP Security Option (CIPSO) Working Group of the Trusted Systems Interoperability Group. The original IP Security options defined by 1038 and 1108 were designed with one specific purpose in mind - to support the fielding of an IP packet encryption device called a BLACKER. Because of this, the definitions and assumptions in those documents were necessarily US Department of Defense and BLACKER centric. This document is meant to serve a larger community, while still meeting the needs of the 1038/1108 audience. "ISO Transport Protocol (ISO 8072 & ISO 8073) Management Information Base", Russell Blaesing, James Verploegh, 06/19/1992, This memo defines an experimental version of an ISO Transport Management Information Base for use with network management protocols. "A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses", R. Hinden, D. Crocker, 06/25/1992, The Internet currently is seeking a means of providing for long-term growth by increasing the amount of address space that is available for hosts and by decreasing the amount of table storage that is required for routers. One solution to these problems is a direct upgrade to a new version of IP. Another is to switch to use of a new protocol such as CLNP which has provisions for a larger and more hierarchical address space. Both require very substantial disruption to the IP installed base. This proposal describes an alternative which minimizes overall disruption and, in fact, entirely eliminates a significant portion of it. "Definitions of Managed Objects for the SONET Interface Type", Tracy Cox, Kaj Tesink, 06/30/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SONET objects. This document is a companion document with Definitions of Managed Objects for the DS1 and DS3 Interface Types, RFC1232 and RFC1233. "EIP: The Extended Internet Protocol a long-term solution to Internet address exhaustion", Zheng Wang, 07/02/1992, In this paper, we present the Extended Internet Protocol (EIP) which provides a long-term solution to Internet address exhaustion. What we propose here is not a new addressing and routing scheme, but a framework in which any addressing and routing schemes can be accommodated. The goal of EIP is to provide maximum flexibility to accommodate any addressing and routing schemes yet to maintain maximum backward compatibility with current IP. It can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. "Transmitting IP Traffic over LocalTalk Networks", C. Ranch, 07/10/1992, This draft document specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across LocalTalk. It is intended to supplement existing technology for enabling Apple Macintoshes with built-in LocalTalk network media to communicate with other IP hosts in a TCP/IP internet. Operational Statistics ---------------------- "A Model for Common Operational Statistics", Bernhard Stockman, 03/24/1992, This document describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. OSI Directory Services ---------------------- "Building an Internet Directory using X.500", S. Kille, 01/07/1991, The IETF has established a Working Group on OSI Directory Services. A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services. This document summarises the strategy established by the Working Group, and describes a number of RFCs which will be written in order to establish the technical framework. "Using the OSI Directory to Achieve User Friendly Naming", S. Kille, 01/30/1992, The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: 1) A user oriented notation and 2) Guessability. This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in the reference of "A String Representation of Distinguished Name", and it is intended that these specifications are compatible. "Handling QOS (Quality of service) in the Directory", S.E. Kille, 08/29/1991, This document describes a mechanism for specifying the Quality of Service for DSA Operations and Data in the Internet Pilot Directory Service ``Building and internet directory using X.500.'' "DSA Naming", S.E. Hardcastle-Kille, 01/24/1992, This INTERNET--DRAFT describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot, which overcomes a number of existing problems, and is an important component for the next stage in increase of scale. "Naming Guidelines for Directory Pilots", P. Barker, S.E. Hardcastle-Kille, 04/14/1992, Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. "Schema for Information Resource Description in X.500", Chris Weider, 06/14/1991, The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. "Interim Directory Tree Structure for Network Infrastructure Information", Chris Weider, Mark Knopper, Ruth Lang,, 06/14/1991, As work progresses on incorporating WHOIS and Network Infrastructure information into X.500, we thought it would be useful to document the current DIT structure for this information, along with some thoughts on future expansion and organization of this subtree of the DIT. The first section of this document describes the current structure, the second section the possible expansion of the structure. "Schema for NIC Profile Information in X.500", Chris Weider, Mark Knopper, 06/14/1991, The authors of this document, in conjuction with the chairs of the IETF Network Information Services Infrastructure (NISI) group, would like to implement a Directory of Network Information Centers, or NICs. This will enable NICs to find each other easily, will allow users with access to a DSA to find out where NICs are, and will in general facilitate the distribution of information about the Internet and some of its infrastructure. This Internet Draft proposes a set of standard schema for this information. "Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)", S.E. Hardcastle-Kille, 07/09/1991, This document specifies operational requirements for DUAs and DSAs in the Internet and COSINE communities. This document summarises conformance requirements. In most cases, technical detail is handled by reference to other documents. This document refers to core directory infrastructure. Each application using the directory may impose additional requirements. "An Access Control Approach for Searching and Listing", S.E. Hardcastle-Kille, T. Howes, 09/23/1991, This memo defines an extended ACL (Access Control List) mechanism for the OSI Directory. It is intended to meet strong operational requirements to restrict searching and listing externally, while allowing much more freedom within an organization. In particular, this mechanism makes it possible to restrict searches to certain sets of attributes, and to prevent ``trawling'': the disclosure of large organizational data or structure information by repeated searches or lists. This capability is necessary for organizations that want to hide their internal structure, or to prevent dumping of their entire database. This memo describes functionality beyond, but compatible with, that expected in the 1992 X.500 standard. "Representing Public Archives in the Directory", Wengyik Yeong, 12/04/1991, The proliferation of publicly accessible archives in the Internet has created an ever-widening gap between the fact of the existence of such archives, and knowledge about the existence and contents of these archives in the user community. Related to this problem is the problem of also providing users with the necessary information on the mechanisms available to retrieve such archives. In order for the Internet user community to better avail themselves of this class of resources, there is a need for these gaps in knowledge to be bridged. "A String Representation of Distinguished Names", S. E. Hardcastle-Kille, 04/15/1992, The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. "The Simple OSI Stack", S. E. Hardcastle-Kille, 03/09/1992, This document specifies a mapping of protocols defined by the Abstract Service Description Conventions onto Connection Oriented Transport Service, Connectionless Transport Service, TCP, and UDP [MHS88b]. This mapping will support all ROS (Remote Operation Service) based protocols, such as directory, both with and without use of RTS (Reliable Transfer Service), and all of the X.400 services [ISO88, CCI88, MHS88a]. Four example applications of the Simple OSI Stack (SOS) are given in appendices. These are all ``real'' examples, which will are quite likely to evolve into formal specifications. They are intended to show that specification of SOS applications is very straightforward and useful. These examples will be dropped from future versions of this document, and perhaps be replaced by artificial examples. "Counting the Directory Information Tree", Steve Hardcastle-Kille, 04/08/1992, Pilot Directory Services are growing rapidly. It is useful to know how much information is available in the directory. This is important for management purposes, both to understand the level of growth, and to provide publicity as to what is there. Current counting techniques are both ad hoc and implementation specific. "Lightweight Directory Access Protocol", Wengyik Yeong, Tim Howes, Steve Hardcastle-Kille,, 04/17/1992, The tremendous interest in X.500 technology in the Internet has lead to efforts to reduce the high ``cost of entry'' associated with use of the technology, such as the Directory Assistance Service and DIXIE. While efforts such as these have met with success, they have been solutions based on particular implementations and as such have limited applicability. This document continues the efforts to define Directory protocol alternatives but departs from previous efforts in that it consciously avoids dependence on particular implementations. The protocol described in this document is the first of a series of protocols designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself. "The String Representation of Standard Attribute Syntaxes", T. Howes, S. Hardcastle-Kille, W. Yeong, C. Robbins, 05/05/1992, The lightweight directory protocols require that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the lightweight directory protocols, then goes on to define the encoding rules for the standard set of attribute syntaxes. Assignment of OSI NSAP Addresses -------------------------------- "OSI NSAP Address Format For Use In The Internet", R Colella, R Callon, 02/13/1991, The Internet is moving towards a multi-protocol environment that includes OSI. To support OSI, it is necessary to address network layer entities and network service users. The basic principles of OSI Network Layer addressing and Network Service Access Points (NSAPs) are defined in Addendum 2 to the OSI Network service definition. This internet draft recommends a structure for the Domain Specific Part of NSAP addresses for use in the Internet that is consistent with these principles. Open Shortest Path First IGP ---------------------------- "OSPF Version 2 Traps", Rob Coltun, 07/23/1991, This draft document defines a set of traps, objects and mechanisms to enhance the ability to manage IP internetworks which use OSPF as its IGP. It is meant as an extension to the OSPF MIB. "Proposed modifications to RFC 1247", John Moy, 04/17/1992, This memo documents proposed modifications to the OSPF protocol. It is the intent that these modifications be folded into the OSPF specification, resulting in an update to RFC 1247. The modifications proposed herein are backward-compatible, and will not outdate any current OSPF implementations. Privacy-Enhanced Electronic Mail -------------------------------- "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", John Linn, 09/05/1991, This Internet-Draft defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. It is intended to become one member of a related set of four RFCs. The procedures defined in the current document are intended to be compatible with a wide range of key management approaches, including both symmetric (secret-key) and asymmetric (public-key) approaches for encryption of data encrypting keys. Use of symmetric cryptography for message text encryption and/or integrity check computation is anticipated. Related Internet-Drafts specify supporting key management mechanisms based on the use of public-key certificates, algorithms, modes, and associated identifiers, and details of paper and electronic formats and procedures for the key management infrastructure being established in support of these services. "Privacy Enhancement for Internet Electronic Mail: Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services", B. Kaliski, 07/10/1991, This document describes four services that top-level certification authorities (TLCAs) may provide in support of Internet Privacy-Enhanced Mail: notary certificate-signing services, co-issuer certificate-signing and certificate revocation list (CRL)-signing services, CRL-storing services, and CRL-retrieving services. "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", Steve Kent, 07/17/1991, This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. It defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients. "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", David Balenson, 08/22/1991, This document provides definitions, references, and citations for algorithms, usage modes, and associated identifiers and parameters used in support of privacy-enhanced mail (PEM) in the Internet community. It is intended to become one member of a set of four related RFCs. Point-to-Point Protocol Extensions ---------------------------------- "The Point-to-Point Protocol Configuration Options: Negotiation of 32-bit FCS", Arthur Harvey, 12/20/1990, This document defines a method to negotiate a 32-bit FCS Configuration Option for PPP. The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: "The Point-to-Point Protocol: LLC over PPP", Arthur Harvey, 12/20/1990, This document defines the operation of the LLC protocol over PPP. The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1) A method for encapsulating datagrams over serial links. 2) An extensible Link Control Protocol (LCP). 3) A family of Network Control Protocols (NCP) for establishing and configuring different network layer protocols. The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called the IP Control Protocol, IPCP) are defined in RFC 1171 ``The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links''. IEEE 802.2 Logical Link Control (LLC) protocol provides additional services beyond those available directly from the various IEEE 802 Medium Access Control (MAC) data link protocols. "Point-to-Point Protocol Extensions for DECnet Phase IV", Steven Senum, 06/17/1992, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT,etc). "The PPP AppleTalk Control Protocol (ATCP))", Brad Parker, 07/10/1992, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the AppleTalk Protocol over PPP. "PPP Authentication Protocols", B. Lloyd, W.A. Simpson, 05/20/1992, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines two protocols for Authentication: the Password Authentication Protocol, and the Challenge Handshake Authentication Protocol. "The PPP OSI Network Layer Control Protocol (OSINLCP)", D. Katz, 06/17/1992, The Point-to-Point Protocol (PPP) provides a standard method of method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring OSI Network Layer Protocols. "IPX PPP Internetwork Packet Exchange Control Protocol [IPXCP]", Michael Allen, 06/10/1992, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the IPX protocol over PPP and MUST be used in conjunction with the Informational RFC "Novell IPX Over Various WAN Media", June 1992, Michael Allen. "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", Frank Kastenholz, 06/22/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol", Frank Kastenholz, 06/22/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols. "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", Frank Kastenholz, 06/22/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols. "The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol", Frank Kastenholz, 06/22/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. RIP Version II -------------- "RIP Version 2 Carrying Additional Information", Gary Malkin, 07/06/1992, This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP packets and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2. "RIP Version 2 MIB Extension", Gary Malkin, Fred Baker, 05/07/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects (in addition to those in the MIB-II RIP Group) for managing RIP Version 2. Remote LAN Monitoring --------------------- "SNMP Trap Definitions For Remote Network Monitoring", Steven Waldbusser, 08/22/1991, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines trap objects for use in remote network monitoring devices. Router Requirements ------------------- "Requirements for Internet IP Routers", Philip Almquist, 10/02/1991, This draft defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as ``routers''. This document is intended to provide guidance for vendors, implementors, and purchasers of IP routers. "Ruminations on Route Leaking", Philip Almquist, 07/25/1991, This memo discusses how routers can "leak" routing information learned from one routing domain into another routing domain. Although this memo is not an official product of the Router Requirements working group, it is being published as an Internet Draft because it is required reading for those who wish to actively participate in the Router Requirements sessions during the IETF meeting in Atlanta. "Ruminations on the Next Hop", Philip Almquist, 07/25/1991, This memo discusses how routers do, can, and should decide how to use the routing information available to them to route packets. It is particularly concerned with the problems of border routers and other routers which have to choose from among routes learned from the multiple routing domains, often using different routing protocols. Although this memo is not an official product of the Router Requirements working group, it is being published as an Internet Draft because it is required reading for those who wish to actively participate in the Router Requirements sessions during the IETF meeting in Atlanta. "Some Thoughts on Multi-Domain Routing", Ross Callon, 07/25/1991, Frequently a router may have multiple sources of information about paths through the network. For example, a router may be simultaneously learning routes from multiple routing domains, and may have static routes configured by the network manager. This paper resents a proposal for control of interactions between multiple routing protocols, including choice of routes when multiple IP routing protocols are being used simultaneously, as well as exchange of routes between routing protocols. Internet Mail Extensions ------------------------ "SMTP Extensions for Transport of Enhanced Text-Based Messages", John Klensin, 06/24/1992, A series of extensions and clarifications are provided for the Simple Mail Transfer Protocol specified by RFC-821. In combination, they provide for the transport of "8 bit mail", i.e., data characters with all bits of the octets used for information, for more robust and efficient handling of large messages, and for an improved foundation for any future extensions to SMTP. Simple Network Management Protocol ---------------------------------- "Proxy between SNMP Transport Mappings", Marshall Rose, Keith McCloghrie, 03/12/1992, This memo suggests a straight-forward approach toward describing SNMP transport mappings so as to allow easy description of proxy relationships in implementations. TELNET ------ "Telnet Data Encryption Option", Dave Borman, 07/10/1991, This document defines an option for encrypting telnet sessions. "Telnet Data Compression Option", Dave Borman, 04/30/1990, "Telnet Authentication Option", Dave Borman, 07/09/1992, No abstract provided. "Telnet Authentication Option", Dave Borman, 07/09/1992, No abstract provided. "Telnet Authentication: Kerberos Version 4", D. Borman, 07/09/1992, No abstract provided. "Telnet Environment Option", D. Borman, 07/02/1992, This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. Distribution of this memo is unlimited. "Telnet Authentication: Kerberos Version 5", D. Borman, 03/03/1992, No abstract provided. "Telnet Remote Flow Control Option", C. Hedrick, D. Borman, 06/29/1992, This memo describes a method of remotely toggling flow control between a user telnet process and the attached terminal. Only flow control of data being transmitted from the telnet process to the terminal is considered. Many systems will also allow flow control of data from the terminal to the telnet process, however there is seldom need to change this behavior repeatedly during the session. "Telnet Authentication : SPX", Kannan Alagappan, 07/09/1992, No Abstract provided. Trusted Network File Systems ---------------------------- "A Specification of Trusted NFS (TNFS) Protocol Extensions", Fred Glover, 07/23/1991, This draft document specifies extensions to RFC 1094 which support network file access in a multilevel secure (MLS) network environment. User Connectivity ----------------- "FYI on an Internet Trouble Ticket Tracking System for addressing Internet User Connectivity Problems", M. Mathis, D. Long, 11/12/1991, Users having trouble with the Internet are directed to contact their designated Network Service Center. The Network Service Center creates a Trouble Ticket which is registered with the Ticket Tracking System. The ticket is an agreement to obtain closure with the user. Network Service Centers can fix problems, track the work of others, or transfer responsibility for the ticket to other Network Service Centers using a formal hand-off procedure. Ticket hand-offs are coordinated by the Ticket Tracking System and ticket progress is monitored by the Ticket Support Centers. User complaints with the problem resolution process may be lodged with a Ticket Support Center, which will act on behalf of the user in resolving the problem. X.25 Management Information Base -------------------------------- "SNMP MIB extension for MultiProtocol Interconnect over X.25", Dean Throop, 06/10/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MultiProtocol Interconnect (including IP) traffic carried over X.25. The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25", "SNMP MIB extension for LAPB", and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of the traffic over an X.25 protocol stack. "SNMP MIB extension for the X.25 Packet Layer", Dean Throop, 06/26/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Packet Layer of X.25. The objects defined here, along with the objects in the "SNMP MIB extension for LAPB" and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of an X.25 protocol stack. "SNMP MIB extension for LAPB", Dean Throop, Fred Baker, 06/12/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25" and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of an X.25 protocol stack. X.400 Operations ---------------- "Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)", Claudio Allocchio, 03/03/1992, This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 (1984/1988) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme. The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations. "Routing coordination for X.400 MHS services within a multi protocol / multi network environment", U. Eppenberger, 03/03/1992, This memo defines a specification on how the routing of X.400 services within the Internet community and other networking communities can be managed. "Operational Requirements for X.400 Management Domains", Robert Hagens, Alf Hansen, 06/19/1992, Abstract not provided. "X.400 use of extended character sets", Harald Alvestrand, 06/18/1992, Abstract not provided.