Internet Documents RFCs RFCs All Documents STDs Internet Standards Documents BCPs Best Current Practice Documents FYIs Informational Documents

RFC 35	Network Meeting
	Authors: S.D. Crocker. Date: March 1970 Formats: txt pdf Status: INFORMATIONAL
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
RFC 699	Request For Comments summary notes: 600-699
	Authors: J. Postel, J. Vernon. Date: November 1982 Formats: txt pdf Status: INFORMATIONAL
RFC 800	Request For Comments summary notes: 700-799
	Authors: J. Postel, J. Vernon. Date: November 1982 Formats: txt pdf Status: INFORMATIONAL 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 899	Request For Comments summary notes: 800-899
	Authors: J. Postel, A. Westine. Date: May 1984 Formats: txt pdf Status: INFORMATIONAL
RFC 1012	Bibliography of Request For Comments 1 through 999
	Authors: J.K. Reynolds, J. Postel. Date: June 1987 Formats: txt pdf Status: INFORMATIONAL 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 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 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 1094	NFS: Network File System Protocol specification
	Authors: B. Nowicki. Date: March 1989 Formats: txt pdf Also: RFC 1813 Status: INFORMATIONAL 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
RFC 1107	Plan for Internet directory services
	Authors: K.R. Sollins. Date: July 1989 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 pdf ps Also: RFC 1119 Status: INFORMATIONAL 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 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 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 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 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 1142	OSI IS-IS Intra-domain Routing Protocol
	Authors: D. Oran, Ed.. Date: February 1990 Formats: txt pdf ps Status: INFORMATIONAL This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.
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 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 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 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 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 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 pdf ps Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
RFC 1202	Directory Assistance service
	Authors: M.T. Rose. Date: February 1991 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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: April 1 1991 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1991 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 pdf ps Also: RFC 1247, RFC 1246 Status: INFORMATIONAL 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 1247, RFC 1245 Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 pdf ps Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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
RFC 1300	Remembrances of Things Past
	Authors: S. Greenfield. Date: February 1992 Formats: txt pdf Status: INFORMATIONAL 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 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 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 1212, RFC 1213, RFC 1157 Status: INFORMATIONAL 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 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 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 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 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 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: April 1 1992 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 1347	TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing
	Authors: R. Callon. Date: June 1992 Formats: txt pdf ps Status: INFORMATIONAL This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 pdf ps Obsoleted by: RFC 1617, RTR_0011 Status: INFORMATIONAL 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 1385	EIP: The Extended Internet Protocol
	Authors: Z. Wang. Date: November 1992 Formats: txt pdf Status: INFORMATIONAL EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.
RFC 1386	The US Domain
	Authors: A. Cooper, J. Postel. Date: December 1992 Formats: txt pdf Obsoleted by: RFC 1480 Status: INFORMATIONAL 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 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 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 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 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 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
RFC 1400	Transition and Modernization of the Internet Registration Service
	Authors: S. Williamson. Date: March 1993 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 pdf ps Obsoleted by: RFC 1795 Status: INFORMATIONAL 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 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 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: April 1 1993 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1993 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
RFC 1501	OS/2 User Group
	Authors: E. Brunsen. Date: August 1993 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 pdf ps Obsoletes: RFC 1523 Obsoleted by: RFC 1896 Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 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 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: April 1 1994 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1994 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1994 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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, J. Romaguera, Eds.. Date: May 1994 Formats: txt pdf Status: INFORMATIONAL 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 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 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 1621	Pip Near-term Architecture
	Authors: P. Francis. Date: May 1994 Formats: txt pdf Status: INFORMATIONAL Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures.
RFC 1622	Pip Header Processing
	Authors: P. Francis. Date: May 1994 Formats: txt pdf Status: INFORMATIONAL Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers andHosts.
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 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 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 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 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 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 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, S. Sataluri, Eds.. Date: May 1994 Formats: txt pdf Obsoletes: RFC 1292 Obsoleted by: RFC 2116 Status: INFORMATIONAL 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 pdf ps Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
RFC 1701	Generic Routing Encapsulation (GRE)
	Authors: S. Hanks, T. Li, D. Farinacci, P. Traina. Date: October 1994 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 1707	CATNIP: Common Architecture for the Internet
	Authors: M. McGovern, R. Ullmann. Date: October 1994 Formats: txt pdf Status: INFORMATIONAL 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 1708	NTP PICS PROFORMA - For the Network Time Protocol Version 3
	Authors: D. Gowin. Date: October 1994 Formats: txt pdf Status: INFORMATIONAL 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 pdf ps Also: FYI 0026 Status: INFORMATIONAL 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 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 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 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 pdf ps Obsoleted by: RFC 2167 Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 1770	IPv4 Option for Sender Directed Multi-Destination Delivery
	Authors: C. Graff. Date: March 1995 Formats: txt pdf Status: INFORMATIONAL This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed BroadcastMode (SDBM). The SDBM provides unreliable UDP delivery to a set ofIP addresses included in the option field of an IPv4 datagram. Data reliability if required will be provided by the application layer.This approach was developed to support sender directed multi- destination delivery to sparsely populated groups with no additional control traffic. This approach will find application in the extremely bandwidth constrained tactical military environment, as well as in some commercial applications requiring sender control of data delivery.
RFC 1773	Experience with the BGP-4 protocol
	Authors: P. Traina. Date: March 1995 Formats: txt pdf Obsoletes: RFC 1656 Status: INFORMATIONAL 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 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 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: April 1 1995 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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, Chair, A. Bartky, Ed.. Date: April 1995 Formats: txt pdf Obsoletes: RFC 1434 Status: INFORMATIONAL 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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, T. Li, Eds.. Date: December 1995 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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
RFC 1900	Renumbering Needs Work
	Authors: B. Carpenter, Y. Rekhter. Date: February 1996 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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: April 1 1996 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1996 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1996 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1996 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 pdf ps Status: INFORMATIONAL 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 pdf ps Status: INFORMATIONAL 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 pdf ps Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them.
RFC 1984	IAB and IESG Statement on Cryptographic Technology and the Internet
	Authors: IAB, IESG. Date: August 1996 Formats: txt pdf Status: INFORMATIONAL The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 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 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 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 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 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 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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
RFC 2100	The Naming of Hosts
	Authors: J. Ashworth. Date: April 1 1997 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Status: INFORMATIONAL 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 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 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 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 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 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 Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
RFC 2202	Test Cases for HMAC-MD5 and HMAC-SHA-1
	Authors: P. Cheng, R. Glenn. Date: September 1997 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 Updated by: RFC 5741 Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
RFC 2306	Tag Image File Format (TIFF) - F Profile for Facsimile
	Authors: G. Parsons, J. Rafferty. Date: March 1998 Formats: txt pdf Status: INFORMATIONAL 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 Status: INFORMATIONAL 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 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 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 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 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 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 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: April 1 1998 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1998 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1998 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1998 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1998 Formats: txt pdf Status: INFORMATIONAL 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 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 Status: INFORMATIONAL 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 to NHRP Transition
	Authors: J. Luciani. Date: July 1998 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Service
	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 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 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 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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 Status: INFORMATIONAL 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 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 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 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: April 1 1999 Formats: txt pdf Updates: RFC 1149 Status: INFORMATIONAL 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: April 1 1999 Formats: txt pdf Status: INFORMATIONAL 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: April 1 1999 Formats: txt pdf Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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
RFC 2604	Wireless Device Configuration (OTASP/OTAPA) via ACAP
	Authors: R. Gellens. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 2636 Status: INFORMATIONAL 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 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 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 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 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 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 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 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 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 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 Status: INFORMATIONAL 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 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 pdf ps Obsoletes: RFC 2604 Status: INFORMATIONAL 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 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 pdf ps Status: INFORMATIONAL 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.
RFC 2639	Internet Printing Protocol/1.0: Implementer's Guide
	Authors: T. Hastings, C. Manros. Date: July 1999 Formats: txt pdf Obsoleted by: RFC 3196 Status: INFORMATIONAL This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. The full set of IPP documents includes: Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Mapping between LPD and IPP Protocols [RFC2569] The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions. The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed. The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp". The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.
RFC 2641	Cabletron's VlanHello Protocol Specification Version 4
	Authors: D. Hamilton, D. Ruffen. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL The VlanHello protocol is part of the InterSwitch Message Protocol(ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric.
RFC 2642	Cabletron's VLS Protocol Specification
	Authors: L. Kane. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitchMessage Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to determine the path over which to route a call connection. VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.
RFC 2643	Cabletron's SecureFast VLAN Operational Model
	Authors: D. Ruffen, T. Len, J. Yanacek. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages.
RFC 2647	Benchmarking Terminology for Firewall Performance
	Authors: D. Newman. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]
RFC 2648	A URN Namespace for IETF Documents
	Authors: R. Moats. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework andURN syntax support this namespace.
RFC 2650	Using RPSL in Practice
	Authors: D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL This document is a tutorial on using the Routing Policy SpecificationLanguage (RPSL) to describe routing policies in the Internet RoutingRegistry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in theIRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations.
RFC 2663	IP Network Address Translator (NAT) Terminology and Considerations
	Authors: P. Srisuresh, M. Holdrege. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.
RFC 2664	FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions
	Authors: R. Plzak, A. Wells, E. Krol. Date: August 1999 Formats: txt pdf Obsoletes: RFC 1594 Also: FYI 0004 Status: INFORMATIONAL This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand theInternet.
RFC 2666	Definitions of Object Identifiers for Identifying Ethernet Chip Sets
	Authors: J. Flick. Date: August 1999 Formats: txt pdf Status: INFORMATIONAL This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes.
RFC 2682	Performance Issues in VC-Merge Capable ATM LSRs
	Authors: I. Widjaja, A. Elwalid. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL VC merging allows many routes to be mapped to the same VC label, thereby providing a scalable mapping method that can support thousands of edge routers. VC merging requires reassembly buffers so that cells belonging to different packets intended for the same destination do not interleave with each other. This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. The main result indicates that VC merging incurs a minimal overhead compared to non-VC merging in terms of additional buffering. Moreover, the overhead decreases as utilization increases, or as the traffic becomes more bursty.
RFC 2683	IMAP4 Implementation Recommendations
	Authors: B. Leiba. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.
RFC 2689	Providing Integrated Services over Low-bitrate Links
	Authors: C. Bormann. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B- channels, and sub-T1 links. It covers only the lower parts of theInternet Multimedia Conferencing Architecture [1]; additional components required for application services such as InternetTelephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real- time flows, elements of negotiation protocols used between routers(or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
RFC 2690	A Proposal for an MOU-Based ICANN Protocol Support Organization
	Authors: S. Bradner. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.
RFC 2691	A Memorandum of Understanding for an ICANN Protocol Support Organization
	Authors: S. Bradner. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers(ICANN). This MoU was developed by representatives of the IETF, ITU,W3C, ETSI, and ICANN with the help of Jorge Contreras of Hale andDorr. MEMORANDUM OF UNDERSTANDING July 14, 1999 ICANN Protocol Supporting Organization (1) Purpose and Scope (a) The Protocol Support Organization (PSO) will be a consensus- based advisory body within the ICANN framework. (b) The PSO will establish a "Protocol Council" and host an annual open meeting (the "General Assembly"). (c) The purpose of this Memorandum of Understanding (MOU) is to establish a set of principles that ICANN and the StandardsDevelopment Organizations who have signed below (the SigningSDOs) will use in forming and operating the PSO (2) Composition and Action of Protocol Council (a) Size. Each Signing SDO will appoint two (2) members to theProtocol Council, each such member to serve for a time period determined by such Signing SDO. (b) Each Signing SDO shall be responsible for choosing its members of the Protocol Council in a manner of its own choosing, and in accordance with its own open procedures.Each Signing SDO may remove or replace one or both of its members on the Protocol Council in its discretion. EachSigning SDO must notify the Protocol Council Secretary andICANN when it changes its members and, in addition, must ratify its choices at least annually. (c) Selection and Appointment. Concurrently with the posting of notice of the date of the annual meeting of the PSO GeneralAssembly on the PSO Web Site, ICANN and the Protocol Council shall make an open call for nominations to any potential vacancies on the Protocol Council. Any nominations received will be forwarded to the Signing SDOs eligible to appoint members (i.e., they do not already have two members on theProtocol Council) for their consideration. (d) Action by Protocol Council. Unless otherwise specified in this MOU, all actions of the Protocol Council shall be taken by majority vote of the total number of members. Action may be taken at any meeting of the Protocol Council, which may be by telephone conference in which all participants can hear the others. Meetings of the Protocol Council may be called by request of any three members of the Protocol Council, with at least 45 days for physical meetings or fifteen (15) days for telephonic or other electronic meetings prior written notice to each of the other members. In order to conduct business at any meeting of the Protocol Council, at least a quorum of members must be present; a quorum shall be present when at least majority of the members of the Protocol Council are present, and when such members represent at least 3/4ths of the Signing SDOs. (e) Web Site. The Protocol Council will arrange for the establishment and maintenance of a Web site devoted to PSO activities and news. (f) Secretary. The Protocol Council will have a Secretary to coordinate administrative matters relating to the PSO andProtocol Council. The Secretary's term of office shall be one year. The position of Secretary will rotate among the Signing SDOs, with the initial Secretary to be selected by the IETF, and subsequent Secretaries to be appointed by a randomly selected Signing SDO that has not appointed theSecretary in the current rotation. (g) No Compensation. Neither the Secretary, nor any ProtocolCouncil member or designated ICANN Board member shall be entitled to any compensation or reimbursement of expenses from the PSO. The PSO shall not be required to obtain insurance coverage for, or to indemnify, the members of theProtocol Council or persons acting in any other capacity by or for the PSO. (3) ICANN Directors (a) The Protocol Council will appoint Directors to the ICANNBoard of Directors in accordance with the By-laws of ICANN, for such terms as are specified by such By-laws. ICANN will notify the Protocol Council of any vacancies on the ICANNBoard which may be filled by the Protocol Council. (b) The Protocol Council will conduct an open call for nominations for any open PSO seats on the ICANN Board. EachSigning SDO is entitled to nominate candidates by procedures of its own choosing. Additionally, nominations from the public at large will be allowed under conditions to be defined by the Protocol Council. The Protocol Council will select the PSO nominees to the ICANN Board from among these nominees. ICANN Directors selected by the Protocol Council may, but need not, be members of the Protocol Council or anySDO. (c) No more than 2 PSO-nominated Directors may be residents of the same Geographic Region (as defined in the ICANN By-laws). (d) The ICANN Directors appointed by the Protocol Council will not represent the PSO on the ICANN Board, but will function as full Directors of ICANN. (4) Duties of Protocol Council (a) Advisory Role. The Protocol Council will advise the ICANNBoard on matters referred to the Protocol Council by theICANN Board relating to the assignment of parameters forInternet protocols. (b) Policy Development (i) In the tradition of the Internet, standards development policies and conflict resolution mechanisms should be created and utilized by those institutions most directly involved, without undue interference from centralized bodies. (ii) The ICANN By-laws vest in the PSO the primary responsibility for developing and recommending substantive policies in the area of protocol parameter assignment. (iii) The PSO is committed to the proposition that policies for parameter assignments for particular protocols are the responsibility of the individual Signing SDO that developed the protocol. (iv) The Protocol Council, and, when requested, ICANN, will be available as needed by the Signing SDOs to develop policies and procedures for conflict resolution betweenSigning SDOs. (v) Any such policies and procedures will be adopted only with the agreement of all SDOs. (5) Annual Open Meeting (a) The Protocol Council will periodically convene an open meeting ("General Assembly") for promoting discussion and receiving input regarding the work of the PSO.(b) A General Assembly will be held at least once per year, and will permit open participation by all interested individuals.(c) Each annual General Assembly will be hosted by a Signing SDO in conjunction with one of its major meetings, as determined by the Protocol Council (with an effort to hold no 2 consecutive General Assemblies in the same GeographicRegion.)(d) It is expected that the major organizations within theInternet protocol standards development community will provide the constituency of the General Assembly. (6) Open Proceedings and Documents (a) Communications between ICANN and the Protocol Council. All official communications between ICANN and the ProtocolCouncil will be made public on the PSO web site. In the event that ICANN requests that a communication be kept confidential, the Protocol Council will honor this request for a fixed period of time not to exceed one year, and then make the communication public. (b) Protocol Council Proceedings. All meetings of the ProtocolCouncil and official discussions of Protocol Council business will be conducted or reported on a publicly-archived mailing list accessible through the PSO web site. (c) Meeting Announcements. The schedule and agenda for the PSOGeneral Assembly will be posted on the PSO Web Site at least90 days in advance of the meeting date. Notice of ProtocolCouncil meetings will be posted on the PSO Web at least 45 days before each physical meeting or fifteen (15) days before any telephonic or other electronic meeting, or such shorter time period agreed upon by each of the Signing SDOs. The minutes from all PSO meetings will be publicly posted on thePSO web site within 30 days of the meeting. (7) Review and Modification of MOU. ICANN and the Signing SDOs will periodically review the results and consequences of their cooperation under this MOU. When appropriate, the signatories will consider the need for improvements in the MOU and make suitable proposals for modifying and updating the arrangements and scope of the MOU. Any modification to the MOU must be approved by all signatories. (8) Standards Development Organizations (a) The initial signatories to this MOU shall include ICANN and the Signing SDOs who have signed below. Each Signing SDO must be an international, Internet-related standards development organization that establishes that it meets the criteria for SDOs set forth below. (i) SDOs must be open, international, voluntary technical standard and technical specification development organizations which: (A) Develop standards and/or specifications for use over the public Internet. (B) Can demonstrate active membership in the IP-related standards and/or specification development process of more than 800 individuals, if individual memberships are used by the organization, or 80 companies, if corporate memberships are used by the organization. (C) Has been in operation for 3 or more years at the time of their application. (D) Can demonstrate that there is significant deployment of its standards on the Internet. (E) The significant protocols controlled by the organization can be implemented without paying a licensing fee to the organization. (ii) Open, international, voluntary standards organizations are defined as international organizations that plan, develop or establish voluntary standards. An organization shall be considered open and international if its standards and/or specifications development process is open to any person or organization of any nationality on equitable terms. An organization shall be considered voluntary if it makes no claim to compel use of its standards and specifications. Additionally, to be considered 'international', an organization's voting (or other "full") membership must include individuals or companies primarily located in at least three different Geographic Regions and at least two different countries within each of those GeographicRegions. (b) New Signatories (i) Any organization that believes it satisfies the SDO qualifications set forth above may apply in writing to the Protocol Council to become a party to this MOU.In order for an organization to become a party to thisMOU, all then-existing MOU signatories must agree that such organization qualifies as an SDO. (ii) Rejected applicants can appeal to the ICANN Board, which may override such a rejection if the ICANN Board finds, by at least a two-thirds vote, that the organization meets the SDO criteria set forth above. (iii) Any organization that is accepted as an SDO under thisMOU must execute a copy of this MOU, and agree to be bound by all of its terms and conditions, upon which it shall be considered a Signing SDO for all purposes under this MOU. (9) General. This MOU does not constitute any of the parties as a partner, joint venture, agent, principal or franchisee of any other party. The waiver of any provision of this MOU on any occasion shall not constitute a waiver for purposes of any other occasion. No party may transfer or assign any interest, right or obligation arising under this MOU without the prior written consent of each other party to this MOU. IN WITNESS WHEREOF, this Memorandum of Understanding is executed this 14 day of July 1999 by the undersigned, acting through their duly authorized representatives: INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERSBy: (signature)Name: Michael W. RobertsTitle: Interim President / CEO INTERNET ENGINEERING TASK FORCEBy: (signature)Name: Fredrick J. BakerTitle: Chair, IETF INTERNATIONAL TELECOMMUNATIONS UNIONBy: (signature)Name: Houlin Zhao, on behalf of Secretary-General of ITUTitle: Director, TSB WORLD WIDE WEB CONSORTIUMBy: (signature)Name: Henrik Frystyk NielsenTitle: HTTP Activity Lead EUROPEAN TELECOMMUNICATIONS STANDARDS INSITITUTEBy: (signature)Name: Bridget CosgraveTitle: Deputy Director General
RFC 2694	DNS extensions to Network Address Translators (DNS_ALG)
	Authors: P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL Domain Name Service (DNS) provides name to address mapping within a routing class (ex: IP). Network Address Translators (NATs) attempt to provide transparent routing between hosts in disparate address realms of the same routing class. Typically, NATs exist at the border of a stub domain, hiding private addresses from external addresses. This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need.DNS_ALG modifies payload transparently to alter address mapping of hosts as DNS packets cross one address realm into another. The document also illustrates the operation of DNS_ALG with specific examples.
RFC 2695	Authentication Mechanisms for ONC RPC
	Authors: A. Chiu. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.
RFC 2696	LDAP Control Extension for Simple Paged Results Manipulation
	Authors: C. Weider, A. Herron, A. Anantha, T. Howes. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.
RFC 2697	A Single Rate Three Color Marker
	Authors: J. Heinanen, R. Guerin. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner [RFC2475,RFC2474]. The srTCM meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate(CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise.
RFC 2698	A Two Rate Three Color Marker
	Authors: J. Heinanen, R. Guerin. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner[RFC2475, RFC2474]. The trTCM meters an IP packet stream and marks its packets based on two rates, Peak Information Rate (PIR) andCommitted Information Rate (CIR), and their associated burst sizes to be either green, yellow, or red. A packet is marked red if it exceeds the PIR. Otherwise it is marked either yellow or green depending on whether it exceeds or doesn't exceed the CIR.
RFC 2699	Request for Comments Summary RFC Numbers 2600-2699
	Authors: S. Ginoza. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL
RFC 2701	Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol
	Authors: G. Malkin. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified.
RFC 2702	Requirements for Traffic Engineering Over MPLS
	Authors: D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics.
RFC 2703	Protocol-independent Content Negotiation Framework
	Authors: G. Klyne. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism.
RFC 2704	The KeyNote Trust-Management System Version 2
	Authors: M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. Date: September 1999 Formats: txt pdf Status: INFORMATIONAL This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. TheKeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services.
RFC 2705	Media Gateway Control Protocol (MGCP) Version 1.0
	Authors: M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. Date: October 1999 Formats: txt pdf Obsoleted by: RFC 3435 Updated by: RFC 3660 Status: INFORMATIONAL This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. The document is structured in 6 main sections: * The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP. * The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress. * The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP. * The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC). * The event packages section provides an initial definition of packages and event names. * The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0.
RFC 2706	ECML v1: Field Names for E-Commerce
	Authors: D. Eastlake 3rd, T. Goldstein. Date: October 1999 Formats: txt pdf Obsoleted by: RFC 3106 Status: INFORMATIONAL Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields.
RFC 2707	Job Monitoring MIB - V1.0
	Authors: R. Bergman, T. Hastings, S. Isaacson, H. Lewis. Date: November 1999 Formats: txt pdf Status: INFORMATIONAL This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job.This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners.
RFC 2708	Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB
	Authors: R. Bergman. Date: November 1999 Formats: txt pdf Status: INFORMATIONAL This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the JobMonitoring MIB.
RFC 2709	Security Model with Tunnel-mode IPsec for NAT Domains
	Authors: P. Srisuresh. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described.
RFC 2713	Schema for Representing Java(tm) Objects in an LDAP Directory
	Authors: V. Ryan, S. Seligman, R. Lee. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL This document defines the schema for representing Java(tm) objects in an LDAP directory [LDAPv3]. It defines schema elements to represent a Java serialized object [Serial], a Java marshalled object [RMI], aJava remote object [RMI], and a JNDI reference [JNDI].
RFC 2714	Schema for Representing CORBA Object References in an LDAP Directory
	Authors: V. Ryan, R. Lee, S. Seligman. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL CORBA [CORBA] is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory[LDAPv3].
RFC 2715	Interoperability Rules for Multicast Routing Protocols
	Authors: D. Thaler. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains.Specific instantiations of these rules are given for the DVMRP,MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them.
RFC 2718	Guidelines for new URL Schemes
	Authors: L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. Date: November 1999 Formats: txt pdf Obsoleted by: RFC 4395 Status: INFORMATIONAL A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet.This document provides guidelines for the definition of new URL schemes.
RFC 2719	Framework Architecture for Signaling Transport
	Authors: L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols.
RFC 2721	RTFM: Applicability Statement
	Authors: N. Brownlee. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL This document provides an overview covering all aspects of RealtimeTraffic Flow Measurement, including its area of applicability and its limitations.
RFC 2722	Traffic Flow Measurement: Architecture
	Authors: N. Brownlee, C. Mills, G. Ruth. Date: October 1999 Formats: txt pdf Obsoletes: RFC 2063 Status: INFORMATIONAL This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within theInternet.
RFC 2723	SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups
	Authors: N. Brownlee. Date: October 1999 Formats: txt pdf Status: INFORMATIONAL This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow.
RFC 2729	Taxonomy of Communication Requirements for Large-scale Multicast Applications
	Authors: P. Bagnall, R. Briscoe, A. Poppitt. Date: December 1999 Formats: txt pdf Status: INFORMATIONAL The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this.Classification is a first step towards standardization.
RFC 2731	Encoding Dublin Core Metadata in HTML
	Authors: J. Kunze. Date: December 1999 Formats: txt pdf Obsoleted by: RFC 5791 Status: INFORMATIONAL The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.
RFC 2753	A Framework for Policy-based Admission Control
	Authors: R. Yavatkar, D. Pendarakis, R. Guerin. Date: January 2000 Formats: txt pdf Status: INFORMATIONAL This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.
RFC 2755	Security Negotiation for WebNFS
	Authors: A. Chiu, M. Eisler, B. Callaghan. Date: January 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a protocol for a WebNFS client [RFC2054] to negotiate the desired security mechanism with a WebNFS server[RFC2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. This document is provided so that people can write compatible implementations.
RFC 2757	Long Thin Networks
	Authors: G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. Date: January 2000 Formats: txt pdf Status: INFORMATIONAL In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind. We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.
RFC 2759	Microsoft PPP CHAP Extensions, Version 2
	Authors: G. Zorn. Date: January 2000 Formats: txt pdf Status: INFORMATIONAL 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 describes version two of Microsoft's PPP CHAP dialect(MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication. The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9.
RFC 2760	Ongoing TCP Research Related to Satellites
	Authors: M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by theIETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks.
RFC 2761	Terminology for ATM Benchmarking
	Authors: J. Dunn, C. Martin. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined inRFCs 1242, 2285, and 2544. This memo is a product of the BenchmarkingMethodology Working Group (BMWG) of the Internet Engineering TaskForce (IETF).
RFC 2763	Dynamic Hostname Exchange Mechanism for IS-IS
	Authors: N. Shen, H. Smit. Date: February 2000 Formats: txt pdf Obsoleted by: RFC 5301 Status: INFORMATIONAL Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network.
RFC 2764	A Framework for IP Based Virtual Private Networks
	Authors: B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a framework for Virtual Private Networks(VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.
RFC 2767	Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
	Authors: K. Tsuchiya, H. Higuchi, Y. Atarashi. Date: February 2000 Formats: txt pdf Obsoleted by: RFC 6535 Status: INFORMATIONAL In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called"Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications.
RFC 2768	Network Policy and Services: A Report of a Workshop on Middleware
	Authors: B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University'sInternational Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified.
RFC 2771	An Abstract API for Multicast Address Allocation
	Authors: R. Finlayson. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications. Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.
RFC 2772	6Bone Backbone Routing Guidelines
	Authors: R. Rockell, R. Fink. Date: February 2000 Formats: txt pdf Obsoletes: RFC 2546 Updated by: RFC 3152 Status: INFORMATIONAL The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment. This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist.
RFC 2775	Internet Transparency
	Authors: B. Carpenter. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer. This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.
RFC 2777	Publicly Verifiable Nomcom Random Selection
	Authors: D. Eastlake 3rd. Date: February 2000 Formats: txt pdf Obsoleted by: RFC 3797 Status: INFORMATIONAL This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases.
RFC 2778	A Model for Presence and Instant Messaging
	Authors: M. Day, J. Rosenberg, H. Sugano. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.
RFC 2779	Instant Messaging / Presence Protocol Requirements
	Authors: M. Day, S. Aggarwal, G. Mohr, J. Vincent. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and PresenceProtocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.
RFC 2781	UTF-16, an encoding of ISO 10646
	Authors: P. Hoffman, F. Yergeau. Date: February 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.
RFC 2783	Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0
	Authors: J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. Date: March 2000 Formats: txt pdf Status: INFORMATIONAL RFC 1589 describes a UNIX kernel implementation model for high- precision time-keeping. This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API.
RFC 2785	Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
	Authors: R. Zuccherato. Date: March 2000 Formats: txt pdf Status: INFORMATIONAL In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks.
RFC 2791	Scalable Routing Design Principles
	Authors: J. Yu. Date: July 2000 Formats: txt pdf Status: INFORMATIONAL Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks.
RFC 2792	DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System
	Authors: M. Blaze, J. Ioannidis, A. Keromytis. Date: March 2000 Formats: txt pdf Status: INFORMATIONAL This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system.
RFC 2795	The Infinite Monkey Protocol Suite (IMPS)
	Authors: S. Christey. Date: April 1 2000 Formats: txt pdf Status: INFORMATIONAL This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works ofWilliam Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.
RFC 2798	Definition of the inetOrgPerson LDAP Object Class
	Authors: M. Smith. Date: April 2000 Formats: txt pdf Updated by: RFC 3698, RFC 4519, RFC 4524 Status: INFORMATIONAL While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs.
RFC 2799	Request for Comments Summary RFC Numbers 2700-2799
	Authors: S. Ginoza. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL
RFC 2801	Internet Open Trading Protocol - IOTP Version 1.0
	Authors: D. Burdett. Date: April 2000 Formats: txt pdf Status: INFORMATIONAL The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure ChannelCredit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, thePayment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party.
RFC 2802	Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)
	Authors: K. Davidson, Y. Kawatsura. Date: April 2000 Formats: txt pdf Status: INFORMATIONAL A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of theInternet Open Trading Protocol (IOTP).
RFC 2803	Digest Values for DOM (DOMHASH)
	Authors: H. Maruyama, K. Tamura, N. Uramoto. Date: April 2000 Formats: txt pdf Status: INFORMATIONAL This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects.
RFC 2804	IETF Policy on Wiretapping
	Authors: IAB, IESG. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means.
RFC 2805	Media Gateway Control Protocol Architecture and Requirements
	Authors: N. Greene, M. Ramalho, B. Rosen. Date: April 2000 Formats: txt pdf Status: INFORMATIONAL This document describes protocol requirements for the Media GatewayControl Protocol between a Media Gateway Controller and a MediaGateway.
RFC 2807	XML Signature Requirements
	Authors: J. Reagle. Date: July 2000 Formats: txt pdf Status: INFORMATIONAL This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.
RFC 2808	The SecurID(r) SASL Mechanism
	Authors: M. Nystrom. Date: April 2000 Formats: txt pdf Status: INFORMATIONAL SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL.
RFC 2809	Implementation of L2TP Compulsory Tunneling via RADIUS
	Authors: B. Aboba, G. Zorn. Date: April 2000 Formats: txt pdf Status: INFORMATIONAL This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using theL2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents.
RFC 2810	Internet Relay Chat: Architecture
	Authors: C. Kalt. Date: April 2000 Formats: txt pdf Updates: RFC 1459 Status: INFORMATIONAL The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves. First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here.
RFC 2811	Internet Relay Chat: Channel Management
	Authors: C. Kalt. Date: April 2000 Formats: txt pdf Updates: RFC 1459 Status: INFORMATIONAL One of the most notable characteristics of the IRC (Internet RelayChat) protocol is to allow for users to be grouped in forums, called channels, providing a mean for multiple users to communicate together. There was originally a unique type of channels, but with the years, new types appeared either as a response to a need, or for experimental purposes. This document specifies how channels, their characteristics and properties are managed by IRC servers.
RFC 2812	Internet Relay Chat: Client Protocol
	Authors: C. Kalt. Date: April 2000 Formats: txt pdf Updates: RFC 1459 Status: INFORMATIONAL The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server. This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH].
RFC 2813	Internet Relay Chat: Server Protocol
	Authors: C. Kalt. Date: April 2000 Formats: txt pdf Updates: RFC 1459 Status: INFORMATIONAL While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network. This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently. First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification.
RFC 2816	A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies
	Authors: A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL This memo describes a framework for supporting IETF IntegratedServices on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches.It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol(RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13].
RFC 2818	HTTP Over TLS
	Authors: E. Rescorla. Date: May 2000 Formats: txt pdf Updated by: RFC 5785 Status: INFORMATIONAL This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP[RFC2817].
RFC 2820	Access Control Requirements for LDAP
	Authors: E. Stokes, D. Byrne, B. Blakley, P. Behera. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory ApplicationProtocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].
RFC 2824	Call Processing Language Framework and Requirements
	Authors: J. Lennox, H. Schulzrinne. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language.
RFC 2825	A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols
	Authors: IAB, L. Daigle, Ed.. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today'sURLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development. There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users. This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces.
RFC 2826	IAB Technical Comment on the Unique DNS Root
	Authors: Internet Architecture Board. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.
RFC 2828	Internet Security Glossary
	Authors: R. Shirey. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 4949 Status: INFORMATIONAL This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion,ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future.
RFC 2832	NSI Registry Registrar Protocol (RRP) Version 1.1.0
	Authors: S. Hollenbeck, M. Srivastava. Date: May 2000 Formats: txt pdf Updated by: RFC 3632 Status: INFORMATIONAL This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top LevelDomains (ccTLDs). This protocol was developed by the NetworkSolutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry. Internet domain name registration typically involves three entities: a registrant who wishes to register a domain name, a registrar who provides services to the registrant, and a registry that provides services to the registrar while serving as the authoritative repository of all functional information required to resolve names registered in the registry's TLDs. This document describes a protocol for registry-registrar communication only. The protocol does not provide any registrant services. This document is being discussed on the "rrp" mailing list. To join the list, send a message to <majordomo@NSIRegistry.com&rt; with the words "subscribe rrp" in the body of the message. There is also a web site for the mailing list archives at<http://www.NSIRegistry.net/maillist/rrp&rt;.
RFC 2838	Uniform Resource Identifiers for Television Broadcasts
	Authors: D. Zigmond, M. Vickers. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.
RFC 2839	Internet Kermit Service
	Authors: F. da Cruz, J. Altman. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.
RFC 2840	TELNET KERMIT OPTION
	Authors: J. Altman, F. da Cruz. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.
RFC 2843	Proxy-PAR
	Authors: P. Droz, T. Przygienda. Date: May 2000 Formats: txt pdf Status: INFORMATIONAL Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment. The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR primarily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI.In addition, Proxy-PAR-capable servers provide filtering based on VPNIDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients.
RFC 2854	The 'text/html' Media Type
	Authors: D. Connolly, L. Masinter. Date: June 2000 Formats: txt pdf Obsoletes: RFC 2070, RFC 1980, RFC 1942, RFC 1867, RFC 1866 Status: INFORMATIONAL This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations; it is intended to obsolete the previous IETF documents defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC1942 and RFC 2070, and to remove HTML from IETF Standards Track. This document was prepared at the request of the W3C HTML working group. Please send comments to www-html@w3.org, a public mailing list with archive at <http://lists.w3.org/Archives/Public/www-html/&rt;.
RFC 2860	Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
	Authors: B. Carpenter, F. Baker, M. Roberts. Date: June 2000 Formats: txt pdf Status: INFORMATIONAL This document places on record the text of the Memorandum ofUnderstanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000.
RFC 2866	RADIUS Accounting
	Authors: C. Rigney. Date: June 2000 Formats: txt pdf Obsoletes: RFC 2139 Updated by: RFC 2867, RFC 5080, RFC 5997 Status: INFORMATIONAL This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer.
RFC 2867	RADIUS Accounting Modifications for Tunnel Protocol Support
	Authors: G. Zorn, B. Aboba, D. Mitton. Date: June 2000 Formats: txt pdf Updates: RFC 2866 Status: INFORMATIONAL This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks.
RFC 2868	RADIUS Attributes for Tunnel Protocol Support
	Authors: G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. Date: June 2000 Formats: txt pdf Updates: RFC 2865 Status: INFORMATIONAL This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.
RFC 2869	RADIUS Extensions
	Authors: C. Rigney, W. Willats, P. Calhoun. Date: June 2000 Formats: txt pdf Updated by: RFC 3579, RFC 5080 Status: INFORMATIONAL This document describes additional attributes for carrying authentication, authorization and accounting information between aNetwork Access Server (NAS) and a shared Accounting Server using theRemote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2].
RFC 2871	A Framework for Telephony Routing over IP
	Authors: J. Rosenberg, H. Schulzrinne. Date: June 2000 Formats: txt pdf Status: INFORMATIONAL This document serves as a framework for Telephony Routing over IP(TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony.
RFC 2876	Use of the KEA and SKIPJACK Algorithms in CMS
	Authors: J. Pawling. Date: July 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the conventions for using the Key ExchangeAlgorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types.
RFC 2877	5250 Telnet Enhancements
	Authors: T. Murphy Jr., P. Rieth, J. Stevens. Date: July 2000 Formats: txt pdf Obsoleted by: RFC 4777 Updates: RFC 1205 Status: INFORMATIONAL This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described. By allowing a Telnet client to select the device name, the 5250Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing,2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange. Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description.Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates. This memo describes how the IBM 5250 Telnet server supports WorkStation Function (WSF) printers using 5250 Display Station Pass-Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session.
RFC 2880	Internet Fax T.30 Feature Mapping
	Authors: L. McIntyre, G. Klyne. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This document describes how to map Group 3 fax capability identification bits, described in ITU T.30 [6], into the Internet fax feature schema described in "Content feature schema for Internet fax"[4]. This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms[1,2,3], for use in performing capability identification between extended Internet fax systems [5].
RFC 2881	Network Access Server Requirements Next Generation (NASREQNG) NAS Model
	Authors: D. Mitton, M. Beadles. Date: July 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the terminology and gives a model of typicalNetwork Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFCs 2865, 2866) [1], [2] and follow-on efforts like AAA Working Group, and the Diameter protocol [3]. These are protocols for carrying user service information for authentication, authorization, accounting, and auditing, between aNetwork Access Server which desires to authenticate its incoming calls and a shared authentication server.
RFC 2882	Network Access Servers Requirements: Extended RADIUS Practices
	Authors: D. Mitton. Date: July 2000 Formats: txt pdf Status: INFORMATIONAL This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment.
RFC 2884	Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks
	Authors: J. Hadi Salim, U. Ahmed. Date: July 2000 Formats: txt pdf Status: INFORMATIONAL This memo presents a performance study of the Explicit CongestionNotification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated intoRFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno,SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers. A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf This memo in its current revision is missing a lot of the visual representations and experimental results found in the pdf version.
RFC 2887	The Reliable Multicast Design Space for Bulk Data Transfer
	Authors: M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions.
RFC 2888	Secure Remote Access with L2TP
	Authors: P. Srisuresh. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server(LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to controlAuthentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access andIPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote AccessServer (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach.
RFC 2889	Benchmarking Methodology for LAN Switching Devices
	Authors: R. Mandeville, J. Perser. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.
RFC 2892	The Cisco SRP MAC Layer Protocol
	Authors: D. Tsiang, G. Suwala. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This document specifies the MAC layer protocol, "Spatial ReuseProtocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). The primary requirements for SRP are as follows: - Efficient use of bandwidth using: spatial reuse of bandwidth local reuse of bandwidth minimal protocol overhead- Support for priority traffic- Scalability across a large number of nodes or stations attached to a ring- "Plug and play" design without a software based station management transfer (SMT) protocol or ring master negotiation as seen in other ring based MAC protocols [1][2]- Fairness among nodes using the ring- Support for ring based redundancy (error detection, ring wrap, etc.) similar to that found in SONET BLSR specifications.- Independence of physical layer (layer 1) media type. This document defines the terminology used with SRP, packet formats, the protocol format, protocol operation and associated protocol finite state machines.
RFC 2896	Remote Network Monitoring MIB Protocol Identifier Macros
	Authors: A. Bierman, C. Bucci, R. Iddon. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895]. This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard.It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document. The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RFC2895], and an "RMON Protocol Identifier Macros", document (this document) which contains the non-normative portion of that specification.
RFC 2897	Proposal for an MGCP Advanced Audio Package
	Authors: D. Cromwell. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This document is a proposal to add a new event/signal package to theMGCP (Media Gateway Control Protocol) protocol to control an ARF(Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This event package provides support for the standard IVR (InteractiveVoice Response) operations of PlayAnnouncement, PlayCollect, andPlayRecord. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides audio variables, control of audio interruptibility, digit buffer control, special key sequences, and support for reprompting during data collection. It also provides an arbitrary number of user defined qualifiers to be used in resolving complex audio structures. For example, the user could define qualifiers for any or all of the following: language, accent, audio file format, gender, speaker, or customer.
RFC 2898	PKCS #5: Password-Based Cryptography Specification Version 2.0
	Authors: B. Kaliski. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This memo represents a republication of PKCS #5 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS#8 [25]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints. Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols[4][5][26] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope.
RFC 2899	Request for Comments Summary RFC Numbers 2800-2899
	Authors: S. Ginoza. Date: May 2001 Formats: txt pdf Status: INFORMATIONAL
RFC 2901	Guide to Administrative Procedures of the Internet Infrastructure
	Authors: Z. Wenzel, J. Klensin, R. Bush, S. Huter. Date: August 2000 Formats: txt pdf Also: FYI 0037 Status: INFORMATIONAL This document describes the administrative procedures for networks seeking to connect to the global Internet. This includes the steps and operations necessary for address space allocation and registration, routing database registration, and domain name registration. The document also contains information about the required forms and how to obtain them.
RFC 2902	Overview of the 1998 IAB Routing Workshop
	Authors: S. Deering, S. Hares, C. Perkins, R. Perlman. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This document is an overview of a Routing workshop held by theInternet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion.
RFC 2904	AAA Authorization Framework
	Authors: J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This memo serves as the base requirements for Authorization ofInternet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.
RFC 2905	AAA Authorization Application Examples
	Authors: J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This memo describes several examples of applications requiring authorization. Each application is described in terms of a consistent framework, and specific authorization requirements of each application are given. This material was not contributed by the working groups responsible for the applications and should not be considered prescriptive for how the applications will meet their authorization needs. Rather the intent is to explore the fundamental needs of a variety of different applications with the view of compiling a set of requirements that an authorization protocol will need to meet in order to be generally useful.
RFC 2906	AAA Authorization Requirements
	Authors: S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. Date: August 2000 Formats: txt pdf Status: INFORMATIONAL This document specifies the requirements that AuthenticationAuthorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others.
RFC 2917	A Core MPLS IP VPN Architecture
	Authors: K. Muthukrishnan, A. Malis. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This memo presents an approach for building core Virtual PrivateNetwork (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications.
RFC 2921	6BONE pTLA and pNLA Formats (pTLA)
	Authors: B. Fink. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation",[6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers(pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's).
RFC 2922	Physical Topology MIB
	Authors: A. Bierman, K. Jones. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing physical topology identification and discovery.
RFC 2923	TCP Problems with Path MTU Discovery
	Authors: K. Lahey. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission UnitDiscovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between MaximumSegment Size (MSS) and segment size, and MSS advertisement based onPMTU.
RFC 2924	Accounting Attributes and Record Formats
	Authors: N. Brownlee, A. Blount. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document summarises Internet Engineering Task Force (IETF) andInternational Telecommunication Union (ITU-T) documents related toAccounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats forAccounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This document discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described.
RFC 2926	Conversion of LDAP Schemas to and from SLP Templates
	Authors: J. Kempf, R. Moats, P. St. Pierre. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a procedure for mapping between ServiceLocation Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. The document covers two aspects of the mapping. One aspect is mapping between SLP service type templates and LDAP directory schema.Because the SLP service type template grammar is relatively simple, mapping from service type templates to LDAP types is straightforward.Mapping in the other direction is straightforward if the attributes are restricted to use just a few of the syntaxes defined in RFC 2252.If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible. The second aspect is representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers.The resulting system allows service advertisements to propagate easily between SLP and LDAP.
RFC 2927	MIME Directory Profile for LDAP Schema
	Authors: M. Wahl. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol(LDAP) schema. It is intended for communication with the Internet schema listing service.
RFC 2928	Initial IPv6 Sub-TLA ID Assignments
	Authors: R. Hinden, S. Deering, R. Fink, T. Hain. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document defines initial assignments of IPv6 Sub-Top-LevelAggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned NumbersAuthority (IANA) from the Internet Engineering Task Force (IETF)Internet Protocol Next Generation (IPNG) and Next GenerationTransition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The Internet Architecture Board (IAB) subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses.
RFC 2936	HTTP MIME Type Handler Detection
	Authors: D. Eastlake 3rd, C. Smith, D. Soroka. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL Entities composing web pages to provide services over the HypertextTransfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. For example, whether an Internet OpenTrading Protocol (IOTP) or VRML or SET or some streaming media handler is available. In some cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on theInternet as of early 2000. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed.
RFC 2951	TELNET Authentication Using KEA and SKIPJACK
	Authors: R. Housley, T. Horting, P. Yee. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document defines a method to authenticate TELNET using the KeyExchange Algorithm (KEA), and encryption of the TELNET stream usingSKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNETAuthentication Option.
RFC 2952	Telnet Encryption: DES 64 bit Cipher Feedback
	Authors: T. Ts'o. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option.
RFC 2953	Telnet Encryption: DES 64 bit Output Feedback
	Authors: T. Ts'o. Date: September 2000 Formats: txt pdf Status: INFORMATIONAL This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option.
RFC 2956	Overview of 1999 IAB Network Layer Workshop
	Authors: M. Kaat. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document is an overview of a workshop held by the InternetArchitecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet.Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering TaskForce (IETF) community.
RFC 2957	The application/whoispp-query Content-Type
	Authors: L. Daigle, P. Faltstrom. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document defines the expression of Whois++ protocol (RFC 1835) queries within MIME (Multipurpose Internet Mail Extensions) (RFC2046) media types. The intention of this document, in conjunction with RFC 2958 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.
RFC 2958	The application/whoispp-response Content-type
	Authors: L. Daigle, P. Faltstrom. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document defines the expression of Whois++ protocol (RFC1835) responses within MIME (Multipurpose Internet Mail Extensions)(RFC2046) media types. The intention of this document, in conjunction with RFC 2957 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.
RFC 2962	An SNMP Application Level Gateway for Payload Address Translation
	Authors: D. Raz, J. Schoenwaelder, B. Sugla. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document describes the ALG (Application Level Gateway) for theSNMP (Simple Network Management Protocol) by which IP (InternetProtocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15]. An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (NetworkAddress Translator) in order to manage several potentially overlapping addressing realms. This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application LevelGateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms.
RFC 2963	A Rate Adaptive Shaper for Differentiated Services
	Authors: O. Bonaventure, S. De Cnodder. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 andRFC2698, respectively. These RAS improve the performance of TCP when a TCM is used at the ingress of a diffserv network by reducing the burstiness of the traffic. With TCP traffic, this reduction of the burstiness is accompanied by a reduction of the number of marked packets and by an improved TCP goodput. The proposed RAS can be used at the ingress of Diffserv networks providing the Assured ForwardingPer Hop Behavior (AF PHB). They are especially useful when a TCM is used to mark traffic composed of a small number of TCP connections.
RFC 2966	Domain-wide Prefix Distribution with Two-Level IS-IS
	Authors: T. Li, T. Przygienda, H. Smit. Date: October 2000 Formats: txt pdf Obsoleted by: RFC 5302 Status: INFORMATIONAL This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2]. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.
RFC 2967	TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
	Authors: L. Daigle, R. Hedberg. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL The strength of the TISDAG (Technical Infrastructure for SwedishDirectory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access- point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.
RFC 2968	Mesh of Multiple DAG servers - Results from TISDAG
	Authors: L. Daigle, T. Eklof. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL The Common Indexing Protocol ([CIP1]) is designed to facilitate the creation not only of query referral indexes, but also of meshes of(loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways) project ([TISDAG], [DAGEXP]) has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services.
RFC 2969	Wide Area Directory Deployment - Experiences from TISDAG
	Authors: T. Eklof, L. Daigle. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL The TISDAG (Technical Infrastructure for Swedish Directory AccessGateway) project provided valuable insight into the current reality of deploying a wide-scale directory service. This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. A perspective on the project's relationship to other directory deployment projects is provided, along with some proposals for future extensions of the work(larger scale deployment, other application areas). These are our own observations, based on work done and general project discussions. No doubt, other project participants have their own list of project experiences; we don't claim this document is exhaustive!
RFC 2970	Architecture for Integrated Directory Services - Result from TISDAG
	Authors: L. Daigle, T. Eklof. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL A single, unified, global whitepages directory service remains elusive. Nonetheless, there is increasing call for participation of widely-dispersed directory servers (i.e., across multiple organizations) in large-scale directory services. These services range from national whitepages services, to multi-national indexes ofWWW resources, and beyond. Drawing from experiences with the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways)([TISDAG]) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use.
RFC 2972	Context and Goals for Common Name Resolution
	Authors: N. Popp, M. Mealling, L. Masinter, K. Sollins. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document establishes the context and goals for a Common NameResolution Protocol. It defines the terminology used concerning a"Common Name" and how one might be "resolved", and establishes the distinction between "resolution" and more elaborate search mechanisms. It establishes some expected contexts for use of CommonName Resolution, and the criteria for evaluating a successful protocol. It also analyzes the various motivations that would cause services to provide Common Name resolution for both public, private and commercial use. This document is intended as input to the formation of a Common NameResolution Protocol working group. Please send any comments to cnrp-ietf@lists.internic.net. To review the mail archives, see<http://lists.internic.net/archives/cnrp-ietf.html&rt;
RFC 2973	IS-IS Mesh Groups
	Authors: R. Balay, D. Katz, J. Parker. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System(IS-IS) Routing protocol, as described in ISO 10589. The described mechanism can be used to reduce the flooding of Link State PDUs(Protocol Data Units) (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This document serves to document the existing behavior in deployed implementations. The document describes behaviors that are backwards compatible with implementations that do not support this feature.
RFC 2975	Introduction to Accounting Management
	Authors: B. Aboba, J. Arkko, D. Harrington. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems. Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application.This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.
RFC 2977	Mobile IP Authentication, Authorization, and Accounting Requirements
	Authors: S. Glass, T. Hiller, S. Jacobs, C. Perkins. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements forAuthentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services.
RFC 2979	Behavior of and Requirements for Internet Firewalls
	Authors: N. Freed. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices.
RFC 2980	Common NNTP Extensions
	Authors: S. Barber. Date: October 2000 Formats: txt pdf Updated by: RFC 3977, RFC 4643, RFC 4644, RFC 6048 Status: INFORMATIONAL In this document, a number of popular extensions to the Network NewsTransfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of extensions.
RFC 2983	Differentiated Services and Tunnels
	Authors: D. Black. Date: October 2000 Formats: txt pdf Status: INFORMATIONAL This document considers the interaction of Differentiated Services(diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms.The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers.This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.
RFC 2985	PKCS #9: Selected Object Classes and Attribute Types Version 2.0
	Authors: M. Nystrom, B. Kaliski. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL This memo represents a republication of PKCS #9 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides a selection of object classes and attribute types for use in conjunction with public-key cryptography and LightweightDirectory Access Protocol (LDAP) accessible directories. It also includes ASN.1 syntax for all constructs.
RFC 2986	PKCS #10: Certification Request Syntax Specification Version 1.7
	Authors: M. Nystrom, B. Kaliski. Date: November 2000 Formats: txt pdf Obsoletes: RFC 2314 Updated by: RFC 5967 Status: INFORMATIONAL This memo represents a republication of PKCS #10 v1.7 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo describes a syntax for certification requests.
RFC 2989	Criteria for Evaluating AAA Protocols for Network Access
	Authors: B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL This document represents a summary of Authentication, Authorization,Accounting (AAA) protocol requirements for network access. In creating this document, inputs were taken from documents produced by the Network Access Server Requirements Next Generation (NASREQ),Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as from TIA 45.6. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.
RFC 2990	Next Steps for the IP QoS Architecture
	Authors: G. Huston. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL While there has been significant progress in the definition ofQuality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
RFC 2991	Multipath Issues in Unicast and Multicast Next-Hop Selection
	Authors: D. Thaler, C. Hopps. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow "Equal-Cost Multipath" (ECMP) routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next- hop should be used for a given data packet.
RFC 2992	Analysis of an Equal-Cost Multi-Path Algorithm
	Authors: C. Hopps. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops.
RFC 2993	Architectural Implications of NAT
	Authors: T. Hain. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.
RFC 2994	A Description of the MISTY1 Encryption Algorithm
	Authors: H. Ohta, M. Matsui. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part.
RFC 2995	Pre-Spirits Implementations of PSTN-initiated Services
	Authors: H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL This document contains information relevant to the work underway inThe Services in the PSTN/IN Requesting InTernet Services (SPIRITS)Working Group. It describes four existing implementations ofSPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. Surveying the implementations, we can make the following observations: o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it. o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between thePSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.) o All implementations use IN-based solutions for the PSTN part. It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS WorkingGroup to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services.
RFC 2998	A Framework for Integrated Services Operation over Diffserv Networks
	Authors: Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. Date: November 2000 Formats: txt pdf Status: INFORMATIONAL The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, theIntserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.
RFC 2999	Request for Comments Summary RFC Numbers 2900-2999
	Authors: S. Ginoza. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL
RFC 3001	A URN Namespace of Object Identifiers
	Authors: M. Mealling. Date: November 2000 Formats: txt pdf Obsoleted by: RFC 3061 Status: INFORMATIONAL This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs).
RFC 3002	Overview of 2000 IAB Wireless Internetworking Workshop
	Authors: D. Mitzel. Date: December 2000 Formats: txt pdf Status: INFORMATIONAL This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thruMarch 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community. Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list.
RFC 3022	Traditional IP Network Address Translator (Traditional NAT)
	Authors: P. Srisuresh, K. Egevang. Date: January 2001 Formats: txt pdf Obsoletes: RFC 1631 Status: INFORMATIONAL Basic Network Address Translation or Basic NAT is a method by whichIP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP (Transmission ControlProtocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses.
RFC 3026	Liaison to IETF/ISOC on ENUM
	Authors: R. Blane. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL Working Party 1/2, of the International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. The agenda of the meeting contained several contributions regarding RFC 2916:"E.164 Number and DNS" from the Internet Engineering Task Force's(IETF) ENUM Working Group - more specifically, the method for administering and maintaining the E.164-based resources in the DomainName System (DNS) as related to the ENUM protocol. Consequently, in addition to the WP1/2 collaborators, there were several members of the IETF present to assist with the discussion of issues contained in the aforementioned contributions. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions.
RFC 3027	Protocol Complications with the IP Network Address Translator
	Authors: M. Holdrege, P. Srisuresh. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IPNetwork Address Translator (NAT) enroute to bridge the realms. TheNAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of ApplicationLevel Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.
RFC 3037	LDP Applicability
	Authors: B. Thomas, E. Gray. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP(for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
RFC 3040	Internet Web Replication and Caching Taxonomy
	Authors: I. Cooper, I. Melve, G. Tomlinson. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in the document titled"Known HTTP Proxy/Caching Problems", and are not part of this document. This document presents open protocols and points to published material for each protocol.
RFC 3043	The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations
	Authors: M. Mealling. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations.
RFC 3044	Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace
	Authors: S. Rozenfeld. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This document presents how the ISSN - International Standard SerialNumber - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by theISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment. This proceeds from concepts and proposals developed in several IETFRFCs emphasising the way to implement and to use "recognised" existing numbering system within the URN framework (RFC 2248, RFC2141, RFC 2611).
RFC 3045	Storing Vendor Information in the LDAP root DSE
	Authors: M. Meredith. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This document specifies two Lightweight Directory Access Protocol(LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of RFC 2251. The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery.
RFC 3048	Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer
	Authors: B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a framework for the standardization of bulk- data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks". The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as "protocol cores".Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols.
RFC 3050	Common Gateway Interface for SIP
	Authors: J. Lennox, H. Schulzrinne, J. Rosenberg. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the CommonGateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between theSession Initiation Protocol (SIP) and the Hyper Text TransferProtocol (HTTP), CGI is a good candidate for service creation in aSIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server.
RFC 3051	IP Payload Compression Using ITU-T V.44 Packet Method
	Authors: J. Heath, J. Border. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a compression method based on the data compression algorithm described in International TelecommunicationUnion (ITU-T) Recommendation V.44. Recommendation V.44 is a modem standard but Annex B, Clause B.1, of the recommendation describes the implementation of V.44 in packet networks (e.g., V.44 Packet Method).This document defines the application of V.44 Packet Method to theInternet Protocol (IP) Payload Compression Protocol (RFC 2393). RFC2393 defines a method for applying lossless compression to the payload portion of IP datagrams. V.44 Packet Method is based upon the LZJH data compression algorithm.Throughout the remainder of this document the terms V.44 PacketMethod and LZJH are synonymous.
RFC 3052	Service Management Architectures Issues and Review
	Authors: M. Eder, S. Nag. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL Many of the support functions necessary to exploit the mechanisms by which differing levels of service can be provided are limited in scope and a complete framework is non-existent. Various efforts at such a framework have received a great deal of attention and represent a historical shift in scope for many of the organizations looking to address this problem. The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved.
RFC 3053	IPv6 Tunnel Broker
	Authors: A. Durand, P. Fasano, I. Guardini, D. Lento. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network(e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented atOrlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting inFebruary 1999.
RFC 3054	Megaco IP Phone Media Gateway Application Profile
	Authors: P. Blatherwick, R. Bell, P. Holland. Date: January 2001 Formats: txt pdf Status: INFORMATIONAL This document specifies a particular application of the Megaco/H.248Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. The telephone itself is a MediaGateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media GatewayController (MGC). To achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of Terminations andPackages, and a Protocol Profile are described. The approach makes use of existing Protocol features and user interface relatedPackages, and is thus a straight-forward application of theMegaco/H.248 Protocol.
RFC 3058	Use of the IDEA Encryption Algorithm in CMS
	Authors: S. Teiwes, P. Hartmann, D. Kuenzi. Date: February 2001 Formats: txt pdf Status: INFORMATIONAL This memo specifies how to incorporate International Data EncryptionAlgorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide theOIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption.
RFC 3061	A URN Namespace of Object Identifiers
	Authors: M. Mealling. Date: February 2001 Formats: txt pdf Obsoletes: RFC 3001 Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). It obsoletes RFC 3001.
RFC 3064	MGCP CAS Packages
	Authors: B. Foster. Date: February 2001 Formats: txt pdf Status: INFORMATIONAL This document contains a collection of media gateway ChannelAssociated Signaling (CAS) packages for R1 CAS, North American CAS,CAS PBX interconnect as well as basic FXO support. Included are six packages. The "MS" package covers MF single stage dialing trunks.This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3].The "DT "package covers immediate start and basic DTMF and dial-pulse trunks and the "BL" package covers the interface to a basic PBX(digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These includeEAIN and EANA which is covered by the enclosed "MD" package and theOperator Service Signaling protocol which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package.
RFC 3067	TERENA'S Incident Object Description and Exchange Format Requirements
	Authors: J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. Date: February 2001 Formats: txt pdf Status: INFORMATIONAL The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (ComputerSecurity Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements.Examples are used to illustrate the requirements where necessary.
RFC 3069	VLAN Aggregation for Efficient IP Address Allocation
	Authors: D. McPherson, B. Dykes. Date: February 2001 Formats: txt pdf Status: INFORMATIONAL This document introduces the concept of Virtual Local Area Network(VLAN) aggregation as it relates to IPv4 address allocation. A mechanism is described by which hosts that reside in the same physical switched infrastructure, but separate virtual broadcast domains, are addressed from the same IPv4 subnet and share a common default gateway IP address, thereby removing the requirement of a dedicated IP subnet for each virtual Local Area Network (LAN) orMetropolitan Area Network (MAN). Employing such a mechanism significantly decreases IPv4 address consumption in virtual LANs and MANs. It may also ease administration of IPv4 addresses within the network.
RFC 3071	Reflections on the DNS, RFC 1591, and Categories of Domains
	Authors: J. Klensin. Date: February 2001 Formats: txt pdf Status: INFORMATIONAL RFC 1591, "Domain Name System Structure and Delegation", laid out the basic administrative design and principles for the allocation and administration of domains, from the top level down. It was written before the introduction of the world wide web (WWW) and rapid growth of the Internet put significant market, social, and political pressure on domain name allocations. In recent years, 1591 has been cited by all sides in various debates, and attempts have been made by various bodies to update it or adjust its provisions, sometimes under pressures that have arguably produced policies that are less well thought out than the original. Some of those efforts have begun from misconceptions about the provisions of 1591 or the motivation for those provisions. The current directions of the Internet Corporation for Assigned Names and Numbers (ICANN) and other groups who now determine the Domain Name System (DNS) policy directions appear to be drifting away from the policies and philosophy of 1591. This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how1591 might have been interpreted and adjusted by the InternetAssigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. An earlier variation of this memo was submitted to ICANN as a comment on its evolving Top-level Domain (TLD) policies.
RFC 3072	Structured Data Exchange Format (SDXF)
	Authors: M. Wildgrube. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and CPU-independent.
RFC 3073	Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration
	Authors: J. Collins. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. A Portable Font Resource (PFR) contains a set of glyph shapes. Each glyph shape is associated with a character code. The PFR format is designed to be both compact and platform-independent. It is intended to facilitate accurate rendering of fonts in all environments whether or not they have the required fonts already installed.
RFC 3076	Canonical XML Version 1.0
	Authors: J. Boyer. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL Any XML (Extensible Markup Language) document is part of a set of XML documents that are logically equivalent within an application context, but which vary in physical representation based on syntactic changes permitted by XML 1.0 and Namespaces in XML. This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. Except for limitations regarding a few unusual cases, if two documents have the same canonical form, then the two documents are logically equivalent within the given application context. Note that two documents may have differing canonical forms yet still be equivalent in a given context based on application-specific equivalence rules for which no generalized XML specification could account.
RFC 3078	Microsoft Point-To-Point Encryption (MPPE) Protocol
	Authors: G. Pall, G. Zorn. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to PointEncryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets.
RFC 3079	Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
	Authors: G. Zorn. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links. Microsoft Point to Point Encryption (MPPE) is a means of representingPPP packets in an encrypted form. MPPE uses the RSA RC4 algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit, 56-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 in the Compression Control Protocol. This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. MPPE itself (including the protocol used to negotiate its use, the details of the encryption method used and the algorithm used to change session keys during a session) is described in RFC 3078.
RFC 3083	Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems
	Authors: R. Woundy. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL 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 a basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the BaselinePrivacy Interface (BPI), which provides data privacy for DOCSIS 1.0(Data-Over-Cable Service Interface Specifications) compliant CableModems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo specifies a MIB module in a manner that is compliant to theSMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards. CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification.
RFC 3085	URN Namespace for NewsML Resources
	Authors: A. Coates, D. Allen, D. Rivers-Moore. Date: March 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. A NewsItem is an information resource that is expressible as a NewsML element within a NewsML document conforming to the NewsML Document Type Declaration (DTD) as defined by the International Press Telecommunications Council (IPTC).
RFC 3086	Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification
	Authors: K. Nichols, B. Carpenter. Date: April 2001 Formats: txt pdf Status: INFORMATIONAL The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select(classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes. The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, orPDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service LevelSpecifications at the network edge. This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to theDiffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions.
RFC 3087	Control of Service Context using SIP Request-URI
	Authors: B. Campbell, R. Sparks. Date: April 2001 Formats: txt pdf Status: INFORMATIONAL This memo provides information for the Internet community. It describes a useful way to conceptualize the use of the standard SIP(Session Initiation Protocol) Request-URI (Uniform ResourceIdentifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context.In a SIP/2.0 call, much of this information may be either non- existent or unreliable. This document proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This document continues with examples of how this mechanism could be used in a voice mail application.
RFC 3089	A SOCKS-based IPv6/IPv4 Gateway Mechanism
	Authors: H. Kitamura. Date: April 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to the heterogeneous communications and relaying two"terminated" IPv4 and IPv6 connections at the "application layer"(the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished. Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by theSOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed.
RFC 3091	Pi Digit Generation Protocol
	Authors: H. Kennedy. Date: April 1 2001 Formats: txt pdf Status: INFORMATIONAL This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers.
RFC 3092	Etymology of "Foo"
	Authors: D. Eastlake 3rd, C. Manros, E. Raymond. Date: April 1 2001 Formats: txt pdf Status: INFORMATIONAL Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency.
RFC 3093	Firewall Enhancement Protocol (FEP)
	Authors: M. Gaynor, S. Bradner. Date: April 1 2001 Formats: txt pdf Status: INFORMATIONAL Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1].However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose theFirewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse aFirewall. Our methodology is to layer any application layerTransmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, sinceHTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, sinceFirewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall.
RFC 3094	Tekelec's Transport Adapter Layer Interface
	Authors: D. Sprague, R. Benedyk, D. Brendes, J. Keller. Date: April 2001 Formats: txt pdf Status: INFORMATIONAL This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks. The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP (Transaction Capability ApplicationPart), ISUP (ISDN User Part), and MTP (Mail Transport Protocol) messaging over TCP/IP. In addition, TALI provides SCCP (SignallingConnection Control Part) Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location.
RFC 3096	Requirements for robust IP/UDP/RTP header compression
	Authors: M. Degermark, Ed.. Date: July 2001 Formats: txt pdf Status: INFORMATIONAL This document contains requirements for robust IP/UDP/RTP (InternetProtocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression)WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.
RFC 3098	How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$
	Authors: T. Gavin, D. Eastlake 3rd, S. Hambridge. Date: April 2001 Formats: txt pdf Also: FYI 0038 Status: INFORMATIONAL This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. Some measure of clarity will also be added to the definitions, dangers, and details inherent to Internet Marketing.
RFC 3099	Request for Comments Summary RFC Numbers 3000-3099
	Authors: S. Ginoza. Date: November 2001 Formats: txt pdf Status: INFORMATIONAL
RFC 3106	ECML v1.1: Field Specifications for E-Commerce
	Authors: D. Eastlake 3rd, T. Goldstein. Date: April 2001 Formats: txt pdf Obsoletes: RFC 2706 Updated by: RFC 4112 Status: INFORMATIONAL Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication.
RFC 3109	Request to Move STD 39 to Historic Status
	Authors: R. Braden, R. Bush, J. Klensin. Date: May 2001 Formats: txt pdf Status: INFORMATIONAL This memo changes the status of STD 39, BBN Report 1822,"Specification of the Interconnection of a Host and an IMP", fromStandard to Historic.
RFC 3112	LDAP Authentication Password Schema
	Authors: K. Zeilenga. Date: May 2001 Formats: txt pdf Status: INFORMATIONAL This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This attribute type holds values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of userPassword.
RFC 3113	3GPP-IETF Standardization Collaboration
	Authors: K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the standardization collaboration between3GPP and IETF.
RFC 3114	Implementing Company Classification Policy with the S/MIME Security Label
	Authors: W. Nicolls. Date: May 2002 Formats: txt pdf Status: INFORMATIONAL This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples.
RFC 3116	Methodology for ATM Benchmarking
	Authors: J. Dunn, C. Martin. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (AsynchronousTransfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo is a product of the Benchmarking Methodology Working Group(BMWG) of the Internet Engineering Task Force (IETF).
RFC 3117	On the Design of Application Protocols
	Authors: M. Rose. Date: November 2001 Formats: txt pdf Status: INFORMATIONAL This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
RFC 3120	A URN Namespace for XML.org
	Authors: K. Best, N. Walsh. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of StructuredInformation Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language)Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents).
RFC 3121	A URN Namespace for OASIS
	Authors: K. Best, N. Walsh. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of StructuredInformation Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible MarkupLanguage) Document Type Definitions, XML Schemas, Namespaces,Stylesheets, and other documents).
RFC 3126	Electronic Signature Formats for long term electronic signatures
	Authors: D. Pinkas, J. Ross, N. Pope. Date: September 2001 Formats: txt pdf Obsoleted by: RFC 5126 Status: INFORMATIONAL This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates the validity of the signature). The format can be considered as an extension to RFC 2630 and RFC2634, where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC is technically equivalent toETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org
RFC 3127	Authentication, Authorization, and Accounting: Protocol Evaluation
	Authors: D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, B. Wolff. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo represents the process and findings of the Authentication,Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC2989. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented.
RFC 3128	Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)
	Authors: I. Miller. Date: June 2001 Formats: txt pdf Updates: RFC 1858 Status: INFORMATIONAL This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action.
RFC 3129	Requirements for Kerberized Internet Negotiation of Keys
	Authors: M. Thomas. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key.
RFC 3130	Notes from the State-Of-The-Technology: DNSSEC
	Authors: E. Lewis. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.
RFC 3131	3GPP2-IETF Standardization Collaboration
	Authors: S. Bradner, P. Calhoun, H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the standardization collaboration between3GPP2 and IETF.
RFC 3132	Dormant Mode Host Alerting ("IP Paging") Problem Statement
	Authors: J. Kempf. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. The results are specifically directed toward the task undertaken by the design team, and are not meant to be the definitive word on paging for all time, nor to be binding onSeamoby or other working groups, should the situation with regard toIP mobility protocols or radio link support undergo a major change.
RFC 3133	Terminology for Frame Relay Benchmarking
	Authors: J. Dunn, C. Martin. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices.
RFC 3134	Terminology for ATM ABR Benchmarking
	Authors: J. Dunn, C. Martin. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices supportingABR (Available Bit Rate). The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544 and2761. This memo is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF).
RFC 3135	Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations
	Authors: J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. Emphasis is put on proxies operating with TCP. In addition, motivations for their development and use are described along with some of the consequences of using them, especially in the context of the Internet.
RFC 3136	The SPIRITS Architecture
	Authors: L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public SwitchedTelephone Network)and necessitating the interactions between the PSTN and the Internet. (Internet Call Waiting, Internet Caller-IDDelivery, and Internet Call Forwarding are examples of SPIRIT services.) Specifically, it defines the components constituting the architecture and the interfaces between the components.
RFC 3137	OSPF Stub Router Advertisement
	Authors: A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router.However, OSPF does not specify a standard way to accomplish this.
RFC 3138	Extended Assignments in 233/8
	Authors: D. Meyer. Date: June 2001 Formats: txt pdf Obsoleted by: RFC 5771 Status: INFORMATIONAL This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space.
RFC 3139	Requirements for Configuration Management of IP-based Networks
	Authors: L. Sanchez, K. McCloghrie, J. Saperia. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP- based networks.
RFC 3141	CDMA2000 Wireless Data Requirements for AAA
	Authors: T. Hiller, P. Walsh, X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. Calhoun, C. Lo, E. Jaques, E. Campbell, Y.Xu,S.Baba,T.Ayaki,T.Seki,A.Hameed. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This memo specifies cdma2000 wireless data AAA (Authentication,Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services.
RFC 3142	An IPv6-to-IPv4 Transport Relay Translator
	Authors: J. Hagino, K. Yamamoto. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL The document describes an IPv6-to-IPv4 transport relay translator(TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic withIPv4-only hosts. A TRT system, which locates in the middle, translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa. The memo talks about how to implement a TRT system using existing technologies. It does not define any new protocols.
RFC 3143	Known HTTP Proxy/Caching Problems
	Authors: I. Cooper, J. Dilley. Date: June 2001 Formats: txt pdf Status: INFORMATIONAL This document catalogs a number of known problems with World Wide Web(WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. The construction of this document is a joint effort of the Web caching community.
RFC 3147	Generic Routing Encapsulation over CLNS Networks
	Authors: P. Christian. Date: July 2001 Formats: txt pdf Status: INFORMATIONAL This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network usingGRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS.
RFC 3148	A Framework for Defining Empirical Bulk Transfer Capacity Metrics
	Authors: M. Mathis, M. Allman. Date: July 2001 Formats: txt pdf Status: INFORMATIONAL This document defines a framework for standardizing multiple BTC(Bulk Transport Capacity) metrics that parallel the permitted transport diversity.
RFC 3149	MGCP Business Phone Packages
	Authors: A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram. Date: September 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a collection of MGCP (Media Gateway ControlProtocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones.
RFC 3151	A URN Namespace for Public Identifiers
	Authors: N. Walsh, J. Cowan, P. Grosso. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI(Uniform Resource Identifiers) syntax.
RFC 3154	Requirements and Functional Architecture for an IP Host Alerting Protocol
	Authors: J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of anIP protocol for alerting dormant IP mobile hosts, commonly called paging.
RFC 3157	Securely Available Credentials - Requirements
	Authors: A. Arsenault, S. Farrell. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL This document describes requirements to be placed on SecurelyAvailable Credentials (SACRED) protocols.
RFC 3158	RTP Testing Strategies
	Authors: C. Perkins, J. Rosenberg, H. Schulzrinne. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.
RFC 3160	The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
	Authors: S. Harris. Date: August 2001 Formats: txt pdf Obsoletes: RFC 1718 Obsoleted by: RFC 4677 Status: INFORMATIONAL This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process.
RFC 3164	The BSD Syslog Protocol
	Authors: C. Lonvick. Date: August 2001 Formats: txt pdf Obsoleted by: RFC 5424 Status: INFORMATIONAL This document describes the observed behavior of the syslog protocol.This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of CaliforniaBerkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices.
RFC 3166	Request to Move RFC 1403 to Historic Status
	Authors: D. Meyer, J. Scudder. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved toHistoric status.
RFC 3167	Request to Move RFC 1745 to Historic Status
	Authors: D. Meyer, J. Scudder. Date: August 2001 Formats: txt pdf Status: INFORMATIONAL RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status.
RFC 3169	Criteria for Evaluating Network Access Server Protocols
	Authors: M. Beadles, D. Mitton. Date: September 2001 Formats: txt pdf Status: INFORMATIONAL This document defines requirements for protocols used by NetworkAccess Servers (NAS).
RFC 3170	IP Multicast Applications: Challenges and Solutions
	Authors: B. Quinn, K. Almeroth. Date: September 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. To this end, the document presents a taxonomy of multicast application I/O models and examples of the services they can support.It then describes the service requirements of these multicast applications, and the recent and ongoing efforts to build protocol solutions to support these services.
RFC 3174	US Secure Hash Algorithm 1 (SHA1)
	Authors: D. Eastlake 3rd, P. Jones. Date: September 2001 Formats: txt pdf Updated by: RFC 4634, RFC 6234 Status: INFORMATIONAL The purpose of this document is to make the SHA-1 (Secure HashAlgorithm 1) hash algorithm conveniently available to the Internet community. The United States of America has adopted the SHA-1 hash algorithm described herein as a Federal Information ProcessingStandard. Most of the text herein was taken by the authors from FIPS180-1. Only the C code implementation is "original".
RFC 3176	InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks
	Authors: P. Phaal, S. Panchen, N. McKee. Date: September 2001 Formats: txt pdf Status: INFORMATIONAL This memo defines InMon Coporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector.
RFC 3177	IAB/IESG Recommendations on IPv6 Address Allocations to Sites
	Authors: IAB, IESG. Date: September 2001 Formats: txt pdf Obsoleted by: RFC 6177 Status: INFORMATIONAL This document provides recommendations to the addressing registries(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of/48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting. The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record.
RFC 3178	IPv6 Multihoming Support at Site Exit Routers
	Authors: J. Hagino, H. Snyder. Date: October 2001 Formats: txt pdf Status: INFORMATIONAL The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently- practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates.
RFC 3186	MAPOS/PPP Tunneling mode
	Authors: S. Shimizu, T. Kawano, K. Murakami, E. Beier. Date: December 2001 Formats: txt pdf Status: INFORMATIONAL This document specifies tunneling configuration over MAPOS (MultipleAccess Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP overSONET/SDH (Packet over SONET/SDH, POS) without any additional overhead.
RFC 3187	Using International Standard Book Numbers as Uniform Resource Names
	Authors: J. Hakala, H. Walravens. Date: October 2001 Formats: txt pdf Status: INFORMATIONAL This document discusses how International Standard Book Numbers(ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288.
RFC 3188	Using National Bibliography Numbers as Uniform Resource Names
	Authors: J. Hakala. Date: October 2001 Formats: txt pdf Status: INFORMATIONAL This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288.
RFC 3194	The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio
	Authors: A. Durand, C. Huitema. Date: November 2001 Formats: txt pdf Updates: RFC 1715 Status: INFORMATIONAL This document provides an update on the "H ratio" defined in RFC1715. It defines a new ratio which the authors claim is easier to understand.
RFC 3196	Internet Printing Protocol/1.1: Implementor's Guide
	Authors: T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst. Date: November 2001 Formats: txt pdf Obsoletes: RFC 2639 Status: INFORMATIONAL This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).
RFC 3197	Applicability Statement for DNS MIB Extensions
	Authors: R. Austein. Date: November 2001 Formats: txt pdf Status: INFORMATIONAL This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status.
RFC 3198	Terminology for Policy-Based Management
	Authors: A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser. Date: November 2001 Formats: txt pdf Status: INFORMATIONAL This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).
RFC 3199	Request for Comments Summary RFC Numbers 3100-3199
	Authors: S. Ginoza. Date: February 2003 Formats: txt pdf Status: INFORMATIONAL
RFC 3210	Applicability Statement for Extensions to RSVP for LSP-Tunnels
	Authors: D. Awduche, A. Hannan, X. Xiao. Date: December 2001 Formats: txt pdf Status: INFORMATIONAL This memo discusses the applicability of "Extensions to RSVP(Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track.
RFC 3213	Applicability Statement for CR-LDP
	Authors: J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This document discusses the applicability of Constraint-Based LSPSetup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track.
RFC 3215	LDP State Machine
	Authors: C. Boscher, P. Cheval, L. Wu, E. Gray. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This document provides state machine tables for ATM (AsynchronousTransfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. We begin in section 1 by defining a list of terminologies. Then in section 2, we propose two sets of state machine tables for ATM switchLSRs that use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 3, we provides a state machine for downstream unsolicited mode ATM LSRs. We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the "LDP controller" that is in charge of LDP session initialization, address mapping messages management, routing interface, etc. that is defined in the LDP specification. Even though the state machines in this document are specific forATM-LSR, they can be easily adapted for other types of LSRs.
RFC 3216	SMIng Objectives
	Authors: C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. Date: December 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives.
RFC 3217	Triple-DES and RC2 Key Wrapping
	Authors: R. Housley. Date: December 2001 Formats: txt pdf Status: INFORMATIONAL This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. These key wrap algorithms were originally published in section 12.6 of RFC 2630. They are republished since these key wrap algorithms have been found to be useful in contexts beyond those supported by RFC 2630.
RFC 3218	Preventing the Million Message Attack on Cryptographic Message Syntax
	Authors: E. Rescorla. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This memo describes a strategy for resisting the Million MessageAttack.
RFC 3221	Commentary on Inter-Domain Routing in the Internet
	Authors: G. Huston. Date: December 2001 Formats: txt pdf Status: INFORMATIONAL This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
RFC 3222	Terminology for Forwarding Information Base (FIB) based Router Performance
	Authors: G. Trotter. Date: December 2001 Formats: txt pdf Status: INFORMATIONAL This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router.
RFC 3232	Assigned Numbers: RFC 1700 is Replaced by an On-line Database
	Authors: J. Reynolds, Ed.. Date: January 2002 Formats: txt pdf Obsoletes: RFC 1700 Status: INFORMATIONAL This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters.
RFC 3234	Middleboxes: Taxonomy and Issues
	Authors: B. Carpenter, S. Brim. Date: February 2002 Formats: txt pdf Status: INFORMATIONAL This document is intended as part of an IETF discussion about"middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive.
RFC 3235	Network Address Translator (NAT)-Friendly Application Design Guidelines
	Authors: D. Senie. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This document discusses those things that application designers might wish to consider when designing new protocols. While many commonInternet applications will operate cleanly in the presence of NetworkAddress Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation).
RFC 3236	The 'application/xhtml+xml' Media Type
	Authors: M. Baker, P. Stark. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This document defines the 'application/xhtml+xml' MIME media type forXHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers'text/html'.
RFC 3237	Requirements for Reliable Server Pooling
	Authors: M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This document defines a basic set of requirements for reliable server pooling. The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool.
RFC 3238	IAB Architectural and Policy Considerations for Open Pluggable Edge Services
	Authors: S. Floyd, L. Daigle. Date: January 2002 Formats: txt pdf Status: INFORMATIONAL This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering ofOpen Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.
RFC 3239	Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations
	Authors: C. Kugler, H. Lewis, T. Hastings. Date: February 2002 Formats: txt pdf Status: INFORMATIONAL This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet PrintingProtocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects.The remaining operations operate on a new Device object that more closely models a single output device.
RFC 3240	Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration
	Authors: D. Clunie, E. Cordonnier. Date: February 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine).The baseline encoding is defined by the DICOM Standards Committee in"Digital Imaging and Communications in Medicine".
RFC 3243	RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression
	Authors: L-E. Jonsson. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL This document contains requirements for the 0-byte IP/UDP/RTP(Internet Protocol/User Datagram Protocol/Real-Time TransportProtocol) header compression scheme to be developed by the RobustHeader Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.
RFC 3244	Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols
	Authors: M. Swift, J. Trostle, J. Brezak. Date: February 2002 Formats: txt pdf Status: INFORMATIONAL This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user.
RFC 3245	The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)
	Authors: J. Klensin, Ed., IAB. Date: March 2002 Formats: txt pdf Status: INFORMATIONAL RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB.It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T StudyGroup 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.
RFC 3247	Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)
	Authors: A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan. Date: March 2002 Formats: txt pdf Status: INFORMATIONAL This document was written during the process of clarification ofRFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revisedEF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures.
RFC 3248	A Delay Bound alternative revision of RFC 2598
	Authors: G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein. Date: March 2002 Formats: txt pdf Status: INFORMATIONAL For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At thePittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF)Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in theDiffServ group. At the San Diego IETF meeting in December 2000 theDiffServ working group decided to pursue an alternative re-expression of the EF PHB.
RFC 3249	Implementers Guide for Facsimile Using Internet Mail
	Authors: V. Cancio, M. Moldovan, H. Tamura, D. Wing. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents.
RFC 3251	Electricity over IP
	Authors: B. Rajagopalan. Date: April 1 2002 Formats: txt pdf Status: INFORMATIONAL Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This document has also been written as a public service. The "Sub-IP" area has been formed to give equal opportunity to those working on technologies outside of traditional IP networking to write complicated IETF documents. There are possibly many who are wondering how to exploit this opportunity and attain high visibility.Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS control for random technologies) as highly amenable for producing a countless number of unimplementable documents. This document illustrates the key ingredients that go into producing any "foo- over-MPLS" document and may be used as a template for all such work.
RFC 3252	Binary Lexical Octet Ad-hoc Transport
	Authors: H. Kennedy. Date: April 1 2002 Formats: txt pdf Status: INFORMATIONAL This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications.
RFC 3254	Definitions for talking about directories
	Authors: H. Alvestrand. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL When discussing systems for making information accessible through theInternet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories".
RFC 3257	Stream Control Transmission Protocol Applicability Statement
	Authors: L. Coene. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the applicability of the Stream ControlTransmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) &Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP.
RFC 3258	Distributing Authoritative Name Servers via Shared Unicast Addresses
	Authors: T. Hardie. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.
RFC 3259	A Message Bus for Local Coordination
	Authors: J. Ott, C. Perkins, D. Kutscher. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms.
RFC 3260	New Terminology and Clarifications for Diffserv
	Authors: D. Grossman. Date: April 2002 Formats: txt pdf Updates: RFC 2474, RFC 2475, RFC 2597 Status: INFORMATIONAL This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC2597. When RFCs 2474 and 2597 advance on the standards track, andRFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the newRFCs.
RFC 3269	Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents
	Authors: R. Kermode, L. Vicisano. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL This document provides general guidelines to assist the authors ofReliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed.
RFC 3271	The Internet is for Everyone
	Authors: V. Cerf. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL This document expresses the Internet Society's ideology that theInternet really is for everyone. However, it will only be such if we make it so.
RFC 3272	Overview and Principles of Internet Traffic Engineering
	Authors: D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. Date: May 2002 Formats: txt pdf Updated by: RFC 5462 Status: INFORMATIONAL This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document.
RFC 3277	Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance
	Authors: D. McPherson. Date: April 2002 Formats: txt pdf Status: INFORMATIONAL This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification.
RFC 3278	Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Authors: S. Blake-Wilson, D. Brown, P. Lambert. Date: April 2002 Formats: txt pdf Obsoleted by: RFC 5753 Status: INFORMATIONAL This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. The readers attention is called to the Intellectual Property Rights section at the end of this document.
RFC 3283	Guide to Internet Calendaring
	Authors: B. Mahoney, G. Babics, A. Taler. Date: June 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), andRFC 2447 (iMIP). The work in progress addressed is "Calendar AccessProtocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work.
RFC 3285	Using Microsoft Word to create Internet Drafts and RFCs
	Authors: M. Gahrns, T. Hain. Date: May 2002 Formats: txt pdf Obsoleted by: RFC 5385 Status: INFORMATIONAL This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format.
RFC 3286	An Introduction to the Stream Control Transmission Protocol (SCTP)
	Authors: L. Ong, J. Yoakum. Date: May 2002 Formats: txt pdf Status: INFORMATIONAL This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol.
RFC 3290	An Informal Management Model for Diffserv Routers
	Authors: Y. Bernet, S. Blake, D. Grossman, A. Smith. Date: May 2002 Formats: txt pdf Status: INFORMATIONAL This document proposes an informal management model of DifferentiatedServices (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements(e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers.It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture.
RFC 3294	General Switch Management Protocol (GSMP) Applicability
	Authors: A. Doria, K. Sundell. Date: June 2002 Formats: txt pdf Status: INFORMATIONAL This memo provides an overview of the GSMP (General Switch ManagementProtocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in anATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration.
RFC 3298	Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
	Authors: I. Faynberg, J. Gato, H. Lu, L. Slutsman. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public SwitchedTelephone Network (PSTN) and necessitate the interactions between thePSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, andInternet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlierIETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.
RFC 3299	Request for Comments Summary RFC Numbers 3200-3299
	Authors: S. Ginoza. Date: December 2003 Formats: txt pdf Status: INFORMATIONAL
RFC 3303	Middlebox communication architecture and framework
	Authors: P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group. There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP andH.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic.
RFC 3304	Middlebox Communications (midcom) Protocol Requirements
	Authors: R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document specifies the requirements that the MiddleboxCommunication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function.These requirements were developed with a specific focus on network address translation and firewall middleboxes.
RFC 3305	Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations
	Authors: M. Mealling, Ed., R. Denenberg, Ed.. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document, a product of the W3C Uniform Resource Identifier (URI)Interest Group, addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject.
RFC 3310	Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)
	Authors: A. Niemi, J. Arkko, V. Torvinen. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext TransferProtocol (HTTP) Digest access authentication. The HTTPAuthentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal MobileTelecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.
RFC 3313	Private Session Initiation Protocol (SIP) Extensions for Media Authorization
	Authors: W. Marshall, Ed.. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.
RFC 3314	Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards
	Authors: M. Wasserman, Ed.. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL This document contains recommendations from the Internet EngineeringTask Force (IETF) IPv6 Working Group to the Third GenerationPartnership Project (3GPP) community regarding the use of IPv6 in the3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document.
RFC 3316	Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts
	Authors: J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on howIPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or UniversalMobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.
RFC 3317	Differentiated Services Quality of Service Policy Information Base
	Authors: K. Chan, R. Sahita, S. Hahn, K. McCloghrie. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control over resources implementing the Differentiated Services Architecture.These provisioning classes can be used with other none DifferentiatedServices provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage.
RFC 3318	Framework Policy Information Base
	Authors: R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol forProvisioning. Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well- defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules.However, some PRovisioning Classes are common to all subject- categories (client-types) and need to be present in each.
RFC 3322	Signaling Compression (SigComp) Requirements & Assumptions
	Authors: H. Hannu. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL The purpose of this document is to outline requirements and motivations for the development of a scheme for compression and decompression of messages from signaling protocols. In wireless environments and especially in cellular systems, e.g., GSM (GlobalSystem for Mobile communications) and UMTS (Universal MobileTelecommunications System), there is a need to maximize the transport efficiency for data over the radio interface. With the introduction of SIP/SDP (Session Initiation Protocol/Session Description Protocol) to cellular devices, compression of the signaling messages should be considered in order to improve both service availability and quality, mainly by reducing the user idle time, e.g., at call setup.
RFC 3324	Short Term Requirements for Network Asserted Identity
	Authors: M. Watson. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL A Network Asserted Identity is an identity initially derived by aSession Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks. There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias.
RFC 3325	Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
	Authors: C. Jennings, J. Peterson, M. Watson. Date: November 2002 Formats: txt pdf Updated by: RFC 5876 Status: INFORMATIONAL This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large.
RFC 3330	Special-Use IPv4 Addresses
	Authors: IANA. Date: September 2002 Formats: txt pdf Obsoleted by: RFC 5735 Status: INFORMATIONAL This document describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned NumbersAuthority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers.
RFC 3345	Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
	Authors: D. McPherson, V. Gill, D. Walton, A. Retana. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL In particular configurations, the BGP scaling mechanisms defined in"BGP Route Reflection - An Alternative to Full Mesh IBGP" and"Autonomous System Confederations for BGP" will introduce persistentBGP route oscillation. This document discusses the two types of persistent route oscillation that have been identified, describes when these conditions will occur, and provides some network design guidelines to avoid introducing such occurrences.
RFC 3346	Applicability Statement for Traffic Engineering with MPLS
	Authors: J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the applicability of Multiprotocol LabelSwitching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted.
RFC 3348	The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
	Authors: M. Gahrns, R. Cheng. Date: July 2002 Formats: txt pdf Status: INFORMATIONAL The Internet Message Action Protocol (IMAP4) CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST "" * or aLIST "" % for each mailbox.
RFC 3351	User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals
	Authors: N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document presents a set of Session Initiation Protocol(SIP) user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications. A number of issues related to these user requirements are further raised in this document. Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level.
RFC 3352	Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status
	Authors: K. Zeilenga. Date: March 2003 Formats: txt pdf Obsoletes: RFC 1798 Status: INFORMATIONAL The Connection-less Lightweight Directory Access Protocol (CLDAP) technical specification, RFC 1798, was published in 1995 as aProposed Standard. This document discusses the reasons why the CLDAP technical specification has not been furthered on the Standard Track.This document recommends that RFC 1798 be moved to Historic status.
RFC 3353	Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment
	Authors: D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document offers a framework for IP multicast deployment in anMPLS environment. Issues arising when MPLS techniques are applied toIP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered.
RFC 3354	Internet Open Trading Protocol Version 2 Requirements
	Authors: D. Eastlake 3rd. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document gives requirements for the Internet Open TradingProtocol (IOTP) Version 2 by describing design principles and scope and dividing features into those which will, may, or will not be included. Version 2 of the IOTP will extend the interoperable framework forInternet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms.
RFC 3356	Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines
	Authors: G. Fishman, S. Bradner. Date: August 2002 Formats: txt pdf Obsoletes: RFC 2436 Status: INFORMATIONAL This document provides guidance to aid in the understanding of collaboration on standards development between the InternationalTelecommunication Union -- Telecommunication Standardization Sector(ITU-T) and the Internet Society (ISOC) / Internet Engineering TaskForce (IETF). It is an update of and obsoletes RFC 2436. The updates reflect changes in the IETF and ITU-T since RFC 2436 was written. The bulk of this document is common text with ITU-TSupplement 3 to the ITU-T A-Series Recommendations. Note: This was approved by ITU-T TSAG on 30 November 2001 as aSupplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3).
RFC 3357	One-way Loss Pattern Sample Metrics
	Authors: R. Koodli, R. Ravikanth. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL Using the base loss metric defined in RFC 2680, this document defines two derived metrics "loss distance" and "loss period", and the associated statistics that together capture loss patterns experienced by packet streams on the Internet. The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. The loss pattern or loss distribution is a key parameter that determines the performance observed by the users for certain real-time applications such as packet voice and video. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance.
RFC 3358	Optional Checksums in Intermediate System to Intermediate System (ISIS)
	Authors: T. Przygienda. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document describes an optional extension to the IntermediateSystem to Intermediate System (ISIS) protocol, used today by severalInternet Service Proviers (ISPs) for routing within their clouds.ISIS is an interior gateway routing protocol developed originally byOSI and used with IP extensions as Interior Gateway Protocol (IGP).ISIS originally does not provide Complete Sequence Numbers ProtocolData (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP) checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional Type, Length and Value (TLV) providing checksums.
RFC 3359	Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System
	Authors: T. Przygienda. Date: August 2002 Formats: txt pdf Status: INFORMATIONAL This document describes implementation codepoints within IntermediateSystem to Intermediate System (IS-IS) used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions asInterior Gateway Protocol (IGP). This document summarizes all Table,Length and Value (TLV) codepoints that are being used by the protocol and its pending extensions.
RFC 3363	Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
	Authors: R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. Date: August 2002 Formats: txt pdf Updates: RFC 2673, RFC 2874 Status: INFORMATIONAL This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status.
RFC 3364	Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)
	Authors: R. Austein. Date: August 2002 Formats: txt pdf Updates: RFC 2673, RFC 2874 Status: INFORMATIONAL The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on.
RFC 3373	Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies
	Authors: D. Katz, R. Saluja. Date: September 2002 Formats: txt pdf Obsoleted by: RFC 5303 Status: INFORMATIONAL The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors.
RFC 3374	Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network
	Authors: J. Kempf, Ed.. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly.In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service(QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility.
RFC 3375	Generic Registry-Registrar Protocol Requirements
	Authors: S. Hollenbeck. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models.
RFC 3378	EtherIP: Tunneling Ethernet Frames in IP Datagrams
	Authors: R. Housley, S. Hollenbeck. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the EtherIP, an early tunneling protocol, to provide informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse anIP internet. The protocol is very lightweight, and it does not provide protection against infinite loops.
RFC 3379	Delegated Path Validation and Delegated Path Discovery Protocol Requirements
	Authors: D. Pinkas, R. Housley. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL This document specifies the requirements for Delegated PathValidation (DPV) and Delegated Path Discovery (DPD) for Public KeyCertificates. It also specifies the requirements for DPV and DPD policy management.
RFC 3384	Lightweight Directory Access Protocol (version 3) Replication Requirements
	Authors: E. Stokes, R. Weiser, R. Moats, R. Huber. Date: October 2002 Formats: txt pdf Status: INFORMATIONAL This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol(version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories.
RFC 3385	Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations
	Authors: D. Sheinwald, J. Satran, P. Thaler, V. Cavanna. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL In this memo, we attempt to give some estimates for the probability of undetected errors to facilitate the selection of an error detection code for the Internet Protocol Small Computer SystemInterface (iSCSI). We will also attempt to compare Cyclic Redundancy Checks (CRCs) with other checksum forms (e.g., Fletcher, Adler, weighted checksums), as permitted by available data.
RFC 3386	Network Hierarchy and Multilayer Survivability
	Authors: W. Lai, Ed., D. McDysan, Ed.. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments.
RFC 3387	Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network
	Authors: M. Eder, H. Chaskar, S. Nag. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL The guiding principles in the design of IP network management were simplicity and no centralized control. The best effort service paradigm was a result of the original management principles and the other way around. New methods to distinguish the service given to one set of packets or flows relative to another are well underway.However, as IP networks evolve the management approach of the past may not apply to the Quality of Service (QoS)-capable network envisioned by some for the future. This document examines some of the areas of impact that QoS is likely to have on management and look at some questions that remain to be addressed.
RFC 3391	The MIME Application/Vnd.pwg-multiplexed Content-Type
	Authors: R. Herriot. Date: December 2002 Formats: txt pdf Status: INFORMATIONAL The Application/Vnd.pwg-multiplexed content-type, like theMultipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. AnApplication/Vnd.pwg-multiplexed entity contains a sequence of chunks.Each chunk contains a MIME message or a part of a MIME message. EachMIME message represents a component of the compound object, just as a body part of a Multipart/Related entity represents a component. With a Multipart/Related entity, a body part and its reference in some other body part may be separated by many octets. With anApplication/Vnd.pwg-multiplexed entity, a message and its reference in some other message can be made quite close by chunking the message containing the reference. For example, if a long message contains references to images and the producer does not know of the need for each image until it generates the reference, thenApplication/Vnd.pwg-multiplexed allows the consumer to process the reference to the image and the image before it consumes the entire long message. This ability is important in printing and scanning applications. This document defines the Application/Vnd.pwg- multiplexed content-type. It also provides examples of its use.
RFC 3394	Advanced Encryption Standard (AES) Key Wrap Algorithm
	Authors: J. Schaad, R. Housley. Date: September 2002 Formats: txt pdf Status: INFORMATIONAL The purpose of this document is to make the Advanced EncryptionStandard (AES) Key Wrap algorithm conveniently available to theInternet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES KeyWrap posted by NIST.
RFC 3401	Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
	Authors: M. Mealling. Date: October 2002 Formats: txt pdf Obsoletes: RFC 2915, RFC 2168 Updates: RFC 2276 Status: INFORMATIONAL This document specifies the exact documents that make up the completeDynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC2168 and RFC 2915, as well as updates RFC 2276.
RFC 3409	Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
	Authors: K. Svanbro. Date: December 2002 Formats: txt pdf Status: INFORMATIONAL This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers.The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified byThird Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2),European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP andUDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document.
RFC 3410	Introduction and Applicability Statements for Internet-Standard Management Framework
	Authors: J. Case, R. Mundy, D. Partain, B. Stewart. Date: December 2002 Formats: txt pdf Obsoletes: RFC 2570 Status: INFORMATIONAL 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. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157,1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570.
RFC 3422	Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)
	Authors: O. Okamoto, M. Maruyama, T. Sajima. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL This memo describes a method for forwarding media access control(MAC) frames over Multiple Access Protocol over Synchronous OpticalNetwork/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network(LAN) environment.
RFC 3423	XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0
	Authors: K. Zhang, E. Elkin. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL This document defines the Common Reliable Accounting for NetworkElement (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems(BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.
RFC 3424	IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
	Authors: L. Daigle, Ed., IAB. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL As a result of the nature of Network Address Translation (NAT)Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-AddressFixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal.
RFC 3426	General Architectural and Policy Considerations
	Authors: S. Floyd. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed.
RFC 3429	Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions
	Authors: H. Ohta. Date: November 2002 Formats: txt pdf Status: INFORMATIONAL This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the'Operation and Maintenance (OAM) Alert Label' that is used by user- plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets.
RFC 3435	Media Gateway Control Protocol (MGCP) Version 1.0
	Authors: F. Andreasen, B. Foster. Date: January 2003 Formats: txt pdf Obsoletes: RFC 2705 Updated by: RFC 3661 Status: INFORMATIONAL This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control"intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals.The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents.
RFC 3439	Some Internet Architectural Guidelines and Philosophy
	Authors: R. Bush, D. Meyer. Date: December 2002 Formats: txt pdf Updates: RFC 1958 Status: INFORMATIONAL This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones.
RFC 3441	Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)
	Authors: R. Kumar. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, andATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol.
RFC 3444	On the Difference between Information Models and Data Models
	Authors: A. Pras, J. Schoenwaelder. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL There has been ongoing confusion about the differences betweenInformation Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as theInternational Telecommunication Union (ITU) or the DistributedManagement Task Force (DMTF)) fit into the universe of InformationModels and Data Models. This memo documents the main results of the 8th workshop of theNetwork Management Research Group (NMRG) of the Internet ResearchTask Force (IRTF) hosted by the University of Texas at Austin.
RFC 3446	Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
	Authors: D. Kim, D. Meyer, H. Kilmer, D. Farinacci. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree ProtocolIndependent Multicast-Sparse Mode (PIM-SM) domain.
RFC 3447	Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1
	Authors: J. Jonsson, B. Kaliski. Date: February 2003 Formats: txt pdf Obsoletes: RFC 2437 Status: INFORMATIONAL This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.
RFC 3453	The Use of Forward Error Correction (FEC) in Reliable Multicast
	Authors: M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. Date: December 2002 Formats: txt pdf Status: INFORMATIONAL This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC.
RFC 3455	Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
	Authors: M. Garcia-Martin, E. Henrikson, D. Mills. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the 3rd-Generation PartnershipProject (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.
RFC 3457	Requirements for IPsec Remote Access Scenarios
	Authors: S. Kelly, S. Ramamoorthi. Date: January 2003 Formats: txt pdf Status: INFORMATIONAL IPsec offers much promise as a secure remote access mechanism.However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios.
RFC 3466	A Model for Content Internetworking (CDI)
	Authors: M. Day, B. Cain, G. Tomlinson, P. Rzewski. Date: February 2003 Formats: txt pdf Status: INFORMATIONAL Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called"content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary.
RFC 3467	Role of the Domain Name System (DNS)
	Authors: J. Klensin. Date: February 2003 Formats: txt pdf Status: INFORMATIONAL This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them.
RFC 3468	The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols
	Authors: L. Andersson, G. Swallow. Date: February 2003 Formats: txt pdf Updates: RFC 3212, RFC 3472, RFC 3475, RFC 3476 Status: INFORMATIONAL This document documents the consensus reached by the MultiprotocolLabel Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions toRSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG.
RFC 3469	Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
	Authors: V. Sharma, Ed., F. Hellstrand, Ed.. Date: February 2003 Formats: txt pdf Updated by: RFC 5462 Status: INFORMATIONAL Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework.
RFC 3474	Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)
	Authors: Z. Lin, D. Pendarakis. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SynchronousOptical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well asOptical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using ResourceReservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-TStudy Group 15 in support of ITU's ASON standardization effort.
RFC 3475	Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)
	Authors: O. Aboul-Magd. Date: March 2003 Formats: txt pdf Updated by: RFC 3468 Status: INFORMATIONAL Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by theIETF in the context of Generalized Multi-Protocol Label Switching(GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents.
RFC 3476	Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling
	Authors: B. Rajagopalan. Date: March 2003 Formats: txt pdf Updated by: RFC 3468 Status: INFORMATIONAL The Optical Interworking Forum (OIF) has defined extensions to theLabel Distribution Protocol (LDP) and the Resource ReSerVationProtocol (RSVP) for optical User Network Interface (UNI) signaling.These extensions consist of a set of new data objects and error codes. This document describes these extensions.
RFC 3482	Number Portability in the Global Switched Telephone Network (GSTN): An Overview
	Authors: M. Foster, T. McGarry, J. Yu. Date: February 2003 Formats: txt pdf Status: INFORMATIONAL This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters forNP implementation, most of which are not network technology specific.Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF.
RFC 3483	Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)
	Authors: D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point(PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPSReport Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state.
RFC 3487	Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
	Authors: H. Schulzrinne. Date: February 2003 Formats: txt pdf Status: INFORMATIONAL This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session InitiationProtocol (SIP).
RFC 3488	Cisco Systems Router-port Group Management Protocol (RGMP)
	Authors: I. Wu, T. Eckert. Date: February 2003 Formats: txt pdf Status: INFORMATIONAL This document describes the Router-port Group Management Protocol(RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.
RFC 3493	Basic Socket Interface Extensions for IPv6
	Authors: R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. Date: February 2003 Formats: txt pdf Obsoletes: RFC 2553 Status: INFORMATIONAL 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.
RFC 3494	Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status
	Authors: K. Zeilenga. Date: March 2003 Formats: txt pdf Obsoletes: RFC 1484, RFC 1485, RFC 1487, RFC 1777, RFC 1778, RFC 1779, RFC 1781, RFC 2559 Status: INFORMATIONAL This document recommends the retirement of version 2 of theLightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status.
RFC 3496	Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering
	Authors: A. G. Malis, T. Hsiao. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL This document specifies a Resource ReSerVation Protocol-TrafficEngineering (RSVP-TE) signaling extension for support of AsynchronousTransfer Mode (ATM) Service Class-aware Multiprotocol Label Switching(MPLS) Traffic Engineering.
RFC 3499	Request for Comments Summary RFC Numbers 3400-3499
	Authors: S. Ginoza. Date: December 2003 Formats: txt pdf Status: INFORMATIONAL
RFC 3504	Internet Open Trading Protocol (IOTP) Version 1, Errata
	Authors: D. Eastlake. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL Since the publication of the RFCs specifying Version 1.0 of theInternet Open Trading Protocol (IOTP), some errors have been noted.This informational document lists these errors and provides corrections for them.
RFC 3505	Electronic Commerce Modeling Language (ECML): Version 2 Requirements
	Authors: D. Eastlake. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to ExtensibleMarkup Language (XML) syntax, data model, format, and payment processing.
RFC 3506	Requirements and Design for Voucher Trading System (VTS)
	Authors: K. Fujimura, D. Eastlake. Date: March 2003 Formats: txt pdf Status: INFORMATIONAL Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher TradingSystem (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the GenericVoucher Language (GVL), with which diverse types of vouchers can be described.
RFC 3507	Internet Content Adaptation Protocol (ICAP)
	Authors: J. Elson, A. Cerpa. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services.ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to passHTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses.
RFC 3508	H.323 Uniform Resource Locator (URL) Scheme Registration
	Authors: O. Levin. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL ITU-T Recommendation H.323 version 4 introduced an H.323-specificUniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority(IANA).
RFC 3509	Alternative Implementations of OSPF Area Border Routers
	Authors: A. Zinin, A. Lindem, D. Yeung. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers.
RFC 3511	Benchmarking Methodology for Firewall Performance
	Authors: B. Hickman, D. Newman, S. Tadjudin, T. Martin. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF).
RFC 3512	Configuring Networks and Devices with Simple Network Management Protocol (SNMP)
	Authors: M. MacFaden, D. Partain, J. Saperia, W. Tackabury. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL This document is written for readers interested in the InternetStandard Management Framework and its protocol, the Simple NetworkManagement Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks.
RFC 3514	The Security Flag in the IPv4 Header
	Authors: S. Bellovin. Date: April 1 2003 Formats: txt pdf Status: INFORMATIONAL Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases.
RFC 3521	Framework for Session Set-up with Media Authorization
	Authors: L-N. Hamer, B. Gage, H. Shieh. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session.
RFC 3523	Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology
	Authors: J. Polk. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREPWorking Group during discussions and when writing requirements, gap analysis and other solutions documents.
RFC 3531	A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block
	Authors: M. Blanchet. Date: April 2003 Formats: txt pdf Status: INFORMATIONAL This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments.
RFC 3532	Requirements for the Dynamic Partitioning of Switching Elements
	Authors: T. Anderson, J. Buerkle. Date: May 2003 Formats: txt pdf Status: INFORMATIONAL This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element(e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party.
RFC 3533	The Ogg Encapsulation Format Version 0
	Authors: S. Pfeiffer. Date: May 2003 Formats: txt pdf Status: INFORMATIONAL This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams.It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream.
RFC 3535	Overview of the 2002 IAB Network Management Workshop
	Authors: J. Schoenwaelder. Date: May 2003 Formats: txt pdf Status: INFORMATIONAL This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide theIETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
RFC 3536	Terminology Used in Internationalization in the IETF
	Authors: P. Hoffman. Date: May 2003 Formats: txt pdf Obsoleted by: RFC 6365 Status: INFORMATIONAL This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
RFC 3538	Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)
	Authors: Y. Kawatsura. Date: June 2003 Formats: txt pdf Status: INFORMATIONAL This document describes detailed Input/Output parameters for theInternet Open Trading Protocol (IOTP) Payment Application ProgrammingInterface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP.
RFC 3541	A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)
	Authors: A. Walsh. Date: May 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality ModelingLanguage (VRML) and Extensible 3D (X3D) files and resources,Extensible Markup Language (XML) Document Type Definitions (DTDs),XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D.
RFC 3542	Advanced Sockets Application Program Interface (API) for IPv6
	Authors: W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. Date: May 2003 Formats: txt pdf Obsoletes: RFC 2292 Status: INFORMATIONAL This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping,Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification(specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum TransmissionUnit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are notIPv6-capable.
RFC 3548	The Base16, Base32, and Base64 Data Encodings
	Authors: S. Josefsson, Ed.. Date: July 2003 Formats: txt pdf Obsoleted by: RFC 4648 Status: INFORMATIONAL This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets.
RFC 3549	Linux Netlink as an IP Services Protocol
	Authors: J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov. Date: July 2003 Formats: txt pdf Status: INFORMATIONAL This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component(FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group.
RFC 3562	Key Management Considerations for the TCP MD5 Signature Option
	Authors: M. Leech. Date: July 2003 Formats: txt pdf Status: INFORMATIONAL The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature.This document addresses the security requirements of that keying material.
RFC 3563	Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development
	Authors: A. Zinin. Date: July 2003 Formats: txt pdf Updated by: RFC 6233 Status: INFORMATIONAL This document contains the text of the agreement signed betweenISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines.
RFC 3564	Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering
	Authors: F. Le Faucheur, W. Lai. Date: July 2003 Formats: txt pdf Updated by: RFC 5462 Status: INFORMATIONAL This document presents Service Provider requirements for support ofDifferentiated Services (Diff-Serv)-aware MPLS Traffic Engineering(DS-TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short andDiff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution.
RFC 3567	Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication
	Authors: T. Li, R. Atkinson. Date: July 2003 Formats: txt pdf Obsoleted by: RFC 5304 Status: INFORMATIONAL This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.
RFC 3568	Known Content Network (CN) Request-Routing Mechanisms
	Authors: A. Barbir, B. Cain, R. Nair, O. Spatscheck. Date: July 2003 Formats: txt pdf Status: INFORMATIONAL This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or beforeDecember 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layerRequest-Routing, and Application-layer Request-Routing.
RFC 3569	An Overview of Source-Specific Multicast (SSM)
	Authors: S. Bhattacharyya, Ed.. Date: July 2003 Formats: txt pdf Status: INFORMATIONAL The purpose of this document is to provide an overview ofSource-Specific Multicast (SSM) and issues related to its deployment.It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models.
RFC 3570	Content Internetworking (CDI) Scenarios
	Authors: P. Rzewski, M. Day, D. Gilletti. Date: July 2003 Formats: txt pdf Status: INFORMATIONAL In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals.
RFC 3571	Framework Policy Information Base for Usage Feedback
	Authors: D. Rawlins, A. Kulkarni, K. Ho Chan, M. Bokaemper, D. Dutt. Date: August 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a portion of the Policy Information Base(PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point(PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected.
RFC 3572	Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)
	Authors: T. Ogura, M. Maruyama, T. Yoshida. Date: July 2003 Formats: txt pdf Status: INFORMATIONAL Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over aSynchronous Optical NETwork/Synchronous Digital Hierarchy(SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of formingIPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages.
RFC 3574	Transition Scenarios for 3GPP Networks
	Authors: J. Soininen, Ed.. Date: August 2003 Formats: txt pdf Status: INFORMATIONAL This document describes different scenarios in Third GenerationPartnership Project (3GPP) defined packet network, i.e., GeneralPacket Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study.
RFC 3576	Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Authors: M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. Date: July 2003 Formats: txt pdf Obsoleted by: RFC 5176 Status: INFORMATIONAL This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.
RFC 3577	Introduction to the Remote Monitoring (RMON) Family of MIB Modules
	Authors: S. Waldbusser, R. Cole, C. Kalbfleisch, D. Romascanu. Date: August 2003 Formats: txt pdf Status: INFORMATIONAL The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another.
RFC 3579	RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
	Authors: B. Aboba, P. Calhoun. Date: September 2003 Formats: txt pdf Updates: RFC 2869 Updated by: RFC 5080 Status: INFORMATIONAL This document defines Remote Authentication Dial In User Service(RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. WhileEAP was originally developed for use with PPP, it is now also in use with IEEE 802. This document updates RFC 2869.
RFC 3580	IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
	Authors: P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document provides suggestions on Remote Authentication Dial InUser Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normativeAppendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.
RFC 3582	Goals for IPv6 Site-Multihoming Architectures
	Authors: J. Abley, B. Black, V. Gill. Date: August 2003 Formats: txt pdf Status: INFORMATIONAL This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here.
RFC 3583	Requirements of a Quality of Service (QoS) Solution for Mobile IP
	Authors: H. Chaskar, Ed.. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet.However, it is also required to provide proper Quality of Service(QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP.
RFC 3587	IPv6 Global Unicast Address Format
	Authors: R. Hinden, S. Deering, E. Nordmark. Date: August 2003 Formats: txt pdf Obsoletes: RFC 2374 Status: INFORMATIONAL This document obsoletes RFC 2374, "An IPv6 Aggregatable GlobalUnicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next LevelAggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic.
RFC 3589	Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5
	Authors: J. Loughney. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document describes the IANA's allocation of a block of DiameterCommand Codes for the Third Generation Partnership Project (3GPP)Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification.
RFC 3599	Request for Comments Summary RFC Numbers 3500-3599
	Authors: S. Ginoza. Date: December 2003 Formats: txt pdf Status: INFORMATIONAL This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs
RFC 3603	Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
	Authors: W. Marshall, Ed., F. Andreasen, Ed.. Date: October 2003 Formats: txt pdf Obsoleted by: RFC 5503 Status: INFORMATIONAL In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.
RFC 3604	Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)
	Authors: H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe. Date: October 2003 Formats: txt pdf Status: INFORMATIONAL This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.
RFC 3607	Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool
	Authors: M. Leech. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.
RFC 3609	Tracing Requirements for Generic Tunnels
	Authors: R. Bonica, K. Kompella, D. Meyer. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers.Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by anIP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.
RFC 3610	Counter with CBC-MAC (CCM)
	Authors: D. Whiting, R. Housley, N. Ferguson. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).
RFC 3612	Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)
	Authors: A. Farrel. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212,"Constraint-Based LSP Setup Using LDP".
RFC 3613	Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)
	Authors: R. Morgan, K. Hazelton. Date: October 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE).This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.
RFC 3614	A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)
	Authors: J. Smith. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.
RFC 3615	A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging
	Authors: J. Gustin, A. Goyens. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.
RFC 3616	A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)
	Authors: F. Bellifemine, I. Constantinescu, S. Willmott. Date: September 2003 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the Foundation for Intelligent PhysicalAgents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.
RFC 3617	Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)
	Authors: E. Lear. Date: October 2003 Formats: txt pdf Status: INFORMATIONAL The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time.While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.
RFC 3619	Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1
	Authors: S. Shah, M. Yip. Date: October 2003 Formats: txt pdf Status: INFORMATIONAL This document describes the Ethernet Automatic Protection Switching(EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided bySONET rings, at a lower cost and with fewer constraints (e.g., ring size).
RFC 3622	A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project
	Authors: M. Mealling. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.
RFC 3624	The Media Gateway Control Protocol (MGCP) Bulk Audit Package
	Authors: B. Foster, D. Auerbach, F. Andreasen. Date: November 2003 Formats: txt pdf Status: INFORMATIONAL The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints.It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.
RFC 3625	The QCP File Format and Media Types for Speech Data
	Authors: R. Gellens, H. Garudadri. Date: September 2003 Formats: txt pdf Updates: RFC 3555 Status: INFORMATIONAL RFC 2658 specifies the streaming format for 3GPP2 13K vocoder (HighRate Speech Service Option 17 for Wideband Spread SpectrumCommunications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder(EVRC) and Selectable Mode Vocoders (SMV) data. (For example,Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types forEVRC and SMV (respectively) data stored in this format.
RFC 3628	Policy Requirements for Time-Stamping Authorities (TSAs)
	Authors: D. Pinkas, N. Pope, J. Ross. Date: November 2003 Formats: txt pdf Status: INFORMATIONAL This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.
RFC 3631	Security Mechanisms for the Internet
	Authors: S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed.. Date: December 2003 Formats: txt pdf Status: INFORMATIONAL Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.
RFC 3632	VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
	Authors: S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli. Date: November 2003 Formats: txt pdf Updates: RFC 2832 Status: INFORMATIONAL This document updates version 1.1.0 of the Network Solutions Inc.(NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of theVeriSign Registry Registrar Protocol.
RFC 3638	Applicability Statement for Reclassification of RFC 1643 to Historic Status
	Authors: J. Flick, C. M. Heard. Date: September 2003 Formats: txt pdf Obsoletes: RFC 1643 Status: INFORMATIONAL This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.
RFC 3639	Considerations on the use of a Service Identifier in Packet Headers
	Authors: M. St. Johns, Ed., G. Huston, Ed., IAB. Date: October 2003 Formats: txt pdf Status: INFORMATIONAL This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.
RFC 3647	Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
	Authors: S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. Date: November 2003 Formats: txt pdf Obsoletes: RFC 2527 Status: INFORMATIONAL This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. 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 or a certification practice statement. This document supersedes RFC 2527.
RFC 3650	Handle System Overview
	Authors: S. Sun, L. Lannom, B. Boesch. Date: November 2003 Formats: txt pdf Status: INFORMATIONAL This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. TheHandle System is a general-purpose global name service that allows secured name resolution and administration over networks such as theInternet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.
RFC 3651	Handle System Namespace and Service Definition
	Authors: S. Sun, S. Reilly, L. Lannom. Date: November 2003 Formats: txt pdf Status: INFORMATIONAL The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document provides a detailed description of theHandle System namespace, and its data, service, and operation models.The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by theHandle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.
RFC 3652	Handle System Protocol (ver 2.1) Specification
	Authors: S. Sun, S. Reilly, L. Lannom, J. Petrone. Date: November 2003 Formats: txt pdf Status: INFORMATIONAL The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle.It also defines the messages exchanged between the client and server for any handle operation.
RFC 3653	XML-Signature XPath Filter 2.0
	Authors: J. Boyer, M. Hughes, J. Reagle. Date: December 2003 Formats: txt pdf Status: INFORMATIONAL XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as aW3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
RFC 3654	Requirements for Separation of IP Control and Forwarding
	Authors: H. Khosravi, Ed., T. Anderson, Ed.. Date: November 2003 Formats: txt pdf Status: INFORMATIONAL This document introduces the Forwarding and Control ElementSeparation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.
RFC 3660	Basic Media Gateway Control Protocol (MGCP) Packages
	Authors: B. Foster, F. Andreasen. Date: December 2003 Formats: txt pdf Updates: RFC 2705 Status: INFORMATIONAL This document provides a basic set of Media Gateway Control Protocol(MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (DualTone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.
RFC 3661	Media Gateway Control Protocol (MGCP) Return Code Usage
	Authors: B. Foster, C. Sivachelvan. Date: December 2003 Formats: txt pdf Updates: RFC 3435 Status: INFORMATIONAL This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP)Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that theCall Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.
RFC 3662	A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
	Authors: R. Bless, K. Nichols, K. Wehrle. Date: December 2003 Formats: txt pdf Status: INFORMATIONAL This document proposes a differentiated services per-domain behavior(PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best- effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.
RFC 3669	Guidelines for Working Groups on Intellectual Property Issues
	Authors: S. Brim. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF.
RFC 3675	.sex Considered Dangerous
	Authors: D. Eastlake 3rd. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.
RFC 3678	Socket Interface Extensions for Multicast Source Filters
	Authors: D. Thaler, B. Fenner, B. Quinn. Date: January 2004 Formats: txt pdf Status: INFORMATIONAL The Internet Group Management Protocol (IGMPv3) for IPv4 and theMulticast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.
RFC 3679	Unused Dynamic Host Configuration Protocol (DHCP) Option Codes
	Authors: R. Droms. Date: January 2004 Formats: txt pdf Status: INFORMATIONAL Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic HostConfiguration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.
RFC 3689	General Requirements for Emergency Telecommunication Service (ETS)
	Authors: K. Carlberg, R. Atkinson. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This document presents a list of general requirements in support ofEmergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s).
RFC 3690	IP Telephony Requirements for Emergency Telecommunication Service (ETS)
	Authors: K. Carlberg, R. Atkinson. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within the context of IP telephony.It is an extension to the general requirements presented in RFC 3689.Solutions to these requirements are not presented in this document.
RFC 3693	Geopriv Requirements
	Authors: J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. Date: February 2004 Formats: txt pdf Updated by: RFC 6280 Status: INFORMATIONAL Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.
RFC 3694	Threat Analysis of the Geopriv Protocol
	Authors: M. Danley, D. Mulligan, J. Morris, J. Peterson. Date: February 2004 Formats: txt pdf Updated by: RFC 6280 Status: INFORMATIONAL This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements.
RFC 3696	Application Techniques for Checking and Transformation of Names
	Authors: J. Klensin. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards.
RFC 3701	6bone (IPv6 Testing Address Allocation) Phaseout
	Authors: R. Fink, R. Hinden. Date: March 2004 Formats: txt pdf Obsoletes: RFC 2471 Status: INFORMATIONAL The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",December, 1998. RFC 2471 will become historic.
RFC 3702	Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)
	Authors: J. Loughney, G. Camarillo. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL As Session Initiation Protocol (SIP) services are deployed on theInternet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work.
RFC 3706	A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
	Authors: G. Huang, S. Beaulieu, D. Rochefort. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This document describes the method detecting a dead Internet KeyExchange (IKE) peer that is presently in use by a number of vendors.The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources.
RFC 3707	Cross Registry Internet Service Protocol (CRISP) Requirements
	Authors: A. Newton. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries.
RFC 3710	An IESG charter
	Authors: H. Alvestrand. Date: February 2004 Formats: txt pdf Updated by: RFC 3932, RFC 5742 Status: INFORMATIONAL This memo provides a charter for the Internet Engineering SteeringGroup (IESG), a management function of the Internet Engineering TaskForce (IETF). It is meant to document the charter of the IESG as it is presently understood.
RFC 3712	Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
	Authors: P. Fleming, I. McDonald. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that supportLightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of InternetPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759).
RFC 3713	A Description of the Camellia Encryption Algorithm
	Authors: M. Matsui, J. Nakajima, S. Moriai. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part.
RFC 3714	IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet
	Authors: S. Floyd, J. Kempf, Eds.. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet.These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service(QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice overInternet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in theInternet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic.
RFC 3715	IPsec-Network Address Translation (NAT) Compatibility Requirements
	Authors: B. Aboba, W. Dixon. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL This document describes known incompatibilities between NetworkAddress Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment ofIPsec in one of its principal uses.
RFC 3716	The IETF in the Large: Administration and Execution
	Authors: IAB Advisory Committee. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL In the fall of 2003, the IETF Chair and the IAB Chair formed an IABAdvisory Committee (AdvComm), with a mandate to review the existingIETF administrative structure and relationships (RFC Editor, IETFSecretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF.The AdvComm mandate did not include the standards process itself. This memo documents the AdvComm's findings and proposals.
RFC 3717	IP over Optical Networks: A Framework
	Authors: B. Rajagopalan, J. Luciani, D. Awduche. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks").
RFC 3718	A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access
	Authors: R. McGowan. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This memo describes various internal workings of the UnicodeConsortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.
RFC 3719	Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)
	Authors: J. Parker, Ed.. Date: February 2004 Formats: txt pdf Status: INFORMATIONAL This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today.These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic.
RFC 3721	Internet Small Computer Systems Interface (iSCSI) Naming and Discovery
	Authors: M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document provides examples of the Internet Small ComputerSystems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document.Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.
RFC 3724	The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture
	Authors: J. Kempf, R. Austein, Eds., IAB. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL The end-to-end principle is the core architectural guideline of theInternet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends.
RFC 3726	Requirements for Signaling Protocols
	Authors: M. Brunner, Ed.. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined.For example, signaling for label distribution in Multiprotocol LabelSwitching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility.
RFC 3735	Guidelines for Extending the Extensible Provisioning Protocol (EPP)
	Authors: S. Hollenbeck. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.
RFC 3740	The Multicast Group Security Architecture
	Authors: T. Hardjono, B. Weis. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast SecurityReference Framework, and proceeds to identify the security services that may be part of a secure multicast solution.
RFC 3741	Exclusive XML Canonicalization, Version 1.0
	Authors: J. Boyer, D. Eastlake 3rd, J. Reagle. Date: March 2004 Formats: txt pdf Status: INFORMATIONAL Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the"xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization.
RFC 3743	Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean
	Authors: K. Konishi, K. Huang, H. Qian, Y. Ko. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as"IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts.
RFC 3746	Forwarding and Control Element Separation (ForCES) Framework
	Authors: L. Yang, R. Dantu, T. Anderson, R. Gopal. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document defines the architectural framework for the ForCES(Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions.
RFC 3750	Unmanaged Networks IPv6 Transition Scenarios
	Authors: C. Huitema, R. Austein, S. Satapati, R. van der Pol. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6.
RFC 3751	Omniscience Protocol Requirements
	Authors: S. Bradner. Date: April 1 2004 Formats: txt pdf Status: INFORMATIONAL There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, theOmniscience Protocol, that could be used to enable such efforts.
RFC 3752	Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
	Authors: A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses.
RFC 3753	Mobility Related Terminology
	Authors: J. Manner, Ed., M. Kojo, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in theSeamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology.
RFC 3754	IP Multicast in Differentiated Services (DS) Networks
	Authors: R. Bless, K. Wehrle. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document discusses the problems of IP Multicast use inDifferentiated Services (DS) networks, expanding on the discussion inRFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.
RFC 3756	IPv6 Neighbor Discovery (ND) Trust Models and Threats
	Authors: P. Nikander, Ed., J. Kempf, E. Nordmark. Date: May 2004 Formats: txt pdf Status: INFORMATIONAL The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsecAuthentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.
RFC 3759	RObust Header Compression (ROHC): Terminology and Channel Mapping Examples
	Authors: L-E. Jonsson. Date: April 2004 Formats: txt pdf Updates: RFC 3095 Status: INFORMATIONAL This document aims to clarify terms and concepts presented in RFC3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues.
RFC 3760	Securely Available Credentials (SACRED) - Credential Server Framework
	Authors: D. Gustafson, M. Just, M. Nystrom. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework.
RFC 3763	One-way Active Measurement Protocol (OWAMP) Requirements
	Authors: S. Shalunov, B. Teitelbaum. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol(OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss.
RFC 3765	NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
	Authors: G. Huston. Date: April 2004 Formats: txt pdf Status: INFORMATIONAL This document describes the use of a scope control Border GatewayProtocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections.
RFC 3769	Requirements for IPv6 Prefix Delegation
	Authors: S. Miyakawa, R. Droms. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site").
RFC 3773	High-Level Requirements for Internet Voice Mail
	Authors: E. Candell. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document describes the high-level requirements for InternetVoice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for InternetMail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment.This document does not include goals that were met fully by VPIM version 2.
RFC 3774	IETF Problem Statement
	Authors: E. Davies, Ed.. Date: May 2004 Formats: txt pdf Status: INFORMATIONAL This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections.
RFC 3778	The application/pdf Media Type
	Authors: E. Taft, J. Pravetz, S. Zilles, L. Masinter. Date: May 2004 Formats: txt pdf Status: INFORMATIONAL PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of thePDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'.
RFC 3783	Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI
	Authors: M. Chadalapaka, R. Elliott. Date: May 2004 Formats: txt pdf Status: INFORMATIONAL Internet Small Computer Systems Interface (iSCSI) is a Small ComputerSystems Interface (SCSI) transport protocol designed to run on top ofTCP. The iSCSI session abstraction is equivalent to the classic SCSI"I_T nexus", which represents the logical relationship between anInitiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI.
RFC 3784	Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)
	Authors: H. Smit, T. Li. Date: June 2004 Formats: txt pdf Obsoleted by: RFC 5305 Updated by: RFC 4205 Status: INFORMATIONAL This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
RFC 3786	Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit
	Authors: A. Hermelin, S. Previdi, M. Shand. Date: May 2004 Formats: txt pdf Obsoleted by: RFC 5311 Status: INFORMATIONAL This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers.
RFC 3787	Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)
	Authors: J. Parker, Ed.. Date: May 2004 Formats: txt pdf Status: INFORMATIONAL This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice.
RFC 3789	Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents
	Authors: P. Nesser, II, A. Bergstrom, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document is a general overview and introduction to the v6opsIETF workgroup project of documenting all usage of IPv4 addresses inIETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results.
RFC 3790	Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents
	Authors: C. Mickles, Ed., P. Nesser, II. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
RFC 3791	Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents
	Authors: C. Olvera, P. Nesser, II. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
RFC 3792	Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents
	Authors: P. Nesser, II, A. Bergstrom, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
RFC 3793	Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents
	Authors: P. Nesser, II, A. Bergstrom, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
RFC 3794	Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents
	Authors: P. Nesser, II, A. Bergstrom, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
RFC 3795	Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents
	Authors: R. Sofia, P. Nesser, II. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, andProposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF ApplicationArea documented Standards may experience.
RFC 3796	Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents
	Authors: P. Nesser, II, A. Bergstrom, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4Internet to an all IPv6 Internet, many interim steps will be taken.One of these steps is the evolution of current protocols that haveIPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 andIPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.
RFC 3797	Publicly Verifiable Nominations Committee (NomCom) Random Selection
	Authors: D. Eastlake 3rd. Date: June 2004 Formats: txt pdf Obsoletes: RFC 2777 Status: INFORMATIONAL This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases.
RFC 3806	Printer Finishing MIB
	Authors: R. Bergman, H. Lewis, I. McDonald. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a PrinterSystem.
RFC 3808	IANA Charset MIB
	Authors: I. McDonald. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used byIANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset RegistrationProcedures (RFC 2978).
RFC 3809	Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)
	Authors: A. Nagarajan, Ed.. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document describes generic requirements for Provider ProvisionedVirtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies.All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.
RFC 3817	Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
	Authors: W. Townsley, R. da Silva. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relayActive Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs(AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP.
RFC 3823	MIME Media Type for the Systems Biology Markup Language (SBML)
	Authors: B. Kovitz. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community.
RFC 3824	Using E.164 numbers with the Session Initiation Protocol (SIP)
	Authors: J. Peterson, H. Liu, J. Yu, B. Campbell. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations.This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number.
RFC 3827	Additional Snoop Datalink Types
	Authors: K. Sarcar. Date: June 2004 Formats: txt pdf Status: INFORMATIONAL The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media.
RFC 3829	Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls
	Authors: R. Weltman, M. Smith, M. Wahl. Date: July 2004 Formats: txt pdf Status: INFORMATIONAL This document extends the Lightweight Directory Access Protocol(LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation.
RFC 3833	Threat Analysis of the Domain Name System (DNS)
	Authors: D. Atkins, R. Austein. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.
RFC 3835	An Architecture for Open Pluggable Edge Services (OPES)
	Authors: A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service.
RFC 3836	Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
	Authors: A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL This document specifies the requirements that the OPES (OpenPluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols.
RFC 3837	Security Threats and Risks for Open Pluggable Edge Services (OPES)
	Authors: A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL The document investigates the security threats associated with theOpen Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions.
RFC 3838	Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)
	Authors: A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow.
RFC 3844	IETF Problem Resolution Process
	Authors: E. Davies, J. Hofmann, Eds.. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL This Informational document records the history of discussions in theProblem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short- term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group.
RFC 3847	Restart Signaling for Intermediate System to Intermediate System (IS-IS)
	Authors: M. Shand, L. Ginsberg. Date: July 2004 Formats: txt pdf Obsoleted by: RFC 5306 Status: INFORMATIONAL This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts.
RFC 3849	IPv6 Address Prefix Reserved for Documentation
	Authors: G. Huston, A. Lord, P. Smith. Date: July 2004 Formats: txt pdf Status: INFORMATIONAL To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation.
RFC 3867	Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)
	Authors: Y. Kawatsura, M. Hiroya, H. Beykirch. Date: November 2004 Formats: txt pdf Status: INFORMATIONAL The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores. Such interfaces exist at the Consumers', the Merchants' and thePayment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems.
RFC 3869	IAB Concerns and Recommendations Regarding Internet Research and Evolution
	Authors: R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. Date: August 2004 Formats: txt pdf Status: INFORMATIONAL This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research.
RFC 3870	application/rdf+xml Media Type Registration
	Authors: A. Swartz. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of theResource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide WebConsortium (W3C) design principles of interoperability, evolution, and decentralization.
RFC 3871	Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
	Authors: G. Jones, Ed.. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.
RFC 3874	A 224-bit One-way Hash Function: SHA-224
	Authors: R. Housley. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document specifies a 224-bit one-way hash function, calledSHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits.
RFC 3875	The Common Gateway Interface (CGI) Version 1.1
	Authors: D. Robinson, K. Coar. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. The interface has been in use by the World-Wide Web (WWW) since 1993.This specification defines the 'current practice' parameters of the'CGI/1.1' interface developed and documented at the U.S. NationalCentre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems.
RFC 3881	Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications
	Authors: G. Marshall. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data.
RFC 3882	Configuring BGP to Block Denial-of-Service Attacks
	Authors: D. Turk. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis.
RFC 3884	Use of IPsec Transport Mode for Dynamic Routing
	Authors: J. Touch, L. Eggert, Y. Wang. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of theVN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database(SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture.IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE).
RFC 3888	Message Tracking Model and Requirements
	Authors: T. Hansen. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding theInternet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions.
RFC 3897	Open Pluggable Edge Services (OPES) Entities and End Points Communication
	Authors: A. Barbir. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).
RFC 3902	The "application/soap+xml" media type
	Authors: M. Baker, M. Nottingham. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0.
RFC 3904	Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
	Authors: C. Huitema, R. Austein, S. Satapati, R. van der Pol. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document analyzes issues involved in the transition of"unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed.
RFC 3905	A Template for IETF Patent Disclosures and Licensing Declarations
	Authors: V. See, Ed.. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document describes a proposal for one form of a template forIETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668.
RFC 3906	Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels
	Authors: N. Shen, H. Smit. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by TrafficEngineering.
RFC 3914	Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
	Authors: A. Barbir, A. Rousskov. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL IETF Internet Architecture Board (IAB) expressed nine architecture- level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations.
RFC 3916	Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
	Authors: X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.. Date: September 2004 Formats: txt pdf Status: INFORMATIONAL This document describes base requirements for the Pseudo-WireEmulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, andFrame Relay. Requirements for pseudo-wire emulation of TDM (i.e.,"synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.
RFC 3917	Requirements for IP Flow Information Export (IPFIX)
	Authors: J. Quittek, T. Zseby, B. Claise, S. Zander. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.
RFC 3918	Methodology for IP Multicast Benchmarking
	Authors: D. Stopp, B. Hickman. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETFBenchmarking Methodology 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 3919	Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)
	Authors: E. Stephan, J. Palet. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895]. This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information.
RFC 3924	Cisco Architecture for Lawful Intercept in IP Networks
	Authors: F. Baker, B. Foster, C. Sharp. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country.
RFC 3930	The Protocol versus Document Points of View in Computer Protocols
	Authors: D. Eastlake 3rd. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced.
RFC 3937	A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)
	Authors: M. Steidl. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International PressTelecommunications Council (IPTC). These resources include XML DataType Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others.
RFC 3943	Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
	Authors: R. Friend. Date: November 2004 Formats: txt pdf Status: INFORMATIONAL The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol.
RFC 3944	H.350 Directory Services
	Authors: T. Johnson, S. Okubo, S. Campos. Date: December 2004 Formats: txt pdf Status: INFORMATIONAL The International Telecommunications Union Standardization Sector(ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T RecommendationsH.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version.
RFC 3954	Cisco Systems NetFlow Services Export Version 9
	Authors: B. Claise, Ed.. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This document specifies the data export format for version 9 of CiscoSystems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics.
RFC 3955	Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
	Authors: S. Leinen. Date: October 2004 Formats: txt pdf Status: INFORMATIONAL This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.
RFC 3960	Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)
	Authors: G. Camarillo, H. Schulzrinne. Date: December 2004 Formats: txt pdf Status: INFORMATIONAL This document describes how to manage early media in the SessionInitiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation.
RFC 3964	Security Considerations for 6to4
	Authors: P. Savola, C. Patel. Date: December 2004 Formats: txt pdf Status: INFORMATIONAL The IPv6 interim mechanism 6to4 (RFC3056) uses automaticIPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.
RFC 3974	SMTP Operational Experience in Mixed IPv4/v6 Environments
	Authors: M. Nakamura, J. Hagino. Date: January 2005 Formats: txt pdf Status: INFORMATIONAL This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. This document does not define any new protocol.
RFC 3975	OMA-IETF Standardization Collaboration
	Authors: G. Huston, Ed., I. Leuca, Ed.. Date: January 2005 Formats: txt pdf Status: INFORMATIONAL This document describes the standardization collaboration between theOpen Mobile Alliance (OMA) and the Internet Engineering Task Force(IETF).
RFC 3976	Interworking SIP and Intelligent Network (IN) Applications
	Authors: V. K. Gurbani, F. Haerens, V. Rastogi. Date: January 2005 Formats: txt pdf Status: INFORMATIONAL Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from SessionInitiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in thePSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP).
RFC 3985	Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
	Authors: S. Bryant, Ed., P. Pate, Ed.. Date: March 2005 Formats: txt pdf Updated by: RFC 5462 Status: INFORMATIONAL This document describes an architecture for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services such asFrame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.
RFC 3989	Middlebox Communications (MIDCOM) Protocol Semantics
	Authors: M. Stiemerling, J. Quittek, T. Taylor. Date: February 2005 Formats: txt pdf Obsoleted by: RFC 5189 Status: INFORMATIONAL This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from theMIDCOM requirements, from the MIDCOM framework, and from working group decisions.
RFC 3990	Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement
	Authors: B. O'Hara, P. Calhoun, J. Kempf. Date: February 2005 Formats: txt pdf Status: INFORMATIONAL This document describes the Configuration and Provisioning forWireless Access Points (CAPWAP) problem statement.
RFC 3991	Media Gateway Control Protocol (MGCP) Redirect and Reset Package
	Authors: B. Foster, F. Andreasen. Date: February 2005 Formats: txt pdf Status: INFORMATIONAL The base Media Gateway Control Protocol (MGCP) specification (RFC3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order.
RFC 3992	Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
	Authors: B. Foster, F. Andreasen. Date: February 2005 Formats: txt pdf Status: INFORMATIONAL A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures.
RFC 3997	Internet Printing Protocol (IPP): Requirements for IPP Notifications
	Authors: T. Hastings, Ed., R. K. deBry, H. Lewis. Date: March 2005 Formats: txt pdf Status: INFORMATIONAL This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPPService.
RFC 4009	The SEED Encryption Algorithm
	Authors: J. Park, S. Lee, J. Kim, J. Lee. Date: February 2005 Formats: txt pdf Obsoleted by: RFC 4269 Status: INFORMATIONAL This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).
RFC 4016	Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements
	Authors: M. Parthasarathy. Date: March 2005 Formats: txt pdf Status: INFORMATIONAL This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.
RFC 4017	Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs
	Authors: D. Stanley, J. Walker, B. Aboba. Date: March 2005 Formats: txt pdf Status: INFORMATIONAL The IEEE 802.11i MAC Security Enhancements Amendment makes use ofIEEE 802.1X, which in turn relies on the Extensible AuthenticationProtocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes.
RFC 4024	Voice Messaging Client Behaviour
	Authors: G. Parsons, J. Maruszak. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message.
RFC 4026	Provider Provisioned Virtual Private Network (VPN) Terminology
	Authors: L. Andersson, T. Madsen. Date: March 2005 Formats: txt pdf Status: INFORMATIONAL The widespread interest in provider-provisioned Virtual PrivateNetwork (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first ProviderProvisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive.
RFC 4027	Domain Name System Media Types
	Authors: S. Josefsson. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035.
RFC 4029	Scenarios and Analysis for Introducing IPv6 into ISP Networks
	Authors: M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. Date: March 2005 Formats: txt pdf Status: INFORMATIONAL This document describes different scenarios for the introduction ofIPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated.Known challenges are also identified.
RFC 4031	Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
	Authors: M. Carugi, Ed., D. McDysan, Ed.. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document provides requirements for Layer 3 Virtual PrivateNetworks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP- based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider.
RFC 4038	Application Aspects of IPv6 Transition
	Authors: M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. Date: March 2005 Formats: txt pdf Status: INFORMATIONAL As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to developIP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period.
RFC 4041	Requirements for Morality Sections in Routing Area Drafts
	Authors: A. Farrel. Date: April 1 2005 Formats: txt pdf Status: INFORMATIONAL It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. This document specifies a requirement for all new Routing AreaInternet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain.
RFC 4042	UTF-9 and UTF-18 Efficient Transformation Formats of Unicode
	Authors: M. Crispin. Date: April 1 2005 Formats: txt pdf Status: INFORMATIONAL ISO-10646 defines a large character set called the UniversalCharacter Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions toISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization. The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet. This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient.
RFC 4046	Multicast Security (MSEC) Group Key Management Architecture
	Authors: M. Baugher, R. Canetti, L. Dondeti, F. Lindholm. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document defines the common architecture for Multicast Security(MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.
RFC 4047	MIME Sub-type Registrations for Flexible Image Transport System (FITS)
	Authors: S. Allen, D. Wells. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible ImageTransport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS.
RFC 4048	RFC 1888 Is Obsolete
	Authors: B. Carpenter. Date: April 2005 Formats: txt pdf Obsoletes: RFC 1888 Updated by: RFC 4548 Status: INFORMATIONAL This document recommends that RFC 1888, on Open SystemsInterconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty.
RFC 4050	Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures
	Authors: S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document specifies how to use Elliptic Curve Digital SignatureAlgorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference.
RFC 4054	Impairments and Other Constraints on Optical Layer Routing
	Authors: J. Strand, Ed., A. Chiu, Ed.. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1)Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints.
RFC 4057	IPv6 Enterprise Network Scenarios
	Authors: J. Bound, Ed.. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document.
RFC 4058	Protocol for Carrying Authentication for Network Access (PANA) Requirements
	Authors: A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of theAAA infrastructure.
RFC 4059	Internet X.509 Public Key Infrastructure Warranty Certificate Extension
	Authors: D. Linsenbardt, S. Pontius, A. Sturgeon. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension.
RFC 4061	Benchmarking Basic OSPF Single Router Control Plane Convergence
	Authors: V. Manral, R. White, A. Shaikh. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance. NOTE: In this document, the word "convergence" relates to single router control plane convergence only.
RFC 4062	OSPF Benchmarking Terminology and Concepts
	Authors: V. Manral, R. White, A. Shaikh. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere(and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol.
RFC 4063	Considerations When Using Basic OSPF Convergence Benchmarks
	Authors: V. Manral, R. White, A. Shaikh. Date: April 2005 Formats: txt pdf Status: INFORMATIONAL This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested.
RFC 4074	Common Misbehavior Against DNS Queries for IPv6 Addresses
	Authors: Y. Morishita, T. Jinmei. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can blockIPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects.
RFC 4076	Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
	Authors: T. Chown, S. Venaas, A. Vijayabhaskar. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and statelessDHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.
RFC 4078	The TV-Anytime Content Reference Identifier (CRID)
	Authors: N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet. The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition. This document reproduces the TV-Anytime CRID definition found in theTV-Anytime content referencing specification, and is published as anRFC for ease of access and registration with the Internet AssignedNumbers Authority (IANA).
RFC 4079	A Presence Architecture for the Distribution of GEOPRIV Location Objects
	Authors: J. Peterson. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation ofGEOPRIV.
RFC 4080	Next Steps in Signaling (NSIS): Framework
	Authors: R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols. This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application.
RFC 4081	Security Threats for Next Steps in Signaling (NSIS)
	Authors: H. Tschofenig, D. Kroeselberg. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite.
RFC 4082	Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
	Authors: A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document introduces Timed Efficient Stream Loss-tolerantAuthentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties. This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts.
RFC 4083	Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)
	Authors: M. Garcia-Martin. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL The 3rd-Generation Partnership Project (3GPP) has selected SessionInitiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part ofRelease 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP forRelease 5 of the 3GPP IMS in cellular networks.
RFC 4089	IAB and IESG Recommendation for IETF Administrative Restructuring
	Authors: S. Hollenbeck, Ed., IAB and IESG. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a joint recommendation of the InternetArchitecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force.The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record.
RFC 4093	Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways
	Authors: F. Adrangi, Ed., H. Levkowetz, Ed.. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.
RFC 4094	Analysis of Existing Quality-of-Service Signaling Protocols
	Authors: J. Manner, X. Fu. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.
RFC 4096	Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best
	Authors: C. Malamud. Date: May 2005 Formats: txt pdf Status: INFORMATIONAL This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.
RFC 4097	Middlebox Communications (MIDCOM) Protocol Evaluation
	Authors: M. Barnes, Ed.. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document provides an evaluation of the applicability of SNMP(Simple Network Management Protocol), RSIP (Realm Specific InternetProtocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation.
RFC 4098	Terminology for Benchmarking BGP Device Convergence in the Control Plane
	Authors: H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant.
RFC 4101	Writing Protocol Models
	Authors: E. Rescorla, IAB. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system.
RFC 4105	Requirements for Inter-Area MPLS Traffic Engineering
	Authors: J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed.. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.
RFC 4110	A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
	Authors: R. Callon, M. Suzuki. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document provides a framework for Layer 3 Provider-ProvisionedVirtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.
RFC 4111	Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
	Authors: L. Fang, Ed.. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements.In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.
RFC 4115	A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
	Authors: O. Aboul-Magd, S. Rabie. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic.Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices.
RFC 4116	IPv4 Multihoming Practices and Limitations
	Authors: J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).
RFC 4117	Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
	Authors: G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document describes how to invoke transcoding services usingSession Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.
RFC 4118	Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)
	Authors: L. Yang, P. Zerfos, E. Sadot. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzingWireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.
RFC 4123	Session Initiation Protocol (SIP)-H.323 Interworking Requirements
	Authors: H. Schulzrinne, C. Agboh. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function(SIP-H.323 IWF) that will allow the interworking between SIP andH.323.
RFC 4128	Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation
	Authors: W. Lai. Date: June 2005 Formats: txt pdf Status: INFORMATIONAL "Differentiated Services (Diffserv)-aware MPLS Traffic EngineeringRequirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, theMaximum Allocation and the Russian Dolls, are described therein.This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.
RFC 4134	Examples of S/MIME Messages
	Authors: P. Hoffman, Ed.. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document gives examples of message bodies formatted usingS/MIME. Specifically, it has examples of Cryptographic MessageSyntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability forS/MIME and other protocols that rely on CMS.
RFC 4135	Goals of Detecting Network Attachment in IPv6
	Authors: JH. Choi, G. Daley. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment(DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.
RFC 4136	OSPF Refresh and Flooding Reduction in Stable Topologies
	Authors: P. Pillay-Esnault. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies. Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies.
RFC 4137	State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator
	Authors: J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a set of state machines for ExtensibleAuthentication Protocol (EAP) peer, EAP stand-alone authenticator(non-pass-through), EAP backend authenticator (for use onAuthentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative. The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAPSwitch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section. The state machine and associated model are informative only.Implementations may achieve the same results using different methods.
RFC 4139	Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)
	Authors: D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong. Date: July 2005 Formats: txt pdf Status: INFORMATIONAL The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, includingSynchronous Optical Network (SONET)/Synchronous Digital Hierarchy(SDH) and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by theGMPLS signaling protocol to support the capabilities of anAutomatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for theGMPLS signaling protocol to support the ASON functionality.
RFC 4144	How to Gain Prominence and Influence in Standards Organizations
	Authors: D. Eastlake 3rd. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations.
RFC 4146	Simple New Mail Notification
	Authors: R. Gellens. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client. In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail.
RFC 4147	Proposed Changes to the Format of the IANA IPv6 Registry
	Authors: G. Huston. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format.The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format.
RFC 4151	The 'tag' URI Scheme
	Authors: T. Kindberg, S. Hawke. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.
RFC 4152	A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code
	Authors: K. Tesink, R. Fox. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace(RFC 3406) for the assignment of the Common Language EquipmentIdentifier (CLEI) code, which is used in messages standardized byANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. TheCLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number).
RFC 4153	XML Voucher: Generic Voucher Language
	Authors: K. Fujimura, M. Terada, D. Eastlake 3rd. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions.
RFC 4154	Voucher Trading System Application Programming Interface (VTS-API)
	Authors: M. Terada, K. Fujimura. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This document specifies the Voucher Trading System ApplicationProgramming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions.
RFC 4155	The application/mbox Media Type
	Authors: E. Hall. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.
RFC 4158	Internet X.509 Public Key Infrastructure: Certification Path Building
	Authors: M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.
RFC 4160	Internet Fax Gateway Requirements
	Authors: K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet FaxGateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN.
RFC 4161	Guidelines for Optional Services for Internet Fax Gateways
	Authors: K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality ofInternet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN. This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways.
RFC 4163	RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression
	Authors: L-E. Jonsson. Date: August 2005 Formats: txt pdf Status: INFORMATIONAL This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression(ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.
RFC 4166	Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement
	Authors: L. Coene, J. Pastor-Balbas. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control TransmissionProtocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.
RFC 4167	Graceful OSPF Restart Implementation Report
	Authors: A. Lindem. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol.
RFC 4169	Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2
	Authors: V. Torvinen, J. Arkko, M. Naslund. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack.
RFC 4176	Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management
	Authors: Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document.
RFC 4177	Architectural Approaches to Multi-homing for IPv6
	Authors: G. Huston. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.
RFC 4179	Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)
	Authors: S. Kang. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA.
RFC 4180	Common Format and MIME Type for Comma-Separated Values (CSV) Files
	Authors: Y. Shafranovich. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv".
RFC 4183	A Suggested Scheme for DNS Resolution of Networks and Gateways
	Authors: E. Warnicke. Date: September 2005 Formats: txt pdf Status: INFORMATIONAL This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.
RFC 4185	National and Local Characters for DNS Top Level Domain (TLD) Names
	Authors: J. Klensin. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL In the context of work on internationalizing the Domain Name System(DNS), there have been extensive discussions about "multilingual" or"internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country.
RFC 4186	Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
	Authors: H. Haverinen, Ed., J. Salowey, Ed.. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using theGlobal System for Mobile Communications (GSM) Subscriber IdentityModule (SIM). GSM is a second generation mobile network standard.The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure.
RFC 4187	Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
	Authors: J. Arkko, H. Haverinen. Date: January 2006 Formats: txt pdf Updated by: RFC 5448 Status: INFORMATIONAL This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal MobileTelecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable)User Identity Module, (R)UIM, similar to a smart card. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure.
RFC 4189	Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
	Authors: K. Ono, S. Tachimoto. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security.
RFC 4190	Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
	Authors: K. Carlberg, I. Brown, C. Beard. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony.We present a series of objectives that reflect a general view of how authorized emergency service, in line with the EmergencyTelecommunications Service (ETS), should be realized within today'sIP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existingIETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.
RFC 4192	Procedures for Renumbering an IPv6 Network without a Flag Day
	Authors: F. Baker, E. Lear, R. Droms. Date: September 2005 Formats: txt pdf Updates: RFC 2072 Status: INFORMATIONAL This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.
RFC 4195	A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum
	Authors: W. Kameyama. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime ForumStandards, XML (Extensible Markup Language) Document TypeDefinitions, XML Schemas, Namespaces, and other documents.
RFC 4197	Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
	Authors: M. Riegel, Ed.. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.
RFC 4198	A Uniform Resource Name (URN) Namespace for Federated Content
	Authors: D. Tessman. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections.A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members.
RFC 4205	Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
	Authors: K. Kompella, Ed., Y. Rekhter, Ed.. Date: October 2005 Formats: txt pdf Obsoleted by: RFC 5307 Updates: RFC 3784 Status: INFORMATIONAL This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS).
RFC 4212	Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols
	Authors: M. Blinov, C. Adams. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL The Public-Key Infrastructure using X.509 (PKIX) Working Group of theInternet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well.This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and CertificateManagement Messages over CMS (CMC).
RFC 4215	Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks
	Authors: J. Wiljakka, Ed.. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document analyzes the transition to IPv6 in Third GenerationPartnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for MobileCommunications (GSM) or Universal Mobile Telecommunications System(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.
RFC 4216	MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
	Authors: R. Zhang, Ed., J.-P. Vasseur, Ed.. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document discusses requirements for the support of inter-AS MPLSTraffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios.
RFC 4218	Threats Relating to IPv6 Multihoming Solutions
	Authors: E. Nordmark, T. Li. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document lists security threats related to IPv6 multihoming.Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to allIPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.
RFC 4219	Things Multihoming in IPv6 (MULTI6) Developers Should Think About
	Authors: E. Lear. Date: October 2005 Formats: txt pdf Status: INFORMATIONAL This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6.The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.
RFC 4221	Multiprotocol Label Switching (MPLS) Management Overview
	Authors: T. Nadeau, C. Srinivasan, A. Farrel. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management.
RFC 4223	Reclassification of RFC 1863 to Historic
	Authors: P. Savola. Date: October 2005 Formats: txt pdf Obsoletes: RFC 1863 Status: INFORMATIONAL This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletesRFC 1863.
RFC 4224	RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets
	Authors: G. Pelletier, L-E. Jonsson, K. Sandlund. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols(profiles). One operating assumption for the profiles defined in RFC3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles.
RFC 4225	Mobile IP Version 6 Route Optimization Security Design Background
	Authors: P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document is an account of the rationale behind the Mobile IPv6(MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002. The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs.
RFC 4226	HOTP: An HMAC-Based One-Time Password Algorithm
	Authors: D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network(VPN) access, Wi-Fi network logon to transaction-oriented Web applications. This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations.
RFC 4228	Requirements for an IETF Draft Submission Toolset
	Authors: A. Rousskov. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.
RFC 4229	HTTP Header Field Registrations
	Authors: M. Nottingham, J. Mogul. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864.
RFC 4230	RSVP Security Properties
	Authors: H. Tschofenig, R. Graveman. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.
RFC 4240	Basic Network Media Services with SIP
	Authors: E. Burger, Ed., J. Van Dyke, A. Spitzer. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner. This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.
RFC 4241	A Model of IPv6/IPv4 Dual Stack Internet Access Service
	Authors: Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This memo is a digest of the user network interface specification ofNTT Communications' dual stack ADSL access service, which provide aIPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses ofIPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.
RFC 4245	High-Level Requirements for Tightly Coupled SIP Conferencing
	Authors: O. Levin, R. Even. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications.
RFC 4246	International Standard Audiovisual Number (ISAN) URN Definition
	Authors: M. Dolan. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formalUniform Resource Name (URN) Namespace Identifier (NID) for ISAN.
RFC 4247	Requirements for Header Compression over MPLS
	Authors: J. Ash, B. Goode, J. Hand, R. Zhang. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS LabelSwitched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario.
RFC 4249	Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components
	Authors: B. Lilly. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer.This memo identifies information useful to implementers of header field generators and parsers.
RFC 4257	Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks
	Authors: G. Bernstein, E. Mannie, V. Sharma, E. Gray. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks.This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous DigitalHierarchy (SDH) or Synchronous Optical Networking (SONET) networks.SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed.
RFC 4258	Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)
	Authors: D. Brungard, Ed.. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous DigitalHierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on theGMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T.
RFC 4259	A Framework for Transmission of IP Datagrams over MPEG-2 Networks
	Authors: M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document describes an architecture for the transport of IPDatagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) andAdvanced Television Systems Committee (ATSC) Standards for DigitalTelevision. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS.
RFC 4260	Mobile IPv6 Fast Handovers for 802.11 Networks
	Authors: P. McCann. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications.
RFC 4263	Media Subtype Registration for Media Type text/troff
	Authors: B. Lilly. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described.
RFC 4264	BGP Wedgies
	Authors: T. Griffin, G. Huston. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state whereBGP converges may be selected by BGP in a non-deterministic manner.These stable, but unintended, BGP states are termed here "BGPWedgies".
RFC 4267	The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml
	Authors: M. Froumentin. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL This document defines the media types for the languages of the W3CSpeech Interface Framework, as designed by the Voice Browser WorkingGroup in the following specifications: the Voice Extensible MarkupLanguage (VoiceXML), the Speech Synthesis Markup Language (SSML), theSpeech Recognition Grammar Specification (SRGS), the Call Control XML(CCXML), and the Pronunciation Lexicon Specification (PLS).
RFC 4269	The SEED Encryption Algorithm
	Authors: H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee. Date: December 2005 Formats: txt pdf Obsoletes: RFC 4009 Status: INFORMATIONAL This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This document obsoletes RFC 4009.
RFC 4270	Attacks on Cryptographic Hashes in Internet Protocols
	Authors: P. Hoffman, B. Schneier. Date: November 2005 Formats: txt pdf Status: INFORMATIONAL Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers.
RFC 4272	BGP Security Vulnerabilities Analysis
	Authors: S. Murphy. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets.
RFC 4274	BGP-4 Protocol Analysis
	Authors: D. Meyer, K. Patel. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance.
RFC 4275	BGP-4 MIB Implementation Survey
	Authors: S. Hares, D. Hares. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification.
RFC 4276	BGP-4 Implementation Report
	Authors: S. Hares, A. Retana. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document reports the results of the BGP-4 implementation survey.The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, andNextHop) and brief information from three that did not (Avici, DataConnection Ltd., and Nokia). The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on.
RFC 4277	Experience with the BGP-4 Protocol
	Authors: D. McPherson, K. Patel. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted forStandard.
RFC 4278	Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification
	Authors: S. Bellovin, A. Zinin. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection ofBGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level.
RFC 4284	Identity Selection Hints for the Extensible Authentication Protocol (EAP)
	Authors: F. Adrangi, V. Lortz, F. Bari, P. Eronen. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL The Extensible Authentication Protocol (EAP) is defined in RFC 3748.This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier(NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker. The mechanism defined in this document is limited in its scalability.It is intended for access networks that have a small to moderate number of direct roaming partners.
RFC 4285	Authentication Protocol for Mobile IPv6
	Authors: A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between aMobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes andHome Agents. The alternate method defined here consists of aMIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.
RFC 4290	Suggested Practices for Registration of Internationalized Domain Names (IDN)
	Authors: J. Klensin. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar- looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed forChinese, Japanese, and Korean domain names.
RFC 4294	IPv6 Node Requirements
	Authors: J. Loughney, Ed.. Date: April 2006 Formats: txt pdf Obsoleted by: RFC 6434 Updated by: RFC 5095 Status: INFORMATIONAL This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
RFC 4296	The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols
	Authors: S. Bailey, T. Talpey. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document defines an abstract architecture for Direct DataPlacement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements.
RFC 4297	Remote Direct Memory Access (RDMA) over IP Problem Statement
	Authors: A. Romanow, J. Mogul, T. Talpey, S. Bailey. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL Overhead due to the movement of user data in the end-system networkI/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and theInternet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application. This document examines this overhead, and addresses an architectural,IP-based "copy avoidance" solution for its elimination, by enablingRemote Direct Memory Access (RDMA).
RFC 4313	Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources
	Authors: D. Oran. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and RealTime Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address.
RFC 4317	Session Description Protocol (SDP) Offer/Answer Examples
	Authors: A. Johnston, R. Sparks. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. CommonThird Party Call Control (3pcc) examples are also given.
RFC 4321	Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
	Authors: R. Sparks. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.
RFC 4322	Opportunistic Encryption using the Internet Key Exchange (IKE)
	Authors: M. Richardson, D.H. Redelmeier. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet KeyExchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance.
RFC 4329	Scripting Media Types
	Authors: B. Hoehrmann. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.
RFC 4330	Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
	Authors: D. Mills. Date: January 2006 Formats: txt pdf Obsoletes: RFC 2030, RFC 1769 Obsoleted by: RFC 5905 Status: INFORMATIONAL This memorandum describes the Simple Network Time Protocol Version 4(SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based onRFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that 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 1769, which describes SNTP Version 3(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) andSNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation ofSNTP.
RFC 4332	Cisco's Mobile IPv4 Host Configuration Extensions
	Authors: K. Leung, A. Patel, G. Tsirtsis, E. Klovning. Date: December 2005 Formats: txt pdf Status: INFORMATIONAL An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host ConfigurationProtocol (DHCP) or Point-to-Point Protocol/IP Control Protocol(PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages.
RFC 4336	Problem Statement for the Datagram Congestion Control Protocol (DCCP)
	Authors: S. Floyd, M. Handley, E. Kohler. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.
RFC 4339	IPv6 Host Configuration of DNS Server Information Approaches
	Authors: J. Jeong, Ed.. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise,3GPP, and unmanaged networks) considering multi-solution resolution.
RFC 4350	A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government
	Authors: F. Hendrikx, C. Wallis. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) NamespaceIdentification (NID)convention as prescribed by the World Wide WebConsortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New ZealandGovernment.
RFC 4353	A Framework for Conferencing with the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents.These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing.
RFC 4354	A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service
	Authors: M. Garcia-Martin. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL The Open Mobile Alliance (OMA) is defining the Push-to-talk overCellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet.
RFC 4357	Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms
	Authors: V. Popov, I. Kurepkin, S. Leontiev. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89,GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use inInternet applications.
RFC 4358	A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)
	Authors: D. Smith. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the Open MobileAlliance (OMA). OMA defines and manages resources that utilize thisURN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA).
RFC 4365	Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)
	Authors: E. Rosen. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document provides an Applicability Statement for the VirtualPrivate Network (VPN) solution described in RFC 4364 and other documents listed in the References section.
RFC 4367	What's in a Name: False Assumptions about DNS Names
	Authors: J. Rosenberg, Ed., IAB. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL The Domain Name System (DNS) provides an essential service on theInternet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform ResourceIdentifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided.
RFC 4373	Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)
	Authors: R. Harrison, J. Sermersheim, Y. Dong. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL The Lightweight Directory Access Protocol (LDAP) BulkUpdate/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication. The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server.
RFC 4374	The application/xv+xml Media Type
	Authors: G. McCobb. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents.
RFC 4375	Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain
	Authors: K. Carlberg. Date: January 2006 Formats: txt pdf Status: INFORMATIONAL This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document.
RFC 4376	Requirements for Floor Control Protocols
	Authors: P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.
RFC 4377	Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks
	Authors: T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.
RFC 4378	A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)
	Authors: D. Allan, Ed., T. Nadeau, Ed.. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-ProtocolLabel Switching (MPLS). The document is structured to outline howOperations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.
RFC 4381	Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)
	Authors: M. Behringer. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users. The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode(ATM) or Frame Relay.
RFC 4392	IP over InfiniBand (IPoIB) Architecture
	Authors: V. Kashyap. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL InfiniBand is a high-speed, channel-based interconnect between systems and devices. This document presents an overview of the InfiniBand architecture.It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents.
RFC 4394	A Transport Network View of the Link Management Protocol (LMP)
	Authors: D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL The Link Management Protocol (LMP) has been developed as part of theGeneralized MPLS (GMPLS) protocol suite to manage Traffic Engineering(TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths(LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International TelecommunicationUnion (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically SwitchedOptical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.
RFC 4397	A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture
	Authors: I. Bryskin, A. Farrel. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths(LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context.
RFC 4403	Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)
	Authors: B. Bergeson, K. Boogert, V. Nanjundaswamy. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document defines the Lightweight Directory Access Protocol(LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory.
RFC 4413	TCP/IP Field Behavior
	Authors: M. West, S. McCann. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers.
RFC 4416	Goals for Internet Messaging to Support Diverse Service Environments
	Authors: J. Wong, Ed.. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process. The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements toInternet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail. The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments-- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols. The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed.
RFC 4417	Report of the 2004 IAB Messaging Workshop
	Authors: P. Resnick, Ed., P. Saint-Andre, Ed.. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB.
RFC 4418	UMAC: Message Authentication Code using Universal Hashing
	Authors: T. Krovetz, Ed.. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors.Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material.
RFC 4423	Host Identity Protocol (HIP) Architecture
	Authors: R. Moskowitz, P. Nikander. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, theHost Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since.This document represents one stable point in that evolution of understanding.
RFC 4427	Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)
	Authors: E. Mannie, Ed., D. Papadimitriou, Ed.. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS.
RFC 4428	Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)
	Authors: D. Papadimitriou, Ed., E. Mannie, Ed.. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects.
RFC 4431	The DNSSEC Lookaside Validation (DLV) DNS Resource Record
	Authors: M. Andrews, S. Weiler. Date: February 2006 Formats: txt pdf Status: INFORMATIONAL This document defines a new DNS resource record, called the DNSSECLookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain.
RFC 4435	A Framework for the Usage of Internet Media Guides (IMGs)
	Authors: Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document defines a framework for the delivery of Internet MediaGuides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol(SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.
RFC 4440	IAB Thoughts on the Role of the Internet Research Task Force (IRTF)
	Authors: S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of theIRTF.
RFC 4441	The IEEE 802/IETF Relationship
	Authors: B. Aboba, Ed.. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs andAuthentication, Authorization, and Accounting (AAA) applications.This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.
RFC 4445	A Proposed Media Delivery Index (MDI)
	Authors: J. Welch, J. Clark. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media,MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. The MDI measurement defined in this memo is intended for Information only.
RFC 4450	Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents
	Authors: E. Lear, H. Alvestrand. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL This memo documents an experiment to review and classify ProposedStandards as not reflecting documented practice within the world today. The results identify a set of documents that were marked asProposed Standards that are now reclassified as Historic.
RFC 4451	BGP MULTI_EXIT_DISC (MED) Considerations
	Authors: D. McPherson, V. Gill. Date: March 2006 Formats: txt pdf Status: INFORMATIONAL The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies. This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar.
RFC 4452	The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces
	Authors: H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces.Namespaces participating in the "info" URI scheme are regulated by an"info" Registry mechanism.
RFC 4453	Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, G. Camarillo, Ed., D. Willis. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks.This document identifies a set of requirements for extensions to SIP that add consent-based communications.
RFC 4457	The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)
	Authors: G. Camarillo, G. Blanco. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document specifies the Session Initiation Protocol (SIP)P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request.
RFC 4458	Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
	Authors: C. Jennings, F. Audet, J. Elwell. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
RFC 4459	MTU and Fragmentation Issues with In-the-Network Tunneling
	Authors: P. Savola. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided.This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length.
RFC 4460	Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
	Authors: R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied.In addition to the delta, a description of the problem and the details of the solution are also provided.
RFC 4461	Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)
	Authors: S. Yasukawa, Ed.. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE)Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). There is no intent to specify solution-specific details or application-specific requirements in this document. The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), TimeDivision Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS.
RFC 4463	A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks
	Authors: S. Shanmugham, P. Monaco, B. Eberman. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for furtherIETF development in this area. MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (SessionInitiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms likeRTP (Real Time Protocol).
RFC 4464	Signaling Compression (SigComp) Users' Guide
	Authors: A. Surtees, M. West. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This document provides an informational guide for users of theSignaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.
RFC 4465	Signaling Compression (SigComp) Torture Tests
	Authors: A. Surtees, M. West. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler.
RFC 4472	Operational Considerations and Issues with IPv6 DNS
	Authors: A. Durand, J. Ihren, P. Savola. Date: April 2006 Formats: txt pdf Status: INFORMATIONAL This memo presents operational considerations and issues with IPv6Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.
RFC 4473	Requirements for Internet Media Guides (IMGs)
	Authors: Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery.
RFC 4475	Session Initiation Protocol (SIP) Torture Test Messages
	Authors: R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This informational document gives examples of Session InitiationProtocol (SIP) test messages designed to exercise and "torture" a SIP implementation.
RFC 4477	Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues
	Authors: T. Chown, S. Venaas, C. Strauf. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol(DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken.
RFC 4484	Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)
	Authors: J. Peterson, J. Polk, D. Sicker, H. Tschofenig. Date: August 2006 Formats: txt pdf Status: INFORMATIONAL This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.
RFC 4485	Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, H. Schulzrinne. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across theInternet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions.
RFC 4487	Mobile IPv6 and Firewalls: Problem Statement
	Authors: F. Le, S. Faccin, B. Patil, H. Tschofenig. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This document captures the issues that may arise in the deployment ofIPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such asGeneral Packet Radio Service / Universal Mobile TelecommunicationsSystem (GPRS/UMTS) and CDMA2000 networks. The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions.
RFC 4492	Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
	Authors: S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller. Date: May 2006 Formats: txt pdf Updated by: RFC 5246 Status: INFORMATIONAL This document describes new key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use ofElliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism.
RFC 4493	The AES-CMAC Algorithm
	Authors: JH. Song, R. Poovendran, J. Lee, T. Iwata. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard(AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community.
RFC 4496	Open Pluggable Edge Services (OPES) SMTP Use Cases
	Authors: M. Stecher, A. Barbir. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES.
RFC 4503	A Description of the Rabbit Stream Cipher Algorithm
	Authors: M. Boesgaard, M. Vesterager, E. Zenner. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed.
RFC 4504	SIP Telephony Device Requirements and Configuration
	Authors: H. Sinnreich, Ed., S. Lass, C. Stredicke. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones andPC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings.
RFC 4525	Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension
	Authors: K. Zeilenga. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL This document describes an extension to the Lightweight DirectoryAccess Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre- read or post-read control extension.
RFC 4529	Requesting Attributes by Object Class in the Lightweight Directory Access Protocol
	Authors: K. Zeilenga. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class.
RFC 4536	The application/smil and application/smil+xml Media Types
	Authors: P. Hoschka. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation.
RFC 4539	Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)
	Authors: T. Edwards. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This document serves to register a media type for the Society ofMotion Picture and Television Engineers (SMPTE) Material ExchangeFormat (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata.
RFC 4541	Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
	Authors: M. Christensen, K. Kimball, F. Solensky. Date: May 2006 Formats: txt pdf Status: INFORMATIONAL This memo describes the recommendations for Internet Group ManagementProtocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes andEthernet-specific encapsulation issues, are also considered.
RFC 4542	Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
	Authors: F. Baker, J. Polk. Date: May 2006 Formats: txt pdf Updated by: RFC 5865 Status: INFORMATIONAL RFCs 3689 and 3690 detail requirements for an EmergencyTelecommunications Service (ETS), of which an Internet EmergencyPreparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-LevelPrecedence and Preemption (MLPP) and Government EmergencyTelecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations.
RFC 4549	Synchronization Operations for Disconnected IMAP4 Clients
	Authors: A. Melnikov, Ed.. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy. This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process. This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients.
RFC 4554	Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks
	Authors: T. Chown. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how suchVLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link.
RFC 4559	SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
	Authors: K. Jaganathan, L. Zhu, J. Brezak. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in MicrosoftWindows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of"negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple AndProtected Negotiate (SPNEGO) implementation are not provided in this document.
RFC 4562	MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network
	Authors: T. Melsen, S. Blake. Date: June 2006 Formats: txt pdf Status: INFORMATIONAL This document describes a mechanism to ensure layer-2 separation ofLocal Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment. The mechanism - called "MAC-Forced Forwarding" - implements anAddress Resolution Protocol (ARP) proxy function that prohibitsEthernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts.
RFC 4564	Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)
	Authors: S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability amongWireless Local Area Network (WLAN) devices of alternative designs.
RFC 4565	Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols
	Authors: D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26,2005.
RFC 4569	Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag
	Authors: G. Camarillo. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features.
RFC 4578	Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)
	Authors: M. Johnston, S. Venaas, Ed.. Date: November 2006 Formats: txt pdf Status: INFORMATIONAL We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible FirmwareInterface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client.
RFC 4584	Extension to Sockets API for Mobile IPv6
	Authors: S. Chakrabarti, E. Nordmark. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document describes data structures and API support for MobileIPv6 as an extension to the Advanced Socket API for IPv6. Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information forMobility Header messages, Home Address destination options, andRouting Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications.
RFC 4586	Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations
	Authors: C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time TransportControl Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic.
RFC 4593	Generic Threats to Routing Protocols
	Authors: A. Barbir, S. Murphy, Y. Yang. Date: October 2006 Formats: txt pdf Status: INFORMATIONAL Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately.
RFC 4594	Configuration Guidelines for DiffServ Service Classes
	Authors: J. Babiarz, K. Chan, F. Baker. Date: August 2006 Formats: txt pdf Updated by: RFC 5865 Status: INFORMATIONAL This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them usingDifferentiated Services Code Points (DSCPs), traffic conditioners,Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.
RFC 4595	Use of IKEv2 in the Fibre Channel Security Association Management Protocol
	Authors: F. Maino, D. Black. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the FibreChannel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies theseIKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel.
RFC 4596	Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension
	Authors: J. Rosenberg, P. Kyzivat. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document contains guidelines for usage of the Caller PreferencesExtension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.
RFC 4597	Conferencing Scenarios
	Authors: R. Even, N. Ismail. Date: August 2006 Formats: txt pdf Status: INFORMATIONAL This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group.
RFC 4602	Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis
	Authors: T. Pusateri. Date: August 2006 Formats: txt pdf Status: INFORMATIONAL This document provides supporting documentation to advance theProtocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard.
RFC 4603	Additional Values for the NAS-Port-Type Attribute
	Authors: G. Zorn, G. Weber, R. Foltak. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL This document defines a set of values for the NAS-Port-Type RADIUSAttribute.
RFC 4609	Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements
	Authors: P. Savola, R. Lehtonen, D. Meyer. Date: October 2006 Formats: txt pdf Status: INFORMATIONAL This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only ProtocolIndependent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast(ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats.
RFC 4613	Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI)
	Authors: P. Frojdh, U. Lindgren, M. Westerlund. Date: September 2006 Formats: txt pdf Status: INFORMATIONAL This document serves to register a media type for DownloadableSounds.
RFC 4614	A Roadmap for Transmission Control Protocol (TCP) Specification Documents
	Authors: M. Duke, R. Braden, W. Eddy, E. Blanton. Date: September 2006 Formats: txt pdf Updated by: RFC 6247 Status: INFORMATIONAL This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.
RFC 4617	A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project
	Authors: J. Kornijenko. Date: August 2006 Formats: txt pdf Status: INFORMATIONAL This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian NationalGovernment Integration Project (Latvian abbreviation IVIS).
RFC 4621	Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
	Authors: T. Kivinen, H. Tschofenig. Date: August 2006 Formats: txt pdf Status: INFORMATIONAL The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsecSecurity Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded.
RFC 4627	The application/json Media Type for JavaScript Object Notation (JSON)
	Authors: D. Crockford. Date: July 2006 Formats: txt pdf Status: INFORMATIONAL JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
RFC 4628	RTP Payload Format for H.263 Moving RFC 2190 to Historic Status
	Authors: R. Even. Date: January 2007 Formats: txt pdf Status: INFORMATIONAL The first RFC that describes RTP payload format for ITUTelecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status.
RFC 4634	US Secure Hash Algorithms (SHA and HMAC-SHA)