Internet Documents

RFCs 1900 - 1999s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 1900 Renumbering Needs Work
 
Authors:B. Carpenter, Y. Rekhter.
Date:February 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1900
Renumbering, i.e., changes in the IP addressing information of various network components, is likely to become more and more widespread and common. The Internet Architecture Board (IAB) would like to stress the need to develop and deploy solutions that would facilitate such changes.
 
RFC 1901 Introduction to Community-based SNMPv2
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1901
The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.
 
RFC 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt json html
Obsoletes:RFC 1442
Obsoleted by:RFC 2578
Status:DRAFT STANDARD
DOI:10.17487/RFC 1902
It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]
 
RFC 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt json html
Obsoletes:RFC 1443
Obsoleted by:RFC 2579
Status:DRAFT STANDARD
DOI:10.17487/RFC 1903
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]
 
RFC 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt html json
Obsoletes:RFC 1444
Obsoleted by:RFC 2580
Status:DRAFT STANDARD
DOI:10.17487/RFC 1904
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]
 
RFC 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt html json
Obsoletes:RFC 1448
Obsoleted by:RFC 3416
Status:DRAFT STANDARD
DOI:10.17487/RFC 1905
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]
 
RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt json html
Obsoletes:RFC 1449
Obsoleted by:RFC 3417
Status:DRAFT STANDARD
DOI:10.17487/RFC 1906
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]
 
RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt json html
Obsoletes:RFC 1450
Obsoleted by:RFC 3418
Status:DRAFT STANDARD
DOI:10.17487/RFC 1907
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]
 
RFC 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework
 
Authors:J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
Date:January 1996
Formats:txt html json
Obsoletes:RFC 1452
Obsoleted by:RFC 2576
Status:DRAFT STANDARD
DOI:10.17487/RFC 1908
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1>. [STANDARDS-TRACK]
 
RFC 1909 An Administrative Infrastructure for SNMPv2
 
Authors:K. McCloghrie, Ed..
Date:February 1996
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1909
It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1910 User-based Security Model for SNMPv2
 
Authors:G. Waters, Ed..
Date:February 1996
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1910
In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1911 Voice Profile for Internet Mail
 
Authors:G. Vaudreuil.
Date:February 1996
Formats:txt html json
Obsoleted by:RFC 2421, RFC 2422, RFC 2423
Status:EXPERIMENTAL
DOI:10.17487/RFC 1911
The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1912 Common DNS Operational and Configuration Errors
 
Authors:D. Barr.
Date:February 1996
Formats:txt json html
Obsoletes:RFC 1537
Status:INFORMATIONAL
DOI:10.17487/RFC 1912
This memo describes errors often found in both the operation ofDomain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537].
 
RFC 1913 Architecture of the Whois++ Index Service
 
Authors:C. Weider, J. Fullton, S. Spero.
Date:February 1996
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 1913
The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol.
 
RFC 1914 How to Interact with a Whois++ Mesh
 
Authors:P. Faltstrom, R. Schoultz, C. Weider.
Date:February 1996
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1914
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]
 
RFC 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol
 
Authors:F. Kastenholz.
Date:February 1996
Formats:txt html json
Also:BCP 0003
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1915
The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
 
RFC 1916 Enterprise Renumbering: Experience and Information Solicitation
 
Authors:H. Berkowitz, P. Ferguson, W. Leland, P. Nesser.
Date:February 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1916
Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. To this end the working group is soliciting information from organizations that already have gone through, or are in the process of going through, renumbering efforts. Case studies, tools, and lists of applications that require special attention are sought.
 
RFC 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA
 
Authors:P. Nesser II.
Date:February 1996
Formats:txt json html
Also:BCP 0004
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1917
This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to theInternet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. Similarly an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment.
 
RFC 1918 Address Allocation for Private Internets
 
Authors:Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear.
Date:February 1996
Formats:txt html json
Obsoletes:RFC 1627, RFC 1597
Updated by:RFC 6761
Also:BCP 0005
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1918
This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
 
RFC 1919 Classical versus Transparent IP Proxies
 
Authors:M. Chatel.
Date:March 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1919
Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control. This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems.
 
RFC 1920 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:March 1996
Formats:txt html json
Obsoletes:RFC 1880
Obsoleted by:RFC 2000
Status:HISTORIC
DOI:10.17487/RFC 1920
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1921 TNVIP Protocol
 
Authors:J. Dujonc.
Date:March 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1921
The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network.
 
RFC 1922 Chinese Character Encoding for Internet Messages
 
Authors:HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin.
Date:March 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1922
This memo describes methods of transporting Chinese characters inInternet services which transport text, such as electronic mail[RFC-822], network news [RFC-1036], telnet [RFC-854] and the WorldWide Web [RFC-1866].
 
RFC 1923 RIPv1 Applicability Statement for Historic Status
 
Authors:J. Halpern, S. Bradner.
Date:March 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1923
RIP Version 1 [RFC-1058] has been declared an historic document.This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is theClassful nature of RIPv1.
 
RFC 1924 A Compact Representation of IPv6 Addresses
 
Authors:R. Elz.
Date:1 April 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1924
This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1925 The Twelve Networking Truths
 
Authors:R. Callon.
Date:1 April 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1925
This memo documents the fundamental truths of networking for theInternet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.
 
RFC 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM
 
Authors:J. Eriksson.
Date:1 April 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1926
This RFC describes a method of encapsulating IP datagrams on top ofAcoustical Transmission Media (ATM). This is a non-recommended standard. Distribution of this memo is unnecessary.
 
RFC 1927 Suggested Additional MIME Types for Associating Documents
 
Authors:C. Rogers.
Date:1 April 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1927
Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1928 SOCKS Protocol Version 5
 
Authors:M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones.
Date:March 1996
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1928
This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]
 
RFC 1929 Username/Password Authentication for SOCKS V5
 
Authors:M. Leech.
Date:March 1996
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1929
The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]
 
RFC 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS)
 
Authors:J. Hawkinson, T. Bates.
Date:March 1996
Formats:txt html json
Updated by:RFC 6996, RFC 7300
Also:BCP 0006
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1930
This memo discusses when it is appropriate to register and utilize anAutonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior GatewayProtocol, now at historical status; see [EGP]), BGP (Border GatewayProtocol, the current de facto standard for inter-AS routing; see[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which theInternet is expected to adopt when BGP becomes obsolete; see [IDRP]).It should be noted that the IDRP equivalent of an AS is the RDI, orRouting Domain Identifier.
 
RFC 1931 Dynamic RARP Extensions for Automatic Network Address Acquisition
 
Authors:D. Brownell.
Date:April 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1931
This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.
 
RFC 1932 IP over ATM: A Framework Document
 
Authors:R. Cole, D. Shur, C. Villamizar.
Date:April 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1932
It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1933 Transition Mechanisms for IPv6 Hosts and Routers
 
Authors:R. Gilligan, E. Nordmark.
Date:April 1996
Formats:txt json html
Obsoleted by:RFC 2893
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1933
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6.
 
RFC 1934 Ascend's Multilink Protocol Plus (MP+)
 
Authors:K. Smith.
Date:April 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1934
This document proposes an extension to the PPP Multilink Protocol(MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP.
 
RFC 1935 What is the Internet, Anyway?
 
Authors:J. Quarterman, S. Carl-Mitchell.
Date:April 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1935
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1936 Implementing the Internet Checksum in Hardware
 
Authors:J. Touch, B. Parham.
Date:April 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1936
This memo presents a techniques for efficiently implementing theInternet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps.
 
RFC 1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks
 
Authors:Y. Rekhter, D. Kandlur.
Date:May 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1937
The IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM,Frame Relay, X.25), as these assumptions impose constraints on communication among hosts and routers through a network. The restrictions may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks.
 
RFC 1938 A One-Time Password System
 
Authors:N. Haller, C. Metz.
Date:May 1996
Formats:txt html json
Obsoleted by:RFC 2289
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1938
This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]
 
RFC 1939 Post Office Protocol - Version 3
 
Authors:J. Myers, M. Rose.
Date:May 1996
Formats:txt html json
Obsoletes:RFC 1725
Updated by:RFC 1957, RFC 2449, RFC 6186, RFC 8314
Also:STD 0053
Status:INTERNET STANDARD
DOI:10.17487/RFC 1939
The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]
 
RFC 1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1)
 
Authors:D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala.
Date:May 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1940
The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1941 Frequently Asked Questions for Schools
 
Authors:J. Sellers, J. Robichaux.
Date:May 1996
Formats:txt json html
Obsoletes:RFC 1578
Also:FYI 0022
Status:INFORMATIONAL
DOI:10.17487/RFC 1941
The goal of this FYI document, produced by the Internet SchoolNetworking (ISN) group in the User Services Area of the InternetEngineering Task Force (IETF), is to act as an introduction to theInternet for faculty, administration, and other school personnel in primary and secondary schools. The intended audience is educators who are recently connected to the Internet, who are accessing theInternet by some means other than a direct connection, or who are just beginning to consider Internet access as a resource for their schools. Although the Internet Engineering Task Force is an international organization and this paper will be valuable to educators in many countries, it is limited in focus to internetworking in the United States.
 
RFC 1942 HTML Tables
 
Authors:D. Raggett.
Date:May 1996
Formats:txt html json
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 1942
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context.
 
RFC 1943 Building an X.500 Directory Service in the US
 
Authors:B. Jennings.
Date:May 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1943
This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the UnitedStates. This project is the work performed for the IntegratedDirectory Services Working Group within the Internet Engineering TaskForce, for establishing an electronic White Pages Directory Service within an organization in the US and for connecting it to a wide-areaDirectory infrastructure.

Establishing a successful White Pages Directory Service within an organization requires a collaborative effort between the technical, legal and data management components of an organization. It also helps if there is a strong commitment from the higher management to participate in a wide-area Directory Service.

The recommendations presented in the document are the result of experience from participating in the Internet White Pages project.

 
RFC 1944 Benchmarking Methodology for Network Interconnect Devices
 
Authors:S. Bradner, J. McQuaid.
Date:May 1996
Formats:txt json html
Obsoleted by:RFC 2544
Status:INFORMATIONAL
DOI:10.17487/RFC 1944
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing.
 
RFC 1945 Hypertext Transfer Protocol -- HTTP/1.0
 
Authors:T. Berners-Lee, R. Fielding, H. Frystyk.
Date:May 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1945
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature ofHTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0".

 
RFC 1946 Native ATM Support for ST2+
 
Authors:S. Jackowski.
Date:May 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1946
As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS).

The IETF is currently working on an integrated services model to support realtime services on the Internet The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.)

Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component.

This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments:

- ATM to internet,- internet to ATM, and- internet to internet across ATM.

 
RFC 1947 Greek Character Encoding for Electronic Mail Messages
 
Authors:D. Spinellis.
Date:May 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1947
This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1948 Defending Against Sequence Number Attacks
 
Authors:S. Bellovin.
Date:May 1996
Formats:txt json html
Obsoleted by:RFC 6528
Status:INFORMATIONAL
DOI:10.17487/RFC 1948
IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks.
 
RFC 1949 Scalable Multicast Key Distribution
 
Authors:A. Ballardie.
Date:May 1996
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 1949
The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of theMBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.

Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.

This memo provides a scalable solution to the multicast key distribution problem.

NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B.

 
RFC 1950 ZLIB Compressed Data Format Specification version 3.3
 
Authors:P. Deutsch, J-L. Gailly.
Date:May 1996
Formats:txt json ps pdf html
Status:INFORMATIONAL
DOI:10.17487/RFC 1950
This specification defines a lossless compressed data format. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format presently uses the DEFLATE compression method but can be easily extended to use other compression methods. It can be implemented readily in a manner not covered by patents. This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.
 
RFC 1951 DEFLATE Compressed Data Format Specification version 1.3
 
Authors:P. Deutsch.
Date:May 1996
Formats:txt json ps html pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1951
This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents.
 
RFC 1952 GZIP file format specification version 4.3
 
Authors:P. Deutsch.
Date:May 1996
Formats:txt html ps pdf json
Status:INFORMATIONAL
DOI:10.17487/RFC 1952
This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents.
 
RFC 1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0
 
Authors:P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.
Date:May 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1953
The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. The label allows more efficient access to cached routing information for that flow. The label can also enable a node to switch further packets belonging to the specified flow at layer 2 rather than forwarding them at layer 3.
 
RFC 1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0
 
Authors:P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.
Date:May 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1954
This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP].
 
RFC 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG
 
Authors:R. Hinden.
Date:June 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1955
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.

This memo describes a proposal made to to the Routing and Addressing group [ROAD] January 1992 by Robert Hinden. It was originally sent as an email message. It proposes a medium term solution to theInternet's routing and addressing problems.

 
RFC 1956 Registration in the MIL Domain
 
Authors:D. Engebretson, R. Plzak.
Date:June 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1956
This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1957 Some Observations on Implementations of the Post Office Protocol (POP3)
 
Authors:R. Nelson.
Date:June 1996
Formats:txt html json
Updates:RFC 1939
Status:INFORMATIONAL
DOI:10.17487/RFC 1957
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1958 Architectural Principles of the Internet
 
Authors:B. Carpenter, Ed..
Date:June 1996
Formats:txt json html
Updated by:RFC 3439
Status:INFORMATIONAL
DOI:10.17487/RFC 1958
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model.
 
RFC 1959 An LDAP URL Format
 
Authors:T. Howes, M. Smith.
Date:June 1996
Formats:txt json html
Obsoleted by:RFC 2255
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1959
This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]
 
RFC 1960 A String Representation of LDAP Search Filters
 
Authors:T. Howes.
Date:June 1996
Formats:txt json html
Obsoletes:RFC 1558
Obsoleted by:RFC 2254
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1960
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]
 
RFC 1961 GSS-API Authentication Method for SOCKS Version 5
 
Authors:P. McMahon.
Date:June 1996
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1961
This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]
 
RFC 1962 The PPP Compression Control Protocol (CCP)
 
Authors:D. Rand.
Date:June 1996
Formats:txt html json
Updated by:RFC 2153
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1962
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol.

This document defines a method for negotiating data compression overPPP links.

 
RFC 1963 PPP Serial Data Transport Protocol (SDTP)
 
Authors:K. Schneider, S. Venters.
Date:August 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1963
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.

This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This protocol was developed for the purpose of using PPP's many features to provide a standard method for synchronous data compression. The encapsulation uses a header structure based on that of the ITU-T Recommendation V.120 [2].

 
RFC 1964 The Kerberos Version 5 GSS-API Mechanism
 
Authors:J. Linn.
Date:June 1996
Formats:txt json html
Updated by:RFC 4121, RFC 6649
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1964
This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK]
 
RFC 1965 Autonomous System Confederations for BGP
 
Authors:P. Traina.
Date:June 1996
Formats:txt json html
Obsoleted by:RFC 3065
Status:EXPERIMENTAL
DOI:10.17487/RFC 1965
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.

This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.

The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

The extension this document describes is widely deployed in theInternet today.

 
RFC 1966 BGP Route Reflection An alternative to full mesh IBGP
 
Authors:T. Bates, R. Chandra.
Date:June 1996
Formats:txt html json
Obsoleted by:RFC 4456
Updated by:RFC 2796
Status:EXPERIMENTAL
DOI:10.17487/RFC 1966
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].

This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP.

 
RFC 1967 PPP LZS-DCP Compression Protocol (LZS-DCP)
 
Authors:K. Schneider, R. Friend.
Date:August 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1967
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.

This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This protocol is an enhanced version of the non-DCP(Option 17) PPP Stac LZS compression protocol [5], and will be referred to as the LZS-DCP Compression Protocol.

 
RFC 1968 The PPP Encryption Control Protocol (ECP)
 
Authors:G. Meyer.
Date:June 1996
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1968
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol.

This document defines a method for negotiating data encryption overPPP links.

 
RFC 1969 The PPP DES Encryption Protocol (DESE)
 
Authors:K. Sklower, G. Meyer.
Date:June 1996
Formats:txt json html
Obsoleted by:RFC 2419
Status:INFORMATIONAL
DOI:10.17487/RFC 1969
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.

This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.

 
RFC 1970 Neighbor Discovery for IP Version 6 (IPv6)
 
Authors:T. Narten, E. Nordmark, W. Simpson.
Date:August 1996
Formats:txt json html
Obsoleted by:RFC 2461
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1970
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.
 
RFC 1971 IPv6 Stateless Address Autoconfiguration
 
Authors:S. Thomson, T. Narten.
Date:August 1996
Formats:txt json html
Obsoleted by:RFC 2462
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1971
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.
 
RFC 1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks
 
Authors:M. Crawford.
Date:August 1996
Formats:txt html json
Obsoleted by:RFC 2464
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1972
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]
 
RFC 1973 PPP in Frame Relay
 
Authors:W. Simpson.
Date:June 1996
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1973
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

This document describes the use of Frame Relay for framing PPP encapsulated packets.

 
RFC 1974 PPP Stac LZS Compression Protocol
 
Authors:R. Friend, W. Simpson.
Date:August 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1974
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.

This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets.

 
RFC 1975 PPP Magnalink Variable Resource Compression
 
Authors:D. Schremp, J. Black, J. Weiss.
Date:August 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1975
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.The PPP Compression Control Protocol [2] provides a method for negotiating data compression over PPP links.

The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources.

 
RFC 1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)
 
Authors:K. Schneider, S. Venters.
Date:August 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1976
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.

The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a standard method for encapsulating and transporting serial data over aPPP link. The PPP Compression Control Protocol [3] provides a standard method for selecting and using a compression protocol to provide for data compression on a PPP link.

This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-TerminatingEquipment (DCE).

 
RFC 1977 PPP BSD Compression Protocol
 
Authors:V. Schryver.
Date:August 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1977
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.

This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets.

 
RFC 1978 PPP Predictor Compression Protocol
 
Authors:D. Rand.
Date:August 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1978
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method for transporting multi-protocol datagrams over PPP encapsulated links.

This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets.

 
RFC 1979 PPP Deflate Protocol
 
Authors:J. Woods.
Date:August 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1979
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.

This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets.

 
RFC 1980 A Proposed Extension to HTML : Client-Side Image Maps
 
Authors:J. Seidman.
Date:August 1996
Formats:txt json html
Obsoleted by:RFC 2854
Status:HISTORIC
DOI:10.17487/RFC 1980
The markup language known as "HTML/2.0" provides for image maps.Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified byUniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves these limitations.
 
RFC 1981 Path MTU Discovery for IP version 6
 
Authors:J. McCann, S. Deering, J. Mogul.
Date:August 1996
Formats:txt json html
Obsoleted by:RFC 8201
Status:DRAFT STANDARD
DOI:10.17487/RFC 1981
This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery forIP version 4.
 
RFC 1982 Serial Number Arithmetic
 
Authors:R. Elz, R. Bush.
Date:August 1996
Formats:txt html json
Updates:RFC 1034, RFC 1035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1982
This memo defines serial number arithmetic, as used in the DomainName System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in anIETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035.
 
RFC 1983 Internet Users' Glossary
 
Authors:G. Malkin, Ed..
Date:August 1996
Formats:txt html json
Obsoletes:RFC 1392
Also:FYI 0018
Status:INFORMATIONAL
DOI:10.17487/RFC 1983
There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them.
 
RFC 1984 IAB and IESG Statement on Cryptographic Technology and the Internet
 
Authors:IAB, IESG.
Date:August 1996
Formats:txt json html
Also:BCP 0200
Status:BEST CURRENT PRACTICE
DOI:10.17487/RFC 1984
The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1985 SMTP Service Extension for Remote Message Queue Starting
 
Authors:J. De Winter.
Date:August 1996
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1985
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers.
 
RFC 1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)
 
Authors:W. Polites, W. Wollman, D. Woo, R. Langan.
Date:August 1996
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 1986
This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1987 Ipsilon's General Switch Management Protocol Specification Version 1.1
 
Authors:P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.
Date:August 1996
Formats:txt html json
Updated by:RFC 2297
Status:INFORMATIONAL
DOI:10.17487/RFC 1987
The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics.
 
RFC 1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework
 
Authors:G. McAnally, D. Gilbert, J. Flick.
Date:August 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1988
This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1989 PPP Link Quality Monitoring
 
Authors:W. Simpson.
Date:August 1996
Formats:txt json html
Obsoletes:RFC 1333
Status:DRAFT STANDARD
DOI:10.17487/RFC 1989
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.

This document defines a protocol for generating Link-Quality-Reports.

 
RFC 1990 The PPP Multilink Protocol (MP)
 
Authors:K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti.
Date:August 1996
Formats:txt json html
Obsoletes:RFC 1717
Status:DRAFT STANDARD
DOI:10.17487/RFC 1990
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.

The differences between the current PPP Multilink specification (RFC1717) and this memo are explained in Section 11. Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations.

 
RFC 1991 PGP Message Exchange Formats
 
Authors:D. Atkins, W. Stallings, P. Zimmermann.
Date:August 1996
Formats:txt json html
Obsoleted by:RFC 4880
Status:INFORMATIONAL
DOI:10.17487/RFC 1991
This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1992 The Nimrod Routing Architecture
 
Authors:I. Castineyra, N. Chiappa, M. Steenstrup.
Date:August 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1992
We present a scalable internetwork routing architecture, calledNimrod. The Nimrod architecture is designed to accommodate a dynamic internetwork of arbitrary size with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork. The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction.
 
RFC 1993 PPP Gandalf FZA Compression Protocol
 
Authors:A. Barbir, D. Carr, W. Simpson.
Date:August 1996
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1993
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.

This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets.

 
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP)
 
Authors:W. Simpson.
Date:August 1996
Formats:txt json html
Obsoletes:RFC 1334
Updated by:RFC 2484
Status:DRAFT STANDARD
DOI:10.17487/RFC 1994
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams 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 a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key.

 
RFC 1995 Incremental Zone Transfer in DNS
 
Authors:M. Ohta.
Date:August 1996
Formats:txt json html
Updates:RFC 1035
Updated by:RFC 9103
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1995
This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.
 
RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
 
Authors:P. Vixie.
Date:August 1996
Formats:txt html json
Updates:RFC 1035
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1996
This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.
 
RFC 1997 BGP Communities Attribute
 
Authors:R. Chandra, P. Traina, T. Li.
Date:August 1996
Formats:txt html json
Updated by:RFC 7606, RFC 8642
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1997
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets.

This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers.

The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.

 
RFC 1998 An Application of the BGP Community Attribute in Multi-home Routing
 
Authors:E. Chen, T. Bates.
Date:August 1996
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1998
This document presents an application of the BGP community attribute[2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. It shows how the community based configuration can be used to replace the AS-based customization of the BGP "LOCAL_PREF" attribute, a common method used today. Not only does the technique presented simplifies configuration and management at the provider level, it also represents a paradigm shift in that it gives the potential for the customer to control its own routing policy with respect to its service provider, as well as providing the ability for policy configuration to be done at a prefix based granularity rather than the more common AS based granularity.
 
RFC 1999 Request for Comments Summary RFC Numbers 1900-1999
 
Authors:J. Elliott.
Date:January 1997
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1999