Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Documents

RFCs 1700 - 1799s

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

 
RFC 1700 Assigned Numbers
 
Authors:J. Reynolds, J. Postel.
Date:October 1994
Formats:txt pdf
Obsoletes:RFC 1340
Obsoleted by:RFC 3232
Status:HISTORIC
DOI:10.17487/RFC 1700
This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.
 
RFC 1701 Generic Routing Encapsulation (GRE)
 
Authors:S. Hanks, T. Li, D. Farinacci, P. Traina.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1701
This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
 
RFC 1702 Generic Routing Encapsulation over IPv4 networks
 
Authors:S. Hanks, T. Li, D. Farinacci, P. Traina.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1702
This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures
 
Authors:M. Rose.
Date:October 1994
Formats:txt pdf
Obsoletes:RFC 1569
Status:INFORMATIONAL
DOI:10.17487/RFC 1703
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1704 On Internet Authentication
 
Authors:N. Haller, R. Atkinson.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1704
This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1705 Six Virtual Inches to the Left: The Problem with IPng
 
Authors:R. Carlson, D. Ficarella.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1705
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
 
RFC 1706 DNS NSAP Resource Records
 
Authors:B. Manning, R. Colella.
Date:October 1994
Formats:txt pdf
Obsoletes:RFC 1637
Status:INFORMATIONAL
DOI:10.17487/RFC 1706
OSI lower layer protocols, comprising the connectionless network protocol (CLNP) and supporting routing protocols, are deployed in some parts of the global Internet. Maintenance and debugging of CLNP connectivity is greatly aided by support in the Domain Name System(DNS) for mapping between names and NSAP addresses.

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

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

This document obsoletes RFC 1348 and RFC 1637.

 
RFC 1707 CATNIP: Common Architecture for the Internet
 
Authors:M. McGovern, R. Ullmann.
Date:October 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1707
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
DOI:10.17487/RFC 1708
This RFC describes a PICS Proforma translated into an Internet acceptable form. The Original document was developed according toISO 9646 for conformance test purposes. This document is intended for both developers and users of the NTP (Network Time Protocol).This document contains specific information and performance characteristics for the use of NTP within the context of Internet usage. It is suggested, that users wishing to use the synchronization capabilities of the Internet abide by the characteristics set within this document.

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

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

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

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

 
RFC 1712 DNS Encoding of Geographical Location
 
Authors:C. Farrell, M. Schulze, S. Pleitner, D. Baldoni.
Date:November 1994
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1712
This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This definition deals with associating geographical host location mappings to host names within a domain.The data shown in this document is fictitious and does not necessarily reflect the real Internet.
 
RFC 1713 Tools for DNS debugging
 
Authors:A. Romao.
Date:November 1994
Formats:txt pdf
Also:FYI 0027
Status:INFORMATIONAL
DOI:10.17487/RFC 1713
Although widely used (and most of the times unnoticed), DNS (DomainName System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work.This document presents some tools available for domain administrators to detect and correct those anomalies.
 
RFC 1714 Referral Whois Protocol (RWhois)
 
Authors:S. Williamson, M. Kosters.
Date:November 1994
Formats:txt ps pdf
Obsoleted by:RFC 2167
Status:INFORMATIONAL
DOI:10.17487/RFC 1714
This memo describes version 1.0 of the client/server interaction ofRWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information.
 
RFC 1715 The H Ratio for Address Assignment Efficiency
 
Authors:C. Huitema.
Date:November 1994
Formats:txt pdf
Updated by:RFC 3194
Status:INFORMATIONAL
DOI:10.17487/RFC 1715
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list.
 
RFC 1716 Towards Requirements for IP Routers
 
Authors:P. Almquist, F. Kastenholz.
Date:November 1994
Formats:txt pdf
Obsoleted by:RFC 1812
Status:INFORMATIONAL
DOI:10.17487/RFC 1716
The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1717 The PPP Multilink Protocol (MP)
 
Authors:K. Sklower, B. Lloyd, G. McGregor, D. Carr.
Date:November 1994
Formats:txt pdf
Obsoleted by:RFC 1990
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1717
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.
 
RFC 1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force
 
Authors:IETF Secretariat, G. Malkin.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1539
Obsoleted by:RFC 3160
Status:INFORMATIONAL
DOI:10.17487/RFC 1718
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) plenary meetings has grown phenomenally. Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.

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

 
RFC 1719 A Direction for IPng
 
Authors:P. Gross.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1719
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
 
RFC 1720 Internet Official Protocol Standards
 
Authors:J. Postel.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1610
Obsoleted by:RFC 1780
Status:HISTORIC
DOI:10.17487/RFC 1720
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1721 RIP Version 2 Protocol Analysis
 
Authors:G. Malkin.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1387
Status:INFORMATIONAL
DOI:10.17487/RFC 1721
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track.
 
RFC 1722 RIP Version 2 Protocol Applicability Statement
 
Authors:G. Malkin.
Date:November 1994
Formats:txt pdf
Also:STD 0057
Status:INTERNET STANDARD
DOI:10.17487/RFC 1722
As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet.This report is a prerequisite to advancing RIP-2 on the standards track.
 
RFC 1723 RIP Version 2 - Carrying Additional Information
 
Authors:G. Malkin.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1388
Obsoleted by:RFC 2453
Updates:RFC 1058
Status:INTERNET STANDARD
DOI:10.17487/RFC 1723
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1,2], to expand the amount of useful information carried in RIP messages and to add a measure of security.This memo obsoletes RFC 1388, which specifies an update to the"Routing Information Protocol" STD 34, RFC 1058.

The RIP-2 protocol analysis is documented in RFC 1721 [4].

The RIP-2 applicability statement is document in RFC 1722 [5].

The RIP-2 MIB description is defined in RFC 1724 [3]. This memo obsoletes RFC 1389.

 
RFC 1724 RIP Version 2 MIB Extension
 
Authors:G. Malkin, F. Baker.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1389
Status:DRAFT STANDARD
DOI:10.17487/RFC 1724
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing RIP Version 2.
 
RFC 1725 Post Office Protocol - Version 3
 
Authors:J. Myers, M. Rose.
Date:November 1994
Formats:txt pdf
Obsoletes:RFC 1460
Obsoleted by:RFC 1939
Status:INTERNET STANDARD
DOI:10.17487/RFC 1725
This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]
 
RFC 1726 Technical Criteria for Choosing IP The Next Generation (IPng)
 
Authors:C. Partridge, F. Kastenholz.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1726
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
 
RFC 1727 A Vision of an Integrated Internet Information Service
 
Authors:C. Weider, P. Deutsch.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1727
This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration.
 
RFC 1728 Resource Transponders
 
Authors:C. Weider.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1728
Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand. This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information.
 
RFC 1729 Using the Z39.50 Information Retrieval Protocol
 
Authors:C. Lynch.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1729
This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1730 Internet Message Access Protocol - Version 4
 
Authors:M. Crispin.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 2060, RFC 2061
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1730
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.IMAP4 permits manipulation of remote message folders, called"mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).

IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers.These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous).

IMAP4 supports a single server. A mechanism for supporting multipleIMAP4 servers is discussed in [IMSP].

IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].

IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.Compatibility issues are discussed in [IMAP-COMPAT].

 
RFC 1731 IMAP4 Authentication Mechanisms
 
Authors:J. Myers.
Date:December 1994
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1731
The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]
 
RFC 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis
 
Authors:M. Crispin.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1732
This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1733 Distributed Electronic Mail Models in IMAP4
 
Authors:M. Crispin.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1733
There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1734 POP3 AUTHentication command
 
Authors:J. Myers.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 5034
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1734
This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]
 
RFC 1735 NBMA Address Resolution Protocol (NARP)
 
Authors:J. Heinanen, R. Govindan.
Date:December 1994
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1735
This document describes the NBMA Address Resolution Protocol (NARP).NARP can be used by a source terminal (host or router) connected to aNon-Broadcast, Multi-Access link layer (NBMA) network to find out theNBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. Although this document focuses on NARP in the context of IP, the technique is applicable to other network layer protocols as well. This RFC is a product of the Routing over Large Clouds Working Group of the IETF.
 
RFC 1736 Functional Recommendations for Internet Resource Locators
 
Authors:J. Kunze.
Date:February 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1736
This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1737 Functional Requirements for Uniform Resource Names
 
Authors:K. Sollins, L. Masinter.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1737
This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1738 Uniform Resource Locators (URL)
 
Authors:T. Berners-Lee, L. Masinter, M. McCahill.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 4248, RFC 4266
Updated by:RFC 1808, RFC 2368, RFC 2396, RFC 3986, RFC 6196, RFC 6270, RFC 8089
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1738
This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet.
 
RFC 1739 A Primer On Internet and TCP/IP Tools
 
Authors:G. Kessler, S. Shepard.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 2151
Status:INFORMATIONAL
DOI:10.17487/RFC 1739
This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1740 MIME Encapsulation of Macintosh Files - MacMIME
 
Authors:P. Faltstrom, D. Crocker, E. Fair.
Date:December 1994
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1740
This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats.
 
RFC 1741 MIME Content Type for BinHex Encoded Files
 
Authors:P. Faltstrom, D. Crocker, E. Fair.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1741
This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files. Only when available software and/or user practice dictates, should this method be employed. It is recommended to use application/applefile [FALT94] for maximum interoperability.
 
RFC 1742 AppleTalk Management Information Base II
 
Authors:S. Waldbusser, K. Frisa.
Date:January 1995
Formats:txt pdf
Obsoletes:RFC 1243
Status:HISTORIC
DOI:10.17487/RFC 1742
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing AppleTalk networks.

RFC 1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of theMIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion.

 
RFC 1743 IEEE 802.5 MIB using SMIv2
 
Authors:K. McCloghrie, E. Decker.
Date:December 1994
Formats:txt pdf
Obsoletes:RFC 1231
Obsoleted by:RFC 1748
Status:DRAFT STANDARD
DOI:10.17487/RFC 1743
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 subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
 
RFC 1744 Observations on the Management of the Internet Address Space
 
Authors:G. Huston.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1744
This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. Possible modifications to the management practices are examined, and potential outcomes considered. Some general conclusions are drawn, and the relevance of these conclusions to the matter of formulation of address management policies for IPv6 are noted.
 
RFC 1745 BGP4/IDRP for IP---OSPF Interaction
 
Authors:K. Varadhan, S. Hares, Y. Rekhter.
Date:December 1994
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1745
This memo defines the various criteria to be used when designing anAutonomous System Border Router (ASBR) that will run either BGP4 orIDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
 
RFC 1746 Ways to Define User Expectations
 
Authors:B. Manning, D. Perkins.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1746
This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet.
 
RFC 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2
 
Authors:J. Hilgeman, S. Nix, A. Bartky, W. Clark, Ed..
Date:January 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1747
This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment.This draft identifies managed objects for SNA Synchronous Data LinkControl (SDLC) links only.
 
RFC 1748 IEEE 802.5 MIB using SMIv2
 
Authors:K. McCloghrie, E. Decker.
Date:December 1994
Formats:txt pdf
Obsoletes:RFC 1743, RFC 1231
Updated by:RFC 1749
Status:DRAFT STANDARD
DOI:10.17487/RFC 1748
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 subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
 
RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2
 
Authors:K. McCloghrie, F. Baker, E. Decker.
Date:December 1994
Formats:txt pdf
Updates:RFC 1748
Status:HISTORIC
DOI:10.17487/RFC 1749
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 by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]
 
RFC 1750 Randomness Recommendations for Security
 
Authors:D. Eastlake 3rd, S. Crocker, J. Schiller.
Date:December 1994
Formats:txt pdf
Obsoleted by:RFC 4086
Status:INFORMATIONAL
DOI:10.17487/RFC 1750
Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.

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

 
RFC 1751 A Convention for Human-Readable 128-bit Keys
 
Authors:D. McDonald.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1751
This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1752 The Recommendation for the IP Next Generation Protocol
 
Authors:S. Bradner, A. Mankin.
Date:January 1995
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1752
This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the InternetProtocol. This recommendation was accepted by the InternetEngineering Steering Group (IESG).
 
RFC 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture
 
Authors:N. Chiappa.
Date:December 1994
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1753
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.

This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. Also presented is some background information, consisting of i) information about architectural and design principles which might apply to the design of a new internetworking layer, and ii) some details of the logic and reasoning behind particular requirements.

 
RFC 1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1
 
Authors:M. Laubach.
Date:January 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1754
This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1755 ATM Signaling Support for IP over ATM
 
Authors:M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis.
Date:February 1995
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1755
This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI)Specification Version 3.1 [ATMF94]. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities.

This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNISpecification Version 3.1. Unless explicitly stated, no distinction is made between the Private and Public UNI.

UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has been produced by the ATM Forum, largely for reasons of alignment withRecommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are several changes that make the two versions incompatible. A description of how to support IP over ATM using UNI 3.0 is found inAppendix B.

 
RFC 1756 Remote Write Protocol - Version 1.0
 
Authors:T. Rinne.
Date:January 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1756
This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1757 Remote Network Monitoring Management Information Base
 
Authors:S. Waldbusser.
Date:February 1995
Formats:txt pdf
Obsoletes:RFC 1271
Obsoleted by:RFC 2819
Status:DRAFT STANDARD
DOI:10.17487/RFC 1757
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices.
 
RFC 1758 NADF Standing Documents: A Brief Overview
 
Authors:The North American Directory Forum.
Date:February 1995
Formats:txt pdf
Obsoletes:RFC 1417
Status:INFORMATIONAL
DOI:10.17487/RFC 1758
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1759 Printer MIB
 
Authors:R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 3805
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1759
A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]
 
RFC 1760 The S/KEY One-Time Password System
 
Authors:N. Haller.
Date:February 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1760
This document describes the S/KEY* One-Time Password system as released for public use by Bellcore and as described in reference[3]. A reference implementation and documentation are available by anonymous ftp from ftp.bellcore.com in the directories pub/nmh/...
 
RFC 1761 Snoop Version 2 Packet Capture File Format
 
Authors:B. Callaghan, R. Gilligan.
Date:February 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1761
This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files.
 
RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP)
 
Authors:S. Senum.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1376
Status:DRAFT STANDARD
DOI:10.17487/RFC 1762
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the NCP for establishing and configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc).

 
RFC 1763 The PPP Banyan Vines Control Protocol (BVCP)
 
Authors:S. Senum.
Date:March 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1763
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 defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP.

 
RFC 1764 The PPP XNS IDP Control Protocol (XNSCP)
 
Authors:S. Senum.
Date:March 1995
Formats:txt pdf
Status:HISTORIC
DOI:10.17487/RFC 1764
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 defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet DatagramProtocol (IDP) over PPP.

 
RFC 1765 OSPF Database Overflow
 
Authors:J. Moy.
Date:March 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1765
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. This memo details a way of gracefully handling unanticipated database overflows.

This memo is a product of the OSPF Working Group. Please send comments to ospf@gated.cornell.edu.

 
RFC 1766 Tags for the Identification of Languages
 
Authors:H. Alvestrand.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 3066, RFC 3282
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1766
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object.

It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822- like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header.

 
RFC 1767 MIME Encapsulation of EDI Objects
 
Authors:D. Crocker.
Date:March 1995
Formats:txt pdf
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1767
Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]
 
RFC 1768 Host Group Extensions for CLNP Multicasting
 
Authors:D. Marlow.
Date:March 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1768
This memo documents work performed in the TUBA (TCP/UDP over BiggerAddresses) working group of IPng area prior to the July 1994 decision to utilize SIPP-16 as the basis for IPng. The TUBA group worked on extending the Internet Protocol suite by the use of ISO 8473 (CLNP) and its related routing protocols. This memo describes multicast extensions to CLNP and its related routing protocols for Internet multicast use. Publication of this memo does not imply acceptance by any IETF Working Group for the ideas expressed within.

This memo provides a specification for multicast extensions to theCLNP protocol similar to those provided to IP by RFC1112. These extensions are intended to provide the mechanisms needed by a host for multicasting in a CLNP based Internet. This memo covers addressing extensions to the CLNP addressing structure, extensions to the CLNP protocol and extensions to the ES-IS protocol. An appendix discusses the differences between IP multicast and the CLNP multicast approach provided in this memo.

 
RFC 1769 Simple Network Time Protocol (SNTP)
 
Authors:D. Mills.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1361
Obsoleted by:RFC 2030, RFC 4330
Status:INFORMATIONAL
DOI:10.17487/RFC 1769
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.

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

 
RFC 1770 IPv4 Option for Sender Directed Multi-Destination Delivery
 
Authors:C. Graff.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1770
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 1771 A Border Gateway Protocol 4 (BGP-4)
 
Authors:Y. Rekhter, T. Li.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1654
Obsoleted by:RFC 4271
Status:DRAFT STANDARD
DOI:10.17487/RFC 1771
This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet.
 
RFC 1772 Application of the Border Gateway Protocol in the Internet
 
Authors:Y. Rekhter, P. Gross.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1655
Status:DRAFT STANDARD
DOI:10.17487/RFC 1772
This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.

Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).

 
RFC 1773 Experience with the BGP-4 protocol
 
Authors:P. Traina.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1656
Status:INFORMATIONAL
DOI:10.17487/RFC 1773
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1774 BGP-4 Protocol Analysis
 
Authors:P. Traina, Ed..
Date:March 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1774
The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1775 To Be "On" the Internet
 
Authors:D. Crocker.
Date:March 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1775
The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access.
 
RFC 1776 The Address is the Message
 
Authors:S. Crocker.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1776
Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1777 Lightweight Directory Access Protocol
 
Authors:W. Yeong, T. Howes, S. Kille.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1487
Obsoleted by:RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1777
The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500Directory, and is intended to be a complement to the DAP itself.

Key aspects of LDAP are:

- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.

- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).

- A lightweight BER encoding is used to encode all protocol elements.

 
RFC 1778 The String Representation of Standard Attribute Syntaxes
 
Authors:T. Howes, S. Kille, W. Yeong, C. Robbins.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1488
Obsoleted by:RFC 3494
Updated by:RFC 2559
Status:HISTORIC
DOI:10.17487/RFC 1778
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].
 
RFC 1779 A String Representation of Distinguished Names
 
Authors:S. Kille.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1485
Obsoleted by:RFC 2253, RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1779
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name.
 
RFC 1780 Internet Official Protocol Standards
 
Authors:J. Postel, Ed..
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1720
Obsoleted by:RFC 1800
Status:HISTORIC
DOI:10.17487/RFC 1780
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
 
RFC 1781 Using the OSI Directory to Achieve User Friendly Naming
 
Authors:S. Kille.
Date:March 1995
Formats:txt pdf
Obsoletes:RFC 1484
Obsoleted by:RFC 3494
Status:HISTORIC
DOI:10.17487/RFC 1781
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them.This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [5], and it is intended that these specifications are compatible.

 
RFC 1782 TFTP Option Extension
 
Authors:G. Malkin, A. Harkin.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 2347
Updates:RFC 1350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1782
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.
 
RFC 1783 TFTP Blocksize Option
 
Authors:G. Malkin, A. Harkin.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 2348
Updates:RFC 1350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1783
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes or greater.

This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2].

 
RFC 1784 TFTP Timeout Interval and Transfer Size Options
 
Authors:G. Malkin, A. Harkin.
Date:March 1995
Formats:txt pdf
Obsoleted by:RFC 2349
Updates:RFC 1350
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1784
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.

This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2].

This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].

 
RFC 1785 TFTP Option Negotiation Analysis
 
Authors:G. Malkin, A. Harkin.
Date:March 1995
Formats:txt pdf
Updates:RFC 1350
Status:INFORMATIONAL
DOI:10.17487/RFC 1785
The TFTP option negotiation mechanism, proposed in [1], is a backward-compatible extension to the TFTP protocol, defined in [2].It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's RequestPacket format. The mechanism is kept simple by enforcing a request- respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.

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

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

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

 
RFC 1788 ICMP Domain Name Messages
 
Authors:W. Simpson.
Date:April 1995
Formats:txt pdf
Obsoleted by:RFC 6918
Status:HISTORIC
DOI:10.17487/RFC 1788
This document specifies ICMP messages for learning the FullyQualified Domain Name associated with an IP address.
 
RFC 1789 INETPhone: Telephone Services and Servers on Internet
 
Authors:C. Yang.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1789
INETPhone is a true telephone service through the Internet. It integrates the local telephone networks and the Internet usingINETPhone servers. Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. In order to support theINETPhone and lay down the ground rules of the service, a scheme of"open partnership" is proposed, so that the entire Internet community can have the equal opportunity and benefits from the INETPhone service.
 
RFC 1790 An Agreement between the Internet Society and Sun Microsystems, Inc
 
Authors:in the Matter of ONC RPC and XDR Protocols. V. Cerf.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1790
This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
 
RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU
 
Authors:T. Sung.
Date:April 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1791
TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
 
RFC 1792 TCP/IPX Connection Mib Specification
 
Authors:T. Sung.
Date:April 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1792
New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
 
RFC 1793 Extending OSPF to Support Demand Circuits
 
Authors:J. Moy.
Date:April 1995
Formats:txt pdf
Updated by:RFC 3883
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1793
This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic.

Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open.

While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio.

The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- to-MultiPoint Interface).

This memo provides functionality similar to that specified for RIP in[2], with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, becauseOSPF employs link-state routing technology as opposed to RIP'sDistance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different.

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

 
RFC 1794 DNS Support for Load Balancing
 
Authors:T. Brisco.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1794
This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1
 
Authors:L. Wells, A. Bartky, Ed..
Date:April 1995
Formats:txt pdf
Obsoletes:RFC 1434
Status:INFORMATIONAL
DOI:10.17487/RFC 1795
This RFC describes use of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and Implementers.

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

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

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

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

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

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

 
RFC 1796 Not All RFCs are Standards
 
Authors:C. Huitema, J. Postel, S. Crocker.
Date:April 1995
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1796
This document discusses the relationship of the Request for Comments(RFCs) notes to Internet Standards.
 
RFC 1797 Class A Subnet Experiment
 
Authors:Internet Assigned Numbers Authority (IANA).
Date:April 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1797
There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
 
RFC 1798 Connection-less Lightweight X.500 Directory Access Protocol
 
Authors:A. Young.
Date:June 1995
Formats:txt pdf
Obsoleted by:RFC 3352
Status:HISTORIC
DOI:10.17487/RFC 1798
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]
 
RFC 1799 Request for Comments Summary RFC Numbers 1700-1799
 
Authors:M. Kennedy.
Date:January 1997
Formats:txt pdf
Status:INFORMATIONAL
DOI:10.17487/RFC 1799