| |
| RFC 1500 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1501 | OS/2 User Group |
| |
| Authors: | E. Brunsen. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1501 |
|
Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind. |
|
| |
| RFC 1502 | X.400 Use of Extended Character Sets |
| |
| Authors: | H. Alvestrand. |
| Date: | August 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1502 |
|
This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS- TRACK] |
|
| |
| RFC 1503 | Algorithms for Automating Administration in SNMPv2 Managers |
| |
| Authors: | K. McCloghrie, M. Rose. |
| Date: | August 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1503 |
|
When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1504 | Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing |
| |
| Authors: | A. Oppenheimer. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1504 |
|
This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1505 | Encoding Header Field for Internet Messages |
| |
| Authors: | A. Costanzo, D. Robinson, R. Ullmann. |
| Date: | August 1993 |
| Formats: | txt json html |
| Obsoletes: | RFC 1154 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1505 |
|
This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154 [1]. |
|
| |
| RFC 1506 | A Tutorial on Gatewaying between X.400 and Internet Mail |
| |
| Authors: | J. Houttuin. |
| Date: | August 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1506 |
|
This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1507 | DASS - Distributed Authentication Security Service |
| |
| Authors: | C. Kaufman. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1507 |
|
The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1508 | Generic Security Service Application Program Interface |
| |
|
|
This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms |
|
| |
| RFC 1509 | Generic Security Service API : C-bindings |
| |
|
|
This document specifies C language bindings for the Generic SecurityService Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents.
The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. |
|
| |
| RFC 1510 | The Kerberos Network Authentication Service (V5) |
| |
|
|
This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites. |
|
| |
| RFC 1511 | Common Authentication Technology Overview |
| |
| Authors: | J. Linn. |
| Date: | September 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1511 |
|
This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1512 | FDDI Management Information Base |
| |
|
|
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 devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard [8], which has been forwarded for publication by the X3T9.5 committee. |
|
| |
| RFC 1513 | Token Ring Extensions to the Remote Network Monitoring MIB |
| |
|
|
This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks.
The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This companion memo defines those specific objects necessary for TokenRing LANs.
In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring StationGroup, the Ring Station Order Group, the Ring Station ConfigurationGroup, and the Source Routing Statistics Group. |
|
| |
| RFC 1514 | Host Resources MIB |
| |
| Authors: | P. Grillo, S. Waldbusser. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1514 |
|
This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. |
|
| |
| RFC 1515 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1515 |
|
This document 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 IEEE 802.3Medium Attachment Units (MAUs). |
|
| |
| RFC 1516 | Definitions of Managed Objects for IEEE 802.3 Repeater Devices |
| |
|
|
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 IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs." |
|
| |
| RFC 1517 | Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) |
| |
| Authors: | Internet Engineering Steering Group, R. Hinden. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1517 |
|
Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK] |
|
| |
| RFC 1518 | An Architecture for IP Address Allocation with CIDR |
| |
| Authors: | Y. Rekhter, T. Li. |
| Date: | September 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1518 |
|
This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK] |
|
| |
| RFC 1519 | Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy |
| |
| Authors: | V. Fuller, T. Li, J. Yu, K. Varadhan. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoletes: | RFC 1338 |
| Obsoleted by: | RFC 4632 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1519 |
|
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. |
|
| |
| RFC 1520 | Exchanging Routing Information Across Provider Boundaries in the CIDR Environment |
| |
| Authors: | Y. Rekhter, C. Topolcic. |
| Date: | September 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1520 |
|
The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1521 | MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies |
| |
|
|
STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC822.
In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi- font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.
This document does NOT extend Internet mail header fields to permit anything other than US-ASCII text data. Such extensions are the subject of a companion document [RFC-1522].
This document is a revision of RFC 1341. Significant differences from RFC 1341 are summarized in Appendix H. |
|
| |
| RFC 1522 | MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text |
| |
|
|
This memo describes an extension to the message format defined in RFC1521 [1], to allow the representation of character sets other thanASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. |
|
| |
| RFC 1523 | The text/enriched MIME Content-type |
| |
|
|
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 json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1524 |
|
This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined byRFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and theMultipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system. |
|
| |
| RFC 1525 | Definitions of Managed Objects for Source Routing Bridges |
| |
| Authors: | E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoletes: | RFC 1286 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1525 |
|
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 source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK] |
|
| |
| RFC 1526 | Assignment of System Identifiers for TUBA/CLNP Hosts |
| |
| Authors: | D. Piscitello. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1526 |
|
This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion. |
|
| |
| RFC 1527 | What Should We Plan Given the Dilemma of the Network? |
| |
| Authors: | G. Cook. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1527 |
|
Early last year, as the concluding effort of an 18 month appointment at the US Congress Office of Technology Assessment (OTA), I drafted a potential policy framework for Congressional action on the NationalResearch and Education Network (NREN).
The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow forCongress to make?
It is unfortunate that this was never officially done for or by theCongress by OTA. What we have as a result is network policy making being carried out now by the Science Subcommittee on the House side in consultation with a relatively small group of interested parties.The debate seems to be more focused on preserving turf than on any sweeping understanding of what the legislation is doing. That is unfortunate.
In the hope that it may contain some useful ideas, I offer a shortened version of the suggested policy draft as information for the Internet community. |
|
| |
| RFC 1528 | Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures |
| |
|
|
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1529 | Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies |
| |
|
|
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 json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1530 |
|
This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System [1,2].
This document is informational and applies only to those Internet sites that choose to register themselves within the tpc.int subdomain. The tpc.int subdomain is organized as a cooperative of the sites that provide access within the context of the subdomain.Policy for the subdomain is set by a board responsible to the cooperative.
The primary purpose of the tpc.int subdomain is to provide transparent mapping between general-purpose computers on the Internet and special-purpose devices directly connected to the telephone network. Initially, a remote printing service is defined [3,4] which ties together G3-compatible facsimile devices on the telephone network with users of electronic mail in the Internet and associated message-handling domains connected to the Internet by application- layer gateways.
It should be noted that remote printer gateways have long been technically feasible and have become an integral part of many individual networks. The tpc.int subdomain integrates individual sites into a common namespace, transforming remote printing from a single-site, value-added service into an integral transparent service in the global Internet. |
|
| |
| RFC 1531 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. |
|
| |
| RFC 1532 | Clarifications and Extensions for the Bootstrap Protocol |
| |
|
|
Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas.
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these. |
|
| |
| RFC 1533 | DHCP Options and BOOTP Vendor Extensions |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message. The data items themselves are also called"options."
This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined.Each superseding document will include the entire current list of valid options.
All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions. |
|
| |
| RFC 1534 | Interoperation Between DHCP and BOOTP |
| |
| Authors: | R. Droms. |
| Date: | October 1993 |
| Formats: | txt json html |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1534 |
|
DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. |
|
| |
| RFC 1535 | A Security Problem and Proposed Correction With Widely Deployed DNS Software |
| |
| Authors: | E. Gavron. |
| Date: | October 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1535 |
|
This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit (although not by the masses). This document points out the flaw, a case in point, and a solution. |
|
| |
| RFC 1536 | Common DNS Implementation Errors and Suggested Fixes |
| |
| Authors: | A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. |
| Date: | October 1993 |
| Formats: | txt html json |
| Updated by: | RFC 9210 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1536 |
|
This memo describes common errors seen in DNS implementations and suggests some fixes. Where applicable, violations of recommendations from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo also describes, where relevant, the algorithms followed in BIND(versions 4.8.3 and 4.9 which the authors referred to) to serve as an example. |
|
| |
| RFC 1537 | Common DNS Data File Configuration Errors |
| |
|
|
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 json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1538 |
|
This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors. Any questions or comments relative to the contents of this RFC may be sent to the followingInternet address: snaip@mcdata.com. |
|
| |
| RFC 1539 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
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 1540 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1541 | Dynamic Host Configuration Protocol |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC1531 in the editorial process, this memo is reissued as RFC 1541. |
|
| |
| RFC 1542 | Clarifications and Extensions for the Bootstrap Protocol |
| |
|
|
Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. Due to some errors introduced into RFC 1532 in the editorial process, this memo is reissued as RFC 1542.
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these. |
|
| |
| RFC 1543 | Instructions to RFC Authors |
| |
|
|
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 1544 | The Content-MD5 Header Field |
| |
|
|
This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. |
|
| |
| RFC 1545 | FTP Operation Over Big Address Records (FOOBAR) |
| |
|
|
This paper describes a convention for specifying longer addresses in the PORT command. |
|
| |
| RFC 1546 | Host Anycasting Service |
| |
| Authors: | C. Partridge, T. Mendez, W. Milliken. |
| Date: | November 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1546 |
|
This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. Insofar as is possible, this memo tries to be agnostic about how the service is actually provided by the internetwork. This memo describes an experimental service and does not propose a protocol. This memo is produced by the Internet Research Task Force (IRTF). |
|
| |
| RFC 1547 | Requirements for an Internet Standard Point-to-Point Protocol |
| |
| Authors: | D. Perkins. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1547 |
|
This document discusses the evaluation criteria for an InternetStandard Data Link Layer protocol to be used with point-to-point links. Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an InternetStandard. In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an InternetStandard are discussed in detail. An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues.
Historical Note: This was the design requirements document datedJune 1989, which was followed for RFC-1134 through the present.It is now published for completeness and future guidance. |
|
| |
| RFC 1548 | The Point-to-Point Protocol (PPP) |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1549 | PPP in HDLC Framing |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1550 | IP: Next Generation (IPng) White Paper Solicitation |
| |
| Authors: | S. Bradner, A. Mankin. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1550 |
|
This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1551 | Novell IPX Over Various WAN Media (IPXWAN) |
| |
|
|
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 1552 | The PPP Internetworking Packet Exchange Control Protocol (IPXCP) |
| |
| Authors: | W. Simpson. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1552 |
|
The Point-to-Point Protocol (PPP) [1] provides a method for transmitting 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 IPX protocol was originally used in Novell's NetWare products[3], and is now supported by numerous other vendors. This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP.
This memo is the product of the Point-to-Point Protocol Working Group of the IETF. Comments should be submitted to the ietf- ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1553 | Compressing IPX Headers Over WAN Media (CIPX) |
| |
| Authors: | S. Mathur, M. Lewis. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1553 |
|
This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX can provide a compression ratio of approximately 2:1 including both IPX header and data. This method can be used on various type of WAN media, including those supporting PPP and X.25.
This memo ia a product of the Point-to-Point Protocol Extensions(PPPEXT) Working Group of the IETF. Comments should be sent to the authors and the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1554 | ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP |
| |
| Authors: | M. Ohta, K. Handa. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1554 |
|
This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1555 | Hebrew Character Encoding for Internet Messages |
| |
| Authors: | H. Nussbacher, Y. Bourvine. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1555 |
|
This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME[RFC1521] and ISO-8859-8. |
|
| |
| RFC 1556 | Handling of Bi-directional Texts in MIME |
| |
| Authors: | H. Nussbacher. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1556 |
|
This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. |
|
| |
| RFC 1557 | Korean Character Encoding for Internet Messages |
| |
| Authors: | U. Choi, K. Chon, H. Park. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1557 |
|
This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1558 | A String Representation of LDAP Search Filters |
| |
|
|
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 1559 | DECnet Phase IV MIB Extensions |
| |
|
|
This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK] |
|
| |
| RFC 1560 | The MultiProtocol Internet |
| |
| Authors: | B. Leiner, Y. Rekhter. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1560 |
|
This document was prepared by the authors on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.
There has recently been considerable discussion on two topics:MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.
In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should:
- maintain its focus on the TCP/IP protocol suite,
- work to select a single next-generation internet protocol and develop mechanisms to aid in transition from the current IPv4, and
- continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet. |
|
| |
| RFC 1561 | Use of ISO CLNP in TUBA Environments |
| |
| Authors: | D. Piscitello. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1561 |
|
This memo specifies a profile of the ISO/IEC 8473 Connectionless-modeNetwork Layer Protocol (CLNP, [1]) for use in conjunction with RFC1347, TCP/UDP over Bigger Addresses (TUBA, [2]). It describes the use of CLNP to provide the lower-level service expected byTransmission Control Protocol (TCP, [3]) and User Datagram Protocol(UDP, [4]). CLNP provides essentially the same datagram service asInternet Protocol (IP, [5]), but offers a means of conveying bigger network addresses (with additional structure, to aid routing).
While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments.This maximizes the use of already-deployed CLNP implementations. |
|
| |
| RFC 1562 | Naming Guidelines for the AARNet X.500 Directory Service |
| |
| Authors: | G. Michaelson, M. Prior. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1562 |
|
AARNet is a member network of the global Internet and participates in the global Internet X.500 based Directory Service. A number of RFC's have been issued that make recommendations that alter or supplement the OSI/ETU standards for X.500 [1]. In general, these RFCs will be followed by the AARNet Directory Service. However, in certain cases we wish to align ourselves with our national ISO body (StandardsAustralia) rather than the Internet where they conflict. In naming, we have chosen to align ourselves with Standards Australia and this document notes the difference in our approach to the Internet guidelines suggested in RFC 1384 [2]. |
|
| |
| RFC 1563 | The text/enriched MIME Content-type |
| |
|
|
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 html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1564 |
|
This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. The intention is that the replies to the questions posed provide a fairly full description of a DSA. Some of the questions will yield answers which are purely descriptive; others, however, are intended to elicit answers which give some measure of the utility of the DSA. The marks awarded for a DSA in each particular area should give a good indication of the DSA's capabilities, and its suitability for particular uses.
Please send comments to the authors or to the discussion group<osi-ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1565 | Network Services Monitoring MIB |
| |
| Authors: | S. Kille, N. Freed. |
| Date: | January 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1565 |
|
This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK] |
|
| |
| RFC 1566 | Mail Monitoring MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK] |
|
| |
| RFC 1567 | X.500 Directory Monitoring MIB |
| |
| Authors: | G. Mansfield, S. Kille. |
| Date: | January 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2605 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1567 |
|
This document defines a portion of the Management Information Base(MIB). It defines the MIB for monitoring Directory System Agents(DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. |
|
| |
| RFC 1568 | Simple Network Paging Protocol - Version 1(b) |
| |
|
|
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 |
| |
|
|
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 1570 | PPP LCP Extensions |
| |
|
|
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. This document defines several additional LCP features which have been suggested over the past few years.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1571 | Telnet Environment Option Interoperability Issues |
| |
|
|
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 1572 | Telnet Environment Option |
| |
| Authors: | S. Alexander, Ed.. |
| Date: | January 1994 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1572 |
|
This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting.
This document corrects some errors in [1]. |
|
| |
| RFC 1573 | Evolution of the Interfaces Group of MIB-II |
| |
|
|
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 Network Interfaces. [STANARDS-TRACK] |
|
| |
| RFC 1574 | Essential Tools for the OSI Internet |
| |
|
|
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 1575 | An Echo Function for CLNP (ISO 8473) |
| |
| Authors: | S. Hares, C. Wittbrodt. |
| Date: | February 1994 |
| Formats: | txt html json |
| Obsoletes: | RFC 1139 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1575 |
|
This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of anEcho function to ISO 8473" an integral part of Version 2 of ISO 8473. |
|
| |
| RFC 1576 | TN3270 Current Practices |
| |
| Authors: | J. Penner. |
| Date: | January 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1576 |
|
This document describes the existing implementation of transferring3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270.
Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators.
The following areas pertaining to TN3270 implementations are covered in this document:
1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data stream commands
2. the method for sending and receiving 3270 data
3. the method of handling some special keys known as SYSREQ andATTN using current available telnet commands
4. the events that will transition a TN3270 session back to an NVT session |
|
| |
| RFC 1577 | Classical IP and ARP over ATM |
| |
|
|
This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connectingIP end-stations ("members") and routers operating in the "classical"LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.
This memo introduces general ATM technology and nomenclature.Readers are encouraged to review the ATM Forum and ITU-TS (formerlyCCITT) references for more detailed information about ATM implementation agreements and standards. |
|
| |
| RFC 1578 | FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions |
| |
|
|
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 html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1579 |
|
This memo describes a suggested change to the behavior of FTP client programs. No protocol modifications are required, though we outline some that might be useful. |
|
| |
| RFC 1580 | Guide to Network Resource Tools |
| |
|
|
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 html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1581 |
|
As required by Routing Protocol Criteria [1], this report documents the key features of Routing over Demand Circuits on Wide AreaNetworks - RIP [2] and the current implementation experience. |
|
| |
| RFC 1582 | Extensions to RIP to Support Demand Circuits |
| |
| Authors: | G. Meyer. |
| Date: | February 1994 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1582 |
|
Running routing protocols on connection oriented Public DataNetworks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data.
Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide AreaNetwork (WAN).
This memo defines a generalized modification which can be applied toBellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above.
The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links.
Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface.When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces. Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN. An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received.
The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN. |
|
| |
| RFC 1583 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. Separate routes can be calculated for each IP Type of Service. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in AppendixE. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 1584 | Multicast Extensions to OSPF |
| |
|
|
This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge.
OSPF, a link-state routing protocol, provides a database describing the Autonomous System's topology. A new OSPF link state advertisement is added describing the location of multicast destinations. A multicast packet's path is then calculated by building a pruned shortest-path tree rooted at the packet's IP source. These trees are built on demand, and the results of the calculation are cached for use by subsequent packets.
The multicast extensions are built on top of OSPF Version 2. The extensions have been implemented so that a multicast routing capability can be introduced piecemeal into an OSPF Version 2 routing domain. Some of the OSPF Version 2 routers may run the multicast extensions, while others may continue to be restricted to the forwarding of regular IP traffic (unicasts).
Please send comments to mospf@gated.cornell.edu. |
|
| |
| RFC 1585 | MOSPF: Analysis and Experience |
| |
| Authors: | J. Moy. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1585 |
|
This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering TaskForce internet routing protocol standardization criteria" ([RFC1264]).
Please send comments to mospf@gated.cornell.edu. |
|
| |
| RFC 1586 | Guidelines for Running OSPF Over Frame Relay Networks |
| |
| Authors: | O. deSouza, M. Rodrigues. |
| Date: | March 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1586 |
|
This memo specifies guidelines for implementors and users of the OpenShortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently. |
|
| |
| RFC 1587 | The OSPF NSSA Option |
| |
| Authors: | R. Coltun, V. Fuller. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3101 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1587 |
|
This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK] |
|
| |
| RFC 1588 | White Pages Meeting Report |
| |
| Authors: | J. Postel, C. Anderson. |
| Date: | February 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1588 |
|
This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1589 | A Kernel Model for Precision Timekeeping |
| |
| Authors: | D. Mills. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1589 |
|
This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1590 | Media Type Registration Procedure |
| |
|
|
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 html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1591 |
|
This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1592 | Simple Network Management Protocol Distributed Protocol Interface Version 2.0 |
| |
| Authors: | B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1228 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1592 |
|
This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol 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 json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1593 |
|
This RFC describes IBM's SNMP support for SNA Advanced Peer-to-PeerNetworking (APPN) nodes. |
|
| |
| RFC 1594 | FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions |
| |
|
|
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 1595 | Definitions of Managed Objects for the SONET/SDH Interface Type |
| |
| Authors: | T. Brown, K. Tesink. |
| Date: | March 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2558 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1595 |
|
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 Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407[13].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 1596 | Definitions of Managed Objects for Frame Relay Service |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service. |
|
| |
| RFC 1597 | Address Allocation for Private Internets |
| |
| Authors: | Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1597 |
|
This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1598 | PPP in X.25 |
| |
| Authors: | W. Simpson. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1598 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of X.25 for framing PPP encapsulated packets.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. |
|
| |
| RFC 1599 | Summary of 1500-1599 |
| |
| Authors: | M. Kennedy. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1599 |
|
|
|
