Internet Documents

RFCs

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

 
RFC 35 Network Meeting
 
Authors:S.D. Crocker.
Date:March 1970
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0035
 
 
RFC 96 An Interactive Network Experiment to Study Modes of Access the Network Information Center
 
Authors:R.W. Watson.
Date:February 1971
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0096
 
 
RFC 699 Request For Comments summary notes: 600-699
 
Authors:J. Postel, J. Vernon.
Date:November 1982
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0699
 
 
RFC 700 Protocol experiment
 
Authors:E. Mader, W.W. Plummer, R.S. Tomlinson.
Date:August 1974
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0700
 
 
RFC 794 Pre-emption
 
Authors:V.G. Cerf.
Date:September 1981
Formats:txt pdf
Updates:IEN125
Status:INFORMATIONAL
DOI:10.17487/RFC 0794
 
 
RFC 800 Request For Comments summary notes: 700-799
 
Authors:J. Postel, J. Vernon.
Date:November 1982
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0800
This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs.
 
RFC 814 Name, addresses, ports, and routes
 
Authors:D.D. Clark.
Date:July 1982
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0814
This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.
 
RFC 817 Modularity and efficiency in protocol implementation
 
Authors:D.D. Clark.
Date:July 1982
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0817
This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.
 
RFC 872 TCP-on-a-LAN
 
Authors:M.A. Padlipsky.
Date:September 1982
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0872
This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.
 
RFC 889 Internet Delay Experiments
 
Authors:D.L. Mills.
Date:December 1983
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0889
This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.
 
RFC 899 Request For Comments summary notes: 800-899
 
Authors:J. Postel, A. Westine.
Date:May 1984
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0899
 
 
RFC 964 Some problems with the specification of the Military Standard Transmission Control Protocol
 
Authors:D.P. Sidhu, T. Blumer.
Date:November 1985
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 0964
The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.
 
RFC 1012 Bibliography of Request For Comments 1 through 999
 
Authors:J.K. Reynolds, J. Postel.
Date:June 1987
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1012
This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.
 
RFC 1056 PCMAIL: A distributed mail system for personal computers
 
Authors:M.L. Lambert.
Date:June 1988
Formats:txt pdf
Obsoletes:RFC 0993
Status:INFORMATIONAL
DOI:10.17487/RFC 1056
This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues.
 
RFC 1057 RPC: Remote Procedure Call Protocol specification: Version 2
 
Authors:Sun Microsystems.
Date:June 1988
Formats:txt pdf
Obsoletes:RFC 1050
Status:INFORMATIONAL
DOI:10.17487/RFC 1057
This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time.
 
RFC 1071 Computing the Internet checksum
 
Authors:R.T. Braden, D.A. Borman, C. Partridge.
Date:September 1988
Formats:txt pdf
Updated by:RFC 1141
Status:INFORMATIONAL
DOI:10.17487/RFC 1071
This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.
 
RFC 1094 NFS: Network File System Protocol specification
 
Authors:B. Nowicki.
Date:March 1989
Formats:txt pdf
Also:RFC 1813
Status:INFORMATIONAL
DOI:10.17487/RFC 1094
This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.
 
RFC 1099 Request for Comments Summary: RFC Numbers 1000-1099
 
Authors:J. Reynolds.
Date:December 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1099
 
 
RFC 1107 Plan for Internet directory services
 
Authors:K.R. Sollins.
Date:July 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1107
This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community.
 
RFC 1111 Request for comments on Request for Comments: Instructions to RFC authors
 
Authors:J. Postel.
Date:August 1989
Formats:txt pdf
Obsoletes:RFC 0825
Obsoleted by:RFC 1543, RFC 2223
Status:INFORMATIONAL
DOI:10.17487/RFC 1111
This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.
 
RFC 1117 Internet numbers
 
Authors:S. Romano, M.K. Stahl, M. Recker.
Date:August 1989
Formats:txt pdf
Obsoletes:RFC 1062, RFC 1020, RFC 0997
Obsoleted by:RFC 1166
Status:INFORMATIONAL
DOI:10.17487/RFC 1117
This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.
 
RFC 1118 Hitchhikers guide to the Internet
 
Authors:E. Krol.
Date:September 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1118
This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo.
 
RFC 1120 Internet Activities Board
 
Authors:V. Cerf.
Date:September 1989
Formats:txt pdf
Obsoleted by:RFC 1160
Status:INFORMATIONAL
DOI:10.17487/RFC 1120
This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.
 
RFC 1121 Act one - the poems
 
Authors:J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm.
Date:September 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1121
This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.
 
RFC 1127 Perspective on the Host Requirements RFCs
 
Authors:R.T. Braden.
Date:October 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1127
This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.
 
RFC 1129 Internet Time Synchronization: The Network Time Protocol
 
Authors:D.L. Mills.
Date:October 1989
Formats:txt ps pdf
Also:RFC 1119
Status:INFORMATIONAL
DOI:10.17487/RFC 1129
This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.
 
RFC 1133 Routing between the NSFNET and the DDN
 
Authors:J.Y. Yu, H.W. Braun.
Date:November 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1133
This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo.
 
RFC 1135 Helminthiasis of the Internet
 
Authors:J.K. Reynolds.
Date:December 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1135
This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included.
 
RFC 1136 Administrative Domains and Routing Domains: A model for routing in the Internet
 
Authors:S. Hares, D. Katz.
Date:December 1989
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1136
This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard.
 
RFC 1141 Incremental updating of the Internet checksum
 
Authors:T. Mallory, A. Kullberg.
Date:January 1990
Formats:txt pdf
Updates:RFC 1071
Updated by:RFC 1624
Status:INFORMATIONAL
DOI:10.17487/RFC 1141
This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique.
 
RFC 1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices
 
Authors:R.H. Stine.
Date:April 1990
Formats:txt pdf ps
Obsoleted by:RFC 1470
Status:INFORMATIONAL
DOI:10.17487/RFC 1147
The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained.
 
RFC 1152 Workshop report: Internet research steering group workshop on very-high-speed networks
 
Authors:C. Partridge.
Date:April 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1152
This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard.
 
RFC 1160 Internet Activities Board
 
Authors:V. Cerf.
Date:May 1990
Formats:txt pdf
Obsoletes:RFC 1120
Status:INFORMATIONAL
DOI:10.17487/RFC 1160
This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.
 
RFC 1166 Internet numbers
 
Authors:S. Kirkpatrick, M.K. Stahl, M. Recker.
Date:July 1990
Formats:txt pdf
Obsoletes:RFC 1117, RFC 1062, RFC 1020
Updated by:RFC 5737
Status:INFORMATIONAL
DOI:10.17487/RFC 1166
This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.
 
RFC 1167 Thoughts on the National Research and Education Network
 
Authors:V.G. Cerf.
Date:July 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1167
The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.
 
RFC 1168 Intermail and Commercial Mail Relay services
 
Authors:A. Westine, A.L. DeSchon, J. Postel, C.E. Ward.
Date:July 1990
Formats:txt ps pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1168
This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.
 
RFC 1169 Explaining the role of GOSIP
 
Authors:V.G. Cerf, K.L. Mills.
Date:August 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1169
This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.
 
RFC 1170 Public key standards and licenses
 
Authors:R.B. Fougner.
Date:January 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1170
This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.
 
RFC 1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet
 
Authors:J. VanBokkelen.
Date:August 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1173
This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.
 
RFC 1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status
 
Authors:V.G. Cerf.
Date:August 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1174
This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.
 
RFC 1175 FYI on where to start: A bibliography of internetworking information
 
Authors:K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, M.K. Stahl, A. Yuan.
Date:August 1990
Formats:txt pdf
Also:FYI 0003
Status:INFORMATIONAL
DOI:10.17487/RFC 1175
The intent of this bibliography is to offer a representative collection of resources of information that will help the reader become familiar with the concepts of internetworking. It is meant to be a starting place for further research. There are references to other sources of information for those users wishing to pursue, in greater depth, the issues and complexities of the current networking environment.
 
RFC 1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions
 
Authors:G.S. Malkin, A.N. Marine, J.K. Reynolds.
Date:August 1990
Formats:txt pdf
Obsoleted by:RFC 1206
Status:INFORMATIONAL
DOI:10.17487/RFC 1177
This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]
 
RFC 1178 Choosing a name for your computer
 
Authors:D. Libes.
Date:August 1990
Formats:txt pdf
Also:FYI 0005
Status:INFORMATIONAL
DOI:10.17487/RFC 1178
In order to easily distinguish between multiple computers, we give them names. Experience has taught us that it is as easy to choose bad names as it is to choose good ones. This essay presents guidelines for deciding what makes a name good or bad.

Keywords: domain name system, naming conventions, computer administration, computer network management

 
RFC 1179 Line printer daemon protocol
 
Authors:L. McLaughlin.
Date:August 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1179
This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.
 
RFC 1180 TCP/IP tutorial
 
Authors:T.J. Socolofsky, C.J. Kale.
Date:January 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1180
This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.
 
RFC 1181 RIPE Terms of Reference
 
Authors:R. Blokzijl.
Date:September 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1181
This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1186 MD4 Message Digest Algorithm
 
Authors:R.L. Rivest.
Date:October 1990
Formats:txt pdf
Obsoleted by:RFC 1320
Status:INFORMATIONAL
DOI:10.17487/RFC 1186
This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.
 
RFC 1192 Commercialization of the Internet summary report
 
Authors:B. Kahin.
Date:November 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1192
This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1193 Client requirements for real-time communication services
 
Authors:D. Ferrari.
Date:November 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1193
A real-time communication service provides its clients with the ability to specify their performance requirements and to obtain guarantees about the satisfaction of those requirements. In this paper, we propose a set of performance specifications that seem appropriate for such services; they include various types of delay bounds, throughput bounds, and reliability bounds. We also describe other requirements and desirable properties from a client's viewpoint, and the ways in which each requirement is to be translated to make it suitable for lower levels in the protocol hierarchy.Finally, we present some examples of requirements specification, and discuss some of the possible objections to our approach.

This research has been supported in part by AT&T Bell Laboratories, the University of California under a MICRO grant, and theInternational Computer Science Institute. The views and conclusions in this document are those of the author and should not be interpreted as representing official policies, either expressed or implied, of any of the sponsoring organizations.

 
RFC 1197 Using ODA for translating multimedia information
 
Authors:M. Sherman.
Date:December 1990
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1197
The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1198 FYI on the X window system
 
Authors:R.W. Scheifler.
Date:January 1991
Formats:txt pdf
Also:FYI 0006
Status:INFORMATIONAL
DOI:10.17487/RFC 1198
This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.
 
RFC 1199 Request for Comments Summary Notes: 1100-1199
 
Authors:J. Reynolds.
Date:December 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1199
 
 
RFC 1202 Directory Assistance service
 
Authors:M.T. Rose.
Date:February 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1202
This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1205 5250 Telnet interface
 
Authors:P. Chmielewski.
Date:February 1991
Formats:txt pdf
Updated by:RFC 2877
Status:INFORMATIONAL
DOI:10.17487/RFC 1205
This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions
 
Authors:G.S. Malkin, A.N. Marine.
Date:February 1991
Formats:txt pdf
Obsoletes:RFC 1177
Obsoleted by:RFC 1325
Status:INFORMATIONAL
DOI:10.17487/RFC 1206
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]
 
RFC 1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions
 
Authors:G.S. Malkin, A.N. Marine, J.K. Reynolds.
Date:February 1991
Formats:txt pdf
Also:FYI 0007
Status:INFORMATIONAL
DOI:10.17487/RFC 1207
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1208 A Glossary of Networking Terms
 
Authors:O.J. Jacobsen, D.C. Lynch.
Date:March 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1208
This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990
 
Authors:V.G. Cerf, P.T. Kirstein, B. Randell.
Date:March 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1210
This report summarises user requirements for networking and related infrastructure facilities needed to enable effective cooperation between US and European research teams participating in the plannedESPRIT-DARPA/NSF programme of collaborative research in InformationScience and Technology. It analyses the problems and disparities of the current facilities, and suggests appropriate one and three year targets for improvements. It proposes a number of initial actions aimed at achieving these targets. Finally, the workshop has identified a non-exhaustive set of important issues upon which support of future research will depend. These issues could be studied in the short term, with the aim of initiating a programme of joint research in collaboration technology within the next year.
 
RFC 1211 Problems with the maintenance of large mailing lists
 
Authors:A. Westine, J. Postel.
Date:March 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1211
This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1215 Convention for defining traps for use with the SNMP
 
Authors:M.T. Rose.
Date:March 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1215
This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1216 Gigabit network economics and paradigm shifts
 
Authors:P. Richard, P. Kynikos.
Date:1 April 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1216
This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]
 
RFC 1217 Memo from the Consortium for Slow Commotion Research (CSCR)
 
Authors:V.G. Cerf.
Date:1 April 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1217
This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1218 Naming scheme for c=US
 
Authors:North American Directory Forum.
Date:April 1991
Formats:txt pdf
Obsoleted by:RFC 1255, RFC 1417
Status:INFORMATIONAL
DOI:10.17487/RFC 1218
This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1219 On the assignment of subnet numbers
 
Authors:P.F. Tsuchiya.
Date:April 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1219
This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1221 Host Access Protocol (HAP) specification: Version 2
 
Authors:W. Edmond.
Date:April 1991
Formats:txt pdf
Updates:RFC 0907
Status:INFORMATIONAL
DOI:10.17487/RFC 1221
This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1222 Advancing the NSFNET routing architecture
 
Authors:H.W. Braun, Y. Rekhter.
Date:May 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1222
This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel
 
Authors:J.M. Halpern.
Date:May 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1223
The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1236 IP to X.121 address mapping for DDN
 
Authors:L. Morales, P. Hasse.
Date:June 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1236
This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1242 Benchmarking Terminology for Network Interconnection Devices
 
Authors:S. Bradner.
Date:July 1991
Formats:txt pdf
Updated by:RFC 6201
Status:INFORMATIONAL
DOI:10.17487/RFC 1242
This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. The terms defined in this memo will be used in additional memos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).
 
RFC 1244 Site Security Handbook
 
Authors:J.P. Holbrook, J.K. Reynolds.
Date:July 1991
Formats:txt pdf
Obsoleted by:RFC 2196
Status:INFORMATIONAL
DOI:10.17487/RFC 1244
This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]
 
RFC 1245 OSPF Protocol Analysis
 
Authors:J. Moy.
Date:July 1991
Formats:txt ps pdf
Also:RFC 1246, RFC 1247
Status:INFORMATIONAL
DOI:10.17487/RFC 1245
This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.
 
RFC 1246 Experience with the OSPF Protocol
 
Authors:J. Moy.
Date:July 1991
Formats:txt pdf ps
Also:RFC 1245, RFC 1247
Status:INFORMATIONAL
DOI:10.17487/RFC 1246
This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.
 
RFC 1249 DIXIE Protocol Specification
 
Authors:T. Howes, M. Smith, B. Beecher.
Date:August 1991
Formats:txt pdf
Also:RFC 1202
Status:INFORMATIONAL
DOI:10.17487/RFC 1249
This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.
 
RFC 1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members
 
Authors:G. Malkin.
Date:August 1991
Formats:txt pdf
Obsoleted by:RFC 1336
Status:INFORMATIONAL
DOI:10.17487/RFC 1251
This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]
 
RFC 1254 Gateway Congestion Control Survey
 
Authors:A. Mankin, K. Ramakrishnan.
Date:August 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1254
The growth of network intensive Internet applications has made gateway congestion control a high priority. The IETF Performance andCongestion Control Working Group surveyed and reviewed gateway congestion control and avoidance approaches. The purpose of this paper is to present our review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication(DEC Bit), and Fair Queueing. The task remains for Internet implementors to determine and agree on the most effective mechanisms for controlling gateway congestion.
 
RFC 1255 A Naming Scheme for c=US
 
Authors:The North American Directory Forum.
Date:September 1991
Formats:txt pdf
Obsoletes:RFC 1218
Obsoleted by:RFC 1417
Status:INFORMATIONAL
DOI:10.17487/RFC 1255
This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1257 Isochronous applications do not require jitter-controlled networks
 
Authors:C. Partridge.
Date:September 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1257
This memo argues that jitter control is not required for networks to support isochronous applications. A network providing bandwidth and bounds delay is sufficient. The implications for gigabit internetworking protocols are briefly considered.
 
RFC 1258 BSD Rlogin
 
Authors:B. Kantor.
Date:September 1991
Formats:txt pdf
Obsoleted by:RFC 1282
Status:INFORMATIONAL
DOI:10.17487/RFC 1258
The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1259 Building the open road: The NREN as test-bed for the national public network
 
Authors:M. Kapor.
Date:September 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1259
This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1261 Transition of Nic Services
 
Authors:S. Williamson, L. Nobile.
Date:September 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1261
This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1262 Guidelines for Internet Measurement Activities
 
Authors:V.G. Cerf.
Date:October 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1262
This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1263 TCP Extensions Considered Harmful
 
Authors:S. O'Malley, L.L. Peterson.
Date:October 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1263
This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve theInternet protocol suite. Its purpose is to stimulate discussion in the Internet community.
 
RFC 1265 BGP Protocol Analysis
 
Authors:Y. Rekhter.
Date:October 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1265
This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1266 Experience with the BGP Protocol
 
Authors:Y. Rekhter.
Date:October 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1266
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1270 SNMP Communications Services
 
Authors:F. Kastenholz.
Date:October 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1270
This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1272 Internet Accounting: Background
 
Authors:C. Mills, D. Hirsh, G.R. Ruth.
Date:November 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1272
This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations
 
Authors:M.F. Schwartz.
Date:November 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1273
In this report we discuss plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. We overview our experimental design, considerations of network and remote site load, mechanisms used to control the measurement collection process, and network appropriate use and privacy issues, including our efforts to inform sites measured by this study. A list of references and information on how to contact the Principal Investigator are included.
 
RFC 1275 Replication Requirements to provide an Internet Directory using X.500
 
Authors:S.E. Hardcastle-Kille.
Date:November 1991
Formats:txt ps pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1275
This RFCconsiders certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective openInternet Directory can be established using these protocols and services [CCI88]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This RFCconcerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation.
 
RFC 1278 A string encoding of Presentation Address
 
Authors:S.E. Hardcastle-Kille.
Date:November 1991
Formats:txt ps pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1278
There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation.
 
RFC 1281 Guidelines for the Secure Operation of the Internet
 
Authors:R. Pethia, S. Crocker, B. Fraser.
Date:November 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1281
The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1282 BSD Rlogin
 
Authors:B. Kantor.
Date:December 1991
Formats:txt pdf
Obsoletes:RFC 1258
Status:INFORMATIONAL
DOI:10.17487/RFC 1282
This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1287 Towards the Future Internet Architecture
 
Authors:D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby.
Date:December 1991
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1287
This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places
 
Authors:J. Martin.
Date:December 1991
Formats:txt pdf
Obsoleted by:RFC 1402
Status:INFORMATIONAL
DOI:10.17487/RFC 1290
This document was presented at the 1991 ACM SIGUCCS User ServicesConference. It appears here in its updated form.

There is a wealth of information on the network. In fact, so much information, that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users.

The ultimate goal is to make the route to these sources of information invisible to the user. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we can all be richer.

 
RFC 1291 Mid-Level Networks Potential Technical Services
 
Authors:V. Aggarwal.
Date:December 1991
Formats:txt ps pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1291
This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. The term "mid-level" is used as a generic term to represent all regional and similar networks, which, due to continuous evolutions and transitions, can no longer be termed"regional" [MAN]. It discusses the pros and cons of offering these services, as well as areas in which mid-level networks can work together.

A large portion of the ideas stem from discussions at the IETFOperational Statistics (OPstat), User Connectivity Problems (UCP) andNetwork Joint Management (NJM) working groups.

 
RFC 1292 A Catalog of Available X.500 Implementations
 
Authors:R. Lang, R. Wright.
Date:January 1992
Formats:txt pdf
Obsoleted by:RFC 1632
Status:INFORMATIONAL
DOI:10.17487/RFC 1292
The goal of this document is to provide information regarding the availability and capability of implementations of X.500. Comments and critiques of this document, and new or updated descriptions ofX.500 implementations are welcome. Send them to the DirectoryInformation Services Infrastructure (DISI) Working Group(disi@merit.edu) or to the editors.
 
RFC 1295 User Bill of Rights for entries and listings in the Public Directory
 
Authors:The North American Directory Forum.
Date:January 1992
Formats:txt pdf
Obsoleted by:RFC 1417
Status:INFORMATIONAL
DOI:10.17487/RFC 1295
This RFC is a near-verbatim copy of a document, known as NADF-265, which has been produced by the North American Directory Forum (NADF).

User Bill of Rights for entries and listings in the Public Directory

The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information. To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in thePublic Directory. As a user, you have:

I. The right not to be listed.

II. The right to have you or your agent informed when your entry is created.

III. The right to examine your entry.

IV. The right to correct inaccurate information in your entry.

V. The right to remove specific information from your entry.

VI. The right to be assured that your listing in thePublic Directory will comply with US or Canadian law regulating privacy or access information.

VII. The right to expect timely fulfillment of these rights.

 
RFC 1296 Internet Growth (1981-1991)
 
Authors:M. Lottor.
Date:January 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1296
This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables.DNS entries are collected by a program called ZONE, which searches the Internet and retrieves data from all known domains. Pre-DNS host table data were retrieved from system archive tapes. Various statistics are presented on the number of hosts and domains.
 
RFC 1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")
 
Authors:D. Johnson.
Date:January 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1297
Professional quality handling of network problems requires some kind of problem tracking system, herein referred to as a "trouble ticket" system. A basic trouble ticket system acts like a hospital chart, coordinating the work of multiple people who may need to work on the problem.

Once the basic trouble ticket system is in place, however, there are many extensions that can aid Network Operations efficiency.Information in the tickets can be used to produce statistical reports. Operator efficiency and accuracy may be increased by automating trouble ticket entry with information from the networkAlert system. The Alert system may be used to monitor trouble ticket progress. Trouble tickets may be also used to communicate network health information between NOCs, to telcom vendors, and to other internal sales and engineering audiences.

This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers.

 
RFC 1298 SNMP over IPX
 
Authors:R. Wormley, S. Bostock.
Date:February 1992
Formats:txt pdf
Obsoleted by:RFC 1420
Status:INFORMATIONAL
DOI:10.17487/RFC 1298
This memo defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2].
 
RFC 1299 Summary of 1200-1299
 
Authors:M. Kennedy.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1299
 
 
RFC 1300 Remembrances of Things Past
 
Authors:S. Greenfield.
Date:February 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1300
Poem. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1301 Multicast Transport Protocol
 
Authors:S. Armstrong, A. Freier, K. Marzullo.
Date:February 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1301
This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1302 Building a Network Information Services Infrastructure
 
Authors:D. Sitzler, P. Smith, A. Marine.
Date:February 1992
Formats:txt pdf
Also:FYI 0012
Status:INFORMATIONAL
DOI:10.17487/RFC 1302
This FYI RFC document is intended for existing Internet NetworkInformation Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. The document strives to:

- Define a basic set of essential services that NetworkInformation Centers (NICs) will provide to Internet users, including new mechanisms that will facilitate the timely dissemination of information to the Internet community and encourage cooperation among NICs.

- Describe existing NIC services as an aid to Internet users and as a model for organizations establishing new NICs.

 
RFC 1303 A Convention for Describing SNMP-based Agents
 
Authors:K. McCloghrie, M. Rose.
Date:February 1992
Formats:txt pdf
Also:RFC 1155, RFC 1157, RFC 1212, RFC 1213
Status:INFORMATIONAL
DOI:10.17487/RFC 1303
This memo suggests a straight-forward approach towards describingSNMP-based agents.
 
RFC 1306 Experiences Supporting By-Request Circuit-Switched T3 Networks
 
Authors:A. Nicholson, J. Young.
Date:March 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1306
This memo describes the experiences of a project team at CrayResearch, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.

Developers at Cray Research, Inc. were presented with an opportunity to use a circuit-switched T3 network for wide area networking. They devised an architectural model for using this new resource. This involves activating the circuit-switched connection when an application program engages in a bulk data transfer, and releasing the connection when the transfer is complete.

Three software implementations for this feature have been tested, and the results documented here. A variety of issues are involved, and further research is necessary. Network users are beginning to recognize the value of this service, and are planning to make use of by-request circuit-switched networks. A standard method of access will be needed to ensure interoperability among vendors of circuit- switched network support products.

 
RFC 1308 Executive Introduction to Directory Services Using the X.500 Protocol
 
Authors:C. Weider, J. Reynolds.
Date:March 1992
Formats:txt pdf
Also:FYI 0013
Status:INFORMATIONAL
DOI:10.17487/RFC 1308
This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500.

This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF).

 
RFC 1309 Technical Overview of Directory Services Using the X.500 Protocol
 
Authors:C. Weider, J. Reynolds, S. Heker.
Date:March 1992
Formats:txt pdf
Also:FYI 0014
Status:INFORMATIONAL
DOI:10.17487/RFC 1309
This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts DirectoryServices based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.

A primary purpose of this paper is to illustrate the vast functionality of the X.500 protocol and to show how it can be used to provide a global directory for human use, and can support other applications which would benefit from directory services, such as main programs.

This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF).

 
RFC 1310 The Internet Standards Process
 
Authors:L. Chapin.
Date:March 1992
Formats:txt pdf
Obsoleted by:RFC 1602
Status:INFORMATIONAL
DOI:10.17487/RFC 1310
This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]
 
RFC 1311 Introduction to the STD Notes
 
Authors:J. Postel.
Date:March 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1311
The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS- TRACK]
 
RFC 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio
 
Authors:C. Partridge.
Date:1 April 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1313
Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1321 The MD5 Message-Digest Algorithm
 
Authors:R. Rivest.
Date:April 1992
Formats:txt pdf
Updated by:RFC 6151
Status:INFORMATIONAL
DOI:10.17487/RFC 1321
This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1322 A Unified Approach to Inter-Domain Routing
 
Authors:D. Estrin, Y. Rekhter, S. Hotz.
Date:May 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1322
This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. The focus is on scalability to very large networks and functionality, as well as scalability, to support routing in an environment of heterogeneous services, requirements, and route selection criteria.

Note: The work of D. Estrin and S. Hotz was supported by the NationalScience Foundation under contract number NCR-9011279, with matching funds from GTE Laboratories. The work of Y. Rekhter was supported by the Defense Advanced Research Projects Agency, under contractDABT63-91-C-0019. Views and conclusions expressed in this paper are not necessarily those of the Defense Advanced Research ProjectsAgency and National Science Foundation.

 
RFC 1324 A Discussion on Computer Network Conferencing
 
Authors:D. Reed.
Date:May 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1324
This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. It is also the intention of this memo to stimulate the computer community and generate some useful discussion about the merits of this field.
 
RFC 1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions
 
Authors:G. Malkin, A. Marine.
Date:May 1992
Formats:txt pdf
Obsoletes:RFC 1206
Obsoleted by:RFC 1594
Status:INFORMATIONAL
DOI:10.17487/RFC 1325
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet.
 
RFC 1326 Mutual Encapsulation Considered Dangerous
 
Authors:P. Tsuchiya.
Date:May 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1326
This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A).
 
RFC 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks
 
Authors:P. Kuehn.
Date:May 1992
Formats:txt pdf
Updated by:RFC 5494
Status:INFORMATIONAL
DOI:10.17487/RFC 1329
In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community
 
Authors:ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet).
Date:May 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1330
This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion
 
Authors:Z. Wang, J. Crowcroft.
Date:May 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1335
This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for theInternet. This is an "idea" paper and discussion is strongly encouraged.
 
RFC 1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members
 
Authors:G. Malkin.
Date:May 1992
Formats:txt pdf
Obsoletes:RFC 1251
Also:FYI 0009
Status:INFORMATIONAL
DOI:10.17487/RFC 1336
This FYI RFC contains biographical information about members of theInternet Activities Board (IAB), the Internet Engineering SteeringGroup (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet ResearchTask Force (IRTF).
 
RFC 1337 TIME-WAIT Assassination Hazards in TCP
 
Authors:R. Braden.
Date:May 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1337
This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified.
 
RFC 1338 Supernetting: an Address Assignment and Aggregation Strategy
 
Authors:V. Fuller, T. Li, J. Yu, K. Varadhan.
Date:June 1992
Formats:txt pdf
Obsoleted by:RFC 1519
Status:INFORMATIONAL
DOI:10.17487/RFC 1338
This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers.
 
RFC 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information
 
Authors:N. Borenstein.
Date:June 1992
Formats:txt pdf ps
Status:INFORMATIONAL
DOI:10.17487/RFC 1343
This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1344 Implications of MIME for Internet Mail Gateways
 
Authors:N. Borenstein.
Date:June 1992
Formats:txt pdf ps
Status:INFORMATIONAL
DOI:10.17487/RFC 1344
While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1345 Character Mnemonics and Character Sets
 
Authors:K. Simonsen.
Date:June 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1345
This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources
 
Authors:P. Jones.
Date:June 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1346
The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1355 Privacy and Accuracy Issues in Network Information Center Databases
 
Authors:J. Curran, A. Marine.
Date:August 1992
Formats:txt pdf
Also:FYI 0015
Status:INFORMATIONAL
DOI:10.17487/RFC 1355
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.
 
RFC 1357 A Format for E-mailing Bibliographic Records
 
Authors:D. Cohen.
Date:July 1992
Formats:txt pdf
Obsoleted by:RFC 1807
Status:INFORMATIONAL
DOI:10.17487/RFC 1357
This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR).
 
RFC 1358 Charter of the Internet Architecture Board (IAB)
 
Authors:L. Chapin.
Date:August 1992
Formats:txt pdf
Obsoleted by:RFC 1601
Status:INFORMATIONAL
DOI:10.17487/RFC 1358
The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1359 Connecting to the Internet - What Connecting Institutions Should Anticipate
 
Authors:ACM SIGUCCS.
Date:August 1992
Formats:txt pdf
Also:FYI 0016
Status:INFORMATIONAL
DOI:10.17487/RFC 1359
This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to theInternet.

In order to provide clarity to the reader, some specific information has been detailed. In doing so, the document has been directed toward U.S. academic institutions that have not yet connected to theInternet.

However, the issues for which specific information has been provided can be generalized for any organization that wishes to participate in the world-wide Internet community. It will be necessary for those organizations to obtain the correct and detailed information from their local or national IP service providers. In addition, this document may be used as an evaluation checklist for organizations that are currently connected. Readers are expected to have general familiarity with networking concepts and terminology.

 
RFC 1361 Simple Network Time Protocol (SNTP)
 
Authors:D. Mills.
Date:August 1992
Formats:txt pdf
Obsoleted by:RFC 1769
Also:RFC 1305
Status:INFORMATIONAL
DOI:10.17487/RFC 1361
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless RPC mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.

This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP.

 
RFC 1362 Novell IPX over Various WAN Media (IPXWAN)
 
Authors:M. Allen.
Date:September 1992
Formats:txt pdf
Obsoleted by:RFC 1634
Status:INFORMATIONAL
DOI:10.17487/RFC 1362
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks.
 
RFC 1363 A Proposed Flow Specification
 
Authors:C. Partridge.
Date:September 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1363
A flow specification (or "flow spec") is a data structure used by internetwork hosts to request special services of the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic. In the future, hosts are expected to have to request such services on behalf of distributed applications such as multimedia conferencing.

The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF).

 
RFC 1365 An IP Address Extension Proposal
 
Authors:K. Siyan.
Date:September 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1365
This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements.
 
RFC 1366 Guidelines for Management of IP Address Space
 
Authors:E. Gerich.
Date:October 1992
Formats:txt pdf
Obsoleted by:RFC 1466
Status:INFORMATIONAL
DOI:10.17487/RFC 1366
This document has been reviewed by the Federal Engineering Task Force(FEPG) on behalf of the Federal Networking Council (FNC), the co- chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.
 
RFC 1367 Schedule for IP Address Space Management Guidelines
 
Authors:C. Topolcic.
Date:October 1992
Formats:txt pdf
Obsoleted by:RFC 1467
Status:INFORMATIONAL
DOI:10.17487/RFC 1367
This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1369 Implementation Notes and Experience for the Internet Ethernet MIB
 
Authors:F. Kastenholz.
Date:October 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1369
This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1371 Choosing a Common IGP for the IP Internet
 
Authors:P. Gross.
Date:October 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1371
This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to theIAB for a single "common IGP" for the IP portions of the Internet.

In this memo, the term "common IGP" is defined, the need for a commonIGP is explained, the relation of this issue to other ongoingInternet Engineering Task Force (IETF) routing protocol development is provided, and the relation of this issue to the goal for multi- protocol integration in the Internet is explored.

Finally, a specific IGP is recommended as the "common IGP" for IP portions of the Internet -- the Open Shortest Path First (OSPF) routing protocol.

The goal of this recommendation is for all vendors of Internet IP routers to make OSPF available as one of the IGP's provided with their routers.

 
RFC 1373 Portable DUAs
 
Authors:T. Tignor.
Date:October 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1373
This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1375 Suggestion for New Classes of IP Addresses
 
Authors:P. Robinson.
Date:October 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1375
This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address.
 
RFC 1380 IESG Deliberations on Routing and Addressing
 
Authors:P. Gross, P. Almquist.
Date:November 1992
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1380
This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the InternetEngineering Task Force (IETF).

It also provides a preliminary report of the Internet EngineeringSteering Group (IESG) deliberations on how these routing and addressing issues should be pursued in the Internet ArchitectureBoard (IAB)/IETF.

 
RFC 1384 Naming Guidelines for Directory Pilots
 
Authors:P. Barker, S.E. Hardcastle-Kille.
Date:January 1993
Formats:txt ps pdf
Obsoleted by:RFC 1617, RTR_0011
Status:INFORMATIONAL
DOI:10.17487/RFC 1384
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.
 
RFC 1386 The US Domain
 
Authors:A. Cooper, J. Postel.
Date:December 1992
Formats:txt pdf
Obsoleted by:RFC 1480
Status:INFORMATIONAL
DOI:10.17487/RFC 1386
This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1387 RIP Version 2 Protocol Analysis
 
Authors:G. Malkin.
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 1721
Status:INFORMATIONAL
DOI:10.17487/RFC 1387
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience.
 
RFC 1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force
 
Authors:G. Malkin.
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 1539
Status:INFORMATIONAL
DOI:10.17487/RFC 1391
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

 
RFC 1392 Internet Users' Glossary
 
Authors:G. Malkin, T. LaQuey Parker.
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 1983
Status:INFORMATIONAL
DOI:10.17487/RFC 1392
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 1394 Relationship of Telex Answerback Codes to Internet Domains
 
Authors:P. Robinson.
Date:January 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1394
This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available.It will also list major Internet "Public" E-Mail addresses.

This list is designed to show the corresponding codes for Fax and voice messages, telex country codes, telex answerbacks and Internet domains. It is an attempt to place all of the information into one list and all the connections for each country.

 
RFC 1396 The Process for Organization of Internet Standards Working Group (POISED)
 
Authors:S. Crocker.
Date:January 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1396
This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible.
 
RFC 1399 Summary of 1300-1399
 
Authors:J. Elliott.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1399
 
 
RFC 1400 Transition and Modernization of the Internet Registration Service
 
Authors:S. Williamson.
Date:March 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1400
As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1401 Correspondence between the IAB and DISA on the use of DNS
 
Authors:Internet Architecture Board.
Date:January 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1401
This memo reproduces three letters exchanged between the InternetActivities Board (IAB) and the Defense Information Systems Agency(DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt".
 
RFC 1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places
 
Authors:J. Martin.
Date:January 1993
Formats:txt pdf
Obsoletes:RFC 1290
Also:FYI 0010
Status:INFORMATIONAL
DOI:10.17487/RFC 1402
A wealth of information exists on the network. In fact, there is so much information that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be useful.

The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer.

 
RFC 1404 A Model for Common Operational Statistics
 
Authors:B. Stockman.
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 1857
Status:INFORMATIONAL
DOI:10.17487/RFC 1404
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats.
 
RFC 1417 NADF Standing Documents: A Brief Overview
 
Authors:The North American Directory Forum.
Date:February 1993
Formats:txt pdf
Obsoletes:RFC 1295, RFC 1255, RFC 1218
Obsoleted by:RFC 1758
Status:INFORMATIONAL
DOI:10.17487/RFC 1417
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
 
Authors:G. Vaudreuil.
Date:February 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1428
Protocols for extending SMTP to pass 8bit characters have been defined [3] [4]. These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2]. Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extendedSMTP environment and these ad hoc mechanisms interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME.
 
RFC 1429 Listserv Distribute Protocol
 
Authors:E. Thomas.
Date:February 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1429
This memo specifies a subset of the distribution protocol used by theBITNET LISTSERV to deliver mail messages to large amounts of recipients. This protocol, known as DISTRIBUTE, optimizes the distribution by sending a single copy of the message over heavily loaded links, insofar as topological information is available to guide such decisions, and reduces the average turnaround time for large mailing lists to 5-15 minutes on the average. This memo describes a simple interface allowing non-BITNET mailing list exploders (or other bulk-delivery scripts) to take advantage of this service by letting the BITNET distribution network take care of the delivery.
 
RFC 1430 A Strategic Plan for Deploying an Internet X.500 Directory Service
 
Authors:S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent.
Date:February 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1430
There are a number of reasons why a new Internet Directory Service is required. This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 DirectoryService. It then describes in more detail the initial steps which need to be taken in order to achieve these goals, and how work already undertaken by Internet Engineering Task Force Working Groups(IETF WGs) is working towards these goals.
 
RFC 1431 DUA Metrics (OSI-DS 33 (v2))
 
Authors:P. Barker.
Date:February 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1431
This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.

This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. Particular issues covered include terminal requirements; style of interface; target user; default object classes and attribute types; use of DAP; error handling. The focus of the note is on"white pages" DUAs: this is a reflection of the current information base. Nevertheless much of the document will be applicable to DUAs developed for other types of Directory usage.

Please send comments to the author or to the discussion group <osi- ds@CS.UCL.AC.UK&rt;.

 
RFC 1432 Recent Internet Books
 
Authors:J. Quarterman.
Date:March 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1432
This article originally appeared in Volume 2 Number 12, (December1992) of Matrix News, the monthly newsletter of Matrix Information and Directory Services, Inc. (MIDS).
 
RFC 1434 Data Link Switching: Switch-to-Switch Protocol
 
Authors:R. Dixon, D. Kushi.
Date:March 1993
Formats:txt ps pdf
Obsoleted by:RFC 1795
Status:INFORMATIONAL
DOI:10.17487/RFC 1434
This RFC describes IBM's support of Data Link Switching over TCP/IP.The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.

Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com.

 
RFC 1435 IESG Advice from Experience with Path MTU Discovery
 
Authors:S. Knowles.
Date:March 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1435
In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTUDiscovery.
 
RFC 1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol)
 
Authors:F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Albert.
Date:March 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1436
The Internet Gopher protocol is designed for distributed document search and retrieval. This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This document is adapted from the basic Internet Gopher protocol document first issued by the Microcomputer Center at the University ofMinnesota in 1991.
 
RFC 1437 The Extension of MIME Content-Types to a New Medium
 
Authors:N. Borenstein, M. Linimon.
Date:1 April 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1437
A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the matter-transport/sentient-life-form type. The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings.

Other informally proposed subtypes, such as "non-sentient-life-form","non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo.

 
RFC 1438 Internet Engineering Task Force Statements Of Boredom (SOBs)
 
Authors:A. Lyman Chapin, C. Huitema.
Date:1 April 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1438
This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1439 The Uniqueness of Unique Identifiers
 
Authors:C. Finseth.
Date:March 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1439
This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people.
 
RFC 1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers
 
Authors:W. Chimiak.
Date:April 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1453
The new generation of multimedia applications demands new features and new mechanisms for proper performance. ATM technology has moved from concept to reality, delivering very high bandwidths and new capabilities to the data link layer user. In an effort to anticipate the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT[RFC 988], and VMTP [RFC 1045] were developed. The excellent insights and mechanisms pioneered by the creators of these experimental Internet protocols were used in the design of XpressTransfer Protocol (XTP) [XTP92] with the goal of eventually delivering ATM bandwidths to a user process. This RFC is a vehicle to inform the Internet community about XTP as it benefits from pastInternet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind.
 
RFC 1454 Comparison of Proposals for Next Version of IP
 
Authors:T. Dixon.
Date:May 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1454
This is a slightly edited reprint of RARE Technical Report(RTC(93)004).

The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated byRARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting inWashington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated. Note that for a time the term"IPv7" was use to mean the eventual next version of IP, but that the same term was closely associated with a particilar proposal, so the term "IPng" is now used to identify the eventual next generation ofIP.

The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually.

 
RFC 1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification
 
Authors:Vietnamese Standardization Working Group.
Date:May 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1456
This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into7-bit US ASCII and in an 8-bit form. These conventions are widely used by the overseas Vietnamese who are on the Internet and are active in USENET. This document only provides information and specifies no level of standard.
 
RFC 1457 Security Label Framework for the Internet
 
Authors:R. Housley.
Date:May 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1457
This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1458 Requirements for Multicast Protocols
 
Authors:R. Braudes, S. Zabele.
Date:May 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1458
This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1462 FYI on "What is the Internet?"
 
Authors:E. Krol, E. Hoffman.
Date:May 1993
Formats:txt pdf
Also:FYI 0020
Status:INFORMATIONAL
DOI:10.17487/RFC 1462
This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the InternetEngineering Task Force (IETF). Containing a modified chapter from EdKrol's 1992 book, "The Whole Internet User's Guide and Catalog," the paper covers the Internet's definition, history, administration, protocols, financing, and current issues such as growth, commercialization, and privatization.
 
RFC 1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings
 
Authors:E. Hoffman, L. Jackson.
Date:May 1993
Formats:txt pdf
Also:FYI 0019
Status:INFORMATIONAL
DOI:10.17487/RFC 1463
This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history.This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel.
 
RFC 1466 Guidelines for Management of IP Address Space
 
Authors:E. Gerich.
Date:May 1993
Formats:txt pdf
Obsoletes:RFC 1366
Obsoleted by:RFC 2050
Status:INFORMATIONAL
DOI:10.17487/RFC 1466
This document has been reviewed by the Federal Engineering PlanningGroup (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.
 
RFC 1468 Japanese Character Encoding for Internet Messages
 
Authors:J. Murai, M. Crispin, E. van der Poel.
Date:June 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1468
This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices
 
Authors:R. Enger, J. Reynolds.
Date:June 1993
Formats:txt pdf
Obsoletes:RFC 1147
Also:FYI 0002
Status:INFORMATIONAL
DOI:10.17487/RFC 1470
The goal of this FYI memo is to provide an update to FYI 2, RFC 1147[1], which provided practical information to site administrators and network managers. New and/or updated tools are listed in this RFC.Additonal descriptions are welcome, and should be sent to: noctools- entries@merit.edu.
 
RFC 1477 IDPR as a Proposed Standard
 
Authors:M. Steenstrup.
Date:July 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1477
This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1480 The US Domain
 
Authors:A. Cooper, J. Postel.
Date:June 1993
Formats:txt pdf
Obsoletes:RFC 1386
Status:INFORMATIONAL
DOI:10.17487/RFC 1480
This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1489 Registration of a Cyrillic Character Set
 
Authors:A. Chernov.
Date:July 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1489
Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1491 A Survey of Advanced Usages of X.500
 
Authors:C. Weider, R. Wright.
Date:July 1993
Formats:txt pdf
Also:FYI 0021
Status:INFORMATIONAL
DOI:10.17487/RFC 1491
This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the IntegratedDirectory Services Working Group of the Application and User ServicesAreas of the IETF.
 
RFC 1492 An Access Control Protocol, Sometimes Called TACACS
 
Authors:C. Finseth.
Date:July 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1492
This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1498 On the Naming and Binding of Network Destinations
 
Authors:J. Saltzer.
Date:August 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1498
This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas:First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. To illustrate the usefulness of this approach, the paper interprets some more subtle and confusing properties of two real-world network systems for naming destinations.
 
RFC 1499 Summary of 1400-1499
 
Authors:J. Elliott.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1499
 
 
RFC 1501 OS/2 User Group
 
Authors:E. Brunsen.
Date:August 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1501
Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.
 
RFC 1503 Algorithms for Automating Administration in SNMPv2 Managers
 
Authors:K. McCloghrie, M. Rose.
Date:August 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1503
When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing
 
Authors:A. Oppenheimer.
Date:August 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1504
This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1506 A Tutorial on Gatewaying between X.400 and Internet Mail
 
Authors:J. Houttuin.
Date:August 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1506
This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1511 Common Authentication Technology Overview
 
Authors:J. Linn.
Date:September 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1511
This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1523 The text/enriched MIME Content-type
 
Authors:N. Borenstein.
Date:September 1993
Formats:txt pdf
Obsoleted by:RFC 1563, RFC 1896
Status:INFORMATIONAL
DOI:10.17487/RFC 1523
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.
 
RFC 1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information
 
Authors:N. Borenstein.
Date:September 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1524
This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined byRFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and theMultipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system.
 
RFC 1526 Assignment of System Identifiers for TUBA/CLNP Hosts
 
Authors:D. Piscitello.
Date:September 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1526
This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion.
 
RFC 1527 What Should We Plan Given the Dilemma of the Network?
 
Authors:G. Cook.
Date:September 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1527
Early last year, as the concluding effort of an 18 month appointment at the US Congress Office of Technology Assessment (OTA), I drafted a potential policy framework for Congressional action on the NationalResearch and Education Network (NREN).

The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow forCongress to make?

It is unfortunate that this was never officially done for or by theCongress by OTA. What we have as a result is network policy making being carried out now by the Science Subcommittee on the House side in consultation with a relatively small group of interested parties.The debate seems to be more focused on preserving turf than on any sweeping understanding of what the legislation is doing. That is unfortunate.

In the hope that it may contain some useful ideas, I offer a shortened version of the suggested policy draft as information for the Internet community.

 
RFC 1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies
 
Authors:C. Malamud, M. Rose.
Date:October 1993
Formats:txt pdf
Obsoletes:RFC 1486
Status:INFORMATIONAL
DOI:10.17487/RFC 1529
This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy
 
Authors:C. Malamud, M. Rose.
Date:October 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1530
This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System [1,2].

This document is informational and applies only to those Internet sites that choose to register themselves within the tpc.int subdomain. The tpc.int subdomain is organized as a cooperative of the sites that provide access within the context of the subdomain.Policy for the subdomain is set by a board responsible to the cooperative.

The primary purpose of the tpc.int subdomain is to provide transparent mapping between general-purpose computers on the Internet and special-purpose devices directly connected to the telephone network. Initially, a remote printing service is defined [3,4] which ties together G3-compatible facsimile devices on the telephone network with users of electronic mail in the Internet and associated message-handling domains connected to the Internet by application- layer gateways.

It should be noted that remote printer gateways have long been technically feasible and have become an integral part of many individual networks. The tpc.int subdomain integrates individual sites into a common namespace, transforming remote printing from a single-site, value-added service into an integral transparent service in the global Internet.

 
RFC 1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software
 
Authors:E. Gavron.
Date:October 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1535
This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit (although not by the masses). This document points out the flaw, a case in point, and a solution.
 
RFC 1536 Common DNS Implementation Errors and Suggested Fixes
 
Authors:A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller.
Date:October 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1536
This memo describes common errors seen in DNS implementations and suggests some fixes. Where applicable, violations of recommendations from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo also describes, where relevant, the algorithms followed in BIND(versions 4.8.3 and 4.9 which the authors referred to) to serve as an example.
 
RFC 1537 Common DNS Data File Configuration Errors
 
Authors:P. Beertema.
Date:October 1993
Formats:txt pdf
Obsoleted by:RFC 1912
Status:INFORMATIONAL
DOI:10.17487/RFC 1537
This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time.
 
RFC 1538 Advanced SNA/IP : A Simple SNA Transport Protocol
 
Authors:W. Behl, B. Sterling, W. Teskey.
Date:October 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1538
This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors. Any questions or comments relative to the contents of this RFC may be sent to the followingInternet address: snaip@mcdata.com.
 
RFC 1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force
 
Authors:G. Malkin.
Date:October 1993
Formats:txt pdf
Obsoletes:RFC 1391
Obsoleted by:RFC 1718
Status:INFORMATIONAL
DOI:10.17487/RFC 1539
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

 
RFC 1543 Instructions to RFC Authors
 
Authors:J. Postel.
Date:October 1993
Formats:txt pdf
Obsoletes:RFC 1111, RFC 0825
Obsoleted by:RFC 2223
Status:INFORMATIONAL
DOI:10.17487/RFC 1543
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1546 Host Anycasting Service
 
Authors:C. Partridge, T. Mendez, W. Milliken.
Date:November 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1546
This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. Insofar as is possible, this memo tries to be agnostic about how the service is actually provided by the internetwork. This memo describes an experimental service and does not propose a protocol. This memo is produced by the Internet Research Task Force (IRTF).
 
RFC 1547 Requirements for an Internet Standard Point-to-Point Protocol
 
Authors:D. Perkins.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1547
This document discusses the evaluation criteria for an InternetStandard Data Link Layer protocol to be used with point-to-point links. Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an InternetStandard. In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an InternetStandard are discussed in detail. An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues.

Historical Note: This was the design requirements document datedJune 1989, which was followed for RFC-1134 through the present.It is now published for completeness and future guidance.

 
RFC 1550 IP: Next Generation (IPng) White Paper Solicitation
 
Authors:S. Bradner, A. Mankin.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1550
This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1551 Novell IPX Over Various WAN Media (IPXWAN)
 
Authors:M. Allen.
Date:December 1993
Formats:txt pdf
Obsoleted by:RFC 1634
Status:INFORMATIONAL
DOI:10.17487/RFC 1551
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability forUnnumbered RIP links, On-demand statically routed links and client to router connectivity.
 
RFC 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP
 
Authors:M. Ohta, K. Handa.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1554
This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1555 Hebrew Character Encoding for Internet Messages
 
Authors:H. Nussbacher, Y. Bourvine.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1555
This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME[RFC1521] and ISO-8859-8.
 
RFC 1556 Handling of Bi-directional Texts in MIME
 
Authors:H. Nussbacher.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1556
This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME.
 
RFC 1557 Korean Character Encoding for Internet Messages
 
Authors:U. Choi, K. Chon, H. Park.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1557
This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1558 A String Representation of LDAP Search Filters
 
Authors:T. Howes.
Date:December 1993
Formats:txt pdf
Obsoleted by:RFC 1960
Status:INFORMATIONAL
DOI:10.17487/RFC 1558
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.
 
RFC 1560 The MultiProtocol Internet
 
Authors:B. Leiner, Y. Rekhter.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1560
This document was prepared by the authors on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.

There has recently been considerable discussion on two topics:MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.

In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should:

- maintain its focus on the TCP/IP protocol suite,

- work to select a single next-generation internet protocol and develop mechanisms to aid in transition from the current IPv4, and

- continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet.

 
RFC 1562 Naming Guidelines for the AARNet X.500 Directory Service
 
Authors:G. Michaelson, M. Prior.
Date:December 1993
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1562
AARNet is a member network of the global Internet and participates in the global Internet X.500 based Directory Service. A number of RFC's have been issued that make recommendations that alter or supplement the OSI/ETU standards for X.500 [1]. In general, these RFCs will be followed by the AARNet Directory Service. However, in certain cases we wish to align ourselves with our national ISO body (StandardsAustralia) rather than the Internet where they conflict. In naming, we have chosen to align ourselves with Standards Australia and this document notes the difference in our approach to the Internet guidelines suggested in RFC 1384 [2].
 
RFC 1563 The text/enriched MIME Content-type
 
Authors:N. Borenstein.
Date:January 1994
Formats:txt ps pdf
Obsoletes:RFC 1523
Obsoleted by:RFC 1896
Status:INFORMATIONAL
DOI:10.17487/RFC 1563
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.
 
RFC 1564 DSA Metrics (OSI-DS 34 (v3))
 
Authors:P. Barker, R. Hedberg.
Date:January 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1564
This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. The intention is that the replies to the questions posed provide a fairly full description of a DSA. Some of the questions will yield answers which are purely descriptive; others, however, are intended to elicit answers which give some measure of the utility of the DSA. The marks awarded for a DSA in each particular area should give a good indication of the DSA's capabilities, and its suitability for particular uses.

Please send comments to the authors or to the discussion group<osi-ds@CS.UCL.AC.UK&rt;.

 
RFC 1568 Simple Network Paging Protocol - Version 1(b)
 
Authors:A. Gwinn.
Date:January 1994
Formats:txt pdf
Obsoleted by:RFC 1645
Status:INFORMATIONAL
DOI:10.17487/RFC 1568
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months in one nationwide paging firm. One other paging firm is in the process of adopting it.

Earlier versions of this specification were reviewed by IESG members and the IETF's "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETFWork", below.

 
RFC 1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures
 
Authors:M. Rose.
Date:January 1994
Formats:txt pdf
Obsoleted by:RFC 1703
Status:INFORMATIONAL
DOI:10.17487/RFC 1569
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1571 Telnet Environment Option Interoperability Issues
 
Authors:D. Borman.
Date:January 1994
Formats:txt pdf
Updates:RFC 1408
Status:INFORMATIONAL
DOI:10.17487/RFC 1571
This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1574 Essential Tools for the OSI Internet
 
Authors:S. Hares, C. Wittbrodt.
Date:February 1994
Formats:txt pdf
Obsoletes:RFC 1139
Status:INFORMATIONAL
DOI:10.17487/RFC 1574
This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473(CLNP):

- ping or OSI Echo function- traceroute function which uses the OSI Echo function- routing table dump function

These CLNS tools are the basics required for hosts and routers forCLNS network support. It is intended that this document specify the most basic support level required for CLNS hosts and routers.

To support some of the needed tools (ping and traceroute) this memo specifies the mechanism specified in RFC 1575 [3].

 
RFC 1576 TN3270 Current Practices
 
Authors:J. Penner.
Date:January 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1576
This document describes the existing implementation of transferring3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270.

Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators.

The following areas pertaining to TN3270 implementations are covered in this document:

1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data stream commands

2. the method for sending and receiving 3270 data

3. the method of handling some special keys known as SYSREQ andATTN using current available telnet commands

4. the events that will transition a TN3270 session back to an NVT session

 
RFC 1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions
 
Authors:J. Sellers.
Date:February 1994
Formats:txt pdf
Obsoleted by:RFC 1941
Status:INFORMATIONAL
DOI:10.17487/RFC 1578
The goal of this FYI RFC, produced by the Internet School Networking(ISN) group in the User Services Area of the Internet EngineeringTask Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools.
 
RFC 1579 Firewall-Friendly FTP
 
Authors:S. Bellovin.
Date:February 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1579
This memo describes a suggested change to the behavior of FTP client programs. No protocol modifications are required, though we outline some that might be useful.
 
RFC 1580 Guide to Network Resource Tools
 
Authors:EARN Staff.
Date:March 1994
Formats:txt pdf
Also:FYI 0023
Status:INFORMATIONAL
DOI:10.17487/RFC 1580
The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]
 
RFC 1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits
 
Authors:G. Meyer.
Date:February 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1581
As required by Routing Protocol Criteria [1], this report documents the key features of Routing over Demand Circuits on Wide AreaNetworks - RIP [2] and the current implementation experience.
 
RFC 1585 MOSPF: Analysis and Experience
 
Authors:J. Moy.
Date:March 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1585
This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering TaskForce internet routing protocol standardization criteria" ([RFC1264]).

Please send comments to mospf@gated.cornell.edu.

 
RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks
 
Authors:O. deSouza, M. Rodrigues.
Date:March 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1586
This memo specifies guidelines for implementors and users of the OpenShortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently.
 
RFC 1588 White Pages Meeting Report
 
Authors:J. Postel, C. Anderson.
Date:February 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1588
This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1589 A Kernel Model for Precision Timekeeping
 
Authors:D. Mills.
Date:March 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1589
This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1590 Media Type Registration Procedure
 
Authors:J. Postel.
Date:March 1994
Formats:txt pdf
Obsoleted by:RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
Updates:RFC 1521
Status:INFORMATIONAL
DOI:10.17487/RFC 1590
Several protocols allow the use of data representing different"media" such as text, images, audio, and video, and within such media different encoding styles, such as (in video) jpeg, gif, ief, and tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] defined several initial types of multimedia data objects, and a procedure for registering additional types with the Internet AssignedNumbers Authority (IANA). Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content- type/subtypes). It also generalizes the scope of use of these MediaTypes to make it appropriate to use the same registrations and specifications with other applications.
 
RFC 1591 Domain Name System Structure and Delegation
 
Authors:J. Postel.
Date:March 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1591
This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1593 SNA APPN Node MIB
 
Authors:W. McKenzie, J. Cheng.
Date:March 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1593
This RFC describes IBM's SNMP support for SNA Advanced Peer-to-PeerNetworking (APPN) nodes.
 
RFC 1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions
 
Authors:A. Marine, J. Reynolds, G. Malkin.
Date:March 1994
Formats:txt pdf
Obsoletes:RFC 1325
Obsoleted by:RFC 2664
Status:INFORMATIONAL
DOI:10.17487/RFC 1594
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet.
 
RFC 1597 Address Allocation for Private Internets
 
Authors:Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot.
Date:March 1994
Formats:txt pdf
Obsoleted by:RFC 1918
Status:INFORMATIONAL
DOI:10.17487/RFC 1597
This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1599 Summary of 1500-1599
 
Authors:M. Kennedy.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1599
 
 
RFC 1601 Charter of the Internet Architecture Board (IAB)
 
Authors:C. Huitema.
Date:March 1994
Formats:txt pdf
Obsoletes:RFC 1358
Obsoleted by:RFC 2850
Status:INFORMATIONAL
DOI:10.17487/RFC 1601
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations.
 
RFC 1602 The Internet Standards Process -- Revision 2
 
Authors:Internet Architecture Board, Internet Engineering Steering Group.
Date:March 1994
Formats:txt pdf
Obsoletes:RFC 1310
Obsoleted by:RFC 2026
Updated by:RFC 1871
Status:INFORMATIONAL
DOI:10.17487/RFC 1602
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.

This revision (revision 2) includes the following major changes:

(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.

(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).

(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.

(d) An appeals procedure is added (Section 3.6).

(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.

(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C.

 
RFC 1603 IETF Working Group Guidelines and Procedures
 
Authors:E. Huizer, D. Crocker.
Date:March 1994
Formats:txt pdf
Obsoleted by:RFC 2418
Updated by:RFC 1871
Status:INFORMATIONAL
DOI:10.17487/RFC 1603
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined.
 
RFC 1605 SONET to Sonnet Translation
 
Authors:W. Shakespeare.
Date:1 April 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1605
Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation(SONNET).
 
RFC 1606 A Historical Perspective On The Usage Of IP Version 9
 
Authors:J. Onions.
Date:1 April 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1606
This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures.
 
RFC 1607 A VIEW FROM THE 21ST CENTURY
 
Authors:V. Cerf.
Date:1 April 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1607
This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1613 cisco Systems X.25 over TCP (XOT)
 
Authors:J. Forster, G. Satz, G. Glick, R. Day.
Date:May 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1613
This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1614 Network Access to Multimedia Information
 
Authors:C. Adie.
Date:May 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1614
This report summarises the requirements of research and academic network users for network access to multimedia information. It does this by investigating some of the projects planned or currently underway in the community. Existing information systems such asGopher, WAIS and World-Wide Web are examined from the point of view of multimedia support, and some interesting hypermedia systems emerging from the research community are also studied. Relevant existing and developing standards in this area are discussed. The report identifies the gaps between the capabilities of currentlydeployed systems and the user requirements, and proposes further work centred on the World-Wide Web system to rectify this.

The report is in some places very detailed, so it is preceded by an extended summary, which outlines the findings of the report.

 
RFC 1615 Migrating from X.400(84) to X.400(88)
 
Authors:J. Houttuin, J. Craigie.
Date:May 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1615
This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. It not only describes the technical complications, but also the effect the transition will have on the end users, especially concerning interworking between end users of the 84 and the 88 services.
 
RFC 1616 X.400(1988) for the Academic and Research Community in Europe
 
Authors:RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed..
Date:May 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1616
The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1617 Naming and Structuring Guidelines for X.500 Directory Pilots
 
Authors:P. Barker, S. Kille, T. Lenggenhager.
Date:May 1994
Formats:txt pdf
Obsoletes:RFC 1384
Status:INFORMATIONAL
DOI:10.17487/RFC 1617
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. The final version of this document will replace RFC 1384.
 
RFC 1620 Internet Architecture Extensions for Shared Media
 
Authors:B. Braden, J. Postel, Y. Rekhter.
Date:May 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1620
The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption may be violated for shared media, including "large public data networks"(LPDNs). The architecture still works if this assumption is violated, but it does not have a means to prevent multiple host- router and router-router hops through the shared medium. This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops.
 
RFC 1624 Computation of the Internet Checksum via Incremental Update
 
Authors:A. Rijsinghani, Ed..
Date:May 1994
Formats:txt pdf
Updates:RFC 1141
Status:INFORMATIONAL
DOI:10.17487/RFC 1624
This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141.
 
RFC 1625 WAIS over Z39.50-1988
 
Authors:M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte.
Date:June 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1625
The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
 
Authors:E. Lear, E. Fair, D. Crocker, T. Kessler.
Date:July 1994
Formats:txt pdf
Obsoleted by:RFC 1918
Status:INFORMATIONAL
DOI:10.17487/RFC 1627
This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1628 UPS Management Information Base
 
Authors:J. Case, Ed..
Date:May 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1628
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]
 
RFC 1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web
 
Authors:T. Berners-Lee.
Date:June 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1630
This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1631 The IP Network Address Translator (NAT)
 
Authors:K. Egevang, P. Francis.
Date:May 1994
Formats:txt pdf
Obsoleted by:RFC 3022
Status:INFORMATIONAL
DOI:10.17487/RFC 1631
The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.

It is possible that CIDR will not be adequate to maintain the IPInternet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complementsCIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons.

 
RFC 1632 A Revised Catalog of Available X.500 Implementations
 
Authors:A. Getchell, Ed., S. Sataluri, Ed..
Date:May 1994
Formats:txt pdf
Obsoletes:RFC 1292
Obsoleted by:RFC 2116
Status:INFORMATIONAL
DOI:10.17487/RFC 1632
This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor inRFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.

This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces.

 
RFC 1633 Integrated Services in the Internet Architecture: an Overview
 
Authors:R. Braden, D. Clark, S. Shenker.
Date:June 1994
Formats:txt ps pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1633
This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.

This memo represents the direct product of recent work by Dave Clark,Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, JohnWroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others.

 
RFC 1634 Novell IPX Over Various WAN Media (IPXWAN)
 
Authors:M. Allen.
Date:May 1994
Formats:txt pdf
Obsoletes:RFC 1551, RFC 1362
Status:INFORMATIONAL
DOI:10.17487/RFC 1634
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and RFC 1551. The changes from RFC 1551 are to correct a problem in the wording when anRFC 1362 router talks to an RFC 1551 router and to allow numbers to be specified in a Router Name.
 
RFC 1635 How to Use Anonymous FTP
 
Authors:P. Deutsch, A. Emtage, A. Marine.
Date:May 1994
Formats:txt pdf
Also:FYI 0024
Status:INFORMATIONAL
DOI:10.17487/RFC 1635
This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. It shows a sample anonymous FTP session. It also discusses common ways files are packaged for efficient storage and transmission.
 
RFC 1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994
 
Authors:R. Braden, D. Clark, S. Crocker, C. Huitema.
Date:June 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1636
This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture.

This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security. It contains some significant diversity of opinions on some important issues.This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet.

 
RFC 1640 The Process for Organization of Internet Standards Working Group (POISED)
 
Authors:S. Crocker.
Date:June 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1640
This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible.
 
RFC 1645 Simple Network Paging Protocol - Version 2
 
Authors:A. Gwinn.
Date:July 1994
Formats:txt pdf
Obsoletes:RFC 1568
Obsoleted by:RFC 1861
Status:INFORMATIONAL
DOI:10.17487/RFC 1645
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows are available at no cost. Please contact the author for more information.

Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below.

 
RFC 1646 TN3270 Extensions for LUname and Printer Selection
 
Authors:C. Graves, T. Butts, M. Angel.
Date:July 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1646
This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from aTN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server.Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing listTN3270E@list.nih.gov . These extensions will be called TN3287 in this document. This information is being provided to members of theInternet community that want to support the 3287 data stream within the TELNET protocol.
 
RFC 1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community
 
Authors:R. Hagens, A. Hansen.
Date:July 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1649
The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1656 BGP-4 Protocol Document Roadmap and Implementation Experience
 
Authors:P. Traina.
Date:July 1994
Formats:txt pdf
Obsoleted by:RFC 1773
Status:INFORMATIONAL
DOI:10.17487/RFC 1656
Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1667 Modeling and Simulation Requirements for IPng
 
Authors:S. Symington, D. Wood, M. Pullen.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1667
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.
 
RFC 1668 Unified Routing Requirements for IPng
 
Authors:D. Estrin, T. Li, Y. Rekhter.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1668
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.
 
RFC 1669 Market Viability as a IPng Criteria
 
Authors:J. Curran.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1669
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.
 
RFC 1670 Input to IPng Engineering Considerations
 
Authors:D. Heagerty.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1670
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.
 
RFC 1671 IPng White Paper on Transition and Other Considerations
 
Authors:B. Carpenter.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1671
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.
 
RFC 1672 Accounting Requirements for IPng
 
Authors:N. Brownlee.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1672
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.
 
RFC 1673 Electric Power Research Institute Comments on IPng
 
Authors:R. Skelton.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1673
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.
 
RFC 1674 A Cellular Industry View of IPng
 
Authors:M. Taylor.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1674
This memo is a response to RFC 1550, "IP: Next Generation (IPng)White Paper Solicitation". The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies.
 
RFC 1675 Security Concerns for IPng
 
Authors:S. Bellovin.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1675
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.
 
RFC 1676 INFN Requirements for an IPng
 
Authors:A. Ghiselli, D. Salomoni, C. Vistoli.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1676
This white paper is sent by INFN network team, the Italian NationalInstitute for nuclear physics, whose network, named INFNet, is a nationwide network founded to provide the access to existing national and international HEP laboratory and to facilitate communications between the researchers. With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan.We do not really expect to add original items to the selection, but we think that it could be useful to submit the opinions and ideas that come from our network experience.
 
RFC 1677 Tactical Radio Frequency Communication Requirements for IPng
 
Authors:B. Adamson.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1677
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.
 
RFC 1678 IPng Requirements of Large Corporate Networks
 
Authors:E. Britton, J. Tavs.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1678
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 draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite.
 
RFC 1679 HPN Working Group Input to the IPng Requirements Solicitation
 
Authors:D. Green, P. Irey, D. Marlow, K. O'Donoghue.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1679
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.
 
RFC 1680 IPng Support for ATM Services
 
Authors:C. Brazdziunas.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1680
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.
 
RFC 1681 On Many Addresses per Host
 
Authors:S. Bellovin.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1681
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.
 
RFC 1682 IPng BSD Host Implementation Analysis
 
Authors:J. Bound.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1682
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.
 
RFC 1683 Multiprotocol Interoperability In IPng
 
Authors:R. Clark, M. Ammar, K. Calvert.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1683
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.
 
RFC 1684 Introduction to White Pages Services based on X.500
 
Authors:P. Jurg.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1684
This document aims at organisations who are using local and global electronic communication on a day to day basis and for whom using an electronic White Pages Service is therefore indispensable.

The document provides an introduction to the international ITU-T(formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic WhitePages Service.

In addition a short overview of the experience gained from theParadise X.500 pilot is given. References to more detailed information are included.

The document should be useful for managers of the above mentioned organisations who need to get the necessary executive commitment for making the address information of their organisation available by means of X.500.

 
RFC 1685 Writing X.400 O/R Names
 
Authors:H. Alvestrand.
Date:August 1994
Formats:txt pdf
Also:RTR_0012
Status:INFORMATIONAL
DOI:10.17487/RFC 1685
There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.
 
RFC 1686 IPng Requirements: A Cable Television Industry Viewpoint
 
Authors:M. Vecchi.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1686
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. The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cable television industry or any of its companies. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
 
RFC 1687 A Large Corporate User's View of IPng
 
Authors:E. Fleischman.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1687
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.
 
RFC 1688 IPng Mobility Considerations
 
Authors:W. Simpson.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1688
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
 
RFC 1689 A Status Report on Networked Information Retrieval: Tools and Groups
 
Authors:J. Foster, Ed..
Date:August 1994
Formats:txt pdf
Also:FYI 0025
Status:INFORMATIONAL
DOI:10.17487/RFC 1689
The purpose of this report is to increase the awareness of NetworkedInformation Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools.NIR Tools covered include Archie, WAIS, gopher and World Wide Web.
 
RFC 1690 Introducing the Internet Engineering and Planning Group (IEPG)
 
Authors:G. Huston.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1690
This memo introduces the IEPG to the Internet Community. The IEPG is an Internet Service Operators' forum, intended to assist ServiceOperators to coordinate in operational aspects of managing Internet services.
 
RFC 1691 The Document Architecture for the Cornell Digital Library
 
Authors:W. Turner.
Date:August 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1691
This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.

Two unique features of this architecture are the ability to generate reference documents and the ability to create multiple views of a document.

 
RFC 1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications
 
Authors:P. Furniss.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1698
This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and DirectoryAccess Protocol, and "migrant" protocols, originally defined for use over other transports.

As well as the octet sequences which are the supporting layer headers(and trailers) around the application data, this document includes some tutorial material on the OSI upper layers.

An implementation that sends the octet sequences given here, and interprets the equivalent protocol received, will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol.

 
RFC 1699 Summary of 1600-1699
 
Authors:J. Elliott.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1699
 
 
RFC 1701 Generic Routing Encapsulation (GRE)
 
Authors:S. Hanks, T. Li, D. Farinacci, P. Traina.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1701
This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
 
RFC 1702 Generic Routing Encapsulation over IPv4 networks
 
Authors:S. Hanks, T. Li, D. Farinacci, P. Traina.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1702
This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures
 
Authors:M. Rose.
Date:October 1994
Formats:txt pdf
Obsoletes:RFC 1569
Status:INFORMATIONAL
DOI:10.17487/RFC 1703
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1704 On Internet Authentication
 
Authors:N. Haller, R. Atkinson.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1704
This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1705 Six Virtual Inches to the Left: The Problem with IPng
 
Authors:R. Carlson, D. Ficarella.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1705
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.
 
RFC 1706 DNS NSAP Resource Records
 
Authors:B. Manning, R. Colella.
Date:October 1994
Formats:txt pdf
Obsoletes:RFC 1637
Status:INFORMATIONAL
DOI:10.17487/RFC 1706
OSI lower layer protocols, comprising the connectionless network protocol (CLNP) and supporting routing protocols, are deployed in some parts of the global Internet. Maintenance and debugging of CLNP connectivity is greatly aided by support in the Domain Name System(DNS) for mapping between names and NSAP addresses.

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format.

NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.

This document obsoletes RFC 1348 and RFC 1637.

 
RFC 1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3
 
Authors:D. Gowin.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1708
This RFC describes a PICS Proforma translated into an Internet acceptable form. The Original document was developed according toISO 9646 for conformance test purposes. This document is intended for both developers and users of the NTP (Network Time Protocol).This document contains specific information and performance characteristics for the use of NTP within the context of Internet usage. It is suggested, that users wishing to use the synchronization capabilities of the Internet abide by the characteristics set within this document.

For more information please contact Dr. David Mills at Mills@udel.edu or review RFC 1305 for more information.

 
RFC 1709 K-12 Internetworking Guidelines
 
Authors:J. Gargano, D. Wasley.
Date:November 1994
Formats:txt ps pdf
Also:FYI 0026
Status:INFORMATIONAL
DOI:10.17487/RFC 1709
The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1710 Simple Internet Protocol Plus White Paper
 
Authors:R. Hinden.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1710
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 author and/or the sipp@sunroof.eng.sun.com mailing list.
 
RFC 1711 Classifications in E-mail Routing
 
Authors:J. Houttuin.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1711
This paper presents a classification for e-mail routing issues. It clearly defines commonly used terminology such as static routing, store-and-forward routing, source routing and others. Real life examples show which routing options are used in existing projects.

The goal is to define all terminology in one reference paper. This will also help relatively new mail system managers to understand the issues and make the right choices. The reader is expected to already have a solid understanding of general networking terminology.

In this paper, the word Message Transfer Agent (MTA) is used to describe a routing entity, which can be an X.400 MTA, a UNIX mailer, or any other piece of software performing mail routing functions. AnMTA processes the so called envelope information of a message. The term User Agent (UA) is used to describe a piece of software performing user related mail functions. It processes the contents of a message's envelope, i.e., the header fields and body parts.

 
RFC 1713 Tools for DNS debugging
 
Authors:A. Romao.
Date:November 1994
Formats:txt pdf
Also:FYI 0027
Status:INFORMATIONAL
DOI:10.17487/RFC 1713
Although widely used (and most of the times unnoticed), DNS (DomainName System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work.This document presents some tools available for domain administrators to detect and correct those anomalies.
 
RFC 1714 Referral Whois Protocol (RWhois)
 
Authors:S. Williamson, M. Kosters.
Date:November 1994
Formats:txt ps pdf
Obsoleted by:RFC 2167
Status:INFORMATIONAL
DOI:10.17487/RFC 1714
This memo describes version 1.0 of the client/server interaction ofRWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information.
 
RFC 1715 The H Ratio for Address Assignment Efficiency
 
Authors:C. Huitema.
Date:November 1994
Formats:txt pdf
Updated by:RFC 3194
Status:INFORMATIONAL
DOI:10.17487/RFC 1715
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 author and/or the sipp@sunroof.eng.sun.com mailing list.
 
RFC 1716 Towards Requirements for IP Routers
 
Authors:P. Almquist, F. Kastenholz.
Date:November 1994
Formats:txt pdf
Obsoleted by:RFC 1812
Status:INFORMATIONAL
DOI:10.17487/RFC 1716
The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force
 
Authors:IETF Secretariat, G. Malkin.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1539
Obsoleted by:RFC 3160
Status:INFORMATIONAL
DOI:10.17487/RFC 1718
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) plenary meetings has grown phenomenally. Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

 
RFC 1719 A Direction for IPng
 
Authors:P. Gross.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1719
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
 
RFC 1721 RIP Version 2 Protocol Analysis
 
Authors:G. Malkin.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1387
Status:INFORMATIONAL
DOI:10.17487/RFC 1721
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track.
 
RFC 1726 Technical Criteria for Choosing IP The Next Generation (IPng)
 
Authors:C. Partridge, F. Kastenholz.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1726
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
 
RFC 1727 A Vision of an Integrated Internet Information Service
 
Authors:C. Weider, P. Deutsch.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1727
This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration.
 
RFC 1728 Resource Transponders
 
Authors:C. Weider.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1728
Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand. This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information.
 
RFC 1729 Using the Z39.50 Information Retrieval Protocol
 
Authors:C. Lynch.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1729
This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis
 
Authors:M. Crispin.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1732
This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1733 Distributed Electronic Mail Models in IMAP4
 
Authors:M. Crispin.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1733
There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1736 Functional Recommendations for Internet Resource Locators
 
Authors:J. Kunze.
Date:February 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1736
This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1737 Functional Requirements for Uniform Resource Names
 
Authors:K. Sollins, L. Masinter.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1737
This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1739 A Primer On Internet and TCP/IP Tools
 
Authors:G. Kessler, S. Shepard.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 2151
Status:INFORMATIONAL
DOI:10.17487/RFC 1739
This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1741 MIME Content Type for BinHex Encoded Files
 
Authors:P. Faltstrom, D. Crocker, E. Fair.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1741
This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files. Only when available software and/or user practice dictates, should this method be employed. It is recommended to use application/applefile [FALT94] for maximum interoperability.
 
RFC 1744 Observations on the Management of the Internet Address Space
 
Authors:G. Huston.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1744
This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. Possible modifications to the management practices are examined, and potential outcomes considered. Some general conclusions are drawn, and the relevance of these conclusions to the matter of formulation of address management policies for IPv6 are noted.
 
RFC 1746 Ways to Define User Expectations
 
Authors:B. Manning, D. Perkins.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1746
This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet.
 
RFC 1750 Randomness Recommendations for Security
 
Authors:D. Eastlake 3rd, S. Crocker, J. Schiller.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 4086
Status:INFORMATIONAL
DOI:10.17487/RFC 1750
Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications.

 
RFC 1751 A Convention for Human-Readable 128-bit Keys
 
Authors:D. McDonald.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1751
This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture
 
Authors:N. Chiappa.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1753
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 document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. Also presented is some background information, consisting of i) information about architectural and design principles which might apply to the design of a new internetworking layer, and ii) some details of the logic and reasoning behind particular requirements.

 
RFC 1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1
 
Authors:M. Laubach.
Date:January 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1754
This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1758 NADF Standing Documents: A Brief Overview
 
Authors:The North American Directory Forum.
Date:February 1995
Formats:txt pdf
Obsoletes:RFC 1417
Status:INFORMATIONAL
DOI:10.17487/RFC 1758
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1760 The S/KEY One-Time Password System
 
Authors:N. Haller.
Date:February 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1760
This document describes the S/KEY* One-Time Password system as released for public use by Bellcore and as described in reference[3]. A reference implementation and documentation are available by anonymous ftp from ftp.bellcore.com in the directories pub/nmh/...
 
RFC 1761 Snoop Version 2 Packet Capture File Format
 
Authors:B. Callaghan, R. Gilligan.
Date:February 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1761
This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files.
 
RFC 1769 Simple Network Time Protocol (SNTP)
 
Authors:D. Mills.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1361
Obsoleted by:RFC 2030, RFC 4330
Status:INFORMATIONAL
DOI:10.17487/RFC 1769
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.

This memorandum obsoletes RFC-1361 of the same title. Its purpose is to explain the protocol model for operation in broadcast mode, to provide additional clarification in some places and to correct a few typographical errors. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.Distribution of this memorandum is unlimited.

 
RFC 1773 Experience with the BGP-4 protocol
 
Authors:P. Traina.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1656
Status:INFORMATIONAL
DOI:10.17487/RFC 1773
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1774 BGP-4 Protocol Analysis
 
Authors:P. Traina, Ed..
Date:March 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1774
The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1775 To Be "On" the Internet
 
Authors:D. Crocker.
Date:March 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1775
The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access.
 
RFC 1776 The Address is the Message
 
Authors:S. Crocker.
Date:1 April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1776
Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1785 TFTP Option Negotiation Analysis
 
Authors:G. Malkin, A. Harkin.
Date:March 1995
Formats:txt pdf
Updates:RFC 1350
Status:INFORMATIONAL
DOI:10.17487/RFC 1785
The TFTP option negotiation mechanism, proposed in [1], is a backward-compatible extension to the TFTP protocol, defined in [2].It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's RequestPacket format. The mechanism is kept simple by enforcing a request- respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.

This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation.

 
RFC 1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++)
 
Authors:T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu.
Date:March 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1786
This document was originally published as a RIPE document known as ripe-181 but is also being published as an Informational RFC to reach a larger audience than its original scope. It has received community wide interest and acknowledgment throughout the Internet service provider community and will be used as the basic starting point for future work on Internet Routing Registries and routing policy representation. It can also be referred to as ripe-81++. This document is an update to the original `ripe-81'[1] proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc.[2] and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry.
 
RFC 1787 Routing in a Multi-provider Internet
 
Authors:Y. Rekhter.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1787
This document was prepared by the author on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.

Over the past few years the Internet has undergone significant changes. Among them is the emergence of multiple Network ServiceProviders, where resources that provide Internet-wide IP connectivity(routers, links) are controlled by different organizations. This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing.

 
RFC 1789 INETPhone: Telephone Services and Servers on Internet
 
Authors:C. Yang.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1789
INETPhone is a true telephone service through the Internet. It integrates the local telephone networks and the Internet usingINETPhone servers. Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. In order to support theINETPhone and lay down the ground rules of the service, a scheme of"open partnership" is proposed, so that the entire Internet community can have the equal opportunity and benefits from the INETPhone service.
 
RFC 1790 An Agreement between the Internet Society and Sun Microsystems, Inc
 
Authors:in the Matter of ONC RPC and XDR Protocols. V. Cerf.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1790
This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 1794 DNS Support for Load Balancing
 
Authors:T. Brisco.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1794
This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1
 
Authors:L. Wells, A. Bartky, Ed..
Date:April 1995
Formats:txt pdf
Obsoletes:RFC 1434
Status:INFORMATIONAL
DOI:10.17487/RFC 1795
This RFC describes use of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and Implementers.

This RFC was created as a joint effort of the Advanced Peer-to-PeerNetworking (APPN) Implementers Workshop (AIW) Data Link Switching(DLSw) Related Interest Group (RIG). The APPN Implementers Workshop is a group sponsored by IBM and consists of representatives of member companies implementing current and future IBM Networking interoperable products. The DLSw Related Interest Group was formed in this forum in order to produce a single version of the Switch toSwitch Protocol (SSP) which could be implemented by all vendors, which would fix documentation problems with the existing RFC 1434, and which would enhance and evolve the protocol to add new functions and features.

This document is based on RFC 1434. This document contains significant changes to RFC 1434 and therefore obsoletes that document.

Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com.

NOTE 1: This is a widely subscribed mailing list and messages sent to this address will be sent to all members of the DLSw mailing list.For specific questions relating to subscribing to the AIW and any of it's working groups send email to: appn@vnet.ibm.com

Information regarding all of the AIW working groups and the work they are producing can be obtained by copying, via anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the Internet host networking.raleigh.ibm.com, located in directory aiw.

NOTE 2: These mailing lists and addresses are subject to change.

 
RFC 1796 Not All RFCs are Standards
 
Authors:C. Huitema, J. Postel, S. Crocker.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1796
This document discusses the relationship of the Request for Comments(RFCs) notes to Internet Standards.
 
RFC 1799 Request for Comments Summary RFC Numbers 1700-1799
 
Authors:M. Kennedy.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1799
 
 
RFC 1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing
 
Authors:H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera.
Date:June 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1802
The Internet X.400 community (i.e., GO-MHS) currently lacks a distributed mechanism providing dynamic updating and management of message routing information. The IETF MHS-DS Working Group has specified an approach for X.400 Message Handling Systems to perform message routing using OSI Directory Services. The MHS-DS approach has been successfully tested in a number of local environments.

This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. The results of this pilot will then be used to draw up recommendations for a global deployment.

 
RFC 1803 Recommendations for an X.500 Production Directory Service
 
Authors:R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong.
Date:June 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1803
This document contains a set of basic recommendations for a country- level X.500 DSA. These recommendations can only be considered a starting point in the quest to create a global production qualityX.500 infrastructure. For there to be a true "production quality"X.500 infrastructure more work must be done, including a transition from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500 standard (including the '93 replication and knowledge model). This document does not discuss this transition.
 
RFC 1805 Location-Independent Data/Software Integrity Protocol
 
Authors:A. Rubin.
Date:June 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1805
This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This protocol is intended for the distribution of software, data, documents, and any other file that is subject to malicious modification. The protocol described here is intended to provide assurances of integrity and time. A trusted third party is required.
 
RFC 1807 A Format for Bibliographic Records
 
Authors:R. Lasher, D. Cohen.
Date:June 1995
Formats:txt pdf
Obsoletes:RFC 1357
Status:INFORMATIONAL
DOI:10.17487/RFC 1807
This RFC defines a format for bibliographic records describing technical reports. This format is used by the Cornell UniversityDienst protocol and the Stanford University SIFT system. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992.This is a revision of RFC 1357. New fields include handle, other_access, keyword, and withdraw.
 
RFC 1809 Using the Flow Label Field in IPv6
 
Authors:C. Partridge.
Date:June 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1809
The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo is for information purposes only and is not one of the IPv6 specifications.Distribution of this memo is unlimited.
 
RFC 1810 Report on MD5 Performance
 
Authors:J. Touch.
Date:June 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1810
MD5 is an authentication algorithm, which has been proposed as the default authentication option in IPv6. When enabled, the MD5 algorithm operates over the entire data packet, including header.This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth.MD5 can be implemented in existing hardware technology at 256 Mbps, and in software at 87 Mbps. These rates cannot support current IP rates, e.g., 100 Mbps TCP and 130 Mbps UDP over ATM. If MD5 cannot support existing network bandwidth using existing technology, it will not scale as network speeds increase in the future. This RFC is intended to alert the IP community about the performance limitations of MD5, and to suggest that alternatives be considered for use in high speed IP implementations.
 
RFC 1811 U.S
 
Authors:Government Internet Domain Names. Federal Networking Council.
Date:June 1995
Formats:txt pdf
Obsoleted by:RFC 1816
Status:INFORMATIONAL
DOI:10.17487/RFC 1811
This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.

As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic.

 
RFC 1813 NFS Version 3 Protocol Specification
 
Authors:B. Callaghan, B. Pawlowski, P. Staubach.
Date:June 1995
Formats:txt pdf
Also:RFC 1094
Status:INFORMATIONAL
DOI:10.17487/RFC 1813
This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations.
 
RFC 1814 Unique Addresses are Good
 
Authors:E. Gerich.
Date:June 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1814
The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider.
 
RFC 1815 Character Sets ISO-10646 and ISO-10646-J-1
 
Authors:M. Ohta.
Date:July 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1815
Though the ISO character set standard of ISO 10646 is specified reasonably well about European characters, it is not so useful in an fully internationalized environment.

For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary.

This memo provides information on such profiling, along with charset names to each profiled instance.

Though all the effort is done to make the resulting charset as useful10646 based charset as possible, the result is not so good. So, the charsets defined in this memo are only for reference purpose and its use for practical purpose is strongly discouraged.

 
RFC 1816 U.S
 
Authors:Government Internet Domain Names. Federal Networking Council.
Date:August 1995
Formats:txt pdf
Obsoletes:RFC 1811
Obsoleted by:RFC 2146
Status:INFORMATIONAL
DOI:10.17487/RFC 1816
This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for.GOV can be fit. This policy is exactly comparable to that for the top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.

As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic.

 
RFC 1820 Multimedia E-mail (MIME) User Agent Checklist
 
Authors:E. Huizer.
Date:August 1995
Formats:txt pdf
Obsoleted by:RFC 1844
Status:INFORMATIONAL
DOI:10.17487/RFC 1820
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described.
 
RFC 1821 Integration of Real-time Services in an IP-ATM Network Architecture
 
Authors:M. Borden, E. Crawley, B. Davie, S. Batsell.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1821
The IETF is currently developing an integrated service model which is designed to support real-time services on the Internet.Concurrently, the ATM Forum is developing Asynchronous Transfer Mode networking which similarly provides real-time networking support. The use of ATM in the Internet as a link layer protocol is already occurring, and both the IETF and the ATM Forum are producing specifications for IP over ATM. The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services.
 
RFC 1822 A Grant of Rights to Use a Specific IBM patent with Photuris
 
Authors:J. Lowe.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1822
This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1823 The LDAP Application Program Interface
 
Authors:T. Howes, M. Smith.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1823
This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)
 
Authors:H. Danisch.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1824
This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys.
 
RFC 1834 Whois and Network Information Lookup Service, Whois++
 
Authors:J. Gargano, K. Weiss.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1834
This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1841 PPP Network Control Protocol for LAN Extension
 
Authors:J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett.
Date:September 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1841
Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informationalRFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol.
 
RFC 1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages
 
Authors:Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1842
This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. The 7-bit representation of GB 2312 Chinese text was specified by Fung Fung Lee of Stanford University [Lee89] and implemented in various software packages under different platforms (see appendix for a partial list of the available software packages that support this encoding method). It is further tested and used in the usenet newsgroups alt.chinese.text and chinese.* as well as various other network forums with considerable success. Future extensions of this encoding method can accommodate additional GB character sets and other east asian language character sets [Wei94].

The name given to this encoding is "HZ-GB-2312", which is intended to be used in the "charset" parameter field of MIME headers (see [MIME1] and [MIME2]).

 
RFC 1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters
 
Authors:F. Lee.
Date:August 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1843
The content of this memo is identical to an article of the same title written by the author on September 4, 1989. In this memo, GB stands for GB2312-80. Note that the title is kept only for historical reasons. HZ has been widely used for purposes other than "file exchange".
 
RFC 1844 Multimedia E-mail (MIME) User Agent Checklist
 
Authors:E. Huizer.
Date:August 1995
Formats:txt pdf
Obsoletes:RFC 1820
Status:INFORMATIONAL
DOI:10.17487/RFC 1844
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described.
 
RFC 1853 IP in IP Tunneling
 
Authors:W. Simpson.
Date:October 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1853
This document discusses implementation techniques for using IPProtocol/Payload number 4 Encapsulation for tunneling with IPSecurity and other protocols.
 
RFC 1855 Netiquette Guidelines
 
Authors:S. Hambridge.
Date:October 1995
Formats:txt pdf
Also:FYI 0028
Status:INFORMATIONAL
DOI:10.17487/RFC 1855
This document provides a minimum set of guidelines for NetworkEtiquette (Netiquette) which organizations may take and adapt for their own use. As such, it is deliberately written in a bulleted format to make adaptation easier and to make any particular item easy(or easier) to find. It also functions as a minimum set of guidelines for individuals, both users and administrators. This memo is the product of the Responsible Use of the Network (RUN) WorkingGroup of the IETF.
 
RFC 1856 The Opstat Client-Server Model for Statistics Retrieval
 
Authors:H. Clark.
Date:September 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1856
Network administrators gather data related to the performance, utilization, usability and growth of their data network. The amount of raw data gathered is usually quite large, typically ranging somewhere between several megabytes to several gigabytes of data each month. Few (if any) tools exist today for the sharing of that raw data among network operators or between a network service provider(NSP) and its customers. This document defines a model and protocol for a set of tools which could be used by NSPs and Network OperationCenters (NOCs) to share data among themselves and with customers.
 
RFC 1857 A Model for Common Operational Statistics
 
Authors:M. Lambert.
Date:October 1995
Formats:txt pdf
Obsoletes:RFC 1404
Status:INFORMATIONAL
DOI:10.17487/RFC 1857
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods and presentation formats and defines a format for the exchange of operational statistics.
 
RFC 1858 Security Considerations for IP Fragment Filtering
 
Authors:G. Ziemba, D. Reed, P. Traina.
Date:October 1995
Formats:txt pdf
Updated by:RFC 3128
Status:INFORMATIONAL
DOI:10.17487/RFC 1858
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them.
 
RFC 1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension
 
Authors:Y. Pouffary.
Date:October 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1859
This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1860 Variable Length Subnet Table For IPv4
 
Authors:T. Pummill, B. Manning.
Date:October 1995
Formats:txt pdf
Obsoleted by:RFC 1878
Status:INFORMATIONAL
DOI:10.17487/RFC 1860
This document itemizes the potential values for IPv4 subnets.Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) andDaniel Karrenberg (RIPE).
 
RFC 1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced
 
Authors:A. Gwinn.
Date:October 1995
Formats:txt pdf
Obsoletes:RFC 1645
Status:INFORMATIONAL
DOI:10.17487/RFC 1861
This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. In its simplest form, SNPP provides a simple way to implement a "shim" between theInternet and a TAP/IXO paging terminal. In its level 3 form, it provides an easy-to-use (and build) method for communicating and receiving end-to-end acknowledgments and replies from two-way messaging devices (such as ReFLEX units).

Gateways supporting this protocol, as well as SMTP, have been in use for well over a year at several commercial paging companies, and private businesses. Client software supporting this protocol has become widespread, and is being integrated into many of the new paging and messaging products being built. In addition to commercial software, email filters and SNPP client software for Unix and Windows(WikiPage) are available at no cost. Please contact the author for more information.

Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below.

 
RFC 1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994
 
Authors:M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider.
Date:November 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1862
This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet.
 
RFC 1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet
 
Authors:W. Houser, J. Griffin, C. Hage.
Date:January 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1865
This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI.
 
RFC 1875 UNINETT PCA Policy Statements
 
Authors:N. Berge.
Date:December 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1875
This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
 
Authors:S. Cobb.
Date:December 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1877
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 a family of NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document extends the NCP for establishing and configuring theInternet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server(NBNS) [4] addresses.

 
RFC 1879 Class A Subnet Experiment Results and Recommendations
 
Authors:B. Manning, Ed..
Date:January 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1879
This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1881 IPv6 Address Allocation Management
 
Authors:IAB, IESG.
Date:December 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1881
The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries.
 
RFC 1882 The 12-Days of Technology Before Christmas
 
Authors:B. Hancock.
Date:December 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1882
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1887 An Architecture for IPv6 Unicast Address Allocation
 
Authors:Y. Rekhter, Ed., T. Li, Ed..
Date:December 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1887
This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in [2]. This document does not go into the details of an addressing plan.
 
RFC 1895 The Application/CALS-1840 Content-type
 
Authors:E. Levinson.
Date:February 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1895
This memorandum provides guidelines for using the United StatesDepartment of Defense Military Standard MIL-STD-1840, "AutomatedInterchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. Electronic mail provides a more convenient mechanism that delivery via physical media for certain types and quantities of data. Software already exists to support data exchanges based on MIL-STD-1840 and it can continue to be used in conjunction with electronic mail exchanges defined in this document. This document defines a new media type and a MIME message structure for exchanging data in conformance with MIL-STD-1840.
 
RFC 1896 The text/enriched MIME Content-type
 
Authors:P. Resnick, A. Walker.
Date:February 1996
Formats:txt ps pdf
Obsoletes:RFC 1523, RFC 1563
Status:INFORMATIONAL
DOI:10.17487/RFC 1896
MIME [RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enrichedMIME type. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This document is only a minor revision to the text/enriched MIME type that was first described in[RFC-1523] and [RFC-1563], and is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed.
 
RFC 1898 CyberCash Credit Card Protocol Version 0.8
 
Authors:D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil.
Date:February 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1898
CyberCash is developing a general payments system for use over theInternet. The structure and communications protocols of version 0.8 are described. This version includes credit card payments only.Additional capabilities are planned for future versions.

This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area ofInternet payments. CyberCash is committed to the further development of its system and to cooperation with the Internet Engineering TaskForce and other standards organizations.

 
RFC 1899 Request for Comments Summary RFC Numbers 1800-1899
 
Authors:J. Elliott.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1899
 
 
RFC 1900 Renumbering Needs Work
 
Authors:B. Carpenter, Y. Rekhter.
Date:February 1996
Formats:txt pdf
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 1912 Common DNS Operational and Configuration Errors
 
Authors:D. Barr.
Date:February 1996
Formats:txt pdf
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 1916 Enterprise Renumbering: Experience and Information Solicitation
 
Authors:H. Berkowitz, P. Ferguson, W. Leland, P. Nesser.
Date:February 1996
Formats:txt pdf
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 1919 Classical versus Transparent IP Proxies
 
Authors:M. Chatel.
Date:March 1996
Formats:txt pdf
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 1921 TNVIP Protocol
 
Authors:J. Dujonc.
Date:March 1996
Formats:txt pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 1931 Dynamic RARP Extensions for Automatic Network Address Acquisition
 
Authors:D. Brownell.
Date:April 1996
Formats:txt pdf
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 pdf
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 1934 Ascend's Multilink Protocol Plus (MP+)
 
Authors:K. Smith.
Date:April 1996
Formats:txt pdf
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 pdf
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 pdf
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 pdf
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 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 pdf
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 pdf
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 1943 Building an X.500 Directory Service in the US
 
Authors:B. Jennings.
Date:May 1996
Formats:txt pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 1950 ZLIB Compressed Data Format Specification version 3.3
 
Authors:P. Deutsch, J-L. Gailly.
Date:May 1996
Formats:txt ps pdf
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 ps 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 ps pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 1963 PPP Serial Data Transport Protocol (SDTP)
 
Authors:K. Schneider, S. Venters.
Date:August 1996
Formats:txt pdf
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 1967 PPP LZS-DCP Compression Protocol (LZS-DCP)
 
Authors:K. Schneider, R. Friend.
Date:August 1996
Formats:txt pdf
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 1969 The PPP DES Encryption Protocol (DESE)
 
Authors:K. Sklower, G. Meyer.
Date:June 1996
Formats:txt pdf
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 1974 PPP Stac LZS Compression Protocol
 
Authors:R. Friend, W. Simpson.
Date:August 1996
Formats:txt pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 pdf
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 1983 Internet Users' Glossary
 
Authors:G. Malkin, Ed..
Date:August 1996
Formats:txt pdf
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 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 pdf
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 pdf
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 1991 PGP Message Exchange Formats
 
Authors:D. Atkins, W. Stallings, P. Zimmermann.
Date:August 1996
Formats:txt pdf
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 pdf
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 pdf
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 1998 An Application of the BGP Community Attribute in Multi-home Routing
 
Authors:E. Chen, T. Bates.
Date:August 1996
Formats:txt pdf
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 pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1999
 
 
RFC 2007 Catalogue of Network Training Materials
 
Authors:J. Foster, M. Isaacs, M. Prior.
Date:October 1996
Formats:txt pdf
Also:FYI 0029
Status:INFORMATIONAL
DOI:10.17487/RFC 2007
The purpose of this document is to provide a catalogue of qualityNetwork Training Materials for use by Internet trainers in training their users. By providing such a collection of pointers to useful resources, it is hoped that trainers will be relieved of much of the load of producing current training materials.
 
RFC 2010 Operational Criteria for Root Name Servers
 
Authors:B. Manning, P. Vixie.
Date:October 1996
Formats:txt pdf
Obsoleted by:RFC 2870
Status:INFORMATIONAL
DOI:10.17487/RFC 2010
This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment.
 
RFC 2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
 
Authors:J. Galvin.
Date:October 1996
Formats:txt pdf
Obsoleted by:RFC 2282
Status:INFORMATIONAL
DOI:10.17487/RFC 2027
The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self- consistent, organized compilation of the process as it is known today.
 
RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
 
Authors:D. Mills.
Date:October 1996
Formats:txt pdf
Obsoletes:RFC 1769
Obsoleted by:RFC 4330
Status:INFORMATIONAL
DOI:10.17487/RFC 2030
This memorandum describes the Simple Network Time Protocol (SNTP)Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.

The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI[COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.

This memorandum obsoletes RFC-1769, which describes SNTP Version 3.Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 andOSI), which are also used for SNTP. A working knowledge of the NTPVersion 3 specification RFC-1305 is not required for an implementation of SNTP.

 
RFC 2031 IETF-ISOC relationship
 
Authors:E. Huizer.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2031
This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary.
 
RFC 2033 Local Mail Transfer Protocol
 
Authors:J. Myers.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2033
SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers
 
Authors:C. Kalbfleisch.
Date:November 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2039
This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
 
Authors:R. Baldwin, R. Rivest.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2040
This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2041 Mobile Network Tracing
 
Authors:B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2041
Mobile networks are both poorly understood and difficult to experiment with. This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. The RFC is a status report on our work tracing mobile networks. Our goal is to begin discussion on a standard format for mobile network tracing as well as a testbed for mobile systems research. We present our format for collecting mobile network traces, and tools to produce from such traces analytical models of mobile network behavior.

We also describe a set of tools to provide network modulation based on collected traces. Modulation allows the emulation of wireless channel latency, bandwidth, loss, and error rates on private, wired networks. This allows system designers to test systems in a realistic yet repeatable manner.

 
RFC 2042 Registering New BGP Attribute Types
 
Authors:B. Manning.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2042
This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2044 UTF-8, a transformation format of Unicode and ISO 10646
 
Authors:F. Yergeau.
Date:October 1996
Formats:txt pdf
Obsoleted by:RFC 2279
Status:INFORMATIONAL
DOI:10.17487/RFC 2044
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character.This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.
 
RFC 2053 The AM (Armenia) Domain
 
Authors:E. Der-Danieliantz.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2053
The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2054 WebNFS Client Specification
 
Authors:B. Callaghan.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2054
This document describes a lightweight binding mechanism that allowsNFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. In removing this overhead, WebNFS clients see benefits in faster response to requests, easy transit of packet filter firewalls and TCP-based proxies, and better server scalability.
 
RFC 2055 WebNFS Server Specification
 
Authors:B. Callaghan.
Date:October 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2055
This document describes the specifications for a server of WebNFS clients. WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols. In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalabilityThis description is provided to facilitate compatible implementations of WebNFS servers.
 
RFC 2057 Source Directed Access Control on the Internet
 
Authors:S. Bradner.
Date:November 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2057
This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2059 RADIUS Accounting
 
Authors:C. Rigney.
Date:January 1997
Formats:txt pdf
Obsoleted by:RFC 2139
Status:INFORMATIONAL
DOI:10.17487/RFC 2059
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer.
 
RFC 2061 IMAP4 Compatibility with IMAP2bis
 
Authors:M. Crispin.
Date:December 1996
Formats:txt pdf
Obsoletes:RFC 1730
Status:INFORMATIONAL
DOI:10.17487/RFC 2061
This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2062 Internet Message Access Protocol - Obsolete Syntax
 
Authors:M. Crispin.
Date:December 1996
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2062
This document describes obsolete syntax which may be encountered byIMAP4 implementations which deal with older versions of the InternetMail Access Protocol. IMAP4 implementations MAY implement this syntax in order to maximize interoperability with older implementations.

This document repeats information from earlier documents, most notably RFC 1176 and RFC 1730.

 
RFC 2071 Network Renumbering Overview: Why would I want it and what is it anyway?
 
Authors:P. Ferguson, H. Berkowitz.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2071
The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber. However, it is becoming apparent that, with the increasing number of new Internet ServiceProviders (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined. This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so.
 
RFC 2072 Router Renumbering Guide
 
Authors:H. Berkowitz.
Date:January 1997
Formats:txt pdf
Updated by:RFC 4192
Status:INFORMATIONAL
DOI:10.17487/RFC 2072
IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes inInternet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration.

Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.

Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering.

 
RFC 2076 Common Internet Message Headers
 
Authors:J. Palme.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2076
This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.
 
RFC 2081 RIPng Protocol Applicability Statement
 
Authors:G. Malkin.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2081
As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet.This report is a prerequisite to advancing RIPng on the standards track.
 
RFC 2083 PNG (Portable Network Graphics) Specification Version 1.0
 
Authors:T. Boutell.
Date:March 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2083
This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement forGIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.

PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also,PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.

This specification defines the Internet Media Type image/png.

 
RFC 2084 Considerations for Web Transaction Security
 
Authors:G. Bossert, S. Cooper, W. Drummond.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2084
This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. Such services may be provided as extensions to HTTP, or as an encapsulating security protocol. Secondary requirements include ease of integration and support of multiple mechanisms for providing these services.
 
RFC 2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent
 
Authors:B. Wijnen, D. Levi.
Date:January 1997
Formats:txt pdf
Obsoleted by:RFC 2576
Status:INFORMATIONAL
DOI:10.17487/RFC 2089
The goal of this memo is to document a common way of mapping anSNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2).
 
RFC 2092 Protocol Analysis for Triggered RIP
 
Authors:S. Sherry, G. Meyer.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2092
As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support DemandCircuits [2] and the current implementation experience.

As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted.

 
RFC 2098 Toshiba's Router Architecture Extensions for ATM : Overview
 
Authors:Y. Katsube, K. Nagami, H. Esaki.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2098
This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "CellSwitch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such asRSVP.
 
RFC 2099 Request for Comments Summary RFC Numbers 2000-2099
 
Authors:J. Elliott.
Date:March 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2099
 
 
RFC 2100 The Naming of Hosts
 
Authors:J. Ashworth.
Date:1 April 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2100
This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2101 IPv4 Address Behaviour Today
 
Authors:B. Carpenter, J. Crowcroft, Y. Rekhter.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2101
The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4.
 
RFC 2102 Multicast Support for Nimrod : Requirements and Solution Approaches
 
Authors:R. Ramanathan.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2102
Nimrod does not specify a particular solution for multicasting.Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. We compare existing approaches for multicasting within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support multicast in Nimrod using the scheme currently being developed within the IETF - namely, the Protocol Indpendent Multicast(PIM) protocol.
 
RFC 2103 Mobility Support for Nimrod : Challenges and Solution Approaches
 
Authors:R. Ramanathan.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2103
We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support.We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol.
 
RFC 2104 HMAC: Keyed-Hashing for Message Authentication
 
Authors:H. Krawczyk, M. Bellare, R. Canetti.
Date:February 1997
Formats:txt pdf
Updated by:RFC 6151
Status:INFORMATIONAL
DOI:10.17487/RFC 2104
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function.
 
RFC 2105 Cisco Systems' Tag Switching Architecture Overview
 
Authors:Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2105
This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. Forwarding is accomplished using simple label-swapping techniques, while the existing network layer routing protocols plus mechanisms for binding and distributing tags are used for control. Tag switching can retain the scaling properties of IP, and can help improve the scalability of IP networks. While tag switching does not rely on ATM, it can straightforwardly be applied to ATM switches. A range of tag switching applications and deployment scenarios are described.
 
RFC 2106 Data Link Switching Remote Access Protocol
 
Authors:S. Chiang, J. Lee, H. Yasuda.
Date:February 1997
Formats:txt pdf
Obsoleted by:RFC 2114
Status:INFORMATIONAL
DOI:10.17487/RFC 2106
This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com.
 
RFC 2107 Ascend Tunnel Management Protocol - ATMP
 
Authors:K. Hamzeh.
Date:February 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2107
This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. The user's client software uses an address contained in the home network address space for the remote access. Packets to and from the home network are tunneled by the Network Access Server (NAS) to which the user connects and a Home Agent (HA) on the user's home network. This allows for the support of access to Virtual Private Networks and also allows for the use of protocols other than IP to be carried over the tunnel. An example of how the RADIUS (Remote Authentication Dial InUser Service) can be used to provide the necessary configuration information to support this service is also provided.
 
RFC 2114 Data Link Switching Client Access Protocol
 
Authors:S. Chiang, J. Lee, H. Yasuda.
Date:February 1997
Formats:txt pdf
Obsoletes:RFC 2106
Status:INFORMATIONAL
DOI:10.17487/RFC 2114
This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to dcap@cisco.com.
 
RFC 2116 X.500 Implementations Catalog-96
 
Authors:C. Apple, K. Rossen.
Date:April 1997
Formats:txt pdf
Obsoletes:RFC 1632
Also:FYI 0011
Status:INFORMATIONAL
DOI:10.17487/RFC 2116
This document is a revision to [RFC 1632]: A Revised Catalog ofAvailable X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations ofX.500, including commercial products and openly available offerings.[RFC 1632] is a revision of [RFC 1292]. We contacted each contributor to [RFC 1632] to request an update and published the URL of the WWW home page survey template in several mailing lists to encourage the submission of new product descriptions.

This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces.

 
RFC 2118 Microsoft Point-To-Point Compression (MPPC) Protocol
 
Authors:G. Pall.
Date:March 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2118
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 Microsoft Point to PointCompression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets.

 
RFC 2121 Issues affecting MARS Cluster Size
 
Authors:G. Armitage.
Date:March 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2121
IP multicast over ATM currently uses the MARS model [1] to manage the use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope of any given MARS services is the MARS Cluster - typically the same as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are usually architected with unicast routing and forwarding issues dictating the sizes of individual LISes. However, as IP multicast is deployed as a service, the size of a LIS will only be as big as aMARS Cluster can be. This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups.
 
RFC 2123 Traffic Flow Measurement: Experiences with NeTraMet
 
Authors:N. Brownlee.
Date:March 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2123
This memo records experiences in implementing and using the TrafficFlow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet.
 
RFC 2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0
 
Authors:P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons.
Date:March 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2124
Light-weight Flow Admission Protocol, LFAP, allows an external FlowAdmission Service (FAS) to manage flow admission at the switch, allowing flexible Flow Admission Services to be deployed by a vendor or customer without changes to, or undue burden on, the switch.

Specifically, this document specifies the protocol between the switchConnection Control Entity (CCE) and the external FAS. Using LFAP, aFlow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes.

 
RFC 2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification
 
Authors:K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki.
Date:April 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2129
This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By usingFANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is;

(1) soft-state cut-through path (Dedicated-VC) management(2) protocol between neighbor nodes instead of end-to-end(3) applicable to any connection oriented datalink platform

 
RFC 2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996
 
Authors:C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg.
Date:April 1997
Formats:txt pdf
Updated by:RFC 6055
Status:INFORMATIONAL
DOI:10.17487/RFC 2130
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols.
 
RFC 2133 Basic Socket Interface Extensions for IPv6
 
Authors:R. Gilligan, S. Thomson, J. Bound, W. Stevens.
Date:April 1997
Formats:txt pdf
Obsoleted by:RFC 2553
Status:INFORMATIONAL
DOI:10.17487/RFC 2133
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [5].
 
RFC 2134 Articles of Incorporation of Internet Society
 
Authors:ISOC Board of Trustees.
Date:April 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2134
These are the articles of incorporation of the Internet Society.They are published for the information of the IETF community at the request of the poisson working group.
 
RFC 2135 Internet Society By-Laws
 
Authors:ISOC Board of Trustees.
Date:April 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2135
These are the by-laws of the Internet Society, as amended, as of June1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws.
 
RFC 2139 RADIUS Accounting
 
Authors:C. Rigney.
Date:April 1997
Formats:txt pdf
Obsoletes:RFC 2059
Obsoleted by:RFC 2866
Status:INFORMATIONAL
DOI:10.17487/RFC 2139
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer.
 
RFC 2140 TCP Control Block Interdependence
 
Authors:J. Touch.
Date:April 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2140
This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round- trip time estimates, congestion control information, and process information. This state is currently maintained on a per-connection basis in the TCP control block, but should be shared across connections to the same host. The goal is to improve transient transport performance, while maintaining backward-compatibility with existing implementations.

This document is a product of the LSAM project at ISI.

 
RFC 2144 The CAST-128 Encryption Algorithm
 
Authors:C. Adams.
Date:May 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2144
There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.

This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm (Section 2), the s-boxes (AppendixA), and a set of test vectors (Appendix B).

 
RFC 2145 Use and Interpretation of HTTP Version Numbers
 
Authors:J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk.
Date:May 1997
Formats:txt pdf
Obsoleted by:RFC 7230
Status:INFORMATIONAL
DOI:10.17487/RFC 2145
HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existingHTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP.
 
RFC 2146 U.S
 
Authors:Government Internet Domain Names. Federal Networking Council.
Date:May 1997
Formats:txt pdf
Obsoletes:RFC 1816
Status:INFORMATIONAL
DOI:10.17487/RFC 2146
This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. Two documents are recognized as constituting documentation on the US government structure: FIPS 95-1 provides a standard recognized structure into which domain registrations for .GOV and FED.US can fit; and, the US Government Manual [3], a special publication of theFederal Register, provides official documentation of the government structure. The latter document may be subject to more timely updates than the former. Either document is suitable for determining which entities qualify for second-level domain registration within .GOV andFED.US.

As a side effect, this RFC reduces the number of .GOV and FED.US level registrations and reduces the workload on the registration authority. Previous versions of this document did not address theFED.US domain. This document anticipates the migration of the .GOV domain into the FED.US domain, in keeping with common practice on theInternet today.

 
RFC 2149 Multicast Server Architectures for MARS-based ATM multicasting
 
Authors:R. Talpade, M. Ammar.
Date:May 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2149
A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on aMulticast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined inRFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used withRFC 2022 based MARS server and clients, without needing any change in their functionality.
 
RFC 2150 Humanities and Arts: Sharing Center Stage on the Internet
 
Authors:J. Max, W. Stickle.
Date:October 1997
Formats:txt pdf
Also:FYI 0031
Status:INFORMATIONAL
DOI:10.17487/RFC 2150
This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet.

The purpose of this document is to provide members of the Arts andHumanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.

The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure.

 
RFC 2151 A Primer On Internet and TCP/IP Tools and Utilities
 
Authors:G. Kessler, S. Shepard.
Date:June 1997
Formats:txt pdf
Obsoletes:RFC 1739
Also:FYI 0030
Status:INFORMATIONAL
DOI:10.17487/RFC 2151
This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtainInternet and TCP/IP documents, and some resources that help users weave their way through the Internet.
 
RFC 2152 UTF-7 A Mail-Safe Transformation Format of Unicode
 
Authors:D. Goldsmith, M. Davis.
Date:May 1997
Formats:txt pdf
Obsoletes:RFC 1642
Status:INFORMATIONAL
DOI:10.17487/RFC 2152
The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 2045 through 2049) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.

This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641,"Using Unicode with MIME".

 
RFC 2153 PPP Vendor Extensions
 
Authors:W. Simpson.
Date:May 1997
Formats:txt pdf
Updates:RFC 1661, RFC 1962
Updated by:RFC 5342, RFC 7042
Status:INFORMATIONAL
DOI:10.17487/RFC 2153
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 (LCP) for establishing, configuring, and testing the data-link connection; and a family ofNetwork Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines a general mechanism for proprietary vendor extensions.

 
RFC 2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements
 
Authors:D. Bryant, P. Brittain.
Date:June 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2166
This document specifies

- a set of extensions to RFC 1795 designed to improve the scalability of DLSw- clarifications to RFC 1795 in the light of the implementation experience to-date.

It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology.

This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSwRIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message.

 
RFC 2167 Referral Whois (RWhois) Protocol V1.5
 
Authors:S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra.
Date:June 1997
Formats:txt pdf
Obsoletes:RFC 1714
Status:INFORMATIONAL
DOI:10.17487/RFC 2167
This memo describes Version 1.5 of the client/server interaction ofRWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism.
 
RFC 2170 Application REQuested IP over ATM (AREQUIPA)
 
Authors:W. Almesberger, J. Le Boudec, P. Oechslin.
Date:July 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2170
This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).

Given a mapping from service classes, as defined by INTSERV[6], toATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward.

The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud.

We discuss the implementation of Arequipa for hosts running IPv4 andIPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service.

In particular we show how

- Arequipa can be implemented in IPv4 by slightly modifying the- Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache,- Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses.

Finally, we address safety and security implications.

 
RFC 2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1
 
Authors:K. Murakami, M. Maruyama.
Date:June 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2171
This document describes the protocol MAPOS, Multiple Access Protocol over SONET/SDH, for transmitting network-protocol datagrams overSONET/SDH. It focuses on the core protocol -- other documents listed in the bibliography may be referenced in conjunction with this document to provide support and services for protocols at higher layers.
 
RFC 2172 MAPOS Version 1 Assigned Numbers
 
Authors:M. Maruyama, K. Murakami.
Date:June 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2172
This document describes the protocol parameters used in the MultipleAccess Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links.
 
RFC 2173 A MAPOS version 1 Extension - Node Switch Protocol
 
Authors:K. Murakami, M. Maruyama.
Date:June 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2173
This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. MAPOS is a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address configuration of each node. Using NSP, a node retrieves its HDLC address from the switch to which it is connected.
 
RFC 2174 A MAPOS version 1 Extension - Switch-Switch Protocol
 
Authors:K. Murakami, M. Maruyama.
Date:June 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2174
This document describes a MAPOS version 1 extension, SSP (SwitchSwitch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-LevelData Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, aSONET switch provides the multiple access capability to end nodes.SSP is a protocol of Distance Vector family and provides unicast and broadcast/multicast routing for multiple SONET switch environment.
 
RFC 2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing
 
Authors:K. Murakami, M. Maruyama.
Date:June 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2175
This document describes the protocol MAPOS 16, Multiple AccessProtocol over SONET/SDH with 16 Bit Addressing, for transmitting network-protocol datagrams over SONET/SDH. The primary difference with MAPOS version 1 is that it has 16 bit address field that offers significant wide address space. It first describes the major differences between MAPOS and MAPOS 16 briefly. Then, it explains the header format and its 16 bit address format.
 
RFC 2176 IPv4 over MAPOS Version 1
 
Authors:K. Murakami, M. Maruyama.
Date:June 1997
Formats:txt pdf
Updated by:RFC 5494
Status:INFORMATIONAL
DOI:10.17487/RFC 2176
This document describes a protocol for transmission of the InternetProtocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. IP runs on top of MAPOS. This document explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address Resolution Protocol (ARP).
 
RFC 2179 Network Security For Trade Shows
 
Authors:A. Gwinn.
Date:July 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2179
This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. Generally, it has been observed that many system administrators and trade show coordinators tend to overlook the importance of system security at trade shows. In fact, systems at trade shows are at least as prone to attack as office-based platforms. Trade show systems should be treated as seriously as an office computer. A breach of security of a trade show system can render -- and has rendered -- an exhibitor's demonstrations inoperable -- sometimes for the entire event!

This document is not intended to replace the multitudes of comprehensive books on the subject of Internet security. Rather, its purpose is to provide a checklist-style collection of frequently overlooked, simple ways to minimize the chance of a costly attack.We encourage exhibitors to pay special attention to this document and share it with all associated representatives.

 
RFC 2180 IMAP4 Multi-Accessed Mailbox Practice
 
Authors:M. Gahrns.
Date:July 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2180
The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2185 Routing Aspects of IPv6 Transition
 
Authors:R. Callon, D. Haskin.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2185
This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document"Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document.

The proposals contained in this document are based on the work of theNgtrans working group.

 
RFC 2186 Internet Cache Protocol (ICP), version 2
 
Authors:D. Wessels, K. Claffy.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2186
This document describes version 2 of the Internet Cache Protocol(ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object.

This document describes only the format and fields of ICP messages.A companion document (RFC2187) describes the application of ICP toWeb caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses ofICP for those trying to implement, deploy, and extend its use for their own purposes.

 
RFC 2187 Application of Internet Cache Protocol (ICP), version 2
 
Authors:D. Wessels, K. Claffy.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2187
This document describes the application of ICPv2 (Internet CacheProtocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use.

ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior.

 
RFC 2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2
 
Authors:M. Banan, M. Taylor, J. Cheng.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2188
This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Procedure Call services. The emphasis of ESRO service definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g., CDPD) usage in mind.

ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead. ESRO protocol supports segmentation and reassembly, concatenation and separation as well as multiplexing for service users (applications).

ESRO allows for trade-offs between efficiency and reliability by specifying both 2-way hand-shake and 3-way hand-shake based protocols.

Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of this document. But, identification (tagging) of the encoding mechanism in use (e.g., XDR,

BER, PER) is supported by ESRO protocol.

A variety of applications can use the ESRO protocol. Some early applications using ESRO include efficient short message submission and delivery, credit card authorization and white pages lookup.

 
RFC 2191 VENUS - Very Extensive Non-Unicast Service
 
Authors:G. Armitage.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2191
The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting over ATM, establishing and managing the use of ATM pt- mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast forwarding is achieved using Mrouters, in a similar manner to which the "Classical IP over ATM" model uses Routers to inter-connect LISes for unicast traffic. The development of unicast IP shortcut mechanisms (e.g. NHRP) has led some people to request the development of a Multicast equivalent. There are a number of different approaches. This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service"(VENUS), and shows how complex such a service would be. It is also noted that VENUS ultimately has the look and feel of a single, large cluster using a distributed MARS. This document is being issued to help focus ION efforts towards alternative solutions for establishingATM level multicast connections between LISes.
 
RFC 2194 Review of Roaming Implementations
 
Authors:B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2194
This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2196 Site Security Handbook
 
Authors:B. Fraser.
Date:September 1997
Formats:txt pdf
Obsoletes:RFC 1244
Also:FYI 0008
Status:INFORMATIONAL
DOI:10.17487/RFC 2196
This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response.
 
RFC 2199 Request for Comments Summary RFC Numbers 2100-2199
 
Authors:A. Ramos.
Date:January 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2199
 
 
RFC 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1
 
Authors:P. Cheng, R. Glenn.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2202
This document provides two sets of test cases for HMAC-MD5 and HMAC-SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and other protocols to authenticate messages.The test cases and results provided in this document are meant to be used as a conformance test for HMAC-MD5 and HMAC-SHA-1 implementations.
 
RFC 2204 ODETTE File Transfer Protocol
 
Authors:D. Nash.
Date:September 1997
Formats:txt pdf
Obsoleted by:RFC 5024
Status:INFORMATIONAL
DOI:10.17487/RFC 2204
This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.

The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community.

 
RFC 2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment
 
Authors:A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2208
This document describes the applicability of RSVP along with theIntegrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto theInternet standards track.
 
RFC 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules
 
Authors:R. Braden, L. Zhang.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2209
This memo contains an algorithmic description of the rules used by anRSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification.

This memo provides a generic description of the rules for the operation of Version 1 of RSVP [RFC 2205]. It is intended to outline a set of algorithms that will accomplish the needed function, omitting many details.

 
RFC 2216 Network Element Service Specification Template
 
Authors:S. Shenker, J. Wroclawski.
Date:September 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2216
This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications).
 
RFC 2220 The Application/MARC Content-type
 
Authors:R. Guenther.
Date:October 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2220
This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications.
 
RFC 2223 Instructions to RFC Authors
 
Authors:J. Postel, J. Reynolds.
Date:October 1997
Formats:txt pdf
Obsoletes:RFC 1543, RFC 1111, RFC 0825
Obsoleted by:RFC 7322
Updated by:RFC 5741, RFC 6949
Status:INFORMATIONAL
DOI:10.17487/RFC 2223
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2224 NFS URL Scheme
 
Authors:B. Callaghan.
Date:October 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2224
A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined inRFC 1738, "Uniform Resource Locators (URL)".

This scheme uses the public filehandle and multi-component lookup[RFC2054, RFC2055] to access server data with a minimum of protocol overhead.

The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3[RFC1813], both built on ONC RPC [RFC1831] at its associated eXternalData Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].

 
RFC 2229 A Dictionary Server Protocol
 
Authors:R. Faith, B. Martin.
Date:October 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2229
The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.
 
RFC 2230 Key Exchange Delegation Record for the DNS
 
Authors:R. Atkinson.
Date:November 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2230
This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2235 Hobbes' Internet Timeline
 
Authors:R. Zakon.
Date:November 1997
Formats:txt pdf
Also:FYI 0032
Status:INFORMATIONAL
DOI:10.17487/RFC 2235
This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2237 Japanese Character Encoding for Internet Messages
 
Authors:K. Tamaru.
Date:November 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2237
This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2240 A Legal Basis for Domain Name Allocation
 
Authors:O. Vaughan.
Date:November 1997
Formats:txt pdf
Obsoleted by:RFC 2352
Status:INFORMATIONAL
DOI:10.17487/RFC 2240
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2258 Internet Nomenclator Project
 
Authors:J. Ordille.
Date:January 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2258
The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world.Each CCSO server has a database schema that is tailored to the needs of the organization that owns it. The project is integrating the different database schema into one query service. The InternetNomenclator Project will provide fast cross-server searches for locating people on the Internet. It augments existing CCSO services by supplying schema integration, more extensive indexing, and two kinds of caching -- all this in a system that scales as the number ofCCSO servers grows. One of the best things about the system is that administrators can incorporate their CCSO servers into Nomenclator without changing the servers. All Nomenclator needs is basic information about the server.

This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet NomenclatorProject, and how to use the Nomenclator search engine to find people on the Internet.

 
RFC 2259 Simple Nomenclator Query Protocol (SNQP)
 
Authors:J. Elliott, J. Ordille.
Date:January 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2259
The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500.

SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere.

 
RFC 2260 Scalable Support for Multi-homed Multi-provider Connectivity
 
Authors:T. Bates, Y. Rekhter.
Date:January 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2260
This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
 
Authors:P. Ferguson, D. Senie.
Date:January 1998
Formats:txt pdf
Obsoleted by:RFC 2827
Status:INFORMATIONAL
DOI:10.17487/RFC 2267
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.
 
RFC 2268 A Description of the RC2(r) Encryption Algorithm
 
Authors:R. Rivest.
Date:March 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2268
This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2269 Using the MARS Model in non-ATM NBMA Networks
 
Authors:G. Armitage.
Date:January 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2269
Initially developed for IP over ATM, the RFC 2022 (MARS) model is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. RFC 2022 is not required over NBMA networks that offer Ethernet-like group addressing functionality.
 
RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider
 
Authors:J. Stewart, T. Bates, R. Chandra, E. Chen.
Date:January 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2270
With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930.
 
RFC 2276 Architectural Principles of Uniform Resource Name Resolution
 
Authors:K. Sollins.
Date:January 1998
Formats:txt pdf
Updated by:RFC 3401
Status:INFORMATIONAL
DOI:10.17487/RFC 2276
This document addresses the issues of the discovery of URN (UniformResource Name) resolver services that in turn will directly translateURNs into URLs (Uniform Resource Locators) and URCs (Uniform ResourceCharacteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately.
 
RFC 2278 IANA Charset Registration Procedures
 
Authors:N. Freed, J. Postel.
Date:January 1998
Formats:txt pdf
Obsoleted by:RFC 2978
Status:INFORMATIONAL
DOI:10.17487/RFC 2278
MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
 
RFC 2281 Cisco Hot Standby Router Protocol (HSRP)
 
Authors:T. Li, B. Cole, P. Morton, D. Li.
Date:March 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2281
The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. Multiple routers participate in this protocol and in concert create the illusion of a single virtual router. The protocol insures that one and only one of the routers is forwarding packets on behalf of the virtual router. End hosts forward their packets to the virtual router.

The router forwarding packets is known as the active router. A standby router is selected to replace the active router should it fail. The protocol provides a mechanism for determining active and standby routers, using the IP addresses on the participating routers.If an active router fails a standby router can take over without a major interruption in the host's connectivity. This memo also discusses the ARP, MAC address, and security issues with this protocol.

 
RFC 2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
 
Authors:J. Galvin.
Date:February 1998
Formats:txt pdf
Obsoletes:RFC 2027
Obsoleted by:RFC 2727
Status:INFORMATIONAL
DOI:10.17487/RFC 2282
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today.
 
RFC 2285 Benchmarking Terminology for LAN Switching Devices
 
Authors:R. Mandeville.
Date:February 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2285
This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
 
Authors:J. Kapp.
Date:February 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2286
This document provides two sets of test cases for HMAC-RIPEMD160 andHMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are two constructs of the HMAC [HMAC] message authentication function using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128 implementations.
 
RFC 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names
 
Authors:C. Lynch, C. Preston, R. Daniel.
Date:February 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2288
A system for Uniform Resource Names (URNs) must be capable of supporting identifiers from existing widely-used naming systems.This document discusses how three major bibliographic identifiers(the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs.
 
RFC 2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
 
Authors:J. Slein, F. Vitali, E. Whitehead, D. Durand.
Date:February 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2291
Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW.
 
RFC 2292 Advanced Sockets API for IPv6
 
Authors:W. Stevens, M. Thomas.
Date:February 1998
Formats:txt pdf
Obsoleted by:RFC 3542
Status:INFORMATIONAL
DOI:10.17487/RFC 2292
Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like.

But another class of applications exists that will also be run underIPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.

There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too.

 
RFC 2297 Ipsilon's General Switch Management Protocol Specification Version 2.0
 
Authors:P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.
Date:March 1998
Formats:txt pdf
Updates:RFC 1987
Status:INFORMATIONAL
DOI:10.17487/RFC 2297
This memo specifies enhancements to the General Switch ManagementProtocol (GSMP) [RFC1987]. The major enhancement is the addition ofQuality of Service (QoS) messages. Other improvements have been made to the protocol resulting from operational experience. GSMP is a general purpose protocol to control an ATM switch. It allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; and request statistics.
 
RFC 2299 Request for Comments Summary
 
Authors:A. Ramos.
Date:January 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2299
 
 
RFC 2306 Tag Image File Format (TIFF) - F Profile for Facsimile
 
Authors:G. Parsons, J. Rafferty.
Date:March 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2306
This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet
 
Authors:B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang.
Date:April 1998
Formats:txt pdf
Obsoleted by:RFC 7567
Updated by:RFC 7141
Status:INFORMATIONAL
DOI:10.17487/RFC 2309
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.
 
RFC 2313 PKCS #1: RSA Encryption Version 1.5
 
Authors:B. Kaliski.
Date:March 1998
Formats:txt pdf
Obsoleted by:RFC 2437
Status:INFORMATIONAL
DOI:10.17487/RFC 2313
This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2314 PKCS #10: Certification Request Syntax Version 1.5
 
Authors:B. Kaliski.
Date:March 1998
Formats:txt pdf
Obsoleted by:RFC 2986
Status:INFORMATIONAL
DOI:10.17487/RFC 2314
This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2315 PKCS #7: Cryptographic Message Syntax Version 1.5
 
Authors:B. Kaliski.
Date:March 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2315
This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2316 Report of the IAB Security Architecture Workshop
 
Authors:S. Bellovin.
Date:April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2316
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2318 The text/css Media Type
 
Authors:H. Lie, B. Bos, C. Lilley.
Date:March 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2318
Cascading Style Sheets (CSS) is a style sheet language for the WorldWide Web. CSS style sheets have been in use since October 1995 using the Media Type text/css without registration; this memo seeks to regularize that position.
 
RFC 2319 Ukrainian Character Set KOI8-U
 
Authors:KOI8-U Working Group.
Date:April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2319
This document provides information about character encoding KOI8-U(KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. KOI8-U is compatible with KOI8-R (RFC 1489) in allRussian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. The official site of KOI8-UWorking Group is http://www.net.ua.
 
RFC 2321 RITA -- The Reliable Internetwork Troubleshooting Agent
 
Authors:A. Bressen.
Date:1 April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2321
A Description of the usage of Nondeterministic Troubleshooting andDiagnostic Methodologies as applied to today's complex nondeterministic networks and environments.
 
RFC 2322 Management of IP numbers by peg-dhcp
 
Authors:K. van den Hout, A. Koopal, R. van Mook.
Date:1 April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2322
This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2323 IETF Identification and Security Guidelines
 
Authors:A. Ramos.
Date:1 April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2323
This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
 
Authors:L. Masinter.
Date:1 April 1998
Formats:txt pdf
Updated by:RFC 7168
Status:INFORMATIONAL
DOI:10.17487/RFC 2324
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.
 
RFC 2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
 
Authors:M. Slavitch.
Date:1 April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2325
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2329 OSPF Standardization Report
 
Authors:J. Moy.
Date:April 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2329
This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met forOSPFv2.

Please send comments to ospf@gated.cornell.edu.

 
RFC 2330 Framework for IP Performance Metrics
 
Authors:V. Paxson, G. Almes, J. Mahdavi, M. Mathis.
Date:May 1998
Formats:txt pdf
Updated by:RFC 7312, RFC 8468
Status:INFORMATIONAL
DOI:10.17487/RFC 2330
The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2336 Classical IP and ARP over ATM to NHRP Transition
 
Authors:J. Luciani.
Date:July 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2336
This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model overATM.
 
RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc
 
Authors:in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems.
Date:May 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2339
This Request for Comments records an agreement between SunMicrosystems, Inc. and the Internet Society to permit the flow ofSun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force.
 
RFC 2340 Nortel's Virtual Network Switching (VNS) Overview
 
Authors:B. Jamoussi, D. Jamieson, D. Williston, S. Gabe.
Date:May 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2340
This document provides an overview of Virtual Network Switching(VNS).

VNS is a multi-protocol switching architecture that provides COS- sensitive packet switching, reduces the complexity of operating protocols like PPP and frame relay, provides logical networks and traffic segregation for Virtual Private Networks (VPNs), security and traffic engineering, enables efficient WAN broadcasting and multicasting, and reduces address space requirements. VNS reduces the number of routing hops over the WAN by switching packets based on labels.

VNS has been proven in production networks for several years.

 
RFC 2346 Making Postscript and PDF International
 
Authors:J. Palme.
Date:May 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2346
Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable DocumentFormat (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world.North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. By using the advice in this document, you can put up a document on theInternet, which recipients can print without problem both in and outside North America.

A very short summary of the advice in this document: If you are usingU.S. Letter paper format, ensure that both the left and right margins are at least 21 mm (0.8 in). If you are using A4 paper format, ensure that both the top and bottom margins are at least 33 mm (1.3 in).

 
RFC 2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP
 
Authors:A. Robert.
Date:May 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2351
This memo specifies a protocol for the encapsulation of the airline specific protocol over IP.
 
RFC 2352 A Convention For Using Legal Names as Domain Names
 
Authors:O. Vaughan.
Date:May 1998
Formats:txt pdf
Obsoletes:RFC 2240
Status:INFORMATIONAL
DOI:10.17487/RFC 2352
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document
 
Authors:G. Dudley.
Date:May 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2353
This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2354 Options for Repair of Streaming Media
 
Authors:C. Perkins, O. Hodson.
Date:June 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2354
This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies.
 
RFC 2356 Sun's SKIP Firewall Traversal for Mobile IP
 
Authors:G. Montenegro, V. Gupta.
Date:June 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2356
The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network.

In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space.

 
RFC 2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols
 
Authors:A. Mankin, A. Romanow, S. Bradner, V. Paxson.
Date:June 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2357
This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of theIETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes1997].

A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications.[Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet?

The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols.

 
RFC 2361 WAVE and AVI Codec Registries
 
Authors:E. Fleischman.
Date:June 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2361
Internet applications may reference specific codecs within the WAVE and AVI registries as follows:* video/vnd.avi; codec=XXX identifies a specific video codec (i.e.,XXX) within the AVI Registry.* audio/vnd.wave; codec=YYY identifies a specific audio codec(i.e., YYY) within the WAVE Registry.

Appendix A and Appendix B provides an authoritative reference for the interpretation of the required "codec" parameter. That is, the current set of audio codecs that are registered within the WAVERegistry are enumerated in Appendix A. Appendix B enumerates the current set of video codecs that have been registered to date within the AVI Registry.

 
RFC 2367 PF_KEY Key Management API, Version 2
 
Authors:D. McDonald, C. Metz, B. Phan.
Date:July 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2367
A generic key management API that can be used not only for IPSecurity [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of thisAPI was implemented inside 4.4-Lite BSD as part of the U. S. NavalResearch Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], aPhoturis daemon, or a SKIP certificate discovery protocol daemon).
 
RFC 2372 Transaction Internet Protocol - Requirements and Supplemental Information
 
Authors:K. Evans, J. Klein, J. Lyon.
Date:July 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2372
This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol [1]. It is intended to help qualify the necessary features and functions of the protocol. It also provides supplemental information to aid understanding and facilitate implementation of the TIP protocol.
 
RFC 2375 IPv6 Multicast Address Assignments
 
Authors:R. Hinden, S. Deering.
Date:July 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2375
This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2376 XML Media Types
 
Authors:E. Whitehead, M. Murata.
Date:July 1998
Formats:txt pdf
Obsoleted by:RFC 3023
Status:INFORMATIONAL
DOI:10.17487/RFC 2376
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the WorldWide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
 
RFC 2377 Naming Plan for Internet Directory-Enabled Applications
 
Authors:A. Grimstad, R. Huber, S. Sataluri, M. Wahl.
Date:September 1998
Formats:txt pdf
Updated by:RFC 4519
Status:INFORMATIONAL
DOI:10.17487/RFC 2377
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach.
 
RFC 2378 The CCSO Nameserver (Ph) Architecture
 
Authors:R. Hedberg, P. Pomes.
Date:September 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2378
The Ph Nameserver from the Computing and Communications ServicesOffice (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. The Ph service as specified in this document is built around an information model, a client command language and the server responses.
 
RFC 2382 A Framework for Integrated Services and RSVP over ATM
 
Authors:E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk.
Date:August 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2382
This document outlines the issues and framework related to providingIP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group.
 
RFC 2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version
 
Authors:M. Suzuki.
Date:August 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2383
This document specifies an ATM-based protocol for communication between ST2+ agents. The ST2+ over ATM protocol supports the matching of one hop in an ST2+ tree-structure stream with one ATM connection.In this document, ATM is a subnet technology for the ST2+ stream.

The ST2+ over ATM protocol is designed to achieve resource- reservation communications across ATM and non-ATM networks, to extend the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ signaling limitations.

The specifications of the ST2+ over ATM protocol consist of a revision of RFC 1819 ST2+ and specifications of protocol interaction between ST2+ and ATM on the user plane, management plane, and control plane which correspond to the three planes of the B-ISDN protocol reference model.

 
RFC 2386 A Framework for QoS-based Routing in the Internet
 
Authors:E. Crawley, R. Nair, B. Rajagopalan, H. Sandick.
Date:August 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2386
This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2391 Load Sharing using IP Network Address Translation (LSNAT)
 
Authors:P. Srisuresh, D. Gan.
Date:August 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2391
Network Address Translators (NATs) translate IP addresses in a datagram, transparent to end nodes, while routing the datagram. NATs have traditionally been been used to allow private network domains to connect to Global networks using as few as one globally unique IP address. In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. Load sharing is beneficial to service providers and system administrators alike in grappling with scalability of servers with increasing session load.
 
RFC 2394 IP Payload Compression Using DEFLATE
 
Authors:R. Pereira.
Date:December 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2394
This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of theDEFLATE algorithm to the IP Payload Compression Protocol.
 
RFC 2395 IP Payload Compression Using LZS
 
Authors:R. Friend, R. Monsour.
Date:December 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2395
This document describes a compression method based on the LZS compression algorithm. This document defines the application of theLZS algorithm to the IP Payload Compression Protocol [IPCOMP].[IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams.
 
RFC 2398 Some Testing Tools for TCP Implementors
 
Authors:S. Parker, C. Schmechel.
Date:August 1998
Formats:txt pdf
Also:FYI 0033
Status:INFORMATIONAL
DOI:10.17487/RFC 2398
This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 2399 Request for Comments Summary
 
Authors:A. Ramos.
Date:January 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2399
 
 
RFC 2411 IP Security Document Roadmap
 
Authors:R. Thayer, N. Doraswamy, R. Glenn.
Date:November 1998
Formats:txt pdf
Obsoleted by:RFC 6071
Status:INFORMATIONAL
DOI:10.17487/RFC 2411
The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and AuthenticationAlgorithm documents are described.
 
RFC 2412 The OAKLEY Key Determination Protocol
 
Authors:H. Orman.
Date:November 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2412
This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material.The basic mechanism is the Diffie-Hellman key exchange algorithm.

The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user- defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms.

 
RFC 2413 Dublin Core Metadata for Resource Discovery
 
Authors:S. Weibel, J. Kunze, C. Lagoze, M. Wolf.
Date:September 1998
Formats:txt pdf
Obsoleted by:RFC 5013
Status:INFORMATIONAL
DOI:10.17487/RFC 2413
This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.
 
RFC 2415 Simulation Studies of Increased Initial TCP Window Size
 
Authors:K. Poduri, K. Nichols.
Date:September 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2415
An increase in the permissible initial window size of a TCP connection, from one segment to three or four segments, has been under discussion in the tcp-impl working group. This document covers some simulation studies of the effects of increasing the initial window size of TCP. Both long-lived TCP connections (file transfers) and short-lived web-browsing style connections were modeled. The simulations were performed using the publicly available ns-2 simulator and our custom models and files are also available.
 
RFC 2416 When TCP Starts Up With Four Packets Into Only Three Buffers
 
Authors:T. Shepard, C. Partridge.
Date:September 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2416
This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet).
 
RFC 2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)
 
Authors:T. Li, Y. Rekhter.
Date:October 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2430
This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.
 
RFC 2432 Terminology for IP Multicast Benchmarking
 
Authors:K. Dubray.
Date:October 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2432
The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 2285, and other IETF BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.

The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology documents present the benchmarks and other related terms.The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.

 
RFC 2433 Microsoft PPP CHAP Extensions
 
Authors:G. Zorn, S. Cobb.
Date:October 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2433
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.
 
RFC 2436 Collaboration between ISOC/IETF and ITU-T
 
Authors:R. Brett, S. Bradner, G. Parsons.
Date:October 1998
Formats:txt pdf
Obsoleted by:RFC 3356
Status:INFORMATIONAL
DOI:10.17487/RFC 2436
This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.
 
RFC 2437 PKCS #1: RSA Cryptography Specifications Version 2.0
 
Authors:B. Kaliski, J. Staddon.
Date:October 1998
Formats:txt pdf
Obsoletes:RFC 2313
Obsoleted by:RFC 3447
Status:INFORMATIONAL
DOI:10.17487/RFC 2437
This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.
 
RFC 2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998
 
Authors:D. Cohen.
Date:November 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2441
This memo provides information for the Internet community.
 
RFC 2442 The Batch SMTP Media Type
 
Authors:N. Freed, D. Newman, J. Belissent, M. Hoy.
Date:November 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2442
This document defines a MIME content type suitable for tunneling anESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g.,[RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such asNOTARY [RFC-1891] over unextended SMTP transport infrastructure.Enabling the transfer of multiple separate messages in a single transactional unit.
 
RFC 2448 AT&T's Error Resilient Video Transmission Technique
 
Authors:M. Civanlar, G. Cash, B. Haskell.
Date:November 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2448
This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. The described techniques can be used over packet networks without packet prioritization. These techniques are related to AT&T/Lucent patents[1, 2].
 
RFC 2450 Proposed TLA and NLA Assignment Rule
 
Authors:R. Hinden.
Date:December 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2450
This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.
 
RFC 2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
 
Authors:H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan.
Date:November 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2458
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public SwitchedTelephone Network (PSTN)/Internet Inter-Networking (PINT) WorkingGroup. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet andPSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over thePSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of thePINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.
 
RFC 2468 I REMEMBER IANA
 
Authors:V. Cerf.
Date:October 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2468
A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.
 
RFC 2469 A Caution On The Canonical Ordering Of Link-Layer Addresses
 
Authors:T. Narten, C. Burton.
Date:December 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2469
Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required.
 
RFC 2475 An Architecture for Differentiated Services
 
Authors:S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss.
Date:December 1998
Formats:txt pdf
Updated by:RFC 3260
Status:INFORMATIONAL
DOI:10.17487/RFC 2475
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field[DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.
 
RFC 2477 Criteria for Evaluating Roaming Protocols
 
Authors:B. Aboba, G. Zorn.
Date:January 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2477
This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.
 
RFC 2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)
 
Authors:C. Adams.
Date:December 1998
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2479
The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community.
 
RFC 2490 A Simulation Model for IP Multicast with RSVP
 
Authors:M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah.
Date:January 1999
Formats:txt pdf ps
Status:INFORMATIONAL
DOI:10.17487/RFC 2490
This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting.
 
RFC 2499 Request for Comments Summary
 
Authors:A. Ramos.
Date:July 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2499
 
 
RFC 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations
 
Authors:S. Corson, J. Macker.
Date:January 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2501
This memo first describes the characteristics of Mobile Ad hocNetworks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations.
 
RFC 2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment
 
Authors:M. Pullen, M. Myjak, C. Bouwens.
Date:February 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2502
The Large-Scale Multicast Applications (LSMA) working group was chartered to produce documents aimed at a consensus based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements.
 
RFC 2503 MIME Types for Use with the ISO ILL Protocol
 
Authors:R. Moulton, M. Needleman.
Date:February 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2503
This memorandum describes a set of MIME types for use with the ISOInterlibrary Loan Protocol (ISO 10160/10161). Two MIME types are specified below.

The first is a media type to carry objects which are BER [BER] encoded ISO ILL Protocol Data Units (PDU's). BER are the basicEncoding Rules used to encode PDU's which have been described usingASN.1 (Abstract Syntax Notation 1) [ASN.1] .

The second is for use with the associated document delivery instructions. Document Delivery Instructions (DDI) is an emerging protocol which enables automatic electronic delivery of items. It allows a request management system (which might have received a request for an item via the ISO Interlibrary Loan Protocol (ISO10160/10161)) to pass details of the request, item, and delivery, to a delivery module, and to receive back reports on the delivery process or arrival of an item. It is currently being submitted to theISO TC46/SC4/WG4 committee for approval as an ISO standard.

 
RFC 2504 Users' Security Handbook
 
Authors:E. Guttman, L. Leong, G. Malkin.
Date:February 1999
Formats:txt pdf
Also:FYI 0034
Status:INFORMATIONAL
DOI:10.17487/RFC 2504
The Users' Security Handbook is the companion to the Site SecurityHandbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure.
 
RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)
 
Authors:L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler.
Date:February 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2516
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.

This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet.

 
RFC 2517 Building Directories from DNS: Experiences from WWWSeeker
 
Authors:R. Moats, R. Huber.
Date:February 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2517
There has been much discussion and several documents written about the need for an Internet Directory. Recently, this discussion has focused on ways to discover an organization's domain name without relying on use of DNS as a directory service. This memo discusses lessons that were learned during InterNIC Directory and DatabaseServices' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. The back end database that drives this application was built from information obtained from domain registries via WHOIS and other protocols. We present this information to help future implementors avoid some of the blind alleys that we have already explored. This work builds on the Netfind system that was created byMike Schwartz and his team at the University of Colorado at Boulder[1].
 
RFC 2519 A Framework for Inter-Domain Route Aggregation
 
Authors:E. Chen, J. Stewart.
Date:February 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2519
This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing.
 
RFC 2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3
 
Authors:M. Banan.
Date:February 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2524
This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.
 
RFC 2525 Known TCP Implementation Problems
 
Authors:V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz.
Date:March 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2525
This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.
 
RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
 
Authors:S. Chokhani, W. Ford.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 3647
Status:INFORMATIONAL
DOI:10.17487/RFC 2527
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.
 
RFC 2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates
 
Authors:R. Housley, W. Polk.
Date:March 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2528
The Key Exchange Algorithm (KEA) is a classified algorithm for exchanging keys. This specification profiles the format and semantics of fields in X.509 V3 certificates containing KEA keys. The specification addresses the subjectPublicKeyInfo field and the keyUsage extension.
 
RFC 2541 DNS Security Operational Considerations
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 4641
Status:INFORMATIONAL
DOI:10.17487/RFC 2541
Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.
 
RFC 2542 Terminology and Goals for Internet Fax
 
Authors:L. Masinter.
Date:March 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2542
This document defines a number of terms useful for the discussion ofInternet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including'real-time', 'session', and 'store and forward'. Different levels of desirability are indicated throughout the document.
 
RFC 2544 Benchmarking Methodology for Network Interconnect Devices
 
Authors:S. Bradner, J. McQuaid.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 1944
Updated by:RFC 6201, RFC 6815
Status:INFORMATIONAL
DOI:10.17487/RFC 2544
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 2546 6Bone Routing Practice
 
Authors:A. Durand, B. Buclin.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 2772
Status:INFORMATIONAL
DOI:10.17487/RFC 2546
This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.
 
RFC 2547 BGP/MPLS VPNs
 
Authors:E. Rosen, Y. Rekhter.
Date:March 1999
Formats:txt pdf
Obsoleted by:RFC 4364
Status:INFORMATIONAL
DOI:10.17487/RFC 2547
This document describes a method by which a Service Provider with anIP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border GatewayProtocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers.
 
RFC 2548 Microsoft Vendor-specific RADIUS Attributes
 
Authors:G. Zorn.
Date:March 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2548
This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft proprietary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-specific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.
 
RFC 2549 IP over Avian Carriers with Quality of Service
 
Authors:D. Waitzman.
Date:1 April 1999
Formats:txt pdf
Updates:RFC 1149
Status:INFORMATIONAL
DOI:10.17487/RFC 2549
This memo amends RFC 1149, "A Standard for the Transmission of IPDatagrams on Avian Carriers", with Quality of Service information.This is an experimental, not recommended standard.
 
RFC 2550 Y10K and Beyond
 
Authors:S. Glassman, M. Manasse, J. Mogul.
Date:1 April 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2550
As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem. Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail.

This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem(Roman numerals).

 
RFC 2551 The Roman Standards Process -- Revision III
 
Authors:S. Bradner.
Date:1 April 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2551
This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.
 
RFC 2552 Architecture for the Information Brokerage in the ACTS Project GAIA
 
Authors:M. Blinov, M. Bessonov, C. Clissmann.
Date:April 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2552
This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability).
 
RFC 2553 Basic Socket Interface Extensions for IPv6
 
Authors:R. Gilligan, S. Thomson, J. Bound, W. Stevens.
Date:March 1999
Formats:txt pdf
Obsoletes:RFC 2133
Obsoleted by:RFC 3493
Updated by:RFC 3152
Status:INFORMATIONAL
DOI:10.17487/RFC 2553
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4].
 
RFC 2555 30 Years of RFCs
 
Authors:RFC Editor, et al..
Date:April 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2555
The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.
 
RFC 2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status
 
Authors:S. Bradner.
Date:March 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2556
RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility.
 
RFC 2570 Introduction to Version 3 of the Internet-standard Network Management Framework
 
Authors:J. Case, R. Mundy, D. Partain, B. Stewart.
Date:April 1999
Formats:txt pdf
Obsoleted by:RFC 3410
Status:INFORMATIONAL
DOI:10.17487/RFC 2570
The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard ManagementFramework (SNMPv1) and the second Internet-standard ManagementFramework (SNMPv2).

The architecture is designed to be modular to allow the evolution of the Framework over time.

 
RFC 2577 FTP Security Considerations
 
Authors:M. Allman, S. Ostermann.
Date:May 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2577
The specification for the File Transfer Protocol (FTP) contains a number of mechanisms that can be used to compromise network security.The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force "password guessing" attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP.
 
RFC 2583 Guidelines for Next Hop Client (NHC) Developers
 
Authors:R. Carlson, L. Winkler.
Date:May 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2583
This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.
 
RFC 2586 The Audio/L16 MIME content type
 
Authors:J. Salsman, H. Alvestrand.
Date:May 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2586
This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.
 
RFC 2588 IP Multicast and Firewalls
 
Authors:R. Finlayson.
Date:May 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2588
In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.
 
RFC 2599 Request for Comments Summary RFC Numbers 2500-2599
 
Authors:A. DeLaCruz.
Date:March 2000
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2599
 
 
RFC 2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP
 
Authors:R. Gellens.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 2636
Status:INFORMATIONAL
DOI:10.17487/RFC 2604
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.

One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.

IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.

This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol.

 
RFC 2607 Proxy Chaining and Policy Implementation in Roaming
 
Authors:B. Aboba, J. Vollbrecht.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2607
This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.
 
RFC 2612 The CAST-256 Encryption Algorithm
 
Authors:C. Adams, J. Gilchrist.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2612
There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.

This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A).

 
RFC 2614 An API for Service Location
 
Authors:J. Kempf, E. Guttman.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2614
The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered withSLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database.
 
RFC 2620 RADIUS Accounting Client MIB
 
Authors:B. Aboba, G. Zorn.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 4670
Status:INFORMATIONAL
DOI:10.17487/RFC 2620
This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients.
 
RFC 2621 RADIUS Accounting Server MIB
 
Authors:G. Zorn, B. Aboba.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 4671
Status:INFORMATIONAL
DOI:10.17487/RFC 2621
This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers.
 
RFC 2624 NFS Version 4 Design Considerations
 
Authors:S. Shepler.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2624
The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on theInternet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.

This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas.

 
RFC 2626 The Internet and the Millennium Problem (Year 2000)
 
Authors:P. Nesser II.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2626
The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols.This investigation only targeted the protocols as documented in theRequest For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost allInternet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation.
 
RFC 2627 Key Management for Multicast: Issues and Architectures
 
Authors:D. Wallner, E. Harder, R. Agee.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2627
This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group.
 
RFC 2628 Simple Cryptographic Program Interface (Crypto API)
 
Authors:V. Smyslov.
Date:June 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2628
This document describes a simple Application Program Interface to cryptographic functions. The main purpose of such an interface is to separate cryptographic libraries from internet applications, thus allowing an independent development of both. It can be used in various internet applications such as [IPsec], [ISAKMP], [IKE],[TLS].
 
RFC 2629 Writing I-Ds and RFCs using XML
 
Authors:M. Rose.
Date:June 1999
Formats:txt pdf
Obsoleted by:RFC 7749
Status:INFORMATIONAL
DOI:10.17487/RFC 2629
This memo presents a technique for using XML (Extensible MarkupLanguage) as a source format for documents in the Internet-Drafts(I-Ds) and Request for Comments (RFC) series.
 
RFC 2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)
 
Authors:S. Hambridge, A. Lunde.
Date:June 1999
Formats:txt pdf
Also:FYI 0035
Status:INFORMATIONAL
DOI:10.17487/RFC 2635
This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow.
 
RFC 2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP
 
Authors:R. Gellens.
Date:July 1999
Formats:txt ps pdf
Obsoletes:RFC 2604
Status:INFORMATIONAL
DOI:10.17487/RFC 2636
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.

One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.

IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.

This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol.

 
RFC 2637 Point-to-Point Tunneling Protocol (PPTP)
 
Authors:K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn.
Date:July 1999
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2637
This document specifies a protocol which allows the Point to PointProtocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network AccessServers (NAS) and support Virtual Private Networks (VPNs). The PPTPNetwork Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP AccessConcentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic RoutingEncapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.
 
RFC 2638 A Two-bit Differentiated Services Architecture for the Internet
 
Authors:K. Nichols, V. Jacobson, L. Zhang.
Date:July 1999
Formats:txt ps pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 2638
This document was originally submitted as an internet draft inNovember of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services WorkingGroup, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form.The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.

The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability.